From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 07FB421F3DA for ; Fri, 27 Feb 2015 07:25:17 -0800 (PST) Received: from srichardlxp2 ([46.245.200.65]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Mh9yT-1Y5jIW2eNl-00MNOC; Fri, 27 Feb 2015 16:25:13 +0100 Message-ID: <9795BDACBD2D4CA5BD102BA9D77F0206@srichardlxp2> From: "Richard Scheffenegger" To: "sahil grover" , "Jonathan Morton" References: Date: Fri, 27 Feb 2015 16:25:09 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0219_01D052A9.F45312A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Provags-ID: V03:K0:rg9vnmQwdCiolPUeA+J8/5JMJmxHENODpqvgVXaS3vKYioeYPBC 5GX8ZMGMFxblUUnyUiM3Q4SWavtHWQgOqrwDxDElAhKOuZys0H6zyXfqwpptbQ5wh8gNh+e 4ic2LOJeIeeJIdzeXsrhUsGdoAxOu3Ln4tFW8e2NyR2rC4WuXM3p4rxxZrnpFWmMNyYQLdj kObUUoqS77yB1jD/gnzEA== X-UI-Out-Filterresults: notjunk:1; Cc: codel@lists.bufferbloat.net Subject: Re: [Codel] why RED is not considered as a solution to bufferbloat. X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 15:25:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0219_01D052A9.F45312A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sahil, A TCP Sender will reduce the congestion window in a similar fashion to = both a) first ECE bit received in a window (flight of packets worth one = RTT), and of course, b) exceeding the DupThresh limit of duplicate acks, = again in one RTT worth of segments. The typical reaction in these two = cases is a multiplicative reduction of the size of the congestion = window, with the muliplication factor 0.5 - with other words, the = sending rate is halved. (Some variants of TCP deviate from this factor = of 0,5, but it's always a multiplicative decrease (the second half of = AIMD - additive increase, multiplicative decrease; the general control = law that results in stable network operating under load). A retransmission timeout causes the sending TCP to reduce it's sending = rate much more significantly - after an RTO, it restarts the TCP sending = rate much like from a clean start, often even more gentle, as the = initial window is reduced to only 1 or 2 segments (instead of 4 to 10)). Regarding the absolute number of losses - note that it's only one loss = (or mark) per RTT that halves the sending rate; with large congestion = window, you could drop dozends or even hundreds of segments, and the = sending TCP will still only half the sending rate. As long as all these = losses occur within the first RTT. Another loss after the first RTT, and = the TCP sender will react again (thus send only at 1/4 from the original = rate). This is the reason why looking at raw drop numbers it not all that = helpful byitself, the overall combination of goodput and latency = (which, in case of TCP, includes queuing-induced latency, transmission = latency and loss recovery latency) are much more relevant. With ECN, the = loss recovery latency is virtually zero, as the congestion signal is = explicitly signaled from the network to the end hosts. Unfortunately, Latency hasn't been a big topic for ISPs; Datacenter = operators care much much more about latency (and it's easier there to = deploy solutions, like ECN with an AQM set up with good parameters for = that limited environment). Hope this helps, Richard ----- Original Message -----=20 From: sahil grover=20 To: Jonathan Morton=20 Cc: codel@lists.bufferbloat.net ; Richard Scheffenegger=20 Sent: Friday, February 27, 2015 3:34 PM Subject: Re: [Codel] why RED is not considered as a solution to = bufferbloat. Jonathan, crystal clear now.. i mean the way u explain, Hats off seriously. well,i need to learn some more. My question is how tcp reacts to packet drop, like if we talk about packet marking then with acknowledgement from = receiver, tcp sender gets the congestion signal(if i am not wrong) but if packet is dropped then what is mechanism? is it related with (a) 3 duplicate acknowledgement or (b)timeout = event? On Thu, Feb 26, 2015 at 7:26 PM, Jonathan Morton = wrote: Okay, let me walk you through this. Let's say you are managing a fairly slow link, on the order of 1 = megabit. The receiver on the far side of it is running a modern OS and = has opened its receive window to a whole megabyte. It would take about = 10 seconds to pass a whole receive window through the link. This is a common situation in the real world, by the way. Now, let's suppose that the sender was constrained to a slower send = rate, say half a megabit, for reasons unrelated to the network. Maybe = it's a streaming video service on a mostly static image, so it only = needs to send small delta frames and compressed audio. It has therefore = opened the congestion window as wide as it will go, to the limit of the = receive window. But then the action starts, there's a complete scene = change, and a big burst of data is sent all at once, because the = congestion window permits it. So the queue you're managing suddenly has a megabyte of data in it. = Unless you do something about it, your induced latency just leapt up to = ten seconds, and the VoIP call your user was on at the time will drop = out. Now, let's compare the behaviour of two AQMs: Codel and something = almost, but not entirely, unlike Codel. Specifically, it does everything = that Codel does, but at enqueue instead of dequeue time. Both of them will let the entire burst into the queue. Codel only = takes action if the queue remains more full than its threshold for more = than 100ms. Since this burst arrives all at once, and the queue stayed = nice and empty up until now, neither AQM will decide to mark or drop = packets at that moment. Now, packets are slowly delivered across the link. Each one takes = about 15ms to deliver. They are answered by acks, and the sender = obligingly sends fresh packets to replace them. After about six or seven = packets have been delivered, both AQMs will decide to start marking = packets (this is an ECN enabled flow). Let's assume that the next packet = after this point will be marked. This will be the receiver's first clue = that congestion is occurring. For Codel, the next packet available to mark will be the eighth = packet. So the receiver learns about the congestion event 120 ms after = it began. It will echo the congestion mark back to the sender in the = corresponding ack, which will immediately halve the congestion window. = It will still take at least ten seconds to drain the queue. For NotCodel, the next available packet for marking is the one a = megabyte later than the eighth packet. The receiver won't see that = packet until 10120 ms after the congestion event began. So the sender = will happily keep the queue ten seconds long for the next ten seconds, = instead of backing off straight away. It will take at least TWENTY = seconds to drain the queue. Note that even if the link bandwidth was 10 megabits rather than = one, with the same receive window size, it would still take one second = to drain the queue with Codel and two seconds with NotCodel. This relatively simple traffic situation demonstrates that marking = on dequeue rather than enqueue is twice as effective at managing queue = length. - Jonathan Morton ------=_NextPart_000_0219_01D052A9.F45312A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Sahil,
 
A TCP Sender will reduce the congestion = window in a=20 similar fashion to both a) first ECE bit received in a window (flight of = packets=20 worth one RTT), and of course, b) exceeding the DupThresh limit of = duplicate=20 acks, again in one RTT worth of segments. The typical reaction in these = two=20 cases is a multiplicative reduction of the size of the congestion = window, with=20 the muliplication factor 0.5 - with other words, the sending rate is = halved.=20 (Some variants of TCP deviate from this factor of 0,5, but it's always a = multiplicative decrease (the second half of AIMD - additive increase,=20 multiplicative decrease; the general control law that results in stable = network=20 operating under load).
 
A retransmission timeout causes the = sending TCP to=20 reduce it's sending rate much more significantly - after an RTO, it = restarts the=20 TCP sending rate much like from a clean start, often even more gentle, = as the=20 initial window is reduced to only 1 or 2 segments (instead of 4 to=20 10)).
 
 
Regarding the absolute number of losses = - note that=20 it's only one loss (or mark) per RTT that halves the sending rate; with = large=20 congestion window, you could drop dozends or even hundreds of segments, = and the=20 sending TCP will still only half the sending rate. As long as all these = losses=20 occur within the first RTT. Another loss after the first RTT, and the = TCP sender=20 will react again (thus send only at 1/4 from the original = rate).
 
This is the reason why looking at raw = drop numbers=20 it not all that helpful byitself, the overall combination of goodput and =  latency (which, in case of TCP, includes queuing-induced latency,=20 transmission latency and loss recovery latency) are much more relevant. = With=20 ECN, the loss recovery latency is virtually zero, as the congestion = signal is=20 explicitly signaled from the network to the end hosts.
 
Unfortunately, Latency hasn't been a = big topic for=20 ISPs; Datacenter operators care much much more about latency (and it's = easier=20 there to deploy solutions, like ECN with an AQM set up with good = parameters for=20 that limited environment).
 
