Subject: Re: [conex] ECN in TCP and CWND

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 12 Sep 2011 07:54:21 +0200

Hi

Thanks, and really sorry for my delayed response, seems like my mailbox and mind is bloated these days :-)
Thanks for the reply, I double checked our TCP implementation and it seems then to be in order even though I find it a bit odd.
I will have a look at  
 http://tools.ietf.org/html/draft-mathis-tcpm-proportional-rate-reduction-00
later on, get the feeling that is is related to DCTCP or ?

Again, thanks for the help.
/Ingemar

> -----Original Message-----
> From: Scheffenegger, Richard [mailto:[email-masked]] 
> Sent: den 22 augusti 2011 15:04
> To: Ingemar Johansson S; [email-masked]
> Cc: ConEx IETF list
> Subject: RE: [conex] ECN in TCP and CWND
> 
> Hi Ingemar,
> 
> I believe there was a very similar question recently in TCPM, 
> revolving around TCP-NCR, i.e.
> 
> http://www.ietf.org/mail-archive/web/tcpm/current/msg06528.html
> 
> 
> My summary was that RFC5681 does allow cwnd to increase 
> whenever an ACK acks new data (as would be the case with 
> ECN); however, the consensus back then was that cwnd should 
> not increase during "exceptional" events (reordering, loss 
> recovery, ecn rtt), even though that may hinder tcp from 
> throttling up when that may be safe...
> 
> OTOH, if cwnd is held constant during such events, particular 
> loss recovery may not complete without RTO (and subsequent 
> slow start), or cwnd may reduce to (and kept at) 1 segment 
> for extended periods of time...
> 
> But your observation, that many implementations will actually 
> increase cwnd after the cwnd reduction event, was made then too. 
> 
> Further note, that this particular behavior may get addressed 
> with draft-mathis-tcpm-proportional-rate-reduction-00, as the 
> cwnd reduction will be spaced out over ~1RTT -  basically a 
> new ACK will not necessarily trigger the sending of a new 
> data segment (and not increase cwnd), when PRR is active.
> 
> 
> But you may want to take this question to the tcpm group too...
> 
> Best regards,
> 
> 
> 
> Richard Scheffenegger
> 
> > -----Original Message-----
> > From: Ingemar Johansson S [mailto:[email-masked]]
> > Sent: Montag, 01. August 2011 19:13
> > To: [email-masked]
> > Cc: ConEx IETF list
> > Subject: [conex] ECN in TCP and CWND
> > 
> > Hi
> > 
> > I am digging in an experimental ECN for TCP implemementation. It is 
> > supposed to be implemented according to RFC3168.
> > 
> > As I understand things "TCP should not react to congestion 
> indications 
> > more than once every window of data" (6.1.3 in RFC3168) 
> Sofar so good, 
> > sounds very reasonable.
> > But what about CWND?, should it be allowed to increase during this 
> > time?.
> > 
> > To me it sounds most reasonable to _not_ allow the CWND to increase 
> > during the time that congestion indications are ingored but 
> the code I 
> > am staring at does not behave in this way.
> > 
> > 
> > What is the correct behavior ?
> > 
> > Regards
> > Ingemar
> > =================================
> > INGEMAR JOHANSSON  M.Sc.
> > Senior Researcher
> > 
> > Ericsson AB
> > Wireless Area Networks
> > Labratoriegränd 11
> > 971 28, Luleå, Sweden
> > Phone +46-1071 43042
> > SMS/MMS +46-73 078 3289
> > [email-masked]
> > www.ericsson.com
> > Visit http://labs.ericsson.com !
> > =================================
> > _______________________________________________
> > conex mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/conex
>

---

From: Matt Mathis <[email-masked]>
Date: Wed, 21 Sep 2011 15:21:53 -0700

We have a paper on PRR to appear IMC11, that discusses this.
Basically if you lose more than 1/2 window in one RTT, RFC3517
specifies that you to make up the difference in a single burst.   This
happens frequently enough in real web traffic where algorithms that
are significantly less aggressive do no perform as well.    PRR is
slightly less aggressive, in that after massive losses, it grows the
window by one extra segment per ACK during the remainder of the
recovery.   This is essentially a slowstart.

It is important to note that "grow the window" is relative to the data
delivered, not the old window.

It turns out that even though PRR is slightly aggressive than RFC3517,
it often gets the same or better performance because the
retransmissions are somewhat less likely to be dropped.   The default
recovery algorithm in Linux (patterned after Rate Halving with
bounding parameters, an unfinished paper of mine from ~1998), does
poorly under these same circumstances, because cwnd can be pulled
artificially low, making recovery take a very long time).

In all fairness, at the time RFC3517 was written it was not realized
that >1/2 window burst losses might be common, or that SACK
retransmission strategies would be robust enough to routinely recover
from them.

We will be updating the PRR draft.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay