From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 9170E21F3D5 for ; Fri, 27 Feb 2015 06:34:42 -0800 (PST) Received: by labhs14 with SMTP id hs14so17924925lab.4 for ; Fri, 27 Feb 2015 06:34:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vnYbgHyLR1Fwf467SUM3R3QgMpEqJvVL6qk6MFvOcM8=; b=KU2twBlohG5B5CIjbFdEqOg1af4FXk+XnnvGgUOyuJM7nzmRBblxn6LjMGRq7TCWvT MN75K06jt3M2dzDUkq0PO0ki2koIB+a7tPGmKCM+o7RuGoRB6x911r0cOUyH/UTHe60C XazTy3vNyqmbXf5o8pcmON1GVABQjyIZUdDhN0dgIybhTyqkfogcZEa1wUiqT/bKaKvs kDQk6sSdI3HwZj2EU1UMm4Dux+hLv+QL4lRk3Gq/+Ygk1l9H8W39JelMejBxDKhOqw/5 WpZ2iLl33jD5SRhReZSxVRClRqXSWXu5dkalsGKKX8gO9AZzD+KH/uROEMIsvYDYweAk Vt6g== MIME-Version: 1.0 X-Received: by 10.112.118.211 with SMTP id ko19mr12895544lbb.19.1425047679520; Fri, 27 Feb 2015 06:34:39 -0800 (PST) Received: by 10.25.147.75 with HTTP; Fri, 27 Feb 2015 06:34:39 -0800 (PST) In-Reply-To: References: Date: Fri, 27 Feb 2015 20:04:39 +0530 Message-ID: From: sahil grover To: Jonathan Morton Content-Type: multipart/alternative; boundary=047d7b8746c2b9d850051012c461 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 14:35:12 -0000 --047d7b8746c2b9d850051012c461 Content-Type: text/plain; charset=UTF-8 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 > --047d7b8746c2b9d850051012c461 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jonathan,
crystal clear now..
i mean the way u exp= lain, Hats off seriously.
well,i =C2=A0need 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 sen= der gets the congestion signal(if i am not wrong)
but if packet i= s dropped then what is mechanism?
=C2=A0is it related with (a) 3 = duplicate acknowledgement or (b)timeout event?


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

Okay, let me wa= lk you through this.

Let's say you are managing a fairly slow link, on the or= der 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 o= nly 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 re= ceive window. But then the action starts, there's a complete scene chan= ge, and a big burst of data is sent all at once, because the congestion win= dow 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 lea= pt up to ten seconds, and the VoIP call your user was on at the time will d= rop out.

Now, let's compare the behaviour of two AQMs: Codel and = something almost, but not entirely, unlike Codel. Specifically, it does eve= rything 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 mo= re than 100ms. Since this burst arrives all at once, and the queue stayed n= ice 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 obli= gingly sends fresh packets to replace them. After about six or seven packet= s 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 conge= stion is occurring.

For Codel, the next packet available to mark will be the eig= hth 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 corres= ponding ack, which will immediately halve the congestion window. It will st= ill take at least ten seconds to drain the queue.

For NotCodel, the next available packet for marking is the o= ne 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 m= arking on dequeue rather than enqueue is twice as effective at managing que= ue length.

- Jonathan Morton


--047d7b8746c2b9d850051012c461--