From ketkulka@gmail.com Sun Feb 3 20:09:20 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5300521F89F9 for ; Sun, 3 Feb 2013 20:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUnjCC0O2QWc for ; Sun, 3 Feb 2013 20:09:19 -0800 (PST) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id E9A1821F89CE for ; Sun, 3 Feb 2013 20:09:18 -0800 (PST) Received: by mail-ve0-f181.google.com with SMTP id d10so4407174vea.12 for ; Sun, 03 Feb 2013 20:09:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=oUS46GNuxU5WhY9C14QfkWmAGpLhxMW9YnRgiMDntyU=; b=z1FbDo0SLZkUFcDxv++HZ+pilmtyDwt5Hbf2R3dhV7aQ2F4aEdMPNS8IaNXEZ9qHJH qLOJ+050bhAcjNQcFjwHr5+V0XdutJOcc+/L7MdNE4ZvkPhvF7HItOsFZIgs7LCFnAgm ziVsRWcTSOuclJ1D4Y5vRxBsqBA9E3kAGv8ORzjOQAfm6aA9j7ISRYd/SH/U9/fFn3/f DUdyywpJMWXKldy6QjzxPVsq8qjSAYSFyPOEKyi5Jdw2w+Fl+kqJjP0vmwcOVDSm30qK lXrx6XPJ4PCah/eSafFUdlWflvLIKQltBH9U9jferNTjMrxetsHTGG4+PKIPslFELOU7 NwqA== MIME-Version: 1.0 X-Received: by 10.220.151.141 with SMTP id c13mr20493132vcw.64.1359950958369; Sun, 03 Feb 2013 20:09:18 -0800 (PST) Received: by 10.58.107.166 with HTTP; Sun, 3 Feb 2013 20:09:18 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Feb 2013 09:39:18 +0530 Message-ID: From: Ketan Kulkarni To: Yoshifumi Nishida Content-Type: text/plain; charset=ISO-8859-1 Cc: tcpm@ietf.org Subject: Re: [tcpm] Few TCP Fast Open considerations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 04 Feb 2013 04:09:20 -0000 Hi Yoshifumi, With the current draft, there is no way fast open client can differentiate between these two cases. However, (albeit with little modification) server can "help" client differentiate. Here's how - In first cases, server is restarted without fast open. So there is no way server can "communicate" anything about fast open to the client. In second case however, server supports fast open but is not able ack syn+data. In such case, it can very well send a NULL cookie to the client. Client on receipt of a NULL cookie can differentiate between first and second case. If client detects first scenario, IMHO, client should stop sending SYN+Data in subsequent connections to the server, as it has the sufficient information to believe server is not supporting tcp fast open. While in second case, client can still attempt fast open (syn+data) in subsequent connections as the condition is temporal and it can expect the syn+data could be acked by the server. Sounds reasonable? Thanks, Ketan On Thu, Jan 31, 2013 at 11:36 AM, Yoshifumi Nishida wrote: > Hi Ketan, > > On Mon, Jan 28, 2013 at 8:42 AM, Ketan Kulkarni wrote: > >> If above suggestion is ok, there could probably also be a need of >> sending NULL cookie (again suggested by Yuchung on netdev) from >> fast-open server. >> Specifically, at fast-open client, to detect the difference between >> the two different scenarios - >> 1. server restarted without Fast Open and is no longer supporting it >> (or any of the condition given above) >> 2. fast-open server exhausted its fast-open backlog and is temporarily >> not acking the data in SYN. >> >> In the 2nd case, server might choose to send the NULL cookie on the >> receipt of which client understands the server still supports >> fast-open but unable to do so temporarily. >> It might also indicate cookie expiration - but I am not sure. >> >> I will like a wider view and more thoughts on such scenarios occurring >> in the network. > > It seems to me that 1 and 2 are mostly the same unless you can know > how long "temporarily" is. > But, I'm guessing it'll be difficult to know.. > > -- > Yoshifumi Nishida From rs@netapp.com Mon Feb 4 03:56:05 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C152821F8472 for ; Mon, 4 Feb 2013 03:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AR7gihSDuzYy for ; Mon, 4 Feb 2013 03:56:05 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1F81821F8468 for ; Mon, 4 Feb 2013 03:56:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,598,1355126400"; d="scan'208";a="16044866" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 04 Feb 2013 03:56:03 -0800 Received: from vmwexceht03-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.241]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r14Bu39g009294; Mon, 4 Feb 2013 03:56:03 -0800 (PST) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.188]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0328.009; Mon, 4 Feb 2013 03:56:03 -0800 From: "Scheffenegger, Richard" To: Ketan Kulkarni Thread-Topic: [tcpm] Few TCP Fast Open considerations Thread-Index: AQHN/XaIwLy/EB44O0uukXC/BTkwMphjfYAAgAYofACAAHQEAA== Date: Mon, 4 Feb 2013 11:56:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <02EBDAC726C63546B58F9F9D8CD96959@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcpm Subject: Re: [tcpm] Few TCP Fast Open considerations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 04 Feb 2013 11:56:05 -0000 Hi, Sorry, i'm cached only so i can not check in the draft: Ketan, you mentioned a cookie revokation also as a potential use for a null= cookie. But if the reply to a fo syn is a null cookie to indicate a tempor= ary overload situation (where the server probably doesn't want to hand out = new cookies), how would such a cookie revokation during syn happen? Best regards, Richard Am 04.02.2013 um 05:09 schrieb "Ketan Kulkarni" : > Hi Yoshifumi, > With the current draft, there is no way fast open client can > differentiate between these two cases. > However, (albeit with little modification) server can "help" client > differentiate. > Here's how - > In first cases, server is restarted without fast open. So there is no > way server can "communicate" anything about fast open to the client. > In second case however, server supports fast open but is not able ack > syn+data. In such case, it can very well send a NULL cookie to the > client. Client on receipt of a NULL cookie can differentiate between > first and second case. >=20 > If client detects first scenario, IMHO, client should stop sending > SYN+Data in subsequent connections to the server, as it has the > sufficient information to believe server is not supporting tcp fast > open. > While in second case, client can still attempt fast open (syn+data) in > subsequent connections as the condition is temporal and it can expect > the syn+data could be acked by the server. >=20 > Sounds reasonable? >=20 > Thanks, > Ketan >=20 > On Thu, Jan 31, 2013 at 11:36 AM, Yoshifumi Nishida > wrote: >> Hi Ketan, >>=20 >> On Mon, Jan 28, 2013 at 8:42 AM, Ketan Kulkarni wro= te: >>=20 >>> If above suggestion is ok, there could probably also be a need of >>> sending NULL cookie (again suggested by Yuchung on netdev) from >>> fast-open server. >>> Specifically, at fast-open client, to detect the difference between >>> the two different scenarios - >>> 1. server restarted without Fast Open and is no longer supporting it >>> (or any of the condition given above) >>> 2. fast-open server exhausted its fast-open backlog and is temporarily >>> not acking the data in SYN. >>>=20 >>> In the 2nd case, server might choose to send the NULL cookie on the >>> receipt of which client understands the server still supports >>> fast-open but unable to do so temporarily. >>> It might also indicate cookie expiration - but I am not sure. >>>=20 >>> I will like a wider view and more thoughts on such scenarios occurring >>> in the network. >>=20 >> It seems to me that 1 and 2 are mostly the same unless you can know >> how long "temporarily" is. >> But, I'm guessing it'll be difficult to know.. >>=20 >> -- >> Yoshifumi Nishida > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From tsabatini@hotmail.com Mon Feb 4 14:11:13 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8887A21F8B3A for ; Mon, 4 Feb 2013 14:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44rQQuDS3Gzp for ; Mon, 4 Feb 2013 14:11:12 -0800 (PST) Received: from bay0-omc3-s10.bay0.hotmail.com (bay0-omc3-s10.bay0.hotmail.com [65.54.190.148]) by ietfa.amsl.com (Postfix) with ESMTP id 67E9F21F8B45 for ; Mon, 4 Feb 2013 14:11:12 -0800 (PST) Received: from BAY172-W37 ([65.54.190.188]) by bay0-omc3-s10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Feb 2013 14:11:08 -0800 X-EIP: [Vej8elEhA1oz6ByEWBkbaiHrchE9Sz/2] X-Originating-Email: [tsabatini@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_806b457b-4bca-4671-931a-18d6e8b4bd2a_" From: Anthony Sabatini To: "l.wood@surrey.ac.uk" , tcpm Michael Scharf , tcpm lars , tccpm cabo , Wesley Eddy , tcpm Date: Mon, 4 Feb 2013 17:11:07 -0500 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 04 Feb 2013 22:11:08.0323 (UTC) FILETIME=[88726F30:01CE0324] Subject: [tcpm] Fujitsu and Saratoga X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 04 Feb 2013 22:11:13 -0000 --_806b457b-4bca-4671-931a-18d6e8b4bd2a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable L. Wood=2C W. Eddy - 1) TDLC is a true message based transmission layer control protocol (unlike= TCP which mixes layers). As such it is concerned only with the secure and= timely delivery of messages. It always has had event based transmission m= anagement=2C not timer based and without timers there is no congestion coll= apse. 2) I chose a bit mapped representation for missing messages because number = pair schemes=2C such as SACK=2C falls apart if the number of outstanding ho= les exceeds what can be carried in the options area of one message. For la= rge holes in the stream this is fine=2C for "popcorn" noise and loss situat= ions it is a disaster. Additionally since I number messages=2C not bytes= =2C I need 10 bit smaller numbers to express the same capabilities that TCP= does. So comparing apples to apples=2C if three sack pairs are in a messa= ge three holes can be expressed (in some cases 4 holes) where as with a bit= map I can span 192 messages uniquely=2C the equivalent of 192KB. Using CCI= TT Group 3 One dimensional bit compression encoding I could express between= 4 and 20 times that many messages in the same space. 3) Since TDLC is state/event driven as opposed to timer driven=2C many cong= estion situations will even themselves out by transmission rates slowing wa= iting for holes to be filled. TDLC was designed to work with ECN=2C not to= try to second guess what the router is doing or what it needs=2C it was im= plemeted with a token based ECN system where a nessage of less tahn 512 byt= es took one token and and additional token for each 512 bytes or fraction t= hereof. These numbers were chosen after consultation with the router manuf= acturers of the time (lower speed links used 256 bytes instead of 512). 4) The reason we are seeing so many alternatives to TCP/IP is that TCP/IP i= s failing badly in the real world. As long as link quality kept getting be= tter TCP/IP was fine=2C but with the random drop situations in mobile phone= s and WiFi and the increase in congestion on cellular=2C WiFi and backbone = links=2C TCP/IP is breaking down (I live in New York=2C I can document at l= east 1 TCP/IP failure per hour=2C minimum=2C due to noise=2C packet loss an= d congestion that happens to me personally). Preliminary comments on Saratoga - 1) Before I give comments please understand I like and support where this p= rotocol is going=2C I just want people to think about how to make it better= . 2) The strength of the IETF protocols are simplicity and solving the genera= l case at the expense of the edge cases. Saratoga is starting to suffer fr= om way to many options=2C you need to define a core implementation and a pa= th to expansion in the base document not all possible variants otherwise it= will be a bear to implement since all features must be included and treate= d equally. I know you have put in some thought on this and there are many = places you say what is mandatory but as a whole document can be overwhelmin= g in it's implications. 3) This protocol suffers from an extreme case of OSI layer violation (worse= than TCP/IP)=2C the underlying transport should be separated into it's own= document and redone for more general use. The file control should ride at= op that protocol. A selection from the TDLC standards document is below fo= r your review. From the TDLC standard document - =20 =20 Transmission Control Byte 76543210 =20 xx Type of packet 00 User Data 01 User Command 10 Supervisory Data 11 Supervisory Command xx Record Control 11 Record is complete in this message 10 Record starts with first byte of message 01 Record ends with last byte of this message 00 Record continues with this message =20 xx Record Group Control 11 Record Group is complete in this message 10 Record Group starts with first byte of this message 01 Record Group ends with last byte of this message 00 Record group continues with this message Notes - Type of packet - User data is the norm. User command is used for things li= ke FTP commands=2C the file is transferred as user data. Supervisory comman= d and data perform similar functions but handle situations such as interrup= t. =20 Record Control - Record control is shared between user and network control.= Only complete records are delivered to user. If network needs to split p= acket then first packet will contain first bit and last packet will contain= second bit=2C other bits here would be zero. Record Group Control - Obeys same rules as Record control as far as packet = splitting but signals to user when first message of group is read and when = last message of group is read. Numeric Compression It is only necessary to have one absolute number in the header=2C the "next= in sequence" (The TCP Acknowledge field)=2C all other numbers in the messa= ge should be realtive to this number. TIFF defines a very light weight compression scheme=2C a number consists of= multiple bytes=2C high to low order=2C the first bit of the byte is a "fin= al" indicator and the low 7 bits are the value. As bytes are read the curr= ent value is shifted left 7 bits and the low order 7 bits of the incoming b= yte are added or ored in. If the high order bit is a one the proccess is c= omplete=2C otherwise it keeps repeating until a byte with the high order bi= t set to one is encountered. Thus values are 7=2C 14=2C 21=2C 28 et seq. bi= ts in length. To be truly efficient numbers should be realtive to the immediately precced= ing number thus requiring the smallest number of bits to express the differ= ence. Bit Map Compression CCITT Group 3 one dimensional coding standard is a run length limited code = for binary compression which works well in compressing a long bitmap of out= standing messages. Tony Anthony Sabatini 200 West 20th Street Apt. 1216 New York=2C NY 10011 Phone: (212) 867-7179 Mobile: (917) 224-8388 =20 = --_806b457b-4bca-4671-931a-18d6e8b4bd2a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
L. Wood=2C W. Eddy -

1) TDLC is a true message based transmission la= yer control protocol (unlike TCP which mixes layers). =3B As such it is= concerned only with the secure and timely delivery of messages. =3B It= always has had event based transmission management=2C not timer based and = without timers there is no congestion collapse.

2) I chose a bit map= ped representation for missing messages because number pair schemes=2C such= as SACK=2C falls apart if the number of outstanding holes exceeds what can= be carried in the options area of one message. =3B For large holes in = the stream this is fine=2C for "popcorn" noise and loss situations it is a = disaster. =3B Additionally since I number messages=2C not bytes=2C I ne= ed 10 bit smaller numbers to express the same capabilities that TCP does.&n= bsp=3B So comparing apples to apples=2C if three sack pairs are in a messag= e three holes can be expressed (in some cases 4 holes) where as with a bitm= ap I can span 192 messages uniquely=2C the equivalent of 192KB. =3B Usi= ng CCITT Group 3 One dimensional bit compression encoding I could express b= etween 4 and 20 times that many messages in the same space.

3) Since= TDLC is state/event driven as opposed to timer driven=2C many congestion s= ituations will even themselves out by transmission rates slowing waiting fo= r holes to be filled. =3B TDLC was designed to work with ECN=2C not to = try to second guess what the router is doing or what it needs=2C it was imp= lemeted with a token based ECN system where a nessage of less tahn 512 byte= s took one token and and additional token for each 512 bytes or fraction th= ereof. =3B These numbers were chosen after consultation with the router= manufacturers of the time (lower speed links used 256 bytes instead of 512= ).

4) The reason we are seeing so many alternatives to TCP/IP is tha= t TCP/IP is failing badly in the real world. =3B As long as link qualit= y kept getting better TCP/IP was fine=2C but with the random drop situation= s in mobile phones and WiFi and the increase in congestion on cellular=2C W= iFi and backbone links=2C TCP/IP is breaking down (I live in New York=2C I = can document at least 1 TCP/IP failure per hour=2C minimum=2C due to noise= =2C packet loss and congestion that happens to me personally).


P= reliminary comments on Saratoga -

1) Before I give comments please u= nderstand I like and support where this protocol is going=2C I just want pe= ople to think about how to make it better.

2) The strength of the IE= TF protocols are simplicity and solving the general case at the expense of = the edge cases. =3B Saratoga is starting to suffer from way to many opt= ions=2C you need to define a core implementation and a path to expansion in= the base document not all possible variants otherwise it will be a bear to= implement since all features must be included and treated equally. =3B= I know you have put in some thought on this and there are many places you = say what is mandatory but as a whole document can be overwhelming in it's i= mplications.

3) This protocol suffers from an extreme case of OSI la= yer violation (worse than TCP/IP)=2C the underlying transport should be sep= arated into it's own document and redone for more general use. =3B The = file control should ride atop that protocol. =3B A selection from the T= DLC standards document is below for your review.

 =3BFrom the TD= LC standard document -
 =3B
 =3B
Transmission Control Byte=
76543210 =3B =3B =3B
xx =3B =3B =3B =3B=  =3B =3B =3B =3B =3B Type of packet
00 =3B = =3B =3B =3B =3B =3B =3B =3B =3B User Data
01=  =3B =3B =3B =3B =3B =3B =3B =3B =3B Us= er Command
10 =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B Supervisory Data
11 =3B =3B =3B =3B = =3B =3B =3B =3B =3B Supervisory Command

 =3B xx&= nbsp=3B =3B =3B =3B =3B =3B =3B Record Control
&= nbsp=3B 11 =3B =3B =3B =3B =3B =3B =3B Record i= s complete in this message
 =3B 10 =3B =3B =3B =3B&n= bsp=3B =3B =3B Record starts with first byte of message
 =3B= 01 =3B =3B =3B =3B =3B =3B =3B Record ends wit= h last byte of this message
 =3B 00 =3B =3B =3B =3B&= nbsp=3B =3B =3B Record continues with this message
 =3B
=  =3B =3B =3B xx =3B =3B =3B =3B =3B Record = Group Control
 =3B =3B =3B 11 =3B =3B =3B = =3B =3B Record Group is complete in this message
 =3B =3B&nb= sp=3B 10 =3B =3B =3B =3B =3B Record Group starts with f= irst byte of this message
 =3B =3B =3B 01 =3B =3B&nb= sp=3B =3B =3B Record Group ends with last byte of this message
&= nbsp=3B =3B =3B 00 =3B =3B =3B =3B =3B Record g= roup continues with this message

Notes -

Type of packet - Use= r data is the norm. =3B User command is used for things like FTP comman= ds=2C the file is transferred as user data. Supervisory command and data pe= rform similar functions but handle situations such as interrupt. =3B&nb= sp=3B =3B

Record Control - Record control is shared between use= r and network control. =3B Only complete records are delivered to user.=  =3B If network needs to split packet then first packet will contain fi= rst bit and last packet will contain second bit=2C other bits here would be= zero.

Record Group Control - Obeys same rules as Record control as = far as packet splitting but signals to user when first message of group is = read and when last message of group is read.


Numeric Compression=

It is only necessary to have one absolute number in the header=2C t= he "next in sequence" (The TCP Acknowledge field)=2C all other numbers in t= he message should be realtive to this number.

TIFF defines a very li= ght weight compression scheme=2C a number consists of multiple bytes=2C hig= h to low order=2C the first bit of the byte is a "final" indicator and the = low 7 bits are the value. =3B As bytes are read the current value is sh= ifted left 7 bits and the low order 7 bits of the incoming byte are added o= r ored in. =3B If the high order bit is a one the proccess is complete= =2C otherwise it keeps repeating until a byte with the high order bit set t= o one is encountered. Thus values are 7=2C 14=2C 21=2C 28 et seq. bits in l= ength.

To be truly efficient numbers should be realtive to the immed= iately precceding number thus requiring the smallest number of bits to expr= ess the difference.


Bit Map Compression

CCITT Group 3 one= dimensional coding standard is a run length limited code for binary compre= ssion which works well in compressing a long bitmap of outstanding messages= .

Tony


Anthony Sabatini
200 =3BWest 20th StreetApt. 1216
New York=2C NY 10011

Phone: (212) 867-7179
Mobile: = (917) 224-8388

 =3B
= --_806b457b-4bca-4671-931a-18d6e8b4bd2a_-- From michawe@ifi.uio.no Tue Feb 5 00:42:26 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1B621F8518 for ; Tue, 5 Feb 2013 00:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LB8owa1P3zcG for ; Tue, 5 Feb 2013 00:42:24 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 27E2C21F8512 for ; Tue, 5 Feb 2013 00:42:23 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1U2e6g-0007sr-53 for tcpm@ietf.org; Tue, 05 Feb 2013 09:42:22 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1U2e6f-0007ai-4Q for tcpm@ietf.org; Tue, 05 Feb 2013 09:42:22 +0100 From: Michael Welzl Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_1DDD04D4-D4A2-4E00-822B-2B7EB93DF39C" Date: Tue, 5 Feb 2013 09:42:19 +0100 In-Reply-To: To: tcpm References: Message-Id: <9AD7A7D3-27D4-42FE-A320-B347F2343933@ifi.uio.no> X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 4 sum msgs/h 2 total rcpts 1858 max rcpts/h 20 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 2A104A84F4BDD6F2E3D837114085DE2D2B3A1506 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 580 max/h 12 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [tcpm] Fujitsu and Saratoga X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 05 Feb 2013 08:42:26 -0000 --Apple-Mail=_1DDD04D4-D4A2-4E00-822B-2B7EB93DF39C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Dear Tony, all, On 4. feb. 2013, at 23:11, Anthony Sabatini wrote: > L. Wood, W. Eddy - >=20 > 1) TDLC is a true message based transmission layer control protocol = (unlike TCP which mixes layers). As such it is concerned only with the = secure and timely delivery of messages. It always has had event based = transmission management, not timer based and without timers there is no = congestion collapse. >=20 > 2) I chose a bit mapped representation for missing messages because = number pair schemes, such as SACK, falls apart if the number of = outstanding holes exceeds what can be carried in the options area of one = message. For large holes in the stream this is fine, for "popcorn" = noise and loss situations it is a disaster. Additionally since I number = messages, not bytes, I need 10 bit smaller numbers to express the same = capabilities that TCP does. So comparing apples to apples, if three = sack pairs are in a message three holes can be expressed (in some cases = 4 holes) where as with a bitmap I can span 192 messages uniquely, the = equivalent of 192KB. Using CCITT Group 3 One dimensional bit = compression encoding I could express between 4 and 20 times that many = messages in the same space. That makes sense to me. What I really wonder is: do you have any data = showing that with an **up-to-date** TCP SACK, these situations really do = become catastrophic? I guess such an investigation would have to answer = questions like "in such extreme heavy loss situations, if TCP runs into = a timeout, wasn't that the better thing to do anyway?" and "does such = 'popcorn' noise really appear at large enough scales to cause problems = for today's TCP SACK"? One point of concern that I see is that bandwidth, and with it the BDP, = is growing, but the usual MTU isn't. Hence, if the = space-wasted-by-SACK-problem that Tony describes really isn't an issue = today, is it possible that this becomes a true problem tomorrow? > 3) Since TDLC is state/event driven as opposed to timer driven, many = congestion situations will even themselves out by transmission rates = slowing waiting for holes to be filled. TDLC was designed to work with = ECN, not to try to second guess what the router is doing or what it = needs, it was implemeted with a token based ECN system where a nessage = of less tahn 512 bytes took one token and and additional token for each = 512 bytes or fraction thereof. These numbers were chosen after = consultation with the router manufacturers of the time (lower speed = links used 256 bytes instead of 512). >=20 > 4) The reason we are seeing so many alternatives to TCP/IP is that = TCP/IP is failing badly in the real world. As long as link quality kept = getting better TCP/IP was fine, but with the random drop situations in = mobile phones and WiFi and the increase in congestion on cellular, WiFi = and backbone links, TCP/IP is breaking down (I live in New York, I can = document at least 1 TCP/IP failure per hour, minimum, due to noise, = packet loss and congestion that happens to me personally). Do you have any data showing that these failures are SACK related, i.e. = would be fixed with better SACK design as you suggest? > Preliminary comments on Saratoga - >=20 > 1) Before I give comments please understand I like and support where = this protocol is going, I just want people to think about how to make it = better. >=20 > 2) The strength of the IETF protocols are simplicity and solving the = general case at the expense of the edge cases. Saratoga is starting to = suffer from way to "The strength of the IETF protocols are simplicity" =3D> this is a joke, = right?? > many options, you need to define a core implementation and a path to = expansion in the base document not all possible variants otherwise it = will be a bear to implement since all features must be included and = treated equally. I know you have put in some thought on this and there = are many places you say what is mandatory but as a whole document can be = overwhelming in it's implications. >=20 > 3) This protocol suffers from an extreme case of OSI layer violation = (worse than TCP/IP), the underlying transport should be separated into = it's own document > and redone for more general use. The file control should ride atop = that protocol. A selection from the TDLC standards document is below = for your review. >=20 > =46rom the TDLC standard document - > =20 > =20 > Transmission Control Byte > 76543210 =20 > xx Type of packet > 00 User Data > 01 User Command > 10 Supervisory Data > 11 Supervisory Command >=20 > xx Record Control > 11 Record is complete in this message > 10 Record starts with first byte of message > 01 Record ends with last byte of this message > 00 Record continues with this message > =20 > xx Record Group Control > 11 Record Group is complete in this message > 10 Record Group starts with first byte of this message > 01 Record Group ends with last byte of this message > 00 Record group continues with this message >=20 > Notes - >=20 > Type of packet - User data is the norm. User command is used for = things like FTP commands, the file is transferred as user data. = Supervisory command and data perform similar functions but handle = situations such as interrupt. =20 >=20 > Record Control - Record control is shared between user and network = control. Only complete records are delivered to user. If network needs = to split packet then first packet will contain first bit and last packet = will contain second bit, other bits here would be zero. >=20 > Record Group Control - Obeys same rules as Record control as far as = packet splitting but signals to user when first message of group is read = and when last message of group is read. >=20 >=20 > Numeric Compression >=20 > It is only necessary to have one absolute number in the header, the = "next in sequence" (The TCP Acknowledge field), all other numbers in the = message should be realtive to this number. >=20 > TIFF defines a very light weight compression scheme, a number consists = of multiple bytes, high to low order, the first bit of the byte is a = "final" indicator and the low 7 bits are the value. As bytes are read = the current value is shifted left 7 bits and the low order 7 bits of the = incoming byte are added or ored in. If the high order bit is a one the = proccess is complete, otherwise it keeps repeating until a byte with the = high order bit set to one is encountered. Thus values are 7, 14, 21, 28 = et seq. bits in length. >=20 > To be truly efficient numbers should be realtive to the immediately = precceding number thus requiring the smallest number of bits to express = the difference. >=20 >=20 > Bit Map Compression >=20 > CCITT Group 3 one dimensional coding standard is a run length limited = code for binary compression which works well in compressing a long = bitmap of outstanding messages. >=20 > Tony >=20 >=20 > Anthony Sabatini > 200 West 20th Street > Apt. 1216 > New York, NY 10011 >=20 > Phone: (212) 867-7179 > Mobile: (917) 224-8388 >=20 > =20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm Cheers, Michael --Apple-Mail=_1DDD04D4-D4A2-4E00-822B-2B7EB93DF39C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Dear Tony, all,


On = 4. feb. 2013, at 23:11, Anthony Sabatini wrote:

L. Wood, W. Eddy -

1) TDLC is a true message = based transmission layer control protocol (unlike TCP which mixes = layers).  As such it is concerned only with the secure and timely = delivery of messages.  It always has had event based transmission = management, not timer based and without timers there is no congestion = collapse.

2) I chose a bit mapped representation for missing = messages because number pair schemes, such as SACK, falls apart if the = number of outstanding holes exceeds what can be carried in the options = area of one message.  For large holes in the stream this is fine, = for "popcorn" noise and loss situations it is a disaster.  = Additionally since I number messages, not bytes, I need 10 bit smaller = numbers to express the same capabilities that TCP does.  So = comparing apples to apples, if three sack pairs are in a message three = holes can be expressed (in some cases 4 holes) where as with a bitmap I = can span 192 messages uniquely, the equivalent of 192KB.  Using = CCITT Group 3 One dimensional bit compression encoding I could express = between 4 and 20 times that many messages in the same = space.

That makes = sense to me. What I really wonder is: do you have any data showing that = with an **up-to-date** TCP SACK, these situations really do become = catastrophic? I guess such an investigation would have to answer = questions like "in such extreme heavy loss situations, if TCP runs into = a timeout, wasn't that the better thing to do anyway?" and "does such = 'popcorn' noise really appear at large enough scales to cause problems = for today's TCP SACK"?

One point of concern = that I see is that bandwidth, and with it the BDP, is growing, but the = usual MTU isn't. Hence, if the space-wasted-by-SACK-problem that Tony = describes really isn't an issue today, is it possible that this becomes = a true problem tomorrow?


3) Since TDLC is state/event driven as opposed to = timer driven, many congestion situations will even themselves out by = transmission rates slowing waiting for holes to be filled.  TDLC = was designed to work with ECN, not to try to second guess what the = router is doing or what it needs, it was implemeted with a token based = ECN system where a nessage of less tahn 512 bytes took one token and and = additional token for each 512 bytes or fraction thereof.  These = numbers were chosen after consultation with the router manufacturers of = the time (lower speed links used 256 bytes instead of 512).

4) = The reason we are seeing so many alternatives to TCP/IP is that TCP/IP = is failing badly in the real world.  As long as link quality kept = getting better TCP/IP was fine, but with the random drop situations in = mobile phones and WiFi and the increase in congestion on cellular, WiFi = and backbone links, TCP/IP is breaking down (I live in New York, I can = document at least 1 TCP/IP failure per hour, minimum, due to noise, = packet loss and congestion that happens to me = personally).

Do = you have any data showing that these failures are SACK related, i.e. = would be fixed with better SACK design as you = suggest?


Preliminary comments on Saratoga -

1) Before I = give comments please understand I like and support where this protocol = is going, I just want people to think about how to make it = better.

2) The strength of the IETF protocols are simplicity and = solving the general case at the expense of the edge cases.  = Saratoga is starting to suffer from way = to

"The strength of = the IETF protocols are simplicity" =3D> this is a joke, = right??


many options, you need to define a core = implementation and a path to expansion in the base document not all = possible variants otherwise it will be a bear to implement since all = features must be included and treated equally.  I know you have put = in some thought on this and there are many places you say what is = mandatory but as a whole document can be overwhelming in it's = implications.

3) This protocol suffers from an extreme case of = OSI layer violation (worse than TCP/IP), the underlying transport should = be separated into it's own = document
and redone for more general use.  The file = control should ride atop that protocol.  A selection from the TDLC = standards document is below for your review.

 =46rom the = TDLC standard document -
 
 
Transmission Control = Byte
76543210    
xx    = ;      Type of = packet
00          User = Data
01          User = Command
10          = Supervisory = Data
11          = Supervisory Command

  = xx        Record Control
  = 11        Record is complete in this = message
  10        Record = starts with first byte of message
  = 01        Record ends with last byte = of this message
  00        = Record continues with this message
  
    = xx      Record Group = Control
    11      Record = Group is complete in this message
    = 10      Record Group starts with first byte of = this message
    01      = Record Group ends with last byte of this message
    = 00      Record group continues with this = message

Notes -

Type of packet - User data is the = norm.  User command is used for things like FTP commands, the file = is transferred as user data. Supervisory command and data perform = similar functions but handle situations such as = interrupt.    

Record Control - = Record control is shared between user and network control.  Only = complete records are delivered to user.  If network needs to split = packet then first packet will contain first bit and last packet will = contain second bit, other bits here would be zero.

Record Group = Control - Obeys same rules as Record control as far as packet splitting = but signals to user when first message of group is read and when last = message of group is read.


Numeric Compression

It is = only necessary to have one absolute number in the header, the "next in = sequence" (The TCP Acknowledge field), all other numbers in the message = should be realtive to this number.

TIFF defines a very light = weight compression scheme, a number consists of multiple bytes, high to = low order, the first bit of the byte is a "final" indicator and the low = 7 bits are the value.  As bytes are read the current value is = shifted left 7 bits and the low order 7 bits of the incoming byte are = added or ored in.  If the high order bit is a one the proccess is = complete, otherwise it keeps repeating until a byte with the high order = bit set to one is encountered. Thus values are 7, 14, 21, 28 et seq. = bits in length.

To be truly efficient numbers should be realtive = to the immediately precceding number thus requiring the smallest number = of bits to express the difference.


Bit Map = Compression

CCITT Group 3 one dimensional coding standard is a = run length limited code for binary compression which works well in = compressing a long bitmap of outstanding = messages.

Tony


Anthony Sabatini
200 West 20th = Street
Apt. 1216
New York, NY 10011

Phone: (212) = 867-7179
Mobile: (917) = 224-8388

 
__________________________________________= _____
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/m= ailman/listinfo/tcpm


<= /div>
Cheers,
Michael