Hope this helps,
  Richard
 
----- Original Message -----
From:=20 sahil=20 grover
Sent: Friday, February 27, 2015 = 3:34=20 PM
Subject: Re: [Codel] why RED is = not=20 considered as a solution to bufferbloat.

Jonathan,
crystal clear now..
i mean the way u explain, Hats off seriously.
well,i  need to learn some more.
My question is how tcp reacts to packet drop,
like if we talk about packet marking then with acknowledgement = from=20 receiver, tcp sender gets the congestion signal(if i am not = wrong)
but if packet is dropped then what is mechanism?
 is it related with (a) 3 duplicate acknowledgement or = (b)timeout=20 event?


On Thu, Feb 26, 2015 at 7:26 PM, Jonathan = Morton <chromatix99@gmail.com> wrote:

Okay, let me walk you through this.

Let's say you are managing a fairly slow link, on the = order of 1=20 megabit. The receiver on the far side of it is running a modern OS = and has=20 opened its receive window to a whole megabyte. It would take about = 10=20 seconds to pass a whole receive window through the link.

This is a common situation in the real world, by the = way.

Now, let's suppose that the sender was constrained to a = slower=20 send rate, say half a megabit, for reasons unrelated to the network. = Maybe=20 it's a streaming video service on a mostly static image, so it only = needs to=20 send small delta frames and compressed audio. It has therefore = opened the=20 congestion window as wide as it will go, to the limit of the receive = window.=20 But then the action starts, there's a complete scene change, and a = big burst=20 of data is sent all at once, because the congestion window permits = it.

