From zhanghuixiang at gmail.com Mon Jan 15 07:10:19 2007 From: zhanghuixiang at gmail.com (=?GB2312?B?1cW728/o?=) Date: Mon, 15 Jan 2007 23:10:19 +0800 Subject: [xcp] xcp code in ns2.30 Message-ID: <5ec4446a0701150710g3bade57g495032006f2e95ad@mail.gmail.com> hello, every one when i read the XCP code in ns2.30, i have two question: i)as to the WRR queue schedule method in xcp.cc, i think the router would serve all the queue in the same way no matter what was the queue's weight; the qToDq_'s value was just 0 1 2 and turn round; the weight didn't work;but in ns manual it say the XCP router would serve XCP queue and TCP queue in default. did i make mistake? int XCPWrapQ::queueToDeque() { int i = 0; if (wrrTemp_[qToDq_] <= 0) { qToDq_ = ((qToDq_ + 1) % MAX_QNUM); wrrTemp_[qToDq_] = queueWeight_[qToDq_] - 1; } else { wrrTemp_[qToDq_] = wrrTemp_[qToDq_] -1; } while ((i < MAX_QNUM) && (q_[qToDq_]->length() == 0)) { wrrTemp_[qToDq_] = 0; qToDq_ = ((qToDq_ + 1) % MAX_QNUM); wrrTemp_[qToDq_] = queueWeight_[qToDq_] - 1; i++; } return (qToDq_); } ii)when the XCP end system initial the congestion header, it just define the MAX_THROUGHPUT to a constant value, it was different from the draft-falk-xcp-spec-02; did it mean the delta_throughput_'s value is not important, the router will change it anyway? void XcpEndsys::send(Packet *p, int datalen) { ...... if (xh->xcp_enabled_) { #define MAX_THROUGHPUT 1e24 if (srtt_estimate_ != 0) { tput = tcp_->window() * tcp_->size_ / srtt_estimate_; xh->x_ = srtt_estimate_/tcp_->window(); xh->delta_throughput_ = (MAX_THROUGHPUT - tput); } else { //XXX can do xh->xcp_enabled_ = hdr_xcp::XCP_DISABLED; xh->x_ = 0; xh->delta_throughput_ = 0; } } ........ } best regards. From yuri at ISI.EDU Tue Jan 16 09:59:22 2007 From: yuri at ISI.EDU (Yuri Pradkin) Date: Tue, 16 Jan 2007 09:59:22 -0800 Subject: [xcp] xcp code in ns2.30 In-Reply-To: <5ec4446a0701150710g3bade57g495032006f2e95ad@mail.gmail.com> References: <5ec4446a0701150710g3bade57g495032006f2e95ad@mail.gmail.com> Message-ID: <200701160959.23085@kmail.yap.isi.edu> On Monday 15 January 2007 7:10 am, ??? wrote: > hello, every one > > when i read the XCP code in ns2.30, i have two question: > i)as to the WRR queue schedule method in xcp.cc, i think the router > would serve all the queue in the same way no matter what was the > queue's weight; the qToDq_'s value was just 0 1 2 and turn round; > the weight didn't work;but in ns manual it say the XCP router would > serve XCP queue and TCP queue in > default. did i make mistake? > int XCPWrapQ::queueToDeque() > { > int i = 0; > > if (wrrTemp_[qToDq_] <= 0) { > qToDq_ = ((qToDq_ + 1) % MAX_QNUM); > wrrTemp_[qToDq_] = queueWeight_[qToDq_] - 1; > } else { > wrrTemp_[qToDq_] = wrrTemp_[qToDq_] -1; > } > while ((i < MAX_QNUM) && (q_[qToDq_]->length() == 0)) { > wrrTemp_[qToDq_] = 0; > qToDq_ = ((qToDq_ + 1) % MAX_QNUM); > wrrTemp_[qToDq_] = queueWeight_[qToDq_] - 1; > i++; > } > return (qToDq_); > } Regrettable lack of comments makes this code a little hard to understand. I agree with you that it seems broken as wrrTemp_[] appears never to rise above 0, given weights normalized to 1. I don't think this code was ever truly exercised. > ii)when the XCP end system initial the congestion header, it just > define the MAX_THROUGHPUT to a constant value, it was different from > the draft-falk-xcp-spec-02; did it mean the delta_throughput_'s > value is not important, the router will change it anyway? > void > XcpEndsys::send(Packet *p, int datalen) > { > ...... > if (xh->xcp_enabled_) { > #define MAX_THROUGHPUT 1e24 > if (srtt_estimate_ != 0) { > tput = tcp_->window() * tcp_->size_ / > srtt_estimate_; xh->x_ = srtt_estimate_/tcp_->window(); > xh->delta_throughput_ = (MAX_THROUGHPUT - tput); > } else { > //XXX can do xh->xcp_enabled_ = > hdr_xcp::XCP_DISABLED; xh->x_ = 0; > xh->delta_throughput_ = 0; > } > } > ........ > } It's supposed to be initialized to the maximum throughput that the host can achieve. In ns land we can pretty much pick any large number as a limit and use that. And yes, given links with bandwidth less than that, the number you choose does not really matter. -Yuri From yuri at ISI.EDU Tue Jan 16 10:13:20 2007 From: yuri at ISI.EDU (Yuri Pradkin) Date: Tue, 16 Jan 2007 10:13:20 -0800 Subject: [xcp] making the XCP specification an RFC In-Reply-To: <4586D82F.8000005@isi.edu> References: <4894E12B-74F6-42C5-B5E4-87192CC436AB@ISI.EDU> <4586D82F.8000005@isi.edu> Message-ID: <200701161013.21068@kmail.yap.isi.edu> Eric, by the same logic, should we move "Delta_Throughput" to be the last field, to allow more time for XCP calculations in lines 20-22: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | Length |Version|Format | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reverse_Feedback | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delta_Throughput | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Would you gain anything from that? -Yuri > 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 From ecoe at ISI.EDU Tue Jan 16 10:29:30 2007 From: ecoe at ISI.EDU (Eric Coe) Date: Tue, 16 Jan 2007 10:29:30 -0800 Subject: [xcp] making the XCP specification an RFC In-Reply-To: <200701161013.21068@kmail.yap.isi.edu> References: <4894E12B-74F6-42C5-B5E4-87192CC436AB@ISI.EDU> <4586D82F.8000005@isi.edu> <200701161013.21068@kmail.yap.isi.edu> Message-ID: <45AD198A.9070907@isi.edu> Yuri Pradkin wrote: > Eric, > > by the same logic, should we move "Delta_Throughput" to be the last > field, to allow more time for XCP calculations in lines 20-22: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Protocol | Length |Version|Format | unused | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | X | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RTT | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reverse_Feedback | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Delta_Throughput | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Would you gain anything from that? > > -Yuri It would give another cycle before the comparison in line 23 which includes a possible writeback. Looking back through my simulation code... I DID change the position of Delta throughput as well. I agree that moving Delta_throughput makes sense. -eric > >> 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