= --Apple-Mail=_1DDD04D4-D4A2-4E00-822B-2B7EB93DF39C-- From michawe@ifi.uio.no Tue Feb 5 01:28:33 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7C021F86A6 for ; Tue, 5 Feb 2013 01:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPe0eKItw+Jt for ; Tue, 5 Feb 2013 01:28:32 -0800 (PST) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 4798E21F869C for ; Tue, 5 Feb 2013 01:28:31 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1U2epK-00065R-36 for tcpm@ietf.org; Tue, 05 Feb 2013 10:28:30 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1U2epJ-0007Y5-28 for tcpm@ietf.org; Tue, 05 Feb 2013 10:28:30 +0100 From: Michael Welzl Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_EDD46465-13F0-442B-8BAC-AA4AE3965AB8" Date: Tue, 5 Feb 2013 10:28:28 +0100 In-Reply-To: <9AD7A7D3-27D4-42FE-A320-B347F2343933@ifi.uio.no> To: tcpm References: <9AD7A7D3-27D4-42FE-A320-B347F2343933@ifi.uio.no> Message-Id: X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 2 sum msgs/h 2 total rcpts 1861 max rcpts/h 20 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 474C3D5E23EB0A8E11E21F957E8905F72FE2B61A X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 582 max/h 12 blacklist 0 greylist 0 ratelimit 0 Subject: Re: [tcpm] Fujitsu and Saratoga X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 05 Feb 2013 09:28:33 -0000 --Apple-Mail=_EDD46465-13F0-442B-8BAC-AA4AE3965AB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Oops. I just noticed that I've been thinking of SCTP too much lately, = letting me forget about a TCP limitation here - so here's me trying to = fix my own mistake before others do it, below: On 5. feb. 2013, at 09:42, Michael Welzl wrote: > Dear Tony, all, >=20 >=20 > On 4. feb. 2013, at 23:11, Anthony Sabatini wrote: >=20 >> L. Wood, W. Eddy - >>=20 >> 1) TDLC is a true message based transmission layer control protocol = (unlike TCP which mixes layers). As such it is concerned only with the = secure and timely delivery of messages. It always has had event based = transmission management, not timer based and without timers there is no = congestion collapse. >>=20 >> 2) I chose a bit mapped representation for missing messages because = number pair schemes, such as SACK, falls apart if the number of = outstanding holes exceeds what can be carried in the options area of one = message. For large holes in the stream this is fine, for "popcorn" = noise and loss situations it is a disaster. Additionally since I number = messages, not bytes, I need 10 bit smaller numbers to express the same = capabilities that TCP does. So comparing apples to apples, if three = sack pairs are in a message three holes can be expressed (in some cases = 4 holes) where as with a bitmap I can span 192 messages uniquely, the = equivalent of 192KB. Using CCITT Group 3 One dimensional bit = compression encoding I could express between 4 and 20 times that many = messages in the same space. >=20 > That makes sense to me. What I really wonder is: do you have any data = showing that with an **up-to-date** TCP SACK, these situations really do = become catastrophic? I guess such an investigation would have to answer = questions like "in such extreme heavy loss situations, if TCP runs into = a timeout, wasn't that the better thing to do anyway?" and "does such = 'popcorn' noise really appear at large enough scales to cause problems = for today's TCP SACK"? >=20 > One point of concern that I see is that bandwidth, and with it the = BDP, is growing, but the usual MTU isn't. Hence, if the = space-wasted-by-SACK-problem that Tony describes really isn't an issue = today, is it possible that this becomes a true problem tomorrow? ... of course the MTU isn't the limit, it's the option size. I think = this is fixed in SCTP (although not with a bit-map, hence presumably = still wasting more space than TDLC). So, I guess that my questions above = could already be (partially) answered by some SCTP papers that show = whether encoding more SACK information makes SCTP significantly = outperform TCP under realistic conditions. >> 3) Since TDLC is state/event driven as opposed to timer driven, many = congestion situations will even themselves out by transmission rates = slowing waiting for holes to be filled. TDLC was designed to work with = ECN, not to try to second guess what the router is doing or what it = needs, it was implemeted with a token based ECN system where a nessage = of less tahn 512 bytes took one token and and additional token for each = 512 bytes or fraction thereof. These numbers were chosen after = consultation with the router manufacturers of the time (lower speed = links used 256 bytes instead of 512). >>=20 >> 4) The reason we are seeing so many alternatives to TCP/IP is that = TCP/IP is failing badly in the real world. As long as link quality kept = getting better TCP/IP was fine, but with the random drop situations in = mobile phones and WiFi and the increase in congestion on cellular, WiFi = and backbone links, TCP/IP is breaking down (I live in New York, I can = document at least 1 TCP/IP failure per hour, minimum, due to noise, = packet loss and congestion that happens to me personally). >=20 > Do you have any data showing that these failures are SACK related, = i.e. would be fixed with better SACK design as you suggest? >=20 >=20 >> Preliminary comments on Saratoga - >>=20 >> 1) Before I give comments please understand I like and support where = this protocol is going, I just want people to think about how to make it = better. >>=20 >> 2) The strength of the IETF protocols are simplicity and solving the = general case at the expense of the edge cases. Saratoga is starting to = suffer from way to >=20 > "The strength of the IETF protocols are simplicity" =3D> this is a = joke, right?? >=20 >=20 >> many options, you need to define a core implementation and a path to = expansion in the base document not all possible variants otherwise it = will be a bear to implement since all features must be included and = treated equally. I know you have put in some thought on this and there = are many places you say what is mandatory but as a whole document can be = overwhelming in it's implications. >>=20 >> 3) This protocol suffers from an extreme case of OSI layer violation = (worse than TCP/IP), the underlying transport should be separated into = it's own document >> and redone for more general use. The file control should ride atop = that protocol. A selection from the TDLC standards document is below = for your review. >>=20 >> =46rom the TDLC standard document - >> =20 >> =20 >> Transmission Control Byte >> 76543210 =20 >> xx Type of packet >> 00 User Data >> 01 User Command >> 10 Supervisory Data >> 11 Supervisory Command >>=20 >> xx Record Control >> 11 Record is complete in this message >> 10 Record starts with first byte of message >> 01 Record ends with last byte of this message >> 00 Record continues with this message >> =20 >> xx Record Group Control >> 11 Record Group is complete in this message >> 10 Record Group starts with first byte of this message >> 01 Record Group ends with last byte of this message >> 00 Record group continues with this message >>=20 >> Notes - >>=20 >> Type of packet - User data is the norm. User command is used for = things like FTP commands, the file is transferred as user data. = Supervisory command and data perform similar functions but handle = situations such as interrupt. =20 >>=20 >> Record Control - Record control is shared between user and network = control. Only complete records are delivered to user. If network needs = to split packet then first packet will contain first bit and last packet = will contain second bit, other bits here would be zero. >>=20 >> Record Group Control - Obeys same rules as Record control as far as = packet splitting but signals to user when first message of group is read = and when last message of group is read. >>=20 >>=20 >> Numeric Compression >>=20 >> It is only necessary to have one absolute number in the header, the = "next in sequence" (The TCP Acknowledge field), all other numbers in the = message should be realtive to this number. >>=20 >> TIFF defines a very light weight compression scheme, a number = consists of multiple bytes, high to low order, the first bit of the byte = is a "final" indicator and the low 7 bits are the value. As bytes are = read the current value is shifted left 7 bits and the low order 7 bits = of the incoming byte are added or ored in. If the high order bit is a = one the proccess is complete, otherwise it keeps repeating until a byte = with the high order bit set to one is encountered. Thus values are 7, = 14, 21, 28 et seq. bits in length. >>=20 >> To be truly efficient numbers should be realtive to the immediately = precceding number thus requiring the smallest number of bits to express = the difference. >>=20 >>=20 >> Bit Map Compression >>=20 >> CCITT Group 3 one dimensional coding standard is a run length limited = code for binary compression which works well in compressing a long = bitmap of outstanding messages. >>=20 >> Tony >>=20 >>=20 >> Anthony Sabatini >> 200 West 20th Street >> Apt. 1216 >> New York, NY 10011 >>=20 >> Phone: (212) 867-7179 >> Mobile: (917) 224-8388 >>=20 >> =20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 >=20 > Cheers, > Michael >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_EDD46465-13F0-442B-8BAC-AA4AE3965AB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Oops. = I just noticed that I've been thinking of SCTP too much lately, letting = me forget about a TCP limitation here - so here's me trying to fix my = own mistake before others do it, = below:


On 5. feb. 2013, at 09:42, = Michael Welzl wrote:

Dear = Tony, all,


On 4. feb. 2013, at 23:11, = Anthony Sabatini wrote:

L. Wood, W. Eddy -

1) TDLC is a true message = based transmission layer control protocol (unlike TCP which mixes = layers).  As such it is concerned only with the secure and timely = delivery of messages.  It always has had event based transmission = management, not timer based and without timers there is no congestion = collapse.

2) I chose a bit mapped representation for missing = messages because number pair schemes, such as SACK, falls apart if the = number of outstanding holes exceeds what can be carried in the options = area of one message.  For large holes in the stream this is fine, = for "popcorn" noise and loss situations it is a disaster.  = Additionally since I number messages, not bytes, I need 10 bit smaller = numbers to express the same capabilities that TCP does.  So = comparing apples to apples, if three sack pairs are in a message three = holes can be expressed (in some cases 4 holes) where as with a bitmap I = can span 192 messages uniquely, the equivalent of 192KB.  Using = CCITT Group 3 One dimensional bit compression encoding I could express = between 4 and 20 times that many messages in the same = space.

That makes = sense to me. What I really wonder is: do you have any data showing that = with an **up-to-date** TCP SACK, these situations really do become = catastrophic? I guess such an investigation would have to answer = questions like "in such extreme heavy loss situations, if TCP runs into = a timeout, wasn't that the better thing to do anyway?" and "does such = 'popcorn' noise really appear at large enough scales to cause problems = for today's TCP SACK"?

One point of concern = that I see is that bandwidth, and with it the BDP, is growing, but the = usual MTU isn't. Hence, if the space-wasted-by-SACK-problem that Tony = describes really isn't an issue today, is it possible that this becomes = a true problem = tomorrow?

... of = course the MTU isn't the limit, it's the option size. I think this is = fixed in SCTP (although not with a bit-map, = hence presumably still wasting more space than TDLC). So, I = guess that my questions above could already be (partially) answered = by some SCTP papers that show whether encoding more SACK information = makes SCTP significantly outperform TCP under realistic = conditions.


3) Since TDLC is state/event driven as opposed to = timer driven, many congestion situations will even themselves out by = transmission rates slowing waiting for holes to be filled.  TDLC = was designed to work with ECN, not to try to second guess what the = router is doing or what it needs, it was implemeted with a token based = ECN system where a nessage of less tahn 512 bytes took one token and and = additional token for each 512 bytes or fraction thereof.  These = numbers were chosen after consultation with the router manufacturers of = the time (lower speed links used 256 bytes instead of 512).

4) = The reason we are seeing so many alternatives to TCP/IP is that TCP/IP = is failing badly in the real world.  As long as link quality kept = getting better TCP/IP was fine, but with the random drop situations in = mobile phones and WiFi and the increase in congestion on cellular, WiFi = and backbone links, TCP/IP is breaking down (I live in New York, I can = document at least 1 TCP/IP failure per hour, minimum, due to noise, = packet loss and congestion that happens to me = personally).

Do = you have any data showing that these failures are SACK related, i.e. = would be fixed with better SACK design as you = suggest?


Preliminary comments on Saratoga -

1) Before I = give comments please understand I like and support where this protocol = is going, I just want people to think about how to make it = better.

2) The strength of the IETF protocols are simplicity and = solving the general case at the expense of the edge cases.  = Saratoga is starting to suffer from way = to

"The strength of = the IETF protocols are simplicity" =3D> this is a joke, = right??


many options, you need to define a core = implementation and a path to expansion in the base document not all = possible variants otherwise it will be a bear to implement since all = features must be included and treated equally.  I know you have put = in some thought on this and there are many places you say what is = mandatory but as a whole document can be overwhelming in it's = implications.

3) This protocol suffers from an extreme case of = OSI layer violation (worse than TCP/IP), the underlying transport should = be separated into it's own = document
and redone for more general use.  The file = control should ride atop that protocol.  A selection from the TDLC = standards document is below for your review.

 =46rom the = TDLC standard document -
 
 
Transmission Control = Byte
76543210    
xx    = ;      Type of = packet
00          User = Data
01          User = Command
10          = Supervisory = Data
11          = Supervisory Command

  = xx        Record Control
  = 11        Record is complete in this = message
  10        Record = starts with first byte of message
  = 01        Record ends with last byte = of this message
  00        = Record continues with this message
  
    = xx      Record Group = Control
    11      Record = Group is complete in this message
    = 10      Record Group starts with first byte of = this message
    01      = Record Group ends with last byte of this message
    = 00      Record group continues with this = message

Notes -

Type of packet - User data is the = norm.  User command is used for things like FTP commands, the file = is transferred as user data. Supervisory command and data perform = similar functions but handle situations such as = interrupt.    

Record Control - = Record control is shared between user and network control.  Only = complete records are delivered to user.  If network needs to split = packet then first packet will contain first bit and last packet will = contain second bit, other bits here would be zero.

Record Group = Control - Obeys same rules as Record control as far as packet splitting = but signals to user when first message of group is read and when last = message of group is read.


Numeric Compression

It is = only necessary to have one absolute number in the header, the "next in = sequence" (The TCP Acknowledge field), all other numbers in the message = should be realtive to this number.

TIFF defines a very light = weight compression scheme, a number consists of multiple bytes, high to = low order, the first bit of the byte is a "final" indicator and the low = 7 bits are the value.  As bytes are read the current value is = shifted left 7 bits and the low order 7 bits of the incoming byte are = added or ored in.  If the high order bit is a one the proccess is = complete, otherwise it keeps repeating until a byte with the high order = bit set to one is encountered. Thus values are 7, 14, 21, 28 et seq. = bits in length.

To be truly efficient numbers should be realtive = to the immediately precceding number thus requiring the smallest number = of bits to express the difference.


Bit Map = Compression

CCITT Group 3 one dimensional coding standard is a = run length limited code for binary compression which works well in = compressing a long bitmap of outstanding = messages.

Tony


Anthony Sabatini
200 West 20th = Street
Apt. 1216
New York, NY 10011

Phone: (212) = 867-7179
Mobile: (917) = 224-8388

 
__________________________________________= _____
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/m= ailman/listinfo/tcpm


<= /div>
Cheers,
Michael



_______________________________________________tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/ma= ilman/listinfo/tcpm

= --Apple-Mail=_EDD46465-13F0-442B-8BAC-AA4AE3965AB8-- From internet-drafts@ietf.org Tue Feb 5 18:04:32 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFE821F8A14; Tue, 5 Feb 2013 18:04:32 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-c0ouhr+Qmp; Tue, 5 Feb 2013 18:04:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C475D21F8A1D; Tue, 5 Feb 2013 18:04:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130206020431.23538.47805.idtracker@ietfa.amsl.com> Date: Tue, 05 Feb 2013 18:04:31 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-proportional-rate-reduction-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Feb 2013 02:04:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : Proportional Rate Reduction for TCP Author(s) : Matt Mathis Nandita Dukkipati Yuchung Cheng Filename : draft-ietf-tcpm-proportional-rate-reduction-04.txt Pages : 17 Date : 2013-02-05 Abstract: This document describes an experimental algorithm, Proportional Rate Reduction (PPR) to improve the accuracy of the amount of data sent by TCP during loss recovery. Standard Congestion Control requires that TCP and other protocols reduce their congestion window in response to losses. This window reduction naturally occurs in the same round trip as the data retransmissions to repair the losses, and is implemented by choosing not to transmit any data in response to some ACKs arriving from the receiver. Two widely deployed algorithms are used to implement this window reduction: Fast Recovery and Rate Halving. Both algorithms are needlessly fragile under a number of conditions, particularly when there is a burst of losses such that the number of ACKs returning to the sender is small. Proportional Rate Reduction minimizes these excess window adjustments such that at the end of recovery the actual window size will be as close as possible to ssthresh, the window size determined by the congestion control algorithm. It is patterned after Rate Halving, but using the fraction that is appropriate for target window chosen by the congestion control algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-proportional-rate-reduction There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-proportional-rate-reduction-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-proportional-rate-reduct= ion-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mattmathis@google.com Tue Feb 5 18:14:37 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A4A21F861A for ; Tue, 5 Feb 2013 18:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.677 X-Spam-Level: X-Spam-Status: No, score=-101.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwMlcI3Usf9S for ; Tue, 5 Feb 2013 18:14:37 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id F0C1D21F8614 for ; Tue, 5 Feb 2013 18:14:36 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id c12so1213646ieb.34 for ; Tue, 05 Feb 2013 18:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JLLpliMJ094rY2IOHD9vqB/28LhS/CQwYKyRpnNkiMQ=; b=BSlzuVV0aWztE8fL4jqp/vH4GwvYmhBaX+fZcf2lr0CTthdECJjxKKemRWBBYC7QIU lvpreEFJeIq/JXNffC6zWvPe03AJajpxmB3YDnBppZ38K37VAlFs7hEHaAeIum1bWjSN qbW3WI2SwJyXmFFrhWZWj3ZCnaHmbLm269uvP+yQKbtettRoeN4VsDQKM/j8yb4s8kfG Ry2/twKWBklOVQAH0TqWMUR03vba0IKBDzIP3k6OCilQ0HaNjjADHAwxn/Ckof8hg21x 5ty8pf5IoXvPFNHb6/jOa9eMZzjOk4+9H8cvdvPAaACsGNl1IWXDXj3jRuXJPMeNPPfl glAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=JLLpliMJ094rY2IOHD9vqB/28LhS/CQwYKyRpnNkiMQ=; b=Rei+xczJZc12ZtnAG9TOvnY1abbFCgo/pTlQZNRj+ZLKG90c928LtvEjyNdNEPnkle actz6joZtmoHVV34JSyi6Xritj7nP1aNvWQkVW8ZrhmhOPed8vd5wlGARl2V9MBsvXSf ylXAENhrkcrMe+uzjxlmlaCS4uevSE3LVccvpfY9R2IZDEmx41bvUlObgJrwVnVLqS6u 81im6XYdaXJjMUQtDVmxMQ9jcC7ORHfvoLrHkfZz8EdU+u0FjZ2dY1N1uNkiGKhsP3pt S7F08j7ywuCCya1dzbj7J1qjqYhK2KsglzUpCpy62GMgc++j5JZ369I1eRq1zAE8y2XV olew== MIME-Version: 1.0 X-Received: by 10.42.27.74 with SMTP id i10mr25874243icc.47.1360116876376; Tue, 05 Feb 2013 18:14:36 -0800 (PST) Received: by 10.64.124.98 with HTTP; Tue, 5 Feb 2013 18:14:36 -0800 (PST) In-Reply-To: <50B2F48A.9040603@mti-systems.com> References: <50B2F48A.9040603@mti-systems.com> Date: Tue, 5 Feb 2013 18:14:36 -0800 Message-ID: From: Matt Mathis To: Wesley Eddy Content-Type: multipart/alternative; boundary=20cf303f64ea44fb9504d504e356 X-Gm-Message-State: ALoCoQneBnDzaqqVWH3Xz2jOSew5DV1IR+19ZG5IlISp1iDDaoTdaCMAErCx7LuMlvwZD+WjI2NyqT4Rgx/gHxoOoD0cZhtsSO1T6pVIOCLs9y4JkBN3sMLG22kilpIJkQ2LdT1vD136RsPM19OJuOASJxgY25wJnjR8a8htfyqyynr4ST8k3LWXcOUahhOJaYVW9t8N36l7 Cc: "draft-ietf-tcpm-proportional-rate-reduction@tools.ietf.org, \"tcpm@ietf.org" Subject: Re: [tcpm] AD review of PRR draft X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Feb 2013 02:14:37 -0000 --20cf303f64ea44fb9504d504e356 Content-Type: text/plain; charset=ISO-8859-1 Sorry for the long delay. Version -04 posted per the comments below. As you may have noticed, TCP is not my first priority these days. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Sun, Nov 25, 2012 at 8:48 PM, Wesley Eddy wrote: > I've completed AD review of this document and have a few small > comments, some of which should be cleared up before going to > the IESG review. It is basically in really good shape, but I > see painful DISCUSS ballots coming if we don't clean up these > small things: > > > (1) It's really minor, but SACKs report received data, not lost > data. Lost data is inferred from what wasn't SACK'ed. A couple > places (like the last sentence of the 3rd paragraph in Section 1) > indicate that SACKs report missing data. I know what you really > mean, but it's technically wrong. > > > (2) All the references to 3517 probably made sense when the doc > was first written, but will really confuse the IESG, now that > 6675 obsoletes 3517. I *think* we can change all instances of > 3517 to 6675 and they all still work ... I know that it already > says: > """ > The analysis and measurement study presented here predates [RFC6675], > which updates RFC 3517. > """ > How about something like: > """ > The analysis and measurement study presented here predate [RFC6675], > which updates RFC 3517. Thus, RFC 3517 was used as the basis for > comparisons and some definitions, however, it is believed that the > changes in RFC 6675 do not significantly alter the results. > """ > Would that be true? If so, we should do this and change the > references. If not, then we need to do a little bit more > explaining about what in 6675 would change things. > > > (3) We are constantly seeing the IESG ask "What is the experiment?" > for Experimental RFCs. Indeed, the WG even asked this during the > last call when we looked at going to Standards Track. We should > have a paragraph (probably in section 6) that indicates a bit more > why we stuck with Experimental. A less cryptic version of what > Matt said in the WGLC thread would probably be good: > """ > Finally there are some details in PRR that are effected by Laminar. I > would rather not go to the effort of fixing the current draft to make > it a proper normative PS, but not totally correct. (Hint: Yoshifumi > Nishida's "off by one" comment reflects the difference between pipe > and total_pipe). > """ > > -- > Wes Eddy > MTI Systems > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --20cf303f64ea44fb9504d504e356 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry for the long delay. =A0Version -04 posted per the comments below.
As you may have noticed, TCP is not my first priority these= days.

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

Privacy matters! =A0We know from recent events that people are usin= g our services to speak in defiance of unjust governments. =A0 We treat pri= vacy and security as matters of life and death, because for some users, the= y are.


On Sun, Nov 25, 2012 at 8:48 PM, Wesley = Eddy <wes@mti-systems.com> wrote:
I've completed AD review of this document and have a few small
comments, some of which should be cleared up before going to
the IESG review. =A0It is basically in really good shape, but I
see painful DISCUSS ballots coming if we don't clean up these
small things:


(1) It's really minor, but SACKs report received data, not lost
data. =A0Lost data is inferred from what wasn't SACK'ed. =A0A coupl= e
places (like the last sentence of the 3rd paragraph in Section 1)
indicate that SACKs report missing data. =A0I know what you really
mean, but it's technically wrong.


(2) All the references to 3517 probably made sense when the doc
was first written, but will really confuse the IESG, now that
6675 obsoletes 3517. =A0I *think* we can change all instances of
3517 to 6675 and they all still work ... I know that it already
says:
"""
The analysis and measurement study presented here predates [RFC6675],
which updates RFC 3517.
"""
How about something like:
"""
The analysis and measurement study presented here predate [RFC6675],
which updates RFC 3517. =A0Thus, RFC 3517 was used as the basis for
comparisons and some definitions, however, it is believed that the
changes in RFC 6675 do not significantly alter the results.
"""
Would that be true? =A0If so, we should do this and change the
references. =A0If not, then we need to do a little bit more
explaining about what in 6675 would change things.


(3) We are constantly seeing the IESG ask "What is the experiment?&quo= t;
for Experimental RFCs. =A0Indeed, the WG even asked this during the
last call when we looked at going to Standards Track. =A0We should
have a paragraph (probably in section 6) that indicates a bit more
why we stuck with Experimental. =A0A less cryptic version of what
Matt said in the WGLC thread would probably be good:
"""
Finally there are some details in PRR that are effected by Laminar. =A0I would rather not go to the effort of fixing the current draft to make
it a proper normative PS, but not totally correct. =A0(Hint: Yoshifumi
Nishida's "off by one" comment reflects the difference betwee= n pipe
and total_pipe).
"""

--
Wes Eddy
MTI Systems
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--20cf303f64ea44fb9504d504e356-- From nishida@sfc.wide.ad.jp Wed Feb 6 00:22:35 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A59E21F8519 for ; Wed, 6 Feb 2013 00:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.677 X-Spam-Level: X-Spam-Status: No, score=-101.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hnvWe7+nBfQ for ; Wed, 6 Feb 2013 00:22:35 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id BF2CD21F84BB for ; Wed, 6 Feb 2013 00:22:34 -0800 (PST) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 67BCD2780CC for ; Wed, 6 Feb 2013 17:22:32 +0900 (JST) Received: by mail-ob0-f170.google.com with SMTP id wc20so1202047obb.29 for ; Wed, 06 Feb 2013 00:22:31 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.169.237 with SMTP id ah13mr5423056oec.41.1360138950929; Wed, 06 Feb 2013 00:22:30 -0800 (PST) Received: by 10.76.12.234 with HTTP; Wed, 6 Feb 2013 00:22:30 -0800 (PST) In-Reply-To: References: Date: Wed, 6 Feb 2013 00:22:30 -0800 Message-ID: From: Yoshifumi Nishida To: Ketan Kulkarni Content-Type: text/plain; charset=ISO-8859-1 Cc: tcpm@ietf.org Subject: Re: [tcpm] Few TCP Fast Open considerations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Feb 2013 08:22:35 -0000 Hi Ketan, My concern is how long the temporal condition will last. Is it 5 minutes or 5 days? 5 days might be absurd, but I'm not very sure how we can guarantee this. Another concern is false positive. If client see SYN without cookie just once, it might stop using TFO for the destination. If we have some smart logic at client side, we can address these issue. But, then, NULL cookie might not be very necessary. Thanks, -- Yoshifumi On Sun, Feb 3, 2013 at 8:09 PM, Ketan Kulkarni wrote: > Hi Yoshifumi, > With the current draft, there is no way fast open client can > differentiate between these two cases. > However, (albeit with little modification) server can "help" client > differentiate. > Here's how - > In first cases, server is restarted without fast open. So there is no > way server can "communicate" anything about fast open to the client. > In second case however, server supports fast open but is not able ack > syn+data. In such case, it can very well send a NULL cookie to the > client. Client on receipt of a NULL cookie can differentiate between > first and second case. > > If client detects first scenario, IMHO, client should stop sending > SYN+Data in subsequent connections to the server, as it has the > sufficient information to believe server is not supporting tcp fast > open. > While in second case, client can still attempt fast open (syn+data) in > subsequent connections as the condition is temporal and it can expect > the syn+data could be acked by the server. > > Sounds reasonable? > > Thanks, > Ketan > > On Thu, Jan 31, 2013 at 11:36 AM, Yoshifumi Nishida > wrote: >> Hi Ketan, >> >> On Mon, Jan 28, 2013 at 8:42 AM, Ketan Kulkarni wrote: >> >>> If above suggestion is ok, there could probably also be a need of >>> sending NULL cookie (again suggested by Yuchung on netdev) from >>> fast-open server. >>> Specifically, at fast-open client, to detect the difference between >>> the two different scenarios - >>> 1. server restarted without Fast Open and is no longer supporting it >>> (or any of the condition given above) >>> 2. fast-open server exhausted its fast-open backlog and is temporarily >>> not acking the data in SYN. >>> >>> In the 2nd case, server might choose to send the NULL cookie on the >>> receipt of which client understands the server still supports >>> fast-open but unable to do so temporarily. >>> It might also indicate cookie expiration - but I am not sure. >>> >>> I will like a wider view and more thoughts on such scenarios occurring >>> in the network. >> >> It seems to me that 1 and 2 are mostly the same unless you can know >> how long "temporarily" is. >> But, I'm guessing it'll be difficult to know.. >> >> -- >> Yoshifumi Nishida From l.wood@surrey.ac.uk Wed Feb 6 03:43:14 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CACA21F892B for ; Wed, 6 Feb 2013 03:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.821 X-Spam-Level: X-Spam-Status: No, score=-5.821 tagged_above=-999 required=5 tests=[AWL=-0.777, BAYES_00=-2.599, FRT_LITTLE=1.555, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHL4cT908kwx for ; Wed, 6 Feb 2013 03:43:13 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.98]) by ietfa.amsl.com (Postfix) with ESMTP id 89B2921F885C for ; Wed, 6 Feb 2013 03:43:12 -0800 (PST) Received: from [193.109.255.147:65318] by server-3.bemta-14.messagelabs.com id 7C/EF-22141-FC142115; Wed, 06 Feb 2013 11:43:11 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-12.tower-72.messagelabs.com!1360150990!10339549!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4537 invoked from network); 6 Feb 2013 11:43:10 -0000 Received: from unknown (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-12.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 6 Feb 2013 11:43:10 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.98]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Wed, 6 Feb 2013 11:43:10 +0000 From: To: Date: Wed, 6 Feb 2013 11:43:08 +0000 Thread-Topic: [tcpm] Fujitsu and Saratoga Thread-Index: Ac4Dgy9oLE62/CLjSGilUZiSUaXiNAA2Y/z+ Message-ID: <290E20B455C66743BE178C5C84F124081779FD38E5@EXMB01CMS.surrey.ac.uk> References: <9AD7A7D3-27D4-42FE-A320-B347F2343933@ifi.uio.no>, In-Reply-To: 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 Subject: Re: [tcpm] Fujitsu and Saratoga X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Feb 2013 11:43:14 -0000 ON various things: We encounter popcorn noise when wireless devices are coming into range, e.g= . a satellite low on the horizon when a pass is starting and link budget is= at its worst (and we can aggregate popcorn into large holes, trading off a= littlle retransmission on the fast downlink for space on the constrained u= plink.) But this isn't a scenario where we would consider using TCP. Did TDLC's bitmap and fixed packet size ever have to contend with changing = MTU size? Bitmaps strike me as coniderable computational effort for a scena= rio where the links are as fast as possible, but the processors are slow, a= nd fun for interop testing. Yes, Saratoga has optional parts; it's clear no-one cares about carrying bu= ndles, and bundle support is in a separate draft. UDP Lite is nice to have = so that time is minimised on checksums, but implementations live without it= - but thar's not enough spec to fill a separate draft. Streaming is needed= by some. Saratoga's SACK information can fill a packet, with a bit to indicate if th= is is all SACK info when sent, or more is needed in other packets. But impl= ementations don't need to hold SACK state between the state supplied in ack= s, and can work with what comes in in a fresh packet, so not having complet= e information is not a problem. Can you explain the OSI layer violation comment? If you want layering in a = transfer protocol, you can run ftp over TCP. If you want OSI, well, use OSI= ; layering over UDP is pretty clean. tftp (an internet standard) is not dis= similar in layering, though rather slower in performance. Lloyd Wood http://saratoga.sf.net/ ________________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Michael We= lzl [michawe@ifi.uio.no] Sent: 05 February 2013 09:28 To: tcpm Subject: Re: [tcpm] Fujitsu and Saratoga Oops. I just noticed that I've been thinking of SCTP too much lately, letti= ng me forget about a TCP limitation here - so here's me trying to fix my ow= n mistake before others do it, below: On 5. feb. 2013, at 09:42, Michael Welzl wrote: Dear Tony, all, On 4. feb. 2013, at 23:11, Anthony Sabatini wrote: L. Wood, W. Eddy - 1) TDLC is a true message based transmission layer control protocol (unlike= TCP which mixes layers). As such it is concerned only with the secure and= timely delivery of messages. It always has had event based transmission m= anagement, not timer based and without timers there is no congestion collap= se. 2) I chose a bit mapped representation for missing messages because number = pair schemes, such as SACK, falls apart if the number of outstanding holes = exceeds what can be carried in the options area of one message. For large = holes in the stream this is fine, for "popcorn" noise and loss situations i= t is a disaster. Additionally since I number messages, not bytes, I need 1= 0 bit smaller numbers to express the same capabilities that TCP does. So c= omparing apples to apples, if three sack pairs are in a message three holes= can be expressed (in some cases 4 holes) where as with a bitmap I can span= 192 messages uniquely, the equivalent of 192KB. Using CCITT Group 3 One d= imensional bit compression encoding I could express between 4 and 20 times = that many messages in the same space. That makes sense to me. What I really wonder is: do you have any data showi= ng that with an **up-to-date** TCP SACK, these situations really do become = catastrophic? I guess such an investigation would have to answer questions = like "in such extreme heavy loss situations, if TCP runs into a timeout, wa= sn't that the better thing to do anyway?" and "does such 'popcorn' noise re= ally appear at large enough scales to cause problems for today's TCP SACK"? One point of concern that I see is that bandwidth, and with it the BDP, is = growing, but the usual MTU isn't. Hence, if the space-wasted-by-SACK-proble= m that Tony describes really isn't an issue today, is it possible that this= becomes a true problem tomorrow? ... of course the MTU isn't the limit, it's the option size. I think this i= s fixed in SCTP (although not with a bit-map, hence presumably still wastin= g more space than TDLC). So, I guess that my questions above could already = be (partially) answered by some SCTP papers that show whether encoding more= SACK information makes SCTP significantly outperform TCP under realistic c= onditions. 3) Since TDLC is state/event driven as opposed to timer driven, many conges= tion situations will even themselves out by transmission rates slowing wait= ing for holes to be filled. TDLC was designed to work with ECN, not to try= to second guess what the router is doing or what it needs, it was implemet= ed with a token based ECN system where a nessage of less tahn 512 bytes too= k one token and and additional token for each 512 bytes or fraction thereof= . These numbers were chosen after consultation with the router manufacture= rs of the time (lower speed links used 256 bytes instead of 512). 4) The reason we are seeing so many alternatives to TCP/IP is that TCP/IP i= s failing badly in the real world. As long as link quality kept getting be= tter TCP/IP was fine, but with the random drop situations in mobile phones = and WiFi and the increase in congestion on cellular, WiFi and backbone link= s, TCP/IP is breaking down (I live in New York, I can document at least 1 T= CP/IP failure per hour, minimum, due to noise, packet loss and congestion t= hat happens to me personally). Do you have any data showing that these failures are SACK related, i.e. wou= ld be fixed with better SACK design as you suggest? Preliminary comments on Saratoga - 1) Before I give comments please understand I like and support where this p= rotocol is going, I just want people to think about how to make it better. 2) The strength of the IETF protocols are simplicity and solving the genera= l case at the expense of the edge cases. Saratoga is starting to suffer fr= om way to "The strength of the IETF protocols are simplicity" =3D> this is a joke, ri= ght?? many options, you need to define a core implementation and a path to expans= ion in the base document not all possible variants otherwise it will be a b= ear to implement since all features must be included and treated equally. = I know you have put in some thought on this and there are many places you s= ay what is mandatory but as a whole document can be overwhelming in it's im= plications. 3) This protocol suffers from an extreme case of OSI layer violation (worse= than TCP/IP), the underlying transport should be separated into it's own d= ocument and redone for more general use. The file control should ride atop that pr= otocol. A selection from the TDLC standards document is below for your rev= iew. From the TDLC standard document - Transmission Control Byte 76543210 xx Type of packet 00 User Data 01 User Command 10 Supervisory Data 11 Supervisory Command xx Record Control 11 Record is complete in this message 10 Record starts with first byte of message 01 Record ends with last byte of this message 00 Record continues with this message xx Record Group Control 11 Record Group is complete in this message 10 Record Group starts with first byte of this message 01 Record Group ends with last byte of this message 00 Record group continues with this message Notes - Type of packet - User data is the norm. User command is used for things li= ke FTP commands, the file is transferred as user data. Supervisory command = and data perform similar functions but handle situations such as interrupt. Record Control - Record control is shared between user and network control.= Only complete records are delivered to user. If network needs to split p= acket then first packet will contain first bit and last packet will contain= second bit, other bits here would be zero. Record Group Control - Obeys same rules as Record control as far as packet = splitting but signals to user when first message of group is read and when = last message of group is read. Numeric Compression It is only necessary to have one absolute number in the header, the "next i= n sequence" (The TCP Acknowledge field), all other numbers in the message s= hould be realtive to this number. TIFF defines a very light weight compression scheme, a number consists of m= ultiple bytes, high to low order, the first bit of the byte is a "final" in= dicator and the low 7 bits are the value. As bytes are read the current va= lue is shifted left 7 bits and the low order 7 bits of the incoming byte ar= e added or ored in. If the high order bit is a one the proccess is complet= e, otherwise it keeps repeating until a byte with the high order bit set to= one is encountered. Thus values are 7, 14, 21, 28 et seq. bits in length. To be truly efficient numbers should be realtive to the immediately precced= ing number thus requiring the smallest number of bits to express the differ= ence. Bit Map Compression CCITT Group 3 one dimensional coding standard is a run length limited code = for binary compression which works well in compressing a long bitmap of out= standing messages. Tony Anthony Sabatini 200 West 20th Street Apt. 1216 New York, NY 10011 Phone: (212) 867-7179 Mobile: (917) 224-8388 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm Cheers, Michael From ketkulka@gmail.com Wed Feb 6 20:59:25 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0579321F84F9 for ; Wed, 6 Feb 2013 20:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N312EgZtyVxE for ; Wed, 6 Feb 2013 20:59:24 -0800 (PST) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id E18DF21F84F8 for ; Wed, 6 Feb 2013 20:59:23 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id b10so1956522vea.2 for ; Wed, 06 Feb 2013 20:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=RhYrEAuaFGuTbztgq4zn9XrxWx1Nrt1zdr4G7lb+INI=; b=V0ffPUR0Yijz6fdZh2wf6jVTIMcWUOhOAZEcc2q+JIoiNAVLaPXm0EMo2OUlNd/vy+ UMlnY+ltr7hq6N1Ld4gN8xmCnDuCFJdQEPCETszfY5H/vnsYJ4zhCDa/31A+THPfNIY4 zGoFvWlM0jRutrU483nPuZE69UdnqQU3V3zTG8hEjg3M8hdrK88LOk8JNOxvflpXI1QX UT2o0S92tYB01kF4HEuDRK9Os4jJyaFm9LKxex9vH4ESNaaE6ena2dOTYnTtSh/VcA7p ZdQfFo4jE/iBeKyKnQ14hXLXVfnUghX0N8Cg/dvA4EUYDzZGUocwHbRkQo7lVIN+i0Yf /cKw== MIME-Version: 1.0 X-Received: by 10.52.22.194 with SMTP id g2mr32451185vdf.91.1360213163222; Wed, 06 Feb 2013 20:59:23 -0800 (PST) Received: by 10.58.107.166 with HTTP; Wed, 6 Feb 2013 20:59:23 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Feb 2013 10:29:23 +0530 Message-ID: From: Ketan Kulkarni To: Yoshifumi Nishida Content-Type: multipart/alternative; boundary=20cf307ac3f769a80804d51b4e74 Cc: tcpm@ietf.org Subject: Re: [tcpm] Few TCP Fast Open considerations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 07 Feb 2013 04:59:25 -0000 --20cf307ac3f769a80804d51b4e74 Content-Type: text/plain; charset=ISO-8859-1 Hi Yoshifumi, Well my idea is as follows - With current draft, tfo client follows this "state machine" 1. Request a cookie from server 2. If cookie is received, cache it. 3. Attempt syn+data to subsequent connections if cookie is cached. There is no way now for the client to detect the server is not supporting tfo. If we modify the state-machine by adding a 4th state as follows - 1. Request a cookie from server 2. If cookie is received, cache it. 3. Attempt syn+data to subsequent connections if cookie is cached. 4. If server does not respond to syn+data (server not acking data in syn), go back to state 1 for subsequent connections. By this logic, there is a way for tfo client to go back to state 1 and re-attempt cookie request. I already mentioned various conditions earlier in my mails in what all cases server does not respond to syn+data. To detect difference between couple of scenarios, I also suggested to have null cookie (or something else if there is any other way) Now having the modified "state-machine" prevents your concerns of false positive. Even if due to false positives client doesn't attempt syn+data, it does attempt cookie request. So the penalty could at max well be limited to one connection. It also gets rid of the temporal aspect of server exhausting backlog. Another benefit it provides in cases of server stop supporting tfo. In such cases, it is seen that client always attempts syn+data and server never acks data and data in syn is retransmitted. That is really odd and I don't think it should be acceptable. If we can have a simpler way to avoid it then why not? Thanks, Ketan On Wed, Feb 6, 2013 at 1:52 PM, Yoshifumi Nishida wrote: > Hi Ketan, > > My concern is how long the temporal condition will last. Is it 5 > minutes or 5 days? 5 days might be absurd, but I'm not very sure how > we can guarantee this. > Another concern is false positive. If client see SYN without cookie > just once, it might stop using TFO for the destination. > > If we have some smart logic at client side, we can address these > issue. But, then, NULL cookie might not be very necessary. > > Thanks, > -- > Yoshifumi > > On Sun, Feb 3, 2013 at 8:09 PM, Ketan Kulkarni wrote: > > Hi Yoshifumi, > > With the current draft, there is no way fast open client can > > differentiate between these two cases. > > However, (albeit with little modification) server can "help" client > > differentiate. > > Here's how - > > In first cases, server is restarted without fast open. So there is no > > way server can "communicate" anything about fast open to the client. > > In second case however, server supports fast open but is not able ack > > syn+data. In such case, it can very well send a NULL cookie to the > > client. Client on receipt of a NULL cookie can differentiate between > > first and second case. > > > > If client detects first scenario, IMHO, client should stop sending > > SYN+Data in subsequent connections to the server, as it has the > > sufficient information to believe server is not supporting tcp fast > > open. > > While in second case, client can still attempt fast open (syn+data) in > > subsequent connections as the condition is temporal and it can expect > > the syn+data could be acked by the server. > > > > Sounds reasonable? > > > > Thanks, > > Ketan > > > > On Thu, Jan 31, 2013 at 11:36 AM, Yoshifumi Nishida > > wrote: > >> Hi Ketan, > >> > >> On Mon, Jan 28, 2013 at 8:42 AM, Ketan Kulkarni > wrote: > >> > >>> If above suggestion is ok, there could probably also be a need of > >>> sending NULL cookie (again suggested by Yuchung on netdev) from > >>> fast-open server. > >>> Specifically, at fast-open client, to detect the difference between > >>> the two different scenarios - > >>> 1. server restarted without Fast Open and is no longer supporting it > >>> (or any of the condition given above) > >>> 2. fast-open server exhausted its fast-open backlog and is temporarily > >>> not acking the data in SYN. > >>> > >>> In the 2nd case, server might choose to send the NULL cookie on the > >>> receipt of which client understands the server still supports > >>> fast-open but unable to do so temporarily. > >>> It might also indicate cookie expiration - but I am not sure. > >>> > >>> I will like a wider view and more thoughts on such scenarios occurring > >>> in the network. > >> > >> It seems to me that 1 and 2 are mostly the same unless you can know > >> how long "temporarily" is. > >> But, I'm guessing it'll be difficult to know.. > >> > >> -- > >> Yoshifumi Nishida > --20cf307ac3f769a80804d51b4e74 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Yoshifumi,