So the queue you're managing suddenly has a megabyte of = data in=20 it. Unless you do something about it, your induced latency just = leapt up to=20 ten seconds, and the VoIP call your user was on at the time will = drop=20 out.

Now, let's compare the behaviour of two AQMs: Codel and = something=20 almost, but not entirely, unlike Codel. Specifically, it does = everything=20 that Codel does, but at enqueue instead of dequeue time.

Both of them will let the entire burst into the queue. = Codel only=20 takes action if the queue remains more full than its threshold for = more than=20 100ms. Since this burst arrives all at once, and the queue stayed = nice and=20 empty up until now, neither AQM will decide to mark or drop packets = at that=20 moment.

Now, packets are slowly delivered across the link. Each = one takes=20 about 15ms to deliver. They are answered by acks, and the sender = obligingly=20 sends fresh packets to replace them. After about six or seven = packets have=20 been delivered, both AQMs will decide to start marking packets (this = is an=20 ECN enabled flow). Let's assume that the next packet after this = point will=20 be marked. This will be the receiver's first clue that congestion is = occurring.

For Codel, the next packet available to mark will be = the eighth=20 packet. So the receiver learns about the congestion event 120 ms = after it=20 began. It will echo the congestion mark back to the sender in the=20 corresponding ack, which will immediately halve the congestion = window. It=20 will still take at least ten seconds to drain the queue.

For NotCodel, the next available packet for marking is = the one a=20 megabyte later than the eighth packet. The receiver won't see that = packet=20 until 10120 ms after the congestion event began. So the sender will = happily=20 keep the queue ten seconds long for the next ten seconds, instead of = backing=20 off straight away. It will take at least TWENTY seconds to drain the = queue.

Note that even if the link bandwidth was 10 megabits = rather than=20 one, with the same receive window size, it would still take one = second to=20 drain the queue with Codel and two seconds with NotCodel.

This relatively simple traffic situation demonstrates = that=20 marking on dequeue rather than enqueue is twice as effective at = managing=20 queue length.

- Jonathan=20 Morton


------=_NextPart_000_0219_01D052A9.F45312A0--