<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=utf-8" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.23588">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2 face=Arial>Sahil,</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>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).</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>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)).</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>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).</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>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.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>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).</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>Hope this helps,</FONT></DIV>
<DIV><FONT size=2 face=Arial> Richard</FONT></DIV>
<DIV> </DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"
dir=ltr>
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="FONT: 10pt arial; BACKGROUND: #e4e4e4; font-color: black"><B>From:</B>
<A title=sahilgrover013@gmail.com href="mailto:sahilgrover013@gmail.com">sahil
grover</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=chromatix99@gmail.com
href="mailto:chromatix99@gmail.com">Jonathan Morton</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=codel@lists.bufferbloat.net
href="mailto:codel@lists.bufferbloat.net">codel@lists.bufferbloat.net</A> ; <A
title=rscheff@gmx.at href="mailto:rscheff@gmx.at">Richard Scheffenegger</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Friday, February 27, 2015 3:34
PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [Codel] why RED is not
considered as a solution to bufferbloat.</DIV>
<DIV><BR></DIV>
<DIV dir=ltr>Jonathan,
<DIV>crystal clear now..
<DIV>i mean the way u explain, Hats off seriously.</DIV>
<DIV>well,i need to learn some more.</DIV>
<DIV>My question is how tcp reacts to packet drop,</DIV>
<DIV>like if we talk about packet marking then with acknowledgement from
receiver, tcp sender gets the congestion signal(if i am not wrong)</DIV>
<DIV>but if packet is dropped then what is mechanism?</DIV>
<DIV> is it related with (a) 3 duplicate acknowledgement or (b)timeout
event?</DIV>
<DIV><BR></DIV></DIV></DIV>
<DIV class=gmail_extra><BR>
<DIV class=gmail_quote>On Thu, Feb 26, 2015 at 7:26 PM, Jonathan Morton <SPAN
dir=ltr><<A href="mailto:chromatix99@gmail.com"
target=_blank>chromatix99@gmail.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE
style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex"
class=gmail_quote>
<P dir=ltr>Okay, let me walk you through this.</P>
<P dir=ltr>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.</P>
<P dir=ltr>This is a common situation in the real world, by the way.</P>
<P dir=ltr>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.</P>
<P dir=ltr>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.</P>
<P dir=ltr>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.</P>
<P dir=ltr>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.</P>
<P dir=ltr>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.</P>
<P dir=ltr>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.</P>
<P dir=ltr>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.</P>
<P dir=ltr>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.</P>
<P dir=ltr>This relatively simple traffic situation demonstrates that
marking on dequeue rather than enqueue is twice as effective at managing
queue length.</P><SPAN class=HOEnZb><FONT color=#888888>
<P dir=ltr>- Jonathan
Morton<BR></P></FONT></SPAN></BLOCKQUOTE></DIV><BR></DIV></BLOCKQUOTE></BODY></HTML>