Well my idea is as follows -

With current draft= , tfo client follows this "state machine"

1. Request a coo= kie from server
2. If cookie is received, cache it.
3. Attempt syn+da= ta to subsequent connections if cookie is cached.

There is no way now for the client to detect the server is not supporti= ng tfo.

If we modify the state-machine by adding a 4th state as foll= ows -
1. Request a cookie from server
2. If cookie is received, cache it.
3. Attempt syn+data to subsequent connections if cookie is cached.
4. If= server does not respond to syn+data (server not acking data in syn), go ba= ck to state 1 for subsequent connections.

By this logic, there is a = way for tfo client to go back to state 1 and re-attempt cookie request.

I already mentioned various conditions earlier in my mails in what all = cases server does not respond to syn+data.
To detect difference between = couple of scenarios, I also suggested to have null cookie (or something els= e if there is any other way)

Now having the modified "state-machine" prevents your concern= s of false positive.
Even if due to false positives client doesn't a= ttempt syn+data, it does attempt cookie request. So the penalty could at ma= x well be limited to one connection. It also gets rid of the temporal aspec= t of server exhausting backlog.

Another benefit it provides in cases of server stop supporting tfo. In = such cases, it is seen that client always attempts syn+data and server neve= r acks data and data in syn is retransmitted.
That is really odd and I d= on't think it should be acceptable.
If we can have a simpler way to avoid it then why not?

Thanks,
Ke= tan

On Wed, Feb 6, 2013 at 1:52 PM, Yoshi= fumi Nishida <nishida@sfc.wide.ad.jp> wrote:
Hi Ketan,

My concern is how long the temporal condition will last. Is it 5
minutes or 5 days? 5 days might be absurd, but I'm not very sure how we can guarantee this.
Another concern is false positive. If client see SYN without cookie
just once, it might stop using TFO for the destination.

If we have some smart logic at client side, we can address these
issue. But, then, NULL cookie might not be very necessary.

Thanks,
--
Yoshifumi

On Sun, Feb 3, 2013 at 8:09 PM, Ketan Kulkarni <ketkulka@gmail.com> wrote:
> Hi Yoshifumi,
> With the current draft, there is no way fast open client can
> differentiate between these two cases.
> However, (albeit with little modification) server can "help"= client
> differentiate.
> Here's how -
> In first cases, server is restarted without fast open. So there is no<= br> > way server can "communicate" anything about fast open to the= client.
> In second case however, server supports fast open but is not able ack<= br> > syn+data. In such case, it can very well send a NULL cookie to the
> client. Client on receipt of a NULL cookie can differentiate between > first and second case.
>
> If client detects first scenario, IMHO, client should stop sending
> SYN+Data in subsequent connections to the server, as it has the
> sufficient information to believe server is not supporting tcp fast > open.
> While in second case, client can still attempt fast open (syn+data) in=
> subsequent connections as the condition is temporal and it can expect<= br> > the syn+data could be acked by the server.
>
> Sounds reasonable?
>
> Thanks,
> Ketan
>
> On Thu, Jan 31, 2013 at 11:36 AM, Yoshifumi Nishida
> <nishida@sfc.wide.ad.jp> wrote:
>> Hi Ketan,
>>
>> On Mon, Jan 28, 2013 at 8:42 AM, Ketan Kulkarni <ketkulka@gmail.com> wrote:
>>
>>> If above suggestion is ok, there could probably also be a need= of
>>> sending NULL cookie (again suggested by Yuchung on netdev) fro= m
>>> fast-open server.
>>> Specifically, at fast-open client, to detect the difference be= tween
>>> the two different scenarios -
>>> 1. server restarted without Fast Open and is no longer support= ing it
>>> (or any of the condition given above)
>>> 2. fast-open server exhausted its fast-open backlog and is tem= porarily
>>> not acking the data in SYN.
>>>
>>> In the 2nd case, server might choose to send the NULL cookie o= n the
>>> receipt of which client understands the server still supports<= br> >>> fast-open but unable to do so temporarily.
>>> It might also indicate cookie expiration - but I am not sure.<= br> >>>
>>> I will like a wider view and more thoughts on such scenarios o= ccurring
>>> in the network.
>>
>> It seems to me that 1 and 2 are mostly the same unless you can kno= w
>> how long "temporarily" is.
>> But, I'm guessing it'll be difficult to know..
>>
>> --
>> Yoshifumi Nishida

--20cf307ac3f769a80804d51b4e74-- From ketkulka@gmail.com Wed Feb 6 21:13:04 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBDB21F842C for ; Wed, 6 Feb 2013 21:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.832 X-Spam-Level: X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dC-TrS8nGbqL for ; Wed, 6 Feb 2013 21:13:03 -0800 (PST) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id B52F821F842B for ; Wed, 6 Feb 2013 21:13:03 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id b10so1963121vea.2 for ; Wed, 06 Feb 2013 21:13:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=v0gUsUHU6gyPNetp/+Yt03ejvt4lHZsUtflo1uOGp5s=; b=bWsos/ek/XzTx3I2qjor1j7cDpM4UDeV1DX2on89XqZ35SzVa1j86cWjJdp9hIGfEC xWCvqYoIDYuFKRgHQVSg0rYi9aOeYgjGCfD9HPOYpl4sup0U3njhcOIg3TOC2lV3ygu+ bYPrbrzxkZr+CJ88g7ZtpXgjxJIxlkYpKq5DFj8QWIrT66kpwRwNEllQfL9De7xnGYtD faXIPuXLOF8a2D+a1Vx75XxX+t4XH47z+d+6jMAF5gHW4+L/FZzVfASsjSRbB3IKOGWU qw3UwzEvs7Vi6WRnDREhBvjseoczynh2ZoyQNc6g7NzD0JnOyQsKDEwA6znVlQsKiOyI XNzQ== MIME-Version: 1.0 X-Received: by 10.52.21.175 with SMTP id w15mr31722728vde.100.1360213983082; Wed, 06 Feb 2013 21:13:03 -0800 (PST) Received: by 10.58.107.166 with HTTP; Wed, 6 Feb 2013 21:13:03 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Feb 2013 10:43:03 +0530 Message-ID: From: Ketan Kulkarni To: "Scheffenegger, Richard" Content-Type: multipart/alternative; boundary=20cf307c9bba47b78904d51b7f2a Cc: tcpm Subject: Re: [tcpm] Few TCP Fast Open considerations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 07 Feb 2013 05:13:04 -0000 --20cf307c9bba47b78904d51b7f2a Content-Type: text/plain; charset=ISO-8859-1 Hi Richard, Not sure if I understand your question completely. Still framing the answer :-) NULL cookie revocation will happen when the client re-requests the cookie from server. Probably the modification to the state-machine I proposed in my last mail might clarify it little further. Thanks, Ketan On Mon, Feb 4, 2013 at 5:26 PM, Scheffenegger, Richard wrote: > Hi, > > Sorry, i'm cached only so i can not check in the draft: > > > Ketan, you mentioned a cookie revokation also as a potential use for a > null cookie. But if the reply to a fo syn is a null cookie to indicate a > temporary overload situation (where the server probably doesn't want to > hand out new cookies), how would such a cookie revokation during syn happen? > > Best regards, > Richard > > > > Am 04.02.2013 um 05:09 schrieb "Ketan Kulkarni" : > > > Hi Yoshifumi, > > With the current draft, there is no way fast open client can > > differentiate between these two cases. > > However, (albeit with little modification) server can "help" client > > differentiate. > > Here's how - > > In first cases, server is restarted without fast open. So there is no > > way server can "communicate" anything about fast open to the client. > > In second case however, server supports fast open but is not able ack > > syn+data. In such case, it can very well send a NULL cookie to the > > client. Client on receipt of a NULL cookie can differentiate between > > first and second case. > > > > If client detects first scenario, IMHO, client should stop sending > > SYN+Data in subsequent connections to the server, as it has the > > sufficient information to believe server is not supporting tcp fast > > open. > > While in second case, client can still attempt fast open (syn+data) in > > subsequent connections as the condition is temporal and it can expect > > the syn+data could be acked by the server. > > > > Sounds reasonable? > > > > Thanks, > > Ketan > > > > On Thu, Jan 31, 2013 at 11:36 AM, Yoshifumi Nishida > > wrote: > >> Hi Ketan, > >> > >> On Mon, Jan 28, 2013 at 8:42 AM, Ketan Kulkarni > wrote: > >> > >>> If above suggestion is ok, there could probably also be a need of > >>> sending NULL cookie (again suggested by Yuchung on netdev) from > >>> fast-open server. > >>> Specifically, at fast-open client, to detect the difference between > >>> the two different scenarios - > >>> 1. server restarted without Fast Open and is no longer supporting it > >>> (or any of the condition given above) > >>> 2. fast-open server exhausted its fast-open backlog and is temporarily > >>> not acking the data in SYN. > >>> > >>> In the 2nd case, server might choose to send the NULL cookie on the > >>> receipt of which client understands the server still supports > >>> fast-open but unable to do so temporarily. > >>> It might also indicate cookie expiration - but I am not sure. > >>> > >>> I will like a wider view and more thoughts on such scenarios occurring > >>> in the network. > >> > >> It seems to me that 1 and 2 are mostly the same unless you can know > >> how long "temporarily" is. > >> But, I'm guessing it'll be difficult to know.. > >> > >> -- > >> Yoshifumi Nishida > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > --20cf307c9bba47b78904d51b7f2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Richard,
Not sure if I understand your question completely.
Still = framing the answer :-)

NULL cookie revocation will happen when the c= lient re-requests the cookie from server. Probably the modification to the = state-machine I proposed in my last mail might clarify it little further.
Thanks,
Ketan

On Mon, Feb 4, 2013 = at 5:26 PM, Scheffenegger, Richard <rs@netapp.com> wrote:
Hi,

Sorry, i'm cached only so i can not check in the draft:


