From Alexander.Zimmermann@nets.rwth-aachen.de Thu Apr 1 01:35:37 2010 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 CB4293A6926 for ; Thu, 1 Apr 2010 01:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_61=0.6, 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 L-XJnnUMsjGq for ; Thu, 1 Apr 2010 01:35:36 -0700 (PDT) Received: from mail-i4.informatik.rwth-aachen.de (mail-i4.informatik.RWTH-Aachen.DE [137.226.12.21]) by core3.amsl.com (Postfix) with ESMTP id 4F8BC3A67FA for ; Thu, 1 Apr 2010 01:35:35 -0700 (PDT) Received: from messenger.nets.rwth-aachen.de (messenger.nets.rwth-aachen.de [137.226.13.40]) by mail-i4.informatik.rwth-aachen.de (Postfix) with ESMTP id D1BB7578E9; Thu, 1 Apr 2010 10:36:06 +0200 (CEST) Received: from MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28]) by MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28%14]) with mapi; Thu, 1 Apr 2010 10:35:49 +0200 From: Alexander Zimmermann To: Lars Eggert Thread-Topic: [tcpm] IANA TCP options registry ... Thread-Index: Acq+TSNHzzS93gfiTSSoDXpuonjTlQTAN3aAAAFduwAABIkZAA== Date: Thu, 1 Apr 2010 08:36:08 +0000 Message-ID: <264D66A5-73F5-4921-8696-032692E29269@nets.rwth-aachen.de> References: <201003072316.AAA29042@TR-Sys.de> <5FDC413D5FA246468C200652D63E627A08144911@LDCMVEXC1-PRD.hq.netapp.com> <74EC24B3-8ACF-4C62-9D0C-163CBF911B1B@nokia.com> In-Reply-To: <74EC24B3-8ACF-4C62-9D0C-163CBF911B1B@nokia.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3d76db41-cf95-421a-aced-8407e85312c9> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: =?iso-8859-1?Q?Alfred_H=CEnes?= , "tcpm@ietf.org" Subject: Re: [tcpm] IANA TCP options registry ... 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, 01 Apr 2010 08:35:37 -0000 Hi Lars, Am 01.04.2010 um 08:26 schrieb Lars Eggert: > Hi, >=20 > On 2010-4-1, at 8:47, Scheffenegger, Richard wrote: >> Out of curiousity, does anyone know about the to-be assigned option numb= er(s ?) for RFC 5690 (AckCChttp://tools.ietf.org/html/rfc5690). >>=20 >> Are there two option numbers proposed for that RFC, or will a single opt= ion (with the length field being the necessary denominator between AckCC co= ntrol permitted and AckCC Ratio) suffice? >=20 > Section 10 is pretty clear, in that RFC5690 is for limited experimentatio= n only at this time and hence no separate option numbers will be assigned. = Experimenters are supposed to use the normal TCP option numbers set aside f= or general experimentation (253/254) when playing with this proposal: this could be funny in Linux. You request ACKcc as TCP sender (option 253) and get Mr. Simpson's TCP Cookie Transactions back ;-) >=20 > No IANA action is needed at this time. If this document was advanced > as Experimental or Proposed Standard, then IANA would allocate the > option numbers for the two TCP options, the ACK Congestion Control > Permitted option, and the ACK Ratio option. In such a case, the > following two lines would be added to the TCP Option Numbers registry > (maintained by IANA -- http://www.iana.org): >=20 > Kind Length Meaning Reference > ---- ------ --------------------------------- ----------- > TBD1 2 ACK Congestion Control Permitted [RFCXXXX] > TBD2 3 ACK Ratio [RFCXXXX] >=20 > In the absence of TCP option numbers allocated by IANA, experimenters > may use the TCP Option Numbers set aside for Experimentation in RFC > 4727 [RFC4727]. As stressed in Section 1 of RFC 3692 [RFC3692], the > TCP Option Numbers in the experimental range are intended for > experimentation and testing and not for wide or general deployments; > these option numbers could be in use by other experimentors for other > purposes. >=20 > Lars_______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From A.Hoenes@TR-Sys.de Thu Apr 1 05:19:18 2010 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 5099C3A700F for ; Thu, 1 Apr 2010 05:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.93 X-Spam-Level: X-Spam-Status: No, score=-93.93 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, J_CHICKENPOX_61=0.6, MIME_8BIT_HEADER=0.3, 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 LHIs8FDb3ORM for ; Thu, 1 Apr 2010 05:19:17 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id D19F83A7C01 for ; Thu, 1 Apr 2010 05:07:52 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA104413674; Thu, 1 Apr 2010 14:07:54 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id OAA28159; Thu, 1 Apr 2010 14:07:49 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201004011207.OAA28159@TR-Sys.de> To: rs@netapp.com Date: Thu, 1 Apr 2010 14:07:48 +0200 (MESZ) In-Reply-To: <5FDC413D5FA246468C200652D63E627A08144911@LDCMVEXC1-PRD.hq.netapp.com> from "Scheffenegger, Richard" at Apr "1, " 2010 "06:47:09" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] IANA TCP options registry ... policy amendments? 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, 01 Apr 2010 12:19:18 -0000 > Hi Alfred et al, > > Out of curiousity, does anyone know about the to-be assigned option > number(s ?) for RFC 5690 (AckCC http://tools.ietf.org/html/rfc5690). > > Are there two option numbers proposed for that RFC, or will a single > option (with the length field being the necessary denominator between > AckCC control permitted and AckCC Ratio) suffice? > > Best regards, > > > Richard Scheffenegger > Field Escalation Engineer > NetApp Global Support > ... Lars already has pointed to the very clear words in RFC 5690. I understand that this is ugly for the actual participants in experiments, but this all is based on Section 9.3 of BCP 37, RFC 2780, published 10 years ago. With that RFC, the previous liberal assignment policy for TCP Option Kind values has been changed radically to require Standards Action or IESG Approval. I do not want to argue in favor or against that decision, but I really want to emphasize that this decision has been half-hearted, leaving the traces of previous, mostly undocumented experiments in the registry forever with fixed code points. Given the current interest in new TCP options, TCPM should reconsider the above decisions. Leaving old experiments in the registry and only admitting two code points for experiments looks discriminating for new experiments. Given the really scarce space in the TCP header for options, subtyping seems to be a poor tradeoff. As you know, I'm already engaged in transforming my previous results of collecting more facts and evidence about TCP options into an I-D that will aim at amending the IANA registry. Thus the following questions arise: (1) Should we take this opportunity to add more experimental code points for TCP Option Kinds ? (2) Should we allow time-limited code point assignments for experiments that only make sense if conducted with many participants? (IANA has reported that they are ready to support such timed transitions in registries.) (3) Combined idea: reserve an additional range of, say, 16 code points for use in IESG-approved experiments (thus no change to RFC 2780!) with a 2-year timeout that can be increased once by the same amount of time *iff* the experiment has lead to follow-up work in an IETF working group targetting Standards Track. These code points would be recycled in a circular manner. Thoughts? Opinions? Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From william.allen.simpson@gmail.com Thu Apr 1 05:27:06 2010 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 60DD43A77E6 for ; Thu, 1 Apr 2010 05:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.004 X-Spam-Level: X-Spam-Status: No, score=-1.004 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 JlqhDtu+lBUN for ; Thu, 1 Apr 2010 05:27:05 -0700 (PDT) Received: from mail-qy0-f195.google.com (mail-qy0-f195.google.com [209.85.221.195]) by core3.amsl.com (Postfix) with ESMTP id A50C63A6CC7 for ; Thu, 1 Apr 2010 05:15:06 -0700 (PDT) Received: by qyk33 with SMTP id 33so1060189qyk.28 for ; Thu, 01 Apr 2010 05:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=t+3FrA2Xq0uEBsUkQpTkOboMLnwY2aRqYUvq2rNvnTY=; b=KCHX+jWN+nLc7uIe/u4ipKAFbv2QSiEyP+PSJqs/kVR/js2lJYDymBAZSmFb8b1dum 7HGv5mjBbTDEuaxhTmuPIjjq01wlzD9pWc13hzbeSEQpYO05/Y/oj2EeB/f/+spn44xI sPPDyZE8aHFwzFJXtGgvs1k5PAbyf1WGf9SzE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=QHFyouezy+MRbfqK5L793gz5YO6MmkoENHEgxEJ8YAt+HIlm45PDJTe24HgDxVsRhb Xbm49L42E+c/0sxA/SyHxDZn3wY/mmdySBlurL7l6jNTq5tv4+qOkbTdLjCsfAqkvLjh NUxh06TWO6mCX6XGabFgIP7vgV2Kmp/FLoY3Y= Received: by 10.229.81.81 with SMTP id w17mr1287641qck.4.1270124134406; Thu, 01 Apr 2010 05:15:34 -0700 (PDT) Received: from Wastrel.local (c-68-40-195-221.hsd1.mi.comcast.net [68.40.195.221]) by mx.google.com with ESMTPS id 23sm7106395iwn.6.2010.04.01.05.15.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 05:15:33 -0700 (PDT) Message-ID: <4BB48E63.10309@gmail.com> Date: Thu, 01 Apr 2010 08:15:31 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Alexander Zimmermann References: <201003072316.AAA29042@TR-Sys.de> <5FDC413D5FA246468C200652D63E627A08144911@LDCMVEXC1-PRD.hq.netapp.com> <74EC24B3-8ACF-4C62-9D0C-163CBF911B1B@nokia.com> <264D66A5-73F5-4921-8696-032692E29269@nets.rwth-aachen.de> In-Reply-To: <264D66A5-73F5-4921-8696-032692E29269@nets.rwth-aachen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: =?UTF-8?B?QWxmcmVkIEjDjm5lcw==?= , "tcpm@ietf.org" Subject: Re: [tcpm] IANA TCP options registry ... 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, 01 Apr 2010 12:27:06 -0000 On 4/1/10 4:36 AM, Alexander Zimmermann wrote: >> Section 10 is pretty clear, in that RFC5690 is for limited experimentation only at this time and hence no separate option numbers will be assigned. Experimenters are supposed to use the normal TCP option numbers set aside for general experimentation (253/254) when playing with this proposal: > > this could be funny in Linux. You request ACKcc as TCP sender (option 253) > and get Mr. Simpson's TCP Cookie Transactions back ;-) > Haven't seen that (RFC5690) so far, but there's somebody else using 253 and another somebody using 254 in deployed code! There are earlier messages on this list about the culprits. Last year's Linux code used the experimental numbers and followed the usual procedures (you have to explicitly turn it on with a sysctl or sockopt), but the conflicts were quickly obvious. Don't turn it on outside your lab. The only reason that I've bothered putting up the internet-draft is to get official IANA assignments. I'd sent in the reservation back in November, but IANA refused to send it to IESG for approval without an internet-draft. Unfortunately, IESG has been *terribly* slow to act. Unlike certain commercial interests, I'm trying to avoid conflicts. But next time, I'll not bother. IETF officialdom has become too ossified. From rs@netapp.com Thu Apr 1 05:53:41 2010 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 9B9B73A6D36 for ; Thu, 1 Apr 2010 05:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_61=0.6, 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 CfDHxFTaWfFz for ; Thu, 1 Apr 2010 05:53:40 -0700 (PDT) Received: from mx4.netapp.com (mx4.netapp.com [217.70.210.8]) by core3.amsl.com (Postfix) with ESMTP id EA46E3A6CC0 for ; Thu, 1 Apr 2010 05:41:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,348,1267430400"; d="scan'208";a="148419845" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx4-out.netapp.com with ESMTP; 01 Apr 2010 05:42:07 -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 o31Cg7SL010846; Thu, 1 Apr 2010 05:42:07 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 13:42:07 +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, 1 Apr 2010 13:42:05 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A04B7C14A@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <201004011207.OAA28159@TR-Sys.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] IANA TCP options registry ... policy amendments? Thread-Index: AcrRlBCERjtZXwXAS9KGxj1IaQNHkgAA9XQg From: "Scheffenegger, Richard" To: =?iso-8859-1?Q?Alfred_H=CEnes?= X-OriginalArrivalTime: 01 Apr 2010 12:42:07.0531 (UTC) FILETIME=[BD56FFB0:01CAD198] Cc: tcpm@ietf.org Subject: Re: [tcpm] IANA TCP options registry ... policy amendments? 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, 01 Apr 2010 12:53:41 -0000 I'd opt for option #3 - having time-limited experiment range, and = clearly stating these opting in I-D or Informational RFCs would help = getting interoperability tests deployed... Cleaning up the IANA registry every 2 years shouldn't be too much of a = burden (actually, if within those 2 years no other options were = requested for experiments, keep them active until recycled / = standards-track RFC emerges... Or, if a useful addition surfaces, promote the "expirimental" Option to = fixed, and put a previously unallocated one to the expirimental code = point pool. Pulling once-implemented codepoints out of commercial stacks = is also a pain... AckCC and DCTCP seem to have some merit together, to get them both a = properly defined code point each. Thanks Alfred!=20 Richard Scheffenegger -----Original Message----- From: Alfred H=CEnes [mailto:ah@TR-Sys.de]=20 Sent: Donnerstag, 01. April 2010 14:08 To: Scheffenegger, Richard Cc: tcpm@ietf.org Subject: Re: [tcpm] IANA TCP options registry ... policy amendments? > Hi Alfred et al, > > Out of curiousity, does anyone know about the to-be assigned option=20 > number(s ?) for RFC 5690 (AckCC http://tools.ietf.org/html/rfc5690). > > Are there two option numbers proposed for that RFC, or will a single=20 > option (with the length field being the necessary denominator between=20 > AckCC control permitted and AckCC Ratio) suffice? > > Best regards, > > > Richard Scheffenegger > Field Escalation Engineer > NetApp Global Support > ... Lars already has pointed to the very clear words in RFC 5690. I understand that this is ugly for the actual participants in = experiments, but this all is based on Section 9.3 of BCP 37, RFC 2780, = published 10 years ago. With that RFC, the previous liberal assignment = policy for TCP Option Kind values has been changed radically to require = Standards Action or IESG Approval. I do not want to argue in favor or against that decision, but I really = want to emphasize that this decision has been half-hearted, leaving the = traces of previous, mostly undocumented experiments in the registry = forever with fixed code points. Given the current interest in new TCP options, TCPM should reconsider = the above decisions. Leaving old experiments in the registry and only = admitting two code points for experiments looks discriminating for new = experiments. Given the really scarce space in the TCP header for = options, subtyping seems to be a poor tradeoff. As you know, I'm already engaged in transforming my previous results of = collecting more facts and evidence about TCP options into an I-D that = will aim at amending the IANA registry. Thus the following questions arise: (1) Should we take this opportunity to add more experimental code points for TCP Option Kinds ? (2) Should we allow time-limited code point assignments for experiments that only make sense if conducted with many participants? (IANA has reported that they are ready to support such timed transitions in registries.) (3) Combined idea: reserve an additional range of, say, 16 code points for use in IESG-approved experiments (thus no change to RFC 2780!) with a 2-year timeout that can be increased once by the same amount of time *iff* the experiment has lead to follow-up work in an IETF working group targetting Standards Track. These code points would be recycled in a circular manner. Thoughts? Opinions? Kind regards, Alfred. --=20 +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From L.Wood@surrey.ac.uk Thu Apr 1 06:11:19 2010 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 E5A3B3A69E2 for ; Thu, 1 Apr 2010 06:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.044 X-Spam-Level: X-Spam-Status: No, score=-5.044 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 zQqtdvapvWQQ for ; Thu, 1 Apr 2010 06:11:15 -0700 (PDT) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id 7B7FE3A689B for ; Thu, 1 Apr 2010 06:11:14 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-12.tower-82.messagelabs.com!1270127504!3994232!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.43] Received: (qmail 11346 invoked from network); 1 Apr 2010 13:11:45 -0000 Received: from unknown (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-12.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 1 Apr 2010 13:11:45 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.49]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Thu, 1 Apr 2010 14:11:44 +0100 From: To: , Date: Thu, 1 Apr 2010 14:10:39 +0100 Thread-Topic: [tcpm] IANA TCP options registry ... policy amendments? Thread-Index: AcrRleFzWXmD9VKPQaGnYbN6H94aPwABthAK Message-ID: References: <5FDC413D5FA246468C200652D63E627A08144911@LDCMVEXC1-PRD.hq.netapp.com> from "Scheffenegger, Richard" at Apr "1, " 2010 "06:47:09" am,<201004011207.OAA28159@TR-Sys.de> In-Reply-To: <201004011207.OAA28159@TR-Sys.de> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcpm@ietf.org Subject: Re: [tcpm] IANA TCP options registry ... policy amendments? 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, 01 Apr 2010 13:11:20 -0000 > Given the really scarce space in the TCP header > for options, subtyping seems to be a poor tradeoff. Revive http://tools.ietf.org/html/draft-eddy-tcp-loo SACK will perform far better with a larger options space. L. http://sat-net.com/L.Wood= From lars.eggert@nokia.com Thu Apr 1 06:35:28 2010 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 B6FC83A67FA for ; Thu, 1 Apr 2010 06:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.264 X-Spam-Level: X-Spam-Status: No, score=-5.264 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 v+vutbzYLa+P for ; Thu, 1 Apr 2010 06:35:28 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 8BCA53A67DF for ; Thu, 1 Apr 2010 06:35:27 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o31DZND8026099; Thu, 1 Apr 2010 16:35:53 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 16:35:41 +0300 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 16:35:41 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o31DZdFM030551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Apr 2010 16:35:39 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/signed; boundary=Apple-Mail-87--236047847; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <264D66A5-73F5-4921-8696-032692E29269@nets.rwth-aachen.de> Date: Thu, 1 Apr 2010 16:35:28 +0300 Message-Id: <1BD11178-9664-4BBA-A68D-C2F861346744@nokia.com> References: <201003072316.AAA29042@TR-Sys.de> <5FDC413D5FA246468C200652D63E627A08144911@LDCMVEXC1-PRD.hq.netapp.com> <74EC24B3-8ACF-4C62-9D0C-163CBF911B1B@nokia.com> <264D66A5-73F5-4921-8696-032692E29269@nets.rwth-aachen.de> To: Alexander Zimmermann X-Mailer: Apple Mail (2.1078) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Thu, 01 Apr 2010 16:35:28 +0300 (EEST) X-OriginalArrivalTime: 01 Apr 2010 13:35:41.0361 (UTC) FILETIME=[38EE8A10:01CAD1A0] X-Nokia-AV: Clean Cc: =?iso-8859-1?Q?Alfred_H=CEnes?= , "tcpm@ietf.org" Subject: Re: [tcpm] IANA TCP options registry ... 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, 01 Apr 2010 13:35:28 -0000 --Apple-Mail-87--236047847 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2010-4-1, at 11:36, Alexander Zimmermann wrote: > this could be funny in Linux. You request ACKcc as TCP sender (option = 253) > and get Mr. Simpson's TCP Cookie Transactions back ;-) Then Linux needs some #ifdefs for people to decide which experiment they = want to participate in. Or just maybe Linux should stop including experimental option code in = shipping releases, as stated by RFC3692, which is pointed to by RFC4727, = which assigned the experimental options... Kars= --Apple-Mail-87--236047847 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDQwMTEzMzUyOFowIwYJKoZIhvcNAQkEMRYEFOTpzU1FyQ9yI+ZeysjszwHmyEBxMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCm0P0GijiEqHMTe6N4EUDfOSjrvnynICSGBWP3zVPy0QD61eAIlet4GsVCEwy3Wj+c1Ueu xFvThsPxVMd95vrCXg0Gu+DLquI8P/DWx+Ly7lKclFS5/v5ziKaBCX3HbJWzmsiSJZ1HEO3uydHh gS4ZMO9wPdIBKX8x9XoONm/jDVUiXJs2ljxSyYogfO4BecW7LzVgJ3rxh0e8f27hGCnLs/Wy5jzK 8Hk1xi+mBp1EPussba9bkE8wsfXKepQ9clLLRZ1rc50QEqF9mD9zrTsotk5Z0Ccn7mt5qKFjt7EM isWXU7qw9Dx5chVHTfAFQqjZxBg21eU86Vtb+1xpLRa8AAAAAAAA --Apple-Mail-87--236047847-- From lars.eggert@nokia.com Thu Apr 1 06:43:54 2010 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 C9E803A6929; Thu, 1 Apr 2010 06:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.271 X-Spam-Level: X-Spam-Status: No, score=-5.271 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 En11TGslf6Pu; Thu, 1 Apr 2010 06:43:54 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id E8F7B3A6912; Thu, 1 Apr 2010 06:43:53 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o31DiKTP027577; Thu, 1 Apr 2010 08:44:24 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 16:44:18 +0300 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 16:44:17 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o31DiGfd017905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Apr 2010 16:44:16 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/signed; boundary=Apple-Mail-88--235527235; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4BB48E63.10309@gmail.com> Date: Thu, 1 Apr 2010 16:44:08 +0300 Message-Id: <8F7AE256-9954-48B5-8B26-08D4CF8E0DDC@nokia.com> References: <201003072316.AAA29042@TR-Sys.de> <5FDC413D5FA246468C200652D63E627A08144911@LDCMVEXC1-PRD.hq.netapp.com> <74EC24B3-8ACF-4C62-9D0C-163CBF911B1B@nokia.com> <264D66A5-73F5-4921-8696-032692E29269@nets.rwth-aachen.de> <4BB48E63.10309@gmail.com> To: William Allen Simpson X-Mailer: Apple Mail (2.1078) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Thu, 01 Apr 2010 16:44:09 +0300 (EEST) X-OriginalArrivalTime: 01 Apr 2010 13:44:17.0535 (UTC) FILETIME=[6C9870F0:01CAD1A1] X-Nokia-AV: Clean Cc: "tcpm@ietf.org Extensions" , =?iso-8859-1?Q?Alfred_H=CEnes?= , Alexander Zimmermann , IESG IESG Subject: Re: [tcpm] IANA TCP options registry ... 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, 01 Apr 2010 13:43:54 -0000 --Apple-Mail-88--235527235 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-4-1, at 15:15, William Allen Simpson wrote: > The only reason that I've bothered putting up the internet-draft is to = get > official IANA assignments. I'd sent in the reservation back in = November, > but IANA refused to send it to IESG for approval without an = internet-draft. > Unfortunately, IESG has been *terribly* slow to act. your request with IANA for the option allocation has been open for a = while, agreed. The ID that IANA asked for before forwarding the request to the IESG was = posted by you on March 1. See = http://datatracker.ietf.org/doc/draft-simpson-tcpct/#history The Independent Stream Editor has sent it to the IESG for the RFC5742 = Section 3 review on March 26, i.e., during the IETF meeting in Anaheim. Today is April 1. The ID is slated for discussion on the very next IESG telechat on April = 8. I fail to see how we're slow. In fact, this is the most aggressive = possible schedule. Lars= --Apple-Mail-88--235527235 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDQwMTEzNDQwOVowIwYJKoZIhvcNAQkEMRYEFNgKErERbXGiBpla1s2r9ylTGVcJMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQC3x1uebDgtpopMfOYdwpiJCGkAhjO8ch9tw8Tl2xsqnaObIbbteqo6UoD6uUjbz2DFfZ+3 g/GMW7hSoOz/sgBCvep8MOr6vmNwbbR+sAermNgXl9CT5ShjwmefI0rAsiWogyehJd6BILwbSiX/ MxGf9y3WBMKsTm5uomixC5sG+ME9CE66lDJmo5QeyDQDr8EeLL9BvITAlYaYB5AeVH3FJwBwrifM FH8IZKCYDHWRQO4yOXhLj+IpXA/YfQAT18IIB2isUNSWRdBepDGQPhJSBlxBYcNzThVJ/ejokGLJ LmoQTeQM7ik0goaUNAJ7oMGCQuBvpWnVzkx7QZHodJuCAAAAAAAA --Apple-Mail-88--235527235-- From lars.eggert@nokia.com Thu Apr 1 06:49:29 2010 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 0028D3A6808 for ; Thu, 1 Apr 2010 06:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.277 X-Spam-Level: X-Spam-Status: No, score=-5.277 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 t3BROyuz49+J for ; Thu, 1 Apr 2010 06:49:28 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 9C6D33A6912 for ; Thu, 1 Apr 2010 06:49:19 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o31Dn1uZ031811; Thu, 1 Apr 2010 08:49:51 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 16:49:39 +0300 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 16:49:38 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o31Dnb71017907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Apr 2010 16:49:37 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/signed; boundary=Apple-Mail-89--235210553; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <201004011207.OAA28159@TR-Sys.de> Date: Thu, 1 Apr 2010 16:49:25 +0300 Message-Id: <21169863-7EB5-4A36-AEAD-59A8AA543BAF@nokia.com> References: <201004011207.OAA28159@TR-Sys.de> To: ah@tr-sys.de X-Mailer: Apple Mail (2.1078) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Thu, 01 Apr 2010 16:49:26 +0300 (EEST) X-OriginalArrivalTime: 01 Apr 2010 13:49:38.0820 (UTC) FILETIME=[2C18A440:01CAD1A2] X-Nokia-AV: Clean Cc: "tcpm@ietf.org" Subject: Re: [tcpm] IANA TCP options registry ... policy amendments? 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, 01 Apr 2010 13:49:29 -0000 --Apple-Mail-89--235210553 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-4-1, at 15:07, ah@tr-sys.de wrote: > Thus the following questions arise: >=20 > (1) Should we take this opportunity to add more experimental > code points for TCP Option Kinds ? no. If we allocate them for shared use, people will just use them and = ship code using them, like they did in the past. Nothing is gained. > (2) Should we allow time-limited code point assignments for > experiments that only make sense if conducted with many > participants? > (IANA has reported that they are ready to support such > timed transitions in registries.) Whether the registry contents time out or not is irrelevant. What would = need to happen is that people need to stop running the code that uses = the allocation when the experiment terminates, which is impossible to = guarantee in practice, and so collisions aren't prevented by this. It = just creates more IANA overhead. > (3) Combined idea: reserve an additional range of, say, 16 code = points > for use in IESG-approved experiments (thus no change to RFC 2780!) We don't need to assign a range for this - the IESG can *already* assign = TCP option numbers for Experimental uses. The tcpct draft was written = exactly to ask for such an assignment. > with a 2-year timeout that can be increased once by the same = amount > of time *iff* the experiment has lead to follow-up work in an IETF > working group targetting Standards Track. These code points would > be recycled in a circular manner. See above for why the timeout doesn't work. Lars= --Apple-Mail-89--235210553 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDQwMTEzNDkyNVowIwYJKoZIhvcNAQkEMRYEFCS5F095tqLUo2OSDnN8a6oYDpd5MIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQC/l0IIX6ji5mAkFuJ7S7FrQlCxvIU23KecZYdltPwam5/SxZRVFYGVitvtnzq6fVBEdpHP IYvEfio4bltODnGV6Rc7qYWWHpMBmrKNAl6KbKG4kTUHY5wpnL+KNZBh+nlGaOrM9ODlu7jHpb9D lDwR7AuX/iia3R2eyrlMnO064I7nAai8THXGTuYzVaxl4K9IJUTD89DiH87OO36CkJpWepdixJpd vqRhROzIJgsWMQ1o0rwXtGwQA7dyRseC9F07nSr2AqUPuTv2idyNw6f+YZ8QvdRVunfZSwqe7Ic+ b/ZW+USLp4H/akuNv42tnZJQt8Z4V2p/1MDhtcfCHoXeAAAAAAAA --Apple-Mail-89--235210553-- From A.Hoenes@TR-Sys.de Thu Apr 1 07:02:02 2010 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 7E0573A686E for ; Thu, 1 Apr 2010 07:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.358 X-Spam-Level: X-Spam-Status: No, score=-94.358 tagged_above=-999 required=5 tests=[AWL=0.847, BAYES_40=-0.185, CHARSET_FARAWAY_HEADER=3.2, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 onrEzj1zNhpx for ; Thu, 1 Apr 2010 07:01:56 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id B77293A6868 for ; Thu, 1 Apr 2010 07:01:53 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA105320515; Thu, 1 Apr 2010 16:01:55 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA28384; Thu, 1 Apr 2010 16:01:54 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201004011401.QAA28384@TR-Sys.de> To: william.allen.simpson@gmail.com Date: Thu, 1 Apr 2010 16:01:53 +0200 (MESZ) In-Reply-To: <4BB48E63.10309@gmail.com> from William Allen Simpson at Apr "1, " 2010 "08:15:31" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] IANA TCP options registry ... 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, 01 Apr 2010 14:02:02 -0000 William Allen Simpson wrote: > On 4/1/10 4:36 AM, Alexander Zimmermann wrote: >>> Section 10 is pretty clear, in that RFC5690 is for limited >>> experimentation only at this time and hence no separate option >>> numbers will be assigned. Experimenters are supposed to use the >> normal TCP option numbers set aside for general experimentation >>> (253/254) when playing with this proposal: >> >> this could be funny in Linux. You request ACKcc as TCP sender (option 253) >> and get Mr. Simpson's TCP Cookie Transactions back ;-) >> > Haven't seen that (RFC5690) so far, but there's somebody else using 253 and > another somebody using 254 in deployed code! There are earlier messages on > this list about the culprits. > > Last year's Linux code used the experimental numbers and followed the usual > procedures (you have to explicitly turn it on with a sysctl or sockopt), > but the conflicts were quickly obvious. Don't turn it on outside your lab. That's it. The rules about these 'experimental' code points have been set out very clearly in RFC 4727, and "deployed code" or even "commercial" implementations are not compatible with these. > The only reason that I've bothered putting up the internet-draft is to get > official IANA assignments. I'd sent in the reservation back in November, > but IANA refused to send it to IESG for approval without an internet-draft. > Unfortunately, IESG has been *terribly* slow to act. Well, I fear in *this* case neither IANA nor the IESG should be blamed: The IANA registry at clearly points out: | Registry Name: TCP Option Kind Numbers | Reference: [RFC2780] | Registration Procedures: IESG Approval or Standards Action RFC 5226 (lower half of page 11) explains the "IESG Approval" policy as exceptional and gives two indications for when it should be applied: - urgency (used recently to get early code point assignments for TLS after a new class of MitM attacks had been discovered and work to counter these had started), and - strong WG consensus (for a non- Standards Track proposal). RFC 5226 also states there: "IESG Approval is not intended to circumvent the public review processes implied by other policies that could have been employed for a particular assignment." In this case, RFC 2780 has established approval of an I-D as a Standards Track RFC as the "normal" requirement ("Standards Action"). Obviously both exceptions quoted above are not proper matches for your case, and so I still do not see the procedural rule on which you have based your expectation of exceptional treatment. Or did I miss something? Sorry: In this case, avoidance of IETF WGs strikes back. > Unlike certain commercial interests, I'm trying to avoid conflicts. > But next time, I'll not bother. IETF officialdom has become too > ossified. I do not want to argue on the final point here, but it looks like in this case the IETF (an the IESG) is simply eating their own doggy-food, and as shown above, this has nothing to do with ossification of the institutions tasked with the execution of the procedures set by the IETF. If the taste of the doggy-food is perceived as being bad, we should better try to modify it (i.e. the rule in RFC 2780 -- see my previous posting on this thread), and not merely complain about it. It is generally seen that for major protocols where experiments in closed lab environments do not suffice to gain siginificant experience before standardization, some rules set by the IETF for IANA policy are too restrictive. The wave of RFCs and drafts seen during the last couple of years that aim at making additions to IETF protocols easier is a clear indication that in some Areas of the IETF the value of experiments and running code is gaining back momentum. For TCP and TLS, that's not the case, for instance. It's ours to request and drive change for the rules if they hurt. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From william.allen.simpson@gmail.com Thu Apr 1 08:21:13 2010 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 E242D3A6898; Thu, 1 Apr 2010 08:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.159 X-Spam-Level: X-Spam-Status: No, score=-1.159 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 XfMVnUg7RBYv; Thu, 1 Apr 2010 08:21:12 -0700 (PDT) Received: from mail-pz0-f196.google.com (mail-pz0-f196.google.com [209.85.222.196]) by core3.amsl.com (Postfix) with ESMTP id A8D5A3A68BF; Thu, 1 Apr 2010 08:20:56 -0700 (PDT) Received: by pzk34 with SMTP id 34so1166538pzk.20 for ; Thu, 01 Apr 2010 08:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=m7Ol0cR+dN/uQbyWIZykgJqk23vYYbg5jPYvuR3cefk=; b=TNgPEhAnHAMkTD6zL0GSVwME839HAEtbagTFYDxBNwNY1jdX40cuF6MgCIJsnKDYym zZxUrQv5ops/XjTmBzxkFuyxM2FFHeAbELS891gCfFf3UUARmOecYvhIN+T1SaCzsCt3 iASFGeILgRtHmhFsDyApn9pRkWRthq17c9K4g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=jt5pxVecvn49Wximp6CQ+9//fx7aILzDJ3FvTAfpNiXzrgK+/LzA880gmaI1P/7iQX UWQPkXM1SAO2Afc7wazI2BrDPk2kjun/NWBDTkq7Vntzf6kPwlTkOTj8zQxHzqG0elen NOqrnAJuFNrpVAVqx+5ZemN5ndydGW6VAfDAI= Received: by 10.114.252.29 with SMTP id z29mr1357350wah.39.1270135285269; Thu, 01 Apr 2010 08:21:25 -0700 (PDT) Received: from Wastrel.local (c-68-40-195-221.hsd1.mi.comcast.net [68.40.195.221]) by mx.google.com with ESMTPS id 22sm7218783iwn.8.2010.04.01.08.21.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 08:21:23 -0700 (PDT) Message-ID: <4BB4B9F1.7080404@gmail.com> Date: Thu, 01 Apr 2010 11:21:21 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Lars Eggert References: <201003072316.AAA29042@TR-Sys.de> <5FDC413D5FA246468C200652D63E627A08144911@LDCMVEXC1-PRD.hq.netapp.com> <74EC24B3-8ACF-4C62-9D0C-163CBF911B1B@nokia.com> <264D66A5-73F5-4921-8696-032692E29269@nets.rwth-aachen.de> <4BB48E63.10309@gmail.com> <8F7AE256-9954-48B5-8B26-08D4CF8E0DDC@nokia.com> In-Reply-To: <8F7AE256-9954-48B5-8B26-08D4CF8E0DDC@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org Extensions" , =?ISO-8859-1?Q?Alfred_H=CEnes?= , Alexander Zimmermann , IESG IESG Subject: Re: [tcpm] IANA TCP options registry ... 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, 01 Apr 2010 15:21:14 -0000 On 4/1/10 9:44 AM, Lars Eggert wrote: > On 2010-4-1, at 15:15, William Allen Simpson wrote: >> The only reason that I've bothered putting up the internet-draft is to get >> official IANA assignments. I'd sent in the reservation back in November, >> but IANA refused to send it to IESG for approval without an internet-draft. >> Unfortunately, IESG has been *terribly* slow to act. > > your request with IANA for the option allocation has been open for a while, agreed. > 5 months. > The ID that IANA asked for before forwarding the request to the IESG was posted by you on March 1. See http://datatracker.ietf.org/doc/draft-simpson-tcpct/#history > That's not how the process is documented. IANA is supposed to forward each such request to the IESG. Then, and only then: IESG Approval - New assignments may be approved by the IESG. Although there is no requirement that the request be documented in an RFC, the IESG has discretion to request documents or other supporting materials on a case-by-case basis. Note well: that's a discretion of the IESG, not IANA. > The Independent Stream Editor has sent it to the IESG for the RFC5742 Section 3 review on March 26, i.e., during the IETF meeting in Anaheim. > The RFC Editor was notified on March 1st, long before Anaheim. The RFC 2026 process says the RFC Editor has two weeks to consult IESG. Yet, it took 3 weekly reminders before the ISE notification was even sent to the IESG! AFAICT, this is not Neville's fault. The RFC Editor processing queue isn't working as externally documented. > The ID is slated for discussion on the very next IESG telechat on April 8. > Good. I wasn't notified. > I fail to see how we're slow. In fact, this is the most aggressive possible schedule. > The IESG was *also* notified on March 1st. [rt.ietf.org #24497] As you well know -- you (Lars) refused to put it on the IESG calendar. You've forgotten, I have the email.... From william.allen.simpson@gmail.com Thu Apr 1 09:52:54 2010 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 4AF383A69FD for ; Thu, 1 Apr 2010 09:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.213 X-Spam-Level: X-Spam-Status: No, score=0.213 tagged_above=-999 required=5 tests=[AWL=-1.218, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3] 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 EWjZ5LOX0ZQv for ; Thu, 1 Apr 2010 09:52:53 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 5E5103A67B4 for ; Thu, 1 Apr 2010 09:52:53 -0700 (PDT) Received: by pwi10 with SMTP id 10so1200516pwi.31 for ; Thu, 01 Apr 2010 09:53:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=251HKBERcEeosGSqdIfwoLmnWOv0NEhd/FurpY40HTw=; b=d04g75fACYVyD+AbnZvhfO8UGvX1p5Jr/3Oz4zj+KxxxmcTLeg7wk72rQNhPMJ5Jj7 LC4Tk3liMQFTox2gLmuEwRCrZEakAjWRR38xZmAjw362pxe91wMoCwSHVwyLoB05y/bb CFbAzsBarMTk/u0TJPAXGEc+MA2NdpAMp+Tjg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=yGdSKC6jEsVBORA94wFcvAdOWuBimqPv7wyHlTNE8RJhLsfsFlQuHdZzpRhrHqfBNF tzToGcAe6lU6BzaSgGA0+CP/s/07UO6ya8e8wknfCXiut8IMcf2fGSJ9RiECcgXZfNA5 Pl+2w18ptucjwveMQlmuj9Rru6vsrfswduErk= Received: by 10.141.1.6 with SMTP id d6mr726114rvi.175.1270140803288; Thu, 01 Apr 2010 09:53:23 -0700 (PDT) Received: from Wastrel.local (c-68-40-195-221.hsd1.mi.comcast.net [68.40.195.221]) by mx.google.com with ESMTPS id 20sm158223iwn.9.2010.04.01.09.53.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 09:53:22 -0700 (PDT) Message-ID: <4BB4CF81.2070202@gmail.com> Date: Thu, 01 Apr 2010 12:53:21 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= References: <201004011401.QAA28384@TR-Sys.de> In-Reply-To: <201004011401.QAA28384@TR-Sys.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: tcpm@ietf.org Subject: Re: [tcpm] IANA TCP options registry ... 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, 01 Apr 2010 16:52:54 -0000 On 4/1/10 10:01 AM, Alfred � wrote: > Obviously both exceptions quoted above are not proper matches for your > case, and so I still do not see the procedural rule on which you have > based your expectation of exceptional treatment. > Or did I miss something? > Reminder: by that time, earlier Linux code had already been posted for over a year, incorrectly using option 255. As noted in my IANA application: "This will have widespread testing starting on Monday, November 30th ... with the December Usenix ;login: issue publication." "There aren't enough experimental options to go around. I'm already using 253, and Cisco is apparently shipping a test with 254." > Sorry: In this case, avoidance of IETF WGs strikes back. > [eyes rolling] The last time I sent a draft through an IETF WG (RFC-4419), it took roughly 6 years to be published. Long after there were multiple interoperable implementations. If they have a deadline, or are planning on getting anything shipped, nobody in their right mind goes through an IETF WG anymore. Especially not this one.... > I do not want to argue on the final point here, but it looks like in > this case the IETF (an the IESG) is simply eating their own doggy-food, > and as shown above, this has nothing to do with ossification of the > institutions tasked with the execution of the procedures set by the > IETF. If the taste of the doggy-food is perceived as being bad, we > should better try to modify it (i.e. the rule in RFC 2780 -- see my > previous posting on this thread), and not merely complain about it. > > It is generally seen that for major protocols where experiments > in closed lab environments do not suffice to gain siginificant > experience before standardization, some rules set by the IETF > for IANA policy are too restrictive. The wave of RFCs and drafts > seen during the last couple of years that aim at making additions > to IETF protocols easier is a clear indication that in some Areas > of the IETF the value of experiments and running code is gaining > back momentum. For TCP and TLS, that's not the case, for instance. > It's ours to request and drive change for the rules if they hurt. > Been there, done that, have the t-shirt (worn on special occasions)! We reject: kings, presidents and voting. We believe in: rough consensus and running code. Sorry, but I've already gone through all that (POISED, POISSON), and we established pretty clear standards of promptness. But it's good to know "that in some Areas of the IETF the value of experiments and running code is gaining back momentum." Thanks for your feedback! From rfc-ed@rfc-editor.org Thu Apr 1 10:23:26 2010 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 F08C83A6AF4; Thu, 1 Apr 2010 10:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.139 X-Spam-Level: X-Spam-Status: No, score=-0.139 tagged_above=-999 required=5 tests=[AWL=0.731, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] 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 8GZW4XRGVFw2; Thu, 1 Apr 2010 10:23:25 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 3E0003A6A28; Thu, 1 Apr 2010 10:23:25 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 6000) id 427E8E0796; Thu, 1 Apr 2010 10:23:58 -0700 (PDT) Date: Thu, 1 Apr 2010 10:23:58 -0700 From: RFC Editor To: William Allen Simpson Message-ID: <20100401172358.GC13630@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Alexander Zimmermann , Alfred Hnes , "tcpm@ietf.org Extensions" , IESG IESG , RFC Editor Subject: [tcpm] IANA TCP options registry ... 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, 01 Apr 2010 17:23:26 -0000 Greetings, Unfortunately, we did not recognize the mail received on 1 March as a request to consider for publication as an Independent Submission, as we did not see a particular request for for the RFC Editor. Once clarified, the document was processed as described in RFC 4846. Please let us know if you have any questions. Thank you. RFC Editor Begin forwarded message: > From: William Allen Simpson > Date: April 1, 2010 8:21:21 AM PDT > To: Lars Eggert > Cc: "tcpm@ietf.org Extensions" , Alfred H?nes , Alexander Zimmermann , IESG IESG > Subject: Re: [tcpm] IANA TCP options registry ... > > On 4/1/10 9:44 AM, Lars Eggert wrote: >> On 2010-4-1, at 15:15, William Allen Simpson wrote: >>> The only reason that I've bothered putting up the internet-draft is to get >>> official IANA assignments. I'd sent in the reservation back in November, >>> but IANA refused to send it to IESG for approval without an internet-draft. >>> Unfortunately, IESG has been *terribly* slow to act. >> >> your request with IANA for the option allocation has been open for a while, agreed. >> > 5 months. > > >> The ID that IANA asked for before forwarding the request to the IESG was posted by you on March 1. See http://datatracker.ietf.org/doc/draft-simpson-tcpct/#history >> > That's not how the process is documented. IANA is supposed to forward each > such request to the IESG. Then, and only then: > > IESG Approval - New assignments may be approved by the IESG. > Although there is no requirement that the request be > documented in an RFC, the IESG has discretion to request > documents or other supporting materials on a case-by-case > basis. > > Note well: that's a discretion of the IESG, not IANA. > > >> The Independent Stream Editor has sent it to the IESG for the RFC5742 Section 3 review on March 26, i.e., during the IETF meeting in Anaheim. >> > The RFC Editor was notified on March 1st, long before Anaheim. > > The RFC 2026 process says the RFC Editor has two weeks to consult IESG. > Yet, it took 3 weekly reminders before the ISE notification was even > sent to the IESG! > > AFAICT, this is not Neville's fault. The RFC Editor processing queue isn't > working as externally documented. > > >> The ID is slated for discussion on the very next IESG telechat on April 8. >> > Good. I wasn't notified. > > >> I fail to see how we're slow. In fact, this is the most aggressive possible schedule. >> > The IESG was *also* notified on March 1st. [rt.ietf.org #24497] As you > well know -- you (Lars) refused to put it on the IESG calendar. You've > forgotten, I have the email.... > ----- End forwarded message ----- From A.Hoenes@TR-Sys.de Thu Apr 1 11:47:47 2010 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 DB8613A6A9B for ; Thu, 1 Apr 2010 11:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.665 X-Spam-Level: X-Spam-Status: No, score=-94.665 tagged_above=-999 required=5 tests=[AWL=1.095, BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 PgB0qUQS-PEl for ; Thu, 1 Apr 2010 11:47:47 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 7CF633A6A90 for ; Thu, 1 Apr 2010 11:47:46 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA106437668; Thu, 1 Apr 2010 20:47:48 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA28794; Thu, 1 Apr 2010 20:47:47 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201004011847.UAA28794@TR-Sys.de> To: lars.eggert@nokia.com Date: Thu, 1 Apr 2010 20:47:46 +0200 (MESZ) In-Reply-To: <74EC24B3-8ACF-4C62-9D0C-163CBF911B1B@nokia.com> from Lars Eggert at Apr "1, " 2010 "09:26:16" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] IANA TCP options registry ... 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, 01 Apr 2010 18:47:47 -0000 Hot news of the day: Apparently, special procedures for TCP Option Kind assignment are available, based on re-using previously assigned code points later returned to IANA; see RFC 5841 for an example. :-) Kind regards, Alfred. From william.allen.simpson@gmail.com Thu Apr 1 12:07:08 2010 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 AA0673A69B2 for ; Thu, 1 Apr 2010 12:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.307 X-Spam-Level: X-Spam-Status: No, score=0.307 tagged_above=-999 required=5 tests=[AWL=-0.824, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 WZo0ddHaWDDE for ; Thu, 1 Apr 2010 12:07:07 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id DCD583A6988 for ; Thu, 1 Apr 2010 12:07:07 -0700 (PDT) Received: by pwi10 with SMTP id 10so1333285pwi.31 for ; Thu, 01 Apr 2010 12:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=s4MwXp6MxLvnLkMcBd8uV+zcMkY2e3ScwQhXybAsj30=; b=v41Z/YZDXmspYnd4kEut9J7x5y2M+gfRhtayTGsUQRjKafaKZuEq17N8/ke9LqBBrh k5DEihPWDcHsP+WpifzvZFcapLlJVeMNRwCTCLEuhg5l6NxRHYtTWWQjFu1tOhQF5ewB tEIF7P8bCjaIZz3G+dbYRiGhB1fAJVpjuYZDo= 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=T/hNyX0S2MbUBNpSjlHZAwLy16tgnIlmA6v0qhYvM7qCXfw3qycw1XBQ/MT9w7OZUP DzhJbRCvXCsuTmy5Ix6Wsi/ZPmUUaQYTDAHZX8lLmX2sCgUCFPqVwZxd444rWuv/bGT+ jRA9+z+RhuWVotD8wuuGnuX1JmH7JAolM8EE4= Received: by 10.114.188.3 with SMTP id l3mr1761486waf.150.1270148858208; Thu, 01 Apr 2010 12:07:38 -0700 (PDT) Received: from Wastrel.local (c-68-40-195-221.hsd1.mi.comcast.net [68.40.195.221]) by mx.google.com with ESMTPS id 20sm242363iwn.13.2010.04.01.12.07.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 12:07:36 -0700 (PDT) Message-ID: <4BB4EEF7.9030503@gmail.com> Date: Thu, 01 Apr 2010 15:07:35 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: tcpm@ietf.org References: <201004011207.OAA28159@TR-Sys.de> <21169863-7EB5-4A36-AEAD-59A8AA543BAF@nokia.com> In-Reply-To: <21169863-7EB5-4A36-AEAD-59A8AA543BAF@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] IANA TCP options registry ... policy amendments? 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, 01 Apr 2010 19:07:08 -0000 On 4/1/10 9:49 AM, Lars Eggert wrote: > no. If we allocate them for shared use, people will just use them and ship code using them, like they did in the past. Nothing is gained. > Both agree and disagree with Lars. We *do* need a bigger range, but it probably should have been done more like we did with PPP. (1 code point, followed by a 3 byte OUI.) Then, it would be less of a problem for shipping code. But it's too late now. Do that with 255, instead. > We don't need to assign a range for this - the IESG can *already* assign TCP option numbers for Experimental uses. The tcpct draft was written exactly to ask for such an assignment. > The IESG can already *approve* TCP option numbers (not assign). The IESG is a functionary body, not an assignment body. We deliberately split the responsibilities long ago. Note that the IESG does not "architect", it doesn't "design", nor does it *evaluate* designs. It is merely a coordinating body. Actually, the TCPCT draft was written outside the IETF, circa late August last year. A big chunk of it was published in December. The internet-draft was posted, as a last gasp of futility, because IANA didn't do its job. IANA records assignments. It does not evaluate designs. In this case, IANA was supposed to forward the formal request to IESG for approval. That didn't happen. So, the work flow (as documented) is supposed to be: 1) IANA receives request. 2) promptly forwarded to IESG (1 working day maximum). 3) IESG takes action at its next meeting (14 calendar days maximum). 4) If there's not enough information (*not* a problem in this case), then ask for more details.... If IANA and IESG merely followed the rules as written, maybe fewer folks would throw up their hands and run away screaming. > See above for why the timeout doesn't work. > It's not the timeout that doesn't work, it's the recycling. But product cycles are typically about 3 years. It's not that hard to look at packets and determine that things are no longer in use. From william.allen.simpson@gmail.com Thu Apr 1 12:35:03 2010 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 76F1C3A69BA for ; Thu, 1 Apr 2010 12:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.856 X-Spam-Level: X-Spam-Status: No, score=-0.856 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 wICo7n3yf2kM for ; Thu, 1 Apr 2010 12:35:02 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id C2F7B3A683A for ; Thu, 1 Apr 2010 12:35:02 -0700 (PDT) Received: by pwi10 with SMTP id 10so1358171pwi.31 for ; Thu, 01 Apr 2010 12:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=kokO9ka0P2W/nhH8E2zH+qq0rxsa3JP5QrnkF1t32Gw=; b=lfhoS6Ua+mkYjaNFLI9L24PtY1f5OX0SsdlfeY2K4IHTCvmGCpvjmVsJsOUVLMZa+K dKOlVArfQCqQ5Ps+2BH1sPrtBV5Tey8YZZu7NHa8gpBXcAsRgKXfy3iWUtm+Ii0jdgIs zH85hg1DvZU2NONCavgKO3Nxvzsp8VBr6Y/D0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Z8JfgRmEQl2ks0gjcGZLbYmaOsJzeNPlLTXnL3em2sVdxIaBEVuprV5a2XAarAq6IU NnMCBaXKSzJLD5ExBiWNXkGnHAc2dI+odmmeqYZwRWJnt28trANAqQpCSMNSuc6Atx2K NUQgZ9602aVPVtZ7vvhvlVzAKpvAd4NeLQmQM= Received: by 10.142.196.17 with SMTP id t17mr494330wff.280.1270150530956; Thu, 01 Apr 2010 12:35:30 -0700 (PDT) Received: from Wastrel.local (c-68-40-195-221.hsd1.mi.comcast.net [68.40.195.221]) by mx.google.com with ESMTPS id 20sm257481iwn.1.2010.04.01.12.35.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 12:35:28 -0700 (PDT) Message-ID: <4BB4F57A.3020400@gmail.com> Date: Thu, 01 Apr 2010 15:35:22 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: RFC Editor References: <20100401172358.GC13630@rfc-editor.org> In-Reply-To: <20100401172358.GC13630@rfc-editor.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: TCP Modifications WG Subject: Re: [tcpm] IANA TCP options registry ... 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, 01 Apr 2010 19:35:03 -0000 On 4/1/10 1:23 PM, RFC Editor wrote: > Unfortunately, we did not recognize the mail received on 1 March as a > request to consider for publication as > an Independent Submission, as we did not see a particular request for > for the RFC Editor. Once clarified, the document was processed as > described in RFC 4846. > Pardon my unclear language in my first sentence of March 1st: # "this is a formal request for approval and publication." >> From: William Allen Simpson >> The RFC Editor was notified on March 1st, long before Anaheim. >> >> The RFC 2026 process says the RFC Editor has two weeks to consult IESG. >> Yet, it took 3 weekly reminders before the ISE notification was even >> sent to the IESG! >> >> AFAICT, this is not Neville's fault. The RFC Editor processing queue isn't >> working as externally documented. >> My message of March 15th yielded more prompt results: # It has been 14 days. RFC 2026 section 4.2.3: # # "... The RFC Editor will wait two weeks after this # publication for comments before proceeding further. ..." # # I have nroff ready. Do you want it now? # From mallman@icir.org Thu Apr 1 12:53:09 2010 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 E83A93A6847 for ; Thu, 1 Apr 2010 12:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.675 X-Spam-Level: X-Spam-Status: No, score=-4.675 tagged_above=-999 required=5 tests=[AWL=0.794, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 1tQE+Pwz+nxI for ; Thu, 1 Apr 2010 12:53:09 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 591563A6836 for ; Thu, 1 Apr 2010 12:53:09 -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 o31JrKwg009993; Thu, 1 Apr 2010 12:53:20 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 65DE6C97755; Thu, 1 Apr 2010 15:53:20 -0400 (EDT) To: Murali Bashyam From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: The Joker MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma63920-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 01 Apr 2010 15:53:20 -0400 Sender: mallman@icir.org Message-Id: <20100401195320.65DE6C97755@lawyers.icir.org> Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 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, 01 Apr 2010 19:53:10 -0000 ----------ma63920-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > There are other aspects too, it's also important for the application > to control the duration that the connection spends in persist state, > this is planned to be accomplished via a socket option. Why? I mean, sure, an app may want to not let a connection hang around forever. But, can't it just ABORT whenever it wants? allman ----------ma63920-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAku0+bAACgkQWyrrWs4yIs6cpgCfSyIUSl58w8ZqzNyh6SBBPVrg TOcAn3FLQGFBqFVjvj2OTtL+fAgRBf0P =2453 -----END PGP SIGNATURE----- ----------ma63920-1-- From mallman@icir.org Thu Apr 1 13:35:16 2010 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 8F29B3A68D4 for ; Thu, 1 Apr 2010 13:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.01 X-Spam-Level: X-Spam-Status: No, score=-4.01 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, 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 ijZbORE0WPDH for ; Thu, 1 Apr 2010 13:35:12 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 99F123A6847 for ; Thu, 1 Apr 2010 13:35:12 -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 o31KZhWZ015786; Thu, 1 Apr 2010 13:35:44 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id BD0FBC9A1C1; Thu, 1 Apr 2010 16:35:43 -0400 (EDT) To: Manqing Huang From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: The Joker MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma927-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 01 Apr 2010 16:35:43 -0400 Sender: mallman@icir.org Message-Id: <20100401203543.BD0FBC9A1C1@lawyers.icir.org> Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Introducing draft-huang-tcpm-tcp-eack-00 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, 01 Apr 2010 20:35:16 -0000 ----------ma927-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > I would like to introduce draft-huang-tcpm-tcp-eack-00 to this > group. The purpose of the TCP option proposed in this draft is to > improve TCP performance by reducing the amount of separate ACK packets > when there are multiple TCP connections and each of the connections > carries one way traffic. Applications that can benefit from this > option include HTTP and FTP. I quickly looked at the draft. Three bits ... (1) Have a look at RFC 5690 on ACK congestion control that tries to adapt the number of pure ACKs sent with the network conditions. (2) It seems to me to be a fairly bad idea to try to exchange state about some connection on an independent connection. Seems like a recipe for a big mess. (3) For this to even have a shot (as Alexander previously mentioned) the traffic pattern would have to be Just So. I.e., you'd have to be sending from A->B on one connection and receiving from B->A on another. That seems implausible to me. You say HTTP and FTP can benefit, but I doubt it. How many times are you fetching a file via FTP while you're also sending a file to the same endpoint? How much do HTTP clients really send? Sure, sometimes they upload pictures and video. But, most of the time they send a few hundred bytes of request and thats it. Not much room for piggybacking. Seems that regardless of whether we could engineer some cross- connection scheme we should have some idea that it'd be Really Useful. Luckily, that can be assessed via looking at network traffic and assessing the symmetry (i.e., the opportunities for piggybacking). That seems like it should be the first step because without that the motivation seems too far fetched to even worry about the details of the proposal. allman ----------ma927-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAku1A58ACgkQWyrrWs4yIs7jGACdFf4RKtyhfzU+C2V+W21z+2cQ YewAmgI9wTiiQaJGeD0LpEukKiSYu9/4 =uhNK -----END PGP SIGNATURE----- ----------ma927-1-- From johnwheffner@gmail.com Thu Apr 1 13:40:03 2010 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 151563A68D4 for ; Thu, 1 Apr 2010 13:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.65 X-Spam-Level: X-Spam-Status: No, score=0.65 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] 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 UcuV9Bnyp2U9 for ; Thu, 1 Apr 2010 13:40:02 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id EFA913A685D for ; Thu, 1 Apr 2010 13:40:01 -0700 (PDT) Received: by wyb29 with SMTP id 29so679980wyb.31 for ; Thu, 01 Apr 2010 13:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/tYvIK+DGyfq92DA9AMf55UvW+x6L9yVJKLo6+yyJYk=; b=nBMNk82ePYKtCFl07drUuaY68O02oLg1XPhbgctcJg1p/tTdIUzAIqIsbrOKJPVI6C FasZlEAHraIbRmM2VKhVbgtWMXyqkAE+eRiIEb9s8757fXq2ipnFy+sY1tVR3zbIwq03 EDfeU2XtE54kL4fSsVP7IaU3wKr/oIZTDvuRA= 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=p5GEE4GfK4VzXtAxAFVhyv0znsQO+SEbtF283jMQH+NjyKQG8tbYULBhNdK6ZGNd3R hFoVBET4qJaMoyT4ogqZOFIz6F4DvIjc/v/GPd/luBEvUfVhW1Rp7j49Z0azNuYCY18N 3nY24g4vq5mnG8ftUuUxApZJise43/3dR6sfI= MIME-Version: 1.0 Received: by 10.216.184.9 with HTTP; Thu, 1 Apr 2010 13:40:31 -0700 (PDT) In-Reply-To: <20100401195320.65DE6C97755@lawyers.icir.org> References: <20100401195320.65DE6C97755@lawyers.icir.org> Date: Thu, 1 Apr 2010 16:40:31 -0400 Received: by 10.216.178.207 with SMTP id f57mr708132wem.88.1270154431206; Thu, 01 Apr 2010 13:40:31 -0700 (PDT) Message-ID: From: John Heffner To: mallman@icir.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tcpm@ietf.org" , Murali Bashyam Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 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, 01 Apr 2010 20:40:03 -0000 On Thu, Apr 1, 2010 at 3:53 PM, Mark Allman wrote: >> There are other aspects too, it's also important for the application >> to control the duration that the connection spends in persist state, >> this is planned to be accomplished via a socket option. > > Why? > > I mean, sure, an app may want to not let a connection hang around > forever. =A0But, can't it just ABORT whenever it wants? I suspect one reason this has become an issue is that the sockets interface does not provide ABORT semantics, so it's not possible on most operating systems to write an application that is able to avoid tying up kernel memory. I'm not sure this is an IETF issue, though. I think a good approach for an operating system implementor is to (1) provide ABORT via a socket fd so individual applications can manage their own connections, and (2) provide a system-wide nanny so admins can provide some degree of safety even if applications aren't written so carefully (obviously, most aren't). (And, not to sound like a broken record, the receiver's current window size should probably have nothing to do with whether the connection is aborted.) -John From ananth@cisco.com Thu Apr 1 13:55:39 2010 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 53EEE3A684B for ; Thu, 1 Apr 2010 13:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.469 X-Spam-Level: X-Spam-Status: No, score=-9.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 SXTBoNfkrsuW for ; Thu, 1 Apr 2010 13:55:38 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 17D963A6888 for ; Thu, 1 Apr 2010 13:55:37 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMektEurR7Ht/2dsb2JhbACbSnGdPZkOhQEEgyM X-IronPort-AV: E=Sophos;i="4.51,350,1267401600"; d="scan'208";a="507140698" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 01 Apr 2010 20:54:58 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o31Ksw3A022957; Thu, 1 Apr 2010 20:54:58 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 13:54:58 -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, 1 Apr 2010 13:54:57 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC580938B73C@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20100401195320.65DE6C97755@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] poll for adoption of draft-ananth-persist-02 Thread-Index: AcrR1QxSicz6NBhNT46X8AmRuQV3WwAAPMTg References: <20100401195320.65DE6C97755@lawyers.icir.org> From: "Anantha Ramaiah (ananth)" To: , "Murali Bashyam" X-OriginalArrivalTime: 01 Apr 2010 20:54:58.0319 (UTC) FILETIME=[96E729F0:01CAD1DD] Cc: tcpm@ietf.org Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 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, 01 Apr 2010 20:55:39 -0000 Hi Mark,=20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Mark Allman > Sent: Thursday, April 01, 2010 12:53 PM > To: Murali Bashyam > Cc: tcpm@ietf.org > Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 >=20 > > There are other aspects too, it's also important for the=20 > application=20 > > to control the duration that the connection spends in=20 > persist state,=20 > > this is planned to be accomplished via a socket option. >=20 > Why? >=20 > I mean, sure, an app may want to not let a connection hang=20 > around forever. But, can't it just ABORT whenever it wants? Yes, the application can ABORT the connection whenever it wants.=20 The socket option is suggested for multiple reasons (use cases) :- - orphaned connections, where the application has already closed the connection and the connection is in persist state. - Typically when the data cannot be sent (due to retransmisions) there is a retransmit timeout happening and a error ETIMEDOUT returned to the application, for persist case there is no way for the application to know about the connection not making any progress. When this socket option is set, TCP would behave the same way as would for ETIMEDOUT case. The reason why the socket option is been suggested because we want to preserve the default behaviour of persist forever but an override suggested by the application if needed by means of a socket option. (or sysctl or something equivalent). This ensures that we are not violating RFC 1122. Also this is an informational draft and typically one would want to explain the situation better and some implementation advice, that is the reason we have put the socket option in the appendix. Hope this explanation conveys the functionality of the socket option, do you think some clarfication are needed in the document?. (actually we have received other comments too and will put all of them together when we submit the next revision). -Anantha >=20 > allman >=20 >=20 >=20 >=20 From Manqing.Huang@exar.com Thu Apr 1 14:36:05 2010 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 04F003A698D for ; Thu, 1 Apr 2010 14:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 1Hs-H8qCkhRU for ; Thu, 1 Apr 2010 14:36:04 -0700 (PDT) Received: from smtp1.exar.com (webmail.exar.com [204.154.183.83]) by core3.amsl.com (Postfix) with ESMTP id 0392F3A6888 for ; Thu, 1 Apr 2010 14:36:03 -0700 (PDT) Received: from FRE1EXCH02.hq.exar.com ([fe80::e9a7:6160:4e13:1677]) by fre1-cas ([10.127.1.162]) with mapi; Thu, 1 Apr 2010 14:36:36 -0700 From: Manqing Huang To: "mallman@icir.org" Date: Thu, 1 Apr 2010 14:36:35 -0700 Thread-Topic: [tcpm] Introducing draft-huang-tcpm-tcp-eack-00 Thread-Index: AcrR2ufNsCZQLrJwQRCAnqYtlK6crAACD/Sw Message-ID: References: <20100401203543.BD0FBC9A1C1@lawyers.icir.org> In-Reply-To: <20100401203543.BD0FBC9A1C1@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Introducing draft-huang-tcpm-tcp-eack-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, 01 Apr 2010 21:36:05 -0000 Mark, Thank you for the comments. I read RFC 5690 and thought the ACK congestion = control will mitigate the issue I am describing. Manqing -----Original Message----- From: mallman@icir.org [mailto:mallman@icir.org] Sent: Thursday, April 01, 2010 1:36 PM To: Manqing Huang Cc: tcpm@ietf.org Subject: Re: [tcpm] Introducing draft-huang-tcpm-tcp-eack-00 > I would like to introduce draft-huang-tcpm-tcp-eack-00 to this group. > The purpose of the TCP option proposed in this draft is to improve TCP > performance by reducing the amount of separate ACK packets when there > are multiple TCP connections and each of the connections carries one > way traffic. Applications that can benefit from this option include > HTTP and FTP. I quickly looked at the draft. Three bits ... (1) Have a look at RFC 5690 on ACK congestion control that tries to adapt the number of pure ACKs sent with the network conditions. (2) It seems to me to be a fairly bad idea to try to exchange state about some connection on an independent connection. Seems like a recipe for a big mess. (3) For this to even have a shot (as Alexander previously mentioned) the traffic pattern would have to be Just So. I.e., you'd have to be sending from A->B on one connection and receiving from B->A on another. That seems implausible to me. You say HTTP and FTP can benefit, but I doubt it. How many times are you fetching a file via FTP while you're also sending a file to the same endpoint? How much do HTTP clients really send? Sure, sometimes they upload pictures and video. But, most of the time they send a few hundred bytes of request and thats it. Not much room for piggybacking. Seems that regardless of whether we could engineer some cross- connection scheme we should have some idea that it'd be Really Useful. Luckily, that can be assessed via looking at network traffic and assessing the symmetry (i.e., the opportunities for piggybacking). That seems like it should be the first step because without that the motivation seems too far fetched to even worry about the details of the proposal. allman The information and any attached documents contained in this message may be confidential and/or legally privileged. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender immediately by return e-mail and destroy all copies of the original message. From rfc-ed@rfc-editor.org Thu Apr 1 15:28:08 2010 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 693073A6869; Thu, 1 Apr 2010 15:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[AWL=0.938, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001] 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 wuJKVzoO6OQQ; Thu, 1 Apr 2010 15:28:07 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 671D53A6800; Thu, 1 Apr 2010 15:28:04 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 6000) id B28EDE0797; Thu, 1 Apr 2010 15:28:37 -0700 (PDT) Date: Thu, 1 Apr 2010 15:28:37 -0700 From: RFC Editor To: William Allen Simpson Message-ID: <20100401222837.GA14648@rfc-editor.org> References: <20091125092230.DC5482A4018@isvc1.lax.icann.org> <4B8C01CB.6030104@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B8C01CB.6030104@gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: TCP Modifications WG , IESG , RFC Editor Subject: [tcpm] IANA TCP options registry ... -- Re: [IANA #282277] General Request for Assignments (tcp-parameters) 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, 01 Apr 2010 22:28:08 -0000 Greetings, We did not recgonize the document as a request for publication as an Independent Submission because we thought the reqeust was to the IESG, as the message below indicates "IESG, this is a formal request for approval and publication." We apologize for the confusion and delay. Please let us know if you have any questions. Thank you. RFC Editor Date: Thu, 01 Apr 2010 15:35:22 -0400 From: William Allen Simpson To: RFC Editor CC: TCP Modifications WG Subject: Re: [tcpm] IANA TCP options registry ... On 4/1/10 1:23 PM, RFC Editor wrote: > Unfortunately, we did not recognize the mail received on 1 March as a > request to consider for publication as > an Independent Submission, as we did not see a particular request for > for the RFC Editor. Once clarified, the document was processed as > described in RFC 4846. > Pardon my unclear language in my first sentence of March 1st: # "this is a formal request for approval and publication." On Mon, Mar 01, 2010 at 01:04:59PM -0500, William Allen Simpson wrote: > Amanda Baber via RT wrote: >> This registry requires IESG Approval or Standards Action, so we can't take >> any action yet. Let us know when your draft has been posted, and we'll ask >> the IESG to review it and approve the assignments. > IESG, this is a formal request for approval and publication. In the > usual tradition (of T/TCP, etc), I'm not interested in Standards Action > at this time. This is not the product of a working group. > > Title : TCP Cookie Transactions (TCPCT) > Author(s) : W. Simpson > Filename : draft-simpson-tcpct-00.txt > Pages : 34 > Date : 2010-2-26 > > TCP Cookie Transactions (TCPCT) deter spoofing of connections and > prevent resource exhaustion, eliminating Responder (server) state > during the initial handshake. The Initiator (client) has sole > responsibility for ensuring required delays between connections. The > cookie exchange may carry data, limited to inhibit amplification and > reflection denial of service attacks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-simpson-tcpct-00.txt > > >> Please note that we can't guarantee that these numbers won't be assigned >> in the interim. >> > We chose them after examining tcpdump repositories and testing. > > TCPM scuttlebutt has Cisco using 33 (without reservation). The official > experimental numbers 253-254 were unusable over the Internet for testing, > as those have been compromised by other shipping products (Cisco and > some "middlebox discovery" vendor or two). > > So, we had to decide on a pair of numbers sooner rather than later! > > There are now many systems running this code. > > >> On Wed Nov 25 09:22:31 2009, William.Allen.Simpson@gmail.com wrote: >>> Contact Name : >>> William Allen Simpson >>> >>> Contact Email : >>> William.Allen.Simpson@gmail.com >>> >>> Type of Assignment : >>> 31 TCP Cookie Extension (variable length) >>> 32 TCP Time Stamp Extension >>> (3) >>> > Here's the draft's IANA Considerations, slightly more formal names: > > TCP Cookie Option > Kind: 31 > Length: variable. > > TCP Timestamps Extended Option > Kind: 32 > Length: 3. > > >>> Registry : >>> http://www.iana.org/assignments/tcp-parameters/ >>> From mallman@icir.org Thu Apr 1 19:45:15 2010 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 AAF143A68AF for ; Thu, 1 Apr 2010 19:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.751 X-Spam-Level: X-Spam-Status: No, score=-4.751 tagged_above=-999 required=5 tests=[AWL=0.718, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 bNyQzMgfV5rn for ; Thu, 1 Apr 2010 19:45:15 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 0B9B63A6774 for ; Thu, 1 Apr 2010 19:45:15 -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 o322jknw023105; Thu, 1 Apr 2010 19:45:46 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id AF102C9C72A; Thu, 1 Apr 2010 22:45:46 -0400 (EDT) To: "Anantha Ramaiah (ananth)" From: Mark Allman In-Reply-To: <0C53DCFB700D144284A584F54711EC580938B73C@xmb-sjc-21c.amer.cisco.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: The Joker MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma23128-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 01 Apr 2010 22:45:46 -0400 Sender: mallman@icir.org Message-Id: <20100402024546.AF102C9C72A@lawyers.icir.org> Cc: tcpm@ietf.org, Murali Bashyam Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 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, 02 Apr 2010 02:45:15 -0000 ----------ma23128-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > > I mean, sure, an app may want to not let a connection hang around > > forever. But, can't it just ABORT whenever it wants? > > Yes, the application can ABORT the connection whenever it wants. > > The socket option is suggested for multiple reasons (use cases) :- Well, that all strikes me as thin. I mean, I don't actually care what socket option anyone wants to add, but I agree with John that it doesn't seem like IETF work to me. I certainly wouldn't suggest doing it in a draft that is meant as a simple clarification of previous RFCs. I am fine with the simple clarification in this draft. I would leave off the API gunk. Just my hit. allman ----------ma23128-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAku1WloACgkQWyrrWs4yIs6zuQCeOWMjjaxKKCXU4ZUxt3GGbqTa G6IAoJQ9tDzbb/6AReCjcZXfAwumZG2b =9j0U -----END PGP SIGNATURE----- ----------ma23128-1-- From MBashyam@OcarinaNetworks.com Thu Apr 1 21:05:10 2010 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 20E423A6863 for ; Thu, 1 Apr 2010 21:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.175 X-Spam-Level: X-Spam-Status: No, score=-0.175 tagged_above=-999 required=5 tests=[AWL=0.960, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334] 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 Xk5YppRU5uZy for ; Thu, 1 Apr 2010 21:05:09 -0700 (PDT) Received: from mail.ocarinanetworks.com (mail.ocarinanetworks.com [69.3.29.22]) by core3.amsl.com (Postfix) with ESMTP id 8F8F73A693F for ; Thu, 1 Apr 2010 21:05:07 -0700 (PDT) Received: from exchsvr01.ocarina.local ([10.250.1.7]) by exchsvr01.ocarina.local ([10.250.1.7]) with mapi; Thu, 1 Apr 2010 21:07:31 -0700 From: Murali Bashyam To: "mallman@icir.org" , "Anantha Ramaiah (ananth)" Date: Thu, 1 Apr 2010 21:07:28 -0700 Thread-Topic: [tcpm] poll for adoption of draft-ananth-persist-02 Thread-Index: AcrSDu2qVdEb1uNzTmSxCix/OAy/7QACWS0Q Message-ID: References: <0C53DCFB700D144284A584F54711EC580938B73C@xmb-sjc-21c.amer.cisco.com> <20100402024546.AF102C9C72A@lawyers.icir.org> In-Reply-To: <20100402024546.AF102C9C72A@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 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, 02 Apr 2010 04:05:10 -0000 The attempt here via the socket option etc is to describe a guideline to no= rmalize the persist condition connection failure to the excessive retransmi= ssions condition. Note that for the latter connection failure, RFC 1122 say= s TCP SHOULD inform the application unless the app has disabled asynchronou= s reporting of soft errors. Are you suggesting that the guideline is unnece= ssary or out of scope for this document? -----Original Message----- From: mallman@icir.org [mailto:mallman@icir.org]=20 Sent: Thursday, April 01, 2010 7:46 PM To: Anantha Ramaiah (ananth) Cc: Murali Bashyam; tcpm@ietf.org Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02=20 > > I mean, sure, an app may want to not let a connection hang around=20 > > forever. But, can't it just ABORT whenever it wants? >=20 > Yes, the application can ABORT the connection whenever it wants.=20 >=20 > The socket option is suggested for multiple reasons (use cases) :- Well, that all strikes me as thin. I mean, I don't actually care what sock= et option anyone wants to add, but I agree with John that it doesn't seem l= ike IETF work to me. I certainly wouldn't suggest doing it in a draft that= is meant as a simple clarification of previous RFCs. I am fine with the simple clarification in this draft. I would leave off t= he API gunk. Just my hit. allman From touch@ISI.EDU Sat Apr 3 11:01:30 2010 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 4AE8D3A698E for ; Sat, 3 Apr 2010 11:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_50=0.001] 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 s-ylc3P8GVpU for ; Sat, 3 Apr 2010 11:01:29 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 01D7B3A69C5 for ; Sat, 3 Apr 2010 11:01:11 -0700 (PDT) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o33HxhUK025881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Apr 2010 10:59:45 -0700 (PDT) Message-ID: <4BB7820E.1010203@isi.edu> Date: Sat, 03 Apr 2010 10:59:42 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: John Heffner References: <20100401195320.65DE6C97755@lawyers.icir.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3EC84FF8311D04FDF785DA93" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , Murali Bashyam , mallman@icir.org Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 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, 03 Apr 2010 18:01:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3EC84FF8311D04FDF785DA93 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable John Heffner wrote: > On Thu, Apr 1, 2010 at 3:53 PM, Mark Allman wrote: >>> There are other aspects too, it's also important for the application >>> to control the duration that the connection spends in persist state, >>> this is planned to be accomplished via a socket option. >> Why? >> >> I mean, sure, an app may want to not let a connection hang around >> forever. But, can't it just ABORT whenever it wants? >=20 > I suspect one reason this has become an issue is that the sockets > interface does not provide ABORT semantics, so it's not possible on > most operating systems to write an application that is able to avoid > tying up kernel memory. I'm not sure this is an IETF issue, though. I don't think so either. RFC 793 specifies an API (including ABORT), but not how it is instantiated. It looks like this is already possible, though: Linux has abort via: CLOSE after SO_LINGER(l_onoff=3Dnonzero, l_linger=3D= 0) FreeBSD has a sysctl_drop accessible by TCPCTL_DROP There appears to be a userland command for this called tcpdrop, too. Joe --------------enig3EC84FF8311D04FDF785DA93 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAku3gg4ACgkQE5f5cImnZru4NQCdEw7YolA+tK0oITRLoIULd3/L qOwAoIwgo+o3HM+YKxiISitbOWqOxU/t =sO2J -----END PGP SIGNATURE----- --------------enig3EC84FF8311D04FDF785DA93-- From fernando@gont.com.ar Sat Apr 3 16:27:41 2010 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 31FA03A684B for ; Sat, 3 Apr 2010 16:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 KLy3u5hIMwRK for ; Sat, 3 Apr 2010 16:27:39 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id AAD3C3A67FC for ; Sat, 3 Apr 2010 16:27:38 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id D91E36B6675; Sat, 3 Apr 2010 20:27:40 -0300 (ART) Received: from [192.168.0.102] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o33NRVpL008049; Sat, 3 Apr 2010 20:27:32 -0300 Message-ID: <4BB7CEE3.6020706@gont.com.ar> Date: Sat, 03 Apr 2010 20:27:31 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Joe Touch References: <20100401195320.65DE6C97755@lawyers.icir.org> <4BB7820E.1010203@isi.edu> In-Reply-To: <4BB7820E.1010203@isi.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Sat, 03 Apr 2010 20:27:39 -0300 (ART) Cc: "tcpm@ietf.org" , Murali Bashyam , mallman@icir.org Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 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, 03 Apr 2010 23:27:41 -0000 Joe Touch wrote: > I don't think so either. RFC 793 specifies an API (including ABORT), but > not how it is instantiated. > > It looks like this is already possible, though: > > Linux has abort via: CLOSE after SO_LINGER(l_onoff=nonzero, l_linger=0) I agree with Joe here. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From mallman@icir.org Wed Apr 7 19:58:06 2010 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 867643A686C for ; Wed, 7 Apr 2010 19:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 TMX27O0kGEzM for ; Wed, 7 Apr 2010 19:58: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 D08773A62C1 for ; Wed, 7 Apr 2010 19:58: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 o382vuoB024447; Wed, 7 Apr 2010 19:57:57 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 85D4ED2D489; Wed, 7 Apr 2010 22:57:56 -0400 (EDT) To: Fernando Gont From: Mark Allman In-Reply-To: <4BB7CEE3.6020706@gont.com.ar> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: TV Dinner MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma17972-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 07 Apr 2010 22:57:56 -0400 Sender: mallman@icir.org Message-Id: <20100408025756.85D4ED2D489@lawyers.icir.org> Cc: "tcpm@ietf.org" , Murali Bashyam , Joe Touch Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 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, 08 Apr 2010 02:58:06 -0000 ----------ma17972-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Joe Touch wrote: > > > I don't think so either. RFC 793 specifies an API (including ABORT), but > > not how it is instantiated. > > > > It looks like this is already possible, though: > > > > Linux has abort via: CLOSE after SO_LINGER(l_onoff=nonzero, l_linger=0) > > I agree with Joe here. Yep. We should clarify and be done with it. The hooks to let the app do something smart if it cares enough to do so are already either there or specified. allman ----------ma17972-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAku9RjQACgkQWyrrWs4yIs6szQCfbl9zT28wshM+9AqRKMmbTG8O wRIAn1pQ2mG0/z5GP3CWIR2h2UrxfSFz =j3As -----END PGP SIGNATURE----- ----------ma17972-1-- From fernando@gont.com.ar Wed Apr 7 20:50:41 2010 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 F2E7F3A68D1 for ; Wed, 7 Apr 2010 20:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.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 aLHfkyoHPPz4 for ; Wed, 7 Apr 2010 20:50:39 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 5DD9D3A6827 for ; Wed, 7 Apr 2010 20:50:38 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 5D9E26B687F; Thu, 8 Apr 2010 00:50:39 -0300 (ART) Received: from [192.168.0.102] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o383oUmJ024636; Thu, 8 Apr 2010 00:50:31 -0300 Message-ID: <4BBD5286.4030003@gont.com.ar> Date: Thu, 08 Apr 2010 00:50:30 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: mallman@icir.org References: <20100408025756.85D4ED2D489@lawyers.icir.org> In-Reply-To: <20100408025756.85D4ED2D489@lawyers.icir.org> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Thu, 08 Apr 2010 00:50:38 -0300 (ART) Cc: "tcpm@ietf.org" , Murali Bashyam , Joe Touch Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 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, 08 Apr 2010 03:50:41 -0000 Mark Allman wrote: >>> Linux has abort via: CLOSE after SO_LINGER(l_onoff=nonzero, l_linger=0) >> I agree with Joe here. > > Yep. We should clarify and be done with it. The hooks to let the app > do something smart if it cares enough to do so are already either there > or specified. FWIW, this SO_LINGER option predates Linux. It was already covered in Stevens' UNP series, which didn't cover Linux (IIRC). IMO, we don't need RFC 1122 (or whatever) to allow us to abort (i.e., ABORT()) connections (despite the reason). The ABORT procedure was already defined in RFC 793, and there were no contraints at all wrt *when* a TCP user is allowed to call it. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From lars.eggert@nokia.com Thu Apr 8 07:29:53 2010 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 999A93A6810 for ; Thu, 8 Apr 2010 07:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 FviImuaz9aRo for ; Thu, 8 Apr 2010 07:29:48 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 053753A67AF for ; Thu, 8 Apr 2010 07:29:33 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o38ETAg8010997; Thu, 8 Apr 2010 09:29:28 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Apr 2010 17:28:27 +0300 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Apr 2010 17:28:27 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o38ESQQ2023227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Apr 2010 17:28:26 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/signed; boundary=Apple-Mail-8-371899919; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4BB4EEF7.9030503@gmail.com> Date: Thu, 8 Apr 2010 17:27:55 +0300 Message-Id: <693C2F76-D603-4746-A676-D82B0559F649@nokia.com> References: <201004011207.OAA28159@TR-Sys.de> <21169863-7EB5-4A36-AEAD-59A8AA543BAF@nokia.com> <4BB4EEF7.9030503@gmail.com> To: William Allen Simpson X-Mailer: Apple Mail (2.1078) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Thu, 08 Apr 2010 17:28:00 +0300 (EEST) X-OriginalArrivalTime: 08 Apr 2010 14:28:27.0200 (UTC) FILETIME=[C0CF7C00:01CAD727] X-Nokia-AV: Clean Cc: "tcpm@ietf.org" Subject: Re: [tcpm] IANA TCP options registry ... policy amendments? 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, 08 Apr 2010 14:29:53 -0000 --Apple-Mail-8-371899919 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-4-1, at 22:07, William Allen Simpson wrote: > The IESG can already *approve* TCP option numbers (not assign). The = IESG > is a functionary body, not an assignment body. We deliberately split = the > responsibilities long ago. correct. Sorry for being sloppy with my wording. > Note that the IESG does not "architect", it doesn't "design", nor does = it > *evaluate* designs. It is merely a coordinating body. Please re-read RFC2026. The IESG is not merely a coordinating body. > So, the work flow (as documented) is supposed to be: > 1) IANA receives request. > 2) promptly forwarded to IESG (1 working day maximum). I agree that this took longer than necessary. I disagree that one = working day is a reasonable deadline. > 3) IESG takes action at its next meeting (14 calendar days maximum). > 4) If there's not enough information (*not* a problem in this case), > then ask for more details.... Because the IESG isn't merely a coordinating body, an action takes some = time. Especially if it involves reviewing an at least moderately complex = proposal that doesn't come from an IETF WG and that requires soliciting = external opinions from TCP, DNS and security experts. I will also freely = admit that I personally prioritize the processing of IETF documents over = dealing with independent submissions. Lars= --Apple-Mail-8-371899919 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDQwODE0Mjc1NlowIwYJKoZIhvcNAQkEMRYEFDnn8U5Y8gWritrvgPDe96uiOjFYMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQBleOPClW7HciqEp7db6TkgXNwOJGBFAyJoUNcA4kD72tQtl3AeFfhx6OjhabgFQgfXwiAT ElKhqwRuieIt3uvXBwXrYpTiR/5v3GctcgWEkGm+Pes5u9eWVTFaIWjLY+ujusRP+6NhSXT8PKzv YxpvVmLI0zVoTCv6eMaMjPlBZQBlEqRxMhbab5b3bx2iorqz1R02MeMlPNhHKVQJhSWAIFRIXB2L 7oNAMmPF/o0ZYU8RI2SQL6yu17Y/dOvUeYhY99RD99KQgtv/g9kKezOkMVxh8UFRGBU872ffefrX y3axrcUFt+JPGfO8j8HIlPoygPg9+H+rnUW9S77HHN6xAAAAAAAA --Apple-Mail-8-371899919-- From wangchentao_76@yahoo.com.cn Mon Apr 12 03:23:20 2010 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 5D8573A68EB for ; Mon, 12 Apr 2010 03:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.739 X-Spam-Level: ** X-Spam-Status: No, score=2.739 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_99=3.5, HTML_MESSAGE=0.001] 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 p1OU4-+Xmj1Z for ; Mon, 12 Apr 2010 03:23:19 -0700 (PDT) Received: from web15208.mail.cnb.yahoo.com (web15208.mail.cnb.yahoo.com [202.165.105.138]) by core3.amsl.com (Postfix) with SMTP id 07CE63A67B3 for ; Mon, 12 Apr 2010 03:23:18 -0700 (PDT) Received: (qmail 15421 invoked by uid 60001); 12 Apr 2010 10:23:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.cn; s=s1024; t=1271067791; bh=uY7MIjPfhWq/a0QrUEQJbX6Aa6ygvqlCxQYeoC3e5es=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=QtCNvnBaqbAqdiAUObUFoUmiuR/hCxyqfWkRov1Qf3Xcp90ueZs6LMqhfbEAPcfRcoaaSVT6ECncuVGM7J1YEUbmjH7SUQH7AapUTG/EGmoVBjmrVJkbTqhljW0+FCPmXet2ZBcJHRkNaKPE/2y3fIXR9WFY/MqAJvdPIAtNOyA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=3L0mDm+trWpxc1LZFI9CNx3yYBwhTCGOJn6wg9BLXuZACNnkw28jIG+3ejG7yZZa4xWpKmbNMZMH0vIviQmt+qVZj9GyNFxiXhNt/g0Jmc6kfkT/S+CnpG8Y6hLDVpp/aL+6SL0qmIqTq6MwSp0ccWWZQ73AUvh46048V1pO7/0=; Message-ID: <763425.13839.qm@web15208.mail.cnb.yahoo.com> X-YMail-OSG: aZlJZKoVM1lQ2psNbwF8P1MqCJvlpv2qQIiFINIZG_U5C__ LUBbogk_RSIlQnk4.n3D2SCZQ4jJSGrE73L8N2rI0X4kQbIwXXf0KC.JCNpi tGXMVBi7S0aCKQvgBVpFup1gs6SS79Q1EVn5aXa4irp26KmzZT0m8OJVTQIP __SowrF__lCC7MaFpsNAP4Exlm5rHl9vVr14_ Received: from [218.207.242.68] by web15208.mail.cnb.yahoo.com via HTTP; Mon, 12 Apr 2010 18:23:11 CST X-Mailer: YahooMailRC/348.3 YahooMailWebService/0.8.100.260964 Date: Mon, 12 Apr 2010 18:23:11 +0800 (CST) From: chentao wang To: tcpm@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1481866680-1271067791=:13839" Subject: [tcpm] hi 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, 12 Apr 2010 10:23:21 -0000 --0-1481866680-1271067791=:13839 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable hello=EF=BC=8Ceveryone !=0A=0Achengong=C2=A0=0A=0A=0A --0-1481866680-1271067791=:13839 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=0A
hello=EF=BC=8Ceveryone !
=0A
chengong 
=0A

=0A=0A=0A=0A=0A=0A= =0A   --0-1481866680-1271067791=:13839-- From david.borman@windriver.com Tue Apr 13 08:26:37 2010 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 E26E43A6359 for ; Tue, 13 Apr 2010 08:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 w-xU5XRycqrJ for ; Tue, 13 Apr 2010 08:26:35 -0700 (PDT) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 7F4F03A6807 for ; Tue, 13 Apr 2010 08:26:28 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id o3DFQIaW001603 for ; Tue, 13 Apr 2010 08:26:22 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Apr 2010 08:25:02 -0700 Received: from [172.25.44.3] ([172.25.44.3]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Apr 2010 08:25:01 -0700 From: David Borman Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Apr 2010 10:25:00 -0500 References: To: "tcpm@ietf.org WG" Message-Id: Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) X-OriginalArrivalTime: 13 Apr 2010 15:25:02.0079 (UTC) FILETIME=[7C61A8F0:01CADB1D] Subject: [tcpm] Fwd: WGLC for MSS 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: Tue, 13 Apr 2010 15:26:38 -0000 Sorry, I just realized that I only sent this reply to Alexander, and not = to the whole list. -David Borman Begin forwarded message: From: David Borman Date: March 31, 2010 11:03:53 AM CDT To: Alexander Zimmermann Subject: Re: [tcpm] WGLC for MSS document On Mar 31, 2010, at 7:27 AM, Alexander Zimmermann wrote: > Hi David, >=20 > I like the changes you have made. Especially, the history stuff you > added (Sec 3, Appendix) is quite interesting for "young" guys like me. >=20 > However, here are some remarks. Please note that these comments are > somehow trivia. If you don't like the changes, forget about them. What > I really do not want is to block the progress. >=20 > * Sec 2, para 2: I would add references for the TCP IPv4/6 > header lengths >=20 > * Appendix, last equation: I suggest to add the bounds into the = equation > 576 <=3D EMTU_R - FixedIPhdrsize - FixedTCPhdrsize <=3D MTU Actually, there is a different change that I think I should make: network(s)". Thus, the MSS value to be sent in an MSS option must be less than or equal to: EMTU_R - FixedIPhdrsize - FixedTCPhdrsize s/option must be/option should be/ It is not required that the MSS value be <=3D the MTU of the interface, = it is perfectly OK to advertise an MSS value larger than the MTU of the = interface. This is especially true for a multi-homed host with = interfaces that have different MTUs. However, deciding what MTU value = to use to calculate the MSS value is not the purpose of this RFC, the = purpose of this RFC is to say that when you calculate the MSS, you do = not adjust it to account for IP or TCP options. Getting into the = discussion about what MTU value to use is a rat-hole that is not part of = this RFC, so I don't even discuss it. That's why this version of the = document has the final sentence in section 2: The determination of what MTU value should be used, especially in the case of multi-homed hosts, is beyond the scope = of this document. This is also in the appendix, so it is just additional commentary that = may be useful to the reader, the requirements are in the main body of = the document. >=20 > * Sec 4: IHO the explanation of the table is too implicit. >=20 > In the following, let's name the fields of the table like this: upper = left 1, > upper right 2, lower left 3, lower right 4. >=20 > Right after the table, the draft said: >=20 > "Since the goal is to not send IP datagrams that have to be = fragmented, and > packets sent with the constraints in the lower right of this grid will = cause > IP fragmentation, the only way to guarantee that this doesn=92t happen = is for the > data sender to decrease the TCP data length by the size of the IP and = TCP options" >=20 > Having read this, the following comes to my mind: I'm sitting in (4) = and I want to > leave this state. The text said that only the transition to (2) is = possible. However, > when I looked at the table, I thought: I can also go to (3) since the = table said here > "Packets are the correct length". Bang! I got confused since the text = said, the > *only* way is (2). But why? At this point I expected an explanation = why (3) is a > bad idea? >=20 > Do you understand what I'm trying to say? Maybe I read the table = wrong. I read it > like a transition diagram. Should I read it line by line, column by = column,...? It isn't a state diagram, it's a grid showing the combinations of what = happens if the receiver does or doesn't adjust the MSS option to account = for options, and if the sender does or doesn't adjust to account for IP = options. The text says it all. If the sender doesn't adjust for the = options, then it can't be guaranteed that it won't generate packets that = are too big when it inserts options. So it should always adjust. And = since the sender is always adjusting, the receiver doesn't need to = modify the value in the MSS option to account for options. Does that make sense? -David >=20 >=20 > Alex >=20 > Am 25.03.2010 um 23:59 schrieb David Borman: >=20 >> On Aug 18, 2009, at 10:38 AM, Eddy, Wesley M. (GRC-MS00)[Verizon] = wrote: >>=20 >>> This note starts a 2-week Working Group Last Call on the TCPM = document: >>> http://tools.ietf.org/html/draft-ietf-tcpm-tcpmss-02 >>> Please send any comments to the TCPM list. The WGLC will last until >>> September 1. >>=20 >>=20 >> I've finally finished updating the MSS document, and have uploaded = it. >> http://tools.ietf.org/html/draft-ietf-tcpm-tcpmss-03 >> I believe I have addressed all the comments received during the Last = Call, and have done some additional changes beyond that. I've been = discussing the document this week at the IETF with several people, and = the results of those conversations are included in this new draft. >>=20 >> Because of the time lapse, and the number of changes that I've made = to the document, let's extend the >> WGLC to Thursday, April 8. >>=20 >> Below are my responses to all the comments received during the = original WGLC. >>=20 >> -David Borman >>=20 >>=20 >> On Aug 20, 2009, at 7:50 AM, Alexander Zimmermann wrote: >>=20 >>> 1. Needs boilerplate update (Copyright section) >>=20 >> Done. >>> 2. IMHO in line 50: %s/to do about TCP options/to do about IP and = TCP options/ >>=20 >> Done. >>> 3. Just one sentence later: "RFC-1122 [Braden89] attempted to = clarify this in section 4.2.2.6, but >>> there still seems to be confusion." What is the problem here with = RFC 1122? Why does RFC 1122 >>> does not manage to clarify the situation. I think one or two = sentence more explanation would be >>> great. >> I've removed "in section 4.2.2.6", and replaced it with a reference = to a new Appendix A that >> has a more complete description of what is in RFC 1122. >>=20 >>>=20 >>> Alex >>=20 >> On Aug 20, 2009, at 11:28 AM, Joe Touch wrote: >>=20 >> .... >>> I'd like to suggest the following for this doc: >>>=20 >>> MSSs can sometimes vary, as when used with variable compression, = e.g., >>> ROHC. The ROHC doc missed an opportunity to address the interaction = of >>> variable MSS with TCP, and this might be a good place to include a >>> sentence or two on it, e.g. (IMO): >>>=20 >>> - --- >>>=20 >>> MSSs can sometimes vary, as when used with variable compression, = e.g., >>> ROHC [RFC5255]. It is tempting for TCP to want to advertise the = largest >>> possible MSS, to support the most efficient use of compressed = payloads. >>> Unfortunately, some compression schemes occasionally need to = transmit >>> full headers (and thus smaller payloads) to resynchronize state at = their >>> endpoint compressor/decompressors. If the largest MSS is advertised, = TCP >>> retransmission may interfere with compressor resynchonization. >>>=20 >>> As a result, when effective MSS varies, TCP SHOULD compute its >>> advertised MSS based on the smallest effective MSS. >>>=20 >>> - --- >>>=20 >>> Joe >>=20 >> Added, with some rewording. >>=20 >>=20 >> On Aug 20, 2009, at 12:59 PM, = wrote: >>=20 >>> Can't TCP MSS also vary across multipath environments? Strikes me >>> that these are more common than header compression - which should >>> be advertising conservative minimum MTUs for their link interfaces. >>>=20 >>> >>>=20 >>=20 >> Ok, this one I've gone round and round on this, including adding an = entire Appendix to discuss issues of which MTU value to use for = calculating the MSS, the history of this, issues with multi-homed hosts, = non-symetric routes, and making multiple recommendations, based on the = context. In the end it felt like it was getting out of control, as one = thing lead to another and the Appendix was getting quite large. In the = end, I deleted the Appendix, and now have just one sentence: >>=20 >> The determination of what MTU value should be used, >> especially in the case of multihomed hosts, is beyond the scope = of >> this document. >>=20 >> This document is about clarifying that you don't include IP and TCP = options when figuring out what to put in the MSS option, it is not about = what MTU value to use when calculating the MSS option, so it is best to = just not go down that path at all. That's not to say that this isn't a = topic that deserves discussion, but that it isn't the purpose of this = document. >>=20 >> On Aug 26, 2009, at 6:56 AM, Mark Allman wrote: >>=20 >>> I am in general in favor of this document. But, this document is = sorta >>> confusing to me and so I'd vote "not ready" at the moment. =20 >>>=20 >>> The statement that the MSS advertisement should not include the = bytes >>> consumed by options is clear, but in the explanation of that rule. >>>=20 >>> + I had to work through the table to figure out "length" on the = y-axis >>> was the overall packet length. >>=20 >> Fixed. >>=20 >>> + I find it strange that the table is left as the sole justification >>> without even a little bit of prose that explains it. In fact, I >>> would think a little prose instead of the table would make the whole >>> thing more clear. >>>=20 >>> + The other thing you might note is that the MSS advertisement = cannot >>> possibly capture the right number of option bytes for every packet >>> in a connection because options are variable (e.g., SACK). So, even >>> if one tries to capture option lengths in the header the length will >>> still have to be hacked on the fly (or, you'll have to take a >>> pessimal view of option usage as "using all of it"). >>=20 >> I've added a paragraph that says that the MSS value, being fixed, can = never accurately reflect all situations of IP and TCP options, because = by their very nature they are variable. >>=20 >>=20 >> On Sep 3, 2009, at 7:37 AM, Danny McPherson wrote: >>=20 >>>=20 >>> I agree with Marks's comments - in general I like the document >>> (my colleague Aaron Campbell and I asked for and offered to write) >>> something similar quite a while back). >>>=20 >>> It is worth noting that the confusion isn't universal, at least, the >>> Linux, NetBSD, and OpenBSD people got it right (options are not >>> subtracted from the advertised MSS on these systems from our past >>> research). >>>=20 >>> RFC2385 is wrong, though: >> ... >> I've added a reference to this issue, and pointed out that RFC 2385 = is wrong. I've also added a reference to the issue with RFC-897, which = mostly got the definition correct until the very last section of the = document... :-) >>=20 >> -David >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 From dab@weston.borman.com Tue Apr 13 08:44:00 2010 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 8F1C73A6B2A for ; Tue, 13 Apr 2010 08:44:00 -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 vkrK6GFLo0mx for ; Tue, 13 Apr 2010 08:43:56 -0700 (PDT) Received: from frantic.weston.borman.com (frantic-dmz.weston.borman.com [206.196.54.22]) by core3.amsl.com (Postfix) with ESMTP id 6FCC73A6B24 for ; Tue, 13 Apr 2010 08:43:52 -0700 (PDT) Received: from [172.25.44.3] (weston-43.weston.borman.com [206.196.45.43]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id o3DFhfCk005490; Tue, 13 Apr 2010 10:43:42 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: David Borman In-Reply-To: Date: Tue, 13 Apr 2010 10:43:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Joe Touch , L.Wood@surrey.ac.uk, Mark Allman , Danny McPherson , Alexander Zimmermann X-Mailer: Apple Mail (2.1078) Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] WGLC for MSS 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: Tue, 13 Apr 2010 15:44:00 -0000 Hi, I'd appreciate it of those on the To: list of this message, who made = comments on the previous version of the MSS document, could reply to the = mailing list whether or not you feel your comments are adequately = addressed, so that we have a record of consensus. Thanks. -David Borman On Mar 25, 2010, at 5:59 PM, David Borman wrote: > On Aug 18, 2009, at 10:38 AM, Eddy, Wesley M. (GRC-MS00)[Verizon] = wrote: >=20 >> This note starts a 2-week Working Group Last Call on the TCPM = document: >> http://tools.ietf.org/html/draft-ietf-tcpm-tcpmss-02 >> Please send any comments to the TCPM list. The WGLC will last until >> September 1. >=20 >=20 > I've finally finished updating the MSS document, and have uploaded it. > http://tools.ietf.org/html/draft-ietf-tcpm-tcpmss-03 > I believe I have addressed all the comments received during the Last = Call, and have done some additional changes beyond that. I've been = discussing the document this week at the IETF with several people, and = the results of those conversations are included in this new draft. >=20 > Because of the time lapse, and the number of changes that I've made to = the document, let's extend the > WGLC to Thursday, April 8. >=20 > Below are my responses to all the comments received during the = original WGLC. >=20 > -David Borman >=20 >=20 > On Aug 20, 2009, at 7:50 AM, Alexander Zimmermann wrote: >=20 >> 1. Needs boilerplate update (Copyright section) >=20 > Done. >> 2. IMHO in line 50: %s/to do about TCP options/to do about IP and TCP = options/ >=20 > Done. >> 3. Just one sentence later: "RFC-1122 [Braden89] attempted to clarify = this in section 4.2.2.6, but >> there still seems to be confusion." What is the problem here with RFC = 1122? Why does RFC 1122 >> does not manage to clarify the situation. I think one or two sentence = more explanation would be >> great. > I've removed "in section 4.2.2.6", and replaced it with a reference to = a new Appendix A that > has a more complete description of what is in RFC 1122. >=20 >>=20 >> Alex >=20 > On Aug 20, 2009, at 11:28 AM, Joe Touch wrote: >=20 > .... >> I'd like to suggest the following for this doc: >>=20 >> MSSs can sometimes vary, as when used with variable compression, = e.g., >> ROHC. The ROHC doc missed an opportunity to address the interaction = of >> variable MSS with TCP, and this might be a good place to include a >> sentence or two on it, e.g. (IMO): >>=20 >> - --- >>=20 >> MSSs can sometimes vary, as when used with variable compression, = e.g., >> ROHC [RFC5255]. It is tempting for TCP to want to advertise the = largest >> possible MSS, to support the most efficient use of compressed = payloads. >> Unfortunately, some compression schemes occasionally need to transmit >> full headers (and thus smaller payloads) to resynchronize state at = their >> endpoint compressor/decompressors. If the largest MSS is advertised, = TCP >> retransmission may interfere with compressor resynchonization. >>=20 >> As a result, when effective MSS varies, TCP SHOULD compute its >> advertised MSS based on the smallest effective MSS. >>=20 >> - --- >>=20 >> Joe >=20 > Added, with some rewording. >=20 >=20 > On Aug 20, 2009, at 12:59 PM, = wrote: >=20 >> Can't TCP MSS also vary across multipath environments? Strikes me >> that these are more common than header compression - which should >> be advertising conservative minimum MTUs for their link interfaces. >>=20 >> >>=20 >=20 > Ok, this one I've gone round and round on this, including adding an = entire Appendix to discuss issues of which MTU value to use for = calculating the MSS, the history of this, issues with multi-homed hosts, = non-symetric routes, and making multiple recommendations, based on the = context. In the end it felt like it was getting out of control, as one = thing lead to another and the Appendix was getting quite large. In the = end, I deleted the Appendix, and now have just one sentence: >=20 > The determination of what MTU value should be used, > especially in the case of multihomed hosts, is beyond the scope = of > this document. >=20 > This document is about clarifying that you don't include IP and TCP = options when figuring out what to put in the MSS option, it is not about = what MTU value to use when calculating the MSS option, so it is best to = just not go down that path at all. That's not to say that this isn't a = topic that deserves discussion, but that it isn't the purpose of this = document. >=20 > On Aug 26, 2009, at 6:56 AM, Mark Allman wrote: >=20 >> I am in general in favor of this document. But, this document is = sorta >> confusing to me and so I'd vote "not ready" at the moment. =20 >>=20 >> The statement that the MSS advertisement should not include the bytes >> consumed by options is clear, but in the explanation of that rule. >>=20 >> + I had to work through the table to figure out "length" on the = y-axis >> was the overall packet length. >=20 > Fixed. >=20 >> + I find it strange that the table is left as the sole justification >> without even a little bit of prose that explains it. In fact, I >> would think a little prose instead of the table would make the = whole >> thing more clear. >>=20 >> + The other thing you might note is that the MSS advertisement cannot >> possibly capture the right number of option bytes for every packet >> in a connection because options are variable (e.g., SACK). So, = even >> if one tries to capture option lengths in the header the length = will >> still have to be hacked on the fly (or, you'll have to take a >> pessimal view of option usage as "using all of it"). >=20 > I've added a paragraph that says that the MSS value, being fixed, can = never accurately reflect all situations of IP and TCP options, because = by their very nature they are variable. >=20 >=20 > On Sep 3, 2009, at 7:37 AM, Danny McPherson wrote: >=20 >>=20 >> I agree with Marks's comments - in general I like the document >> (my colleague Aaron Campbell and I asked for and offered to write) >> something similar quite a while back). >>=20 >> It is worth noting that the confusion isn't universal, at least, the >> Linux, NetBSD, and OpenBSD people got it right (options are not >> subtracted from the advertised MSS on these systems from our past >> research). >>=20 >> RFC2385 is wrong, though: > ... > I've added a reference to this issue, and pointed out that RFC 2385 is = wrong. I've also added a reference to the issue with RFC-897, which = mostly got the definition correct until the very last section of the = document... :-) >=20 > -David > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From wesley.m.eddy@nasa.gov Tue Apr 13 13:37:35 2010 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 734993A6A49 for ; Tue, 13 Apr 2010 13:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 1AzO9G6Iu6FD for ; Tue, 13 Apr 2010 13:37:34 -0700 (PDT) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id 9C27E28C176 for ; Tue, 13 Apr 2010 13:37:33 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id D5026A8370 for ; Tue, 13 Apr 2010 15:37:27 -0500 (CDT) Received: from ndjshub03.ndc.nasa.gov (ndjshub03-pub.ndc.nasa.gov [198.117.1.33]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o3DKbRtt025151 for ; Tue, 13 Apr 2010 15:37:27 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Tue, 13 Apr 2010 15:37:27 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Tue, 13 Apr 2010 15:37:23 -0500 Thread-Topic: WGLC for LCD document Thread-Index: AcrbSR9SHm/3R90qSROVDOSrO0j7Sw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AnCD BYgA Bjvg BlP/ DK3A D1Ww EDZQ FHv6 GQGE G9Iq HTo3 H+Ny IhCo JqS9 Jvmk K2fU; 1; dABjAHAAbQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {FA00016B-8D78-4EA8-AB16-44C3A66A5F86}; dwBlAHMAbABlAHkALgBtAC4AZQBkAGQAeQBAAG4AYQBzAGEALgBnAG8AdgA=; Tue, 13 Apr 2010 20:37:23 GMT;VwBHAEwAQwAgAGYAbwByACAATABDAEQAIABkAG8AYwB1AG0AZQBuAHQA x-cr-puzzleid: {FA00016B-8D78-4EA8-AB16-44C3A66A5F86} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-13_07:2010-02-06, 2010-04-13, 2010-04-13 signatures=0 Subject: [tcpm] WGLC for LCD 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: Tue, 13 Apr 2010 20:37:35 -0000 This email starts a working group last call in TCPM for the document on making TCP more robust to long connectivity disruptions: http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-lcd/ As discussed at IETF 77, this has been stable for a while, and is believed to be complete, aside from checking on how SYNs are handled and making this clear, as Mark Handley raised. This WGLC is planned to last for 2 weeks, and end on April 28. Please send your comments on this document to the TCPM list. -- Wes Eddy MTI Systems From Alexander.Zimmermann@nets.rwth-aachen.de Wed Apr 14 00:32:05 2010 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 3A6953A6950 for ; Wed, 14 Apr 2010 00:32:05 -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 V6wW32gPXbRH for ; Wed, 14 Apr 2010 00:32:04 -0700 (PDT) Received: from mail-i4.informatik.rwth-aachen.de (mail-i4.informatik.RWTH-Aachen.DE [137.226.12.21]) by core3.amsl.com (Postfix) with ESMTP id EF79A3A694E for ; Wed, 14 Apr 2010 00:32:02 -0700 (PDT) Received: from messenger.nets.rwth-aachen.de (messenger.nets.rwth-aachen.de [137.226.13.40]) by mail-i4.informatik.rwth-aachen.de (Postfix) with ESMTP id E9FA057899; Wed, 14 Apr 2010 09:31:55 +0200 (CEST) Received: from MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28]) by MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28%14]) with mapi; Wed, 14 Apr 2010 09:31:29 +0200 From: Alexander Zimmermann To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" Thread-Topic: [tcpm] WGLC for LCD document Thread-Index: AQHK26R/9xBJSGmONkeQgJdFQAlRdA== Date: Wed, 14 Apr 2010 07:31:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <12782171-d8ec-43d7-bf5d-4dcf2c851af7> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WGLC for LCD 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: Wed, 14 Apr 2010 07:32:05 -0000 Hi all, Am 13.04.2010 um 22:37 schrieb Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CO= RP]: > This email starts a working group last call in TCPM for the > document on making TCP more robust to long connectivity > disruptions: >=20 > http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-lcd/ >=20 > As discussed at IETF 77, this has been stable for a while, and > is believed to be complete, aside from checking on how SYNs are > handled and making this clear, as Mark Handley raised. Copied from the draft: A.1. Changes from draft-ietf-tcpm-tcp-lcd-00 o Editorial changes. o Clarified TCP-LCD's behaviour during connection establishment (Thanks to Mark Handley). So, all is done :-) >=20 > This WGLC is planned to last for 2 weeks, and end on April 28. > Please send your comments on this document to the TCPM list. >=20 >=20 > -- > Wes Eddy > MTI Systems >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From wesley.m.eddy@nasa.gov Wed Apr 14 06:25:28 2010 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 DA1603A6B0D for ; Wed, 14 Apr 2010 06:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 HG74-dxgoybs for ; Wed, 14 Apr 2010 06:25:28 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id 1FA2A28C25F for ; Wed, 14 Apr 2010 06:21:53 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id D6325261052 for ; Wed, 14 Apr 2010 08:21:42 -0500 (CDT) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o3EDLg2Q032315 for ; Wed, 14 Apr 2010 08:21:42 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Wed, 14 Apr 2010 08:21:42 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Wed, 14 Apr 2010 08:21:41 -0500 Thread-Topic: poll for adoption of draft-ananth-persist-02 Thread-Index: Acq++HhKPa/WNfamRcGprqSmMXJeBgc3B4fw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-14_09:2010-02-06, 2010-04-14, 2010-04-14 signatures=0 Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 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, 14 Apr 2010 13:25:29 -0000 After reviewing this mailing list thread and the IETF 77 discussion, David and I think there's support to make this a working group document. As we see it, the path to take toward publication is: 1) authors submit a draft-ietf-tcpm version of the document 2) authors need to come to closure with several people who disagree with specification of a new socket option; this seems to be the main point of contention 3) issue a WGLC once consensus is determined for the socket option issue -- Wes Eddy MTI Systems >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] >Sent: Monday, March 08, 2010 2:50 PM >To: tcpm@ietf.org >Subject: [tcpm] poll for adoption of draft-ananth-persist-02 > >The authors have updated draft-ananth-persist, and asked >us to poll the TCPM WG to have this particular document >adopted with an Informational target. > >http://www.ietf.org/id/draft-ananth-tcpm-persist-02.txt > >This has been discussed to some extent on the mailing >list and at the Dublin meeting. The authors have >responded to comments received thus far and updated the >document as it grew from the outcome of prior feedback >on the draft-mahesh-persist-timeout document. > >Please respond if you either: > >(1) Support making this document a WG document with the > target for Informational. > >(2) Oppose making this document a WG document. > >Of course, other comments are also welcome :). > >It's relatively short, so if people could respond in the >next 2 weeks, this would allow us to determine consensus >during the week of the IETF meeting. > >-- >Wes Eddy >MTI Systems > > >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm From christos@zoulas.com Wed Apr 14 07:37:24 2010 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 193AB3A67BD for ; Wed, 14 Apr 2010 07:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 D2NManUwxRjP for ; Wed, 14 Apr 2010 07:37:23 -0700 (PDT) Received: from rebar.astron.com (rebar.astron.com [38.117.134.202]) by core3.amsl.com (Postfix) with ESMTP id B4CA33A6851 for ; Wed, 14 Apr 2010 07:37:19 -0700 (PDT) Received: by rebar.astron.com (Postfix, from userid 10080) id 00DE956425; Wed, 14 Apr 2010 10:37:12 -0400 (EDT) From: christos@zoulas.com (Christos Zoulas) Date: Wed, 14 Apr 2010 10:37:12 -0400 In-Reply-To: from "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" (Apr 14, 8:21am) Organization: Astron Software X-Mailer: Mail User's Shell (7.2.6 beta(4.pl1)+dynamic 20000103) To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , "tcpm@ietf.org" Message-Id: <20100414143713.00DE956425@rebar.astron.com> Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 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, 14 Apr 2010 14:37:24 -0000 On Apr 14, 8:21am, wesley.m.eddy@nasa.gov ("Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]") wrote: -- Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 | After reviewing this mailing list thread and the IETF 77 | discussion, David and I think there's support to make | this a working group document. | | As we see it, the path to take toward publication is: | | 1) authors submit a draft-ietf-tcpm version of the document | 2) authors need to come to closure with several people who | disagree with specification of a new socket option; this | seems to be the main point of contention | 3) issue a WGLC once consensus is determined for the socket | option issue - Shouldn't the variable be called something like SO_PERSISTTIMEO to follow suit with existing options and be in the proper namespace? - Shouldn't the type of the persist_timeout_value be mentioned (again presumably either int or struct timeval, again to follow convention) as well if "int" is chosen the units (seconds)? - There should also be a getsockopt(2) for this (for symmetry). - Are there any existing implementations for this, and if so do they use one of the existing timers, or does this need a new one? Best, christos From ananth@cisco.com Wed Apr 14 08:32:26 2010 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 0F44728C1E3 for ; Wed, 14 Apr 2010 08:32:26 -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=[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 phlm8tdI15kz for ; Wed, 14 Apr 2010 08:32:25 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8ED1228C1EF for ; Wed, 14 Apr 2010 08:32:24 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM58xUurR7Ht/2dsb2JhbACbVnGjV5luhQ0Egyk X-IronPort-AV: E=Sophos;i="4.52,205,1270425600"; d="scan'208";a="514867708" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2010 15:32:18 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3EFWIHq029440; Wed, 14 Apr 2010 15:32:18 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.3959); Wed, 14 Apr 2010 08:32:18 -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: Wed, 14 Apr 2010 08:32:17 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5809605EAA@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] poll for adoption of draft-ananth-persist-02 Thread-Index: Acq++HhKPa/WNfamRcGprqSmMXJeBgc3B4fwAARMR6A= References: From: "Anantha Ramaiah (ananth)" To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , X-OriginalArrivalTime: 14 Apr 2010 15:32:18.0523 (UTC) FILETIME=[AAEF7AB0:01CADBE7] Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 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, 14 Apr 2010 15:32:26 -0000 Wes,=20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] > Sent: Wednesday, April 14, 2010 6:22 AM > To: tcpm@ietf.org > Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 >=20 > After reviewing this mailing list thread and the IETF 77=20 > discussion, David and I think there's support to make this a=20 > working group document. >=20 > As we see it, the path to take toward publication is: >=20 > 1) authors submit a draft-ietf-tcpm version of the document Should we re-submit the draft-ietf version taking into incorporating all the comments we have received so far + new boiler plate etc.,?=20 > 2) authors need to come to closure with several people who > disagree with specification of a new socket option; this > seems to be the main point of contention Ok, there seems to be some confusion caused with the purpose of socket option and the references to SO_LINGER etc., I think we need to get closure on this issue. We (authors) discussed these responses and we agree that if there is enough guidance that already exists to support the implementers, then there is no need to invent any new socket option and just mention the existing tools. OTOH, if currently there are no ways to make things work reliably, we think that it is not a bad idea to give some examples in the appendix (after all it is an informational document and we are not changing ANY standard here, so I personally see no conflict of interest here). The key is to give a guidance (or at the least an example) to implementers and we think it is within the scope of the informational document. That is the reason to mention the socket option etc., in the first place. That said, we will work with the folks who have had concerns and see if we are on the same page w.r.t their thoughts. This is a pending action from our side. > 3) issue a WGLC once consensus is determined for the socket > option issue Sounds good to me. Thanks, -Anantha >=20 From wesley.m.eddy@nasa.gov Wed Apr 14 08:36:39 2010 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 24F1F3A6973 for ; Wed, 14 Apr 2010 08:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 fbK0qkJC7FMi for ; Wed, 14 Apr 2010 08:36:38 -0700 (PDT) Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by core3.amsl.com (Postfix) with ESMTP id 374023A68B9 for ; Wed, 14 Apr 2010 08:36:38 -0700 (PDT) Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 1CB992D8535; Wed, 14 Apr 2010 10:36:32 -0500 (CDT) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt04.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o3EFaVxY001637; Wed, 14 Apr 2010 10:36:31 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Wed, 14 Apr 2010 10:36:31 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "Anantha Ramaiah (ananth)" , "tcpm@ietf.org" Date: Wed, 14 Apr 2010 10:36:30 -0500 Thread-Topic: [tcpm] poll for adoption of draft-ananth-persist-02 Thread-Index: Acq++HhKPa/WNfamRcGprqSmMXJeBgc3B4fwAARMR6AAAILj8A== Message-ID: References: <0C53DCFB700D144284A584F54711EC5809605EAA@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5809605EAA@xmb-sjc-21c.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-14_12:2010-02-06, 2010-04-14, 2010-04-14 signatures=0 Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 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, 14 Apr 2010 15:36:39 -0000 >-----Original Message----- >From: Anantha Ramaiah (ananth) [mailto:ananth@cisco.com] >Sent: Wednesday, April 14, 2010 11:32 AM >To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; tcpm@ietf.org >Subject: RE: [tcpm] poll for adoption of draft-ananth-persist-02 > >Wes, > >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >> Behalf Of Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] >> Sent: Wednesday, April 14, 2010 6:22 AM >> To: tcpm@ietf.org >> Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 >> >> After reviewing this mailing list thread and the IETF 77 >> discussion, David and I think there's support to make this a >> working group document. >> >> As we see it, the path to take toward publication is: >> >> 1) authors submit a draft-ietf-tcpm version of the document > >Should we re-submit the draft-ietf version taking into incorporating all >the comments we have received so far + new boiler plate etc.,? > Yes, and in the meantime, keep the discussion open on the socket option. If it converges in time for the resolution to be included in the updated WG document, that would be good, but not strictly necessary. We would like to come to consensus on that before making a WGLC though. -- Wes Eddy MTI Systems From wesley.m.eddy@nasa.gov Thu Apr 15 13:31:59 2010 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 7DFA83A6801 for ; Thu, 15 Apr 2010 13:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 aBbmm7mUBNXI for ; Thu, 15 Apr 2010 13:31:58 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id 62B223A699D for ; Thu, 15 Apr 2010 13:30:16 -0700 (PDT) Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 5709F2C8136 for ; Thu, 15 Apr 2010 15:30:09 -0500 (CDT) Received: from ndjshub03.ndc.nasa.gov (ndjshub03-pub.ndc.nasa.gov [198.117.1.33]) by ndjsppt04.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o3FKU6H8003978 for ; Thu, 15 Apr 2010 15:30:08 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Thu, 15 Apr 2010 15:30:07 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Thu, 15 Apr 2010 15:30:06 -0500 Thread-Topic: WG status for 4/15/2010 Thread-Index: Acrc2m+lCume96F/Qo+p2SMME58q8Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-15_11:2010-02-06, 2010-04-15, 2010-04-15 signatures=0 Subject: [tcpm] WG status for 4/15/2010 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, 15 Apr 2010 20:31:59 -0000 Hello TCPMers, below is a snapshot of the WG status as of this week. There are a few updates following the IETF 77 meeting. We're up to 4 documents in the RFC Editor queue, 1 ready to go to the IESG, 2 more in WGLC, and there are a couple getting close to ready for WGLC. Then there are a number of them that we need to look at and check consensus on whether they should become WG documents or not, particularly the NewReno proposed modification has been floating around for awhile, and hasn't had much feedback lately. If people can focus on the two in WGLC and on the NewReno proposal, I think that would be healthy for progress. Also, there are draft notes from IETF 77 (thanks to Jamshid and Matt for taking notes, any errors are probably mine in merging them!). Vetting these would also be helpful: http://www.ietf.org/proceedings/10mar/minutes/tcpm.txt WG Items Nearing RFC Publication =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 Early-Retransmit http://www.ietf.org/id/draft-ietf-tcpm-early-rexmt-04.txt Milestone Target: Experimental in July 2009 Status: In RFC Editor's queue Action: None in TCPM ICMP Attacks http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-11.txt Milestone Target: Informational in July 2009 Status: finished IETF LC, with IESG Action: None in TCPM TCP Authentication Option http://www.ietf.org/id/draft-ietf-tcpm-tcp-auth-opt-10.txt Milestone Target: Proposed Standard in April 2009 Status: In RFC Editor's queue Action: None in TCPM TCP Authentication Option Crypto http://www.ietf.org/id/draft-ietf-tcpm-tcp-ao-crypto-01.txt Milestone Target: Proposed Standard with AO spec Status: In RFC Editor's queue Action: None in TCPM WG Items in WGLC or being revised after WGLC =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=3D=3D=3D Urgent Pointer http://www.ietf.org/id/draft-ietf-tcpm-urgent-data-05.txt Milestone Target: Proposed Standard in January 2010 Status: updated after WGLC Action: chairs (David) writing PROTO for sending to IESG MSS Option http://www.ietf.org/id/draft-ietf-tcpm-tcpmss-02.txt 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 will write PROTO and send to the IESG, after WGLC completes Long Connectivity Disruptions http://www.ietf.org/id/draft-ietf-tcpm-tcp-lcd-00.txt (need to submit WG version) Milestone Target: Experimental in October 2010 Status: In WGLC Action: WGLC to last 2 weeks, started on 4/13 Active WG Items =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1323bis http://www.ietf.org/id/draft-ietf-tcpm-1323bis-01.txt Milestone Target: Proposed Standard in July 2009 Status: Needs revision Action: Revise & WGLC (action with D. Borman) TCP Security http://www.ietf.org/id/draft-ietf-tcpm-tcp-security-01.txt Milestone Target: BCP in August 2010 Status: outline discussion dying off? content needs work Action: 00-draft / outline has been under active discussion; but not attain= ed very clear consensus WG has begun working on recommendations while still looking for a possible compromise on outline (action with Fernando Gont) progress on recommendations made at IETF 77 needs to be worked into the next version of draft (D. Borman to work w/ Fernando) SACK Entry http://www.ietf.org/id/draft-ietf-tcpm-sack-recovery-entry-01.txt Milestone Target: Proposed Standard in October 2010 Action: need WG to read/discuss TBD how this relates to 3517, and if it will update it; authors are to determine how much additional time this might take as a bis document versus standalone Clarification of sender behavior in persist condition http://tools.ietf.org/id/draft-ananth-tcpm-persist-01.txt Status: discussed on mailing list and in face-to-face meetings Action: authors to submit WG version WG determine what to do with socket option section then WGLC Documents Under a Poll to Become WG Items =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 Timestamps http://tools.ietf.org/id/draft-gont-tcpm-tcp-timestamps-01.txt Status: consensus to work on some portions of this, possibly as a part of t= he 1323bis document Action: need to determine if the accepted portions can be worked into 1323b= is Other Proposals Not Yet Decided On =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 NewReno Modification http://www.ietf.org/internet-drafts/draft-nishida-newreno-modification-01.t= xt Action: need WG to read/discuss presentation given, document updated, but WG list not yet polled fo= r adoption AO NAT http://www.ietf.org/internet-drafts/draft-touch-tcp-ao-nat-00.txt Status: IETF 77 discussion determined this should be Experimental, whether = or not it is a WG document; need to ask TCPM list Action: need to poll mailing list about path forward Increasing TCP's Initial Window http://tools.ietf.org/html/draft-hkchu-tcpm-initcwnd-00 Status: presented in Anaheim; lots of interest need to keep discussing; the work is in verifying that this is a go= od idea, moreso than documenting the change Action: WG to continue to discuss Computing TCP's Retransmission Timer http://tools.ietf.org/id/draft-paxson-tcpm-rfc2988bis-00.txt Status: presented briefly at IETF 77, also well-discussed on mailing list earlier and at IETF 75 Action: need to poll for becoming a WG document Older & Expired Documents Discussed =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 discussions on Rate-Halving http://tools.ietf.org/id/draft-mathis-tcp-ratehalving-00.txt 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-01 Status: expired; not specifically polled for adoption in WG Documents Not Adopted by WG =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 TCP Option for Transparent Middlebox Discovery http://www.ietf.org/id/draft-knutsen-tcpm-middlebox-discovery-03.txt 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 Other WG Activities =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Errata Review for legacy TCP RFCs: RFC0793 (1496) 3.9 Technical Legacy Yin Shuming 2008-08-27 RFC0793 (1561) 3.2 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1562) 3.3 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1563) 3.4 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1564) 3.7 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1565) 3.8 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1566) 3.9 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1567) 3.9 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1568) 3.9 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1569) 2.4 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1570) 2.7 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1571) 3.1 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1572) 3.4 Technical Legacy Constantin Hagemeier 2008-10-11 -- Wes Eddy MTI Systems From fernando.gont.netbook.win@gmail.com Thu Apr 15 14:37:17 2010 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 720AE3A6988 for ; Thu, 15 Apr 2010 14:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 7N1BAqnOjoxT for ; Thu, 15 Apr 2010 14:37:16 -0700 (PDT) Received: from mail-gy0-f194.google.com (mail-gy0-f194.google.com [209.85.160.194]) by core3.amsl.com (Postfix) with ESMTP id F0FB03A6A91 for ; Thu, 15 Apr 2010 14:36:49 -0700 (PDT) Received: by gyg8 with SMTP id 8so70014gyg.1 for ; Thu, 15 Apr 2010 14:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=Yh89Ov65RF4iSFU6byx0eK9vw4mcqdKdGCXjjpWhq3Q=; b=ZZitlLBfKF/ZLBlZAo6iE1wlXtz6D53bqjfIvoGPgJVdof3h0oUwI7TlO7yrheWQ5I VKUwMUDL+88PWAqeSBal1dSb3LrdNPOZfLlGMbMIY32ONo64JdYvlmlYNtwSff3CVI3S 6nfedlBmlq5zCmPKy2z3gSXAZIYZFgEIVQn8o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=MKBWvpmLl1yM3HHojZIj3gFMprmmfd3G1ErGY4XrQP5l1P+6DduljYV7Cl38Q3Tf6O lMiM4XWKKn2lWGXZPrYY5qenZyUtOTndydqtrlnG8Fw8CRn5Sditxm6ATrWo+eGWooJP /8RiqegIHEkfP5aKSjxBZ0WxlMn6bSOh3cGUo= Received: by 10.101.178.8 with SMTP id f8mr1370085anp.179.1271367400342; Thu, 15 Apr 2010 14:36:40 -0700 (PDT) Received: from [192.168.0.124] (129-130-17-190.fibertel.com.ar [190.17.130.129]) by mx.google.com with ESMTPS id 22sm5206143anz.18.2010.04.15.14.36.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 15 Apr 2010 14:36:39 -0700 (PDT) Sender: Fernando Gont Message-ID: <4BC786D8.6060407@gont.com.ar> Date: Thu, 15 Apr 2010 18:36:24 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" References: In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG status for 4/15/2010 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, 15 Apr 2010 21:37:17 -0000 Hi, Wes, Two small comments.... > ICMP Attacks > http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-11.txt > Milestone Target: Informational in July 2009 > Status: finished IETF LC, with IESG > Action: None in TCPM ICMP attacks has already been approved by the IESG. It's in the RFC Editor's queue. > Documents Under a Poll to Become WG Items > ========================================= > > Timestamps > http://tools.ietf.org/id/draft-gont-tcpm-tcp-timestamps-01.txt > Status: consensus to work on some portions of this, possibly as a part of the > 1323bis document > Action: need to determine if the accepted portions can be worked into 1323bis I think the idea is to publish a stand alone document that could be published "soon". rfc1323bis could certainly pick that stuff at anytime.... Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nishida@sfc.wide.ad.jp Thu Apr 15 17:48:58 2010 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 1452C3A68EB for ; Thu, 15 Apr 2010 17:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.204 X-Spam-Level: ** X-Spam-Status: No, score=2.204 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] 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 xv9XjCkTSeiW for ; Thu, 15 Apr 2010 17:48:56 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id B7CFD3A684D for ; Thu, 15 Apr 2010 17:48:54 -0700 (PDT) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 728E24C0CC; Fri, 16 Apr 2010 09:48:43 +0900 (JST) Date: Fri, 16 Apr 2010 09:48:43 +0900 (JST) Message-Id: <20100416.094843.13723382.nishida@sfc.wide.ad.jp> To: tcpm@ietf.org From: Yoshifumi Nishida In-Reply-To: References: X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] WG status for 4/15/2010 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, 16 Apr 2010 00:48:58 -0000 Hello Eddy, Thank you so much. Just a small correction.. > NewReno Modification > http://www.ietf.org/internet-drafts/draft-nishida-newreno-modification-01.txt > Action: need WG to read/discuss > presentation given, document updated, but WG list not yet polled for adoption > Please use the following link http://www.ietf.org/internet-drafts/draft-nishida-newreno-modification-02.txt Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" Subject: [tcpm] WG status for 4/15/2010 Date: Thu, 15 Apr 2010 15:30:06 -0500 Message-ID: > Hello TCPMers, below is a snapshot of the WG status as of > this week. There are a few updates following the IETF 77 > meeting. We're up to 4 documents in the RFC Editor queue, > 1 ready to go to the IESG, 2 more in WGLC, and there are a > couple getting close to ready for WGLC. Then there are a > number of them that we need to look at and check consensus > on whether they should become WG documents or not, > particularly the NewReno proposed modification has been > floating around for awhile, and hasn't had much feedback > lately. If people can focus on the two in WGLC and on the > NewReno proposal, I think that would be healthy for progress. > > Also, there are draft notes from IETF 77 (thanks to Jamshid > and Matt for taking notes, any errors are probably mine in > merging them!). Vetting these would also be helpful: > http://www.ietf.org/proceedings/10mar/minutes/tcpm.txt > > > > WG Items Nearing RFC Publication > ================================ > > Early-Retransmit > http://www.ietf.org/id/draft-ietf-tcpm-early-rexmt-04.txt > Milestone Target: Experimental in July 2009 > Status: In RFC Editor's queue > Action: None in TCPM > > ICMP Attacks > http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-11.txt > Milestone Target: Informational in July 2009 > Status: finished IETF LC, with IESG > Action: None in TCPM > > TCP Authentication Option > http://www.ietf.org/id/draft-ietf-tcpm-tcp-auth-opt-10.txt > Milestone Target: Proposed Standard in April 2009 > Status: In RFC Editor's queue > Action: None in TCPM > > TCP Authentication Option Crypto > http://www.ietf.org/id/draft-ietf-tcpm-tcp-ao-crypto-01.txt > Milestone Target: Proposed Standard with AO spec > Status: In RFC Editor's queue > Action: None in TCPM > > > > WG Items in WGLC or being revised after WGLC > ============================================ > > Urgent Pointer > http://www.ietf.org/id/draft-ietf-tcpm-urgent-data-05.txt > Milestone Target: Proposed Standard in January 2010 > Status: updated after WGLC > Action: chairs (David) writing PROTO for sending to IESG > > MSS Option > http://www.ietf.org/id/draft-ietf-tcpm-tcpmss-02.txt > 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 will write PROTO and send to the IESG, after WGLC > completes > > Long Connectivity Disruptions > http://www.ietf.org/id/draft-ietf-tcpm-tcp-lcd-00.txt > (need to submit WG version) > Milestone Target: Experimental in October 2010 > Status: In WGLC > Action: WGLC to last 2 weeks, started on 4/13 > > > Active WG Items > =============== > > 1323bis > http://www.ietf.org/id/draft-ietf-tcpm-1323bis-01.txt > Milestone Target: Proposed Standard in July 2009 > Status: Needs revision > Action: Revise & WGLC (action with D. Borman) > > TCP Security > http://www.ietf.org/id/draft-ietf-tcpm-tcp-security-01.txt > Milestone Target: BCP in August 2010 > Status: outline discussion dying off? content needs work > Action: 00-draft / outline has been under active discussion; but not attained > very clear consensus > WG has begun working on recommendations while still looking for a > possible compromise on outline (action with Fernando Gont) > progress on recommendations made at IETF 77 needs to be worked into > the next version of draft (D. Borman to work w/ Fernando) > > SACK Entry > http://www.ietf.org/id/draft-ietf-tcpm-sack-recovery-entry-01.txt > Milestone Target: Proposed Standard in October 2010 > Action: need WG to read/discuss > TBD how this relates to 3517, and if it will update it; authors are > to determine how much additional time this might take as a bis > document versus standalone > > Clarification of sender behavior in persist condition > http://tools.ietf.org/id/draft-ananth-tcpm-persist-01.txt > Status: discussed on mailing list and in face-to-face meetings > Action: authors to submit WG version > WG determine what to do with socket option section > then WGLC > > > Documents Under a Poll to Become WG Items > ========================================= > > Timestamps > http://tools.ietf.org/id/draft-gont-tcpm-tcp-timestamps-01.txt > Status: consensus to work on some portions of this, possibly as a part of the > 1323bis document > Action: need to determine if the accepted portions can be worked into 1323bis > > > Other Proposals Not Yet Decided On > ================================== > > NewReno Modification > http://www.ietf.org/internet-drafts/draft-nishida-newreno-modification-01.txt > Action: need WG to read/discuss > presentation given, document updated, but WG list not yet polled for adoption > > AO NAT > http://www.ietf.org/internet-drafts/draft-touch-tcp-ao-nat-00.txt > Status: IETF 77 discussion determined this should be Experimental, whether or > not it is a WG document; need to ask TCPM list > Action: need to poll mailing list about path forward > > Increasing TCP's Initial Window > http://tools.ietf.org/html/draft-hkchu-tcpm-initcwnd-00 > Status: presented in Anaheim; lots of interest > need to keep discussing; the work is in verifying that this is a good > idea, moreso than documenting the change > Action: WG to continue to discuss > > Computing TCP's Retransmission Timer > http://tools.ietf.org/id/draft-paxson-tcpm-rfc2988bis-00.txt > Status: presented briefly at IETF 77, also well-discussed on mailing list > earlier and at IETF 75 > Action: need to poll for becoming a WG document > > > Older & Expired Documents Discussed > =================================== > > discussions on Rate-Halving > http://tools.ietf.org/id/draft-mathis-tcp-ratehalving-00.txt > 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-01 > Status: expired; not specifically polled for adoption in WG > > > Documents Not Adopted by WG > =========================== > > TCP Option for Transparent Middlebox Discovery > http://www.ietf.org/id/draft-knutsen-tcpm-middlebox-discovery-03.txt > 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 > > > > Other WG Activities > =================== > > Errata Review for legacy TCP RFCs: > > RFC0793 (1496) 3.9 Technical Legacy Yin Shuming 2008-08-27 > RFC0793 (1561) 3.2 Technical Legacy Constantin Hagemeier 2008-10-11 > RFC0793 (1562) 3.3 Technical Legacy Constantin Hagemeier 2008-10-11 > RFC0793 (1563) 3.4 Technical Legacy Constantin Hagemeier 2008-10-11 > RFC0793 (1564) 3.7 Technical Legacy Constantin Hagemeier 2008-10-11 > RFC0793 (1565) 3.8 Technical Legacy Constantin Hagemeier 2008-10-11 > RFC0793 (1566) 3.9 Technical Legacy Constantin Hagemeier 2008-10-11 > RFC0793 (1567) 3.9 Technical Legacy Constantin Hagemeier 2008-10-11 > RFC0793 (1568) 3.9 Technical Legacy Constantin Hagemeier 2008-10-11 > RFC0793 (1569) 2.4 Technical Legacy Constantin Hagemeier 2008-10-11 > RFC0793 (1570) 2.7 Technical Legacy Constantin Hagemeier 2008-10-11 > RFC0793 (1571) 3.1 Technical Legacy Constantin Hagemeier 2008-10-11 > RFC0793 (1572) 3.4 Technical Legacy Constantin Hagemeier 2008-10-11 > > > > > -- > Wes Eddy > MTI Systems > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From alexander.zimmermann@nets.rwth-aachen.de Fri Apr 16 03:28:41 2010 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 5D69B3A69D2 for ; Fri, 16 Apr 2010 03:28:41 -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 87Sq3m5rt6T8 for ; Fri, 16 Apr 2010 03:28:40 -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 B39BC3A6967 for ; Fri, 16 Apr 2010 03:28:39 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) 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 <0L0Y000GDT3JD6C0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Fri, 16 Apr 2010 12:28:31 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.52,218,1270418400"; d="sig'?scan'208";a="53365711" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Fri, 16 Apr 2010 12:28:31 +0200 Received: from miami.nets.rwth-aachen.de ([unknown] [137.226.12.180]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L0Y00L7CT385E10@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Fri, 16 Apr 2010 12:28:31 +0200 (CEST) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-17-1048734823 From: Alexander Zimmermann In-reply-to: Date: Fri, 16 Apr 2010 12:28:30 +0200 Content-transfer-encoding: 7bit Message-id: <73D77710-D7C5-4863-8C1A-441CE42AB315@nets.rwth-aachen.de> References: To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1078) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] WG status for 4/15/2010 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, 16 Apr 2010 10:28:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-17-1048734823 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A small correction from me too. The newest version is: http://www.ietf.org/id/draft-ietf-tcpm-tcp-lcd-01.txt Alex Am 15.04.2010 um 22:30 schrieb Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE = CORP]: > Hello TCPMers, below is a snapshot of the WG status as of > this week. There are a few updates following the IETF 77 > meeting. We're up to 4 documents in the RFC Editor queue, > 1 ready to go to the IESG, 2 more in WGLC, and there are a > couple getting close to ready for WGLC. Then there are a > number of them that we need to look at and check consensus > on whether they should become WG documents or not, > particularly the NewReno proposed modification has been > floating around for awhile, and hasn't had much feedback > lately. If people can focus on the two in WGLC and on the > NewReno proposal, I think that would be healthy for progress. >=20 > Also, there are draft notes from IETF 77 (thanks to Jamshid > and Matt for taking notes, any errors are probably mine in > merging them!). Vetting these would also be helpful: > http://www.ietf.org/proceedings/10mar/minutes/tcpm.txt >=20 >=20 >=20 > WG Items Nearing RFC Publication > =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 >=20 > Early-Retransmit > http://www.ietf.org/id/draft-ietf-tcpm-early-rexmt-04.txt > Milestone Target: Experimental in July 2009 > Status: In RFC Editor's queue > Action: None in TCPM >=20 > ICMP Attacks > http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-11.txt > Milestone Target: Informational in July 2009 > Status: finished IETF LC, with IESG > Action: None in TCPM >=20 > TCP Authentication Option > http://www.ietf.org/id/draft-ietf-tcpm-tcp-auth-opt-10.txt > Milestone Target: Proposed Standard in April 2009 > Status: In RFC Editor's queue > Action: None in TCPM >=20 > TCP Authentication Option Crypto > http://www.ietf.org/id/draft-ietf-tcpm-tcp-ao-crypto-01.txt > Milestone Target: Proposed Standard with AO spec > Status: In RFC Editor's queue > Action: None in TCPM >=20 >=20 >=20 > WG Items in WGLC or being revised after WGLC > =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=3D=3D=3D >=20 > Urgent Pointer > http://www.ietf.org/id/draft-ietf-tcpm-urgent-data-05.txt > Milestone Target: Proposed Standard in January 2010 > Status: updated after WGLC > Action: chairs (David) writing PROTO for sending to IESG >=20 > MSS Option > http://www.ietf.org/id/draft-ietf-tcpm-tcpmss-02.txt > 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 >=20 > Wes will write PROTO and send to the IESG, after WGLC > completes >=20 > Long Connectivity Disruptions > http://www.ietf.org/id/draft-ietf-tcpm-tcp-lcd-00.txt > (need to submit WG version) > Milestone Target: Experimental in October 2010 > Status: In WGLC > Action: WGLC to last 2 weeks, started on 4/13 >=20 >=20 > Active WG Items > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 1323bis > http://www.ietf.org/id/draft-ietf-tcpm-1323bis-01.txt > Milestone Target: Proposed Standard in July 2009 > Status: Needs revision > Action: Revise & WGLC (action with D. Borman) >=20 > TCP Security > http://www.ietf.org/id/draft-ietf-tcpm-tcp-security-01.txt > Milestone Target: BCP in August 2010 > Status: outline discussion dying off? content needs work > Action: 00-draft / outline has been under active discussion; but not = attained > very clear consensus > WG has begun working on recommendations while still looking for = a > possible compromise on outline (action with Fernando Gont) > progress on recommendations made at IETF 77 needs to be worked = into > the next version of draft (D. Borman to work w/ Fernando) >=20 > SACK Entry > http://www.ietf.org/id/draft-ietf-tcpm-sack-recovery-entry-01.txt > Milestone Target: Proposed Standard in October 2010 > Action: need WG to read/discuss > TBD how this relates to 3517, and if it will update it; authors = are > to determine how much additional time this might take as a = bis > document versus standalone >=20 > Clarification of sender behavior in persist condition > http://tools.ietf.org/id/draft-ananth-tcpm-persist-01.txt > Status: discussed on mailing list and in face-to-face meetings > Action: authors to submit WG version > WG determine what to do with socket option section > then WGLC >=20 >=20 > Documents Under a Poll to Become WG Items > =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 >=20 > Timestamps > http://tools.ietf.org/id/draft-gont-tcpm-tcp-timestamps-01.txt > Status: consensus to work on some portions of this, possibly as a part = of the > 1323bis document > Action: need to determine if the accepted portions can be worked into = 1323bis >=20 >=20 > Other Proposals Not Yet Decided On > =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 >=20 > NewReno Modification > = http://www.ietf.org/internet-drafts/draft-nishida-newreno-modification-01.= txt > Action: need WG to read/discuss > presentation given, document updated, but WG list not yet = polled for adoption >=20 > AO NAT > http://www.ietf.org/internet-drafts/draft-touch-tcp-ao-nat-00.txt > Status: IETF 77 discussion determined this should be Experimental, = whether or > not it is a WG document; need to ask TCPM list > Action: need to poll mailing list about path forward >=20 > Increasing TCP's Initial Window > http://tools.ietf.org/html/draft-hkchu-tcpm-initcwnd-00 > Status: presented in Anaheim; lots of interest > need to keep discussing; the work is in verifying that this is = a good > idea, moreso than documenting the change > Action: WG to continue to discuss >=20 > Computing TCP's Retransmission Timer > http://tools.ietf.org/id/draft-paxson-tcpm-rfc2988bis-00.txt > Status: presented briefly at IETF 77, also well-discussed on mailing = list > earlier and at IETF 75 > Action: need to poll for becoming a WG document >=20 >=20 > Older & Expired Documents Discussed > =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 >=20 > discussions on Rate-Halving > http://tools.ietf.org/id/draft-mathis-tcp-ratehalving-00.txt > Action: mailing list discussion about the history of this, and whether > it needs to be revived >=20 > Faster Application Handshakes with SYN/ACK Payloads > expired draft-agl-tcpm-sadata-01 > Status: expired; not specifically polled for adoption in WG >=20 >=20 > Documents Not Adopted by WG > =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 >=20 > TCP Option for Transparent Middlebox Discovery > http://www.ietf.org/id/draft-knutsen-tcpm-middlebox-discovery-03.txt > 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 >=20 >=20 >=20 > Other WG Activities > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Errata Review for legacy TCP RFCs: >=20 > RFC0793 (1496) 3.9 Technical Legacy Yin Shuming = 2008-08-27 > RFC0793 (1561) 3.2 Technical Legacy Constantin Hagemeier = 2008-10-11 > RFC0793 (1562) 3.3 Technical Legacy Constantin Hagemeier = 2008-10-11 > RFC0793 (1563) 3.4 Technical Legacy Constantin Hagemeier = 2008-10-11 > RFC0793 (1564) 3.7 Technical Legacy Constantin Hagemeier = 2008-10-11 > RFC0793 (1565) 3.8 Technical Legacy Constantin Hagemeier = 2008-10-11 > RFC0793 (1566) 3.9 Technical Legacy Constantin Hagemeier = 2008-10-11 > RFC0793 (1567) 3.9 Technical Legacy Constantin Hagemeier = 2008-10-11 > RFC0793 (1568) 3.9 Technical Legacy Constantin Hagemeier = 2008-10-11 > RFC0793 (1569) 2.4 Technical Legacy Constantin Hagemeier = 2008-10-11 > RFC0793 (1570) 2.7 Technical Legacy Constantin Hagemeier = 2008-10-11 > RFC0793 (1571) 3.1 Technical Legacy Constantin Hagemeier = 2008-10-11 > RFC0793 (1572) 3.4 Technical Legacy Constantin Hagemeier = 2008-10-11 >=20 >=20 >=20 >=20 > -- > Wes Eddy > MTI Systems >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-17-1048734823 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkvIO84ACgkQdyiq39b9uS7ItgCgvDPK7cZaJOV0SK4GwvI/nqcu Z9wAoIU+ZpIg+fUw/nmzpvizpzLs/nmE =FPTq -----END PGP SIGNATURE----- --Apple-Mail-17-1048734823-- From Xiangsong.Cui@huawei.com Tue Apr 20 02:34:44 2010 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 7FB7C3A693B for ; Tue, 20 Apr 2010 02:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.146 X-Spam-Level: X-Spam-Status: No, score=-0.146 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] 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 PaxgwDn8zwAq for ; Tue, 20 Apr 2010 02:34:43 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 41B323A6900 for ; Tue, 20 Apr 2010 02:34:42 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1600EKY55MB1@szxga04-in.huawei.com> for tcpm@ietf.org; Tue, 20 Apr 2010 17:32:10 +0800 (CST) Received: from c00111037 ([10.111.16.150]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L160011R55MJ7@szxga04-in.huawei.com> for tcpm@ietf.org; Tue, 20 Apr 2010 17:32:10 +0800 (CST) Date: Tue, 20 Apr 2010 17:32:10 +0800 From: Xiangsong Cui To: tcpm@ietf.org Message-id: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Subject: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? 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, 20 Apr 2010 09:34:44 -0000 Hi folks, I'm thinking such a question, can we, or should we add a pause/resume mechanism on TCP? Current TCP senders understand all packet losses as indications of congestion, but this is not always true, especially in the scenarios where wireless link is part of the network. Compared with wire link, wireless link is less stable, with higher bit error rate and more disconnection. And additionally, packet error and link disconnection can not be indicated by current TCP protocol and extensions, do I miss anything? So I think maybe pause/resume mechanism is helpful to this situation. The outline of pause/resume mechanism is as follows: * Pause/Resume indication may be transmitted by the receiver or the middle-box. Like ECN on TCP, middle-box may also send Pause/Resume indication. The use cases may be (a) wireless host moves to a tunnel or a shadow where the radio coverage is lost, and later returns to the radio coverage; (b) the router in the TCP path detects the next hop is invalid (by BFD or other mechanism), and later detects the re-connection to the next hop; (c) the wireless host (i.e. the receiver) doesn't want to accept too many traffic. A scenario for this use case is a user watches TCP video by wireless device, the user/device doesn't want buffer too many video stream because maybe the user only watch a little begin part of the video, but the unwanted video would waste wireless bandwidth and user's money. So the device does receiving-buffering-pausing-resuming, following the user's schedule. * Pause/Resume indication is directional, that means the receiver of Pause should stop transmit traffic packets but the sender of Pause may transmit traffic packets, unless the peer host also transmits a Pause indication. * When the TCP sender receives the Pause indication, it should keep the cwind value, stop transmitting traffic packets, and if the retransmission timer is running, the sender should also stop the timer. The TCP sender should accept received incoming TCP packet (both traffic packet and control packet) as normal, that means the sender can adjust the receive window, mark the transmitted packets as acknowledged, and so on. Another consideration is the Pause timer, the TCP sender should start the pause timer when it receives the Pause indication. * After the TCP receiver transmits the Pause indication, it may accept the received traffic packets or discard the packets, but the receiver should accept TCP control packets. * When the TCP sender receives the Resume indication, it should begin to transmit traffic packets (if there are) as normal, if there are transmitted packet(s) in the queue, it should also restart the retransmission timer... If the Pause timer is running, the TCP sender should kill the timer as soon as it receives the Resume indication. * If the TCP sender doesn't receive the Resume indication before the Pause timer expires, it should close the TCP connection. The intention of Pause/Resume is to avoid the violent change on the TCP congestion window, does this idea make sense? If it builds interest, I am going to write a draft, anybody who like to co-work on this topic? Thanks and best regards Xiangsong From nishida@sfc.wide.ad.jp Tue Apr 20 03:09:02 2010 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 7E75328C278 for ; Tue, 20 Apr 2010 03:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.854 X-Spam-Level: ** X-Spam-Status: No, score=2.854 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] 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 FnnpzlE46CNH for ; Tue, 20 Apr 2010 03:09:01 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 19B263A6B96 for ; Tue, 20 Apr 2010 02:58:23 -0700 (PDT) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 228D64C615; Tue, 20 Apr 2010 18:58:13 +0900 (JST) Date: Tue, 20 Apr 2010 18:58:13 +0900 (JST) Message-Id: <20100420.185813.30897748.nishida@sfc.wide.ad.jp> To: Xiangsong.Cui@huawei.com From: Yoshifumi Nishida In-Reply-To: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com> References: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? 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, 20 Apr 2010 10:09:02 -0000 Hi, My first impression is it looks like TCP needs to interact with other layers to know when to pasue/resume, which might be a bit tricky.. Also, is thre any reason not to use zero window advertisement? Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From: Xiangsong Cui Subject: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? Date: Tue, 20 Apr 2010 17:32:10 +0800 Message-ID: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com> > Hi folks, > > I'm thinking such a question, can we, or should we add a pause/resume > mechanism on TCP? > > Current TCP senders understand all packet losses as indications of > congestion, but this is not always true, especially in the scenarios > where wireless link is part of the network. Compared with wire link, > wireless link is less stable, with higher bit error rate and more > disconnection. And additionally, packet error and link disconnection > can not be indicated by current TCP protocol and extensions, do I miss > anything? > > > So I think maybe pause/resume mechanism is helpful to this > situation. The outline of pause/resume mechanism is as follows: > > * Pause/Resume indication may be transmitted by the receiver or the > * middle-box. Like ECN on TCP, middle-box may also send Pause/Resume > * indication. The use cases may be (a) wireless host moves to a tunnel > * or a shadow where the radio coverage is lost, and later returns to the > * radio coverage; (b) the router in the TCP path detects the next hop is > * invalid (by BFD or other mechanism), and later detects the > * re-connection to the next hop; (c) the wireless host (i.e. the > * receiver) doesn't want to accept too many traffic. A scenario for this > * use case is a user watches TCP video by wireless device, the > * user/device doesn't want buffer too many video stream because maybe > * the user only watch a little begin part of the video, but the unwanted > * video would waste wireless bandwidth and user's money. So the device > * does receiving-buffering-pausing-resuming, following the user's > * schedule. > > * Pause/Resume indication is directional, that means the receiver of > * Pause should stop transmit traffic packets but the sender of Pause may > * transmit traffic packets, unless the peer host also transmits a Pause > * indication. > > * When the TCP sender receives the Pause indication, it should keep the > * cwind value, stop transmitting traffic packets, and if the > * retransmission timer is running, the sender should also stop the > * timer. The TCP sender should accept received incoming TCP packet (both > * traffic packet and control packet) as normal, that means the sender > * can adjust the receive window, mark the transmitted packets as > * acknowledged, and so on. > Another consideration is the Pause timer, the TCP sender should start > the pause timer when it receives the Pause indication. > > * After the TCP receiver transmits the Pause indication, it may accept > * the received traffic packets or discard the packets, but the receiver > * should accept TCP control packets. > > * When the TCP sender receives the Resume indication, it should begin to > * transmit traffic packets (if there are) as normal, if there are > * transmitted packet(s) in the queue, it should also restart the > * retransmission timer... > If the Pause timer is running, the TCP sender should kill the timer as > soon as it receives the Resume indication. > > * If the TCP sender doesn't receive the Resume indication before the > * Pause timer expires, it should close the TCP connection. > > > The intention of Pause/Resume is to avoid the violent change on the > TCP congestion window, does this idea make sense? > If it builds interest, I am going to write a draft, anybody who like > to co-work on this topic? > > Thanks and best regards > > Xiangsong > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From lars.eggert@nokia.com Tue Apr 20 03:20:36 2010 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 AAF8928C1F0 for ; Tue, 20 Apr 2010 03:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, 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 p0qQDzj-1CoQ for ; Tue, 20 Apr 2010 03:20:33 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 5FC9D28C1F3 for ; Tue, 20 Apr 2010 03:10:28 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3KA9ptU021764; Tue, 20 Apr 2010 13:10:11 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Apr 2010 13:09:37 +0300 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Apr 2010 13:09:27 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3KA9PxP012756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Apr 2010 13:09:25 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/signed; boundary=Apple-Mail-23--754301307; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com> Date: Tue, 20 Apr 2010 13:09:18 +0300 Message-Id: <05F0AC17-703E-4F25-8730-A88ACA4D8E6B@nokia.com> References: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com> To: Xiangsong Cui X-Mailer: Apple Mail (2.1078) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Tue, 20 Apr 2010 13:09:18 +0300 (EEST) X-OriginalArrivalTime: 20 Apr 2010 10:09:27.0114 (UTC) FILETIME=[8F278AA0:01CAE071] X-Nokia-AV: Clean Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? 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, 20 Apr 2010 10:20:36 -0000 --Apple-Mail-23--754301307 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, are you aware of the following research paper? @inproceedings{DBLP :conf/infocom/GoffMPG00, author =3D {Tom Goff and James Moronski and Dhananjay S. Phatak and Vipul Gupta}, title =3D {Freeze-TCP: A True End-to-End TCP Enhancement Mechanism for Mobile Environments}, booktitle =3D {INFOCOM}, year =3D {2000}, pages =3D {1537-1545}, ee =3D {http://www.ieee-infocom.org/2000/papers/501.pdf}, bibsource =3D {DBLP, http://dblp.uni-trier.de} Lars On 2010-4-20, at 12:32, Xiangsong Cui wrote: > Hi folks, >=20 > I'm thinking such a question, can we, or should we add a pause/resume = mechanism on TCP? >=20 > Current TCP senders understand all packet losses as indications of = congestion, but this is not always true, especially in the=20 > scenarios where wireless link is part of the network. Compared with = wire link, wireless link is less stable, with higher bit error=20 > rate and more disconnection. And additionally, packet error and link = disconnection can not be indicated by current TCP protocol and=20 > extensions, do I miss anything? >=20 >=20 > So I think maybe pause/resume mechanism is helpful to this situation. = The outline of pause/resume mechanism is as follows: >=20 > * Pause/Resume indication may be transmitted by the receiver or the = middle-box. Like ECN on TCP, middle-box may also send=20 > Pause/Resume indication. The use cases may be (a) wireless host moves = to a tunnel or a shadow where the radio coverage is lost, and=20 > later returns to the radio coverage; (b) the router in the TCP path = detects the next hop is invalid (by BFD or other mechanism), and=20 > later detects the re-connection to the next hop; (c) the wireless host = (i.e. the receiver) doesn't want to accept too many traffic.=20 > A scenario for this use case is a user watches TCP video by wireless = device, the user/device doesn't want buffer too many video=20 > stream because maybe the user only watch a little begin part of the = video, but the unwanted video would waste wireless bandwidth and=20 > user's money. So the device does receiving-buffering-pausing-resuming, = following the user's schedule. >=20 > * Pause/Resume indication is directional, that means the receiver of = Pause should stop transmit traffic packets but the sender of=20 > Pause may transmit traffic packets, unless the peer host also = transmits a Pause indication. >=20 > * When the TCP sender receives the Pause indication, it should keep = the cwind value, stop transmitting traffic packets, and if the=20 > retransmission timer is running, the sender should also stop the = timer. The TCP sender should accept received incoming TCP packet=20 > (both traffic packet and control packet) as normal, that means the = sender can adjust the receive window, mark the transmitted=20 > packets as acknowledged, and so on. > Another consideration is the Pause timer, the TCP sender should start = the pause timer when it receives the Pause indication. >=20 > * After the TCP receiver transmits the Pause indication, it may accept = the received traffic packets or discard the packets, but the=20 > receiver should accept TCP control packets. >=20 > * When the TCP sender receives the Resume indication, it should begin = to transmit traffic packets (if there are) as normal, if there=20 > are transmitted packet(s) in the queue, it should also restart the = retransmission timer... > If the Pause timer is running, the TCP sender should kill the timer as = soon as it receives the Resume indication. >=20 > * If the TCP sender doesn't receive the Resume indication before the = Pause timer expires, it should close the TCP connection. >=20 >=20 > The intention of Pause/Resume is to avoid the violent change on the = TCP congestion window, does this idea make sense? > If it builds interest, I am going to write a draft, anybody who like = to co-work on this topic? >=20 > Thanks and best regards >=20 > Xiangsong=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-23--754301307 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDQyMDEwMDkxOFowIwYJKoZIhvcNAQkEMRYEFCPowX9yZ+FmonclvAZAz+syMtx5MIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCJ1gq5ruUwRCNgI46oAiLY8TGT2YXquyXaGKASGw21xrKNddx8v0pEfwZhQcie0PbEGDjc mj/4T3L2zSag5/AKDtkz8C7OmMqw7kQMgRJhaVVLZ8SKpNISxXwlbJFk9w5AervodCOq8iQqywBv 9O8y+kVJ2P1GtpGytNHRrHFWxWm/er/rqOYRJ0iDzBIJ0OtscUCPK/joFH0jRv9Qwka/xKcP7YxP BMoKwCZOUj8FMr7luI8b+7h1BE4xKZQd3HEGyYy2RrWbv8ASgjQ4zWBlh94xOA9v3QGU+O/8nkdn 9XH8nD04HlptMWPsm7luzb3FhrMbkrJr/qQ3UwMN+HW7AAAAAAAA --Apple-Mail-23--754301307-- From perfgeek@mac.com Tue Apr 20 07:34:04 2010 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 6736C28C1E3 for ; Tue, 20 Apr 2010 07:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 RSfJk9FxU2d2 for ; Tue, 20 Apr 2010 07:34:03 -0700 (PDT) Received: from asmtpout017.mac.com (asmtpout017.mac.com [17.148.16.92]) by core3.amsl.com (Postfix) with ESMTP id 47DFA28C1FE for ; Tue, 20 Apr 2010 07:29:57 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from [192.168.1.101] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by asmtp017.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0L1600B7SIXNXT10@asmtp017.mac.com> for tcpm@ietf.org; Tue, 20 Apr 2010 07:29:48 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004200118 From: rick jones To: Xiangsong Cui In-reply-to: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com> X-Priority: 3 References: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com> Message-id: <9C35012A-43AE-4B93-BDBB-3B4AFE7A22B2@mac.com> Date: Tue, 20 Apr 2010 07:29:45 -0700 X-Mailer: Apple Mail (2.936) Cc: tcpm@ietf.org Subject: Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? 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, 20 Apr 2010 14:34:04 -0000 Superficially at least, it sounds like ICMP source quench. rick jones there is no rest for the wicked, yet the virtuous have no pillows From rs@netapp.com Tue Apr 20 15:52:09 2010 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 533643A680A for ; Tue, 20 Apr 2010 15:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 VANQJQO4K6GW for ; Tue, 20 Apr 2010 15:52:08 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id DD0B13A659A for ; Tue, 20 Apr 2010 15:52:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,245,1270450800"; d="scan'208";a="142513321" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 20 Apr 2010 15:51:57 -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 o3KMpuUE027601; Tue, 20 Apr 2010 15:51:56 -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); Wed, 21 Apr 2010 00:51:56 +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: Tue, 20 Apr 2010 23:51:54 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0852A5BC@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? Thread-Index: AcrgbLQpJva8vyjMSpCGXf8hOszK/QAbbWRg References: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com> From: "Scheffenegger, Richard" To: "Xiangsong Cui" , X-OriginalArrivalTime: 20 Apr 2010 22:51:56.0296 (UTC) FILETIME=[13CAB880:01CAE0DC] Subject: Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? 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, 20 Apr 2010 22:52:09 -0000 Hi, I think it's well known (and well established), that middle-boxes which intercept and "translate" TCP from wired to wireless give a big performance boost; I've been involved in a PoC of such an architecture for a cell provider some 10 years ago (when GPRS was in it's infancy). Logically, the middlebox would terminate the tcp sessions from each end, but appear transparent on the L3. Appropriate tunings to the tcp stack depending on the type of connectivity were then made... For the wired side, a zero window advertisement was used to throttle incoming data when the wireless receiver were in a high BER area... I would have thought, that such boxes are commercially available and widely deployed these days. (Back then, it was an expirimental feature of a Linux stack, I believe). Besides, as others noted, some of the functionality described seems to require some interaction between L4 and L1/L2; An application wishing to do that, can already use zero window advertisements (indirectly, by not fetching the data from the tcp receive buffer). The only "enhancement" I see here is to now cut back cwnd - but without an ack clock, you are asking for incast issues there... Best regards Richard Scheffenegger =20 > -----Original Message----- > From: Xiangsong Cui [mailto:Xiangsong.Cui@huawei.com]=20 > Sent: Dienstag, 20. April 2010 11:32 > To: tcpm@ietf.org > Subject: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? >=20 > Hi folks, >=20 > I'm thinking such a question, can we, or should we add a=20 > pause/resume mechanism on TCP? >=20 > Current TCP senders understand all packet losses as=20 > indications of congestion, but this is not always true,=20 > especially in the scenarios where wireless link is part of=20 > the network. Compared with wire link, wireless link is less=20 > stable, with higher bit error rate and more disconnection.=20 > And additionally, packet error and link disconnection can not=20 > be indicated by current TCP protocol and extensions, do I=20 > miss anything? >=20 >=20 > So I think maybe pause/resume mechanism is helpful to this=20 > situation. The outline of pause/resume mechanism is as follows: >=20 > * Pause/Resume indication may be transmitted by the receiver=20 > or the middle-box. Like ECN on TCP, middle-box may also send=20 > Pause/Resume indication. The use cases may be (a) wireless=20 > host moves to a tunnel or a shadow where the radio coverage=20 > is lost, and later returns to the radio coverage; (b) the=20 > router in the TCP path detects the next hop is invalid (by=20 > BFD or other mechanism), and later detects the re-connection=20 > to the next hop; (c) the wireless host (i.e. the receiver)=20 > doesn't want to accept too many traffic.=20 > A scenario for this use case is a user watches TCP video by=20 > wireless device, the user/device doesn't want buffer too many=20 > video stream because maybe the user only watch a little begin=20 > part of the video, but the unwanted video would waste=20 > wireless bandwidth and user's money. So the device does=20 > receiving-buffering-pausing-resuming, following the user's schedule. >=20 > * Pause/Resume indication is directional, that means the=20 > receiver of Pause should stop transmit traffic packets but=20 > the sender of Pause may transmit traffic packets, unless the=20 > peer host also transmits a Pause indication. >=20 > * When the TCP sender receives the Pause indication, it=20 > should keep the cwind value, stop transmitting traffic=20 > packets, and if the retransmission timer is running, the=20 > sender should also stop the timer. The TCP sender should=20 > accept received incoming TCP packet (both traffic packet and=20 > control packet) as normal, that means the sender can adjust=20 > the receive window, mark the transmitted packets as=20 > acknowledged, and so on. > Another consideration is the Pause timer, the TCP sender=20 > should start the pause timer when it receives the Pause indication. >=20 > * After the TCP receiver transmits the Pause indication, it=20 > may accept the received traffic packets or discard the=20 > packets, but the receiver should accept TCP control packets. >=20 > * When the TCP sender receives the Resume indication, it=20 > should begin to transmit traffic packets (if there are) as=20 > normal, if there are transmitted packet(s) in the queue, it=20 > should also restart the retransmission timer... > If the Pause timer is running, the TCP sender should kill the=20 > timer as soon as it receives the Resume indication. >=20 > * If the TCP sender doesn't receive the Resume indication=20 > before the Pause timer expires, it should close the TCP connection. >=20 >=20 > The intention of Pause/Resume is to avoid the violent change=20 > on the TCP congestion window, does this idea make sense? > If it builds interest, I am going to write a draft, anybody=20 > who like to co-work on this topic? >=20 > Thanks and best regards >=20 > Xiangsong=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From Xiangsong.Cui@huawei.com Tue Apr 20 18:31:53 2010 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 439103A67A7 for ; Tue, 20 Apr 2010 18:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.409 X-Spam-Level: X-Spam-Status: No, score=-1.409 tagged_above=-999 required=5 tests=[AWL=1.189, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 Hn64mljYPczS for ; Tue, 20 Apr 2010 18:31:52 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id D27FF3A67E7 for ; Tue, 20 Apr 2010 18:31:50 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L17008NJDKQQB@szxga04-in.huawei.com> for tcpm@ietf.org; Wed, 21 Apr 2010 09:31:38 +0800 (CST) Received: from c00111037 ([10.111.16.150]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L1700JY1DKPGU@szxga04-in.huawei.com> for tcpm@ietf.org; Wed, 21 Apr 2010 09:31:38 +0800 (CST) Date: Wed, 21 Apr 2010 09:31:37 +0800 From: Xiangsong Cui To: Yoshifumi Nishida Message-id: <003d01cae0f2$630a5750$96106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com> <20100420.185813.30897748.nishida@sfc.wide.ad.jp> Cc: tcpm@ietf.org Subject: Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? 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, 21 Apr 2010 01:31:53 -0000 Hi Yoshifumi, Thank you for your response! One reason is that zero window advertisement can not stop the sender's RTX timer, in my understand, the zero window advertisement can only tell the sender not to send new traffic, but the sender will still keep the timer running, and when the timer expires, the cwind is reduced, and some packets are retransmitted unnecessary. When the receiver advertises the new receive window, maybe the sender has entered the slow start procedure, is that right? Regards, Xiangsong ----- Original Message ----- From: "Yoshifumi Nishida" To: Cc: Sent: Tuesday, April 20, 2010 5:58 PM Subject: Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? > > Hi, My first impression is it looks like TCP needs to interact with other > layers to know when to pasue/resume, which might be a bit tricky.. > Also, is thre any reason not to use zero window advertisement? > > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp > > From: Xiangsong Cui > Subject: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? > Date: Tue, 20 Apr 2010 17:32:10 +0800 > Message-ID: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com> > > > Hi folks, > > > > I'm thinking such a question, can we, or should we add a pause/resume > > mechanism on TCP? > > > > Current TCP senders understand all packet losses as indications of > > congestion, but this is not always true, especially in the scenarios > > where wireless link is part of the network. Compared with wire link, > > wireless link is less stable, with higher bit error rate and more > > disconnection. And additionally, packet error and link disconnection > > can not be indicated by current TCP protocol and extensions, do I miss > > anything? > > > > > > So I think maybe pause/resume mechanism is helpful to this > > situation. The outline of pause/resume mechanism is as follows: > > > > * Pause/Resume indication may be transmitted by the receiver or the > > * middle-box. Like ECN on TCP, middle-box may also send Pause/Resume > > * indication. The use cases may be (a) wireless host moves to a tunnel > > * or a shadow where the radio coverage is lost, and later returns to the > > * radio coverage; (b) the router in the TCP path detects the next hop is > > * invalid (by BFD or other mechanism), and later detects the > > * re-connection to the next hop; (c) the wireless host (i.e. the > > * receiver) doesn't want to accept too many traffic. A scenario for this > > * use case is a user watches TCP video by wireless device, the > > * user/device doesn't want buffer too many video stream because maybe > > * the user only watch a little begin part of the video, but the unwanted > > * video would waste wireless bandwidth and user's money. So the device > > * does receiving-buffering-pausing-resuming, following the user's > > * schedule. > > > > * Pause/Resume indication is directional, that means the receiver of > > * Pause should stop transmit traffic packets but the sender of Pause may > > * transmit traffic packets, unless the peer host also transmits a Pause > > * indication. > > > > * When the TCP sender receives the Pause indication, it should keep the > > * cwind value, stop transmitting traffic packets, and if the > > * retransmission timer is running, the sender should also stop the > > * timer. The TCP sender should accept received incoming TCP packet (both > > * traffic packet and control packet) as normal, that means the sender > > * can adjust the receive window, mark the transmitted packets as > > * acknowledged, and so on. > > Another consideration is the Pause timer, the TCP sender should start > > the pause timer when it receives the Pause indication. > > > > * After the TCP receiver transmits the Pause indication, it may accept > > * the received traffic packets or discard the packets, but the receiver > > * should accept TCP control packets. > > > > * When the TCP sender receives the Resume indication, it should begin to > > * transmit traffic packets (if there are) as normal, if there are > > * transmitted packet(s) in the queue, it should also restart the > > * retransmission timer... > > If the Pause timer is running, the TCP sender should kill the timer as > > soon as it receives the Resume indication. > > > > * If the TCP sender doesn't receive the Resume indication before the > > * Pause timer expires, it should close the TCP connection. > > > > > > The intention of Pause/Resume is to avoid the violent change on the > > TCP congestion window, does this idea make sense? > > If it builds interest, I am going to write a draft, anybody who like > > to co-work on this topic? > > > > Thanks and best regards > > > > Xiangsong > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm From Xiangsong.Cui@huawei.com Tue Apr 20 18:36:13 2010 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 1E8C53A6823 for ; Tue, 20 Apr 2010 18:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 iOGPdFiL2W5A for ; Tue, 20 Apr 2010 18:36:11 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id DB8823A67FF for ; Tue, 20 Apr 2010 18:36:10 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L17004A1DRPWF@szxga01-in.huawei.com> for tcpm@ietf.org; Wed, 21 Apr 2010 09:35:49 +0800 (CST) Received: from c00111037 ([10.111.16.150]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L17003R4DROGG@szxga01-in.huawei.com> for tcpm@ietf.org; Wed, 21 Apr 2010 09:35:48 +0800 (CST) Date: Wed, 21 Apr 2010 09:35:48 +0800 From: Xiangsong Cui To: Lars Eggert Message-id: <004301cae0f2$f863fbd0$96106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com> <05F0AC17-703E-4F25-8730-A88ACA4D8E6B@nokia.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? 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, 21 Apr 2010 01:36:13 -0000 Hi Lars, Thank you very much for your reminder! I didn't know this paper until now, and I have downloaded the paper and will read it carefully. Regards, Xiangsong ----- Original Message ----- From: "Lars Eggert" To: "Xiangsong Cui" Cc: Sent: Tuesday, April 20, 2010 6:09 PM Subject: Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? Hi, are you aware of the following research paper? @inproceedings{DBLP :conf/infocom/GoffMPG00, author = {Tom Goff and James Moronski and Dhananjay S. Phatak and Vipul Gupta}, title = {Freeze-TCP: A True End-to-End TCP Enhancement Mechanism for Mobile Environments}, booktitle = {INFOCOM}, year = {2000}, pages = {1537-1545}, ee = {http://www.ieee-infocom.org/2000/papers/501.pdf}, bibsource = {DBLP, http://dblp.uni-trier.de} Lars On 2010-4-20, at 12:32, Xiangsong Cui wrote: > Hi folks, > > I'm thinking such a question, can we, or should we add a pause/resume mechanism on TCP? > > Current TCP senders understand all packet losses as indications of congestion, but this is not always true, especially in the > scenarios where wireless link is part of the network. Compared with wire link, wireless link is less stable, with higher bit error > rate and more disconnection. And additionally, packet error and link disconnection can not be indicated by current TCP protocol > and > extensions, do I miss anything? > > > So I think maybe pause/resume mechanism is helpful to this situation. The outline of pause/resume mechanism is as follows: > > * Pause/Resume indication may be transmitted by the receiver or the middle-box. Like ECN on TCP, middle-box may also send > Pause/Resume indication. The use cases may be (a) wireless host moves to a tunnel or a shadow where the radio coverage is lost, > and > later returns to the radio coverage; (b) the router in the TCP path detects the next hop is invalid (by BFD or other mechanism), > and > later detects the re-connection to the next hop; (c) the wireless host (i.e. the receiver) doesn't want to accept too many > traffic. > A scenario for this use case is a user watches TCP video by wireless device, the user/device doesn't want buffer too many video > stream because maybe the user only watch a little begin part of the video, but the unwanted video would waste wireless bandwidth > and > user's money. So the device does receiving-buffering-pausing-resuming, following the user's schedule. > > * Pause/Resume indication is directional, that means the receiver of Pause should stop transmit traffic packets but the sender of > Pause may transmit traffic packets, unless the peer host also transmits a Pause indication. > > * When the TCP sender receives the Pause indication, it should keep the cwind value, stop transmitting traffic packets, and if the > retransmission timer is running, the sender should also stop the timer. The TCP sender should accept received incoming TCP packet > (both traffic packet and control packet) as normal, that means the sender can adjust the receive window, mark the transmitted > packets as acknowledged, and so on. > Another consideration is the Pause timer, the TCP sender should start the pause timer when it receives the Pause indication. > > * After the TCP receiver transmits the Pause indication, it may accept the received traffic packets or discard the packets, but > the > receiver should accept TCP control packets. > > * When the TCP sender receives the Resume indication, it should begin to transmit traffic packets (if there are) as normal, if > there > are transmitted packet(s) in the queue, it should also restart the retransmission timer... > If the Pause timer is running, the TCP sender should kill the timer as soon as it receives the Resume indication. > > * If the TCP sender doesn't receive the Resume indication before the Pause timer expires, it should close the TCP connection. > > > The intention of Pause/Resume is to avoid the violent change on the TCP congestion window, does this idea make sense? > If it builds interest, I am going to write a draft, anybody who like to co-work on this topic? > > Thanks and best regards > > Xiangsong > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From Xiangsong.Cui@huawei.com Tue Apr 20 18:39:20 2010 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 119F13A68ED for ; Tue, 20 Apr 2010 18:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.579 X-Spam-Level: X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 pDjMtJjUcN3q for ; Tue, 20 Apr 2010 18:39:19 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 3F6893A67A7 for ; Tue, 20 Apr 2010 18:39:19 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1700414DWZWF@szxga01-in.huawei.com> for tcpm@ietf.org; Wed, 21 Apr 2010 09:38:59 +0800 (CST) Received: from c00111037 ([10.111.16.150]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L170037VDWZGG@szxga01-in.huawei.com> for tcpm@ietf.org; Wed, 21 Apr 2010 09:38:59 +0800 (CST) Date: Wed, 21 Apr 2010 09:38:58 +0800 From: Xiangsong Cui To: rick jones Message-id: <004901cae0f3$69ddaa90$96106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com> <9C35012A-43AE-4B93-BDBB-3B4AFE7A22B2@mac.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? 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, 21 Apr 2010 01:39:20 -0000 Hi Rick, Yes, they are similar, maybe the only difference is that the functionality is moved to TCP layer, affecting the TCP congestion control. Regards Xiangsong ----- Original Message ----- From: "rick jones" To: "Xiangsong Cui" Cc: Sent: Tuesday, April 20, 2010 10:29 PM Subject: Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? > Superficially at least, it sounds like ICMP source quench. > > rick jones > there is no rest for the wicked, yet the virtuous have no pillows > From Xiangsong.Cui@huawei.com Tue Apr 20 19:00:27 2010 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 293053A6BEE for ; Tue, 20 Apr 2010 19:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.178 X-Spam-Level: X-Spam-Status: No, score=0.178 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 b6zrWLTTfAuh for ; Tue, 20 Apr 2010 19:00:26 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id C56383A6BE9 for ; Tue, 20 Apr 2010 19:00:25 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1700J71EW5K2@szxga02-in.huawei.com> for tcpm@ietf.org; Wed, 21 Apr 2010 10:00:06 +0800 (CST) Received: from c00111037 ([10.111.16.150]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L1700KZGEW55P@szxga02-in.huawei.com> for tcpm@ietf.org; Wed, 21 Apr 2010 10:00:05 +0800 (CST) Date: Wed, 21 Apr 2010 10:00:05 +0800 From: Xiangsong Cui To: "Scheffenegger, Richard" , tcpm@ietf.org Message-id: <006a01cae0f6$5cdffc00$96106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com> <5FDC413D5FA246468C200652D63E627A0852A5BC@LDCMVEXC1-PRD.hq.netapp.com> Subject: Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? 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, 21 Apr 2010 02:00:27 -0000 Hi Richard, Thank you very much for your detailed explanation! I found PILC, a concluded working group, ever studied on this area, and outputted many documents, but it seems that the RFCs are not used widely. maybe one reason is that the mechanism destroys the end-to-end principle of internet? I am wondering at this fact. Could you please tell me more information? Another issue I am concerning is the buffer in the middle box. If there is a TCP proxy in the border and it splits the TCP connection into two parts, it has to buffer the TCP traffic? I am not sure about the influence. Regards, Xiangsong ----- Original Message ----- From: "Scheffenegger, Richard" To: "Xiangsong Cui" ; Sent: Wednesday, April 21, 2010 6:51 AM Subject: RE: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? Hi, I think it's well known (and well established), that middle-boxes which intercept and "translate" TCP from wired to wireless give a big performance boost; I've been involved in a PoC of such an architecture for a cell provider some 10 years ago (when GPRS was in it's infancy). Logically, the middlebox would terminate the tcp sessions from each end, but appear transparent on the L3. Appropriate tunings to the tcp stack depending on the type of connectivity were then made... For the wired side, a zero window advertisement was used to throttle incoming data when the wireless receiver were in a high BER area... I would have thought, that such boxes are commercially available and widely deployed these days. (Back then, it was an expirimental feature of a Linux stack, I believe). Besides, as others noted, some of the functionality described seems to require some interaction between L4 and L1/L2; An application wishing to do that, can already use zero window advertisements (indirectly, by not fetching the data from the tcp receive buffer). The only "enhancement" I see here is to now cut back cwnd - but without an ack clock, you are asking for incast issues there... Best regards Richard Scheffenegger > -----Original Message----- > From: Xiangsong Cui [mailto:Xiangsong.Cui@huawei.com] > Sent: Dienstag, 20. April 2010 11:32 > To: tcpm@ietf.org > Subject: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? > > Hi folks, > > I'm thinking such a question, can we, or should we add a > pause/resume mechanism on TCP? > > Current TCP senders understand all packet losses as > indications of congestion, but this is not always true, > especially in the scenarios where wireless link is part of > the network. Compared with wire link, wireless link is less > stable, with higher bit error rate and more disconnection. > And additionally, packet error and link disconnection can not > be indicated by current TCP protocol and extensions, do I > miss anything? > > > So I think maybe pause/resume mechanism is helpful to this > situation. The outline of pause/resume mechanism is as follows: > > * Pause/Resume indication may be transmitted by the receiver > or the middle-box. Like ECN on TCP, middle-box may also send > Pause/Resume indication. The use cases may be (a) wireless > host moves to a tunnel or a shadow where the radio coverage > is lost, and later returns to the radio coverage; (b) the > router in the TCP path detects the next hop is invalid (by > BFD or other mechanism), and later detects the re-connection > to the next hop; (c) the wireless host (i.e. the receiver) > doesn't want to accept too many traffic. > A scenario for this use case is a user watches TCP video by > wireless device, the user/device doesn't want buffer too many > video stream because maybe the user only watch a little begin > part of the video, but the unwanted video would waste > wireless bandwidth and user's money. So the device does > receiving-buffering-pausing-resuming, following the user's schedule. > > * Pause/Resume indication is directional, that means the > receiver of Pause should stop transmit traffic packets but > the sender of Pause may transmit traffic packets, unless the > peer host also transmits a Pause indication. > > * When the TCP sender receives the Pause indication, it > should keep the cwind value, stop transmitting traffic > packets, and if the retransmission timer is running, the > sender should also stop the timer. The TCP sender should > accept received incoming TCP packet (both traffic packet and > control packet) as normal, that means the sender can adjust > the receive window, mark the transmitted packets as > acknowledged, and so on. > Another consideration is the Pause timer, the TCP sender > should start the pause timer when it receives the Pause indication. > > * After the TCP receiver transmits the Pause indication, it > may accept the received traffic packets or discard the > packets, but the receiver should accept TCP control packets. > > * When the TCP sender receives the Resume indication, it > should begin to transmit traffic packets (if there are) as > normal, if there are transmitted packet(s) in the queue, it > should also restart the retransmission timer... > If the Pause timer is running, the TCP sender should kill the > timer as soon as it receives the Resume indication. > > * If the TCP sender doesn't receive the Resume indication > before the Pause timer expires, it should close the TCP connection. > > > The intention of Pause/Resume is to avoid the violent change > on the TCP congestion window, does this idea make sense? > If it builds interest, I am going to write a draft, anybody > who like to co-work on this topic? > > Thanks and best regards > > Xiangsong > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From Xiangsong.Cui@huawei.com Wed Apr 21 01:36:51 2010 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 B24573A6822 for ; Wed, 21 Apr 2010 01:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=1.082, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 CkqHL3kGvx2e for ; Wed, 21 Apr 2010 01:36:49 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 39D623A6405 for ; Wed, 21 Apr 2010 01:36:45 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1700CE9X5YSA@szxga04-in.huawei.com> for tcpm@ietf.org; Wed, 21 Apr 2010 16:34:47 +0800 (CST) Received: from c00111037 ([10.111.16.150]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L1700BD8X5X62@szxga04-in.huawei.com> for tcpm@ietf.org; Wed, 21 Apr 2010 16:34:45 +0800 (CST) Date: Wed, 21 Apr 2010 16:34:49 +0800 From: Xiangsong Cui To: Lars Eggert Message-id: <01ac01cae12d$81d50640$96106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com> <05F0AC17-703E-4F25-8730-A88ACA4D8E6B@nokia.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? 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, 21 Apr 2010 08:36:51 -0000 Hi Lars, Many thanks for your showing me the excellent paper! As stated in the paper: "the main advantage is that when the sender enters persist mode, it freezes all packet retransmit timers and does not drop the congestion window so that the idle time during the slow-start phase can be avoided", I am also in this way. Some details I am considering now are: who send the indication, middle-box or the receiver? when does host/middle-box send the indication? sometimes it is difficult to forecast the disconnection. I also read some other papers about TCP over wireless link and I am a little confused. It seems that there are many researches and energy on this topic for more than ten years, but it is not clear until now which solution is recommended by IETF, or I missed the proposal? Since the TCP protocol is product of IETF, should IETF give some official suggestion on the applicability of TCP extensions? So the mobile hosts and middle-boxes may follow that... Thanks and regards Xiangsong ----- Original Message ----- From: "Lars Eggert" To: "Xiangsong Cui" Cc: Sent: Tuesday, April 20, 2010 6:09 PM Subject: Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? Hi, are you aware of the following research paper? @inproceedings{DBLP :conf/infocom/GoffMPG00, author = {Tom Goff and James Moronski and Dhananjay S. Phatak and Vipul Gupta}, title = {Freeze-TCP: A True End-to-End TCP Enhancement Mechanism for Mobile Environments}, booktitle = {INFOCOM}, year = {2000}, pages = {1537-1545}, ee = {http://www.ieee-infocom.org/2000/papers/501.pdf}, bibsource = {DBLP, http://dblp.uni-trier.de} Lars On 2010-4-20, at 12:32, Xiangsong Cui wrote: > Hi folks, > > I'm thinking such a question, can we, or should we add a pause/resume mechanism on TCP? > > Current TCP senders understand all packet losses as indications of congestion, but this is not always true, especially in the > scenarios where wireless link is part of the network. Compared with wire link, wireless link is less stable, with higher bit error > rate and more disconnection. And additionally, packet error and link disconnection can not be indicated by current TCP protocol > and > extensions, do I miss anything? > > > So I think maybe pause/resume mechanism is helpful to this situation. The outline of pause/resume mechanism is as follows: > > * Pause/Resume indication may be transmitted by the receiver or the middle-box. Like ECN on TCP, middle-box may also send > Pause/Resume indication. The use cases may be (a) wireless host moves to a tunnel or a shadow where the radio coverage is lost, > and > later returns to the radio coverage; (b) the router in the TCP path detects the next hop is invalid (by BFD or other mechanism), > and > later detects the re-connection to the next hop; (c) the wireless host (i.e. the receiver) doesn't want to accept too many > traffic. > A scenario for this use case is a user watches TCP video by wireless device, the user/device doesn't want buffer too many video > stream because maybe the user only watch a little begin part of the video, but the unwanted video would waste wireless bandwidth > and > user's money. So the device does receiving-buffering-pausing-resuming, following the user's schedule. > > * Pause/Resume indication is directional, that means the receiver of Pause should stop transmit traffic packets but the sender of > Pause may transmit traffic packets, unless the peer host also transmits a Pause indication. > > * When the TCP sender receives the Pause indication, it should keep the cwind value, stop transmitting traffic packets, and if the > retransmission timer is running, the sender should also stop the timer. The TCP sender should accept received incoming TCP packet > (both traffic packet and control packet) as normal, that means the sender can adjust the receive window, mark the transmitted > packets as acknowledged, and so on. > Another consideration is the Pause timer, the TCP sender should start the pause timer when it receives the Pause indication. > > * After the TCP receiver transmits the Pause indication, it may accept the received traffic packets or discard the packets, but > the > receiver should accept TCP control packets. > > * When the TCP sender receives the Resume indication, it should begin to transmit traffic packets (if there are) as normal, if > there > are transmitted packet(s) in the queue, it should also restart the retransmission timer... > If the Pause timer is running, the TCP sender should kill the timer as soon as it receives the Resume indication. > > * If the TCP sender doesn't receive the Resume indication before the Pause timer expires, it should close the TCP connection. > > > The intention of Pause/Resume is to avoid the violent change on the TCP congestion window, does this idea make sense? > If it builds interest, I am going to write a draft, anybody who like to co-work on this topic? > > Thanks and best regards > > Xiangsong > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From lars.eggert@nokia.com Wed Apr 21 03:00:48 2010 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 7C6DA28C0F7 for ; Wed, 21 Apr 2010 03:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.307 X-Spam-Level: X-Spam-Status: No, score=-5.307 tagged_above=-999 required=5 tests=[AWL=-1.122, BAYES_40=-0.185, 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 bfUS33zLJZdE for ; Wed, 21 Apr 2010 03:00:47 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 7E1B828C0F2 for ; Wed, 21 Apr 2010 03:00:44 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3LA048v026759; Wed, 21 Apr 2010 13:00:27 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 13:00:24 +0300 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Apr 2010 13:00:23 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3LA0MWA012378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Apr 2010 13:00:22 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/signed; boundary=Apple-Mail-12--668444118; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <01ac01cae12d$81d50640$96106f0a@china.huawei.com> Date: Wed, 21 Apr 2010 13:00:15 +0300 Message-Id: <816145D8-3C62-4F28-AC93-FC7B1051B833@nokia.com> References: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com> <05F0AC17-703E-4F25-8730-A88ACA4D8E6B@nokia.com> <01ac01cae12d$81d50640$96106f0a@china.huawei.com> To: Xiangsong Cui X-Mailer: Apple Mail (2.1078) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Wed, 21 Apr 2010 13:00:15 +0300 (EEST) X-OriginalArrivalTime: 21 Apr 2010 10:00:23.0766 (UTC) FILETIME=[75B4F760:01CAE139] X-Nokia-AV: Clean Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? 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, 21 Apr 2010 10:00:48 -0000 --Apple-Mail-12--668444118 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-4-21, at 11:34, Xiangsong Cui wrote: > I also read some other papers about TCP over wireless link and I am a = little confused. It seems that there are many researches and=20 > energy on this topic for more than ten years, but it is not clear = until now which solution is recommended by IETF, or I missed the=20 > proposal? Since the TCP protocol is product of IETF, should IETF give = some official suggestion on the applicability of TCP=20 > extensions? So the mobile hosts and middle-boxes may follow that... you're correct in that there is no IETF recommendation in this space, = although there is a large body of research work. In my view, the reason = for this is mainly that none of the researchers have had the energy to = seriously continue their work so that it could be published as an IETF = recommendation. This is to some degree understandable, because the = effort it takes may need to be spent on something that may not be = academically publishable. For example, whereas it is sufficient for a research paper to show that = benefits exists in some scenarios, for an IETF recommendation, we need = to be sure that a proposal has no drawbacks, or at the very least that = they are well-understood and easy to work around (e.g., by not using a = proposed extension in those cases). Also, TCP is a general-purpose protocol. Optimizing its operation for a = specific link technology implicitly assumes that that link technology = will be used on the bottleneck link that mostly defines the path = characteristics. That's a pretty strong assumption in general. Many = folks have shown that TCP can be tuned in this way; not many have tried = to determine whether there are drawbacks when a tuned TCP runs over a = path where a different link technology is the bottleneck. Even proposals that are agnostic to link technology have issues, e.g., = Freeze TCP, which I cited since it sounded similar to your proposal. For = example, there is an implicit assumption that path characteristics = (available bandwidth, RTT, etc.) do not change during the freeze period = - when they do, the thawed connection can significantly overshoot along = the new path, or it can underperform (and will take a long time to probe = for extra capacity if it is in congestion avoidance mode). And = obviously, there is an assumption that you somehow know when to freeze = and thaw.=20 In a nutshell, I believe there is no IETF recommendation in this space, = because designing one that is often useful and overall not harmful and = has sufficient benefits to offset the needed effort is harder than it = first appears. Lars= --Apple-Mail-12--668444118 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDQyMTEwMDAxNVowIwYJKoZIhvcNAQkEMRYEFHjKIW+wLmRb7dBQi/2idv1uESj8MIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQBM7geKM6Yryhz2fCL2vfIX1ZSrwbXyn6PzXdsELWSomt88UCnxFEOuvTl3xYRICQraPAOv +llQW+np83IS+QchRByh4oaxhCuV4BUhcXDO/e9Utg3kRgWPO0NNCmV6OpNDLEIqgcGShYdcXoKu LcgDuhlUV4mebWpd/RnbFf+IrXPdfR9NiYKLvZenyRqFtaruhEYVx+yJVMIPffp7a9M6YSMVvP1U E7HbjGBbpJ43XrLP8RLpTzUWraN+shazrtJZ3bjPqmS3ScCyfw9ayfmiI75ZCNbk3xzqgpeGCaKn qZsOnToRXFReoZnX+P3GCh+5VdfJl9nIyB26n9NbFQ8MAAAAAAAA --Apple-Mail-12--668444118-- From alexander.zimmermann@nets.rwth-aachen.de Wed Apr 21 05:01:16 2010 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 A76F028C14A for ; Wed, 21 Apr 2010 05:01:16 -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 MKBw6ZnTJV1z for ; Wed, 21 Apr 2010 05:01:15 -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 041D13A67E9 for ; Wed, 21 Apr 2010 05:01:12 -0700 (PDT) MIME-version: 1.0 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 <0L1800GG36PPDJ50@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 21 Apr 2010 14:01:01 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.52,250,1270418400"; d="sig'?scan'208";a="28791156" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-2.rz.rwth-aachen.de with ESMTP; Wed, 21 Apr 2010 14:01:02 +0200 Received: from [137.226.12.56] ([unknown] [137.226.12.56]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L180015S6PP7Q50@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Wed, 21 Apr 2010 14:01:01 +0200 (CEST) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-37--661193714 From: Alexander Zimmermann In-reply-to: <816145D8-3C62-4F28-AC93-FC7B1051B833@nokia.com> Date: Wed, 21 Apr 2010 14:01:05 +0200 Content-transfer-encoding: 7bit Message-id: <129BD33F-1E6B-43FD-9769-B0075044ED70@nets.rwth-aachen.de> References: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com> <05F0AC17-703E-4F25-8730-A88ACA4D8E6B@nokia.com> <01ac01cae12d$81d50640$96106f0a@china.huawei.com> <816145D8-3C62-4F28-AC93-FC7B1051B833@nokia.com> To: Lars Eggert X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1078) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? 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, 21 Apr 2010 12:01:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-37--661193714 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Am 21.04.2010 um 12:00 schrieb Lars Eggert: > Hi, >=20 > ... >=20 > Even proposals that are agnostic to link technology have issues, e.g., = Freeze TCP, which I cited since it sounded similar to your proposal. For = example, there is an implicit assumption that path characteristics = (available bandwidth, RTT, etc.) do not change during the freeze period = - when they do, the thawed connection can significantly overshoot along = the new path, or it can underperform (and will take a long time to probe = for extra capacity if it is in congestion avoidance mode). And = obviously, there is an assumption that you somehow know when to freeze = and thaw.=20 >=20 Exactly!!! This IMO the reason why TCP freeze would not work (in = general). Copied from RFC 2861: 3. Description "When a TCP sender has sufficient data available to fill the available = network capacity for that flow, cwnd and ssthresh get set to appropriate = values for the network conditions. When a TCP sender stops sending, the = flow stops sampling the network conditions, and so the value of the = congestion window may become inaccurate." BTW: Read the introduction of this RFC. It gave me an excellent insight = why TCP freeze is a bad idea... Alex= --Apple-Mail-37--661193714 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkvO6QIACgkQdyiq39b9uS6JRgCgtGPCPSj36XQ7JMTHHHWjO/iY NzYAmwbITAH27pZeCR0stcIjxmgQebzP =x3uL -----END PGP SIGNATURE----- --Apple-Mail-37--661193714-- From Xiangsong.Cui@huawei.com Wed Apr 21 21:15:26 2010 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 25B913A6ABD for ; Wed, 21 Apr 2010 21:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.707 X-Spam-Level: X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_20=-0.74, STOX_REPLY_TYPE=0.001] 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 ArLSiFvfxCer for ; Wed, 21 Apr 2010 21:15:25 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 8F6553A6ABB for ; Wed, 21 Apr 2010 21:15:20 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1900FNNFLEPX@szxga02-in.huawei.com> for tcpm@ietf.org; Thu, 22 Apr 2010 12:10:26 +0800 (CST) Received: from c00111037 ([10.111.16.150]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L1900CP3FLE4A@szxga02-in.huawei.com> for tcpm@ietf.org; Thu, 22 Apr 2010 12:10:26 +0800 (CST) Date: Thu, 22 Apr 2010 12:10:25 +0800 From: Xiangsong Cui To: Lars Eggert Message-id: <009601cae1d1$bcb03740$96106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00d601cae06c$5a4324c0$96106f0a@china.huawei.com> <05F0AC17-703E-4F25-8730-A88ACA4D8E6B@nokia.com> <01ac01cae12d$81d50640$96106f0a@china.huawei.com> <816145D8-3C62-4F28-AC93-FC7B1051B833@nokia.com> Cc: tcpm@ietf.org Subject: Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? 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, 22 Apr 2010 04:15:26 -0000 Hi Lars, Thanks for your detailed explanation! I can understand this item better now. Regards, Xiangsong ----- Original Message ----- From: "Lars Eggert" To: "Xiangsong Cui" Cc: Sent: Wednesday, April 21, 2010 6:00 PM Subject: Re: [tcpm] Discussion -- Pause/Resume mechanism on TCP ? Hi, On 2010-4-21, at 11:34, Xiangsong Cui wrote: > I also read some other papers about TCP over wireless link and I am a little confused. It seems that there are many researches and > energy on this topic for more than ten years, but it is not clear until now which solution is recommended by IETF, or I missed the > proposal? Since the TCP protocol is product of IETF, should IETF give some official suggestion on the applicability of TCP > extensions? So the mobile hosts and middle-boxes may follow that... you're correct in that there is no IETF recommendation in this space, although there is a large body of research work. In my view, the reason for this is mainly that none of the researchers have had the energy to seriously continue their work so that it could be published as an IETF recommendation. This is to some degree understandable, because the effort it takes may need to be spent on something that may not be academically publishable. For example, whereas it is sufficient for a research paper to show that benefits exists in some scenarios, for an IETF recommendation, we need to be sure that a proposal has no drawbacks, or at the very least that they are well-understood and easy to work around (e.g., by not using a proposed extension in those cases). Also, TCP is a general-purpose protocol. Optimizing its operation for a specific link technology implicitly assumes that that link technology will be used on the bottleneck link that mostly defines the path characteristics. That's a pretty strong assumption in general. Many folks have shown that TCP can be tuned in this way; not many have tried to determine whether there are drawbacks when a tuned TCP runs over a path where a different link technology is the bottleneck. Even proposals that are agnostic to link technology have issues, e.g., Freeze TCP, which I cited since it sounded similar to your proposal. For example, there is an implicit assumption that path characteristics (available bandwidth, RTT, etc.) do not change during the freeze period - when they do, the thawed connection can significantly overshoot along the new path, or it can underperform (and will take a long time to probe for extra capacity if it is in congestion avoidance mode). And obviously, there is an assumption that you somehow know when to freeze and thaw. In a nutshell, I believe there is no IETF recommendation in this space, because designing one that is often useful and overall not harmful and has sufficient benefits to offset the needed effort is harder than it first appears. Lars From Xiangsong.Cui@huawei.com Thu Apr 22 00:22:59 2010 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 24E5B3A68D0 for ; Thu, 22 Apr 2010 00:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.339 X-Spam-Level: X-Spam-Status: No, score=-0.339 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] 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 2mwY5Y1-VpT0 for ; Thu, 22 Apr 2010 00:22:54 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id B3BE23A6832 for ; Thu, 22 Apr 2010 00:22:53 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L19008BFOHURA@szxga02-in.huawei.com> for tcpm@ietf.org; Thu, 22 Apr 2010 15:22:42 +0800 (CST) Received: from c00111037 ([10.111.16.150]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L19005XUOHT7Y@szxga02-in.huawei.com> for tcpm@ietf.org; Thu, 22 Apr 2010 15:22:42 +0800 (CST) Date: Thu, 22 Apr 2010 15:22:40 +0800 From: Xiangsong Cui To: David Borman , tcpm@ietf.org Message-id: <00f301cae1ec$97f94e30$96106f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [tcpm] WGLC for MSS 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, 22 Apr 2010 07:22:59 -0000 Hi David, This is a late comment, about a typo. 3. MSS in to other RFCs 3.1 RFC-879 RFC-897 [RFC879] discusses the MSS option and other topics. In ^^^^^^^^ It seems should be RFC-879. Regards Xiangsong ----- Original Message ----- From: "David Borman" To: Sent: Friday, March 26, 2010 6:59 AM Subject: Re: [tcpm] WGLC for MSS document > On Aug 18, 2009, at 10:38 AM, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: > >> This note starts a 2-week Working Group Last Call on the TCPM document: >> http://tools.ietf.org/html/draft-ietf-tcpm-tcpmss-02 >> Please send any comments to the TCPM list. The WGLC will last until >> September 1. > > > I've finally finished updating the MSS document, and have uploaded it. > http://tools.ietf.org/html/draft-ietf-tcpm-tcpmss-03 > I believe I have addressed all the comments received during the Last Call, and have done some additional changes beyond that. > I've been discussing the document this week at the IETF with several people, and the results of those conversations are included > in this new draft. > > Because of the time lapse, and the number of changes that I've made to the document, let's extend the > WGLC to Thursday, April 8. > > Below are my responses to all the comments received during the original WGLC. > > -David Borman > > > On Aug 20, 2009, at 7:50 AM, Alexander Zimmermann wrote: > >> 1. Needs boilerplate update (Copyright section) > > Done. >> 2. IMHO in line 50: %s/to do about TCP options/to do about IP and TCP options/ > > Done. >> 3. Just one sentence later: "RFC-1122 [Braden89] attempted to clarify this in section 4.2.2.6, but >> there still seems to be confusion." What is the problem here with RFC 1122? Why does RFC 1122 >> does not manage to clarify the situation. I think one or two sentence more explanation would be >> great. > I've removed "in section 4.2.2.6", and replaced it with a reference to a new Appendix A that > has a more complete description of what is in RFC 1122. > >> >> Alex > > On Aug 20, 2009, at 11:28 AM, Joe Touch wrote: > > .... >> I'd like to suggest the following for this doc: >> >> MSSs can sometimes vary, as when used with variable compression, e.g., >> ROHC. The ROHC doc missed an opportunity to address the interaction of >> variable MSS with TCP, and this might be a good place to include a >> sentence or two on it, e.g. (IMO): >> >> - --- >> >> MSSs can sometimes vary, as when used with variable compression, e.g., >> ROHC [RFC5255]. It is tempting for TCP to want to advertise the largest >> possible MSS, to support the most efficient use of compressed payloads. >> Unfortunately, some compression schemes occasionally need to transmit >> full headers (and thus smaller payloads) to resynchronize state at their >> endpoint compressor/decompressors. If the largest MSS is advertised, TCP >> retransmission may interfere with compressor resynchonization. >> >> As a result, when effective MSS varies, TCP SHOULD compute its >> advertised MSS based on the smallest effective MSS. >> >> - --- >> >> Joe > > Added, with some rewording. > > > On Aug 20, 2009, at 12:59 PM, wrote: > >> Can't TCP MSS also vary across multipath environments? Strikes me >> that these are more common than header compression - which should >> be advertising conservative minimum MTUs for their link interfaces. >> >> >> > > Ok, this one I've gone round and round on this, including adding an entire Appendix to discuss issues of which MTU value to use > for calculating the MSS, the history of this, issues with multi-homed hosts, non-symetric routes, and making multiple > recommendations, based on the context. In the end it felt like it was getting out of control, as one thing lead to another and > the Appendix was getting quite large. In the end, I deleted the Appendix, and now have just one sentence: > > The determination of what MTU value should be used, > especially in the case of multihomed hosts, is beyond the scope of > this document. > > This document is about clarifying that you don't include IP and TCP options when figuring out what to put in the MSS option, it is > not about what MTU value to use when calculating the MSS option, so it is best to just not go down that path at all. That's not > to say that this isn't a topic that deserves discussion, but that it isn't the purpose of this document. > > On Aug 26, 2009, at 6:56 AM, Mark Allman wrote: > >> I am in general in favor of this document. But, this document is sorta >> confusing to me and so I'd vote "not ready" at the moment. >> >> The statement that the MSS advertisement should not include the bytes >> consumed by options is clear, but in the explanation of that rule. >> >> + I had to work through the table to figure out "length" on the y-axis >> was the overall packet length. > > Fixed. > >> + I find it strange that the table is left as the sole justification >> without even a little bit of prose that explains it. In fact, I >> would think a little prose instead of the table would make the whole >> thing more clear. >> >> + The other thing you might note is that the MSS advertisement cannot >> possibly capture the right number of option bytes for every packet >> in a connection because options are variable (e.g., SACK). So, even >> if one tries to capture option lengths in the header the length will >> still have to be hacked on the fly (or, you'll have to take a >> pessimal view of option usage as "using all of it"). > > I've added a paragraph that says that the MSS value, being fixed, can never accurately reflect all situations of IP and TCP > options, because by their very nature they are variable. > > > On Sep 3, 2009, at 7:37 AM, Danny McPherson wrote: > >> >> I agree with Marks's comments - in general I like the document >> (my colleague Aaron Campbell and I asked for and offered to write) >> something similar quite a while back). >> >> It is worth noting that the confusion isn't universal, at least, the >> Linux, NetBSD, and OpenBSD people got it right (options are not >> subtracted from the advertised MSS on these systems from our past >> research). >> >> RFC2385 is wrong, though: > ... > I've added a reference to this issue, and pointed out that RFC 2385 is wrong. I've also added a reference to the issue with > RFC-897, which mostly got the definition correct until the very last section of the document... :-) > > -David > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From william.allen.simpson@gmail.com Thu Apr 22 06:18:44 2010 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 3049328C134; Thu, 22 Apr 2010 06:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.21 X-Spam-Level: X-Spam-Status: No, score=-0.21 tagged_above=-999 required=5 tests=[AWL=-1.770, BAYES_20=-0.74, MANGLED_TOOL=2.3] 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 O1euL3k0ulrm; Thu, 22 Apr 2010 06:18:43 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 2274D28C138; Thu, 22 Apr 2010 06:17:48 -0700 (PDT) Received: by pvg7 with SMTP id 7so1185949pvg.31 for ; Thu, 22 Apr 2010 06:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:content-type :content-transfer-encoding; bh=LhZlAPSyp2ZBRrhx6/N5FFWJEftrgBKYa3s/+XxrRCE=; b=qEnMiAWMHDZjjrPce0dNU7hrIs9063YEMgVOHaDndCJOfMCiYhI+qT9k/zeWOBfpGG Yw9I7eZ+YHPx44rtLzMk3S6aCp3M5R5vYMwLl7kaEYfV93JqJmJTKV1Y5TaIxv1UkzwI rJyU6goi9LkvgTh05LOddg+jsqrLsZS+xObWI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; b=Purw/gHy9rbWK/HdYdbZToDCNzDGbKCT8BkihHO1z5imCkaqpY1q/IlCOV+Ty6zqBl GPqXWi8KbYXQUNVpcBwzACpiVlSdWiNYSR5jNsHIgLX07upXryjUcAcFTdefzLzCzpzN HMFvTQ66wsnhhsVYPOJxEIo3hxswBIWSWbGNA= Received: by 10.142.210.17 with SMTP id i17mr1596988wfg.83.1271942252862; Thu, 22 Apr 2010 06:17:32 -0700 (PDT) Received: from Wastrel.local (c-68-40-195-221.hsd1.mi.comcast.net [68.40.195.221]) by mx.google.com with ESMTPS id 21sm1457419iwn.11.2010.04.22.06.17.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 22 Apr 2010 06:17:31 -0700 (PDT) Message-ID: <4BD04C69.7010004@gmail.com> Date: Thu, 22 Apr 2010 09:17:29 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: rfc-ise@rfc-editor.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: TCP Modifications WG , Internet Engineering Steering Group Subject: [tcpm] draft-simpson-tcpct-02 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, 22 Apr 2010 13:18:44 -0000 A new version has been submitted for draft-simpson-tcpct: http://www.ietf.org/internet-drafts/draft-simpson-tcpct-02.txt On 4/1/10 9:44 AM, Lars Eggert wrote: # The ID is slated for discussion on the very next IESG telechat on April 8. # The IESG missed their self-imposed deadline for review. However, I've received a half-dozen comments during the past few weeks, including a WG chair, some area directors, and various hoi polloi. This is not a TCPM WG product. Here's a summary of the changes since -00. The major change to -01 was the restoration of an earlier, more complete listing of expected Length variants of cookies and cookie-less options. A minor change to -01 was some implementation notes from FreeBSD, which has much smarter syncookie handling than Linux. The major change to -02 was the *removal* of the Length variants again! (This is harder to notice, as they are simply no longer present.) Later reviewers found them confusing, as implementation is not required. The variants without cookies or without timestamps are intended only for use with authentication, "beyond the scope of this specification". A minor change to -02 is the addition of 128-bit timestamps, anticipating future NTP5 support. "Forewarned is forearmed." This change in format is fairly insignificant, as nobody yet supports 64-bit TCP Timestamps! Another change is hiding the SYN-only options in the header extension to inhibit middleware interference. There wasn't any actual testing that found this hypothetical problem, but it's not too painful (although this complicates the option generation code). See Appendix A examples. The trivial changes are format, reference, and wording nits. That we're down to wording nits indicates this is a mature specification! Please approve the IANA code points and RFC publication. From danny@tcb.net Thu Apr 22 06:40:48 2010 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 DCBDF3A6B5A for ; Thu, 22 Apr 2010 06:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 MsK8l+qiHmzm for ; Thu, 22 Apr 2010 06:40:46 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 4EC4A28C15F for ; Thu, 22 Apr 2010 06:39:44 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 47D3C2684E9; Thu, 22 Apr 2010 07:39:34 -0600 (MDT) Received: from 10-1-15-12.aa.arbor.net (204.181.64.1 [204.181.64.1]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Thu, 22 Apr 2010 07:39:33 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=204.181.64.1; client-port=5925; client-dnsfail=204.181.64.1: name server failure; syn-fingerprint=65535:48:1:64:M1360,N,W3,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Danny McPherson In-Reply-To: Date: Thu, 22 Apr 2010 07:39:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0401257A-0C93-4211-B618-B34552D8227D@tcb.net> References: To: David Borman X-Mailer: Apple Mail (2.1077) Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] Fwd: WGLC for MSS 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, 22 Apr 2010 13:40:49 -0000 [top post only] David,=20 You've accommodated my concerns with your update, thanks much! -danny On Apr 13, 2010, at 9:25 AM, David Borman wrote: > Sorry, I just realized that I only sent this reply to Alexander, and = not to the whole list. >=20 > -David Borman >=20 > Begin forwarded message: >=20 > From: David Borman > Date: March 31, 2010 11:03:53 AM CDT > To: Alexander Zimmermann > Subject: Re: [tcpm] WGLC for MSS document >=20 >=20 > On Mar 31, 2010, at 7:27 AM, Alexander Zimmermann wrote: >=20 >> Hi David, >>=20 >> I like the changes you have made. Especially, the history stuff you >> added (Sec 3, Appendix) is quite interesting for "young" guys like = me. >>=20 >> However, here are some remarks. Please note that these comments are >> somehow trivia. If you don't like the changes, forget about them. = What >> I really do not want is to block the progress. >>=20 >> * Sec 2, para 2: I would add references for the TCP IPv4/6 >> header lengths >>=20 >> * Appendix, last equation: I suggest to add the bounds into the = equation >> 576 <=3D EMTU_R - FixedIPhdrsize - FixedTCPhdrsize <=3D MTU >=20 > Actually, there is a different change that I think I should make: >=20 > network(s)". Thus, the MSS value to be sent in an MSS option must be > less than or equal to: >=20 > EMTU_R - FixedIPhdrsize - FixedTCPhdrsize >=20 > s/option must be/option should be/ >=20 > It is not required that the MSS value be <=3D the MTU of the = interface, it is perfectly OK to advertise an MSS value larger than the = MTU of the interface. This is especially true for a multi-homed host = with interfaces that have different MTUs. However, deciding what MTU = value to use to calculate the MSS value is not the purpose of this RFC, = the purpose of this RFC is to say that when you calculate the MSS, you = do not adjust it to account for IP or TCP options. Getting into the = discussion about what MTU value to use is a rat-hole that is not part of = this RFC, so I don't even discuss it. That's why this version of the = document has the final sentence in section 2: >=20 > The determination of what MTU value should be used, > especially in the case of multi-homed hosts, is beyond the scope = of > this document. >=20 > This is also in the appendix, so it is just additional commentary that = may be useful to the reader, the requirements are in the main body of = the document. >=20 >=20 >>=20 >> * Sec 4: IHO the explanation of the table is too implicit. >>=20 >> In the following, let's name the fields of the table like this: upper = left 1, >> upper right 2, lower left 3, lower right 4. >>=20 >> Right after the table, the draft said: >>=20 >> "Since the goal is to not send IP datagrams that have to be = fragmented, and >> packets sent with the constraints in the lower right of this grid = will cause >> IP fragmentation, the only way to guarantee that this doesn=92t = happen is for the >> data sender to decrease the TCP data length by the size of the IP and = TCP options" >>=20 >> Having read this, the following comes to my mind: I'm sitting in (4) = and I want to >> leave this state. The text said that only the transition to (2) is = possible. However, >> when I looked at the table, I thought: I can also go to (3) since the = table said here >> "Packets are the correct length". Bang! I got confused since the text = said, the >> *only* way is (2). But why? At this point I expected an explanation = why (3) is a >> bad idea? >=20 >>=20 >> Do you understand what I'm trying to say? Maybe I read the table = wrong. I read it >> like a transition diagram. Should I read it line by line, column by = column,...? >=20 >=20 > It isn't a state diagram, it's a grid showing the combinations of what = happens if the receiver does or doesn't adjust the MSS option to account = for options, and if the sender does or doesn't adjust to account for IP = options. The text says it all. If the sender doesn't adjust for the = options, then it can't be guaranteed that it won't generate packets that = are too big when it inserts options. So it should always adjust. And = since the sender is always adjusting, the receiver doesn't need to = modify the value in the MSS option to account for options. >=20 > Does that make sense? > -David >=20 >=20 >>=20 >>=20 >> Alex >>=20 >> Am 25.03.2010 um 23:59 schrieb David Borman: >>=20 >>> On Aug 18, 2009, at 10:38 AM, Eddy, Wesley M. (GRC-MS00)[Verizon] = wrote: >>>=20 >>>> This note starts a 2-week Working Group Last Call on the TCPM = document: >>>> http://tools.ietf.org/html/draft-ietf-tcpm-tcpmss-02 >>>> Please send any comments to the TCPM list. The WGLC will last = until >>>> September 1. >>>=20 >>>=20 >>> I've finally finished updating the MSS document, and have uploaded = it. >>> http://tools.ietf.org/html/draft-ietf-tcpm-tcpmss-03 >>> I believe I have addressed all the comments received during the Last = Call, and have done some additional changes beyond that. I've been = discussing the document this week at the IETF with several people, and = the results of those conversations are included in this new draft. >>>=20 >>> Because of the time lapse, and the number of changes that I've made = to the document, let's extend the >>> WGLC to Thursday, April 8. >>>=20 >>> Below are my responses to all the comments received during the = original WGLC. >>>=20 >>> -David Borman >>>=20 >>>=20 >>> On Aug 20, 2009, at 7:50 AM, Alexander Zimmermann wrote: >>>=20 >>>> 1. Needs boilerplate update (Copyright section) >>>=20 >>> Done. >>>> 2. IMHO in line 50: %s/to do about TCP options/to do about IP and = TCP options/ >>>=20 >>> Done. >>>> 3. Just one sentence later: "RFC-1122 [Braden89] attempted to = clarify this in section 4.2.2.6, but >>>> there still seems to be confusion." What is the problem here with = RFC 1122? Why does RFC 1122 >>>> does not manage to clarify the situation. I think one or two = sentence more explanation would be >>>> great. >>> I've removed "in section 4.2.2.6", and replaced it with a reference = to a new Appendix A that >>> has a more complete description of what is in RFC 1122. >>>=20 >>>>=20 >>>> Alex >>>=20 >>> On Aug 20, 2009, at 11:28 AM, Joe Touch wrote: >>>=20 >>> .... >>>> I'd like to suggest the following for this doc: >>>>=20 >>>> MSSs can sometimes vary, as when used with variable compression, = e.g., >>>> ROHC. The ROHC doc missed an opportunity to address the interaction = of >>>> variable MSS with TCP, and this might be a good place to include a >>>> sentence or two on it, e.g. (IMO): >>>>=20 >>>> - --- >>>>=20 >>>> MSSs can sometimes vary, as when used with variable compression, = e.g., >>>> ROHC [RFC5255]. It is tempting for TCP to want to advertise the = largest >>>> possible MSS, to support the most efficient use of compressed = payloads. >>>> Unfortunately, some compression schemes occasionally need to = transmit >>>> full headers (and thus smaller payloads) to resynchronize state at = their >>>> endpoint compressor/decompressors. If the largest MSS is = advertised, TCP >>>> retransmission may interfere with compressor resynchonization. >>>>=20 >>>> As a result, when effective MSS varies, TCP SHOULD compute its >>>> advertised MSS based on the smallest effective MSS. >>>>=20 >>>> - --- >>>>=20 >>>> Joe >>>=20 >>> Added, with some rewording. >>>=20 >>>=20 >>> On Aug 20, 2009, at 12:59 PM, = wrote: >>>=20 >>>> Can't TCP MSS also vary across multipath environments? Strikes me >>>> that these are more common than header compression - which should >>>> be advertising conservative minimum MTUs for their link interfaces. >>>>=20 >>>> >>>>=20 >>>=20 >>> Ok, this one I've gone round and round on this, including adding an = entire Appendix to discuss issues of which MTU value to use for = calculating the MSS, the history of this, issues with multi-homed hosts, = non-symetric routes, and making multiple recommendations, based on the = context. In the end it felt like it was getting out of control, as one = thing lead to another and the Appendix was getting quite large. In the = end, I deleted the Appendix, and now have just one sentence: >>>=20 >>> The determination of what MTU value should be used, >>> especially in the case of multihomed hosts, is beyond the scope = of >>> this document. >>>=20 >>> This document is about clarifying that you don't include IP and TCP = options when figuring out what to put in the MSS option, it is not about = what MTU value to use when calculating the MSS option, so it is best to = just not go down that path at all. That's not to say that this isn't a = topic that deserves discussion, but that it isn't the purpose of this = document. >>>=20 >>> On Aug 26, 2009, at 6:56 AM, Mark Allman wrote: >>>=20 >>>> I am in general in favor of this document. But, this document is = sorta >>>> confusing to me and so I'd vote "not ready" at the moment. =20 >>>>=20 >>>> The statement that the MSS advertisement should not include the = bytes >>>> consumed by options is clear, but in the explanation of that rule. >>>>=20 >>>> + I had to work through the table to figure out "length" on the = y-axis >>>> was the overall packet length. >>>=20 >>> Fixed. >>>=20 >>>> + I find it strange that the table is left as the sole = justification >>>> without even a little bit of prose that explains it. In fact, I >>>> would think a little prose instead of the table would make the = whole >>>> thing more clear. >>>>=20 >>>> + The other thing you might note is that the MSS advertisement = cannot >>>> possibly capture the right number of option bytes for every packet >>>> in a connection because options are variable (e.g., SACK). So, = even >>>> if one tries to capture option lengths in the header the length = will >>>> still have to be hacked on the fly (or, you'll have to take a >>>> pessimal view of option usage as "using all of it"). >>>=20 >>> I've added a paragraph that says that the MSS value, being fixed, = can never accurately reflect all situations of IP and TCP options, = because by their very nature they are variable. >>>=20 >>>=20 >>> On Sep 3, 2009, at 7:37 AM, Danny McPherson wrote: >>>=20 >>>>=20 >>>> I agree with Marks's comments - in general I like the document >>>> (my colleague Aaron Campbell and I asked for and offered to write) >>>> something similar quite a while back). >>>>=20 >>>> It is worth noting that the confusion isn't universal, at least, = the >>>> Linux, NetBSD, and OpenBSD people got it right (options are not >>>> subtracted from the advertised MSS on these systems from our past >>>> research). >>>>=20 >>>> RFC2385 is wrong, though: >>> ... >>> I've added a reference to this issue, and pointed out that RFC 2385 = is wrong. I've also added a reference to the issue with RFC-897, which = mostly got the definition correct until the very last section of the = document... :-) >>>=20 >>> -David >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@ISI.EDU Mon Apr 26 14:55:43 2010 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 9B17C28C1A1 for ; Mon, 26 Apr 2010 14:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 dbF-TNc2XB67 for ; Mon, 26 Apr 2010 14:55:41 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 49CC928C170 for ; Mon, 26 Apr 2010 14:55:41 -0700 (PDT) Received: from [75.212.237.89] (89.sub-75-212-237.myvzw.com [75.212.237.89]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o3QLq0Ym023373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Apr 2010 14:52:12 -0700 (PDT) Message-ID: <4BD60AFF.6080403@isi.edu> Date: Mon, 26 Apr 2010 14:51:59 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Danny McPherson References: <0401257A-0C93-4211-B618-B34552D8227D@tcb.net> In-Reply-To: <0401257A-0C93-4211-B618-B34552D8227D@tcb.net> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3F7CAD8FF938F87246B0B128" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org WG" , David Borman Subject: Re: [tcpm] Fwd: WGLC for MSS 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: Mon, 26 Apr 2010 21:55:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3F7CAD8FF938F87246B0B128 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable [top post only as well] Same here. My concerns have been addressed. Joe Danny McPherson wrote: > [top post only] >=20 > David,=20 > You've accommodated my concerns with your update, thanks > much! >=20 > -danny >=20 >=20 > On Apr 13, 2010, at 9:25 AM, David Borman wrote: >=20 >> Sorry, I just realized that I only sent this reply to Alexander, and n= ot to the whole list. >> >> -David Borman >> >> Begin forwarded message: >> >> From: David Borman >> Date: March 31, 2010 11:03:53 AM CDT >> To: Alexander Zimmermann >> Subject: Re: [tcpm] WGLC for MSS document >> >> >> On Mar 31, 2010, at 7:27 AM, Alexander Zimmermann wrote: >> >>> Hi David, >>> >>> I like the changes you have made. Especially, the history stuff you >>> added (Sec 3, Appendix) is quite interesting for "young" guys like me= =2E >>> >>> However, here are some remarks. Please note that these comments are >>> somehow trivia. If you don't like the changes, forget about them. Wha= t >>> I really do not want is to block the progress. >>> >>> * Sec 2, para 2: I would add references for the TCP IPv4/6 >>> header lengths >>> >>> * Appendix, last equation: I suggest to add the bounds into the equat= ion >>> 576 <=3D EMTU_R - FixedIPhdrsize - FixedTCPhdrsize <=3D MTU >> Actually, there is a different change that I think I should make: >> >> network(s)". Thus, the MSS value to be sent in an MSS option must be= >> less than or equal to: >> >> EMTU_R - FixedIPhdrsize - FixedTCPhdrsize >> >> s/option must be/option should be/ >> >> It is not required that the MSS value be <=3D the MTU of the interface= , it is perfectly OK to advertise an MSS value larger than the MTU of the= interface. This is especially true for a multi-homed host with interfac= es that have different MTUs. However, deciding what MTU value to use to = calculate the MSS value is not the purpose of this RFC, the purpose of th= is RFC is to say that when you calculate the MSS, you do not adjust it to= account for IP or TCP options. Getting into the discussion about what M= TU value to use is a rat-hole that is not part of this RFC, so I don't ev= en discuss it. That's why this version of the document has the final sen= tence in section 2: >> >> The determination of what MTU value should be used, >> especially in the case of multi-homed hosts, is beyond the scope of >> this document. >> >> This is also in the appendix, so it is just additional commentary that= may be useful to the reader, the requirements are in the main body of th= e document. >> >> >>> * Sec 4: IHO the explanation of the table is too implicit. >>> >>> In the following, let's name the fields of the table like this: upper= left 1, >>> upper right 2, lower left 3, lower right 4. >>> >>> Right after the table, the draft said: >>> >>> "Since the goal is to not send IP datagrams that have to be fragmente= d, and >>> packets sent with the constraints in the lower right of this grid wil= l cause >>> IP fragmentation, the only way to guarantee that this doesn=92t happe= n is for the >>> data sender to decrease the TCP data length by the size of the IP and= TCP options" >>> >>> Having read this, the following comes to my mind: I'm sitting in (4) = and I want to >>> leave this state. The text said that only the transition to (2) is po= ssible. However, >>> when I looked at the table, I thought: I can also go to (3) since the= table said here >>> "Packets are the correct length". Bang! I got confused since the text= said, the >>> *only* way is (2). But why? At this point I expected an explanation w= hy (3) is a >>> bad idea? >>> Do you understand what I'm trying to say? Maybe I read the table wron= g. I read it >>> like a transition diagram. Should I read it line by line, column by c= olumn,...? >> >> It isn't a state diagram, it's a grid showing the combinations of what= happens if the receiver does or doesn't adjust the MSS option to account= for options, and if the sender does or doesn't adjust to account for IP = options. The text says it all. If the sender doesn't adjust for the opt= ions, then it can't be guaranteed that it won't generate packets that are= too big when it inserts options. So it should always adjust. And since= the sender is always adjusting, the receiver doesn't need to modify the = value in the MSS option to account for options. >> >> Does that make sense? >> -David >> >> >>> >>> Alex >>> >>> Am 25.03.2010 um 23:59 schrieb David Borman: >>> >>>> On Aug 18, 2009, at 10:38 AM, Eddy, Wesley M. (GRC-MS00)[Verizon] wr= ote: >>>> >>>>> This note starts a 2-week Working Group Last Call on the TCPM docum= ent: >>>>> http://tools.ietf.org/html/draft-ietf-tcpm-tcpmss-02 >>>>> Please send any comments to the TCPM list. The WGLC will last unti= l >>>>> September 1. >>>> >>>> I've finally finished updating the MSS document, and have uploaded i= t. >>>> http://tools.ietf.org/html/draft-ietf-tcpm-tcpmss-03 >>>> I believe I have addressed all the comments received during the Last= Call, and have done some additional changes beyond that. I've been disc= ussing the document this week at the IETF with several people, and the re= sults of those conversations are included in this new draft. >>>> >>>> Because of the time lapse, and the number of changes that I've made = to the document, let's extend the >>>> WGLC to Thursday, April 8. >>>> >>>> Below are my responses to all the comments received during the origi= nal WGLC. >>>> >>>> -David Borman >>>> >>>> >>>> On Aug 20, 2009, at 7:50 AM, Alexander Zimmermann wrote: >>>> >>>>> 1. Needs boilerplate update (Copyright section) >>>> Done. >>>>> 2. IMHO in line 50: %s/to do about TCP options/to do about IP and T= CP options/ >>>> Done. >>>>> 3. Just one sentence later: "RFC-1122 [Braden89] attempted to clari= fy this in section 4.2.2.6, but >>>>> there still seems to be confusion." What is the problem here with R= FC 1122? Why does RFC 1122 >>>>> does not manage to clarify the situation. I think one or two senten= ce more explanation would be >>>>> great. >>>> I've removed "in section 4.2.2.6", and replaced it with a reference = to a new Appendix A that >>>> has a more complete description of what is in RFC 1122. >>>> >>>>> Alex >>>> On Aug 20, 2009, at 11:28 AM, Joe Touch wrote: >>>> >>>> .... >>>>> I'd like to suggest the following for this doc: >>>>> >>>>> MSSs can sometimes vary, as when used with variable compression, e.= g., >>>>> ROHC. The ROHC doc missed an opportunity to address the interaction= of >>>>> variable MSS with TCP, and this might be a good place to include a >>>>> sentence or two on it, e.g. (IMO): >>>>> >>>>> - --- >>>>> >>>>> MSSs can sometimes vary, as when used with variable compression, e.= g., >>>>> ROHC [RFC5255]. It is tempting for TCP to want to advertise the lar= gest >>>>> possible MSS, to support the most efficient use of compressed paylo= ads. >>>>> Unfortunately, some compression schemes occasionally need to transm= it >>>>> full headers (and thus smaller payloads) to resynchronize state at = their >>>>> endpoint compressor/decompressors. If the largest MSS is advertised= , TCP >>>>> retransmission may interfere with compressor resynchonization. >>>>> >>>>> As a result, when effective MSS varies, TCP SHOULD compute its >>>>> advertised MSS based on the smallest effective MSS. >>>>> >>>>> - --- >>>>> >>>>> Joe >>>> Added, with some rewording. >>>> >>>> >>>> On Aug 20, 2009, at 12:59 PM, wrote: >>>> >>>>> Can't TCP MSS also vary across multipath environments? Strikes me >>>>> that these are more common than header compression - which should >>>>> be advertising conservative minimum MTUs for their link interfaces.= >>>>> >>>>> >>>>> >>>> Ok, this one I've gone round and round on this, including adding an = entire Appendix to discuss issues of which MTU value to use for calculati= ng the MSS, the history of this, issues with multi-homed hosts, non-symet= ric routes, and making multiple recommendations, based on the context. I= n the end it felt like it was getting out of control, as one thing lead t= o another and the Appendix was getting quite large. In the end, I delete= d the Appendix, and now have just one sentence: >>>> >>>> The determination of what MTU value should be used, >>>> especially in the case of multihomed hosts, is beyond the scope of >>>> this document. >>>> >>>> This document is about clarifying that you don't include IP and TCP = options when figuring out what to put in the MSS option, it is not about = what MTU value to use when calculating the MSS option, so it is best to j= ust not go down that path at all. That's not to say that this isn't a to= pic that deserves discussion, but that it isn't the purpose of this docum= ent. >>>> >>>> On Aug 26, 2009, at 6:56 AM, Mark Allman wrote: >>>> >>>>> I am in general in favor of this document. But, this document is s= orta >>>>> confusing to me and so I'd vote "not ready" at the moment. =20 >>>>> >>>>> The statement that the MSS advertisement should not include the byt= es >>>>> consumed by options is clear, but in the explanation of that rule. >>>>> >>>>> + I had to work through the table to figure out "length" on the y-a= xis >>>>> was the overall packet length. >>>> Fixed. >>>> >>>>> + I find it strange that the table is left as the sole justificatio= n >>>>> without even a little bit of prose that explains it. In fact, I >>>>> would think a little prose instead of the table would make the whol= e >>>>> thing more clear. >>>>> >>>>> + The other thing you might note is that the MSS advertisement cann= ot >>>>> possibly capture the right number of option bytes for every packet >>>>> in a connection because options are variable (e.g., SACK). So, eve= n >>>>> if one tries to capture option lengths in the header the length wil= l >>>>> still have to be hacked on the fly (or, you'll have to take a >>>>> pessimal view of option usage as "using all of it"). >>>> I've added a paragraph that says that the MSS value, being fixed, ca= n never accurately reflect all situations of IP and TCP options, because = by their very nature they are variable. >>>> >>>> >>>> On Sep 3, 2009, at 7:37 AM, Danny McPherson wrote: >>>> >>>>> I agree with Marks's comments - in general I like the document >>>>> (my colleague Aaron Campbell and I asked for and offered to write) >>>>> something similar quite a while back). >>>>> >>>>> It is worth noting that the confusion isn't universal, at least, th= e >>>>> Linux, NetBSD, and OpenBSD people got it right (options are not >>>>> subtracted from the advertised MSS on these systems from our past >>>>> research). >>>>> >>>>> RFC2385 is wrong, though: >>>> ... >>>> I've added a reference to this issue, and pointed out that RFC 2385 = is wrong. I've also added a reference to the issue with RFC-897, which m= ostly got the definition correct until the very last section of the docum= ent... :-) >>>> >>>> -David >>>> _______________________________________________ >>>> 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 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------enig3F7CAD8FF938F87246B0B128 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkvWCv8ACgkQE5f5cImnZrvvggCfTWwaWEqDo7x7PObAjp0z2NET EpIAoLoDGvfOyFzt+UfF6EEaVO7mPZRv =soXV -----END PGP SIGNATURE----- --------------enig3F7CAD8FF938F87246B0B128-- From wwwrun@rfc-editor.org Mon Apr 26 16:50:28 2010 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 869FB28C194; Mon, 26 Apr 2010 16:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 KxZhy+l1vRTC; Mon, 26 Apr 2010 16:50:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 4BF513A69EA; Mon, 26 Apr 2010 16:50:26 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A8B1BE07E8; Mon, 26 Apr 2010 16:50:14 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100426235014.A8B1BE07E8@rfc-editor.org> Date: Mon, 26 Apr 2010 16:50:14 -0700 (PDT) Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 5827 on Early Retransmit for and Stream Control Transmission Protocol (SCTP) 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, 26 Apr 2010 23:50:28 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5827 Title: Early Retransmit for and Stream Control Transmission Protocol (SCTP) Author: M. Allman, K. Avrachenkov, U. Ayesta, J. Blanton, P. Hurtig Status: Experimental Stream: IETF Date: April 2010 Mailbox: mallman@icir.org, k.avrachenkov@sophia.inria.fr, urtzi@laas.fr, jblanton@irg.cs.ohiou.edu, per.hurtig@kau.se Pages: 15 Characters: 35383 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-early-rexmt-04.txt URL: http://www.rfc-editor.org/rfc/rfc5827.txt This document proposes a new mechanism for TCP and Stream Control Transmission Protocol (SCTP) that can be used to recover lost segments when a connection's congestion window is small. The "Early Retransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission. This allows the transport to use fast retransmit to recover segment losses that would otherwise require a lengthy retransmission timeout. [STANDARDS TRACK] This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Mon Apr 26 17:58:31 2010 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 A708C3A69FD; Mon, 26 Apr 2010 17:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 9UNCWPuN1vJn; Mon, 26 Apr 2010 17:58:30 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id D4DFF3A686E; Mon, 26 Apr 2010 17:58:30 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 54528E07E5; Mon, 26 Apr 2010 17:58:19 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100427005819.54528E07E5@rfc-editor.org> Date: Mon, 26 Apr 2010 17:58:19 -0700 (PDT) Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] Corrected Announcement: RFC 5827 on Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP) 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, 27 Apr 2010 00:58:31 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5827 Title: Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP) Author: M. Allman, K. Avrachenkov, U. Ayesta, J. Blanton, P. Hurtig Status: Experimental Stream: IETF Date: April 2010 Mailbox: mallman@icir.org, k.avrachenkov@sophia.inria.fr, urtzi@laas.fr, jblanton@irg.cs.ohiou.edu, per.hurtig@kau.se Pages: 15 Characters: 35383 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-early-rexmt-04.txt URL: http://www.rfc-editor.org/rfc/rfc5827.txt This document proposes a new mechanism for TCP and Stream Control Transmission Protocol (SCTP) that can be used to recover lost segments when a connection's congestion window is small. The "Early Retransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission. This allows the transport to use fast retransmit to recover segment losses that would otherwise require a lengthy retransmission timeout. [STANDARDS TRACK] This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From mallman@icir.org Mon Apr 26 20:16:39 2010 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 92A173A6A08 for ; Mon, 26 Apr 2010 20:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.864 X-Spam-Level: X-Spam-Status: No, score=-3.864 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_50=0.001, 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 7evxt+KSWH9I for ; Mon, 26 Apr 2010 20:16:38 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id A080228C0FE for ; Mon, 26 Apr 2010 20:16:33 -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 o3R3GJNQ018973; Mon, 26 Apr 2010 20:16:19 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 661E0F22DD7; Mon, 26 Apr 2010 23:16:19 -0400 (EDT) To: Fred Baker From: Mark Allman In-Reply-To: <1E5DD920-1E18-4F76-B724-5355431CB4DD@cisco.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Friend Of The Devil MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma22275-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 26 Apr 2010 23:16:19 -0400 Sender: mallman@icir.org Message-Id: <20100427031619.661E0F22DD7@lawyers.icir.org> Cc: jblanton@masaka.cs.ohiou.edu, tcpm@ietf.org, k.avrachenkov@sophia.inria.fr Subject: Re: [tcpm] RFC 5827 on Early Retransmit for and Stream Control Transmission Protocol (SCTP) 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, 27 Apr 2010 03:16:39 -0000 ----------ma22275-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > In cases in which cwnd < 4, it seems like your biggest concern is to > elicit the information necessary to trigger the retransmission without > unnecessarily burdening the path. That is in essence why we use three > dup-acks as a trigger - it is "enough" information to ensure that with > high probability it is not being triggered by simple packet > reordering. > > Would it make sense to, when cwnd < 4 or all of the data available to > transmit is in flight, in response to a SACK, send a segment > containing exactly the TCP header, and one byte of SACKed data? The > receipt of the SACK says that it is highly likely that the missing > segment cleared the bottleneck, and would trigger an additional > dup-ack containing the SACK record in question (which might trigger > another of the same type of segment). If the missing segment is in > fact lost, doing that would allow you to trigger three dup-acks in > three RTTs even if you only had two segments outstanding (cwnd=2 or > that's all the data you have). You only take the RTO if you literally > have a single segment outstanding. If the missing segment in fact > arrived but the ACK was lost, it would trigger the ACK. My quick response is ... - ER explicitly defers to Limited Transmit (RFC 3042) when possible, which is sorta what you describe, but not with dummy sorts of packets, but with packets off the top. But, the point is the same---to try to drive the ACK process to a less ambiguous state. - I am not a big fan of dummy packets that really don't accomplish any work [*] (and, not just here; they've been proposed in a number of contexts). My mental model says one of these packets you sketch above is about as much work as a data carrying packet and so why not just retransmit and be done with it? Yeah, if we're wrong because of small scale reordering then we needlessly injected a packet. But, using the scheme above to try to better ensure the right action is taken we also injected a packet (or two). And, in either case, the cwnd is so small cutting it isn't a huge deal, it seems to me. [*] By work I mean in the context transfer process, not in terms of the underlying mechanisms to get that done. So, in my mind "work" == data packets or their ACKs and not control things such as you sketch. allman ----------ma22275-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkvWVwMACgkQWyrrWs4yIs67/ACcDmO5vcORvDb1J7oHVjeGdgMU R+sAnjHJQCP3lQDjClqQAvIZtCWk3QjD =t2Ta -----END PGP SIGNATURE----- ----------ma22275-1-- From mallman@icir.org Mon Apr 26 21:18:36 2010 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 5184328C0FE for ; Mon, 26 Apr 2010 21:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[AWL=1.402, BAYES_00=-2.599, 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 xBQT08ULdQ-4 for ; Mon, 26 Apr 2010 21:18:26 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id E99F03A6883 for ; Mon, 26 Apr 2010 21:18:22 -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 o3R4I89p023851; Mon, 26 Apr 2010 21:18:09 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id D6F51F24164; Tue, 27 Apr 2010 00:18:08 -0400 (EDT) To: Fred Baker From: Mark Allman In-Reply-To: <8D6E7279-21DC-44CC-A623-671A18D951C3@cisco.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Friend Of The Devil MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma25984-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 27 Apr 2010 00:18:08 -0400 Sender: mallman@icir.org Message-Id: <20100427041808.D6F51F24164@lawyers.icir.org> Cc: jblanton@masaka.cs.ohiou.edu, tcpm@ietf.org, k.avrachenkov@sophia.inria.fr Subject: Re: [tcpm] RFC 5827 on Early Retransmit for and Stream Control Transmission Protocol (SCTP) 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, 27 Apr 2010 04:18:36 -0000 ----------ma25984-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > I'm sure you're wiser than I. Well. > I'm just thinking that in a context where cwnd<4 (pretty normal at my > house when uploading to Picasa, which is an obvious file-transfer > test, because the RTT is relatively short) sending after two dup-acks > inserts a relatively large delay on the line in the event that it is a > wrong guess. Why? I don't follow. > If you're going to increase the chance of guessing wrong, it seems > like you might want to minimize the side-effect of being wrong. The side effect seems to me to be you inject an additional packet into the network and cut the cwnd by a packet or two---which is readily recouped (esp. if the RTT is short). What else is there? allman ----------ma25984-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkvWZYAACgkQWyrrWs4yIs6rfQCdE1VG09MClI64juVYS6Pqt4nD P2gAn36B37Rx7nRSxps19dGWdTju/HSD =mbWY -----END PGP SIGNATURE----- ----------ma25984-1-- From lars.eggert@nokia.com Tue Apr 27 01:43:32 2010 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 2F9BF3A696D for ; Tue, 27 Apr 2010 01:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.446 X-Spam-Level: X-Spam-Status: No, score=-6.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, 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 QSq3qhfL8RWc for ; Tue, 27 Apr 2010 01:43:31 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 58A5E3A6969 for ; Tue, 27 Apr 2010 01:43:28 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3R8gcuu024394 for ; Tue, 27 Apr 2010 03:43:15 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Apr 2010 11:43:05 +0300 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Apr 2010 11:43:04 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3R8h42q019760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Apr 2010 11:43:04 +0300 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96 at fit.nokia.com Content-Type: multipart/signed; boundary=Apple-Mail-49--154686176; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 27 Apr 2010 09:42:53 +0100 References: <20100426191447.55E2C28C0F4@core3.amsl.com> To: "tcpm@ietf.org Extensions" Message-Id: <4D03DBD4-2A0D-4820-AEE1-154B79499BE4@nokia.com> Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Tue, 27 Apr 2010 11:42:54 +0300 (EEST) X-OriginalArrivalTime: 27 Apr 2010 08:43:04.0600 (UTC) FILETIME=[A706E980:01CAE5E5] X-Nokia-AV: Clean Subject: [tcpm] Fwd: Experimental RFC to be: draft-simpson-tcpct-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, 27 Apr 2010 08:43:32 -0000 --Apple-Mail-49--154686176 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI, since this ID has been discussed on this list. Begin forwarded message: > From: The IESG > Date: April 26, 2010 20:14:47 GMT+01:00 > To: RFC Editor > Cc: "iana@iana.org" , The IESG , = "ietf-announce@ietf.org" > Subject: Re: Experimental RFC to be: draft-simpson-tcpct-02.txt >=20 > The IESG has no problem with the publication of 'TCP Cookie = Transactions (TCPCT)' as an Experimental = RFC. >=20 > The IESG would also like the IRSG or RFC-Editor to review the comments = in=20 > the datatracker=20 > = (https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D19765&rfc_flag=3D0)=20 > related to this document and determine whether or not they merit=20 > incorporation into the document. Comments may exist in both the ballot=20= > and the comment log.=20 >=20 > The IESG contact person is Lars Eggert. >=20 > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-simpson-tcpct-02.txt >=20 >=20 > The process for such documents is described at = http://www.rfc-editor.org/indsubs.html. >=20 > Thank you, >=20 > The IESG Secretary >=20 > RFC Editor and IANA Note >=20 > TCP Option numbers are assigned following an "IESG Approval" or > "Standards Action" process [RFC2780]. The ID draft-simpson-tcpct is a > technical description to support a request to the IESG to approve the > assignment of two TCP Option numbers for the "TCP Cookie Option" and = the > "TCP Timestamps Extended Option". It has also been submitted to the = RFC > Editor for publication on the Independent Stream. >=20 > IESG members and external TCP and security experts reviewed > draft-simpson-tcpct for conflicts with the IETF standards process or = work > done in the IETF community [RFC5742], and to determine whether an IANA > assignment of the two requested TCP Option numbers should be approved = by > the IESG. [RFC5226] states the following conditions for an IANA = assignment > by IESG Approval: >=20 >> IESG Approval is not intended to be used often or as a >> "common case"; indeed, it has seldom been used in practice >> during the period RFC 2434 was in effect. Rather, it is >> intended to be available in conjunction with other policies >> as a fall-back mechanism in the case where one of the other >> allowable approval mechanisms cannot be employed in a timely >> fashion or for some other compelling reason. IESG Approval >> is not intended to circumvent the public review processes >> implied by other policies that could have been employed for >> a particular assignment. IESG Approval would be >> appropriate, however, in cases where expediency is desired >> and there is strong consensus for making the assignment >> (e.g., WG consensus). >>=20 >> The following guidelines are suggested for any evaluation >> under IESG Approval: >>=20 >> - The IESG can (and should) reject a request if another path >> for registration is available that is more appropriate and >> there is no compelling reason to use that path. >>=20 >> - Before approving a request, the community should be >> consulted, via a "call for comments" that provides as much >> information as is reasonably possible about the request. >=20 > Based on this review, the IESG has decided that at this time it will = not > approve the request for the assignment of two TCP Option numbers for = the > mechanisms described in draft-simpson-tcpct. The IESG notes that a = more > appropriate path for the registration is available under [RFC2780], > namely, publication of a Standards Track RFC, typically produced by an > IETF working group ("Standards Action"). The IESG also notes that no > strong consensus exists in the IETF community that expediency is = desired > to assign these TCP Option numbers via IESG Approval. >=20 > The IESG recommends that the authors of draft-simpson-tcpct submit = their > draft as a proposed work item for the TCP Maintenance and Minor = Extensions > (TCPM) working group, instead of pursuing publication on the = Independent > Stream, with the intent of producing a Standards Track document. >=20 > If the authors instead decide to pursue publication on the Independent > Stream, the IESG wishes to inform the RFC Editor that two conditions = would > need to be met: >=20 > (1) The (unnumbered) "IANA Considerations" section on page 26 is = removed > by the RFC Editor prior to publication, because no IANA assignment of = TCP > Option numbers has occurred. In place of that section, the IESG = suggests > informing readers of the document that two TCP Option numbers are = already > reserved for general experimental use under the rules laid out in > [RFC4727] and [RFC3692], Section 1. Such values reserved for = experimental > use are never to be made permanent; permanent assignments should be > obtained through standard processes. Experimental numbers are intended = for > experimentation and testing and are not intended for wide or general > deployments. >=20 > (2) The text in Section 3 is changed such that it no longer refers to > unassigned TCP Option number values. Instead, the IESG suggests = referring > readers to the modified IANA Considerations section discussing the > availability of TCP Option numbers for general experimentation, which = can > be used for this experiment. >=20 > If the authors decide to pursue publication on the Independent Stream = and > the two changes above are made to the document, the IESG wishes to = inform > the RFC Editor that following Section 3 of [RFC5742]: >=20 > 2. The IESG has concluded that this work is related to IETF work = done > in WG TCPM, but this relationship does not prevent publishing. >=20 > publication on the Independent Stream may occur. >=20 --Apple-Mail-49--154686176 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDQyNzA4NDI1M1owIwYJKoZIhvcNAQkEMRYEFKZ2aG/PGQl0izvoY9VWRkqyqwqnMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQDXMw5XvSqBzV7erGF3ulqEqdP6cJoL+dYobgsYgWcU5xd2EBTfE4FnosoAm08kVAX4kyhn eULlyecQZabrfNdt4kceBD3FC8MAod1LL7WP+GKxttIfWY4mAgeurPsir4g5ZULUpQKnnc2dfCv5 myh/mAOnoKyv7hRXwxY1/UxiyelyX/Hud78knA7lvw9ipYgIsvPbziY0FiW6H4mi8QRoMSVcEEnl Akr/25omD7TnGsuhWHxLiM84jG2U/alXkoX+M9OWdTw6+16BmBmLUbnVPkKVEsJN80Gh7vbkvrk7 fqzUuBoZrOa6gHpt+v/NdiHEB7gACCl9m2CTt042KVDoAAAAAAAA --Apple-Mail-49--154686176-- From fred@cisco.com Mon Apr 26 20:00:41 2010 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 87AFA3A6B6E for ; Mon, 26 Apr 2010 20:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.247 X-Spam-Level: X-Spam-Status: No, score=-100.247 tagged_above=-999 required=5 tests=[AWL=2.352, 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 gONHqxiMW-Ga for ; Mon, 26 Apr 2010 20:00:40 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id F03EE3A6949 for ; Mon, 26 Apr 2010 20:00:39 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMBAJfv1UuQ/uCWiWdsb2JhbACcRhUBAQEKCxERBhykcpoVhQsEjxg X-IronPort-AV: E=Sophos;i="4.52,277,1270425600"; d="scan'208";a="6237139" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 27 Apr 2010 02:23:36 +0000 Received: from [10.10.35.113] (ams3-vpn-dhcp1091.cisco.com [10.61.68.67]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3R30OuS022402; Tue, 27 Apr 2010 03:00:24 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <20100426235014.A8B1BE07E8@rfc-editor.org> Date: Tue, 27 Apr 2010 04:00:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1E5DD920-1E18-4F76-B724-5355431CB4DD@cisco.com> References: <20100426235014.A8B1BE07E8@rfc-editor.org> To: jblanton@irg.cs.ohiou.edu, k.avrachenkov@sophia.inria.fr, Mark Allman , per.hurtig@kau.se, urtzi@laas.fr X-Mailer: Apple Mail (2.1078) X-Mailman-Approved-At: Tue, 27 Apr 2010 08:18:41 -0700 Cc: tcpm@ietf.org Subject: Re: [tcpm] RFC 5827 on Early Retransmit for and Stream Control Transmission Protocol (SCTP) 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, 27 Apr 2010 03:00:41 -0000 Thinking out loud... In cases in which cwnd < 4, it seems like your biggest concern is to = elicit the information necessary to trigger the retransmission without = unnecessarily burdening the path. That is in essence why we use three = dup-acks as a trigger - it is "enough" information to ensure that with = high probability it is not being triggered by simple packet reordering.=20= Would it make sense to, when cwnd < 4 or all of the data available to = transmit is in flight, in response to a SACK, send a segment containing = exactly the TCP header, and one byte of SACKed data? The receipt of the = SACK says that it is highly likely that the missing segment cleared the = bottleneck, and would trigger an additional dup-ack containing the SACK = record in question (which might trigger another of the same type of = segment). If the missing segment is in fact lost, doing that would allow = you to trigger three dup-acks in three RTTs even if you only had two = segments outstanding (cwnd=3D2 or that's all the data you have). You = only take the RTO if you literally have a single segment outstanding. If = the missing segment in fact arrived but the ACK was lost, it would = trigger the ACK. On Apr 27, 2010, at 12:50 AM, rfc-editor@rfc-editor.org wrote: >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 5827 >=20 > Title: Early Retransmit for and Stream=20 > Control Transmission Protocol (SCTP)=20 > Author: M. Allman, K. Avrachenkov, > U. Ayesta, J. Blanton, > P. Hurtig > Status: Experimental > Stream: IETF > Date: April 2010 > Mailbox: mallman@icir.org,=20 > k.avrachenkov@sophia.inria.fr,=20 > urtzi@laas.fr, jblanton@irg.cs.ohiou.edu,=20 > per.hurtig@kau.se > Pages: 15 > Characters: 35383 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-tcpm-early-rexmt-04.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc5827.txt >=20 > This document proposes a new mechanism for TCP and Stream Control=20 > Transmission Protocol (SCTP) that can be used to recover lost segments=20= > when a connection's congestion window is small. The "Early = Retransmit"=20 > mechanism allows the transport to reduce, in certain special=20 > circumstances, the number of duplicate acknowledgments required to = trigger=20 > a fast retransmission. This allows the transport to use fast = retransmit=20 > to recover segment losses that would otherwise require a lengthy=20 > retransmission timeout. [STANDARDS TRACK] >=20 > This document is a product of the TCP Maintenance and Minor Extensions = Working Group of the IETF. >=20 >=20 > EXPERIMENTAL: This memo defines an Experimental Protocol for the > Internet community. It does not specify an Internet standard of any > kind. Discussion and suggestions for improvement are requested. > Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see = http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce http://www.ipinc.net/IPv4.GIF From fred@cisco.com Mon Apr 26 21:13:32 2010 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 63A303A6C38 for ; Mon, 26 Apr 2010 21:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.216 X-Spam-Level: X-Spam-Status: No, score=-100.216 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_40=-0.185, 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 OiOEkLEL43fP for ; Mon, 26 Apr 2010 21:13:31 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id E0EF73A67A6 for ; Mon, 26 Apr 2010 21:13:23 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIBACsB1kuQ/uCWiWdsb2JhbACQPYwMFQEBAQoLEREGHKQqmh+FDAQ X-IronPort-AV: E=Sophos;i="4.52,277,1270425600"; d="scan'208";a="6238017" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 27 Apr 2010 03:36:22 +0000 Received: from [10.10.35.113] (ams3-vpn-dhcp1091.cisco.com [10.61.68.67]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3R4DA7A005889; Tue, 27 Apr 2010 04:13:10 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <20100427031619.661E0F22DD7@lawyers.icir.org> Date: Tue, 27 Apr 2010 05:13:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8D6E7279-21DC-44CC-A623-671A18D951C3@cisco.com> References: <20100427031619.661E0F22DD7@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.1078) X-Mailman-Approved-At: Tue, 27 Apr 2010 08:18:41 -0700 Cc: jblanton@masaka.cs.ohiou.edu, tcpm@ietf.org, k.avrachenkov@sophia.inria.fr Subject: Re: [tcpm] RFC 5827 on Early Retransmit for and Stream Control Transmission Protocol (SCTP) 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, 27 Apr 2010 04:13:32 -0000 I'm sure you're wiser than I. I'm just thinking that in a context where = cwnd<4 (pretty normal at my house when uploading to Picasa, which is an = obvious file-transfer test, because the RTT is relatively short) sending = after two dup-acks inserts a relatively large delay on the line in the = event that it is a wrong guess. If you're going to increase the chance = of guessing wrong, it seems like you might want to minimize the = side-effect of being wrong. On Apr 27, 2010, at 4:16 AM, Mark Allman wrote: >=20 >> In cases in which cwnd < 4, it seems like your biggest concern is to >> elicit the information necessary to trigger the retransmission = without >> unnecessarily burdening the path. That is in essence why we use three >> dup-acks as a trigger - it is "enough" information to ensure that = with >> high probability it is not being triggered by simple packet >> reordering. =20 >>=20 >> Would it make sense to, when cwnd < 4 or all of the data available to >> transmit is in flight, in response to a SACK, send a segment >> containing exactly the TCP header, and one byte of SACKed data? The >> receipt of the SACK says that it is highly likely that the missing >> segment cleared the bottleneck, and would trigger an additional >> dup-ack containing the SACK record in question (which might trigger >> another of the same type of segment). If the missing segment is in >> fact lost, doing that would allow you to trigger three dup-acks in >> three RTTs even if you only had two segments outstanding (cwnd=3D2 or >> that's all the data you have). You only take the RTO if you literally >> have a single segment outstanding. If the missing segment in fact >> arrived but the ACK was lost, it would trigger the ACK.=20 >=20 > My quick response is ... >=20 > - ER explicitly defers to Limited Transmit (RFC 3042) when possible, > which is sorta what you describe, but not with dummy sorts of > packets, but with packets off the top. But, the point is the > same---to try to drive the ACK process to a less ambiguous state. >=20 > - I am not a big fan of dummy packets that really don't accomplish = any > work [*] (and, not just here; they've been proposed in a number of > contexts). My mental model says one of these packets you sketch > above is about as much work as a data carrying packet and so why = not > just retransmit and be done with it? Yeah, if we're wrong because > of small scale reordering then we needlessly injected a packet. > But, using the scheme above to try to better ensure the right = action > is taken we also injected a packet (or two). And, in either case, > the cwnd is so small cutting it isn't a huge deal, it seems to me. >=20 > [*] By work I mean in the context transfer process, not in terms of > the underlying mechanisms to get that done. So, in my mind > "work" =3D=3D data packets or their ACKs and not control things = such > as you sketch. >=20 > allman >=20 >=20 >=20 http://www.ipinc.net/IPv4.GIF