From sailor_list at hotmail.com Tue Nov 15 05:20:08 2005 From: sailor_list at hotmail.com (Alp) Date: Tue, 15 Nov 2005 22:20:08 +0900 Subject: [xcp] XCP stability problem Message-ID: Hi I am working on XCP and I have a very simple question. I am very sorry, if here is the wrong place for my question. I thought that it is a general XCP problem, not a simulator problem, so I am submitting it to this mailing list instead of ns2 mailing list. I am doing some simulations on XCP and I saw a strange behavior of XCP when there is two-way traffic. I am not sure, but probably the ACK compression caused by two-way traffic can make XCP unstable especially when there are few number of flows. XCP uses the estimated RTT value when updating its congestion window. RTT is calculated by timestamp option of TCP. However, XCP is a bursty protocol, so sometimes it sends too many data packets back to back and the ACK packets of other way traffic is sometimes compressed after the backside of the data traffic and this delays the arrival of ACK packets. Therefore, XCP overestimates the RTT value. Window size increases more than it should be due to overestimated RTT when source receives feedbacks as window size increase is calculated by feedback*RTT. Increase in window size also cause increase in burstiness and queue occupancy as more packets are sent back to back and therefore RTT and CWND continue increasing and make XCP unstable. I am attaching a sample script that makes XCP unstable and loses many packets. It is actually the script xcp_test.tcl available inside ns2 package. The only difference is that I added the following lines to have two-way traffic in the simulation: # Create sources: set i 0 while { $i < $nXCPs } { set StartTime [expr [$rtg integer 1000] * 0.001 * (0.01 * $delay) + $i * 0.0] set rcvr_XCP [new Agent/XCPSink] $ns attach-agent [set n$i] $rcvr_XCP set srcc$i [new GeneralSender $i [set R1] $rcvr_XCP "$StartTime TCP/Reno/XCP"] [[set srcc$i] set tcp_] set packetSize_ [expr 100 * ($i +10)] [[set srcc$i] set tcp_] set window_ [expr $qSize * 10] incr i } There are only two XCP flows (one incoming, one outgoing) in the simulation. Could you please simulate this script and share your results? XCP became unstable in my simulations on an unmodified ns simulator. I checked the script, but I could not see any bugs, so I thought that maybe it is a general XCP problem. Please forgive me, if it is a well-known problem or it is caused by an implementation error in the script or here is the wrong place for the question. The full script is attached below to this mail. Thank you Alp # ----------------------- Test XCP Performance ------------------------------# # # Author: Dina Katabi, dina at ai.mit.edu # Last Update : 7/16/2002 # #-------------------------------------------------------------------------------# #-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Utility Functions -*-*-*-*-*-*-*-*--*-*-*-*-*-*-*-*-# #--------- Creating the TOPOLOGY --------------------# # n0 # : \ Bottleneck # : R0-----------------------R1 # / # ni # Agent/TCP set minrto_ 1 proc set-red-params { qsize } { Queue/RED set thresh_ [expr 0.6 * $qsize] Queue/RED set maxthresh_ [expr 0.8 * $qsize] Queue/RED set q_weight_ 0.001 Queue/RED set linterm_ 10 Queue/RED set bytes_ false ; Queue/RED set queue_in_bytes_ false ; Agent/TCP set old_ecn_ true Queue/RED set setbit_ true } proc create-topology2 { BW delay qtype qsize numSideLinks deltaDelay } { global ns #Set the queue size to the pipe's size assuming the packet size is 1000 KByte if { $qsize == 0 } { set qsize [expr round([expr ($BW / 8) * 2 * $delay])] } set i 0 while { $i < 2 } { global R$i set R$i [$ns node] incr i } $ns duplex-link $R0 $R1 [set BW]Mb [set delay]ms $qtype $ns queue-limit $R0 $R1 $qsize $ns queue-limit $R1 $R0 $qsize # Give a global handle to the Bottleneck Queue to allow # setting the RED paramters global Bottleneck rBottleneck set Bottleneck [[$ns link $R0 $R1] queue] set rBottleneck [[$ns link $R1 $R0] queue] global l rl set l [$ns link $R0 $R1] set rl [$ns link $R1 $R0] global all_links set all_links "$l $rl " # The side links have the same BW as the Bottleneck set i 0 while { $i < $numSideLinks } { global n$i q$i rq$i l$i rl$i set n$i [$ns node] $ns duplex-link [set n$i] $R0 [set BW]Mb [expr $delay + $i * $deltaDelay]ms $qtype $ns queue-limit [set n$i] $R0 $qsize $ns queue-limit $R0 [set n$i] $qsize set q$i [[$ns link [set n$i] $R0] queue] set rq$i [[$ns link $R0 [set n$i]] queue] set l$i [$ns link [set n$i] $R0] set rl$i [$ns link $R0 [set n$i]] set all_links "$all_links [set l$i] [set rl$i] " incr i } } #------- Sender Class : # This is essentially an ftp sender Class GeneralSender -superclass Agent # otherparams are "startTime TCPclass .." GeneralSender instproc init { id node rcvrTCP otherparams } { global ns $self next $self instvar tcp_ id_ ftp_ node_ tcp_rcvr_ tcp_type_ set id_ $id set node_ $node if { [llength $otherparams] > 1 } { set TCP [lindex $otherparams 1] } else { set TCP "TCP/Reno" } set tcp_type_ $TCP set tcp_ [new Agent/$TCP] $tcp_ set packetSize_ 1000 $tcp_ set class_ $id set ftp_ [new Source/FTP] $ftp_ set agent_ $tcp_ $ns attach-agent $node $tcp_ $ns connect $tcp_ $rcvrTCP set tcp_rcvr_ $rcvrTCP set startTime [lindex $otherparams 0] $ns at $startTime "$ftp_ start" puts "initialized Sender $id_ at $startTime" } GeneralSender instproc trace-xcp parameters { $self instvar tcp_ id_ tcpTrace_ global ftracetcp$id_ set ftracetcp$id_ [open xcp$id_.tr w] set tcpTrace_ [set ftracetcp$id_] $tcp_ attach-trace [set ftracetcp$id_] if { -1 < [lsearch $parameters cwnd] } { $tcp_ tracevar cwnd_ } if { -1 < [lsearch $parameters seqno] } { $tcp_ tracevar t_seqno_ } } #--- Command line arguments proc set-cmd-line-args { list_args } { global argv set i 0 foreach a $list_args { global $a set $a [lindex $argv $i] puts "$a = [set $a]" incr i } } #-------------- Plotting functions -----------# # plot a xcp traced var proc plot-xcp { TraceName nXCPs PlotTime what } { if {[string compare $what "cwnd_"] == 0} { exec rm -f xgraph_cwnd.tcp set f [open xgraph_cwnd.tcp w] set a cwnd } else { exec rm -f xgraph_seqno.tcp set f [open xgraph_seqno.tcp w] set a seqno } puts $f "TitleText: $TraceName" puts $f "Device: Postscript" foreach i $nXCPs { #the TCP traces are flushed when the sources are stopped exec rm -f temp.tcp exec touch temp.tcp global ftracetcp$i if [info exists ftracetcp$i] { flush [set ftracetcp$i] } set packetsize [expr 100 * ($i +10)] set result [exec awk -v PlotTime=$PlotTime -v what=$what -v s=$packetsize { { if (( $6 == what ) && ($1 > PlotTime)) { tmp=$7*s print $1, tmp >> "temp.tcp"; } } } xcp$i.tr] puts "$i : $result" puts $f \"$what$i exec cat temp.tcp >@ $f puts $f "\n" flush $f } close $f exec xgraph -nl -m -x time -y $what xgraph_$a.tcp & return } # Takes as input the the label on the Y axis, the time it starts plotting, and the trace file tcl var proc plot-red-queue { TraceName PlotTime traceFile } { exec rm -f xgraph.red_queue exec rm -f temp.q temp.a temp.p temp.avg_enqueued temp.avg_dequeued temp.x temp.y exec touch temp.q temp.a temp.p temp.avg_enqueued temp.avg_dequeued temp.x temp.y exec awk -v PT=$PlotTime { { if (($1 == "q" && NF>2) && ($2 > PT)) { print $2, $3 >> "temp.q" } else if (($1 == "a" && NF>2) && ($2 > PT)){ print $2, $3 >> "temp.a" } else if (($1 == "p" && NF>2) && ($2 > PT)){ print $2, $3 >> "temp.p" } } } $traceFile set ff [open xgraph.red_queue w] puts $ff "TitleText: $TraceName" puts $ff "Device: Postscript \n" puts $ff \"queue exec cat temp.q >@ $ff puts $ff \n\"ave_queue exec cat temp.a >@ $ff puts $ff \n\"prob_drop exec cat temp.p >@ $ff close $ff exec xgraph -P -x time -y queue xgraph.red_queue & } proc plot-red {varname filename PlotTime} { exec rm -f temp.$filename exec touch temp.$filename set result [exec awk -v PlotTime=$PlotTime -v what=$varname -v file=temp.$filename { { if (( $1 == what ) && ($2 > PlotTime)) { print $2, $3 >> file ; } } } ft_red_Bottleneck.tr] exec xgraph -P -x time -y $filename temp.$filename } #-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Initializing Simulator -*-*-*-*-*-*-*-*--*-*-*-*-*-*-*-*-# # BW is in Mbs and delay is in ms #set-cmd-line-args "seed qType BW nXCPs delay " set seed 472904 set qType XCP set BW 10; # in Mb/s set nXCPs 1; # Number of flows set delay 10; # in ms set ns [new Simulator] $ns use-scheduler Heap set rtg [new RNG] $rtg seed $seed set nf [open out.nam w] $ns namtrace-all $nf set qSize [expr round([expr ($BW / 8.0) * 4 * $delay * 1.0])];#set buffer to the pipe size set tracedXCPs "0 " set SimStopTime 10 set PlotTime 0 #---------- Create the simulation --------------------# # Create topology create-topology2 $BW $delay $qType $qSize $nXCPs 0.0 foreach link $all_links { set queue [$link queue] switch $qType { "XCP" { $queue set-link-capacity [[$link set link_] set bandwidth_]; } "DropTail/XCP" { $queue set-link-capacity-Kbytes [expr [[$link set link_] set bandwidth_] / 8000]; } default { puts "Incorrect qType $qType" exit 0 } } } # Create sources: set i 0 while { $i < $nXCPs } { set StartTime [expr [$rtg integer 1000] * 0.001 * (0.01 * $delay) + $i * 0.0] set rcvr_XCP [new Agent/XCPSink] $ns attach-agent $R1 $rcvr_XCP set src$i [new GeneralSender $i [set n$i] $rcvr_XCP "$StartTime TCP/Reno/XCP"] [[set src$i] set tcp_] set packetSize_ [expr 100 * ($i +10)] [[set src$i] set tcp_] set window_ [expr $qSize * 10] incr i } # Create sources: set i 0 while { $i < $nXCPs } { set StartTime [expr [$rtg integer 1000] * 0.001 * (0.01 * $delay) + $i * 0.0] set rcvr_XCP [new Agent/XCPSink] $ns attach-agent [set n$i] $rcvr_XCP set srcc$i [new GeneralSender $i [set R1] $rcvr_XCP "$StartTime TCP/Reno/XCP"] [[set srcc$i] set tcp_] set packetSize_ [expr 100 * ($i +10)] [[set srcc$i] set tcp_] set window_ [expr $qSize * 10] incr i } #---------- Trace --------------------# # Trace sources foreach i $tracedXCPs { [set src$i] trace-xcp "cwnd seqno" } # Trace Queues foreach queue_name "Bottleneck rBottleneck" { set queue [set "$queue_name"] switch $qType { "XCP" { global "ft_red_$queue_name" set "ft_red_$queue_name" [open ft_red_[set queue_name].tr w] set xcpq $queue ;#[$queue set vq_(0)] $xcpq attach [set ft_red_$queue_name] } "DropTail/XCP" {} } } #---------------- Run the simulation ------------------------# proc flush-files {} { set files "f_all ft_red_Bottleneck ft_red_rBottleneck" global tracedXCPs foreach file $files { global $file if {[info exists $file]} { flush [set $file] close [set $file] } } foreach i $tracedXCPs { global src$i set file [set src$i tcpTrace_] if {[info exists $file]} { flush [set $file] close [set $file] } } } proc finish {} { global ns if {[info exists f]} { $ns flush-trace close $f } $ns halt } $ns at $SimStopTime "finish" $ns run flush-files #------------ Post Processing ---------------# set PostProcess 1 if { $PostProcess } { #--- Traced TCPs set TraceName "Flows --$qType-QS$qSize" plot-xcp $TraceName $tracedXCPs 0.0 "cwnd_" # plot-xcp $TraceName $tracedXCPs 0.0 "t_seqno_" # plot-red-queue $TraceName $PlotTime ft_red_Bottleneck.tr plot-red "u" util 0.0 } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/xcp/attachments/20051115/6345f0db/attachment.html From faber at ISI.EDU Thu Nov 17 09:35:09 2005 From: faber at ISI.EDU (Ted Faber) Date: Thu, 17 Nov 2005 09:35:09 -0800 Subject: [xcp] XCP stability problem In-Reply-To: References: Message-ID: <20051117173509.GC19228@hut.isi.edu> Just so you know this didn't go into the bit bucket, I'll have a look and get back to you fairly soon. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/xcp/attachments/20051117/491a9514/attachment.bin From sailor_list at hotmail.com Thu Nov 17 10:17:11 2005 From: sailor_list at hotmail.com (Alp) Date: Fri, 18 Nov 2005 03:17:11 +0900 Subject: [xcp] XCP stability problem References: <20051117173509.GC19228@hut.isi.edu> Message-ID: I am waiting for your reply. Thank you very much. Alp From leon70m at yahoo.com Mon Nov 21 10:08:29 2005 From: leon70m at yahoo.com (Leon Martin) Date: Mon, 21 Nov 2005 10:08:29 -0800 (PST) Subject: [xcp] Questions about delta_throughput and reaction to packet loss Message-ID: <20051121180829.93776.qmail@web52512.mail.yahoo.com> Hi all, XCP is new to me. So my question may be a bit simple. Can someone help me with the following doubts: 1. In the original 2002 paper, the feedback is in terms of bytes, but in the 2005 draft and the 2.29 ns-2 implementation, the feedback is in bits/sec (i.e., delta_throughput). Is there any reason for this change? 2. Why does Jacobson's congestion control take over in the case there is packet loss? Even if there is real congestion in the network, the intermediate routers will be allocate the correct bandwidth after at most one RTT. Thanks! - Leon __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com From sampad_m at rediffmail.com Mon Nov 21 12:53:15 2005 From: sampad_m at rediffmail.com (sampad mishra) Date: 21 Nov 2005 20:53:15 -0000 Subject: [xcp] Questions about delta_throughput and reaction to packet loss Message-ID: <20051121205315.432.qmail@webmail31.rediffmail.com> Hi Leon, Will try to answer ur 2nd qustion ? though me also a newbie... As per ur 2nd qestion 2. Why does Jacobson's congestion control take over in >the case there is packet loss? I guess thr can be 2 reasons due to which a packet loss might occur... 1> an occurence of a router in the path which is not xcp enabled . Bcoz if all the routers are XCP enabled , sender rates cannot exceed the bottleneck BW . So I think its better to fall bak to our old n reliable congesion control algo (Jacobson's) to prevent congestion in the non-XCP router. 2> It might occcur within the control interval , when the parameters are not updated but the n/w haas changed drastically due to burstiness. I think its rare however , it depends on how efficiently the control interval is modelled . I hope the answers are reasonable , kindly forgive clarify if anywhere I've faltered . I also have a question , Don't you ppl think tht it is too much of an ask from a router to do the calculations like 'Calculations Upon Packet Arrival' , 'Calculations Upon Packet Departure' and 'Calculations Upon Control Interval Timeout' ? Regards , Sampad Mishra Project Assistant IISc. On Mon, 21 Nov 2005 Leon Martin wrote : >Hi all, > >XCP is new to me. So my question may be a bit simple. >Can someone help me with the following doubts: > >1. In the original 2002 paper, the feedback is in >terms of bytes, but in the 2005 draft and the 2.29 >ns-2 implementation, the feedback is in bits/sec >(i.e., delta_throughput). Is there any reason for this >change? > >2. Why does Jacobson's congestion control take over in >the case there is packet loss? Even if there is real >congestion in the network, the intermediate routers >will be allocate the correct bandwidth after at most >one RTT. > >Thanks! > >- Leon > > > >__________________________________ >Yahoo! FareChase: Search multiple travel sites in one click. >http://farechase.yahoo.com >_______________________________________________ >xcp mailing list >xcp at isi.edu >http://mailman.isi.edu/mailman/listinfo/xcp -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.isi.edu/pipermail/xcp/attachments/20051121/b13f654e/attachment.html From fla at inescporto.pt Mon Nov 21 13:18:17 2005 From: fla at inescporto.pt (Filipe Abrantes) Date: Mon, 21 Nov 2005 21:18:17 +0000 Subject: [xcp] Questions about delta_throughput and reaction to packet loss In-Reply-To: <20051121180829.93776.qmail@web52512.mail.yahoo.com> References: <20051121180829.93776.qmail@web52512.mail.yahoo.com> Message-ID: <43823999.1000706@inescporto.pt> Hi Leon, I'm not the XCP expert here but ill try to answer your questions the best I can, please correct me if I'm wrong. Leon Martin wrote: > Hi all, > > XCP is new to me. So my question may be a bit simple. > Can someone help me with the following doubts: > > 1. In the original 2002 paper, the feedback is in > terms of bytes, but in the 2005 draft and the 2.29 > ns-2 implementation, the feedback is in bits/sec > (i.e., delta_throughput). Is there any reason for this > change? > It's been a while since i last read the 2002 paper, but i think that's mainly a matter of simplification of the calculations performed at the router. 2002 paper states: f = alpha*avg_rtt*(c-input_bw)-beta*pqueue but after, every calculation that involves /f/ is divided by avg_rtt. If you do it already in the calculation of /f/ you save a few divisions in the subsequent calculations. [ (...) residue_pos_fbk = (max(f,0)+shuffled_traffic)/avg_rtt residue_neg_fbk = (max(-f,0)+shuffled_traffic)/avg_rtt (...) ] (and the same applies for xi_p and xi_n calculations) > 2. Why does Jacobson's congestion control take over in > the case there is packet loss? Even if there is real > congestion in the network, the intermediate routers > will be allocate the correct bandwidth after at most > one RTT. > If the bottleneck is non-XCP, you need to use Jacobson's congestion control, if you keep using XCP, the rate of the flow will be regulated by a non-bottleneck queue, leading to more losses in the real bottleneck. The rate of a flow must be regulated by the bottleneck right? If the bottleneck doesn't play XCP... you can't use XCP to adjust the flow's rate. Of course, when losses are caused by some other reason (wireless, ...) than a non-XCP bottleneck we might have a problem. Best Regards Filipe > Thanks! > > - Leon > > > > __________________________________ > Yahoo! FareChase: Search multiple travel sites in one click. > http://farechase.yahoo.com > _______________________________________________ > xcp mailing list > xcp at isi.edu > http://mailman.isi.edu/mailman/listinfo/xcp > -- Filipe Lameiro Abrantes INESC Porto Campus da FEUP Rua Dr. Roberto Frias, 378 4200-465 Porto Portugal Phone: +351 22 209 4266 E-mail: fla at inescporto.pt From leon70m at yahoo.com Tue Nov 22 17:43:41 2005 From: leon70m at yahoo.com (Leon Martin) Date: Tue, 22 Nov 2005 17:43:41 -0800 (PST) Subject: [xcp] Why use positive feedback and negative feedback at the same time? Message-ID: <20051123014341.19051.qmail@web52504.mail.yahoo.com> Hi all, It looks to me that the two feedbacks are used simultaneously for a given packet at a given time. In other words, both the positive feedback and the negative feedback can be non-zero at the same time. This is clear in Lines 13 and 14 in 4.2.2. of the following document: http://www.isi.edu/isi-xcp/docs/draft-falk-xcp-spec-01.html What is the rationale behind this? Thanks! - Leon __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs From faber at ISI.EDU Tue Nov 22 18:21:50 2005 From: faber at ISI.EDU (Ted Faber) Date: Tue, 22 Nov 2005 18:21:50 -0800 Subject: [xcp] XCP stability problem In-Reply-To: References: <20051117173509.GC19228@hut.isi.edu> Message-ID: <20051123022150.GH87237@hut.isi.edu> On Fri, Nov 18, 2005 at 03:17:11AM +0900, Alp wrote: > I am waiting for your reply. Hi. I found some time to play with your simulations today, and you're not seeing a simulator bug. You're using ns correctly, and it's not doing anything wrong as far as I can tell. I would be careful about generalizing too much from these results, though. The XCP implemented in ns is not a perfect reflection of all the thinking about XCP. It's generated from the original sims and tweaked some for robustness and integration, but I don't think it's a full implementation of all the corner cases. One of the nasty effects you're seeing is that the simulation of XCP in ns is not programmed to deal well with packet loss. And, by that I mean that it doesn't deal with them at all - TCP error correction takes over and interferes with the XCP rate control algorithm. This is, IMHO, the reason that the performance degredation is so catastrophic. There are some other things going on that you probably already know, but that others might be curious about. This simulation of XCP uses the length of the standing queue in bytes in its feedback calculations, but the implementation queues packets. The ACKs in your two-way traffic are underrepresented in terms of the queueing term of the phi calculation. They're 40 bytes long, but really take up 1/nbuf of the queue. Beyond that, this simulation doesn't count ACK packets at all in determining the traffic load - i.e. the arrival rate. Your discussion of the RTT and its effect on the throughput variable in this ns simulation is correct, but I believe that this is not the dominant feature that's causing your performance degredation. (I believe this because I ran your scenario through a simulation that (correctly) just keeps track of the throughput assigned by the router and it didn't fix anything - in fact things got worse.) There is plenty of room to improve the simulation code in these respects and others. We're delighted to receive patches, and I apologize that not everything is implemented. I did try a few things out and they may provide some directions for you or others: * Smoothing the traffic eliminates the problem. There are standing queues from the unaccounted for ACKS, but they're about 5 packets (just eyballing it). Throughput in each direction saturates the link and is very smooth. * Increasing the queue size by a factor of 5 gets rid of the big drops in utilization and throughput - again pointing the finger at the packet loss code. There's about a 150 packet standing queue in this case, with gusts somewhat higher. Throughput is not as stable as in the smoothed case, but considerably better than before. * Using the router-assigned throughput rather than recalculating the throughput put into each packet based on current RTT & cwnd actually makes the situation worse in the lossy case, but again I believe that this is because the underlying loss reaction strategy in this code is unsound. I have a student looking at a more sane strategy for reacting to losses, and he's had some good preliminary results that I hope to write up and get out to the community in the near future. (And we'll contribute that code to the ns simulation, too.) If you have more results or want to discuss this in more detail (especially if I've been unclear) please don't hesitate to get back to me on or off the list. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/xcp/attachments/20051122/c7333434/attachment.bin From faber at ISI.EDU Tue Nov 22 18:36:46 2005 From: faber at ISI.EDU (Ted Faber) Date: Tue, 22 Nov 2005 18:36:46 -0800 Subject: [xcp] Why use positive feedback and negative feedback at the same time? In-Reply-To: <20051123014341.19051.qmail@web52504.mail.yahoo.com> References: <20051123014341.19051.qmail@web52504.mail.yahoo.com> Message-ID: <20051123023646.GJ87237@hut.isi.edu> On Tue, Nov 22, 2005 at 05:43:41PM -0800, Leon Martin wrote: > Hi all, > > It looks to me that the two feedbacks are used > simultaneously for a given packet at a given time. In > other words, both the positive feedback and the > negative feedback can be non-zero at the same time. > This is clear in Lines 13 and 14 in 4.2.2. of the > following document: > > http://www.isi.edu/isi-xcp/docs/draft-falk-xcp-spec-01.html > > What is the rationale behind this? The two feedback pools make the shuffling algorithm used for fairness work. Dina's (and Mark's and Charlie's, but I think of it as Dina's) sigcomm paper explains how the positive and negative feedback is allocated - and they're each done differently. All hosts get the smae amount of positive feedback per control interval (linear increase), but the amount of negative feedback depends on the current sending rate (multiplicative decrease). You have to keep track of how much of each you've allocated to stay in the high utilization region. I find it helpful to consider the case here there's one source that's sending as close as possible to full utilization. At this point the total feedback (phi) is 0, but there's actually equal quantities of positive and negative feedback allocated. Over the control interval, the single source will recieve all the positive and all the negative feedback, and its long term rate will be the same - that of the full outgoing link. Keeping track of the negative feedback in this case keeps the router from reducing the single source more than it was increased, which would result in a net utilization decrease. Because the router doesn't remember per-flow state, it can't keep track of this for each flow. The question I had at that point is "why hand out any feedback at all in this case?" When another source joins, it's going to need positive feedback to speed up and negative feedback to slow the outher source down. Because there's no per-flow state at the routers with which to detect a new flow, the routers are always handing out a bit of each to nudge sources toward fairness. Without per-flow state routers don't know when to stop shuffling capacity like this, so they don't stop. Does that make sense? -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/xcp/attachments/20051122/311f7f90/attachment.bin From faber at ISI.EDU Tue Nov 22 18:40:08 2005 From: faber at ISI.EDU (Ted Faber) Date: Tue, 22 Nov 2005 18:40:08 -0800 Subject: [xcp] Questions about delta_throughput and reaction to packet loss In-Reply-To: <20051121180829.93776.qmail@web52512.mail.yahoo.com> References: <20051121180829.93776.qmail@web52512.mail.yahoo.com> Message-ID: <20051123024008.GK87237@hut.isi.edu> On Mon, Nov 21, 2005 at 10:08:29AM -0800, Leon Martin wrote: > Hi all, > > XCP is new to me. So my question may be a bit simple. > Can someone help me with the following doubts: > > 1. In the original 2002 paper, the feedback is in > terms of bytes, but in the 2005 draft and the 2.29 > ns-2 implementation, the feedback is in bits/sec > (i.e., delta_throughput). Is there any reason for this > change? It's also changed in Dina's thesis. In the SIGCOMM paper the protocol passes around explicit cwnd values - which are in bytes. Later versions of the protocol manipulate the throughputs directly so not to be tied to a specific rate control algorithm, e.g., sliding windows. There's a different trick involving changing units to eliminate the divisions at the routers that we should write up for your collective amusement. Let me know if that makes sense. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/xcp/attachments/20051122/2d42cef6/attachment.bin From faber at ISI.EDU Tue Nov 22 18:49:21 2005 From: faber at ISI.EDU (Ted Faber) Date: Tue, 22 Nov 2005 18:49:21 -0800 Subject: [xcp] Questions about delta_throughput and reaction to packet loss In-Reply-To: <20051121205315.432.qmail@webmail31.rediffmail.com> References: <20051121205315.432.qmail@webmail31.rediffmail.com> Message-ID: <20051123024921.GL87237@hut.isi.edu> On Mon, Nov 21, 2005 at 08:53:15PM -0000, sampad mishra wrote: > Don't you ppl think tht it is too much of an ask from a router to do > the calculations like 'Calculations Upon Packet Arrival' , > 'Calculations Upon Packet Departure' and 'Calculations Upon Control > Interval Timeout' ? Nope. It's much harder to get router designers to put the calculations in. And there are some good reasons for that; if they put every idea that someone throws out in an academic paper into a router, well, you're starting to talk about an awful lot of code to write and maintain. and congestion control isn't something you can go alone. We do think that the cost/benefit tradeoff for getting XCP into routers is a good one - particularly because the cost of the actual calculations are so low. It's a few multiplies and adds per packet and a few words of memory per router. The per-CI calcucations - which are more involved - can be done in a slower processor, and are not terribly time-critical. They're trivial compared to running a routing algorithm. We have a student working on an IXP implementation that we have every reason to believe will saturate a Gb/s link using the fairly clumsy IXP architecture. We think that putting the few operations directly on a chip will be very cheap in terms of processing time. I do believe strongly that these per-packet computational costs are pretty minor, but right now the onus is on XCP proponents (like me) to prove that there really is a benefit and no bugaboos lurking in the corner. I haven't seen anything too awful, but there are lots of corners unturned at this point. And I would not say that it's a great idea to shift all hosts over to XCP tomorrow, even if such a thing were possible. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://mailman.isi.edu/pipermail/xcp/attachments/20051122/84307560/attachment.bin From leon70m at yahoo.com Mon Nov 28 13:45:00 2005 From: leon70m at yahoo.com (Leon Martin) Date: Mon, 28 Nov 2005 13:45:00 -0800 (PST) Subject: [xcp] Can someone help explain a line in the specification? Message-ID: <20051128214500.34809.qmail@web52512.mail.yahoo.com> Hi all, I am reading the 2005 spec for XCP located at http://www.isi.edu/isi-xcp/docs/draft-falk-xcp-spec-01.html I have a question about Line 26, which is in Section 4.2.3.: 26. neg_fbk = min(residue_neg_fbk, neg_fbk + (feedback - Delta_Throughput)) The explanation says that the term (feedback - Delta_Throughput) allows the router to capture feedback which is allocated by an upstream bottleneck. I don't understand why. The only information that is non-local is Delta_Throughput, and other variables here are all locally computed. Does it mean Delta_Throughput carry feedback information from the upstream bottleneck router? Also, if you substitute Line 22. 22. feedback = pos_fbk - neg_fbk into Line 26., you will get neg_fbk = min(residue_neg_fbk, pos_fbk - Delta_Throughput). What is the exact reason of doing this? Why not just use neg_fbk for the second term in the parenthses? Thanks! - Leon __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ From yuri at ISI.EDU Tue Nov 29 11:32:56 2005 From: yuri at ISI.EDU (Yuri Pryadkin) Date: Tue, 29 Nov 2005 11:32:56 -0800 Subject: [xcp] Can someone help explain a line in the specification? In-Reply-To: <20051128214500.34809.qmail@web52512.mail.yahoo.com> References: <20051128214500.34809.qmail@web52512.mail.yahoo.com> Message-ID: <200511291132.56177@kmail.yap.isi.edu> On Monday 28 November 2005 01:45 pm, Leon Martin wrote: > Hi all, > > I am reading the 2005 spec for XCP located at > http://www.isi.edu/isi-xcp/docs/draft-falk-xcp-spec-01.html > > I have a question about Line 26, which is in Section > 4.2.3.: > > 26. neg_fbk = min(residue_neg_fbk, neg_fbk + > (feedback - > Delta_Throughput)) > > The explanation says that the term (feedback - > Delta_Throughput) allows the router to capture > feedback which is allocated by an upstream bottleneck. > > > I don't understand why. The only information that is > non-local is Delta_Throughput, and other variables > here are all locally computed. Does it mean > Delta_Throughput carry feedback information from the > upstream bottleneck router? > > Also, if you substitute Line 22. > > 22. feedback = pos_fbk - neg_fbk > > into Line 26., you will get > > neg_fbk = min(residue_neg_fbk, pos_fbk - > Delta_Throughput). > > What is the exact reason of doing this? Why not just > use neg_fbk for the second term in the parenthses? This branch is executed only when Delta_Throughput < feedback. This means that the queue controller (e.g. router) is willing to give more feedback to this packet than the packet wants. (feedback - Delta_Throughput) thus constitutes the "excess feedback" that can be handed to other packets. To accomplish this, it's added to the neg_fbk, so it appears as if this packet got more negative feedback. The min() just takes care so total negative feedback stays under the negative feedback "pool" - residue_neg_fbk. The idea is: given excess of feedback, drain the negative pool first, then start adding to positive pool. That's what line 27 does. -Yuri From mwoldese at ee.ucl.ac.uk Tue Nov 15 08:14:58 2005 From: mwoldese at ee.ucl.ac.uk (Moses Woldeselassie) Date: Tue, 15 Nov 2005 16:14:58 -0000 Subject: [xcp] error with xcp-1.1 and ns2.28 Message-ID: <20051115160939.M60276@ee.ucl.ac.uk> Hi all I did try to use the XCP-1.1 and xcp_test.tcl with the ns2.28: I did replace these files queue.c and queue.h in nam-1.11. but my problem is with the xcp: xcp.cc, xcp-end-sys.cc and xcp-end-sys.h how do I modifie this Makefile/Makefile.in for the xcp.cc and xcp-end-sys.cc? what do I need beside that to run the xcp_test.tcl? I am looking forward to hearing from you. Cheers Moses *************************************************************** Electronic & Electrical Engineering @ UCL www.ee.ucl.ac.uk ***************************************************************