From ingemar.s.johansson@ericsson.com Sun Sep 11 22:52:23 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72EA21F8B05 for ; Sun, 11 Sep 2011 22:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.375 X-Spam-Level: X-Spam-Status: No, score=-5.375 tagged_above=-999 required=5 tests=[AWL=1.224, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFdXghMidrJ4 for ; Sun, 11 Sep 2011 22:52:23 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id B953F21F8B02 for ; Sun, 11 Sep 2011 22:52:22 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-00-4e6d9e8f4da9 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 72.8A.02839.F8E9D6E4; Mon, 12 Sep 2011 07:54:23 +0200 (CEST) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.203]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Mon, 12 Sep 2011 07:54:23 +0200 From: Ingemar Johansson S To: "Scheffenegger, Richard" , "iccrg@cs.ucl.ac.uk" Date: Mon, 12 Sep 2011 07:54:21 +0200 Thread-Topic: [conex] ECN in TCP and CWND Thread-Index: AcwHJeP4G4+ifRfwRtmBNxUuXLF2bBJRov2wBBdOK9AEEVumwA== Message-ID: References: <5FDC413D5FA246468C200652D63E627A0FC0FA50@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A0FC0FA50@LDCMVEXC1-PRD.hq.netapp.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: ConEx IETF list Subject: Re: [conex] ECN in TCP and CWND X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 05:52:24 -0000 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 =20 http://tools.ietf.org/html/draft-mathis-tcpm-proportional-rate-reduction-0= 0 later on, get the feeling that is is related to DCTCP or ? Again, thanks for the help. /Ingemar > -----Original Message----- > From: Scheffenegger, Richard [mailto:rs@netapp.com]=20 > Sent: den 22 augusti 2011 15:04 > To: Ingemar Johansson S; iccrg@cs.ucl.ac.uk > Cc: ConEx IETF list > Subject: RE: [conex] ECN in TCP and CWND >=20 > Hi Ingemar, >=20 > I believe there was a very similar question recently in TCPM,=20 > revolving around TCP-NCR, i.e. >=20 > http://www.ietf.org/mail-archive/web/tcpm/current/msg06528.html >=20 >=20 > My summary was that RFC5681 does allow cwnd to increase=20 > whenever an ACK acks new data (as would be the case with=20 > ECN); however, the consensus back then was that cwnd should=20 > not increase during "exceptional" events (reordering, loss=20 > recovery, ecn rtt), even though that may hinder tcp from=20 > throttling up when that may be safe... >=20 > OTOH, if cwnd is held constant during such events, particular=20 > loss recovery may not complete without RTO (and subsequent=20 > slow start), or cwnd may reduce to (and kept at) 1 segment=20 > for extended periods of time... >=20 > But your observation, that many implementations will actually=20 > increase cwnd after the cwnd reduction event, was made then too.=20 >=20 > Further note, that this particular behavior may get addressed=20 > with draft-mathis-tcpm-proportional-rate-reduction-00, as the=20 > cwnd reduction will be spaced out over ~1RTT - basically a=20 > new ACK will not necessarily trigger the sending of a new=20 > data segment (and not increase cwnd), when PRR is active. >=20 >=20 > But you may want to take this question to the tcpm group too... >=20 > Best regards, >=20 >=20 >=20 > Richard Scheffenegger >=20 > > -----Original Message----- > > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > > Sent: Montag, 01. August 2011 19:13 > > To: iccrg@cs.ucl.ac.uk > > Cc: ConEx IETF list > > Subject: [conex] ECN in TCP and CWND > >=20 > > Hi > >=20 > > I am digging in an experimental ECN for TCP implemementation. It is=20 > > supposed to be implemented according to RFC3168. > >=20 > > As I understand things "TCP should not react to congestion=20 > indications=20 > > more than once every window of data" (6.1.3 in RFC3168)=20 > Sofar so good,=20 > > sounds very reasonable. > > But what about CWND?, should it be allowed to increase during this=20 > > time?. > >=20 > > To me it sounds most reasonable to _not_ allow the CWND to increase=20 > > during the time that congestion indications are ingored but=20 > the code I=20 > > am staring at does not behave in this way. > >=20 > >=20 > > What is the correct behavior ? > >=20 > > Regards > > Ingemar > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > INGEMAR JOHANSSON M.Sc. > > Senior Researcher > >=20 > > Ericsson AB > > Wireless Area Networks > > Labratoriegr=E4nd 11 > > 971 28, Lule=E5, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 > > ingemar.s.johansson@ericsson.com > > www.ericsson.com > > Visit http://labs.ericsson.com ! > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex > = From mattmathis@google.com Wed Sep 21 15:19:34 2011 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197FB1F0CF6 for ; Wed, 21 Sep 2011 15:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUjuRVDQypXI for ; Wed, 21 Sep 2011 15:19:32 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5C66F1F0CF1 for ; Wed, 21 Sep 2011 15:19:30 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p8LMLwsx001058 for ; Wed, 21 Sep 2011 15:21:59 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1316643719; bh=6tsRnXWqUpidIT38oQ2bn4HHnXg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=r5U8D5HuQQM+SbvIBy64Mnl2q6u5W9pe5mxl14VK47pDByoKgGh0moIgl7WNgYRFZ ZeO7Sw1dEvvJFTWg0haPA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=ntc9atMtworArM8075jpwCJbaSMOdXBz6+n5pns9YN3aaA/e0oxyJFAIFvbxcr5yl FBQ+7nPqilkAt6Zy1MJDw== Received: from eyb6 (eyb6.prod.google.com [10.208.2.6]) by wpaz33.hot.corp.google.com with ESMTP id p8LMLunD020822 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 21 Sep 2011 15:21:57 -0700 Received: by eyb6 with SMTP id 6so1443698eyb.25 for ; Wed, 21 Sep 2011 15:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RptFs3+2YO7FH2543PKEMGT7wQeY2mD10KUNoBBLSmw=; b=GFkt6nzM9JTaP7+UaWsHxef+pC7HMi1uOrqan+FRQOThX8euBFn+m6LNFm9ZW+T6gW TqWUsu90/hHRS0/qCB2g== Received: by 10.213.13.200 with SMTP id d8mr1048290eba.89.1316643715499; Wed, 21 Sep 2011 15:21:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.13.200 with SMTP id d8mr1048277eba.89.1316643713987; Wed, 21 Sep 2011 15:21:53 -0700 (PDT) Received: by 10.213.12.211 with HTTP; Wed, 21 Sep 2011 15:21:53 -0700 (PDT) In-Reply-To: References: <5FDC413D5FA246468C200652D63E627A0FC0FA50@LDCMVEXC1-PRD.hq.netapp.com> Date: Wed, 21 Sep 2011 15:21:53 -0700 Message-ID: From: Matt Mathis To: Ingemar Johansson S Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "iccrg@cs.ucl.ac.uk" , ConEx IETF list Subject: Re: [conex] ECN in TCP and CWND X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 22:19:34 -0000 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. =A0- Alan Kay On Sun, Sep 11, 2011 at 10:54 PM, Ingemar Johansson S wrote: > Hi > > Thanks, and really sorry for my delayed response, seems like my mailbox a= nd mind is bloated these days :-) > Thanks for the reply, I double checked our TCP implementation and it seem= s then to be in order even though I find it a bit odd. > I will have a look at > =A0http://tools.ietf.org/html/draft-mathis-tcpm-proportional-rate-reducti= on-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:rs@netapp.com] >> Sent: den 22 augusti 2011 15:04 >> To: Ingemar Johansson S; iccrg@cs.ucl.ac.uk >> 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 - =A0basically 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:ingemar.s.johansson@ericsson.com] >> > Sent: Montag, 01. August 2011 19:13 >> > To: iccrg@cs.ucl.ac.uk >> > 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 >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > INGEMAR JOHANSSON =A0M.Sc. >> > Senior Researcher >> > >> > Ericsson AB >> > Wireless Area Networks >> > Labratoriegr=E4nd 11 >> > 971 28, Lule=E5, Sweden >> > Phone +46-1071 43042 >> > SMS/MMS +46-73 078 3289 >> > ingemar.s.johansson@ericsson.com >> > www.ericsson.com >> > Visit http://labs.ericsson.com ! >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > _______________________________________________ >> > conex mailing list >> > conex@ietf.org >> > https://www.ietf.org/mailman/listinfo/conex >> > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex >