From mallman@icir.org Thu Mar 3 07:08:19 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F1C73A67B2 for ; Thu, 3 Mar 2011 07:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oq6Ki4mE42rf for ; Thu, 3 Mar 2011 07:08:18 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 1A5653A67B1 for ; Thu, 3 Mar 2011 07:08:17 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p23F9N7M027603; Thu, 3 Mar 2011 07:09:24 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id BE30333A2632; Thu, 3 Mar 2011 10:09:23 -0500 (EST) To: Yoshifumi Nishida From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: You MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma44833-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 03 Mar 2011 10:09:23 -0500 Sender: mallman@icir.org Message-Id: <20110303150923.BE30333A2632@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) ) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 15:08:19 -0000 ----------ma44833-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- > I've been thinking about the issue Richard brought up and I think it's > valid and worth for discussion. I personally think this is a minor > issue in RFC3517. (also in RFC3517bis) As part of thinking about 3517bis I came back to this yesterday and asked Ethan about it again. Per his suggestion from a while back, and since nobody else seems to have done so, we puzzled through this for a bit and played around with various scenarios. Again illustrating how subtle this stuff is we (really Ethan) have identified an issue. I am leaving your email appended below because its a nice summary to remind folks. The problematic scenario involves reordering, not loss. If you play out a scenario where packets 1--10 are transmitted in order, but arrive at the receiver as "2, 3, 4, 1, 5, 6, 7, 8, 9, 10" and there is no data beyond 10 available. Packet 1 will be retransmitted needlessly because of the reordering (in 3517, 3517bis and Richard's proposal). However, in the proposal below that removes condition (1.b) from step (3) in NextSeg() the TCP will also needlessly retransmit packets 7--10 whereas 3517 and 3517bis will not. Basically, with the proposed change it looks like this from the sender's perspective: snd 1--10, cwnd = 10 rcv ack=1, sack={2-2} (via pkt 2) rcv ack=1, sack={2-3} (via pkt 3) rcv ack=1, sack={2-4} (via pkt 4) rexmt 1, cwnd = 5, pipe = 7 rcv ack=5 (via pkt 1-orig), pipe = 6 rcv ack=6 (via pkt 5), pipe = 5 rcv ack=7 (via pkt 6), pipe = 4 rexmt 7, pipe = 5 rcv ack=8 (via pkt 7), pipe = 3 rexmt 8, pipe = 4 rexmt 9, pipe = 5 rcv ack=9 (via pkt 8), pipe = 2 rexmt 10, pipe = 3 Instead of 1 needless retransmit we end up with half the window needlessly retransmitted. (This holds I believe no matter how big the window gets if the first packet is delayed to the 4th position. Different amounts of delay will clearly result in different scenarios.) Of course, we have cut the sending rate (needlessly) and so in some sense this is conservative in terms of the *amount* of traffic being dumped into the network. However, in terms of *useful* traffic it is clearly suboptimal. So, there is a tradeoff here. In order to make loss recovery from the tail of a window (when there is no further data to send) more timely we aggravate the impact of reordering. (Note: This might not be the only issue. This is the first one we tripped over.) allman > Let's say, we have a pair of SACK TCP sender and receiver and when > cwnd=5, sender transmits S1, S2, S3 .. S5 packets. > Now, if we lost S1, S5, segments here, we will see the following sequence. > > 1: When S2 S3 S4 arrives at the receiver side, the receiver sends back > dupacks with SACK info to the sender. > 2: When the sender receives the 3rd dupack, it retransmits S1 and > enters loss recovery phase. > 3: When S1 arrives at the receiver side, the receiver sends back a > cumulative ACK for S4. > 4: When the ACK for S4 arrives, the sender process this ACK by the > following steps > 4.1: It's not greater than RecoveryPoint, so TCP cannot exit loss > recovery phase yet. > 4.2: Use update() and setpipe() and find it has only 1 outstanding segment. > 4.3: Since cwnd - pipe >= 1MSS, tcp tries to send one or more segments. > 4.4: Use NextSeg() to find the packet to be sent > > Here, I think there is one minor issue in NextSeg(). > When TCP checks if S5 can be sent with the rule (1) in NextSeg(), it > fails. ( because (1.b) and (1.c) return false.) > Rule (2) can be applicable "if there are available unsent data". But, > let's think about the case where there's no available unsent data. > Now, TCP is going to apply Rule (3) for S5, but again it fails ( > because (1.b) returns false. ) > Here, TCP cannot send any packets even though there is a chance to > send a retransmit packet. > > To summarize, I think the logic in RFC3517 can stall in some > situations even though there are packets can be sent. > This might cause the lost of ack clocking and unnecessary timeouts. > > I think the solution would be simple. Don't apply (1.b) to the Rule > (3) in NextSeg(). > I mean, change Rule (3) in NextSeg() from > > If the conditions for rules (1) and (2) fail, but there exists > an unSACKed sequence number 'S3' that meets the criteria for > detecting loss given in steps (1.a) and (1.b) above > (specifically excluding step (1.c)) then one segment of up to > SMSS octets starting with S3 MAY be returned. > > To > > If the conditions for rules (1) and (2) fail, but there exists > an unSACKed sequence number 'S3' that meets the criteria for > detecting loss given in steps (1.a) above > (specifically excluding step (1.b) and step (1.c)) then one > segment of up to > SMSS octets starting with S3 MAY be returned. > > I might need more time to think about this, but I think removing (1.b) > from (3) will not be very harmful. ----------ma44833-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk1vryMACgkQWyrrWs4yIs4GhQCdFeT5MFYX9Txaf9HSBVeHGduU pCcAnixWI7bpy9X9qmU7k1NgAdCOX4ro =viEi -----END PGP SIGNATURE----- ----------ma44833-1-- From mallman@icir.org Thu Mar 3 09:27:20 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07B4F3A6810 for ; Thu, 3 Mar 2011 09:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPJZzTRSheNt for ; Thu, 3 Mar 2011 09:27:19 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 33C193A67B3 for ; Thu, 3 Mar 2011 09:27:19 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p23HSQ5u021335; Thu, 3 Mar 2011 09:28:26 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 6CBFD33A98F0; Thu, 3 Mar 2011 12:28:26 -0500 (EST) To: "Scheffenegger, Richard" From: Mark Allman In-Reply-To: <5FDC413D5FA246468C200652D63E627A085752D2@LDCMVEXC1-PRD.hq.netapp.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: You MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma53178-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 03 Mar 2011 12:28:26 -0500 Sender: mallman@icir.org Message-Id: <20110303172826.6CBFD33A98F0@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) ) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 17:27:20 -0000 ----------ma53178-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Otoh, a more optimal approach could be to identify if the cumulative > ack 5 was due to the retransmitted seg 1, or the original seg 1 - > I.e. By using timestamp information. Depending on the result, a cumack > due to delayed seg1 could be identified and adressed (similar to eifel > detection/response).... > > Would that be a workable solution for that scenario? Maybe. I'll channel colleague here and note that you'd have to work through a bunch of scenarios. This reordering case is merely one example of the sort of thing Ethan and I have did *countless* times in the development of 3517. The interactions are subtle and not always readily apparent at first blush. (For instance, this conversation with Ethan started by me saying "looks OK, right?" and him saying something like "well, I dunno who has worked through it diligently?". And then me throwing out some examples and then both of us trying to figure out where it breaks. Ethan constructed a case based on your example where we needlessly retransmitted and then we hit upon the realization that half the window could get needlessly sent. But, it takes some effort to play through these things and dream up what might happen. So, "is that workable?" is a really tough question to answer.) Also, I'd like to remind folks that we never intended 3517 to be *the* way to do SACK. We designed it as a reasonable and conservative way to use SACK information to do loss recovery. I would be perfectly happy to see folks carefully develop alternatives. allman ----------ma53178-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEUEARECAAYFAk1vz7oACgkQWyrrWs4yIs6fCwCVFr0FA9OIxeLHEZ6S182tc5Cl TwCbB+5RBNt0TnIl0nkl0jdd5HhY3Ew= =rb5t -----END PGP SIGNATURE----- ----------ma53178-1-- From yoshifumi.nishida@gmail.com Thu Mar 3 22:21:04 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB4AE3A6800 for ; Thu, 3 Mar 2011 22:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZ-pi2stteXE for ; Thu, 3 Mar 2011 22:21:03 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 2F3D83A68D3 for ; Thu, 3 Mar 2011 22:21:03 -0800 (PST) Received: by yic13 with SMTP id 13so784398yic.31 for ; Thu, 03 Mar 2011 22:22:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JB0Ld69SbLp5qj7YOIBNCYKKdfnpvtvOihJpk/uNhCY=; b=awp92zykl9fhvVJZu3xzOKFHS//taxn3lj9Z31wyQX081y5OfJYp+e7DfqEAblp+p+ rcC6FsJRTft7GIAkDEOozDI0uOVCGhFJGRkfNcnpcWEnD3P9OaVFoWtQ8XryHnDt73E7 YMMNGrrSeKG1C4lJKgg8tZTFlzpVWKXvIkew0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=LfhwlMOS6I6u1mBLkl/hTs5+f+Utg+Q4UjpFQw+L7UMr248MlgqGLhS0kZSGDsNV9C wKIhLyvLdHhtHW66iD7okI+Yzi2nSGpSjQQjzWbLmXcbdv4cxdUbKJkcVpd2/S1s/NiV FcWwHe62mdc5vrRjcBc62/qDyyO0BTUStamgE= MIME-Version: 1.0 Received: by 10.150.63.8 with SMTP id l8mr256769yba.114.1299219731618; Thu, 03 Mar 2011 22:22:11 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.147.33.9 with HTTP; Thu, 3 Mar 2011 22:22:11 -0800 (PST) In-Reply-To: <20110303150923.BE30333A2632@lawyers.icir.org> References: <20110303150923.BE30333A2632@lawyers.icir.org> Date: Thu, 3 Mar 2011 22:22:11 -0800 X-Google-Sender-Auth: gAKk-2gjuz7vtvCDpmYQQw7KmVk Message-ID: From: Yoshifumi Nishida To: mallman@icir.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org Subject: Re: [tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) ) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 06:21:05 -0000 Hello Mark, Thanks for your response. The point you mentioned is exactly what I wanted to discuss. I have thought several similar scenarios and here's my opinion on that. 1: As Richard already pointed out, this redundant transmission happens even in NewReno, since NewReno retransmits the first unacknowledged segment when it receives a partial ACK. So, It's just as bad as NewReno but not worse than NewReno, which might be mostly acceptable. 2: If the problem is the amount of unnecessary transmission, we have several ways to mitigate this. 2a) I believe we can presume the use of delayed ACK in most cases. So, in your example, the amount of unnecessary transmission will be 1/4 of the window. 2b) We might be able to presume the use of DSACK, Once the sender finds out spurious retransmission, it can stop unnecessary transmission immediately. 2c) I believe it's possible to implement a certain simple logic to reduce the amount of unnecessary transmission. For example, I think we can apply this special rule every other time by having one flag in NextSeg(). Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/3/3 Mark Allman : > > Folks- > >> I've been thinking about the issue Richard brought up and I think it's >> valid and worth for discussion. =A0I personally think this is a minor >> issue in RFC3517. (also in RFC3517bis) > > As part of thinking about 3517bis I came back to this yesterday and > asked Ethan about it again. =A0Per his suggestion from a while back, and > since nobody else seems to have done so, we puzzled through this for a > bit and played around with various scenarios. =A0Again illustrating how > subtle this stuff is we (really Ethan) have identified an issue. =A0I am > leaving your email appended below because its a nice summary to remind > folks. > > The problematic scenario involves reordering, not loss. =A0If you play ou= t > a scenario where packets 1--10 are transmitted in order, but arrive at > the receiver as "2, 3, 4, 1, 5, 6, 7, 8, 9, 10" and there is no data > beyond 10 available. =A0Packet 1 will be retransmitted needlessly because > of the reordering (in 3517, 3517bis and Richard's proposal). =A0However, > in the proposal below that removes condition (1.b) from step (3) in > NextSeg() the TCP will also needlessly retransmit packets 7--10 whereas > 3517 and 3517bis will not. =A0Basically, with the proposed change it look= s > like this from the sender's perspective: > > snd 1--10, cwnd =3D 10 > rcv ack=3D1, sack=3D{2-2} (via pkt 2) > rcv ack=3D1, sack=3D{2-3} (via pkt 3) > rcv ack=3D1, sack=3D{2-4} (via pkt 4) > rexmt 1, cwnd =3D 5, pipe =3D 7 > rcv ack=3D5 (via pkt 1-orig), pipe =3D 6 > rcv ack=3D6 (via pkt 5), pipe =3D 5 > rcv ack=3D7 (via pkt 6), pipe =3D 4 > rexmt 7, pipe =3D 5 > rcv ack=3D8 (via pkt 7), pipe =3D 3 > rexmt 8, pipe =3D 4 > rexmt 9, pipe =3D 5 > rcv ack=3D9 (via pkt 8), pipe =3D 2 > rexmt 10, pipe =3D 3 > > Instead of 1 needless retransmit we end up with half the window > needlessly retransmitted. =A0(This holds I believe no matter how big the > window gets if the first packet is delayed to the 4th position. > Different amounts of delay will clearly result in different scenarios.) > > Of course, we have cut the sending rate (needlessly) and so in some > sense this is conservative in terms of the *amount* of traffic being > dumped into the network. =A0However, in terms of *useful* traffic it is > clearly suboptimal. > > So, there is a tradeoff here. =A0In order to make loss recovery from the > tail of a window (when there is no further data to send) more timely we > aggravate the impact of reordering. > > (Note: This might not be the only issue. =A0This is the first one we > tripped over.) > > allman > > > > > >> Let's say, we have a pair of SACK TCP sender and receiver and when >> cwnd=3D5, sender transmits S1, S2, S3 .. S5 packets. >> Now, if we lost S1, S5, segments here, we will see the following sequenc= e. >> >> 1: When S2 S3 S4 arrives at the receiver side, the receiver sends back >> dupacks with SACK info to the sender. >> 2: When the sender receives the 3rd dupack, it retransmits S1 and >> enters loss recovery phase. >> 3: When S1 arrives at the receiver side, the receiver sends back a >> cumulative ACK for S4. >> 4: When the ACK for S4 arrives, the sender process this ACK by the >> following steps >> =A0 =A0 4.1: It's not greater than RecoveryPoint, so TCP cannot exit los= s >> recovery phase yet. >> =A0 =A0 4.2: Use update() and setpipe() and find it has only 1 outstandi= ng segment. >> =A0 =A0 4.3: Since cwnd - pipe >=3D 1MSS, tcp tries to send one or more = segments. >> =A0 =A0 4.4: Use NextSeg() to find the packet to be sent >> >> Here, I think there is one minor issue in NextSeg(). >> When TCP checks if S5 can be sent with the rule (1) in NextSeg(), it >> fails. ( because (1.b) and (1.c) return false.) >> Rule (2) can be applicable "if there are available unsent data". But, >> let's think about the case where there's no available unsent data. >> Now, TCP is going to apply Rule (3) for S5, but again it fails ( >> because (1.b) returns false. ) >> Here, TCP cannot send any packets even though there is a chance to >> send a retransmit packet. >> >> To summarize, I think the logic in RFC3517 can stall in some >> situations even though there are packets can be sent. >> This might cause the lost of ack clocking and unnecessary timeouts. >> >> I think the solution would be simple. Don't apply (1.b) to the Rule >> (3) in NextSeg(). >> I mean, change Rule (3) in NextSeg() from >> >> =A0 =A0 =A0 =A0 =A0 If the conditions for rules (1) and (2) fail, but th= ere exists >> =A0 =A0 =A0 =A0 =A0 an unSACKed sequence number 'S3' that meets the crit= eria for >> =A0 =A0 =A0 =A0 =A0 detecting loss given in steps (1.a) and (1.b) above >> =A0 =A0 =A0 =A0 =A0 (specifically excluding step (1.c)) then one segment= of up to >> =A0 =A0 =A0 =A0 =A0 SMSS octets starting with S3 MAY be returned. >> >> To >> >> =A0 =A0 =A0 =A0 =A0 If the conditions for rules (1) and (2) fail, but th= ere exists >> =A0 =A0 =A0 =A0 =A0 an unSACKed sequence number 'S3' that meets the crit= eria for >> =A0 =A0 =A0 =A0 =A0 detecting loss given in steps (1.a) =A0above >> =A0 =A0 =A0 =A0 =A0 (specifically excluding step (1.b) and step (1.c)) t= hen one >> segment of up to >> =A0 =A0 =A0 =A0 =A0 SMSS octets starting with S3 MAY be returned. >> >> I might need more time to think about this, but I think removing (1.b) >> from (3) will not be very harmful. > > > > From lars.eggert@nokia.com Fri Mar 4 01:12:27 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E4023A68B3; Fri, 4 Mar 2011 01:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.762 X-Spam-Level: X-Spam-Status: No, score=-102.762 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sf88QV4-FRci; Fri, 4 Mar 2011 01:12:26 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 282633A6933; Fri, 4 Mar 2011 01:12:26 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p249DTQI001814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Mar 2011 11:13:31 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-8-947737992; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Fri, 4 Mar 2011 11:13:21 +0200 Message-Id: References: <20110216121501.9756.17896.idtracker@localhost> <11AE786E-F8C6-408E-9F1A-863BBFD0BC10@nokia.com> To: David Harrington X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Fri, 04 Mar 2011 11:13:27 +0200 (EET) X-Nokia-AV: Clean Cc: Christian Huitema , "ops-dir@ietf.org" , "tcpm@ietf.org Extensions" , "Scott O. Bradner" Subject: Re: [tcpm] I-D Action:draft-eggert-tcpm-historicize-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 09:12:27 -0000 --Apple-Mail-8-947737992 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, David & WG, Scott and Christian both suggested to remove RFC1263 from the I-D. If = you agree with this suggestion, I will make the change and resubmit. Thanks, Lars On 2011-2-17, at 19:43, Lars Eggert wrote: > ACK. >=20 > I'll leave it to David as the responsible AD to make a call here. As I = said, I have no issue removing 1263 from this doc if this is the = consensus. >=20 > Lars >=20 > On 2011-2-17, at 19:35, Christian Huitema wrote: >=20 >> I would suggest to leave 1623 alone for now. There may be a = rationale to downgrade it later -- or maybe not. In any case, that = rationale is not that it defines unused TCP extensions, and thus it does = not belong to the same batch. >>=20 >> -----Original Message----- >> From: Lars Eggert [mailto:lars.eggert@nokia.com]=20 >> Sent: Thursday, February 17, 2011 12:57 AM >> To: Christian Huitema >> Cc: tcpm@ietf.org Extensions; ops-dir@ietf.org; Scott O. Bradner >> Subject: Re: [tcpm] I-D Action:draft-eggert-tcpm-historicize-01.txt >>=20 >> Hi, >>=20 >> On 2011-2-17, at 9:00, Christian Huitema wrote: >>> I note that the list of RFC includes RFC 1263, "TCP Extensions = Considered Harmful." The purpose of the draft is to make some extensions = historic. Since RFC 1263 does not define any particular extension, I = don't see the point of including it. RFC 1263 is an informational RFC. = It provides advice on protocol design, and that advice appears to be = just as informational now as it was then. I don't see why we should = reclassify it. >>=20 >> it provides advice on *TCP* protocol design going forward, but the = community went the other way. I don't feel strongly about moving it to = Historic or not, but someone suggested it (see below). >>=20 >> Scott Bradner brought this up during his ops-dir review as well: >>=20 >>> On 2011-2-11, at 4:24, Scott O. Bradner wrote: >>>> I'm not sure why RFC 1263 "TCP Extensions Considered Harmful" = should >>>> be included in the list since it seems to me that message of the = RFC >>>> is still valid. But if it is to be included it seems like the >>>> "it is not used" general description does not apply to this RFC and = some >>>> specific text should be added to say why it should be made historic >>>=20 >>> good point. Someone (I can't remember who, might have been Craig = Partridge) suggested to include RFC1263 in this list because it argues = for an architectural approach which the subsequent TCP evolution with = its myriad of options did not follow. (RFC4614 also contains text along = those lines.) >>>=20 >>> I'm adding this text to my working copy: >>>=20 >>> ("TCP Extensions Considered Harmful") is = somewhat of a special case. Unlike the other RFCs made Historic by this = memo, it does not specify a TCP option that failed to see deployment, = but argued for a way to evolve TCP forward that the community did not = choose to follow. >>=20 >> Lars >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-8-947737992 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMwNDA5MTMyMVowIwYJKoZIhvcNAQkE MRYEFBq9z4oCALypgqBihn+GyDsmuIPcMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AHOGJ8jGI7ADlLpgV72MwBA7+OARH7HI9xZhA/Rrljivni26h0TQUz5BfihzrYwpFUwazZ5f0fH3 lYyUD730izrhDcoyn2XMuSM4ouYrDUn5fJsCx2a63CuA6dsV51YIYi+YCghcBk0PBto6Z3mY3m8x XTRZt+oxTfo6/EF7JEKpb0ITkgUZiUmDwSTSdcprNO0VjcUGtMrnGx6XoeJWAqNS/oSwX/av0uNY jlsAnZjYg5MW5acojyEx0v2K02nzjKKyxsZntkPp0QUL9uYx5HVRhOLPlUlLCEuG/J/IT1IeZmrf Th8f18Nq8ti+uJ88oKvvVyCTDZxb2Bp5kZnSinEAAAAAAAA= --Apple-Mail-8-947737992-- From ilpo.jarvinen@helsinki.fi Fri Mar 4 01:49:58 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2069B3A696F for ; Fri, 4 Mar 2011 01:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bON4H+LGRyML for ; Fri, 4 Mar 2011 01:49:57 -0800 (PST) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 429533A6882 for ; Fri, 4 Mar 2011 01:49:57 -0800 (PST) Received: from melkinpaasi.cs.helsinki.fi (melkinpaasi.cs.helsinki.fi [128.214.9.14]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 04 Mar 2011 11:51:04 +0200 id 0009C7FF.4D70B608.0000722D Date: Fri, 4 Mar 2011 11:51:04 +0200 (EET) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@melkinpaasi.cs.helsinki.fi To: Yoshifumi Nishida In-Reply-To: Message-ID: References: <20110303150923.BE30333A2632@lawyers.icir.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org, mallman@icir.org Subject: Re: [tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) ) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 09:49:58 -0000 On Thu, 3 Mar 2011, Yoshifumi Nishida wrote: > Hello Mark, Thanks for your response. > > The point you mentioned is exactly what I wanted to discuss. > I have thought several similar scenarios and here's my opinion on that. > > 1: As Richard already pointed out, this redundant transmission > happens even in NewReno, > since NewReno retransmits the first unacknowledged segment when > it receives a partial ACK. > > So, It's just as bad as NewReno but not worse than NewReno, > which might be mostly acceptable. > > 2: If the problem is the amount of unnecessary transmission, we have > several ways to mitigate this. > 2a) I believe we can presume the use of delayed ACK in most cases. > So, in your example, the amount of unnecessary > transmission will be 1/4 of the window. True. > 2b) We might be able to presume the use of DSACK, > Once the sender finds out spurious retransmission, it can > stop unnecessary transmission immediately. That will be only after all of the unnecessary retransmissions were made so it is of no use here. > 2c) I believe it's possible to implement a certain simple logic > to reduce the amount of unnecessary transmission. > For example, I think we can apply this special rule every > other time by having one flag in NextSeg(). I don't think your 2c) has any logical basis... this here is more or less just a tradeoff in a case where ambiguity exists. ...Instead the algorithm should try to break out from the ambiguities using something similar to FRTO xmit ordering (but that's hardly a thing that belongs to 3517bis now). Yet, in theory, the delayed ACK double cumulatives could be used as a flag to distinguish between rexmit/original data generated ACKs: ~"If more than the retransmitted one was cumulatively ACKed, do nothing." ...But that depends on the receiver doing delayed ACKs. -- i. From mallman@icir.org Fri Mar 4 05:16:06 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758FC3A694C for ; Fri, 4 Mar 2011 05:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lR-VnCYt1wC6 for ; Fri, 4 Mar 2011 05:16:05 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id B56753A68DB for ; Fri, 4 Mar 2011 05:16:05 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p24DHD6s029502; Fri, 4 Mar 2011 05:17:14 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 0283B33BB8C1; Fri, 4 Mar 2011 08:17:13 -0500 (EST) To: Yoshifumi Nishida From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: You MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma58966-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 04 Mar 2011 08:17:12 -0500 Sender: mallman@icir.org Message-Id: <20110304131713.0283B33BB8C1@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) ) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 13:16:06 -0000 ----------ma58966-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > So, It's just as bad as NewReno but not worse than NewReno, which > might be mostly acceptable. I understand the sentiment. But, lets be clear that both are suboptimal. > 2: If the problem is the amount of unnecessary transmission, we have > several ways to mitigate this. > 2a) I believe we can presume the use of delayed ACK in most cases. > So, in your example, the amount of unnecessary > transmission will be 1/4 of the window. Actually that isn't true. It probably is for NewReno, but RFC3517 tries quite hard to work based on the amount of data SACKed and ACKed and *not* the *number* of SACKs/ACKs that arrive. So, you can play through my scenario with delayed ACKs and you'll see that a cumack for two segments would open more room in the pipe than a cumack for one segment and so you'd see the same number of needless retransmits. Therefore, the claim of "just as bad as NewReno" is likely not right and RFC3517 without (1.b) in rule (3) is something like twice as bad. > 2b) We might be able to presume the use of DSACK, > Once the sender finds out spurious retransmission, it can > stop unnecessary transmission immediately. Look at my scenario. By the time the DSACK gets to the sender it has already strobed out all the unnecessary retransmits because the DSACK comes in the next RTT. This is the basic problem with DSACK. You can use it to figure out you have made a mistake after the fact, but you can make a bunch more mistakes before you find out because of the RTT lag. > 2c) I believe it's possible to implement a certain simple logic > to reduce the amount of unnecessary transmission. I am certainly willing to believe that there is additional complexity that could be added to address this case. The first question is whether the cost of the required complexity is worth the benefit it provides. The second question is whether the complexity interferes with the rest of the algorithm in ways that break it. allman ----------ma58966-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk1w5lgACgkQWyrrWs4yIs633gCgg5DebbufdNfy04b9+pVdXh51 ZwQAoIrLYoLAN4dGBmi+eRKN+9H4Pdmg =jSCo -----END PGP SIGNATURE----- ----------ma58966-1-- From rs@netapp.com Sat Mar 5 04:42:17 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7E563A68A2 for ; Sat, 5 Mar 2011 04:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzQPhdDvjjFS for ; Sat, 5 Mar 2011 04:42:16 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id ED6663A687F for ; Sat, 5 Mar 2011 04:42:15 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.62,268,1297065600"; d="scan'208";a="245263021" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 05 Mar 2011 04:43:23 -0800 Received: from amsrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p25ChPfM027312 for ; Sat, 5 Mar 2011 04:43:25 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 5 Mar 2011 13:43:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 5 Mar 2011 12:43:10 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0D32AFBF@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <20110303150923.BE30333A2632@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) ) Thread-Index: AcvZtRikdrtvLXqLRfygbh3iVfEJCwBfcJUQ References: <20110303150923.BE30333A2632@lawyers.icir.org> From: "Scheffenegger, Richard" To: X-OriginalArrivalTime: 05 Mar 2011 12:43:25.0412 (UTC) FILETIME=[EB623240:01CBDB32] Subject: Re: [tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) ) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 12:42:17 -0000 [hopefully this arrives at the list too... also expanded over the = private emails.] Mark, You and Ethan have clearly a point here. Do you see a way to address this? Ie. If RecoveryPoint is 10 in your = example, and loss of the last segment running up to the end of stream = would require a RTO with SACK, while not so with NewReno. In fact, NewReno would exhibit the same behavior (unnecessary = retransmitting up to 1/2 window on a reorder event > DupThresh). Thinking about the cost (latency of in-order delivered data on the = receiver side) of the RTO vs the cost of possibly retransmitting data = unnecessary (while reducing cwnd shortly before end of stream), I = believe the latter is less hard to the network, while the first can have = a more problematic impact on the timeliness of your application = (typically, the RTO is >> RTT)... (I think I have mentioned that some vendors appear to prefer NewReno = over SACK for latency sensitive applications/environments. Insofar they = appear to have choosen the lesser of the two bads for their = enironments.) OTOH, a more optimal approach could be to identify if the partial Ack 5 = was due to the retransmitted segment 1, or the original segment 1 - for = example by using timestamp information (akin to eifel detection). = Depending on the result, a partial Ack due to a delayed segment 1 could = be identified and addressed (similar to eifel response).... Would that be a workable solution for that scenario? Of course, TCP stacks that want to use the improved end-of-stream = behavior may only be allowed to do so, if the session has negotiated for = SACK+TS... In any case, at the very least, 3517bis should document this corner = case, albeit I would still think that SACK should not be less timely = under any circumstances than NewReno. But I would agree, that a proper = fix (as sketched above) is beyond the scope of 3517bis. (Actually, synergy between SACK and TS would allow improvements in other = areas as well). Best regards, Richard -----Original Message----- From: Mark Allman [mailto:mallman@icir.org]=20 Sent: Donnerstag, 03. M=E4rz 2011 16:09 To: Yoshifumi Nishida Cc: Scheffenegger, Richard; tcpm@ietf.org Subject: Re: [tcpm] An issue in RFC3517? (Re: end-of-stream loss = recovery (TCP SACK) )=20 Folks- > I've been thinking about the issue Richard brought up and I think it's = > valid and worth for discussion. I personally think this is a minor=20 > issue in RFC3517. (also in RFC3517bis) As part of thinking about 3517bis I came back to this yesterday and = asked Ethan about it again. Per his suggestion from a while back, and = since nobody else seems to have done so, we puzzled through this for a = bit and played around with various scenarios. Again illustrating how = subtle this stuff is we (really Ethan) have identified an issue. I am = leaving your email appended below because its a nice summary to remind = folks. The problematic scenario involves reordering, not loss. If you play out = a scenario where packets 1--10 are transmitted in order, but arrive at = the receiver as "2, 3, 4, 1, 5, 6, 7, 8, 9, 10" and there is no data = beyond 10 available. Packet 1 will be retransmitted needlessly because = of the reordering (in 3517, 3517bis and Richard's proposal). However, = in the proposal below that removes condition (1.b) from step (3) in NextSeg() the TCP will also needlessly retransmit packets 7--10 whereas 3517 and 3517bis will not. Basically, with the proposed change it looks = like this from the sender's perspective: snd 1--10, cwnd =3D 10 rcv ack=3D1, sack=3D{2-2} (via pkt 2) rcv ack=3D1, sack=3D{2-3} (via pkt 3) rcv ack=3D1, sack=3D{2-4} (via pkt 4) rexmt 1, cwnd =3D 5, pipe =3D 7 rcv ack=3D5 (via pkt 1-orig), pipe =3D 6 rcv ack=3D6 (via pkt 5), pipe =3D 5 rcv ack=3D7 (via pkt 6), pipe =3D 4 rexmt 7, pipe =3D 5 rcv ack=3D8 (via pkt 7), pipe =3D 3 rexmt 8, pipe =3D 4 rexmt 9, pipe =3D 5 rcv ack=3D9 (via pkt 8), pipe =3D 2 rexmt 10, pipe =3D 3 Instead of 1 needless retransmit we end up with half the window = needlessly retransmitted. (This holds I believe no matter how big the = window gets if the first packet is delayed to the 4th position. Different amounts of delay will clearly result in different scenarios.)=20 Of course, we have cut the sending rate (needlessly) and so in some = sense this is conservative in terms of the *amount* of traffic being = dumped into the network. However, in terms of *useful* traffic it is = clearly suboptimal. =20 So, there is a tradeoff here. In order to make loss recovery from the = tail of a window (when there is no further data to send) more timely we = aggravate the impact of reordering. (Note: This might not be the only issue. This is the first one we = tripped over.) allman > Let's say, we have a pair of SACK TCP sender and receiver and when=20 > cwnd=3D5, sender transmits S1, S2, S3 .. S5 packets. > Now, if we lost S1, S5, segments here, we will see the following = sequence. >=20 > 1: When S2 S3 S4 arrives at the receiver side, the receiver sends back = > dupacks with SACK info to the sender. > 2: When the sender receives the 3rd dupack, it retransmits S1 and=20 > enters loss recovery phase. > 3: When S1 arrives at the receiver side, the receiver sends back a=20 > cumulative ACK for S4. > 4: When the ACK for S4 arrives, the sender process this ACK by the=20 > following steps > 4.1: It's not greater than RecoveryPoint, so TCP cannot exit loss=20 > recovery phase yet. > 4.2: Use update() and setpipe() and find it has only 1 outstanding = segment. > 4.3: Since cwnd - pipe >=3D 1MSS, tcp tries to send one or more = segments. > 4.4: Use NextSeg() to find the packet to be sent >=20 > Here, I think there is one minor issue in NextSeg(). > When TCP checks if S5 can be sent with the rule (1) in NextSeg(), it=20 > fails. ( because (1.b) and (1.c) return false.) Rule (2) can be=20 > applicable "if there are available unsent data". But, let's think=20 > about the case where there's no available unsent data. > Now, TCP is going to apply Rule (3) for S5, but again it fails (=20 > because (1.b) returns false. ) Here, TCP cannot send any packets even=20 > though there is a chance to send a retransmit packet. >=20 > To summarize, I think the logic in RFC3517 can stall in some=20 > situations even though there are packets can be sent. > This might cause the lost of ack clocking and unnecessary timeouts. >=20 > I think the solution would be simple. Don't apply (1.b) to the Rule > (3) in NextSeg(). > I mean, change Rule (3) in NextSeg() from >=20 > If the conditions for rules (1) and (2) fail, but there = exists > an unSACKed sequence number 'S3' that meets the criteria for > detecting loss given in steps (1.a) and (1.b) above > (specifically excluding step (1.c)) then one segment of up = to > SMSS octets starting with S3 MAY be returned. >=20 > To >=20 > If the conditions for rules (1) and (2) fail, but there = exists > an unSACKed sequence number 'S3' that meets the criteria for > detecting loss given in steps (1.a) above > (specifically excluding step (1.b) and step (1.c)) then one=20 > segment of up to > SMSS octets starting with S3 MAY be returned. >=20 > I might need more time to think about this, but I think removing (1.b) = > from (3) will not be very harmful. From henk@ripe.net Fri Feb 25 01:37:47 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FF2A3A67E7; Fri, 25 Feb 2011 01:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id br-1Bg-Xf7Fz; Fri, 25 Feb 2011 01:37:42 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id E88FB3A6947; Fri, 25 Feb 2011 01:37:41 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Psu84-000387-IL; Fri, 25 Feb 2011 10:38:30 +0100 Received: from [193.0.21.124] (helo=guest133.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Psu84-0001tX-4O; Fri, 25 Feb 2011 10:38:28 +0100 Message-ID: <4D677893.2050200@ripe.net> Date: Fri, 25 Feb 2011 10:38:27 +0100 From: Henk Uijterwaal Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: IETF IPPM WG References: <4C7CBBFD.1030402@ripe.net> In-Reply-To: <4C7CBBFD.1030402@ripe.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: e0cdef1f45f89a40ad608d255b27e7d57ff7894f30da3286ec7367e0edd6838f X-Mailman-Approved-At: Sun, 06 Mar 2011 18:22:27 -0800 Cc: tcpm@ietf.org Subject: [tcpm] WGLC for draft-ietf-ippm-tcp-throughput-tm-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 09:37:47 -0000 IPPM WG, This is a Working Group Last Call for the draft: TCP Throughput Testing Methodology draft-ietf-ippm-tcp-throughput-tm-12.txt The -07 version of this document has been submitted to IESG last October. Since then, there have been several reviews and a lot of text has been changed. Before proceeding, we think it is good that the WG looks at this document again. The TCPM WG is cc'd as some members of this group have been involved in the reviews. Please review the draft and raise any issues by Monday, March 28, 2011, 8:00 UTC. An URL for the draft is: http://www.ietf.org/id/draft-ietf-ippm-tcp-throughput-tm-12.txt (The date is intentional, if there are issues that require face-2-face discussion, we can do this in Prague). Matt & Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From Richard.Scheffenegger@netapp.com Thu Mar 3 23:42:15 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48A8F3A6955 for ; Thu, 3 Mar 2011 23:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ch3Djrm3KV37 for ; Thu, 3 Mar 2011 23:42:14 -0800 (PST) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 754F23A691F for ; Thu, 3 Mar 2011 23:42:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.62,263,1297065600"; d="scan'208";a="244914590" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 03 Mar 2011 23:43:21 -0800 Received: from ldcrsexc2-prd.hq.netapp.com (ldcrsexc2-prd.hq.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p247hKXL005199; Thu, 3 Mar 2011 23:43:21 -0800 (PST) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Mar 2011 07:43:20 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Mar 2011 07:43:05 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0D32AAA6@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <20110303150923.BE30333A2632@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) ) Thread-Index: AcvZtRikdrtvLXqLRfygbh3iVfEJCwAipBYw References: <20110303150923.BE30333A2632@lawyers.icir.org> From: "Scheffenegger, Richard" To: , "Yoshifumi Nishida" X-OriginalArrivalTime: 04 Mar 2011 07:43:20.0643 (UTC) FILETIME=[D54AB930:01CBDA3F] X-Mailman-Approved-At: Sun, 06 Mar 2011 18:22:26 -0800 Cc: tcpm@ietf.org Subject: Re: [tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) ) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 07:42:15 -0000 Mark, You and ethan have clearly a point here. Do you see a way to address this? Ie. If recoverypoint is 10 in your = example, and loss of the last segement running up to the end of stream = would require a rto with sack, while not so with newreno. In fact, newreno would exhibit the same behaviour (unnecessary = retransmitting up to 1/2 window on a reorder event > dupthresh). Thinking about the cost (latency of in-order delivered data on the rx = side) of the rton vs the cost of possibly retransmitting data = unnecessary (and reducing cwnd shortly before end of stream = unnecessary), I beliefe the latter is less hard to the network... (I think I have mentioned that some vendors appear to prefer newreno = over sack for latency sensitive applications/environments. Insofar they = appear to have choosen the lesser of the two bads for their = environments.) Otoh, a more optimal approach could be to identify if the cumulative ack = 5 was due to the retransmitted seg 1, or the original seg 1 - I.e. By = using timestamp information. Depending on the result, a cumack due to = delayed seg1 could be identified and adressed (similar to eifel = detection/response).... Would that be a workable solution for that scenario? Of course, tcp stacks that want to use the improved end-of-stream = behavior may only be allowed to do so, if the session has negotiated for = sack+ts... (Actually, synergy between sack and ts would allow improvements in other = areas as well). Best regards, Richard -----Original Message----- From: Mark Allman [mailto:mallman@icir.org]=20 Sent: Donnerstag, 03. M=E4rz 2011 16:09 To: Yoshifumi Nishida Cc: Scheffenegger, Richard; tcpm@ietf.org Subject: Re: [tcpm] An issue in RFC3517? (Re: end-of-stream loss = recovery (TCP SACK) )=20 Folks- > I've been thinking about the issue Richard brought up and I think it's = > valid and worth for discussion. I personally think this is a minor=20 > issue in RFC3517. (also in RFC3517bis) As part of thinking about 3517bis I came back to this yesterday and = asked Ethan about it again. Per his suggestion from a while back, and = since nobody else seems to have done so, we puzzled through this for a = bit and played around with various scenarios. Again illustrating how = subtle this stuff is we (really Ethan) have identified an issue. I am = leaving your email appended below because its a nice summary to remind = folks. The problematic scenario involves reordering, not loss. If you play out = a scenario where packets 1--10 are transmitted in order, but arrive at = the receiver as "2, 3, 4, 1, 5, 6, 7, 8, 9, 10" and there is no data = beyond 10 available. Packet 1 will be retransmitted needlessly because = of the reordering (in 3517, 3517bis and Richard's proposal). However, = in the proposal below that removes condition (1.b) from step (3) in NextSeg() the TCP will also needlessly retransmit packets 7--10 whereas 3517 and 3517bis will not. Basically, with the proposed change it looks = like this from the sender's perspective: snd 1--10, cwnd =3D 10 rcv ack=3D1, sack=3D{2-2} (via pkt 2) rcv ack=3D1, sack=3D{2-3} (via pkt 3) rcv ack=3D1, sack=3D{2-4} (via pkt 4) rexmt 1, cwnd =3D 5, pipe =3D 7 rcv ack=3D5 (via pkt 1-orig), pipe =3D 6 rcv ack=3D6 (via pkt 5), pipe =3D 5 rcv ack=3D7 (via pkt 6), pipe =3D 4 rexmt 7, pipe =3D 5 rcv ack=3D8 (via pkt 7), pipe =3D 3 rexmt 8, pipe =3D 4 rexmt 9, pipe =3D 5 rcv ack=3D9 (via pkt 8), pipe =3D 2 rexmt 10, pipe =3D 3 Instead of 1 needless retransmit we end up with half the window = needlessly retransmitted. (This holds I believe no matter how big the = window gets if the first packet is delayed to the 4th position. Different amounts of delay will clearly result in different scenarios.)=20 Of course, we have cut the sending rate (needlessly) and so in some = sense this is conservative in terms of the *amount* of traffic being = dumped into the network. However, in terms of *useful* traffic it is = clearly suboptimal. =20 So, there is a tradeoff here. In order to make loss recovery from the = tail of a window (when there is no further data to send) more timely we = aggravate the impact of reordering. (Note: This might not be the only issue. This is the first one we = tripped over.) allman > Let's say, we have a pair of SACK TCP sender and receiver and when=20 > cwnd=3D5, sender transmits S1, S2, S3 .. S5 packets. > Now, if we lost S1, S5, segments here, we will see the following = sequence. >=20 > 1: When S2 S3 S4 arrives at the receiver side, the receiver sends back = > dupacks with SACK info to the sender. > 2: When the sender receives the 3rd dupack, it retransmits S1 and=20 > enters loss recovery phase. > 3: When S1 arrives at the receiver side, the receiver sends back a=20 > cumulative ACK for S4. > 4: When the ACK for S4 arrives, the sender process this ACK by the=20 > following steps > 4.1: It's not greater than RecoveryPoint, so TCP cannot exit loss=20 > recovery phase yet. > 4.2: Use update() and setpipe() and find it has only 1 outstanding = segment. > 4.3: Since cwnd - pipe >=3D 1MSS, tcp tries to send one or more = segments. > 4.4: Use NextSeg() to find the packet to be sent >=20 > Here, I think there is one minor issue in NextSeg(). > When TCP checks if S5 can be sent with the rule (1) in NextSeg(), it=20 > fails. ( because (1.b) and (1.c) return false.) Rule (2) can be=20 > applicable "if there are available unsent data". But, let's think=20 > about the case where there's no available unsent data. > Now, TCP is going to apply Rule (3) for S5, but again it fails (=20 > because (1.b) returns false. ) Here, TCP cannot send any packets even=20 > though there is a chance to send a retransmit packet. >=20 > To summarize, I think the logic in RFC3517 can stall in some=20 > situations even though there are packets can be sent. > This might cause the lost of ack clocking and unnecessary timeouts. >=20 > I think the solution would be simple. Don't apply (1.b) to the Rule > (3) in NextSeg(). > I mean, change Rule (3) in NextSeg() from >=20 > If the conditions for rules (1) and (2) fail, but there = exists > an unSACKed sequence number 'S3' that meets the criteria for > detecting loss given in steps (1.a) and (1.b) above > (specifically excluding step (1.c)) then one segment of up = to > SMSS octets starting with S3 MAY be returned. >=20 > To >=20 > If the conditions for rules (1) and (2) fail, but there = exists > an unSACKed sequence number 'S3' that meets the criteria for > detecting loss given in steps (1.a) above > (specifically excluding step (1.b) and step (1.c)) then one=20 > segment of up to > SMSS octets starting with S3 MAY be returned. >=20 > I might need more time to think about this, but I think removing (1.b) = > from (3) will not be very harmful. From yoshifumi.nishida@gmail.com Sun Mar 6 19:24:29 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65EF13A68BA for ; Sun, 6 Mar 2011 19:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnSItgMDhcFV for ; Sun, 6 Mar 2011 19:24:28 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 693F83A67CC for ; Sun, 6 Mar 2011 19:24:28 -0800 (PST) Received: by gxk5 with SMTP id 5so1877077gxk.31 for ; Sun, 06 Mar 2011 19:25:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QYfZTlvkMVcjkc6N6ko3qRUX7iqGGnVwUz4RW9AvPhE=; b=enwi7W/SjovIgxeBq+K1mLY0CAys5DpI6EWpTKHQDmkpEIziuNoXAB5rs0mrZbp50P yfAs3KTRsgeW7CgWJqDMJCrAi/MFSmktCKdtP6hxnr37maS7TnKAv6WqBgRX3uwssQKJ oJ+MwLgtuQII6ff/PL47FocRaKENdairihw04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=prMMTPXiVkzRM5vzaPltKh9za52BZ0yK9aia5AUfdlk2POKNKxVaWirJ8OzL8ZodeL zNfPnfkawHA2G/6s7wdmgz+IWHKhacea1ld0jtOhhT5/QU6OHYonhbKGi/QQGzs5tERT MlzwgeSjNmZHKpfFrATjjmpUlzs+V7Xj3tQ4M= MIME-Version: 1.0 Received: by 10.146.59.21 with SMTP id h21mr1265622yaa.3.1299468340729; Sun, 06 Mar 2011 19:25:40 -0800 (PST) Sender: yoshifumi.nishida@gmail.com Received: by 10.147.33.9 with HTTP; Sun, 6 Mar 2011 19:25:40 -0800 (PST) In-Reply-To: <20110304131713.0283B33BB8C1@lawyers.icir.org> References: <20110304131713.0283B33BB8C1@lawyers.icir.org> Date: Sun, 6 Mar 2011 19:25:40 -0800 X-Google-Sender-Auth: 6UNANym7-S99F8hWlqh1pvscsTU Message-ID: From: Yoshifumi Nishida To: mallman@icir.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org Subject: Re: [tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) ) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 03:24:29 -0000 Hello Mark, Thanks for your insightful comments. The points you mentioned are quite right and thanks for pointing out my misunderstanding. I also agree with you that there'll be additional complexity to address this issue, but I still personally think there might be a certain good balance between efficiency and complexity. I'll need to think about it more carefully and hopefully get back soon. I really appreciate Ethan and you spending some time to check this. Thank you so much. -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/3/4 Mark Allman : > >> So, It's just as bad as NewReno but not worse than NewReno, which >> might be mostly acceptable. > > I understand the sentiment. =A0But, lets be clear that both are > suboptimal. > >> =A0 2: If the problem is the amount of unnecessary transmission, we have >> several ways to mitigate this. >> =A0 =A0 =A0 2a) I believe we can presume the use of delayed ACK in most = cases. >> =A0 =A0 =A0 =A0 =A0 =A0 So, in your example, the amount of unnecessary >> transmission will be 1/4 of the window. > > Actually that isn't true. =A0It probably is for NewReno, but RFC3517 trie= s > quite hard to work based on the amount of data SACKed and ACKed and > *not* the *number* of SACKs/ACKs that arrive. =A0So, you can play through > my scenario with delayed ACKs and you'll see that a cumack for two > segments would open more room in the pipe than a cumack for one segment > and so you'd see the same number of needless retransmits. > > Therefore, the claim of "just as bad as NewReno" is likely not right and > RFC3517 without (1.b) in rule (3) is something like twice as bad. > >> =A0 =A0 =A0 2b) We might be able to presume the use of DSACK, >> =A0 =A0 =A0 =A0 =A0 =A0 Once the sender finds out spurious retransmissio= n, it can >> stop unnecessary transmission immediately. > > Look at my scenario. =A0By the time the DSACK gets to the sender it has > already strobed out all the unnecessary retransmits because the DSACK > comes in the next RTT. =A0This is the basic problem with DSACK. =A0You ca= n > use it to figure out you have made a mistake after the fact, but you can > make a bunch more mistakes before you find out because of the RTT lag. > >> =A0 =A0 =A0 2c) =A0I believe it's possible to implement a certain simple= logic >> to reduce the amount of unnecessary transmission. > > I am certainly willing to believe that there is additional complexity > that could be added to address this case. =A0The first question is whethe= r > the cost of the required complexity is worth the benefit it provides. > The second question is whether the complexity interferes with the rest > of the algorithm in ways that break it. > > allman > > > > From mallman@icir.org Mon Mar 7 06:28:39 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4960A3A6962 for ; Mon, 7 Mar 2011 06:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7Anzcn1F4SB for ; Mon, 7 Mar 2011 06:28:38 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 929D13A67CF for ; Mon, 7 Mar 2011 06:28:38 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p27ETpte006236 for ; Mon, 7 Mar 2011 06:29:52 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B4B093436C51 for ; Mon, 7 Mar 2011 09:29:51 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: It's Still Rock and Roll to Me MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma60383-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 07 Mar 2011 09:29:51 -0500 Sender: mallman@icir.org Message-Id: <20110307142951.B4B093436C51@lawyers.icir.org> Subject: [tcpm] new ID on RTO considerations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 14:28:39 -0000 ----------ma60383-1 Content-Type: text/plain Content-Disposition: inline Folks- For a while I have been thinking maybe what we need is some high-level guidance on the RTO and to then leave it at that instead of worrying about nitty-gritty specifics that really don't much matter. This has bubbled up to the top of my brain recently based on a few different conversations. So, last week I spent a little time bloviating into an emacs buffer. See draft-allman-tcpm-rto-consider-00.txt . Its rough, but I hope gets the idea across. I have no idea if this is something the WG might want to pursue, but feedback is certainly welcome. allman ----------ma60383-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk10698ACgkQWyrrWs4yIs4lyQCeP3dhFP+0iJBOyC09w4mjy2j6 k/kAn33q0C4VbaN4YdFbkfvzzA01X+h7 =jBJs -----END PGP SIGNATURE----- ----------ma60383-1-- From ycheng@google.com Tue Mar 8 16:20:15 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2083A67D2 for ; Tue, 8 Mar 2011 16:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.572 X-Spam-Level: X-Spam-Status: No, score=-104.572 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, DRUG_DOSAGE=1.623, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O17sfqaKZF-6 for ; Tue, 8 Mar 2011 16:20:13 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 080A43A67EE for ; Tue, 8 Mar 2011 16:20:12 -0800 (PST) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p290LSMT003294 for ; Tue, 8 Mar 2011 16:21:28 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299630088; bh=E89PgsqnN0qVuiPTFstWqJljfYU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=wGspwrqIlK+uXIqxxnZg5B9FBlxH0xJvz+hYkmB7+ldE/aCVZM+HzlJ1MP9bZrXoF rq7Y7siD5bEfZgO+s1d9Q== Received: from gyf3 (gyf3.prod.google.com [10.243.50.67]) by wpaz37.hot.corp.google.com with ESMTP id p290K2n5008035 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 8 Mar 2011 16:21:27 -0800 Received: by gyf3 with SMTP id 3so7532gyf.1 for ; Tue, 08 Mar 2011 16:21:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0UPzrT2bLH4BFOhRCdTvTnJ02p88Loir+yLcDuaTmls=; b=s0+QzQcSEBErpZuWjjuO1uiT7REDw8sO4NBEcbVNegLVpGdtcKv09iImGsJNX5P0MV zQXb34r34qkhTxQprF/A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=XNKlT9FGrheZcl1fgu6S6PbXJZ+x4sVHSVknrkXtBUppTy8f32ph4Z4yZNWcTu73SL e4JTSRkuhbfiumOXTWKQ== Received: by 10.90.24.40 with SMTP id 40mr7822483agx.109.1299630085132; Tue, 08 Mar 2011 16:21:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.42.34 with HTTP; Tue, 8 Mar 2011 16:21:05 -0800 (PST) In-Reply-To: <20110307142951.B4B093436C51@lawyers.icir.org> References: <20110307142951.B4B093436C51@lawyers.icir.org> From: Yuchung Cheng Date: Tue, 8 Mar 2011 16:21:05 -0800 Message-ID: To: mallman@icir.org Content-Type: multipart/alternative; boundary=001636283cf49050d2049e01b54a X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] new ID on RTO considerations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 00:20:15 -0000 --001636283cf49050d2049e01b54a Content-Type: text/plain; charset=ISO-8859-1 I like this draft but the MUST on exp backoff may be too strict. Research study has argued the exp-backoff is not needed. http://blue.cs.northwestern.edu/~akm175/docs/extr.pdf In practice, Linux implements TCP thin-stream that does linear-backoff to improve online game performance (by default off) http://heim.ifi.uio.no/paalh/publications/files/lcn08-thin.pdf Yuchung On Mon, Mar 7, 2011 at 6:29 AM, Mark Allman wrote: > > Folks- > > For a while I have been thinking maybe what we need is some high-level > guidance on the RTO and to then leave it at that instead of worrying > about nitty-gritty specifics that really don't much matter. This has > bubbled up to the top of my brain recently based on a few different > conversations. So, last week I spent a little time bloviating into an > emacs buffer. See draft-allman-tcpm-rto-consider-00.txt . Its rough, > but I hope gets the idea across. > > I have no idea if this is something the WG might want to pursue, but > feedback is certainly welcome. > > allman > > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > --001636283cf49050d2049e01b54a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I like this draft but the MUST on exp backoff may be too strict.
=

Research study has argued the exp-backoff is not needed= .
http= ://blue.cs.northwestern.edu/~akm175/docs/extr.pdf

In practice, Linux implements TCP thin-stream that does line= ar-backoff to improve online game performance (by default off)

Yuchung


On Mon,= Mar 7, 2011 at 6:29 AM, Mark Allman <mallman@icir.org> wrote:

Folks-

For a while I have been thinking maybe what we need is some high-level
guidance on the RTO and to then leave it at that instead of worrying
about nitty-gritty specifics that really don't much matter. =A0This has=
bubbled up to the top of my brain recently based on a few different
conversations. =A0So, last week I spent a little time bloviating into an emacs buffer. =A0See draft-allman-tcpm-rto-consider-00.txt . =A0Its rough,<= br> but I hope gets the idea across.

I have no idea if this is something the WG might want to pursue, but
feedback is certainly welcome.

allman






_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm


--001636283cf49050d2049e01b54a-- From mallman@icir.org Wed Mar 9 08:02:46 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 331F73A69F1 for ; Wed, 9 Mar 2011 08:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.787 X-Spam-Level: X-Spam-Status: No, score=-105.787 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_00=-2.599, DRUG_DOSAGE=1.623, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIncx-s1uWCQ for ; Wed, 9 Mar 2011 08:02:45 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id E2E753A6992 for ; Wed, 9 Mar 2011 08:02:44 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p29G3uhJ027279; Wed, 9 Mar 2011 08:03:56 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 3C7FE34BC349; Wed, 9 Mar 2011 11:03:56 -0500 (EST) To: Yuchung Cheng From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Centerfold MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma42219-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 09 Mar 2011 11:03:56 -0500 Sender: mallman@icir.org Message-Id: <20110309160356.3C7FE34BC349@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] new ID on RTO considerations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 16:02:46 -0000 ----------ma42219-1 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > I like this draft but the MUST on exp backoff may be too strict. >=20 > Research study has argued the exp-backoff is not needed. > http://blue.cs.northwestern.edu/~akm175/docs/extr.pdf >=20 > In practice, Linux implements TCP thin-stream that does linear-backoff to > improve online game performance (by default off) > http://heim.ifi.uio.no/paalh/publications/files/lcn08-thin.pdf I am aware of the first, but not the second. I glanced through it and will endeavor to look into it further. However, I'll note that I am disinclined to remove exponential backoff From=20the guidelines based on a couple of simulation / testbed studies no matter what they say. It seems that we'd want to be quite careful before we decided that was not required as that seems like our ultimate backstop. Plus, ... its hard to imagine that backoff really hurts in some meaningful way. Once you have RTOed twice your performance is likely gone. And, you have had multiple indications the network is congested. So, its hard for me to buy the removal of this. And, especially so in the absence of any sort of empirical understanding. allman ----------ma42219-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk13pOwACgkQWyrrWs4yIs4WZwCfaCIWB+i0ZBRuGzrPOfOKrrLC qPQAmwXyG/AOr4Vh+Cn5YJKDjk4xEM0x =5RDw -----END PGP SIGNATURE----- ----------ma42219-1-- From ycheng@google.com Fri Mar 11 11:04:01 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01B963A698F for ; Fri, 11 Mar 2011 11:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.311 X-Spam-Level: X-Spam-Status: No, score=-105.311 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoKRLhSswT0Z for ; Fri, 11 Mar 2011 11:04:00 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id EA6CE3A6966 for ; Fri, 11 Mar 2011 11:03:59 -0800 (PST) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p2BJ5JfE028820 for ; Fri, 11 Mar 2011 11:05:19 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1299870319; bh=K6HCq9ZjETjk5Q7jLlQJOLaZeME=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=f+Kg9eOmC+cnNLLOUCpgKrWYQG0ykLrCs8O/Q5nJUylWHgy11vDSjBrd0/uSrEsuR n4Tc5biib3hUsx5go7tSg== Received: from vxc38 (vxc38.prod.google.com [10.241.33.166]) by wpaz1.hot.corp.google.com with ESMTP id p2BJ5Imt002161 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 11 Mar 2011 11:05:18 -0800 Received: by vxc38 with SMTP id 38so3558367vxc.0 for ; Fri, 11 Mar 2011 11:05:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=z6lecXu2emrGECwEgJhn+ZCQTJpV7z3VtvntjLnDyt4=; b=jpqoI+4sfZt8jTNjwRisFGiph5w2fxtt2SnLM8dVsgpptjWuC7S4yG6eEIZ3DjeIcg H1q7kR6cjlPZOl3vJ19w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Ws9lCtnP5vcy7RaZAV8ZwxCbfEqQHQkWaOsRaXos0XlCc1tCNfEp/Q2gv4bvUXH/Fz P16yqtrt3EGQdKE8po9w== Received: by 10.52.0.43 with SMTP id 11mr3446363vdb.283.1299870317788; Fri, 11 Mar 2011 11:05:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.16.148 with HTTP; Fri, 11 Mar 2011 11:04:57 -0800 (PST) In-Reply-To: <20110308004501.27770.44908.idtracker@localhost> References: <20110308004501.27770.44908.idtracker@localhost> From: Yuchung Cheng Date: Fri, 11 Mar 2011 11:04:57 -0800 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary=20cf30549f798bc149049e39a4aa X-System-Of-Record: true Cc: Mike Belshe , Sivasankar Radhakrishnan , Arvind Jain Subject: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 19:04:01 -0000 --20cf30549f798bc149049e39a4aa Content-Type: text/plain; charset=ISO-8859-1 Hi folks, We are proposing a new draft called TCP Fast Open (TFO) which allows data exchange to begin in TCP handshake to improve performance. We would like to gather some comments before we present it in the next tcpm meeting in Prague. The presentation will also include some performance numbers based on our beta implementation in Linux and the Chrome browser. Thanks, Yuchung ---------- Forwarded message ---------- From: Date: Mon, Mar 7, 2011 at 4:45 PM Subject: I-D Action:draft-cheng-tcpm-fastopen-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : TCP Fast Open Author(s) : Y. Cheng, et al. Filename : draft-cheng-tcpm-fastopen-00.txt Pages : 17 Date : 2011-03-07 TCP Fast Open (TFO) allows data to be carried in the SYN or SYN-ACK packets and consumed by the receiving end during the initial connection handshake, thus providing a saving of up to one full round trip time (RTT) compared to standard TCP requiring a three-way handshake (3WHS) to complete before data can be exchanged. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cheng-tcpm-fastopen-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --20cf30549f798bc149049e39a4aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi folks,

We are proposing a new draft called= TCP Fast Open (TFO) which allows data exchange to begin in TCP handshake t= o improve performance.

We would like to gather som= e comments before we present it in the next tcpm meeting in Prague. The pre= sentation will also include some performance numbers based on our beta impl= ementation in Linux and the Chrome browser.

Thanks,

Yuchung

=
---------- Forwarded message ----------
From: <Internet-Drafts@ietf.org>
Date: Mon, Mar 7, 2011 at 4:45 PM
Subject: I-D Action:draft-cheng-tcpm-f= astopen-00.txt
To: i-d-announce= @ietf.org


A New Internet-Draft is available from the on-line= Internet-Drafts directories.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : TCP Fast Open
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Y. Cheng, et al.
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-cheng-tcpm-fastopen-00.txt<= br> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 17
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-03-07

TCP Fast Open (TFO) allows data to be carried in the SYN or SYN-ACK
packets and consumed by the receiving end during the initial
connection handshake, thus providing a saving of up to one full round
trip time (RTT) compared to standard TCP requiring a three-way
handshake (3WHS) to complete before data can be exchanged.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-cheng-tcp= m-fastopen-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--20cf30549f798bc149049e39a4aa-- From lars.eggert@nokia.com Sat Mar 12 00:10:02 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 051013A68D3 for ; Sat, 12 Mar 2011 00:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.779 X-Spam-Level: X-Spam-Status: No, score=-102.779 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfER+XGrgRCX for ; Sat, 12 Mar 2011 00:10:01 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id F23EF3A68E8 for ; Sat, 12 Mar 2011 00:10:00 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2C8BD7c014389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Mar 2011 10:11:15 +0200 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97 at fit.nokia.com Content-Type: multipart/signed; boundary=Apple-Mail-35--512286538; protocol="application/pkcs7-signature"; micalg=sha1 Date: Sat, 12 Mar 2011 10:11:00 +0200 References: <6210AF7E-3EB3-4199-A87B-A54B0F73A106@gmail.com> To: "tcpm@ietf.org Extensions" , "iccrg@cs.ucl.ac.uk list" Message-Id: <2231D7DC-D58A-41F8-8A06-05FF4EEA0EA5@nokia.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Sat, 12 Mar 2011 10:11:05 +0200 (EET) X-Nokia-AV: Clean Subject: [tcpm] Fwd: [Bloat] Taxonomy of various sender-side TCPs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 08:10:02 -0000 --Apple-Mail-35--512286538 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI, there is an active thread on the bufferbloat list in response to = this email that some of you might want to be aware of or join. Begin forwarded message: > From: Jonathan Morton > Date: March 11, 2011 9:24:33 GMT+02:00 > To: > Subject: [Bloat] Taxonomy of various sender-side TCPs >=20 > There's a lot of literature about how various TCP congestion-control = algorithms compare to each other, but there's not much in the way of = 10,000 foot overviews. So this is an attempt to bring the most relevant = data into one place. >=20 > I've sorted some common TCPs into groups in roughly ascending order of = aggressiveness in the face of congestion, and considered how they might = react to the introduction of ECN at the bottleneck. >=20 > 1: Vegas. > Strategy: Fill the pipe, not the buffers. > Reaction to congestion: Backs off until RTT approaches baseline, ie. = buffers empty. > Probable reaction to 1% ECN marking: Very little (but it doesn't need = to). >=20 > 2: Illinois, Compound. > Strategy: Fill the pipe quickly, then probe the buffer slowly to = avoid being outcompeted. > Reaction to congestion: Backs off firmly on packet loss, then quickly = re-probes for the pipe. > Probable reaction to 1% ECN marking: Window should stabilise near = pipe length. >=20 > 3: Reno (and subtle variations thereof). > Strategy: Avoid congestion collapse in a simple, standardisable way. > Reaction to congestion: Halves the window on packet loss. > Probable reaction to 1% ECN marking: Window should stabilise near 100 = packets. >=20 > 4: Veno, Westwood+. > Strategy: Distinguish congestion loss from random channel loss. > Reaction to congestion: Identical to Reno. > Probable reaction to 1% ECN marking: Identical to Reno. >=20 > 5: CUBIC. > Strategy: Fill pipe and all buffers to capacity. This is the most = aggressive widely-deployed TCP. > Reaction to congestion: On packet loss, quickly re-probes for buffer = capacity. > Probable reaction to 1% ECN marking: UNKNOWN. >=20 > Currently, CUBIC is the default TCP send-side algorithm in Linux. It = seems likely that it will react correctly to ECN marking, but that a = higher rate of marking may be needed to bring it down to a given = buffering level. =46rom what I've read, SFB should be able to probe for = the correct marking rate on a per-flow basis, which is nice. >=20 > On the subject of ECN, my impression is that YouTube currently doesn't = enable it, but a one-man company I recently downloaded some stuff from = does. I wonder if there's any reliable data on how many of the most = popular sites enable ECN if you ask for it. Personally, I think IPv6 = and ECN should probably go together - v6 gear is new or upgraded anyway = so there shouldn't be any legacy problems. >=20 > - Jonathan >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --Apple-Mail-35--512286538 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMxMjA4MTEwMFowIwYJKoZIhvcNAQkE MRYEFABRAwFc4xwr4IVNLf2rzYeA2BauMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB ABu1cx4CZ58CYGAWgsNYFYzOGzNkklgYMJ6mTEafwllBcpCWtMzNb7iQOIK/SFR3aY8zhlOuCFYc 365q+2R6m0HmpohIFNWGJpzBFtematj/uOroSQaCz6CuCEkcT6LSLHuawca+NIJVgdewVVtjXUDM JxAnLVL9PGReLlKI1PDPjkK9q8FsUbjC6bGC/raWm8OOb04/mlFKMKIOqrFj3Ctw4wbqDgN2UcIu ZbN9ipdO8G8UAEyZsJwNfpYh5W3ov1CbN2coSRV+7dhGt4kYH3gZnyTCPGSDUjzdaWllFEHQSSPo FrrhmREMPssGWsGFMTNKA2WcTSuaHQshP/p0YngAAAAAAAA= --Apple-Mail-35--512286538-- From rs@netapp.com Mon Mar 14 04:14:24 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36D33A6C74 for ; Mon, 14 Mar 2011 04:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iA+lUJY4Plp for ; Mon, 14 Mar 2011 04:14:18 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id D02E83A6B14 for ; Mon, 14 Mar 2011 04:14:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.62,315,1297065600"; d="scan'208,217";a="245620945" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 14 Mar 2011 04:15:34 -0700 Received: from amsrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p2EBFYAd027597; Mon, 14 Mar 2011 04:15:34 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Mar 2011 12:15:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE239.22AF8C49" Date: Mon, 14 Mar 2011 11:15:19 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0D4F4DE1@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt Thread-Index: AcvgH0bRmQu707NkRB2i8FQVLY3o3QCGIXSw References: <20110308004501.27770.44908.idtracker@localhost> From: "Scheffenegger, Richard" To: "Yuchung Cheng" , X-OriginalArrivalTime: 14 Mar 2011 11:15:34.0842 (UTC) FILETIME=[2398C9A0:01CBE239] Cc: Arvind Jain , Mike Belshe , Sivasankar Radhakrishnan Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 11:14:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE239.22AF8C49 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Yuchung, =20 your proposal will only address new tcp sessions preceeded by one = "normal" 3WHS session setup.=20 =20 In the draft, you mention that Chrome keeps persistent connections for = up to 4 min, while 35% of the requests are made using new sessions; Now = I wonder, what fraction of these new sessions are set up towards a = server, where the client already had an earlier normal session (or, what = is the fraction of persistent connections, that get disconnected within = that 4 min timeout due to external reasons such as a NAT gateways = running out of resources, or into a timeout...) =20 Because that 35% value above appears to throw genuinely "new" sessions = (new sites) and "lost" sessions (timed out, reset by intermediate device = or server etc) to a known host into the same bucket - unless the wording = around there is misleading me J =20 =20 (Since I know how you value even small sub-1% improvements, I do see how = this can help you, but I'm wondering if the complexity is worthwhile for = a generic tcp stack that deals mostly with non-http'ish traffic). =20 Best regards,=20 =20 Richard Scheffenegger =20 From: Yuchung Cheng [mailto:ycheng@google.com]=20 Sent: Freitag, 11. M=E4rz 2011 20:05 To: tcpm@ietf.org Extensions Cc: Mike Belshe; Sivasankar Radhakrishnan; Arvind Jain Subject: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt =20 Hi folks, =20 We are proposing a new draft called TCP Fast Open (TFO) which allows = data exchange to begin in TCP handshake to improve performance. =20 We would like to gather some comments before we present it in the next = tcpm meeting in Prague. The presentation will also include some = performance numbers based on our beta implementation in Linux and the = Chrome browser. =20 Thanks, =20 Yuchung =20 ---------- Forwarded message ---------- From: Date: Mon, Mar 7, 2011 at 4:45 PM Subject: I-D Action:draft-cheng-tcpm-fastopen-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : TCP Fast Open Author(s) : Y. Cheng, et al. Filename : draft-cheng-tcpm-fastopen-00.txt Pages : 17 Date : 2011-03-07 TCP Fast Open (TFO) allows data to be carried in the SYN or SYN-ACK packets and consumed by the receiving end during the initial connection handshake, thus providing a saving of up to one full round trip time (RTT) compared to standard TCP requiring a three-way handshake (3WHS) to complete before data can be exchanged. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cheng-tcpm-fastopen-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft = = directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =20 ------_=_NextPart_001_01CBE239.22AF8C49 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Yuchung,

 

your proposal will only address new tcp sessions preceeded by one = “normal” 3WHS session setup.

 

In the draft, you mention that Chrome keeps persistent connections = for up to 4 min, while 35% of the requests are made using new sessions; = Now I wonder, what fraction of these new sessions are set up towards a = server, where the client already had an earlier normal session (or, what = is the fraction of persistent connections, that get disconnected within = that 4 min timeout due to external reasons such as a NAT gateways = running out of resources, or into a = timeout…)

 

Because that 35% value above appears to throw genuinely = “new” sessions (new sites) and “lost” sessions = (timed out, reset by intermediate device or server etc) to a known host = into the same bucket – unless the wording around there is = misleading me J

 

 

(Since I know how you value even small sub-1% improvements, I do see = how this can help you, but I’m wondering if the complexity is = worthwhile for a generic tcp stack that deals mostly with = non-http’ish traffic).

 

Best regards,

 

Richard Scheffenegger

 

From:= Yuchung = Cheng [mailto:ycheng@google.com]
Sent: Freitag, 11. M=E4rz = 2011 20:05
To: tcpm@ietf.org Extensions
Cc: Mike = Belshe; Sivasankar Radhakrishnan; Arvind Jain
Subject: [tcpm] = Fwd: I-D = Action:draft-cheng-tcpm-fastopen-00.txt

=

 

Hi = folks,

 

We are proposing a new draft called TCP Fast Open = (TFO) which allows data exchange to begin in TCP handshake to improve = performance.

 

We would like to gather some comments before we = present it in the next tcpm meeting in Prague. The presentation will = also include some performance numbers based on our beta implementation = in Linux and the Chrome browser.

 

Thanks,

 

Yuchung

 

---------- Forwarded message = ----------

From: <Internet-Drafts@ietf.org>=
Date: Mon, Mar 7, 2011 at 4:45 PM
Subject: I-D = Action:draft-cheng-tcpm-fastopen-00.txt
To: i-d-announce@ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts = directories.

       Title     =       : TCP Fast Open
      =  Author(s)       : Y. Cheng, et al.
    =    Filename        : = draft-cheng-tcpm-fastopen-00.txt
       Pages =           : 17
      =  Date            : = 2011-03-07

TCP Fast Open (TFO) allows data to be carried in the = SYN or SYN-ACK
packets and consumed by the receiving end during the = initial
connection handshake, thus providing a saving of up to one = full round
trip time (RTT) compared to standard TCP requiring a = three-way
handshake (3WHS) to complete before data can be = exchanged.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-cheng-tcpm-fa= stopen-00.txt

Internet-Drafts are also available by anonymous = FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below = is the data which will enable a MIME compliant mail = reader
implementation to automatically retrieve the ASCII version of = the
Internet-Draft.


_______________________________________= ________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
I= nternet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

 

------_=_NextPart_001_01CBE239.22AF8C49-- From Internet-Drafts@ietf.org Mon Mar 14 06:00:09 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81C603A6D29; Mon, 14 Mar 2011 06:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPmW3W9SpgyN; Mon, 14 Mar 2011 06:00:08 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AD883A6D30; Mon, 14 Mar 2011 06:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314130002.4193.22831.idtracker@localhost> Date: Mon, 14 Mar 2011 06:00:02 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-paxson-tcpm-rfc2988bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 13:00:09 -0000 --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 : Computing TCP's Retransmission Timer Author(s) : V. Paxson, et al. Filename : draft-paxson-tcpm-rfc2988bis-02.txt Pages : 9 Date : 2011-03-14 This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-paxson-tcpm-rfc2988bis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-paxson-tcpm-rfc2988bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14055334.I-D@ietf.org> --NextPart-- From mallman@icir.org Mon Mar 14 09:19:15 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CC0D3A696C for ; Mon, 14 Mar 2011 09:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U9q0NT1PylX for ; Mon, 14 Mar 2011 09:19:14 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 9246D3A6DDA for ; Mon, 14 Mar 2011 09:19:14 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p2EGKXrD000499; Mon, 14 Mar 2011 09:20:33 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 931833536351; Mon, 14 Mar 2011 12:20:33 -0400 (EDT) To: "Scheffenegger, Richard" From: Mark Allman In-Reply-To: <5FDC413D5FA246468C200652D63E627A0D4F4DE1@LDCMVEXC1-PRD.hq.netapp.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Jack and Diane MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma16463-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 14 Mar 2011 12:20:33 -0400 Sender: mallman@icir.org Message-Id: <20110314162033.931833536351@lawyers.icir.org> Cc: Arvind Jain , Mike Belshe , tcpm@ietf.org, Sivasankar Radhakrishnan Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 16:19:15 -0000 ----------ma16463-1 Content-Type: text/plain Content-Disposition: inline > Now I wonder, what fraction of these new sessions are set up towards a > server, where the client already had an earlier normal session Well, I grabbed a connection log from yesterday for a monitoring point that watches a fiber-to-the-home setup that serves 100 houses in Cleveland, OH to test this out. (Nothing magic here ... it just happened to be handy data.) For each outgoing TCP connection I looked at whether there was a previous connection from the current source host to the current destination host within the last [threshold] seconds. The results for various thresholds: 30sec 60sec 120sec 180sec 240sec Inf ----------------------------------------------------------------------------- Total 15.3M 15.3M 15.3M 15.3M 15.3M 15.3M Prev 5.1M 6.1M 7.2M 7.8M 8.2M 15.1M NoPrev 10.1M 9.2M 8.1M 7.4M 7.1M 145K (modulo rounding errors; you get the point ...) Where "Prev" means there was a previous connection in the time interval and "NoPrev" means there was no previous connection. The "Inf" column removes the time threshold and just tests whether there was a previous connection or not. The analysis is not perfect. E.g., the same source could be used for a few machines behind a NAT in the given house. But, it gives a general idea. > (Since I know how you value even small sub-1% improvements, I do see > how this can help you, but I'm wondering if the complexity is > worthwhile for a generic tcp stack that deals mostly with non-http'ish > traffic). As you can see, this is not a (sub-)1% situation in the data I grabbed. Maybe its a 1% situation somewhere. And, while I agree that we should obviously assess cost-v-benefit, setting up strawmen to knock down to suggest this isn't useful is dubious.) allman ----------ma16463-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk1+QFEACgkQWyrrWs4yIs6/UACfbyniiW4MHT3HQbkXPKWDvnoW +hYAmwedwG9a8guzaKH0qNkHYnIblnEp =AxZ8 -----END PGP SIGNATURE----- ----------ma16463-1-- From william.allen.simpson@gmail.com Mon Mar 14 10:20:28 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FB853A6D87 for ; Mon, 14 Mar 2011 10:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmpKj2n7Ah68 for ; Mon, 14 Mar 2011 10:20:23 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 0AA063A6DB4 for ; Mon, 14 Mar 2011 10:20:22 -0700 (PDT) Received: by iyi12 with SMTP id 12so2453671iyi.31 for ; Mon, 14 Mar 2011 10:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dOuwsdD4gBDjYYC0OLBAB/koLdFViI57uaF7QyBOEA8=; b=PGrzYuZ3ivD4rXuuIDm+IV4K5iLwCVHLKSMmMuL2c7RxpnvZTjbAr0qRPjQSHcxF4g HG8ob3x9bw2GfKXEwm+UQoXmx27b3V1Wom5XnQ4oeVQge8ncoxFd1cq2/7r2Vzf9r9Xh 9TDvxVgUQPBGTy8AJycY0eJXg+wBMaIYLmiKw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=BugG+T/pTdjv18RcxLLhRd0AYxBZ4Q/dA+DBzwhnXULRLP+YdQ/+EsC3GZwe/qFkbE eVTPMBEiWTA1tKpEhhu2FEn2XOyp84ul24ZZrwB4DvFI0mA7FOc9elkPNvSzaj+uQWHB TtcPIoK+++P4cHfjklo63CZtpKfY0U6TuMPVM= Received: by 10.43.56.70 with SMTP id wb6mr5079051icb.339.1300123304906; Mon, 14 Mar 2011 10:21:44 -0700 (PDT) Received: from Wastrel-2.local (d199-74-177-50.col.wideopenwest.com [74.199.50.177]) by mx.google.com with ESMTPS id wf3sm3189352icb.9.2011.03.14.10.21.42 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Mar 2011 10:21:43 -0700 (PDT) Message-ID: <4D7E4EA5.80001@gmail.com> Date: Mon, 14 Mar 2011 13:21:41 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: tcpm@ietf.org References: <20110308004501.27770.44908.idtracker@localhost> <5FDC413D5FA246468C200652D63E627A0D4F4DE1@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A0D4F4DE1@LDCMVEXC1-PRD.hq.netapp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 17:20:28 -0000 On 3/14/11 7:15 AM, Scheffenegger, Richard wrote: > your proposal will only address new tcp sessions preceeded by one “normal” 3WHS session setup. > Yes, that's a problem. Most sessions are one-off. Especially DNSsec TCP queries, redirect sessions, etc. I'd talked to various Google folks last year about their idea to treat the second session differently, and left it as an open issue for TCPCT. See RFC-6013 Acknowledgments. For idempotent operations, that's not a problem. So, I'd view this as a follow-on draft to RFC-6013. Certainly, the second TCPCT session could send multiple data packets (the +data, plus additional ACK+data packets). SACK will acknowledge the SYN data, and TCP itself handle any later holes completely transparently. But I didn't want to add so much extra detail to TCPCT until we had a good handle on how well it worked in the field. We still don't have much data, mostly because Google didn't follow-up after I'd included their requested SYN+data features.... > In the draft, you mention that Chrome keeps persistent connections for up to 4 min, while 35% of the requests are made using new sessions; Now I wonder, what fraction of these new sessions are set up towards a server, where the client already had an > earlier normal session (or, what is the fraction of persistent connections, that get disconnected within that 4 min timeout due to external reasons such as a NAT gateways running out of resources, or into a timeout…) > I'm also concerned that re-using the cookies for that long a time isn't sufficiently secure. In fact, it feels like they don't really understand the underlying security issues that are handled by cookies. We had this same problem over in the IPsec group with ISAKMP. It's not *only* a token, it's an anti-clogging token for preventing DoS attacks. Just because you stick cookies into a protocol, doesn't make it improve security in and of itself. Security first, performance second! > Because that 35% value above appears to throw genuinely “new” sessions (new sites) and “lost” sessions (timed out, reset by intermediate device or server etc) to a known host into the same bucket – unless the wording around there is misleading me J > Indeed, this proposal worries me about other protocol and security issues. 1) How does it handle path changes that affect options? 2) How does it prevent use in DoS? It's an OK rough draft, but needs a lot of work. From wes@mti-systems.com Mon Mar 14 10:39:44 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBCA63A6DF8 for ; Mon, 14 Mar 2011 10:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-A1ypSizFHg for ; Mon, 14 Mar 2011 10:39:44 -0700 (PDT) Received: from omr2.networksolutionsemail.com (omr2.networksolutionsemail.com [205.178.146.52]) by core3.amsl.com (Postfix) with ESMTP id F27073A6DBE for ; Mon, 14 Mar 2011 10:39:43 -0700 (PDT) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p2EHexNm026469 for ; Mon, 14 Mar 2011 13:41:07 -0400 Authentication-Results: cm-omr7 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [107.27.225.235] ([107.27.225.235:33389] helo=[192.168.9.2]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 53/8D-22821-A235E7D4; Mon, 14 Mar 2011 13:40:59 -0400 Message-ID: <4D7E5329.1030202@mti-systems.com> Date: Mon, 14 Mar 2011 13:40:57 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tcpm@ietf.org References: <20110216164501.27490.96538.idtracker@localhost> <0C53DCFB700D144284A584F54711EC580BE2DF4F@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580BE2DF4F@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-persist-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 17:39:45 -0000 On 2/16/2011 1:31 PM, Anantha Ramaiah (ananth) wrote: > Greetings, > This new version posted addresses the concerns raised during the > last call. It also contains the idnits changes suggested by Fernando and > Lars. Special thanks goes to Wes for going through the draft and > providing some useful text which primarily aims at addressing the > concerns raised during the LC. If folks in the to list can review the > new version and check if this version addresses the issues raised by > them, and provide feedback to the list, it would be great. I haven't seen responses to this, but as the document shepherd, it looks to me like the comments have been incorporated to good extent. This note is just to be explicit about the process being followed. David is planning to make a review of it this week, and our plan is that if he agrees with that assessment, we'll forward the request for publication to the IESG. -- Wes Eddy MTI Systems From wes@mti-systems.com Mon Mar 14 10:40:36 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFF183A6D79 for ; Mon, 14 Mar 2011 10:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbF3d2xfkfuj for ; Mon, 14 Mar 2011 10:40:36 -0700 (PDT) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by core3.amsl.com (Postfix) with ESMTP id 4AD1D3A6D6C for ; Mon, 14 Mar 2011 10:40:35 -0700 (PDT) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p2EHfwRW010304 for ; Mon, 14 Mar 2011 13:41:58 -0400 Authentication-Results: cm-omr6 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [107.27.225.235] ([107.27.225.235:10582] helo=[192.168.9.2]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id E7/2B-24897-6635E7D4; Mon, 14 Mar 2011 13:41:58 -0400 Message-ID: <4D7E535D.6090307@mti-systems.com> Date: Mon, 14 Mar 2011 13:41:49 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tcpm@ietf.org References: <20110314130002.4193.22831.idtracker@localhost> In-Reply-To: <20110314130002.4193.22831.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] I-D Action:draft-paxson-tcpm-rfc2988bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 17:40:36 -0000 FYI - the authors made this update to the 2988bis document in order to correct some idnits warnings/errors prior to us requesting publication to the IESG. This note is intended to be explicit about the process being followed. The WGLC ran from 2/7 - 2/21 and ended without significant feedback. Because the WG formerly expressed reasonable interest in this and it represents only a couple of modifications to the existing RFC 2988 with clear explanation and analysis, I feel comfortable requesting publication and am planning to do so on Friday. To be safe, before that time, David is also planning to review the document and whether all issues on it have been closed. On 3/14/2011 9:00 AM, Internet-Drafts@ietf.org wrote: > 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 : Computing TCP's Retransmission Timer > Author(s) : V. Paxson, et al. > Filename : draft-paxson-tcpm-rfc2988bis-02.txt > Pages : 9 > Date : 2011-03-14 > > This document defines the standard algorithm that Transmission > Control Protocol (TCP) senders are required to use to compute and > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-paxson-tcpm-rfc2988bis-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- Wes Eddy MTI Systems From ycheng@google.com Mon Mar 14 11:25:31 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 946DF3A69BC for ; Mon, 14 Mar 2011 11:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FknsuizkppyD for ; Mon, 14 Mar 2011 11:25:30 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 425D23A68C3 for ; Mon, 14 Mar 2011 11:25:30 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id p2EIQqeq025644 for ; Mon, 14 Mar 2011 11:26:53 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1300127213; bh=PyCIlDHOR14Uiv2sc60Hb+sWNL8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=xZ696BDFswBG/GmM7qxcDmJtkdlARgIeHmcPcDDy3swmHXj82zAdONZYfXNmaV6zl Q6OQKQ/1P+JZu+GybdxlQ== Received: from vws8 (vws8.prod.google.com [10.241.21.136]) by kpbe17.cbf.corp.google.com with ESMTP id p2EIQGbm030169 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 14 Mar 2011 11:26:51 -0700 Received: by vws8 with SMTP id 8so2871050vws.36 for ; Mon, 14 Mar 2011 11:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Nljc+mvNqTnTETPw0LzPZAtRVVRGfR2YwKTIuut0yfs=; b=ZtezeJMQ1Pbh+5o04zZxxfhqegwXjAJdydesztpCVJ2lwGYNbEFNDSWxmddePsmNcr PEAOWaoc2DANZizlaO8w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=E4cpYnWvF+GCQFzWtRY3SL1hmVMywkyB6s7Vs6SuF5trh8vhlqFj+ikXIrQvBzyD1o z787tEUMu0eAhkBsFcOg== Received: by 10.52.0.43 with SMTP id 11mr36615vdb.283.1300127210596; Mon, 14 Mar 2011 11:26:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.16.148 with HTTP; Mon, 14 Mar 2011 11:26:30 -0700 (PDT) In-Reply-To: <5FDC413D5FA246468C200652D63E627A0D4F4DE1@LDCMVEXC1-PRD.hq.netapp.com> References: <20110308004501.27770.44908.idtracker@localhost> <5FDC413D5FA246468C200652D63E627A0D4F4DE1@LDCMVEXC1-PRD.hq.netapp.com> From: Yuchung Cheng Date: Mon, 14 Mar 2011 11:26:30 -0700 Message-ID: To: "Scheffenegger, Richard" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Arvind Jain , Mike Belshe , tcpm@ietf.org, Sivasankar Radhakrishnan Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 18:25:31 -0000 The 35% number does include sessions visiting new sites. But Mark's number suggests that apps frequently visit same IPs in short intervals. We also have similar stat. We will update this part of text to make it more clear. Thanks! Yuchung On Mon, Mar 14, 2011 at 4:15 AM, Scheffenegger, Richard wro= te: > Hi Yuchung, > > > > your proposal will only address new tcp sessions preceeded by one =93norm= al=94 > 3WHS session setup. > > > > In the draft, you mention that Chrome keeps persistent connections for up= to > 4 min, while 35% of the requests are made using new sessions; Now I wonde= r, > what fraction of these new sessions are set up towards a server, where th= e > client already had an earlier normal session (or, what is the fraction of > persistent connections, that get disconnected within that 4 min timeout d= ue > to external reasons such as a NAT gateways running out of resources, or i= nto > a timeout=85) > > > > Because that 35% value above appears to throw genuinely =93new=94 session= s (new > sites) and =93lost=94 sessions (timed out, reset by intermediate device o= r > server etc) to a known host into the same bucket =96 unless the wording a= round > there is misleading me J > > > > > > (Since I know how you value even small sub-1% improvements, I do see how > this can help you, but I=92m wondering if the complexity is worthwhile fo= r a > generic tcp stack that deals mostly with non-http=92ish traffic). > > > > Best regards, > > > > Richard Scheffenegger > > > > From: Yuchung Cheng [mailto:ycheng@google.com] > Sent: Freitag, 11. M=E4rz 2011 20:05 > To: tcpm@ietf.org Extensions > Cc: Mike Belshe; Sivasankar Radhakrishnan; Arvind Jain > Subject: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt > > > > Hi folks, > > > > We are proposing a new draft called TCP Fast Open (TFO) which allows data > exchange to begin in TCP handshake to improve performance. > > > > We would like to gather some comments before we present it in the next tc= pm > meeting in Prague. The presentation will also include some performance > numbers based on our beta implementation in Linux and the Chrome browser. > > > > Thanks, > > > > Yuchung > > > > ---------- Forwarded message ---------- > > From: > Date: Mon, Mar 7, 2011 at 4:45 PM > Subject: I-D Action:draft-cheng-tcpm-fastopen-00.txt > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : TCP Fast Open > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Y. Cheng, et al. > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-cheng-tcpm-fastopen-00.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 17 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-03-07 > > TCP Fast Open (TFO) allows data to be carried in the SYN or SYN-ACK > packets and consumed by the receiving end during the initial > connection handshake, thus providing a saving of up to one full round > trip time (RTT) compared to standard TCP requiring a three-way > handshake (3WHS) to complete before data can be exchanged. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-cheng-tcpm-fastopen-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > From william.allen.simpson@gmail.com Mon Mar 14 11:35:38 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21B893A6A19 for ; Mon, 14 Mar 2011 11:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVQn5jna6Pg8 for ; Mon, 14 Mar 2011 11:35:37 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 22A123A68C3 for ; Mon, 14 Mar 2011 11:35:37 -0700 (PDT) Received: by iwl42 with SMTP id 42so6458850iwl.31 for ; Mon, 14 Mar 2011 11:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SWo2KVlERPCi5/CfrlpZQaWRJ81wfkjRbyljotxHjpA=; b=Fb4u/hb1XWeG/G/+QwGQ8nWAhlOf9n6XZG7cL9UV2z5xHBdpvtQDydWklKqmBnwKMZ z/VP6TeIY2iUKctLblPcz1VhwBboj9Uk8lX0fckB7Hi4txWZa3PWn7Hnm5moMc4F0i+/ fZwrH0/vG68/63Laa8IA3M4gwB/fYZl2pt0Y8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=JE5D21F/ORZ/zUwSUo57xSx6oJ4SMhaXuWsvMHadlomQ/U8rFOOetkYRXgoY1NceHY SMNrmpXY0if/UWYpbvmDhUzXNVAnxMVIg2JUyltheevk5FGwZtKqPk5HKZcEQ2TIqVPa Lr/ql9HFjx0EVdGzhJIooHtyX09L0389VYkSk= Received: by 10.43.56.195 with SMTP id wd3mr4109345icb.529.1300127819029; Mon, 14 Mar 2011 11:36:59 -0700 (PDT) Received: from Wastrel-2.local (d199-74-177-50.col.wideopenwest.com [74.199.50.177]) by mx.google.com with ESMTPS id u9sm6864273ibe.14.2011.03.14.11.36.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Mar 2011 11:36:57 -0700 (PDT) Message-ID: <4D7E6047.6010508@gmail.com> Date: Mon, 14 Mar 2011 14:36:55 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: tcpm@ietf.org References: <20110308004501.27770.44908.idtracker@localhost> <5FDC413D5FA246468C200652D63E627A0D4F4DE1@LDCMVEXC1-PRD.hq.netapp.com> <4D7E4EA5.80001@gmail.com> In-Reply-To: <4D7E4EA5.80001@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 18:35:38 -0000 On 3/14/11 1:21 PM, William Allen Simpson wrote: > Indeed, this proposal worries me about other protocol and security issues. > 1) How does it handle path changes that affect options? > 2) How does it prevent use in DoS? > > It's an OK rough draft, but needs a lot of work. After a little bit of thought, there are some *VERY* serious problems. This simply won't work in a heterogeneous environment. All kinds of failure modes. Moreover, I told at least 1 author and 1 listed reviewer about all of them as long ago as Feb 2010.... 3) The cookie isn't big enough, and there's no cookie pair. The whole scheme isn't crytologically sound! Googlers should go back and look at my presentation, and review the slide: "Size Matters". I remember remarking to several folks how disappointing that folks were more interested in the performance than the security. :-( Security first, performance second! 4) Sending a new option doesn't test the ability to send SYN data. The fact that you exchange an option doesn't tell you whether the 2nd session will actually pass data. TCPCT indicates that SYN data is successful by sending a SACK in the client . The server can cache that signal to indicate that SYN data is acceptable on the next session. Without a protocol signal, you end up losing the data -- or worse, the whole packet might be filtered -- and sending extra data segments that will be discarded. Over and over again, as the server retransmits. This leads to congestive collapse! That's one reason (of many) that TCPCT Responders never, Never, *NEVER* retransmit SYN segments! 6) There's no checking for collapsed TCP segments. There are many boxen out there with the damn off-loading boards or chips. Who even knows what they might do with SYN data and a following segment?!?! TCPCT checks for collapsed segments with second option, checking known data fields at the beginning of the option segment. It doesn't have any good method of fixing the connection (the handshake simply doesn't complete). But *not* checking these things could lead to data corruption! From rs@netapp.com Mon Mar 14 13:43:32 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B94803A6E12 for ; Mon, 14 Mar 2011 13:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnNLYaeFylkS for ; Mon, 14 Mar 2011 13:43:31 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id 841333A6B57 for ; Mon, 14 Mar 2011 13:43:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.62,318,1297065600"; d="scan'208";a="245738260" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 14 Mar 2011 13:44:54 -0700 Received: from amsrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p2EKcX7j009362; Mon, 14 Mar 2011 13:38:33 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Mar 2011 21:38:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Mar 2011 20:38:17 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0D5F1780@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <20110314162033.931833536351@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt Thread-Index: AcviY82/LLsNEqe1Tvys3SNzPb63xgAIw96A References: <5FDC413D5FA246468C200652D63E627A0D4F4DE1@LDCMVEXC1-PRD.hq.netapp.com> <20110314162033.931833536351@lawyers.icir.org> From: "Scheffenegger, Richard" To: X-OriginalArrivalTime: 14 Mar 2011 20:38:33.0294 (UTC) FILETIME=[C91F86E0:01CBE287] Cc: Arvind Jain , Mike Belshe , tcpm@ietf.org, Sivasankar Radhakrishnan Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 20:43:32 -0000 Thanks Mark, I was genuinely wondering what would be the fraction of sessions that = could benefit from this proposal; The data you provided and the comment = by Arvind indicate, that for normal users performing one specific = application (web browsing), a majority of session would benefit. But it was my understanding that looking at only one single application = and optimizing TCP just for that would only make sense, if that impact = is large enough to warrant it.=20 Best regards, =20 Richard Scheffenegger > -----Original Message----- > From: Mark Allman [mailto:mallman@icir.org] > Sent: Montag, 14. M=E4rz 2011 17:21 > To: Scheffenegger, Richard > Cc: Yuchung Cheng; tcpm@ietf.org; Arvind Jain; Mike Belshe; Sivasankar > Radhakrishnan > Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt >=20 >=20 > > Now I wonder, what fraction of these new sessions are set up towards > a > > server, where the client already had an earlier normal session >=20 > Well, I grabbed a connection log from yesterday for a monitoring point > that watches a fiber-to-the-home setup that serves 100 houses in > Cleveland, OH to test this out. (Nothing magic here ... it just > happened to be handy data.) For each outgoing TCP connection I looked > at whether there was a previous connection from the current source = host > to the current destination host within the last [threshold] seconds. > The results for various thresholds: >=20 > 30sec 60sec 120sec 180sec 240sec > Inf > = ----------------------------------------------------------------------- > ------ > Total 15.3M 15.3M 15.3M 15.3M 15.3M > 15.3M > Prev 5.1M 6.1M 7.2M 7.8M 8.2M > 15.1M > NoPrev 10.1M 9.2M 8.1M 7.4M 7.1M > 145K >=20 > (modulo rounding errors; you get the point ...) >=20 > Where "Prev" means there was a previous connection in the time = interval > and "NoPrev" means there was no previous connection. The "Inf" column > removes the time threshold and just tests whether there was a previous > connection or not. The analysis is not perfect. E.g., the same = source > could be used for a few machines behind a NAT in the given house. = But, > it gives a general idea. >=20 > > (Since I know how you value even small sub-1% improvements, I do see > > how this can help you, but I'm wondering if the complexity is > > worthwhile for a generic tcp stack that deals mostly with non- > http'ish > > traffic). >=20 > As you can see, this is not a (sub-)1% situation in the data I = grabbed. > Maybe its a 1% situation somewhere. And, while I agree that we should > obviously assess cost-v-benefit, setting up strawmen to knock down to > suggest this isn't useful is dubious.) >=20 > allman >=20 >=20 >=20 From mallman@icir.org Mon Mar 14 13:49:25 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2BE53A6B85 for ; Mon, 14 Mar 2011 13:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.509 X-Spam-Level: X-Spam-Status: No, score=-106.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cKCHiW60bWx for ; Mon, 14 Mar 2011 13:49:24 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id BE6083A6AA5 for ; Mon, 14 Mar 2011 13:49:24 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p2EKoiTY012219; Mon, 14 Mar 2011 13:50:44 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 67C84353A342; Mon, 14 Mar 2011 16:50:44 -0400 (EDT) To: "Scheffenegger, Richard" From: Mark Allman In-Reply-To: <5FDC413D5FA246468C200652D63E627A0D5F1780@LDCMVEXC1-PRD.hq.netapp.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Lights MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma32675-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 14 Mar 2011 16:50:44 -0400 Sender: mallman@icir.org Message-Id: <20110314205044.67C84353A342@lawyers.icir.org> Cc: Arvind Jain , Mike Belshe , tcpm@ietf.org, Sivasankar Radhakrishnan Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 20:49:25 -0000 ----------ma32675-1 Content-Type: text/plain Content-Disposition: inline > I was genuinely wondering what would be the fraction of sessions that > could benefit from this proposal; The data you provided and the > comment by Arvind indicate, that for normal users performing one > specific application (web browsing), a majority of session would > benefit. > > But it was my understanding that looking at only one single > application and optimizing TCP just for that would only make sense, if > that impact is large enough to warrant it. I didn't say my data was from one application. In fact, I said: For each outgoing TCP connection I looked at whether there was a previous connection from the current source host to the current destination host within the last [threshold] seconds. I made no application-layer determination. Arvind's data may be application-biased by being from Google. I looked at a population of users doing whatever it is they do with TCP. allman ----------ma32675-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk1+f6MACgkQWyrrWs4yIs5TGwCfTKjfGGUpxBpS0QkctvN08gGX oqsAoIotX//vaovVaeHLvmJSaQn34P2e =RBSq -----END PGP SIGNATURE----- ----------ma32675-1-- From rs@netapp.com Mon Mar 14 14:05:10 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15EBB3A6B57 for ; Mon, 14 Mar 2011 14:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9FNXdeWbPd9 for ; Mon, 14 Mar 2011 14:05:08 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id F25193A6AA5 for ; Mon, 14 Mar 2011 14:05:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.62,318,1297065600"; d="scan'208";a="245740834" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 14 Mar 2011 14:06:26 -0700 Received: from amsrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p2EL6Q1V011558; Mon, 14 Mar 2011 14:06:26 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Mar 2011 22:06:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Mar 2011 21:06:10 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0D5F178C@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt Thread-Index: AcvidWWIVuYtR2EIS2GkFG5vALNP1wAFjl4g References: <20110308004501.27770.44908.idtracker@localhost> <5FDC413D5FA246468C200652D63E627A0D4F4DE1@LDCMVEXC1-PRD.hq.netapp.com> From: "Scheffenegger, Richard" To: "Yuchung Cheng" X-OriginalArrivalTime: 14 Mar 2011 21:06:26.0764 (UTC) FILETIME=[AE96C8C0:01CBE28B] Cc: Arvind Jain , Mike Belshe , tcpm@ietf.org, Sivasankar Radhakrishnan Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 21:05:10 -0000 Thank you! Richard Scheffenegger > -----Original Message----- > From: Yuchung Cheng [mailto:ycheng@google.com] > Sent: Montag, 14. M=E4rz 2011 19:27 > To: Scheffenegger, Richard > Cc: tcpm@ietf.org; Mike Belshe; Sivasankar Radhakrishnan; Arvind Jain > Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt >=20 > The 35% number does include sessions visiting new sites. But Mark's > number suggests that apps frequently visit same IPs in short > intervals. We also have similar stat. We will update this part of text > to make it more clear. Thanks! >=20 > Yuchung >=20 > On Mon, Mar 14, 2011 at 4:15 AM, Scheffenegger, Richard = > wrote: > > Hi Yuchung, > > > > > > > > your proposal will only address new tcp sessions preceeded by one > "normal" > > 3WHS session setup. > > > > > > > > In the draft, you mention that Chrome keeps persistent connections > for up to > > 4 min, while 35% of the requests are made using new sessions; Now I > wonder, > > what fraction of these new sessions are set up towards a server, > where the > > client already had an earlier normal session (or, what is the > fraction of > > persistent connections, that get disconnected within that 4 min > timeout due > > to external reasons such as a NAT gateways running out of resources, > or into > > a timeout...) > > > > > > > > Because that 35% value above appears to throw genuinely "new" > sessions (new > > sites) and "lost" sessions (timed out, reset by intermediate device > or > > server etc) to a known host into the same bucket - unless the = wording > around > > there is misleading me J > > > > > > > > > > > > (Since I know how you value even small sub-1% improvements, I do see > how > > this can help you, but I'm wondering if the complexity is worthwhile > for a > > generic tcp stack that deals mostly with non-http'ish traffic). > > > > > > > > Best regards, > > > > > > > > Richard Scheffenegger > > > > > > > > From: Yuchung Cheng [mailto:ycheng@google.com] > > Sent: Freitag, 11. M=E4rz 2011 20:05 > > To: tcpm@ietf.org Extensions > > Cc: Mike Belshe; Sivasankar Radhakrishnan; Arvind Jain > > Subject: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt > > > > > > > > Hi folks, > > > > > > > > We are proposing a new draft called TCP Fast Open (TFO) which allows > data > > exchange to begin in TCP handshake to improve performance. > > > > > > > > We would like to gather some comments before we present it in the > next tcpm > > meeting in Prague. The presentation will also include some > performance > > numbers based on our beta implementation in Linux and the Chrome > browser. > > > > > > > > Thanks, > > > > > > > > Yuchung > > > > > > > > ---------- Forwarded message ---------- > > > > From: > > Date: Mon, Mar 7, 2011 at 4:45 PM > > Subject: I-D Action:draft-cheng-tcpm-fastopen-00.txt > > To: i-d-announce@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : TCP Fast Open > > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Y. Cheng, et al. > > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: = draft-cheng-tcpm-fastopen-00.txt > > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 17 > > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-03-07 > > > > TCP Fast Open (TFO) allows data to be carried in the SYN or SYN-ACK > > packets and consumed by the receiving end during the initial > > connection handshake, thus providing a saving of up to one full = round > > trip time (RTT) compared to standard TCP requiring a three-way > > handshake (3WHS) to complete before data can be exchanged. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-cheng-tcpm-fastopen-00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > From johnwheffner@gmail.com Mon Mar 14 14:09:55 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FD503A6EE8 for ; Mon, 14 Mar 2011 14:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifcsmzHSkxYU for ; Mon, 14 Mar 2011 14:09:54 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 78E613A6EE1 for ; Mon, 14 Mar 2011 14:09:54 -0700 (PDT) Received: by gyf3 with SMTP id 3so1392325gyf.31 for ; Mon, 14 Mar 2011 14:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zs1GbxYWoaWtslpnRZs92izB+kRHL/4K5VO1vFJ7uwo=; b=lH37j9qWJxvCXrG+bgl2zbKkKnjtNlSFMV6pNR4CF90yMgViJ/T0VCqhkedfEsvZYe cMS49Iudf0yud/9L+gvsl8MkF4aIfUvT0CsusZlcXQxKs/Il7s+Kl+bIDxOg/twln2xp 2fOfcEUOIhUN+Lb+1DtujGE7qLsCkX02TXfbo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fcKfvVgjtNfAyOdhV8D0iLMnsaAZI6EI1B+MzxjUr4zLnp+RQ1761MHmJ1OLQ80W4n 4raiV5StfmKZ/3wwxsH0IlXSWItbFGnFbnyiPrRUUIay5tzEGiMCNgfbjED2aP9Xs6Oj 7OJkrTP0jsWK8O1Wx4w258Za/yzpJCO3TET0E= MIME-Version: 1.0 Received: by 10.101.17.11 with SMTP id u11mr3843152ani.168.1300137077920; Mon, 14 Mar 2011 14:11:17 -0700 (PDT) Received: by 10.101.3.12 with HTTP; Mon, 14 Mar 2011 14:11:17 -0700 (PDT) In-Reply-To: <4D7E5329.1030202@mti-systems.com> References: <20110216164501.27490.96538.idtracker@localhost> <0C53DCFB700D144284A584F54711EC580BE2DF4F@xmb-sjc-21c.amer.cisco.com> <4D7E5329.1030202@mti-systems.com> Date: Mon, 14 Mar 2011 17:11:17 -0400 Message-ID: From: John Heffner To: Wesley Eddy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-persist-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 21:09:55 -0000 For the record, none of my previous comments have not been addressed. At a minimum, I strongly suggest removing the last paragraph of Section 5: "In order to provide some level of robustness to DoS attacks, a TCP implementation MAY provide a feedback regarding the persist condition to the application if requested to do so or an application or other resource manager can query the health of the TCP connection allowing it to take the desired action. All such techniques are in complete compliance of TCP [RFC0793] and Requirements for Internet Hosts [RFC1122]." and all of Appendix A. Thanks, -John On Mon, Mar 14, 2011 at 1:40 PM, Wesley Eddy wrote: > On 2/16/2011 1:31 PM, Anantha Ramaiah (ananth) wrote: >> >> Greetings, >> =A0 =A0 =A0This new version posted addresses the concerns raised during = the >> last call. It also contains the idnits changes suggested by Fernando and >> Lars. Special thanks goes to Wes for going through the draft and >> providing some useful text which primarily aims at addressing the >> concerns raised during the LC. If folks in the to list can review the >> new version and check if this version addresses the issues raised by >> them, and provide feedback to the list, it would be great. > > > I haven't seen responses to this, but as the document shepherd, it looks = to > me like the comments have been incorporated to good extent. =A0This note = is > just to be explicit about the process being followed. =A0David is plannin= g to > make a review of it this week, and our plan is that if he agrees with tha= t > assessment, we'll forward the request for publication to the IESG. > > > -- > Wes Eddy > MTI Systems > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From johnwheffner@gmail.com Mon Mar 14 14:11:38 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 388EA3A6EF9 for ; Mon, 14 Mar 2011 14:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83oMVXmqL5tb for ; Mon, 14 Mar 2011 14:11:33 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 90CD23A6977 for ; Mon, 14 Mar 2011 14:11:32 -0700 (PDT) Received: by gxk19 with SMTP id 19so1550949gxk.31 for ; Mon, 14 Mar 2011 14:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6Wv3ZD4H3DZEsfiS+l82FR3ttap5hN3n8erzxH4XICw=; b=fbRvq/Wz8dAYu5Q4MlMoKUuvtg76cv4mgWD0KJDWakiI170JRRcaa62QBWc3ZtTOPR pxLIu181Zrm+p/qfvAD6fAStmkE33F5fknWJECETNoVhLGB5GseWPBS00Ll1GejVPAON CJdDxUTxcJcybymv707dYAc8zO8Xzl4/znESQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SpsUz5vk25tb5aJYWKmyfEylfumkl8f8+21inCZUkQuf0capEHzxnbDIkhQO4gZciE nJVNEtdHTMey+Z2Qj0yXlKANBX2Z08FV4ybR8u0H5Bc6Oz2ust+mEiIKfD2/MbXipla9 xepzprIP2C0l2cGeXbzE5jWIm4bhk72GM5Sk4= MIME-Version: 1.0 Received: by 10.100.40.6 with SMTP id n6mr3840918ann.102.1300137176329; Mon, 14 Mar 2011 14:12:56 -0700 (PDT) Received: by 10.101.3.12 with HTTP; Mon, 14 Mar 2011 14:12:56 -0700 (PDT) In-Reply-To: References: <20110216164501.27490.96538.idtracker@localhost> <0C53DCFB700D144284A584F54711EC580BE2DF4F@xmb-sjc-21c.amer.cisco.com> <4D7E5329.1030202@mti-systems.com> Date: Mon, 14 Mar 2011 17:12:56 -0400 Message-ID: From: John Heffner To: Wesley Eddy Content-Type: text/plain; charset=ISO-8859-1 Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-persist-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 21:11:38 -0000 On Mon, Mar 14, 2011 at 5:11 PM, John Heffner wrote: > For the record, none of my previous comments have not been addressed. Remove the "not" in the sentence above. :-) -John From ananth@cisco.com Mon Mar 14 15:26:45 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A90DF3A6978 for ; Mon, 14 Mar 2011 15:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.641 X-Spam-Level: X-Spam-Status: No, score=-11.641 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iv6kaJT5zFrT for ; Mon, 14 Mar 2011 15:26:43 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 028EC3A6944 for ; Mon, 14 Mar 2011 15:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=7292; q=dns/txt; s=iport; t=1300141687; x=1301351287; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=tRYp4CZb+x+5MHqL1beh+An+TISO4ymm8Nv8WzZXT78=; b=lT828wHSspHOL6nqnhuVYQouz6XvYwrHUsYg9BM9Ocme2rwxb3u4O83U zKMOSYDEXA6OhExNZcpqcrCXQcUNn4+9/eL84wf5pB9bEBVHPSZRjyt9X A3orDGy/ZlPUnlKakmERyHric6cTRRUXQS8bIZnxXDZvlD0YzXvK5q+bD s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANcyfk2tJXG+/2dsb2JhbACmDXekbZw4hWIEhSuKew X-IronPort-AV: E=Sophos;i="4.62,319,1297036800"; d="scan'208";a="320223487" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-2.cisco.com with ESMTP; 14 Mar 2011 22:28:06 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2EMRjnZ028461; Mon, 14 Mar 2011 22:28:06 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 15:28:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Mar 2011 15:28:02 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580C2CFB46@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] I-D Action:draft-ietf-tcpm-persist-03.txt Thread-Index: AcvijGJnzxgZe1y6QxyaVxd9U51TaQAAK3RA References: <20110216164501.27490.96538.idtracker@localhost><0C53DCFB700D144284A584F54711EC580BE2DF4F@xmb-sjc-21c.amer.cisco.com><4D7E5329.1030202@mti-systems.com> From: "Anantha Ramaiah (ananth)" To: "John Heffner" , "Wesley Eddy" X-OriginalArrivalTime: 14 Mar 2011 22:28:03.0272 (UTC) FILETIME=[15229C80:01CBE297] Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-persist-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 22:26:45 -0000 John, Firstly I am alarmed at the timing of your emails. For the last call = comments which you provided (albeit late), in consultations with the = chairs we incorporated all the LC comments received including = yours(IOHO) and the next version was out. I had sent a note to the list = (you were cc'ed and so as TCPM, you should have received at least 1 or 2 = copies of the same email). Here is the link (for the sake of reference) = :- http://www.ietf.org/mail-archive/web/tcpm/current/msg06319.html I did not see any comments to the above post. Now you have an email = saying your comments have not been incorporated when the last call = process commenced again. You may want to relax your filter rules esp. = when you have commented on something and authors have taking the pain to = incorporate them and waiting for a reply. (if you need more time, that's = fine..) Only sounds as a fair practice to me. Anyways, lets come to the point :- You had made the following comments during the last call : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D First, apologies for missing the last call deadline. But I'd like for = the record to state that I don't believe the authors have addressed the = substantive criticisms raised on the list. I'm also not sure that = consensus has been reached on this document, but that is for the working = group chairs to decide. To summarize my position in a single phrase, closing a TCP connection = because it is in the persist state is a mistake. And this document = describes a mechanism to do exactly that. If the language in RFC1122 = needs to be clarified, the clarification should be that a connection may = be aborted while in the persist state. It should not be aborted *because* it is in the persist state. To be more specific, the majority of the doc describes a DoS attack by = resource exhaustion; however, the persist condition is only a small = subset of this class of resource exhaustion attacks. Addressing only = connections in the persist state ignores the rest of the problem. The = document does not address this very simple well-know attack: . This document also does not address = connections where, for example, one byte of window is opened every 60 = seconds, and how they might be prioritized relative to connections in = the persist state. Using the mechanism described in the document leaves = a system completely vulnerable to resource exhaustion by such a = slow-acking attacker. As a developer, why would I choose to implement = this? Unless these simple variations are addressed, I think it's a = waste of time. Additionally, most implementations already provide an API for handling = closing of sockets in FIN_WAIT or CLOSING states, with the SO_LINGER = option. I don't think this document makes a sufficient justification = for why this existing mechanism is inadequate, or why the proposed API = is necessary or sufficient. Thanks, -John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Response to some of the claims you make above :- C1 : "close connections because it is persist state". "it also doesn't = say a connection may be aborted because it is in persist state".=20 Response :- where in the document it is mentioned like you said above? = We will be glad to correct it. C2 : "majority of the document describes a DoS attack by resource = exhaustion".=20 Response: Can you explain why you feel so?=20 C3: " The document does not address this very simple well-know attack: " Response : It is not the purpose of the document to address attacks = since the WG consensus was for clarification of RFC 1122 text.=20 C4: "handling closing of sockets in FIN_WAIT or CLOSING states, with the = SO_LINGER option". Response : SO_LINGER works only during connection close. The API which = is being illustrated in the document is not a proposal. It is the one = which we used and we needed that API since it informs the resource = manager about the connection that is not making any progress which in = the current case is in persist state. Actually by mentioning the = SO_LINGER etc., and explaining why it was inadequate simply implies that = we are trying to propose a new API. This is not the case since we are = simply adhering to the WG consensus of being "informational draft + = clarification of persist condition". Further.. > For the record, none of my previous comments have not been addressed. > At a minimum, I strongly suggest removing the last paragraph of > Section 5: > "In order to provide some level of robustness to DoS attacks, a TCP > implementation MAY provide a feedback regarding the persist > condition > to the application if requested to do so or an application or other > resource manager can query the health of the TCP connection = allowing > it to take the desired action. All such techniques are in complete > compliance of TCP [RFC0793] and Requirements for Internet Hosts > [RFC1122]." > and all of Appendix A. Please note the "desired action" A desired action can mean nothing or it = could be mean aborting a connection. It is up to the application or = resource manager to decide what to do. There is no harm in the above = sentence, in fact it only clarifies the current spirit of RFC 1122, IMO. = Querying about a connection, taking action etc., are all normal, we are = not suggesting anything implicit. =20 Can you elaborate/send text? Thanks, -Anantha >=20 > Thanks, > -John >=20 >=20 > On Mon, Mar 14, 2011 at 1:40 PM, Wesley Eddy > wrote: > > On 2/16/2011 1:31 PM, Anantha Ramaiah (ananth) wrote: > >> > >> Greetings, > >> =A0 =A0 =A0This new version posted addresses the concerns raised = during > the > >> last call. It also contains the idnits changes suggested by = Fernando > and > >> Lars. Special thanks goes to Wes for going through the draft and > >> providing some useful text which primarily aims at addressing the > >> concerns raised during the LC. If folks in the to list can review > the > >> new version and check if this version addresses the issues raised = by > >> them, and provide feedback to the list, it would be great. > > > > > > I haven't seen responses to this, but as the document shepherd, it > looks to > > me like the comments have been incorporated to good extent. =A0This > note is > > just to be explicit about the process being followed. =A0David is > planning to > > make a review of it this week, and our plan is that if he agrees = with > that > > assessment, we'll forward the request for publication to the IESG. > > > > > > -- > > Wes Eddy > > MTI Systems > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From Internet-Drafts@ietf.org Mon Mar 14 15:45:05 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D64CC3A6D75; Mon, 14 Mar 2011 15:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJmXbYnXBJpA; Mon, 14 Mar 2011 15:45:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 608D63A6EEC; Mon, 14 Mar 2011 15:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314224502.22925.8364.idtracker@localhost> Date: Mon, 14 Mar 2011 15:45:02 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-rfc3782-bis-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 22:45:05 -0000 --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 : The NewReno Modification to TCP's Fast Recovery Algorithm Author(s) : T. Henderson, et al. Filename : draft-ietf-tcpm-rfc3782-bis-01.txt Pages : 23 Date : 2011-03-14 RFC 5681 [RFC5681] documents the following four intertwined TCP congestion control algorithms: Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery. RFC 5681 explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgement (SACK) option [RFC2883], and modifications that respond to "partial acknowledgments" (ACKs which cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as NewReno. This response to partial acknowledgments was first proposed by Janey Hoe in [Hoe95]. The purpose of this revision from [RFC3782] is to make errata changes and to adopt a proposal from Yoshifumi Nishida to slightly increase the minimum window size after Fast Recovery from one to two segments, to improve performance when the receiver uses delayed acknowledgments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc3782-bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-tcpm-rfc3782-bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14153727.I-D@ietf.org> --NextPart-- From johnwheffner@gmail.com Mon Mar 14 16:50:26 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92CA43A6EF3 for ; Mon, 14 Mar 2011 16:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJBDEzTjU4mb for ; Mon, 14 Mar 2011 16:50:24 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 7B0393A6B8B for ; Mon, 14 Mar 2011 16:50:24 -0700 (PDT) Received: by gyf3 with SMTP id 3so22362gyf.31 for ; Mon, 14 Mar 2011 16:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=APjcCwguaEueMda/Vrur/GcwO9KaEeriHurJ8XAPAW8=; b=A8Yc8OaYg/UeKtD5LSYvbgPjAv5r2GqWqcechClIVh86eX52WQ2MQ+4skwgkI74PTd 75NPUllVuMjt26ShPpcWGqzoNetZru+3AYoB6dt7/SZvf60lRG41NzWhA9SFCUbQL8ty FfILG8JI3OjDhXfRPH/JM4ZH+2rbkOTjMfBMs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=M4YNHkfMSWu4dpuphSZDC4S3s6G5vzdLJJs5PNudtdjsmfVQw6MbCQB9N85HkVeFJ4 xzgFHimPEYN5gA9K9LsyvxUBX6ri1NClhgADeGKIfSs+UUUKMgZ0KdIbhvLSDfJyqoKe I1mY4FkkS2rQmpt23RiXXCcQhpaUm0Zs/KzrM= MIME-Version: 1.0 Received: by 10.100.191.16 with SMTP id o16mr3951748anf.80.1300146708416; Mon, 14 Mar 2011 16:51:48 -0700 (PDT) Received: by 10.101.3.12 with HTTP; Mon, 14 Mar 2011 16:51:48 -0700 (PDT) In-Reply-To: <0C53DCFB700D144284A584F54711EC580C2CFB46@xmb-sjc-21c.amer.cisco.com> References: <20110216164501.27490.96538.idtracker@localhost> <0C53DCFB700D144284A584F54711EC580BE2DF4F@xmb-sjc-21c.amer.cisco.com> <4D7E5329.1030202@mti-systems.com> <0C53DCFB700D144284A584F54711EC580C2CFB46@xmb-sjc-21c.amer.cisco.com> Date: Mon, 14 Mar 2011 19:51:48 -0400 Message-ID: From: John Heffner To: "Anantha Ramaiah (ananth)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-persist-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 23:50:26 -0000 On Mon, Mar 14, 2011 at 6:28 PM, Anantha Ramaiah (ananth) wrote: > Response to some of the claims you make above :- > > C1 : "close connections because it is persist state". "it also doesn't sa= y a connection may be aborted because it is in persist state". > > Response :- where in the document it is mentioned like you said above? We= will be glad to correct it. > > C2 : "majority of the document describes a DoS attack by resource exhaust= ion". > > Response: Can you explain why you feel so? > > C3: > " The document does not address this very simple well-know attack: > " > > Response : It is not the purpose of the document to address attacks since= the WG consensus was for clarification of RFC 1122 text. > > C4: > > "handling closing of sockets in FIN_WAIT or CLOSING states, with the SO_L= INGER option". > > Response : SO_LINGER works only during connection close. =A0The API which= is being illustrated in the document is not a proposal. It is the one whic= h we used and we needed that API since it informs the resource manager abou= t the connection that is not making any progress which in the current case = is in persist state. Actually by mentioning the SO_LINGER etc., and explain= ing why it was inadequate simply implies that we are trying to propose a ne= w API. This is not the case since we are simply adhering to the WG consensu= s of being "informational draft + clarification of persist condition". Nothing has changed since the last round of discussion, so I won't rehash it. It's up to the chairs to decide if there is consensus to send the doc as-is to the IESG. Thanks, -John From mallman@icir.org Mon Mar 14 19:16:47 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48B8B3A6A3A for ; Mon, 14 Mar 2011 19:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.518 X-Spam-Level: X-Spam-Status: No, score=-106.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtWmBS6mu89J for ; Mon, 14 Mar 2011 19:16:46 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 6BD763A697D for ; Mon, 14 Mar 2011 19:16:46 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p2F2I7xm028748; Mon, 14 Mar 2011 19:18:07 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 4C54835405C5; Mon, 14 Mar 2011 22:18:07 -0400 (EDT) To: William Allen Simpson From: Mark Allman In-Reply-To: <4D7E6047.6010508@gmail.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Lights MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma52318-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 14 Mar 2011 22:18:07 -0400 Sender: mallman@icir.org Message-Id: <20110315021807.4C54835405C5@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 02:16:47 -0000 ----------ma52318-1 Content-Type: text/plain Content-Disposition: inline Bill- > On 3/14/11 1:21 PM, William Allen Simpson wrote: > > Indeed, this proposal worries me about other protocol and security issues. > > 1) How does it handle path changes that affect options? > > 2) How does it prevent use in DoS? > > > > It's an OK rough draft, but needs a lot of work. > > After a little bit of thought, there are some *VERY* serious problems. > This simply won't work in a heterogeneous environment. All kinds of > failure modes. Moreover, I told at least 1 author and 1 listed reviewer > about all of them as long ago as Feb 2010.... > > 3) The cookie isn't big enough, and there's no cookie pair. The whole > scheme isn't crytologically sound! > > Googlers should go back and look at my presentation, and review the slide: > "Size Matters". I remember remarking to several folks how disappointing > that folks were more interested in the performance than the security. :-( > > Security first, performance second! This is a lot of "if you were there then you'd know". But, I wasn't and so I don't. Can you frame this complaint in a way that us non-Googlers might grok, please? > 4) Sending a new option doesn't test the ability to send SYN data. The > fact that you exchange an option doesn't tell you whether the 2nd session > will actually pass data. > > TCPCT indicates that SYN data is successful by sending a SACK in the client > . The server can cache that signal to indicate that SYN data is > acceptable on the next session. > > Without a protocol signal, you end up losing the data -- or > worse, the whole packet might be filtered -- and sending extra data segments > that will be discarded. Over and over again, as the server retransmits. > > This leads to congestive collapse! That's one reason (of many) that TCPCT > Responders never, Never, *NEVER* retransmit SYN segments! This is FUD. Retransmitting SYNs is done using RTO backoff. You'd be hard to pressed to show me a scenario whereby this would cause congestion collapse. If this was *the only* traffic in the network, well maybe, since it is unproductive is being filtered. On the other hand, if it is the only traffic in the network nobody cares about congestion collapse because either way you're not getting anything done. So, yeah, there would need to be some backoff-to-no-data-in-the-SYN sort of approach. But, congestion collapse is a pretty ridiculous assertion here, IMHO. > 6) There's no checking for collapsed TCP segments. There are many boxen > out there with the damn off-loading boards or chips. Who even knows what > they might do with SYN data and a following segment?!?! Again, I cannot parse. I mean, yeah, who knows what these offload engines do, but what do you mean "collapsing TCP segments"? allman ----------ma52318-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk1+zF4ACgkQWyrrWs4yIs42iQCfbmqdI78qcOC7a5qcCnWqKLKR VlUAn2u1q4G4RGNKv1QzLo+bnaRbtIZf =M6nT -----END PGP SIGNATURE----- ----------ma52318-1-- From william.allen.simpson@gmail.com Tue Mar 15 06:47:21 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E1273A6D2F for ; Tue, 15 Mar 2011 06:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnjBfFcD4cwc for ; Tue, 15 Mar 2011 06:47:20 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 69BE33A6C08 for ; Tue, 15 Mar 2011 06:47:20 -0700 (PDT) Received: by iyi12 with SMTP id 12so699833iyi.31 for ; Tue, 15 Mar 2011 06:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9+xoRo3XT7Z07w+EAYtdMuhwHzZH0K9kvedaDEacgCI=; b=HuOuIUo4NPOez5fgyOudSgHVRSUoCZ1ZnSm6MGlXAZ4fHHQjD3/q/SY964JNDzLq01 W95YShvd4her9d+JpEcV6Q8YQFttEeTqojhgwTLlIeL+W8XifaG6nBCzRmKIS8NrGxP6 QWIpokzHNZyDNJ5OQfUqJEWEVgJShIasgVn+Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Jxv4tzOAkdBExuCYNJJv5Mrx4t20GbWmIUYqtN0ixMydhekhq2aq55v0ARPJCsr18E zKI82Ft0VGjRcLjxsACddYMUB0zBc5NHP/mx5MFqWUbc0kbmMC3ENzbhT4OkaOGz77I3 DNgYiA/Di8U7sJ50oSrHUyRsCsso+7QIP/rJo= Received: by 10.42.88.10 with SMTP id a10mr17337801icm.292.1300196925345; Tue, 15 Mar 2011 06:48:45 -0700 (PDT) Received: from Wastrel-2.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id wo11sm6272749icb.20.2011.03.15.06.48.42 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2011 06:48:43 -0700 (PDT) Message-ID: <4D7F6E39.9090308@gmail.com> Date: Tue, 15 Mar 2011 09:48:41 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: tcpm@ietf.org References: <20110315021807.4C54835405C5@lawyers.icir.org> In-Reply-To: <20110315021807.4C54835405C5@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 13:47:21 -0000 On 3/14/11 10:18 PM, Mark Allman wrote: >> 3) The cookie isn't big enough, and there's no cookie pair. The whole >> scheme isn't crytologically sound! >> >> Googlers should go back and look at my presentation, and review the slide: >> "Size Matters". I remember remarking to several folks how disappointing >> that folks were more interested in the performance than the security. :-( >> >> Security first, performance second! > > This is a lot of "if you were there then you'd know". But, I wasn't and > so I don't. Can you frame this complaint in a way that us non-Googlers > might grok, please? > Sorry. Went through the history of protocols and thinking on amount of client/initiator/requester unpredictable input to cryptographic hashes; such as Port (16 bits), PPP's Magic Number (32 bits), Photuris (Port + 128-bit Cookie + other bits), etc. Mentioned some notable failures, going back to the Morris worm -- and IKE/ISAKMP. Also presented "What's in a name?" -- about cookies themselves, the requirements, etc. This draft doesn't even use the most rudimentary of principles. The token shouldn't be called a "Cookie". Perhaps "Twinkie" -- all fat and calories, without nutritional value. >> 4) Sending a new option doesn't test the ability to send SYN data. The >> fact that you exchange an option doesn't tell you whether the 2nd session >> will actually pass data. >> >> TCPCT indicates that SYN data is successful by sending a SACK in the client >> . The server can cache that signal to indicate that SYN data is >> acceptable on the next session. >> >> Without a protocol signal, you end up losing the data -- or >> worse, the whole packet might be filtered -- and sending extra data segments >> that will be discarded. Over and over again, as the server retransmits. >> >> This leads to congestive collapse! That's one reason (of many) that TCPCT >> Responders never, Never, *NEVER* retransmit SYN segments! > > This is FUD. Retransmitting SYNs is done using RTO backoff. You'd be > hard to pressed to show me a scenario whereby this would cause > congestion collapse. If this was *the only* traffic in the network, > well maybe, since it is unproductive is being filtered. On the other > hand, if it is the only traffic in the network nobody cares about > congestion collapse because either way you're not getting anything done. > So, yeah, there would need to be some backoff-to-no-data-in-the-SYN sort > of approach. But, congestion collapse is a pretty ridiculous assertion > here, IMHO. > The initial RTO on a SYN with no history is specified as 3 seconds in RFC-1122. If your server sends the second segment 3 seconds after SYN data, and retransmits at 6 and 12 seconds, I'd be willing to suspend disbelief. But I'm pretty sure that's not what the draft has in mind. Instead, think for a moment about the other end. The Syn arrives with no data, the client sends an ACK. Then an out-of-sequence segment arrives, so the client sends an ACK. Then another out-of-sequence segment arrives, and the client sends an ACK. Etc. Now think about ACK clocking and duplicate ACK handling.... Wrapped your head around that? Now think about a server that's sending thousands of these packet trains into AT&T's iPhone network. Plug *that* into your network simulator.... Moreover, to entirely avoid use as a DoS source, you have to limit the initial retransmissions to be triggered by the client/initiator only. Otherwise, the server becomes a self-perpetuating source (for as many retransmissions as it's willing to make). >> 6) There's no checking for collapsed TCP segments. There are many boxen >> out there with the damn off-loading boards or chips. Who even knows what >> they might do with SYN data and a following segment?!?! > > Again, I cannot parse. I mean, yeah, who knows what these offload > engines do, but what do you mean "collapsing TCP segments"? > Please read up on TCP Offload Engines and TCP Segmentation Offload. There are a bunch of Linux NICs that re-combine smaller segments into larger ones. Although looking at the terrible code, I'm not sure it ever worked. Don't know of any other releases (everybody *I* respect is against it). But we have to design for it. We have to design for as many failure modes as we can imagine, *and* what to do when the unimaginable happens! From Internet-Drafts@ietf.org Tue Mar 15 09:45:04 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 901283A6D3C; Tue, 15 Mar 2011 09:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iwR3HoBsdKX; Tue, 15 Mar 2011 09:45:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70E143A6D48; Tue, 15 Mar 2011 09:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110315164502.25429.90902.idtracker@localhost> Date: Tue, 15 Mar 2011 09:45:02 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D ACTION:draft-eggert-tcpm-historicize-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 16:45:04 -0000 --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 : Moving the Undeployed TCP Extensions RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1379, RFC1644 and RFC1693 to Historic Status Author(s) : L. Eggert Filename : draft-eggert-tcpm-historicize-02.txt Pages : 4 Date : 2011-03-15 This document recommends that several TCP extensions that have never seen widespread use be moved to Historic status. The affected RFCs are RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1379, RFC1644 and RFC1693. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eggert-tcpm-historicize-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-eggert-tcpm-historicize-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-15093615.I-D@ietf.org> --NextPart-- From mallman@icir.org Tue Mar 15 10:00:06 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7B5E3A6E14 for ; Tue, 15 Mar 2011 10:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.525 X-Spam-Level: X-Spam-Status: No, score=-106.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qc2m+qLvgN2a for ; Tue, 15 Mar 2011 10:00:05 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id E207A3A6D32 for ; Tue, 15 Mar 2011 10:00:05 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p2FH1SnW004681; Tue, 15 Mar 2011 10:01:28 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 08C173565F48; Tue, 15 Mar 2011 13:01:28 -0400 (EDT) To: William Allen Simpson From: Mark Allman In-Reply-To: <4D7F6E39.9090308@gmail.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Glycerine MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma39783-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 15 Mar 2011 13:01:28 -0400 Sender: mallman@icir.org Message-Id: <20110315170128.08C173565F48@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 17:00:06 -0000 ----------ma39783-1 Content-Type: text/plain Content-Disposition: inline > The initial RTO on a SYN with no history is specified as 3 seconds in > RFC-1122. And in RFC2988. RFC 2988bis uses 1sec. > If your server sends the second segment 3 seconds after SYN data, and > retransmits at 6 and 12 seconds, I'd be willing to suspend disbelief. > But I'm pretty sure that's not what the draft has in mind. That is precisely what RFC2988 would have you do. My experience in looking at packet traces says this is in fact what happens. I read a pre-cursor to the fast open draft and I don't recall it changing this, but perhaps the fast open draft does and, if so, I think it'd be dubious and at least worthy of a bunch of skepticism. But, even without that I seriously doubt you could show collapse. > Instead, think for a moment about the other end. The Syn arrives with no > data, the client sends an ACK. Then an out-of-sequence segment arrives, so > the client sends an ACK. Then another out-of-sequence segment arrives, and > the client sends an ACK. Etc. Now think about ACK clocking and duplicate > ACK handling.... I have thought about this stuff a tremendous amount of the years. I don't see what you're getting at here. As best as I can tell you have just described TCP's standard behavior. Yes, an out of order packet triggers an (duplicate) ACK transmission. After a few of these the sender retransmits and slows down. What is your point? > There are a bunch of Linux NICs that re-combine smaller segments into > larger ones. Although looking at the terrible code, I'm not sure it > ever worked. Don't know of any other releases (everybody *I* respect > is against it). There are lots of things that muck with packet contents. I agree that they need to be thought about / understood / dealt with. On the other hand, because there exists some broken 'thing' should not necessarily prevent forward motion. allman ----------ma39783-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk1/m2cACgkQWyrrWs4yIs7JBgCeIDfUAzmNbQ50mWLzJnLPivgK qHkAn2oI0hfBeZzKNyyRxRj6dte8m9GD =aPGS -----END PGP SIGNATURE----- ----------ma39783-1-- From ycheng@google.com Tue Mar 15 10:12:41 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18473A6D39 for ; Tue, 15 Mar 2011 10:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.478 X-Spam-Level: X-Spam-Status: No, score=-105.478 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0ZyXUZLgh8r for ; Tue, 15 Mar 2011 10:12:40 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id ED0763A6D32 for ; Tue, 15 Mar 2011 10:12:39 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id p2FHE44J012770 for ; Tue, 15 Mar 2011 10:14:04 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1300209244; bh=ACT64/VDMNxaw6Zez5o8WW6+nzI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=FIrFww6Va8G4mYGw/THNu3tgB93wqwvEsfam3q2ZADp7H39QR1owOuFY+peD4ntR2 I0+h/JfUfA9/8f9hBVjwA== Received: from vxb39 (vxb39.prod.google.com [10.241.33.103]) by kpbe17.cbf.corp.google.com with ESMTP id p2FHAshX017665 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 15 Mar 2011 10:14:03 -0700 Received: by vxb39 with SMTP id 39so815089vxb.12 for ; Tue, 15 Mar 2011 10:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=httuWnwt0ixpWNgohCCc/z3wDH+N0GashjynZ8sH6mg=; b=M5X2y9K/7wFEbL3djJSqSdR7qSTS/3x16jWuNSkgRLVNiqSZd1G7OLtvD38+3CRJ8s fVgBkan6lNxxYlMXjNOw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=cUeo6JbWsOiJHStgsZ2ftAZzvjCpnMrVsUzM8cmEWej9x0wxujihJEImY21x9DD86f 83k/VtP1vjIEzmyYl0Bg== Received: by 10.220.202.74 with SMTP id fd10mr3554920vcb.215.1300209242206; Tue, 15 Mar 2011 10:14:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.16.148 with HTTP; Tue, 15 Mar 2011 10:13:41 -0700 (PDT) In-Reply-To: <4D7E6047.6010508@gmail.com> References: <20110308004501.27770.44908.idtracker@localhost> <5FDC413D5FA246468C200652D63E627A0D4F4DE1@LDCMVEXC1-PRD.hq.netapp.com> <4D7E4EA5.80001@gmail.com> <4D7E6047.6010508@gmail.com> From: Yuchung Cheng Date: Tue, 15 Mar 2011 10:13:41 -0700 Message-ID: To: William Allen Simpson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 17:12:41 -0000 On Mon, Mar 14, 2011 at 11:36 AM, William Allen Simpson wrote: > On 3/14/11 1:21 PM, William Allen Simpson wrote: >> >> Indeed, this proposal worries me about other protocol and security issue= s. >> 1) How does it handle path changes that affect options? Do you mean the network path change during a connection or in between connections? please elaborate. >> 2) How does it prevent use in DoS? The entire security consideration is all about dealing with DoS attacks. It may not be complete. Could you describe the specific attack that we do not cover? >> >> It's an OK rough draft, but needs a lot of work. > > After a little bit of thought, there are some *VERY* serious problems. > This simply won't work in a heterogeneous environment. =A0All kinds of > failure modes. =A0Moreover, I told at least 1 author and 1 listed reviewe= r > about all of them as long ago as Feb 2010.... > > =A03) The cookie isn't big enough, and there's no cookie pair. =A0The who= le > scheme isn't crytologically sound! I don't see how TFO can use cookie-pair to improve the cryptological part a= nd still achieve our goal. TFO does not share the same goal with TCPCT. > > Googlers should go back and look at my presentation, and review the slide= : > "Size Matters". =A0I remember remarking to several folks how disappointin= g > that folks were more interested in the performance than the security. :-( I did attend the talk years ago but I couldn't find the slide. Could you send me a copy? Thanks. > > =A04) Sending a new option doesn't test the ability to send SYN data. =A0= The > fact that you exchange an option doesn't tell you whether the 2nd session > will actually pass data. True > > TCPCT indicates that SYN data is successful by sending a SACK in the clie= nt > . =A0The server can cache that signal to indicate that SYN data= is > acceptable on the next session. Instead of sacking the data in SYN-ACK, why can't the client just acknowled= ge it cumulatively? > > Without a protocol signal, you end up losing the data -- o= r > worse, the whole packet might be filtered -- and sending extra data segme= nts > that will be discarded. =A0Over and over again, as the server retransmits= . Certainly any payload in SYN/SYN-ACK may got drop anytime. TFO deals with by retransmitting without the data. When this happens, the data exchange st= arts after handshake like regular TCP and TFO receive no latency benefit. > > This leads to congestive collapse! =A0That's one reason (of many) that TC= PCT > Responders never, Never, *NEVER* retransmit SYN segments! The SYN and SYN-ACK max retransmits count are still regulated by RFC1122. TFO should send the same amount of data packets as regular TCP connection. Maybe we aren't super clear in the draft but I couldn't see how this cause congestion collapse? > > =A06) There's no checking for collapsed TCP segments. =A0There are many b= oxen > out there with the damn off-loading boards or chips. =A0Who even knows wh= at > they might do with SYN data and a following segment?!?! > Could you explain what "collapsed TCP segments" are? Thanks. Yuchung From william.allen.simpson@gmail.com Tue Mar 15 11:39:16 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0F53A6B10 for ; Tue, 15 Mar 2011 11:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbTFwe5H0T1a for ; Tue, 15 Mar 2011 11:39:15 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 0A5323A6E17 for ; Tue, 15 Mar 2011 11:39:14 -0700 (PDT) Received: by iwl42 with SMTP id 42so1026346iwl.31 for ; Tue, 15 Mar 2011 11:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8+0HNF1LPnxMHfDJiGoPmuoTCg3zruDqDWCEUaOMJEU=; b=n7dC7qINddn2V71ggFuW9ydBHOYFjOLCDvVHNq6suOCa7qGbo+qZNTa1Kiv8XlhmVF qrwYvFNBhyEJ1Tjijl2k4MMrLLuKV+z4cs1Iad9xPoSV82zzGHnEGCb77pa/6OJ6GXA9 IBKKrzD9J3VF9s39QrGkt4h2Sw1vM3lSWicKE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=G2H4VzPWZR+UUe8qDCyd+jrnTTQSeRqBZjIPt7ZYMpfYvJma3qqcE9NlqyBYo+BoQt rT5K/+bH1R0FFsAkwiX2jc8OUPQC85QkhPQM/b0ItGu8BdQpVLFr4gm5KryTyEqLJo1L PBGpF2mXlirc/6R0BXdZpubvtEJSm25apz0B0= Received: by 10.42.136.68 with SMTP id s4mr2000535ict.187.1300214440308; Tue, 15 Mar 2011 11:40:40 -0700 (PDT) Received: from Wastrel-2.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id 19sm50560ibx.19.2011.03.15.11.40.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2011 11:40:39 -0700 (PDT) Message-ID: <4D7FB2A5.30908@gmail.com> Date: Tue, 15 Mar 2011 14:40:37 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: tcpm@ietf.org References: <20110315170128.08C173565F48@lawyers.icir.org> In-Reply-To: <20110315170128.08C173565F48@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 18:39:16 -0000 On 3/15/11 1:01 PM, Mark Allman wrote: > >> The initial RTO on a SYN with no history is specified as 3 seconds in >> RFC-1122. > > And in RFC2988. RFC 2988bis uses 1sec. > >> If your server sends the second segment 3 seconds after SYN data, and >> retransmits at 6 and 12 seconds, I'd be willing to suspend disbelief. >> But I'm pretty sure that's not what the draft has in mind. > > That is precisely what RFC2988 would have you do. My experience in > looking at packet traces says this is in fact what happens. I read a > pre-cursor to the fast open draft and I don't recall it changing this, > but perhaps the fast open draft does and, if so, I think it'd be dubious > and at least worthy of a bunch of skepticism. But, even without that I > seriously doubt you could show collapse. > Ah, but it's *not* what this draft would have you do, although it's not particularly clear about inter-packet timeouts: 3. Send the SYN-ACK packet acknowledging the SYN and data sequence. The server MAY include data in the SYN-ACK packet. 6. The server MAY send more data packets before the handshake completes. The maximum amount is ruled by the initial congestion window and the receiver window [RFC3390]. My reading sees *no* waiting before these packets. Certainly not 3 seconds, or even 1 second. Because with waiting, there's no reason to bother with this scheme; the client will likely arrive in 3 seconds. I'm pretty sure that's not what the draft has in mind. >> Instead, think for a moment about the other end. The Syn arrives with no >> data, the client sends an ACK. Then an out-of-sequence segment arrives, so >> the client sends an ACK. Then another out-of-sequence segment arrives, and >> the client sends an ACK. Etc. Now think about ACK clocking and duplicate >> ACK handling.... > > I have thought about this stuff a tremendous amount of the years. I > don't see what you're getting at here. As best as I can tell you have > just described TCP's standard behavior. Yes, an out of order packet > triggers an (duplicate) ACK transmission. After a few of these the > sender retransmits and slows down. What is your point? > Please go back and read the draft. They don't only send on retransmit. They can re-send the whole packet train, with no waiting. That's *not* TCP's standard behavior! N.B: the draft uses inconsistent terminology on this point: [Page 9] The network or servers may drop the SYN or SYN-ACK packets with the new cookie options which causes SYN or SYN-ACK timeouts. We RECOMMEND both the client and the server retransmit SYN and SYN-ACK without the cookie options on timeouts. [Page 10] If the SYN-ACK timer fires, the server SHOULD retransmit a SYN-ACK packet without data and Fast Open Cookie options for compatibility reasons. Instead, both places must be MUST! >> There are a bunch of Linux NICs that re-combine smaller segments into >> larger ones. Although looking at the terrible code, I'm not sure it >> ever worked. Don't know of any other releases (everybody *I* respect >> is against it). > > There are lots of things that muck with packet contents. I agree that > they need to be thought about / understood / dealt with. On the other > hand, because there exists some broken 'thing' should not necessarily > prevent forward motion. > As long as it's designed not to cause data corruption, or to detect it and fail the connection. This draft doesn't handle it. From mallman@icir.org Tue Mar 15 12:04:04 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 175543A6E65 for ; Tue, 15 Mar 2011 12:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.231 X-Spam-Level: X-Spam-Status: No, score=-106.231 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTrDkH8Jovf3 for ; Tue, 15 Mar 2011 12:04:03 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 3B6DF3A6E58 for ; Tue, 15 Mar 2011 12:04:03 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p2FJ5PkF025534; Tue, 15 Mar 2011 12:05:25 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 482303569067; Tue, 15 Mar 2011 15:05:25 -0400 (EDT) To: William Allen Simpson From: Mark Allman In-Reply-To: <4D7FB2A5.30908@gmail.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Glycerine MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma47220-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 15 Mar 2011 15:05:25 -0400 Sender: mallman@icir.org Message-Id: <20110315190525.482303569067@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 19:04:04 -0000 ----------ma47220-1 Content-Type: text/plain Content-Disposition: inline > Ah, but it's *not* what this draft would have you do, although it's not > particularly clear about inter-packet timeouts: > > 3. Send the SYN-ACK packet acknowledging the SYN and data sequence. > The server MAY include data in the SYN-ACK packet. > > 6. The server MAY send more data packets before the handshake > completes. The maximum amount is ruled by the initial congestion > window and the receiver window [RFC3390]. > > My reading sees *no* waiting before these packets. Certainly not 3 seconds, > or even 1 second. Yes, OK, but I still don't see your point. These are *not retransmits* so why would you apply the RTO? Neither of the points above pertain to the case of retransmits, so I completely don't follow your point. The point of the document is to cut out the 3WHS time [*]. So, you send the SYN+ACK and then the first window of data. That window of data is bounded (per 3390; probably should be by 5681, but same thing window-size-wise). And, at that point the host has not actually detected loss or congestion in the network. So, there is no reason to RTO or take any sort of congestion control actions. If loss is in fact detected (likely via the RTO) then backoff will kick in. [*] Note: I am not trying to strongly advocate the fast open scheme here. My complaint is that you're claiming that somehow it is leading to congestion collapse without showing how. And, in fact, I think its a dubious claim. > Please go back and read the draft. They don't only send on > retransmit. They can re-send the whole packet train, with no waiting. > That's *not* TCP's standard behavior! If they re-send the entire window then that is not standard TCP and sounds dubious at first glance. I do have a bit set to read the document. > >> There are a bunch of Linux NICs that re-combine smaller segments > >> into larger ones. Although looking at the terrible code, I'm not > >> sure it ever worked. Don't know of any other releases (everybody > >> *I* respect is against it). > > > > There are lots of things that muck with packet contents. I agree > > that they need to be thought about / understood / dealt with. On > > the other hand, because there exists some broken 'thing' should not > > necessarily prevent forward motion. > > As long as it's designed not to cause data corruption, or to detect it > and fail the connection. This draft doesn't handle it. So you're saying Fast Open is designed to cause data corruption? TCP doesn't handle all data corruption either. I could increment the first byte of every TCP payload in a middlebox and adjust the checksum accordingly and the TCP recipient would be none-the-wiser. Networks do stupid things. Application-layer validation is a good thing (being closer to the "end" and all). allman ----------ma47220-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk1/uHQACgkQWyrrWs4yIs4C5gCbBWeeiGy82dcvBMmliWDj6dFf 6ZsAoJqQ/xMZeQDMxRptwwfdSB5/dFqb =h8MS -----END PGP SIGNATURE----- ----------ma47220-1-- From hkchu@google.com Tue Mar 15 23:01:54 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8CE43A67DB for ; Tue, 15 Mar 2011 23:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.376 X-Spam-Level: X-Spam-Status: No, score=-105.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LTYZSWd2X8h for ; Tue, 15 Mar 2011 23:00:29 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 398573A67DA for ; Tue, 15 Mar 2011 22:59:00 -0700 (PDT) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id p2G60JLR011831 for ; Tue, 15 Mar 2011 23:00:19 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1300255219; bh=ayzQ5E3Bcu1wHAza7p+z/kgkUGI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=U9wETK14D6MKVUgHRm1/erYAcvkd2ANmj9FBJbtRdYxB1x3msS4qyvuGdlQEO6gAv ha1mP4px5wvDJw1N1Vtxw== Received: from qyk27 (qyk27.prod.google.com [10.241.83.155]) by kpbe16.cbf.corp.google.com with ESMTP id p2G60I9L010467 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 15 Mar 2011 23:00:18 -0700 Received: by qyk27 with SMTP id 27so1159372qyk.20 for ; Tue, 15 Mar 2011 23:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kfsyBn6GYqzmFktmlfbusSShLpTbT3GcyOWIgHqXU2A=; b=IXlUcy5sX3wjgyqlHopC2IN31MDN2E/VuC3Fjg7XzEcCB7ph37xFuQKFO5309n5gPt gVaqJyvyOXh3zzT6k/wQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CTKDb+XoRd/reSe3nBT+FY+krK6f2itK9rhy68mTzahunCjnqEIDCqh20B5tg7xG6P R/yLcwyKqoBj+iCC9bAA== MIME-Version: 1.0 Received: by 10.229.127.88 with SMTP id f24mr264887qcs.186.1300255217946; Tue, 15 Mar 2011 23:00:17 -0700 (PDT) Received: by 10.229.53.199 with HTTP; Tue, 15 Mar 2011 23:00:17 -0700 (PDT) In-Reply-To: <4D7E4EA5.80001@gmail.com> References: <20110308004501.27770.44908.idtracker@localhost> <5FDC413D5FA246468C200652D63E627A0D4F4DE1@LDCMVEXC1-PRD.hq.netapp.com> <4D7E4EA5.80001@gmail.com> Date: Tue, 15 Mar 2011 23:00:17 -0700 Message-ID: From: Jerry Chu To: William Allen Simpson Content-Type: multipart/alternative; boundary=000e0cd67116621232049e93429a X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 06:01:54 -0000 --000e0cd67116621232049e93429a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Mar 14, 2011 at 10:21 AM, William Allen Simpson < william.allen.simpson@gmail.com> wrote: > On 3/14/11 7:15 AM, Scheffenegger, Richard wrote: > >> your proposal will only address new tcp sessions preceeded by one =93nor= mal=94 >> 3WHS session setup. >> >> Yes, that's a problem. Most sessions are one-off. Especially DNSsec T= CP > queries, redirect sessions, etc. > > I'd talked to various Google folks last year about their idea to treat th= e > second session differently, and left it as an open issue for TCPCT. See > RFC-6013 Acknowledgments. For idempotent operations, that's not a proble= m. > > So, I'd view this as a follow-on draft to RFC-6013. TFO and TCPCT have distinctly different goals so I don't see how one could call it a follow-on to RFC6013. Yes we've had some discussion a year ago because after reading your then still unpublished and very sketchy draft I thought we could use TCPCT to get what we want. But after the meeting we concluded TCPCT is not suitable for us. Certainly, the second > TCPCT session could send multiple data packets (the +data, > plus additional ACK+data packets). SACK will acknowledge the SYN data, a= nd > TCP itself handle any later holes completely transparently. > > But I didn't want to add so much extra detail to TCPCT until we had a goo= d > handle on how well it worked in the field. We still don't have much data= , > mostly because Google didn't follow-up after I'd included their requested > SYN+data features.... I thought in our meeting we hit a constraint of TCPCT, which can only accommodate upto one MSS worth of response data in SYN-ACK, which was a show stopper fo= r us. Besides that the design goals/requirement of TCPCT (defense against SYN attack, server stateless, security...) were just too different than TFO and hence introducing too much complexity that we felt necessary for TFO. > > > In the draft, you mention that Chrome keeps persistent connections for u= p >> to 4 min, while 35% of the requests are made using new sessions; Now I >> wonder, what fraction of these new sessions are set up towards a server, >> where the client already had an >> earlier normal session (or, what is the fraction of persistent >> connections, that get disconnected within that 4 min timeout due to exte= rnal >> reasons such as a NAT gateways running out of resources, or into a timeo= ut=85) >> >> I'm also concerned that re-using the cookies for that long a time isn't > sufficiently secure. > > In fact, it feels like they don't really understand the underlying securi= ty > issues that are handled by cookies. We had this same problem over in the > IPsec group with ISAKMP. It's not *only* a token, it's an anti-clogging > token for preventing DoS attacks. > > Just because you stick cookies into a protocol, doesn't make it improve > security in and of itself. Security first, performance second! Unlike TCPCT, or designing a protocol for bank transaction, TFO is a performance project. Without performance there is no TFO so the design constraint for u= s is really "getting the performance without compromising security". We spent months pondering on potential security holes from TFO. (See section 6.) Obviously we may have missed some, and can benefit greatly from folks on this list. But please be specific on what we may have missed. Jerry > > > Because that 35% value above appears to throw genuinely =93new=94 sessio= ns >> (new sites) and =93lost=94 sessions (timed out, reset by intermediate de= vice or >> server etc) to a known host into the same bucket =96 unless the wording = around >> there is misleading me J >> >> Indeed, this proposal worries me about other protocol and security > issues. > 1) How does it handle path changes that affect options? > 2) How does it prevent use in DoS? > > It's an OK rough draft, but needs a lot of work. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000e0cd67116621232049e93429a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Mar 14, 2011 at 10:21 AM, William Allen Simpson &= lt;william.allen.simpson= @gmail.com> wrote:
On 3/14/11 7:15 AM, Scheffenegger, Richard wrote:
your proposal will only address new tcp sessions preceeded by one =93normal= =94 3WHS session setup.

Yes, that's a problem. =A0Most sessions are one-off. =A0Especially DNSs= ec TCP
queries, redirect sessions, etc.

I'd talked to various Google folks last year about their idea to treat = the
second session differently, and left it as an open issue for TCPCT. =A0See<= br> RFC-6013 Acknowledgments. =A0For idempotent operations, that's not a pr= oblem.

So, I'd view this as a follow-on draft to RFC-6013.
TFO and TCPCT have distinctly different goals so I don't s= ee how one could call
it a follow-on to=A0RFC6013.
=A0<= /div>
Yes we've had some discussion a year ago because after reading you= r then still
unpublished and very sketchy=A0draft=A0I thought we = could use TCPCT to get what we
want. But after the meeting we con= cluded TCPCT is not suitable for us.

Certainly, the second
TCPCT session could send multiple data packets (the <SYN,ACK(SYN)>+da= ta,
plus additional ACK+data packets). =A0SACK will acknowledge the SYN data, a= nd
TCP itself handle any later holes completely transparently.

But I didn't want to add so much extra detail to TCPCT until we had a g= ood
handle on how well it worked in the field. =A0We still don't have much = data,
mostly because Google didn't follow-up after I'd included their req= uested
SYN+data features....=A0

I thought in our m= eeting we hit a constraint of TCPCT, which can only accommodate
u= pto one=A0MSS worth of response data in SYN-ACK, which was a show stopper f= or us.
Besides that the design goals/requirement of TCPCT (defense against SY= N attack,
server stateless, security...) were just too different = than TFO and hence introducing
too much complexity that we felt n= ecessary for TFO.




In the draft, you mention that Chrome keeps persistent connections for up t= o 4 min, while 35% of the requests are made using new sessions; Now I wonde= r, what fraction of these new sessions are set up towards a server, where t= he client already had an
earlier normal session (or, what is the fraction of persistent connections,= that get disconnected within that 4 min timeout due to external reasons su= ch as a NAT gateways running out of resources, or into a timeout=85)

I'm also concerned that re-using the cookies for that long a time isn&#= 39;t
sufficiently secure.

In fact, it feels like they don't really understand the underlying secu= rity
issues that are handled by cookies. =A0We had this same problem over in the=
IPsec group with ISAKMP. =A0It's not *only* a token, it's an anti-c= logging
token for preventing DoS attacks.

Just because you stick cookies into a protocol, doesn't make it improve=
security in and of itself. =A0Security first, performance second!

Unlike TCPCT, or designing a protocol for bank trans= action, TFO is a performance
project. Without performance there i= s no TFO so the design constraint for us
is really=A0"getting the=A0performance without compromising secur= ity". We spent
months=A0pondering on potential security hole= s from TFO. (See section 6.)
Obviously we may have missed some, a= nd can benefit greatly from folks
on this list. But please be specific on what we may have missed.
=

Jerry




Because that 35% value above appears to throw genuinely =93new=94 sessions = (new sites) and =93lost=94 sessions (timed out, reset by intermediate devic= e or server etc) to a known host into the same bucket =96 unless the wordin= g around there is misleading me J

Indeed, this proposal worries me about other protocol and security issues.<= br> =A01) How does it handle path changes that affect options?
=A02) How does it prevent use in DoS?

It's an OK rough draft, but needs a lot of work.
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--000e0cd67116621232049e93429a-- From hkchu@google.com Wed Mar 16 00:16:01 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AE683A681D for ; Wed, 16 Mar 2011 00:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.676 X-Spam-Level: X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZlZ+XscYTYl for ; Wed, 16 Mar 2011 00:15:59 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C90F43A681A for ; Wed, 16 Mar 2011 00:15:58 -0700 (PDT) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id p2G7HOAM021116 for ; Wed, 16 Mar 2011 00:17:24 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1300259844; bh=kyqCxEwP2IbrIHWcON8mbFaxJ5U=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=G65F80dXBpDV/0pcBGPNeVZyRZZ6ACUvPHWAj/4YzbafzS0mtIphzCjmtQ6vTYv0/ pGVqG5ewT9GspkbaKb03w== Received: from qwc9 (qwc9.prod.google.com [10.241.193.137]) by kpbe12.cbf.corp.google.com with ESMTP id p2G7HMfM011251 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 16 Mar 2011 00:17:23 -0700 Received: by qwc9 with SMTP id 9so1447609qwc.40 for ; Wed, 16 Mar 2011 00:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YU/YEXSTsBesUQwgwfXFZFkB0gsFrApddR7qMBWXJAA=; b=N1L5eNdK3Q8dWxhgGPaDf299gHEYLGvNr1ecQ+0gWC+nlMzNss6+RD6LUskHnzUmcc c0VrKuMZtkgbR2UFdDTQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Dz2TnwtU8Tr72x7/Lm3ypN0esBJ4pUuTlFGgWf7KSkYGRR3wb3JwsIEuu5bdCak2KM L7azi9j4XmpeXfSptErg== MIME-Version: 1.0 Received: by 10.229.24.12 with SMTP id t12mr295379qcb.224.1300259842268; Wed, 16 Mar 2011 00:17:22 -0700 (PDT) Received: by 10.229.53.199 with HTTP; Wed, 16 Mar 2011 00:17:22 -0700 (PDT) In-Reply-To: <4D7FB2A5.30908@gmail.com> References: <20110315170128.08C173565F48@lawyers.icir.org> <4D7FB2A5.30908@gmail.com> Date: Wed, 16 Mar 2011 00:17:22 -0700 Message-ID: From: Jerry Chu To: William Allen Simpson Content-Type: multipart/alternative; boundary=0016364185a1039c78049e945604 X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 07:16:01 -0000 --0016364185a1039c78049e945604 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 15, 2011 at 11:40 AM, William Allen Simpson < william.allen.simpson@gmail.com> wrote: > On 3/15/11 1:01 PM, Mark Allman wrote: > >> >> The initial RTO on a SYN with no history is specified as 3 seconds in >>> RFC-1122. >>> >> >> And in RFC2988. RFC 2988bis uses 1sec. >> >> If your server sends the second segment 3 seconds after SYN data, and >>> retransmits at 6 and 12 seconds, I'd be willing to suspend disbelief. >>> But I'm pretty sure that's not what the draft has in mind. >>> >> >> That is precisely what RFC2988 would have you do. My experience in >> looking at packet traces says this is in fact what happens. I read a >> pre-cursor to the fast open draft and I don't recall it changing this, >> but perhaps the fast open draft does and, if so, I think it'd be dubious >> and at least worthy of a bunch of skepticism. But, even without that I >> seriously doubt you could show collapse. >> >> Ah, but it's *not* what this draft would have you do, although it's not > particularly clear about inter-packet timeouts: > 3. Send the SYN-ACK packet acknowledging the SYN and data sequence. > The server MAY include data in the SYN-ACK packet. > > 6. The server MAY send more data packets before the handshake > completes. The maximum amount is ruled by the initial congestion > window and the receiver window [RFC3390]. > > My reading sees *no* waiting before these packets. Certainly not 3 > seconds, > or even 1 second. Because with waiting, there's no reason to bother with > this scheme; the client will likely arrive in 3 seconds. > > I'm pretty sure that's not what the draft has in mind. > Like Mark I'm also very confused about your concern about "inter-packet timeouts" (??) These are first transmissions not REtransmissions so why would there need to be "inter-packet timeouts"? Other than allowing data to be sent in SYN-SENT and SYN-RCVD states TFO does NOT alter any TCP standard transmission/retransmission algorithms! > > Instead, think for a moment about the other end. The Syn arrives with no >>> data, the client sends an ACK. Then an out-of-sequence segment arrives, >>> so >>> the client sends an ACK. Then another out-of-sequence segment arrives, >>> and >>> the client sends an ACK. Etc. Now think about ACK clocking and >>> duplicate >>> ACK handling.... >>> >> >> I have thought about this stuff a tremendous amount of the years. I >> don't see what you're getting at here. As best as I can tell you have >> just described TCP's standard behavior. Yes, an out of order packet >> triggers an (duplicate) ACK transmission. After a few of these the >> sender retransmits and slows down. What is your point? >> >> Please go back and read the draft. They don't only send on > retransmit. They can re-send the whole packet train, with no waiting. > That's *not* TCP's standard behavior! > Please go back and read the draft and point to us where we deviate from (or even mention anything related to) the standard TCP retransmission algorithm? > N.B: the draft uses inconsistent terminology on this point: > > [Page 9] > The network or servers may drop the SYN or SYN-ACK packets with the > new cookie options which causes SYN or SYN-ACK timeouts. We RECOMMEND > both the client and the server retransmit SYN and SYN-ACK without the > cookie options on timeouts. > > [Page 10] > If the SYN-ACK timer fires, the server SHOULD retransmit a SYN-ACK > packet without data and Fast Open Cookie options for compatibility > reasons. > > Instead, both places must be MUST! We can debate on whether MUST is really necessary but why would you interpret both paragraphs above as "the server, when justified, is allowed to retransmit the WHOLE UN-ACKed data"? > > > > There are a bunch of Linux NICs that re-combine smaller segments into >>> larger ones. Although looking at the terrible code, I'm not sure it >>> ever worked. Don't know of any other releases (everybody *I* respect >>> is against it). >>> >> >> There are lots of things that muck with packet contents. I agree that >> they need to be thought about / understood / dealt with. On the other >> hand, because there exists some broken 'thing' should not necessarily >> prevent forward motion. >> >> As long as it's designed not to cause data corruption, or to detect it > and fail the connection. This draft doesn't handle it. I just don't follow your concern. Any buggy middle box or NIC offload feature can cause data corruption and any new TCP options/feature may risk some more vulnerability from buggy h/w. Why would TFO be any worse? Jerry > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0016364185a1039c78049e945604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Mar 15, 2011 at 11:40 AM, William Allen Simpson &= lt;william.allen.simpson= @gmail.com> wrote:
On 3/15/11 1:01 PM, Mark Allman wrote:

The initial RTO on a SYN with no history is specified as 3 seconds in
RFC-1122.

And in RFC2988. =A0RFC 2988bis uses 1sec.

If your server sends the second segment 3 seconds after SYN data, and
retransmits at 6 and 12 seconds, I'd be willing to suspend disbelief. But I'm pretty sure that's not what the draft has in mind.

That is precisely what RFC2988 would have you do. =A0My experience in
looking at packet traces says this is in fact what happens. =A0I read a
pre-cursor to the fast open draft and I don't recall it changing this,<= br> but perhaps the fast open draft does and, if so, I think it'd be dubiou= s
and at least worthy of a bunch of skepticism. =A0But, even without that I seriously doubt you could show collapse.

Ah, but it's *not* what this draft would have you do, although it's= not
particularly clear about inter-packet timeouts:=A0

=A0 3. Send the SYN-ACK packet acknowledging the SYN and data sequence. =A0 =A0 =A0 The server MAY include data in the SYN-ACK packet.

=A0 6. The server MAY send more data packets before the handshake
=A0 =A0 =A0 completes. The maximum amount is ruled by the initial congesti= on
=A0 =A0 =A0 window and the receiver window [RFC3390].

My reading sees *no* waiting before these packets. =A0Certainly not 3 secon= ds,
or even 1 second. =A0Because with waiting, there's no reason to bother = with
this scheme; the client <ACK(SYN)> will likely arrive in 3 seconds.= =A0


I'm pretty sure that's not what the draft has in mind.

Like Mark I'm also very confused about yo= ur concern about "inter-packet timeouts" (??)
These are= first transmissions not REtransmissions so why would there need to be
"inter-packet timeouts"?

Other than= allowing data to be sent in SYN-SENT and SYN-RCVD states TFO does
NOT alter any TCP standard transmission/retransmission algorithms!



Instead, think for a moment about the other end. =A0The Syn arrives with no=
data, the client sends an ACK. =A0Then an out-of-sequence segment arrives, = so
the client sends an ACK. =A0Then another out-of-sequence segment arrives, a= nd
the client sends an ACK. =A0Etc. =A0Now think about ACK clocking and duplic= ate
ACK handling....

I have thought about this stuff a tremendous amount of the years. =A0I
don't see what you're getting at here. =A0As best as I can tell you= have
just described TCP's standard behavior. =A0Yes, an out of order packet<= br> triggers an (duplicate) ACK transmission. =A0After a few of these the
sender retransmits and slows down. =A0What is your point?

Please go back and read the draft. They don't only send <SYN,ACK(SYN= )> on
retransmit. =A0They can re-send the whole packet train, with no waiting. That's *not* TCP's standard behavior!

Please go back and read the draft and point to us where we deviate f= rom
(or even mention anything related to) the=A0standard TCP retr= ansmission algorithm?


N.B: the draft uses inconsistent terminology on this point:

[Page 9]
=A0 The network or servers may drop the SYN or SYN-ACK packets with the =A0 new cookie options which causes SYN or SYN-ACK timeouts. We RECOMMEND<= br> =A0 both the client and the server retransmit SYN and SYN-ACK without the<= br> =A0 cookie options on timeouts.

[Page 10]
=A0 If the SYN-ACK timer fires, the server SHOULD retransmit a SYN-ACK
=A0 packet without data and Fast Open Cookie options for compatibility
=A0 reasons.

Instead, both places must be MUST!

We can d= ebate on whether MUST is really necessary but why would you interpret
=
both paragraphs above as "the server, when justified, is allowed = to retransmit the
WHOLE=A0UN-ACKed data"?
=A0



There are a bunch of Linux NICs that re-combine smaller segments into
larger ones. =A0Although looking at the terrible code, I'm not sure it<= br> ever worked. =A0Don't know of any other releases (everybody *I* respect=
is against it).

There are lots of things that muck with packet contents. =A0I agree that they need to be thought about / understood / dealt with. =A0On the other hand, because there exists some broken 'thing' should not necessari= ly
prevent forward motion.

As long as it's designed not to cause data corruption, or to detect it<= br> and fail the connection. =A0This draft doesn't handle it.
<= div>
I just don't follow your concern. Any buggy middle b= ox or NIC offload feature
can cause data corruption and any new T= CP options/feature may risk some
more vulnerability from buggy h/w.=A0Why would TFO be any worse?
=

Jerry


_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--0016364185a1039c78049e945604-- From lars.eggert@nokia.com Wed Mar 16 00:44:14 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C47833A6841 for ; Wed, 16 Mar 2011 00:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.291 X-Spam-Level: X-Spam-Status: No, score=-103.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MO+kMW-7VC0f for ; Wed, 16 Mar 2011 00:44:14 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 04ED93A6840 for ; Wed, 16 Mar 2011 00:44:13 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p2G7jbM6004126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Mar 2011 09:45:38 +0200 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97 at fit.nokia.com Content-Type: multipart/signed; boundary=Apple-Mail-16--168217994; protocol="application/pkcs7-signature"; micalg=sha1 Date: Wed, 16 Mar 2011 09:45:29 +0200 Message-Id: To: "tcpm@ietf.org Extensions" Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Wed, 16 Mar 2011 09:45:34 +0200 (EET) X-Nokia-AV: Clean Subject: [tcpm] new co-chair for TCPM X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 07:44:14 -0000 --Apple-Mail-16--168217994 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, as you know, Wes will be our new AD for the Transport Area very soon, = and will therefore need to step down as co-chair of TCPM after Prague. The current chairs and ADs have discussed this situation, and we're = pleased to report that Michael Scharf, who has been a longtime = participant in TCPM and other WGs in the area, will follow Wes as a new = co-chair for TCPM. We're adding Michael as a third chair to TCPM at this time, so he can = work with Wes and David and get up to speed. David and Michael will then = continue after Prague. Please join me in welcoming Michael to his new role. Thanks, Lars= --Apple-Mail-16--168217994 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMxNjA3NDUyOVowIwYJKoZIhvcNAQkE MRYEFKbxIBeb0uWHlRHWyKJGja7YvRZ6MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB ADSdv81Mfo9D6LKGHftJ7aZw6/vOThqOMN0XslsZU9vNomyJn55ZImuYoC/mVJ+iZCqiobv1hAVf qdWLMcXcyHhXvC2sNqYZvnHrmkn+synVfuOdriJC2jw0l7ejZ278gB+CaAIQRQej0XsMU9Jnn3DW vsC8XYi0n3+3QNNaeOBx3woLsoh9Yo0YzEEojKLd/hXp2qKD/BbwP7SKjtY12BtPew5/3QeHICnX B8GzhCZ7fOp97ekzv0rZtr2HrdI6bN/SDrDYF06duSYYwyo2XSqaRcu4INl8rc+r556rtTN0iHBR d1w2QRPJTOTTJc9at/VA8ZJ/KWEK+Gz1LjDuKOgAAAAAAAA= --Apple-Mail-16--168217994-- From michawe@ifi.uio.no Wed Mar 16 02:33:12 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F4413A68DA for ; Wed, 16 Mar 2011 02:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otNZ2mYR64kT for ; Wed, 16 Mar 2011 02:33:05 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id 902003A68D9 for ; Wed, 16 Mar 2011 02:33:03 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out1.uio.no with esmtp (Exim 4.72) (envelope-from ) id 1Pzn7d-0005bc-0y for tcpm@ietf.org; Wed, 16 Mar 2011 10:34:29 +0100 Received: from 1x-193-157-199-151.uio.no ([193.157.199.151]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1Pzn7b-0004pm-Nh for tcpm@ietf.org; Wed, 16 Mar 2011 10:34:28 +0100 From: michawe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Mar 2011 10:34:26 +0100 Message-Id: To: tcpm@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 7 sum msgs/h 4 total rcpts 7537 max rcpts/h 36 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 7325AE3411A4BF3978F748CB6FD830A654867276 X-UiO-SPAM-Test: remote_host: 193.157.199.151 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 24 max/h 4 blacklist 0 greylist 0 ratelimit 0 Subject: [tcpm] Using the ECN Nonce to detect spurious loss events X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 09:33:12 -0000 Hi all, This is about an idea that I've been carrying around with me for a long = time now. The plan was to continue the work - which is so far only based = on simulations - with a real-life implementation, and then one day write = a draft and suggest it to TCPM... but, having treated this as a = low-priority item because of the ECN Nonce's shaky situation, time = worked against me, and now I find myself wondering whether I should = continue this at all or simply dump it. So I'd like to ask what the = group thinks - continue or dump? The idea is to update RFC 3540 (ECN Signaling with Nonces) to include a = method for spurious loss event detection. Here's how it works: Say, we send a packet, and expect the nonce sum to be 1 in return. The = packet is lost, we retransmit =3D> this retransmission carries no nonce = (by definition). The nonce sum in the ACK that was caused by this = retransmitted packet should then be 0. So, if we get an ACK for the = retransmitted packet which carries the nonce sum 1, this indicates that = the loss event that led to this retransmission was spurious. We probably can't rely on the receiver to send a 0 nonce sum on all ACKs = that are caused by packets carrying no nonce; also, if the above is the = only check done, a receiver would have a 50% chance of tricking a sender = into believing that a loss event was spurious, thereby eliminating the = very benefit that the nonce provides. We therefore have to wait for a = sequence of correct nonce sums to come back - e.g. 4 would already give = a reliability of around 94% (i.e. the receiver has a 6% chance of = lying). I see this mechanism as complementary to the other spurious loss event = detection schemes (minus Eifel, of course) - it would sometimes kick in = when the others don't. One of the nice things about it is that it seems = to be easy to implement: it doesn't change anything about the nonce = specification on the wire, it only adds a little more intelligence to = how we interpret the nonce sums that come back. I have a small page about this here: http://heim.ifi.uio.no/~michawe/research/projects/spurious/index.html where you can get the Globecom'08 paper that gives more details, and an = updated implementation of the ECN Nonce for the Linux kernel (that was = preparatory work towards a real-life implementation of the mechanism). Of course, the big problem with this whole scheme is that it is based on = the ECN Nonce, which is (it seems to me) probably going to be eliminated = by conex (for a cause that I personally consider more valuable than the = combination of the ECN nonce + my scheme). So - dump? Opinions? Cheers, Michael From yoshifumi.nishida@gmail.com Wed Mar 16 03:49:25 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C302D3A690B for ; Wed, 16 Mar 2011 03:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.902 X-Spam-Level: X-Spam-Status: No, score=-102.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEGnYeQrneYA for ; Wed, 16 Mar 2011 03:49:25 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id DC80C3A68C2 for ; Wed, 16 Mar 2011 03:49:24 -0700 (PDT) Received: by gyf3 with SMTP id 3so733282gyf.31 for ; Wed, 16 Mar 2011 03:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pD4KGzX9BTT+MPY3X2Te85Em1i/QFYoGHx0xRXcVw5s=; b=qYefTUg1SPdAP+vQXNSV4TmEC5MQ+7kq5vGWkhYcJmM4Qcb6ROoMXqpD4XbtT9Lfx2 A3JkzmqcsS1OTV4AESmhgvH4V9L6V1bIAyKmaXgdk9zCceg3u6lFlfxkTZ2NcZtJ7som CK1mctYPOI111qF45Pf7O7a9twa403H3sF5ss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=b0hqlNVM4NL0SxFXFYT+7vrwGObt6aqEi68Kw6o2FzgFyYdxksaUw3N3zl3rTonGUw yZrs1m4dKPCH3gEqxfnwahRXaswMrlH7miPekdY8ipNP6QmlgM6HvBEGUAlPT1uxbpW9 Vm8l21LDg5f54qwWy0fIAQfzUKX5KwrMshzF0= MIME-Version: 1.0 Received: by 10.151.15.7 with SMTP id s7mr1302262ybi.57.1300272650884; Wed, 16 Mar 2011 03:50:50 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.147.171.12 with HTTP; Wed, 16 Mar 2011 03:50:50 -0700 (PDT) In-Reply-To: References: <20110308004501.27770.44908.idtracker@localhost> Date: Wed, 16 Mar 2011 03:50:50 -0700 X-Google-Sender-Auth: URlyEEV-jPBZYVZa7Ucpb2XGbZE Message-ID: From: Yoshifumi Nishida To: Yuchung Cheng Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Arvind Jain , Mike Belshe , "tcpm@ietf.org Extensions" , Sivasankar Radhakrishnan Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 10:49:25 -0000 Hello Yuchung, A naive question.. why not setting small value for keep alive interval? -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/3/11 Yuchung Cheng : > Hi folks, > We are proposing a new draft called TCP Fast Open (TFO) which allows data > exchange to begin in TCP handshake to improve performance. > We would like to gather some comments before we present it in the next tc= pm > meeting in Prague. The presentation will also include some performance > numbers based on our beta implementation in Linux and the Chrome browser. > Thanks, > Yuchung > ---------- Forwarded message ---------- > From: > Date: Mon, Mar 7, 2011 at 4:45 PM > Subject: I-D Action:draft-cheng-tcpm-fastopen-00.txt > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : TCP Fast Open > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Y. Cheng, et al. > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-cheng-tcpm-fastopen-00.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 17 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-03-07 > > TCP Fast Open (TFO) allows data to be carried in the SYN or SYN-ACK > packets and consumed by the receiving end during the initial > connection handshake, thus providing a saving of up to one full round > trip time (RTT) compared to standard TCP requiring a three-way > handshake (3WHS) to complete before data can be exchanged. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-cheng-tcpm-fastopen-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > From rs@netapp.com Wed Mar 16 05:05:53 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D8D63A697E for ; Wed, 16 Mar 2011 05:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sF+amVhAykpb for ; Wed, 16 Mar 2011 05:05:51 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id 3F5513A6977 for ; Wed, 16 Mar 2011 05:05:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,193,1299484800"; d="scan'208";a="246014529" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 16 Mar 2011 05:07:16 -0700 Received: from ldcrsexc1-prd.hq.netapp.com (ldcrsexc1-prd.hq.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p2GC7Fct003280; Wed, 16 Mar 2011 05:07:16 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Mar 2011 12:06:01 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Mar 2011 12:05:45 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0D5F20BE@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Using the ECN Nonce to detect spurious loss events Thread-Index: AcvjvYRhw1JwKBv9RXCQu+o3Yu8eSwAC12Ew References: From: "Scheffenegger, Richard" To: "michawe" , X-OriginalArrivalTime: 16 Mar 2011 12:06:01.0056 (UTC) FILETIME=[842FE600:01CBE3D2] Subject: Re: [tcpm] Using the ECN Nonce to detect spurious loss events X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 12:05:53 -0000 Hi Michael, I believe that your goal is very worthwhile - detecting spurious = retransmissions and fixing the CC reaction. But neither ECN nor ECN-nounce are very widely deployed (in comparison = with Timestamp - Eifel; SACK - DSACK). Hopefully, the state of ECN will = improve with IPv6 (and now, that a number of major OS allow enabling = ECN, even though it's not enabled by default). However, as the number of SACK (DSACK) enabled sessions is already quite = high, and there is less (no) state required in the server to = discriminate spurious retransmissions with very high probability. I = think documenting the proper response to DSACK (only the signaling is = currently documented, IIRC) may be more valuable to drive adoption with = commercial stacks - often stacks actively signal DSACK, but don't = process that feedback themselves... Overall, I'm afraid I don't see that efforts to improve your scheme = would see much deployment because of all these reasons. On a related topic, I would like to hear your and the groups feedback on = the (sketchy) draft around TCP timestamp negotiation - when in use with = SACK, it asks for immediate, unconditional reflection of the last = received timestamp on the receiver side. This allows the unwind of = misdirected CC reaction to be done faster than the RTT of the = retransmission (current timestamp / DSACK can only signal back the = spurious retransmission 1 RTT after the spurious retransmission, but not = 1 RTT (+reorder delay) after the original segment). (The other main features this signaling would allow are one-way-delay = variance measurements, and also faster lost retransmission detection = (than Linux; not a IETF RFC yet) without violating packet conservation = principles, plus provide a means of transparently allowing integrity = checks of timestamps without breaking timestamp-based algorithms). http://www.ietf.org/id/draft-scheffenegger-tcpm-timestamp-negotiation-01.= txt Best regards, Richard Scheffenegger > -----Original Message----- > From: michawe [mailto:michawe@ifi.uio.no] > Sent: Mittwoch, 16. M=E4rz 2011 10:34 > To: tcpm@ietf.org > Subject: [tcpm] Using the ECN Nonce to detect spurious loss events >=20 > Hi all, >=20 > This is about an idea that I've been carrying around with me for a = long > time now. The plan was to continue the work - which is so far only > based on simulations - with a real-life implementation, and then one > day write a draft and suggest it to TCPM... but, having treated this = as > a low-priority item because of the ECN Nonce's shaky situation, time > worked against me, and now I find myself wondering whether I should > continue this at all or simply dump it. So I'd like to ask what the > group thinks - continue or dump? >=20 > The idea is to update RFC 3540 (ECN Signaling with Nonces) to include = a > method for spurious loss event detection. >=20 > Here's how it works: > Say, we send a packet, and expect the nonce sum to be 1 in return. The > packet is lost, we retransmit =3D> this retransmission carries no = nonce > (by definition). The nonce sum in the ACK that was caused by this > retransmitted packet should then be 0. So, if we get an ACK for the > retransmitted packet which carries the nonce sum 1, this indicates = that > the loss event that led to this retransmission was spurious. >=20 > We probably can't rely on the receiver to send a 0 nonce sum on all > ACKs that are caused by packets carrying no nonce; also, if the above > is the only check done, a receiver would have a 50% chance of tricking > a sender into believing that a loss event was spurious, thereby > eliminating the very benefit that the nonce provides. We therefore = have > to wait for a sequence of correct nonce sums to come back - e.g. 4 > would already give a reliability of around 94% (i.e. the receiver has = a > 6% chance of lying). >=20 > I see this mechanism as complementary to the other spurious loss event > detection schemes (minus Eifel, of course) - it would sometimes kick = in > when the others don't. One of the nice things about it is that it = seems > to be easy to implement: it doesn't change anything about the nonce > specification on the wire, it only adds a little more intelligence to > how we interpret the nonce sums that come back. >=20 > I have a small page about this here: > http://heim.ifi.uio.no/~michawe/research/projects/spurious/index.html > where you can get the Globecom'08 paper that gives more details, and = an > updated implementation of the ECN Nonce for the Linux kernel (that was > preparatory work towards a real-life implementation of the mechanism). >=20 > Of course, the big problem with this whole scheme is that it is based > on the ECN Nonce, which is (it seems to me) probably going to be > eliminated by conex (for a cause that I personally consider more > valuable than the combination of the ECN nonce + my scheme). So - = dump? > Opinions? >=20 > Cheers, > Michael >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michawe@ifi.uio.no Wed Mar 16 05:43:16 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C6FC3A6977 for ; Wed, 16 Mar 2011 05:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CgwpOgOWi9i for ; Wed, 16 Mar 2011 05:43:15 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id 48E383A67F1 for ; Wed, 16 Mar 2011 05:43:15 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.72) (envelope-from ) id 1Pzq5h-0000m7-5e; Wed, 16 Mar 2011 13:44:41 +0100 Received: from 1x-193-157-199-151.uio.no ([193.157.199.151]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1Pzq5g-0008Ce-Kq; Wed, 16 Mar 2011 13:44:41 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: michawe In-Reply-To: <5FDC413D5FA246468C200652D63E627A0D5F20BE@LDCMVEXC1-PRD.hq.netapp.com> Date: Wed, 16 Mar 2011 13:44:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1D773EAD-B091-4A25-85F9-292863790AFD@ifi.uio.no> References: <5FDC413D5FA246468C200652D63E627A0D5F20BE@LDCMVEXC1-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1082) X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 4 sum rcpts/h 9 sum msgs/h 8 total rcpts 7556 max rcpts/h 36 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 75E430FAC836D59E34D38F252B56174F3F3C271D X-UiO-SPAM-Test: remote_host: 193.157.199.151 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 42 max/h 6 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm@ietf.org Subject: Re: [tcpm] Using the ECN Nonce to detect spurious loss events X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 12:43:16 -0000 On Mar 16, 2011, at 1:05 PM, Scheffenegger, Richard wrote: > Hi Michael, >=20 > I believe that your goal is very worthwhile - detecting spurious = retransmissions and fixing the CC reaction. >=20 > But neither ECN nor ECN-nounce are very widely deployed (in comparison = with Timestamp - Eifel; SACK - DSACK). Hopefully, the state of ECN will = improve with IPv6 (and now, that a number of major OS allow enabling = ECN, even though it's not enabled by default). ... but if conex grabs the ecn nonce, they grab it for both ipv4 and = ipv6 I suppose. >=20 > However, as the number of SACK (DSACK) enabled sessions is already = quite high, and there is less (no) state required in the server to = discriminate spurious retransmissions with very high probability. I = think documenting the proper response to DSACK (only the signaling is = currently documented, IIRC) may be more valuable to drive adoption with = commercial stacks - often stacks actively signal DSACK, but don't = process that feedback themselves... rfc 3708 seems to take care of what you describe here. while i think = that this is a good thing to implement, it has the disadvantage of = having to wait for a duplicate to arrive at the receiver, which can = delay the reaction. > Overall, I'm afraid I don't see that efforts to improve your scheme = would see much deployment because of all these reasons. >=20 >=20 > On a related topic, I would like to hear your and the groups feedback = on the (sketchy) draft around TCP timestamp negotiation - when in use = with SACK, it asks for immediate, unconditional reflection of the last = received timestamp on the receiver side. This allows the unwind of = misdirected CC reaction to be done faster than the RTT of the = retransmission (current timestamp / DSACK can only signal back the = spurious retransmission 1 RTT after the spurious retransmission, but not = 1 RTT (+reorder delay) after the original segment). >=20 > (The other main features this signaling would allow are one-way-delay = variance measurements, and also faster lost retransmission detection = (than Linux; not a IETF RFC yet) without violating packet conservation = principles, plus provide a means of transparently allowing integrity = checks of timestamps without breaking timestamp-based algorithms). >=20 > = http://www.ietf.org/id/draft-scheffenegger-tcpm-timestamp-negotiation-01.t= xt I read this now. Style wise, I think that it's tough to read, a lot of = things could just be expressed in simpler ways, probably by reducing the = number of hints regarding possible usage. I like the general idea. I think it's probably useful to extend TCP's = timestamp handling in this manner, but I also think that the right point = in time to extend it is when you can also propose a specific usage for = this extension. Like LEDBAT: if a part of the idea is to use this for incorporating = LEDBAT congestion control in TCP, why not write this in the draft, as = one concrete example application (with full detail, so that it can = actually be implemented) of your extended signaling? Cheers, Michael From william.allen.simpson@gmail.com Wed Mar 16 06:03:27 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEFE83A6984 for ; Wed, 16 Mar 2011 06:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tR-8CSyMGQ5q for ; Wed, 16 Mar 2011 06:03:27 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 2246B3A657C for ; Wed, 16 Mar 2011 06:03:27 -0700 (PDT) Received: by iyi12 with SMTP id 12so1961320iyi.31 for ; Wed, 16 Mar 2011 06:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7s+fjBKA6FmMRjFp1bAUeYcHgeZ4ahgFJTZkkixRAe0=; b=t/7QwmhAEY9FZuj5LKV17qLSP1oJNyhPTY1vh3LG4BQe9cULFQeehn9VPn3IyFg7Se WbzJMV4NgU2l8rV13cxpvx2zpys0ua5qaLuZyzK8b/0+QNwY2n0RLXH4WHkxTB+g6yme pbu6HCz8uue8pqxwNNOGZP3NL5c5Kn/p6DAc8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=IXWnTEfACwGPT+bYnlqiZjwtulIzV3X2OltoQ4fBymMY94GQ9HGd+LjpvXiox69w48 E0b18Lxcg6rUBIOoXXpf+9bijjaqgrNWdE2E6ptF918fWQeShCi7BwydAiBFeXqErC5I kUTJ53p0d3flx38iejfFEfK5/P56FAeb39fFc= Received: by 10.42.139.197 with SMTP id h5mr931614icu.243.1300280693520; Wed, 16 Mar 2011 06:04:53 -0700 (PDT) Received: from Wastrel-2.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id 19sm670227ibx.7.2011.03.16.06.04.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Mar 2011 06:04:52 -0700 (PDT) Message-ID: <4D80B572.8090707@gmail.com> Date: Wed, 16 Mar 2011 09:04:50 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: tcpm@ietf.org References: <20110308004501.27770.44908.idtracker@localhost> <5FDC413D5FA246468C200652D63E627A0D4F4DE1@LDCMVEXC1-PRD.hq.netapp.com> <4D7E4EA5.80001@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 13:03:28 -0000 On 3/16/11 2:00 AM, Jerry Chu wrote: > TFO and TCPCT have distinctly different goals so I don't see how one could call > it a follow-on to RFC6013. > Yes we've had some discussion a year ago because after reading your then still > unpublished and very sketchy draft I thought we could use TCPCT to get what we > want. But after the meeting we concluded TCPCT is not suitable for us. > Thank you for clarifying. I misunderstood our prior communications, and your actions on joining the private TCPCT developers list. I was unaware that Google had decided to go its own way, and had been waiting for various other parties to complete their work. TCPCT as a specification has been stable and fully specified for over a year! Rather than continuing to wait, I'll post my own competing variant of this proposal as a follow-on to TCPCT for comparison and discussion, as soon as I've some spare hours. However, I do not view flooding data on the second connection as important as reducing all latency by including data on the first connection (and all subsequent connections). Much more bang for the buck! The fact that your proposal does not test whether SYN data works *before* flooding the data is a serious flaw, as it will in many cases actually increase the number of RTT. First do no harm.... I do not consider sacrificing reliability and security for performance a good trade. Moreover, this impedes ever adding any other TCP option ever again. This actively prevents inclusion of options approved by the IETF and this group over the past few years. From rs@netapp.com Wed Mar 16 06:18:53 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97ACF3A695B for ; Wed, 16 Mar 2011 06:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyuOuIlAQUpk for ; Wed, 16 Mar 2011 06:18:52 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id 68CEE3A693D for ; Wed, 16 Mar 2011 06:18:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,194,1299484800"; d="scan'208";a="246021892" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 16 Mar 2011 06:20:18 -0700 Received: from ldcrsexc2-prd.hq.netapp.com (ldcrsexc2-prd.hq.netapp.com [10.65.251.110]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p2GDDvhp015033; Wed, 16 Mar 2011 06:13:57 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Mar 2011 13:13:56 +0000 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 Date: Wed, 16 Mar 2011 13:13:42 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0D5F2140@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <1D773EAD-B091-4A25-85F9-292863790AFD@ifi.uio.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Using the ECN Nonce to detect spurious loss events Thread-Index: Acvj1+8bW9aI5eQjRbaabU4VDwF54QAAETNQ References: <5FDC413D5FA246468C200652D63E627A0D5F20BE@LDCMVEXC1-PRD.hq.netapp.com> <1D773EAD-B091-4A25-85F9-292863790AFD@ifi.uio.no> From: "Scheffenegger, Richard" To: "michawe" X-OriginalArrivalTime: 16 Mar 2011 13:13:56.0964 (UTC) FILETIME=[019E1A40:01CBE3DC] Cc: tcpm@ietf.org Subject: Re: [tcpm] Using the ECN Nonce to detect spurious loss events X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 13:18:53 -0000 Hi Michael, =20 > rfc 3708 seems to take care of what you describe here. while i think > that this is a good thing to implement, it has the disadvantage of > having to wait for a duplicate to arrive at the receiver, which can > delay the reaction. Yes, somehow I seem to have missed that rfc. Unless you have some unique signal that is conveyed in each sent segment, the best reaction time will be 1 RTT after the (spurious) retransmission. With a unique signal (like ECN nonce or timestamps (or packet size?), 1RTT (+reorder delay) of the original segment is the minimum reaction time. >=20 > I read this now. Style wise, I think that it's tough to read, a lot of > things could just be expressed in simpler ways, probably by reducing > the number of hints regarding possible usage. Fully agreed - this is still a very sketchy draft at this time; the hints on possible use cases are there to move them later into separate sections. We didn't want to put in too much possible signaling for which no current foreseeable use case exists (ie. moved the clock resolution range negotiation to annex A, from the -00 version, and got rid of a number of possible redundant/unnecessary flags - ie BIAs, MIRror). Does the negotiable range of clock rates between ~16 sec and ~8ns (down to 8ps with reduced precision) sound reasonable enough, and is the precision of a binary16 float good enough? Except for the bias and the removal of special numbers (NaN/infinity), the format is like a IEEE binary16, so I hope conversion can be made easy (simple stacks may just insert a fixed value and negotiate for the modified TS reflection behavior, without using the information from the other host). The mask is now defined with bit-precision, allowing up to 31 bits of the timestamp to be masked (limiting the value of timestamps for PAWS very much :); personally, I think only up to 12 bits make some sense for integrity checking while maintaining the usefulness of timestamps to existing algorithms, but nibble-precision was seen as being too coarse. >=20 > I like the general idea. I think it's probably useful to extend TCP's > timestamp handling in this manner, but I also think that the right > point in time to extend it is when you can also propose a specific > usage for this extension. > Like LEDBAT: if a part of the idea is to use this for incorporating > LEDBAT congestion control in TCP, why not write this in the draft, as > one concrete example application (with full detail, so that it can > actually be implemented) of your extended signaling? Actually, I had a model like RFC2018 / RFC3517 in mind - disentangle the signaling from the algorithms making use of it.=20 Putting all the already investigated algorithms making use of such an enhancement into one draft (ie. TCP Chirp, TCP LEDBAT, [TCP CUBIC interaction w/ timestamps], fast-LRD, (eifel-style) spurious retransmission detection/response) would make this a very lengthy and needlessly complex draft. Besides, there may be other useful properties (ie, a low bitrate, unreliable channel in the masked TS bits) which could be put to other good use... I would rather go with a section for use cases, referencing the (existing) RFCs/papers, and only giving hints how the improved signaling can help in those algorithms. However, this is currently completely missing from the draft due to it's very early stage. >=20 > Cheers, > Michael >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michawe@ifi.uio.no Wed Mar 16 06:34:35 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 625733A693D for ; Wed, 16 Mar 2011 06:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMMZ1aDHALrg for ; Wed, 16 Mar 2011 06:34:34 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id A2DC93A68E5 for ; Wed, 16 Mar 2011 06:34:33 -0700 (PDT) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out1.uio.no with esmtp (Exim 4.72) (envelope-from ) id 1PzqtL-0007N0-Qb; Wed, 16 Mar 2011 14:35:59 +0100 Received: from 1x-193-157-199-151.uio.no ([193.157.199.151]) by mail-mx5.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1PzqtL-0000Yq-7B; Wed, 16 Mar 2011 14:35:59 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: michawe In-Reply-To: <5FDC413D5FA246468C200652D63E627A0D5F2140@LDCMVEXC1-PRD.hq.netapp.com> Date: Wed, 16 Mar 2011 14:35:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2BCBD479-5BE1-44F9-93B4-CD2FA107D75E@ifi.uio.no> References: <5FDC413D5FA246468C200652D63E627A0D5F20BE@LDCMVEXC1-PRD.hq.netapp.com> <1D773EAD-B091-4A25-85F9-292863790AFD@ifi.uio.no> <5FDC413D5FA246468C200652D63E627A0D5F2140@LDCMVEXC1-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1082) X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 5 sum rcpts/h 10 sum msgs/h 8 total rcpts 7563 max rcpts/h 36 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A82C6E7D6FD6DF4B9ADF2EDD726AEA653476046C X-UiO-SPAM-Test: remote_host: 193.157.199.151 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 48 max/h 6 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm@ietf.org Subject: Re: [tcpm] Using the ECN Nonce to detect spurious loss events X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 13:34:35 -0000 On Mar 16, 2011, at 2:13 PM, Scheffenegger, Richard wrote: >=20 > Hi Michael, >=20 >=20 >> rfc 3708 seems to take care of what you describe here. while i think >> that this is a good thing to implement, it has the disadvantage of >> having to wait for a duplicate to arrive at the receiver, which can >> delay the reaction. >=20 >=20 > Yes, somehow I seem to have missed that rfc. Unless you have some = unique > signal that is conveyed in each sent segment, the best reaction time > will be 1 RTT after the (spurious) retransmission. With a unique = signal > (like ECN nonce or timestamps (or packet size?), 1RTT (+reorder delay) > of the original segment is the minimum reaction time. AFAIK this is only the minimum reaction time for DSACK. I think that all = other schemes - Eifel, F-RTO and my scheme - can react upon receiving an = ACK that was caused by the original packet, yet received after = retransmitting it. >> I read this now. Style wise, I think that it's tough to read, a lot = of >> things could just be expressed in simpler ways, probably by reducing >> the number of hints regarding possible usage. >=20 > Fully agreed - this is still a very sketchy draft at this time; the > hints on possible use cases are there to move them later into separate > sections. We didn't want to put in too much possible signaling for = which > no current foreseeable use case exists (ie. moved the clock resolution > range negotiation to annex A, from the -00 version, and got rid of a > number of possible redundant/unnecessary flags - ie BIAs, MIRror). >=20 > Does the negotiable range of clock rates between ~16 sec and ~8ns = (down > to 8ps with reduced precision) sound reasonable enough, and is the > precision of a binary16 float good enough? Except for the bias and the > removal of special numbers (NaN/infinity), the format is like a IEEE > binary16, so I hope conversion can be made easy (simple stacks may = just > insert a fixed value and negotiate for the modified TS reflection > behavior, without using the information from the other host). (that's for someone with more knowledge about these things to answer) >=20 > The mask is now defined with bit-precision, allowing up to 31 bits of > the timestamp to be masked (limiting the value of timestamps for PAWS > very much :); personally, I think only up to 12 bits make some sense = for > integrity checking while maintaining the usefulness of timestamps to > existing algorithms, but nibble-precision was seen as being too = coarse. >=20 >>=20 >> I like the general idea. I think it's probably useful to extend TCP's >> timestamp handling in this manner, but I also think that the right >> point in time to extend it is when you can also propose a specific >> usage for this extension. >> Like LEDBAT: if a part of the idea is to use this for incorporating >> LEDBAT congestion control in TCP, why not write this in the draft, as >> one concrete example application (with full detail, so that it can >> actually be implemented) of your extended signaling? >=20 >=20 > Actually, I had a model like RFC2018 / RFC3517 in mind - disentangle = the > signaling from the algorithms making use of it.=20 > Putting all the already investigated algorithms making use of such an > enhancement into one draft (ie. TCP Chirp, TCP LEDBAT, [TCP CUBIC > interaction w/ timestamps], fast-LRD, (eifel-style) spurious > retransmission detection/response) would make this a very lengthy and > needlessly complex draft. I also think that, among the schemes you mention here, only LEDBAT is = soon going to be an RFC - so that would make it a matter of only = explaining this one as an example, and mentioning the others as possible = other mechanisms where your signaling could be used. One difference = between this and the 2018/3517 case is that RFC 3517 is about 10 times = as long as I think the "and here's how to apply this for LEDBAT" section = could be (just 1-2 paragraphs perhaps?). Another reason is that such a = use case might just make the document easier to understand. In RFC 2018 = it's extremely clear why the specification is in fact useful; in your = document this now looks like nebulous handwaving to me, which it = wouldn't have to. But that's just my opinion... > Besides, there may be other useful properties (ie, a low bitrate, > unreliable channel in the masked TS bits) which could be put to other > good use... but saying "this is how to use this for LEDBAT" in one section doesn't = exclude these possible future uses at all. Cheers, Michael From rs@netapp.com Wed Mar 16 07:39:01 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 909983A6911 for ; Wed, 16 Mar 2011 07:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XaHEHsR0636 for ; Wed, 16 Mar 2011 07:39:00 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id D32EE3A6954 for ; Wed, 16 Mar 2011 07:38:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,194,1299484800"; d="scan'208";a="246044662" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 16 Mar 2011 07:40:25 -0700 Received: from ldcrsexc1-prd.hq.netapp.com (emeaexchrs.hq.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p2GEePYV002948; Wed, 16 Mar 2011 07:40:25 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Mar 2011 14:40:25 +0000 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 Date: Wed, 16 Mar 2011 14:40:10 -0000 Message-ID: <5FDC413D5FA246468C200652D63E627A0D5F21F6@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <4D80B572.8090707@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt Thread-Index: Acvj2sClrOcTGxkJShKM1Fcj/g/eUwAAbZxQ References: <20110308004501.27770.44908.idtracker@localhost> <5FDC413D5FA246468C200652D63E627A0D4F4DE1@LDCMVEXC1-PRD.hq.netapp.com> <4D7E4EA5.80001@gmail.com> <4D80B572.8090707@gmail.com> From: "Scheffenegger, Richard" To: "William Allen Simpson" , X-OriginalArrivalTime: 16 Mar 2011 14:40:25.0174 (UTC) FILETIME=[16081F60:01CBE3E8] Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 14:39:01 -0000 Richard Scheffenegger >=20 > However, I do not view flooding data on the second connection as > important as reducing all latency by including data on the first > connection (and all subsequent connections). Much more bang for > the buck! Ever since browsers were allowed to use multiple connections, stepping back from their use puts your session(s) at a disadvantage... this behavior is questionable/discussionable, but never the less, fact. =20 > The fact that your proposal does not test whether SYN data works > *before* > flooding the data is a serious flaw, as it will in many cases actually > increase the number of RTT. First do no harm.... Yes, you loose either the data contents of the SYN-flagged segments (1 RTT for recovery), of the full initial flight (also 1 RTT, but more troublesome to the network). > I do not consider sacrificing reliability and security for performance > a good trade. > Moreover, this impedes ever adding any other TCP option ever again. > This actively prevents inclusion of options approved by the IETF and this > group over the past few years. What did I miss here again? The Cookie is 4..16 bytes in size - the option 6..18; What prevents me from using smaller cookies when I want to use other options too? (MSS+WS+SACK+TS has the very same issue today also). Best regards, Richard From arvind@google.com Mon Mar 14 09:27:03 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9A03A6A06 for ; Mon, 14 Mar 2011 09:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h24z-IgvSDbx for ; Mon, 14 Mar 2011 09:27:02 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 1EE153A6957 for ; Mon, 14 Mar 2011 09:27:01 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p2EGSOLY021189 for ; Mon, 14 Mar 2011 09:28:24 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1300120105; bh=mz2hD6FP4LrsIOQjW+rCTeVJZ9I=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=hxNlW3fgd5lbZWh9376zcmGAiCMUzYcgF7/gU+YWC3LmVp17Z81AjpUAt4iiSAlXU otyiLYZbMLvUI3A/E7iBQ== Received: from pvf33 (pvf33.prod.google.com [10.241.210.97]) by hpaq13.eem.corp.google.com with ESMTP id p2EGS7U3020154 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 14 Mar 2011 09:28:22 -0700 Received: by pvf33 with SMTP id 33so1223002pvf.24 for ; Mon, 14 Mar 2011 09:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Euy0wo8tMEQBBCulfJsVSmCyDee8jn5fIwUBdZwTqP0=; b=hnKZ0LLRrivIKyuv4BcVzkdIQED0fFEto3hYLUddGI7qu6kwCGxLhiUTLbzjDJgmPa r4pdBnZGDHC+mmYc4IAw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=B5c88n1EcDPTeN2QpUli2ptkKKVnraZnf0VxuuxQnKq/qfeVbWG/o2+3U4ZSL+nw1b 9bI1KDi12Nwyg+KRalQg== MIME-Version: 1.0 Received: by 10.142.223.6 with SMTP id v6mr10719469wfg.4.1300120102385; Mon, 14 Mar 2011 09:28:22 -0700 (PDT) Received: by 10.143.163.13 with HTTP; Mon, 14 Mar 2011 09:28:22 -0700 (PDT) In-Reply-To: <20110314162033.931833536351@lawyers.icir.org> References: <5FDC413D5FA246468C200652D63E627A0D4F4DE1@LDCMVEXC1-PRD.hq.netapp.com> <20110314162033.931833536351@lawyers.icir.org> Date: Mon, 14 Mar 2011 09:28:22 -0700 Message-ID: From: Arvind Jain To: mallman@icir.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Mailman-Approved-At: Wed, 16 Mar 2011 08:16:43 -0700 Cc: Mike Belshe , tcpm@ietf.org, Sivasankar Radhakrishnan Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 16:28:26 -0000 Thanks Mark. Re. 4 mins timeout on the browser for keeping persistent connections, note that this proposal doesn't require you to have an established connection to do the fast open. We can do fast open as long as the client has a cookie cached from the server. The eviction time for that could be much longer. Arvind On Mon, Mar 14, 2011 at 9:20 AM, Mark Allman wrote: > >> Now I wonder, what fraction of these new sessions are set up towards a >> server, where the client already had an earlier normal session > > Well, I grabbed a connection log from yesterday for a monitoring point > that watches a fiber-to-the-home setup that serves 100 houses in > Cleveland, OH to test this out. =A0(Nothing magic here ... it just > happened to be handy data.) =A0For each outgoing TCP connection I looked > at whether there was a previous connection from the current source host > to the current destination host within the last [threshold] seconds. > The results for various thresholds: > > =A0 =A0 =A0 =A0 =A0 =A030sec =A0 =A0 =A060sec =A0 =A0 =A0120sec =A0 =A0 = =A0180sec =A0 =A0 =A0240sec =A0 =A0 =A0Inf > -------------------------------------------------------------------------= ---- > Total =A0 =A0 =A0 15.3M =A0 =A0 =A015.3M =A0 =A0 =A015.3M =A0 =A0 =A0 15.= 3M =A0 =A0 =A0 15.3M =A0 =A0 =A0 15.3M > Prev =A0 =A0 =A0 =A0 5.1M =A0 =A0 =A0 6.1M =A0 =A0 =A0 7.2M =A0 =A0 =A0 = =A07.8M =A0 =A0 =A0 =A08.2M =A0 =A0 =A0 15.1M > NoPrev =A0 =A0 =A010.1M =A0 =A0 =A0 9.2M =A0 =A0 =A0 8.1M =A0 =A0 =A0 =A0= 7.4M =A0 =A0 =A0 =A07.1M =A0 =A0 =A0 =A0145K > > (modulo rounding errors; you get the point ...) > > Where "Prev" means there was a previous connection in the time interval > and "NoPrev" means there was no previous connection. =A0The "Inf" column > removes the time threshold and just tests whether there was a previous > connection or not. =A0The analysis is not perfect. =A0E.g., the same sour= ce > could be used for a few machines behind a NAT in the given house. =A0But, > it gives a general idea. > >> (Since I know how you value even small sub-1% improvements, I do see >> how this can help you, but I'm wondering if the complexity is >> worthwhile for a generic tcp stack that deals mostly with non-http'ish >> traffic). > > As you can see, this is not a (sub-)1% situation in the data I grabbed. > Maybe its a 1% situation somewhere. =A0And, while I agree that we should > obviously assess cost-v-benefit, setting up strawmen to knock down to > suggest this isn't useful is dubious.) > > allman > > > > > From wes@mti-systems.com Wed Mar 16 09:24:03 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8466B3A68EB for ; Wed, 16 Mar 2011 09:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4M3WUK7AqVdZ for ; Wed, 16 Mar 2011 09:24:02 -0700 (PDT) Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by core3.amsl.com (Postfix) with ESMTP id 701C13A68DE for ; Wed, 16 Mar 2011 09:24:02 -0700 (PDT) Received: from cm-omr5 (mail.networksolutionsemail.com [205.178.146.50]) by omr14.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p2GGPR3x005880 for ; Wed, 16 Mar 2011 12:25:27 -0400 Authentication-Results: cm-omr5 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [184.203.181.116] ([184.203.181.116:36360] helo=[192.168.9.2]) by cm-omr5 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 54/76-29376-774E08D4; Wed, 16 Mar 2011 12:25:27 -0400 Message-ID: <4D80E478.4070508@mti-systems.com> Date: Wed, 16 Mar 2011 12:25:28 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tcpm] poll for adoption of TCP-AO NAT draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 16:24:03 -0000 TCP-AO has been published for some time. NAT support was separated from AO during development, but Joe has maintained a draft describing how to support operation through NATs and it has been discussed in the past on the mailing list and in TCPM meetings. This is a relatively short document, and Joe has recently updated it based on feedback. The latest copy of the document is at: http://tools.ietf.org/html/draft-touch-tcp-ao-nat-02 Please let us know in the next 2 weeks (by March 30) if you would support this as a WG document (via reviewing and commenting on it) for Proposed Standard. If needed, we can discuss this in Prague. Thanks for your feedback. -- Wes Eddy MTI Systems From hkchu@google.com Wed Mar 16 12:04:42 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 080E93A6A38 for ; Wed, 16 Mar 2011 12:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSWiPiafqM5S for ; Wed, 16 Mar 2011 12:04:40 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 6F6013A68DA for ; Wed, 16 Mar 2011 12:04:39 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p2GJ65ZG016212 for ; Wed, 16 Mar 2011 12:06:05 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1300302366; bh=ml8Wt4Zy4Dtj2NmgUMtK5tUJ8iA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=jh37481iZkRDQpvLsKux0zHo3rMlDxEbJfKDr+/S7RFPU+MObGLCzebQd7XxKnpFC CDfpdN+NN4mQreoHoDdAw== Received: from qyk29 (qyk29.prod.google.com [10.241.83.157]) by wpaz21.hot.corp.google.com with ESMTP id p2GJ64or021339 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 16 Mar 2011 12:06:04 -0700 Received: by qyk29 with SMTP id 29so3725377qyk.17 for ; Wed, 16 Mar 2011 12:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=teGLdB7X7nEzhiwAs9eHffZwEU8IR1gU2aPA2rmsuiw=; b=ZNmHSvwM2eXAM7gH+6VgVTJyZPT8KLcCgXA2tJ3m6wGCpAHV+lqKQ6jCHTCVGfGvFm /07DhSd4/VazYGwj4Tzg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NPjYc/gdqf3gcJ7W2vO1cerNFu4jPfNwbNm5pdYHgpHDW85RVMDJ012QQnSc3BnjEC CPEIGjM8R8Tj9C393VrQ== MIME-Version: 1.0 Received: by 10.229.127.88 with SMTP id f24mr368157qcs.186.1300302364078; Wed, 16 Mar 2011 12:06:04 -0700 (PDT) Received: by 10.229.53.199 with HTTP; Wed, 16 Mar 2011 12:06:03 -0700 (PDT) In-Reply-To: <4D80B572.8090707@gmail.com> References: <20110308004501.27770.44908.idtracker@localhost> <5FDC413D5FA246468C200652D63E627A0D4F4DE1@LDCMVEXC1-PRD.hq.netapp.com> <4D7E4EA5.80001@gmail.com> <4D80B572.8090707@gmail.com> Date: Wed, 16 Mar 2011 12:06:03 -0700 Message-ID: From: Jerry Chu To: William Allen Simpson Content-Type: multipart/alternative; boundary=000e0cd6711682f41d049e9e3c47 X-System-Of-Record: true Cc: tcpm@ietf.org Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 19:04:42 -0000 --000e0cd6711682f41d049e9e3c47 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 16, 2011 at 6:04 AM, William Allen Simpson < william.allen.simpson@gmail.com> wrote: > On 3/16/11 2:00 AM, Jerry Chu wrote: > >> TFO and TCPCT have distinctly different goals so I don't see how one could >> call >> it a follow-on to RFC6013. >> Yes we've had some discussion a year ago because after reading your then >> still >> unpublished and very sketchy draft I thought we could use TCPCT to get >> what we >> want. But after the meeting we concluded TCPCT is not suitable for us. >> >> Thank you for clarifying. I misunderstood our prior communications, and > your actions on joining the private TCPCT developers list. I was unaware > that Google had decided to go its own way, and had been waiting for various > other parties to complete their work. TCPCT as a specification has been > stable and fully specified for over a year! > Sorry for any misunderstanding but I thought in our meeting we've made it clear the response data for our target application is often > 1 MSS. How would TCPCT, with server stateless achieve that? (See section 7.3 of our draft for a comparison discussion.) > Rather than continuing to wait, I'll post my own competing variant of this > proposal as a follow-on to TCPCT for comparison and discussion, as soon as > I've some spare hours. > > However, I do not view flooding data on the second connection as important > as reducing all latency by including data on the first connection (and all > subsequent connections). Much more bang for the buck! > If you had a solution that allows data-in-syn on the first connection and also meets all the other requirements and is easy to implement, we would jump on it! But how could you allow data to be accepted on the server side on the first connection while avoiding burning-your-CPU-cycle attack? > > The fact that your proposal does not test whether SYN data works *before* > flooding the data is a serious flaw, as it will in many cases actually > increase the number of RTT. First do no harm.... > The draft already includes discussions in various places on deployment, robustness, mitigation... This includes empirical data showing the vast majority of the studied paths allow data-in-SYN, and suggestion to reduce initRTO to one based on RTT measurement... Moreover, if this still turns out to be an issue the endhost can always cache a path's data-in-SYN friendliness. We could try to address some deployment issue in the protocol itself by it would much complicate the protocol and probably open up some other can of worms. I do not consider sacrificing reliability and security for performance a > good trade. > > Moreover, this impedes ever adding any other TCP option ever again. This > actively prevents inclusion of options approved by the IETF and this group > over the past few years. > May I ask how so? (And how is TCPCT with much larger cookies and the exotic TCP header extension any better?) Best, Jerry --000e0cd6711682f41d049e9e3c47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Mar 16, 2011 at 6:04 AM, William Allen Simpson &l= t;william.allen.simpson@= gmail.com> wrote:
On 3/16/11 2:00 AM, Jerry Chu wrote:
TFO and TCPCT have distinctly different goals so I don't see how one co= uld call
it a follow-on to RFC6013.
Yes we've had some discussion a year ago because after reading your the= n still
unpublished and very sketchy draft I thought we could use TCPCT to get what= we
want. But after the meeting we concluded TCPCT is not suitable for us.

Thank you for clarifying. =A0I misunderstood our prior communications, and<= br> your actions on joining the private TCPCT developers list. =A0I was unaware=
that Google had decided to go its own way, and had been waiting for various=
other parties to complete their work. =A0TCPCT as a specification has been<= br> stable and fully specified for over a year!

=
Sorry for any misunderstanding but I thought in our meeting we've = made it
clear the response data for our target application is oft= en > 1 MSS. How
would TCPCT, with server stateless achieve that? (See section 7.3 of o= ur
draft for a comparison discussion.)


Rather than continuing to wait, I'll post my own competing variant of t= his
proposal as a follow-on to TCPCT for comparison and discussion, as soon as<= br> I've some spare hours.

However, I do not view flooding data on the second connection as important<= br> as reducing all latency by including data on the first connection (and all<= br> subsequent connections). =A0Much more bang for the buck!

If you had a solution that allows data-in-syn on the firs= t connection and also
meets=A0all the other requirements and is e= asy to implement, we would jump on
it!=A0But how could you allow data to be accepted on the server side o= n the first
connection while avoiding burning-your-CPU-cycle=A0at= tack?=A0
=A0

The fact that your proposal does not test whether SYN data works *before* flooding the data is a serious flaw, as it will in many cases actually
increase the number of RTT. =A0First do no harm....
The draft already includes discussions in various places on de= ployment,
robustness, mitigation... This includes empirical data = showing=A0the vast
majority of the studied paths allow data-in-SYN, and suggestion to red= uce
initRTO to one based on RTT measurement... Moreover, if this = still turns
out to be an issue the endhost can always cache a pat= h's data-in-SYN
friendliness. We could try to address some deployment issue in the
protocol itself by it would much complicate the protocol and probabl= y open
up some other=A0can of worms.

I do not consider sacrificing reliability and security for performance a good trade.

Moreover, this impedes ever adding any other TCP option ever again. =A0This=
actively prevents inclusion of options approved by the IETF and this group<= br> over the past few years.

May I ask how = so? (And how is TCPCT with much larger cookies and the exotic
TCP= header extension any better?)

Best,

Jerry


--000e0cd6711682f41d049e9e3c47-- From william.allen.simpson@gmail.com Wed Mar 16 12:08:52 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D30D53A6A63 for ; Wed, 16 Mar 2011 12:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s09TcbEc-luc for ; Wed, 16 Mar 2011 12:08:51 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id B0CCD3A6A43 for ; Wed, 16 Mar 2011 12:08:50 -0700 (PDT) Received: by iyi12 with SMTP id 12so2347497iyi.31 for ; Wed, 16 Mar 2011 12:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=F3TkjkgxGhRuOLBenMDyii+s9DT9I305yKQKGqgE5Ww=; b=ZpDw68a0R3RCA2eXWybk/R2zw3ODgDNtIXhnm+mkX8DjT6kezNZAlzfEqHVrvHUQDX T+7AqzyTpZ8TPo84cqnwLpM18naFT7YPaU4wBn5asvrRBdA9Fn7vdRS5WC8md3DvOGEc 2cTJVL5it5OWXhUJ+thdo2PUxu+pObMx5kRNw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Y6Lx3W5V5n9YsToyZ/HmzwU4E2dNmKjR9zepHQn8Lgm110C/RPEW9XgQxFGp3JLOcl hL0cB8qOyff2M01azEXNNQwd0F8iSQEz7KazIAgskoPv56X+DdC8IBfUZ2J2kVmtHV96 9CW0YH1as1V++IA4xKHMkmi+NjvEudmf4x87Y= Received: by 10.43.64.18 with SMTP id xg18mr573704icb.144.1300302617449; Wed, 16 Mar 2011 12:10:17 -0700 (PDT) Received: from Wastrel-2.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id i20sm100860iby.14.2011.03.16.12.10.15 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Mar 2011 12:10:16 -0700 (PDT) Message-ID: <4D810B15.2080500@gmail.com> Date: Wed, 16 Mar 2011 15:10:13 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: tcpm@ietf.org References: <20110308004501.27770.44908.idtracker@localhost> <5FDC413D5FA246468C200652D63E627A0D4F4DE1@LDCMVEXC1-PRD.hq.netapp.com> <4D7E4EA5.80001@gmail.com> <4D80B572.8090707@gmail.com> <5FDC413D5FA246468C200652D63E627A0D5F21F6@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <5FDC413D5FA246468C200652D63E627A0D5F21F6@LDCMVEXC1-PRD.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 19:08:52 -0000 On 3/16/11 10:40 AM, Scheffenegger, Richard wrote: >> However, I do not view flooding data on the second connection as >> important as reducing all latency by including data on the first >> connection (and all subsequent connections). Much more bang for >> the buck! > > Ever since browsers were allowed to use multiple connections, stepping > back from their use puts your session(s) at a disadvantage... this > behavior is questionable/discussionable, but never the less, fact. > Perhaps you could enlighten me? I'm not able to parse "your". What prevents TCPCT from operating over multiple connections? > Yes, you loose either the data contents of the SYN-flagged segments (1 > RTT for recovery), of the full initial flight (also 1 RTT, but more > troublesome to the network). > With TCPCT, that doesn't happen. And since the explicit design goal is to reduce the RTT, this proposal doesn't meet that goal in that case. BTW, are you sure that many/most stacks will accept the later segments after the missing Syn+data segment? It seems to me they are very likely to be lost. Also, don't forget that retransmission will reduce CWND, also defeating the purpose. If CWND is already less than maximum, only half or less of the initial flight of segments will be sent. They'll await the delayed Ack, so total RTT at that point should be 3 or 4 extra RTT respectively. In the worst case, CWND will be at 1 MSS, and it will take many more Acks to expand. That could be 8 or more RTT. > What did I miss here again? The Cookie is 4..16 bytes in size - the > option 6..18; What prevents me from using smaller cookies when I want to > use other options too? (MSS+WS+SACK+TS has the very same issue today > also). > Surely you wouldn't use a 32-bit Twinkie (don't call it a cookie, it doesn't meet the published requirements) as a security token for session recovery.... That's a birthday attack of only 2**16. Indeed, with MSS+WS+SACK+TS+UTO, the best we can do now is 112-bit Twinkie. And there's no room for both Twinkie and AO. From yoshifumi.nishida@gmail.com Thu Mar 17 00:06:42 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AB4C3A67DB for ; Thu, 17 Mar 2011 00:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.917 X-Spam-Level: X-Spam-Status: No, score=-102.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSsjj6f3fX+F for ; Thu, 17 Mar 2011 00:06:41 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 1A54C3A67F7 for ; Thu, 17 Mar 2011 00:06:41 -0700 (PDT) Received: by ywi6 with SMTP id 6so1195496ywi.31 for ; Thu, 17 Mar 2011 00:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=WKluXoef9oS9qsA5pumAB6OlrJc9PDwZOGfsPVwxRow=; b=K3ZjPUiGveQWZREQrKGT6fLr0Nk0HV6C4+GXBdiHz4IoWt6q+sQAv6OjuSTz5BEuCq vX37KPUZNH5n9mQnvBeYlfscLPazvS78GpouIJ8vg+nA2WwIlARCYQHxi5OQir+QMjQp 3uQTbxgPh0Zz8aQjeiqmYIIyuF9+mJJXVjXN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=KQzWUQAmxFVJOXTOPdrPBnB7AjNPxjEhIFwXFSnsGLS1If4cpIiG6xabto573K9+xq RP6mgHo6N4GdW1CXv9bWrjHOM6UjXZvRac5FEeyv9y3RDasOqqOxpV5HjfOQX8LMichT VcdQqzhGxFGs4DS/cTytA1L2rYzD3100poddQ= MIME-Version: 1.0 Received: by 10.236.189.98 with SMTP id b62mr998912yhn.169.1300345686742; Thu, 17 Mar 2011 00:08:06 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.147.171.12 with HTTP; Thu, 17 Mar 2011 00:08:06 -0700 (PDT) In-Reply-To: References: <20110308004501.27770.44908.idtracker@localhost> Date: Thu, 17 Mar 2011 00:08:06 -0700 X-Google-Sender-Auth: gP6KcnapGPBNoWsau7O_3YNu8YA Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 07:06:42 -0000 Hi, please allow me to clarify my vague question. I'm personally would like to know the reason why we cannot reuse TCP connections more. If middlebox timeout (NAT table expire) is major reason, I think a simple solution is to use small value for tcp's keep-alive interval. Isn't this useful in the scenario of this draft? Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp 2011/3/16 Yoshifumi Nishida : > Hello Yuchung, > > A naive question.. > why not setting small value for keep alive interval? > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp > > > 2011/3/11 Yuchung Cheng : >> Hi folks, >> We are proposing a new draft called TCP Fast Open (TFO) which allows dat= a >> exchange to begin in TCP handshake to improve performance. >> We would like to gather some comments before we present it in the next t= cpm >> meeting in Prague. The presentation will also include some performance >> numbers based on our beta implementation in Linux and the Chrome browser= . >> Thanks, >> Yuchung >> ---------- Forwarded message ---------- >> From: >> Date: Mon, Mar 7, 2011 at 4:45 PM >> Subject: I-D Action:draft-cheng-tcpm-fastopen-00.txt >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : TCP Fast Open >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Y. Cheng, et al. >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-cheng-tcpm-fastopen-00.tx= t >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 17 >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-03-07 >> >> TCP Fast Open (TFO) allows data to be carried in the SYN or SYN-ACK >> packets and consumed by the receiving end during the initial >> connection handshake, thus providing a saving of up to one full round >> trip time (RTT) compared to standard TCP requiring a three-way >> handshake (3WHS) to complete before data can be exchanged. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-cheng-tcpm-fastopen-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> >> > From ycheng@google.com Thu Mar 17 10:30:01 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE46C3A69F3 for ; Thu, 17 Mar 2011 10:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.578 X-Spam-Level: X-Spam-Status: No, score=-105.578 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJr2yelfXa1S for ; Thu, 17 Mar 2011 10:29:59 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 728783A69EE for ; Thu, 17 Mar 2011 10:29:58 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p2HHVPrk015508 for ; Thu, 17 Mar 2011 10:31:25 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1300383086; bh=/f1fO80AEydLjUXjukw3n3kkLqc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=VE42wO5k9mhKpsKlSyftBNbCno+GpGQkfKecB/JT1lqPkuck/tu6nOV28txonlTKm BDLwlDMxfNxPsB07OgxHg== Received: from vxc34 (vxc34.prod.google.com [10.241.33.162]) by kpbe19.cbf.corp.google.com with ESMTP id p2HHUnaq009996 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 17 Mar 2011 10:31:24 -0700 Received: by vxc34 with SMTP id 34so3197377vxc.13 for ; Thu, 17 Mar 2011 10:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Efz8PhU467oD14a6zEwFTXu1IJl5cP043igIn4BL5HU=; b=NDdXipIv1idgk0xVZvXqxMfuDBqej7wQCVbDk73FuT29J2o/hJd5NmhyZgxOvdZGk9 MJBAid6nv9SkZtoWFmJw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=epOGXDv9qqapMbI18wONOaPJXeZ2XCvY0GP5XXS4Xb8/g54A88k5u2p1zYeA9x64dH mvvA0LRG3I1QiWdAkCog== Received: by 10.220.177.69 with SMTP id bh5mr4327vcb.180.1300383083158; Thu, 17 Mar 2011 10:31:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.16.148 with HTTP; Thu, 17 Mar 2011 10:31:03 -0700 (PDT) In-Reply-To: References: <20110308004501.27770.44908.idtracker@localhost> From: Yuchung Cheng Date: Thu, 17 Mar 2011 10:31:03 -0700 Message-ID: To: Yoshifumi Nishida Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Fwd: I-D Action:draft-cheng-tcpm-fastopen-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 17:30:01 -0000 Hi Yoshifumi, I contacted someone who studied issues on TCP keep-alives and NAT after your email but have not receive the reply yet. I vaguely remembered his study showed a) in general using TCP keep-alive helps b) it may not be energy friendly for mobile devices c) Some broken NAT boxes ignore keep-alive probes (since they don't carry data?). I had one before :( On the other hand, servers do close persistent connections (for resource reasons). E.g., apache pHTTP default timeout is 5s-15s only. Yuchung On Thu, Mar 17, 2011 at 12:08 AM, Yoshifumi Nishida wrote: > Hi, please allow me to clarify my vague question. > I'm personally would like to know the reason why we cannot reuse TCP > connections more. > If middlebox timeout (NAT table expire) is major reason, I think a > simple solution > is to use small value for tcp's keep-alive interval. > Isn't this useful in the scenario of this draft? > > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp > > 2011/3/16 Yoshifumi Nishida : >> Hello Yuchung, >> >> A naive question.. >> why not setting small value for keep alive interval? >> -- >> Yoshifumi Nishida >> nishida@sfc.wide.ad.jp >> >> >> 2011/3/11 Yuchung Cheng : >>> Hi folks, >>> We are proposing a new draft called TCP Fast Open (TFO) which allows da= ta >>> exchange to begin in TCP handshake to improve performance. >>> We would like to gather some comments before we present it in the next = tcpm >>> meeting in Prague. The presentation will also include some performance >>> numbers based on our beta implementation in Linux and the Chrome browse= r. >>> Thanks, >>> Yuchung >>> ---------- Forwarded message ---------- >>> From: >>> Date: Mon, Mar 7, 2011 at 4:45 PM >>> Subject: I-D Action:draft-cheng-tcpm-fastopen-00.txt >>> To: i-d-announce@ietf.org >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : TCP Fast Open >>> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Y. Cheng, et al. >>> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-cheng-tcpm-fastopen-00.t= xt >>> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 17 >>> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-03-07 >>> >>> TCP Fast Open (TFO) allows data to be carried in the SYN or SYN-ACK >>> packets and consumed by the receiving end during the initial >>> connection handshake, thus providing a saving of up to one full round >>> trip time (RTT) compared to standard TCP requiring a three-way >>> handshake (3WHS) to complete before data can be exchanged. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-cheng-tcpm-fastopen-00.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >>> >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From wes@mti-systems.com Thu Mar 17 18:59:17 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F67A3A6A30 for ; Thu, 17 Mar 2011 18:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pENhmeZ1b1Oj for ; Thu, 17 Mar 2011 18:59:16 -0700 (PDT) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by core3.amsl.com (Postfix) with ESMTP id 6913F3A6A05 for ; Thu, 17 Mar 2011 18:59:16 -0700 (PDT) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p2I20iHg006486 for ; Thu, 17 Mar 2011 22:00:44 -0400 Authentication-Results: cm-omr9 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.80.150] ([174.130.80.150:27915] helo=[192.168.1.101]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id AA/30-23235-CCCB28D4; Thu, 17 Mar 2011 22:00:44 -0400 Message-ID: <4D82BCCD.50405@mti-systems.com> Date: Thu, 17 Mar 2011 22:00:45 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tcpm] draft agenda for IETF80/Prague X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 01:59:17 -0000 FYI - TCPM is currently scheduled to meet Wednesday afternoon in Prague: https://datatracker.ietf.org/meeting/80/agenda.html A draft agenda is at: http://www.ietf.org/proceedings/80/agenda/tcpm.txt Please let us know of any corrections or other suggestions; we're considering adjusting the order to move tcp-security earlier within the session as it's a WG item that we'd like to dedicate time to. -- Wes Eddy MTI Systems From thomas.r.henderson@boeing.com Thu Mar 17 23:55:54 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57AFB3A6ADF for ; Thu, 17 Mar 2011 23:55:54 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+0+cQiAEH6u for ; Thu, 17 Mar 2011 23:55:53 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 6E1553A6AD6 for ; Thu, 17 Mar 2011 23:55:53 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p2I6vBur028777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Mar 2011 23:57:15 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p2I6vBPg019512; Thu, 17 Mar 2011 23:57:11 -0700 (PDT) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p2I6vAVC019507 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 17 Mar 2011 23:57:11 -0700 (PDT) Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.85]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Thu, 17 Mar 2011 23:57:10 -0700 From: "Henderson, Thomas R" To: tcpm WG Date: Thu, 17 Mar 2011 23:57:09 -0700 Thread-Topic: I-D Action:draft-ietf-tcpm-rfc3782-bis-01.txt Thread-Index: AcvimcxJG+t4pU1OT5WUvmwTpkMzkgCn3MsA Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CED25B01B@XCH-NW-10V.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_003_7CC566635CFE364D87DC5803D4712A6C4CED25B01BXCHNW10Vnwnos_" MIME-Version: 1.0 Subject: [tcpm] FW: I-D Action:draft-ietf-tcpm-rfc3782-bis-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 06:55:54 -0000 --_003_7CC566635CFE364D87DC5803D4712A6C4CED25B01BXCHNW10Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, the below update to the NewReno revision attempts to address Alexander= Zimmermann's comments from a while back. More comments and review would b= e welcome. I'm considering whether to align the document more with the RFC= 5681 specification of Fast Retransmit and Fast Recovery. - Tom -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of Internet-Drafts@ietf.org Sent: Monday, March 14, 2011 3:45 PM To: i-d-announce@ietf.org Cc: tcpm@ietf.org Subject: I-D Action:draft-ietf-tcpm-rfc3782-bis-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Worki= ng Group of the IETF. Title : The NewReno Modification to TCP's Fast Recovery Algorith= m Author(s) : T. Henderson, et al. Filename : draft-ietf-tcpm-rfc3782-bis-01.txt Pages : 23 Date : 2011-03-14 RFC 5681 [RFC5681] documents the following four intertwined TCP congestion = control algorithms: Slow Start, Congestion Avoidance, Fast Retransmit, and = Fast Recovery. RFC 5681 explicitly allows certain modifications of these a= lgorithms, including modifications that use the TCP Selective Acknowledgeme= nt (SACK) option [RFC2883], and modifications that respond to "partial ackn= owledgments" (ACKs which cover new data, but not all the data outstanding w= hen loss was detected) in the absence of SACK. This document describes a specific algor= ithm for responding to partial acknowledgments, referred to as NewReno. Th= is response to partial acknowledgments was first proposed by Janey Hoe in [= Hoe95]. The purpose of this revision from [RFC3782] is to make errata changes and t= o adopt a proposal from Yoshifumi Nishida to slightly increase the minimum = window size after Fast Recovery from one to two segments, to improve perfor= mance when the receiver uses delayed acknowledgments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc3782-bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. --_003_7CC566635CFE364D87DC5803D4712A6C4CED25B01BXCHNW10Vnwnos_ Content-Type: message/external-body; name="draft-ietf-tcpm-rfc3782-bis-01.url" Content-Description: draft-ietf-tcpm-rfc3782-bis-01.url Content-Disposition: attachment; filename="draft-ietf-tcpm-rfc3782-bis-01.url"; size=95; creation-date="Mon, 14 Mar 2011 15:47:29 GMT"; modification-date="Mon, 14 Mar 2011 15:47:29 GMT" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXRjcG0tcmZjMzc4Mi1iaXMtMDEudHh0DQo= --_003_7CC566635CFE364D87DC5803D4712A6C4CED25B01BXCHNW10Vnwnos_ Content-Type: text/plain; name="ATT00001..txt" Content-Description: ATT00001..txt Content-Disposition: attachment; filename="ATT00001..txt"; size=258; creation-date="Mon, 14 Mar 2011 15:47:29 GMT"; modification-date="Mon, 14 Mar 2011 15:47:29 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K --_003_7CC566635CFE364D87DC5803D4712A6C4CED25B01BXCHNW10Vnwnos_-- From william.allen.simpson@gmail.com Sun Mar 20 10:40:34 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C5723A6AAB for ; Sun, 20 Mar 2011 10:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.762 X-Spam-Level: X-Spam-Status: No, score=-2.762 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_00=-2.599, FRT_ADULT2=1.474, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MmEQjE1ClG3 for ; Sun, 20 Mar 2011 10:40:33 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 9C9703A695F for ; Sun, 20 Mar 2011 10:40:33 -0700 (PDT) Received: by iyi12 with SMTP id 12so6648944iyi.31 for ; Sun, 20 Mar 2011 10:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=MFeQMuEIJ77q05V4DPjRa2P9Sr74Ef5ySaTHyN1DO5o=; b=dIYZx9tFI9oTVN6p53Lbz7upVCKqfdWr5F99YkAtcfrwkY+jQGVDHBwV8fynYrnhL7 1ugjKP8l3PEJwDgJmv5opBQgwfAZ1RqRYnoNesCA1ZvId/6HrnJzlBgc1vlV9NYeMV1c VAIZHzqf958zilS4lWl24WQk+Ywfg68uMjCUU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=O+EBSI+H68xhKdzlCKwleyF+yhBYPJ075TQBX1Ceu5LDCINfyKXue974+k1yy1fj/0 lguFs5AcYTqeIpGNQkzx6QOsmB46c4wPQoc8xKqRl2bJRpdMhU2xbWR8JpW783QqKjL+ WIpfYPkRDfCQx13fjDQmDG57EEk4+kz5niP+U= Received: by 10.231.16.9 with SMTP id m9mr3346320iba.9.1300642925494; Sun, 20 Mar 2011 10:42:05 -0700 (PDT) Received: from Wastrel-2.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id 14sm3107166ibo.29.2011.03.20.10.42.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 20 Mar 2011 10:42:04 -0700 (PDT) Message-ID: <4D863C6B.3030901@gmail.com> Date: Sun, 20 Mar 2011 13:42:03 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: TCP Modifications WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tcpm] TCPCT Rapid Restart -00a X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 17:40:34 -0000 As I promised a few days ago, I've done my own competing variant of this proposal as a follow-on to TCPCT for comparison and discussion. It's mostly complete, or at least as complete as I could whip up in a weekend. It helps that I'd already thought through the various problems over a year ago.... Other than actually having better security, a major difference is a more moderate approach to the restart congestion window. Rather than banging out a SYN with 10 segments several minutes after the most recent transmission (Fast Open + IW10), or reducing the window after only 1 RTT (RFC5681), I've taken a more gradualist approach of reducing by half per RTT (RFC2861). But then, it's experimental.... Available upon request. From mallman@icir.org Sun Mar 20 20:16:05 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF0D13A63CA for ; Sun, 20 Mar 2011 20:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.776 X-Spam-Level: X-Spam-Status: No, score=-105.776 tagged_above=-999 required=5 tests=[AWL=-0.651, BAYES_00=-2.599, FRT_ADULT2=1.474, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPVrxTC7N1Xi for ; Sun, 20 Mar 2011 20:16:05 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 1F4463A6359 for ; Sun, 20 Mar 2011 20:16:05 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id p2L3HYOF012034; Sun, 20 Mar 2011 20:17:34 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 17D183643B17; Sun, 20 Mar 2011 23:17:34 -0400 (EDT) To: William Allen Simpson From: Mark Allman In-Reply-To: <4D863C6B.3030901@gmail.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Jungle Love MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma49997-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 20 Mar 2011 23:17:33 -0400 Sender: mallman@icir.org Message-Id: <20110321031734.17D183643B17@lawyers.icir.org> Cc: TCP Modifications WG Subject: Re: [tcpm] TCPCT Rapid Restart -00a X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 03:16:06 -0000 ----------ma49997-1 Content-Type: text/plain Content-Disposition: inline > Rather than banging out a SYN with 10 segments several minutes after the > most recent transmission (Fast Open + IW10), or reducing the window after > only 1 RTT (RFC5681), I've taken a more gradualist approach of reducing by > half per RTT (RFC2861). But then, it's experimental.... Maybe I don't understand what you're saying, but the whole point of this sort of thing is to cut out of the 3WHS time. So, if you're going to restrict the initial window then that goes against the entire goal it would seem. Perhaps there would be some slightly different congestion control response to loss in this area of the connection (e.g., because losing a SYN would prevent the usual IW from being sent or something). And, maybe we'd agree that the IW should be IW-1 to account for the SYN segment. Or, other such small items. However, that is working the edges. From a congestion control perspective this fundamentally this isn't much different from starting a new connection with the usual IW (which would be perfectly legal). allman ----------ma49997-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2Gw00ACgkQWyrrWs4yIs6YMACfVArOSBAHUVh5O5SunUNH6wSa 2DkAoJfUobKOPwq2lg8OEkklNPwPyYI+ =ZKts -----END PGP SIGNATURE----- ----------ma49997-1-- From william.allen.simpson@gmail.com Mon Mar 21 05:48:41 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0194228C12E for ; Mon, 21 Mar 2011 05:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvnVl2twPBD9 for ; Mon, 21 Mar 2011 05:48:40 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 37ED628C136 for ; Mon, 21 Mar 2011 05:48:40 -0700 (PDT) Received: by iyi12 with SMTP id 12so7431287iyi.31 for ; Mon, 21 Mar 2011 05:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SI06buzcoJTf5GNbSEdzUQ5L+tL7bGIs80rUXYfjxnE=; b=gHo5JNNDLIlSymfhXMXfRibWAIQDWq93x21DZoAtZnPVbDmx5dKLsPP+BsTEqK5LU6 W3TX/MpMeZf7cI0Jr5m3LxZ8bLZ2o29/uNhpQMO8ARYsM9p5wmiHRSLEU/TMWkl7nr98 uZmfA0XiaKK2ljI2hiypznIq7Xf4tvAd1MUQc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=W575vubIqpYQo+oyd5jhNoqCeoJEVQuyHAAqX48c510ZNBLfFtdD5fiTQ0B5Hcxm/f 2A5sVtttkuVXxweoCq6r+2X/2FOc1eXdXPMoQwUD4D/k+nEuB7luSZojyxc3uD7ipflr 5GOHLQWHk2sC4sHigj0lsPvfRfcYamand/QXs= Received: by 10.42.156.6 with SMTP id x6mr6941277icw.90.1300711812603; Mon, 21 Mar 2011 05:50:12 -0700 (PDT) Received: from Wastrel-2.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id jv9sm3963368icb.1.2011.03.21.05.50.10 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Mar 2011 05:50:11 -0700 (PDT) Message-ID: <4D874981.8030502@gmail.com> Date: Mon, 21 Mar 2011 08:50:09 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: TCP Modifications WG References: <20110321031734.17D183643B17@lawyers.icir.org> In-Reply-To: <20110321031734.17D183643B17@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] TCPCT Rapid Restart -00a X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 12:48:41 -0000 On 3/20/11 11:17 PM, Mark Allman wrote: > edges. From a congestion control perspective this fundamentally this > isn't much different from starting a new connection with the usual IW > (which would be perfectly legal). > Certainly. My point is that the usual IW comes after a 3WHS, so there's timing information available and you "know" enough bandwidth to carry the 3WHS.... But the current 1 RTO (RFC-5681) RW drop defeats the purpose of keeping the bandwidth going for long-delay paths. So, I'm proposing we go back to the more gradual RFC-2861 approach for these purposes. From william.allen.simpson@gmail.com Mon Mar 21 06:25:21 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 219203A6869 for ; Mon, 21 Mar 2011 06:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfQYjeGvZX8Y for ; Mon, 21 Mar 2011 06:25:20 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 2A2623A685D for ; Mon, 21 Mar 2011 06:25:20 -0700 (PDT) Received: by iyi12 with SMTP id 12so7471167iyi.31 for ; Mon, 21 Mar 2011 06:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2SZxwMPC4ja6azODmyb076eiPu9SqIKtm9O14isoymM=; b=c2hbKdkHbJEwaOpAzjsqxNWe7Jsn177hIPDgdySqftbbNQ247N3CV3c569s9z2Qb0f Q1C1FHEb5vyHrk1olasA3q4I+saTJNarS90d2ja5wsY1OHgyV5JGwihfEN7DXIWT3Ga0 ysfGN1NmqXh3ibldSGHrBOvpTyQaqfRCu4izs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=v9hbJnwccdTqxNwoECusA/SSPMCmcQ9UMz/q/zYDktXTWlcjgYxSJmqJKUEsdoELQD zDjPhaATDu1cJ30dVw9heZcRefJxQY34aU0ZDoufq3lbkq4sxGhVkIMHPcO+OWq35BCW V59n48BBggzta1D2s2dXip3xT+JKH1qyGtfR0= Received: by 10.42.243.9 with SMTP id lk9mr6700188icb.297.1300714012640; Mon, 21 Mar 2011 06:26:52 -0700 (PDT) Received: from Wastrel-2.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id i20sm3723375iby.65.2011.03.21.06.26.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Mar 2011 06:26:50 -0700 (PDT) Message-ID: <4D875219.2080302@gmail.com> Date: Mon, 21 Mar 2011 09:26:49 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: TCP Modifications WG References: <20110321031734.17D183643B17@lawyers.icir.org> <4D874981.8030502@gmail.com> In-Reply-To: <4D874981.8030502@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] TCPCT Rapid Restart -00a X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 13:25:21 -0000 The wording of the critical section is: 3.1. Responder TCB Retention By default, upon receipt of the Initiator (and verification of the Timestamps and Cookie-Pair options), the Responder removes its TCB. If the Responder (server) application has set the TCPCT_RETAIN flag, the Responder calculates the retention time. This time is based on the anticipated decay of the congestion window during an idle period. For purposes of these calculations, the implementation SHOULD reduce its congestion window by half for every Round Trip Time (RTT) that the flow has remained idle. [RFC2861] When the congestion window is less than or equal to TCP_SYN_ACK_DATA_LIMIT (or the local value in tcpct_s_data_desired) plus Maximum Segment Size (MSS), as limited by the retained Path Maximum Transmission Unit (PMTU), rapid restart offers no improvement over accelerated open. At that time, the Responder removes its TCB. All the rest is mechanism. Critique requested. From iesg-secretary@ietf.org Mon Mar 21 10:07:47 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 829B828C16D; Mon, 21 Mar 2011 10:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1CNuAsV6kcZ; Mon, 21 Mar 2011 10:07:46 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F85428C176; Mon, 21 Mar 2011 10:07:46 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110321170746.14816.62086.idtracker@localhost> Date: Mon, 21 Mar 2011 10:07:46 -0700 Cc: tcpm chair , tcpm mailing list , Internet Architecture Board , RFC Editor Subject: [tcpm] Document Action: 'Moving the Undeployed TCP Extensions RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1379, RFC1644 and RFC1693 to Historic Status' to Informational RFC (draft-eggert-tcpm-historicize-02.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 17:07:47 -0000 The IESG has approved the following document: - 'Moving the Undeployed TCP Extensions RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1379, RFC1644 and RFC1693 to Historic Status' (draft-eggert-tcpm-historicize-02.txt) as an Informational RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are David Harrington and Lars Eggert. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-eggert-tcpm-historicize/ Technical Summary This document recommends that several TCP extensions that have never seen widespread use be moved to Historic status. The affected RFCs are RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1379, RFC1644 and RFC1693. Working Group Summary There was debate about whether RFC1263 should be included in this document because it is not an extension; it is an Informational document that describes an architectural approach that the TCP community chose not to follow. RFC1263 has been removed from the list of documents to be declared Historic. There was debate about whether the Alternate Checksum option should be removed from this document. It was decided to keep this item in the list. Document Quality This document declares certain features historic because they have not been widely implemented. Personnel Who is the Document Shepherd for this document? Wesley Eddy (Wesley.M.Eddy@nasa.gov) Who is the Responsible Area Director? David Harrington RFC Editor Note A reference pointer to additional research will be added by Lars prior to ietf80. From bob.briscoe@bt.com Sun Mar 27 01:46:16 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997A63A68EB for ; Sun, 27 Mar 2011 01:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.43 X-Spam-Level: X-Spam-Status: No, score=-3.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlCMv5+yHI2t for ; Sun, 27 Mar 2011 01:46:15 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id CE0E43A688F for ; Sun, 27 Mar 2011 01:46:14 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 27 Mar 2011 09:47:50 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 27 Mar 2011 09:47:50 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1301215668811; Sun, 27 Mar 2011 09:47:48 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.128.38]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p2R8lkWj020297; Sun, 27 Mar 2011 09:47:46 +0100 Message-Id: <201103270847.p2R8lkWj020297@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 27 Mar 2011 09:47:46 +0100 To: "Scheffenegger, Richard" From: Bob Briscoe In-Reply-To: <5FDC413D5FA246468C200652D63E627A0D8D3231@LDCMVEXC1-PRD.hq. netapp.com> References: <201103252009.p2PK9WYm008391@bagheera.jungle.bt.co.uk> <5FDC413D5FA246468C200652D63E627A0D8D3231@LDCMVEXC1-PRD.hq.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 27 Mar 2011 08:47:50.0205 (UTC) FILETIME=[A73B46D0:01CBEC5B] Cc: tcpm@ietf.org Subject: Re: [tcpm] Quick review: scheffenegger-tcpm-timestamp-negotiation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 08:46:16 -0000 Richard, [I've added tcpm to distr - I omitted accidentally first time round.] At 01:45 26/03/2011, Scheffenegger, Richard wrote: >Hi Bob, > >thank you for your review! It is always=20 >beneficial to get a native speaker input on=20 >wording - especially if he is as knowledgeable in the topic as you are :) > >The first remark I already changed locally to this: >" A compliant TCP receiver will then XOR the received > TSval with the local timestamp options,=20 > when responding with the SYN+ACK." What does "local" mean? May-be I didn't assume=20 correctly what you are trying to do in this para at the start of S.4. Firstly the TCP client must detect whether the=20 server has implemented your draft. So it needs to=20 see some difference between what an RFC1323=20 server would echo and what an updated server would echo. Secondly, you need to say that you are allowing=20 for future extension of the capabilities so you=20 are trying to do capability negotiation, to find=20 the lowest common denominator capability that the=20 two ends support (I think that's what you are doing, anyway). Lastly, you need to unambiguously say that the=20 server puts the result of the XOR in the TSecr of the SYN-ACK. In fact, this leads to a more more general point:=20 the draft needs to start with a more general=20 explanation of what the protocol is trying to=20 achieve. At the moment one has to reverse=20 engineer the intent from the protocol specification. It would be worth following the layout of RFC4101=20 "Writing Protocol Models". This gives guidance on=20 how to write a clear protocol description. >(Although I may need a different referent to=20 >"timestamp options" (the extended fields=20 >indicating the capabilies; hmm.. perhaps=20 >"timestamp capabilities" is be good generic=20 >reference to the sum total of all suggested=20 >fields in the SYNs (currently I have timestamp=20 >option referencing the TCP TS option=20 >(TSval/TSecr), and timestamp options referencing=20 >to only the new fields; a single character is=20 >definitely not enough hamming distance for a casual reader :) ). Yes, you need a term. I can't suggest one while=20 I'm not sure any more what the protocol is trying to do. How about a terminology section first? > > Have you tested whether any existing implementations actually check > > whether the TSecr field is zero in a SYN? I doubt it, but we ought to > > check. > >No; there were some legacy implementations which=20 >wouldn't properly clear the TCPCB and the TSecr=20 >on the initial SYN would therefore not be zero=20 >(I can not find the reference, but it was deemed=20 >a potential data leak). But most implementations=20 >seem to simply ignore anything in TSecr when=20 >receiving a SYN, and nowadays properly clear TSecr when sending... > >The more interesting finding I had is that it=20 >appears that even though RFC1323 is quite clear=20 >about the use of the TS value during=20 >loss/reordering (so the sender should ignore=20 >TSecr if a SACK option is present too - as that=20 >is a definitive indication of some=20 >reordering/loss happening, even though there may=20 >not have been any earlier indication to the=20 >sender (lost/delayed ACKs), TS processing is=20 >completely independent from anything else. > >Therefore, a full backwards-compatible=20 >implementation is required (ie only enable=20 >"opaque, non-monotonic LSBs" and direct=20 >mirroring when both ends negotiate this new=20 >capability. If they don't, a sender (and=20 >receiver) have to revert to RFC1323 behavior.=20 >However, as there are a number of reserved bits,=20 >the behavior at the presence of an unknown=20 >future capabilities field needs to be specified.=20 >I would think that at the very least, the direct=20 >reflection of the TS value when SACK is present=20 >too, should happen always, even if such future=20 >capabilities render the TSval completely opaque=20 >to a receiver that doesn't understand those. > > >One more question: As these TS capabilities=20 >provide additional values / bit fields, is this=20 >something that IANA needs to govern? Or is this=20 >merely an extension of RFC1323 which does not=20 >define any IANA action (as currently mentioned)?=20 >(I guess what I'm asking is, when does IANA need to be involved in an= RFC?). Indeed - good point. You are creating a space for=20 people to populate in future, so you need to=20 register this with IANA to avoid two people=20 populating the same part of the space with different things. Given I now understand you are allowing future=20 extension, you need to say what would be a valid=20 extension and what not. For instance, are forks=20 allowed, or must each extension build on the last? Cheers Bob >And lastly, I think the option is probably=20 >incompatible (as is) with TCPCT, if TSecr is=20 >used there with the previous sessions last=20 >timestamp (I'm not 100% clear on this though,=20 >even though it would probably be beneficial also=20 >for these 64 / 128 bit timestamps...) > > >Thanks again for your feedback! > >Richard Scheffenegger > >NetApp >rs@netapp.com >+43 1 3676811 3146 Office (2143 3146 - internal) >+43 676 654 3146 Mobile >www.netapp.com > >EURO PLAZA >Geb=E4ude G, Stiege 7, 3.OG >Am Euro Platz 2 >A-1120 Wien > > > > > -----Original Message----- > > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > > Sent: Freitag, 25. M=E4rz 2011 21:10 > > To: Scheffenegger, Richard; Mirja KUEHLEWIND > > Subject: Quick review: scheffenegger-tcpm-timestamp-negotiation > > > > Richard, Mirja, > > > > Nice draft. > > > > Have you tested whether any existing implementations actually check > > whether the TSecr field is zero in a SYN? I doubt it, but we ought to > > check. > > > > Some editorial comments: > > > > 4. "A compliant TCP receiver will XOR the flags with the received > > TSval" > > > > I worked it out what you mean, but it's not unambiguous what "the > > flags" are at this stage (they haven't been called "the flags" yet). > > I initially thought you meant the control bits in the TCP header (!). > > And later you call them "the flags and the fields", so do you mean we > > should XOR with only the 1-bit flags and not the fields?" I assume not. > > > > Also, to be unambiguous, you need to be much clearer about which > > field in which direction you are talking about here, because the > > names of the fields switch round. > > > > p7 > > s/Note that the use of this option as implications/ > > /Note that the use of this option has implications/ > > s/wraped/ > > /wrapped/ > > > > p9 > > s/vulerabilities/ > > /vulnerabilities/ > > > > > > Bob > > > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 From wes@mti-systems.com Mon Mar 28 00:49:52 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 472283A68D2 for ; Mon, 28 Mar 2011 00:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0xIufeZ539m for ; Mon, 28 Mar 2011 00:49:51 -0700 (PDT) Received: from omr10.networksolutionsemail.com (omr10.networksolutionsemail.com [205.178.146.60]) by core3.amsl.com (Postfix) with ESMTP id 26C5C3A68C7 for ; Mon, 28 Mar 2011 00:49:51 -0700 (PDT) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr10.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p2S7pR15000649 for ; Mon, 28 Mar 2011 03:51:28 -0400 Authentication-Results: cm-omr1 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [94.75.220.77] ([94.75.220.77:57272] helo=[10.9.0.26]) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 11/4F-06416-FFD309D4; Mon, 28 Mar 2011 03:51:27 -0400 Message-ID: <4D903DFD.5050504@mti-systems.com> Date: Mon, 28 Mar 2011 09:51:25 +0200 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tcpm] WG status pre-IETF80 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 07:49:52 -0000 Hello; below is a snapshot of TCPM status from the chairs prior to the IETF80 meeting. As usual, we may have made mistakes, so please correct us, if needed. As a reminder, there is currently a poll on the TCP AO document proposed as a WG item, and we are also still searching for reviewer volunteers for portions of the tcp-security recommendations. Please let us know your thoughts on either. Recent RFCs =========== RFC 6093 - On the Implementation of the TCP Urgent Mechanism (January, 2011) WG Items Nearing RFC Publication ================================ draft-eggert-tcpm-historicize Milestone Target: Informational in October 2010 Status: in RFC-Editor's queue draft-ietf-tcpm-tcp-timestamps Milestone Target: Informational Status: in RFC-Editor's queue draft-paxson-tcpm-rfc2988bis Milestone Target: Proposed Standard in March 2011 Status: publication requested on 3/22/11 WG Items in WGLC or being revised after WGLC ============================================ Clarification of sender behavior in persist condition draft-ietf-tcpm-persist Milestone Target: Informational Status: finished WGLC, needs update to resolve comments Action: need to make changes in response to suggestions to remove appendix w/ API and one of the recommendations MSS Option draft-ietf-tcpm-tcpmss Milestone Target: Proposed Standard in July 2009 Status: WGLC started 8/19, ended 9/8 (extended) 2nd WGLC started at IETF 77, and is ended with few comments Action: David will check with commenters from first WGLC to see if issues are closed Wes/Michael will write PROTO and send to the IESG, after WGLC starts and completes Active WG Items =============== 1323bis draft-ietf-tcpm-1323bis Milestone Target: Proposed Standard in July 2009 Status: Needs revision Action: Revise & WGLC (action with D. Borman) TCP Security draft-ietf-tcpm-tcp-security Milestone Target: BCP in August 2010 Status: content needs work Action: need to have people review this; possibly in individual sections (few volunteers so far) SACK Entry / RFC 3517bis draft-blanton-tcpm-3517bis Milestone Target: Proposed Standard in October 2010 Action: ready for WGLC? (need to identify as WG doc in tracker) Increasing the Initial Window draft-ietf-tcpm-initcwnd Milestone Target: August 2011 to determine intended status September 2011 to publish document Status: under active discussion / review Action: determine intended status through continued WG discussion NewReno Update draft-ietf-tcpm-rfc3782-bis Status: probably ready for WGLC Milestone Target: Proposed Standard in April 2011 Documents Under a Poll to Become WG Items ========================================= AO NAT draft-touch-tcp-ao-nat Status: IETF 77 discussion determined this should be Experimental, whether or not it is a WG document; need to ask TCPM list Action: poll started on 3/16/11, to close 3/30/11 Other Proposals Not Yet Decided On ================================== draft-allman-tcpm-bump-initcwnd draft-allman-tcpm-rto-consider draft-bittau-tcp-crypt draft-cheng-tcpm-fastopen draft-fairhurst-tcpm-newcwv draft-gont-tcpm-rfc1948bis draft-hurtig-tcpm-rtorestart draft-mathis-tcpm-proportional-rate-reduction draft-scheffenegger-tcpm-sack-loss-recovery draft-scheffenegger-tcpm-timestamp-negotiation draft-touch-tcpm-automatic-iw draft-mongazon-tcpm-tcp-rehash Status: discussed on-list, lack of consensus draft-anumita-tcpm-stronger-checksum Status: discussed on-list, mingled with historicize draft discussion draft-duan-tcpm-tcp-ao-rekeying Status: discussed in Anaheim and on-list; motivations and usefulness was questioned draft-huang-tcpm-tcp-eack Status: discussed on-list; there seems to be agreement that ACK congestion control (RFC 5690) will mitigate the issue Older & Expired Documents Discussed =================================== discussions on Rate-Halving draft-mathis-tcp-ratehalving Action: mailing list discussion about the history of this, and whether it needs to be revived Faster Application Handshakes with SYN/ACK Payloads expired draft-agl-tcpm-sadata Status: expired; not specifically polled for adoption in WG draft-ycheng-tcpm-rtosynrtt Status: has been suggested as either an addition to 2988bis or to initcwnd documents discussion with authors indicates that this is superceded by the other changes in the 2988bis document Documents Not Adopted by WG =========================== TCP Option for Transparent Middlebox Discovery draft-knutsen-tcpm-middlebox-discovery Status: discussed on mailing list and updated in response poll for working group adoption opened on 12/9, responses desired by 12/23 decision not to adopt by WG; IESG may allow publication and option number assignment at their discretion, but TCPM does not have consensus to do this work background presented at IETF 77 authors are working with other vendors on a separate mailing list draft-sridharan-tcpm-ctcp Status: polled for interest on 6/16/10 one positive response; no negative - too weak for adoption Other TCP Documents =================== TCP Cookie Transactions (TCPCT) RFC 6013 Other WG Activities =================== Errata Review for legacy TCP RFCs (many outstanding) -- Wes Eddy MTI Systems From wes@mti-systems.com Mon Mar 28 01:08:59 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACC1D3A688A for ; Mon, 28 Mar 2011 01:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAR2QNlmjs0Q for ; Mon, 28 Mar 2011 01:08:58 -0700 (PDT) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by core3.amsl.com (Postfix) with ESMTP id 949023A6867 for ; Mon, 28 Mar 2011 01:08:58 -0700 (PDT) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p2S8AZbZ011564 for ; Mon, 28 Mar 2011 04:10:35 -0400 Authentication-Results: cm-omr14 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [94.75.220.77] ([94.75.220.77:26793] helo=[10.9.0.26]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id B7/83-28723-A72409D4; Mon, 28 Mar 2011 04:10:35 -0400 Message-ID: <4D904279.2080709@mti-systems.com> Date: Mon, 28 Mar 2011 10:10:33 +0200 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tcpm] meeting preparation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 08:08:59 -0000 The TCPM agenda has been updated a little bit based on feedback: http://www.ietf.org/proceedings/80/agenda/tcpm.txt The agenda is very full. We have a focus on current WG items, and have prioritized those in the agenda. There are also a number of brand new topics being introduced in only very short timeslots. For this to work, we are asking the presenters to minimize introductory slides, and focus instead on their proposal. Please read the drafts in order to help the presenters in this! We will probably have to redirect a lot of comments onto the mailing list. As I see it, the purpose of several of these presentations should be to raise awareness of the documents, get initial feedback, and help to begin the discussions on them. Please keep this in mind when presenting and keep feedback crisp :). -- Wes Eddy MTI Systems From mattmathis@google.com Mon Mar 28 07:39:05 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 104F93A690D for ; Mon, 28 Mar 2011 07:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNaOdH1Bb5qi for ; Mon, 28 Mar 2011 07:39:04 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id F04E93A697C for ; Mon, 28 Mar 2011 07:39:03 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p2SEeeEr013864 for ; Mon, 28 Mar 2011 07:40:40 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301323241; bh=7Hm8uUvOlMRM3vbHuYw2XBCICZE=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type: Content-Transfer-Encoding; b=T5zNZ280d1AIf/h390GTA69KmaiIaW7TmESIujXyq1aj8d/eYwNvHkh+xiYpGybUc hi72RuRxlRpz8m+bUsXzg== Received: from ewy9 (ewy9.prod.google.com [10.241.103.9]) by wpaz9.hot.corp.google.com with ESMTP id p2SEeceU012526 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 28 Mar 2011 07:40:38 -0700 Received: by ewy9 with SMTP id 9so1230827ewy.0 for ; Mon, 28 Mar 2011 07:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=ubdVTBf85VP0urdaEBnmBqR/W+cX5VbYI701PunAdls=; b=SOgJXx4KQM5vH7w7Lb5KQrkKdk8CKAfQr/IFrokH1RdixNoSCgDOa7nHYPVGVhfeIs Mr8RDoyiTpcJgHWxy9AA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=hT4kEYlX9uB3sEc8wQg9W7HnTghJPQbo7bf0EHDIjDKu6T9qAtiFJfPdl5XqXFOtRv kEHA4SsoGNKP6PXytwQQ== MIME-Version: 1.0 Received: by 10.213.1.214 with SMTP id 22mr1710370ebg.46.1301323237617; Mon, 28 Mar 2011 07:40:37 -0700 (PDT) Received: by 10.213.14.139 with HTTP; Mon, 28 Mar 2011 07:40:37 -0700 (PDT) Date: Mon, 28 Mar 2011 10:40:37 -0400 Message-ID: From: Matt Mathis To: TCP Maintenance and Minor Extensions WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Subject: [tcpm] TCP Rate Halving is superseded by Proportional Rate Reduction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 14:39:05 -0000 The old ratehalving draft, draft-mathis-tcp-ratehalving, is superseded by the Proportional Rate Reduction, being presented by Nandita Dukkipati at tcpm. See: draft-mathis-tcpm-proportional-rate-reduction-00.txt Note that the new document is much simpler because it builds on the definitions and framework provided by 3517 and 5681. The old RH draft was stalled due to an unresolved corner case that was not so serious in wider Internet, but was a huge problem for some of our applications at the Pittsburgh Supercomputing Center. The corner case has to do with interactions between application pauses and TCP recovery that results in excessive cwnd reductions. The PRR draft avoids the problem. Thanks, --MM-- The best way to predict the future is to create it. =A0- Alan Kay From Internet-Drafts@ietf.org Mon Mar 28 23:00:06 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 380753A6802; Mon, 28 Mar 2011 23:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miO-ZIh7mXgZ; Mon, 28 Mar 2011 23:00:03 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70FCF3A6812; Mon, 28 Mar 2011 23:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110329060001.29868.1338.idtracker@localhost> Date: Mon, 28 Mar 2011 23:00:01 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-persist-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 06:00:06 -0000 --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 : Clarification of sender behavior in persist condition. Author(s) : M. Bashyam, et al. Filename : draft-ietf-tcpm-persist-04.txt Pages : 12 Date : 2011-03-28 This document clarifies the Zero Window Probes (ZWP) described in Requirements for Internet Hosts [RFC1122]. In particular, it clarifies the actions that can be taken on connections which are experiencing the ZWP condition. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-persist-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-tcpm-persist-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-28224637.I-D@ietf.org> --NextPart-- From henk@uijterwaal.nl Wed Mar 30 01:06:26 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17F343A6B23; Wed, 30 Mar 2011 01:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRt39tfhN3JB; Wed, 30 Mar 2011 01:06:25 -0700 (PDT) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by core3.amsl.com (Postfix) with ESMTP id D3D563A6B0E; Wed, 30 Mar 2011 01:06:24 -0700 (PDT) Received: from dhcp-1653.meeting.ietf.org (dhcp-1653.meeting.ietf.org [130.129.22.83]) (authenticated bits=0) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id p2U882Zm024977 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 30 Mar 2011 10:08:02 +0200 (CEST) (envelope-from henk@uijterwaal.nl) Message-ID: <4D92E4E1.7000308@uijterwaal.nl> Date: Wed, 30 Mar 2011 10:08:01 +0200 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Henk Uijterwaal References: <4C7CBBFD.1030402@ripe.net> <4D677893.2050200@ripe.net> In-Reply-To: <4D677893.2050200@ripe.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: tcpm@ietf.org, IETF IPPM WG Subject: Re: [tcpm] WGLC for draft-ietf-ippm-tcp-throughput-tm-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 08:06:26 -0000 On 25/02/2011 10:38, Henk Uijterwaal wrote: > IPPM WG, > > This is a Working Group Last Call for the draft: > > TCP Throughput Testing Methodology > draft-ietf-ippm-tcp-throughput-tm-12.txt No issues were raised and the WGLC is closed. We'll move the draft forward in the next week or so. Henk > > The -07 version of this document has been submitted to IESG last October. Since > then, there have been several reviews and a lot of text has been changed. > Before proceeding, we think it is good that the WG looks at this document again. > The TCPM WG is cc'd as some members of this group have been > involved in the reviews. > > Please review the draft and raise any issues by Monday, March 28, 2011, 8:00 > UTC. An URL for the draft is: > > http://www.ietf.org/id/draft-ietf-ippm-tcp-throughput-tm-12.txt > > (The date is intentional, if there are issues that require face-2-face > discussion, we can do this in Prague). > > Matt & Henk > > -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl RIPE NCC http://www.xs4all.nl/~henku Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From michawe@ifi.uio.no Wed Mar 30 05:51:18 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B277B3A6816 for ; Wed, 30 Mar 2011 05:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyfCSEIG7Gya for ; Wed, 30 Mar 2011 05:51:15 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id 9F90C3A67FC for ; Wed, 30 Mar 2011 05:51:15 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.72) (envelope-from ) id 1Q4utJ-0002Sl-Km for tcpm@ietf.org; Wed, 30 Mar 2011 14:52:53 +0200 Received: from [130.129.10.50] (helo=dhcp-9232.meeting.ietf.org) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1Q4utJ-0002NE-5E for tcpm@ietf.org; Wed, 30 Mar 2011 14:52:53 +0200 Message-Id: From: Michael Welzl To: tcpm Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 30 Mar 2011 14:52:52 +0200 X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 3 sum rcpts/h 6 sum msgs/h 3 total rcpts 7974 max rcpts/h 36 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 71569F473A8154655E621B83A67350EB08B1A561 X-UiO-SPAM-Test: remote_host: 130.129.10.50 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 33 max/h 7 blacklist 0 greylist 0 ratelimit 0 Subject: [tcpm] My time slot, TCP spurious loss detection with nonces X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 12:51:18 -0000 Hi, It's getting clear that I won't get the time to present at today's meeting; my item on the agenda is listed as tentative, as I also told the chairs that I don't care if they kick me out, I see this as a low- priority item. Anyway: the point of the presentation would have been to repeat the question I raised before on the list: http://www.ietf.org/mail-archive/web/tcpm/current/msg06380.html For more info: the chairs uploaded my slides: http://www.ietf.org/proceedings/80/slides/tcpm-2.pdf and there's more stuff at http://heim.ifi.uio.no/~michawe/research/projects/spurious/index.html I'd just like to get an idea of whether someone cares about this, i.e. whether it's worth continuing, given the shaky ground underneath the ECN nonce. If I don't see any significant interest from the list soon now, it just goes in the dump. No worries though :-) Cheers, Michael From Michael.Scharf@alcatel-lucent.com Wed Mar 30 14:20:20 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6C0128C1AA for ; Wed, 30 Mar 2011 14:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laxUYUpmGYyY for ; Wed, 30 Mar 2011 14:20:20 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id C613628C144 for ; Wed, 30 Mar 2011 14:20:19 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p2ULLvJX018360 for ; Wed, 30 Mar 2011 23:21:57 +0200 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 Date: Wed, 30 Mar 2011 23:21:56 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Interest in draft-mathis-tcpm-proportional-rate-reduction-00? Thread-index: AcvvIH82/PCki9RXQpe1F9A1etpTfQ== From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Subject: [tcpm] Interest in draft-mathis-tcpm-proportional-rate-reduction-00? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 21:20:21 -0000 Folks, since we ran out of time during the TCPM session, I shifted the discussion of draft-mathis-tcp-ratehalving-00 to the list. In order to trigger this discussion, I'd like to start an informal poll who would in principle be interested in the topic of that draft. If so, please reply to this email. Of course, any technical comment would be excellent. Thanks! Michael From michawe@ifi.uio.no Wed Mar 30 16:41:56 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B311728C0F5 for ; Wed, 30 Mar 2011 16:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8tHb0JGZdpp for ; Wed, 30 Mar 2011 16:41:55 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by core3.amsl.com (Postfix) with ESMTP id 9D2FB3A6A7B for ; Wed, 30 Mar 2011 16:41:55 -0700 (PDT) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out2.uio.no with esmtp (Exim 4.74) (envelope-from ) id 1Q552y-0006OH-Ur; Thu, 31 Mar 2011 01:43:32 +0200 Received: from dhcp-44b7.meeting.ietf.org ([130.129.68.183]) by mail-mx5.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1Q552y-0002rr-EU; Thu, 31 Mar 2011 01:43:32 +0200 Message-Id: <1B22A12A-E5F0-4B15-A311-8CA5ED66FFD7@ifi.uio.no> From: Michael Welzl To: "SCHARF, Michael" In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 31 Mar 2011 01:43:30 +0200 References: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 2 sum rcpts/h 6 sum msgs/h 4 total rcpts 7999 max rcpts/h 36 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 841E86120FFF0AA347C9EF6CA5618C24E09D8BE1 X-UiO-SPAM-Test: remote_host: 130.129.68.183 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 30 max/h 7 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm@ietf.org Subject: Re: [tcpm] Interest in draft-mathis-tcpm-proportional-rate-reduction-00? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 23:41:56 -0000 i am in principle interested and have the impression that this is probably a useful document, but too complicated. maybe an example would help? but i am also a bit drunk :-) cheers michael On Mar 30, 2011, at 11:21 PM, SCHARF, Michael wrote: > Folks, > > since we ran out of time during the TCPM session, I shifted the > discussion of draft-mathis-tcp-ratehalving-00 to the list. > > In order to trigger this discussion, I'd like to start an informal > poll > who would in principle be interested in the topic of that draft. If > so, > please reply to this email. Of course, any technical comment would be > excellent. > > Thanks! > > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From muraris@microsoft.com Wed Mar 30 17:07:22 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1932028C1A4 for ; Wed, 30 Mar 2011 17:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.374 X-Spam-Level: X-Spam-Status: No, score=-110.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioSxohWn0QpI for ; Wed, 30 Mar 2011 17:07:21 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 20CFE3A6BEA for ; Wed, 30 Mar 2011 17:07:20 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 30 Mar 2011 17:09:00 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.31]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0270.002; Wed, 30 Mar 2011 17:08:59 -0700 From: Murari Sridharan To: Michael Welzl , "SCHARF, Michael" Thread-Topic: [tcpm] Interest in draft-mathis-tcpm-proportional-rate-reduction-00? Thread-Index: AQHL7zRMzNCQPnDsI0KgD9ysJQl2eJRGkRIA Date: Thu, 31 Mar 2011 00:08:59 +0000 Message-ID: References: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de> <1B22A12A-E5F0-4B15-A311-8CA5ED66FFD7@ifi.uio.no> In-Reply-To: <1B22A12A-E5F0-4B15-A311-8CA5ED66FFD7@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Interest in draft-mathis-tcpm-proportional-rate-reduction-00? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 00:07:22 -0000 I would be interested, I think this is a very useful addition to 3517.=20 -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Mic= hael Welzl Sent: Wednesday, March 30, 2011 4:44 PM To: SCHARF, Michael Cc: tcpm@ietf.org Subject: Re: [tcpm] Interest in draft-mathis-tcpm-proportional-rate-reducti= on-00? i am in principle interested and have the impression that this is probably = a useful document, but too complicated. maybe an example would help? but i am also a bit drunk :-) cheers michael On Mar 30, 2011, at 11:21 PM, SCHARF, Michael wrote: > Folks, > > since we ran out of time during the TCPM session, I shifted the=20 > discussion of draft-mathis-tcp-ratehalving-00 to the list. > > In order to trigger this discussion, I'd like to start an informal=20 > poll who would in principle be interested in the topic of that draft.=20 > If so, please reply to this email. Of course, any technical comment=20 > would be excellent. > > Thanks! > > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nanditad@google.com Wed Mar 30 18:23:08 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7C43A6AAE for ; Wed, 30 Mar 2011 18:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2inlOKJpM679 for ; Wed, 30 Mar 2011 18:23:07 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id F06A43A692C for ; Wed, 30 Mar 2011 18:23:06 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p2V1OjR0014662 for ; Wed, 30 Mar 2011 18:24:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301534685; bh=0ZroXsTKXKzoUWqtlAEDuWVf3KQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type; b=L+SzxFUMXXoOjF+xpYLGOyn7Y+1S8XfT/+dzXl2oZPirDCev7ZgcmGP8OqDXb9Quf bgTOzapDheMiq22a7HtIg== Received: from yie12 (yie12.prod.google.com [10.243.66.12]) by hpaq5.eem.corp.google.com with ESMTP id p2V1O1b4008497 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 30 Mar 2011 18:24:44 -0700 Received: by yie12 with SMTP id 12so908039yie.13 for ; Wed, 30 Mar 2011 18:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=9pEF/Yrhp7ER13r7ff8AD8L4Sjq62BgIQOH4SHvU0tE=; b=KAq3SOttNelBVVxBuKDJd3XrMSvVi+kO9tZ0Xi0O+kewc4pdQhHXxiVmf6cIB2FRq1 xMno2WXygkij9ob2/AEQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=R+QJcffBWP/gHOqTuL1GDl/GRkxXPq2dGAw1/zDq5DBSc+QLeytbu4MevFchOPBOFg /j7hAcwfGAkPCe2Tikdw== MIME-Version: 1.0 Received: by 10.90.156.12 with SMTP id d12mr2338238age.46.1301534682392; Wed, 30 Mar 2011 18:24:42 -0700 (PDT) Received: by 10.91.219.10 with HTTP; Wed, 30 Mar 2011 18:24:42 -0700 (PDT) In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de> References: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de> Date: Thu, 31 Mar 2011 03:24:42 +0200 Message-ID: From: Nandita Dukkipati To: "SCHARF, Michael" , tcpm@ietf.org Content-Type: multipart/alternative; boundary=00163630eabd68292c049fbd28a4 X-System-Of-Record: true Subject: Re: [tcpm] Interest in draft-mathis-tcpm-proportional-rate-reduction-00? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 01:23:08 -0000 --00163630eabd68292c049fbd28a4 Content-Type: text/plain; charset=ISO-8859-1 Hi everyone, For those not present at the meeting, here's the link to the presentation slides. We welcome any questions or suggestions. link: http://www.ietf.org/proceedings/80/slides/tcpm-6.pdf thanks, -Nandita On Wed, Mar 30, 2011 at 11:21 PM, SCHARF, Michael < Michael.Scharf@alcatel-lucent.com> wrote: > Folks, > > since we ran out of time during the TCPM session, I shifted the > discussion of draft-mathis-tcp-ratehalving-00 to the list. > > In order to trigger this discussion, I'd like to start an informal poll > who would in principle be interested in the topic of that draft. If so, > please reply to this email. Of course, any technical comment would be > excellent. > > Thanks! > > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --00163630eabd68292c049fbd28a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi everyone,=A0

For those not present at the meeting, he= re's the link to the presentation slides. We welcome any questions or s= uggestions.
link: http://www.ietf.org/proceedings/80/slides/tcpm-6.pdf= =A0

thanks,
-Nandita

On Wed, Mar 30, 2011 at 11:21 PM, SCHARF, Michael <= span dir=3D"ltr"><M= ichael.Scharf@alcatel-lucent.com> wrote:
Folks,

since we ran out of time during the TCPM session, I shifted the
discussion of draft-mathis-tcp-ratehalving-00 to the list.

In order to trigger this discussion, I'd like to start an informal poll=
who would in principle be interested in the topic of that draft. If so,
please reply to this email. Of course, any technical comment would be
excellent.

Thanks!

Michael
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--00163630eabd68292c049fbd28a4-- From nanditad@google.com Wed Mar 30 18:28:41 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36363A6AE4 for ; Wed, 30 Mar 2011 18:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPpvXmAM0yeS for ; Wed, 30 Mar 2011 18:28:40 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 425313A6AE3 for ; Wed, 30 Mar 2011 18:28:40 -0700 (PDT) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id p2V1UHps013091 for ; Wed, 30 Mar 2011 18:30:18 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301535018; bh=woZloaZPPqO/LbByzxNqw/bVng4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Z5H4GVWgTPsBuj1kXh7bsDyv+87Imuh6FGftIJQwPVQXCKQZziKLHVNX8SbknFe9f HZfQZoabRlNI1C4p+1nEA== Received: from yib18 (yib18.prod.google.com [10.243.65.82]) by kpbe15.cbf.corp.google.com with ESMTP id p2V1UGPJ030527 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 30 Mar 2011 18:30:16 -0700 Received: by yib18 with SMTP id 18so835886yib.28 for ; Wed, 30 Mar 2011 18:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=67jSwvyPHMeP/joH2OYq90/ai4/BShRuSuHDuMktvjk=; b=QUyRA/uRAssDTMhhVPzxmUfSp4dzEmcjmYwfWRnmO9CfLwwArec61XtgcDnedOmhxq C3mjmnGUXP2KQ5M6ZQGw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DfgiaCjPwK6gjogkVtCDry8SEe8HUWKeyXt1mBmCRCvvq26QgDShMrcDKNqY64ML6F QptQhffWdfszkDi/BIdA== MIME-Version: 1.0 Received: by 10.90.183.18 with SMTP id g18mr2336350agf.73.1301535014114; Wed, 30 Mar 2011 18:30:14 -0700 (PDT) Received: by 10.91.219.10 with HTTP; Wed, 30 Mar 2011 18:30:14 -0700 (PDT) In-Reply-To: <1B22A12A-E5F0-4B15-A311-8CA5ED66FFD7@ifi.uio.no> References: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de> <1B22A12A-E5F0-4B15-A311-8CA5ED66FFD7@ifi.uio.no> Date: Thu, 31 Mar 2011 03:30:14 +0200 Message-ID: From: Nandita Dukkipati To: Michael Welzl Content-Type: multipart/alternative; boundary=00163630f1032ddef2049fbd3c42 X-System-Of-Record: true Cc: tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] Interest in draft-mathis-tcpm-proportional-rate-reduction-00? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 01:28:41 -0000 --00163630f1032ddef2049fbd3c42 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 31, 2011 at 1:43 AM, Michael Welzl wrote: > i am in principle interested and have the impression that this is probably > a useful document, but too complicated. maybe an example would help? That's a great idea - we will post a couple of examples within next few days on how the algorithm behaves under single and multiple losses. It is actually surprisingly simple. > On Mar 30, 2011, at 11:21 PM, SCHARF, Michael wrote: > > Folks, >> >> since we ran out of time during the TCPM session, I shifted the >> discussion of draft-mathis-tcp-ratehalving-00 to the list. >> >> In order to trigger this discussion, I'd like to start an informal poll >> who would in principle be interested in the topic of that draft. If so, >> please reply to this email. Of course, any technical comment would be >> excellent. >> >> Thanks! >> >> Michael >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --00163630f1032ddef2049fbd3c42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 31, 2011 at 1:43 AM, Michael Welzl <= span dir=3D"ltr"><michawe@ifi.uio.= no> wrote:
i am in principle interested and have the impression that this is probably = a useful document, but too complicated. maybe an example would help?

That's a great idea - we will post a couple o= f examples within next few days on how the algorithm behaves under single a= nd multiple losses. It is actually surprisingly simple.

=A0
On Mar 30, 2011, at 11:21 PM, SCHARF, Michael wrote:
Folks,

since we ran out of time during the TCPM session, I shifted the
discussion of draft-mathis-tcp-ratehalving-00 to the list.

In order to trigger this discussion, I'd like to start an informal poll=
who would in principle be interested in the topic of that draft. If so,
please reply to this email. Of course, any technical comment would be
excellent.

Thanks!

Michael
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--00163630f1032ddef2049fbd3c42-- From Michael.Scharf@alcatel-lucent.com Thu Mar 31 00:25:02 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31EEA3A699D for ; Thu, 31 Mar 2011 00:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.23 X-Spam-Level: X-Spam-Status: No, score=-6.23 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0+nkCObySBR for ; Thu, 31 Mar 2011 00:25:01 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id DE01F28C238 for ; Thu, 31 Mar 2011 00:25:00 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p2V7Qdk6008779 for ; Thu, 31 Mar 2011 09:26:39 +0200 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 Date: Thu, 31 Mar 2011 09:26:38 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0522F74B@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Adoption of draft-gont-tcpm-rfc1948bis-00 as WG document Thread-index: AcvvdPkNk0s+fod1Sn2UHOsGljmDVQ== From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Subject: [tcpm] Adoption of draft-gont-tcpm-rfc1948bis-00 as WG document X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 07:25:02 -0000 I'd like to confirm that the working group has consensus to take the draft-gont-tcpm-rfc1948bis-00 as a working group item, heading to Proposed Standard: http://www.ietf.org/id/draft-gont-tcpm-rfc1948bis-00.txt Based on the discussion in the TCPM meeting, there seems to be sufficient interest to this. If anyone disagrees with bringing this in as a working group item, please speek up prior to April 15. Thanks! Michael From ycheng@google.com Thu Mar 31 00:38:10 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B70A3A6B0A for ; Thu, 31 Mar 2011 00:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyMgfQajRRdQ for ; Thu, 31 Mar 2011 00:38:09 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 9E8C33A6A8C for ; Thu, 31 Mar 2011 00:38:08 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p2V7dkLT003852 for ; Thu, 31 Mar 2011 00:39:47 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301557187; bh=w/ujBxzvOe8epvNAjbX6pJssCwI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=TIZ+LPQQUBIj7pR3NNIT20eZNhenaewooDQJTg7otgkQ7i7W/1+E69y6O4tws+Oa6 nR2kvLbVfHlA3idgWYJAA== Received: from vxb39 (vxb39.prod.google.com [10.241.33.103]) by kpbe18.cbf.corp.google.com with ESMTP id p2V7dh3O025829 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 31 Mar 2011 00:39:45 -0700 Received: by vxb39 with SMTP id 39so1769128vxb.26 for ; Thu, 31 Mar 2011 00:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=BOpBJ8zUS4EDKykbg7dNaHsw8xmZVWSpX3fuMkPtRWk=; b=P05g/DwC5KGEAK2dlGk5R2F6ldAqYro5Cm4H13fHRqHWmjKc1YNtFaKBJg+PJotY4o DS7DA9Iy2ukU8w0mfebg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=H5YQW5QYXdpk0UCDkGKHGeSTOUNk/HOVyZlWdS+gmFkow3T34DjyJHsCMgHp73yk5H hs+zg1bG9pyiQvgYBcxQ== Received: by 10.220.180.68 with SMTP id bt4mr567765vcb.180.1301557185086; Thu, 31 Mar 2011 00:39:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.16.148 with HTTP; Thu, 31 Mar 2011 00:39:25 -0700 (PDT) In-Reply-To: References: From: Yuchung Cheng Date: Thu, 31 Mar 2011 09:39:25 +0200 Message-ID: To: Michael Welzl Content-Type: multipart/alternative; boundary=00248c0d7a90ac04e8049fc2652e X-System-Of-Record: true Cc: tcpm Subject: Re: [tcpm] My time slot, TCP spurious loss detection with nonces X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 07:38:10 -0000 --00248c0d7a90ac04e8049fc2652e Content-Type: text/plain; charset=ISO-8859-1 AFAICT, the detection happens one RTT after the spurious retransmit like DSACK? It's a cute idea but since DSACK is on by default in poplar stacks, it may not be that useful? On Wed, Mar 30, 2011 at 2:52 PM, Michael Welzl wrote: > Hi, > > It's getting clear that I won't get the time to present at today's meeting; > my item on the agenda is listed as tentative, as I also told the chairs that > I don't care if they kick me out, I see this as a low-priority item. > > Anyway: the point of the presentation would have been to repeat the > question I raised before on the list: > http://www.ietf.org/mail-archive/web/tcpm/current/msg06380.html > > For more info: the chairs uploaded my slides: > http://www.ietf.org/proceedings/80/slides/tcpm-2.pdf > and there's more stuff at > http://heim.ifi.uio.no/~michawe/research/projects/spurious/index.html > > I'd just like to get an idea of whether someone cares about this, i.e. > whether it's worth continuing, given the shaky ground underneath the ECN > nonce. > If I don't see any significant interest from the list soon now, it just > goes in the dump. No worries though :-) > > Cheers, > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --00248c0d7a90ac04e8049fc2652e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
AFAICT, the detection happens one RTT after the spurious retransmit li= ke DSACK?

It's a cute idea but since DSACK is = on by default in poplar stacks, it may not be that useful?

On Wed, Mar 30, 2011 at 2:52 PM, Michael W= elzl <michawe@if= i.uio.no> wrote:
Hi,

It's getting clear that I won't get the time to present at today= 9;s meeting; my item on the agenda is listed as tentative, as I also told t= he chairs that I don't care if they kick me out, I see this as a low-pr= iority item.

Anyway: the point of the presentation would have been to repeat the questio= n I raised before on the list:
http://www.ietf.org/mail-archive/web/tcpm/current/msg063= 80.html

For more info: the chairs uploaded my slides:
http://www.ietf.org/proceedings/80/slides/tcpm-2.pdf
and there's more stuff at http://heim.ifi.uio.= no/~michawe/research/projects/spurious/index.html

I'd just like to get an idea of whether someone cares about this, i.e. = whether it's worth continuing, given the shaky ground underneath the EC= N nonce.
If I don't see any significant interest from the list soon now, it just= goes in the dump. No worries though =A0:-)

Cheers,
Michael

_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--00248c0d7a90ac04e8049fc2652e-- From michawe@ifi.uio.no Thu Mar 31 01:00:23 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01EE028C1F5 for ; Thu, 31 Mar 2011 01:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTekwSUj8hQ1 for ; Thu, 31 Mar 2011 01:00:21 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by core3.amsl.com (Postfix) with ESMTP id 93F1B28C1FA for ; Thu, 31 Mar 2011 01:00:21 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.72) (envelope-from ) id 1Q5CpM-0001MT-3g; Thu, 31 Mar 2011 10:02:00 +0200 Received: from dhcp-9232.meeting.ietf.org ([130.129.10.50]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1Q5CpL-0003Jr-D4; Thu, 31 Mar 2011 10:02:00 +0200 Message-Id: <1E45E61F-7761-4FAD-9D43-43F91EA38114@ifi.uio.no> From: Michael Welzl To: Yuchung Cheng In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 31 Mar 2011 10:01:58 +0200 References: X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 9 sum msgs/h 4 total rcpts 8018 max rcpts/h 36 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 4ED61720BC97072B53F74BC8D21B92133379DE1B X-UiO-SPAM-Test: remote_host: 130.129.10.50 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 49 max/h 7 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm Subject: Re: [tcpm] My time slot, TCP spurious loss detection with nonces X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 08:00:23 -0000 no, it doesn't. here's an example. you send, say, 10 packets, and run into RTO, and retransmit them all. if you then get, say, acks for packets 1-3 whose nonce sums match the nonces of the originally transmitted packets, you can react. the ack carrying DSACK may still be in flight at this point. in fact, even the retransmitted data packets that would potentially cause a DSACK to be sent would still be in flight. this is illustrated with simulations in the globecom paper and the master thesis at http://heim.ifi.uio.no/~michawe/research/projects/spurious/index.html my question really is about the group's view of the ECN nonce... my idea just adds a bit more value to it, the way i see it - but AFAIK noone uses the nonce... so what? cheers michael On Mar 31, 2011, at 9:39 AM, Yuchung Cheng wrote: > AFAICT, the detection happens one RTT after the spurious retransmit > like DSACK? > > It's a cute idea but since DSACK is on by default in poplar stacks, > it may not be that useful? > > On Wed, Mar 30, 2011 at 2:52 PM, Michael Welzl > wrote: > Hi, > > It's getting clear that I won't get the time to present at today's > meeting; my item on the agenda is listed as tentative, as I also > told the chairs that I don't care if they kick me out, I see this as > a low-priority item. > > Anyway: the point of the presentation would have been to repeat the > question I raised before on the list: > http://www.ietf.org/mail-archive/web/tcpm/current/msg06380.html > > For more info: the chairs uploaded my slides: > http://www.ietf.org/proceedings/80/slides/tcpm-2.pdf > and there's more stuff at http://heim.ifi.uio.no/~michawe/research/projects/spurious/index.html > > I'd just like to get an idea of whether someone cares about this, > i.e. whether it's worth continuing, given the shaky ground > underneath the ECN nonce. > If I don't see any significant interest from the list soon now, it > just goes in the dump. No worries though :-) > > Cheers, > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From rs@netapp.com Thu Mar 31 01:35:19 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A34C28C0F1 for ; Thu, 31 Mar 2011 01:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.307 X-Spam-Level: X-Spam-Status: No, score=-10.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27wkbI7JHA5J for ; Thu, 31 Mar 2011 01:35:17 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id 532A128C0ED for ; Thu, 31 Mar 2011 01:35:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,274,1299484800"; d="scan'208";a="247133776" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 31 Mar 2011 01:36:56 -0700 Received: from ldcrsexc1-prd.hq.netapp.com (ldcrsexc1-prd.hq.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p2V8asU9000259; Thu, 31 Mar 2011 01:36:54 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Mar 2011 09:36:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 31 Mar 2011 09:36:34 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0D9D5740@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <1E45E61F-7761-4FAD-9D43-43F91EA38114@ifi.uio.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] My time slot, TCP spurious loss detection with nonces Thread-Index: AcvvegVkeWHwK+sbRcqDAuPCkvGHRAAArALg References: <1E45E61F-7761-4FAD-9D43-43F91EA38114@ifi.uio.no> From: "Scheffenegger, Richard" To: "Michael Welzl" , "Yuchung Cheng" X-OriginalArrivalTime: 31 Mar 2011 08:36:51.0345 (UTC) FILETIME=[C82C3810:01CBEF7E] Cc: tcpm Subject: Re: [tcpm] My time slot, TCP spurious loss detection with nonces X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 08:35:19 -0000 Yuchung, DSACK feedback can only be sent out, once the receiver has seen these = additional segments. Same problem with F-RTO - detection is delayed.=20 If the original segments carry *SOME* unique tag that would disambiguate = them from the retransmitted ones, this feedback is available to the = sender about 1 RTT earlier... (while you still remember the TCPCB state = prior to the wrong congestion action). Eifel uses timestamp information (if that's sufficiently granular) for = that purpose too - but as discussed, only works if the first = retransmissions is subsequently received in-sequence. Basically, my draft with immediate echoing of the timestamps would = provide the same signal (without the added complexity of a probabilistic = detection only). The added benefit would be, that the sender can figure = this out also when there are reordered ACKs, lost retransmissions etc... Another scheme could also shift the segment boundaries (length of the = data segments) as a signal to disambiguate between original and = retransmitted segments. However, such a scheme - while workable without = any receiver participation and no requirement of any TCP options - has = other issues (ie. Increasing the packet rate =3D network processing = overhead; segment based stacks would also not like that approach I = gather). Sending at least one additional segment for each hole of = sequence space in the receivers buffer would violate the packet = conservation principle as I understand it. One more comment: RFC3540 (ECN Nonce) doesn't appear to be available in = many stacks at all. Conex is also looking into overloading this bit for = a better ECN feedback mechanism than what is in RFC3168, that does not = mask feedback for one RTT (ECE/CWR exchange)... Richard Scheffenegger > -----Original Message----- > From: Michael Welzl [mailto:michawe@ifi.uio.no] > Sent: Donnerstag, 31. M=E4rz 2011 10:02 > To: Yuchung Cheng > Cc: tcpm > Subject: Re: [tcpm] My time slot, TCP spurious loss detection with > nonces >=20 > no, it doesn't. >=20 > here's an example. you send, say, 10 packets, and run into RTO, and > retransmit them all. if you then get, say, acks for packets 1-3 whose > nonce sums match the nonces of the originally transmitted packets, you > can react. the ack carrying DSACK may still be in flight at this > point. in fact, even the retransmitted data packets that would > potentially cause a DSACK to be sent would still be in flight. >=20 > this is illustrated with simulations in the globecom paper and the > master thesis at > http://heim.ifi.uio.no/~michawe/research/projects/spurious/index.html >=20 > my question really is about the group's view of the ECN nonce... my > idea just adds a bit more value to it, the way i see it - but AFAIK > noone uses the nonce... so what? >=20 > cheers > michael >=20 >=20 > On Mar 31, 2011, at 9:39 AM, Yuchung Cheng wrote: >=20 > > AFAICT, the detection happens one RTT after the spurious retransmit > > like DSACK? > > > > It's a cute idea but since DSACK is on by default in poplar stacks, > > it may not be that useful? > > > > On Wed, Mar 30, 2011 at 2:52 PM, Michael Welzl > > wrote: > > Hi, > > > > It's getting clear that I won't get the time to present at today's > > meeting; my item on the agenda is listed as tentative, as I also > > told the chairs that I don't care if they kick me out, I see this as > > a low-priority item. > > > > Anyway: the point of the presentation would have been to repeat the > > question I raised before on the list: > > http://www.ietf.org/mail-archive/web/tcpm/current/msg06380.html > > > > For more info: the chairs uploaded my slides: > > http://www.ietf.org/proceedings/80/slides/tcpm-2.pdf > > and there's more stuff at > http://heim.ifi.uio.no/~michawe/research/projects/spurious/index.html > > > > I'd just like to get an idea of whether someone cares about this, > > i.e. whether it's worth continuing, given the shaky ground > > underneath the ECN nonce. > > If I don't see any significant interest from the list soon now, it > > just goes in the dump. No worries though :-) > > > > Cheers, > > Michael > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michawe@ifi.uio.no Thu Mar 31 01:58:56 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0523A699C for ; Thu, 31 Mar 2011 01:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-BVoFteyBqT for ; Thu, 31 Mar 2011 01:58:55 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [129.240.10.58]) by core3.amsl.com (Postfix) with ESMTP id C5B3B3A6826 for ; Thu, 31 Mar 2011 01:58:54 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.74) (envelope-from ) id 1Q5Dk0-0000Dt-VD; Thu, 31 Mar 2011 11:00:32 +0200 Received: from dhcp-47d5.meeting.ietf.org ([130.129.71.213]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.72) (envelope-from ) id 1Q5Dk0-0002j2-BI; Thu, 31 Mar 2011 11:00:32 +0200 Message-Id: <75AE50DB-6A0D-42D2-8610-2061F223237A@ifi.uio.no> From: Michael Welzl To: "Scheffenegger, Richard" In-Reply-To: <5FDC413D5FA246468C200652D63E627A0D9D5740@LDCMVEXC1-PRD.hq.netapp.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 31 Mar 2011 11:00:31 +0200 References: <1E45E61F-7761-4FAD-9D43-43F91EA38114@ifi.uio.no> <5FDC413D5FA246468C200652D63E627A0D9D5740@LDCMVEXC1-PRD.hq.netapp.com> X-Mailer: Apple Mail (2.936) X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 8 sum msgs/h 4 total rcpts 8024 max rcpts/h 36 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 767D57ECC9DB8987375A4F7CE236D15806D30E7A X-UiO-SPAM-Test: remote_host: 130.129.71.213 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1 max/h 1 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm Subject: Re: [tcpm] My time slot, TCP spurious loss detection with nonces X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 08:58:56 -0000 On Mar 31, 2011, at 10:36 AM, Scheffenegger, Richard wrote: > Yuchung, > > DSACK feedback can only be sent out, once the receiver has seen =20 > these additional segments. Same problem with F-RTO - detection is =20 > delayed. > > If the original segments carry *SOME* unique tag that would =20 > disambiguate them from the retransmitted ones, this feedback is =20 > available to the sender about 1 RTT earlier... (while you still =20 > remember the TCPCB state prior to the wrong congestion action). > > > Eifel uses timestamp information (if that's sufficiently granular) =20 > for that purpose too - but as discussed, only works if the first =20 > retransmissions is subsequently received in-sequence. > > > > Basically, my draft with immediate echoing of the timestamps would =20 > provide the same signal (without the added complexity of a =20 > probabilistic detection only). The added benefit would be, that the =20= > sender can figure this out also when there are reordered ACKs, lost =20= > retransmissions etc... I agree, but of course this prompts me to say "...but it needs =20 timestamps", and "my scheme is probabilistic, yes, but it's still very =20= simple". > Another scheme could also shift the segment boundaries (length of =20 > the data segments) as a signal to disambiguate between original and =20= > retransmitted segments. However, such a scheme - while workable =20 > without any receiver participation and no requirement of any TCP =20 > options - has other issues (ie. Increasing the packet rate =3D network = =20 > processing overhead; segment based stacks would also not like that =20 > approach I gather). Sending at least one additional segment for each =20= > hole of sequence space in the receivers buffer would violate the =20 > packet conservation principle as I understand it. I agree again, but just as a data point, this scheme was actually =20 proposed, in: K. Tan, Q. Zhang, and W. Zhu, =E2=80=9CSTODER: a robust and ef=EF=AC=81cie= nt =20 algorithm for handling spurious retransmit timeouts in =20 TCP,=E2=80=9DinGLOBECOM=E2=80=9905, vol. 6, no. 2, St. Louis, Missouri, = USA, =20 December 2005, pp. 3692=E2=80=933696. > One more comment: RFC3540 (ECN Nonce) doesn't appear to be available =20= > in many stacks at all. Conex is also looking into overloading this =20 > bit for a better ECN feedback mechanism than what is in RFC3168, =20 > that does not mask feedback for one RTT (ECE/CWR exchange)... Yes, exactly - these are the issues that made me give up on my plan of =20= doing this in any case, and made me ask here if there is even any =20 interest on this (i.e. the nonce, in general), or if I'm adding =20 decoration to a corpse here... Cheers, Michael From ilpo.jarvinen@helsinki.fi Thu Mar 31 02:27:18 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C58C28C258 for ; Thu, 31 Mar 2011 02:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5liJvLWEB-3x for ; Thu, 31 Mar 2011 02:27:17 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 40C4B28C27C for ; Thu, 31 Mar 2011 02:24:08 -0700 (PDT) Received: from melkinpaasi.cs.helsinki.fi (melkinpaasi.cs.helsinki.fi [128.214.9.14]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 31 Mar 2011 12:25:44 +0300 id 0008CEF9.4D944898.00003446 Date: Thu, 31 Mar 2011 12:25:44 +0300 (EEST) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@melkinpaasi.cs.helsinki.fi To: tcpm@ietf.org In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de> Message-ID: References: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Interest in draft-mathis-tcpm-proportional-rate-reduction-00? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 09:27:18 -0000 On Wed, 30 Mar 2011, SCHARF, Michael wrote: > since we ran out of time during the TCPM session, I shifted the > discussion of draft-mathis-tcp-ratehalving-00 to the list. ...I assume the draft name in the subject is actually what you meant (the one given here is a bit prehistoric already ;-))... > In order to trigger this discussion, I'd like to start an informal poll > who would in principle be interested in the topic of that draft. If so, > please reply to this email. Of course, any technical comment would be > excellent. I find the idea itself useful and quite intuitive (but I didn't have time just yet to actually convince myself about the details of the given algorithm). ...I've never liked too much about the dubious approach of RFC2581/5681 where TCP pauses first and then continues with exactly the same rate as it did before the congestion was detected. -- i. From ycheng@google.com Thu Mar 31 02:36:53 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0E3B3A6949 for ; Thu, 31 Mar 2011 02:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.644 X-Spam-Level: X-Spam-Status: No, score=-105.644 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quyMx-tW2HqW for ; Thu, 31 Mar 2011 02:36:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 2154028C0F1 for ; Thu, 31 Mar 2011 02:36:46 -0700 (PDT) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id p2V9cOJI024555 for ; Thu, 31 Mar 2011 02:38:24 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301564305; bh=Hrbj/j6ZKYXSXZzID9O/rUPnl78=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=O5M6OnZ6vL2keXF7SSx/LQv/2xi8Gy2ww/mAoPkHe4JWzWJXwsJnuUGmcFOYHD+/0 wsuG6d2Ju6qN659de8Jyg== Received: from vws7 (vws7.prod.google.com [10.241.21.135]) by kpbe20.cbf.corp.google.com with ESMTP id p2V9cCt3018628 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 31 Mar 2011 02:38:23 -0700 Received: by vws7 with SMTP id 7so2454542vws.21 for ; Thu, 31 Mar 2011 02:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=D4BkPiN0ZU3for0r1dIlZQyq9R2sQMBEqoD21sXGm70=; b=Nw7P0q2yOlU7otc86pp19DoF0eG6ydRviMJ6YVDoFM7SOObKmv3P4gABK1KbvMPqMc udrJOLSRMKJ7dK3cEhgQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=KEa7PkeZGvUud3pG1TiBLKD9FkHVLZYnVQr+zmmwivsAdE4Frqtd4HoGeKZ5FkKf9o TO0WbIrkOwEQYy5Pl4lw== Received: by 10.220.180.68 with SMTP id bt4mr596352vcb.180.1301564303156; Thu, 31 Mar 2011 02:38:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.16.148 with HTTP; Thu, 31 Mar 2011 02:38:03 -0700 (PDT) In-Reply-To: <5FDC413D5FA246468C200652D63E627A0D5F20BE@LDCMVEXC1-PRD.hq.netapp.com> References: <5FDC413D5FA246468C200652D63E627A0D5F20BE@LDCMVEXC1-PRD.hq.netapp.com> From: Yuchung Cheng Date: Thu, 31 Mar 2011 11:38:03 +0200 Message-ID: To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=00248c0d7a90f12787049fc40d3e X-System-Of-Record: true Cc: tcpm@ietf.org, michawe Subject: Re: [tcpm] Using the ECN Nonce to detect spurious loss events X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 09:36:53 -0000 --00248c0d7a90f12787049fc40d3e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 16, 2011 at 1:05 PM, Scheffenegger, Richard wrote: > Hi Michael, > > I believe that your goal is very worthwhile - detecting spurious > retransmissions and fixing the CC reaction. > > But neither ECN nor ECN-nounce are very widely deployed (in comparison with > Timestamp - Eifel; SACK - DSACK). Hopefully, the state of ECN will improve > with IPv6 (and now, that a number of major OS allow enabling ECN, even > though it's not enabled by default). > AFAIK TCP-TS is supported in Microsoft Windows but not enabled by default. Maybe TCP-TS can not considered widely-deployed? However, as the number of SACK (DSACK) enabled sessions is already quite > high, and there is less (no) state required in the server to discriminate > spurious retransmissions with very high probability. I think documenting the > proper response to DSACK (only the signaling is currently documented, IIRC) > may be more valuable to drive adoption with commercial stacks - often stacks > actively signal DSACK, but don't process that feedback themselves... > Linux already (partially) implements RFC4015? > > Overall, I'm afraid I don't see that efforts to improve your scheme would > see much deployment because of all these reasons. > After Michael's clarification, I like the idea a lot more In particular, I see the value in data centers: 1) receivers won't cheat (hopefully) 2) if (fast) retransmission was sent within the TS granular (e.g. 1ms), the detection has to rely on DSACK instead (2+ RTT slower) --00248c0d7a90f12787049fc40d3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Mar 16, 2011 at 1:05 PM, Scheffe= negger, Richard <rs@netapp.com> wrote:
Hi Michael,

I believe that your goal is very worthwhile - detecting spurious retransmis= sions and fixing the CC reaction.

But neither ECN nor ECN-nounce are very widely deployed (in comparison with= Timestamp - Eifel; SACK - DSACK). Hopefully, the state of ECN will improve= with IPv6 (and now, that a number of major OS allow enabling ECN, even tho= ugh it's not enabled by default).
=A0
AFAIK TCP-TS is supported in Microsoft Wind= ows but not enabled by default. Maybe TCP-TS can not considered widely-depl= oyed?

However, as the number of SACK (DSACK) enabled sessions is already quite hi= gh, and there is less (no) state required in the server to discriminate spu= rious retransmissions with very high probability. I think documenting the p= roper response to DSACK (only the signaling is currently documented, IIRC) = may be more valuable to drive adoption with commercial stacks - often stack= s actively signal DSACK, but don't process that feedback themselves...<= br>
Linux already (partially) implements RFC4015?=A0
=A0

Overall, I'm afraid I don't see that efforts to improve your scheme= would see much deployment because of all these reasons.

After Michael's clarification, I like the idea a lot = more

In particular, I see the value in data centers:
1) receivers won't cheat=A0(hopefully)=A0
2) if (fast) ret= ransmission was sent within the TS granular (e.g. 1ms), the detection has t= o rely on DSACK instead (2+ RTT slower)


--00248c0d7a90f12787049fc40d3e-- From Michael.Scharf@alcatel-lucent.com Thu Mar 31 03:17:28 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 799D528C0D8 for ; Thu, 31 Mar 2011 03:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.233 X-Spam-Level: X-Spam-Status: No, score=-6.233 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgOYAFSLDs9Q for ; Thu, 31 Mar 2011 03:17:27 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id 726A928C0CE for ; Thu, 31 Mar 2011 03:17:27 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p2VAJ5In004324 for ; Thu, 31 Mar 2011 12:19:05 +0200 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 Date: Thu, 31 Mar 2011 12:19:04 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0522F774@SLFSNX.rcs.alcatel-research.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [tcpm] Interest in draft-mathis-tcpm-proportional-rate-reduction-00? Thread-index: AcvvhvE6BySnONOZTM64APD1NkF9pAABZCxQ References: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de> From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Subject: Re: [tcpm] Interest in draft-mathis-tcpm-proportional-rate-reduction-00? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 10:17:28 -0000 > > since we ran out of time during the TCPM session, I shifted the=20 > > discussion of draft-mathis-tcp-ratehalving-00 to the list. >=20 > ...I assume the draft name in the subject is actually what=20 > you meant (the one given here is a bit prehistoric already ;-))... Of course, I meant draft-mathis-tcpm-proportional-rate-reduction-00. Sorry, this was a copy and past error; I had both drafts open in parallel in the Web browser. Thanks for pointing this out! Michael From alexander.zimmermann@comsys.rwth-aachen.de Thu Mar 31 03:33:23 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BAA63A6B23 for ; Thu, 31 Mar 2011 03:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdTL6DemAb-l for ; Thu, 31 Mar 2011 03:33:21 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 66DCD3A6B29 for ; Thu, 31 Mar 2011 03:33:21 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LIX000S542CD800@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Thu, 31 Mar 2011 12:35:00 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.63,274,1299452400"; d="scan'208";a="51807898" Received: from relay-auth-1.ms.rz.rwth-aachen.de (HELO relay-auth-1) ([134.130.7.78]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Thu, 31 Mar 2011 12:35:00 +0200 Received: from [IPv6:::1] ([unknown] [137.226.54.2]) by relay-auth-1.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LIX007RU42BY880@relay-auth-1.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Thu, 31 Mar 2011 12:35:00 +0200 (CEST) From: Alexander Zimmermann In-reply-to: <5FDC413D5FA246468C200652D63E627A0D9D5740@LDCMVEXC1-PRD.hq.netapp.com> Date: Thu, 31 Mar 2011 12:34:58 +0200 Message-id: References: <1E45E61F-7761-4FAD-9D43-43F91EA38114@ifi.uio.no> <5FDC413D5FA246468C200652D63E627A0D9D5740@LDCMVEXC1-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: tcpm , Michael Welzl Subject: Re: [tcpm] My time slot, TCP spurious loss detection with nonces X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 10:33:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Am 31.03.2011 um 10:36 schrieb Scheffenegger, Richard: > Yuchung, > > DSACK feedback can only be sent out, once the receiver has seen these additional segments. Same problem with F-RTO - detection is delayed. Richard, I don't get this. IMO F-RTO is fast as Eifel regarding the detection time. It avoids the typical go-back-n recovery. Alex > > If the original segments carry *SOME* unique tag that would disambiguate them from the retransmitted ones, this feedback is available to the sender about 1 RTT earlier... (while you still remember the TCPCB state prior to the wrong congestion action). > > > Eifel uses timestamp information (if that's sufficiently granular) for that purpose too - but as discussed, only works if the first retransmissions is subsequently received in-sequence. > > > > Basically, my draft with immediate echoing of the timestamps would provide the same signal (without the added complexity of a probabilistic detection only). The added benefit would be, that the sender can figure this out also when there are reordered ACKs, lost retransmissions etc... > > > Another scheme could also shift the segment boundaries (length of the data segments) as a signal to disambiguate between original and retransmitted segments. However, such a scheme - while workable without any receiver participation and no requirement of any TCP options - has other issues (ie. Increasing the packet rate = network processing overhead; segment based stacks would also not like that approach I gather). Sending at least one additional segment for each hole of sequence space in the receivers buffer would violate the packet conservation principle as I understand it. > > > One more comment: RFC3540 (ECN Nonce) doesn't appear to be available in many stacks at all. Conex is also looking into overloading this bit for a better ECN feedback mechanism than what is in RFC3168, that does not mask feedback for one RTT (ECE/CWR exchange)... > > > Richard Scheffenegger // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk2UWNIACgkQdyiq39b9uS6kxgCgoRPVumFllR3dlJLit22S3KVw K+MAoIXmFojBjzN38arXM+2qHEIaer1M =7yty -----END PGP SIGNATURE----- From rs@netapp.com Thu Mar 31 04:25:04 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BBBB28C13F for ; Thu, 31 Mar 2011 04:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.33 X-Spam-Level: X-Spam-Status: No, score=-10.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egJ2scvOHtI4 for ; Thu, 31 Mar 2011 04:25:03 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 740BD28C136 for ; Thu, 31 Mar 2011 04:25:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,274,1299484800"; d="scan'208";a="248189666" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 31 Mar 2011 04:26:41 -0700 Received: from amsrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p2VBQdjs004058; Thu, 31 Mar 2011 04:26:41 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Mar 2011 13:26:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 31 Mar 2011 12:26:39 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0D9D5905@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Interest in draft-mathis-tcpm-proportional-rate-reduction-00? Thread-Index: AcvvIH82/PCki9RXQpe1F9A1etpTfQAZ7bOA References: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de> From: "Scheffenegger, Richard" To: "SCHARF, Michael" , X-OriginalArrivalTime: 31 Mar 2011 11:26:41.0000 (UTC) FILETIME=[81AE2E80:01CBEF96] Subject: Re: [tcpm] Interest in draft-mathis-tcpm-proportional-rate-reduction-00? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 11:25:04 -0000 Are you asking about the ratehalving or the proportional rate reduction = draft? I like the general idea, but matt pointed out that ratehalving has = serious issues when the data socket runs empty and the sender is = application limited; with the proportional rate reduction, this aspect = is fixed (which I consider very important for my use case), thus I'm in = full support of the PRR-RB draft. (Afaik, it also fixes the half-way RH implementation of Linux, another = good aspect). Richard Scheffenegger > -----Original Message----- > From: SCHARF, Michael [mailto:Michael.Scharf@alcatel-lucent.com] > Sent: Mittwoch, 30. M=E4rz 2011 23:22 > To: tcpm@ietf.org > Subject: [tcpm] Interest in draft-mathis-tcpm-proportional-rate- > reduction-00? >=20 > Folks, >=20 > since we ran out of time during the TCPM session, I shifted the > discussion of draft-mathis-tcp-ratehalving-00 to the list. >=20 > In order to trigger this discussion, I'd like to start an informal = poll > who would in principle be interested in the topic of that draft. If = so, > please reply to this email. Of course, any technical comment would be > excellent. >=20 > Thanks! >=20 > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Thu Mar 31 04:25:13 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AB7328C1B6 for ; Thu, 31 Mar 2011 04:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.349 X-Spam-Level: X-Spam-Status: No, score=-10.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhbfRDq+Xvtn for ; Thu, 31 Mar 2011 04:25:12 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id 26D8928C136 for ; Thu, 31 Mar 2011 04:25:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,274,1299484800"; d="scan'208";a="247140873" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 31 Mar 2011 04:26:42 -0700 Received: from amsrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p2VBQdju004058; Thu, 31 Mar 2011 04:26:41 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Mar 2011 13:26:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 31 Mar 2011 12:26:40 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0D9D5907@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Interestin draft-mathis-tcpm-proportional-rate-reduction-00? Thread-Index: AQHL7zRMzNCQPnDsI0KgD9ysJQl2eJRGkRIAgACicDA= References: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de><1B22A12A-E5F0-4B15-A311-8CA5ED66FFD7@ifi.uio.no> From: "Scheffenegger, Richard" To: "Murari Sridharan" , "Michael Welzl" , "SCHARF, Michael" X-OriginalArrivalTime: 31 Mar 2011 11:26:41.0328 (UTC) FILETIME=[81E03B00:01CBEF96] Cc: tcpm@ietf.org Subject: Re: [tcpm] Interestin draft-mathis-tcpm-proportional-rate-reduction-00? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 11:25:13 -0000 Murari, PRR-RD is not limited to the SACK case though (but it works near optimal = when SACK is enabled) :). Are you saying you'd want to use it only together with SACK, retaining = NewReno for non-SACK sessions? Richard Scheffenegger > -----Original Message----- > From: Murari Sridharan [mailto:muraris@microsoft.com] > Sent: Donnerstag, 31. M=E4rz 2011 02:09 > To: Michael Welzl; SCHARF, Michael > Cc: tcpm@ietf.org > Subject: Re: [tcpm] Interestin draft-mathis-tcpm-proportional-rate- > reduction-00? >=20 > I would be interested, I think this is a very useful addition to 3517. >=20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf = Of > Michael Welzl > Sent: Wednesday, March 30, 2011 4:44 PM > To: SCHARF, Michael > Cc: tcpm@ietf.org > Subject: Re: [tcpm] Interest in draft-mathis-tcpm-proportional-rate- > reduction-00? >=20 > i am in principle interested and have the impression that this is > probably a useful document, but too complicated. maybe an example = would > help? >=20 > but i am also a bit drunk :-) >=20 > cheers > michael >=20 >=20 > On Mar 30, 2011, at 11:21 PM, SCHARF, Michael wrote: >=20 > > Folks, > > > > since we ran out of time during the TCPM session, I shifted the > > discussion of draft-mathis-tcp-ratehalving-00 to the list. > > > > In order to trigger this discussion, I'd like to start an informal > > poll who would in principle be interested in the topic of that = draft. > > If so, please reply to this email. Of course, any technical comment > > would be excellent. > > > > Thanks! > > > > Michael > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Thu Mar 31 04:25:14 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A55928C146 for ; Thu, 31 Mar 2011 04:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.216 X-Spam-Level: X-Spam-Status: No, score=-10.216 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pV0Ot0APgOfy for ; Thu, 31 Mar 2011 04:25:13 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id 3B2E628C199 for ; Thu, 31 Mar 2011 04:25:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,274,1299484800"; d="scan'208";a="247140876" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 31 Mar 2011 04:26:42 -0700 Received: from amsrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p2VBQdk2004058; Thu, 31 Mar 2011 04:26:42 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Mar 2011 13:26:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 31 Mar 2011 12:26:40 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0D9D5909@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Interest in draft-mathis-tcpm-proportional-rate-reduction-00? Thread-Index: AcvvhwQpAapCgrzKSpe+sggNiIVSMQAAt6cQ References: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de> From: "Scheffenegger, Richard" To: =?iso-8859-1?Q?Ilpo_J=E4rvinen?= , X-OriginalArrivalTime: 31 Mar 2011 11:26:41.0985 (UTC) FILETIME=[82447B10:01CBEF96] Subject: Re: [tcpm] Interest in draft-mathis-tcpm-proportional-rate-reduction-00? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 11:25:14 -0000 > -----Original Message----- > From: Ilpo J=E4rvinen [mailto:ilpo.jarvinen@helsinki.fi] > > I've never liked too much about the dubious approach of > RFC2581/5681 where TCP pauses first and then continues with exactly = the > same rate as it did before the congestion was detected. Fully agree - the current behavior actually causes subsequent losses, = particular in low-latency environments (where the RTT is in the same = order of time, as the network conditions change. with the current = standard response, there is a high likelihood that your retransmissions = hit the network -with the same rate as noted - while the congested = condition still persists. This subsequently often (well, with easily = observable probability) leads to lost retransmissions and then to a = retransmit timeout to recover from that... (unless you sway from RFC3517 = like Linux does) The immediate reduction in sending rate is a very very useful property. = The numbers shown in the presentation seem to support my claim above = (fewer retransmission timeouts with PRR-RB at comparable fast retransmit = events). This even though Linux can already recover many lost = retransmissions with SACK though! Richard Scheffenegger From rs@netapp.com Thu Mar 31 04:25:18 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A3E428C1D6 for ; Thu, 31 Mar 2011 04:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.37 X-Spam-Level: X-Spam-Status: No, score=-10.37 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEPXuEDtI6rz for ; Thu, 31 Mar 2011 04:25:13 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id C058728C171 for ; Thu, 31 Mar 2011 04:25:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,274,1299484800"; d="scan'208,217";a="247140874" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 31 Mar 2011 04:26:42 -0700 Received: from amsrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p2VBQdjw004058; Thu, 31 Mar 2011 04:26:42 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Mar 2011 13:26:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEF96.81804454" Date: Thu, 31 Mar 2011 12:26:40 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0D9D5908@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Interest indraft-mathis-tcpm-proportional-rate-reduction-00? Thread-Index: AcvvQzaEkhg67eg6QRSlRiSaGA6ZOwARg2Ag References: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de><1B22A12A-E5F0-4B15-A311-8CA5ED66FFD7@ifi.uio.no> From: "Scheffenegger, Richard" To: "Nandita Dukkipati" , "Michael Welzl" X-OriginalArrivalTime: 31 Mar 2011 11:26:41.0766 (UTC) FILETIME=[82231060:01CBEF96] Cc: tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] Interest indraft-mathis-tcpm-proportional-rate-reduction-00? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 11:25:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEF96.81804454 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nandita, =20 I would also be interested in learning how the algorithm behaves, when = more then one half of the window is lost (ie, there aren't enough ACKs = sent back to clock out each allowed data segment by it's own ACK). Will = it clock out multiple segments per ACK (and if so, will they be spread = over the remaining ACKs, so to limit the maximum number of sent packets = per ACK - or would PRR-RB by itself allow a burst of packets being = clocked out by a single ACK? I think Linux does such a send-rate = clamping automatically - how is the interaction with PRR-RB, should that = not be part of this draft too)? =20 =20 Richard Scheffenegger =20 From: Nandita Dukkipati [mailto:nanditad@google.com]=20 Sent: Donnerstag, 31. M=E4rz 2011 03:30 To: Michael Welzl Cc: tcpm@ietf.org; SCHARF, Michael Subject: Re: [tcpm] Interest = indraft-mathis-tcpm-proportional-rate-reduction-00? =20 On Thu, Mar 31, 2011 at 1:43 AM, Michael Welzl = wrote: i am in principle interested and have the impression that this is = probably a useful document, but too complicated. maybe an example would = help? =20 That's a great idea - we will post a couple of examples within next few = days on how the algorithm behaves under single and multiple losses. It = is actually surprisingly simple. =20 =20 On Mar 30, 2011, at 11:21 PM, SCHARF, Michael wrote: Folks, =09 since we ran out of time during the TCPM session, I shifted the discussion of draft-mathis-tcp-ratehalving-00 to the list. =09 In order to trigger this discussion, I'd like to start an informal poll who would in principle be interested in the topic of that draft. If so, please reply to this email. Of course, any technical comment would be excellent. =09 Thanks! =09 Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm =09 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm =20 ------_=_NextPart_001_01CBEF96.81804454 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Nandita,

 

I would also be interested in learning how the algorithm behaves, = when more then one half of the window is lost (ie, there aren’t = enough ACKs sent back to clock out each allowed data segment by = it’s own ACK). Will it clock out multiple segments per ACK (and if = so, will they be spread over the remaining ACKs, so to limit the maximum = number of sent packets per ACK – or would PRR-RB by itself allow a = burst of packets being clocked out by a single ACK? I think Linux does = such a send-rate clamping automatically – how is the interaction = with PRR-RB, should that not be part of this draft = too)?

 

 

Richard Scheffenegger

 

From:= Nandita = Dukkipati [mailto:nanditad@google.com]
Sent: Donnerstag, 31. = M=E4rz 2011 03:30
To: Michael Welzl
Cc: = tcpm@ietf.org; SCHARF, Michael
Subject: Re: [tcpm] Interest = indraft-mathis-tcpm-proportional-rate-reduction-00?

=

 

On Thu, Mar 31, 2011 at 1:43 AM, Michael Welzl <michawe@ifi.uio.no> = wrote:

i am in principle interested = and have the impression that this is probably a useful document, but too = complicated. maybe an example would help?

 

That's a great idea - we will post a couple of = examples within next few days on how the algorithm behaves under single = and multiple losses. It is actually surprisingly = simple.

 

 

On Mar 30, 2011, at 11:21 PM, SCHARF, = Michael wrote:

Folks,

since we = ran out of time during the TCPM session, I shifted the
discussion of = draft-mathis-tcp-ratehalving-00 to the list.

In order to trigger = this discussion, I'd like to start an informal poll
who would in = principle be interested in the topic of that draft. If so,
please = reply to this email. Of course, any technical comment would = be
excellent.

Thanks!

Michael
_______________________= ________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm


_______________________________________________
= tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

 

------_=_NextPart_001_01CBEF96.81804454-- From rs@netapp.com Thu Mar 31 04:50:46 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DAAC3A68B7 for ; Thu, 31 Mar 2011 04:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.384 X-Spam-Level: X-Spam-Status: No, score=-10.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0DcTDUjOziv for ; Thu, 31 Mar 2011 04:50:45 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 7E1343A6875 for ; Thu, 31 Mar 2011 04:50:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,275,1299484800"; d="scan'208";a="248191822" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 31 Mar 2011 04:52:24 -0700 Received: from amsrsexc1-prd.hq.netapp.com (amsrsexc1-prd.hq.netapp.com [10.64.251.107]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p2VBqOIU009742; Thu, 31 Mar 2011 04:52:24 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.107]) by amsrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Mar 2011 13:52:24 +0200 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 Date: Thu, 31 Mar 2011 12:52:07 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0D9D594D@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] My time slot, TCP spurious loss detection with nonces Thread-Index: Acvvj1AcXzMc0QN/TPCnQ+xWFQN1SQAChWlw References: <1E45E61F-7761-4FAD-9D43-43F91EA38114@ifi.uio.no> <5FDC413D5FA246468C200652D63E627A0D9D5740@LDCMVEXC1-PRD.hq.netapp.com> From: "Scheffenegger, Richard" To: "Alexander Zimmermann" X-OriginalArrivalTime: 31 Mar 2011 11:52:24.0639 (UTC) FILETIME=[19C2CCF0:01CBEF9A] Cc: tcpm , Michael Welzl Subject: Re: [tcpm] My time slot, TCP spurious loss detection with nonces X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 11:50:46 -0000 > Richard, I don't get this. IMO F-RTO is fast as Eifel regarding the > detection time. > It avoids the typical go-back-n recovery. True, sorry. Of course, the same limitation that applies to Eifel also applies here (tcp timestamp clock needs to tick once per RTT at least).=20 Richard Scheffenegger From Michael.Scharf@alcatel-lucent.com Thu Mar 31 07:55:30 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D78828C0F7 for ; Thu, 31 Mar 2011 07:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOUiQIVkzZw2 for ; Thu, 31 Mar 2011 07:55:29 -0700 (PDT) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by core3.amsl.com (Postfix) with ESMTP id 194A528C0E7 for ; Thu, 31 Mar 2011 07:55:28 -0700 (PDT) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id p2VEv7up022528 for ; Thu, 31 Mar 2011 16:57:07 +0200 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 Date: Thu, 31 Mar 2011 16:57:05 +0200 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C0522F7A6@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [tcpm] Working group consensus concerning TCP-AO NAT draft Thread-index: Acvj9spmxORQD0fwRUyWNF+wHNi0ZALuPOBA From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.64 on 149.204.45.73 Subject: [tcpm] Working group consensus concerning TCP-AO NAT draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:55:30 -0000 Folks, in yesterday's meeting there has been no apparent interest in draft-touch-tcp-ao-nat-02, and the deadline of the poll has expired. If there is lack of interest, the document has to move forward as an independent submission without further feedback from the working group.=20 I'd like to verify that this is the consensus of the working group. Please speak up urgently if you should disagree. Michael -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Wesley Eddy Sent: Wednesday, March 16, 2011 5:25 PM To: tcpm@ietf.org Subject: [tcpm] poll for adoption of TCP-AO NAT draft TCP-AO has been published for some time. NAT support was separated from AO during development, but Joe has maintained a draft describing how to support operation through NATs and it has been discussed in the past on the mailing list and in TCPM meetings. This is a relatively short document, and Joe has recently updated it based on feedback. The latest copy of the document is at: http://tools.ietf.org/html/draft-touch-tcp-ao-nat-02 Please let us know in the next 2 weeks (by March 30) if you would support this as a WG document (via reviewing and commenting on it) for Proposed Standard. If needed, we can discuss this in Prague. Thanks for your feedback. -- Wes Eddy MTI Systems _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From ananth@cisco.com Thu Mar 31 10:15:48 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95F883A6B32 for ; Thu, 31 Mar 2011 10:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.381 X-Spam-Level: X-Spam-Status: No, score=-11.381 tagged_above=-999 required=5 tests=[AWL=-0.782, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukC3OJaWqld8 for ; Thu, 31 Mar 2011 10:15:47 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 8CCA03A6A63 for ; Thu, 31 Mar 2011 10:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=2552; q=dns/txt; s=iport; t=1301591847; x=1302801447; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=nnQnie/Yk0gb5olmGGWMpi1/D+msQdkRt5fNT9vPnVk=; b=L+k1XB2iszuPivEuVdKNnja0O4tcgjMlJ0K4W6oWQ38Yg/moxYROjMr7 FWz5Tx5naqOKwKKgCMlQkeiXEKMeIKL5l66WEVJpCDcBiHGf4Zn4bH/mC /EzpVjaUocdLKn+VzmP2HwRSrqB8sOaWXnqky0V0oce9cnI3fRsE3MYg5 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgABAH22lE2rRDoI/2dsb2JhbACYEo1Ad6M4nDKDCYJiBIVBiys X-IronPort-AV: E=Sophos;i="4.63,276,1299456000"; d="scan'208";a="286700350" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 31 Mar 2011 17:17:27 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2VHHPTJ028011; Thu, 31 Mar 2011 17:17:26 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Mar 2011 10:17:25 -0700 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 Date: Thu, 31 Mar 2011 10:17:23 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580C56CF8A@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C0522F7A6@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Working group consensus concerning TCP-AO NAT draft Thread-Index: Acvj9spmxORQD0fwRUyWNF+wHNi0ZALuPOBAAAWw46A= References: <133D9897FB9C5E4E9DF2779DC91E947C0522F7A6@SLFSNX.rcs.alcatel-research.de> From: "Anantha Ramaiah (ananth)" To: "SCHARF, Michael" , X-OriginalArrivalTime: 31 Mar 2011 17:17:25.0715 (UTC) FILETIME=[814EDA30:01CBEFC7] Subject: Re: [tcpm] Working group consensus concerning TCP-AO NAT draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 17:15:48 -0000 I had already already communicated my comments to Joe in private conversation. I am listing them below. - This method won't work when NAT is doing the ALG functionality. Examples include FTP, SIP, Skinny protocol, etc., Since some part of the payload (IP addr/port) needs to be adjusted for ALG's. Hence this restricts the applicability of this document to some NAT features. I would urge that this limitation is explicitly noted in the document irrespective of whichever route it takes. (individual or WG) Thanks, -Anantha > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > SCHARF, Michael > Sent: Thursday, March 31, 2011 7:57 AM > To: tcpm@ietf.org > Subject: [tcpm] Working group consensus concerning TCP-AO NAT draft >=20 > Folks, >=20 > in yesterday's meeting there has been no apparent interest in > draft-touch-tcp-ao-nat-02, and the deadline of the poll has expired. If > there is lack of interest, the document has to move forward as an > independent submission without further feedback from the working group. >=20 > I'd like to verify that this is the consensus of the working group. > Please speak up urgently if you should disagree. >=20 > Michael >=20 >=20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Wesley Eddy > Sent: Wednesday, March 16, 2011 5:25 PM > To: tcpm@ietf.org > Subject: [tcpm] poll for adoption of TCP-AO NAT draft >=20 > TCP-AO has been published for some time. NAT support was separated > from > AO during development, but Joe has maintained a draft describing how to > support operation through NATs and it has been discussed in the past on > the mailing list and in TCPM meetings. >=20 > This is a relatively short document, and Joe has recently updated it > based on feedback. >=20 > The latest copy of the document is at: > http://tools.ietf.org/html/draft-touch-tcp-ao-nat-02 >=20 > Please let us know in the next 2 weeks (by March 30) if you would > support this as a WG document (via reviewing and commenting on it) for > Proposed Standard. >=20 > If needed, we can discuss this in Prague. Thanks for your feedback. >=20 > -- > Wes Eddy > MTI Systems > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Thu Mar 31 11:32:35 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E186E3A6B6A for ; Thu, 31 Mar 2011 11:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.699 X-Spam-Level: X-Spam-Status: No, score=-103.699 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajwsxoKb6BW3 for ; Thu, 31 Mar 2011 11:32:35 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 0662A3A6B31 for ; Thu, 31 Mar 2011 11:32:35 -0700 (PDT) Received: from [130.129.67.235] (dhcp-43eb.meeting.ietf.org [130.129.67.235]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p2VIXUQf005085 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 31 Mar 2011 11:33:46 -0700 (PDT) Message-ID: <4D94C8F8.9070701@isi.edu> Date: Thu, 31 Mar 2011 11:33:28 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "SCHARF, Michael" References: <133D9897FB9C5E4E9DF2779DC91E947C0522F7A6@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C0522F7A6@SLFSNX.rcs.alcatel-research.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p2VIXUQf005085 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Working group consensus concerning TCP-AO NAT draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 18:32:36 -0000 Hi, all, I'm glad to complete this work as an individual submission, but had hoped to include it as a WG item because it extends a WG standard (albeit experimentally), in support of another WG's interest (some members of MPTCP had asked, and it would benefit from cross-area review that would be more difficult to accomplish as an individual. Especially to those who have been silent on this, I would appreciate a note to the list ;-) Glad to do what the WG decides... Thanks, Joe On 3/31/2011 7:57 AM, SCHARF, Michael wrote: > Folks, > > in yesterday's meeting there has been no apparent interest in > draft-touch-tcp-ao-nat-02, and the deadline of the poll has expired. If > there is lack of interest, the document has to move forward as an > independent submission without further feedback from the working group. > > I'd like to verify that this is the consensus of the working group. > Please speak up urgently if you should disagree. > > Michael > > > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Wesley Eddy > Sent: Wednesday, March 16, 2011 5:25 PM > To: tcpm@ietf.org > Subject: [tcpm] poll for adoption of TCP-AO NAT draft > > TCP-AO has been published for some time. NAT support was separated from > AO during development, but Joe has maintained a draft describing how to > support operation through NATs and it has been discussed in the past on > the mailing list and in TCPM meetings. > > This is a relatively short document, and Joe has recently updated it > based on feedback. > > The latest copy of the document is at: > http://tools.ietf.org/html/draft-touch-tcp-ao-nat-02 > > Please let us know in the next 2 weeks (by March 30) if you would > support this as a WG document (via reviewing and commenting on it) for > Proposed Standard. > > If needed, we can discuss this in Prague. Thanks for your feedback. > > -- > Wes Eddy > MTI Systems > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Thu Mar 31 11:34:01 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8FE23A6B31 for ; Thu, 31 Mar 2011 11:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.653 X-Spam-Level: X-Spam-Status: No, score=-103.653 tagged_above=-999 required=5 tests=[AWL=-1.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AboQFmUoNFsd for ; Thu, 31 Mar 2011 11:34:00 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id B3C9C3A6AAB for ; Thu, 31 Mar 2011 11:34:00 -0700 (PDT) Received: from [130.129.67.235] (dhcp-43eb.meeting.ietf.org [130.129.67.235]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p2VIZBuK005271 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 31 Mar 2011 11:35:24 -0700 (PDT) Message-ID: <4D94C95D.7080501@isi.edu> Date: Thu, 31 Mar 2011 11:35:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <133D9897FB9C5E4E9DF2779DC91E947C0522F7A6@SLFSNX.rcs.alcatel-research.de> <0C53DCFB700D144284A584F54711EC580C56CF8A@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580C56CF8A@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: p2VIZBuK005271 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "SCHARF, Michael" Subject: Re: [tcpm] Working group consensus concerning TCP-AO NAT draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 18:34:01 -0000 Hi, Anantha, On 3/31/2011 10:17 AM, Anantha Ramaiah (ananth) wrote: > > I had already already communicated my comments to Joe in private > conversation. I am listing them below. > > - This method won't work when NAT is doing the ALG functionality. > Examples include FTP, SIP, Skinny protocol, etc., Since some part of the > payload (IP addr/port) needs to be adjusted for ALG's. > > Hence this restricts the applicability of this document to some NAT > features. I would urge that this limitation is explicitly noted in the > document irrespective of whichever route it takes. (individual or WG) Yes, we had talked about it, as well as the fact that there are many protocols that don't require ALG support and thus would not be affected, but it's a good point to note, regardless, and I expect to revise the doc shortly (regardless of outcome, as an individual update) on this and another point Dan Wing raised on another list... Joe > > Thanks, > -Anantha > >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf > Of >> SCHARF, Michael >> Sent: Thursday, March 31, 2011 7:57 AM >> To: tcpm@ietf.org >> Subject: [tcpm] Working group consensus concerning TCP-AO NAT draft >> >> Folks, >> >> in yesterday's meeting there has been no apparent interest in >> draft-touch-tcp-ao-nat-02, and the deadline of the poll has expired. > If >> there is lack of interest, the document has to move forward as an >> independent submission without further feedback from the working > group. >> >> I'd like to verify that this is the consensus of the working group. >> Please speak up urgently if you should disagree. >> >> Michael >> >> >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf > Of >> Wesley Eddy >> Sent: Wednesday, March 16, 2011 5:25 PM >> To: tcpm@ietf.org >> Subject: [tcpm] poll for adoption of TCP-AO NAT draft >> >> TCP-AO has been published for some time. NAT support was separated >> from >> AO during development, but Joe has maintained a draft describing how > to >> support operation through NATs and it has been discussed in the past > on >> the mailing list and in TCPM meetings. >> >> This is a relatively short document, and Joe has recently updated it >> based on feedback. >> >> The latest copy of the document is at: >> http://tools.ietf.org/html/draft-touch-tcp-ao-nat-02 >> >> Please let us know in the next 2 weeks (by March 30) if you would >> support this as a WG document (via reviewing and commenting on it) for >> Proposed Standard. >> >> If needed, we can discuss this in Prague. Thanks for your feedback. >> >> -- >> Wes Eddy >> MTI Systems >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From mattmathis@google.com Thu Mar 31 20:04:34 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B58893A6BCC for ; Thu, 31 Mar 2011 20:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQVOXBDtjQwn for ; Thu, 31 Mar 2011 20:04:33 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 17C8F3A6BCA for ; Thu, 31 Mar 2011 20:04:32 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p3136CVF004596 for ; Thu, 31 Mar 2011 20:06:12 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301627172; bh=vxEtc/RrDZYNyrnlxpJnQrQCwAk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=VGbYyL1RRKwCq9mbRLWh7t6AVVB3CUfHIdfMorrD1Aqw+y9tG4crL6uaTGdXZdt3b +0SvcyAgce1IMVeYE9BEw== Received: from eye27 (eye27.prod.google.com [10.208.5.27]) by hpaq2.eem.corp.google.com with ESMTP id p3136AqZ014299 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 31 Mar 2011 20:06:11 -0700 Received: by eye27 with SMTP id 27so1248318eye.34 for ; Thu, 31 Mar 2011 20:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=w5V7PVHDfjxir/ksrupJDYUsU1fLthbnfYaw4bdjAv0=; b=IdyKh5Jylp1T/6wQCOZQFCie9G014ryKd1vj3tjW53eotXyXFoed2B3P3Siek63iwc g5yzU+MhBI7/GDNDQo3A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=w/tyRNqFIN3a9ggVygQb92fVB7MQgpfYXTpynQ5dyuKhIK3CpKTcQpQ1vMPicQpezV uunUl2QBAdqAAvYV5Zyw== MIME-Version: 1.0 Received: by 10.213.17.1 with SMTP id q1mr2133816eba.8.1301627170532; Thu, 31 Mar 2011 20:06:10 -0700 (PDT) Received: by 10.213.104.139 with HTTP; Thu, 31 Mar 2011 20:06:10 -0700 (PDT) In-Reply-To: <5FDC413D5FA246468C200652D63E627A0D9D5908@LDCMVEXC1-PRD.hq.netapp.com> References: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de> <1B22A12A-E5F0-4B15-A311-8CA5ED66FFD7@ifi.uio.no> <5FDC413D5FA246468C200652D63E627A0D9D5908@LDCMVEXC1-PRD.hq.netapp.com> Date: Thu, 31 Mar 2011 23:06:10 -0400 Message-ID: From: Matt Mathis To: "SCHARF, Michael" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm@ietf.org, Michael Welzl Subject: Re: [tcpm] Interest indraft-mathis-tcpm-proportional-rate-reduction-00? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 03:04:34 -0000 When you said "interest", did you actually mean as a WG item? You didn't quite ask the question. We plan to update the document and bring it to the next IETF in any case, and we know of a number of individuals who have expressed interest. My only reservation with making it a WG item is that we expect to broaden the scope somewhat, and the current file and document names may not be appropriate. As long as a future scope changes are not a problem, a WG item would be preferred. Thanks, --MM-- The best way to predict the future is to create it. =A0- Alan Kay On Thu, Mar 31, 2011 at 7:26 AM, Scheffenegger, Richard wro= te: > Nandita, > > > > I would also be interested in learning how the algorithm behaves, when mo= re > then one half of the window is lost (ie, there aren=92t enough ACKs sent = back > to clock out each allowed data segment by it=92s own ACK). Will it clock = out > multiple segments per ACK (and if so, will they be spread over the remain= ing > ACKs, so to limit the maximum number of sent packets per ACK =96 or would > PRR-RB by itself allow a burst of packets being clocked out by a single A= CK? > I think Linux does such a send-rate clamping automatically =96 how is the > interaction with PRR-RB, should that not be part of this draft too)? > > > > > > Richard Scheffenegger > > > > From: Nandita Dukkipati [mailto:nanditad@google.com] > Sent: Donnerstag, 31. M=E4rz 2011 03:30 > To: Michael Welzl > Cc: tcpm@ietf.org; SCHARF, Michael > > Subject: Re: [tcpm] Interest > indraft-mathis-tcpm-proportional-rate-reduction-00? > > > > On Thu, Mar 31, 2011 at 1:43 AM, Michael Welzl wrote= : > > i am in principle interested and have the impression that this is probabl= y a > useful document, but too complicated. maybe an example would help? > > > > That's a great idea - we will post a couple of examples within next few d= ays > on how the algorithm behaves under single and multiple losses. It is > actually surprisingly simple. > > > > > > On Mar 30, 2011, at 11:21 PM, SCHARF, Michael wrote: > > Folks, > > since we ran out of time during the TCPM session, I shifted the > discussion of draft-mathis-tcp-ratehalving-00 to the list. > > In order to trigger this discussion, I'd like to start an informal poll > who would in principle be interested in the topic of that draft. If so, > please reply to this email. Of course, any technical comment would be > excellent. > > Thanks! > > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > From nanditad@google.com Thu Mar 31 21:56:12 2011 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA3F73A6BE9 for ; Thu, 31 Mar 2011 21:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.676 X-Spam-Level: X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUrrwP22PE2f for ; Thu, 31 Mar 2011 21:56:11 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 043BA3A6851 for ; Thu, 31 Mar 2011 21:56:10 -0700 (PDT) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id p314vnuY004289 for ; Thu, 31 Mar 2011 21:57:50 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301633870; bh=aIGIGwrEYWXyte9434q51w+OARU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=djUu88+n88h/KB6yZIjD8W5SMMNClsgIrDvnDjf28b4CQg7EEwhgVPkbpFT5ev51T t9EAV5bZeIgFlSMCyK33w== Received: from vws7 (vws7.prod.google.com [10.241.21.135]) by kpbe13.cbf.corp.google.com with ESMTP id p314umLl001010 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 31 Mar 2011 21:57:48 -0700 Received: by vws7 with SMTP id 7so3803185vws.35 for ; Thu, 31 Mar 2011 21:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JWOjTj1Rg05oOqkwyaC8h3sdkbFTLS0GTw+sOTq5RHo=; b=vsZ0EXGe5P0XdK81zMpxGoX3xmJgLNcaczuoLFTR0/vfsohA9hPDs7kY12j+Dpb0CV 71kRnwXfXmDMdk4da1rA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TfNFJv7NC9JSRgTv6XBA9GTcr1cyHY/vRi3A2E8kwNbKq1HdPEt75yN+2OR7qbJOUE bxCHJDHS3MSsHmRdaiLA== MIME-Version: 1.0 Received: by 10.220.6.4 with SMTP id 4mr894051vcx.160.1301633868219; Thu, 31 Mar 2011 21:57:48 -0700 (PDT) Received: by 10.220.52.136 with HTTP; Thu, 31 Mar 2011 21:57:48 -0700 (PDT) In-Reply-To: <5FDC413D5FA246468C200652D63E627A0D9D5908@LDCMVEXC1-PRD.hq.netapp.com> References: <133D9897FB9C5E4E9DF2779DC91E947C0522F740@SLFSNX.rcs.alcatel-research.de> <1B22A12A-E5F0-4B15-A311-8CA5ED66FFD7@ifi.uio.no> <5FDC413D5FA246468C200652D63E627A0D9D5908@LDCMVEXC1-PRD.hq.netapp.com> Date: Fri, 1 Apr 2011 06:57:48 +0200 Message-ID: From: Nandita Dukkipati To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=000325573b2657c54e049fd440a5 X-System-Of-Record: true Cc: tcpm@ietf.org, "SCHARF, Michael" , Michael Welzl Subject: Re: [tcpm] Interest indraft-mathis-tcpm-proportional-rate-reduction-00? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 04:56:12 -0000 --000325573b2657c54e049fd440a5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > > I would also be interested in learning how the algorithm behaves, when mo= re > then one half of the window is lost (ie, there aren=92t enough ACKs sent = back > to clock out each allowed data segment by it=92s own ACK). Will it clock = out > multiple segments per ACK (and if so, will they be spread over the remain= ing > ACKs, so to limit the maximum number of sent packets per ACK =96 or would > PRR-RB by itself allow a burst of packets being clocked out by a single A= CK? > > PRR-RB can clock out multiple segments per ACK but has a bound - on every ACK the cumulative amount of data sent in recovery is bound by the amount o= f data delivered to the receiver during recovery. This is unlike in rfc3517, where larger the losses are, the bigger the burst can be (upto [ssthresh - pipe]). Will send out an example with this scenario after I get back to Cal= . I think Linux does such a send-rate clamping automatically =96 how is the > interaction with PRR-RB, should that not be part of this draft too)? > Linux does the clamping by reducing cwnd to min(ssthresh, pipe + 1) on each ACK in recovery. This has the unfortunate behavior in that: 1) it is limite= d to clocking out at most 1 packet/ACK, and 2) for short Web traffic or when the application is temporarily running out of new data to send, pipe reduce= s to 0, so cwnd =3D=3D 1 at the end of recovery. PRR-RB will replace the abov= e and so no question of interaction. > > *From:* Nandita Dukkipati [mailto:nanditad@google.com] > *Sent:* Donnerstag, 31. M=E4rz 2011 03:30 > *To:* Michael Welzl > *Cc:* tcpm@ietf.org; SCHARF, Michael > *Subject:* Re: [tcpm] Interest > indraft-mathis-tcpm-proportional-rate-reduction-00? > > > > On Thu, Mar 31, 2011 at 1:43 AM, Michael Welzl wrote= : > > i am in principle interested and have the impression that this is probabl= y > a useful document, but too complicated. maybe an example would help? > > > > That's a great idea - we will post a couple of examples within next few > days on how the algorithm behaves under single and multiple losses. It is > actually surprisingly simple. > > > > > > On Mar 30, 2011, at 11:21 PM, SCHARF, Michael wrote: > > Folks, > > since we ran out of time during the TCPM session, I shifted the > discussion of draft-mathis-tcp-ratehalving-00 to the list. > > In order to trigger this discussion, I'd like to start an informal poll > who would in principle be interested in the topic of that draft. If so, > please reply to this email. Of course, any technical comment would be > excellent. > > Thanks! > > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > --000325573b2657c54e049fd440a5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

= I would also be interested in learning how the algorithm behaves, when more= then one half of the window is lost (ie, there aren=92t enough ACKs sent b= ack to clock out each allowed data segment by it=92s own ACK). Will it cloc= k out multiple segments per ACK (and if so, will they be spread over the re= maining ACKs, so to limit the maximum number of sent packets per ACK =96 or= would PRR-RB by itself allow a burst of packets being clocked out by a sin= gle ACK?


PRR-RB can clock out multiple = segments per ACK but has a bound - on every ACK the cumulative amount of da= ta sent in recovery is bound by the amount of data delivered to the receive= r during recovery. This is unlike in rfc3517, where larger the losses are, = the bigger the burst can be (upto [ssthresh - pipe]).=A0Will send out an ex= ample with this scenario after I get back to Cal.

I think Linux= does such a send-rate clamping automatically =96 how is the interaction wi= th PRR-RB, should that not be part of this draft too)?


Linux does the clamping by red= ucing cwnd to min(ssthresh, pipe + 1) on each ACK in recovery. This has the= unfortunate behavior in that: 1) it is limited to clocking out at most 1 p= acket/ACK, and 2) for short Web traffic or when the application is temporar= ily running out of new data to send, pipe reduces to 0, so cwnd =3D=3D 1 at= the end of recovery. PRR-RB will replace the above and so no question of i= nteraction.=A0

=A0

From: Nandita Dukkipati [mailto:nanditad@google.com]
Sent: Donnerstag, 31. M=E4rz 2011 03:30
To: Michael Welzl<= br>Cc: tcpm@ietf.= org; SCHARF, Michael
Subject: Re: [tcpm] Interest indraft-mat= his-tcpm-proportional-rate-reduction-00?

=A0

On Thu, Mar 31, 2011 at 1:43 AM, Michael Welzl= <michawe@ifi.ui= o.no> wrote:

i am in principle interested and have the impression= that this is probably a useful document, but too complicated. maybe an exa= mple would help?

=A0

That's a great idea - we will post a couple of examples within next few= days on how the algorithm behaves under single and multiple losses. It is = actually surprisingly simple.

=A0

<= /div>

=A0

On Mar 30, 2011, at 11:21 PM, SCHARF, Michael wrote:

Folks,

since we ran out of time during the TCPM session, I shift= ed the
discussion of draft-mathis-tcp-ratehalving-00 to the list.
In order to trigger this discussion, I'd like to start an informal poll=
who would in principle be interested in the topic of that draft. If so,=
please reply to this email. Of course, any technical comment would be excellent.

Thanks!

Michael
_______________________________= ________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/t= cpm


_______________________________________________<= br>tcpm mailing list
= tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

=A0


--000325573b2657c54e049fd440a5--