From yuri at ISI.EDU Wed Dec 6 08:01:30 2006 From: yuri at ISI.EDU (Yuri Pradkin) Date: Wed, 6 Dec 2006 08:01:30 -0800 Subject: [xcp] help with xcp's experiment files In-Reply-To: <20061130155800.M70917@ee.ucl.ac.uk> References: <20061130155800.M70917@ee.ucl.ac.uk> Message-ID: <200612060801.30627@kmail.yap.isi.edu> On Thursday 30 November 2006 08:09, Moses Woldeselassie wrote: > 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... I'm guessing that you're talking about NS simulations, not running XCP kernel. I don't think any version of NS out there includes TCL scripts designed to replicate the XCP results from that figure. You'll either have to write your own or contact authors directly to try to get their (old) code. Dina's code will have to be slightly modified in order to run with the latest version of NS as class names have changed. -Yuri From fla at inescporto.pt Fri Dec 8 09:33:38 2006 From: fla at inescporto.pt (Filipe Abrantes) Date: Fri, 08 Dec 2006 17:33:38 +0000 Subject: [xcp] making the XCP specification an RFC In-Reply-To: <200611301206.53285@kmail.yap.isi.edu> References: <4894E12B-74F6-42C5-B5E4-87192CC436AB@ISI.EDU> <20061123004619.GA19860@yap.isi.edu> <4565E5FC.5040007@inescporto.pt> <200611301206.53285@kmail.yap.isi.edu> Message-ID: <4579A1F2.4090900@inescporto.pt> Hi Yuri, Yuri Pradkin wrote: > 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. > Yes, that's a tradeoff between state and accuracy. But if the aggregate is misbehaving, then we can change the detail to individual flows. > 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". > True, ideally the policer would be the first-hop XCP router, otherwise this may happen. > 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. > Thanks, the text is good imo. Filipe > -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. > > _______________________________________________ > xcp mailing list > xcp at isi.edu > http://mailman.isi.edu/mailman/listinfo/xcp > -- Filipe Lameiro 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/20061208/51bf10fb/smime.bin From ecoe at ISI.EDU Mon Dec 18 10:04:31 2006 From: ecoe at ISI.EDU (Eric Coe) Date: Mon, 18 Dec 2006 10:04:31 -0800 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: <4586D82F.8000005@isi.edu> I suggest a change to the XCP header format ordering. X should come before RTT. When implementing XCP per packet calculations on a Xilinx Virtex Pro4 FPGA device I found the critical calculation (time constraint-wise) to be line 20 of "On Packet Departure". All other "large" calculations do not have to complete before packet departure. Line 20 involves a 32x32 bit multiplication that can be performed with an IP math core from Xilinx in 3 cycles. I streamed the packet through the FPGA device by receiving 32 bits every cycle. After my Place-and-Route results I could achieve a clock speed of roughly 70MHz which translates to approximately 2.24 Gbps. Without getting to deep into implementation details I think it makes sense to switch the order of these variables. Of course FPGA devices will become faster but in the end I believe line 20 will always be the critical calculation on any platform. Starting that calculation as soon as possible can only be a good thing because packet departure depends on when this calculation completes. comments? 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