Ketan, you mentioned a cookie revokation also as a potential use for a null= cookie. But if the reply to a fo syn is a null cookie to indicate a tempor= ary overload situation (where the server probably doesn't want to hand = out new cookies), how would such a cookie revokation during syn happen?

Best regards,
=A0 =A0Richard



Am 04.02.2013 um 05:09 schrieb "Ketan Kulkarni" <ketkulka@gmail.com>:

> Hi Yoshifumi,
> With the current draft, there is no way fast open client can
> differentiate between these two cases.
> However, (albeit with little modification) server can "help"= client
> differentiate.
> Here's how -
> In first cases, server is restarted without fast open. So there is no<= br> > way server can "communicate" anything about fast open to the= client.
> In second case however, server supports fast open but is not able ack<= br> > syn+data. In such case, it can very well send a NULL cookie to the
> client. Client on receipt of a NULL cookie can differentiate between > first and second case.
>
> If client detects first scenario, IMHO, client should stop sending
> SYN+Data in subsequent connections to the server, as it has the
> sufficient information to believe server is not supporting tcp fast > open.
> While in second case, client can still attempt fast open (syn+data) in=
> subsequent connections as the condition is temporal and it can expect<= br> > the syn+data could be acked by the server.
>
> Sounds reasonable?
>
> Thanks,
> Ketan
>
> On Thu, Jan 31, 2013 at 11:36 AM, Yoshifumi Nishida
> <nishida@sfc.wide.ad.jp> wrote:
>> Hi Ketan,
>>
>> On Mon, Jan 28, 2013 at 8:42 AM, Ketan Kulkarni <ketkulka@gmail.com> wrote:
>>
>>> If above suggestion is ok, there could probably also be a need= of
>>> sending NULL cookie (again suggested by Yuchung on netdev) fro= m
>>> fast-open server.
>>> Specifically, at fast-open client, to detect the difference be= tween
>>> the two different scenarios -
>>> 1. server restarted without Fast Open and is no longer support= ing it
>>> (or any of the condition given above)
>>> 2. fast-open server exhausted its fast-open backlog and is tem= porarily
>>> not acking the data in SYN.
>>>
>>> In the 2nd case, server might choose to send the NULL cookie o= n the
>>> receipt of which client understands the server still supports<= br> >>> fast-open but unable to do so temporarily.
>>> It might also indicate cookie expiration - but I am not sure.<= br> >>>
>>> I will like a wider view and more thoughts on such scenarios o= ccurring
>>> in the network.
>>
>> It seems to me that 1 and 2 are mostly the same unless you can kno= w
>> how long "temporarily" is.
>> But, I'm guessing it'll be difficult to know..
>>
>> --
>> Yoshifumi Nishida
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

--20cf307c9bba47b78904d51b7f2a-- From michael.scharf@alcatel-lucent.com Fri Feb 8 00:59:24 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A5F21F86F5 for ; Fri, 8 Feb 2013 00:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.378 X-Spam-Level: X-Spam-Status: No, score=-7.378 tagged_above=-999 required=5 tests=[AWL=-1.729, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9kdEwftVgGl for ; Fri, 8 Feb 2013 00:59:23 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9CF21F86F7 for ; Fri, 8 Feb 2013 00:59:22 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r188x6HS005911 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 8 Feb 2013 09:59:21 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 8 Feb 2013 09:59:19 +0100 From: "Scharf, Michael (Michael)" To: tcpm Date: Fri, 8 Feb 2013 09:59:19 +0100 Thread-Topic: Presentations at IETF 86 Thread-Index: Ac4Fn4ZD8trOzw+wSW6GDTcHABUoiAAOfGiA Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0B4CD@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "tcpm-chairs@tools.ietf.org" Subject: [tcpm] Presentations at IETF 86 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 08 Feb 2013 08:59:24 -0000 Hi all, The tentative schedule for the tcpm meeting in Orlando is: Tuesday, Morning Session I+II, 0900-11:30 If you want to ask for a time slot, please let the chairs know until Feb 25= : * Title / Internet-Draft * Presenter * Requested time Thanks Michael, Pasi, Yoshifumi From internet-drafts@ietf.org Mon Feb 11 03:36:37 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F8321F87A3; Mon, 11 Feb 2013 03:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdRS2t+5Ol7Q; Mon, 11 Feb 2013 03:36:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD80C21F842D; Mon, 11 Feb 2013 03:36:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130211113636.22016.7086.idtracker@ietfa.amsl.com> Date: Mon, 11 Feb 2013 03:36:36 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-accecn-reqs-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 11 Feb 2013 11:36:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : Problem Statement and Requirements for a More Accurate E= CN Feedback Author(s) : Mirja Kuehlewind Richard Scheffenegger Filename : draft-ietf-tcpm-accecn-reqs-00.txt Pages : 9 Date : 2013-02-11 Abstract: Explicit Congestion Notification (ECN) is an IP/TCP mechanism where network nodes can mark IP packets instead of dropping them to indicate congestion to the end-points. An ECN-capable receiver will feedback this information to the sender. ECN is specified for TCP in such a way that only one feedback signal can be transmitted per Round-Trip Time (RTT). Recently, new TCP mechanisms like ConEx or DCTCP need more accurate ECN feedback information in the case where more than one marking is received in one RTT. This documents specifies requirement for different ECN feedback scheme in the TCP header to provide more than one feedback signal per RTT. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-accecn-reqs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-accecn-reqs-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From magnus.westerlund@ericsson.com Mon Feb 11 06:44:36 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778F321F89EE; Mon, 11 Feb 2013 06:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.604 X-Spam-Level: X-Spam-Status: No, score=-105.604 tagged_above=-999 required=5 tests=[AWL=0.645, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76OqIP6z33gE; Mon, 11 Feb 2013 06:44:34 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id EE88621F8715; Mon, 11 Feb 2013 06:44:33 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-b8-511903d0a77e Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E8.82.10459.0D309115; Mon, 11 Feb 2013 15:44:32 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Mon, 11 Feb 2013 15:44:32 +0100 Message-ID: <511903CF.4050007@ericsson.com> Date: Mon, 11 Feb 2013 15:44:31 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Matt Mathis References: <20121126212940.20378.58186.idtracker@ietfa.amsl.com> <50C06CE6.40909@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUyM+Jvje4FZslAg59zLSyebZzPYnH+3CVW i20n5zM5MHss2FTqsWTJT6YApigum5TUnMyy1CJ9uwSujK2XZjIXdKZXnHj9nb2BcWFwFyMn h4SAicTlN71MELaYxIV769m6GDk4hAROMkrs0eti5AIylzNKnGxrYwWp4RXQlnjzqpEZxGYR UJU4smUeC4jNJmAhcfNHIxuILSoQLLHh4ComiHpBiZMzn4DViAioS1x6fhCshllAQWLXtNdg c4QFCiXuNK5lgli2hFFi8ot5jCAJToFAifkfP7GAHCQhIC6x5g0HRK+exJSrLYwQtrxE89bZ YHOEgG5raOpgncAoNAvJ6llIWmYhaVnAyLyKkT03MTMnvdxwEyMwYA9u+a27g/HUOZFDjNIc LErivGGuFwKEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MDY52unLmbzw0V2t6jVZO1Z/Qxzf p4LEF2Ic4lf1S222nljy66Heeu4dL9d2H4ux8d8kqO/15fw6Yw3lw81TBXiex98V2v1jf8q/ 2E4L9VB+x5vOaf/eLNzBMnmBLk/v/uqIzadc21neavYeNjoR6f/55obWh+/Y/5/wXs4y28Nq D1NTRfyNHiWW4oxEQy3mouJEAL1Jt3kmAgAA Cc: tcpm@ietf.org, ietf@ietf.org Subject: Re: [tcpm] Last Call: (Increasing TCP's Initial Window) to Experimental RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 11 Feb 2013 14:44:36 -0000 On 2013-01-24 23:35, Matt Mathis wrote: > Magnus, > > In behalf of the draft-ietf-tcpm-initcwnd authors I publicly address > the comments in your IETF LC review of draft-ietf-tcpm-initcwnd-06. > > In regards to interactions between IW and real time traffic (your > points 1&2 below and echoed in Robert Spark's DISCUSS): > > By design TCP creates queues to measure the bottleneck bandwidth. > Reducing the jitter for real time traffic is not a goal for TCP. > Although there are a number of TCP centric approaches for reducing > jitter, including reducing queue space, deploying AQM and limiting IW, > none are general nor work in all situations. Furthermore if you > construct a scenario where one of these approaches seems to help, a > slight variation on that scenario will fail. In the case of IW, > larger transactions will produce equally large queue occupancy later > on during slowstart or during bulk transfers. > > This observation is borne out by the work of Ilpo Jarvinen et al. See > http://www.tschofenig.priv.at/cc-workshop/irtf_iab-ccirtcpaper9.pdf > and the tcpm slides from IETF 84 > http://www.ietf.org/proceedings/84/slides/slides-84-tcpm-11. > > We have not attempted to measure IW10 impact on real time traffic, > however we have investigated over one year of historical performance > data for our Hangout/Talk application where we track both the startup > delay of an audio/video call as well as a jitter metric. Our data > shows no degradation in either metric as IW10 is deployed at Google > and elsewhere. In fact, we see a steady improvement in our metrics, > even for the tail end of the users, which we attribute to generally > better connectivity. > > As you noted, the only real solution to controlling jitter is to put > real time and throughput maximizing traffic into separate queues. > All other solutions have the property that they force implementers to > make tradeoffs between peak queuing delay and link utilization, and as > such are just workarounds that don't actually solve the root problem. > The real time community has finally come to understand this reality, > as reflected in the RMCAT charter. > > These workarounds can be characterized as protecting RT traffic by > deliberately making TCP less aggressive than desired to quickly fill > the network. Continuing to use these workarounds widens the gap > between actual application performance and raw network capacity. This > fact is not lost on application developers and users who often observe > only slight application performance improvements after deploying > expensive faster networks, unless they take things under their own > control by opening multiple connections. As we all know, this > approach undermines TCP's ability to control congestion. > > Trying to make TCP compensate for the lack of segregated queueing (a > network problem) prevents correct solutions to problems caused by TCP > itself, namely it being too timid for most of todays networks. Given > the wide discussion of bufferbloat and the need for traffic > segregation to support important RT applications, it is fairly likely > that the network problems will come to be solved and the solutions > widely deployed in the next few years. A side benefit of these > changes to better support RT will be to further limit any possible > impact of IW10 on other Internet traffic. Thanks for providing some more investigation material. Even from a TCP perspective I think it is important as the experiment continues that one include measurement data on how the one-way delay is affected as also TCP flows carries "real-time" data. To be clear, your answer has resulted in my having the position that not going forward with IW10 is probably worse for the Internet than to not do it. There is clearly work to be done dealing with buffer-bloat but also the reactions in the growing heterogeneous behavior of Internet paths. This is an encouragement to people doing active work on this to continue. > > In regards to your point 3, about client domains that experience > persistent problems with IW10. We propose to add a sentence at the > end of section 12 (Usage and Deployment Recommendation): "Resolution > of these experiments and tighter specifications of the suggestions > here might be grounds for a future standards track document on the > same topic." Ok, so you don't yet have even an experimental algorithm that you are confident in auto performing this process yet. I think this is a bit worrying, but consider the relative few that appears having such issues according to your investigations I am willing to take the chance. > > In regards to your point 4, clarify incentives in section 3 by > replacing end of the 2nd paragraph: "A larger initial window will > incentivize applications to use fewer concurrent TCP connections." > With: "If a larger initial window causes harm to any other flows then > local application tuning will reveal that fewer concurrent connections > yields better performance for some users. Any content provider > deploying IW10 in conjunction with content distributed across multiple > domains is explicitly encouraged to perform measurement experiments to > detect such problems, and to consider reducing the number of > concurrent connections used to retrieve their content." As this was really a guess for the future which was difficult to act on I think the above is as well as I can see you do anything about my issues. >From my perspective I think this can be published as an experimental with the proposed updates. Cheers Magnus > > Other planned change to the draft as requested by IESG feedback: > > Drop "Updates RFC 3390 and 5681" from the metadata. > > This change answers the DISCUSSes posted by Brian Haberman and Ralph Droms. > > I believe that together these chanes should address all of the IESG > DISCUSS items. > > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay > > Privacy matters! We know from recent events that people are using our > services to speak in defiance of unjust governments. We treat > privacy and security as matters of life and death, because for some > users, they are. > > > On Thu, Dec 6, 2012 at 2:01 AM, Magnus Westerlund > wrote: >> Hi, >> >> I have reviewed draft-ietf-tcpm-initcwnd-06 and have some questions and >> comments. >> >> 1) First of all the experiments done appear to cover the impact on other >> applications, like measuring the RTT variations when using IW10 compared >> to IW3. If one is interested in the impact this proposal have on >> real-time traffic flows over a shared bottle-neck the variations in >> queue time at the bottleneck combined with that flows seen loss rates >> are the most important factors. As a sudden delay spike of sufficient >> magnitude will most likely result in a real-time media packet being >> late, i.e. late loss rather than being lost in the network there might >> be significant impact on such traffic from these IW10 packet bursts. >> Have I missed any material discussing this aspect? >> >> All the latency figures in the parts I was looking at was discussing >> cases when the object transfer takes longer time. But it appear obvious >> that even with a 100 ms increased one-way transfer time for a packet is >> the end of the initial window the total transfer goes faster compared to >> the delay caused by growing the window. >> >> 2) If I assume that most users are behind buffer-bloated links the >> introduction of IW10 on wide scale will additionally disrupt interactive >> applications and cause increased delay and possible late loss depending >> on application. Especially in combination with domain sharding. For >> example a Swedish newspaper's website front page results in that more >> than 40 TCP connections are opened in a current browser. If these all >> was using IW10, the amount of packets being sent initially will grow >> roughly from 40*3 = 120 to 40*10 = 400. There are some distribution over >> time but still this likely results in a larger delay spike. >> >> I don't quite know how I should consider this case. One stand point is >> that the interactive application is anyway buggered and IW10 effects are >> not making it significantly worse. The only remedy is queue separation >> so that what ever happens with the web-downloads doesn't affect the >> interactive traffic. Another is that it will make the existing situation >> worse and we should try to avoid making it worse. >> >> I think I am more in the first camp, but still the second one is >> worrying to me. But I dare to guess that the performance gains might be >> worth the issues, but without real progress on mitigation of the buffer >> bloat issues for interactive real-time traffic this will add >> significantly to the issues real-time has to face. >> >> >> 3) The documents talks in quite loose terms about what can be done to >> avoid to continue cause issues for destinations which has issues with >> IW10. However I think it is a bit unspecific here. I can see that a >> content deliverer can have lists for destination address blocks that >> they see issues with which configures the sending server side with a >> lower IW value. It also talks about the clients can configure to keep >> the window low initially to prevent an IW10 sender to clobber ones link >> if that is known. My question here is if the recommendation for auto >> detection and configuration can be made more explicit. Fortunately the >> issues with misconfiguration in this cases is not that serious. But >> otherwise there is commonly need to be quite careful with such auto >> configs that affects the behavior. >> >> 4) I am also worried that the document is a bit to positive in regards >> to that IW10 will reduce the domain sharding practice. I think the only >> thing that can do is likely a new HTTP transport strata that shows that >> significantly improved performance for multiple objects from the same >> domain over fewer transport flows. Maybe SPDY + IW10 can provide such >> incentive, but I don't think IW10 alone will do much. >> >> Cheers >> >> Magnus >> >> On 2012-11-26 22:29, The IESG wrote: >>> >>> The IESG has received a request from the TCP Maintenance and Minor >>> Extensions WG (tcpm) to consider the following document: >>> - 'Increasing TCP's Initial Window' >>> as Experimental RFC >>> >>> The IESG plans to make a decision in the next few weeks, and solicits >>> final comments on this action. Please send substantive comments to the >>> ietf@ietf.org mailing lists by 2012-12-10. Exceptionally, comments may be >>> sent to iesg@ietf.org instead. In either case, please retain the >>> beginning of the Subject line to allow automated sorting. >>> >>> Abstract >>> >>> >>> This document proposes an experiment to increase the permitted TCP >>> initial window (IW) from between 2 and 4 segments, as specified in >>> RFC 3390, to 10 segments, with a fallback to the existing >>> recommendation when performance issues are detected. It discusses the >>> motivation behind the increase, the advantages and disadvantages of >>> the higher initial window, and presents results from several large >>> scale experiments showing that the higher initial window improves the >>> overall performance of many web services without resulting in a >>> congestion collapse. The document closes with a discussion of usage >>> and deployment for further experimental purpose recommended by the >>> IETF TCP Maintenance and Minor Extensions (TCPM) working group. >>> >>> >>> >>> >>> The file can be obtained via >>> http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/ >>> >>> IESG discussion can be tracked via >>> http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/ballot/ >>> >>> >>> No IPR declarations have been submitted directly on this I-D. >>> >>> >>> >>> >> >> >> -- >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nishida@sfc.wide.ad.jp Mon Feb 11 10:04:05 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BF321F8849 for ; Mon, 11 Feb 2013 10:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.378 X-Spam-Level: X-Spam-Status: No, score=-101.378 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_52=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79wPFNidm8kj for ; Mon, 11 Feb 2013 10:04:04 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id 55BAD21F8820 for ; Mon, 11 Feb 2013 10:04:03 -0800 (PST) Received: from mail-la0-x235.google.com (la-in-x0235.1e100.net [IPv6:2a00:1450:4010:c03::235]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 813302780B1 for ; Tue, 12 Feb 2013 03:04:01 +0900 (JST) Received: by mail-la0-f53.google.com with SMTP id fr10so6115160lab.12 for ; Mon, 11 Feb 2013 10:03:58 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.45.140 with SMTP id n12mr13868504lam.36.1360605838493; Mon, 11 Feb 2013 10:03:58 -0800 (PST) Received: by 10.114.4.39 with HTTP; Mon, 11 Feb 2013 10:03:58 -0800 (PST) In-Reply-To: References: Date: Mon, 11 Feb 2013 10:03:58 -0800 Message-ID: From: Yoshifumi Nishida To: Ketan Kulkarni Content-Type: multipart/alternative; boundary=bcaec5524516aec9b304d576bb51 Cc: tcpm@ietf.org Subject: Re: [tcpm] Few TCP Fast Open considerations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 11 Feb 2013 18:04:05 -0000 --bcaec5524516aec9b304d576bb51 Content-Type: text/plain; charset=ISO-8859-1 Hi Ketan, Please allow me to clarify your idea here and let me know if I miss something. In my understanding, server has 3 choices when it receives TFO option from clients. 1: server supports TFO and has valid cookie. if it can allow the client to use TFO, attach valid cookie 2: server supports TFO and has valid cookie. if it cannot allow the client to use TFO, attach NULL cookie 3: in other conditions, don't attach any cookie. In case of 1, the client keeps using TFO. In case of 2, the client stops using TFO, but keeps the cached cookie and try with the cookie sometime later. In case of 3, the client invalidates cookie and request new one again. Case 2 will happen when the server is too busy to use TFO while it has valid cookies. This seems to be only case where NULL cookie is used.(if there're more cases, please let me know) I'm not denying this, but I'm wondering how this is effective. This is because I'm not very sure how often Case 2 will happen. Also, my another question is how long client should stop using TFO as this will also affect the efficiency. Thanks, -- Yoshifumi On Wed, Feb 6, 2013 at 8:59 PM, Ketan Kulkarni wrote: > Hi Yoshifumi, > > Well my idea is as follows - > > With current draft, tfo client follows this "state machine" > > 1. Request a cookie from server > 2. If cookie is received, cache it. > 3. Attempt syn+data to subsequent connections if cookie is cached. > > There is no way now for the client to detect the server is not supporting > tfo. > > If we modify the state-machine by adding a 4th state as follows - > 1. Request a cookie from server > 2. If cookie is received, cache it. > 3. Attempt syn+data to subsequent connections if cookie is cached. > 4. If server does not respond to syn+data (server not acking data in syn), > go back to state 1 for subsequent connections. > > By this logic, there is a way for tfo client to go back to state 1 and > re-attempt cookie request. > > I already mentioned various conditions earlier in my mails in what all > cases server does not respond to syn+data. > To detect difference between couple of scenarios, I also suggested to have > null cookie (or something else if there is any other way) > > Now having the modified "state-machine" prevents your concerns of false > positive. > Even if due to false positives client doesn't attempt syn+data, it does > attempt cookie request. So the penalty could at max well be limited to one > connection. It also gets rid of the temporal aspect of server exhausting > backlog. > > Another benefit it provides in cases of server stop supporting tfo. In > such cases, it is seen that client always attempts syn+data and server > never acks data and data in syn is retransmitted. > That is really odd and I don't think it should be acceptable. > If we can have a simpler way to avoid it then why not? > > Thanks, > Ketan > > > On Wed, Feb 6, 2013 at 1:52 PM, Yoshifumi Nishida wrote: > >> Hi Ketan, >> >> My concern is how long the temporal condition will last. Is it 5 >> minutes or 5 days? 5 days might be absurd, but I'm not very sure how >> we can guarantee this. >> Another concern is false positive. If client see SYN without cookie >> just once, it might stop using TFO for the destination. >> >> If we have some smart logic at client side, we can address these >> issue. But, then, NULL cookie might not be very necessary. >> >> Thanks, >> -- >> Yoshifumi >> >> On Sun, Feb 3, 2013 at 8:09 PM, Ketan Kulkarni >> wrote: >> > Hi Yoshifumi, >> > With the current draft, there is no way fast open client can >> > differentiate between these two cases. >> > However, (albeit with little modification) server can "help" client >> > differentiate. >> > Here's how - >> > In first cases, server is restarted without fast open. So there is no >> > way server can "communicate" anything about fast open to the client. >> > In second case however, server supports fast open but is not able ack >> > syn+data. In such case, it can very well send a NULL cookie to the >> > client. Client on receipt of a NULL cookie can differentiate between >> > first and second case. >> > >> > If client detects first scenario, IMHO, client should stop sending >> > SYN+Data in subsequent connections to the server, as it has the >> > sufficient information to believe server is not supporting tcp fast >> > open. >> > While in second case, client can still attempt fast open (syn+data) in >> > subsequent connections as the condition is temporal and it can expect >> > the syn+data could be acked by the server. >> > >> > Sounds reasonable? >> > >> > Thanks, >> > Ketan >> > >> > On Thu, Jan 31, 2013 at 11:36 AM, Yoshifumi Nishida >> > wrote: >> >> Hi Ketan, >> >> >> >> On Mon, Jan 28, 2013 at 8:42 AM, Ketan Kulkarni >> wrote: >> >> >> >>> If above suggestion is ok, there could probably also be a need of >> >>> sending NULL cookie (again suggested by Yuchung on netdev) from >> >>> fast-open server. >> >>> Specifically, at fast-open client, to detect the difference between >> >>> the two different scenarios - >> >>> 1. server restarted without Fast Open and is no longer supporting it >> >>> (or any of the condition given above) >> >>> 2. fast-open server exhausted its fast-open backlog and is temporarily >> >>> not acking the data in SYN. >> >>> >> >>> In the 2nd case, server might choose to send the NULL cookie on the >> >>> receipt of which client understands the server still supports >> >>> fast-open but unable to do so temporarily. >> >>> It might also indicate cookie expiration - but I am not sure. >> >>> >> >>> I will like a wider view and more thoughts on such scenarios occurring >> >>> in the network. >> >> >> >> It seems to me that 1 and 2 are mostly the same unless you can know >> >> how long "temporarily" is. >> >> But, I'm guessing it'll be difficult to know.. >> >> >> >> -- >> >> Yoshifumi Nishida >> > > --bcaec5524516aec9b304d576bb51 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ketan,

Please allow me to clarify your idea here and = let me know if I miss something.=A0
In my understanding, server h= as 3 choices when it receives TFO option from clients.

1: server supports TFO and has valid cookie. if it can allow the = client to use TFO, attach valid cookie
2: server supports T= FO and has valid cookie. if it cannot allow the client to use TFO, attach N= ULL cookie
3: in other conditions, don't attach any cookie.

In case of 1, the client keeps using TFO.
In = case of 2, the client stops using TFO, but keeps the cached cookie and try = with the cookie sometime later.
In case of 3, the client invalida= tes cookie and request new one again.

Case 2 will happen when the server is too busy to use TFO while it= has valid cookies.
This seems to be only case where NULL cookie is use= d.(if there're more cases, please let me know)

I'm not denyi= ng this, but I'm wondering how this is effective.
This is because I'm not very sure how often Case 2 will happen.
Als= o, my another question is how long client should stop using TFO as this wil= l also affect the efficiency.

Thanks,
--
Yoshifumi



On Wed, F= eb 6, 2013 at 8:59 PM, Ketan Kulkarni <ketkulka@gmail.com> = wrote:
Hi Yoshifumi,

Well my idea is as foll= ows -

With current draft, tfo client follows this "state machin= e"

1. Request a cookie from server
2. If cookie is received, cache it.<= br>3. Attempt syn+data to subsequent connections if cookie is cached.

There is no way now for the client to detect the server is not supporti= ng tfo.

If we modify the state-machine by adding a 4th state as foll= ows -
1. Request a cookie from server
2. If cookie is received, cache it.
3. Attempt syn+data to subsequent connections if cookie is cached.
4. If= server does not respond to syn+data (server not acking data in syn), go ba= ck to state 1 for subsequent connections.

By this logic, there is a = way for tfo client to go back to state 1 and re-attempt cookie request.

I already mentioned various conditions earlier in my mails in what all = cases server does not respond to syn+data.
To detect difference between = couple of scenarios, I also suggested to have null cookie (or something els= e if there is any other way)

Now having the modified "state-machine" prevents your concern= s of false positive.
Even if due to false positives client doesn't a= ttempt syn+data, it does attempt cookie request. So the penalty could at ma= x well be limited to one connection. It also gets rid of the temporal aspec= t of server exhausting backlog.

Another benefit it provides in cases of server stop supporting tfo. In = such cases, it is seen that client always attempts syn+data and server neve= r acks data and data in syn is retransmitted.
That is really odd and I d= on't think it should be acceptable.
If we can have a simpler way to avoid it then why not?

Thanks,
Ke= tan


On Wed, Feb 6, 2013 at 1:52= PM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:<= br>
Hi Ketan,

My concern is how long the temporal condition will last. Is it 5
minutes or 5 days? 5 days might be absurd, but I'm not very sure how we can guarantee this.
Another concern is false positive. If client see SYN without cookie
just once, it might stop using TFO for the destination.

If we have some smart logic at client side, we can address these
issue. But, then, NULL cookie might not be very necessary.

Thanks,
--
Yoshifumi

On Sun, Feb 3, 2013 at 8:09 PM, Ketan Kulkarni <ketkulka@gmail.com> wrote:
> Hi Yoshifumi,
> With the current draft, there is no way fast open client can
> differentiate between these two cases.
> However, (albeit with little modification) server can "help"= client
> differentiate.
> Here's how -
> In first cases, server is restarted without fast open. So there is no<= br> > way server can "communicate" anything about fast open to the= client.
> In second case however, server supports fast open but is not able ack<= br> > syn+data. In such case, it can very well send a NULL cookie to the
> client. Client on receipt of a NULL cookie can differentiate between > first and second case.
>
> If client detects first scenario, IMHO, client should stop sending
> SYN+Data in subsequent connections to the server, as it has the
> sufficient information to believe server is not supporting tcp fast > open.
> While in second case, client can still attempt fast open (syn+data) in=
> subsequent connections as the condition is temporal and it can expect<= br> > the syn+data could be acked by the server.
>
> Sounds reasonable?
>
> Thanks,
> Ketan
>
> On Thu, Jan 31, 2013 at 11:36 AM, Yoshifumi Nishida
> <nishid= a@sfc.wide.ad.jp> wrote:
>> Hi Ketan,
>>
>> On Mon, Jan 28, 2013 at 8:42 AM, Ketan Kulkarni <ketkulka@gmail.com> wrote:=
>>
>>> If above suggestion is ok, there could probably also be a need= of
>>> sending NULL cookie (again suggested by Yuchung on netdev) fro= m
>>> fast-open server.
>>> Specifically, at fast-open client, to detect the difference be= tween
>>> the two different scenarios -
>>> 1. server restarted without Fast Open and is no longer support= ing it
>>> (or any of the condition given above)
>>> 2. fast-open server exhausted its fast-open backlog and is tem= porarily
>>> not acking the data in SYN.
>>>
>>> In the 2nd case, server might choose to send the NULL cookie o= n the
>>> receipt of which client understands the server still supports<= br> >>> fast-open but unable to do so temporarily.
>>> It might also indicate cookie expiration - but I am not sure.<= br> >>>
>>> I will like a wider view and more thoughts on such scenarios o= ccurring
>>> in the network.
>>
>> It seems to me that 1 and 2 are mostly the same unless you can kno= w
>> how long "temporarily" is.
>> But, I'm guessing it'll be difficult to know..
>>
>> --
>> Yoshifumi Nishida


--bcaec5524516aec9b304d576bb51-- From iesg-secretary@ietf.org Tue Feb 12 06:37:32 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1168E21F8E75; Tue, 12 Feb 2013 06:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3r5+yxOT7p+B; Tue, 12 Feb 2013 06:37:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E0221F8DB2; Tue, 12 Feb 2013 06:37:31 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130212143731.1741.97441.idtracker@ietfa.amsl.com> Date: Tue, 12 Feb 2013 06:37:31 -0800 Cc: tcpm@ietf.org Subject: [tcpm] Last Call: (Proportional Rate Reduction for TCP) to Experimental RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.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, 12 Feb 2013 14:37:32 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Proportional Rate Reduction for TCP' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-02-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes an experimental algorithm, Proportional Rate Reduction (PPR) to improve the accuracy of the amount of data sent by TCP during loss recovery. Standard Congestion Control requires that TCP and other protocols reduce their congestion window in response to losses. This window reduction naturally occurs in the same round trip as the data retransmissions to repair the losses, and is implemented by choosing not to transmit any data in response to some ACKs arriving from the receiver. Two widely deployed algorithms are used to implement this window reduction: Fast Recovery and Rate Halving. Both algorithms are needlessly fragile under a number of conditions, particularly when there is a burst of losses such that the number of ACKs returning to the sender is small. Proportional Rate Reduction minimizes these excess window adjustments such that at the end of recovery the actual window size will be as close as possible to ssthresh, the window size determined by the congestion control algorithm. It is patterned after Rate Halving, but using the fraction that is appropriate for target window chosen by the congestion control algorithm. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tcpm-proportional-rate-reduction/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tcpm-proportional-rate-reduction/ballot/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Wed Feb 13 08:08:56 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C8A21F8938; Wed, 13 Feb 2013 08:08:56 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxKgS3Dq5bGv; Wed, 13 Feb 2013 08:08:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAB421F8921; Wed, 13 Feb 2013 08:08:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130213160855.6352.37135.idtracker@ietfa.amsl.com> Date: Wed, 13 Feb 2013 08:08:55 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2013 16:08:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : TCP Extensions for High Performance Author(s) : David Borman Bob Braden Van Jacobson Richard Scheffenegger Filename : draft-ietf-tcpm-1323bis-05.txt Pages : 43 Date : 2013-02-13 Abstract: This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth*delay product and to provide reliable operation over very high-speed paths. It defines TCP options for scaled windows and timestamps. The timestamps are used for two distinct mechanisms, RTTM (Round Trip Time Measurement) and PAWS (Protection Against Wrapped Sequences). This document updates and obsoletes RFC 1323. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rs@netapp.com Wed Feb 13 08:25:59 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B2021F88B5 for ; Wed, 13 Feb 2013 08:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYTnCuTtLAD8 for ; Wed, 13 Feb 2013 08:25:58 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id C1C3421F8771 for ; Wed, 13 Feb 2013 08:25:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,658,1355126400"; d="scan'208";a="9928132" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 13 Feb 2013 08:25:55 -0800 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r1DGPptu016053; Wed, 13 Feb 2013 08:25:51 -0800 (PST) Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.8.229]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0328.009; Wed, 13 Feb 2013 08:25:51 -0800 From: "Scheffenegger, Richard" To: "tcpm (tcpm@ietf.org)" Thread-Topic: New Version Notification for draft-ietf-tcpm-1323bis-05.txt Thread-Index: AQHOCgRuOFN715fmA0Si5G36KS1/CZh39XFQ Date: Wed, 13 Feb 2013 16:25:50 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F249F8C28@SACEXCMBX06-PRD.hq.netapp.com> References: <20130213160856.6352.31413.idtracker@ietfa.amsl.com> In-Reply-To: <20130213160856.6352.31413.idtracker@ietfa.amsl.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Alexander Zimmermann \(zimmermann@nets.rwth-aachen.de\)" , "david.borman@quantum.com" , "braden@isi.edu" , "Matthew Mathis \(mattmathis@google.com\)" , "van@packetdesign.com" Subject: Re: [tcpm] New Version Notification for draft-ietf-tcpm-1323bis-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 13 Feb 2013 16:25:59 -0000 SGksDQoNCkkgaGF2ZSB1cGRhdGVkIHRoZSBkcmFmdCB3aXRoIHRoZSBjb21tZW50cyBmcm9tIHRo ZSBsYXN0IElFVEYgKG1haW5seSB0cmltbWVkIG11Y2ggb2YgdGhlIGhpc3RvcmljIGRpc2N1c3Np b25zIGFuZCByYXRpb25hbGUgaW4gdGhlIGludHJvZHVjdGlvbiBzZWN0aW9uLCBsZWF2aW5nIGFs b25lIHRoZSBkZXRhaWxlZCBkaXNjdXNzaW9ucyBhbmQgaW1wbGVtZW50ZXJzIGd1aWRlbGluZXMg aW4gdGhlIGxhdGVyIHNlY3Rpb25zIGRlc2NyaWJpbmcgdGhlIG9wdGlvbnMgYW5kIG1lY2hhbmlz bXMsIGFmdGVyIHRoZSBjb21tZW50cyBmcm9tIE1hdHQpLg0KDQpTbywgaXQgcmVhbGx5IGlzbid0 IHRoYXQgbXVjaCBzaG9ydGVyIG92ZXJhbGwsIGJ1dCB0aGVyZSBpcyBsZXNzIHRleHQgdG8gcmVh ZCBiZWZvcmUgdGhlIHJlYWwgdGVjaG5pY2FsIGNvbnRlbnQgc3RhcnRzLg0KDQpBcyB0aGlzIGlz IGEgV0cgaXRlbSwgdGhlcmUnbGwgcHJvYmFibHkgYmUgYSBzaG9ydCBzbG90IGluIHRoZSBuZXh0 IFRDUE0gdG8gZ2V0IGxpdmUgZmVlZGJhY2sgdG9vIQ0KDQpCZXN0IHJlZ2FyZHMsDQoNClJpY2hh cmQgU2NoZWZmZW5lZ2dlcg0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmddDQo+IFNlbnQ6IE1pdHR3b2NoLCAxMy4gRmVicnVhciAyMDEzIDE3OjA5DQo+IFRvOiBT Y2hlZmZlbmVnZ2VyLCBSaWNoYXJkDQo+IENjOiBicmFkZW5AaXNpLmVkdTsgZGF2aWQuYm9ybWFu QHF1YW50dW0uY29tOyB2YW5AcGFja2V0ZGVzaWduLmNvbQ0KPiBTdWJqZWN0OiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtdGNwbS0xMzIzYmlzLTA1LnR4dA0KPiANCj4g DQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLXRjcG0tMTMyM2Jpcy0wNS50eHQg aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5DQo+IHN1Ym1pdHRlZCBieSBSaWNoYXJkIFNjaGVmZmVuZWdn ZXIgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KPiANCj4gRmlsZW5hbWU6CSBk cmFmdC1pZXRmLXRjcG0tMTMyM2Jpcw0KPiBSZXZpc2lvbjoJIDA1DQo+IFRpdGxlOgkJIFRDUCBF eHRlbnNpb25zIGZvciBIaWdoIFBlcmZvcm1hbmNlDQo+IENyZWF0aW9uIGRhdGU6CSAyMDEzLTAy LTEzDQo+IEdyb3VwOgkJIHRjcG0NCj4gTnVtYmVyIG9mIHBhZ2VzOiA0Mw0KPiBVUkw6ICAgICAg ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtdGNw bS0NCj4gMTMyM2Jpcy0wNS50eHQNCj4gU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGNwbS0xMzIzYmlzDQo+IEh0bWxpemVkOiAgICAg ICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLTEzMjNiaXMtMDUN Cj4gRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLXRjcG0tMTMyM2Jpcy0NCj4gMDUNCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRv Y3VtZW50IHNwZWNpZmllcyBhIHNldCBvZiBUQ1AgZXh0ZW5zaW9ucyB0byBpbXByb3ZlDQo+ICAg IHBlcmZvcm1hbmNlIG92ZXIgcGF0aHMgd2l0aCBhIGxhcmdlIGJhbmR3aWR0aCpkZWxheSBwcm9k dWN0IGFuZCB0bw0KPiAgICBwcm92aWRlIHJlbGlhYmxlIG9wZXJhdGlvbiBvdmVyIHZlcnkgaGln aC1zcGVlZCBwYXRocy4gIEl0IGRlZmluZXMNCj4gICAgVENQIG9wdGlvbnMgZm9yIHNjYWxlZCB3 aW5kb3dzIGFuZCB0aW1lc3RhbXBzLiAgVGhlIHRpbWVzdGFtcHMgYXJlDQo+ICAgIHVzZWQgZm9y IHR3byBkaXN0aW5jdCBtZWNoYW5pc21zLCBSVFRNIChSb3VuZCBUcmlwIFRpbWUgTWVhc3VyZW1l bnQpDQo+ICAgIGFuZCBQQVdTIChQcm90ZWN0aW9uIEFnYWluc3QgV3JhcHBlZCBTZXF1ZW5jZXMp Lg0KPiANCj4gICAgVGhpcyBkb2N1bWVudCB1cGRhdGVzIGFuZCBvYnNvbGV0ZXMgUkZDIDEzMjMu DQo+IA0KPiANCj4gDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From internet-drafts@ietf.org Thu Feb 14 10:12:11 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C726E21F8C17; Thu, 14 Feb 2013 10:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BxvF95Ja5y9; Thu, 14 Feb 2013 10:12:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A74821F8678; Thu, 14 Feb 2013 10:12:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130214181206.22434.33733.idtracker@ietfa.amsl.com> Date: Thu, 14 Feb 2013 10:12:06 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 14 Feb 2013 18:12:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : Updating TCP to support Rate-Limited Traffic Author(s) : Godred Fairhurst Arjuna Sathiaseelan Filename : draft-ietf-tcpm-newcwv-00.txt Pages : 16 Date : 2013-02-14 Abstract: This document proposes an update to RFC 5681 to address issues that arise when TCP is used to support traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It updates TCP to allow a TCP sender to restart quickly following either an idle or rate-limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP, while also providing an appropriate response if congestion is experienced. It also evaluates TCP Congestion Window Validation, CWV, an IETF experimental specification defined in RFC 2861, and concludes that CWV sought to address important issues, but failed to deliver a widely used solution. This document therefore proposes an update to the status of RFC 2861 by recommending it is moved from Experimental to Historic status, and that it is replaced by the current specification. NOTE: The standards status of this WG document is under review for consideration as either Experimental (EXP) or Proposed Standard (PS). This decision will be made later as the document is finalised. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-newcwv-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From touch@isi.edu Fri Feb 15 11:57:20 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D072221F863C for ; Fri, 15 Feb 2013 11:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.799 X-Spam-Level: X-Spam-Status: No, score=-104.799 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfcfdC26E-pc for ; Fri, 15 Feb 2013 11:57:20 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 42F6B21F8873 for ; Fri, 15 Feb 2013 11:57:20 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r1FJuQeW012002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Feb 2013 11:56:26 -0800 (PST) Message-ID: <511E92E9.6080709@isi.edu> Date: Fri, 15 Feb 2013 11:56:25 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "tcpm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 Feb 2013 19:57:20 -0000 Hi, all, The IESG has reviewed draft-touch-tcpm-experimental-options and is holding the document up on two key concerns: I. the lack of a registry for magic numbers II. potential for prefix collision within the set of magic numbers supported in a single implementation Addressing their concerns would involve a substantive change to the draft, so I would appreciate some feedback on the following possible solution before updating the document. Please post your comments on this proposed change. Here's what we need to know: 1. do you agree with change (A)? 2. do you agree with change (B)? 3. do you agree with change (C)? if so, which variant (i), (ii), (iii)? My preference is: A yes B yes C yes first choice (i) second choice (iii) (I think (ii) is inelegant) Thanks, Joe ----------------------------------------------------------------------- PROPOSED CHANGES: A) change the name from MAGIC NUMBER to "experiment ID" Rationale: because the new value will be delegated by IANA, it no longer qualifies as a self-assigned "magic number" B) request that IANA register experiment IDs The procedure would be: FCFC assignment from among unassigned values zero hurdle for assignment (no ID required) OK to indicate multiple assignees list in the order of request Rationale: Needed to satisfy IANA concern (I) above. C) Specify a more limited number of sizes to avoid overlap Here's a list of the current known uses of the magic number as already proposed in this doc: draft-ietf-tcpm-fastopen-02 0xF989 draft-fox-tcpm-shared-memory-rdma-01 0xE2D4C3D9 draft-sarolahti-irtf-catcp-00 0x20120229 draft-trammell-tcpm-timestamp-interval-00 0x75ec i) Given this, my first inclination - given we'd be using an IANA registry - would be to just stick to 16-bits, and assign the values for current uses to be consistent. ii) a second variant would be 16- and 32-bit values a) assign as follows to be compatible with current use: 16-bit 0x0000 - 0x7FFF 0xF000 - 0xFFFF 32-bit 0x8000 0000 - 0xEFFF 0000 This allows all current known uses unchanged. b) assign according a simpler split, and assign a large range to one of the members above: 16-bit 0x0000 - 0x7FFF 32-bit 0x8000 0000 - 0xFFFF FFFF All current uses would be unchanged except: fastopen 0xF989 0000 - 0xF989 FFFF catcp 0x2012 (note - this would be updated in their spec, but need not affect their implementations) ----------------------------------------------------------------------- From touch@isi.edu Fri Feb 15 13:23:12 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7D421F859D for ; Fri, 15 Feb 2013 13:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.847 X-Spam-Level: X-Spam-Status: No, score=-102.847 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-uXQAVCpX8A for ; Fri, 15 Feb 2013 13:23:09 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id F114C21F8626 for ; Fri, 15 Feb 2013 13:23:06 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r1FLMUiE019347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Feb 2013 13:22:30 -0800 (PST) Message-ID: <511EA715.7070505@isi.edu> Date: Fri, 15 Feb 2013 13:22:29 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <511E92E9.6080709@isi.edu> In-Reply-To: <511E92E9.6080709@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 15 Feb 2013 21:23:12 -0000 PS - one additional point: regardless of the length that might be registered with IANA, using a longer experiment ID might still be useful, since it helps guard against both squatters and those who don't support this mechanism I'll be sure to include that in the update if we converge on this approach. Joe On 2/15/2013 11:56 AM, Joe Touch wrote: > Hi, all, > > The IESG has reviewed draft-touch-tcpm-experimental-options and is > holding the document up on two key concerns: > > I. the lack of a registry for magic numbers > > II. potential for prefix collision within the set of magic numbers > supported in a single implementation > > Addressing their concerns would involve a substantive change to the > draft, so I would appreciate some feedback on the following possible > solution before updating the document. > > Please post your comments on this proposed change. > > Here's what we need to know: > > 1. do you agree with change (A)? > > 2. do you agree with change (B)? > > 3. do you agree with change (C)? > > if so, which variant (i), (ii), (iii)? > > My preference is: > A yes > B yes > C yes > first choice (i) > second choice (iii) > (I think (ii) is inelegant) > > Thanks, > > Joe > > ----------------------------------------------------------------------- > > PROPOSED CHANGES: > > A) change the name from MAGIC NUMBER to "experiment ID" > > Rationale: because the new value will be delegated by IANA, > it no longer qualifies as a self-assigned "magic number" > > B) request that IANA register experiment IDs > The procedure would be: > FCFC assignment from among unassigned values > zero hurdle for assignment (no ID required) > OK to indicate multiple assignees > list in the order of request > > Rationale: Needed to satisfy IANA concern (I) above. > > C) Specify a more limited number of sizes to avoid overlap > > Here's a list of the current known uses of the magic > number as already proposed in this doc: > > draft-ietf-tcpm-fastopen-02 > 0xF989 > > draft-fox-tcpm-shared-memory-rdma-01 > 0xE2D4C3D9 > > draft-sarolahti-irtf-catcp-00 > 0x20120229 > > draft-trammell-tcpm-timestamp-interval-00 > 0x75ec > > i) Given this, my first inclination - given we'd be using > an IANA registry - would be to just stick to 16-bits, > and assign the values for current uses to be consistent. > > ii) a second variant would be 16- and 32-bit values > > a) assign as follows to be compatible with current use: > 16-bit 0x0000 - 0x7FFF > 0xF000 - 0xFFFF > > 32-bit 0x8000 0000 - 0xEFFF 0000 > > This allows all current known uses unchanged. > > b) assign according a simpler split, and assign a large > range to one of the members above: > > 16-bit 0x0000 - 0x7FFF > > 32-bit 0x8000 0000 - 0xFFFF FFFF > > All current uses would be unchanged except: > > fastopen 0xF989 0000 - 0xF989 FFFF > > catcp 0x2012 > > (note - this would be updated in their spec, > but need not affect their implementations) > > ----------------------------------------------------------------------- > > > > > > > From wes@mti-systems.com Fri Feb 15 16:42:35 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8263021F85A0 for ; Fri, 15 Feb 2013 16:42:35 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKrr-EEalS+7 for ; Fri, 15 Feb 2013 16:42:35 -0800 (PST) Received: from atl4mhob05.myregisteredsite.com (atl4mhob05.myregisteredsite.com [209.17.115.43]) by ietfa.amsl.com (Postfix) with ESMTP id E945E21F859D for ; Fri, 15 Feb 2013 16:42:34 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r1G0gXOP013140 for ; Fri, 15 Feb 2013 19:42:33 -0500 Received: (qmail 31887 invoked by uid 0); 16 Feb 2013 00:42:33 -0000 Received: from unknown (HELO ?192.168.1.145?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 16 Feb 2013 00:42:33 -0000 Message-ID: <511ED5F2.4030100@mti-systems.com> Date: Fri, 15 Feb 2013 19:42:26 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <511ED5B3.1040803@mti-systems.com> In-Reply-To: <511ED5B3.1040803@mti-systems.com> X-Forwarded-Message-Id: <511ED5B3.1040803@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2013 00:42:35 -0000 On 2/15/2013 2:56 PM, Joe Touch wrote: > > Here's what we need to know: > > 1. do you agree with change (A)? > > 2. do you agree with change (B)? > > 3. do you agree with change (C)? > A) YES B) YES (but should be clear that requesters can "suggest" a value) C) YES (prefer option i) -- Wes Eddy MTI Systems From ycheng@google.com Fri Feb 15 17:04:20 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E6F21F84C7 for ; Fri, 15 Feb 2013 17:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAQGXYNA8BDQ for ; Fri, 15 Feb 2013 17:04:20 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA4721F8484 for ; Fri, 15 Feb 2013 17:04:19 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id fr10so4030329lab.12 for ; Fri, 15 Feb 2013 17:04:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=cLDh5GiRE+l1D7PvQw3cfHsJYydFyRH02yLWLgAGtvs=; b=cMNT51OrC6ooi96pC0J8PA9zzEFEgcKwAYDmVINTIIj5A2dUFIWXVLWoezlZhgQv7u iWwOlZSRe0sTZilq5f0ixhjpkbcYiWg8SXsEUrpm+sVtuy87O1oHRbQCrlJV2OX44Qy5 0tzDmeoRBfj0vS7JgrfrPUZKOUj8AbdDzF8bDS3EOn3p/+jMqPq6cS/ro3x2FNsbpTSe 52YfIUd4ob2PjhRRBp8RDIXld/0J7fPxOuZHbWILVm3T8cWBO7OKzyy7aaJeH98ciowq OzcfUf586hpgkWu7GCMNmIw72q/J9zU4P+hN14PqaGz7mbUYxoI4P7rvGus8kpOdb89D tExg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=cLDh5GiRE+l1D7PvQw3cfHsJYydFyRH02yLWLgAGtvs=; b=p3YQjpD0BtYaWttbskp6h/5OtEa17ZcSayq6dI9RXra5Hz+n4l6Cf9O6ILO+fraxGv ti0uvNHwEuoghD0c3cDFGwa9Zyf0ZBb7l0zvvcgfvjqHCYRbgSUOJP0oeU/ZvU4R6JoK YdPUMCOiQfw2WZI1NdndY9A52Jkxsd7GfP6hSc6zpy+PDj6UeoIF+9QD1iO19TjF/OV5 XRB+E9t3Ofn+86kRKmNDLg7A0WpFTm1e+nVJJuUA2l3lSlrjYiocn0b4fA5H4EsgXh/2 +UMq/0ak4o5njspv94F2Dvp8SKY7yKe3d6oMCHGZcXS2nhVK893KZk2AEeWBODyl2Do2 1ntw== X-Received: by 10.112.36.71 with SMTP id o7mr540195lbj.47.1360976658820; Fri, 15 Feb 2013 17:04:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.128.225 with HTTP; Fri, 15 Feb 2013 17:03:57 -0800 (PST) In-Reply-To: <511ED5F2.4030100@mti-systems.com> References: <511ED5B3.1040803@mti-systems.com> <511ED5F2.4030100@mti-systems.com> From: Yuchung Cheng Date: Fri, 15 Feb 2013 17:03:57 -0800 Message-ID: To: Wesley Eddy Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmPj8PrzMX7e9brzSIJVvy+4poCOWTk2ZvufHlrpLOGbec1aqj0S8ToLy84ftQWZ2SvO4p/f1tkUvFDhN6URIRC/jYm9eUFSDaFaG1YOorw6kYnxSItTIumLtDtiyQ1Yn72pb7bTMjZpxO/a4RBxsXj2rPf7lSn5hlqFeGklHd8Od8AyzkkyMypurrlpGCcP1+AS1BW Cc: "tcpm@ietf.org" Subject: Re: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2013 01:04:21 -0000 On Fri, Feb 15, 2013 at 4:42 PM, Wesley Eddy wrote: > On 2/15/2013 2:56 PM, Joe Touch wrote: >> >> Here's what we need to know: >> >> 1. do you agree with change (A)? >> >> 2. do you agree with change (B)? >> >> 3. do you agree with change (C)? >> > > > > A) YES > > B) YES (but should be clear that requesters can "suggest" a value) > > C) YES (prefer option i) same votes as Wes and Joe. > > > -- > Wes Eddy > MTI Systems > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From i.goyret@alcatel-lucent.com Fri Feb 15 17:50:34 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B6821F8461 for ; Fri, 15 Feb 2013 17:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sqv9AA6mUkXq for ; Fri, 15 Feb 2013 17:50:33 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7C53221F841D for ; Fri, 15 Feb 2013 17:50:32 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r1G1oRol008183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 Feb 2013 19:50:27 -0600 (CST) Received: from cliff.eng.ascend.com (cliff.eng.ascend.com [192.207.23.55]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r1G1oFFx021547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 Feb 2013 20:50:17 -0500 Received: from igoyret-c1.alcatel-lucent.com (igoyret.lra.lucent.com [135.244.41.245]) by cliff.eng.ascend.com (8.13.1/8.13.1) with ESMTP id r1G1oCHZ015796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Feb 2013 17:50:14 -0800 Message-Id: <201302160150.r1G1oCHZ015796@cliff.eng.ascend.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 15 Feb 2013 17:01:57 -0800 To: Joe Touch From: Ignacio Goyret In-Reply-To: <511E92E9.6080709@isi.edu> References: <511E92E9.6080709@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2013 01:50:34 -0000 (A) yes (B) yes (C) yes, option ii), a) which requires no changes for anyone. At 11:56 2/15/2013, Joe Touch wrote: >Hi, all, > >The IESG has reviewed draft-touch-tcpm-experimental-options and is holding the document up on two key concerns: > > I. the lack of a registry for magic numbers > > II. potential for prefix collision within the set of magic numbers > supported in a single implementation From gorry@erg.abdn.ac.uk Sat Feb 16 02:26:02 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B6721F8523 for ; Sat, 16 Feb 2013 02:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UUcPt0qk9ve for ; Sat, 16 Feb 2013 02:26:00 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id ADC1321F8415 for ; Sat, 16 Feb 2013 02:26:00 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 9EB592B4044; Sat, 16 Feb 2013 10:25:59 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Sat, 16 Feb 2013 10:25:59 -0000 Message-ID: In-Reply-To: References: <511ED5B3.1040803@mti-systems.com> <511ED5F2.4030100@mti-systems.com> Date: Sat, 16 Feb 2013 10:25:59 -0000 From: gorry@erg.abdn.ac.uk To: "Yuchung Cheng" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "tcpm@ietf.org" Subject: Re: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2013 10:26:02 -0000 I've thought about this and also think the proposed approach is simple and sufficient. +1 - If a specific value is requested value and this has already been assigned, I think it could be wise for IANA to confirm that the value will be shared with the other entries. Gorry > On Fri, Feb 15, 2013 at 4:42 PM, Wesley Eddy wrote: >> On 2/15/2013 2:56 PM, Joe Touch wrote: >>> >>> Here's what we need to know: >>> >>> 1. do you agree with change (A)? >>> >>> 2. do you agree with change (B)? >>> >>> 3. do you agree with change (C)? >>> >> >> >> >> A) YES >> >> B) YES (but should be clear that requesters can "suggest" a value) >> >> C) YES (prefer option i) > > same votes as Wes and Joe. > >> >> >> -- >> Wes Eddy >> MTI Systems >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From gorry@erg.abdn.ac.uk Sat Feb 16 02:27:33 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0695721F84EB for ; Sat, 16 Feb 2013 02:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKUQhYMtXfPk for ; Sat, 16 Feb 2013 02:27:32 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2D67D21F84E2 for ; Sat, 16 Feb 2013 02:27:32 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 6F7612B4044; Sat, 16 Feb 2013 10:27:31 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Sat, 16 Feb 2013 10:27:31 -0000 Message-ID: In-Reply-To: <511EA715.7070505@isi.edu> References: <511E92E9.6080709@isi.edu> <511EA715.7070505@isi.edu> Date: Sat, 16 Feb 2013 10:27:31 -0000 From: gorry@erg.abdn.ac.uk To: "Joe Touch" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "tcpm@ietf.org" Subject: Re: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2013 10:27:33 -0000 This sounds good. You could consider citing one of the existing longer value as a concrete example. Gorry > PS - one additional point: > > regardless of the length that might be registered with IANA, > using a longer experiment ID might still be useful, since > it helps guard against both squatters and those who don't > support this mechanism > > I'll be sure to include that in the update if we converge on this > approach. > > Joe > > On 2/15/2013 11:56 AM, Joe Touch wrote: >> Hi, all, >> >> The IESG has reviewed draft-touch-tcpm-experimental-options and is >> holding the document up on two key concerns: >> >> I. the lack of a registry for magic numbers >> >> II. potential for prefix collision within the set of magic numbers >> supported in a single implementation >> >> Addressing their concerns would involve a substantive change to the >> draft, so I would appreciate some feedback on the following possible >> solution before updating the document. >> >> Please post your comments on this proposed change. >> >> Here's what we need to know: >> >> 1. do you agree with change (A)? >> >> 2. do you agree with change (B)? >> >> 3. do you agree with change (C)? >> >> if so, which variant (i), (ii), (iii)? >> >> My preference is: >> A yes >> B yes >> C yes >> first choice (i) >> second choice (iii) >> (I think (ii) is inelegant) >> >> Thanks, >> >> Joe >> >> ----------------------------------------------------------------------- >> >> PROPOSED CHANGES: >> >> A) change the name from MAGIC NUMBER to "experiment ID" >> >> Rationale: because the new value will be delegated by IANA, >> it no longer qualifies as a self-assigned "magic number" >> >> B) request that IANA register experiment IDs >> The procedure would be: >> FCFC assignment from among unassigned values >> zero hurdle for assignment (no ID required) >> OK to indicate multiple assignees >> list in the order of request >> >> Rationale: Needed to satisfy IANA concern (I) above. >> >> C) Specify a more limited number of sizes to avoid overlap >> >> Here's a list of the current known uses of the magic >> number as already proposed in this doc: >> >> draft-ietf-tcpm-fastopen-02 >> 0xF989 >> >> draft-fox-tcpm-shared-memory-rdma-01 >> 0xE2D4C3D9 >> >> draft-sarolahti-irtf-catcp-00 >> 0x20120229 >> >> draft-trammell-tcpm-timestamp-interval-00 >> 0x75ec >> >> i) Given this, my first inclination - given we'd be using >> an IANA registry - would be to just stick to 16-bits, >> and assign the values for current uses to be consistent. >> >> ii) a second variant would be 16- and 32-bit values >> >> a) assign as follows to be compatible with current use: >> 16-bit 0x0000 - 0x7FFF >> 0xF000 - 0xFFFF >> >> 32-bit 0x8000 0000 - 0xEFFF 0000 >> >> This allows all current known uses unchanged. >> >> b) assign according a simpler split, and assign a large >> range to one of the members above: >> >> 16-bit 0x0000 - 0x7FFF >> >> 32-bit 0x8000 0000 - 0xFFFF FFFF >> >> All current uses would be unchanged except: >> >> fastopen 0xF989 0000 - 0xF989 FFFF >> >> catcp 0x2012 >> >> (note - this would be updated in their spec, >> but need not affect their implementations) >> >> ----------------------------------------------------------------------- >> >> >> >> >> >> >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From trammell@tik.ee.ethz.ch Sat Feb 16 04:09:16 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D0521F86AC for ; Sat, 16 Feb 2013 04:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.083 X-Spam-Level: X-Spam-Status: No, score=-6.083 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jya6buicRCFO for ; Sat, 16 Feb 2013 04:09:15 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 0D34721F86A5 for ; Sat, 16 Feb 2013 04:09:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8027CD9314; Sat, 16 Feb 2013 13:09:09 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yTTxbUsYGUIc; Sat, 16 Feb 2013 13:09:09 +0100 (MET) Received: from [10.0.27.106] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 45277D9309; Sat, 16 Feb 2013 13:09:09 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <511E92E9.6080709@isi.edu> Date: Sat, 16 Feb 2013 13:10:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2D5114CD-D316-4A0A-AFE4-5A9129C6DD2B@tik.ee.ethz.ch> References: <511E92E9.6080709@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1499) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2013 12:09:16 -0000 hi Joe, all, On 15 Feb 2013, at 20:56, Joe Touch wrote: > Here's what we need to know: >=20 > 1. do you agree with change (A)? yes > 2. do you agree with change (B)? yes > 3. do you agree with change (C)? >=20 > if so, which variant (i), (ii), (iii)? yes. The value in our draft, in any case, is arbitrary and can be = changed at this point with minimal experimental impact, so preserving = existing values (at least from my viewpoint) isn't worth the relative = inelegance of (ii). On straight 16- vs 16-32 bit identifiers, I have noticed that scarcity = in 16-bit number space often tends to be perceived quite early through = the use of the space, so even if we say "no barrier to entry" now, the = ability to expand to 32-bit numbers would make it more likely that = assignments in this space remain zero-friction. So I'd say I prefer = (iii) to (i). Cheers, Brian= From fgont@si6networks.com Sat Feb 16 15:45:21 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6645821F8A66 for ; Sat, 16 Feb 2013 15:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nANyZF-QrJSj for ; Sat, 16 Feb 2013 15:45:20 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3E29A21F8A64 for ; Sat, 16 Feb 2013 15:45:19 -0800 (PST) Received: from [186.134.32.92] (helo=[192.168.123.126]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U6rRR-0008Hu-DZ; Sun, 17 Feb 2013 00:45:14 +0100 Message-ID: <51201A00.4060608@si6networks.com> Date: Sat, 16 Feb 2013 20:45:04 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <20130216230218.8678.8957.idtracker@ietfa.amsl.com> In-Reply-To: <20130216230218.8678.8957.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.6 X-Forwarded-Message-Id: <20130216230218.8678.8957.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [tcpm] New I-D "On the Validation of TCP Sequence Numbers" (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-00.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2013 23:45:21 -0000 Folks, We have just published a new IETF I-D entitled "On the Validation of TCP Sequence Numbers". The I-D is available at: . The abstract of the I-D is: ---- cut here ---- When TCP receives packets that lie outside of the receive window, the corresponding packets are dropped and either an ACK, RST or no response is generated due to the out-of-window packet, with no further processing of the packet. Most of the time, this works just fine and TCP remains stable, especially when a TCP connection has unidirectional data flow. However, there are three scenarios in which packets that are outside of the receive window should still have their ACK field processed, or else a packet war will take place. The aforementioned issues have affected a number of popular TCP implementations, typically leading to connection failures, system crashes, or other undesirable behaviors. This document describes the three scenarios in which the aforementioned issues might arise, and formally updates RFC 793 such that these potential problems are mitigated. ---- cut here ---- It discusses a problem that has affected a number of popular TCP implementations, and aims to formally update RFC 793 to mitigate these issues. Any comments will be welcome. Thanks! Best regards, Fernando -------- Original Message -------- From: internet-drafts@ietf.org To: fgont@si6networks.com Cc: david.borman@quantum.com Subject: New Version Notification for draft-gont-tcpm-tcp-seq-validation-00.txt Message-ID: <20130216230218.8678.8957.idtracker@ietfa.amsl.com> Date: Sat, 16 Feb 2013 15:02:18 -0800 A new version of I-D, draft-gont-tcpm-tcp-seq-validation-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Filename: draft-gont-tcpm-tcp-seq-validation Revision: 00 Title: On the Validation of TCP Sequence Numbers Creation date: 2013-02-16 Group: Individual Submission Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-seq-validation-00.txt Status: http://datatracker.ietf.org/doc/draft-gont-tcpm-tcp-seq-validation Htmlized: http://tools.ietf.org/html/draft-gont-tcpm-tcp-seq-validation-00 Abstract: When TCP receives packets that lie outside of the receive window, the corresponding packets are dropped and either an ACK, RST or no response is generated due to the out-of-window packet, with no further processing of the packet. Most of the time, this works just fine and TCP remains stable, especially when a TCP connection has unidirectional data flow. However, there are three scenarios in which packets that are outside of the receive window should still have their ACK field processed, or else a packet war will take place. The aforementioned issues have affected a number of popular TCP implementations, typically leading to connection failures, system crashes, or other undesirable behaviors. This document describes the three scenarios in which the aforementioned issues might arise, and formally updates RFC 793 such that these potential problems are mitigated. The IETF Secretariat From internet-drafts@ietf.org Mon Feb 18 01:48:52 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D5121F8815; Mon, 18 Feb 2013 01:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6CNnga+bg8A; Mon, 18 Feb 2013 01:48:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80DC21F880E; Mon, 18 Feb 2013 01:48:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130218094851.31807.44373.idtracker@ietfa.amsl.com> Date: Mon, 18 Feb 2013 01:48:51 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 18 Feb 2013 09:48:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : TCP and SCTP RTO Restart Author(s) : Per Hurtig Anna Brunstrom Andreas Petlund Michael Welzl Filename : draft-ietf-tcpm-rtorestart-00.txt Pages : 10 Date : 2013-02-18 Abstract: This document describes a modified algorithm for managing the TCP and SCTP retransmission timers that provides faster loss recovery when a connection's amount of outstanding data is small. The modification allows the transport to restart its retransmission timer more aggressively in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short-lived or application-limited. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rs@netapp.com Mon Feb 18 06:50:17 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C43621F88CF for ; Mon, 18 Feb 2013 06:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMVoT+9rCuhn for ; Mon, 18 Feb 2013 06:50:15 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id D50A521F88B4 for ; Mon, 18 Feb 2013 06:50:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,688,1355126400"; d="scan'208";a="23290568" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 18 Feb 2013 06:50:13 -0800 Received: from vmwexceht05-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r1IEoB48002538; Mon, 18 Feb 2013 06:50:12 -0800 (PST) Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.8.229]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0328.009; Mon, 18 Feb 2013 06:50:11 -0800 From: "Scheffenegger, Richard" To: Brian Trammell , Joe Touch Thread-Topic: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options Thread-Index: AQHOC7as5UzFOxWkPEi3SibgkZDMhJh868iAgALKuRA= Date: Mon, 18 Feb 2013 14:50:10 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F24A07FF7@SACEXCMBX06-PRD.hq.netapp.com> References: <511E92E9.6080709@isi.edu> <2D5114CD-D316-4A0A-AFE4-5A9129C6DD2B@tik.ee.ethz.ch> In-Reply-To: <2D5114CD-D316-4A0A-AFE4-5A9129C6DD2B@tik.ee.ethz.ch> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 18 Feb 2013 14:50:17 -0000 Hi Joe, >1. do you agree with change (A)? > >2. do you agree with change (B)? > >3. do you agree with change (C)? > > if so, which variant (i), (ii), (iii)? > >My preference is: > A yes > B yes > C yes > first choice (i) > second choice (iii) > (I think (ii) is inelegant) With (B) stating that multiple assignments are possible, I think C(ii) and = C(iii) don't really need to be in the document. Any experiment that is noti= fied by IANA of an experiment id collision should be free to use whatever m= eans appear feasible to disambiguate further (such as adding 16 more bits a= s extended experiment id, using different length options etc.)... Thus I support (A), (B), (C)(i)... Best regards, Richard Scheffenegger > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Brian Trammell > Sent: Samstag, 16. Februar 2013 13:10 > To: Joe Touch > Cc: tcpm@ietf.org > Subject: Re: [tcpm] request for feedback - proposed update to draft-touch= - > tcpm-experimental-options >=20 > hi Joe, all, >=20 > On 15 Feb 2013, at 20:56, Joe Touch wrote: >=20 > > Here's what we need to know: > > > > 1. do you agree with change (A)? >=20 > yes >=20 > > 2. do you agree with change (B)? >=20 > yes >=20 > > 3. do you agree with change (C)? > > > > if so, which variant (i), (ii), (iii)? >=20 > yes. The value in our draft, in any case, is arbitrary and can be changed > at this point with minimal experimental impact, so preserving existing > values (at least from my viewpoint) isn't worth the relative inelegance o= f > (ii). >=20 > On straight 16- vs 16-32 bit identifiers, I have noticed that scarcity in > 16-bit number space often tends to be perceived quite early through the > use of the space, so even if we say "no barrier to entry" now, the abilit= y > to expand to 32-bit numbers would make it more likely that assignments in > this space remain zero-friction. So I'd say I prefer (iii) to (i). >=20 > Cheers, >=20 > Brian > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From brandon.williams@akamai.com Tue Feb 19 06:51:58 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719DE21F8CF2 for ; Tue, 19 Feb 2013 06:51:58 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUy8BPTxntuj for ; Tue, 19 Feb 2013 06:51:58 -0800 (PST) Received: from prod-mail-xrelay01.akamai.com (prod-mail-xrelay01.akamai.com [72.246.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id F357C21F89EF for ; Tue, 19 Feb 2013 06:51:57 -0800 (PST) Received: from prod-mail-xrelay01.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 02A08CF9C3 for ; Tue, 19 Feb 2013 14:51:55 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay01.akamai.com (Postfix) with ESMTP id E43E9CF2EE for ; Tue, 19 Feb 2013 14:51:54 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id D9498FE09A for ; Tue, 19 Feb 2013 14:51:54 +0000 (GMT) Message-ID: <51239189.2060504@akamai.com> Date: Tue, 19 Feb 2013 09:51:53 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: tcpm@ietf.org References: <511E92E9.6080709@isi.edu> In-Reply-To: <511E92E9.6080709@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 14:51:58 -0000 On 02/15/2013 02:56 PM, Joe Touch wrote: > 1. do you agree with change (A)? Yes. > > 2. do you agree with change (B)? Yes, provided that "OK to indicate multiple assignees" means that the multiple assignees should all agree. > > 3. do you agree with change (C)? Yes. i looks better due to size, iii is next. --Brandon -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. From touch@isi.edu Tue Feb 19 09:25:22 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A923A21F8BF0 for ; Tue, 19 Feb 2013 09:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.934 X-Spam-Level: X-Spam-Status: No, score=-104.934 tagged_above=-999 required=5 tests=[AWL=1.665, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYZTML+MvDWk for ; Tue, 19 Feb 2013 09:25:19 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDCD21F8B90 for ; Tue, 19 Feb 2013 09:25:19 -0800 (PST) Received: from [128.9.184.177] ([128.9.184.177]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r1JHNLFY023293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Feb 2013 09:23:21 -0800 (PST) Message-ID: <5123B50A.1050001@isi.edu> Date: Tue, 19 Feb 2013 09:23:22 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Brandon Williams References: <511E92E9.6080709@isi.edu> <51239189.2060504@akamai.com> In-Reply-To: <51239189.2060504@akamai.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 17:25:22 -0000 On 2/19/2013 6:51 AM, Brandon Williams wrote: > On 02/15/2013 02:56 PM, Joe Touch wrote: >> 1. do you agree with change (A)? > > Yes. > >> >> 2. do you agree with change (B)? > > Yes, provided that "OK to indicate multiple assignees" means that the > multiple assignees should all agree. So what if they don't? Or, more specifically, what if they: - refuse - cannot be contacted Or should we just say that the IANA list is the 'first to file', and don't really list anything else? Joe From touch@isi.edu Tue Feb 19 09:44:18 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A71A21F8E48 for ; Tue, 19 Feb 2013 09:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.979 X-Spam-Level: X-Spam-Status: No, score=-104.979 tagged_above=-999 required=5 tests=[AWL=1.620, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krJZjbt8b0z9 for ; Tue, 19 Feb 2013 09:44:18 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0750621F8E3D for ; Tue, 19 Feb 2013 09:44:18 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r1JHh3hO026870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Feb 2013 09:43:06 -0800 (PST) Message-ID: <5123B9A2.7000805@isi.edu> Date: Tue, 19 Feb 2013 09:42:58 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Brandon Williams References: <511E92E9.6080709@isi.edu> <51239189.2060504@akamai.com> <5123B50A.1050001@isi.edu> In-Reply-To: <5123B50A.1050001@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 17:44:18 -0000 PS - we could add the following: 16 bits are assigned, but 32 SHOULD be used IANA registration will assign FCFS the first 16 bits, and record the second 16 bits if provided. That still leaves the question of squatters and/or collisions that request explicit registration. Clearly, IANA requests should help the applicant choose an unassigned codepoint rather than recording a collision. However, if they either refuse or didn't contact IANA (i.e., squatter), what should we ask IANA to do? This case comes up in the ports space. There are a few solutions: a) don't record or indicate collisions i.e., record only the IANA assignments b) record the existence of a collision, but no other info this helps users debug problems, but avoids implicit endorsement of squatter usage c) record the collision and all available info helps debugging the best, and allows the community to "assign blame", but might be taken as an implicit endorsement of squatter usage I'm in favor of (b) above. Joe On 2/19/2013 9:23 AM, Joe Touch wrote: > > > On 2/19/2013 6:51 AM, Brandon Williams wrote: >> On 02/15/2013 02:56 PM, Joe Touch wrote: >>> 1. do you agree with change (A)? >> >> Yes. >> >>> >>> 2. do you agree with change (B)? >> >> Yes, provided that "OK to indicate multiple assignees" means that the >> multiple assignees should all agree. > > So what if they don't? > > Or, more specifically, what if they: > > - refuse > - cannot be contacted > > Or should we just say that the IANA list is the 'first to file', and > don't really list anything else? > > Joe From brandon.williams@akamai.com Tue Feb 19 09:50:33 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE5A21F8D76 for ; Tue, 19 Feb 2013 09:50:33 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KcN1mJRE43Z for ; Tue, 19 Feb 2013 09:50:33 -0800 (PST) Received: from prod-mail-xrelay01.akamai.com (prod-mail-xrelay01.akamai.com [72.246.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0F59821F8CC5 for ; Tue, 19 Feb 2013 09:50:32 -0800 (PST) Received: from prod-mail-xrelay01.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7B2B7CF2EE; Tue, 19 Feb 2013 17:50:31 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay01.akamai.com (Postfix) with ESMTP id 68233CF240; Tue, 19 Feb 2013 17:50:31 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 55E3AFE1B4; Tue, 19 Feb 2013 17:50:31 +0000 (GMT) Message-ID: <5123BB67.9080805@akamai.com> Date: Tue, 19 Feb 2013 12:50:31 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Joe Touch References: <511E92E9.6080709@isi.edu> <51239189.2060504@akamai.com> <5123B50A.1050001@isi.edu> In-Reply-To: <5123B50A.1050001@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 17:50:33 -0000 On 02/19/2013 12:23 PM, Joe Touch wrote: > > > On 2/19/2013 6:51 AM, Brandon Williams wrote: >> On 02/15/2013 02:56 PM, Joe Touch wrote: >>> 1. do you agree with change (A)? >> >> Yes. >> >>> >>> 2. do you agree with change (B)? >> >> Yes, provided that "OK to indicate multiple assignees" means that the >> multiple assignees should all agree. > > So what if they don't? > > Or, more specifically, what if they: > > - refuse > - cannot be contacted > > Or should we just say that the IANA list is the 'first to file', and > don't really list anything else? > > Joe > My thinking is that one of the goals of a registry would be to avoid collisions, which suggests that 'first to file' language would be good. I don't think it's absolutely necessary to disallow multiple assignees, but would prefer that to an approach that too readily allows collisions. --Brandon -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. From brandon.williams@akamai.com Tue Feb 19 09:55:15 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C3B21F8D6A for ; Tue, 19 Feb 2013 09:55:15 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OT6HxLmVOCWR for ; Tue, 19 Feb 2013 09:55:15 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2D15E21F8C8D for ; Tue, 19 Feb 2013 09:55:15 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 933DD27C1A for ; Tue, 19 Feb 2013 17:55:14 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 812AF27C0E for ; Tue, 19 Feb 2013 17:55:14 +0000 (GMT) Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 6E5E0FE18D for ; Tue, 19 Feb 2013 17:55:14 +0000 (GMT) Message-ID: <5123BC82.1010907@akamai.com> Date: Tue, 19 Feb 2013 12:55:14 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <511E92E9.6080709@isi.edu> <51239189.2060504@akamai.com> <5123B50A.1050001@isi.edu> <5123B9A2.7000805@isi.edu> In-Reply-To: <5123B9A2.7000805@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 19 Feb 2013 17:55:15 -0000 This looks good to me. I also like your suggestion (b). --Brandon On 02/19/2013 12:42 PM, Joe Touch wrote: > PS - we could add the following: > > 16 bits are assigned, but 32 SHOULD be used > > IANA registration will assign FCFS the first 16 bits, > and record the second 16 bits if provided. > > That still leaves the question of squatters and/or collisions that > request explicit registration. > > Clearly, IANA requests should help the applicant choose an unassigned > codepoint rather than recording a collision. However, if they either > refuse or didn't contact IANA (i.e., squatter), what should we ask IANA > to do? > > This case comes up in the ports space. There are a few solutions: > > a) don't record or indicate collisions > i.e., record only the IANA assignments > > b) record the existence of a collision, but no other info > this helps users debug problems, but > avoids implicit endorsement of squatter usage > > c) record the collision and all available info > helps debugging the best, and allows > the community to "assign blame", but > might be taken as an implicit endorsement > of squatter usage > > I'm in favor of (b) above. > > Joe > > On 2/19/2013 9:23 AM, Joe Touch wrote: >> >> >> On 2/19/2013 6:51 AM, Brandon Williams wrote: >>> On 02/15/2013 02:56 PM, Joe Touch wrote: >>>> 1. do you agree with change (A)? >>> >>> Yes. >>> >>>> >>>> 2. do you agree with change (B)? >>> >>> Yes, provided that "OK to indicate multiple assignees" means that the >>> multiple assignees should all agree. >> >> So what if they don't? >> >> Or, more specifically, what if they: >> >> - refuse >> - cannot be contacted >> >> Or should we just say that the IANA list is the 'first to file', and >> don't really list anything else? >> >> Joe -- Brandon Williams; Principal Software Engineer Cloud Engineering; Akamai Technologies Inc. From anna.brunstrom@kau.se Wed Feb 20 14:57:41 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B0521F8727 for ; Wed, 20 Feb 2013 14:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpGBEm4lKhlR for ; Wed, 20 Feb 2013 14:57:41 -0800 (PST) Received: from smtprelay-h31.telenor.se (smtprelay-h31.telenor.se [213.150.131.4]) by ietfa.amsl.com (Postfix) with ESMTP id C03F921F8726 for ; Wed, 20 Feb 2013 14:57:40 -0800 (PST) Received: from ipb3.telenor.se (ipb3.telenor.se [195.54.127.166]) by smtprelay-h31.telenor.se (Postfix) with ESMTP id 15AD2E9FBF for ; Wed, 20 Feb 2013 23:57:19 +0100 (CET) X-SENDER-IP: [85.231.110.181] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQXAKRTJVFV5261PGdsb2JhbAANOMBjgRkDAQEBATiCUwEBAQEDAQEBNTYKEQsYCRYPCQMCAQIBFQYWFBMGAgEBiBqtD5MtjUeBThaDKgOXSZJGgWg X-IronPort-AV: E=Sophos;i="4.84,705,1355094000"; d="scan'208";a="284002843" Received: from c-b56ee755.06-34-6b736411.cust.bredbandsbolaget.se (HELO [192.168.1.100]) ([85.231.110.181]) by ipb3.telenor.se with ESMTP; 20 Feb 2013 23:57:19 +0100 Message-ID: <512554CE.9090608@kau.se> Date: Wed, 20 Feb 2013 23:57:18 +0100 From: Anna Brunstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: tcpm@ietf.org References: <20130218094851.31807.44373.idtracker@ietfa.amsl.com> In-Reply-To: <20130218094851.31807.44373.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 20 Feb 2013 22:57:42 -0000 Hi all, A kernel patch for the Linux 3.7 kernel that implements the RTO restart draft is available from http://riteproject.eu/projects/wp1-end-systems-and-applications/rto-restart/. Please try it out and see how it works in your context. Comments on the draft itself are of course also welcome. Best Regards, Anna On 2013-02-18 10:48, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. > > Title : TCP and SCTP RTO Restart > Author(s) : Per Hurtig > Anna Brunstrom > Andreas Petlund > Michael Welzl > Filename : draft-ietf-tcpm-rtorestart-00.txt > Pages : 10 > Date : 2013-02-18 > > Abstract: > This document describes a modified algorithm for managing the TCP and > SCTP retransmission timers that provides faster loss recovery when a > connection's amount of outstanding data is small. The modification > allows the transport to restart its retransmission timer more > aggressively in situations where fast retransmit cannot be used. > This enables faster loss detection and recovery for connections that > are short-lived or application-limited. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michael.scharf@alcatel-lucent.com Fri Feb 22 00:23:28 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F276E21F8763 for ; Fri, 22 Feb 2013 00:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.389 X-Spam-Level: X-Spam-Status: No, score=-9.389 tagged_above=-999 required=5 tests=[AWL=0.860, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8sk-5ku0OqW for ; Fri, 22 Feb 2013 00:23:27 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0217521F8722 for ; Fri, 22 Feb 2013 00:23:24 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1M8N0YP011012 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 22 Feb 2013 09:23:22 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 22 Feb 2013 09:23:02 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Date: Fri, 22 Feb 2013 09:23:01 +0100 Thread-Topic: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options Thread-Index: Ac4L3oZKRSQb+s5IR36Bk7x0tYTjNgE9lWoA Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6224@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <511ED5B3.1040803@mti-systems.com> <511ED5F2.4030100@mti-systems.com> In-Reply-To: <511ED5F2.4030100@mti-systems.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2013 08:23:28 -0000 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Wesley Eddy > Sent: Saturday, February 16, 2013 1:42 AM > To: tcpm@ietf.org > Subject: Re: [tcpm] request for feedback - proposed update to=20 > draft-touch-tcpm-experimental-options >=20 > On 2/15/2013 2:56 PM, Joe Touch wrote: > >=20 > > Here's what we need to know: > >=20 > > 1. do you agree with change (A)? > >=20 > > 2. do you agree with change (B)? > >=20 > > 3. do you agree with change (C)? >=20 > A) YES >=20 > B) YES (but should be clear that requesters can "suggest" a value) >=20 > C) YES (prefer option i) As individual TCPM contributor, I agree with Joe and Wes. As co-chair, I would really appreciate further opinions, most notably regar= ding change (C). Michael From john@jlc.net Fri Feb 22 10:36:20 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E588A21F8890 for ; Fri, 22 Feb 2013 10:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.08 X-Spam-Level: X-Spam-Status: No, score=-106.08 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gekzgh-3xzWs for ; Fri, 22 Feb 2013 10:36:18 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 222AA21F8810 for ; Fri, 22 Feb 2013 10:36:18 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id E2D2A33DA3; Fri, 22 Feb 2013 13:36:17 -0500 (EST) Date: Fri, 22 Feb 2013 13:36:17 -0500 From: John Leslie To: "Scharf, Michael (Michael)" Message-ID: <20130222183617.GG63436@verdi> References: <511ED5B3.1040803@mti-systems.com> <511ED5F2.4030100@mti-systems.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6224@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6224@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> User-Agent: Mutt/1.4.1i Cc: "tcpm@ietf.org" Subject: Re: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2013 18:36:21 -0000 Scharf, Michael (Michael) wrote: > > As co-chair, I would really appreciate further opinions, most notably > regarding change (C). I was too confused by the original request to comment. Since you ask, I traced down the actual issue, which is on draft-ietf-tcpm-experimental-options, not draft-touch... The plain fact is that the IESG state is three Yes vs. five Abstain. Abstain is the way the IESG "votes" "No". The remaining ballot positions are two Discuss vs. five No-Objection. No-Objection is the way the IESG "votes" "don't care". I recommend perusing the Narrative Minutes at www.ietf.org/iesg/minutes/2012/narrative-minutes-2012-12-20.html in which I heard a serious concern about variable-length nonces and an opinion that the WG might not be able to agree on a length. My personal opinion is that variable-length is a terrible idea; and that if we can't agree on a single length we should just give up. Frankly, I'm not sure the IESG is ready to approve this, even with a fixed-length nonce. Wes has been supportive of this I-D; but Wes will be off the IESG by the time this could return. Five Abstains is a pretty stiff barrier (though I have seen more). I think the discussion in the Narrative Minutes is a good one; and I agree with several IESG members who said we should look to an IANA registry, strictly first-come-first-served, where _any_ individual (even one with no connection to the group wanting to experiment) can request a number, with no requirement to document the purpose of the experiment, and be assured of a unique number. You asked for other opinions: that's mine. ==== To Joe's specific questions: A) I don't care what it's called B) OK, but "unassigned values" needs a definition C) only (i) is acceptable; (16 bits is fine) (I would expect we'd reserve the first 16-bits of known uses: any further length they use is their problem, not ours.) If we ever exhaust 16-bits, I consider that sufficient justification for allocating another TCP Option Number reserved for experimental use. -- John Leslie From touch@isi.edu Fri Feb 22 10:46:13 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4267921F8A90 for ; Fri, 22 Feb 2013 10:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.021 X-Spam-Level: X-Spam-Status: No, score=-103.021 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikk-0SS2Vq6J for ; Fri, 22 Feb 2013 10:46:12 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A907E21F89A3 for ; Fri, 22 Feb 2013 10:46:12 -0800 (PST) Received: from [128.9.184.100] ([128.9.184.100]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r1MIjHLU000728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Feb 2013 10:45:19 -0800 (PST) Message-ID: <5127BCC0.3030903@isi.edu> Date: Fri, 22 Feb 2013 10:45:20 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Leslie References: <511ED5B3.1040803@mti-systems.com> <511ED5F2.4030100@mti-systems.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6224@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <20130222183617.GG63436@verdi> In-Reply-To: <20130222183617.GG63436@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2013 18:46:13 -0000 On 2/22/2013 10:36 AM, John Leslie wrote: > Scharf, Michael (Michael) wrote: >> >> As co-chair, I would really appreciate further opinions, most notably >> regarding change (C). > > I was too confused by the original request to comment. > > Since you ask, I traced down the actual issue, which is on > draft-ietf-tcpm-experimental-options, not draft-touch... > > The plain fact is that the IESG state is three Yes vs. five Abstain. > Abstain is the way the IESG "votes" "No". AFAICT, 'discuss' is how they vote "no", since a position can pass with abstains so long as there are enough "yes" votes. Nothing happens until a discuss is resolved, though, so that's the only vote that blocks things if there are enough 'yes' positions. > The remaining ballot positions are two Discuss vs. five No-Objection. > No-Objection is the way the IESG "votes" "don't care". > > I recommend perusing the Narrative Minutes at > www.ietf.org/iesg/minutes/2012/narrative-minutes-2012-12-20.html > in which I heard a serious concern about variable-length nonces and > an opinion that the WG might not be able to agree on a length. This note posted a solution that addresses IESG concerns to see what the WG feedback would be. > My personal opinion is that variable-length is a terrible idea; and > that if we can't agree on a single length we should just give up. > > Frankly, I'm not sure the IESG is ready to approve this, even with > a fixed-length nonce. Wes has been supportive of this I-D; but Wes will > be off the IESG by the time this could return. Five Abstains is a > pretty stiff barrier (though I have seen more). Some of those positions might be changed based on this update. > I think the discussion in the Narrative Minutes is a good one; and > I agree with several IESG members who said we should look to an IANA > registry, strictly first-come-first-served, where _any_ individual > (even one with no connection to the group wanting to experiment) can > request a number, with no requirement to document the purpose of the > experiment, and be assured of a unique number. The IESG lives in a fantasy world where IANA registry assures users of assignment; we live in the real world where that doesn't happen. So we can update this doc to encourage people to register, but the solution MUST be robust to the squatting that a) has already happened and b) will continue to happen, either out of malice or ignorance. Joe > > You asked for other opinions: that's mine. > ==== > To Joe's specific questions: > > A) I don't care what it's called > B) OK, but "unassigned values" needs a definition > C) only (i) is acceptable; (16 bits is fine) > > (I would expect we'd reserve the first 16-bits of known uses: any > further length they use is their problem, not ours.) > > If we ever exhaust 16-bits, I consider that sufficient justification > for allocating another TCP Option Number reserved for experimental use. > > -- > John Leslie > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From john@jlc.net Fri Feb 22 11:21:44 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E5C21F8956 for ; Fri, 22 Feb 2013 11:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.103 X-Spam-Level: X-Spam-Status: No, score=-106.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KX8CD5H1s6Ql for ; Fri, 22 Feb 2013 11:21:36 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6D62321F8955 for ; Fri, 22 Feb 2013 11:21:35 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id B01C533C95; Fri, 22 Feb 2013 14:21:35 -0500 (EST) Date: Fri, 22 Feb 2013 14:21:35 -0500 From: John Leslie To: Joe Touch Message-ID: <20130222192135.GH63436@verdi> References: <511ED5B3.1040803@mti-systems.com> <511ED5F2.4030100@mti-systems.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6224@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <20130222183617.GG63436@verdi> <5127BCC0.3030903@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5127BCC0.3030903@isi.edu> User-Agent: Mutt/1.4.1i Cc: "tcpm@ietf.org" Subject: Re: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2013 19:21:44 -0000 Joe deserves a response: Joe Touch wrote: > On 2/22/2013 10:36 AM, John Leslie wrote: >> >> The plain fact is that the IESG state is three Yes vs. five Abstain. >> Abstain is the way the IESG "votes" "No". > > AFAICT, 'discuss' is how they vote "no", since a position can pass with > abstains so long as there are enough "yes" votes. While an I-D may pass with Abstains, it is the intent of IESG process that the IESG isn't allowed to stop something just because a minority doesn't like it. Usually more than one Abstain means the others will try to understand _why_ the AD Abstained. > Nothing happens until a discuss is resolved, though, Indeed: a Discuss is blocking; but it's common for an AD to move from Discuss to Abstain if others don't agree his Discuss has merit. There is a process (seldom invoked) for removing the block if the AD can't find another AD to agree the Discuss is worth resolving. I'll not attempt to describe that process here: see www.ietf.org/iesg/voting-procedures.html > so that's the only vote that blocks things if there are enough 'yes' > positions. It's better to avoid the word "vote" -- these are "ballot positions." Also, the rules for number of Yes positions are a bit complex; see www.ietf.org/iesg/voting-procedures.html >> I recommend perusing the Narrative Minutes at >> www.ietf.org/iesg/minutes/2012/narrative-minutes-2012-12-20.html >> in which I heard a serious concern about variable-length nonces and >> an opinion that the WG might not be able to agree on a length. > > This note posted a solution that addresses IESG concerns to see what the > WG feedback would be. Indeed. Alas, I may not have been the only person confused by it... >> Frankly, I'm not sure the IESG is ready to approve this, even with >> a fixed-length nonce. Wes has been supportive of this I-D; but Wes will >> be off the IESG by the time this could return. Five Abstains is a >> pretty stiff barrier (though I have seen more). > > Some of those positions might be changed based on this update. when it goes back to the IESG, yes... or they might not... >> I think the discussion in the Narrative Minutes is a good one; and >> I agree with several IESG members who said we should look to an IANA >> registry, strictly first-come-first-served, where _any_ individual >> (even one with no connection to the group wanting to experiment) can >> request a number, with no requirement to document the purpose of the >> experiment, and be assured of a unique number. > > The IESG lives in a fantasy world where IANA registry assures users of > assignment; we live in the real world where that doesn't happen. We _all_ live in a fantasy world! ;^) I'm not sure what you consider "assured" "assignment". IANA clearly cannot stop unfriendly users from forging TCP Option values. Nor can anyone else. :^( > So we can update this doc to encourage people to register, but the > solution MUST be robust to the squatting that > a) has already happened and > b) will continue to happen, either out of malice or ignorance. Believe it or not, IANA tries to avoid squatting damage, and the IESG is very supportive of these efforts. But it is pointless to try to "be robust" against all possible squatting. In a document like this, we can almost certainly list a few values where we believe already are used. Alternatively, we could propose a _new_ Experimental TCP Option number where IANA believes _no_ squatting exists; but there are IESG members I know would resist that -- YMMV. It is a bit silly to talk of "squatting" in the Experimental Option space -- these have always been "Use at your own risk." -- John Leslie From jamshid.mahdavi@bluecoat.com Fri Feb 22 12:54:21 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F4321F8EE3 for ; Fri, 22 Feb 2013 12:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOFOF6tPiSTV for ; Fri, 22 Feb 2013 12:54:07 -0800 (PST) Received: from plsvl-mailgw-01.bluecoat.com (plsvl-mailgw-01.bluecoat.com [199.91.133.11]) by ietfa.amsl.com (Postfix) with ESMTP id A502721F87AA for ; Fri, 22 Feb 2013 12:54:07 -0800 (PST) Received: from pwsvl-exchts-03.internal.cacheflow.com (pwsvl-exchts-03.bluecoat.com [10.2.2.160]) by plsvl-mailgw-01.bluecoat.com (Postfix) with ESMTP id 7253B81A0AE for ; Fri, 22 Feb 2013 13:01:59 -0900 (AKST) Received: from PWSVL-EXCMBX-04.internal.cacheflow.com ([fe80::c596:c77:dd67:b72d]) by pwsvl-exchts-03.internal.cacheflow.com ([fe80::a508:17dc:1550:e9f6%12]) with mapi id 14.01.0355.002; Fri, 22 Feb 2013 12:54:06 -0800 From: "Mahdavi, Jamshid" To: "tcpm@ietf.org" Thread-Topic: draft-ietf-tcpm-experimental-options Thread-Index: Ac4RN3UDu/G7H2JITH6LXAHQ4WqGxg== Date: Fri, 22 Feb 2013 20:54:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.2.106] Content-Type: multipart/alternative; boundary="_000_DF29671EFBFC454E984F5A1AD4834F491E7B02EApwsvlexcmbx04in_" MIME-Version: 1.0 Subject: [tcpm] draft-ietf-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2013 20:54:21 -0000 --_000_DF29671EFBFC454E984F5A1AD4834F491E7B02EApwsvlexcmbx04in_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this proposed draft. I don't believe that commercial vendo= rs who have TCP option needs would view this as changing the current landsc= ape at all. If your intent is to provide a new alternative that "cooperati= ng protocol designers" could use, in my opinion this is not meeting the nee= d. (If your intent is just to make it safer and easier to use the experimental= TCP options for actual experiments, you can ignore the rest of this email.= ) The draft claims that experimental TCP options are "intended to be used both in controlled environments and in are a= llowed in public deployments (when not enabled as default) [RFC3962]" (Side note: typo "in", and the citation is wrong, it should be 3692.) However, that goes against other documentation - for example these statemen= ts in 3692: "Mutually consenting devices could use these numbers for whatever purposes = they desire, but under the understanding that they are reserved for generic= testing purposes" (i.e. not for production use) "They are not intended to be used in general deployments or be enabled by d= efault in products or other general releases." (my reading of that has alw= ays been, "not intended for use in the public Internet") And, on the IANA assigned numbers: "RFC3692-style Experiment 1 (also improperly used for shipping products)" -= clearly implying these are not intended for use in commercial products. Finally, the draft itself implies the experimental option usage is still in= tended to be temporary in the discussion "Migration to Assigned Options". (Another side note: I'd have concerns about implementing the proposed migr= ation mechanism in practice due to the creation of extra connections which = would just be dropped.) In the absence of a better solution, a vendor may find using an experimenta= l option to be preferable to squatting somewhere else in the option space, = but this draft in its current form does not really appear to change any of = the underlying rules which suggest experimental options are not intended fo= r this type of use. One other suggestion for the draft: it might merit a word or two in the se= curity considerations how this draft might affect the firewall processing o= f TCP options 253 and 254. Having the IANA registry suggested elsewhere in= the thread would actually help firewalls to have better visibility into th= e contents of these options to be more selective about what to allow. --Jamshid --_000_DF29671EFBFC454E984F5A1AD4834F491E7B02EApwsvlexcmbx04in_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I have reviewed this proposed draft.  I donR= 17;t believe that commercial vendors who have TCP option needs would view t= his as changing the current landscape at all.  If your intent is to pr= ovide a new alternative that “cooperating protocol designers” could use, in my opinion this is not meeting the need.

 

(If your intent is just to make it safer and easier = to use the experimental TCP options for actual experiments, you can ignore = the rest of this email.)

 

The draft claims that experimental TCP options are <= o:p>

        &nbs= p; “intended to be used both in controlled environments and in a= re allowed in public deployments (when not enabled as default) [RFC3962]= 221;

(Side note:  typo “in”, and the cit= ation is wrong, it should be 3692.)

 

However, that goes against other documentation ̵= 1; for example these statements in 3692:

 

“Mutually consenting devices could use these n= umbers for whatever purposes they desire, but under the understanding that = they are reserved for generic testing purposes” (i.e. not for product= ion use)

 

“They are not intended to be used in general d= eployments or be enabled by default in products or other general releases.&= #8221;  (my reading of that has always been, “not intended for u= se in the public Internet”)

 

And, on the IANA assigned numbers:

 

“RFC3692-style Experiment 1 (also improperly u= sed for shipping products)” – clearly implying these are not in= tended for use in commercial products.

 

Finally, the draft itself implies the experimental o= ption usage is still intended to be temporary in the discussion “Migr= ation to Assigned Options”. 

(Another side note:  I’d have concerns ab= out implementing the proposed migration mechanism in practice due to the cr= eation of extra connections which would just be dropped.)

 

In the absence of a better solution, a vendor may fi= nd using an experimental option to be preferable to squatting somewhere els= e in the option space, but this draft in its current form does not really a= ppear to change any of the underlying rules which suggest experimental options are not intended for this type of= use.

 

One other suggestion for the draft:  it might m= erit a word or two in the security considerations how this draft might affe= ct the firewall processing of TCP options 253 and 254.  Having the IAN= A registry suggested elsewhere in the thread would actually help firewalls to have better visibility into the contents = of these options to be more selective about what to allow.

 

--Jamshid

 

--_000_DF29671EFBFC454E984F5A1AD4834F491E7B02EApwsvlexcmbx04in_-- From internet-drafts@ietf.org Fri Feb 22 13:04:09 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0266B21E805D; Fri, 22 Feb 2013 13:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCiIL4xblo97; Fri, 22 Feb 2013 13:04:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8303A21E8089; Fri, 22 Feb 2013 13:04:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130222210408.787.95615.idtracker@ietfa.amsl.com> Date: Fri, 22 Feb 2013 13:04:08 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-initcwnd-08.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2013 21:04:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : Increasing TCP's Initial Window Author(s) : Jerry Chu Nandita Dukkipati Yuchung Cheng Matt Mathis Filename : draft-ietf-tcpm-initcwnd-08.txt Pages : 23 Date : 2013-02-22 Abstract: This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments, with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purpose recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-initcwnd-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-initcwnd-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From touch@isi.edu Fri Feb 22 13:33:47 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32F421F8706 for ; Fri, 22 Feb 2013 13:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.011 X-Spam-Level: X-Spam-Status: No, score=-103.011 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2gpUCtgrdVe for ; Fri, 22 Feb 2013 13:33:47 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAC321F86C2 for ; Fri, 22 Feb 2013 13:33:47 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r1MLXFWp024885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Feb 2013 13:33:15 -0800 (PST) Message-ID: <5127E413.1000702@isi.edu> Date: Fri, 22 Feb 2013 13:33:07 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Mahdavi, Jamshid" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2013 21:33:48 -0000 Hi, Jamshid, On 2/22/2013 12:54 PM, Mahdavi, Jamshid wrote: ... > The draft claims that experimental TCP options are > > “intended to be used both in controlled environments and in > are allowed in public deployments (when not enabled as default) [RFC3962]” > > (Side note: typo “in”, and the citation is wrong, it should be 3692.) Those are part of pending updates. > However, that goes against other documentation – for example these > statements in 3692: > > “Mutually consenting devices could use these numbers for whatever > purposes they desire, but under the understanding that they are reserved > for generic testing purposes” (i.e. not for production use) > > “They are not intended to be used in general deployments or be enabled > by default in products or other general releases.” (my reading of that > has always been, “not intended for use in the public Internet”) The key is the term "default". I.e., they are allowed in general releases if not enabled by default. > And, on the IANA assigned numbers: > > “RFC3692-style Experiment 1 (also improperly used for shipping > products)” – clearly implying these are not intended for use in > commercial products. Not by default. But having them available where users can turn them on causes the same problem. > Finally, the draft itself implies the experimental option usage is still > intended to be temporary in the discussion “Migration to Assigned Options”. That's correct. The goal would be for experiments with sufficient experience that are sufficiently warranted to justify assignment of permanent TCP option codepoints. > (Another side note: I’d have concerns about implementing the proposed > migration mechanism in practice due to the creation of extra connections > which would just be dropped.) > > In the absence of a better solution, a vendor may find using an > experimental option to be preferable to squatting somewhere else in the > option space, but this draft in its current form does not really appear > to change any of the underlying rules which suggest experimental options > are not intended for this type of use. > > One other suggestion for the draft: it might merit a word or two in the > security considerations how this draft might affect the firewall > processing of TCP options 253 and 254. I can add that. > Having the IANA registry > suggested elsewhere in the thread would actually help firewalls to have > better visibility into the contents of these options to be more > selective about what to allow. The IANA registry would help firewalls only if they parsed inside TCP options; is that remotely likely? Joe > > --Jamshid > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From jamshid.mahdavi@bluecoat.com Fri Feb 22 15:42:04 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4607E21F86F6 for ; Fri, 22 Feb 2013 15:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFkl7aMHVKnb for ; Fri, 22 Feb 2013 15:42:03 -0800 (PST) Received: from plsvl-mailgw-01.bluecoat.com (plsvl-mailgw-01.bluecoat.com [199.91.133.11]) by ietfa.amsl.com (Postfix) with ESMTP id D51C321F86AB for ; Fri, 22 Feb 2013 15:42:00 -0800 (PST) Received: from PWSVL-EXCHTS-01.internal.cacheflow.com (unknown [10.2.2.122]) by plsvl-mailgw-01.bluecoat.com (Postfix) with ESMTP id 9A06381A072; Fri, 22 Feb 2013 15:49:53 -0900 (AKST) Received: from PWSVL-EXCMBX-04.internal.cacheflow.com ([fe80::c596:c77:dd67:b72d]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0289.001; Fri, 22 Feb 2013 15:41:59 -0800 From: "Mahdavi, Jamshid" To: Joe Touch Thread-Topic: [tcpm] draft-ietf-tcpm-experimental-options Thread-Index: Ac4RN3UDu/G7H2JITH6LXAHQ4WqGxgAT806AAAxbESA= Date: Fri, 22 Feb 2013 23:41:58 +0000 Message-ID: References: <5127E413.1000702@isi.edu> In-Reply-To: <5127E413.1000702@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.2.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2013 23:42:04 -0000 > > Having the IANA registry > > suggested elsewhere in the thread would actually help firewalls to=20 > > have better visibility into the contents of these options to be more=20 > > selective about what to allow. > The IANA registry would help firewalls only if they parsed inside TCP opt= ions; is that remotely likely? I don't know if it is likely, but I know that some firewalls do parse the o= ption numbers themselves and give control to block or allow specific option= numbers. If the data were available it seems at least plausible that some= would try to take advantage of that. From touch@isi.edu Fri Feb 22 15:46:06 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B6721F854C for ; Fri, 22 Feb 2013 15:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.99 X-Spam-Level: X-Spam-Status: No, score=-104.99 tagged_above=-999 required=5 tests=[AWL=1.609, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxV42+pgV7GG for ; Fri, 22 Feb 2013 15:46:06 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB0621F84ED for ; Fri, 22 Feb 2013 15:46:06 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r1MNj9jp016689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Feb 2013 15:45:09 -0800 (PST) Message-ID: <512802FD.9020802@isi.edu> Date: Fri, 22 Feb 2013 15:45:01 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Mahdavi, Jamshid" References: <5127E413.1000702@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 22 Feb 2013 23:46:07 -0000 On 2/22/2013 3:41 PM, Mahdavi, Jamshid wrote: >>> Having the IANA registry >>> suggested elsewhere in the thread would actually help firewalls to >>> have better visibility into the contents of these options to be more >>> selective about what to allow. > >> The IANA registry would help firewalls only if they parsed inside TCP options; is that remotely likely? > > I don't know if it is likely, but I know that some firewalls do parse the option numbers themselves and give control to block or allow specific option numbers. If the data were available it seems at least plausible that some would try to take advantage of that. Yes, but I suspect it would be prudent to block experimental options completely, rather than to parse them for various experiments. Joe From jamshid.mahdavi@bluecoat.com Fri Feb 22 16:04:14 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D232321F894E for ; Fri, 22 Feb 2013 16:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJgSZ-Z1ul9u for ; Fri, 22 Feb 2013 16:04:14 -0800 (PST) Received: from plsvl-mailgw-01.bluecoat.com (plsvl-mailgw-01.bluecoat.com [199.91.133.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB1421F8931 for ; Fri, 22 Feb 2013 16:04:14 -0800 (PST) Received: from PWSVL-EXCHTS-02.internal.cacheflow.com (unknown [10.2.2.126]) by plsvl-mailgw-01.bluecoat.com (Postfix) with ESMTP id 65F4181A08D; Fri, 22 Feb 2013 16:12:07 -0900 (AKST) Received: from PWSVL-EXCMBX-04.internal.cacheflow.com ([fe80::c596:c77:dd67:b72d]) by PWSVL-EXCHTS-02.internal.cacheflow.com ([fe80::4910:317f:407:6ecc%14]) with mapi id 14.01.0289.001; Fri, 22 Feb 2013 16:04:13 -0800 From: "Mahdavi, Jamshid" To: Joe Touch Thread-Topic: [tcpm] draft-ietf-tcpm-experimental-options Thread-Index: Ac4RN3UDu/G7H2JITH6LXAHQ4WqGxgAT806AAAxbESD//8IBgIAAgv8Q Date: Sat, 23 Feb 2013 00:04:10 +0000 Message-ID: References: <5127E413.1000702@isi.edu> <512802FD.9020802@isi.edu> In-Reply-To: <512802FD.9020802@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.2.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2013 00:04:14 -0000 > Yes, but I suspect it would be prudent to block experimental options comp= letely, rather than to parse them for various experiments. Fair enough, but that reiterates my main point -- if you are trying to prov= ide a solution for vendors who have needs around TCP Options, this draft is= not really going to provide that any better than the current scheme does. --J From touch@isi.edu Fri Feb 22 16:12:12 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3995321F8EA0 for ; Fri, 22 Feb 2013 16:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.029 X-Spam-Level: X-Spam-Status: No, score=-105.029 tagged_above=-999 required=5 tests=[AWL=1.570, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTkmreQvwTI5 for ; Fri, 22 Feb 2013 16:12:11 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A270E21F8E64 for ; Fri, 22 Feb 2013 16:12:11 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r1N0BtZ1020519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Feb 2013 16:11:55 -0800 (PST) Message-ID: <51280942.50402@isi.edu> Date: Fri, 22 Feb 2013 16:11:46 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Mahdavi, Jamshid" References: <5127E413.1000702@isi.edu> <512802FD.9020802@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 23 Feb 2013 00:12:12 -0000 On 2/22/2013 4:04 PM, Mahdavi, Jamshid wrote: > >> Yes, but I suspect it would be prudent to block experimental options completely, rather than to parse them for various experiments. > > Fair enough, but that reiterates my main point -- if you are trying to provide a solution for vendors who have needs around TCP Options, this draft is not really going to provide that any better than the current scheme does. Vendors ought to go through the process and get their stuff approved by the IETF - or be mocked publicly for not doing so. We're talking about TCP here. If you play with an option as a test, you ought to call it a test and be happy with that, even if it means the system isn't yet commercially viable. Joe From wes@mti-systems.com Sun Feb 24 18:46:02 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B1521F9181 for ; Sun, 24 Feb 2013 18:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPqMPHwTnaUz for ; Sun, 24 Feb 2013 18:46:01 -0800 (PST) Received: from atl4mhob07.myregisteredsite.com (atl4mhob07.myregisteredsite.com [209.17.115.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF2421F9123 for ; Sun, 24 Feb 2013 18:45:54 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob07.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r1P2jq6g020412 for ; Sun, 24 Feb 2013 21:45:52 -0500 Received: (qmail 29117 invoked by uid 0); 25 Feb 2013 02:45:52 -0000 Received: from unknown (HELO ?192.168.1.145?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 25 Feb 2013 02:45:52 -0000 Message-ID: <512AD050.5010805@mti-systems.com> Date: Sun, 24 Feb 2013 21:45:36 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Joe Touch References: <511ED5B3.1040803@mti-systems.com> <511ED5F2.4030100@mti-systems.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6224@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <20130222183617.GG63436@verdi> <5127BCC0.3030903@isi.edu> In-Reply-To: <5127BCC0.3030903@isi.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 25 Feb 2013 02:46:02 -0000 On 2/22/2013 1:45 PM, Joe Touch wrote: >> Frankly, I'm not sure the IESG is ready to approve this, even with >> a fixed-length nonce. Wes has been supportive of this I-D; but Wes will >> be off the IESG by the time this could return. Five Abstains is a >> pretty stiff barrier (though I have seen more). > > Some of those positions might be changed based on this update. As I understand them, those ballots *should* be able to change based on some of the modifications Joe proposed. Some of them were, in my opinion, based on a misunderstanding of what the goals were, and AD's envisioning their own personal criteria that wasn't consistent with what the WG originally shot for. I think these changes will bring it within expectations. -- Wes Eddy MTI Systems From internet-drafts@ietf.org Mon Feb 25 10:08:28 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF39221F943D; Mon, 25 Feb 2013 10:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-Ro2w3xXWSI; Mon, 25 Feb 2013 10:08:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54D81F0D0E; Mon, 25 Feb 2013 10:08:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225180826.23539.26542.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 10:08:26 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 25 Feb 2013 18:08:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : Shared Use of Experimental TCP Options Author(s) : Joe Touch Filename : draft-ietf-tcpm-experimental-options-04.txt Pages : 9 Date : 2013-02-25 Abstract: This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection. It uses a new IANA TCP experiment identifier, and is also robust to experiments that are not registered and those that do not use this sharing mechanism. It is recommended for all new TCP options that use these codepoints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-experimental-options-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-experimental-options-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From touch@isi.edu Mon Feb 25 10:22:34 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC5021E8097; Mon, 25 Feb 2013 10:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.22 X-Spam-Level: X-Spam-Status: No, score=-103.22 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYKbNsA0+WBQ; Mon, 25 Feb 2013 10:22:33 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 894CD21E8096; Mon, 25 Feb 2013 10:22:33 -0800 (PST) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r1PIMCKi005999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Feb 2013 10:22:15 -0800 (PST) Message-ID: <512BABD9.2020008@isi.edu> Date: Mon, 25 Feb 2013 10:22:17 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: internet-drafts@ietf.org References: <20130225180826.23539.26542.idtracker@ietfa.amsl.com> In-Reply-To: <20130225180826.23539.26542.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, i-d-announce@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 25 Feb 2013 18:22:34 -0000 Hi, all, This version provides the following updates: - changes the magic number to an experiment ID - uses a 16-bit registry with an optional 16-bit additional "magic number" to combine aspects of an IANA registry with the potential for additional protection by using a larger value - thus allows 16-bit or 32-bit values, but the first 16 bits are expected to be unique Joe On 2/25/2013 10:08 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. > > Title : Shared Use of Experimental TCP Options > Author(s) : Joe Touch > Filename : draft-ietf-tcpm-experimental-options-04.txt > Pages : 9 > Date : 2013-02-25 > > Abstract: > This document describes how the experimental TCP option codepoints > can concurrently support multiple TCP extensions, even within the > same connection. It uses a new IANA TCP experiment identifier, and > is also robust to experiments that are not registered and those that > do not use this sharing mechanism. It is recommended for all new TCP > options that use these codepoints. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tcpm-experimental-options-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-experimental-options-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From internet-drafts@ietf.org Mon Feb 25 11:22:08 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9187C21F92E1; Mon, 25 Feb 2013 11:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p22UzSYcob69; Mon, 25 Feb 2013 11:22:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2284A21F92EB; Mon, 25 Feb 2013 11:22:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225192208.21371.21404.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 11:22:08 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 25 Feb 2013 19:22:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : TCP Fast Open Author(s) : Yuchung Cheng Jerry Chu Sivasankar Radhakrishnan Arvind Jain Filename : draft-ietf-tcpm-fastopen-03.txt Pages : 23 Date : 2013-02-25 Abstract: TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, thus saving up to one full round trip time (RTT) compared to standard TCP which requires a three-way handshake (3WHS) to complete before data can be exchanged. Terminology The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-fastopen-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From john@jlc.net Mon Feb 25 11:29:41 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB4921F929C for ; Mon, 25 Feb 2013 11:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.143 X-Spam-Level: X-Spam-Status: No, score=-106.143 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epxGz6t6WEKP for ; Mon, 25 Feb 2013 11:29:41 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1B121F9297 for ; Mon, 25 Feb 2013 11:29:36 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 3AC0233C23; Mon, 25 Feb 2013 14:29:36 -0500 (EST) Date: Mon, 25 Feb 2013 14:29:36 -0500 From: John Leslie To: Joe Touch Message-ID: <20130225192936.GK63436@verdi> References: <20130225180826.23539.26542.idtracker@ietfa.amsl.com> <512BABD9.2020008@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <512BABD9.2020008@isi.edu> User-Agent: Mutt/1.4.1i Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 25 Feb 2013 19:29:41 -0000 Joe Touch wrote: > > This version provides the following updates: > > - changes the magic number to an experiment ID :^) > - uses a 16-bit registry with an optional 16-bit additional "magic > number" to combine aspects of an IANA registry with the potential for > additional protection by using a larger value This IMHO gives us the best chance of IESG approval. (Alas, that's not quite what the draft says -- I know Joe is squeezed for time.) > - thus allows 16-bit or 32-bit values, but the first 16 bits are > expected to be unique :^) Note the IANA Considerations: ] ] This document calls for IANA to create a new TCP experimental option ] Experiment Identifier (ExID) registry. ] That registry should allow 16-bit and 32-bit entries... Wording like that _will_ confuse IANA, and will cause Michelle to ask for more clarity. :^( Wording like Joe's post suggests, where IANA is simply asked to register a 16-bit ExID, is simpler for everyone and IMHO accomplishes what we want. The IESG discussion last time suggested the WG is unable to agree on a single length. I sincerely hope we can prove that idea wrong. -- John Leslie From touch@isi.edu Mon Feb 25 11:38:18 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E05D21F9314 for ; Mon, 25 Feb 2013 11:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.111 X-Spam-Level: X-Spam-Status: No, score=-103.111 tagged_above=-999 required=5 tests=[AWL=-0.512, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjquvXRmzCdF for ; Mon, 25 Feb 2013 11:38:17 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9294021F931D for ; Mon, 25 Feb 2013 11:38:17 -0800 (PST) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r1PJbeeW029718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Feb 2013 11:37:43 -0800 (PST) Message-ID: <512BBD88.7020609@isi.edu> Date: Mon, 25 Feb 2013 11:37:44 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Leslie References: <20130225180826.23539.26542.idtracker@ietfa.amsl.com> <512BABD9.2020008@isi.edu> <20130225192936.GK63436@verdi> In-Reply-To: <20130225192936.GK63436@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 25 Feb 2013 19:38:18 -0000 John, On 2/25/2013 11:29 AM, John Leslie wrote: > Joe Touch wrote: >> >> This version provides the following updates: >> >> - changes the magic number to an experiment ID > > :^) > >> - uses a 16-bit registry with an optional 16-bit additional "magic >> number" to combine aspects of an IANA registry with the potential for >> additional protection by using a larger value > > This IMHO gives us the best chance of IESG approval. > > (Alas, that's not quite what the draft says -- I know Joe is squeezed > for time.) Please see Section 3.1; I was summarizing that section. >> - thus allows 16-bit or 32-bit values, but the first 16 bits are >> expected to be unique > > :^) > > Note the IANA Considerations: > ] > ] This document calls for IANA to create a new TCP experimental option > ] Experiment Identifier (ExID) registry. > ] That registry should allow 16-bit and 32-bit entries... > > Wording like that _will_ confuse IANA, and will cause Michelle to > ask for more clarity. :^( > > Wording like Joe's post suggests, where IANA is simply asked to > register a 16-bit ExID, is simpler for everyone and IMHO accomplishes > what we want. Absolutely. Instead, I recommend that IANA uses the entire section, which includes: That registry should allow 16-bit and 32-bit entries, where entries are "first-come, first-served" on the first two bytes of the value in network-standard byte order (big endian), in which the entry should indicate the entire ExID value. Known overlapping uses - whether of the first-come portion or the entire value - should also be listed and highlighted as collisions. > The IESG discussion last time suggested the WG is unable to agree > on a single length. I sincerely hope we can prove that idea wrong. I don't intend to provide a tutorial to IANA on why this satisfies their "single length" goal with the WG's desire to allow different lengths with different costs. If they can't figure it out from the text, I'll gladly wait for an IESG that can. Or consider publishing this as a tech report and running the registry myself. Joe From john@jlc.net Mon Feb 25 11:59:40 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF86E21E80F9 for ; Mon, 25 Feb 2013 11:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.16 X-Spam-Level: X-Spam-Status: No, score=-106.16 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+3b1MY3CzbY for ; Mon, 25 Feb 2013 11:59:40 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF5F21E80F8 for ; Mon, 25 Feb 2013 11:59:40 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 666E633C23; Mon, 25 Feb 2013 14:59:40 -0500 (EST) Date: Mon, 25 Feb 2013 14:59:40 -0500 From: John Leslie To: Joe Touch Message-ID: <20130225195940.GL63436@verdi> References: <20130225180826.23539.26542.idtracker@ietfa.amsl.com> <512BABD9.2020008@isi.edu> <20130225192936.GK63436@verdi> <512BBD88.7020609@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <512BBD88.7020609@isi.edu> User-Agent: Mutt/1.4.1i Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 25 Feb 2013 19:59:40 -0000 Joe Touch wrote: > On 2/25/2013 11:29 AM, John Leslie wrote: >> >> Wording like Joe's post suggests, where IANA is simply asked to >> register a 16-bit ExID, is simpler for everyone and IMHO accomplishes >> what we want. > > Absolutely. :^) > Instead, I recommend that IANA uses the entire section, Perhaps somebody can explain why simpler isn't better? > which includes: > > That registry should allow 16-bit and 32-bit entries, where entries > are "first-come, first-served" on the first two bytes of the value > in network-standard byte order (big endian), in which the entry > should indicate the entire ExID value. Known overlapping uses - > whether of the first-come portion or the entire value - should also > be listed and highlighted as collisions. I really couldn't blame Michelle for being confused by such wording. Even naming the first 16 bits "ExID" and the remainder "Magic Number" would greatly reduce the confusion. Also, the passive voice about "listed and highligted" leaves open the question of who does this and how. If IANA simply does first come first served on 16 bits, and has a short free-form comments field, it would be clear that it's not IANA's job to find overlapping usage. >> The IESG discussion last time suggested the WG is unable to agree >> on a single length. I sincerely hope we can prove that idea wrong. > > I don't intend to provide a tutorial to IANA on why this satisfies their > "single length" goal with the WG's desire to allow different lengths > with different costs. (I didn't realize I was asking for a tutorial -- I though I was asking for simplicity.) > If they can't figure it out from the text, I'll gladly wait for an IESG > that can. Or consider publishing this as a tech report and running the > registry myself. Hmm... I thought this was a WG document... If it is, I think views of other WG members would help. -- John Leslie From ycheng@google.com Mon Feb 25 12:00:55 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26AF21E8121 for ; Mon, 25 Feb 2013 12:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lf+u6JaRDZdN for ; Mon, 25 Feb 2013 12:00:51 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2DB21E811C for ; Mon, 25 Feb 2013 12:00:36 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id ez12so3915948wid.5 for ; Mon, 25 Feb 2013 12:00:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=y/8mAPtQhgpmzgImTFuWjHtA3t0B8Jga/F6ibIJ6i3E=; b=R5BFcwXc46RBURSQh7Z20ePbJYqFJ5M3cXe0mUwLG7ciTutuUMNwLBHRAYa+VQBKP9 +SlKE14eXnNRk4ss1G6OUeGVTUPOp49Do8KluBnX3GnGEhU4UWPM04Qm0F3OYk5WXxn0 4ag0IgUbzktx6tIMewV7t7v1tqygAreLtoOnNfcxuf2CgB8w1w8EsUy8qsZg1ySLRLTg c0/lPywM4CYH7OruBZEWKDCQ2KGYWMDCLGPOrI0dLAcfYDSliPWyLsvrvkprD2TxlM0t g9cTGo/lk1tUX/zvfva9GQ8D4OmBlw9sJCAsaPdJculyg2f7xO59jgMeL/iQeSvoYVlt rp7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=y/8mAPtQhgpmzgImTFuWjHtA3t0B8Jga/F6ibIJ6i3E=; b=IU0EAgiikJ5pQMmOib063YiJDgPiCSV+Ds+LqSeWKMe+XRjoabIhmGfljDPONmuLFU kAEM5LJFdBbZam7oKdEyEEFa8a8OLzCgMe67beitf3FZjPmHEfblRt+r+00vHbpng+LE GoxXEsW8vOM+dT5vwZqva/HY718OHzlaL46roVC2z6Tt/dvat++X+khizduP5WcXCOrL SntxMH1FSxFH+NFQrFzZytW+VjvnSDVsE1K9yYB+RsE4bJ7rAkatSrt1KJHPIPz018QM zP4/2ObV7aiITb2Mu7moKQ3yCGVauYwlCIf/Hg9/B0+AxlQ01CDR3LcZs/NP0//TI0Ww U9Nw== X-Received: by 10.194.77.129 with SMTP id s1mr21770013wjw.17.1361822434341; Mon, 25 Feb 2013 12:00:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.56.227 with HTTP; Mon, 25 Feb 2013 12:00:14 -0800 (PST) In-Reply-To: <20130225192208.21371.21404.idtracker@ietfa.amsl.com> References: <20130225192208.21371.21404.idtracker@ietfa.amsl.com> From: Yuchung Cheng Date: Mon, 25 Feb 2013 12:00:14 -0800 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkG0z2T38rQFqigqOBzHv/8KS9GKm/H3Hl/mH9M+y+KKXaCG7hCqjeWbn+OhLRCloREe6LtzzWN3pcC8/6d3DonW4d/zUwHbId3hHqTndw3vn62kP4xp2ml9+Z8z0rWiS3j5RP1Wys8E+sqWtSFnoUySvSIkVaaxznQEflQl+ea2ObDBxkQHSVazqUJJTGdunHu+ZbO Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 25 Feb 2013 20:00:57 -0000 On Mon, Feb 25, 2013 at 11:22 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. > > Title : TCP Fast Open > Author(s) : Yuchung Cheng > Jerry Chu > Sivasankar Radhakrishnan > Arvind Jain > Filename : draft-ietf-tcpm-fastopen-03.txt > Pages : 23 > Date : 2013-02-25 > > Abstract: > TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK > packets and consumed by the receiving end during the initial > connection handshake, thus saving up to one full round trip time > (RTT) compared to standard TCP which requires a three-way handshake > (3WHS) to complete before data can be exchanged. > Diffs from -02.txt 1. A fore warning TFO isn't for everyone at section 2. Carved a new section 7 dedicated for application developers considering TFO. We highlight the potential issues and benefits, and use Web applications an example evaluation. 2. Two new paragraphs in section 4.2.2 after "Server: Receiving SYN and responding with SYN-ACK" 1. on SYN-ACK loss TFO may be more aggressive on the first round trip 2. Simultaneous Fast open is straightforward in the protocol 3. Negative caching on path not supporting SYN/data is a SHOULD 4. Minor edits > Terminology > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-fastopen-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Mon Feb 25 12:06:26 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B8921F922C for ; Mon, 25 Feb 2013 12:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.082 X-Spam-Level: X-Spam-Status: No, score=-103.082 tagged_above=-999 required=5 tests=[AWL=-0.483, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRba4YGdWFMY for ; Mon, 25 Feb 2013 12:06:18 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 58EDC21E8115 for ; Mon, 25 Feb 2013 12:05:50 -0800 (PST) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r1PK5ecn008481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Feb 2013 12:05:43 -0800 (PST) Message-ID: <512BC418.3030209@isi.edu> Date: Mon, 25 Feb 2013 12:05:44 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Leslie References: <20130225180826.23539.26542.idtracker@ietfa.amsl.com> <512BABD9.2020008@isi.edu> <20130225192936.GK63436@verdi> <512BBD88.7020609@isi.edu> <20130225195940.GL63436@verdi> In-Reply-To: <20130225195940.GL63436@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 25 Feb 2013 20:06:26 -0000 On 2/25/2013 11:59 AM, John Leslie wrote: > Joe Touch wrote: >> On 2/25/2013 11:29 AM, John Leslie wrote: >>> >>> Wording like Joe's post suggests, where IANA is simply asked to >>> register a 16-bit ExID, is simpler for everyone and IMHO accomplishes >>> what we want. >> >> Absolutely. > > :^) > >> Instead, I recommend that IANA uses the entire section, > > Perhaps somebody can explain why simpler isn't better? Please see Section 3.1, which already does. >> which includes: >> >> That registry should allow 16-bit and 32-bit entries, where entries >> are "first-come, first-served" on the first two bytes of the value >> in network-standard byte order (big endian), in which the entry >> should indicate the entire ExID value. Known overlapping uses - >> whether of the first-come portion or the entire value - should also >> be listed and highlighted as collisions. > > I really couldn't blame Michelle for being confused by such wording. > Even naming the first 16 bits "ExID" and the remainder "Magic Number" > would greatly reduce the confusion. > > Also, the passive voice about "listed and highligted" leaves open > the question of who does this and how. It's in the IANA considerations section. IANA does it. How is up to them. > If IANA simply does first come > first served on 16 bits, and has a short free-form comments field, it > would be clear that it's not IANA's job to find overlapping usage. Overlapping usage is a collision. If you ask for 0x1234 and it's already assigned, FCFS means they say "NO". We want them to say "this is already taken, but we'll list yours too". The first one has a "privileged" position in the listing, but otherwise collisions are not a reason to reject. IANA has no name for that sort of registry. All current IANA registries assume exclusive assignment only. Joe From john@jlc.net Mon Feb 25 12:22:32 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED9F21F913F for ; Mon, 25 Feb 2013 12:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.176 X-Spam-Level: X-Spam-Status: No, score=-106.176 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4F90yKFT92E for ; Mon, 25 Feb 2013 12:22:31 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id AC82E21F90F4 for ; Mon, 25 Feb 2013 12:22:31 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id E5A7133C23; Mon, 25 Feb 2013 15:22:31 -0500 (EST) Date: Mon, 25 Feb 2013 15:22:31 -0500 From: John Leslie To: Joe Touch Message-ID: <20130225202231.GM63436@verdi> References: <20130225180826.23539.26542.idtracker@ietfa.amsl.com> <512BABD9.2020008@isi.edu> <20130225192936.GK63436@verdi> <512BBD88.7020609@isi.edu> <20130225195940.GL63436@verdi> <512BC418.3030209@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <512BC418.3030209@isi.edu> User-Agent: Mutt/1.4.1i Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 25 Feb 2013 20:22:32 -0000 Joe Touch wrote: > On 2/25/2013 11:59 AM, John Leslie wrote: >> >> Perhaps somebody can explain why simpler isn't better? > > Please see Section 3.1, which already does. Help me please. Section 3.1 includes: ] ] ExIDs are selected at design time, when the protocol designer first ] implements or specifies the experimental option. Are we saying it's important to "select" these without any regard to whether the first 16 bits conflict with a prior use? ] ExIDs are registered with IANA using "first-come, first-served" ] priority based on the first two bytes. Those two bytes are thus ] sufficient to interpret which experimental option is contained in ] the option field. I don't see how this can be consistent with the idea of using the first 16 bits without regard for conflicting usage. >> If IANA simply does first come first served on 16 bits, and has a >> short free-form comments field, it would be clear that it's not >> IANA's job to find overlapping usage. > > Overlapping usage is a collision. If you ask for 0x1234 and it's already > assigned, FCFS means they say "NO". We want them to say "this is already > taken, but we'll list yours too". I really don't think IANA will consider that reasonable. > The first one has a "privileged" position in the listing, but otherwise > collisions are not a reason to reject. IMHO, asking for such a fundamental change in IANA operation would be a waste of IESG telechat time. > IANA has no name for that sort of registry. All current IANA registries > assume exclusive assignment only. Exactly! If that really is what the WG wants, I think we should find another provider of "registration". (Obviously, YMMV; and I really do think opinions from other folks would be more helpful than continuing this Joe/John dialogue...) -- John Leslie From touch@isi.edu Mon Feb 25 12:39:14 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF0421E8064 for ; Mon, 25 Feb 2013 12:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.057 X-Spam-Level: X-Spam-Status: No, score=-103.057 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcxNPlT-dBqx for ; Mon, 25 Feb 2013 12:39:13 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 630C621E8063 for ; Mon, 25 Feb 2013 12:39:12 -0800 (PST) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r1PKcgqr019487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Feb 2013 12:38:45 -0800 (PST) Message-ID: <512BCBD7.3060809@isi.edu> Date: Mon, 25 Feb 2013 12:38:47 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Leslie References: <20130225180826.23539.26542.idtracker@ietfa.amsl.com> <512BABD9.2020008@isi.edu> <20130225192936.GK63436@verdi> <512BBD88.7020609@isi.edu> <20130225195940.GL63436@verdi> <512BC418.3030209@isi.edu> <20130225202231.GM63436@verdi> In-Reply-To: <20130225202231.GM63436@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 25 Feb 2013 20:39:14 -0000 Hi, John, On 2/25/2013 12:22 PM, John Leslie wrote: > Joe Touch wrote: >> On 2/25/2013 11:59 AM, John Leslie wrote: >>> >>> Perhaps somebody can explain why simpler isn't better? >> >> Please see Section 3.1, which already does. > > Help me please. Section 3.1 includes: > ] > ] ExIDs are selected at design time, when the protocol designer first > ] implements or specifies the experimental option. > > Are we saying it's important to "select" these without any regard to > whether the first 16 bits conflict with a prior use? Preferably, but one thing that distinguishes this from conventional IANA use is that we're designing-in the expectation that there can be collisions, and how to deal with them. > ] ExIDs are registered with IANA using "first-come, first-served" > ] priority based on the first two bytes. Those two bytes are thus > ] sufficient to interpret which experimental option is contained in > ] the option field. > > I don't see how this can be consistent with the idea of using the > first 16 bits without regard for conflicting usage. The first 16 bits demux. The next 16 bits - if fixed, i.e., if the magic number part is used - verify. >>> If IANA simply does first come first served on 16 bits, and has a >>> short free-form comments field, it would be clear that it's not >>> IANA's job to find overlapping usage. >> >> Overlapping usage is a collision. If you ask for 0x1234 and it's already >> assigned, FCFS means they say "NO". We want them to say "this is already >> taken, but we'll list yours too". > > I really don't think IANA will consider that reasonable. IANA should be implementing what we ask. They already have lists where collisions are noted - the port numbers in specific. >> The first one has a "privileged" position in the listing, but otherwise >> collisions are not a reason to reject. > > IMHO, asking for such a fundamental change in IANA operation would be > a waste of IESG telechat time. The IESG started this by not understanding the goal of what the WG asked for. However, this isn't a fundamental change in how IANA runs; it's just not noted in the doc that defines FCFS or other IANA processes. >> IANA has no name for that sort of registry. All current IANA registries >> assume exclusive assignment only. > > Exactly! > > If that really is what the WG wants, I think we should find another > provider of "registration". IANA should be capable of doing something more than just what has been done before. This variant isn't rocket science, and as I noted they already do keep track of additional entries in other lists. > (Obviously, YMMV; and I really do think opinions from other folks > would be more helpful than continuing this Joe/John dialogue...) I'll be glad to have others chime in... Joe From internet-drafts@ietf.org Mon Feb 25 14:03:56 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B076F21E80D4; Mon, 25 Feb 2013 14:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8XrA7H2Hnbz; Mon, 25 Feb 2013 14:03:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4535C21E80DB; Mon, 25 Feb 2013 14:03:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225220356.30253.19546.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 14:03:56 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 25 Feb 2013 22:03:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions Work= ing Group of the IETF. Title : TCP Extensions for High Performance Author(s) : David Borman Bob Braden Van Jacobson Richard Scheffenegger Filename : draft-ietf-tcpm-1323bis-06.txt Pages : 43 Date : 2013-02-25 Abstract: This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth*delay product and to provide reliable operation over very high-speed paths. It defines TCP options for scaled windows and timestamps. The timestamps are used for two distinct mechanisms, RTTM (Round Trip Time Measurement) and PAWS (Protection Against Wrapped Sequences). This document updates and obsoletes RFC 1323. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-1323bis-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From michael.scharf@alcatel-lucent.com Tue Feb 26 08:48:16 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D908521F88BE for ; Tue, 26 Feb 2013 08:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.587 X-Spam-Level: X-Spam-Status: No, score=-7.587 tagged_above=-999 required=5 tests=[AWL=-1.338, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNfiXMo9jSCY for ; Tue, 26 Feb 2013 08:48:14 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id A0BD721F87D3 for ; Tue, 26 Feb 2013 08:48:14 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1QGlfOx031074 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 26 Feb 2013 17:48:10 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 26 Feb 2013 17:48:06 +0100 From: "Scharf, Michael (Michael)" To: Anna Brunstrom , "tcpm@ietf.org" Date: Tue, 26 Feb 2013 17:48:03 +0100 Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-00.txt Thread-Index: Ac4PvbOGlAeTRQbARw6ZZ+smXKvCjAEgpFsQ Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6325@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <20130218094851.31807.44373.idtracker@ietfa.amsl.com> <512554CE.9090608@kau.se> In-Reply-To: <512554CE.9090608@kau.se> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 26 Feb 2013 16:48:16 -0000 Anna, Thanks a lot for sharing this patch! Is there already some report of experiments with that patch (e. g., a paper= )? I'd be interested in that (as individual contributor). Thanks Michael > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Anna Brunstrom > Sent: Wednesday, February 20, 2013 11:57 PM > To: tcpm@ietf.org > Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-00.txt >=20 > Hi all, >=20 > A kernel patch for the Linux 3.7 kernel that implements the=20 > RTO restart draft is available from=20 > http://riteproject.eu/projects/wp1-end-systems-and-application > s/rto-restart/.=20 > Please try it out and see how it works in your context. >=20 > Comments on the draft itself are of course also welcome. >=20 > Best Regards, > Anna >=20 >=20 > On 2013-02-18 10:48, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > > This draft is a work item of the TCP Maintenance and=20 > Minor Extensions Working Group of the IETF. > > > > Title : TCP and SCTP RTO Restart > > Author(s) : Per Hurtig > > Anna Brunstrom > > Andreas Petlund > > Michael Welzl > > Filename : draft-ietf-tcpm-rtorestart-00.txt > > Pages : 10 > > Date : 2013-02-18 > > > > Abstract: > > This document describes a modified algorithm for=20 > managing the TCP and > > SCTP retransmission timers that provides faster loss=20 > recovery when a > > connection's amount of outstanding data is small. The=20 > modification > > allows the transport to restart its retransmission timer more > > aggressively in situations where fast retransmit cannot be used. > > This enables faster loss detection and recovery for=20 > connections that > > are short-lived or application-limited. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-00 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > = From michael.scharf@alcatel-lucent.com Tue Feb 26 10:24:15 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1222621F856E for ; Tue, 26 Feb 2013 10:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.492 X-Spam-Level: X-Spam-Status: No, score=-7.492 tagged_above=-999 required=5 tests=[AWL=-1.243, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3L-x3LsZV81M for ; Tue, 26 Feb 2013 10:24:14 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFBB21F8501 for ; Tue, 26 Feb 2013 10:24:13 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1QINEqD030136 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 26 Feb 2013 19:24:09 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 26 Feb 2013 19:23:44 +0100 From: "Scharf, Michael (Michael)" To: Joe Touch Date: Tue, 26 Feb 2013 19:23:42 +0100 Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-04.txt Thread-Index: Ac4ThSA5ltVfRWhOQaywBPu0yAiUuQAwM6AA Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6326@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <20130225180826.23539.26542.idtracker@ietfa.amsl.com> <512BABD9.2020008@isi.edu> In-Reply-To: <512BABD9.2020008@isi.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 26 Feb 2013 18:24:15 -0000 Joe, As individual WG contributor, I wonder why the complexity of a 32bit IANA r= egistry is indeed needed. I clearly prefered variant (C)i in your earlier e= -mail to the TCPM list, i. e., a 16 bit registry only. I think that this is= simple and just enough. Maybe I should have stated more explicitly in my original e-mail why a 16bi= t value without any magic number is enough - I assumed it was clear from th= e context: Assuming that the IANA registry is indeed used by most experimen= tors, wasting 2 bytes of scarce option space for a magic number hardly seem= s reasonable. TCPM considered 32bit when we assumed that there was no centr= al registry, i. e., a higher collision probability of randomly chosen magic= numbers. This has changed now given the planned use of an IANA registry. If the WG consensus was to stick to experiment IDs of either 16bit or 32bit= , I think that stronger guidance is needed in the document regarding whethe= r to select 32bit. Right now, the document says: The second two bytes serve as a "magic number". A magic number is a self-selected codepoint whose primary value is its unlikely collision with values selected by others. Magic numbers are used in other protocols, e.g., BOOTP [RFC951] and DHCP [RFC2131]. The magic number helps reduce the probability of a false positive collision with those who either do not register their experiment or who do not implement this mechanism. Using the additional magic number bytes also helps the option contents have the same byte alignment in the TCP header as they would have if (or when) a conventional (non- experiment) TCP option codepoint is assigned. I think that the document should more clearly explain the downsides of usin= g 32bit ID including a magic number, i. e., the consumption of TCP option s= pace possibly preventing other TCP extensions. As a side note, I don't understand why byte alignment helps that much - thi= s only applies to a 32-bit CPU architecture, right? Finally, I think that our objective is to encourage TCP experimentors to re= ally use the IANA registry, in order to avoid collisions as much as possibl= e. When I personally did my first TCP experiments as student, I had no unde= rstanding of IANA processes etc. While the current IANA consideration secti= on in draft-ietf-tcpm-experimental-options-04 may include the mandatory for= mal information for experts, as a student I would not have understood what = this means to my TCP experiment. The current text is written for experts on= ly, imho. I also wonder whether the IANA section could comment on the possibility to = deregister an experiment ID if the experimentor is confident that the codep= oint will not be used any more in the Internet. At least if an experimentor= has all endpoints under his control, this seems doable. Thanks Michael (again, all this e-mail is my individual opinion) > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Joe Touch > Sent: Monday, February 25, 2013 7:22 PM > To: internet-drafts@ietf.org > Cc: tcpm@ietf.org; i-d-announce@ietf.org > Subject: Re: [tcpm] I-D Action:=20 > draft-ietf-tcpm-experimental-options-04.txt >=20 > Hi, all, >=20 > This version provides the following updates: >=20 > - changes the magic number to an experiment ID >=20 > - uses a 16-bit registry with an optional 16-bit additional=20 > "magic number" to combine aspects of an IANA registry with=20 > the potential for additional protection by using a larger value >=20 > - thus allows 16-bit or 32-bit values, but the first 16 bits=20 > are expected to be unique >=20 > Joe >=20 > On 2/25/2013 10:08 AM, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > > This draft is a work item of the TCP Maintenance and=20 > Minor Extensions Working Group of the IETF. > > > > Title : Shared Use of Experimental TCP Options > > Author(s) : Joe Touch > > Filename : draft-ietf-tcpm-experimental-options-04.txt > > Pages : 9 > > Date : 2013-02-25 > > > > Abstract: > > This document describes how the experimental TCP option=20 > codepoints > > can concurrently support multiple TCP extensions, even=20 > within the > > same connection. It uses a new IANA TCP experiment=20 > identifier, and > > is also robust to experiments that are not registered=20 > and those that > > do not use this sharing mechanism. It is recommended=20 > for all new TCP > > options that use these codepoints. > > > > > > The IETF datatracker status page for this draft is: > >=20 > https://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-tcpm-experimental-options-04 > > > > A diff from the previous version is available at: > >=20 > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-experimental-options- > > 04 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > = From touch@isi.edu Tue Feb 26 10:47:56 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE3621F88BC for ; Tue, 26 Feb 2013 10:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.108 X-Spam-Level: X-Spam-Status: No, score=-105.108 tagged_above=-999 required=5 tests=[AWL=1.491, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5MmSWEbx6ck for ; Tue, 26 Feb 2013 10:47:56 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id EB71121F88B0 for ; Tue, 26 Feb 2013 10:47:55 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r1QIlDTP028385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Feb 2013 10:47:13 -0800 (PST) Message-ID: <512D0324.6010609@isi.edu> Date: Tue, 26 Feb 2013 10:47:00 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <20130225180826.23539.26542.idtracker@ietfa.amsl.com> <512BABD9.2020008@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6326@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6326@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 26 Feb 2013 18:47:57 -0000 On 2/26/2013 10:23 AM, Scharf, Michael (Michael) wrote: > Joe, > > As individual WG contributor, I wonder why the complexity of a 32bit > IANA registry is indeed needed. I clearly prefered variant (C)i in your > earlier e-mail to the TCPM list, i. e., a 16 bit registry only. I think > that this is simple and just enough. The document includes a registry based on the first 16-bits, but allows registrants to include the following 16 bits as well. The second 16-bits are included in the registry, but the registry should only ever have a max of 2**16 entries. > Maybe I should have stated more explicitly in my original e-mail why > a 16bit value without any magic number is enough - I assumed it was > clear from the context: Assuming that the IANA registry is indeed > used by most experimentors, wasting 2 bytes of scarce option space > for a magic number hardly seems reasonable. TCPM considered 32bit > when we assumed that there was no central registry, i. e., a higher > collision probability of randomly chosen magic numbers. This has > changed now given the planned use of an IANA registry. There are two reasons for designers using 32-bit values, even given an effectively 16-bit registry: 1) better protection against systems that don't use this extension There are already numerous deployments that use the TCP experimental options; a longer field reduces the probability of collisions. 2) results in identical alignment between the experimental option and a standards-track variant, if that transition occurs Yes, it consumes 2 extra bytes if used. However, it's optional. I don't see a good reason not to record those values as 32-bits in an IANA registry. > If the WG consensus was to stick to experiment IDs of either 16bit > or 32bit, I think that stronger guidance is needed in the document > regarding whether to select 32bit. Right now, the document says: > > The second two bytes serve as a "magic number". A magic number is a > self-selected codepoint whose primary value is its unlikely > collision with values selected by others. Magic numbers are used in > other protocols, e.g., BOOTP [RFC951] and DHCP [RFC2131]. The magic > number helps reduce the probability of a false positive collision > with those who either do not register their experiment or who do not > implement this mechanism. Using the additional magic number bytes > also helps the option contents have the same byte alignment in the > TCP header as they would have if (or when) a conventional (non- > experiment) TCP option codepoint is assigned. > > I think that the document should more clearly explain the downsides > of using 32bit ID including a magic number, i. e., the consumption of > TCP option space possibly preventing other TCP extensions. Sure; that's the only downside; I do already mention the upside. I can add that. > As a side note, I don't understand why byte alignment helps that > much - this only applies to a 32-bit CPU architecture, right? It certainly applies to 32-bit architectures (CPU, memory, etc.) and not 16-bit. I'd have to think about the relative impact to 64-bit. However, TCP data needs to begin on a 32-bit boundary. Using an experimental option with the same length modulo 4 (i.e., same relative byte offset length) means that the implementer would expect to interact with other options and/or padding in exactly the same way if the option transitions to standards-track. So this is more about "fewer surprises" when transitioning. It does eat 2 more bytes, but IMO no TCP option should be wedged in so tightly that 2 bytes matter. > Finally, I think that our objective is to encourage TCP > experimentors to really use the IANA registry, in order to avoid > collisions as much as possible. When I personally did my first TCP > experiments as student, I had no understanding of IANA processes etc. > While the current IANA consideration section in > draft-ietf-tcpm-experimental-options-04 may include the mandatory > formal information for experts, as a student I would not have > understood what this means to my TCP experiment. The current text is > written for experts only, imho. Yeah, I found that out when I got the comments from the IESG ;-) I need to take the advice of Sarris to Captain Taggert in Galaxy quest and revise that section. > I also wonder whether the IANA section could comment on the > possibility to deregister an experiment ID if the experimentor is > confident that the codepoint will not be used any more in the Internet. > At least if an experimentor has all endpoints under his control, this > seems doable. Yeah. I've also seen that it might be useful to convert some SHOULDs to MUSTs, even though we know they won't be followed. I'll gather these edits and revise. Joe > > Thanks > > Michael (again, all this e-mail is my individual opinion) > > >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >> Behalf Of Joe Touch >> Sent: Monday, February 25, 2013 7:22 PM >> To: internet-drafts@ietf.org >> Cc: tcpm@ietf.org; i-d-announce@ietf.org >> Subject: Re: [tcpm] I-D Action: >> draft-ietf-tcpm-experimental-options-04.txt >> >> Hi, all, >> >> This version provides the following updates: >> >> - changes the magic number to an experiment ID >> >> - uses a 16-bit registry with an optional 16-bit additional >> "magic number" to combine aspects of an IANA registry with >> the potential for additional protection by using a larger value >> >> - thus allows 16-bit or 32-bit values, but the first 16 bits >> are expected to be unique >> >> Joe >> >> On 2/25/2013 10:08 AM, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >>> This draft is a work item of the TCP Maintenance and >> Minor Extensions Working Group of the IETF. >>> >>> Title : Shared Use of Experimental TCP Options >>> Author(s) : Joe Touch >>> Filename : draft-ietf-tcpm-experimental-options-04.txt >>> Pages : 9 >>> Date : 2013-02-25 >>> >>> Abstract: >>> This document describes how the experimental TCP option >> codepoints >>> can concurrently support multiple TCP extensions, even >> within the >>> same connection. It uses a new IANA TCP experiment >> identifier, and >>> is also robust to experiments that are not registered >> and those that >>> do not use this sharing mechanism. It is recommended >> for all new TCP >>> options that use these codepoints. >>> >>> >>> The IETF datatracker status page for this draft is: >>> >> https://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-tcpm-experimental-options-04 >>> >>> A diff from the previous version is available at: >>> >> http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-experimental-options- >>> 04 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> From nanditad@google.com Tue Feb 26 10:58:00 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE84521F87CC for ; Tue, 26 Feb 2013 10:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wi5J0nRCI952 for ; Tue, 26 Feb 2013 10:57:59 -0800 (PST) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id E80AF21F8793 for ; Tue, 26 Feb 2013 10:57:58 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id o17so6034542oag.34 for ; Tue, 26 Feb 2013 10:57:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=jy7kyzXh43oRT7L8/B10uAlLegrE8DyoK44XEwOTznc=; b=nbDVhfCOW9ZA8JyR4MQwGi1tqMV9/s1gRc0XNY7+wETqVT+pY6Mr3EqOEwEVQ38QDP L7Y/tBsUADDu17PxgFc8it4lpR1EVytpEqUKtNvXZUIt8cHIEk8UswEz7N6VcYwzogue OlgoIZFHo/wp78jk8n1cu85szhBFBoMjlpojOhinqAVABYhCpLrbVzk+ADfWFSm2G/ji JWWjF3a1Q5+NS9/G7Ogn2559SMEitJyWev7PKZ9c1XJwZ5S3YK86vnQweSF9UDVYIoX9 nYE4tdnHSuLETdjm7kY60sottCs88uN1rkDfDT+lj4cE/eUGtP37OCjiv8rl4ACw6lZl WtVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=jy7kyzXh43oRT7L8/B10uAlLegrE8DyoK44XEwOTznc=; b=ZWjveyXXFREttIiyBBjYuavPx/vdCqioX64GARmPG+d/UhThQjC60nBQyx5rcrHHj6 ghJWMN2ZRiEnHmg7cKOfwfchnf8Z3lCfCv9zaaYHloukx6XLUzz8uWeurSPaFWS9FKv6 hJvhA777YmKNwutjv09R1iwh9cDLp52mU3j88QHvBfHMbT1fm/2LhI/HAVU7XJnrul4a n5fSmrZgznEbckwvKchtdwOjHm9T8rhCAP1ehbU72YN0FjjzrYiqbvv12XIjnUmpBMeC XJz64dz0k0uEXGNIEyJSsRi0QIbfKbAVzA9Vrq6LoGYf9UdfB5WlA2tTkTB0XdiuBykK Q+4A== MIME-Version: 1.0 X-Received: by 10.182.156.20 with SMTP id wa20mr12558471obb.59.1361905078495; Tue, 26 Feb 2013 10:57:58 -0800 (PST) Received: by 10.182.107.165 with HTTP; Tue, 26 Feb 2013 10:57:58 -0800 (PST) In-Reply-To: <20130225210433.11921.895.idtracker@ietfa.amsl.com> References: <20130225210433.11921.895.idtracker@ietfa.amsl.com> Date: Tue, 26 Feb 2013 10:57:58 -0800 Message-ID: From: Nandita Dukkipati To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=f46d0444ebbf6bfabc04d6a53ceb X-Gm-Message-State: ALoCoQnCXT8B81iL5Z1lN+0zVzt7CooojtzPh978m67qptJ96UOKptQZcFD/eMoDS078kXrbMgS6GCL8jiZIAIYOXJgNH6e+Ib0pPuRSNOSqGevbIEyiieHcpiENWMZHBI+Eo/Vu8AlP/HQKQFkkT3UADYR3GPTF2dEopUyztZ9nkkm4c3qvZ3jBbaq2j62L/+2Augmw1LR3 Subject: [tcpm] Fwd: New Version Notification for draft-dukkipati-tcpm-tcp-loss-probe-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 26 Feb 2013 18:58:00 -0000 --f46d0444ebbf6bfabc04d6a53ceb Content-Type: text/plain; charset=ISO-8859-1 Here is the -01 version of the Tail loss probe draft. Following is the main delta since -00 version: 1) Updated the Experiment section with our latest findings with the TLP loss detection algorithm. 2) A section on FACK based threshold recovery, which is critical for TLP to work. 3) Several minor edits, including many points brought up tcpm members: ** Clarified on why PTO is 2.RTT (and not RTT, 3.RTT...). ** TCP Loss Probe -> Tail Loss Probe. ** Clarified why we used 1 probe (versus multiple probes) per tail loss episode. ** Referenced "rescue retransmission" introduced in RFC6675 and a discussion on why that doesn't solve the tail loss problem. ** Why we decided against 1-byte retransmission. ** Relation to RTO-restart. Happy reading! Nandita ---------- Forwarded message ---------- From: Date: Mon, Feb 25, 2013 at 1:04 PM Subject: New Version Notification for draft-dukkipati-tcpm-tcp-loss-probe-01.txt To: nanditad@google.com Cc: ncardwell@google.com, ycheng@google.com, mattmathis@google.com A new version of I-D, draft-dukkipati-tcpm-tcp-loss-probe-01.txt has been successfully submitted by Nandita Dukkipati and posted to the IETF repository. Filename: draft-dukkipati-tcpm-tcp-loss-probe Revision: 01 Title: Tail Loss Probe (TLP): An Algorithm for Fast Recovery of Tail Losses Creation date: 2013-02-25 Group: Individual Submission Number of pages: 20 URL: http://www.ietf.org/internet-drafts/draft-dukkipati-tcpm-tcp-loss-probe-01.txt Status: http://datatracker.ietf.org/doc/draft-dukkipati-tcpm-tcp-loss-probe Htmlized: http://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-dukkipati-tcpm-tcp-loss-probe-01 Abstract: Retransmission timeouts are detrimental to application latency, especially for short transfers such as Web transactions where timeouts can often take longer than all of the rest of a transaction. The primary cause of retransmission timeouts are lost segments at the tail of transactions. This document describes an experimental algorithm for TCP to quickly recover lost segments at the end of transactions or when an entire window of data or acknowledgments are lost. Tail Loss Probe (TLP) is a sender-only algorithm that allows the transport to recover tail losses through fast recovery as opposed to lengthy retransmission timeouts. If a connection is not receiving any acknowledgments for a certain period of time, TLP transmits the last unacknowledged segment (loss probe). In the event of a tail loss in the original transmissions, the acknowledgment from the loss probe triggers SACK/FACK based fast recovery. TLP effectively avoids long timeouts and thereby improves TCP performance. The IETF Secretariat --f46d0444ebbf6bfabc04d6a53ceb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Here is the -01 version of the Tail loss probe draft. Foll= owing is the main delta since -00 version:

1) Updated the Experiment sect= ion with our latest findings with the TLP loss detection algorithm.<= /div>
2) A= section on FACK based threshold recovery, which is critical for TLP to wor= k.
3) Several minor edits, including many points brought up tcpm me= mbers:
=A0 = =A0 ** Clarified on why PTO is 2.RTT (and not RTT, 3.RTT...).
=A0 =A0 ** TCP Loss Prob= e -> Tail Loss Probe.
=A0 =A0 ** Clari= fied why we used 1 probe (versus multiple probes) per tail loss episode.
=A0 =A0 *= * Referenced "rescue retransmission" introduced in RFC6675 and a = discussion on why that doesn't solve the tail loss problem.
=A0 =A0 ** Why w= e decided against 1-byte retransmission.
=A0 =A0 ** Relation to RTO-restart.

Happy = reading!
Na= ndita=A0

---------- Forwarded message ----------=
From: <internet-drafts@ietf.org>
Date: Mon, Feb 25, 2013 at 1:04 PM
Subject: New Version Notification for= draft-dukkipati-tcpm-tcp-loss-probe-01.txt
To: nanditad@google.com
Cc: ncardwell@google.com, y= cheng@google.com, mattmathis@g= oogle.com



A new version of I-D, draft-dukkipati-tcpm-tcp-loss-probe-01.txt
has been successfully submitted by Nandita Dukkipati and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-dukkipati-tcpm-tcp-loss-probe
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 Tail Loss Probe (TLP): An Algorithm for Fast Rec= overy of Tail Losses
Creation date: =A0 2013-02-25
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 20
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.i= etf.org/internet-drafts/draft-dukkipati-tcpm-tcp-loss-probe-01.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.o= rg/doc/draft-dukkipati-tcpm-tcp-loss-probe
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/dr= aft-dukkipati-tcpm-tcp-loss-probe-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.o= rg/rfcdiff?url2=3Ddraft-dukkipati-tcpm-tcp-loss-probe-01

Abstract:
=A0 =A0Retransmission timeouts are detrimental to application latency,
=A0 =A0especially for short transfers such as Web transactions where
=A0 =A0timeouts can often take longer than all of the rest of a transaction= .
=A0 =A0The primary cause of retransmission timeouts are lost segments at th= e
=A0 =A0tail of transactions. =A0This document describes an experimental
=A0 =A0algorithm for TCP to quickly recover lost segments at the end of
=A0 =A0transactions or when an entire window of data or acknowledgments are=
=A0 =A0lost. =A0Tail Loss Probe (TLP) is a sender-only algorithm that allow= s
=A0 =A0the transport to recover tail losses through fast recovery as oppose= d
=A0 =A0to lengthy retransmission timeouts. =A0If a connection is not receiv= ing
=A0 =A0any acknowledgments for a certain period of time, TLP transmits the<= br> =A0 =A0last unacknowledged segment (loss probe). =A0In the event of a tail<= br> =A0 =A0loss in the original transmissions, the acknowledgment from the loss=
=A0 =A0probe triggers SACK/FACK based fast recovery. =A0TLP effectively avo= ids
=A0 =A0long timeouts and thereby improves TCP performance.




The IETF Secretariat


--f46d0444ebbf6bfabc04d6a53ceb-- From michael.scharf@alcatel-lucent.com Tue Feb 26 11:38:53 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B63821F8951 for ; Tue, 26 Feb 2013 11:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.462 X-Spam-Level: X-Spam-Status: No, score=-7.462 tagged_above=-999 required=5 tests=[AWL=-1.212, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uk8djJj9z-Yd for ; Tue, 26 Feb 2013 11:38:52 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6841821F8821 for ; Tue, 26 Feb 2013 11:38:52 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1QJcnAQ007411 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 26 Feb 2013 20:38:49 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 26 Feb 2013 20:38:49 +0100 From: "Scharf, Michael (Michael)" To: Joe Touch Date: Tue, 26 Feb 2013 20:38:48 +0100 Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-04.txt Thread-Index: Ac4UUcw2tpTGPsa5T16vbVAOIHz8nQABEYKw Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D632A@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <20130225180826.23539.26542.idtracker@ietfa.amsl.com> <512BABD9.2020008@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6326@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <512D0324.6010609@isi.edu> In-Reply-To: <512D0324.6010609@isi.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 26 Feb 2013 19:38:53 -0000 > > Maybe I should have stated more explicitly in my original=20 > e-mail why a=20 > > 16bit value without any magic number is enough - I assumed it was=20 > > clear from the context: Assuming that the IANA registry is=20 > indeed used=20 > > by most experimentors, wasting 2 bytes of scarce option space for a=20 > > magic number hardly seems reasonable. TCPM considered 32bit when we=20 > > assumed that there was no central registry, i. e., a higher=20 > collision=20 > > probability of randomly chosen magic numbers. This has changed now=20 > > given the planned use of an IANA registry. >=20 > There are two reasons for designers using 32-bit values, even=20 > given an effectively 16-bit registry: >=20 > 1) better protection against systems that don't use this extension >=20 > There are already numerous deployments that use the TCP=20 > experimental options; a longer field reduces the probability=20 > of collisions. >=20 > 2) results in identical alignment between the experimental=20 > option and a standards-track variant, if that transition occurs >=20 > Yes, it consumes 2 extra bytes if used. However, it's=20 > optional. I don't see a good reason not to record those=20 > values as 32-bits in an IANA registry. Apart from the fact that the IANA registry gets more complicated to underst= and. If there is strong desire in TCPM for 32bit registry (I won't argue in= favor of that), I think we should use one of the suggested ways to split t= he codepoint space, to make clear what a codepoint is about. (But, as noted= in your original e-mail, they are not really elegant.) > > As a side note, I don't understand why byte alignment helps=20 > that much=20 > > - this only applies to a 32-bit CPU architecture, right? >=20 > It certainly applies to 32-bit architectures (CPU, memory,=20 > etc.) and not 16-bit. I'd have to think about the relative=20 > impact to 64-bit. >=20 > However, TCP data needs to begin on a 32-bit boundary. Using=20 > an experimental option with the same length modulo 4 (i.e.,=20 > same relative byte offset length) means that the implementer=20 > would expect to interact with other options and/or padding in=20 > exactly the same way if the option transitions to standards-track. Some TCP stacks indeed optimize 32-bit boundaries for production deployment= s. But all research experiments with TCP options I did myself, 32-bit alignmen= t was the least thing I cared about. I just parsed the given "struct" defin= ing the option header. But, sure, other experiments may have other needs. =20 Michael From touch@isi.edu Tue Feb 26 11:47:22 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B1421F882E for ; Tue, 26 Feb 2013 11:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.158 X-Spam-Level: X-Spam-Status: No, score=-103.158 tagged_above=-999 required=5 tests=[AWL=-0.559, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xT+lYUjBWtrJ for ; Tue, 26 Feb 2013 11:47:16 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id A3D7F21F8A04 for ; Tue, 26 Feb 2013 11:47:16 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r1QJkbdS029993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Feb 2013 11:46:37 -0800 (PST) Message-ID: <512D1110.9090407@isi.edu> Date: Tue, 26 Feb 2013 11:46:24 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <20130225180826.23539.26542.idtracker@ietfa.amsl.com> <512BABD9.2020008@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6326@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <512D0324.6010609@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D632A@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D632A@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 26 Feb 2013 19:47:22 -0000 On 2/26/2013 11:38 AM, Scharf, Michael (Michael) wrote: >>> Maybe I should have stated more explicitly in my original >> e-mail why a >>> 16bit value without any magic number is enough - I assumed it was >>> clear from the context: Assuming that the IANA registry is >> indeed used >>> by most experimentors, wasting 2 bytes of scarce option space for a >>> magic number hardly seems reasonable. TCPM considered 32bit when we >>> assumed that there was no central registry, i. e., a higher >> collision >>> probability of randomly chosen magic numbers. This has changed now >>> given the planned use of an IANA registry. >> >> There are two reasons for designers using 32-bit values, even >> given an effectively 16-bit registry: >> >> 1) better protection against systems that don't use this extension >> >> There are already numerous deployments that use the TCP >> experimental options; a longer field reduces the probability >> of collisions. >> >> 2) results in identical alignment between the experimental >> option and a standards-track variant, if that transition occurs >> >> Yes, it consumes 2 extra bytes if used. However, it's >> optional. I don't see a good reason not to record those >> values as 32-bits in an IANA registry. > > Apart from the fact that the IANA registry gets more complicated to > understand. If there is strong desire in TCPM for 32bit registry (I > won't argue in favor of that), I think we should use one of the > suggested ways to split the codepoint space, to make clear what a > codepoint is about. (But, as noted in your original e-mail, they are not > really elegant.) IMO, 16-bits is sufficient as a registration - it's still enough for ports. AFAICT 32-bits is needed only to increase protection, or if the entire space is "magic". >>> As a side note, I don't understand why byte alignment helps >> that much >>> - this only applies to a 32-bit CPU architecture, right? >> >> It certainly applies to 32-bit architectures (CPU, memory, >> etc.) and not 16-bit. I'd have to think about the relative >> impact to 64-bit. >> >> However, TCP data needs to begin on a 32-bit boundary. Using >> an experimental option with the same length modulo 4 (i.e., >> same relative byte offset length) means that the implementer >> would expect to interact with other options and/or padding in >> exactly the same way if the option transitions to standards-track. > > Some TCP stacks indeed optimize 32-bit boundaries for production deployments. > > But all research experiments with TCP options I did myself, 32-bit > alignment was the least thing I cared about. I just parsed the given > "struct" defining the option header. But, sure, other experiments may > have other needs. Sure - and you can use 16 bits. There are two reasons for the additional two, and neither one is always necessary. Joe From michael.scharf@alcatel-lucent.com Wed Feb 27 01:12:30 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A050921F85DC for ; Wed, 27 Feb 2013 01:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.39 X-Spam-Level: X-Spam-Status: No, score=-9.39 tagged_above=-999 required=5 tests=[AWL=0.859, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w13+VxOdSuLS for ; Wed, 27 Feb 2013 01:12:29 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id D88E821F85C0 for ; Wed, 27 Feb 2013 01:12:27 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1R9Bugm022652 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 27 Feb 2013 10:12:21 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 27 Feb 2013 10:12:19 +0100 From: "Scharf, Michael (Michael)" To: "Mahdavi, Jamshid" Date: Wed, 27 Feb 2013 10:12:17 +0100 Thread-Topic: draft-ietf-tcpm-experimental-options Thread-Index: Ac4RN3UDu/G7H2JITH6LXAHQ4WqGxgDkdx5g Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D633E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Feb 2013 09:12:30 -0000 Jamshid,=20 > I have reviewed this proposed draft. I don't believe that=20 > commercial vendors who have TCP option needs would view this=20 > as changing the current landscape at all. If your intent is=20 > to provide a new alternative that "cooperating protocol=20 > designers" could use, in my opinion this is not meeting the need. We've always explicitly stated that the existing process for getting a dedi= cated TCP option codepoint does not change. Personally, I think that this should be the prefered solution, e. g., becau= se it doesn't waste TCP SYN bytes. But an IANA-assigned codepoint indeed requires some "cooperation" of the pr= otocol designer with the IETF (and preferably TCPM). Michael From michael.scharf@alcatel-lucent.com Wed Feb 27 01:49:19 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E4D21F8489 for ; Wed, 27 Feb 2013 01:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.138 X-Spam-Level: X-Spam-Status: No, score=-9.138 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CkZj1HkV0hZ for ; Wed, 27 Feb 2013 01:49:19 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id BC71521F845A for ; Wed, 27 Feb 2013 01:49:18 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1R9nEix007278 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 27 Feb 2013 10:49:16 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 27 Feb 2013 10:49:16 +0100 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Date: Wed, 27 Feb 2013 10:49:15 +0100 Thread-Topic: TCPM draft agenda for IETF 86 Thread-Index: Ac4Uz7Pxp1lXV2ruQLGOojiGEGu02w== Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6341@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: [tcpm] TCPM draft agenda for IETF 86 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 27 Feb 2013 09:49:19 -0000 Dear all, The first draft of the agenda for the Orlando meeting can be found at http:= //www.ietf.org/proceedings/86/agenda/agenda-86-tcpm and is also copied belo= w. The chairs have approved all presentation requests we have received so far.= Given past complaints about lack of discussion time in TCPM, we explicitly= allocated time for interactive discussion. The presenters are asked to tak= e this into account as a guideline when preparing the meeting. We will probably have some time left at the end of the meeting. Please let = us know if there are suggested changes. Happy agenda bashing! Michael TCP Maintenance and Minor Extensions IETF 86, Orlando, FL, USA Tuesday, March 12, 2013 Morning Session I+II, 0900-11:30 ***************************************************************************= * WG Status --------- 9:00 Title: Agenda and WG status Presenter: Chairs Presentation/Discussion: 10min WG items -------- 9:10 Title: TCP Extensions for High Performance=09 Draft: draft-ietf-tcpm-1323bis-06 Presenter: Richard Scheffenegger Presentation: 5min Discussion: 5min 9:20 Title: Updating TCP to support Rate-Limited Traffic Draft: draft-ietf-tcpm-newcwv-00 Presenter: Gorry Fairhurst Presentation: 10min Discussion: 10min 9:40 Title: TCP Fast Open Draft: draft-ietf-tcpm-fastopen-02 Presenter: Yuchung Cheng Presentation: 10min Discussion: 10min 10:00 Title: Problem Statement and Requirements for a More Accurate ECN Feedback Draft: draft-ietf-tcpm-accecn-reqs-00 Presenter: Richard Scheffenegger Presentation: 5min Discussion: 10min Individual submissions ---------------------- 10:15 Title: On the Validation of TCP Sequence Numbers Draft: draft-gont-tcpm-tcp-seq-validation-00 Presenter: Fernando Gont Presentation: 10min Discussion: 10min 10:35 Title: Tail loss probe (TLP) Draft: draft-dukkipati-tcpm-tcp-loss-probe-01 Presenter: Nandita Dukkipati (or coauthor) =20 Presentation: 10min Discussion: 10min From pasi.sarolahti@iki.fi Thu Feb 28 05:07:31 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6867521F857A for ; Thu, 28 Feb 2013 05:07:31 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIUCzKKI6igT for ; Thu, 28 Feb 2013 05:07:29 -0800 (PST) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id ECE9221F85CC for ; Thu, 28 Feb 2013 05:07:28 -0800 (PST) Received: from pc118.netlab.hut.fi (130.233.154.118) by jenni1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 508712A00812FAA6 for tcpm@ietf.org; Thu, 28 Feb 2013 15:07:27 +0200 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Feb 2013 15:07:25 +0200 Message-Id: <8EF31D84-3241-48D0-95C3-141374AA3311@iki.fi> To: tcpm Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [tcpm] TCPM working group status X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2013 13:07:31 -0000 Hi, Here is our understanding of the current working group status. Please = let us know if there are corrections or something is missing. Thanks! - Pasi, Michael and Yoshifumi Recent RFCs ----------- Conservative SACK-based Recovery Algorithm / RFC 3517bis (draft-ietf-tcpm-3517bis) * Milestone Target: Proposed Standard in October 2010 * Status: RFC 6675 (August 2012) WG Items Nearing RFC Publication -------------------------------- Increasing the Initial Window (draft-ietf-tcpm-initcwnd) * Milestone Target: Experimental in September 2011 * Status: Revised on Feb 22 to address IESG discusses * Action: IESG to re-review Proportional Rate Reduction for TCP (draft-ietf-tcpm-proportional-rate-reduction) * Milestone Target: Experimental in May 2012 * Status: Draft was updated on Feb to address AD comments, IETF Last = Call ended Feb 26 * Action: IESG review=20 Shared Use of Experimental TCP Options (draft-ietf-tcpm-experimental-options) * Milestone Target: PS in Sept. 2012 * Status: Draft was updated on Feb 25 to address IESG discusses * Action: IESG to re-review Active WG Items --------------- TCP Extensions for High Performance (draft-ietf-tcpm-1323bis) * Milestone Target: Proposed Standard in July 2009 * Status: Recently updated, waiting for reviews from WG * Action: WG to review the draft=20 TCP Fast Open (draft-ietf-tcpm-fastopen) * Milestone Target: Experimental in Sept. 2012 * Status: Recently updated * Action: Needs WG review Problem Statement and Requirements for a More Accurate ECN Feedback (draft-kuehlewind-tcpm-accecn-reqs) * Status: Became WG draft, earlier name = draft-kuehlewind-tcpm-accecn-reqs TCP and SCTP RTO Restart (draft-ietf-tcpm-rtorestart) * Status: Became WG draft, previous name draft-hurtig-tcpm-rtorestart Updating TCP to support Variable-Rate Traffic (draft-ietf-tcpm-newcwv) * Status: Became WG draft, previous name draft-fairhurst-tcpm-newcwv * Action: To be discussed at IETF-86, intended status yet undecided Active Individual Internet-Drafts --------------------------------- Additional negotiation in the TCP Timestamp Option field during the TCP = handshake (draft-scheffenegger-tcpm-timestamp-negotiation) * Status: Not recently updated Exposure of Time Intervals for the TCP Timestamp Option (draft-trammell-tcpm-timestamp-interval) * Status: Not recently updated TCP Loss Probe (TLP): An Algorithm for Fast Recovery of Tail Losses (draft-dukkipati-tcpm-tcp-loss-probe) * Status: Updated prior to IETF-86 On the Validation of TCP Sequence Numbers (draft-gont-tcpm-tcp-seq-validation) * Status: New draft, Feb 2013 From kevin.lahey@oracle.com Thu Feb 28 08:56:08 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66DFA21F8771 for ; Thu, 28 Feb 2013 08:56:08 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30vGPd1FMYqJ for ; Thu, 28 Feb 2013 08:56:01 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4B17421F86B8 for ; Thu, 28 Feb 2013 08:56:00 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1SGtxwA006993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 28 Feb 2013 16:55:59 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1SGtw6H022858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 28 Feb 2013 16:55:58 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1SGtwna011233 for ; Thu, 28 Feb 2013 10:55:58 -0600 Received: from [10.0.0.4] (/24.23.239.182) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Feb 2013 08:55:57 -0800 From: Kevin Lahey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Feb 2013 08:55:54 -0800 Message-Id: <68F2142A-FE1A-4FE0-95C7-3717D90A3B92@oracle.com> To: tcpm@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: [tcpm] draft-ietf-tcpm-experimental-options-04 nit X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2013 16:56:08 -0000 Reading draft-ietf-tcpm-experimental-options-04, I was curious about the = following provisions: The ExID mechanism must be coordinated during connection establishment, just as with any TCP option. >> TCP ExID, if used in any TCP segment of a connection, MUST be present in TCP SYN segments of that connection. >> TCP experimental option ExIDS, if used in any TCP segment of a connection, SHOULD be used in all TCP segments of that connection in which any experimental option is present. Am I being too lawyerly, or would this prevent something like = SACK-Permitted where a different option is sent on SYN segments than is = sent with every other segment? I presume that SACK-Permitted was an = attempt to avoid stressing the options processing code then deployed, = but I've seen more recent suggestions for an "I implement window shift, = timestamps, SACK, and perhaps other options" option to save space. Kevin kevin.lahey@oracle.com From kevin.lahey@oracle.com Thu Feb 28 09:03:12 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F8521F8835 for ; Thu, 28 Feb 2013 09:03:12 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVbRxvcYDa4h for ; Thu, 28 Feb 2013 09:03:11 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 93EB621F884F for ; Thu, 28 Feb 2013 09:03:11 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1SH3A4i006664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 28 Feb 2013 17:03:11 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1SH390B026150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 28 Feb 2013 17:03:10 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1SH39J0017912 for ; Thu, 28 Feb 2013 11:03:09 -0600 Received: from [10.0.0.4] (/24.23.239.182) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Feb 2013 09:03:09 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Kevin Lahey In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D633E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Date: Thu, 28 Feb 2013 09:03:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <16EF3923-04A3-44AF-B52B-4BD910104A98@oracle.com> References: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D633E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> To: tcpm@ietf.org X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: Re: [tcpm] draft-ietf-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2013 17:03:12 -0000 On Feb 27, 2013, at 1:12 AM, Scharf, Michael (Michael) wrote: > We've always explicitly stated that the existing process for getting a = dedicated TCP option codepoint does not change. >=20 > Personally, I think that this should be the prefered solution, e. g., = because it doesn't waste TCP SYN bytes. I have no objection to the publication of this document (aside from a = nit that I sent in a different message), but it does seem like we're = optimizing the wrong value. We have only 40 octets of TCP option space = on a SYN, and we've seen proposals that are pushing up against that. We = have used something like 35 of the available TCP option values in the 32 = years since RFC 793 was published, and it doesn't seem like there will = be a big run on TCP options in the near future. Yet here we're burning = precious option space to save option values. I'd really prefer that we loosen our standards for assigning TCP = options. Given a choice between even reasonably responsible parties[*] = squatting on values or passing out a few more options and documenting = the use, I'll take the documentation. Kevin kevin.lahey@oracle.com From andrew.knutsen@bluecoat.com Thu Feb 28 11:47:06 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8FB21F8771 for ; Thu, 28 Feb 2013 11:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yS4WWkjp1lj for ; Thu, 28 Feb 2013 11:47:05 -0800 (PST) Received: from synonym.bluecoat.com (synonym.bluecoat.com [199.91.133.5]) by ietfa.amsl.com (Postfix) with ESMTP id 652FB21F86BE for ; Thu, 28 Feb 2013 11:47:05 -0800 (PST) Received: from [10.9.43.135] (unknown [10.9.43.135]) by synonym.bluecoat.com (Postfix) with ESMTP id 2BFBD7FE1D1 for ; Thu, 28 Feb 2013 11:47:05 -0800 (PST) Message-ID: <512FB43A.7050505@bluecoat.com> Date: Thu, 28 Feb 2013 11:47:06 -0800 From: Andrew Knutsen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: tcpm@ietf.org References: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D633E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <16EF3923-04A3-44AF-B52B-4BD910104A98@oracle.com> In-Reply-To: <16EF3923-04A3-44AF-B52B-4BD910104A98@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] draft-ietf-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2013 19:47:07 -0000 Hear, hear! Andrew On 2/28/2013 9:03 AM, Kevin Lahey wrote: > On Feb 27, 2013, at 1:12 AM, Scharf, Michael (Michael) wrote: > >> We've always explicitly stated that the existing process for getting a dedicated TCP option codepoint does not change. >> >> Personally, I think that this should be the prefered solution, e. g., because it doesn't waste TCP SYN bytes. > I have no objection to the publication of this document (aside from a nit that I sent in a different message), but it does seem like we're optimizing the wrong value. We have only 40 octets of TCP option space on a SYN, and we've seen proposals that are pushing up against that. We have used something like 35 of the available TCP option values in the 32 years since RFC 793 was published, and it doesn't seem like there will be a big run on TCP options in the near future. Yet here we're burning precious option space to save option values. > > I'd really prefer that we loosen our standards for assigning TCP options. Given a choice between even reasonably responsible parties[*] squatting on values or passing out a few more options and documenting the use, I'll take the documentation. > > Kevin > kevin.lahey@oracle.com > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Thu Feb 28 12:54:11 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0366E21F89D3 for ; Thu, 28 Feb 2013 12:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.144 X-Spam-Level: X-Spam-Status: No, score=-103.144 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vw6noiPY266d for ; Thu, 28 Feb 2013 12:54:10 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id BB61321F8901 for ; Thu, 28 Feb 2013 12:54:09 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r1SKrSLL027216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Feb 2013 12:53:30 -0800 (PST) Message-ID: <512FC3B9.80408@isi.edu> Date: Thu, 28 Feb 2013 12:53:13 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Andrew Knutsen References: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D633E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <16EF3923-04A3-44AF-B52B-4BD910104A98@oracle.com> <512FB43A.7050505@bluecoat.com> In-Reply-To: <512FB43A.7050505@bluecoat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2013 20:54:11 -0000 Hi, all, The bar for TCP options is passing a standards-track RFC. That's the same bar as for many other limited resources, including system TCP and UDP ports. Some of the current squatters fall into the following categories: - in the process of developing a standards-track option, some parties were impatient and disagreed with the process, and squatted on the experimental ports (for TCP-AO precursors) - some parties want to develop extensions that they explicitly don't want to participate in the IETF process (tcp-ct) - some parties developed a prototype that squatted on numbers before they even brought it to the IETF; when they did, there were concerns with the approach expressed (tcp-crypt) So, FWIW, "lowering the bar" to issuing option numbers means TCPM accepting: a) multiple competing standards in early development stages b) proposals that don't even want to be vetted by the WG c) proposals that the WG has already expressed concerns about In part, the bar could be lowered by the WG being more accepting of proposals, but even then is it appropriate to burn multiple codepoints on one option? Or to allow standards based on non-WG drafts (how does that occur?) or to assign codepoints to competing standards while under active WG debate? There's no easy solution here, but it's clear that there's no way to "lower the bar" that is compatible with IETF processes AFAICT. Joe On 2/28/2013 11:47 AM, Andrew Knutsen wrote: > > Hear, hear! > > Andrew > > On 2/28/2013 9:03 AM, Kevin Lahey wrote: >> On Feb 27, 2013, at 1:12 AM, Scharf, Michael (Michael) wrote: >> >>> We've always explicitly stated that the existing process for getting >>> a dedicated TCP option codepoint does not change. >>> >>> Personally, I think that this should be the prefered solution, e. g., >>> because it doesn't waste TCP SYN bytes. >> I have no objection to the publication of this document (aside from a >> nit that I sent in a different message), but it does seem like we're >> optimizing the wrong value. We have only 40 octets of TCP option >> space on a SYN, and we've seen proposals that are pushing up against >> that. We have used something like 35 of the available TCP option >> values in the 32 years since RFC 793 was published, and it doesn't >> seem like there will be a big run on TCP options in the near future. >> Yet here we're burning precious option space to save option values. >> >> I'd really prefer that we loosen our standards for assigning TCP >> options. Given a choice between even reasonably responsible >> parties[*] squatting on values or passing out a few more options and >> documenting the use, I'll take the documentation. >> >> Kevin >> kevin.lahey@oracle.com >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From michael.scharf@alcatel-lucent.com Thu Feb 28 15:05:55 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F96221F8A09 for ; Thu, 28 Feb 2013 15:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.465 X-Spam-Level: X-Spam-Status: No, score=-9.465 tagged_above=-999 required=5 tests=[AWL=0.784, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DizESV14Q0pP for ; Thu, 28 Feb 2013 15:05:54 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF7421F85B1 for ; Thu, 28 Feb 2013 15:05:53 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1SN5mLI026636 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 1 Mar 2013 00:05:48 +0100 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 1 Mar 2013 00:05:48 +0100 From: "Scharf, Michael (Michael)" To: Joe Touch , Andrew Knutsen Date: Fri, 1 Mar 2013 00:05:47 +0100 Thread-Topic: [tcpm] draft-ietf-tcpm-experimental-options Thread-Index: Ac4V9cZ/XroWFf2JS9aRhcZTYj56DQADlgfW Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F4@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D633E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <16EF3923-04A3-44AF-B52B-4BD910104A98@oracle.com> <512FB43A.7050505@bluecoat.com>,<512FC3B9.80408@isi.edu> In-Reply-To: <512FC3B9.80408@isi.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2013 23:05:55 -0000 I think that the bar is actually a little bit lower. For instance, the IETF= allocated in the last years codepoints to experimental protocols as well (= Quick-Start, MPTCP). Also, TCPM currently has one active working group draf= t that asks for assignment of a dedicated option number. I do believe that we have enough remaining TCP option codepoints so that im= plementors of Internet-scale TCP extensions can get dedicated codepoints. B= ut obviously not bypassing the IETF process. Michael ________________________________________ Von: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] im Auftrag von Joe Touch= [touch@isi.edu] Gesendet: Donnerstag, 28. Februar 2013 21:53 An: Andrew Knutsen Cc: tcpm@ietf.org Betreff: Re: [tcpm] draft-ietf-tcpm-experimental-options Hi, all, The bar for TCP options is passing a standards-track RFC. That's the same bar as for many other limited resources, including system TCP and UDP ports. Some of the current squatters fall into the following categories: - in the process of developing a standards-track option, some parties were impatient and disagreed with the process, and squatted on the experimental ports (for TCP-AO precursors) - some parties want to develop extensions that they explicitly don't want to participate in the IETF process (tcp-ct) - some parties developed a prototype that squatted on numbers before they even brought it to the IETF; when they did, there were concerns with the approach expressed (tcp-crypt) So, FWIW, "lowering the bar" to issuing option numbers means TCPM accepting= : a) multiple competing standards in early development stages b) proposals that don't even want to be vetted by the WG c) proposals that the WG has already expressed concerns about In part, the bar could be lowered by the WG being more accepting of proposals, but even then is it appropriate to burn multiple codepoints on one option? Or to allow standards based on non-WG drafts (how does that occur?) or to assign codepoints to competing standards while under active WG debate? There's no easy solution here, but it's clear that there's no way to "lower the bar" that is compatible with IETF processes AFAICT. Joe On 2/28/2013 11:47 AM, Andrew Knutsen wrote: > > Hear, hear! > > Andrew > > On 2/28/2013 9:03 AM, Kevin Lahey wrote: >> On Feb 27, 2013, at 1:12 AM, Scharf, Michael (Michael) wrote: >> >>> We've always explicitly stated that the existing process for getting >>> a dedicated TCP option codepoint does not change. >>> >>> Personally, I think that this should be the prefered solution, e. g., >>> because it doesn't waste TCP SYN bytes. >> I have no objection to the publication of this document (aside from a >> nit that I sent in a different message), but it does seem like we're >> optimizing the wrong value. We have only 40 octets of TCP option >> space on a SYN, and we've seen proposals that are pushing up against >> that. We have used something like 35 of the available TCP option >> values in the 32 years since RFC 793 was published, and it doesn't >> seem like there will be a big run on TCP options in the near future. >> Yet here we're burning precious option space to save option values. >> >> I'd really prefer that we loosen our standards for assigning TCP >> options. Given a choice between even reasonably responsible >> parties[*] squatting on values or passing out a few more options and >> documenting the use, I'll take the documentation. >> >> Kevin >> kevin.lahey@oracle.com >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From andrew.knutsen@bluecoat.com Thu Feb 28 15:06:29 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7013C21F8A5E for ; Thu, 28 Feb 2013 15:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7-ghuKoHVEc for ; Thu, 28 Feb 2013 15:06:28 -0800 (PST) Received: from synonym.bluecoat.com (synonym.bluecoat.com [199.91.133.5]) by ietfa.amsl.com (Postfix) with ESMTP id D340321F85B1 for ; Thu, 28 Feb 2013 15:06:28 -0800 (PST) Received: from [10.9.43.135] (unknown [10.9.43.135]) by synonym.bluecoat.com (Postfix) with ESMTP id 9256F7FE1A5; Thu, 28 Feb 2013 15:06:28 -0800 (PST) Message-ID: <512FE2F4.90202@bluecoat.com> Date: Thu, 28 Feb 2013 15:06:28 -0800 From: Andrew Knutsen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Joe Touch References: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D633E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <16EF3923-04A3-44AF-B52B-4BD910104A98@oracle.com> <512FB43A.7050505@bluecoat.com> <512FC3B9.80408@isi.edu> In-Reply-To: <512FC3B9.80408@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2013 23:06:29 -0000 The problems arise when "IETF processes" cause longstanding problems in the field. A bit analogous to what's going on in Congress today, it seems to me. Several of the largest "squatters" (widely deployed, multivendor technology, none listed below) tried to get "over the bar" a couple years ago, and found it unreasonably high. So, we're all still squatting (and shipping lots of units ;-). To repeat Kevin's point again, so it doesn't get lost in the verbiage: TCP option *size* seems to be a more limited resource than the "kinds"/codepoints. This is the *Engineering* task force; we should be making *engineering* decisions. Trading off one resource for another is a classic engineering decision. Andrew PS Yes this is a sore point for me. AK On 2/28/2013 12:53 PM, Joe Touch wrote: > Hi, all, > > The bar for TCP options is passing a standards-track RFC. That's the > same bar as for many other limited resources, including system TCP and > UDP ports. > > Some of the current squatters fall into the following categories: > > - in the process of developing a standards-track option, > some parties were impatient and disagreed with the process, > and squatted on the experimental ports (for TCP-AO precursors) > > - some parties want to develop extensions that they explicitly > don't want to participate in the IETF process (tcp-ct) > > - some parties developed a prototype that squatted on > numbers before they even brought it to the IETF; when they did, > there were concerns with the approach expressed > (tcp-crypt) > > So, FWIW, "lowering the bar" to issuing option numbers means TCPM > accepting: > a) multiple competing standards in early development stages > b) proposals that don't even want to be vetted by the WG > c) proposals that the WG has already expressed concerns about > > In part, the bar could be lowered by the WG being more accepting of > proposals, but even then is it appropriate to burn multiple codepoints > on one option? Or to allow standards based on non-WG drafts (how does > that occur?) or to assign codepoints to competing standards while > under active WG debate? > > There's no easy solution here, but it's clear that there's no way to > "lower the bar" that is compatible with IETF processes AFAICT. > > Joe > > > > On 2/28/2013 11:47 AM, Andrew Knutsen wrote: >> >> Hear, hear! >> >> Andrew >> >> On 2/28/2013 9:03 AM, Kevin Lahey wrote: >>> On Feb 27, 2013, at 1:12 AM, Scharf, Michael (Michael) wrote: >>> >>>> We've always explicitly stated that the existing process for getting >>>> a dedicated TCP option codepoint does not change. >>>> >>>> Personally, I think that this should be the prefered solution, e. g., >>>> because it doesn't waste TCP SYN bytes. >>> I have no objection to the publication of this document (aside from a >>> nit that I sent in a different message), but it does seem like we're >>> optimizing the wrong value. We have only 40 octets of TCP option >>> space on a SYN, and we've seen proposals that are pushing up against >>> that. We have used something like 35 of the available TCP option >>> values in the 32 years since RFC 793 was published, and it doesn't >>> seem like there will be a big run on TCP options in the near future. >>> Yet here we're burning precious option space to save option values. >>> >>> I'd really prefer that we loosen our standards for assigning TCP >>> options. Given a choice between even reasonably responsible >>> parties[*] squatting on values or passing out a few more options and >>> documenting the use, I'll take the documentation. >>> >>> Kevin >>> kevin.lahey@oracle.com >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Thu Feb 28 15:16:58 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E2521F8700 for ; Thu, 28 Feb 2013 15:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.124 X-Spam-Level: X-Spam-Status: No, score=-105.124 tagged_above=-999 required=5 tests=[AWL=1.475, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eENJgBzbhaf1 for ; Thu, 28 Feb 2013 15:16:57 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id D7FAC21F8623 for ; Thu, 28 Feb 2013 15:16:57 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r1SNGLal022811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Feb 2013 15:16:21 -0800 (PST) Message-ID: <512FE536.3020206@isi.edu> Date: Thu, 28 Feb 2013 15:16:06 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Andrew Knutsen References: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D633E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <16EF3923-04A3-44AF-B52B-4BD910104A98@oracle.com> <512FB43A.7050505@bluecoat.com> <512FC3B9.80408@isi.edu> <512FE2F4.90202@bluecoat.com> In-Reply-To: <512FE2F4.90202@bluecoat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2013 23:16:58 -0000 On 2/28/2013 3:06 PM, Andrew Knutsen wrote: > > The problems arise when "IETF processes" cause longstanding problems > in the field. A bit analogous to what's going on in Congress today, it > seems to me. Several of the largest "squatters" (widely deployed, > multivendor technology, none listed below) tried to get "over the bar" a > couple years ago, and found it unreasonably high. So, we're all still > squatting (and shipping lots of units ;-). It either means the bar is too high or they can't jump. Whether we ought to lower the bar depends on that decision. We shouldn't just assume we should lower the bar solely to avoid circumnavigation. > To repeat Kevin's point again, so it doesn't get lost in the > verbiage: TCP option *size* seems to be a more limited resource than the > "kinds"/codepoints. This is the *Engineering* task force; we should be > making *engineering* decisions. Trading off one resource for another is > a classic engineering decision. I agree that space is a big issue, but wouldn't opening the gates to wider standardized usage similarly compromise that space? Joe From touch@isi.edu Thu Feb 28 15:23:51 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4BA521F8A55 for ; Thu, 28 Feb 2013 15:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.15 X-Spam-Level: X-Spam-Status: No, score=-105.15 tagged_above=-999 required=5 tests=[AWL=1.449, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laoKdwdYPnA2 for ; Thu, 28 Feb 2013 15:23:51 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8A021F8976 for ; Thu, 28 Feb 2013 15:23:51 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r1SNNa7C023629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Feb 2013 15:23:36 -0800 (PST) Message-ID: <512FE6E9.7000109@isi.edu> Date: Thu, 28 Feb 2013 15:23:21 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Kevin Lahey References: <68F2142A-FE1A-4FE0-95C7-3717D90A3B92@oracle.com> In-Reply-To: <68F2142A-FE1A-4FE0-95C7-3717D90A3B92@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-experimental-options-04 nit X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2013 23:23:51 -0000 Hi, Kevin, On 2/28/2013 8:55 AM, Kevin Lahey wrote: > Reading draft-ietf-tcpm-experimental-options-04, I was curious about the following provisions: > > The ExID mechanism must be coordinated during connection > establishment, just as with any TCP option. > > >> TCP ExID, if used in any TCP segment of a connection, MUST be > present in TCP SYN segments of that connection. > > >> TCP experimental option ExIDS, if used in any TCP segment of a > connection, SHOULD be used in all TCP segments of that connection in > which any experimental option is present. > > Am I being too lawyerly, or would this prevent something like > SACK-Permitted where a different option is sent on SYN segments than is > sent with every other segment? I presume that SACK-Permitted was an > attempt to avoid stressing the options processing code then deployed, > but I've seen more recent suggestions for an "I implement window shift, > timestamps, SACK, and perhaps other options" option to save space. SACK-permitted vs. SACK is a great example of how to burn codepoint space needlessly. SACK could instead easily have been defined as: if 2-bytes, then only in the SYN and means "sack permitted" otherwise means "sack" That could have used a single codepoint. So, yes, this language does avoid the idea that one TCP option codepoint should enable/extend a different one. Joe From andrew.knutsen@bluecoat.com Thu Feb 28 16:24:55 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C57321F84CA for ; Thu, 28 Feb 2013 16:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.456 X-Spam-Level: X-Spam-Status: No, score=-5.456 tagged_above=-999 required=5 tests=[AWL=1.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qK+W82hNSJH for ; Thu, 28 Feb 2013 16:24:54 -0800 (PST) Received: from synonym.bluecoat.com (synonym.bluecoat.com [199.91.133.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9940E21F84B6 for ; Thu, 28 Feb 2013 16:24:54 -0800 (PST) Received: from [10.9.43.135] (unknown [10.9.43.135]) by synonym.bluecoat.com (Postfix) with ESMTP id E21DF7FE17E; Thu, 28 Feb 2013 16:24:53 -0800 (PST) Message-ID: <512FF556.5060401@bluecoat.com> Date: Thu, 28 Feb 2013 16:24:54 -0800 From: Andrew Knutsen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Joe Touch References: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D633E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <16EF3923-04A3-44AF-B52B-4BD910104A98@oracle.com> <512FB43A.7050505@bluecoat.com> <512FC3B9.80408@isi.edu> <512FE2F4.90202@bluecoat.com> <512FE536.3020206@isi.edu> In-Reply-To: <512FE536.3020206@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 00:24:55 -0000 I think what you're saying is that if we allow more options, its more likely the 40 bytes sometimes won't be enough. The key here is that we standardize on working code. That means, any new option functions with the other options needed for it to work. If a new option causes problems with other relevant options, that should be part of the decision, as it has in the past. If it doesn't, it shouldn't. Andrew PS the joke about not jumping isn't funny to all of us. AK On 2/28/2013 3:16 PM, Joe Touch wrote: > > > On 2/28/2013 3:06 PM, Andrew Knutsen wrote: >> >> The problems arise when "IETF processes" cause longstanding problems >> in the field. A bit analogous to what's going on in Congress today, it >> seems to me. Several of the largest "squatters" (widely deployed, >> multivendor technology, none listed below) tried to get "over the bar" a >> couple years ago, and found it unreasonably high. So, we're all still >> squatting (and shipping lots of units ;-). > > It either means the bar is too high or they can't jump. > > Whether we ought to lower the bar depends on that decision. We > shouldn't just assume we should lower the bar solely to avoid > circumnavigation. > >> To repeat Kevin's point again, so it doesn't get lost in the >> verbiage: TCP option *size* seems to be a more limited resource than the >> "kinds"/codepoints. This is the *Engineering* task force; we should be >> making *engineering* decisions. Trading off one resource for another is >> a classic engineering decision. > > I agree that space is a big issue, but wouldn't opening the gates to > wider standardized usage similarly compromise that space? > > Joe From touch@isi.edu Thu Feb 28 17:21:33 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA3121F856C for ; Thu, 28 Feb 2013 17:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.175 X-Spam-Level: X-Spam-Status: No, score=-103.175 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TI6SezzFx-xn for ; Thu, 28 Feb 2013 17:21:32 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id CB17121F8569 for ; Thu, 28 Feb 2013 17:21:32 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r211LJqi019467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 28 Feb 2013 17:21:19 -0800 (PST) Message-ID: <51300280.30103@isi.edu> Date: Thu, 28 Feb 2013 17:21:04 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Andrew Knutsen References: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D633E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <16EF3923-04A3-44AF-B52B-4BD910104A98@oracle.com> <512FB43A.7050505@bluecoat.com> <512FC3B9.80408@isi.edu> <512FE2F4.90202@bluecoat.com> <512FE536.3020206@isi.edu> <512FF556.5060401@bluecoat.com> In-Reply-To: <512FF556.5060401@bluecoat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 01:21:34 -0000 On 2/28/2013 4:24 PM, Andrew Knutsen wrote: > > I think what you're saying is that if we allow more options, its > more likely the 40 bytes sometimes won't be enough. Yes, that sometimes is (and has been) a deciding issue. > The key here is that we standardize on working code. That means, > any new option functions with the other options needed for it to work. > If a new option causes problems with other relevant options, that should > be part of the decision, as it has in the past. If it doesn't, it > shouldn't. Agreed. > Andrew > > PS the joke about not jumping isn't funny to all of us. It wasn't a joke; it was an extension of the euphemism of "over the bar" - which you brought up. I'm fine with not using euphemisms if you prefer. Joe > AK > > On 2/28/2013 3:16 PM, Joe Touch wrote: >> >> >> On 2/28/2013 3:06 PM, Andrew Knutsen wrote: >>> >>> The problems arise when "IETF processes" cause longstanding problems >>> in the field. A bit analogous to what's going on in Congress today, it >>> seems to me. Several of the largest "squatters" (widely deployed, >>> multivendor technology, none listed below) tried to get "over the bar" a >>> couple years ago, and found it unreasonably high. So, we're all still >>> squatting (and shipping lots of units ;-). >> >> It either means the bar is too high or they can't jump. >> >> Whether we ought to lower the bar depends on that decision. We >> shouldn't just assume we should lower the bar solely to avoid >> circumnavigation. >> >>> To repeat Kevin's point again, so it doesn't get lost in the >>> verbiage: TCP option *size* seems to be a more limited resource than the >>> "kinds"/codepoints. This is the *Engineering* task force; we should be >>> making *engineering* decisions. Trading off one resource for another is >>> a classic engineering decision. >> >> I agree that space is a big issue, but wouldn't opening the gates to >> wider standardized usage similarly compromise that space? >> >> Joe From kevin.lahey@oracle.com Thu Feb 28 19:05:14 2013 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3A221F854E for ; Thu, 28 Feb 2013 19:05:14 -0800 (PST) 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.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1zhbKHuaTqF for ; Thu, 28 Feb 2013 19:05:12 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id A2E2121F854C for ; Thu, 28 Feb 2013 19:05:12 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r21359Td019039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Mar 2013 03:05:10 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r21358vZ003720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Mar 2013 03:05:09 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r21358fd031617; Thu, 28 Feb 2013 21:05:09 -0600 Received: from dhcp-santaclara18-3fl-west-10-132-146-215.usdhcp.oraclecorp.com (/10.132.146.215) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Feb 2013 19:05:08 -0800 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Kevin Lahey In-Reply-To: <512FC3B9.80408@isi.edu> Date: Thu, 28 Feb 2013 19:05:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D633E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <16EF3923-04A3-44AF-B52B-4BD910104A98@oracle.com> <512FB43A.7050505@bluecoat.com> <512FC3B9.80408@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: tcpm@ietf.org Subject: Re: [tcpm] draft-ietf-tcpm-experimental-options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 03:05:14 -0000 On Feb 28, 2013, at 12:53 PM, Joe Touch wrote: > The bar for TCP options is passing a standards-track RFC. That's the = same bar as for many other limited resources, including system TCP and = UDP ports. Well, it's actually Standards Action or IESG Approval, right? I had = naively assumed that we could squeeze in a slightly more relaxed process = via IESG Approval, but RFC 5226 suggests that this is intended for = exceptional cases. My concern is that, as an implementor and occasional deployer of boxes, = I don't want to see an option show up in a packet trace (or in a crash = dump or even a log file) that I haven't seen before and that I can't = identify. If I do see something weird, I'd really like to be able to = look it up and make an informed decision about how to deal with it. I also would like to have enough options around in case I someday have a = need for one, so I understand why we don't want them to be handed out = without any controls at all. I'd like it if really awful options = weren't deployed, but I suspect that there's really not much I can do if = a widely deployed system decides to implement something (hence our = squatted values). > In part, the bar could be lowered by the WG being more accepting of = proposals, but even then is it appropriate to burn multiple codepoints = on one option? Or to allow standards based on non-WG drafts (how does = that occur?) or to assign codepoints to competing standards while under = active WG debate? Of the options in RFC 5226, I'd prefer to use Specification Required (or = RFC Required with Expert Review) to allocate TCP Option Kinds. There's = obviously a balance to be had between carefully protecting a limited = resource and throwing open a registry to all comers. Given the small = number of assigned TCP Option Kinds and the squatting situation, it = seems like the current balance is tilted too far towards conservation = and not far enough towards serving the community. Speaking for myself, Kevin kevin.lahey@oracle.com