From tcpm-bounces@ietf.org Wed Jan 11 15:46:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewmrm-0001hV-Bv; Wed, 11 Jan 2006 15:46:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewmrk-0001hQ-SI for tcpm@megatron.ietf.org; Wed, 11 Jan 2006 15:46:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11487 for ; Wed, 11 Jan 2006 15:45:23 -0500 (EST) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewmyg-00073l-F6 for tcpm@ietf.org; Wed, 11 Jan 2006 15:53:57 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k0BKkblm066260 for ; Wed, 11 Jan 2006 12:46:37 -0800 (PST) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 25CE477B018 for ; Wed, 11 Jan 2006 15:46:36 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id E91D53A6584 for ; Wed, 11 Jan 2006 15:09:55 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: In the City MIME-Version: 1.0 Date: Wed, 11 Jan 2006 15:09:55 -0500 Message-Id: <20060111200955.E91D53A6584@lawyers.icir.org> X-Spam-Score: 0.7 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [tcpm] draft on congestion window limiting X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0395237692==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0395237692== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =20 Folks- A quick note (chair hat off) to let you know that several of us have put together a quick i-d on one particular strategy for mitigating micro-bursts within TCP. We submitted a very rough cut in November, but have just cleaned it up quite a bit and it was sent to the I-D archives this morning. Until it pops out in the standard places you can slurp it From=20the URL below. The I-D is: Janardhan Iyengar, Mark Allman, Ethan Blanton. TCP Burst Mitigation Through Congestion Window Limiting, January 2006. Internet-Draft draft-iyengar-burst-mitigation-01.txt (work in progress). http://www.icir.org/mallman/papers/draft-iyengar-burst-mitigation-01.txt It'd be great to get people experimenting and thinking about whether this is something that TCP needs or not. There are some data points on this contained in the references given in the I-D. In any case, we'd like to hear folks' thought on this one. Thanks! allman =2D-=20 Mark Allman -- ICIR/ICSI -- http://www.icir.org/mallman/ --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDxWYTWyrrWs4yIs4RApQmAKCMMwjFdV3KvQY/mZJ/vA0QWBhDTACbBn8h XBkSH86vdTJqaa5UwCCqtmo= =o16M -----END PGP SIGNATURE----- --=_bOundary-- --===============0395237692== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0395237692==-- From tcpm-bounces@ietf.org Fri Jan 13 13:02:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExTFs-0005Jv-QR; Fri, 13 Jan 2006 13:02:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExTFr-0005Jq-R7 for tcpm@megatron.ietf.org; Fri, 13 Jan 2006 13:02:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25531 for ; Fri, 13 Jan 2006 13:01:06 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExTNE-0005Nl-6c for tcpm@ietf.org; Fri, 13 Jan 2006 13:10:04 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0DI1Oi11767; Fri, 13 Jan 2006 10:01:24 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id k0DI1NXH022524; Fri, 13 Jan 2006 10:01:23 -0800 (PST) (envelope-from faber) Date: Fri, 13 Jan 2006 10:01:23 -0800 From: Ted Faber To: tcpm@ietf.org Subject: Re: [tcpm] ECN for SYN/ACK draft Message-ID: <20060113180123.GB21742@hut.isi.edu> References: <20051129194010.GG12561@hut.isi.edu> <20051208223917.GD22920@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20051208223917.GD22920@hut.isi.edu> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: floyd@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1976262200==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1976262200== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V0207lvV8h4k8FAm" Content-Disposition: inline --V0207lvV8h4k8FAm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 08, 2005 at 02:39:17PM -0800, Ted Faber wrote: > On Tue, Nov 29, 2005 at 11:40:11AM -0800, Ted Faber wrote: > > Hi. > >=20 > > As those of you who were at tsvwg in Vancouver know, Sally Floyd has > > proposed a draft adding ECN to SYN and SYN/ACK packets, which was not > > allowed under the original RFC 3168 ECN spec. The draft has not yet > > popped out, but there are also relatively-permanent local copies at: > >=20 > > http://www.icir.org/floyd/papers/draft-ietf-tsvwg-ecnsyn-00.txt > > http://www.icir.org/floyd/papers/draft-kuzmanovic-ecn-syn-00.txt > [snip] > >=20 > > If accepted, I'd like to request that we move fairly quickly to get this > > reviewed and on the publication path. I think sending it up to the IESG > > for Proposed Standard before Dallas would be reasonable, but you all get > > the final say. If we decide not to accept it, clear reasons need to be > > given. > >=20 > > Comments? >=20 > I realize that this is December and people have end-of-year holidays and > end-of-semester chores taking their time, but Mark and I need some > indication that this is a useful thing for us to do or it will go back > to TSVWG. OK, one more time. It's no longer December. This is a draft that TSVWG originally took on, but is right in the TCPMi area. The TSVWG and TCPM chairs agree this is the right group to do this work, but that doesn't matter if no one's interested in the work here. I understand that people from this group already hummed in TSVWG, but we need a show of interest to take it on here in TCPM. Please: * If you hummed in TSVWG and think it's good to do the work here, send a note. (Or if you don't think so, send that note). This needn't be a long message. =09 * Please read the draft and let us know what you think, whether you've read it or not. Obviously we'd be delighted to see the longer discussion. If the deafening silence continues, we'll have to send the draft back to TSVWG and our case for doing new work here will get muddier. Even if you think TCPM is a dumb place to do such work, please make that an actual statement rather than somethign we have to guess from a dead silence. Thanks! --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --V0207lvV8h4k8FAm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDx+rzaUz3f+Zf+XsRAgwXAJ9FDJwRHkeBQjOr6Lwphfdw6aRczQCgv0e7 8JWUSvHt7wfCAklmyVLUGdo= =IKto -----END PGP SIGNATURE----- --V0207lvV8h4k8FAm-- --===============1976262200== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1976262200==-- From tcpm-bounces@ietf.org Fri Jan 13 13:13:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExTQe-00081G-UH; Fri, 13 Jan 2006 13:13:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExTQd-000815-Eh for tcpm@megatron.ietf.org; Fri, 13 Jan 2006 13:13:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26127 for ; Fri, 13 Jan 2006 13:12:14 -0500 (EST) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExTXy-0005hM-UE for tcpm@ietf.org; Fri, 13 Jan 2006 13:21:12 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k0DIDUHs005331; Fri, 13 Jan 2006 10:13:30 -0800 (PST) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 8448577AAA7; Fri, 13 Jan 2006 13:13:28 -0500 (EST) To: Ted Faber From: Mark Allman Subject: Re: [tcpm] ECN for SYN/ACK draft In-Reply-To: <20060113180123.GB21742@hut.isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Pretty Noose MIME-Version: 1.0 Date: Fri, 13 Jan 2006 13:13:28 -0500 Message-Id: <20060113181328.8448577AAA7@guns.icir.org> X-Spam-Score: 0.7 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: tcpm@ietf.org, floyd@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1613121863==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1613121863== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [speaking as an individual contributer] I read through this I-D a week or so ago (along with the SIGCOMM paper From=20which the idea came). I think the general idea that ECT should be allowed on the SYN+ACK is a good idea. So, my opinion is that this document should be a WG item. (I am not sold on a host's response when a SYN+ACK is CE-ed by the network that is currently given in the I-D. I have iterated a little with the authors about this and I may have more to say about this aspect of the I-D in the future. But, part of the WG process is in engineering the scheme and so this sort of complaint has no bearing on whether I think the draft ought to be a WG item.) [chair hat on] What Ted said. More comments, please! allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDx+3IWyrrWs4yIs4RAi/4AJ9SX4xIkCLhvVyem+IODsTe4V9xJgCfTDne EreKwqFPV/gkZOyFNo4wE2c= =JZv2 -----END PGP SIGNATURE----- --=_bOundary-- --===============1613121863== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1613121863==-- From tcpm-bounces@ietf.org Sun Jan 15 15:35:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyEbV-0003sx-S2; Sun, 15 Jan 2006 15:35:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyEbU-0003sr-OQ for tcpm@megatron.ietf.org; Sun, 15 Jan 2006 15:35:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13439 for ; Sun, 15 Jan 2006 15:34:33 -0500 (EST) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyEjF-0001mW-RB for tcpm@ietf.org; Sun, 15 Jan 2006 15:44:00 -0500 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id EDA2A17E; Sun, 15 Jan 2006 15:35:51 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id C703C14D; Sun, 15 Jan 2006 15:35:44 -0500 (EST) Date: Sun, 15 Jan 2006 15:35:44 -0500 (EST) From: Janardhan Iyengar X-X-Sender: iyengar@stimpy.eecis.udel.edu To: Ted Faber Subject: Re: [tcpm] ECN for SYN/ACK draft In-Reply-To: <20060113180123.GB21742@hut.isi.edu> Message-ID: References: <20051129194010.GG12561@hut.isi.edu> <20051208223917.GD22920@hut.isi.edu> <20060113180123.GB21742@hut.isi.edu> X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on louie.udel.edu X-Spam-Status: No, score=-3.8 required=4.1 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tcpm@ietf.org, floyd@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Ted/all, > * If you hummed in TSVWG and think it's good to do the work > here, send a note. (Or if you don't think so, send that > note). This needn't be a long message. I somehow missed the last email asking for feedback on whether the draft belongs here---I had assumed that the draft was already in this WG. My bad, I forgot protocol. I think this work is meaningful as a TCPM WG item. > * Please read the draft and let us know what you think, whether > you've read it or not. Obviously we'd be delighted to see the > longer discussion. I have read the draft, and it looks good to me except for one part that needs clarification. Section 4, last para: "As a final step, [ECN+] explored the co-existence of flows that do and don't set the ECN-capable codepoint in TCP SYN/ACK packets. The results in [ECN+] confirmed that both types of flows can coexist; flows that apply the change improve their end-to-end performance, while the performance degradation for flows that don't apply the change, as a result of the flows that do apply the change, is marginal." Is this comparison the one in Figure 10 in the SIGCOMM paper? If so, I'm not sure if it would be correct to say that the performance degradation for flows that don't apply the change is "marginal". I like "gradual" instead, as used in the paper. Maybe "gradually significant". Let me know if I'm way off. Thanks! jana -------------------- Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar Protocol Engineering Lab, University of Delaware _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jan 16 16:38:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyc39-0003Al-P0; Mon, 16 Jan 2006 16:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyc37-0003Ag-ON for tcpm@megatron.ietf.org; Mon, 16 Jan 2006 16:38:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17703 for ; Mon, 16 Jan 2006 16:36:37 -0500 (EST) Received: from fep02-0.kolumbus.fi ([193.229.0.44] helo=fep02-app.kolumbus.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EycB6-0004EF-N7 for tcpm@ietf.org; Mon, 16 Jan 2006 16:46:18 -0500 Received: from a84-230-92-128.elisa-laajakaista.fi ([84.230.92.128]) by fep02-app.kolumbus.fi with ESMTP id <20060116213746.PLNH29001.fep02-app.kolumbus.fi@a84-230-92-128.elisa-laajakaista.fi>; Mon, 16 Jan 2006 23:37:46 +0200 Subject: Re: [tcpm] ECN for SYN/ACK draft From: Pasi Sarolahti To: Ted Faber In-Reply-To: <20060113180123.GB21742@hut.isi.edu> References: <20051129194010.GG12561@hut.isi.edu> <20051208223917.GD22920@hut.isi.edu> <20060113180123.GB21742@hut.isi.edu> Date: Mon, 16 Jan 2006 23:37:40 +0200 Message-Id: <1137447461.6655.56.camel@viivi> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: tcpm@ietf.org, floyd@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1709885054==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1709885054== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-fTrZBU+Rea7eB6JHIp6i" --=-fTrZBU+Rea7eB6JHIp6i Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I'm one who really intended to read the draft and respond to your call earlier, but never got to it until now... Sorry! On Fri, 2006-01-13 at 10:01 -0800, Ted Faber wrote: > * If you hummed in TSVWG and think it's good to do the work > here, send a note. (Or if you don't think so, send that > note). This needn't be a long message. I didn't see it a problem to have the draft in tsvwg, because there have been also other drafts on explicit transport signaling, even when primarily discussing TCP. But tcpm would be fine for me as well, since the draft is after all quite specific to TCP, as you said earlier. > * Please read the draft and let us know what you think, whether > you've read it or not. Obviously we'd be delighted to see the > longer discussion. To me the proposal seems pretty straightforward and well justified, and I'd be happy to see this going forward without delays. This sentence got me puzzled in the last paragraph of Section 2: "If the sending node (node B) was going to use an initial window of one segment, and receives an ECN-Echo packet informing it of a Congestion Experienced indication on its SYN/ACK packet, the sending node MAY continue to send with an initial window of one segment, without waiting for a retransmit timeout." I don't have opinion for or against this right now, but having TCP sender not slow down its sending rate in this particular case got me a bit alarmed. On the other hand, I realize this is a pretty minor thing, and one motivation of the draft is to avoid retransmit timeouts for SYN/ACKs, but maybe the draft could then say that this is not thought to be a significant concern for the network? (Especially since RFC 3168 argues that it is necessary to slow down the sending rate also when cwnd=3D=3D1 and ECN-Echo arrives) - Pasi --=-fTrZBU+Rea7eB6JHIp6i Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDzBIkoNa7NH1G2csRAl2rAKChbBZTBYeJTM3f50aIvE/zc+BsiACgweA6 5VALJrpqCaUgKXsc/Z7wDCw= =z6wh -----END PGP SIGNATURE----- --=-fTrZBU+Rea7eB6JHIp6i-- --===============1709885054== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1709885054==-- From tcpm-bounces@ietf.org Tue Jan 17 21:40:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez3Fg-00017I-9J; Tue, 17 Jan 2006 21:40:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez3Ff-000179-0C for tcpm@megatron.ietf.org; Tue, 17 Jan 2006 21:40:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24531 for ; Tue, 17 Jan 2006 21:39:20 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ez3Nt-0005Y9-8v for tcpm@ietf.org; Tue, 17 Jan 2006 21:49:18 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0I2dOi22117 for ; Tue, 17 Jan 2006 18:39:34 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id k0I2dJDJ084866 for tcpm@ietf.org; Tue, 17 Jan 2006 18:39:19 -0800 (PST) (envelope-from faber) Date: Tue, 17 Jan 2006 18:39:19 -0800 From: Ted Faber To: tcpm@ietf.org Message-ID: <20060118023919.GA84155@hut.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.txt ENDS 27 Jan 2006 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1792021639==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1792021639== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. I'd like to start a WG last call for the DCR document for protecting TCP from reordering from Bhandarkar, Reddy, Allman, and Blanton. Title : Improving the Robustness of TCP to Non-Congestion Events Authors : Sumitha Bhandarkar, et al. Filename : draft-ietf-tcpm-tcp-dcr-06.txt Pages : 17 Date : November 2005 http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-dcr-06.txt This draft is chartered to become Experimental. I understand that all the feedback to date, from the list and privately communicated, has been incorporated into the document. Further, I believe that the technical opinions as expressed have been largely in favor of this draft becoming Experimental. Now is the time to speak up if you disagree or feel that there are outstanding technical points that remain unaddressed in the document. Because this is starting mid-week, I'm extending the WGLC period for a couple days. Final day for comments is Friday 27, 2006 at midnight PST (but I'm not going to be picky over an hour). Please take some time to read it. Please take some time to send feedback to the list or to me. As with all TCPM documents, there needs to be a demonstration that the document has some support from the group, so even a message that says "ship it" is helpful. Also note that Mark is one of the authors, so I'm handling all the chair stuff for this one, including an idnits pass and all the admin.=20 Thanks for your help. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --jRHKVT23PllUwdXP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDzapXaUz3f+Zf+XsRAqM+AJ0QHtderdjs0AinUgnWHBFaRdF0igCeL93k rYo96aUDGi/uhi7E8KSS14w= =IwS4 -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- --===============1792021639== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1792021639==-- From tcpm-bounces@ietf.org Wed Jan 18 00:36:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez607-0005Zg-BF; Wed, 18 Jan 2006 00:36:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez604-0005Z4-3D for tcpm@megatron.ietf.org; Wed, 18 Jan 2006 00:36:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06178 for ; Wed, 18 Jan 2006 00:35:27 -0500 (EST) Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ez68J-0002al-Uw for tcpm@ietf.org; Wed, 18 Jan 2006 00:45:25 -0500 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.11/8.12.11) with ESMTP id k0I5ak1j081630; Tue, 17 Jan 2006 21:36:46 -0800 (PST) (envelope-from floyd@cougar.icir.org) Message-Id: <200601180536.k0I5ak1j081630@cougar.icir.org> To: Janardhan Iyengar From: Sally Floyd Subject: Re: [tcpm] ECN for SYN/ACK draft Date: Tue, 17 Jan 2006 21:36:46 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "K.K. Ramakrishnan" , tcpm@ietf.org, Ted Faber , Aleksandar Kuzmanovic X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Janardhan - Many thanks for the feedback. >I have read the draft, and it looks good to me except for one part that >needs clarification. Section 4, last para: > > "As a final step, [ECN+] explored the co-existence of flows that do > and don't set the ECN-capable codepoint in TCP SYN/ACK packets. The > results in [ECN+] confirmed that both types of flows can coexist; > flows that apply the change improve their end-to-end performance, > while the performance degradation for flows that don't apply the > change, as a result of the flows that do apply the change, is > marginal." > >Is this comparison the one in Figure 10 in the SIGCOMM paper? If so, I'm >not sure if it would be correct to say that the performance degradation >for flows that don't apply the change is "marginal". I like "gradual" >instead, as used in the paper. Maybe "gradually significant". Let me know >if I'm way off. I think that you are quite right. We will revise that paragraph. We are also planning on adding some simulations exploring worst-case scenarios of the addition of ECN-Capability to some SYN/ACK packets negatively affecting the performance of other traffic, just to be quite clear about what could and couldn't happen. Again, many thanks. - Sally http://www.icir.org/floyd/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jan 18 01:14:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez6am-000518-JR; Wed, 18 Jan 2006 01:14:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez6ak-000512-Mk for tcpm@megatron.ietf.org; Wed, 18 Jan 2006 01:14:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08539 for ; Wed, 18 Jan 2006 01:13:21 -0500 (EST) Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ez6j1-0003ez-Qp for tcpm@ietf.org; Wed, 18 Jan 2006 01:23:20 -0500 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.11/8.12.11) with ESMTP id k0I6EiqY082085; Tue, 17 Jan 2006 22:14:44 -0800 (PST) (envelope-from floyd@cougar.icir.org) Message-Id: <200601180614.k0I6EiqY082085@cougar.icir.org> To: Pasi Sarolahti From: Sally Floyd Subject: Re: [tcpm] ECN for SYN/ACK draft Date: Tue, 17 Jan 2006 22:14:44 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: "K.K. Ramakrishnan" , tcpm@ietf.org, Ted Faber , Aleksandar Kuzmanovic X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Pasi - >To me the proposal seems pretty straightforward and well justified, and >I'd be happy to see this going forward without delays. > >This sentence got me puzzled in the last paragraph of Section 2: > > "If the sending node (node B) was going to use an > initial window of one segment, and receives an ECN-Echo packet > informing it of a Congestion Experienced indication on its SYN/ACK > packet, the sending node MAY continue to send with an initial window > of one segment, without waiting for a retransmit timeout." > >I don't have opinion for or against this right now, but having TCP >sender not slow down its sending rate in this particular case got me a >bit alarmed. On the other hand, I realize this is a pretty minor thing, >and one motivation of the draft is to avoid retransmit timeouts for >SYN/ACKs, but maybe the draft could then say that this is not thought to >be a significant concern for the network? (Especially since RFC 3168 >argues that it is necessary to slow down the sending rate also when >cwnd=1 and ECN-Echo arrives) Yep, Mark Allman also raised the same point. At the moment, I have the following text added to the draft: Response to ECN-marking of SYN/ACK packets: One question is why TCP SYN/ACK packets should be treated differently from other packets in terms of the packet sender's response to an ECN-marked packet. Section 6.1.2 of RFC 3168 specifies that when the TCP congestion window consists of a single packet and that packet is ECN-marked in the network, then the sender must reduce the sending rate below one packet per round-trip time, by waiting for one RTO before sending another packet. If the RTO was set to the average round-trip time, this would result in halving the sending rate; because the RTO is in fact larger than the average round-trip time, the sending rate is reduced to less than half of its previous value. It might seem at first glance that the comparable response in reply to the ECN-marking of the SYN/ACK packet would be for the packet sender to reduce its sending rate by waiting for one RTO before sending the next packet. However, this would not result in halving the sending rate; the packet sender has only sent one packet, the SYN/ACK packet, so there is no sending rate to halve. If the RTO is set to its default initial value of three seconds, this would also not reduce the sending rate to one packet every two round-trip times, because the default three seconds could be much larger (or, in extreme cases, much smaller) than the actual round-trip time. One possibility would be for the packet sender to measure the round- trip time T between the sending of the SYN/ACK packet and the receipt of the acknowledgement, and to reply to the ECN-marking of the SYN/ACK packet by waiting T seconds before sending another packet. Conceptually, this could be thought of as halving the previous sending rate of one packet per round-trip time. However, because there is no `sending rate' associated with the SYN/ACK packet, it seems to us just as plausible for the packet sender to set its initial congestion window to one packet after the ECN-marking of the SYN/ACK packet, and to proceed with a cautious sending rate of one packet per round-trip time. If that packet is ECN-marked or dropped, then the sender will wait an RTO before sending another packet. It seems convincing to me, but we are also going to add a section about worst-case scenarios of the potential bad effects of this on other traffic, just to be clear. - Sally http://www.icir.org/floyd/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jan 18 16:39:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzL1A-0007SC-BC; Wed, 18 Jan 2006 16:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzL15-0007QU-UC; Wed, 18 Jan 2006 16:38:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06560; Wed, 18 Jan 2006 16:37:29 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzL9V-0006XR-Ct; Wed, 18 Jan 2006 16:47:37 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EzL15-0003zK-BK; Wed, 18 Jan 2006 16:38:55 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 18 Jan 2006 16:38:55 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: tcpm@ietf.org Subject: [tcpm] Last Call: 'A Roadmap for TCP Specification Documents' to Informational RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org The IESG has received a request from the TCP Maintenance and Minor Extensions WG to consider the following document: - 'A Roadmap for TCP Specification Documents ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-02-01. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-roadmap-05.txt _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jan 18 18:53:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzN7X-0004H5-7G; Wed, 18 Jan 2006 18:53:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzN7V-0004Gq-O2 for tcpm@megatron.ietf.org; Wed, 18 Jan 2006 18:53:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22012 for ; Wed, 18 Jan 2006 18:52:16 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzNFw-0004gI-16 for tcpm@ietf.org; Wed, 18 Jan 2006 19:02:24 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0INphi11074; Wed, 18 Jan 2006 15:51:43 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id k0INphFY094221; Wed, 18 Jan 2006 15:51:43 -0800 (PST) (envelope-from faber) Date: Wed, 18 Jan 2006 15:51:43 -0800 From: Ted Faber To: tcpm@ietf.org Subject: Re: [tcpm] ECN for SYN/ACK draft Message-ID: <20060118235143.GV96731@hut.isi.edu> References: <20051129194010.GG12561@hut.isi.edu> <20051208223917.GD22920@hut.isi.edu> <20060113180123.GB21742@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20060113180123.GB21742@hut.isi.edu> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: floyd@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0205776412==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0205776412== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QILrdhYozogw5Vly" Content-Disposition: inline --QILrdhYozogw5Vly Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In light of the generally positive reaction on the list and in private mail to the chairs and the complete lack of any negative indications, TCPM will be taking the ECN for SYN/ACK draft on as a working group item. It will be included in the upcoming charter update. Thanks for your input. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --QILrdhYozogw5Vly Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDztSPaUz3f+Zf+XsRAgxaAJ43xpSUFbysNhoitim+MgFz2zwh9ACfVDSN P/Ei8sVgaPXnKGpdIK0+Dy8= =r6gy -----END PGP SIGNATURE----- --QILrdhYozogw5Vly-- --===============0205776412== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0205776412==-- From tcpm-bounces@ietf.org Thu Jan 19 20:38:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzlEa-0003Qe-T1; Thu, 19 Jan 2006 20:38:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzlEZ-0003Pw-Hl for tcpm@megatron.ietf.org; Thu, 19 Jan 2006 20:38:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19862 for ; Thu, 19 Jan 2006 20:37:08 -0500 (EST) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzlND-0006Vl-7w for tcpm@ietf.org; Thu, 19 Jan 2006 20:47:31 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k0K1cNEo037284; Thu, 19 Jan 2006 17:38:24 -0800 (PST) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id B802777ACAA; Thu, 19 Jan 2006 20:38:21 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 981103AACA3; Thu, 19 Jan 2006 20:37:45 -0500 (EST) To: Sally Floyd From: Mark Allman Subject: Re: [tcpm] ECN for SYN/ACK draft In-Reply-To: <200601180614.k0I6EiqY082085@cougar.icir.org> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Down on the Corner MIME-Version: 1.0 Date: Thu, 19 Jan 2006 20:37:45 -0500 Message-Id: <20060120013745.981103AACA3@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: ietf/tcpm@icir.org, outbox@icir.org, Pasi Sarolahti , "K.K. Ramakrishnan" , Ted Faber , Aleksandar Kuzmanovic , tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1653236302==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1653236302== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline [speaking as an individual contributor, obviously] Sally and I have had a bit of offline discussion about the response to a CE-ed SYN+ACK. My intention here is to gather my high-order points for everyone to consider. First, I'll react to the new text that Sally posted... > It might seem at first glance that the comparable response in reply > to the ECN-marking of the SYN/ACK packet would be for the packet > sender to reduce its sending rate by waiting for one RTO before > sending the next packet. However, this would not result in halving > the sending rate; the packet sender has only sent one packet, the > SYN/ACK packet, so there is no sending rate to halve. I don't buy this argument. If we consider two connections ... one that has an SYN+ACK outstanding and one that has a data segment outstanding then they have the same rate [*]. I don't understand how there could be "no sending rate" in either of these cases. And, it confuses me even more than there could be a sending rate in one case and no sending rate in the other case. Maybe I am missing something here. [*] In terms of packets / second or packets / RTT --- there could be a bps difference because of differing packet sizes. The way I look at this, is as follows... * Exactly when we get to send the first data segment if the SYN+ACK is CE-ed is a very minor issue. Probably you could do anything and nothing awful would happen. Likewise, you could probably do anything on the first retransmit of a data segment when cwnd=1 in the middle of a connection and nothing awful would happen. * That said, I like consistency. I don't like special cases if they can be avoided. I'd rather just uniformly apply our algorithms and principles as much as possible. (That said, clearly there are sometimes special cases and deviating when there are well laid out special cases seems OK to me.) * Therefore, I don't like the notion from the ecnsyn I-D that when a SYN+ACK is CE-ed the sender gets to use a cwnd of 1 segment and transmit immediately because RFC3168 clearly doesn't allow this in other cases when there is only one segment outstanding. * It seems dubious to me to standardize as acceptable the practice of advertising ECT on a packet when the sender of that ECT has no intention of actually slowing down when given a CE by the network. * Is there a difference in the SYN+ACK getting CE-ed and some random data packet getting CE-ed when the cwnd=1? Yes. Are the differences a reason to transmit immediately? I don't think so. Let me work through two differences I see ... (1) If the cwnd is 1 in the middle of a connection there is probably a reason for it. I.e., it has been beat down to 1 segment because of congestion. So, not only do we have a cwnd of 1 segment, but we have a little more history of congestion. With the SYN+ACK getting CE-ed we do not have that history. This is all true. However, just because there is no visible history when the SYN+ACK is CE-ed doesn't mean the network is not in the same state as when cwnd=1 in the middle of the connection. We just don't know whether the SYN+ACK just got unlucky or the network is in a bad state. Basically, we're presenting one segment to the network and we're getting the same signal back. So, it seems to me that we ought to try to do about the same thing. As with other things we have standardized, I think that conservativeness is the right approach in the face of the unknown. (2) The other difference is that during the 3WHS the RTO is set to the default RTO and has nothing to do with the actual network path over which the connection is traversing. The basic idea behind ECT-ing the SYN+ACK is to get around the default RTO (3sec) in cases when ECN could clearly be used. I think this is a very nice idea. So, simply saying that a CE-ed SYN+ACK incurs the default RTO really makes the change proposed in this I-D pretty much a moot point. (It still helps a little in that the SYN+ACK wouldn't have to be resent after 3 seconds, but ...) Further, subjecting the connection to an arbitrary delay seems pretty dubious. If the two response options were "send immediately" or "send after the default RTO" then I'd probably lean towards the former because the draft would be pretty useless if the latter was used, IMO. But, there is no reason to limit ourselves to those two options. The ACK of the SYN+ACK gives an RTT measurement, so we can be much smarter. E.g., we could actually use this RTT measurement to seed the RTO per (2.2) in RFC2988 and then delay for RTO seconds before sending the first data segment. There are some people who don't like the idea of seeding the RTO during the 3WHS because of the discrepancy between packet sizes during the 3WHS and the data transfer. This certainly makes some sense. But, even if an implementation didn't want to set the actual RTO during the 3WHS it could impose a delay per (2.2) of RFC2988 on transmission of the first data segment in response to a SYN+ACK getting CE-ed. * Using either of these methods of imposing delay between getting the CE and sending the next data segment seems pretty consistent with the way that this is all handled elsewhere to me. In particular, ... + It doesn't seem aggressive in the face of the unknown. + It delays transmission very similarly to RFC3168. I.e., we respond to the same signal from about the same amount of load in about the same way in all cases. + It does not impose the penalty of an arbitrary default RTO on connections that get the SYN+ACK CE-ed. + It very likely improves the situation over dropping the SYN+ACK. So, my vote is for a delay that is based on RFC2988 and the measured RTT. (And, I am happy to keep discussing this if someone has another approach that might help me understand the difference of these cases and why immediate transmission is an OK special case during the 3WHS.) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFD0D7pWyrrWs4yIs4RAgWDAJ4jtIHxlE4j1ox0ZxffSNX0xTTiOQCfVbw1 FfHzHEUKt4lSJI+KVGeCqFQ= =CaqR -----END PGP SIGNATURE----- --=_bOundary-- --===============1653236302== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1653236302==-- From tcpm-bounces@ietf.org Fri Jan 20 12:28:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F003X-0002Ku-Gm; Fri, 20 Jan 2006 12:28:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F003V-0002Ka-S9 for tcpm@megatron.ietf.org; Fri, 20 Jan 2006 12:28:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03063 for ; Fri, 20 Jan 2006 12:26:41 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F00CG-0004KL-LR for tcpm@ietf.org; Fri, 20 Jan 2006 12:37:14 -0500 Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id DE65D14FF3; Fri, 20 Jan 2006 18:27:58 +0100 (CET) Received: from n-eggert.office ([10.1.1.112]) by venus.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jan 2006 18:27:58 +0100 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n-eggert.office (Postfix) with ESMTP id 66A6A64B640; Fri, 20 Jan 2006 18:27:57 +0100 (CET) In-Reply-To: <20060118023919.GA84155@hut.isi.edu> References: <20060118023919.GA84155@hut.isi.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: From: Lars Eggert Subject: Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.txt ENDS 27 Jan 2006 Date: Fri, 20 Jan 2006 18:27:55 +0100 To: Ted Faber X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 20 Jan 2006 17:27:58.0818 (UTC) FILETIME=[DB74B420:01C61DE6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0717879948==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0717879948== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-32-557086536; protocol="application/pkcs7-signature" --Apple-Mail-32-557086536 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi, On Jan 18, 2006, at 3:39, Ted Faber wrote: > > I'd like to start a WG last call for the DCR document for > protecting TCP > from reordering from Bhandarkar, Reddy, Allman, and Blanton. ... > Please take some time to read it. Please take some time to send > feedback to the list or to me. As with all TCPM documents, there > needs > to be a demonstration that the document has some support from the > group, > so even a message that says "ship it" is helpful. I gave it a quick read and I think it is in pretty good shape generally. Given that the text repeatedly states that the impact of this on the general Internet is not really known, I assume this is going for the "experimental in the sense that we want to experiment with it"-flavor of Experimental? If so, stating prominently in the abstract and maybe introduction that this is not ready for production use may be a good idea. One question regarding fairness: If there's a DCR flow and a non-DCR flow sharing a path that reorders packets a bit, wouldn't the reordering tolerance of the DCR flow cause it to steal bandwidth from the non-DCR flow? The paper says "it is to be noted that the reason for TCP-DCR realizing better throughputs (when packets are reordered) is not due to unfairness, but due to correctly recovering from the reordering events." Maybe I'm dense, but I don't see the experimental data to back this up. Is the throughput for SACK shown in Figure 4 identical when competing only against other SACK flows? Is the dynamic behavior roughly the same? Nits: overall, the specification parts of the document could try to use RFC2119 terms a bit more explicitly page 1: "mild reordering" - maybe _minor_ reordering? page 3/4: "schemes proposed for differentiated services architecture" - for _a_ diff. serv. arch.? page 4: "in the face of packet reordering three duplicate" - in the face of packet reordering, three duplicate (Similarly missing commas in many places throughout the document; need to read many sentences twice to grok the meaning.) page 10: s/algoritms in [RFC3517]/algorithms in [RFC3517]/ page 11: s/that the additonal buffer/that the additional buffer/ page 12/13: section 6 & its related work references could be removed for RFC publication ref BPS99: s/is not pat hological/is not pathological/ ref KM02: s/twostage switche s/twostage switches/ Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-32-557086536 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2 usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwMTIwMTcyNzU2WjAjBgkqhkiG9w0BCQQxFgQUBQ60F0JyMnBgZvkDw3Ex Zr8lsUMwgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBANBOtAaOrx6tod5cftOhsT08nfbtDdZhUMuosbfPlqUBBJHHnk4FIkiWw4jZKPK/VuSxiUL0 88aLjty+bc357jxNB58Q1XlpRZTPAYb62qct/OI+1hYWGC87xpAjCT93P6dnAZlyLzwOjEt9qAY0 drCsK6IbMsJL8wgLg5m2DxSs5HzqhAoKpnOaNRe+HcOG0dEebR+kBcy+iIotoarVsKYuZnv3ep30 Ee9A6Q/hyP8+6wtb06Mgs6xL6NfpRkAyWQn4TFvHQOLOf0Dnnwzvvvhzd2mgcAC8yWqDPmt6v4r+ dkUBQCc0qrWqrqv4u1qzMPEJ5HyUvY+4Ep585twRFOwAAAAAAAA= --Apple-Mail-32-557086536-- --===============0717879948== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0717879948==-- From tcpm-bounces@ietf.org Fri Jan 20 15:17:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02hh-0000VM-Uo; Fri, 20 Jan 2006 15:17:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02hg-0000VG-Hd for tcpm@megatron.ietf.org; Fri, 20 Jan 2006 15:17:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16096 for ; Fri, 20 Jan 2006 15:16:21 -0500 (EST) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F02qT-0001UA-7J for tcpm@ietf.org; Fri, 20 Jan 2006 15:26:54 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k0KKHht0055074; Fri, 20 Jan 2006 12:17:43 -0800 (PST) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 2F15777B063; Fri, 20 Jan 2006 15:17:41 -0500 (EST) To: Lars Eggert From: Mark Allman Subject: Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.txt ENDS 27 Jan 2006 In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Just the Way You Are MIME-Version: 1.0 Date: Fri, 20 Jan 2006 15:17:41 -0500 Message-Id: <20060120201741.2F15777B063@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1814389525==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1814389525== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Lars- Thanks for the comments. I'll fix up the nits, thanks! > Given that the text repeatedly states that the impact of this on the > general Internet is not really known, I assume this is going for the > "experimental in the sense that we want to experiment with it"-flavor > of Experimental? Yes. In fact, the really experimental part of it to me is that using Aggressive Limited Transmit delays the congestion response by an RTT. (To a lesser degree even the Careful variant of Limited Transmit removes the standard idle period between detecting "congestion" and resuming transmission. But, this seems sort of minor to me.) > If so, stating prominently in the abstract and maybe introduction that > this is not ready for production use may be a good idea. Good call. I'll add a note. > One question regarding fairness: I am confused about what you're reading here. I.e., the draft has no figures, the quote below isn't from the draft and I don't think we even discuss fairness in the i-d. > If there's a DCR flow and a non-DCR flow sharing a path that reorders > packets a bit, wouldn't the reordering tolerance of the DCR flow cause > it to steal bandwidth from the non-DCR flow? This is not clear to me. In fact, it's not clear to me exactly how fairness comes into this. If there were 2 flows over some path and no reordering then we'd expect them to see about the same performance (about half the bandwidth). Now, if there was reordering and neither did NCR then they would each get less than half the bandwidth -- say they each got 1/4 the bandwidth, just to put some numbers on things. So, now the reordering is causing a 50% slowdown in the flows and less than full utilization. Now, if one of the flows were to use NCR and it were to get more than 1/4 the bandwidth that would seem fine to me. And, in fact, the NCR flow could get up to 3/4 of the capacity and I wouldn't think that was unfair at all --- even though the rates are quite different. I.e., the NCR flow is using what is available. Now, if the NCR flow ended up with 7/8 of the capacity and drove the non-NCR flow to 1/8 of the capacity ... well, then there is a question. In some sense, the NCR flow is stealing from the non-NCR flow, for sure. Will this happen? I am not sure. Is there a way to minimize it? I don't know. Is this a natural part of trying to make progress and an incentive for stacks to combat reordering? Perhaps. This could all be part of the experiment. > The paper says "it is to be noted that the reason for TCP-DCR > realizing better throughputs (when packets are reordered) is not due > to unfairness, but due to correctly recovering from the reordering > events." Maybe I'm dense, but I don't see the experimental data to > back this up. Is the throughput for SACK shown in Figure 4 identical > when competing only against other SACK flows? Is the dynamic behavior > roughly the same? Where is this from? Thanks again! allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFD0UVlWyrrWs4yIs4RAoMKAJ9Opm0p30/vCJkMmZQxHWGkaeT6HgCglA7L M0pno55cfFaXIaFXjOXzKqg= =Hdn9 -----END PGP SIGNATURE----- --=_bOundary-- --===============1814389525== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1814389525==-- From tcpm-bounces@ietf.org Fri Jan 20 15:56:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F03JV-0004hJ-Mt; Fri, 20 Jan 2006 15:56:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F03JU-0004hD-4O for tcpm@megatron.ietf.org; Fri, 20 Jan 2006 15:56:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18720 for ; Fri, 20 Jan 2006 15:55:24 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F03SE-0002lL-GK for tcpm@ietf.org; Fri, 20 Jan 2006 16:05:58 -0500 Received: from lars.local (p54AD28B3.dip0.t-ipconnect.de [84.173.40.179]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 12D001BAC4D; Fri, 20 Jan 2006 21:56:38 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lars.local (Postfix) with ESMTP id 723FF64B69C; Fri, 20 Jan 2006 21:56:34 +0100 (CET) In-Reply-To: <20060120201741.2F15777B063@guns.icir.org> References: <20060120201741.2F15777B063@guns.icir.org> Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: <53E64C3C-9B40-4B14-848B-4FE22F0727D4@netlab.nec.de> From: Lars Eggert Subject: Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.txt ENDS 27 Jan 2006 Date: Fri, 20 Jan 2006 21:56:32 +0100 To: mallman@icir.org X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1048209970==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1048209970== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-37-569603432; protocol="application/pkcs7-signature" --Apple-Mail-37-569603432 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi, On Jan 20, 2006, at 21:17, Mark Allman wrote: >> One question regarding fairness: > > I am confused about what you're reading here. I.e., the draft has no > figures, the quote below isn't from the draft and I don't think we > even > discuss fairness in the i-d. oops, I meant to add that I got this from [BR04] before I hit "send." (I started thinking about the fairness stuff when reading the draft and then dug through the refs to find an evaluation.) >> If there's a DCR flow and a non-DCR flow sharing a path that reorders >> packets a bit, wouldn't the reordering tolerance of the DCR flow >> cause >> it to steal bandwidth from the non-DCR flow? > > This is not clear to me. In fact, it's not clear to me exactly how > fairness comes into this. If there were 2 flows over some path and no > reordering then we'd expect them to see about the same performance > (about half the bandwidth). Yup. > Now, if there was reordering and neither > did NCR then they would each get less than half the bandwidth -- say > they each got 1/4 the bandwidth, just to put some numbers on things. Yup. > So, now the reordering is causing a 50% slowdown in the flows and less > than full utilization. Now, if one of the flows were to use NCR > and it > were to get more than 1/4 the bandwidth that would seem fine to me. > And, in fact, the NCR flow could get up to 3/4 of the capacity and I > wouldn't think that was unfair at all --- even though the rates are > quite different. I.e., the NCR flow is using what is available. Right - iff the other flow still got its 1/4. I'm wondering if this will always (or at least usually) be the case. What if we had a long, fat path where the non-DCR flow would need a long time to get back to 1/2 - could the DCR flow actually delay that even more? Maybe not or not by much, but I'd still feel better if there was some sort of experimental results. > Now, > if the NCR flow ended up with 7/8 of the capacity and drove the non- > NCR > flow to 1/8 of the capacity ... well, then there is a question. In > some > sense, the NCR flow is stealing from the non-NCR flow, for sure. Will > this happen? I am not sure. Is there a way to minimize it? I don't > know. Is this a natural part of trying to make progress and an > incentive for stacks to combat reordering? Perhaps. This could > all be > part of the experiment. Right, that was sort of what popped up in my head when reading this. >> The paper says "it is to be noted that the reason for TCP-DCR >> realizing better throughputs (when packets are reordered) is not due >> to unfairness, but due to correctly recovering from the reordering >> events." Maybe I'm dense, but I don't see the experimental data to >> back this up. Is the throughput for SACK shown in Figure 4 identical >> when competing only against other SACK flows? Is the dynamic behavior >> roughly the same? > > Where is this from? Sumitha's Networking 2004 paper [BR04], but I just saw in Section 4 that the mechanism may have changed since then - that pub was about DCR. Also, note that I don't think this question is a showstopper for going forward with the draft as Experimental. It's one more question that should be looked at when experimenting with this. Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-37-569603432 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2 usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwMTIwMjA1NjMzWjAjBgkqhkiG9w0BCQQxFgQU6YtvIHNOK/dS2bzHy8gk 8+tjzQowgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAIblwPd2WB1V2SYojWLRk8QvwNRTfFsNxkw5qFQfKhS2uND6TwzH0nrP8l0n+Z9845+cX5+L A63VIbL0Xtb1/s8DK/9lFPxblw/ljZlL42NxXRqAcq1rmf5W667N54wt0TbGVfEAASeLBhigHlhc jF7SA5nq1Da/q6R5byvDZZPZUCCwlbn2Ibmv1aLTDC7cpqnSTAdu0Yt4Jxub3NaDm9N+PMgLPPJ6 XDqV6eCFA8PCScAz9zsRMQtCHvsKlAOFqllnhfIv7vbhKjVcZ1MYfDSkCyrlQu9PfYWxkG/UOiWM tT7lbU5I1Rj0Bb9C63NaKBr9twFJ0Ae5MRXhq50+PLAAAAAAAAA= --Apple-Mail-37-569603432-- --===============1048209970== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1048209970==-- From tcpm-bounces@ietf.org Fri Jan 20 16:32:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F03rj-0003aY-01; Fri, 20 Jan 2006 16:32:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F03rh-0003aQ-5R for tcpm@megatron.ietf.org; Fri, 20 Jan 2006 16:32:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29515 for ; Fri, 20 Jan 2006 16:30:45 -0500 (EST) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F040U-0006mm-Ax for tcpm@ietf.org; Fri, 20 Jan 2006 16:41:19 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 25B9B1492BF for ; Fri, 20 Jan 2006 13:32:00 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29239-10 for ; Fri, 20 Jan 2006 13:31:59 -0800 (PST) Received: from [127.0.0.1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 100DA1492BC for ; Fri, 20 Jan 2006 13:31:59 -0800 (PST) Message-ID: <43D156B4.8020802@redback.com> Date: Fri, 20 Jan 2006 13:31:32 -0800 From: Jakob Heitz Organization: Redback Networks, Software Development User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.txt ENDS 27 Jan 2006 References: <20060120201741.2F15777B063@guns.icir.org> In-Reply-To: <20060120201741.2F15777B063@guns.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Awesome footwork, Mark! I've been out of the loop for a while, so can someone please refresh me on the requirement for fairness. I understand the requirement to prevent the next Internet meltdown, but not a requirement for fairness. Mark Allman wrote: > >>If there's a DCR flow and a non-DCR flow sharing a path that reorders >>packets a bit, wouldn't the reordering tolerance of the DCR flow cause >>it to steal bandwidth from the non-DCR flow? > > > This is not clear to me. In fact, it's not clear to me exactly how > fairness comes into this. If there were 2 flows over some path and no > reordering then we'd expect them to see about the same performance > (about half the bandwidth). Now, if there was reordering and neither > did NCR then they would each get less than half the bandwidth -- say > they each got 1/4 the bandwidth, just to put some numbers on things. > So, now the reordering is causing a 50% slowdown in the flows and less > than full utilization. Now, if one of the flows were to use NCR and it > were to get more than 1/4 the bandwidth that would seem fine to me. > And, in fact, the NCR flow could get up to 3/4 of the capacity and I > wouldn't think that was unfair at all --- even though the rates are > quite different. I.e., the NCR flow is using what is available. Now, > if the NCR flow ended up with 7/8 of the capacity and drove the non-NCR > flow to 1/8 of the capacity ... well, then there is a question. In some > sense, the NCR flow is stealing from the non-NCR flow, for sure. Will > this happen? I am not sure. Is there a way to minimize it? I don't > know. Is this a natural part of trying to make progress and an > incentive for stacks to combat reordering? Perhaps. This could all be > part of the experiment. > > >>The paper says "it is to be noted that the reason for TCP-DCR >>realizing better throughputs (when packets are reordered) is not due >>to unfairness, but due to correctly recovering from the reordering >>events." Maybe I'm dense, but I don't see the experimental data to >>back this up. Is the throughput for SACK shown in Figure 4 identical >>when competing only against other SACK flows? Is the dynamic behavior >>roughly the same? > > > Where is this from? > > Thanks again! > > allman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Jan 20 17:33:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F04pR-0002lP-Rd; Fri, 20 Jan 2006 17:33:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F04pQ-0002kp-Jk for tcpm@megatron.ietf.org; Fri, 20 Jan 2006 17:33:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07745 for ; Fri, 20 Jan 2006 17:32:28 -0500 (EST) Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F04yE-0001jO-Bu for tcpm@ietf.org; Fri, 20 Jan 2006 17:43:03 -0500 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.3/8.13.3) with ESMTP id k0KMXj1Z009703 for ; Fri, 20 Jan 2006 14:33:45 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jan 2006 14:33:45 -0800 Received: from [192.168.81.4] ([192.168.81.4]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jan 2006 14:33:44 -0800 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: tcpm@ietf.org From: David Borman Date: Fri, 20 Jan 2006 16:33:41 -0600 X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 20 Jan 2006 22:33:45.0939 (UTC) FILETIME=[93313230:01C61E11] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Subject: [tcpm] RFC 2581 question X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi, I have a question about when to clear the duplicate ack counter. RFC 2581 says: The TCP sender SHOULD use the "fast retransmit" algorithm to detect and repair loss, based on incoming duplicate ACKs. The fast retransmit algorithm uses the arrival of 3 duplicate ACKs (4 identical ACKs without the arrival of any other intervening packets) as an indication that a segment has been lost. After receiving 3 duplicate ACKs, TCP performs a retransmission of what appears to be the missing segment, without waiting for the retransmission timer to expire. I'm questioning the description as 3 duplicate ACKs as "4 identical ACKs without the arrival of any other intervening packets". Let's take a normal fast retransmit case: dupack == 0 [101,200] ACK(1) ----> <---- ACK(200) [201,300] ACK(1) ----> LOST [301,400] ACK(1) ----> <---- ACK(200) dupack == 1 [401,500] ACK(1) ----> <---- ACK(200) dupack == 2 [501,600] ACK(1) ----> <---- ACK(200) dupack == 3 => Fast Retransmit! [101,200] ACK(1) ----> <---- ACK(600) Now, let's say the other side decided to send 10 bytes of data in the middle: dupack == 0 [101,200] ACK(1) ----> <---- ACK(200) [201,300] ACK(1) ----> LOST [301,400] ACK(1) ----> <---- ACK(200) dupack == 1 [401,500] ACK(1) ----> <---- ACK(200) dupack == 2 User writes 10 bytes of data <---- [1,10] ACK(200) Got an intervening packet, so reset: dupack = 0 ACK(10) -------------> [501,600] ACK(10) ----> <---- ACK(200) dupack == 1 No Fast Retransmit!!! It seems to me that the dupack counter should only be cleared when an ACK for new data is received, whether it is in a pure ACK or piggybacked on a data packet. Just the receipt of something other than a dup ack shouldn't cause the duplicate ack count to get reset. Am I missing something? -David Borman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Jan 21 14:04:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0O2S-0007ho-Ly; Sat, 21 Jan 2006 14:04:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0O2R-0007hh-ID for tcpm@megatron.ietf.org; Sat, 21 Jan 2006 14:04:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19164 for ; Sat, 21 Jan 2006 14:03:10 -0500 (EST) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0OBQ-0000wV-6w for tcpm@ietf.org; Sat, 21 Jan 2006 14:13:57 -0500 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id 972FF10F; Sat, 21 Jan 2006 14:04:34 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 22BE7CF; Sat, 21 Jan 2006 14:04:33 -0500 (EST) Date: Sat, 21 Jan 2006 14:04:33 -0500 (EST) From: Janardhan Iyengar X-X-Sender: iyengar@stimpy.eecis.udel.edu To: David Borman Subject: Re: [tcpm] RFC 2581 question In-Reply-To: Message-ID: References: X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on louie.udel.edu X-Spam-Status: No, score=-3.8 required=4.1 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org David, > It seems to me that the dupack counter should only be cleared when an ACK for > new data is received, whether it is in a pure ACK or piggybacked on a data > packet. Just the receipt of something other than a dup ack shouldn't cause > the duplicate ack count to get reset. I took a quick look at the FreeBSD code, and I think you are right (someone correct me if this is not the case). I am also wondering what the reason for the clause "without any intervening packets" is. I also do not see how your solution will work without SACK---how can a non-SACK sender determine when new data is being acked? A sender could still "not do anything to the dupack count" when a piggybacked ack is received. In other words, the dupack count is changed on only pure acks and new acks. That is a fair estimate in this particular case, IMHO, that new data is being acked. Anyone? - jana -------------------- Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar Protocol Engineering Lab, University of Delaware _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Jan 21 15:26:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0PJh-0000Rz-7v; Sat, 21 Jan 2006 15:26:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0PJf-0000Qp-F0 for tcpm@megatron.ietf.org; Sat, 21 Jan 2006 15:26:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23524 for ; Sat, 21 Jan 2006 15:25:03 -0500 (EST) Received: from wizmail.org ([217.146.107.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0PSe-0002zg-Hz for tcpm@ietf.org; Sat, 21 Jan 2006 15:35:49 -0500 Received: from trunk.jgh.adsl.wizards.co.uk ([217.146.123.57]) (from_AS 16353) by wizmail.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.52) id 1F0PJb-0004GV-Ez for tcpm@ietf.org (return-path ); Sat, 21 Jan 2006 20:26:27 +0000 Message-ID: <43D298E8.4090105@wizmail.org> Date: Sat, 21 Jan 2006 20:26:16 +0000 From: Jeremy Harris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050929 Thunderbird/1.0.7 Fedora/1.0.7-1.1.fc4 Mnenhy/0.7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.txt ENDS 27 Jan 2006 References: <20060120201741.2F15777B063@guns.icir.org> In-Reply-To: <20060120201741.2F15777B063@guns.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Mark Allman wrote: > This is not clear to me. In fact, it's not clear to me exactly how > fairness comes into this. If there were 2 flows over some path and no > reordering then we'd expect them to see about the same performance > (about half the bandwidth). Now, if there was reordering and neither > did NCR then they would each get less than half the bandwidth -- say > they each got 1/4 the bandwidth, just to put some numbers on things. > So, now the reordering is causing a 50% slowdown in the flows and less > than full utilization. Wait - you're arguing too far from an assumption, I think. Does reordering have as bad an effect on a congested link as on an uncongested link? Or is it more like a 5% penalty (congested) and 50% (congested). If so, there's potential for NCR to improve the situation for the flow using it to, say, 3/4 of the bandwidth - leaving the non-NCR user only getting 95% of 1/4 of the bandwidth. Possibly this is what you mean later: >if the NCR flow ended up with 7/8 of the capacity and drove the non-NCR >flow to 1/8 of the capacity ... well, then there is a question. and I didn't see the steps in your reasoning. I'd call it unfair, but justified. In any case, I'm not arguing against the draft becoming Experimental. Cheers, Jeremy Harris _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jan 23 09:41:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12sd-0005lK-F9; Mon, 23 Jan 2006 09:41:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F12sb-0005l4-1m for tcpm@megatron.ietf.org; Mon, 23 Jan 2006 09:41:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23859 for ; Mon, 23 Jan 2006 09:39:42 -0500 (EST) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F131w-0000Cw-80 for tcpm@ietf.org; Mon, 23 Jan 2006 09:50:53 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k0NEf0K9005207; Mon, 23 Jan 2006 06:41:00 -0800 (PST) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 090E777A9D9; Mon, 23 Jan 2006 09:40:59 -0500 (EST) To: Lars Eggert From: Mark Allman Subject: Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.txt ENDS 27 Jan 2006 In-Reply-To: <53E64C3C-9B40-4B14-848B-4FE22F0727D4@netlab.nec.de> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: The Other Side MIME-Version: 1.0 Date: Mon, 23 Jan 2006 09:40:59 -0500 Message-Id: <20060123144059.090E777A9D9@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: tcpm@ietf.org, Ted Faber X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1192765259==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1192765259== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > oops, I meant to add that I got this from [BR04] before I hit "send." > (I started thinking about the fairness stuff when reading the draft > and then dug through the refs to find an evaluation.) Thanks. I looked over the paper and I agree with you that the results in that paper do not specifically address the question you're asking. > Sumitha's Networking 2004 paper [BR04], but I just saw in Section 4 > that the mechanism may have changed since then - that pub was about > DCR. Right. > Also, note that I don't think this question is a showstopper for going > forward with the draft as Experimental. It's one more question that > should be looked at when experimenting with this. Great, thanks for the clarifications and the comments! allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFD1Or6WyrrWs4yIs4RAu/FAJwLzuB4T6JK/8L0SaNTVNCmOn5AzQCggSyS KBuqlnTICHLa/0T9zoAH4aU= =yEz5 -----END PGP SIGNATURE----- --=_bOundary-- --===============1192765259== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1192765259==-- From tcpm-bounces@ietf.org Mon Jan 23 09:52:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F133z-0002QL-95; Mon, 23 Jan 2006 09:52:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F133y-0002Pf-04 for tcpm@megatron.ietf.org; Mon, 23 Jan 2006 09:52:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25013 for ; Mon, 23 Jan 2006 09:51:27 -0500 (EST) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F13DJ-0000kh-JV for tcpm@ietf.org; Mon, 23 Jan 2006 10:02:39 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k0NEqoKf005332; Mon, 23 Jan 2006 06:52:51 -0800 (PST) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 231D077A9D9; Mon, 23 Jan 2006 09:52:50 -0500 (EST) To: Jakob Heitz From: Mark Allman Subject: Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.txt ENDS 27 Jan 2006 In-Reply-To: <43D156B4.8020802@redback.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: The Other Side MIME-Version: 1.0 Date: Mon, 23 Jan 2006 09:52:50 -0500 Message-Id: <20060123145250.231D077A9D9@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0149307280==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0149307280== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > I've been out of the loop for a while, so can someone > please refresh me on the requirement for fairness. > > I understand the requirement to prevent the next > Internet meltdown, but not a requirement for fairness. I am not sure there is a "requirement for fairness". It's certainly a little bit of a fuzzy issue in a case like NCR tries to combat. For instance, say over a given path two flows can get X bps given the current congestion and reordering state of the network. But, if NCR is used on one flow and that flow gets 3*X bps and the first flow still gets X bps is that unfair? For sure the flows have different rates. So, using something like Jain's fairness index (i.e., just measuring the spread of rates amongst all flows) might say this is unfair. But, to me, neither flow is sending at an inappropriate rate for the given context. I.e., the flow sending at X bps cannot send any faster and the flow sending at 3*X bps is just using what is available. (Another example of this would be one flow using an advertised window of Y and another using 5*Y and obtaining better performance.) Of course, it gets thornier if the flow that gets 3*X bps ends up stealing some of those bps from the other flow such that it sends at N*X (for some N < 1). Now, the reordering robust flow is not just using spare capacity, but also getting some of its performance boost at the expense of the non-NCR flow. We might say that is unfair and say we have to try to design something into NCR to avoid this - or, largely mitigate it. On the other hand, we might decide that the disadvantage is not great and that this is part of the natural evolutionary path of TCP, whereby older TCPs don't compete as well as newer TCPs and therefore, we view this as an incentive to upgrade. This would be a bit of engineering judgment after we have a solid set of experiments to look over, IMO. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFD1O3CWyrrWs4yIs4RAt61AJ0QsNtm2Fuw0qCmhR7dVi/mRz+jsQCfcRGp C6EclqFQDeOnkvzvbFzxaxI= =yisj -----END PGP SIGNATURE----- --=_bOundary-- --===============0149307280== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0149307280==-- From tcpm-bounces@ietf.org Mon Jan 23 09:56:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F137a-0003jg-9Q; Mon, 23 Jan 2006 09:56:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F137Z-0003jb-Mh for tcpm@megatron.ietf.org; Mon, 23 Jan 2006 09:56:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25213 for ; Mon, 23 Jan 2006 09:55:11 -0500 (EST) Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F13Gv-0000rP-E0 for tcpm@ietf.org; Mon, 23 Jan 2006 10:06:22 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k0NEuWVC005369; Mon, 23 Jan 2006 06:56:32 -0800 (PST) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 8BBD677A9D9; Mon, 23 Jan 2006 09:56:31 -0500 (EST) To: Jeremy Harris From: Mark Allman Subject: Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.txt ENDS 27 Jan 2006 In-Reply-To: <43D298E8.4090105@wizmail.org> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: The Other Side MIME-Version: 1.0 Date: Mon, 23 Jan 2006 09:56:31 -0500 Message-Id: <20060123145631.8BBD677A9D9@guns.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1067834634==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1067834634== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline > Does reordering have as bad an effect on a congested link > as on an uncongested link? My own guess is that on a congested link the congestion would have more of an impact than reordering. I think that if reordering ends up being the dominant phenomenon then the path will not be (as) congested because of the slow downs from false congestion signals. But, this would clearly be something to look at with real measurements and not just wave one's hands over as I am doing. > In any case, I'm not arguing against the draft becoming Experimental. Great, thanks! allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFD1O6fWyrrWs4yIs4RAtbgAJ0YqzuCTFhkEGjhURa9LX7EeLlPjACfWpKc yzIENAdHjcc79VDcJcO5LC4= =alIV -----END PGP SIGNATURE----- --=_bOundary-- --===============1067834634== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1067834634==-- From tcpm-bounces@ietf.org Mon Jan 23 10:05:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13G5-0005Oo-7p; Mon, 23 Jan 2006 10:05:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F13G3-0005OC-2C for tcpm@megatron.ietf.org; Mon, 23 Jan 2006 10:05:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25647 for ; Mon, 23 Jan 2006 10:03:58 -0500 (EST) Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F13PL-00017H-HL for tcpm@ietf.org; Mon, 23 Jan 2006 10:15:04 -0500 Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id C9812C2CE for ; Mon, 23 Jan 2006 10:05:10 -0500 (EST) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id k0NF593C012813; Mon, 23 Jan 2006 10:05:09 -0500 (EST) Received: from apataki.grc.nasa.gov (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id k0NF59UU029495; Mon, 23 Jan 2006 10:05:09 -0500 (EST) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id k0NF58HB029480; Mon, 23 Jan 2006 10:05:08 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id B9F7C4FD91; Mon, 23 Jan 2006 10:05:20 -0500 (EST) Date: Mon, 23 Jan 2006 10:05:20 -0500 From: Wesley Eddy To: Mark Allman Subject: Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.txt ENDS 27 Jan 2006 Message-ID: <20060123150520.GA25197@grc.nasa.gov> References: <43D156B4.8020802@redback.com> <20060123145250.231D077A9D9@guns.icir.org> Mime-Version: 1.0 In-Reply-To: <20060123145250.231D077A9D9@guns.icir.org> User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0118090548==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0118090548== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 23, 2006 at 09:52:50AM -0500, Mark Allman wrote: >=20 > I am not sure there is a "requirement for fairness". It's certainly a > little bit of a fuzzy issue in a case like NCR tries to combat. For > instance, say over a given path two flows can get X bps given the > current congestion and reordering state of the network. But, if NCR is > used on one flow and that flow gets 3*X bps and the first flow still > gets X bps is that unfair? For sure the flows have different rates. > So, using something like Jain's fairness index (i.e., just measuring the > spread of rates amongst all flows) might say this is unfair. But, to > me, neither flow is sending at an inappropriate rate for the given > context. I.e., the flow sending at X bps cannot send any faster and the > flow sending at 3*X bps is just using what is available. >=20 > (Another example of this would be one flow using an advertised window of > Y and another using 5*Y and obtaining better performance.) >=20 > Of course, it gets thornier if the flow that gets 3*X bps ends up > stealing some of those bps from the other flow such that it sends at N*X > (for some N < 1). Now, the reordering robust flow is not just using > spare capacity, but also getting some of its performance boost at the > expense of the non-NCR flow. We might say that is unfair and say we > have to try to design something into NCR to avoid this - or, largely > mitigate it. On the other hand, we might decide that the disadvantage > is not great and that this is part of the natural evolutionary path of > TCP, whereby older TCPs don't compete as well as newer TCPs and > therefore, we view this as an incentive to upgrade. This would be a bit > of engineering judgment after we have a solid set of experiments to look > over, IMO. More compactly, the question is how closely NCR can achieve a Pareto optimum, or max-min fairness, in competition with other types of flows. -Wes --=20 Wesley M. Eddy Verizon Federal Network Systems --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFD1PCwzBuYqbnj3IwRAnimAJ46PM3J9IpwZ08lZlg1A3hGmFQs7QCeP1DP +UTNZuL2pY9cXA3tupo1Kdg= =6jaw -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- --===============0118090548== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0118090548==-- From tcpm-bounces@ietf.org Mon Jan 23 14:34:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F17Sf-0000Xb-Nd; Mon, 23 Jan 2006 14:34:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F17Se-0000Wh-N5 for tcpm@megatron.ietf.org; Mon, 23 Jan 2006 14:34:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11897 for ; Mon, 23 Jan 2006 14:33:13 -0500 (EST) Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F17c2-0001LJ-Ae for tcpm@ietf.org; Mon, 23 Jan 2006 14:44:27 -0500 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.11/8.12.11) with ESMTP id k0NJYen6061791; Mon, 23 Jan 2006 11:34:40 -0800 (PST) (envelope-from floyd@cougar.icir.org) Message-Id: <200601231934.k0NJYen6061791@cougar.icir.org> To: tcpm@ietf.org From: Sally Floyd Date: Mon, 23 Jan 2006 11:34:40 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: "K.K. Ramakrishnan" , Aleksandar Kuzmanovic Subject: [tcpm] draft-ietf-tcpm-ecnsyn-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org I have submitted draft-ietf-tcpm-ecnsyn-00.txt to the internet-drafts editor, replacing draft-ietf-tsvwg-ecnsyn-00.txt. A copy is available at: http://www.icir.org/floyd/papers/draft-ietf-tcpm-ecnsyn-00.txt http://www.icir.org/floyd/papers/draft-ietf-tcpm-ecnsyn-00.ps The changes are as follows: Changes from draft-ietf-twvsg-ecnsyn: * Changed name of draft to draft-ietf-tcpm-ecnsyn. * Added a discussion in Section 3 of "Response to ECN-marking of SYN/ACK packets". Based on suggestions from Mark Allman. * Added a discussion to the Conclusions about adding ECN-capability to relevant set-up packets in other protocols. From a suggestion from Wesley Eddy. * Added a description of SYN exchanges with SYN cookies. From a suggestion from Wesley Eddy. * Added a discussion of one-way data transfers, where the host sending the SYN/ACK packet sends no data packets. * Minor editing, from feedback from Mark Allman and Janardhan Iyengar. * Future work: a look at the costs of adding ECN-Capability in a worst-case scenario. From feedback from Mark Allman and Janardhan Iyengar. * Future work: a comparative evaluation of two possible responses to an ECN-marked SYN/ACK packet. Many thanks for the feedback so far! - Sally http://www.icir.org/floyd/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jan 23 19:19:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Bub-00069K-Id; Mon, 23 Jan 2006 19:19:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Bua-000693-Mb for tcpm@megatron.ietf.org; Mon, 23 Jan 2006 19:19:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12233 for ; Mon, 23 Jan 2006 19:18:21 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1C3x-0006QY-IH for tcpm@ietf.org; Mon, 23 Jan 2006 19:29:37 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id QAA04773; Mon, 23 Jan 2006 16:17:42 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k0O0HfN01643; Mon, 23 Jan 2006 18:17:41 -0600 (CST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jan 2006 16:17:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] RFC 2581 question Date: Mon, 23 Jan 2006 16:17:34 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6DC9E97C@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [tcpm] RFC 2581 question Thread-Index: AcYevbx9wuCq3WsFSiasN5Qa3KsjagBvB3Qg From: "Henderson, Thomas R" To: "Janardhan Iyengar" , "David Borman" X-OriginalArrivalTime: 24 Jan 2006 00:17:34.0612 (UTC) FILETIME=[93028540:01C6207B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org I seem to recall that, in the course of revising NewReno, we raised some discussion with Mark about the ambiguity of what constitutes a dupack (in our discussion at the time, we were noticing that pure window updates were inappropriately resetting the NewReno dupack counter), and I believe that he mentioned it as one of the issues to be taken up in 2581bis. Tom > -----Original Message----- > From: Janardhan Iyengar [mailto:iyengar@mail.eecis.udel.edu]=20 > Sent: Saturday, January 21, 2006 11:05 AM > To: David Borman > Cc: tcpm@ietf.org > Subject: Re: [tcpm] RFC 2581 question >=20 > David, >=20 > > It seems to me that the dupack counter should only be=20 > cleared when an=20 > > ACK for new data is received, whether it is in a pure ACK or=20 > > piggybacked on a data packet. Just the receipt of something other=20 > > than a dup ack shouldn't cause the duplicate ack count to get reset. >=20 > I took a quick look at the FreeBSD code, and I think you are=20 > right (someone correct me if this is not the case). I am also=20 > wondering what the reason for the clause "without any=20 > intervening packets" is. I also do not see how your solution=20 > will work without SACK---how can a non-SACK sender determine=20 > when new data is being acked? >=20 > A sender could still "not do anything to the dupack count"=20 > when a piggybacked ack is received. In other words, the=20 > dupack count is changed on only pure acks and new acks. That=20 > is a fair estimate in this particular case, IMHO, that new=20 > data is being acked. >=20 > Anyone? >=20 > - jana >=20 > -------------------- > Janardhan R. Iyengar > http://www.cis.udel.edu/~iyengar > Protocol Engineering Lab, University of Delaware >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jan 23 21:39:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1E5v-0006Qx-2L; Mon, 23 Jan 2006 21:39:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1E5t-0006Qp-QE for tcpm@megatron.ietf.org; Mon, 23 Jan 2006 21:39:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27313 for ; Mon, 23 Jan 2006 21:38:10 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1EFK-0004iC-Hb for tcpm@ietf.org; Mon, 23 Jan 2006 21:49:29 -0500 Received: from [12.208.106.139] (helo=elb.elitists.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1E5n-000FVT-6k; Tue, 24 Jan 2006 02:39:35 +0000 Received: by elb.elitists.net (Postfix, from userid 3000) id 89D4C1E895; Mon, 23 Jan 2006 21:39:34 -0500 (EST) Date: Mon, 23 Jan 2006 21:39:34 -0500 From: Ethan Blanton To: Jian Liu Subject: Re: [tcpm] TCP duplicate ACK definition and detection, RFC 2581 Message-ID: <20060124023934.GL5063@colt.internal> Mail-Followup-To: Jian Liu , tcpm@ietf.org References: <2E42D9E13CBBA94A95552A4CA036CDC2047D33@hq-ex-3.brocade.com> Mime-Version: 1.0 In-Reply-To: <2E42D9E13CBBA94A95552A4CA036CDC2047D33@hq-ex-3.brocade.com> User-Agent: Mutt/1.4.1i X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0918287377==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0918287377== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sCNd3Ivk/oijKKf1" Content-Disposition: inline --sCNd3Ivk/oijKKf1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Jian Liu spake unto us the following wisdom: > Summary: duplicate ACK detection is not documented in any ACK; BSD4.4 > (documented in "TCP/IP Illustrated Volume 2 The implementation") may > not detect duplicate ACK if the traffice is bi-directional; propose a > simple modification on reseting duplicate ACK count to reliably detect > 3 duplicate ACK that triggers fast retransmit and fast recovery. This is well-defined in the next rev of RFC2581. Announcement forthcoming... Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 --sCNd3Ivk/oijKKf1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFD1ZNmr9kA9Ig8HBQRAkxvAKCoWgBQGYbNQP4TWN79/WEWWYib8gCggyZM MTgRS62awa3+fBwwHRYC6Uo= =tRw0 -----END PGP SIGNATURE----- --sCNd3Ivk/oijKKf1-- --===============0918287377== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0918287377==-- From tcpm-bounces@ietf.org Mon Jan 23 21:51:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1EHN-00018n-ND; Mon, 23 Jan 2006 21:51:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1EHM-00018i-BJ for tcpm@megatron.ietf.org; Mon, 23 Jan 2006 21:51:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27852 for ; Mon, 23 Jan 2006 21:50:01 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1EQo-00051j-EY for tcpm@ietf.org; Mon, 23 Jan 2006 22:01:19 -0500 Received: from [12.208.106.139] (helo=elb.elitists.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1EHJ-000G2Y-Pa; Tue, 24 Jan 2006 02:51:29 +0000 Received: by elb.elitists.net (Postfix, from userid 3000) id EA6C11E895; Mon, 23 Jan 2006 21:51:28 -0500 (EST) Date: Mon, 23 Jan 2006 21:51:28 -0500 From: Ethan Blanton To: David Borman Subject: Re: [tcpm] RFC 2581 question Message-ID: <20060124025128.GM5063@colt.internal> Mail-Followup-To: David Borman , tcpm@ietf.org References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.1i X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0926989591==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0926989591== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7vLGWvOrvbSM0Ba8" Content-Disposition: inline --7vLGWvOrvbSM0Ba8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Wow, I replied to an ancient email intending to reply to this one. Just goes to show this question is common. ;-) David Borman spake unto us the following wisdom: > I have a question about when to clear the duplicate ack counter. RFC =20 > 2581 says: >=20 > The TCP sender SHOULD use the "fast retransmit" algorithm to detect > and repair loss, based on incoming duplicate ACKs. The fast > retransmit algorithm uses the arrival of 3 duplicate ACKs (4 > identical ACKs without the arrival of any other intervening packets) > as an indication that a segment has been lost. After receiving 3 > duplicate ACKs, TCP performs a retransmission of what appears to be > the missing segment, without waiting for the retransmission timer to > expire. You are correct that this discription is ambiguous at best, and incorrect at worst. There is a forthcoming revision of RFC2581 which (hopefully) clarifies this issue. We look forward to comments on the draft... Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 --7vLGWvOrvbSM0Ba8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFD1ZYwr9kA9Ig8HBQRAkt/AKDLbwL45sPPYkVuyKVrz+1oRDelrACeMzYi YKQL5qEDa7HO8BH06bKYScw= =BM2L -----END PGP SIGNATURE----- --7vLGWvOrvbSM0Ba8-- --===============0926989591== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0926989591==-- From tcpm-bounces@ietf.org Mon Jan 23 22:23:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1EmP-0000Xw-ME; Mon, 23 Jan 2006 22:23:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1EmG-0000Ty-HO for tcpm@megatron.ietf.org; Mon, 23 Jan 2006 22:23:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29511 for ; Mon, 23 Jan 2006 22:21:57 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Evi-0005xq-NZ for tcpm@ietf.org; Mon, 23 Jan 2006 22:33:16 -0500 Received: from [12.208.106.139] (helo=elb.elitists.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1EmD-000HKg-L8; Tue, 24 Jan 2006 03:23:25 +0000 Received: by elb.elitists.net (Postfix, from userid 3000) id A2F0A1E895; Mon, 23 Jan 2006 22:23:09 -0500 (EST) Date: Mon, 23 Jan 2006 22:23:09 -0500 From: Ethan Blanton To: tcpm@ietf.org Message-ID: <20060124032309.GN5063@colt.internal> Mail-Followup-To: tcpm@ietf.org, mallman@icir.org, vern@icir.org Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: vern@icir.org, mallman@icir.org Subject: [tcpm] Revising RFC2581: draft-ietf-tcpm-rfc2581bis-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1307602460==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1307602460== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TN8pJM9vJMHHFgJc" Content-Disposition: inline --TN8pJM9vJMHHFgJc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, Mark Allman, Vern Paxson and I are ready to push a revised version of RFC2581 to the archives, draft-ietf-tcpm-rfc2581bis-00.txt . This is a charter goal for this working group, so we would love to have some feedback on the issue. Until this hits the archives: http://www.icir.org/mallman/papers/draft-ietf-tcpm-rfc2581bis-00.txt Note that the changes in this revision are specifically designed to be well-understood and non-contentious, as the goal is to move this document to Draft Standard. (A summary of changes follows.) In general, standards track RFC changes since RFC2581 have been integrated from elsewhere with very few other changes. There are a few clarifications (such as the definition of duplicate acknowledgment recently discussed on this list), as well. Please peruse this document when you get a chance (particularly if you know of a particular clarity issue or outdated text in RFC2581; make sure we took care of it!) and provide feedback to us. On-list feedback is most welcome, to stir community discussion. 7. Changes Relative to RFC 2581 A specific definition for "duplicate acknowledgment" has been added, based on the definition used by BSD TCP. The initial window requirements were changed to allow Larger Initial Windows as standardized in [RFC3390]. Additionally, the steps to take when an initial window is discovered to be too large due to Path MTU Discovery [RFC1191] are detailed. The recommended initial value for ssthresh has been changed to say that it SHOULD be arbitrarily high, where it was previously MAY. This is to provide additional guidance to implementors on the matter. During slow start, the usage of Appropriate Byte Counting [RFC3465] with L=1*SMSS is explicitly recommended. The method of increasing cwnd given in [RFC2581] is still explicitly allowed. Byte counting during congestion avoidance is also recommended, while the method from [RFC2581] and other safe methods are still allowed. The treatment of ssthresh on retransmission timeout was clarified. Specifically, Equation (3) from [RFC2581] was split into Equations (4) and (5) in this document. The description of fast retransmit and fast recovery has been clarified, and the use of Limited Transmit [RFC3042] is now recommended. The restart window has been changed to min(IW,cwnd) from IW. This behavior was described as "experimental" in [RFC2581]. It is now recommended that TCP implementors implement an advanced loss recovery algorithm conforming to the principles outlined in this document. The security considerations have been updated to discuss ACK division and recommend byte counting as a counter to this attack. Ethan --TN8pJM9vJMHHFgJc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFD1Z2dr9kA9Ig8HBQRArRWAKCa0PfpTvMYNvaU2LUZQuvgCzl4KQCgqUW4 366xJRSLOpoY8AVaz2tKrhk= =q05J -----END PGP SIGNATURE----- --TN8pJM9vJMHHFgJc-- --===============1307602460== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1307602460==-- From tcpm-bounces@ietf.org Tue Jan 24 15:51:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1V8D-0004Tn-GU; Tue, 24 Jan 2006 15:51:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1V7A-0003xy-SR; Tue, 24 Jan 2006 15:50:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17967; Tue, 24 Jan 2006 15:48:36 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1VGi-0002mV-2M; Tue, 24 Jan 2006 16:00:01 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F1V74-0002cZ-Mm; Tue, 24 Jan 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 24 Jan 2006 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-ecnsyn-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets Author(s) : A. Kuzmanovic, et al. Filename : draft-ietf-tcpm-ecnsyn-00.txt,.ps Pages : 16 Date : 2006-1-24 This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 only specified setting an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmit timeout, this document is specifying the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmit timeout for a connection that has not yet started placing a load on the network. The sender of the SYN/ACK packet must respond to an ECN mark by reducing its initial congestion window from two, three, or four segments to one segment, reducing the subsequent load from that connection on the network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-ecnsyn-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-ecnsyn-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-ecnsyn-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-1-24145046.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-ecnsyn-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-ecnsyn-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-24145046.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Wed Jan 25 16:51:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1sY0-0003zq-Fk; Wed, 25 Jan 2006 16:51:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1sXy-0003zg-8O for tcpm@megatron.ietf.org; Wed, 25 Jan 2006 16:51:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26207 for ; Wed, 25 Jan 2006 16:49:49 -0500 (EST) Received: from fep02-0.kolumbus.fi ([193.229.0.44] helo=fep02-app.kolumbus.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1shn-00035C-Br for tcpm@ietf.org; Wed, 25 Jan 2006 17:01:31 -0500 Received: from a84-230-92-128.elisa-laajakaista.fi ([84.230.92.128]) by fep02-app.kolumbus.fi with ESMTP id <20060125215108.MKQQ29001.fep02-app.kolumbus.fi@a84-230-92-128.elisa-laajakaista.fi>; Wed, 25 Jan 2006 23:51:08 +0200 Subject: Re: [tcpm] draft on congestion window limiting From: Pasi Sarolahti To: mallman@icir.org In-Reply-To: <20060111200955.E91D53A6584@lawyers.icir.org> References: <20060111200955.E91D53A6584@lawyers.icir.org> Date: Wed, 25 Jan 2006 23:51:01 +0200 Message-Id: <1138225861.16702.36.camel@viivi> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: eblanton@cs.purdue.edu, tcpm@ietf.org, iyengar@mail.eecis.udel.edu X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1019246285==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1019246285== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8wcyMk9t2kGEISpQwqTo" --=-8wcyMk9t2kGEISpQwqTo Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Some comments on the burst mitigation draft below... On Wed, 2006-01-11 at 15:09 -0500, Mark Allman wrote: > Janardhan Iyengar, Mark Allman, Ethan Blanton. TCP Burst Mitigation > Through Congestion Window Limiting, January 2006. Internet-Draft > draft-iyengar-burst-mitigation-01.txt (work in progress). > http://www.icir.org/mallman/papers/draft-iyengar-burst-mitigation-01.= txt >=20 > It'd be great to get people experimenting and thinking about whether > this is something that TCP needs or not. There are some data points on > this contained in the references given in the I-D. In any case, we'd > like to hear folks' thought on this one. I believe experimenting with burst mitigation algorithms in real networks could be possible for many of us. At least Linux has implemented a similar scheme for years, though I don't know what's the status of TCP in the latest kernel versions. (Btw, the Linux scheme is shortly outlined on page 6 of P. Sarolahti and A. Kuznetsov. "Congestion Control in Linux TCP". In Proceedings of Usenix/Freenix 2002. Monterey, CA, USA, June 2002.=20 [http://www.cs.helsinki.fi/u/sarolaht/papers/linuxtcp.pdf]) We did some experimentations with Linux TCP on slow links and a limited set of network paramaters about five years ago, and from what I remember (with the experience of an undergraduate student), burst mitigation didn't seem to cause problems, but not huge benefits, either. I think it would be worthwhile to discuss the trade-offs a bit more. Discussion section says that whether or not mitigation is needed remains open, but it could give some more baits for further thinking. For instance, while burst mitigation can reduce the stress on network queues to some extent, much research has been done on how to utilize a high-delay path as effectively as possible within the limits of congestion control principles. People working with high-delay paths might want to evaluate carefully whether reductions on congestion window are more harmful than the temporary=20 bursts of load on queues. I was also thinking about the fairness and incentiveness of burst mitigation as another kind of trade-off. I cannot come up with very good case that would illustrate this well, but let's assume there was a receiver with a buggy delayed ack implementation (say, ignoring the "ack-on-every-second" rule -- I have seen this sometimes), and two senders on the other side of the network, one implementing burst mitigation and another not. It would seem that burst mitigation would give unnecessary advantage to the flow that does not implement it. This could be a minor effect, but on the other hand, it is not known how significant the benefit for avoiding micro-bursts is. But to me the algorithm itself on Section 2 seems straightforward, and having BLimit to follow initial congestion window equation feels an appropriate choice. So if there was some consensus that burst mitigation is generally needed, I could not see what could go wrong with the algorithm as described in the draft. Other than that, I'm only able to come up with small nits: * I was thinking if the beginning of section 2 should emphasize it a bit more that burst mitigation is in an experimental landscape. Maybe in addition than just saying "When using CWL, the following steps MUST be executed", one could also add that CWL is experimental and TCP MAY implement it, and when using CWL, the following steps MUST be executed, just to make it clear. Well, I don't know. This is a very minor thing, and probably a matter of opinon. * Section 3 begins with: CWL makes TCP congestion control more conservative and is therefore implicitly allowed by [RFC2581]. Rather than being in the related work section, this note could also be somewhere in section 2. Don't know how much these thoughts help, but hopefully they at least spring up more comments ;-) - Pasi --=-8wcyMk9t2kGEISpQwqTo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBD1/LFoNa7NH1G2csRAtM7AJ4lJ+ZSsXtGsUX4hxExUx03GAIYgACgt2FS 0vjw8oYyuz03Yn4jxacXIDg= =GelW -----END PGP SIGNATURE----- --=-8wcyMk9t2kGEISpQwqTo-- --===============1019246285== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1019246285==-- From tcpm-bounces@ietf.org Wed Jan 25 21:32:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1wvc-0005Rc-ND; Wed, 25 Jan 2006 21:32:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1wva-0005RP-Ft for tcpm@megatron.ietf.org; Wed, 25 Jan 2006 21:32:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29300 for ; Wed, 25 Jan 2006 21:30:30 -0500 (EST) Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1x5R-0008I9-FL for tcpm@ietf.org; Wed, 25 Jan 2006 21:42:14 -0500 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.3/8.13.3) with ESMTP id k0Q2VSMK007383; Wed, 25 Jan 2006 18:31:28 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] RFC 2581 question Date: Wed, 25 Jan 2006 18:31:27 -0800 Message-ID: <31749A0AD079E64183675A5F5B741AAD015CE630@ALA-MAIL03.corp.ad.wrs.com> Thread-Topic: [tcpm] RFC 2581 question Thread-Index: AcYgkZHZAfMIQoz2RhacJSe1ZH++qQBjkw7w From: "Krejsa, Dan" To: "Ethan Blanton" , "Borman, David" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hi Ethan, I like the duplicate ACK definition in the new draft, however I'm not sure the draft addresses David's particular question regarding the phrase 'without the arrival of any other intervening packets'. What is the reason for this restriction? If a segment arrives which is not a 'duplicate ACK' according to the definition, but which does not acknowledge new data, should the duplicate ACK count really be zeroed as this phrase seems to imply? - Dan -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Ethan Blanton Sent: Monday, January 23, 2006 6:51 PM To: Borman, David Cc: tcpm@ietf.org Subject: Re: [tcpm] RFC 2581 question Wow, I replied to an ancient email intending to reply to this one. Just goes to show this question is common. ;-) David Borman spake unto us the following wisdom: > I have a question about when to clear the duplicate ack counter. RFC > 2581 says: >=20 > The TCP sender SHOULD use the "fast retransmit" algorithm to detect > and repair loss, based on incoming duplicate ACKs. The fast > retransmit algorithm uses the arrival of 3 duplicate ACKs (4 > identical ACKs without the arrival of any other intervening packets) > as an indication that a segment has been lost. After receiving 3 > duplicate ACKs, TCP performs a retransmission of what appears to be > the missing segment, without waiting for the retransmission timer to > expire. You are correct that this discription is ambiguous at best, and incorrect at worst. There is a forthcoming revision of RFC2581 which (hopefully) clarifies this issue. We look forward to comments on the draft... _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Jan 25 21:52:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1xF4-000636-2v; Wed, 25 Jan 2006 21:52:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1xF2-00061J-23 for tcpm@megatron.ietf.org; Wed, 25 Jan 2006 21:52:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00732 for ; Wed, 25 Jan 2006 21:50:36 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1xOt-0000VA-69 for tcpm@ietf.org; Wed, 25 Jan 2006 22:02:20 -0500 Received: from [12.208.106.139] (helo=elb.elitists.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F1xEw-000CDN-Uc; Thu, 26 Jan 2006 02:52:03 +0000 Received: by elb.elitists.net (Postfix, from userid 3000) id 5D2911E895; Wed, 25 Jan 2006 21:52:02 -0500 (EST) Date: Wed, 25 Jan 2006 21:52:02 -0500 From: Ethan Blanton To: "Krejsa, Dan" Subject: Re: [tcpm] RFC 2581 question Message-ID: <20060126025202.GV5063@colt.internal> Mail-Followup-To: "Krejsa, Dan" , "Borman, David" , tcpm@ietf.org References: <31749A0AD079E64183675A5F5B741AAD015CE630@ALA-MAIL03.corp.ad.wrs.com> Mime-Version: 1.0 In-Reply-To: <31749A0AD079E64183675A5F5B741AAD015CE630@ALA-MAIL03.corp.ad.wrs.com> User-Agent: Mutt/1.4.1i X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tcpm@ietf.org, "Borman, David" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0735309993==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0735309993== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="worL9B4ITIAQZ1FS" Content-Disposition: inline --worL9B4ITIAQZ1FS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Krejsa, Dan spake unto us the following wisdom: > I like the duplicate ACK definition in the new draft, however > I'm not sure the draft addresses David's particular question > regarding the phrase 'without the arrival of any other intervening > packets'. What is the reason for this restriction? If > a segment arrives which is not a 'duplicate ACK' according > to the definition, but which does not acknowledge new data, > should the duplicate ACK count really be zeroed as this phrase > seems to imply? Yes, this was brought up to us by another reader off-list ... I thought this was cleaned up when the dupack definition was added, but I have now seen that it was not. I have proposed the following text for the second paragraph of 3.2: The TCP sender SHOULD use the "fast retransmit" algorithm to detect and repair loss, based on incoming duplicate ACKs. The fast retransmit algorithm uses the arrival of 3 duplicate ACKs (as defined in section 2, without any intervening ACKs which move SND.UNA) as an indication that a segment has been lost. After receiving 3 duplicate ACKs, TCP performs a retransmission of what appears to be the missing segment, without waiting for the retransmission timer to expire. Does this look better to you? Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 --worL9B4ITIAQZ1FS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFD2DlSr9kA9Ig8HBQRAgxyAKCjNaadMwMw8WNMGR3j8NEGbZzv/gCeMEd4 OP0I8C4amGB0XFlUFfofMg8= =nzec -----END PGP SIGNATURE----- --worL9B4ITIAQZ1FS-- --===============0735309993== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============0735309993==-- From tcpm-bounces@ietf.org Wed Jan 25 22:00:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1xNB-00011W-Tb; Wed, 25 Jan 2006 22:00:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1xNA-00010D-H3 for tcpm@megatron.ietf.org; Wed, 25 Jan 2006 22:00:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01284 for ; Wed, 25 Jan 2006 21:59:00 -0500 (EST) Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1xX2-0000lZ-B6 for tcpm@ietf.org; Wed, 25 Jan 2006 22:10:44 -0500 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.3/8.13.3) with ESMTP id k0Q30KsF010784; Wed, 25 Jan 2006 19:00:20 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] RFC 2581 question Date: Wed, 25 Jan 2006 19:00:19 -0800 Message-ID: <31749A0AD079E64183675A5F5B741AAD015CE647@ALA-MAIL03.corp.ad.wrs.com> Thread-Topic: [tcpm] RFC 2581 question Thread-Index: AcYiI7lJ5q0SM4pFRkK853wzNV+vnAAAGgSQ From: "Krejsa, Dan" To: "Ethan Blanton" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org, "Borman, David" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Ethan Blanton Wrote: > I like the duplicate ACK definition in the new draft, however > I'm not sure the draft addresses David's particular question > regarding the phrase 'without the arrival of any other intervening > packets'. What is the reason for this restriction? If > a segment arrives which is not a 'duplicate ACK' according > to the definition, but which does not acknowledge new data, > should the duplicate ACK count really be zeroed as this phrase > seems to imply? Yes, this was brought up to us by another reader off-list ... I thought this was cleaned up when the dupack definition was added, but I have now seen that it was not. I have proposed the following text for the second paragraph of 3.2: The TCP sender SHOULD use the "fast retransmit" algorithm to detect and repair loss, based on incoming duplicate ACKs. The fast retransmit algorithm uses the arrival of 3 duplicate ACKs (as defined in section 2, without any intervening ACKs which move SND.UNA) as an indication that a segment has been lost. After receiving 3 duplicate ACKs, TCP performs a retransmission of what appears to be the missing segment, without waiting for the retransmission timer to expire. Does this look better to you? Yup, I think it does! - Dan _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Jan 26 15:50:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2E4J-0004Ld-HX; Thu, 26 Jan 2006 15:50:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2E4C-0004I6-Ot; Thu, 26 Jan 2006 15:50:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24006; Thu, 26 Jan 2006 15:48:32 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2EEE-0005Vn-8E; Thu, 26 Jan 2006 16:00:26 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F2E49-0008N1-TF; Thu, 26 Jan 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 26 Jan 2006 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-ietf-tcpm-rfc2581bis-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP Congestion Control Author(s) : M. Allman, et al. Filename : draft-ietf-tcpm-rfc2581bis-00.txt Pages : 15 Date : 2006-1-26 This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc2581bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-rfc2581bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-rfc2581bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-1-26120232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-rfc2581bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-rfc2581bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-26120232.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Mon Jan 30 01:23:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3SRW-0004PQ-59; Mon, 30 Jan 2006 01:23:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3SRU-0004PH-3r for tcpm@megatron.ietf.org; Mon, 30 Jan 2006 01:23:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29807 for ; Mon, 30 Jan 2006 01:21:37 -0500 (EST) Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3Sc9-0000e4-9Q for tcpm@ietf.org; Mon, 30 Jan 2006 01:34:16 -0500 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.11/8.12.11) with ESMTP id k0U6Mvvq065454; Sun, 29 Jan 2006 22:22:57 -0800 (PST) (envelope-from floyd@cougar.icir.org) Message-Id: <200601300622.k0U6Mvvq065454@cougar.icir.org> To: Janardhan Iyengar From: Sally Floyd Date: Sun, 29 Jan 2006 22:22:57 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: Ethan Blanton , tcpm@ietf.org, Mark Allman Subject: [tcpm] Re: draft-iyengar-burst-mitigation-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Jana - >We would appreciate it if you could find the time/energy to review this >draft. Though we'd prefer a public review (sent to TCPM), we will value >your review as much even if you'd rather send it to us in private. Here it is. Thanks for writing this draft, and hopefully starting to get some progress on these issues. - Sally http://www.icir.org/floyd/ Title: TCP Burst Mitigation Through Congestion Window Limiting Authors: Iyengar, Allman, and Blanton. I liked this draft, and think it is useful. And, though it makes a small change, I think that the mechanism proposed in the draft is a big improvement over "Use It or Lose it". First the high-level comments, about active queue management; rate-based pacing; and security considerations: * The network's tolerance of burstiness: The first paragraph of the Introduction says the following: "Bursting can stress network queues causing loss in the bursting connection as well as in other flows sharing the stressed queues." I think it would be useful to add that another important change that is happening in parallel, to some (unknown) extent, is for congested routers to use some form of Active Queue Management, allowing queues in the congested routers to accomodate transient bursts in the arriving traffic. Reason 1 for using AQM: Congestion control is more effective if queues don't giving congestion feedback (in the form of packet drops) in response to small transient bursts in the traffic. Reason 2 for using AQM: Even if burst mitigation and rate-based pacing and all other things are done at the end-nodes, there can still be burstiness in the aggregate traffic inside the network, and it would be good for queues to be tolerant of this. * Rate-based pacing: The document says that rate-based pacing could be quite effective, but the implementation can be costly (timers and such). I think it would be worth it to say that there are many cases where rate-based pacing should be a big win over CWL, or over MaxBurst, in terms of traffic dynamics. E.g., in a short connection with only BLimit + 1 more packets to send, but when only one ack will be arriving, due to ACK losses. Or when dealing with the significant transient bursts that can be caused by a connection slow-starting up to a large window. CWL and MaxBurst don't prevent the transient bursts of slow-start at all, but rate-based pacing could work well. Of course, it is still a question of whether the benefits of rate-based pacing are worth the costs in terms of implementation overhead. And there is still the old paper by Stefan Savage about rate-based pacing to deal with, about how rate-based pacing isn't always a win. But my suggestion would be to be more explicit about the potential advantages of rate-based pacing, and to say something about it a little earlier in the document. (My current assumption is that connections slow-starting up to large congestion windows have a large effect on the burstiness of the aggregate traffic. I forget, however, what some of the papers about burstiness-on-small-time-scales have to say about this...) * Security: I think that the security issues raised in Section 5 are pretty important, and could use more discussion. This is another case where rate-based pacing would be more robust than CWL, I think. Details: * Causes of micro-bursts: ACK-compression can also be a cause of micro-bursts. (That is, ACK-compression can cause micro-bursts as well as macro-bursts.) * Section 2, step (1): "the only case where a micro-burst will not occur" -> "the only case where a micro-burst will not occur, if steps (2) and (3) aren't used". * "BLimit SHOULD be chosen such that bursts are no larger than those allowed by [RFC3390]." Why is this? It is not obvious to me. For example, four-packet bursts, for 1500-byte packets, might be perfectly acceptable, for a connection that has a sufficiently large congestion window to send that many packets. And there is a cost to BLimit being at most three 1500-byte packets. * Maxburst: "An additional drawback of MaxBurst ...". What was the first drawback? Introducing a separate control? But the earlier sentence says that "using two different controls may make sense". "the two transmission controllers may interact poorly, causing undesirable side effects." Do you have any examples of this? Or citations? Or anything else to back this up? "When BLimit == MaxBurst, CWL and MaxBurst perform similarly [AB05]." I don't see how CWL and MaxBurst can perform similarly, and at the same time you can prefer one over the other. I think it would be useful to look a little more closely for performance differences, or to say that there aren't any. Depending on how it is implemented, MaxBurst could be made to work quite well with re-ordering, where each duplicate ack packet (possibly from reordering of data packets) could be responded-to with up to MaxBurst data packets (if allowed by the congestion window). (E.g., Aggressive MaxBurst from [AB05].) Can something like this be done with CWL as well? * I didn't go back and re-read [AB05]. so if I have forgotten something that is answered in that document, my apologies... _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jan 30 12:25:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3cmh-00034N-6x; Mon, 30 Jan 2006 12:25:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3cmf-00034A-CQ for tcpm@megatron.ietf.org; Mon, 30 Jan 2006 12:25:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10480 for ; Mon, 30 Jan 2006 12:24:10 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3cxT-00038X-EN for tcpm@ietf.org; Mon, 30 Jan 2006 12:36:55 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k0UHP2618409 for ; Mon, 30 Jan 2006 09:25:02 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id k0UHP2rv092789 for tcpm@ietf.org; Mon, 30 Jan 2006 09:25:02 -0800 (PST) (envelope-from faber) Date: Mon, 30 Jan 2006 09:25:01 -0800 From: Ted Faber To: tcpm@ietf.org Subject: Re: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.txt ENDS 27 Jan 2006 Message-ID: <20060130172501.GH31516@hut.isi.edu> References: <20060118023919.GA84155@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20060118023919.GA84155@hut.isi.edu> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1959418011==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1959418011== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xGGVyNQdqA79rdfn" Content-Disposition: inline --xGGVyNQdqA79rdfn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 17, 2006 at 06:39:19PM -0800, Ted Faber wrote: >=20 > Hi. >=20 > I'd like to start a WG last call for the DCR document for protecting TCP > from reordering from Bhandarkar, Reddy, Allman, and Blanton. >=20 > Title : Improving the Robustness of TCP to > Non-Congestion Events > Authors : Sumitha Bhandarkar, et al. > Filename : draft-ietf-tcpm-tcp-dcr-06.txt > Pages : 17 > Date : November 2005 > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-dcr-06.txt >=20 > This draft is chartered to become Experimental. I understand that all > the feedback to date, from the list and privately communicated, has been > incorporated into the document. Further, I believe that the technical > opinions as expressed have been largely in favor of this draft becoming > Experimental. Now is the time to speak up if you disagree or feel that > there are outstanding technical points that remain unaddressed in the > document. >=20 > Because this is starting mid-week, I'm extending the WGLC period for a > couple days. Final day for comments is Friday 27, 2006 at midnight PST > (but I'm not going to be picky over an hour). Having watched the discussion and spoken with Mark about any off-list interaction, it seems clear to me this dosument has passed WGLC. Minor issues were raised and dealt with during the WGLC, but no showstoppers surfaced. No one argued that the draft should not move to experimental. If I've missed comments, or you disagree with my assessment of consensus, I'd like to hear ASAP. Thanks to everyone who participated in the creation and review of this document. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --xGGVyNQdqA79rdfn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD3kvtaUz3f+Zf+XsRAnk1AKDpySUqwmJ1PkGxbWlV2dNxyEGcSACfR6Wt Dww9dvbb7rZGEPQuT6xRHz8= =rae8 -----END PGP SIGNATURE----- --xGGVyNQdqA79rdfn-- --===============1959418011== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --===============1959418011==-- From tcpm-bounces@ietf.org Mon Jan 30 17:17:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3hKm-0000qa-Pm; Mon, 30 Jan 2006 17:17:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3hKk-0000gt-BS for tcpm@megatron.ietf.org; Mon, 30 Jan 2006 17:17:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17127 for ; Mon, 30 Jan 2006 17:15:31 -0500 (EST) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3hVP-00012G-48 for tcpm@ietf.org; Mon, 30 Jan 2006 17:28:16 -0500 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id AB3EF229; Mon, 30 Jan 2006 17:16:58 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 9C6171AF; Mon, 30 Jan 2006 17:16:57 -0500 (EST) Date: Mon, 30 Jan 2006 17:16:57 -0500 (EST) From: Janardhan Iyengar X-X-Sender: iyengar@stimpy.eecis.udel.edu To: Pasi Sarolahti Subject: Re: [tcpm] draft on congestion window limiting In-Reply-To: <1138225861.16702.36.camel@viivi> Message-ID: References: <20060111200955.E91D53A6584@lawyers.icir.org> <1138225861.16702.36.camel@viivi> X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on louie.udel.edu X-Spam-Status: No, score=-3.8 required=4.1 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Ethan Blanton , tcpm@ietf.org, Mark Allman X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Pasi, Thank you for your comments, and for spending your time on this document. > I believe experimenting with burst mitigation algorithms in real > networks could be possible for many of us. At least Linux has > implemented a similar scheme for years, though I don't know what's the > status of TCP in the latest kernel versions. Thank you for this bit of information. The scheme mentioned in the paper looks like the "Use it or Lose it" scheme mentioned in the draft. I did probe the Linux community recently about whether a micro-burst mitigation scheme was deployed in Linux. The response I got was that there wasn't any such scheme currently deployed, but patches were available. I am not sure at this time if there is or isn't a scheme in Linux (I haven't looked at the code myself yet). I would be happy if someone could confirm for me which one is currently the case. > I think it would be worthwhile to discuss the trade-offs a bit > more. Agree, and Good point. I did have this in my mind, but I should have put it in the draft. Thanks for the tradeoff suggestions. > I was also thinking about the fairness and incentiveness of burst > mitigation as another kind of trade-off. I cannot come up with very good > case that would illustrate this well, but let's assume there was a > receiver with a buggy delayed ack implementation (say, ignoring the > "ack-on-every-second" rule -- I have seen this sometimes), and two > senders on the other side of the network, one implementing burst > mitigation and another not. It would seem that burst mitigation would > give unnecessary advantage to the flow that does not implement it. This > could be a minor effect, but on the other hand, it is not known how > significant the benefit for avoiding micro-bursts is. As far as the buggy receiver is concerned, I'm not sure that we should aim to demonstrate trade-offs in such cases. But, IIUC, your core point is that under the same conditions, a sender with burst-mitigation might be at a disadvantage with respect to a sender without burst-mitigation. There is also the possibility that a sender without burst-mitigation loses packets in the network due to the burst when a sender with burst-mitigation does not. So, I agree that there is a tradeoff. And that we should write it out clearly. > So if there was some consensus that burst mitigation is generally > needed, We are trying to gather data points on this question too. Our goal in this draft is to gauge interest in the issue, and to give a starting point for experimentation. > * I was thinking if the beginning of section 2 should emphasize it a bit > more that burst mitigation is in an experimental landscape. Maybe in We did try to emphasize exactly that (just before Section 2, in fact). Maybe it did not come through clearly enough.. I'll try to make it clearer. Section 2 specifies the mechanics of the algorithm itself and I'm not sure if that space should be used for making a statement about the experimental status of burst-mitigation. But, point taken. > * Section 3 begins with: > CWL makes TCP congestion control more conservative and is therefore > implicitly allowed by [RFC2581]. > Rather than being in the related work section, this note could also be > somewhere in section 2. Does Section 4 (Discussion) seem more appropriate? Thank you for your comments! regards, jana -------------------- Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar Protocol Engineering Lab, University of Delaware _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Jan 30 19:51:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3jjr-0005PE-P9; Mon, 30 Jan 2006 19:51:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3jh7-0004Ub-EH for tcpm@megatron.ietf.org; Mon, 30 Jan 2006 19:48:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23914 for ; Mon, 30 Jan 2006 18:47:50 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3il3-0003o8-Eu for tcpm@ietf.org; Mon, 30 Jan 2006 18:48:32 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA13981; Mon, 30 Jan 2006 15:36:43 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k0UNahW12724; Mon, 30 Jan 2006 15:36:43 -0800 (PST) Received: from XCH-NW-5V2.nw.nos.boeing.com ([130.247.55.45]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jan 2006 15:36:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] RFC2581bis Date: Mon, 30 Jan 2006 15:36:36 -0800 Message-ID: <8C7C41A176AC0B468BEFB2EFD9BDAB99CFB01F@XCH-NW-5V2.nw.nos.boeing.com> Thread-Topic: [tcpm] RFC2581bis Thread-Index: AcYgleAbFhKxWcWeSF+oEaw1it5VEQFWv4KQ From: "Duke, Martin" To: "Ethan Blanton" X-OriginalArrivalTime: 30 Jan 2006 23:36:37.0356 (UTC) FILETIME=[034342C0:01C625F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org, vern@icir.org, mallman@icir.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Ethan, I have concerns about setting ssthresh after multiple timeouts (Equation 5). My initial feeling is that cutting ssthresh in half each time is too conservative. Let's look at some potential causes of this, and what we might do with perfect knowledge: (1) Very severe congestion, causing frequent packet loss due to (a) temporary traffic spike: as long as this state exists, we're highly unlikely to get cwnd to the point where ssthresh matters. Later recovery will be hampered by a very low ssthresh. We'd probably prefer the pre-congestion ssthresh. (b) longer-term increase in traffic or reduction in link data rate: We'd want to reduce ssthresh, but perhaps not asymptotically to 2*MSS. (2) Link outage -- ideally, ssthresh should not change at all. (3) Routing change -- preferably, we would reset ssthresh to its default value to probe the new path. (1b) is the only case where we'd clearly want to reduce ssthresh, and it's not clear to me that flightsize/2 is not enough. So I'm not sure there's that much upside to being that conservative, and there's certainly downside in outage-prone wireless and satellite environments. I understand that we're not engineering to special cases. However, when we have the opportunity to refine standards to make TCP a little more wireless friendly, I think we should do so, especially when costs are low and benefits are high. As late as 2003 (and maybe still?), the Linux stack halved ssthresh only after the first retransmit, and that didn't appear to have particularly negative effects on internet performance. (The Linux stack behavior, and the effect on outage-prone wireless, are documented in our paper in ACM CCR Jun '04). So as an alternative, perhaps we should leave ssthresh unchanged after the first retransmit. Martin -----Original Message----- From: Ethan Blanton [mailto:eblanton@cs.ohiou.edu]=20 Sent: Monday, January 23, 2006 7:23 PM To: tcpm@ietf.org Cc: vern@icir.org; mallman@icir.org Subject: [tcpm] Revising RFC2581: draft-ietf-tcpm-rfc2581bis-00.txt Hi all, Mark Allman, Vern Paxson and I are ready to push a revised version of RFC2581 to the archives, draft-ietf-tcpm-rfc2581bis-00.txt . This is a charter goal for this working group, so we would love to have some feedback on the issue. Until this hits the archives: http://www.icir.org/mallman/papers/draft-ietf-tcpm-rfc2581bis-00.txt Note that the changes in this revision are specifically designed to be well-understood and non-contentious, as the goal is to move this document to Draft Standard. (A summary of changes follows.) In general, standards track RFC changes since RFC2581 have been integrated from elsewhere with very few other changes. There are a few clarifications (such as the definition of duplicate acknowledgment recently discussed on this list), as well. Please peruse this document when you get a chance (particularly if you know of a particular clarity issue or outdated text in RFC2581; make sure we took care of it!) and provide feedback to us. On-list feedback is most welcome, to stir community discussion. 7. Changes Relative to RFC 2581 A specific definition for "duplicate acknowledgment" has been added, based on the definition used by BSD TCP. The initial window requirements were changed to allow Larger Initial Windows as standardized in [RFC3390]. Additionally, the steps to take when an initial window is discovered to be too large due to Path MTU Discovery [RFC1191] are detailed. The recommended initial value for ssthresh has been changed to say that it SHOULD be arbitrarily high, where it was previously MAY. This is to provide additional guidance to implementors on the matter. During slow start, the usage of Appropriate Byte Counting [RFC3465] with L=3D1*SMSS is explicitly recommended. The method of increasing cwnd given in [RFC2581] is still explicitly allowed. Byte counting during congestion avoidance is also recommended, while the method from [RFC2581] and other safe methods are still allowed. The treatment of ssthresh on retransmission timeout was clarified. Specifically, Equation (3) from [RFC2581] was split into Equations (4) and (5) in this document. The description of fast retransmit and fast recovery has been clarified, and the use of Limited Transmit [RFC3042] is now recommended. The restart window has been changed to min(IW,cwnd) from IW. This behavior was described as "experimental" in [RFC2581]. It is now recommended that TCP implementors implement an advanced loss recovery algorithm conforming to the principles outlined in this document. The security considerations have been updated to discuss ACK division and recommend byte counting as a counter to this attack. Ethan _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm