From falk at ISI.EDU Wed Nov 8 13:46:15 2006 From: falk at ISI.EDU (Aaron Falk) Date: Wed, 8 Nov 2006 13:46:15 -0800 Subject: [xcp] making the XCP specification an RFC Message-ID: <4894E12B-74F6-42C5-B5E4-87192CC436AB@ISI.EDU> Folks- We've refreshed the XCP spec Internet Draft, fixing a few typos along the way. The document can be downloaded at: http://www.isi.edu/isi-xcp/docs/draft-falk-xcp-spec-02.txt http://www.isi.edu/isi-xcp/docs/draft-falk-xcp-spec-02.html I plan to submit it to the RFC editor for publication as an Experimental RFC. (This is a category of independent submission, not a standard.) The objective of RFC publication is to capture the state of our work, which is winding down, and provide a stable reference point that matches our BSD implementation of XCP. If anyone would like to provide comments on the draft, we (Yuri, actually) will do our best to make appropriate revisions before publication. Regards, --aaron From fla at inescporto.pt Wed Nov 22 09:24:12 2006 From: fla at inescporto.pt (Filipe Abrantes) Date: Wed, 22 Nov 2006 17:24:12 +0000 Subject: [xcp] making the XCP specification an RFC In-Reply-To: <4894E12B-74F6-42C5-B5E4-87192CC436AB@ISI.EDU> References: <4894E12B-74F6-42C5-B5E4-87192CC436AB@ISI.EDU> Message-ID: <456487BC.7040509@inescporto.pt> Hi all, One comment regarding Section 6 Security Considerations. 3 types of attacks are stated for malicious sources, however nothing is said about malicious sinks/receivers. A sink may increase the amount of bandwidth fed back to the source inducing the sender to send faster than the "fair share". Clearly there is an incentive for receivers to do this, and this is introduced by XCP (there is no way a TCP sink can do this). The feedback information returned by the receivers can be policed at the edge of the network in a counter-based approach, each forward data packet would get it's feedback value added to the counter, while each ACK packet would decrease the counter by the value of the feedback field it carries. When the counter gets to zero, the feedback field of the ACK packet gets zeroed as well. Possibly some punitive action could be taken against the malicious receiver as well. What do you think? (and sorry for the delay on the comment) Cheers, Filipe Aaron Falk wrote: > Folks- > > We've refreshed the XCP spec Internet Draft, fixing a few typos along > the way. The document can be downloaded at: > > http://www.isi.edu/isi-xcp/docs/draft-falk-xcp-spec-02.txt > http://www.isi.edu/isi-xcp/docs/draft-falk-xcp-spec-02.html > > I plan to submit it to the RFC editor for publication as an > Experimental RFC. (This is a category of independent submission, not > a standard.) The objective of RFC publication is to capture the > state of our work, which is winding down, and provide a stable > reference point that matches our BSD implementation of XCP. If > anyone would like to provide comments on the draft, we (Yuri, > actually) will do our best to make appropriate revisions before > publication. > > Regards, > > --aaron > _______________________________________________ > xcp mailing list > xcp at isi.edu > http://mailman.isi.edu/mailman/listinfo/xcp > > -- Filipe Abrantes INESC Porto fla at inescporto.pt Certificate Auth https://ra.inescporto.pt/pub/cacert/cacert.crt -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4475 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.isi.edu/pipermail/xcp/attachments/20061122/0cc47993/smime.bin From ecoe at ISI.EDU Wed Nov 22 13:24:59 2006 From: ecoe at ISI.EDU (Eric Coe) Date: Wed, 22 Nov 2006 13:24:59 -0800 Subject: [xcp] making the XCP specification an RFC In-Reply-To: <456487BC.7040509@inescporto.pt> References: <4894E12B-74F6-42C5-B5E4-87192CC436AB@ISI.EDU> <456487BC.7040509@inescporto.pt> Message-ID: <4564C02B.4060606@isi.edu> Filipe Abrantes wrote: > Hi all, > One comment regarding Section 6 Security Considerations. 3 types of > attacks are stated for malicious sources, however nothing is said about > malicious sinks/receivers. A sink may increase the amount of bandwidth > fed back to the source inducing the sender to send faster than the "fair > share". Clearly there is an incentive for receivers to do this, and this > is introduced by XCP (there is no way a TCP sink can do this). TCP receivers can do this... it's called optimistic acking. Basically receivers ack data before it arrives which increases the congestion window on the sender and allows flows to receive an inflated share of BW. Here is a link to the paper from CCS 2005. http://www.cs.umd.edu/~capveg/optack/optack-extended.pdf > The feedback information returned by the receivers can be policed at the > edge of the network in a counter-based approach, each forward data > packet would get it's feedback value added to the counter, while each > ACK packet would decrease the counter by the value of the feedback field > it carries. When the counter gets to zero, the feedback field of the ACK > packet gets zeroed as well. Possibly some punitive action could be taken > against the malicious receiver as well. You might be able to do this over some "bin" of throughput values but it will be difficult to accomplish without introducing substantial state. Quantifying the trade-off for state introduced and the benefits of subverting malicious users seems like an important question. -Eric > Aaron Falk wrote: >> Folks- >> >> We've refreshed the XCP spec Internet Draft, fixing a few typos along >> the way. The document can be downloaded at: >> >> http://www.isi.edu/isi-xcp/docs/draft-falk-xcp-spec-02.txt >> http://www.isi.edu/isi-xcp/docs/draft-falk-xcp-spec-02.html >> >> I plan to submit it to the RFC editor for publication as an >> Experimental RFC. (This is a category of independent submission, not >> a standard.) The objective of RFC publication is to capture the >> state of our work, which is winding down, and provide a stable >> reference point that matches our BSD implementation of XCP. If >> anyone would like to provide comments on the draft, we (Yuri, >> actually) will do our best to make appropriate revisions before >> publication. >> >> Regards, >> >> --aaron >> _______________________________________________ >> xcp mailing list >> xcp at isi.edu >> http://mailman.isi.edu/mailman/listinfo/xcp >> >> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > xcp mailing list > xcp at isi.edu > http://mailman.isi.edu/mailman/listinfo/xcp From falk at ISI.EDU Wed Nov 22 13:30:36 2006 From: falk at ISI.EDU (Aaron Falk) Date: Wed, 22 Nov 2006 13:30:36 -0800 Subject: [xcp] making the XCP specification an RFC In-Reply-To: <4564C02B.4060606@isi.edu> References: <4894E12B-74F6-42C5-B5E4-87192CC436AB@ISI.EDU> <456487BC.7040509@inescporto.pt> <4564C02B.4060606@isi.edu> Message-ID: On Nov 22, 2006, at 1:24 PM, Eric Coe wrote: > Filipe Abrantes wrote: >> Hi all, >> One comment regarding Section 6 Security Considerations. 3 types >> of attacks are stated for malicious sources, however nothing is >> said about malicious sinks/receivers. A sink may increase the >> amount of bandwidth fed back to the source inducing the sender to >> send faster than the "fair share". Clearly there is an incentive >> for receivers to do this, and this is introduced by XCP (there is >> no way a TCP sink can do this). > TCP receivers can do this... it's called optimistic acking. > Basically receivers ack data before it arrives which increases the > congestion window on the sender and allows flows to receive an > inflated share of BW. Here is a link to the paper from CCS 2005. > http://www.cs.umd.edu/~capveg/optack/optack-extended.pdf > >> The feedback information returned by the receivers can be policed >> at the edge of the network in a counter-based approach, each >> forward data packet would get it's feedback value added to the >> counter, while each ACK packet would decrease the counter by the >> value of the feedback field it carries. When the counter gets to >> zero, the feedback field of the ACK packet gets zeroed as well. >> Possibly some punitive action could be taken against the malicious >> receiver as well. > > You might be able to do this over some "bin" of throughput values > but it will be difficult to accomplish without introducing > substantial state. Quantifying the trade-off for state introduced > and the benefits of subverting malicious users seems like an > important question. Perhaps a policer between the receiver and his first hop router could use an ECN nonce-like scheme to verify that feedback was being accurately being copied from received packets into ACKs. --aaron From yuri at ISI.EDU Wed Nov 22 16:46:19 2006 From: yuri at ISI.EDU (Yuri Pradkin) Date: Wed, 22 Nov 2006 16:46:19 -0800 Subject: [xcp] making the XCP specification an RFC In-Reply-To: References: <4894E12B-74F6-42C5-B5E4-87192CC436AB@ISI.EDU> <456487BC.7040509@inescporto.pt> <4564C02B.4060606@isi.edu> Message-ID: <20061123004619.GA19860@yap.isi.edu> On Wed, Nov 22, 2006 at 01:30:36PM -0800, Aaron Falk wrote: > > On Nov 22, 2006, at 1:24 PM, Eric Coe wrote: > > > Filipe Abrantes wrote: > >> Hi all, > >> One comment regarding Section 6 Security Considerations. 3 types > >> of attacks are stated for malicious sources, however nothing is > >> said about malicious sinks/receivers. A sink may increase the > >> amount of bandwidth fed back to the source inducing the sender to > >> send faster than the "fair share". Clearly there is an incentive > >> for receivers to do this, and this is introduced by XCP (there is > >> no way a TCP sink can do this). > > TCP receivers can do this... it's called optimistic acking. > > Basically receivers ack data before it arrives which increases the > > congestion window on the sender and allows flows to receive an > > inflated share of BW. Here is a link to the paper from CCS 2005. > > http://www.cs.umd.edu/~capveg/optack/optack-extended.pdf > > > >> The feedback information returned by the receivers can be policed > >> at the edge of the network in a counter-based approach, each > >> forward data packet would get it's feedback value added to the > >> counter, while each ACK packet would decrease the counter by the > >> value of the feedback field it carries. When the counter gets to > >> zero, the feedback field of the ACK packet gets zeroed as well. > >> Possibly some punitive action could be taken against the malicious > >> receiver as well. > > > > You might be able to do this over some "bin" of throughput values > > but it will be difficult to accomplish without introducing > > substantial state. Quantifying the trade-off for state introduced > > and the benefits of subverting malicious users seems like an > > important question. > > Perhaps a policer between the receiver and his first hop router could > use an ECN nonce-like scheme to verify that feedback was being > accurately being copied from received packets into ACKs. > This problem is exacerbated a little bit by the fact that it's not always a matter of simply copying the feedback value. A receiver may not ACK every single packet and can accumulate feedback from several packets before returning it to the sender (delayed acking). What Filipe suggested seems one way of doing it. And it can be done probabilistically by monitoring a random flow for several data/ack exchanges. This way you could save on the state required. Another way to detect such things may be at the bottleneck router. This seems to be a case of a truthful but non-responsive sender who keeps reporting rate that's too high, but doesn't slow down, because the receiver is tampering with feedback. -Yuri From fla at inescporto.pt Thu Nov 23 10:18:36 2006 From: fla at inescporto.pt (Filipe Abrantes) Date: Thu, 23 Nov 2006 18:18:36 +0000 Subject: [xcp] making the XCP specification an RFC In-Reply-To: <20061123004619.GA19860@yap.isi.edu> References: <4894E12B-74F6-42C5-B5E4-87192CC436AB@ISI.EDU> <456487BC.7040509@inescporto.pt> <4564C02B.4060606@isi.edu> <20061123004619.GA19860@yap.isi.edu> Message-ID: <4565E5FC.5040007@inescporto.pt> Yuri Pradkin wrote: > On Wed, Nov 22, 2006 at 01:30:36PM -0800, Aaron Falk wrote: > >> On Nov 22, 2006, at 1:24 PM, Eric Coe wrote: >> >> >>> Filipe Abrantes wrote: >>> >>>> Hi all, >>>> One comment regarding Section 6 Security Considerations. 3 types >>>> of attacks are stated for malicious sources, however nothing is >>>> said about malicious sinks/receivers. A sink may increase the >>>> amount of bandwidth fed back to the source inducing the sender to >>>> send faster than the "fair share". Clearly there is an incentive >>>> for receivers to do this, and this is introduced by XCP (there is >>>> no way a TCP sink can do this). >>>> >>> TCP receivers can do this... it's called optimistic acking. >>> Basically receivers ack data before it arrives which increases the >>> congestion window on the sender and allows flows to receive an >>> inflated share of BW. Here is a link to the paper from CCS 2005. >>> http://www.cs.umd.edu/~capveg/optack/optack-extended.pdf >>> >>> Thanks for the reference, and thanks for pointing that out. I guess it puts XCP on the same position as TCP. Maybe the attack would be easier to perform/implement with XCP but that would be it. >>>> The feedback information returned by the receivers can be policed >>>> at the edge of the network in a counter-based approach, each >>>> forward data packet would get it's feedback value added to the >>>> counter, while each ACK packet would decrease the counter by the >>>> value of the feedback field it carries. When the counter gets to >>>> zero, the feedback field of the ACK packet gets zeroed as well. >>>> Possibly some punitive action could be taken against the malicious >>>> receiver as well. >>>> >>> You might be able to do this over some "bin" of throughput values >>> but it will be difficult to accomplish without introducing >>> substantial state. Quantifying the trade-off for state introduced >>> and the benefits of subverting malicious users seems like an >>> important question. >>> I thought of doing this without keeping any state. Sum all feedbacks from all flows coming in one way (data packets), and then subtract every feedback coming the other way (ACK packets), and never let the counter go to zero. The malicious receiver could still mix the feedbacks between flows (use the feedback of a certain flow for another flow), but I don't see much incentive to that. The counter would only be needed at the edge of the network (first-hop router). [however, it could be used at inter-domain borders as well]. Then again, maybe a host would start "dummy" flows just to get some extra feedback for a particular flow... :/ (not too practical though). Policing per-flow would assure correct behaviour of the receiver, but it has the state keeping trade-off that you mention. It could be reduced by doing it for a flow (or a subset of flows) at a time as Yuri mentions below. >> Perhaps a policer between the receiver and his first hop router could >> use an ECN nonce-like scheme to verify that feedback was being >> accurately being copied from received packets into ACKs. >> >> > > Would this require per-packet state at the policer? > This problem is exacerbated a little bit by the fact that it's not > always a matter of simply copying the feedback value. A receiver > may not ACK every single packet and can accumulate feedback from > several packets before returning it to the sender (delayed acking). > > > What Filipe suggested seems one way of doing it. And it can be done > probabilistically by monitoring a random flow for several data/ack > exchanges. This way you could save on the state required. > > Another way to detect such things may be at the bottleneck router. > This seems to be a case of a truthful but non-responsive sender who > keeps reporting rate that's too high, but doesn't slow down, because > the receiver is tampering with feedback. > bottlenecks can identify the flows with higher rates in that bottleneck, thus they are a good source of information for choosing which flows to monitor as well. cheers, Filipe > -Yuri > _______________________________________________ > xcp mailing list > xcp at isi.edu > http://mailman.isi.edu/mailman/listinfo/xcp > > -- Filipe Abrantes INESC Porto fla at inescporto.pt Certificate Auth https://ra.inescporto.pt/pub/cacert/cacert.crt -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4475 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.isi.edu/pipermail/xcp/attachments/20061123/57a53dfa/smime.bin From mwoldese at ee.ucl.ac.uk Thu Nov 30 08:09:40 2006 From: mwoldese at ee.ucl.ac.uk (Moses Woldeselassie) Date: Thu, 30 Nov 2006 16:09:40 +0000 Subject: [xcp] help with xcp's experiment files Message-ID: <20061130155800.M70917@ee.ucl.ac.uk> hi all I would appreciate it, if you could help me. I am comparing my results with XCP resulsts "Congestion Control for High-Bandwidth-delay product Networks". But I need also to test the XCP protocol on my system so that i could easly compare them with my results. In this case, I need the files which are used in the the XCP's report. For example, I couldn't get the mice arrival rate (in figure 7) to work with xcp_test.tcl or xcp-tcp.tcl... Again, I appreciate if you could drop me an email. I am looking forward to hearing from you. Sincerely M Woldeselassie ************************************************************************************* My Brain is Hungry for: M-Internet,M-commerce,Wirless Technologies,Networking Systems, etc. Electronic & Electrical Engineering @ UCL www.ee.ucl.ac.uk ************************************************************************************* From yuri at ISI.EDU Thu Nov 30 12:06:53 2006 From: yuri at ISI.EDU (Yuri Pradkin) Date: Thu, 30 Nov 2006 12:06:53 -0800 Subject: [xcp] making the XCP specification an RFC In-Reply-To: <4565E5FC.5040007@inescporto.pt> References: <4894E12B-74F6-42C5-B5E4-87192CC436AB@ISI.EDU> <20061123004619.GA19860@yap.isi.edu> <4565E5FC.5040007@inescporto.pt> Message-ID: <200611301206.53285@kmail.yap.isi.edu> On Thursday 23 November 2006 10:18, Filipe Abrantes wrote: > I thought of doing this without keeping any state. Sum all feedbacks > from all flows coming in one way (data packets), and then subtract > every feedback coming the other way (ACK packets), and never let the > counter go to zero. The malicious receiver could still mix the > feedbacks between flows (use the feedback of a certain flow for > another flow), but I don't see much incentive to that. The counter > would only be needed at the edge of the network (first-hop router). > [however, it could be used at inter-domain borders as well]. This does not tell you though which flows are misbehaving, only lets you detect that something may be wrong in the aggregate. A slight problem with this may be that XCP may be running on queues behind the policer (even on receiver end-systems, cf back-to-back operation) so the feedback may be further reduced for some flows and the policer will now know about it. In such situations a malicious receiver's actions may be offset to some extent and come "under radar". I propose to add the following couple of paragraphs to the draft summarizing our discussion here without committing to specific recipes. Please feel free to edit and post your changes to the list. -Yuri ------------------- Malicious Receivers An XCP receiver is required to return XCP congestion feedback unmodified to the sender. It is possible for a receiver to lie about the feedback by sending a greater value than XCP actually allocated thus causing the flow to acquire an unfair share of bandwidth. It is worth noting that a similar problem exists in TCP [Sherwood05] whereby TCP receivers can ACK data before it arrives (optimistic ACKing), however its technical implementation in XCP is much easier. The explicit nature of XCP though makes it possible to verify that the receiver does a truthful job. For example, a policer at the edge can monitor the feedback going in both directions and may punish flows whose feedback values have been tampered with; another possibility is for a bottleneck router to punish packets that report an unfairly large throughput.