From michael.scharf@alcatel-lucent.com Tue Jan 1 07:33:39 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 1891821F8BE3 for ; Tue, 1 Jan 2013 07:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.072 X-Spam-Level: X-Spam-Status: No, score=-10.072 tagged_above=-999 required=5 tests=[AWL=0.177, 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 5szrv5YEbC3H for ; Tue, 1 Jan 2013 07:33:38 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1A44B21F8BCF for ; Tue, 1 Jan 2013 07:33:37 -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 r01FXYcd008799 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Jan 2013 16:33:34 +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; Tue, 1 Jan 2013 16:33:34 +0100 From: "Scharf, Michael (Michael)" To: Jakob Heitz , Michael Welzl , "tcpm (tcpm@ietf.org)" Date: Tue, 1 Jan 2013 16:33:32 +0100 Thread-Topic: [tcpm] About the SYN/ACK-timer Thread-Index: AQHN5b8Stu8nYED5FE+WsO7zyjvHrZgwFqsMgAFYDACAAHPGAP//xaCNgABbY4CAAACVAP//tpv7gABzqwCAANDSAIAATjzOgAFLxfA= Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4A@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> <9797BC06-420A-467D-8B0F-A9FDFD30F06D@ericsson.com> <50E00E8E.40204@tlc.polito.it> <50E06FAC.80200@isi.edu> <96C14B42-81DD-49E3-A795-03B21425552F@ericsson.com> <50E08B5D.1000003@isi.edu> <50E08BDA.8030102@isi.edu> , <2C87EAC5-4BF7-4A30-BAF5-4A9C113EF9EE@ifi.uio.no> <68C68DEB-B178-4980-A581-7909CC3FD947@ericsson.com> In-Reply-To: <68C68DEB-B178-4980-A581-7909CC3FD947@ericsson.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 Subject: Re: [tcpm] About the SYN/ACK-timer 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, 01 Jan 2013 15:33:39 -0000 I might miss something here, but to me there are some orthogonal issues in = this discussion. Retransmission of the SYN without data is already recommended in Section 4.= 2.2. of draft-ietf-tcpm-fastopen-02. Also, draft-ietf-tcpm-fastopen-02 refe= rs to RFC6298, i.e., the 1s minimum RTO. Thus, the novelty in this thread seems to be the suggestion to use much sma= ller minimum or initial RTOs (100ms or 200ms), right? I really wonder how this would work for over-buffered links ("bufferbloat")= , or, e.g., satellite links? IMHO, with a SYN (or SYN/ACK) RTO of 200ms, we= would send every SYN (or SYN/ACK) three times, if we happen to run over a = path with an RTT of one second... On a narrowband link, this could be a lot= of overhead. Michael > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Jakob Heitz > Sent: Monday, December 31, 2012 8:24 PM > To: Michael Welzl; tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] About the SYN/ACK-timer >=20 > I have an alternative to cookies. >=20 > Send data with the SYN. > When retransmission of the SYN is required, retransmit it=20 > without the data. > Retransmit the SYN quickly: 100 to 200 mS. >=20 > It works with Middleboxes. > SYN flood protection works as normal, just bias it against=20 > SYN with data. >=20 > Cheers, > Jakob. >=20 > On Dec 31, 2012, at 1:44 AM, "Michael Welzl"=20 > wrote: >=20 > > Hi, > >=20 > > About data-in-the-SYN: I agree with Joe that this has been=20 > debated a=20 > > lot already - see=20 > > https://tools.ietf.org/html/draft-ietf-tcpm-fastopen-02 and the=20 > > discussions surrounding it. FWIW this draft is a (IMHO,=20 > good) proposal=20 > > to do what you want, in the right way > >=20 > > Cheers, > > Michael > >=20 > >=20 > > On Dec 30, 2012, at 10:17 PM, Joe Touch wrote: > >=20 > >>=20 > >>=20 > >> On Dec 30, 2012, at 11:23 AM, Jakob Heitz=20 > wrote: > >>=20 > >>> On Dec 30, 2012, at 10:46 AM, "Joe Touch" wrote: > >>>>=20 > >>>> ...if it is to have any real effect. You can send data=20 > in the SYN now, but the server can't deliver it to the app=20 > layer until the three-way handshake completes. And it also=20 > increases the amount of state for pending connections,=20 > increasing the impact of DOS attacks. > >>>>=20 > >>>> Joe > >>>=20 > >>> It could, with a change to the sockets API. > >>=20 > >> No, it cannot without a change in CTO semantics, which=20 > affects the state diagram and its processing on both ends -=20 > which also changes the meaning of an ack and the concept of=20 > reliability.=20 > >>=20 > >> There is a lot required, and for the first connection to a=20 > site it won't work to allow the server to act on data before=20 > a connection has been established.=20 > >>=20 > >> This is well- trod ground.=20 > >>=20 > >> Joe > >>=20 > >>> Of course, the app will need to participate in SYN flood=20 > protection, but that's not impossible given the right architecture. > >>>=20 > >>> -- > >>> Jakob Heitz. > >>>=20 > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > = From jakob.heitz@ericsson.com Tue Jan 1 07:52: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 7DBCC21E8037 for ; Tue, 1 Jan 2013 07:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.435 X-Spam-Level: X-Spam-Status: No, score=-6.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 cmFbstDa9BGb for ; Tue, 1 Jan 2013 07:52:57 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C67FF21E8030 for ; Tue, 1 Jan 2013 07:52:57 -0800 (PST) Received: from EUSAAHC003.ericsson.se ([147.117.188.81]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id r01G6Ohi004785; Tue, 1 Jan 2013 10:06:26 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.004; Tue, 1 Jan 2013 10:52:49 -0500 From: Jakob Heitz To: "Scharf, Michael (Michael)" Thread-Topic: [tcpm] About the SYN/ACK-timer Thread-Index: AQHN5b8Stu8nYED5FE+WsO7zyjvHrZgwFqsMgAFYDACAAHPGAP//xaCNgABbY4CAAACVAP//tpv7gABzqwCAANDSAIAATjzOgAFLxfCAAAtsMA== Date: Tue, 1 Jan 2013 15:52:48 +0000 Message-ID: References: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> <9797BC06-420A-467D-8B0F-A9FDFD30F06D@ericsson.com> <50E00E8E.40204@tlc.polito.it> <50E06FAC.80200@isi.edu> <96C14B42-81DD-49E3-A795-03B21425552F@ericsson.com> <50E08B5D.1000003@isi.edu> <50E08BDA.8030102@isi.edu> , <2C87EAC5-4BF7-4A30-BAF5-4A9C113EF9EE@ifi.uio.no> <68C68DEB-B178-4980-A581-7909CC3FD947@ericsson.com>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4A@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4A@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" , Michael Welzl Subject: Re: [tcpm] About the SYN/ACK-timer 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, 01 Jan 2013 15:52:58 -0000 It's only a SYN. There aren't lots of those. And they're really small. How about make the first SYN retransmission at 100mS and the next one at 1.= 1 second? Cheers, Jakob. On Jan 1, 2013, at 7:33 AM, "Scharf, Michael (Michael)" wrote: > I might miss something here, but to me there are some orthogonal issues i= n this discussion. >=20 > Retransmission of the SYN without data is already recommended in Section = 4.2.2. of draft-ietf-tcpm-fastopen-02. Also, draft-ietf-tcpm-fastopen-02 re= fers to RFC6298, i.e., the 1s minimum RTO. >=20 > Thus, the novelty in this thread seems to be the suggestion to use much s= maller minimum or initial RTOs (100ms or 200ms), right? >=20 > I really wonder how this would work for over-buffered links ("bufferbloat= "), or, e.g., satellite links? IMHO, with a SYN (or SYN/ACK) RTO of 200ms, = we would send every SYN (or SYN/ACK) three times, if we happen to run over = a path with an RTT of one second... On a narrowband link, this could be a l= ot of overhead. >=20 > Michael >=20 >=20 >=20 >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 >> Behalf Of Jakob Heitz >> Sent: Monday, December 31, 2012 8:24 PM >> To: Michael Welzl; tcpm (tcpm@ietf.org) >> Subject: Re: [tcpm] About the SYN/ACK-timer >>=20 >> I have an alternative to cookies. >>=20 >> Send data with the SYN. >> When retransmission of the SYN is required, retransmit it=20 >> without the data. >> Retransmit the SYN quickly: 100 to 200 mS. >>=20 >> It works with Middleboxes. >> SYN flood protection works as normal, just bias it against=20 >> SYN with data. >>=20 >> Cheers, >> Jakob. >>=20 >> On Dec 31, 2012, at 1:44 AM, "Michael Welzl"=20 >> wrote: >>=20 >>> Hi, >>>=20 >>> About data-in-the-SYN: I agree with Joe that this has been=20 >> debated a=20 >>> lot already - see=20 >>> https://tools.ietf.org/html/draft-ietf-tcpm-fastopen-02 and the=20 >>> discussions surrounding it. FWIW this draft is a (IMHO,=20 >> good) proposal=20 >>> to do what you want, in the right way >>>=20 >>> Cheers, >>> Michael >>>=20 >>>=20 >>> On Dec 30, 2012, at 10:17 PM, Joe Touch wrote: >>>=20 >>>>=20 >>>>=20 >>>> On Dec 30, 2012, at 11:23 AM, Jakob Heitz=20 >> wrote: >>>>=20 >>>>> On Dec 30, 2012, at 10:46 AM, "Joe Touch" wrote: >>>>>>=20 >>>>>> ...if it is to have any real effect. You can send data=20 >> in the SYN now, but the server can't deliver it to the app=20 >> layer until the three-way handshake completes. And it also=20 >> increases the amount of state for pending connections,=20 >> increasing the impact of DOS attacks. >>>>>>=20 >>>>>> Joe >>>>>=20 >>>>> It could, with a change to the sockets API. >>>>=20 >>>> No, it cannot without a change in CTO semantics, which=20 >> affects the state diagram and its processing on both ends -=20 >> which also changes the meaning of an ack and the concept of=20 >> reliability.=20 >>>>=20 >>>> There is a lot required, and for the first connection to a=20 >> site it won't work to allow the server to act on data before=20 >> a connection has been established.=20 >>>>=20 >>>> This is well- trod ground.=20 >>>>=20 >>>> Joe >>>>=20 >>>>> Of course, the app will need to participate in SYN flood=20 >> protection, but that's not impossible given the right architecture. >>>>>=20 >>>>> -- >>>>> Jakob Heitz. >>>>>=20 >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From michael.scharf@alcatel-lucent.com Tue Jan 1 08:13: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 4437B21E803D for ; Tue, 1 Jan 2013 08:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.085 X-Spam-Level: X-Spam-Status: No, score=-8.085 tagged_above=-999 required=5 tests=[AWL=-1.836, 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 dnryvMu6aywJ for ; Tue, 1 Jan 2013 08:13:29 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF4221E803C for ; Tue, 1 Jan 2013 08:13:22 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r01GDKqB032406 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Jan 2013 17:13:20 +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; Tue, 1 Jan 2013 17:13:20 +0100 From: "Scharf, Michael (Michael)" To: Jakob Heitz Date: Tue, 1 Jan 2013 17:13:19 +0100 Thread-Topic: [tcpm] About the SYN/ACK-timer Thread-Index: AQHN5b8Stu8nYED5FE+WsO7zyjvHrZgwFqsMgAFYDACAAHPGAP//xaCNgABbY4CAAACVAP//tpv7gABzqwCAANDSAIAATjzOgAFLxfCAAAtsMIAAAH5g Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> <9797BC06-420A-467D-8B0F-A9FDFD30F06D@ericsson.com> <50E00E8E.40204@tlc.polito.it> <50E06FAC.80200@isi.edu> <96C14B42-81DD-49E3-A795-03B21425552F@ericsson.com> <50E08B5D.1000003@isi.edu> <50E08BDA.8030102@isi.edu> , <2C87EAC5-4BF7-4A30-BAF5-4A9C113EF9EE@ifi.uio.no> <68C68DEB-B178-4980-A581-7909CC3FD947@ericsson.com>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4A@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> 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.13 Cc: "tcpm \(tcpm@ietf.org\)" , Michael Welzl Subject: Re: [tcpm] About the SYN/ACK-timer 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, 01 Jan 2013 16:13:31 -0000 100ms would imply that we send two SYNs for most inter-continental TCP conn= ections. I am still to be convinced that there is a real benefit of that re= dundancy. If so, then let's be honest and call it "FEC scheme" - not getting an ACK a= fter 100ms is clearly not a sign of loss in the current Internet. Also, SYNs are actually not so "cheap", imho. They typically cannot be proc= essed in the "fast path" of a TCP stack (for in-sequence data segments w/o = special flags), and middleboxes might care a lot about every single bit in = SYNs... And let's not enter the discussion of byte vs. packet-based queues = here... For what it is worth, I guess that one could reduce the initial RTO below o= ne second if an endsystem has chached RTT data to the same IP address. Mayb= e some stacks do this already these days? It is well-known that some stacks= use own optimizations beyond RFC 6298. Michael > -----Original Message----- > From: Jakob Heitz [mailto:jakob.heitz@ericsson.com]=20 > Sent: Tuesday, January 01, 2013 4:53 PM > To: Scharf, Michael (Michael) > Cc: Michael Welzl; tcpm (tcpm@ietf.org) > Subject: Re: [tcpm] About the SYN/ACK-timer >=20 > It's only a SYN. There aren't lots of those. And they're really small. > How about make the first SYN retransmission at 100mS and the=20 > next one at 1.1 second? >=20 > Cheers, > Jakob. >=20 > On Jan 1, 2013, at 7:33 AM, "Scharf, Michael (Michael)"=20 > wrote: >=20 > > I might miss something here, but to me there are some=20 > orthogonal issues in this discussion. > >=20 > > Retransmission of the SYN without data is already=20 > recommended in Section 4.2.2. of draft-ietf-tcpm-fastopen-02.=20 > Also, draft-ietf-tcpm-fastopen-02 refers to RFC6298, i.e.,=20 > the 1s minimum RTO. > >=20 > > Thus, the novelty in this thread seems to be the suggestion=20 > to use much smaller minimum or initial RTOs (100ms or 200ms), right? > >=20 > > I really wonder how this would work for over-buffered links=20 > ("bufferbloat"), or, e.g., satellite links? IMHO, with a SYN=20 > (or SYN/ACK) RTO of 200ms, we would send every SYN (or=20 > SYN/ACK) three times, if we happen to run over a path with an=20 > RTT of one second... On a narrowband link, this could be a=20 > lot of overhead. > >=20 > > Michael > >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org]=20 > On Behalf=20 > >> Of Jakob Heitz > >> Sent: Monday, December 31, 2012 8:24 PM > >> To: Michael Welzl; tcpm (tcpm@ietf.org) > >> Subject: Re: [tcpm] About the SYN/ACK-timer > >>=20 > >> I have an alternative to cookies. > >>=20 > >> Send data with the SYN. > >> When retransmission of the SYN is required, retransmit it=20 > without the=20 > >> data. > >> Retransmit the SYN quickly: 100 to 200 mS. > >>=20 > >> It works with Middleboxes. > >> SYN flood protection works as normal, just bias it against=20 > SYN with=20 > >> data. > >>=20 > >> Cheers, > >> Jakob. > >>=20 > >> On Dec 31, 2012, at 1:44 AM, "Michael Welzl"=20 > >> wrote: > >>=20 > >>> Hi, > >>>=20 > >>> About data-in-the-SYN: I agree with Joe that this has been > >> debated a > >>> lot already - see > >>> https://tools.ietf.org/html/draft-ietf-tcpm-fastopen-02 and the=20 > >>> discussions surrounding it. FWIW this draft is a (IMHO, > >> good) proposal > >>> to do what you want, in the right way > >>>=20 > >>> Cheers, > >>> Michael > >>>=20 > >>>=20 > >>> On Dec 30, 2012, at 10:17 PM, Joe Touch wrote: > >>>=20 > >>>>=20 > >>>>=20 > >>>> On Dec 30, 2012, at 11:23 AM, Jakob Heitz > >> wrote: > >>>>=20 > >>>>> On Dec 30, 2012, at 10:46 AM, "Joe Touch" wrote: > >>>>>>=20 > >>>>>> ...if it is to have any real effect. You can send data > >> in the SYN now, but the server can't deliver it to the app layer=20 > >> until the three-way handshake completes. And it also increases the=20 > >> amount of state for pending connections, increasing the=20 > impact of DOS=20 > >> attacks. > >>>>>>=20 > >>>>>> Joe > >>>>>=20 > >>>>> It could, with a change to the sockets API. > >>>>=20 > >>>> No, it cannot without a change in CTO semantics, which > >> affects the state diagram and its processing on both ends - which=20 > >> also changes the meaning of an ack and the concept of reliability. > >>>>=20 > >>>> There is a lot required, and for the first connection to a > >> site it won't work to allow the server to act on data before a=20 > >> connection has been established. > >>>>=20 > >>>> This is well- trod ground.=20 > >>>>=20 > >>>> Joe > >>>>=20 > >>>>> Of course, the app will need to participate in SYN flood > >> protection, but that's not impossible given the right architecture. > >>>>>=20 > >>>>> -- > >>>>> Jakob Heitz. > >>>>>=20 > >>>> _______________________________________________ > >>>> tcpm mailing list > >>>> tcpm@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tcpm > >>>=20 > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > = From swmike@swm.pp.se Tue Jan 1 09:24: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 55EBB21F84D9 for ; Tue, 1 Jan 2013 09:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, 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 7EO+71RAriVm for ; Tue, 1 Jan 2013 09:24:52 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id AB82321E8041 for ; Tue, 1 Jan 2013 09:24:47 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id BFDEC9C; Tue, 1 Jan 2013 18:24:44 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BAE459A for ; Tue, 1 Jan 2013 18:24:44 +0100 (CET) Date: Tue, 1 Jan 2013 18:24:44 +0100 (CET) From: Mikael Abrahamsson To: "tcpm (tcpm@ietf.org)" In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4A@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Message-ID: References: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> <9797BC06-420A-467D-8B0F-A9FDFD30F06D@ericsson.com> <50E00E8E.40204@tlc.polito.it> <50E06FAC.80200@isi.edu> <96C14B42-81DD-49E3-A795-03B21425552F@ericsson.com> <50E08B5D.1000003@isi.edu> <50E08BDA.8030102@isi.edu> , <2C87EAC5-4BF7-4A30-BAF5-4A9C113EF9EE@ifi.uio.no> <68C68DEB-B178-4980-A581-7909CC3FD947@ericsson.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4A@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [tcpm] About the SYN/ACK-timer 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, 01 Jan 2013 17:24:53 -0000 On Tue, 1 Jan 2013, Scharf, Michael (Michael) wrote: > I really wonder how this would work for over-buffered links > ("bufferbloat"), or, e.g., satellite links? IMHO, with a SYN (or > SYN/ACK) RTO of 200ms, we would send every SYN (or SYN/ACK) three times, > if we happen to run over a path with an RTT of one second... On a > narrowband link, this could be a lot of overhead. I believe the only way to handle all the cases is for each end to somehow "learn" that it's on a certain type of link (some kind of heuritics), and tell the other end about it. I see no way to optimize TCP for all cases ranging from multisecond RTT low bw connections up to future 100GE attachement over high RTT links, to rate-limited/policed medium-bw links, to 3GPP HSPA networks that might be high-bw but that might have initial 1-2 second "stop" in the communication with a then-rush of packets as radio resources are done negotiating, without telling the other end about what kind of access it's on. I don't know if this falls into a "minor" modification of TCP or not, but without this, TCP is not going to behave as well as it could for a lot of cases. If we keep RTT for a certain destination and tell the other end that we're on a ETTH connection policed to approximately 20 megabit/s and what RTT we're expecting to see (ie no change in RTT over time, throttling will be done via dropping of packets, no significant buffering), then that other end can treat traffic in a whole different way compared to if we're on a low-bw link with a lot of buffering where RTT will change wildly over time depending on buffer fill. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Tue Jan 1 09:29: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 6D9F521E8041 for ; Tue, 1 Jan 2013 09:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 eiPvQ1M6nv6E for ; Tue, 1 Jan 2013 09:29:01 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 34C6F21E803F for ; Tue, 1 Jan 2013 09:29:01 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8CB269C; Tue, 1 Jan 2013 18:29:00 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 871759A for ; Tue, 1 Jan 2013 18:29:00 +0100 (CET) Date: Tue, 1 Jan 2013 18:29:00 +0100 (CET) From: Mikael Abrahamsson To: tcpm@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 01 Jan 2013 17:29:02 -0000 On Fri, 9 Nov 2012, Mikael Abrahamsson wrote: I have sent this email both to the list (as can be seen below), and to one of the chairs 5 days later, with zero reply. I would really appricate some kind of feedback on this idea, if nothing else just a "this is not applicable to this WG" and perhaps a hint on where it would be more applicable. Thanks. > > Hello. > > I don't know if this is appropriate for this WG, please tell me if it's not. > > A while ago, I pitched an idea in the linux-netdev mailing list, regarding > how a connection manager might hint the TCP stack of the host, to do things > depending on network conditions. > > The post is here: > > Would what I am suggesting be appropriate to discuss here and perhaps even > create a document giving guidance to TCP implementors about APIs that might > be helpful, and how they should behave? I believe the problem I'm describing > is real and it affects users all the time. > > Here is the text: > > ------------------------------------ > > I'm a network engineer, as in I work primarily with IP routing. Ever since I > started running Linux back in the mid 90ties I've had a love/hate > relationship with how Linux handles disappearing network connectivity or IP > addresses. > > > In my mind there are two ways to handle outage: > > 1. When a network connection (physical interface) goes down, keep everything > as it is, it might come back up again shortly and then we can continue as if > basically nothing happened. TCP was designed for this considering timeouts > can be in hours. > > > 2. When a network connection (physical interface) goes down, wait a few > seconds, give up, reset all connectivity related to that connection, > basically give up. > > > Now to my question for the netdev people: > > Is there functionality in the kernel for a connection manager to easily > accomplish 2, in that when it tries to deconfigure the IP address on the > interface to also kill all TCP connections terminated at that IP? On my > laptop, I regularily have to kill my ssh client after suspend/resume cycle, > because it's been down for quite a while, and the ssh client doesn't know the > TCP connection is now not functional anymore (TCP session is still up and > retransmit won't happen for a while, so the TCP RST from the server (I use > keepalives within SSH) isn't seen for a long time). > > > Without knowing what's in place right now, I see some behaviours that I'd > like to have: > > > After resume (or otherwise network connectivity re-established), connection > manager should be able to tell the kernel to: > > > a) kill all TCP/UDP/other sessions existing which doesn't currently have an > active IP address on the machine. This is for the sake of local clients. b) > the TCP/SCTP sessions that *do* have an IP, should have their retransmit > timers "reset", so that whatever needs to be sent, should be sent immediately > (or shortly, within a few seconds). c) tell the kernel to kill all TCP > sessions bound to a certain IP, because the connection manager is going to > remove it shortly. Send TCP RSTs or whatever and close the TCP session, so > both ends know that network connectivity is going down. > > > This would mean that if I resume my laptop and it establishes network > connectivity, I will then *know* within a few seconds what TCP sessions are > still valid (the ones that aren't will be killed either because they're bound > to an IP that is not available, or a TCP packet is sent out to which there > will be a TCP RST reply from the other side if the TCP session is closed at > that end). > > > All of this also has implications on IPv6 and autoconfiguration, I don't know > if currently we are closing TCP sessions bound to IPv6 addresses that are > going away due to the RA the addresses were autoconfigured based on, now > doesn't have a valid lifetime anymore and the kernel is going to remove them. > It also applies to both DHCPv6 and DHCPv4 when a lease is expiring and the > IPv4/IPv6 address is going to be removed. > > > Right now I think the situation with a lot of "hanging" TCP sessions after > connectivity is restored is suboptimal and negatively impacts user > experience. Probably there should be knobs to turn for different user needs > (server or desktop/laptop) because desired behaviour is different in > different use cases. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- Mikael Abrahamsson email: swmike@swm.pp.se From michael.scharf@alcatel-lucent.com Tue Jan 1 10:52: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 2B29921F886C for ; Tue, 1 Jan 2013 10:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.962 X-Spam-Level: X-Spam-Status: No, score=-9.962 tagged_above=-999 required=5 tests=[AWL=0.287, 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 9-BnVrRGCEqc for ; Tue, 1 Jan 2013 10:52:36 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id A6B2221F8864 for ; Tue, 1 Jan 2013 10:52:35 -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 r01IqVrx027839 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 Jan 2013 19:52:32 +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; Tue, 1 Jan 2013 19:52:31 +0100 From: "Scharf, Michael (Michael)" To: Mikael Abrahamsson , "tcpm@ietf.org" Date: Tue, 1 Jan 2013 19:52:30 +0100 Thread-Topic: [tcpm] host behaviour when connectivity is lost Thread-Index: Ac3oRYD/RSYntwNORq2M47c0gEa99gAAkr+A Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@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 Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 01 Jan 2013 18:52:37 -0000 Mikael, The lack of a reply is feedback as well... My understanding (as individual WG contributor, for what it is worth) is th= at one has to distinguish functions inside the TCP stack and user/system pr= ograms using TCP. From a high-level perspective, TCPM cares about the forme= r, but not about the latter. A connection manager is in my understanding a function *on top* of the TCP/= IP network stack. Connection managers are realized already today in operati= ng systems, i. e., the key question is whether any additional TCP (or IETF)= standard is actually required. Note that the IETF typically does not stand= ardize operating system interfaces.=20 More specifically regarding your suggestions: Proposals a) and c) are about killing TCP connections. In my understanding,= a TCP implementation itself cannot decide whether there is "an active IP a= ddress on the machine", i. e., it is apparently not up to the TCP implement= ation to decide this. Moreover, as you already note yourself, the question = whether it is "better" to persist or kill a connection is highly applicatio= n-specific, i. e., TCP cannot decide that at all. To me, this is an applica= tion decision that TCP cannot solve. For instance, many application protoco= ls have means to check whether a connection is still alive, and they also h= ave their own means to react to connectivity problems (I don't know about S= SH). That seems to be the right solution, and does not require TCP modifica= tions, imho. A potentially interesting field that could be relevant to TCPM is whether T= CP's timer management can be further improved after a system resume, i. e.,= bullet point b) in your list. However, my assumption is that the typical i= mplementations of retransmission timers inside an OS automatically fire aft= er a system resume. If so, objective b) might already be realized by TCP st= acks as of today. But I might be wrong. In short, in TCPM you should explain what is indeed missing in the TCP stan= dards. Michael > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Mikael Abrahamsson > Sent: Tuesday, January 01, 2013 6:29 PM > To: tcpm@ietf.org > Subject: Re: [tcpm] host behaviour when connectivity is lost >=20 > On Fri, 9 Nov 2012, Mikael Abrahamsson wrote: >=20 > I have sent this email both to the list (as can be seen=20 > below), and to one of the chairs 5 days later, with zero=20 > reply. I would really appricate some kind of feedback on this=20 > idea, if nothing else just a "this is not applicable to this=20 > WG" and perhaps a hint on where it would be more applicable. >=20 > Thanks. >=20 > > > > Hello. > > > > I don't know if this is appropriate for this WG, please=20 > tell me if it's not. > > > > A while ago, I pitched an idea in the linux-netdev mailing list,=20 > > regarding how a connection manager might hint the TCP stack of the=20 > > host, to do things depending on network conditions. > > > > The post is here:=20 > > > > > Would what I am suggesting be appropriate to discuss here=20 > and perhaps=20 > > even create a document giving guidance to TCP implementors=20 > about APIs=20 > > that might be helpful, and how they should behave? I believe the=20 > > problem I'm describing is real and it affects users all the time. > > > > Here is the text: > > > > ------------------------------------ > > > > I'm a network engineer, as in I work primarily with IP=20 > routing. Ever=20 > > since I started running Linux back in the mid 90ties I've had a=20 > > love/hate relationship with how Linux handles disappearing network=20 > > connectivity or IP addresses. > > > > > > In my mind there are two ways to handle outage: > > > > 1. When a network connection (physical interface) goes down, keep=20 > > everything as it is, it might come back up again shortly=20 > and then we=20 > > can continue as if basically nothing happened. TCP was designed for=20 > > this considering timeouts can be in hours. > > > > > > 2. When a network connection (physical interface) goes down, wait a=20 > > few seconds, give up, reset all connectivity related to that=20 > > connection, basically give up. > > > > > > Now to my question for the netdev people: > > > > Is there functionality in the kernel for a connection manager to=20 > > easily accomplish 2, in that when it tries to deconfigure the IP=20 > > address on the interface to also kill all TCP connections=20 > terminated=20 > > at that IP? On my laptop, I regularily have to kill my ssh client=20 > > after suspend/resume cycle, because it's been down for=20 > quite a while,=20 > > and the ssh client doesn't know the TCP connection is now not=20 > > functional anymore (TCP session is still up and retransmit won't=20 > > happen for a while, so the TCP RST from the server (I use=20 > keepalives within SSH) isn't seen for a long time). > > > > > > Without knowing what's in place right now, I see some=20 > behaviours that=20 > > I'd like to have: > > > > > > After resume (or otherwise network connectivity re-established),=20 > > connection manager should be able to tell the kernel to: > > > > > > a) kill all TCP/UDP/other sessions existing which doesn't currently=20 > > have an active IP address on the machine. This is for the sake of=20 > > local clients. b) the TCP/SCTP sessions that *do* have an=20 > IP, should=20 > > have their retransmit timers "reset", so that whatever needs to be=20 > > sent, should be sent immediately (or shortly, within a few=20 > seconds).=20 > > c) tell the kernel to kill all TCP sessions bound to a certain IP,=20 > > because the connection manager is going to remove it=20 > shortly. Send TCP=20 > > RSTs or whatever and close the TCP session, so both ends=20 > know that network connectivity is going down. > > > > > > This would mean that if I resume my laptop and it=20 > establishes network=20 > > connectivity, I will then *know* within a few seconds what TCP=20 > > sessions are still valid (the ones that aren't will be=20 > killed either=20 > > because they're bound to an IP that is not available, or a=20 > TCP packet=20 > > is sent out to which there will be a TCP RST reply from the=20 > other side=20 > > if the TCP session is closed at that end). > > > > > > All of this also has implications on IPv6 and autoconfiguration, I=20 > > don't know if currently we are closing TCP sessions bound to IPv6=20 > > addresses that are going away due to the RA the addresses were=20 > > autoconfigured based on, now doesn't have a valid lifetime=20 > anymore and the kernel is going to remove them. > > It also applies to both DHCPv6 and DHCPv4 when a lease is=20 > expiring and=20 > > the > > IPv4/IPv6 address is going to be removed. > > > > > > Right now I think the situation with a lot of "hanging" TCP=20 > sessions=20 > > after connectivity is restored is suboptimal and negatively impacts=20 > > user experience. Probably there should be knobs to turn for=20 > different=20 > > user needs (server or desktop/laptop) because desired behaviour is=20 > > different in different use cases. > > > > --=20 > > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > = From mallman@icir.org Tue Jan 1 18:53:49 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 7B29721E8041 for ; Tue, 1 Jan 2013 18:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xsVjsOf8c4e for ; Tue, 1 Jan 2013 18:53:49 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0249B21E8030 for ; Tue, 1 Jan 2013 18:53:48 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r022rghg022555; Tue, 1 Jan 2013 18:53:42 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id AF22755A074; Tue, 1 Jan 2013 21:53:50 -0500 (EST) To: Michael Welzl From: Mark Allman In-Reply-To: <1D1BEDF8-28D1-41CD-999C-5627E81D0537@ifi.uio.no> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Pink Houses X-URL-0: http://www.icir.org/mallman-files/Document51295.doc MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma41276-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 01 Jan 2013 21:53:50 -0500 Sender: mallman@icir.org Message-Id: <20130102025350.AF22755A074@lawyers.icir.org> Cc: "tcpm \(tcpm@ietf.org\)" , Marco Mellia , Joe Touch Subject: Re: [tcpm] About the SYN/ACK-timer X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 02:53:49 -0000 ----------ma41276-1 Content-Type: text/plain Content-Disposition: inline I am confused. > Not sure about everyone else, but the way I interpreted (and meant) > the 1s bit was to say "a new value, such as 1s, as opposed to a > complex adaptive mechanism". It wasn't about the exact value of 1s per > se. You say "a new value, such as 1s". My point is 1s is NOT a new value. It is the standardized value. Before proposing some new value, it'd at least be handy if folks understood the current value. > About lowering the initial RTO further: I, for one, hadn't thought of > that, and am not fully aware of all the pro's and con's. But yeah, it > might be worth considering? Well, if you're not suggesting lowering the initial RTO then what are you suggesting? I have no idea what you are saying here. The initial RTO is the RTO that is used before an RTT sample is taken. So, just what are you suggesting here? allman ----------ma41276-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlDjoT4ACgkQWyrrWs4yIs6wIgCfZVyQ4sfwLyULowrRyrwo4doN RYMAnj53e9J5CrkilDMJ13PnuDVyh3B6 =0A6Z -----END PGP SIGNATURE----- ----------ma41276-1-- From swmike@swm.pp.se Tue Jan 1 20:06: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 62DC51F0CFF for ; Tue, 1 Jan 2013 20:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 hM9AZ4us-llE for ; Tue, 1 Jan 2013 20:06:44 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id D37591F0CFC for ; Tue, 1 Jan 2013 20:06:43 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 170029C; Wed, 2 Jan 2013 05:06:42 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0EFB29A; Wed, 2 Jan 2013 05:06:42 +0100 (CET) Date: Wed, 2 Jan 2013 05:06:42 +0100 (CET) From: Mikael Abrahamsson To: "Scharf, Michael (Michael)" In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Message-ID: References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 02 Jan 2013 04:06:44 -0000 On Tue, 1 Jan 2013, Scharf, Michael (Michael) wrote: > A potentially interesting field that could be relevant to TCPM is > whether TCP's timer management can be further improved after a system > resume, i. e., bullet point b) in your list. However, my assumption is > that the typical implementations of retransmission timers inside an OS > automatically fire after a system resume. If so, objective b) might > already be realized by TCP stacks as of today. But I might be wrong. My thinking is if there is TCP standardization/guidance needed for what the TCP timers should be set to when a system is resumed from hibernation or when know network loss is rectified. There has been a lot of discussion on retransmission timers for SYN+ACK packets here recently, I feel that giving guidance on what timers should be after prolonged network connectivity loss or sleep as well. Keeping it at real time clock values what it should have been if this was just silent packet loss seems overly conservative (we know network was out, it's now most likely not, keeping retransmission timers in the tens of minutes is not helping anyone), and putting them into repeatedly fast-retransmit seems overly aggressive. Off the top of my head, I'd say putting them into somewhere around 1 second retransmit time range sounds plausable. But this is what I want to discuss. > In short, in TCPM you should explain what is indeed missing in the TCP standards. Guidance on timers, at least. Perhaps also guidance that having an operating system interface for userspace applications (perhaps a connection manager) is a good idea to indicate that TCP timers should be put into "network connectivity problem gone, please try to see what TCP sessions are still valid" (and how to do this) and have TCP lower timers and send packets that need sending, in a reasonable time (and define what is reasonable). -- Mikael Abrahamsson email: swmike@swm.pp.se From jakob.heitz@ericsson.com Tue Jan 1 21:25:39 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 952B821F89C0 for ; Tue, 1 Jan 2013 21:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.439 X-Spam-Level: X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 SLnk+C86NpZo for ; Tue, 1 Jan 2013 21:25:39 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8BD21E8042 for ; Tue, 1 Jan 2013 21:25:28 -0800 (PST) Received: from EUSAAHC008.ericsson.se ([147.117.188.96]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id r025crKd020837; Tue, 1 Jan 2013 23:38:55 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 00:25:15 -0500 From: Jakob Heitz To: "mallman@icir.org" , Michael Welzl Thread-Topic: [tcpm] About the SYN/ACK-timer Thread-Index: AQHN6JRkfTevst8bIk+96AjjSWwxV5g1fTBQ Date: Wed, 2 Jan 2013 05:25:14 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E148E68@eusaamb109.ericsson.se> References: <1D1BEDF8-28D1-41CD-999C-5627E81D0537@ifi.uio.no> <20130102025350.AF22755A074@lawyers.icir.org> In-Reply-To: <20130102025350.AF22755A074@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" , Marco Mellia , Joe Touch Subject: Re: [tcpm] About the SYN/ACK-timer 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, 02 Jan 2013 05:25:39 -0000 On Tuesday, January 01, 2013 6:54 PM, mallman@icir.org wrote: > I am confused. >=20 >> Not sure about everyone else, but the way I interpreted (and meant) >> the 1s bit was to say "a new value, such as 1s, as opposed to a >> complex adaptive mechanism". It wasn't about the exact value of 1s >> per se. >=20 > You say "a new value, such as 1s". My point is 1s is NOT a new value. > It is the standardized value. Before proposing some new > value, it'd at > least be handy if folks understood the current value. >=20 >> About lowering the initial RTO further: I, for one, hadn't thought of >> that, and am not fully aware of all the pro's and con's. But yeah, it >> might be worth considering? >=20 > Well, if you're not suggesting lowering the initial RTO then what are > you suggesting? I have no idea what you are saying here. The initial > RTO is the RTO that is used before an RTT sample is taken. So, just > what are you suggesting here?=20 >=20 > allman I am suggesting: 1st SYN contains data. Retransmit that SYN without data after 100mS. Make the next retransmit timer 1 second with the normal power of 2 backoff = after that. All SYN retransmits without data. Do the same for the SYN/ACK. No cookies. The initial 100mS SYN retransmit timer MAY be lengthened by application kno= wledge of conditions. For example, satellite or wireless. --=20 Jakob Heitz. From nishida@sfc.wide.ad.jp Tue Jan 1 23:32: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 8B85921F8E51 for ; Tue, 1 Jan 2013 23:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 eICcVZRFZ2yW for ; Tue, 1 Jan 2013 23:32:22 -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 9C64521F8E49 for ; Tue, 1 Jan 2013 23:32:21 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 5E0952780BC for ; Wed, 2 Jan 2013 16:32:19 +0900 (JST) Received: by mail-la0-f54.google.com with SMTP id fp12so5651707lab.13 for ; Tue, 01 Jan 2013 23:32:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.98.232 with SMTP id el8mr6542490lbb.121.1357111936976; Tue, 01 Jan 2013 23:32:16 -0800 (PST) Received: by 10.112.142.196 with HTTP; Tue, 1 Jan 2013 23:32:16 -0800 (PST) In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E148E68@eusaamb109.ericsson.se> References: <1D1BEDF8-28D1-41CD-999C-5627E81D0537@ifi.uio.no> <20130102025350.AF22755A074@lawyers.icir.org> <2F3EBB88EC3A454AAB08915FBF0B8C7E148E68@eusaamb109.ericsson.se> Date: Tue, 1 Jan 2013 23:32:16 -0800 Message-ID: From: Yoshifumi Nishida To: Jakob Heitz Content-Type: multipart/alternative; boundary=f46d0401f8e1ec861804d2493e67 Cc: Joe Touch , "tcpm \(tcpm@ietf.org\)" , Marco Mellia , Michael Welzl , "mallman@icir.org" Subject: Re: [tcpm] About the SYN/ACK-timer 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, 02 Jan 2013 07:32:22 -0000 --f46d0401f8e1ec861804d2493e67 Content-Type: text/plain; charset=ISO-8859-1 Hi Jakob, On Tue, Jan 1, 2013 at 9:25 PM, Jakob Heitz wrote: > On Tuesday, January 01, 2013 6:54 PM, mallman@icir.org mallman@icir.org> wrote: > > > I am confused. > > > >> Not sure about everyone else, but the way I interpreted (and meant) > >> the 1s bit was to say "a new value, such as 1s, as opposed to a > >> complex adaptive mechanism". It wasn't about the exact value of 1s > >> per se. > > > > You say "a new value, such as 1s". My point is 1s is NOT a new value. > > It is the standardized value. Before proposing some new > > value, it'd at > > least be handy if folks understood the current value. > > > >> About lowering the initial RTO further: I, for one, hadn't thought of > >> that, and am not fully aware of all the pro's and con's. But yeah, it > >> might be worth considering? > > > > Well, if you're not suggesting lowering the initial RTO then what are > > you suggesting? I have no idea what you are saying here. The initial > > RTO is the RTO that is used before an RTT sample is taken. So, just > > what are you suggesting here? > > > > allman > > I am suggesting: > 1st SYN contains data. > Retransmit that SYN without data after 100mS. > Make the next retransmit timer 1 second with the normal power of 2 backoff > after that. All SYN retransmits without data. > Do the same for the SYN/ACK. > No cookies. > The initial 100mS SYN retransmit timer MAY be lengthened by application > knowledge of conditions. For example, satellite or wireless. I think you consider 1 second SYN RTO is fine. But, you want to accelerate the first retransmission. This seems to be a bit inconsistent design to me. Well, it might be useful if the SYNs are discarded because of accidental packet drops or because of data payload. But, I'm still wondering how practical these situations are. Thanks, -- Yoshifumi --f46d0401f8e1ec861804d2493e67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jakob,

On Tue, Jan 1, 2013 at 9:25 PM,= Jakob Heitz <jakob.heitz@ericsson.com> wrote:
On Tuesday, January 01, 2013 6:54 P= M, mallman@icir.org <mailto:mallman@icir.org> wrote:

> I am confused.
>
>> Not sure about everyone else, but the way I interpreted (and meant= )
>> the 1s bit was to say "a new value, such as 1s, as opposed to= a
>> complex adaptive mechanism". It wasn't about the exact va= lue of 1s
>> per se.
>
> You say "a new value, such as 1s". =C2=A0My point is 1s is N= OT a new value.
> It is the standardized value. =C2=A0Before proposing some new
> value, it'd at
> least be handy if folks understood the current value.
>
>> About lowering the initial RTO further: I, for one, hadn't tho= ught of
>> that, and am not fully aware of all the pro's and con's. B= ut yeah, it
>> might be worth considering?
>
> Well, if you're not suggesting lowering the initial RTO then what = are
> you suggesting? =C2=A0I have no idea what you are saying here. =C2=A0T= he initial
> RTO is the RTO that is used before an RTT sample is taken. =C2=A0So, j= ust
> what are you suggesting here?
>
> allman

I am suggesting:
1st SYN contains data.
Retransmit that SYN without data after 100mS.
Make the next retransmit timer 1 second with the normal power of 2 backoff = after that. All SYN retransmits without data.
Do the same for the SYN/ACK.
No cookies.
The initial 100mS SYN retransmit timer MAY be lengthened by application kno= wledge of conditions. For example, satellite or wireless.
=
I think you consider 1 second SYN RTO is fine. But, you want= to accelerate the first retransmission.=C2=A0
This seems to be a bit inconsistent design t= o me.
Well, it might be useful if the S= YNs are discarded because of accidental packet drops or because of data pay= load.
But, I'm still wondering how practical t= hese situations are.=E3=80=80

Thanks,
--
Yoshifumi
--f46d0401f8e1ec861804d2493e67-- From michawe@ifi.uio.no Tue Jan 1 23:52:48 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 D677A21F910B for ; Tue, 1 Jan 2013 23:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 CYnU87Mk1+V1 for ; Tue, 1 Jan 2013 23:52:48 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 1392921F9109 for ; Tue, 1 Jan 2013 23:52:47 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TqJ7y-00086j-Ql; Wed, 02 Jan 2013 08:52:42 +0100 Received: from 089144206222.atnat0015.highway.a1.net ([89.144.206.222] helo=[192.168.1.2]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1TqJ7x-0006Bs-TL; Wed, 02 Jan 2013 08:52:42 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Michael Welzl In-Reply-To: <20130102025350.AF22755A074@lawyers.icir.org> Date: Wed, 2 Jan 2013 08:52:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2D043D15-F5B7-4568-B2FA-125EBD128215@ifi.uio.no> References: <20130102025350.AF22755A074@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.1499) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 1 sum rcpts/h 6 sum msgs/h 1 total rcpts 1056 max rcpts/h 20 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1684FBC234E27791B4B134C05B54753B23785057 X-UiO-SPAM-Test: remote_host: 89.144.206.222 spam_score: -49 maxlevel 80 minaction 2 bait 0 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm \(tcpm@ietf.org\)" , Marco Mellia , Joe Touch Subject: Re: [tcpm] About the SYN/ACK-timer 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, 02 Jan 2013 07:52:49 -0000 On Jan 2, 2013, at 3:53 AM, Mark Allman wrote: >=20 > I am confused. Apologies - see below: >> Not sure about everyone else, but the way I interpreted (and meant) >> the 1s bit was to say "a new value, such as 1s, as opposed to a >> complex adaptive mechanism". It wasn't about the exact value of 1s = per >> se.=20 >=20 > You say "a new value, such as 1s". My point is 1s is NOT a new value. > It is the standardized value. Before proposing some new value, it'd = at > least be handy if folks understood the current value. Sorry for that. I had missed the change to 1s, and so, when someone said = "shorter value, such as 1s", I said "yeah, something like that". >> About lowering the initial RTO further: I, for one, hadn't thought of >> that, and am not fully aware of all the pro's and con's. But yeah, it >> might be worth considering?=20 >=20 > Well, if you're not suggesting lowering the initial RTO then what are > you suggesting? I have no idea what you are saying here. The initial > RTO is the RTO that is used before an RTT sample is taken. So, just > what are you suggesting here? Sorry again for the confusion. I called it a SYN-ACK timer, but of = course that's the initial RTO. So yes, the idea was to lower that - but = I'd first have to look into the arguments that went into the 3s =3D> 1s = step which I had missed. Cheers, Michael From jakob.heitz@ericsson.com Wed Jan 2 00:53:38 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 9BB9621F8F43 for ; Wed, 2 Jan 2013 00:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 NuZODCpeOyvp for ; Wed, 2 Jan 2013 00:53:37 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id D0B8421F8F41 for ; Wed, 2 Jan 2013 00:53:37 -0800 (PST) Received: from EUSAAHC005.ericsson.se ([147.117.188.87]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id r0297Acf024012; Wed, 2 Jan 2013 03:07:12 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 03:53:28 -0500 From: Jakob Heitz To: Yoshifumi Nishida Thread-Topic: [tcpm] About the SYN/ACK-timer Thread-Index: AQHN6Kmen9PlwwSgXU2cX18Avy7He5g1+RIA///C3m0= Date: Wed, 2 Jan 2013 08:53:27 +0000 Message-ID: <9DF82729-E83B-4515-8BCD-D33E4EBC3E39@ericsson.com> References: <1D1BEDF8-28D1-41CD-999C-5627E81D0537@ifi.uio.no> <20130102025350.AF22755A074@lawyers.icir.org> <2F3EBB88EC3A454AAB08915FBF0B8C7E148E68@eusaamb109.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_9DF82729E83B45158BCDD33E4EBC3E39ericssoncom_" MIME-Version: 1.0 Cc: Joe Touch , "tcpm \(tcpm@ietf.org\)" , Marco Mellia , Michael Welzl , "mallman@icir.org" Subject: Re: [tcpm] About the SYN/ACK-timer 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, 02 Jan 2013 08:53:38 -0000 --_000_9DF82729E83B45158BCDD33E4EBC3E39ericssoncom_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable The reason for the accelerated first retransmission: The SYN with data may get dropped for 2 reasons. 1. Middleboxes that consider it abnormal. 2. SYN flood protection at the server. I expect SYN flood protection to be much more aggressive towards SYN packet= s with data. In the majority of cases, the SYN with data should get through just fine. W= hen it doesn't, the accelerated retransmission without the data will recove= r. Cheers, Jakob. On Jan 1, 2013, at 11:32 PM, "Yoshifumi Nishida" > wrote: Hi Jakob, On Tue, Jan 1, 2013 at 9:25 PM, Jakob Heitz > wrote: On Tuesday, January 01, 2013 6:54 PM, mallman@icir.org > wrote: > I am confused. > >> Not sure about everyone else, but the way I interpreted (and meant) >> the 1s bit was to say "a new value, such as 1s, as opposed to a >> complex adaptive mechanism". It wasn't about the exact value of 1s >> per se. > > You say "a new value, such as 1s". My point is 1s is NOT a new value. > It is the standardized value. Before proposing some new > value, it'd at > least be handy if folks understood the current value. > >> About lowering the initial RTO further: I, for one, hadn't thought of >> that, and am not fully aware of all the pro's and con's. But yeah, it >> might be worth considering? > > Well, if you're not suggesting lowering the initial RTO then what are > you suggesting? I have no idea what you are saying here. The initial > RTO is the RTO that is used before an RTT sample is taken. So, just > what are you suggesting here? > > allman I am suggesting: 1st SYN contains data. Retransmit that SYN without data after 100mS. Make the next retransmit timer 1 second with the normal power of 2 backoff = after that. All SYN retransmits without data. Do the same for the SYN/ACK. No cookies. The initial 100mS SYN retransmit timer MAY be lengthened by application kno= wledge of conditions. For example, satellite or wireless. I think you consider 1 second SYN RTO is fine. But, you want to accelerate = the first retransmission. This seems to be a bit inconsistent design to me. Well, it might be useful if the SYNs are discarded because of accidental pa= cket drops or because of data payload. But, I'm still wondering how practical these situations are.=1B$B!!=1B(B Thanks, -- Yoshifumi --_000_9DF82729E83B45158BCDD33E4EBC3E39ericssoncom_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
The reason for the accelerated first retransmission:
The SYN with data may get dropped for 2 reasons.
1. Middleboxes that consider it abnormal.
2. SYN flood protection at the server.

I expect SYN flood protection to be much more aggressive towards SYN p= ackets with data.
In the majority of cases, the SYN with data should get through just fi= ne. When it doesn't, the accelerated retransmission without the data will r= ecover.

Cheers,
Jakob.

On Jan 1, 2013, at 11:32 PM, "Yoshifumi Nishida" <nishida@sfc.wide.ad.jp> wrote:

Hi Jakob,

On Tue, Jan 1, 2013 at 9:25 PM, Jakob Heitz <jakob.hei= tz@ericsson.com> wrote:
On Tuesday, January 01, 2013 6:54 PM, mallman@icir.org <mailto:mallman= @icir.org> wrote:

> I am confused.
>
>> Not sure about everyone else, but the way I interpreted (and meant= )
>> the 1s bit was to say "a new value, such as 1s, as opposed to= a
>> complex adaptive mechanism". It wasn't about the exact value = of 1s
>> per se.
>
> You say "a new value, such as 1s".  My point is 1s is N= OT a new value.
> It is the standardized value.  Before proposing some new
> value, it'd at
> least be handy if folks understood the current value.
>
>> About lowering the initial RTO further: I, for one, hadn't thought= of
>> that, and am not fully aware of all the pro's and con's. But yeah,= it
>> might be worth considering?
>
> Well, if you're not suggesting lowering the initial RTO then what are<= br> > you suggesting?  I have no idea what you are saying here.  T= he initial
> RTO is the RTO that is used before an RTT sample is taken.  So, j= ust
> what are you suggesting here?
>
> allman

I am suggesting:
1st SYN contains data.
Retransmit that SYN without data after 100mS.
Make the next retransmit timer 1 second with the normal power of 2 backoff = after that. All SYN retransmits without data.
Do the same for the SYN/ACK.
No cookies.
The initial 100mS SYN retransmit timer MAY be lengthened by application kno= wledge of conditions. For example, satellite or wireless.

I think you consider 1 second SYN RTO is fine. But, you want to accele= rate the first retransmission. 
This seems to be a bit inconsistent design t= o me.
Well, it might be useful if the SYNs are dis= carded because of accidental packet drops or because of data payload.
But, I'm still wondering how practical these= situations are.=1B$B!!=1B(B

Thanks,
--
Yoshifumi
--_000_9DF82729E83B45158BCDD33E4EBC3E39ericssoncom_-- From michael.scharf@alcatel-lucent.com Wed Jan 2 01:02: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 5220321F907D for ; Wed, 2 Jan 2013 01:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.68 X-Spam-Level: X-Spam-Status: No, score=-7.68 tagged_above=-999 required=5 tests=[AWL=-2.031, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_33=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 7dQDE-fx6zEu for ; Wed, 2 Jan 2013 01:02:40 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6E59D21F905C for ; Wed, 2 Jan 2013 01:02:39 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0292XBx025250 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 Jan 2013 10:02:36 +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, 2 Jan 2013 10:02:35 +0100 From: "Scharf, Michael (Michael)" To: Mikael Abrahamsson Date: Wed, 2 Jan 2013 10:02:34 +0100 Thread-Topic: [tcpm] host behaviour when connectivity is lost Thread-Index: Ac3onpY3zlGbhrS3Qi+SBJFAzDH3TgAJ1IPQ Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> 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.83 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 02 Jan 2013 09:02:41 -0000 > > A potentially interesting field that could be relevant to TCPM is=20 > > whether TCP's timer management can be further improved=20 > after a system=20 > > resume, i. e., bullet point b) in your list. However, my=20 > assumption is=20 > > that the typical implementations of retransmission timers=20 > inside an OS=20 > > automatically fire after a system resume. If so, objective b) might=20 > > already be realized by TCP stacks as of today. But I might be wrong. >=20 > My thinking is if there is TCP standardization/guidance=20 > needed for what the TCP timers should be set to when a system=20 > is resumed from hibernation or when know network loss is rectified. I think that these are two different cases. There has been a lot of work on improving TCP during periods of disconnecti= vity in the last decade, mostly driven by mobile use. In contrast, I am not= really aware of work on hibernation. > There has been a lot of discussion on retransmission timers=20 > for SYN+ACK packets here recently, I feel that giving=20 > guidance on what timers should be after prolonged network=20 > connectivity loss or sleep as well. Keeping it at real time=20 > clock values what it should have been if this was just silent=20 > packet loss seems overly conservative (we know network was=20 > out, it's now most likely not, keeping retransmission timers=20 Well, a TCP instance can hardly know this without cross-layer triggers - ye= t another area that was (not really sucessfully) investigated a lot in the = last decade. > in the tens of minutes is not helping anyone), and putting=20 > them into repeatedly fast-retransmit seems overly aggressive.=20 > Off the top of my head, I'd say putting them into somewhere=20 > around 1 second retransmit time range sounds plausable. But=20 > this is what I want to discuss. Before discussing solutions, it would make sense to provide first real-worl= d data showing that there is indeed a TCP problem. For instance, to me it would be really useful to see some explanation how r= elavant TCP stacks deal with hibernation, and how suboptimal their timers a= re in reality. Also, potential guidance in that space has to be realistic, = i. e., it must take into account the actual constraints inside a real TCP s= tack. So, we have to understand these constraints. Michael > > In short, in TCPM you should explain what is indeed missing=20 > in the TCP standards. >=20 > Guidance on timers, at least. Perhaps also guidance that=20 > having an operating system interface for userspace=20 > applications (perhaps a connection manager) is a good idea to=20 > indicate that TCP timers should be put into "network=20 > connectivity problem gone, please try to see what TCP=20 > sessions are still valid" (and how to do this) and have TCP=20 > lower timers and send packets that need sending, in a=20 > reasonable time (and define what is reasonable). >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > = From michael.scharf@alcatel-lucent.com Wed Jan 2 01:35: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 EFE4321F9048 for ; Wed, 2 Jan 2013 01:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.861 X-Spam-Level: X-Spam-Status: No, score=-9.861 tagged_above=-999 required=5 tests=[AWL=0.388, 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 LVmeOoq8XF55 for ; Wed, 2 Jan 2013 01:35:53 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6DE21F9043 for ; Wed, 2 Jan 2013 01:35:51 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r029ZPs7032240 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 Jan 2013 10:35:44 +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, 2 Jan 2013 10:35:36 +0100 From: "Scharf, Michael (Michael)" To: Jakob Heitz , Yoshifumi Nishida Date: Wed, 2 Jan 2013 10:35:35 +0100 Thread-Topic: [tcpm] About the SYN/ACK-timer Thread-Index: AQHN6Kmen9PlwwSgXU2cX18Avy7He5g1+RIA///C3m2AAAWQIA== Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4F@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <1D1BEDF8-28D1-41CD-999C-5627E81D0537@ifi.uio.no> <20130102025350.AF22755A074@lawyers.icir.org> <2F3EBB88EC3A454AAB08915FBF0B8C7E148E68@eusaamb109.ericsson.se>, <9DF82729-E83B-4515-8BCD-D33E4EBC3E39@ericsson.com> In-Reply-To: <9DF82729-E83B-4515-8BCD-D33E4EBC3E39@ericsson.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="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "tcpm \(tcpm@ietf.org\)" , "mallman@icir.org" , Michael Welzl , Marco Mellia , Joe Touch Subject: Re: [tcpm] About the SYN/ACK-timer 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, 02 Jan 2013 09:35:54 -0000 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Jakob Heitz > Sent: Wednesday, January 02, 2013 9:53 AM > To: Yoshifumi Nishida > Cc: Joe Touch; tcpm (tcpm@ietf.org); Marco Mellia; Michael=20 > Welzl; mallman@icir.org > Subject: Re: [tcpm] About the SYN/ACK-timer >=20 > The reason for the accelerated first retransmission: > The SYN with data may get dropped for 2 reasons. > 1. Middleboxes that consider it abnormal. If there is such a middlebox, the best solution is to try to learn that and= cache it, on order to avoid the use of SYN data at all. This is mostly ort= hogonal to the retransmission timer. Except for one detail: The smaller the= gap between the two transmissions, the higher is the risk of reordering, i= . e., that such heuristics break because the RTO is *too* small. Thus, acce= lerated first retranmission can indeed have drawbacks with middleboxes... A= nd, with an initial RTO of 1s, the only penalty is the 1s timeout for the f= irst connection. After that, the sender would hopefully not use SYN data an= y more. So, what remains is the 1s RTO for the first connection to that destination= . An initial timeout below one second to an unknown destination comes along= with quite some risk of spuriour retransmission on narrow-band links. It m= ight not be a too good idea because of that. > 2. SYN flood protection at the server. I might miss something fundamental, but if a server is in SYN flood protect= ion mode, would it not be a good idea if the client backs off a bit? Using = a 100ms timer is quite the opposite of that. In summary, it is not clear to me what actual problem we discuss here. For what it is worth, as already mentioned multiple times: There is a TCPM = working group item draft-ietf-tcpm-fastopen, which has quite some related t= ext, including the initial RTO. Michael =20 > I expect SYN flood protection to be much more aggressive=20 > towards SYN packets with data. > In the majority of cases, the SYN with data should get=20 > through just fine. When it doesn't, the accelerated=20 > retransmission without the data will recover. >=20 > Cheers, > Jakob. >=20 > On Jan 1, 2013, at 11:32 PM, "Yoshifumi Nishida"=20 > wrote: >=20 >=20 >=20 > Hi Jakob, > =09 > =09 > On Tue, Jan 1, 2013 at 9:25 PM, Jakob Heitz=20 > wrote: > =09 >=20 > On Tuesday, January 01, 2013 6:54 PM,=20 > mallman@icir.org =20 > wrote: > =09 > > I am confused. > > > >> Not sure about everyone else, but the way I=20 > interpreted (and meant) > >> the 1s bit was to say "a new value, such as=20 > 1s, as opposed to a > >> complex adaptive mechanism". It wasn't about=20 > the exact value of 1s > >> per se. > > > > You say "a new value, such as 1s". My point=20 > is 1s is NOT a new value. > > It is the standardized value. Before=20 > proposing some new > > value, it'd at > > least be handy if folks understood the current value. > > > >> About lowering the initial RTO further: I,=20 > for one, hadn't thought of > >> that, and am not fully aware of all the=20 > pro's and con's. But yeah, it > >> might be worth considering? > > > > Well, if you're not suggesting lowering the=20 > initial RTO then what are > > you suggesting? I have no idea what you are=20 > saying here. The initial > > RTO is the RTO that is used before an RTT=20 > sample is taken. So, just > > what are you suggesting here? > > > > allman > =09 > =09 > I am suggesting: > 1st SYN contains data. > Retransmit that SYN without data after 100mS. > Make the next retransmit timer 1 second with=20 > the normal power of 2 backoff after that. All SYN retransmits=20 > without data. > Do the same for the SYN/ACK. > No cookies. > The initial 100mS SYN retransmit timer MAY be=20 > lengthened by application knowledge of conditions. For=20 > example, satellite or wireless. >=20 >=20 > I think you consider 1 second SYN RTO is fine. But, you=20 > want to accelerate the first retransmission.=20 > This seems to be a bit inconsistent design to me. > Well, it might be useful if the SYNs are discarded=20 > because of accidental packet drops or because of data payload. > But, I'm still wondering how practical these situations are.=1B$B!!=1B(B >=20 > Thanks, > -- > Yoshifumi >=20 > = From swmike@swm.pp.se Wed Jan 2 05:06: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 0C42021F9032 for ; Wed, 2 Jan 2013 05:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190, 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 VddtVQ0TtGay for ; Wed, 2 Jan 2013 05:06:35 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id F28EE21F9030 for ; Wed, 2 Jan 2013 05:06:34 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id EC72B9C; Wed, 2 Jan 2013 14:06:32 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E522A9A; Wed, 2 Jan 2013 14:06:32 +0100 (CET) Date: Wed, 2 Jan 2013 14:06:32 +0100 (CET) From: Mikael Abrahamsson To: "Scharf, Michael (Michael)" In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Message-ID: References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 02 Jan 2013 13:06:36 -0000 On Wed, 2 Jan 2013, Scharf, Michael (Michael) wrote: > Before discussing solutions, it would make sense to provide first > real-world data showing that there is indeed a TCP problem. Well, as I stated in my original email, I have this problem all the time when I resume my Ubuntu 12.04 machine (and the behaviour has been identical since 8.04 or 8.10 when I first started running ubuntu on this laptop), I have to kill my ssh client because TCP is "stuck". The other end has long ago closed its end of the session, but my end hasn't noticed and even if I wait several minutes, it won't. My experience is that Windows (XP and 7) in case of resume will just kill all TCP sessions, which I don't think is optimal either. I know several applications that run their own keep-alive on top of TCP just to workaround TCP behaviour (the way TCP was designed to stay alive and be network-friendly with re-transmit timers in tens of minutes or even hours and basically never timeot) which might make sense for some applications, but is not really what the user needs in case of interactive application using TCP. > For instance, to me it would be really useful to see some explanation > how relavant TCP stacks deal with hibernation, and how suboptimal their > timers are in reality. Also, potential guidance in that space has to be > realistic, i. e., it must take into account the actual constraints > inside a real TCP stack. So, we have to understand these constraints. http://www.pcvr.nl/tcpip/tcp_time.htm was one document I found discussing this, claiming in this particular test that 64 seconds is the maximum retransmission timer. I'll do some tests and see if my ubuntu machine has approximately the same value. When waiting after a resume this 64 seconds feels like an eternity anyway :P -- Mikael Abrahamsson email: swmike@swm.pp.se From mellia@tlc.polito.it Wed Jan 2 05:30: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 9C6A221F8DE6 for ; Wed, 2 Jan 2013 05:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.119 X-Spam-Level: X-Spam-Status: No, score=-4.119 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_33=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 5c3mD6b8sn8X for ; Wed, 2 Jan 2013 05:30:51 -0800 (PST) Received: from frontmail1.polito.it (frontmail1.polito.it [130.192.180.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8871721F8E0E for ; Wed, 2 Jan 2013 05:30:51 -0800 (PST) X-ExtScanner: Niversoft's FindAttachments (free) Received: from [151.33.184.161] (account d003516@polito.it HELO [192.168.1.7]) by frontmail1.polito.it (CommuniGate Pro SMTP 5.4.6) with ESMTPSA id 61934492; Wed, 02 Jan 2013 14:30:49 +0100 Received-SPF: none receiver=frontmail1.polito.it; client-ip=151.33.184.161; envelope-from=mellia@tlc.polito.it Message-ID: <50E43675.4020106@tlc.polito.it> Date: Wed, 02 Jan 2013 14:30:29 +0100 From: Marco Mellia User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Michael Welzl References: <20130102025350.AF22755A074@lawyers.icir.org> <2D043D15-F5B7-4568-B2FA-125EBD128215@ifi.uio.no> In-Reply-To: <2D043D15-F5B7-4568-B2FA-125EBD128215@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Joe Touch , "tcpm \(tcpm@ietf.org\)" , mallman@icir.org Subject: Re: [tcpm] About the initial SYN/ACK RTO 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, 02 Jan 2013 13:30:52 -0000 FYI, here are some old slides on the topic http://www.ietf.org/proceedings/75/slides/tcpm-1.pdf and here you can find how to play with the initial RTO on MS Windows http://support.microsoft.com/kb/170359/en-us and more tweaks are here http://technet.microsoft.com/en-us/library/cc739819(v=ws.10).aspx Honestly, 1s as initial RTO seems a good and safe choice. Going below 1s as default value seems really not a good idea, especially considering that from the user perspective, little is gained. The "SYN with data" looks like a very complicated stuff, that in most of the cases would allow to gain 10ms or so (i.e., one RTT), with a lot of problems that will arise with incompatible middleboxes, incompatible implementation, etc.etc. To me it seems not worth. Consider this my 2c tip. Ciao M > Sorry again for the confusion. I called it a SYN-ACK timer, but of course that's the initial RTO. So yes, the idea was to lower that - but I'd first have to look into the arguments that went into the 3s => 1s step which I had missed. > > Cheers, > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- Ciao, /\/\/\rco +-----------------------------------+ | Marco Mellia - Assistant Professor| | Skypeid: mgmellia | | Tel: +39-011-090-4173 | | Cel: +39-331-6714789 | /"\ .. . . . . . . . . . . . . | Politecnico di Torino | \ / . ASCII Ribbon Campaign . | Corso Duca degli Abruzzi 24 | X .- NO HTML/RTF in e-mail . | Torino - 10129 - Italy | / \ .- NO Word docs in e-mail. | http://www.telematica.polito.it | .. . . . . . . . . . . . . +-----------------------------------+ The box said "Requires Windows 95 or Better." So I installed Linux. From ycheng@google.com Wed Jan 2 09:40: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 8214721F86C2 for ; Wed, 2 Jan 2013 09:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.144 X-Spam-Level: X-Spam-Status: No, score=-102.144 tagged_above=-999 required=5 tests=[AWL=-0.834, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 MKTGYKG+DdMz for ; Wed, 2 Jan 2013 09:40:43 -0800 (PST) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by ietfa.amsl.com (Postfix) with ESMTP id 91F8321F850C for ; Wed, 2 Jan 2013 09:40:43 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id dn14so12986423obc.16 for ; Wed, 02 Jan 2013 09:40:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nJ4BNcbyu8omFi4hDC0UQe5HgFVlbJ38276xMZ4uPQM=; b=auU57ov+qUmFoY1DNZiaLqtu5qLnoPDoPZJFzE9HMnWpGKj/dft/OZtrv+sabFsbOZ KSmZlSXxvB7q2KP/zU9e+xwPgNF2GFVYl2SW0+Kj36RQeZ44c1ySr1njpl+eCF/isjfp GlOSVKMjAyll8gvguRN6RNTi9l6wPrds9a/28W7/dMOw/2MsXUl7tUcvG+4ROYL907BI C7L6I7a63/R3fikPmYRYxy6qbycbkuni/7XkGWqJlIp5Itr6TV1kU4AIOVHUd7t09h+G xFMx6PRFQomY4q3DENm0cY8rLqPySuGZXG9YuMF5ptPY4nDLwR7qirnySbzaZN7fSJnQ 6DmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=nJ4BNcbyu8omFi4hDC0UQe5HgFVlbJ38276xMZ4uPQM=; b=W1aAwRdmwyObru3irdabNIKyDYjgn9UrKSTeNEytMyZSo/EIslhfFEXVzkyJtDhr+l ar7fyI621sbhWWPUA/XHr02KCw2K3b/NJmQat/8SfOnNrDRU8o/6aRwtJm1HuIcE7UdD P+Lk4rHVcJ71gbI5CBIFD71Ebr7/Kcn9GfgSxh6CR8wZgOBKHtNd465fHmL4IcjZKE43 9JkV4zSd+yEGk60koZjd6Huz7jkIDHdzE06juBWhun2OeGeaf8gymHmwmDtsD2MvB5zQ iKSUZO82T1fS8WR9SnSm0MWD4jOM30Yk5or9ny5CWa3Jpz8hqiCoZXlmvoKx7pkcu1co mQZg== Received: by 10.182.235.46 with SMTP id uj14mr37499737obc.40.1357148443017; Wed, 02 Jan 2013 09:40:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.82.39 with HTTP; Wed, 2 Jan 2013 09:40:22 -0800 (PST) In-Reply-To: References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> From: Yuchung Cheng Date: Wed, 2 Jan 2013 09:40:22 -0800 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=14dae93b6024da807304d251beec X-Gm-Message-State: ALoCoQmiCvFtnkXJ/95J2EGQzWIkJoN+zuZ28o27ZGONQxCY9Y8sMJuDCEIBVlILDl2ezCRJGo9KplKQkp785z48DVW/aQ039SP5Oa8PLryLuc8DgnNuqms9KsxumQ/3u4xa1pleRjI5yV1f71LwoF3xs9uDl9AT9xHx9e+UB3mTeGZrQqKABV7XoTPf0NRvH/0EzEcC5jH1 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 02 Jan 2013 17:40:44 -0000 --14dae93b6024da807304d251beec Content-Type: text/plain; charset=ISO-8859-1 You might find this RFC relevant. http://tools.ietf.org/html/rfc5482 On Wed, Jan 2, 2013 at 5:06 AM, Mikael Abrahamsson wrote: > On Wed, 2 Jan 2013, Scharf, Michael (Michael) wrote: > > Before discussing solutions, it would make sense to provide first >> real-world data showing that there is indeed a TCP problem. >> > > Well, as I stated in my original email, I have this problem all the time > when I resume my Ubuntu 12.04 machine (and the behaviour has been identical > since 8.04 or 8.10 when I first started running ubuntu on this laptop), I > have to kill my ssh client because TCP is "stuck". The other end has long > ago closed its end of the session, but my end hasn't noticed and even if I > wait several minutes, it won't. > > My experience is that Windows (XP and 7) in case of resume will just kill > all TCP sessions, which I don't think is optimal either. > > I know several applications that run their own keep-alive on top of TCP > just to workaround TCP behaviour (the way TCP was designed to stay alive > and be network-friendly with re-transmit timers in tens of minutes or even > hours and basically never timeot) which might make sense for some > applications, but is not really what the user needs in case of interactive > application using TCP. > > > For instance, to me it would be really useful to see some explanation how >> relavant TCP stacks deal with hibernation, and how suboptimal their timers >> are in reality. Also, potential guidance in that space has to be realistic, >> i. e., it must take into account the actual constraints inside a real TCP >> stack. So, we have to understand these constraints. >> > > http://www.pcvr.nl/tcpip/tcp_**time.htmwas one document I found discussing this, claiming in this particular test > that 64 seconds is the maximum retransmission timer. I'll do some tests and > see if my ubuntu machine has approximately the same value. When waiting > after a resume this 64 seconds feels like an eternity anyway :P > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > ______________________________**_________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/**listinfo/tcpm > --14dae93b6024da807304d251beec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
You might find this RFC relev= ant.
http://tools.ietf.org/html/rfc5482


O= n Wed, Jan 2, 2013 at 5:06 AM, Mikael Abrahamsson <swmike@swm.pp.se>= wrote:
On Wed, 2 Jan 2013, Scharf= , Michael (Michael) wrote:

Before discussing solutions, it would make sense to provide first real-worl= d data showing that there is indeed a TCP problem.

Well, as I stated in my original email, I have this problem all the time wh= en I resume my Ubuntu 12.04 machine (and the behaviour has been identical s= ince 8.04 or 8.10 when I first started running ubuntu on this laptop), I ha= ve to kill my ssh client because TCP is "stuck". The other end ha= s long ago closed its end of the session, but my end hasn't noticed and= even if I wait several minutes, it won't.

My experience is that Windows (XP and 7) in case of resume will just kill a= ll TCP sessions, which I don't think is optimal either.

I know several applications that run their own keep-alive on top of TCP jus= t to workaround TCP behaviour (the way TCP was designed to stay alive and b= e network-friendly with re-transmit timers in tens of minutes or even hours= and basically never timeot) which might make sense for some applications, = but is not really what the user needs in case of interactive application us= ing TCP.


For instance, to me it would be really useful to see some explanation how r= elavant TCP stacks deal with hibernation, and how suboptimal their timers a= re in reality. Also, potential guidance in that space has to be realistic, = i. e., it must take into account the actual constraints inside a real TCP s= tack. So, we have to understand these constraints.

h= ttp://www.pcvr.nl/tcpip/tcp_time.htm was one document I found di= scussing this, claiming in this particular test that 64 seconds is the maxi= mum retransmission timer. I'll do some tests and see if my ubuntu machi= ne has approximately the same value. When waiting after a resume this 64 se= conds feels like an eternity anyway :P


--
Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se
_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--14dae93b6024da807304d251beec-- From swmike@swm.pp.se Wed Jan 2 09:55: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 2034021F86CB for ; Wed, 2 Jan 2013 09:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 mtgOsswMgxQM for ; Wed, 2 Jan 2013 09:55:29 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 11F2E21F86C3 for ; Wed, 2 Jan 2013 09:55:28 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 444B49C; Wed, 2 Jan 2013 18:55:27 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 37C069A for ; Wed, 2 Jan 2013 18:55:27 +0100 (CET) Date: Wed, 2 Jan 2013 18:55:27 +0100 (CET) From: Mikael Abrahamsson To: "tcpm@ietf.org" In-Reply-To: Message-ID: References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 02 Jan 2013 17:55:30 -0000 On Wed, 2 Jan 2013, Yuchung Cheng wrote: Yes, it's relevant and it would help this very specific use-case if SSH implemented RFC5482. However, I still feel that the overall problem would be better adressed by the TCP stack being able to understand that "network connectivity was down, now it's up again, time to wake up all connections and see if they're still valid" and not treat each TCP connection like ships in the night. I imagine this would be triggered by for instance a connection manager re-connecting to a network and determining that it seems to have full connectivity, then it would signal the TCP stack to take action on all existing TCP connections. I seem to have problem even getting agreement about my problem statement, am I really that far off, none of you here see the same problem I do? > You might find this RFC relevant. > http://tools.ietf.org/html/rfc5482 > > > On Wed, Jan 2, 2013 at 5:06 AM, Mikael Abrahamsson wrote: > >> On Wed, 2 Jan 2013, Scharf, Michael (Michael) wrote: >> >> Before discussing solutions, it would make sense to provide first >>> real-world data showing that there is indeed a TCP problem. >>> >> >> Well, as I stated in my original email, I have this problem all the time >> when I resume my Ubuntu 12.04 machine (and the behaviour has been identical >> since 8.04 or 8.10 when I first started running ubuntu on this laptop), I >> have to kill my ssh client because TCP is "stuck". The other end has long >> ago closed its end of the session, but my end hasn't noticed and even if I >> wait several minutes, it won't. >> >> My experience is that Windows (XP and 7) in case of resume will just kill >> all TCP sessions, which I don't think is optimal either. >> >> I know several applications that run their own keep-alive on top of TCP >> just to workaround TCP behaviour (the way TCP was designed to stay alive >> and be network-friendly with re-transmit timers in tens of minutes or even >> hours and basically never timeot) which might make sense for some >> applications, but is not really what the user needs in case of interactive >> application using TCP. >> >> >> For instance, to me it would be really useful to see some explanation how >>> relavant TCP stacks deal with hibernation, and how suboptimal their timers >>> are in reality. Also, potential guidance in that space has to be realistic, >>> i. e., it must take into account the actual constraints inside a real TCP >>> stack. So, we have to understand these constraints. >>> >> >> http://www.pcvr.nl/tcpip/tcp_**time.htmwas one document I found discussing this, claiming in this particular test >> that 64 seconds is the maximum retransmission timer. I'll do some tests and >> see if my ubuntu machine has approximately the same value. When waiting >> after a resume this 64 seconds feels like an eternity anyway :P >> >> >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se >> ______________________________**_________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/**listinfo/tcpm >> > -- Mikael Abrahamsson email: swmike@swm.pp.se From touch@isi.edu Wed Jan 2 10:38: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 1510821F882E for ; Wed, 2 Jan 2013 10:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.945 X-Spam-Level: X-Spam-Status: No, score=-104.945 tagged_above=-999 required=5 tests=[AWL=1.654, 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 je0Jkovv8Igz for ; Wed, 2 Jan 2013 10:38:46 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6F421F882C for ; Wed, 2 Jan 2013 10:38:45 -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 r02IbsME015383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Jan 2013 10:37:54 -0800 (PST) Message-ID: <50E47E82.8030407@isi.edu> Date: Wed, 02 Jan 2013 10:37:54 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> 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] host behaviour when connectivity is lost 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, 02 Jan 2013 18:38:47 -0000 Hi, all, FWIW: - TCP has a "keepalive" setting, which (if enabled) will kill a connection whose interface is down - in the absence of that setting, it is a key "feature" of TCP that a connection can be idle for an arbitrary period of time (if there is no outstanding unack'd data) without any packet exchanges - TCP state isn't generally 'cleaned up' until it interferes with a new connection; it is at that time that the old connection state is discarded So I'm not clear on what "stuck" means for a TCP connection in this context. If host connectivity is lost and re-established later, the connection can resume. PS - the IETF has claimed in the past that it doesn't standardize OS interfaces (I agree), but IMO the result is that they too often ignore a critical interface of a protocol. E.g., TCP doesn't define a POSIX socket interface, but does define a set of commands as interface to the upper layer - OPEN, CLOSE, LISTEN, etc. (which are similar to the socket interface, but not identical). Such interfaces are critical and help define the protocol's semantics; it's not appropriate to assume they can be changed without impact. Joe From jakob.heitz@ericsson.com Wed Jan 2 10:57: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 CBBEF21F86A2 for ; Wed, 2 Jan 2013 10:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 hYyE4qp4Yv0m for ; Wed, 2 Jan 2013 10:57:28 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0C61521F86A1 for ; Wed, 2 Jan 2013 10:57:27 -0800 (PST) Received: from EUSAAHC007.ericsson.se ([147.117.188.93]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id r02JB3et009348; Wed, 2 Jan 2013 13:11:04 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 13:57:17 -0500 From: Jakob Heitz To: "Scharf, Michael (Michael)" , "Yoshifumi Nishida" Thread-Topic: [tcpm] About the SYN/ACK-timer Thread-Index: AQHN6Kmen9PlwwSgXU2cX18Avy7He5g1+RIA///C3m2AAAWQIIAAm/sQ Date: Wed, 2 Jan 2013 18:57:17 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E14A253@eusaamb109.ericsson.se> References: <1D1BEDF8-28D1-41CD-999C-5627E81D0537@ifi.uio.no> <20130102025350.AF22755A074@lawyers.icir.org> <2F3EBB88EC3A454AAB08915FBF0B8C7E148E68@eusaamb109.ericsson.se>, <9DF82729-E83B-4515-8BCD-D33E4EBC3E39@ericsson.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4F@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4F@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" , "mallman@icir.org" , Michael Welzl , Marco Mellia , Joe Touch Subject: Re: [tcpm] About the SYN/ACK-timer 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, 02 Jan 2013 18:57:28 -0000 On Wednesday, January 02, 2013 1:36 AM, Scharf, Michael (Michael) <> wrote: >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf >> Of Jakob Heitz Sent: Wednesday, January 02, 2013 9:53 AM >> To: Yoshifumi Nishida >> Cc: Joe Touch; tcpm (tcpm@ietf.org); Marco Mellia; Michael Welzl; >> mallman@icir.org Subject: Re: [tcpm] About the SYN/ACK-timer >>=20 >> The reason for the accelerated first retransmission: >> The SYN with data may get dropped for 2 reasons. >> 1. Middleboxes that consider it abnormal. >=20 > If there is such a middlebox, the best solution is to try to > learn that and cache it, on order to avoid the use of SYN > data at all. Of course it is, but there is no need to standardize that. > This is mostly orthogonal to the retransmission > timer. Except for one detail: The smaller the gap between the > two transmissions, the higher is the risk of reordering, i. > e., that such heuristics break because the RTO is *too* > small. Thus, accelerated first retranmission can indeed have > drawbacks with middleboxes... no. It will pass the lone SYN (misordered, arrives first) Then it will drop the SYN with data. No harm done. > And, with an initial RTO of 1s, > the only penalty is the 1s timeout for the first connection. > After that, the sender would hopefully not use SYN data any more. >=20 > So, what remains is the 1s RTO for the first connection to > that destination. An initial timeout below one second to an > unknown destination comes along with quite some risk of > spuriour retransmission on narrow-band links. It might not be > a too good idea because of that. >=20 >> 2. SYN flood protection at the server. >=20 > I might miss something fundamental, but if a server is in SYN > flood protection mode, would it not be a good idea if the > client backs off a bit? During SYN flood protection, I'm assuming the server will aggressively drop SYN with data, but accept SYN without data more readily. Therefore, retransmit the SYN without data, then back off as normal. > Using a 100ms timer is quite the > opposite of that. >=20 > In summary, it is not clear to me what actual problem we discuss here. >=20 > For what it is worth, as already mentioned multiple times: > There is a TCPM working group item draft-ietf-tcpm-fastopen, > which has quite some related text, including the initial RTO. I'm aware of it. I don't like the cookie idea. It was a great initial idea, but got complicated and incomplete in a hurry. I am not proposing an initial RTO of 100mS. I am proposing a single retransmission of the SYN without data at 100mS. There is a difference. >=20 > Michael >=20 >=20 >> I expect SYN flood protection to be much more aggressive >> towards SYN packets with data. >> In the majority of cases, the SYN with data should get >> through just fine. When it doesn't, the accelerated >> retransmission without the data will recover. >>=20 >> Cheers, >> Jakob. >>=20 >> On Jan 1, 2013, at 11:32 PM, "Yoshifumi Nishida" >> wrote: >>=20 >>=20 >>=20 >> Hi Jakob, >>=20 >>=20 >> On Tue, Jan 1, 2013 at 9:25 PM, Jakob Heitz >> wrote: >>=20 >>=20 >> On Tuesday, January 01, 2013 6:54 PM, >> mallman@icir.org >> wrote: >>=20 >> > I am confused. >> > >> >> Not sure about everyone else, but the way I >> interpreted (and meant) >> >> the 1s bit was to say "a new value, such as >> 1s, as opposed to a >> >> complex adaptive mechanism". It wasn't about >> the exact value of 1s >> >> per se. >> > >> > You say "a new value, such as 1s". My point >> is 1s is NOT a new value. >> > It is the standardized value. Before >> proposing some new >> > value, it'd at >> > least be handy if folks understood the current value. > >> >> About lowering the initial RTO further: I, >> for one, hadn't thought of >> >> that, and am not fully aware of all the >> pro's and con's. But yeah, it >> >> might be worth considering? >> > >> > Well, if you're not suggesting lowering the >> initial RTO then what are >> > you suggesting? I have no idea what you are >> saying here. The initial >> > RTO is the RTO that is used before an RTT >> sample is taken. So, just >> > what are you suggesting here? >> > >> > allman >>=20 >>=20 >> I am suggesting: >> 1st SYN contains data. >> Retransmit that SYN without data after 100mS. >> Make the next retransmit timer 1 second with >> the normal power of 2 backoff after that. All SYN retransmits >> without data. Do the same for the SYN/ACK. >> No cookies. >> The initial 100mS SYN retransmit timer MAY be >> lengthened by application knowledge of conditions. For >> example, satellite or wireless. >>=20 >>=20 >> I think you consider 1 second SYN RTO is fine. But, you >> want to accelerate the first retransmission. >> This seems to be a bit inconsistent design to me. >> Well, it might be useful if the SYNs are discarded >> because of accidental packet drops or because of data payload. >> But, I'm still wondering how practical these situations are. >>=20 >> Thanks, >> -- >> Yoshifumi --=20 Jakob Heitz. x25475. 510-566-2901 From swmike@swm.pp.se Wed Jan 2 11:14: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 B241321F876E for ; Wed, 2 Jan 2013 11:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 kXWBbz7g+k6C for ; Wed, 2 Jan 2013 11:14:33 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 23B0A21F86B2 for ; Wed, 2 Jan 2013 11:14:32 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C3A749C; Wed, 2 Jan 2013 20:14:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BDCBD9A; Wed, 2 Jan 2013 20:14:31 +0100 (CET) Date: Wed, 2 Jan 2013 20:14:31 +0100 (CET) From: Mikael Abrahamsson To: Joe Touch In-Reply-To: <50E47E82.8030407@isi.edu> Message-ID: References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@isi.edu> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 02 Jan 2013 19:14:33 -0000 On Wed, 2 Jan 2013, Joe Touch wrote: > - TCP state isn't generally 'cleaned up' until it interferes with a new > connection; it is at that time that the old connection state is discarded > > So I'm not clear on what "stuck" means for a TCP connection in this context. > If host connectivity is lost and re-established later, the connection can > resume. Yes, but how long does it take for it to resume? I want my TCP sessions to be either reset (if they're not up at both ends) or taking traffic (which means they're not in 64s retransmit timer mode) when my connection manager has deemed that my network connectivity is up and running again. "Happy Eyeballs" was invented to remove a lot of interactive user delay when it came to dysfunctioning IPv4 or IPv6. I would like to see similar work done for TCP when it comes to network connectivity being re-established. For my interactive sessions, I don't want to wait up to 64s for it to decide if the session is down at the other end or not after a known outage (suspend/hibernate or other network outage that can be detected by the host). -- Mikael Abrahamsson email: swmike@swm.pp.se From touch@isi.edu Wed Jan 2 11:21: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 BECD621F84EA for ; Wed, 2 Jan 2013 11:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.002 X-Spam-Level: X-Spam-Status: No, score=-103.002 tagged_above=-999 required=5 tests=[AWL=-0.403, 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 IZ63su2xSWw5 for ; Wed, 2 Jan 2013 11:21:03 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A858F21F84E0 for ; Wed, 2 Jan 2013 11:21:02 -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 r02JKKfI002101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Jan 2013 11:20:20 -0800 (PST) Message-ID: <50E48874.9030906@isi.edu> Date: Wed, 02 Jan 2013 11:20:20 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@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] host behaviour when connectivity is lost 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, 02 Jan 2013 19:21:04 -0000 On 1/2/2013 11:14 AM, Mikael Abrahamsson wrote: > On Wed, 2 Jan 2013, Joe Touch wrote: > >> - TCP state isn't generally 'cleaned up' until it interferes with a >> new connection; it is at that time that the old connection state is >> discarded >> >> So I'm not clear on what "stuck" means for a TCP connection in this >> context. If host connectivity is lost and re-established later, the >> connection can resume. > > Yes, but how long does it take for it to resume? I want my TCP sessions > to be either reset (if they're not up at both ends) or taking traffic > (which means they're not in 64s retransmit timer mode) when my > connection manager has deemed that my network connectivity is up and > running again. Why not just set the TCP to "keepalive" and set the interval you want? Why rely on a separate mechanism to do this when it's already there? > "Happy Eyeballs" was invented to remove a lot of interactive user delay > when it came to dysfunctioning IPv4 or IPv6. I would like to see similar > work done for TCP when it comes to network connectivity being > re-established. It's already there for apps that want it. Note that some apps either don't care or don't want this sort of behavior, though. > For my interactive sessions, I don't want to wait up to > 64s for it to decide if the session is down at the other end or not > after a known outage (suspend/hibernate or other network outage that can > be detected by the host). See above ;-) Joe From prvs=971440e0cf=david.borman@quantum.com Wed Jan 2 11:24: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 6F61921F8751 for ; Wed, 2 Jan 2013 11:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 0SyxIl0E5nuz for ; Wed, 2 Jan 2013 11:24:30 -0800 (PST) Received: from mx0a-000ceb01.pphosted.com (mx0a-000ceb01.pphosted.com [67.231.144.126]) by ietfa.amsl.com (Postfix) with ESMTP id ACF1021F84E0 for ; Wed, 2 Jan 2013 11:24:29 -0800 (PST) Received: from pps.filterd (m0030277 [127.0.0.1]) by mx0a-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id r02JMd3X016877; Wed, 2 Jan 2013 11:24:26 -0800 Received: from ppoxedge1.quantum.com ([146.174.252.27]) by mx0a-000ceb01.pphosted.com with ESMTP id 19kg3k3qpv-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 02 Jan 2013 11:24:26 -0800 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE1.quantum.com (146.174.252.27) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 2 Jan 2013 12:24:11 -0700 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.02.0318.001; Wed, 2 Jan 2013 12:24:24 -0700 From: David Borman To: Mikael Abrahamsson Thread-Topic: [tcpm] host behaviour when connectivity is lost Thread-Index: AQHN6R6+TT1L8EL2OUeJaR/akUkDwg== Date: Wed, 2 Jan 2013 19:24:11 +0000 Message-ID: References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <41367CB5FC401F47AB81DCEF758B762A@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-02_08:2012-12-31, 2013-01-02, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1301020193 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 02 Jan 2013 19:24:32 -0000 On Jan 2, 2013, at 7:06 AM, Mikael Abrahamsson wrote: > On Wed, 2 Jan 2013, Scharf, Michael (Michael) wrote: >=20 >> Before discussing solutions, it would make sense to provide first real-w= orld data showing that there is indeed a TCP problem. >=20 > Well, as I stated in my original email, I have this problem all the time = when I resume my Ubuntu 12.04 machine (and the behaviour has been identical= since 8.04 or 8.10 when I first started running ubuntu on this laptop), I = have to kill my ssh client because TCP is "stuck". The other end has long a= go closed its end of the session, but my end hasn't noticed and even if I w= ait several minutes, it won't. There has to be unacknowledged data for TCP to notice that the other side h= as gone away. If everything is working properly, when you resume your mach= ine, in an interactive SSH session if you type new data, TCP should send th= at off, and the other side should send back an immediate TCP reset because = the connection no longer exists on the other side. However, if no reset is= received, the TCP connection will go through the normal TCP exponential ba= ck-off and retransmits until it gives up and drops the connection. The pri= mary reasons why you wouldn't get the reset is that the remote host is down= or unreachable, or some middle box in the path is silently dropping the pa= ckets because it no longer has, or never had, state information for that co= nnection. Keep in mind that even if TCP gets an ICMP Host Unreachable mess= age, it'll typically treat that as a soft error and continue trying to send= the data until it times out, then when it eventually does time out, it'll = report it as a host unreachable instead of timed out. Of course, if there is no data to send, TCP won't discover that the connect= ion is dead. That's exactly the scenario why people added Keep-Alive timer= s into TCP, to allow servers to have a way to clean up idle connections whe= re the remote side has silently gone away. >=20 > My experience is that Windows (XP and 7) in case of resume will just kill= all TCP sessions, which I don't think is optimal either. >=20 > I know several applications that run their own keep-alive on top of TCP j= ust to workaround TCP behaviour (the way TCP was designed to stay alive and= be network-friendly with re-transmit timers in tens of minutes or even hou= rs and basically never timeot) which might make sense for some applications= , but is not really what the user needs in case of interactive application = using TCP. TCP can't, by itself, make decisions about when to drop connections, other = than timing out a connection due to lack of response to new data, or other = situations defined in the protocol. Beyond that requires knowledge beyond = the scope of TCP; e.g. when the application sets the TCP keep-alive timer, = it is giving TCP additional information about how to handle particular idle= connections. Ultimately, if the application doesn't like how TCP handles = things, it must implement its own method of detecting and dropping connecti= ons that have become non-responsive within the parameters that the applicat= ion thinks are reasonable. -David Borman >=20 >> For instance, to me it would be really useful to see some explanation ho= w relavant TCP stacks deal with hibernation, and how suboptimal their timer= s are in reality. Also, potential guidance in that space has to be realisti= c, i. e., it must take into account the actual constraints inside a real TC= P stack. So, we have to understand these constraints. >=20 > http://www.pcvr.nl/tcpip/tcp_time.htm was one document I found discussing= this, claiming in this particular test that 64 seconds is the maximum retr= ansmission timer. I'll do some tests and see if my ubuntu machine has appro= ximately the same value. When waiting after a resume this 64 seconds feels = like an eternity anyway :P >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From swmike@swm.pp.se Wed Jan 2 11:29:38 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 D284721F87ED for ; Wed, 2 Jan 2013 11:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 hRKBZXd3DsGh for ; Wed, 2 Jan 2013 11:29:38 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 561E921F8667 for ; Wed, 2 Jan 2013 11:29:38 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C306E9C; Wed, 2 Jan 2013 20:29:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BFBED9A; Wed, 2 Jan 2013 20:29:36 +0100 (CET) Date: Wed, 2 Jan 2013 20:29:36 +0100 (CET) From: Mikael Abrahamsson To: Joe Touch In-Reply-To: <50E48874.9030906@isi.edu> Message-ID: References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@isi.edu> <50E48874.9030906@isi.edu> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 02 Jan 2013 19:29:38 -0000 On Wed, 2 Jan 2013, Joe Touch wrote: > Why not just set the TCP to "keepalive" and set the interval you want? > Why rely on a separate mechanism to do this when it's already there? If I set TCP keepalive to 5 seconds, I'm going to unneccessarily send a packet every 5 seconds for the duration of the session, right? Is that really a sane recommendation for solving resume problem generally? -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Wed Jan 2 11:39: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 2295121F84FC for ; Wed, 2 Jan 2013 11:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 Nlf3Lk9g6o39 for ; Wed, 2 Jan 2013 11:39:57 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 377E721F84DC for ; Wed, 2 Jan 2013 11:39:57 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E60799C; Wed, 2 Jan 2013 20:39:55 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E1F919A; Wed, 2 Jan 2013 20:39:55 +0100 (CET) Date: Wed, 2 Jan 2013 20:39:55 +0100 (CET) From: Mikael Abrahamsson To: David Borman In-Reply-To: Message-ID: References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 02 Jan 2013 19:39:58 -0000 On Wed, 2 Jan 2013, David Borman wrote: > There has to be unacknowledged data for TCP to notice that the other > side has gone away. If everything is working properly, when you resume > your machine, in an interactive SSH session if you type new data, TCP > should send that off, and the other side should send back an immediate > TCP reset because the connection no longer exists on the other side. Yes, I understand that. However, if I happen to press enter in my ssh session before the connection manager is done with setting up my wifi, it's now in backoff and it seems to take a substantial amount of time before it recovers. Enough that I've given up on waiting and just kill it on reconnect. If I wait until the connection manager is done and then press enter, I get the RST quickly just as you describe. What I want to happen (or that is the answer I have come up with), is basically when the connection manager has deemed that connectivity is up, it tells the TCP stack to fire all connections (send a keepalive or whatever), figure out what connections are still valid and reset the ones it receives RST to. Basically do a "state refresh". If it doesn't receive a response, then that session should after a while go back to 64s retransmit timer just like we do today. > However, if no reset is received, the TCP connection will go through the > normal TCP exponential back-off and retransmits until it gives up and > drops the connection. The primary reasons why you wouldn't get the > reset is that the remote host is down or unreachable, or some middle box > in the path is silently dropping the packets because it no longer has, > or never had, state information for that connection. Keep in mind that > even if TCP gets an ICMP Host Unreachable message, it'll typically treat > that as a soft error and continue trying to send the data until it times > out, then when it eventually does time out, it'll report it as a host > unreachable instead of timed out. In my case, there is no stateful inspection firewall that might timeout the session, yet I still see my described problem. > Of course, if there is no data to send, TCP won't discover that the > connection is dead. That's exactly the scenario why people added > Keep-Alive timers into TCP, to allow servers to have a way to clean up > idle connections where the remote side has silently gone away. Yes, so what I want is to do "spurious keepalive" on all TCP sessions (or send null data) without having to put all my sessions in 5s keepalive to handle the two times per day I have my laptop suspended. > TCP can't, by itself, make decisions about when to drop connections, > other than timing out a connection due to lack of response to new data, I am not talking about lack of response. > or other situations defined in the protocol. Beyond that requires > knowledge beyond the scope of TCP; e.g. when the application sets the > TCP keep-alive timer, it is giving TCP additional information about how > to handle particular idle connections. Ultimately, if the application > doesn't like how TCP handles things, it must implement its own method of > detecting and dropping connections that have become non-responsive > within the parameters that the application thinks are reasonable. So what you're saying is that you don't see any use in my proposal to handle re-establishment of network connectivity differently from existing functionality already there. -- Mikael Abrahamsson email: swmike@swm.pp.se From touch@isi.edu Wed Jan 2 11:42:49 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 C7FF521F8848 for ; Wed, 2 Jan 2013 11:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.989 X-Spam-Level: X-Spam-Status: No, score=-102.989 tagged_above=-999 required=5 tests=[AWL=-0.390, 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 4IUxztN6Mal5 for ; Wed, 2 Jan 2013 11:42:49 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 34F5A21F879E for ; Wed, 2 Jan 2013 11:42:42 -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 r02JgRJm008218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Jan 2013 11:42:27 -0800 (PST) Message-ID: <50E48DA3.9060409@isi.edu> Date: Wed, 02 Jan 2013 11:42:27 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@isi.edu> <50E48874.9030906@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] host behaviour when connectivity is lost 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, 02 Jan 2013 19:42:49 -0000 On 1/2/2013 11:29 AM, Mikael Abrahamsson wrote: > On Wed, 2 Jan 2013, Joe Touch wrote: > >> Why not just set the TCP to "keepalive" and set the interval you want? >> Why rely on a separate mechanism to do this when it's already there? > > If I set TCP keepalive to 5 seconds, I'm going to unneccessarily send a > packet every 5 seconds for the duration of the session, right? Is that > really a sane recommendation for solving resume problem generally? 5 seconds is a bit short for a keepalive, but it's the same packet whether TCP sends it or the app does. I.e., if 5 seconds is the keepalive you want, then there's no reason not to use TCP's internal mechanism for this. Joe From ycheng@google.com Wed Jan 2 11:46: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 D133021F85E8 for ; Wed, 2 Jan 2013 11:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.769 X-Spam-Level: X-Spam-Status: No, score=-102.769 tagged_above=-999 required=5 tests=[AWL=0.208, 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 odYOdbNwM7Om for ; Wed, 2 Jan 2013 11:46:08 -0800 (PST) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id C1F9921F879E for ; Wed, 2 Jan 2013 11:46:08 -0800 (PST) Received: by mail-oa0-f45.google.com with SMTP id i18so13517739oag.32 for ; Wed, 02 Jan 2013 11:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CRYsORV9e6XL1XZhhAnRk6DRHaCgRfSdLCDkzypdJcA=; b=TEiNh9Vpk4t2KpuKVJO5kgJND3Kf/YcDGOPLDCrRk1qaAhn4yBl19AwnYqhfsFQZg/ oaO3mNXOLk+mUm+D+nfjFXPcjHf7Vdy9rCXVZaqRTBvZ/0si324qpMxUz1nyyo4tDlnJ 0JDxfzg1tlRcOnrZeQmihEZDrOcGAhYcxarZaTGUp83cEw7+2ZFS38nBWmc1Wg8zMvK2 YDKm8k3M6OSxnBYpR7giENKAl+DuoujqJuUbes/vAp/GUA35X30dVUCvYvGKflS9Z94g 7kA4qo1z1CDgYfr1xAVOpArKPbkmmPYB5mH9eoXFSju1srRWdXxejoL4VP2AnPxIv1Ye 7TQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=CRYsORV9e6XL1XZhhAnRk6DRHaCgRfSdLCDkzypdJcA=; b=IEROVBoDrztJ2fTw82+xfdA+lKHAEa0tEWQNHdlgBjJlvt4MvQyK24LWqqKNOP3UWx bCX20rzoQTfdAUE76zGNIyZtQU6gIVsnP4CRHSYfYna6oBthohalAD/xnXgR6QqIGytT knkGwrQWFQu7KzN2CmY4iJyGxXM6bDOG/niFf/V1nM/dcvKqSuyszPJ2Rja/JgQFXj6h 0EurRuecuhUTeWMTuZKTj8WsgRBu5dwnoozuBFJeS+2DPVWhLJfpSiZfp/42chWqasbj arTBy4HY+lPz6aCZPbFp26aziMN9dYyegi9doWir3dAHieEGBPIkA/XA2x+Aj3VofRzY 3AZg== Received: by 10.60.169.140 with SMTP id ae12mr25854255oec.52.1357155967951; Wed, 02 Jan 2013 11:46:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.82.39 with HTTP; Wed, 2 Jan 2013 11:45:46 -0800 (PST) In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E14A253@eusaamb109.ericsson.se> References: <1D1BEDF8-28D1-41CD-999C-5627E81D0537@ifi.uio.no> <20130102025350.AF22755A074@lawyers.icir.org> <2F3EBB88EC3A454AAB08915FBF0B8C7E148E68@eusaamb109.ericsson.se> <9DF82729-E83B-4515-8BCD-D33E4EBC3E39@ericsson.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4F@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E14A253@eusaamb109.ericsson.se> From: Yuchung Cheng Date: Wed, 2 Jan 2013 11:45:46 -0800 Message-ID: To: Jakob Heitz Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmaP/cEwdHp66WaJokY3X2rNHvJFcy01+Yc0LZWKwSO7NpydErGFg36Ly9LdR0+HZYEe19BSi6J7tajSHDa9iuY+R8p3g/InV0TKy9/J4zJ7Omn2ep1dWqV6ThncGgjPxRa4a1FExYF8gcPwNiMzS0CQ5yzQ0Ol2g9xOGPHtk4dMu1uhSrRVxCleBgks8PqAjq7DrEd Cc: "tcpm \(tcpm@ietf.org\)" , Michael Welzl , Joe Touch , "mallman@icir.org" , Marco Mellia Subject: Re: [tcpm] About the SYN/ACK-timer 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, 02 Jan 2013 19:46:09 -0000 On Wed, Jan 2, 2013 at 10:57 AM, Jakob Heitz wrote: > On Wednesday, January 02, 2013 1:36 AM, Scharf, Michael (Michael) <> wrote: > >>> -----Original Message----- >>> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf >>> Of Jakob Heitz Sent: Wednesday, January 02, 2013 9:53 AM >>> To: Yoshifumi Nishida >>> Cc: Joe Touch; tcpm (tcpm@ietf.org); Marco Mellia; Michael Welzl; >>> mallman@icir.org Subject: Re: [tcpm] About the SYN/ACK-timer >>> >>> The reason for the accelerated first retransmission: >>> The SYN with data may get dropped for 2 reasons. >>> 1. Middleboxes that consider it abnormal. >> >> If there is such a middlebox, the best solution is to try to >> learn that and cache it, on order to avoid the use of SYN >> data at all. > > Of course it is, but there is no need to standardize that. > >> This is mostly orthogonal to the retransmission >> timer. Except for one detail: The smaller the gap between the >> two transmissions, the higher is the risk of reordering, i. >> e., that such heuristics break because the RTO is *too* >> small. Thus, accelerated first retranmission can indeed have >> drawbacks with middleboxes... > > no. > It will pass the lone SYN (misordered, arrives first) > Then it will drop the SYN with data. > No harm done. > >> And, with an initial RTO of 1s, >> the only penalty is the 1s timeout for the first connection. >> After that, the sender would hopefully not use SYN data any more. >> >> So, what remains is the 1s RTO for the first connection to >> that destination. An initial timeout below one second to an >> unknown destination comes along with quite some risk of >> spuriour retransmission on narrow-band links. It might not be >> a too good idea because of that. >> >>> 2. SYN flood protection at the server. >> >> I might miss something fundamental, but if a server is in SYN >> flood protection mode, would it not be a good idea if the >> client backs off a bit? > > During SYN flood protection, I'm assuming the server will > aggressively drop SYN with data, but accept SYN without data > more readily. When syn-cookie is activated in Linux, upon receiving SYN-data the server sends SYN-ACK acking only the initial/SYN sequence (i.e., it drops the data part only). Upon receiving the SYN-ACK, the client will retransmit the data in the final ACK of the handshake. The proposed shorter SYN-retransmit w/o data in TFO does not help assuming no network drops. HTH > Therefore, retransmit the SYN without data, then back off > as normal. > >> Using a 100ms timer is quite the >> opposite of that. >> >> In summary, it is not clear to me what actual problem we discuss here. >> >> For what it is worth, as already mentioned multiple times: >> There is a TCPM working group item draft-ietf-tcpm-fastopen, >> which has quite some related text, including the initial RTO. > > I'm aware of it. > I don't like the cookie idea. > It was a great initial idea, but got complicated > and incomplete in a hurry. > > I am not proposing an initial RTO of 100mS. > I am proposing a single retransmission of the SYN without data > at 100mS. There is a difference. > >> >> Michael >> >> >>> I expect SYN flood protection to be much more aggressive >>> towards SYN packets with data. >>> In the majority of cases, the SYN with data should get >>> through just fine. When it doesn't, the accelerated >>> retransmission without the data will recover. >>> >>> Cheers, >>> Jakob. >>> >>> On Jan 1, 2013, at 11:32 PM, "Yoshifumi Nishida" >>> wrote: >>> >>> >>> >>> Hi Jakob, >>> >>> >>> On Tue, Jan 1, 2013 at 9:25 PM, Jakob Heitz >>> wrote: >>> >>> >>> On Tuesday, January 01, 2013 6:54 PM, >>> mallman@icir.org >>> wrote: >>> >>> > I am confused. >>> > >>> >> Not sure about everyone else, but the way I >>> interpreted (and meant) >>> >> the 1s bit was to say "a new value, such as >>> 1s, as opposed to a >>> >> complex adaptive mechanism". It wasn't about >>> the exact value of 1s >>> >> per se. >>> > >>> > You say "a new value, such as 1s". My point >>> is 1s is NOT a new value. >>> > It is the standardized value. Before >>> proposing some new >>> > value, it'd at >>> > least be handy if folks understood the current value. > >>> >> About lowering the initial RTO further: I, >>> for one, hadn't thought of >>> >> that, and am not fully aware of all the >>> pro's and con's. But yeah, it >>> >> might be worth considering? >>> > >>> > Well, if you're not suggesting lowering the >>> initial RTO then what are >>> > you suggesting? I have no idea what you are >>> saying here. The initial >>> > RTO is the RTO that is used before an RTT >>> sample is taken. So, just >>> > what are you suggesting here? >>> > >>> > allman >>> >>> >>> I am suggesting: >>> 1st SYN contains data. >>> Retransmit that SYN without data after 100mS. >>> Make the next retransmit timer 1 second with >>> the normal power of 2 backoff after that. All SYN retransmits >>> without data. Do the same for the SYN/ACK. >>> No cookies. >>> The initial 100mS SYN retransmit timer MAY be >>> lengthened by application knowledge of conditions. For >>> example, satellite or wireless. >>> >>> >>> I think you consider 1 second SYN RTO is fine. But, you >>> want to accelerate the first retransmission. >>> This seems to be a bit inconsistent design to me. >>> Well, it might be useful if the SYNs are discarded >>> because of accidental packet drops or because of data payload. >>> But, I'm still wondering how practical these situations are. >>> >>> Thanks, >>> -- >>> Yoshifumi > > > > -- > Jakob Heitz. x25475. 510-566-2901 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From swmike@swm.pp.se Wed Jan 2 12: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 738A021F8959 for ; Wed, 2 Jan 2013 12:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 soyJJmuFsYzf for ; Wed, 2 Jan 2013 12:08:56 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id D51B321F87CC for ; Wed, 2 Jan 2013 12:08:55 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 34CCC9F; Wed, 2 Jan 2013 21:08:55 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2EF8B9A for ; Wed, 2 Jan 2013 21:08:55 +0100 (CET) Date: Wed, 2 Jan 2013 21:08:55 +0100 (CET) From: Mikael Abrahamsson To: "tcpm@ietf.org" In-Reply-To: <50E48DA3.9060409@isi.edu> Message-ID: References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@isi.edu> <50E48874.9030906@isi.edu> <50E48DA3.9060409@isi.edu> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 02 Jan 2013 20:08:56 -0000 On Wed, 2 Jan 2013, Joe Touch wrote: > 5 seconds is a bit short for a keepalive, but it's the same packet > whether TCP sends it or the app does. I.e., if 5 seconds is the > keepalive you want, then there's no reason not to use TCP's internal > mechanism for this. Well, it's not the behaviour I want. I want keepalives at a single instance, once each time my network connectivity has been re-established. If an OS vendor implemented this without any further standardization, would that violate any RFC as they stand today? My thought was always that it would be better to have "TCP people" give guidance on this topic, but perhaps that is not needed (and desired). -- Mikael Abrahamsson email: swmike@swm.pp.se From dab@weston.borman.com Wed Jan 2 12:28: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 294F721F8871 for ; Wed, 2 Jan 2013 12:28:47 -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 GoAiKTcvyRvL for ; Wed, 2 Jan 2013 12:28:46 -0800 (PST) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0F98E21F885E for ; Wed, 2 Jan 2013 12:28:45 -0800 (PST) Received: from [127.0.0.1] (frantic.weston.borman.com [70.57.156.33]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id r02KShjH028604; Wed, 2 Jan 2013 14:28:44 -0600 (CST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: David Borman In-Reply-To: Date: Wed, 2 Jan 2013 14:28:43 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6DD8401E-F2FD-4411-8A91-39441B42D742@weston.borman.com> References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1499) Cc: "tcpm@ietf.org" , David Borman Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 02 Jan 2013 20:28:47 -0000 On Jan 2, 2013, at 1:39 PM, Mikael Abrahamsson wrote: > On Wed, 2 Jan 2013, David Borman wrote: ... >> Of course, if there is no data to send, TCP won't discover that the = connection is dead. That's exactly the scenario why people added = Keep-Alive timers into TCP, to allow servers to have a way to clean up = idle connections where the remote side has silently gone away. >=20 > Yes, so what I want is to do "spurious keepalive" on all TCP sessions = (or send null data) without having to put all my sessions in 5s = keepalive to handle the two times per day I have my laptop suspended. I see no problem with that, basically a keep-alive that is triggered on = network state transitions, rather than on a time-based interval. FYI, = TCP does not have explicit keep alive packets, it is not part of the = protocol. TCP keepalives are just carefully constructed TCP packets = designed to elicit an immediate ACK from the remote side. >=20 >> TCP can't, by itself, make decisions about when to drop connections, = other than timing out a connection due to lack of response to new data, >=20 > I am not talking about lack of response. >=20 >> or other situations defined in the protocol. Beyond that requires = knowledge beyond the scope of TCP; e.g. when the application sets the = TCP keep-alive timer, it is giving TCP additional information about how = to handle particular idle connections. Ultimately, if the application = doesn't like how TCP handles things, it must implement its own method of = detecting and dropping connections that have become non-responsive = within the parameters that the application thinks are reasonable. >=20 > So what you're saying is that you don't see any use in my proposal to = handle re-establishment of network connectivity differently from = existing functionality already there. Nope, I didn't say that. After a sleep/resume cycle, maybe things have = changed, maybe not. There's nothing wrong with telling TCP that things = might have changed. The question is what should TCP do with that = information, beyond what it is already doing? In the ssh example, TCP = could aggressively determine whether or not particular connections are = still useful, and drop them quickly. Or not. If I unplug my laptop = from the ethernet and walk over to another office for a few minutes, and = there connect via wi-fi (different network, different IP address), then = do I really want all my idle SSH connections to go away? Not = necessarily, I'm going to go back to my office, plug it back into the = ethernet, and then the idle SSH connections can work again when the old = IP address again is available on my ethernet interface. My point is that what may be the correct behavior in one situation, may = be exactly the wrong behavior in another situation. That's why things = like TCP Keep-Alives are configurable and off by default. The default = behavior for TCP should always be to do its best to keep connections = alive, no matter how much the ground shifts underneath its feet, unless = told to do otherwise by the application. And the application should = also have a way for the user to tell the application what behavior = should be used. -David Borman > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From jakob.heitz@ericsson.com Wed Jan 2 12:35: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 B1A1221F88C8 for ; Wed, 2 Jan 2013 12:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.452 X-Spam-Level: X-Spam-Status: No, score=-6.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 ISmsIr8cMHUd for ; Wed, 2 Jan 2013 12:35:25 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 49F6821F867D for ; Wed, 2 Jan 2013 12:35:23 -0800 (PST) Received: from EUSAAHC005.ericsson.se ([147.117.188.87]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id r02KZIH3021857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jan 2013 14:35:18 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 15:35:17 -0500 From: Jakob Heitz To: Yuchung Cheng Thread-Topic: [tcpm] About the SYN/ACK-timer Thread-Index: AQHN6Kmen9PlwwSgXU2cX18Avy7He5g1+RIA///C3m2AAAWQIIAAm/sQgABohwD//7k9MA== Date: Wed, 2 Jan 2013 20:35:17 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E14A4CE@eusaamb109.ericsson.se> References: <1D1BEDF8-28D1-41CD-999C-5627E81D0537@ifi.uio.no> <20130102025350.AF22755A074@lawyers.icir.org> <2F3EBB88EC3A454AAB08915FBF0B8C7E148E68@eusaamb109.ericsson.se> <9DF82729-E83B-4515-8BCD-D33E4EBC3E39@ericsson.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4F@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E14A253@eusaamb109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" , Michael Welzl , Joe Touch , "mallman@icir.org" , Marco Mellia Subject: Re: [tcpm] About the SYN/ACK-timer 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, 02 Jan 2013 20:35:25 -0000 On Wednesday, January 02, 2013 11:46 AM, Yuchung Cheng wrote: >> During SYN flood protection, I'm assuming the server will >> aggressively drop SYN with data, but accept SYN without data >> more readily. > When syn-cookie is activated in Linux, upon receiving SYN-data the > server sends SYN-ACK acking only the initial/SYN sequence (i.e., it > drops the data part only). Upon receiving the SYN-ACK, the client will > retransmit the data in the final ACK of the handshake. The proposed > shorter SYN-retransmit w/o data in TFO does not help assuming no > network drops.=20 I am assuming an upgraded stack once SYN with data becomes a common thing to do. However, you confirm that the scheme will work with current code too. --=20 Jakob Heitz. From jakob.heitz@ericsson.com Wed Jan 2 12: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 628F621F8A5A for ; Wed, 2 Jan 2013 12:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.456 X-Spam-Level: X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.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 26R-Et9Sc+8A for ; Wed, 2 Jan 2013 12:48:52 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id C09FC21F8A58 for ; Wed, 2 Jan 2013 12:48:51 -0800 (PST) Received: from EUSAAHC006.ericsson.se ([147.117.188.90]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id r02Kmo7N023330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jan 2013 14:48:51 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 15:48:50 -0500 From: Jakob Heitz To: Joe Touch , Mikael Abrahamsson Thread-Topic: [tcpm] host behaviour when connectivity is lost Thread-Index: AQHN6EV/o0lKVsvSj0+2rT1fksKO9Jg1JZMAgACa2ACAAFKqAIAARCoAgABclQCAAAo7gIAAAaAA///DgiA= Date: Wed, 2 Jan 2013 20:48:49 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E14A540@eusaamb109.ericsson.se> References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@isi.edu> <50E48874.9030906@isi.edu> In-Reply-To: <50E48874.9030906@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 02 Jan 2013 20:48:52 -0000 On , Joe Touch <> wrote: > Why not just set the TCP to "keepalive" and set the interval > you want? > Why rely on a separate mechanism to do this when it's already there? Even if you set the keepalive to 5 seconds, it takes an eon of retransmissions before the session actually goes down. This is why BGP (at least) has a user level keepalive. --=20 Jakob Heitz. From jakob.heitz@ericsson.com Wed Jan 2 12:56: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 578F321F8864 for ; Wed, 2 Jan 2013 12:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 BUqEtam2cKcG for ; Wed, 2 Jan 2013 12:56:28 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id CEC6B21F8858 for ; Wed, 2 Jan 2013 12:56:28 -0800 (PST) Received: from EUSAAHC006.ericsson.se ([147.117.188.90]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id r02KuSCa024009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jan 2013 14:56:28 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 15:56:27 -0500 From: Jakob Heitz To: Joe Touch , Mikael Abrahamsson Thread-Topic: [tcpm] host behaviour when connectivity is lost Thread-Index: AQHN6EV/o0lKVsvSj0+2rT1fksKO9Jg1JZMAgACa2ACAAFKqAIAARCoAgABclQD//9GjgA== Date: Wed, 2 Jan 2013 20:56:26 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E14A578@eusaamb109.ericsson.se> References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@isi.edu> In-Reply-To: <50E47E82.8030407@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 02 Jan 2013 20:56:29 -0000 On , Joe Touch <> wrote: > PS - the IETF has claimed in the past that it doesn't standardize OS > interfaces (I agree) http://tools.ietf.org/html/rfc3493 http://tools.ietf.org/html/rfc3542 are examples of when they do. These RFCs are referenced in code, even though they are informational. I find them useful. --=20 Jakob Heitz. From swmike@swm.pp.se Wed Jan 2 12:57: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 69B0321F88D8 for ; Wed, 2 Jan 2013 12:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 jX03BlSP3TJN for ; Wed, 2 Jan 2013 12:57:10 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCE521F88C7 for ; Wed, 2 Jan 2013 12:57:02 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1A6249C; Wed, 2 Jan 2013 21:57:01 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 14E319A for ; Wed, 2 Jan 2013 21:57:01 +0100 (CET) Date: Wed, 2 Jan 2013 21:57:01 +0100 (CET) From: Mikael Abrahamsson To: "tcpm@ietf.org" In-Reply-To: <6DD8401E-F2FD-4411-8A91-39441B42D742@weston.borman.com> Message-ID: References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <6DD8401E-F2FD-4411-8A91-39441B42D742@weston.borman.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 02 Jan 2013 20:57:11 -0000 On Wed, 2 Jan 2013, David Borman wrote: > Nope, I didn't say that. After a sleep/resume cycle, maybe things have > changed, maybe not. There's nothing wrong with telling TCP that things > might have changed. The question is what should TCP do with that > information, beyond what it is already doing? In the ssh example, TCP > could aggressively determine whether or not particular connections are > still useful, and drop them quickly. Or not. If I unplug my laptop > from the ethernet and walk over to another office for a few minutes, and > there connect via wi-fi (different network, different IP address), then > do I really want all my idle SSH connections to go away? Not > necessarily, I'm going to go back to my office, plug it back into the > ethernet, and then the idle SSH connections can work again when the old > IP address again is available on my ethernet interface. My idea the whole time has been that this would be configurable in the conncetion manager. I just wanted an API (or functionality) for the program to trigger the TCP stack functionality I am describing, and I thought it would be a good idea to have a guiding document that describes this. > My point is that what may be the correct behavior in one situation, may > be exactly the wrong behavior in another situation. That's why things > like TCP Keep-Alives are configurable and off by default. The default > behavior for TCP should always be to do its best to keep connections > alive, no matter how much the ground shifts underneath its feet, unless > told to do otherwise by the application. And the application should > also have a way for the user to tell the application what behavior > should be used. For me, doing this on an application basis is fine in some scenarios, and in some I just want this to be a system wide thing. If I know that a change of subnetwork/IP address is permanent and I don't want any lingering TCP sessions bound to old IPs, I would like to configure the connection manager to tell the TCP stack to just close all TCP sessions bound to the old IPs. This was an API I also thought would make sense to have a document describing (or at least describe the high-level functionality). -- Mikael Abrahamsson email: swmike@swm.pp.se From prvs=971440e0cf=david.borman@quantum.com Wed Jan 2 13:00: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 E98D421F8658 for ; Wed, 2 Jan 2013 13:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 36jAoV5WJizF for ; Wed, 2 Jan 2013 13:00:40 -0800 (PST) Received: from mx0b-000ceb01.pphosted.com (mx0b-000ceb01.pphosted.com [67.231.152.126]) by ietfa.amsl.com (Postfix) with ESMTP id 5941821F84F0 for ; Wed, 2 Jan 2013 13:00:40 -0800 (PST) Received: from pps.filterd (m0001151 [127.0.0.1]) by mx0b-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id r02KwCVV021369; Wed, 2 Jan 2013 13:00:37 -0800 Received: from ppoxedge1.quantum.com ([146.174.252.27]) by mx0b-000ceb01.pphosted.com with ESMTP id 19jmevkbbe-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 02 Jan 2013 13:00:37 -0800 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE1.quantum.com (146.174.252.27) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 2 Jan 2013 14:00:22 -0700 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.02.0318.001; Wed, 2 Jan 2013 14:00:36 -0700 From: David Borman To: Jakob Heitz Thread-Topic: [tcpm] About the SYN/ACK-timer Thread-Index: AQHN6Swuf98zT7SLEEmblDCMGQ4PaQ== Date: Wed, 2 Jan 2013 21:00:23 +0000 Message-ID: References: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> <9797BC06-420A-467D-8B0F-A9FDFD30F06D@ericsson.com> <50E00E8E.40204@tlc.polito.it>,<50E06FAC.80200@isi.edu> <96C14B42-81DD-49E3-A795-03B21425552F@ericsson.com> In-Reply-To: <96C14B42-81DD-49E3-A795-03B21425552F@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <2EB74C45EC805D4BB5F0C1E143E0C779@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-02_08:2012-12-31, 2013-01-02, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1301020223 Cc: "tcpm \(tcpm@ietf.org\)" , Michael Welzl Subject: Re: [tcpm] About the SYN/ACK-timer 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, 02 Jan 2013 21:00:41 -0000 On Dec 30, 2012, at 12:16 PM, Jakob Heitz wrote: ... > BTW, I think the SYN packet should include data. A simple change to the s= ockets API should do it. We've been down this road before with T/TCP. In a nut-shell, sending data = in the SYN doesn't buy you anything, because, as has already been stated, t= he other side can't deliver it until the 3-way handshake completes. T/TCP i= s how you make that data immediately available. The challenge is knowing t= hat you can trust that the data is safe to be delivered before completing t= he 3-way handshake. If you have to wait for the 3-way handshake, there's r= eally not much savings over sending the data with the final ACK. -David Borman ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From touch@isi.edu Wed Jan 2 13:04: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 247BF21F89FD for ; Wed, 2 Jan 2013 13:04:00 -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=[AWL=-0.377, 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 lEcEx8umv4ov for ; Wed, 2 Jan 2013 13:03:59 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id B5A2621F89EE for ; Wed, 2 Jan 2013 13:03:59 -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 r02L3dfM008021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Jan 2013 13:03:39 -0800 (PST) Message-ID: <50E4A0AB.1060801@isi.edu> Date: Wed, 02 Jan 2013 13:03:39 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jakob Heitz References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@isi.edu> <2F3EBB88EC3A454AAB08915FBF0B8C7E14A578@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E14A578@eusaamb109.ericsson.se> 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] host behaviour when connectivity is lost 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, 02 Jan 2013 21:04:00 -0000 On 1/2/2013 12:56 PM, Jakob Heitz wrote: > On , Joe Touch <> wrote: > >> PS - the IETF has claimed in the past that it doesn't standardize OS >> interfaces (I agree) > > http://tools.ietf.org/html/rfc3493 > http://tools.ietf.org/html/rfc3542 > > are examples of when they do. RFC 793 has an API as well. > These RFCs are referenced in code, even though they are informational. > I find them useful. IMO, they should be more than informational, though. Joe From jakob.heitz@ericsson.com Wed Jan 2 13:13: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 239C521F8A2F for ; Wed, 2 Jan 2013 13:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 Z22cg5XaMYxo for ; Wed, 2 Jan 2013 13:13:50 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9502221F89CE for ; Wed, 2 Jan 2013 13:13:50 -0800 (PST) Received: from EUSAAHC007.ericsson.se ([147.117.188.93]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id r02LRQLE005277; Wed, 2 Jan 2013 15:27:31 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 16:13:49 -0500 From: Jakob Heitz To: David Borman Thread-Topic: [tcpm] About the SYN/ACK-timer Thread-Index: AQHN5b8Stu8nYED5FE+WsO7zyjvHrZgwFqsMgAFYDACAAHPGAP//xaCNgAU4k4D//60csA== Date: Wed, 2 Jan 2013 21:13:47 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E14A5FC@eusaamb109.ericsson.se> References: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> <9797BC06-420A-467D-8B0F-A9FDFD30F06D@ericsson.com> <50E00E8E.40204@tlc.polito.it>,<50E06FAC.80200@isi.edu> <96C14B42-81DD-49E3-A795-03B21425552F@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" , Michael Welzl Subject: Re: [tcpm] About the SYN/ACK-timer 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, 02 Jan 2013 21:13:51 -0000 On Wednesday, January 02, 2013 1:00 PM, David Borman wrote: > On Dec 30, 2012, at 12:16 PM, Jakob Heitz > wrote: > ... >> BTW, I think the SYN packet should include data. A simple > change to the sockets API should do it. >=20 > We've been down this road before with T/TCP. In a nut-shell, > sending data in the SYN doesn't buy you anything, because, as > has already been stated, the other side can't deliver it > until the 3-way handshake completes. T/TCP is how you make > that data immediately available. The challenge is knowing > that you can trust that the data is safe to be delivered > before completing the 3-way handshake. This is not universally the case. In many cases, it doesn't matter and TCP can deliver before the 3-way handshake. For the case where it does matter, the data can be retransmitted with the final ACK. Flood protection is not difficult. Just fall back to SYN only. --=20 Jakob Heitz. From ycheng@google.com Wed Jan 2 13:20: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 C7B4C21F857C for ; Wed, 2 Jan 2013 13:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.81 X-Spam-Level: X-Spam-Status: No, score=-102.81 tagged_above=-999 required=5 tests=[AWL=0.167, 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 X0T7T7UoJNyS for ; Wed, 2 Jan 2013 13:20:32 -0800 (PST) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1590D21F84F0 for ; Wed, 2 Jan 2013 13:20:32 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id ta14so13185691obb.19 for ; Wed, 02 Jan 2013 13:20:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7IBCkkYUBaHzva4Z5XAGWbLDpYqRms36+UEzbiJii9k=; b=C1LmEUKKhJ3X9xAuGopWnSMSa1Uym0yVoMiDyZyGgYFrkHd+lLvOJvjLMLxnOEVNl1 /sYI8UwnTX/3/HsCuT61tX7wXayi3dVLqSqCDetdMW4wq0yOCl+X1B+Z2oJdTyETuYsJ yLM6SGmlzYQW3DW8JaOVYp6dLSsZmPiATf4ZIGxV/PTgQNbvwOhbWCOhpWfG5eUmnCQA 70hXGypb53UxtfiC4PjV7GaiuerK/5vSEER6fwC6motazoKII5CeGjVuVYvQ2/FPSq9N k23J8MQ8zRETMbIbNBKma6/oSK/FOZIZwwhbytx0I9iN1QaLOLGKTQ9l9Jz8PRKrWaN8 nMug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=7IBCkkYUBaHzva4Z5XAGWbLDpYqRms36+UEzbiJii9k=; b=ciB4nNaHtHTuCnPdv3sLqR9yKAFzV1RrC7lerG4eTY0+TmkxDiFDDNdERPOwpW06Ng 91kxOc+h67fmNQtbDB/1FBnsvC72A5B7ifkmYpLwSxU+tPiMOhmdhGKoMdmzRFq5mM/c kf/u5knfMotQlJBZm+sApiTcNBT9TxqsC/pfHR8MFG5kFnq4fE+ChMqAEiLQPRpVHLyd Y3VgMlYWfHTgEzXDQ9mHsH1BlavcmzA5Nm5Q2QzBpjzY+6GSEg+XK91CRpn977k9eDRM sZb0t4vm9zxmJgIUyLd98LRaLhfQeFGAA6HdJQIKTB62WRyh/7AmtkvvEdgHC0XM8U84 m2Xg== Received: by 10.60.2.103 with SMTP id 7mr26882884oet.79.1357161631543; Wed, 02 Jan 2013 13:20:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.82.39 with HTTP; Wed, 2 Jan 2013 13:20:10 -0800 (PST) In-Reply-To: References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <6DD8401E-F2FD-4411-8A91-39441B42D742@weston.borman.com> From: Yuchung Cheng Date: Wed, 2 Jan 2013 13:20:10 -0800 Message-ID: To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm5E67hF6GFDqfodXk8Uk2wymgLQ+dgHUzjzf29tb/FmRX7xvzRAFD+Q+iET/foQEJBH3bl0wuk+u+ESplmq2U3dpPC3PV2jM3MD0kzCdg1Aj3MVEXQpxM1iO2qOMYm6oj28XiArlKNFKZR5iXCgbSEytkC1yQnLeDmXgk8Mqn7QuLQr+eugzAB+bm6gJYJGhToczuj Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 02 Jan 2013 21:20:32 -0000 Hi Mikael, On Wed, Jan 2, 2013 at 12:57 PM, Mikael Abrahamsson wrote: > On Wed, 2 Jan 2013, David Borman wrote: > >> Nope, I didn't say that. After a sleep/resume cycle, maybe things have >> changed, maybe not. There's nothing wrong with telling TCP that things >> might have changed. The question is what should TCP do with that >> information, beyond what it is already doing? In the ssh example, TCP could >> aggressively determine whether or not particular connections are still >> useful, and drop them quickly. Or not. If I unplug my laptop from the >> ethernet and walk over to another office for a few minutes, and there >> connect via wi-fi (different network, different IP address), then do I >> really want all my idle SSH connections to go away? Not necessarily, I'm >> going to go back to my office, plug it back into the ethernet, and then the >> idle SSH connections can work again when the old IP address again is >> available on my ethernet interface. > > > My idea the whole time has been that this would be configurable in the > conncetion manager. I just wanted an API (or functionality) for the program > to trigger the TCP stack functionality I am describing, and I thought it > would be a good idea to have a guiding document that describes this. FWIW, we are developing/experimenting a "system" similar to your connection manager idea to guide TCP connections. http://www.ietf.org/proceedings/84/slides/slides-84-iccrg-3.pdf Dave and Joe are discussing that such a system can interface with TCP, not built into TCP itself. The TCP people see such a system as separate component, but app developers consider this part of transport/network layer or sometimes kernel's job. > > >> My point is that what may be the correct behavior in one situation, may be >> exactly the wrong behavior in another situation. That's why things like TCP >> Keep-Alives are configurable and off by default. The default behavior for >> TCP should always be to do its best to keep connections alive, no matter how >> much the ground shifts underneath its feet, unless told to do otherwise by >> the application. And the application should also have a way for the user to >> tell the application what behavior should be used. > > > For me, doing this on an application basis is fine in some scenarios, and in > some I just want this to be a system wide thing. If I know that a change of > subnetwork/IP address is permanent and I don't want any lingering TCP > sessions bound to old IPs, I would like to configure the connection manager > to tell the TCP stack to just close all TCP sessions bound to the old IPs. > This was an API I also thought would make sense to have a document > describing (or at least describe the high-level functionality). > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Wed Jan 2 13:22: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 1B9FA21F865B for ; Wed, 2 Jan 2013 13:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.953 X-Spam-Level: X-Spam-Status: No, score=-102.953 tagged_above=-999 required=5 tests=[AWL=-0.354, 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 qtOw2BKttFwV for ; Wed, 2 Jan 2013 13:22:26 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id E4D5921F862A for ; Wed, 2 Jan 2013 13:22:24 -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 r02LLsqU013899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Jan 2013 13:21:54 -0800 (PST) Message-ID: <50E4A4F2.8050702@isi.edu> Date: Wed, 02 Jan 2013 13:21:54 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@isi.edu> <50E48874.9030906@isi.edu> <50E48DA3.9060409@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] host behaviour when connectivity is lost 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, 02 Jan 2013 21:22:31 -0000 On 1/2/2013 12:08 PM, Mikael Abrahamsson wrote: > On Wed, 2 Jan 2013, Joe Touch wrote: > >> 5 seconds is a bit short for a keepalive, but it's the same packet >> whether TCP sends it or the app does. I.e., if 5 seconds is the >> keepalive you want, then there's no reason not to use TCP's internal >> mechanism for this. > > Well, it's not the behaviour I want. I want keepalives at a single > instance, once each time my network connectivity has been re-established. How do you know? Network connectivity is defined as a connected path, not just an interface state. PS - if you have keepalives set, TCP doesn't necessarily send keepalive packets if there are already other data packets being exchanged. The packets are sent only when nothing else is. > If an OS vendor implemented this without any further standardization, > would that violate any RFC as they stand today? My thought was always > that it would be better to have "TCP people" give guidance on this > topic, but perhaps that is not needed (and desired). OS vendors already have implemented this. However, if you want a timer that flushes all current connections when a TCP goes away that's fine too - just note that it may kill connections you want. The user level - whether implemented inside the OS, in a library, in user code - can always ABORT or CLOSE connections any time it wants. Joe From prvs=971440e0cf=david.borman@quantum.com Wed Jan 2 14: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 7A31C21F8617 for ; Wed, 2 Jan 2013 14:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 jKAV+wrN89GZ for ; Wed, 2 Jan 2013 14:07:30 -0800 (PST) Received: from mx0b-000ceb01.pphosted.com (mx0b-000ceb01.pphosted.com [67.231.152.126]) by ietfa.amsl.com (Postfix) with ESMTP id B774721F85F7 for ; Wed, 2 Jan 2013 14:07:30 -0800 (PST) Received: from pps.filterd (m0001158 [127.0.0.1]) by mx0b-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id r02M21jY024824; Wed, 2 Jan 2013 14:07:27 -0800 Received: from ppoxedge1.quantum.com ([146.174.252.27]) by mx0b-000ceb01.pphosted.com with ESMTP id 19gssrp8e0-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 02 Jan 2013 14:07:27 -0800 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE1.quantum.com (146.174.252.27) with Microsoft SMTP Server (TLS) id 14.2.318.1; Wed, 2 Jan 2013 15:07:12 -0700 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.02.0318.001; Wed, 2 Jan 2013 15:07:26 -0700 From: David Borman To: Jakob Heitz Thread-Topic: [tcpm] About the SYN/ACK-timer Thread-Index: AQHN6Swuf98zT7SLEEmblDCMGQ4PaZg2/xuAgAAO8IA= Date: Wed, 2 Jan 2013 22:07:16 +0000 Message-ID: References: <882A42E5-6B54-4334-97B0-C574D8A1D714@ifi.uio.no> <9797BC06-420A-467D-8B0F-A9FDFD30F06D@ericsson.com> <50E00E8E.40204@tlc.polito.it>,<50E06FAC.80200@isi.edu> <96C14B42-81DD-49E3-A795-03B21425552F@ericsson.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E14A5FC@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E14A5FC@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <953526266547C74D835491C3DFF493DB@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-02_08:2012-12-31, 2013-01-02, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1301020245 Cc: "tcpm \(tcpm@ietf.org\)" , Michael Welzl Subject: Re: [tcpm] About the SYN/ACK-timer 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, 02 Jan 2013 22:07:31 -0000 On Jan 2, 2013, at 3:13 PM, Jakob Heitz wrote: > On Wednesday, January 02, 2013 1:00 PM, David Borman wrote: >=20 >> On Dec 30, 2012, at 12:16 PM, Jakob Heitz >> wrote: >> ... >>> BTW, I think the SYN packet should include data. A simple >> change to the sockets API should do it. >>=20 >> We've been down this road before with T/TCP. In a nut-shell, >> sending data in the SYN doesn't buy you anything, because, as >> has already been stated, the other side can't deliver it >> until the 3-way handshake completes. T/TCP is how you make >> that data immediately available. The challenge is knowing >> that you can trust that the data is safe to be delivered >> before completing the 3-way handshake. >=20 > This is not universally the case. >=20 > In many cases, it doesn't matter and TCP can deliver > before the 3-way handshake. That would, of course, depend on the application, and what, if any, damage = would be done by receiving replicated, forged or flood of SYN packets. TCP was designed to provide a reliable two-way byte-stream between two endp= oints. The 3-way handshake is the first step in that reliability. By deli= vering data before having gone into established state, you are short-circut= ing that reliability, and the application has to be prepared for that. You= can achieve the same immediacy of data delivery by using UDP instead of TC= P, but UDP forces the application to do more work if there's need for more = than just a simple message-response system, especially for more data than w= ill fit into a single UDP packet. In a sense, putting data into the SYN an= d SYN/ACK is creating a UDP/TCP hybrid, the initial immediacy and reliabili= ty of UDP with the byte-stream handling of TCP. As long as the application understands the underlying service, there's no p= roblem. If you are going to put data into the SYN and allow it to be immediately de= livered, there is no reason to not also allow a FIN to go into the SYN. Th= en the whole TCP connection could be accomplished with just: Send: SYN-data-FIN Receive: SYN-ACK(of-FIN)-data-FIN Send: ACK(of-FIN) It's UDP with TCP data handling. I'm not saying it's a bad thing, let's ju= st call it what it is. -David Borman >=20 > For the case where it does matter, the data can be retransmitted > with the final ACK. >=20 > Flood protection is not difficult. Just fall back to SYN only. >=20 > --=20 > Jakob Heitz. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From michael.scharf@alcatel-lucent.com Wed Jan 2 15:28: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 B6BCC21F87FA for ; Wed, 2 Jan 2013 15:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.882 X-Spam-Level: X-Spam-Status: No, score=-7.882 tagged_above=-999 required=5 tests=[AWL=-1.633, 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 T-zUa-W9qUg4 for ; Wed, 2 Jan 2013 15:28:19 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id D8E9221F87B3 for ; Wed, 2 Jan 2013 15:28:18 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r02NS9XX014931 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Jan 2013 00:28: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; Thu, 3 Jan 2013 00:28:09 +0100 From: "Scharf, Michael (Michael)" To: Jakob Heitz , Yoshifumi Nishida Date: Thu, 3 Jan 2013 00:28:07 +0100 Thread-Topic: [tcpm] About the SYN/ACK-timer Thread-Index: AQHN6Kmen9PlwwSgXU2cX18Avy7He5g1+RIA///C3m2AAAWQIIAAm/sQgABKcvA= Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE58@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <1D1BEDF8-28D1-41CD-999C-5627E81D0537@ifi.uio.no> <20130102025350.AF22755A074@lawyers.icir.org> <2F3EBB88EC3A454AAB08915FBF0B8C7E148E68@eusaamb109.ericsson.se>, <9DF82729-E83B-4515-8BCD-D33E4EBC3E39@ericsson.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4F@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E14A253@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E14A253@eusaamb109.ericsson.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.83 Cc: "tcpm \(tcpm@ietf.org\)" , "mallman@icir.org" , Michael Welzl , Marco Mellia , Joe Touch Subject: Re: [tcpm] About the SYN/ACK-timer 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, 02 Jan 2013 23:28:19 -0000 > >> The reason for the accelerated first retransmission: > >> The SYN with data may get dropped for 2 reasons. > >> 1. Middleboxes that consider it abnormal. > >=20 > > If there is such a middlebox, the best solution is to try to learn=20 > > that and cache it, on order to avoid the use of SYN data at all. >=20 > Of course it is, but there is no need to standardize that. >=20 > > This is mostly orthogonal to the retransmission timer.=20 > Except for one=20 > > detail: The smaller the gap between the two transmissions,=20 > the higher=20 > > is the risk of reordering, i. > > e., that such heuristics break because the RTO is *too*=20 > small. Thus,=20 > > accelerated first retranmission can indeed have drawbacks with=20 > > middleboxes... >=20 > no. > It will pass the lone SYN (misordered, arrives first) Then it=20 > will drop the SYN with data. > No harm done. Well, right for that case. But if there is *no* middlebox (hopefully the default in the Internet), and= if there is reordering, the sender sees that the SYN w/o data got through = first (I guess that the SYN with data will have to be dropped). Therefore, = the sender has to wrongly assume that there is a malicious middlebox. As a = result, it will probably needlessly disable the use of SYN data for that pa= th. If so, there is harm. The whole point here is that this risk is probably higher for a gap of 100m= s, compared to 1s. > > And, with an initial RTO of 1s, > > the only penalty is the 1s timeout for the first connection. > > After that, the sender would hopefully not use SYN data any more. > >=20 > > So, what remains is the 1s RTO for the first connection to that=20 > > destination. An initial timeout below one second to an unknown=20 > > destination comes along with quite some risk of spuriour=20 > > retransmission on narrow-band links. It might not be a too=20 > good idea=20 > > because of that. > >=20 > >> 2. SYN flood protection at the server. > >=20 > > I might miss something fundamental, but if a server is in SYN flood=20 > > protection mode, would it not be a good idea if the client=20 > backs off a=20 > > bit? >=20 > During SYN flood protection, I'm assuming the server will=20 > aggressively drop SYN with data, but accept SYN without data=20 > more readily. > Therefore, retransmit the SYN without data, then back off as normal. Sure, it makes sense to drop SYN with data first. But my concern is the overall increase of the server load that this early r= etransmission causes. For instance, consider a server that is flooded by SY= Ns and, as a result, the processing of a SYN may require some additional ti= me, possibly resulting in an overall RTT larger than 100ms. If you then ret= ransmit the SYN after 100ms, the load on the overloaded server is further i= ncreased, possibly by factor two, because every SYN is basically sent twice= , and the server thus has to process twice the number of SYNs. That is inde= pendent of what exactly is done with SYN data. Actually, in such a case it really matters why a server enters SYN flood pr= otection, where the actual processing/resource bottlenecks are, etc. Maybe = these are non-issues in practice. But it seems to require at least some car= eful thinking. Michael From jakob.heitz@ericsson.com Wed Jan 2 15:59:43 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 2941021F8834 for ; Wed, 2 Jan 2013 15:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 pCHvKZMXx6LN for ; Wed, 2 Jan 2013 15:59:42 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8498721F882C for ; Wed, 2 Jan 2013 15:59:42 -0800 (PST) Received: from EUSAAHC001.ericsson.se ([147.117.188.75]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id r02Nxc8o007712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Jan 2013 17:59:38 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 18:59:37 -0500 From: Jakob Heitz To: "Scharf, Michael (Michael)" , "Yoshifumi Nishida" Thread-Topic: [tcpm] About the SYN/ACK-timer Thread-Index: AQHN6Kmen9PlwwSgXU2cX18Avy7He5g1+RIA///C3m2AAAWQIIAAm/sQgABKcvCAAA/S8A== Date: Wed, 2 Jan 2013 23:59:37 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E14A873@eusaamb109.ericsson.se> References: <1D1BEDF8-28D1-41CD-999C-5627E81D0537@ifi.uio.no> <20130102025350.AF22755A074@lawyers.icir.org> <2F3EBB88EC3A454AAB08915FBF0B8C7E148E68@eusaamb109.ericsson.se>, <9DF82729-E83B-4515-8BCD-D33E4EBC3E39@ericsson.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4F@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E14A253@eusaamb109.ericsson.se> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE58@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE58@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" , "mallman@icir.org" , Michael Welzl , Marco Mellia , Joe Touch Subject: Re: [tcpm] About the SYN/ACK-timer 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, 02 Jan 2013 23:59:43 -0000 On Wednesday, January 02, 2013 3:28 PM, Scharf, Michael (Michael) <> wrote: >>>> The reason for the accelerated first retransmission: >>>> The SYN with data may get dropped for 2 reasons. >>>> 1. Middleboxes that consider it abnormal. >>>=20 >>> If there is such a middlebox, the best solution is to try to learn >>> that and cache it, on order to avoid the use of SYN data at all. >>=20 >> Of course it is, but there is no need to standardize that. >>=20 >>> This is mostly orthogonal to the retransmission timer. Except for >>> one detail: The smaller the gap between the two transmissions, the >>> higher is the risk of reordering, i. e., that such heuristics break >>> because the RTO is *too* small. Thus, accelerated first >>> retranmission can indeed have drawbacks with middleboxes... >>=20 >> no. >> It will pass the lone SYN (misordered, arrives first) Then it >> will drop the SYN with data. >> No harm done. >=20 > Well, right for that case. >=20 > But if there is *no* middlebox (hopefully the default in the > Internet), and if there is reordering, the sender sees that > the SYN w/o data got through first (I guess that the SYN with > data will have to be dropped). Therefore, the sender has to > wrongly assume that there is a malicious middlebox. As a > result, it will probably needlessly disable the use of SYN > data for that path. That would be old code. Even then, it still works. > If so, there is harm. >=20 > The whole point here is that this risk is probably higher for > a gap of 100ms, compared to 1s. >=20 >>> And, with an initial RTO of 1s, >>> the only penalty is the 1s timeout for the first connection. >>> After that, the sender would hopefully not use SYN data any more. >>>=20 >>> So, what remains is the 1s RTO for the first connection to that >>> destination. An initial timeout below one second to an unknown >>> destination comes along with quite some risk of spuriour >>> retransmission on narrow-band links. It might not be a too good >>> idea because of that.=20 >>>=20 >>>> 2. SYN flood protection at the server. >>>=20 >>> I might miss something fundamental, but if a server is in SYN flood >>> protection mode, would it not be a good idea if the client backs >>> off a bit? >>=20 >> During SYN flood protection, I'm assuming the server will >> aggressively drop SYN with data, but accept SYN without data >> more readily. >> Therefore, retransmit the SYN without data, then back off as normal. >=20 > Sure, it makes sense to drop SYN with data first. >=20 > But my concern is the overall increase of the server load > that this early retransmission causes. For instance, consider > a server that is flooded by SYNs and, as a result, the > processing of a SYN may require some additional time, > possibly resulting in an overall RTT larger than 100ms. If > you then retransmit the SYN after 100ms, the load on the > overloaded server is further increased, possibly by factor > two, because every SYN is basically sent twice, and the > server thus has to process twice the number of SYNs. That is > independent of what exactly is done with SYN data. Processing a duplicate SYN is even less work than processing a new SYN. This really is no drama. The prolific use of multiple TCP connections by browsers over several years has not dented the internet, much less melted it down. >=20 > Actually, in such a case it really matters why a server > enters SYN flood protection, where the actual > processing/resource bottlenecks are, etc. Maybe these are > non-issues in practice. But it seems to require at least some careful > thinking.=20 >=20 > Michael --=20 Jakob Heitz. From swmike@swm.pp.se Thu Jan 3 00:23: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 A1B7021F8994 for ; Thu, 3 Jan 2013 00:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 bw0wGm3BOc+C for ; Thu, 3 Jan 2013 00:23:36 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 01E7C21F86C1 for ; Thu, 3 Jan 2013 00:23:35 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7E5839E; Thu, 3 Jan 2013 09:23:33 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 759049A; Thu, 3 Jan 2013 09:23:33 +0100 (CET) Date: Thu, 3 Jan 2013 09:23:33 +0100 (CET) From: Mikael Abrahamsson To: Yuchung Cheng In-Reply-To: Message-ID: References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <6DD8401E-F2FD-4411-8A91-39441B42D742@weston.borman.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 03 Jan 2013 08:23:36 -0000 On Wed, 2 Jan 2013, Yuchung Cheng wrote: > FWIW, we are developing/experimenting a "system" similar to your > connection manager idea to guide TCP connections. > http://www.ietf.org/proceedings/84/slides/slides-84-iccrg-3.pdf That looks very promising. To me, it sounds like the functionality I'm looking for could be incorporated in a system/framework you're describing in those slides. The system you're describing would be helped to get information from connection manager, as the connection manager actually knows a little bit about what connection is currently handling default route traffic (if the computer is moved from wifi, to mobile Internet, to fixed connection) and the least your system would need then I guess, would be to get notified that things have changed and take into account that network connectivity has changed. If the connection manager knows that the 3G connection is down and if it's coming back up, it's for sure that the old IP address isn't coming back, then it would make sense to just reset all TCP sessions associated with that address. So I believe the connection manager has valuable information for TCP, or something that interfaces with TCP and instructs TCP what to do. So perhaps this actually is not a TCP problem per se, apart from that there is need for an API to control TCP. > Dave and Joe are discussing that such a system can interface with TCP, > not built into TCP itself. The TCP people see such a system as separate > component, but app developers consider this part of transport/network > layer or sometimes kernel's job. I would agree that the view of such a system might differ from who you ask. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Thu Jan 3 00:26: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 D1C3A21F88B9 for ; Thu, 3 Jan 2013 00:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 082tWpxqDb04 for ; Thu, 3 Jan 2013 00:26:31 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA5F21F8438 for ; Thu, 3 Jan 2013 00:26:31 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2F9429C; Thu, 3 Jan 2013 09:26:30 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2B3A79A; Thu, 3 Jan 2013 09:26:30 +0100 (CET) Date: Thu, 3 Jan 2013 09:26:30 +0100 (CET) From: Mikael Abrahamsson To: Joe Touch In-Reply-To: <50E4A4F2.8050702@isi.edu> Message-ID: References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@isi.edu> <50E48874.9030906@isi.edu> <50E48DA3.9060409@isi.edu> <50E4A4F2.8050702@isi.edu> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 03 Jan 2013 08:26:31 -0000 On Wed, 2 Jan 2013, Joe Touch wrote: >> Well, it's not the behaviour I want. I want keepalives at a single >> instance, once each time my network connectivity has been re-established. > > How do you know? Network connectivity is defined as a connected path, not > just an interface state. I am well aware of that, and I don't want to send keepalives every 5 seconds during my entire uptime just because I want to solve a suspend/resume issue. > PS - if you have keepalives set, TCP doesn't necessarily send keepalive > packets if there are already other data packets being exchanged. The > packets are sent only when nothing else is. I am aware of that. > OS vendors already have implemented this. However, if you want a timer > that flushes all current connections when a TCP goes away that's fine > too - just note that it may kill connections you want. The user level - > whether implemented inside the OS, in a library, in user code - can > always ABORT or CLOSE connections any time it wants. I don't what wholesale killing of all connections the way Windows seem to do it. I want the sessions which are still viable to be detected as such, the ones that are not viable (other end sends RST) should go away asap. -- Mikael Abrahamsson email: swmike@swm.pp.se From olivier.bonaventure@uclouvain.be Thu Jan 3 02:28: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 6DA6D21F8AB0 for ; Thu, 3 Jan 2013 02:28:19 -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 6C8twDwUCy6D for ; Thu, 3 Jan 2013 02:28:18 -0800 (PST) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 767E921F8AA8 for ; Thu, 3 Jan 2013 02:28:18 -0800 (PST) Received: from mbpobo.dhcp.info.ucl.ac.be (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id CA6DE11E165; Thu, 3 Jan 2013 11:28:12 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be CA6DE11E165 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1357208892; bh=xGqWgGceTs4lWxFQ75GfQSFmGUyK3ovz1r/yhi6uT+o=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=v4hpEsuteRICbHKEJUgiYE+TSoCr/tfmdS20omnuoqolUh+mnrv2Dejovjo5qLMje NA8yJF9mejfE4OfTx1eCPllNOhz41xBKYxR3P3iXw53tE5eCaKKrWMF4UZ6nGHBOwT sfpLr27tFTtV0vJImFkRslW6QzeFfD0myBka2fLA= Message-ID: <50E55D3C.7070300@uclouvain.be> Date: Thu, 03 Jan 2013 11:28:12 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <6DD8401E-F2FD-4411-8A91-39441B42D742@weston.borman.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.3-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: CA6DE11E165.A3FCD X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 10:28:19 -0000 Mikael, > >> Nope, I didn't say that. After a sleep/resume cycle, maybe things >> have changed, maybe not. There's nothing wrong with telling TCP that >> things might have changed. The question is what should TCP do with >> that information, beyond what it is already doing? In the ssh >> example, TCP could aggressively determine whether or not particular >> connections are still useful, and drop them quickly. Or not. If I >> unplug my laptop from the ethernet and walk over to another office for >> a few minutes, and there connect via wi-fi (different network, >> different IP address), then do I really want all my idle SSH >> connections to go away? Not necessarily, I'm going to go back to my >> office, plug it back into the ethernet, and then the idle SSH >> connections can work again when the old IP address again is available >> on my ethernet interface. > > My idea the whole time has been that this would be configurable in the > conncetion manager. I just wanted an API (or functionality) for the > program to trigger the TCP stack functionality I am describing, and I > thought it would be a good idea to have a guiding document that > describes this. Multipath TCP already includes such functionnalities and this is transparent for the application. You can start an ssh when plugged over ethernet, move to a pub and multipath TCP will open a subflow over the WiFi interface. When you come back to the office, a new subflow is open automatically and your ssh session continues. The Multipath TCP code in the Linux kernel ( http://www.multipath-tcp.org ) already supports this Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From swmike@swm.pp.se Thu Jan 3 03:40:46 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 04A8521F8AE3 for ; Thu, 3 Jan 2013 03:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 E0JQIa-oeWGw for ; Thu, 3 Jan 2013 03:40:45 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 65CB221F84D0 for ; Thu, 3 Jan 2013 03:40:44 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id BD7899C; Thu, 3 Jan 2013 12:40:41 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B6FCD9A; Thu, 3 Jan 2013 12:40:41 +0100 (CET) Date: Thu, 3 Jan 2013 12:40:41 +0100 (CET) From: Mikael Abrahamsson To: Olivier Bonaventure In-Reply-To: <50E55D3C.7070300@uclouvain.be> Message-ID: References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <6DD8401E-F2FD-4411-8A91-39441B42D742@weston.borman.com> <50E55D3C.7070300@uclouvain.be> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 03 Jan 2013 11:40:46 -0000 On Thu, 3 Jan 2013, Olivier Bonaventure wrote: > Multipath TCP already includes such functionnalities and this is transparent > for the application. The application doesn't know anything about whether the ethernet plug is in or not, the connection manager does. > You can start an ssh when plugged over ethernet, move to a pub and > multipath TCP will open a subflow over the WiFi interface. When you come > back to the office, a new subflow is open automatically and your ssh > session continues. How long does that take? Remember network might have been out for 5 minutes so all sessions might be in max retransmit timer mode. Also, how does multipath TCP handle multiple default routes? If I have wifi and 4G and LAN at the same time, the OS usually selects the LAN default route for all traffic, meaning Wifi and 4G IPs will be dropped by ISP antispoofing filter. -- Mikael Abrahamsson email: swmike@swm.pp.se From olivier.bonaventure@uclouvain.be Thu Jan 3 05:07: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 0EB3421F8C05 for ; Thu, 3 Jan 2013 05:07: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 d03jNng1LcGg for ; Thu, 3 Jan 2013 05:07:07 -0800 (PST) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id BF65721F8C03 for ; Thu, 3 Jan 2013 05:07:06 -0800 (PST) Received: from mbpobo.dhcp.info.ucl.ac.be (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 137B11C6278; Thu, 3 Jan 2013 14:07:01 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 137B11C6278 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1357218421; bh=2FNQw+XADbe9XMi+sQnBEdmK/t5b8YfOEvyXm8++xN4=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Dib5CtETc/bgnnVzUjCxMFSSIeoJFNptJHVd762aFHAF8LgI8VY14HrTtOARf6b5U SDcbofKg16+GqmLGrkycxVZHeVbXCm+gQc5rNUYG8XJYWjWj0gmpLYK1U2b4CBAH0v 3+Qelvaa1UNI23Dg6iAgN2oIfg7hy6XVZkDLjCEI= Message-ID: <50E58274.80709@uclouvain.be> Date: Thu, 03 Jan 2013 14:07:00 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <6DD8401E-F2FD-4411-8A91-39441B42D742@weston.borman.com> <50E55D3C.7070300@uclouvain.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.3-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 137B11C6278.A42C8 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 13:07:08 -0000 Mikael, > >> Multipath TCP already includes such functionnalities and this is >> transparent for the application. > > The application doesn't know anything about whether the ethernet plug is > in or not, the connection manager does. Multipath TCP is informed about the arrival/removal of IP addresses and can create the necessary subflows. >> You can start an ssh when plugged over ethernet, move to a pub and >> multipath TCP will open a subflow over the WiFi interface. When you >> come back to the office, a new subflow is open automatically and your >> ssh session continues. > > How long does that take? Remember network might have been out for 5 > minutes so all sessions might be in max retransmit timer mode. Standard TCP timer setting applies if there are retransmissions. A Multipath TCP connection is composed of one of more TCP subflows. Multipath TCP schedules the packet transmission on the different available subflows. If no subflow is available, Multipath TCP can create a new one. A TCP subflow may die due to excessive retransmissions but the Multipath TCP connection state could potentially remain active and another subflow could be reestablished. > Also, how does multipath TCP handle multiple default routes? If I have > wifi and 4G and LAN at the same time, the OS usually selects the LAN > default route for all traffic, meaning Wifi and 4G IPs will be dropped > by ISP antispoofing filter. No, Multipath TCP works by using one TCP subflow over each interface. If you have LAN, 4G and WiFi, you have 3 IP addresses. Let's assume that the LAN address is the default one. If you create an MPTCP connection, it will be initiated from this address. Once the three-way handshake has been done over the LAN interface, MPTCP will start a new handshake over the 4G and over the WiFi interface. You then have three subflows that can be used to send and receive data. If you lose LAN interface or change its IP address, a new subflow can be reestablished. You can find some information about the design of MPTCP at http://inl.info.ucl.ac.be/publications/how-hard-can-it-be-designing-and-implementing-deployable-multipath-tcp and its usage in mobile environments at http://inl.info.ucl.ac.be/publications/exploring-mobilewifi-handover-multipath-tcp Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From swmike@swm.pp.se Thu Jan 3 05:39:39 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 DFE6D21E803A for ; Thu, 3 Jan 2013 05:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 Y6Oh3jPY5x1G for ; Thu, 3 Jan 2013 05:39:39 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 2E82521E8034 for ; Thu, 3 Jan 2013 05:39:39 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4CD5E9C; Thu, 3 Jan 2013 14:39:37 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 43C129A; Thu, 3 Jan 2013 14:39:37 +0100 (CET) Date: Thu, 3 Jan 2013 14:39:37 +0100 (CET) From: Mikael Abrahamsson To: Olivier Bonaventure In-Reply-To: <50E58274.80709@uclouvain.be> Message-ID: References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <6DD8401E-F2FD-4411-8A91-39441B42D742@weston.borman.com> <50E55D3C.7070300@uclouvain.be> <50E58274.80709@uclouvain.be> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 03 Jan 2013 13:39:40 -0000 On Thu, 3 Jan 2013, Olivier Bonaventure wrote: > No, Multipath TCP works by using one TCP subflow over each interface. If > you have LAN, 4G and WiFi, you have 3 IP addresses. Let's assume that > the LAN address is the default one. If you create an MPTCP connection, > it will be initiated from this address. Once the three-way handshake has > been done over the LAN interface, MPTCP will start a new handshake over > the 4G and over the WiFi interface. You then have three subflows that > can be used to send and receive data. If you lose LAN interface or > change its IP address, a new subflow can be reestablished. You seem to have misunderstood my question. If I have eth0, ppp0 and wlan0 with one address each, my system will still only have a single default route, where all packets are going out. I am not allowed to source traffic from ppp0 and wlan0 out eth0 as it will be dropped by the ISP router as soon as it reaches their router (uRPF). So unless my system also uses source based routing and/or has each interface in its own routing domain, even though I now have three IP addresses, only the eth0 one is actually usable for reaching The Internet (as any traffic sourced from ppp0 and wlan0 will be dropped). > http://inl.info.ucl.ac.be/publications/how-hard-can-it-be-designing-and-implementing-deployable-multipath-tcp A quick browse yielded nothing about my above question. -- Mikael Abrahamsson email: swmike@swm.pp.se From olivier.bonaventure@uclouvain.be Thu Jan 3 05:47:48 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 2B5BB21E8049 for ; Thu, 3 Jan 2013 05:47:48 -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 TnTV8mEofEuh for ; Thu, 3 Jan 2013 05:47:47 -0800 (PST) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 342CD21E8045 for ; Thu, 3 Jan 2013 05:47:47 -0800 (PST) Received: from mbpobo.dhcp.info.ucl.ac.be (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id CC72B1C60E7; Thu, 3 Jan 2013 14:47:41 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be CC72B1C60E7 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1357220861; bh=xl6sC5duQo1+UE/bx6AvC0LoLi967fEyYHfHghyGqmI=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=M3V4byjMvB6i1HC8iBjtCOwN0MvRsBZF0NfEmDOxuO19ssxFTD2llqbZveNmzEWiA 0o7T1yxwcDtOWmvp7MZyV4FPLK0mP8oIzkBUR67RcqOK6/dwT2jmXo2spYNNIxJ3DE 0rmJGE68YD9dGlQW5PlS7PwXBYHac7WmY10JD3oA= Message-ID: <50E58BFD.6010606@uclouvain.be> Date: Thu, 03 Jan 2013 14:47:41 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <6DD8401E-F2FD-4411-8A91-39441B42D742@weston.borman.com> <50E55D3C.7070300@uclouvain.be> <50E58274.80709@uclouvain.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.3-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: CC72B1C60E7.A267A X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 13:47:48 -0000 Mikael, > >> No, Multipath TCP works by using one TCP subflow over each interface. >> If you have LAN, 4G and WiFi, you have 3 IP addresses. Let's assume >> that the LAN address is the default one. If you create an MPTCP >> connection, it will be initiated from this address. Once the three-way >> handshake has been done over the LAN interface, MPTCP will start a new >> handshake over the 4G and over the WiFi interface. You then have three >> subflows that can be used to send and receive data. If you lose LAN >> interface or change its IP address, a new subflow can be reestablished. > > You seem to have misunderstood my question. > > If I have eth0, ppp0 and wlan0 with one address each, my system will > still only have a single default route, where all packets are going out. > I am not allowed to source traffic from ppp0 and wlan0 out eth0 as it > will be dropped by the ISP router as soon as it reaches their router > (uRPF). Of course. Multipath TCP will only send packets with the IP address assigned to each interface when sending them over one interface. We know that packet with other source addresses will be subject to uRPF. > So unless my system also uses source based routing and/or has each > interface in its own routing domain, even though I now have three IP > addresses, only the eth0 one is actually usable for reaching The > Internet (as any traffic sourced from ppp0 and wlan0 will be dropped). > >> http://inl.info.ucl.ac.be/publications/how-hard-can-it-be-designing-and-implementing-deployable-multipath-tcp >> > > A quick browse yielded nothing about my above question. The Linux implementation uses one routing table per interface so that in your case the ppp0 and wlan0 interfaces can be used as well. See http://mptcp.info.ucl.ac.be/pmwiki.php?n=Users.ConfigureRouting Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From swmike@swm.pp.se Thu Jan 3 05:58:42 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 93B9C11E8099 for ; Thu, 3 Jan 2013 05:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 JfguX9Ona1nM for ; Thu, 3 Jan 2013 05:58:42 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id E11F811E8097 for ; Thu, 3 Jan 2013 05:58:41 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 146729C; Thu, 3 Jan 2013 14:58:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0FFE49A; Thu, 3 Jan 2013 14:58:39 +0100 (CET) Date: Thu, 3 Jan 2013 14:58:39 +0100 (CET) From: Mikael Abrahamsson To: Olivier Bonaventure In-Reply-To: <50E58BFD.6010606@uclouvain.be> Message-ID: References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <6DD8401E-F2FD-4411-8A91-39441B42D742@weston.borman.com> <50E55D3C.7070300@uclouvain.be> <50E58274.80709@uclouvain.be> <50E58BFD.6010606@uclouvain.be> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 03 Jan 2013 13:58:42 -0000 On Thu, 3 Jan 2013, Olivier Bonaventure wrote: > The Linux implementation uses one routing table per interface so that in your > case the ppp0 and wlan0 interfaces can be used as well. > > See > > http://mptcp.info.ucl.ac.be/pmwiki.php?n=Users.ConfigureRouting Exactly what I was looking for, thanks. I've seen the same problem with SCTP implementations that didn't have this as well. Vendors are getting better at this over time though. What we need to happen is that the connection manager should do this automatically as it adds routes etc. This needs to work dynamically with DHCP and other ways of handing out IPs and routes. Have you had any luck in getting traction for this with OS vendors? -- Mikael Abrahamsson email: swmike@swm.pp.se From touch@isi.edu Thu Jan 3 13:36: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 2CCC121F8D40 for ; Thu, 3 Jan 2013 13:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 dAjHG0BrJn82 for ; Thu, 3 Jan 2013 13:36:07 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8D51521F8CF1 for ; Thu, 3 Jan 2013 13:36:07 -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 r03LZj52017629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Jan 2013 13:35:45 -0800 (PST) Message-ID: <50E5F9B1.4010006@isi.edu> Date: Thu, 03 Jan 2013 13:35:45 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@isi.edu> <50E48874.9030906@isi.edu> <50E48DA3.9060409@isi.edu> <50E4A4F2.8050702@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] host behaviour when connectivity is lost 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, 03 Jan 2013 21:36:08 -0000 On 1/3/2013 12:26 AM, Mikael Abrahamsson wrote: > On Wed, 2 Jan 2013, Joe Touch wrote: > >>> Well, it's not the behaviour I want. I want keepalives at a single >>> instance, once each time my network connectivity has been >>> re-established. >> >> How do you know? Network connectivity is defined as a connected path, >> not just an interface state. > > I am well aware of that, and I don't want to send keepalives every 5 > seconds during my entire uptime just because I want to solve a > suspend/resume issue. > >> PS - if you have keepalives set, TCP doesn't necessarily send >> keepalive packets if there are already other data packets being >> exchanged. The packets are sent only when nothing else is. > > I am aware of that. > >> OS vendors already have implemented this. However, if you want a timer >> that flushes all current connections when a TCP goes away that's fine >> too - just note that it may kill connections you want. The user level >> - whether implemented inside the OS, in a library, in user code - can >> always ABORT or CLOSE connections any time it wants. > > I don't what wholesale killing of all connections the way Windows seem > to do it. I want the sessions which are still viable to be detected as > such, the ones that are not viable (other end sends RST) should go away > asap. That's the trick; "viable" is a relative thing, at best known only when you actually want to send more data on the connection. That's when most TCP implementations bother to clean up stale state, since that's the only time it really matters. Joe From swmike@swm.pp.se Thu Jan 3 22:16:23 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 89CAB21F88F1 for ; Thu, 3 Jan 2013 22:16:23 -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 dScXDEDqb9Ok for ; Thu, 3 Jan 2013 22:16:22 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id AF6EB21F88D8 for ; Thu, 3 Jan 2013 22:16:22 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2D1789C; Fri, 4 Jan 2013 07:16:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 267659A; Fri, 4 Jan 2013 07:16:20 +0100 (CET) Date: Fri, 4 Jan 2013 07:16:20 +0100 (CET) From: Mikael Abrahamsson To: Joe Touch In-Reply-To: <50E5F9B1.4010006@isi.edu> Message-ID: References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@isi.edu> <50E48874.9030906@isi.edu> <50E48DA3.9060409@isi.edu> <50E4A4F2.8050702@isi.edu> <50E5F9B1.4010006@isi.edu> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 04 Jan 2013 06:16:23 -0000 On Thu, 3 Jan 2013, Joe Touch wrote: > That's the trick; "viable" is a relative thing, at best known only when > you actually want to send more data on the connection. That's when most > TCP implementations bother to clean up stale state, since that's the > only time it really matters. Well, there is data outbound I want to send it *ASAP*, but TCP thinks it needs to wait 50 seconds because it's been in exponential backoff because of the network outage that is now rectified (and known by the connection manager as being rectified). Why should I wait 49 seconds extra because the connection manager and TCP doesn't share information? The connection manager also knows that half my TCP sessions are never going to be viable ever again because the IP address they're bound to is gone and is never going to return (because it was on my 4G USB dongle). -- Mikael Abrahamsson email: swmike@swm.pp.se From touch@isi.edu Thu Jan 3 22:47: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 358D921F858C for ; Thu, 3 Jan 2013 22:47:15 -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 JQZvZsNKl9Ql for ; Thu, 3 Jan 2013 22:47:14 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id AA6F321F8589 for ; Thu, 3 Jan 2013 22:47:14 -0800 (PST) Received: from [192.168.1.95] (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 r046kxQm017426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Jan 2013 22:47:04 -0800 (PST) Message-ID: <50E67AE3.6030800@isi.edu> Date: Thu, 03 Jan 2013 22:46:59 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@isi.edu> <50E48874.9030906@isi.edu> <50E48DA3.9060409@isi.edu> <50E4A4F2.8050702@isi.edu> <50E5F9B1.4010006@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] host behaviour when connectivity is lost 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, 04 Jan 2013 06:47:15 -0000 On 1/3/2013 10:16 PM, Mikael Abrahamsson wrote: > On Thu, 3 Jan 2013, Joe Touch wrote: > >> That's the trick; "viable" is a relative thing, at best known only >> when you actually want to send more data on the connection. That's >> when most TCP implementations bother to clean up stale state, since >> that's the only time it really matters. > > Well, there is data outbound I want to send it *ASAP*, but TCP thinks it > needs to wait 50 seconds because it's been in exponential backoff > because of the network outage that is now rectified (and known by the > connection manager as being rectified). > > Why should I wait 49 seconds extra because the connection manager and > TCP doesn't share information? The trouble is that there are other cases that are indistinguishable - i.e., when the network interface goes down then up but the reason packets aren't getting through is that the network is congested. I.e., sharing information isn't the issue; it's the fact that the information your sharing isn't complete. Did your connection manager check the path to make sure that the TCP packets will get through? Did it do probes in a way that won't create congestion in a case where congestion was what brought the path down (or made it appear so)? That's exactly why TCP does what it does. Assuming that some omniscient entity knows better is a fine academic exercise, but easily creates a tragedy of the commons in the real world. > The connection manager also knows that half my TCP sessions are never > going to be viable ever again because the IP address they're bound to is > gone and is never going to return (because it was on my 4G USB dongle). How does it "know" the address will never return? Restarting your dongle could easily result in reassigning the same address. Joe From jakob.heitz@ericsson.com Thu Jan 3 23:36: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 84E5521F86CD for ; Thu, 3 Jan 2013 23:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.114, 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 jlb-TexNvT4f for ; Thu, 3 Jan 2013 23:36:46 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9494121F85EE for ; Thu, 3 Jan 2013 23:36:46 -0800 (PST) Received: from EUSAAHC003.ericsson.se ([147.117.188.81]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id r047aiP6014959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jan 2013 01:36:45 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.004; Fri, 4 Jan 2013 02:36:44 -0500 From: Jakob Heitz To: Joe Touch , Mikael Abrahamsson Thread-Topic: [tcpm] host behaviour when connectivity is lost Thread-Index: AQHN6EV/o0lKVsvSj0+2rT1fksKO9Jg1JZMAgACa2ACAAFKqAIAARCoAgABclQCAAAo7gIAAAaAAgAAClwCAAAOXgIAAB2WAgAAUZACAALmwAIAA3IOAgACRcwCAAAiRgP//uQtQ Date: Fri, 4 Jan 2013 07:36:43 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E14D31E@eusaamb109.ericsson.se> References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@isi.edu> <50E48874.9030906@isi.edu> <50E48DA3.9060409@isi.edu> <50E4A4F2.8050702@isi.edu> <50E5F9B1.4010006@isi.edu> <50E67AE3.6030800@isi.edu> In-Reply-To: <50E67AE3.6030800@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 04 Jan 2013 07:36:47 -0000 The trouble with TCP keepalives is they take too long. 1. They should not be sent more frequently than 2 hours. 2. If the keepalive fails, it takes at least 100 seconds to find out. TCP needs an "on demand" keepalive. For example, send 3 of them, one second apart and die if no response in 5 seconds. Something like that. On , Joe Touch <> wrote: > On 1/3/2013 10:16 PM, Mikael Abrahamsson wrote: >> On Thu, 3 Jan 2013, Joe Touch wrote: >>=20 >>> That's the trick; "viable" is a relative thing, at best known only >>> when you actually want to send more data on the connection. That's >>> when most TCP implementations bother to clean up stale state, since >>> that's the only time it really matters. >>=20 >> Well, there is data outbound I want to send it *ASAP*, but TCP >> thinks it needs to wait 50 seconds because it's been in exponential >> backoff because of the network outage that is now rectified (and >> known by the connection manager as being rectified). >>=20 >> Why should I wait 49 seconds extra because the connection manager and >> TCP doesn't share information? >=20 > The trouble is that there are other cases that are > indistinguishable - > i.e., when the network interface goes down then up but the reason > packets aren't getting through is that the network is congested. >=20 > I.e., sharing information isn't the issue; it's the fact that the > information your sharing isn't complete. Did your connection manager > check the path to make sure that the TCP packets will get > through? Did > it do probes in a way that won't create congestion in a case where > congestion was what brought the path down (or made it appear > so)? That's > exactly why TCP does what it does. Assuming that some > omniscient entity > knows better is a fine academic exercise, but easily creates > a tragedy > of the commons in the real world. >=20 >> The connection manager also knows that half my TCP sessions are never >> going to be viable ever again because the IP address they're bound >> to is gone and is never going to return (because it was on my 4G USB >> dongle).=20 >=20 > How does it "know" the address will never return? Restarting > your dongle > could easily result in reassigning the same address. >=20 > Joe > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --=20 Jakob Heitz. From touch@isi.edu Fri Jan 4 10:56: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 B14AD21F881C for ; Fri, 4 Jan 2013 10:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.713 X-Spam-Level: X-Spam-Status: No, score=-102.713 tagged_above=-999 required=5 tests=[AWL=-0.114, 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 rx0rf1XvVGhV for ; Fri, 4 Jan 2013 10:56:25 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED8A21F87ED for ; Fri, 4 Jan 2013 10:56:25 -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 r04ItrS0003470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Jan 2013 10:55:53 -0800 (PST) Message-ID: <50E725B9.5060009@isi.edu> Date: Fri, 04 Jan 2013 10:55:53 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jakob Heitz References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@isi.edu> <50E48874.9030906@isi.edu> <50E48DA3.9060409@isi.edu> <50E4A4F2.8050702@isi.edu> <50E5F9B1.4010006@isi.edu> <50E67AE3.6030800@isi.edu> <2F3EBB88EC3A454AAB08915FBF0B8C7E14D31E@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E14D31E@eusaamb109.ericsson.se> 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] host behaviour when connectivity is lost 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, 04 Jan 2013 18:56:25 -0000 Please review RFC 1122, Section 4.2.3.6 Keepalives *default* to off and a 2-hour interval, but also *must* be configurable. If you want a 1-second keepalive, you should configure it as such. Joe On 1/3/2013 11:36 PM, Jakob Heitz wrote: > The trouble with TCP keepalives is they take too long. > 1. They should not be sent more frequently than 2 hours. > 2. If the keepalive fails, it takes at least 100 seconds to find out. > > TCP needs an "on demand" keepalive. > For example, send 3 of them, one second apart and > die if no response in 5 seconds. Something like that. > > On , Joe Touch <> wrote: > >> On 1/3/2013 10:16 PM, Mikael Abrahamsson wrote: >>> On Thu, 3 Jan 2013, Joe Touch wrote: >>> >>>> That's the trick; "viable" is a relative thing, at best known only >>>> when you actually want to send more data on the connection. That's >>>> when most TCP implementations bother to clean up stale state, since >>>> that's the only time it really matters. >>> >>> Well, there is data outbound I want to send it *ASAP*, but TCP >>> thinks it needs to wait 50 seconds because it's been in exponential >>> backoff because of the network outage that is now rectified (and >>> known by the connection manager as being rectified). >>> >>> Why should I wait 49 seconds extra because the connection manager and >>> TCP doesn't share information? >> >> The trouble is that there are other cases that are >> indistinguishable - >> i.e., when the network interface goes down then up but the reason >> packets aren't getting through is that the network is congested. >> >> I.e., sharing information isn't the issue; it's the fact that the >> information your sharing isn't complete. Did your connection manager >> check the path to make sure that the TCP packets will get >> through? Did >> it do probes in a way that won't create congestion in a case where >> congestion was what brought the path down (or made it appear >> so)? That's >> exactly why TCP does what it does. Assuming that some >> omniscient entity >> knows better is a fine academic exercise, but easily creates >> a tragedy >> of the commons in the real world. >> >>> The connection manager also knows that half my TCP sessions are never >>> going to be viable ever again because the IP address they're bound >>> to is gone and is never going to return (because it was on my 4G USB >>> dongle). >> >> How does it "know" the address will never return? Restarting >> your dongle >> could easily result in reassigning the same address. >> >> Joe >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > > From jakob.heitz@ericsson.com Fri Jan 4 11:04:23 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 10E3E21F87ED for ; Fri, 4 Jan 2013 11:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 OP75TyzsQCOM for ; Fri, 4 Jan 2013 11:04:22 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2D90321F8753 for ; Fri, 4 Jan 2013 11:04:22 -0800 (PST) Received: from EUSAAHC005.ericsson.se ([147.117.188.87]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id r04J4JcT031029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jan 2013 13:04:20 -0600 Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Fri, 4 Jan 2013 14:04:18 -0500 From: Jakob Heitz To: Joe Touch Thread-Topic: [tcpm] host behaviour when connectivity is lost Thread-Index: AQHN6EV/o0lKVsvSj0+2rT1fksKO9Jg1JZMAgACa2ACAAFKqAIAARCoAgABclQCAAAo7gIAAAaAAgAAClwCAAAOXgIAAB2WAgAAUZACAALmwAIAA3IOAgACRcwCAAAiRgP//uQtQgAESnID//63WMA== Date: Fri, 4 Jan 2013 19:04:18 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E14DC16@eusaamb109.ericsson.se> References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@isi.edu> <50E48874.9030906@isi.edu> <50E48DA3.9060409@isi.edu> <50E4A4F2.8050702@isi.edu> <50E5F9B1.4010006@isi.edu> <50E67AE3.6030800@isi.edu> <2F3EBB88EC3A454AAB08915FBF0B8C7E14D31E@eusaamb109.ericsson.se> <50E725B9.5060009@isi.edu> In-Reply-To: <50E725B9.5060009@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 04 Jan 2013 19:04:23 -0000 On Friday, January 04, 2013 10:56 AM, Joe Touch wrot= e: > Please review RFC 1122, Section 4.2.3.6 >=20 > Keepalives *default* to off and a 2-hour interval, but also *must* be > configurable.=20 >=20 > If you want a 1-second keepalive, you should configure it as such. >=20 > Joe >=20 Also in TCP, if the keepalive fails, it takes an eternity of retransmissions before TCP fails. This is why many applications, including BGP, use an application level keepalive. I don't want a 1 second keepalive. I want an on-demand keepalive. --=20 Jakob Heitz. From michael.scharf@alcatel-lucent.com Fri Jan 4 11:44: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 A89D821F8715 for ; Fri, 4 Jan 2013 11:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[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 4Vj1wIpUtUno for ; Fri, 4 Jan 2013 11:44:28 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id D6B1421F8703 for ; Fri, 4 Jan 2013 11:44: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 r04JiJLh007326 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Jan 2013 20:44:19 +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; Fri, 4 Jan 2013 20:44:19 +0100 From: "Scharf, Michael (Michael)" To: Jakob Heitz , Joe Touch Date: Fri, 4 Jan 2013 20:44:19 +0100 Thread-Topic: [tcpm] host behaviour when connectivity is lost Thread-Index: AQHN6EV/o0lKVsvSj0+2rT1fksKO9Jg1JZMAgACa2ACAAFKqAIAARCoAgABclQCAAAo7gIAAAaAAgAAClwCAAAOXgIAAB2WAgAAUZACAALmwAIAA3IOAgACRcwCAAAiRgP//uQtQgAESnID//63WMIAACmfw Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE70@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@isi.edu> <50E48874.9030906@isi.edu> <50E48DA3.9060409@isi.edu> <50E4A4F2.8050702@isi.edu> <50E5F9B1.4010006@isi.edu> <50E67AE3.6030800@isi.edu> <2F3EBB88EC3A454AAB08915FBF0B8C7E14D31E@eusaamb109.ericsson.se> <50E725B9.5060009@isi.edu> <2F3EBB88EC3A454AAB08915FBF0B8C7E14DC16@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E14DC16@eusaamb109.ericsson.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 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 04 Jan 2013 19:44:28 -0000 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Jakob Heitz > Sent: Friday, January 04, 2013 8:04 PM > To: Joe Touch > Cc: tcpm@ietf.org > Subject: Re: [tcpm] host behaviour when connectivity is lost >=20 > On Friday, January 04, 2013 10:56 AM, Joe Touch=20 > wrote: >=20 > > Please review RFC 1122, Section 4.2.3.6 > >=20 > > Keepalives *default* to off and a 2-hour interval, but also=20 > *must* be=20 > > configurable. > >=20 > > If you want a 1-second keepalive, you should configure it as such. > >=20 > > Joe > >=20 >=20 > Also in TCP, if the keepalive fails, it takes an eternity of=20 > retransmissions before TCP fails. >=20 > This is why many applications, including BGP, use an=20 > application level keepalive. >=20 > I don't want a 1 second keepalive. > I want an on-demand keepalive. Maybe a very naive question: What does prevent the app from reducing the ke= ep-alive interval "on-demand"? At first sight, RFC 1122 does not mandate that the interval has to be const= ant. Michael= From touch@isi.edu Fri Jan 4 11:52: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 48FA821F86C0 for ; Fri, 4 Jan 2013 11:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.694 X-Spam-Level: X-Spam-Status: No, score=-102.694 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 F6IikcLdEmpr for ; Fri, 4 Jan 2013 11:52:31 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9A29721F885C for ; Fri, 4 Jan 2013 11:52:24 -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 r04JpmX5014361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Jan 2013 11:51:48 -0800 (PST) Message-ID: <50E732D4.8040701@isi.edu> Date: Fri, 04 Jan 2013 11:51:48 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@isi.edu> <50E48874.9030906@isi.edu> <50E48DA3.9060409@isi.edu> <50E4A4F2.8050702@isi.edu> <50E5F9B1.4010006@isi.edu> <50E67AE3.6030800@isi.edu> <2F3EBB88EC3A454AAB08915FBF0B8C7E14D31E@eusaamb109.ericsson.se> <50E725B9.5060009@isi.edu> <2F3EBB88EC3A454AAB08915FBF0B8C7E14DC16@eusaamb109.ericsson.se> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE70@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE70@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] host behaviour when connectivity is lost 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, 04 Jan 2013 19:52:32 -0000 On 1/4/2013 11:44 AM, Scharf, Michael (Michael) wrote: >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On >> Behalf Of Jakob Heitz >> Sent: Friday, January 04, 2013 8:04 PM >> To: Joe Touch >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] host behaviour when connectivity is lost >> >> On Friday, January 04, 2013 10:56 AM, Joe Touch >> wrote: >> >>> Please review RFC 1122, Section 4.2.3.6 >>> >>> Keepalives *default* to off and a 2-hour interval, but also >> *must* be >>> configurable. >>> >>> If you want a 1-second keepalive, you should configure it as such. >>> >>> Joe >>> >> >> Also in TCP, if the keepalive fails, it takes an eternity of >> retransmissions before TCP fails. >> >> This is why many applications, including BGP, use an >> application level keepalive. >> >> I don't want a 1 second keepalive. >> I want an on-demand keepalive. > > Maybe a very naive question: What does prevent the app from reducing the keep-alive interval "on-demand"? > > At first sight, RFC 1122 does not mandate that the interval has to be constant. Right - that was my thought. If what you want is app-controlled keepalive, then implement it at the app layer. But so far what I see is an optimization that might work in some cases, but could backfire in a lot of others. Joe From touch@isi.edu Fri Jan 4 11:56:45 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 B9EFC21F84D8 for ; Fri, 4 Jan 2013 11:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.681 X-Spam-Level: X-Spam-Status: No, score=-102.681 tagged_above=-999 required=5 tests=[AWL=-0.082, 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 gsMbDHgkZWhR for ; Fri, 4 Jan 2013 11:56:45 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3211821F84A1 for ; Fri, 4 Jan 2013 11:56:45 -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 r04JuJhm015081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Jan 2013 11:56:19 -0800 (PST) Message-ID: <50E733E3.3060008@isi.edu> Date: Fri, 04 Jan 2013 11:56:19 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jakob Heitz References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@isi.edu> <50E48874.9030906@isi.edu> <50E48DA3.9060409@isi.edu> <50E4A4F2.8050702@isi.edu> <50E5F9B1.4010006@isi.edu> <50E67AE3.6030800@isi.edu> <2F3EBB88EC3A454AAB08915FBF0B8C7E14D31E@eusaamb109.ericsson.se> <50E725B9.5060009@isi.edu> <2F3EBB88EC3A454AAB08915FBF0B8C7E14DC16@eusaamb109.ericsson.s! e> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E14DC16@eusaamb109.ericsson.se> 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] host behaviour when connectivity is lost 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, 04 Jan 2013 19:56:45 -0000 On 1/4/2013 11:04 AM, Jakob Heitz wrote: > On Friday, January 04, 2013 10:56 AM, Joe Touch wrote: > >> Please review RFC 1122, Section 4.2.3.6 >> >> Keepalives *default* to off and a 2-hour interval, but also *must* be >> configurable. >> >> If you want a 1-second keepalive, you should configure it as such. >> >> Joe >> > > Also in TCP, if the keepalive fails, it takes an > eternity of retransmissions before TCP fails. There are several keepalive parameters: time - duration between two keepalive tests; defaults to 2 hours but must be configurable interval - duration between successive keepalive transmissions retry - how many transmissions fail before giving up Set these as you want. > This is why many applications, including BGP, > use an application level keepalive. BGP uses a keepalive because it incorrectly links TCP connectivity to IP connectivity - i.e., if TCP goes down, it wants to pull routes to that endpoint (which was a mistake IMO). So it has to try to keep the TCP connection up. It uses its own keepalives because keepalive isn't required at the TCP layer; these days it could easily use TCP keepalives instead. Joe > I don't want a 1 second keepalive. > I want an on-demand keepalive. From mallman@icir.org Mon Jan 7 10:36: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 3D97A21F8A06 for ; Mon, 7 Jan 2013 10:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXDM7pUg5zK8 for ; Mon, 7 Jan 2013 10:36:03 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4928121F8994 for ; Mon, 7 Jan 2013 10:36:03 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id r07Ia0t6023625 for ; Mon, 7 Jan 2013 10:36:01 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id E376A59343C for ; Mon, 7 Jan 2013 13:36:00 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Smoke On the Water X-URL-0: http://www.icir.org/mallman-files/Document38501.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma5520-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 07 Jan 2013 13:36:00 -0500 Sender: mallman@icir.org Message-Id: <20130107183600.E376A59343C@lawyers.icir.org> Subject: [tcpm] bufferbloat paper X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 18:36:04 -0000 ----------ma5520-1 Content-Type: text/plain Content-Disposition: inline [I tried to post this in a couple places to ensure I hit folks who would be interested. If you end up with multiple copies of the email, my apologies. --allman] I know bufferbloat has been an interest of lots of folks recently. So, I thought I'd flog a recent paper that presents a little data on the topic ... Mark Allman. Comments on Bufferbloat, ACM SIGCOMM Computer Communication Review, 43(1), January 2013. http://www.icir.org/mallman/papers/bufferbloat-ccr13.pdf Its an initial paper. I think more data would be great! allman -- http://www.icir.org/mallman/ ----------ma5520-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlDrFZAACgkQWyrrWs4yIs48PwCdGTPDDMjL3eNQ3RTNK7kWYZvJ eWQAn2OqzogHRiOIUrfN0z2NVW9XSOFD =PNPB -----END PGP SIGNATURE----- ----------ma5520-1-- From eblanton@cs.ohiou.edu Mon Jan 7 19:51:43 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 37AAD11E8097 for ; Mon, 7 Jan 2013 19:51:43 -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 y-BG9YNWHG3E for ; Mon, 7 Jan 2013 19:51:42 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id A348221F8726 for ; Mon, 7 Jan 2013 19:51:41 -0800 (PST) Received: from [99.52.196.7] (helo=mail.kb8ojh.net) by psg.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TsQDy-000DI4-8I; Tue, 08 Jan 2013 03:51:39 +0000 Received: by mail.kb8ojh.net (Postfix, from userid 1000) id 7018131BB9; Mon, 7 Jan 2013 22:51:37 -0500 (EST) Date: Mon, 7 Jan 2013 22:51:37 -0500 From: Ethan Blanton To: Mikael Abrahamsson Message-ID: <20130108035137.GA28233@mail.kb8ojh.net> Mail-Followup-To: Mikael Abrahamsson , Joe Touch , "tcpm@ietf.org" References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@isi.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline In-Reply-To: X-GnuPG-Fingerprint: CB44 99AC EDDA D1AB D6E6 A2CA FF1F 8B16 771F C72B User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 08 Jan 2013 03:51:43 -0000 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mikael Abrahamsson spake unto us the following wisdom: > >So I'm not clear on what "stuck" means for a TCP connection in > >this context. If host connectivity is lost and re-established > >later, the connection can resume. >=20 > Yes, but how long does it take for it to resume? I want my TCP > sessions to be either reset (if they're not up at both ends) or > taking traffic (which means they're not in 64s retransmit timer > mode) when my connection manager has deemed that my network > connectivity is up and running again. I actually think this is a more complex problem, caused by middle boxes and NATs and "security" and all kinds of things. When your PC resumes and you go to that SSH session and hit Enter, that will trigger SSH to send some data, and a TCP segment will go out almost immediately. (That is, assuming there wasn't data being actively sent at the time the machine went to sleep, which is often a valid assumption.) This will cause the other end to either ACK or RST, in a perfect world, at which point you'll either have a usable connection or you'll find out you were disconnected. Unfortunately, the world isn't perfect, and a LARGE percentage of the time, that data segment just disappears into the Ether. I'm not sure what all of the reasons for that are, but here are a couple of well-known reasons: * Stateful NATs and/or firewalls with timeouts can "forget" about your TCP connection whilst your machine is asleep, then silently drop your data segment because they "didn't see a SYN" and don't have state for your connection. * Misguided "security" policies on the remote machine may cause them to fail to reset packets from unknown connections, if the other machine had been sending data while your machine was asleep and eventually timed out. The trouble with these reasons is that they're not necessarily something you can fix by telling TCP "hey, shorten your timeouts", unless you want to make them *way* short (you're unhappy with ~1 minute, apparently?). Since the outgoing packets just silently disappear with no reply, the local TCP has no way of telling if there's a transient network issue (maybe not at the local interface, if your system just told the TCP the interface is good), if the end-to-end delay is simply long, etc. This seems like something that should be handled by applications that are specifically concerned about interactivity. If you don't have interactive goals, wait 64 seconds (or longer) and see what happens. If you do, then send an application layer ping after a resume, give it however long the user should be expected to wait, and reconnect. Ethan --17pEHd4RhPHOinZp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBUOuXyf8fixZ3H8crAQg3WAf/fsKbkEJJt7IMlqHwDpu5AhphhvFjZwjq 6nUFOciVqL5ygXXJnGLJDny0wKFYW5JnBFnQViMdy01fHQCX2+PU/54Vlugm5vG2 nPo7ErJpdA83+uJrtjCBOoQGYP11U01wE4XE8iYp8uDv4O0JX+UrsPmY9Y6yXcve h1MjEZBeCOc+/4lbsbJ4sxZvPDTY7JGppBJplsGjiStvU5QkcqN2RbVUxnG96u+T PRKK2rriKjXagjQPSyUi4RDxOrg7f7VpcTxKV1pWXKy35EorMgR5WJ6z+LwFS6JK WJIndx9Lc2gf7qruktvcgVZGE7NQLjZBcqwQQ+N0xhWdWTKt5eKsNQ== =svN+ -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- From swmike@swm.pp.se Tue Jan 8 01:33: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 0AB4E21F84E9 for ; Tue, 8 Jan 2013 01:33:02 -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 ng+LLayT2ZOu for ; Tue, 8 Jan 2013 01:33:01 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 6174821F8445 for ; Tue, 8 Jan 2013 01:33:00 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A51EB9E; Tue, 8 Jan 2013 10:32:57 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9F76C9A; Tue, 8 Jan 2013 10:32:57 +0100 (CET) Date: Tue, 8 Jan 2013 10:32:57 +0100 (CET) From: Mikael Abrahamsson To: Joe Touch In-Reply-To: <50E67AE3.6030800@isi.edu> Message-ID: References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@isi.edu> <50E48874.9030906@isi.edu> <50E48DA3.9060409@isi.edu> <50E4A4F2.8050702@isi.edu> <50E5F9B1.4010006@isi.edu> <50E67AE3.6030800@isi.edu> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "tcpm@ietf.org" Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 08 Jan 2013 09:33:02 -0000 On Thu, 3 Jan 2013, Joe Touch wrote: > The trouble is that there are other cases that are indistinguishable - > i.e., when the network interface goes down then up but the reason > packets aren't getting through is that the network is congested. If the network interface goes down, packets aren't going to pass. When it comes back up again, there is a chance packets might pass. I don't see how this can be indistinguishable. > I.e., sharing information isn't the issue; it's the fact that the > information your sharing isn't complete. Did your connection manager > check the path to make sure that the TCP packets will get through? Did > it do probes in a way that won't create congestion in a case where > congestion was what brought the path down (or made it appear so)? That's > exactly why TCP does what it does. Assuming that some omniscient entity > knows better is a fine academic exercise, but easily creates a tragedy > of the commons in the real world. The connection manager knows when the network is completely down (network interface down), and it knows when it might start working again. That's why I'm not proposing that it should tell TCP to go into fast-retransmit when the cable is up again and DHCP address has been negotiated and there now is a chance it might work again. I'm proposing retransmit numbers in the range of 1 or a few seconds, instead of 64. >> The connection manager also knows that half my TCP sessions are never >> going to be viable ever again because the IP address they're bound to is >> gone and is never going to return (because it was on my 4G USB dongle). > > How does it "know" the address will never return? Restarting your dongle > could easily result in reassigning the same address. Because I have checkboxed in my 4G connection profile that addresses are dynamic and will be new each time there is a connection, so the connection manager knows because I've told it so. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Tue Jan 8 01:40: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 E853221F8837 for ; Tue, 8 Jan 2013 01:40:56 -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 WqGS09jz4tpE for ; Tue, 8 Jan 2013 01:40:56 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 3810A21F87FD for ; Tue, 8 Jan 2013 01:40:56 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8C89A9C; Tue, 8 Jan 2013 10:40:55 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 882359A; Tue, 8 Jan 2013 10:40:55 +0100 (CET) Date: Tue, 8 Jan 2013 10:40:55 +0100 (CET) From: Mikael Abrahamsson To: Ethan Blanton In-Reply-To: <20130108035137.GA28233@mail.kb8ojh.net> Message-ID: References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@isi.edu> <20130108035137.GA28233@mail.kb8ojh.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] host behaviour when connectivity is lost 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, 08 Jan 2013 09:40:57 -0000 On Mon, 7 Jan 2013, Ethan Blanton wrote: > When your PC resumes and you go to that SSH session and hit Enter, > that will trigger SSH to send some data, and a TCP segment will go out > almost immediately. No, it usually doesn't, because I pressed it too soon so the first 3-4 transmits went to nowhere because there was no wifi up yet. > time, that data segment just disappears into the Ether. I'm not sure > what all of the reasons for that are, but here are a couple of > well-known reasons: I have none of these problems. With IPv6, I see them being less and less prevelant, thus the need for the functionality I am describing. > The trouble with these reasons is that they're not necessarily something > you can fix by telling TCP "hey, shorten your timeouts", unless you want > to make them *way* short (you're unhappy with ~1 minute, apparently?). > Since the outgoing packets just silently disappear with no reply, the > local TCP has no way of telling if there's a transient network issue > (maybe not at the local interface, if your system just told the TCP the > interface is good), if the end-to-end delay is simply long, etc. I have no problem with that. I want to fix the case where TCP can get an RST or ACK immediately if it just starts talking instead of waiting tens of seconds. > This seems like something that should be handled by applications that > are specifically concerned about interactivity. If you don't have > interactive goals, wait 64 seconds (or longer) and see what happens. If > you do, then send an application layer ping after a resume, give it > however long the user should be expected to wait, and reconnect. What should the application do exactly? And what mechanism tells the application that the host has resumed so the application should now tell TCP to do things. And why does it make more sense to have the connection manager communicate to all applications, instead of just communicating to the kernel TCP (SCTP and others) and have them figure out the problem. I see TCP as the easy target here, instead of modifying a lot of applications. -- Mikael Abrahamsson email: swmike@swm.pp.se From touch@isi.edu Wed Jan 9 15:51:45 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 476C621F8495 for ; Wed, 9 Jan 2013 15:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.67 X-Spam-Level: X-Spam-Status: No, score=-102.67 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 bKw8P1-KHluK for ; Wed, 9 Jan 2013 15:51:44 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 8899321F8481 for ; Wed, 9 Jan 2013 15:51:44 -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 r09Np77a009433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Jan 2013 15:51:14 -0800 (PST) Message-ID: <50EE026B.2050800@isi.edu> Date: Wed, 09 Jan 2013 15:51:07 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Mikael Abrahamsson References: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0AE4E@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <50E47E82.8030407@isi.edu> <50E48874.9030906@isi.edu> <50E48DA3.9060409@isi.edu> <50E4A4F2.8050702@isi.edu> <50E5F9B1.4010006@isi.edu> <50E67AE3.6030800@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] host behaviour when connectivity is lost 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, 09 Jan 2013 23:51:45 -0000 On 1/8/2013 1:32 AM, Mikael Abrahamsson wrote: > On Thu, 3 Jan 2013, Joe Touch wrote: > >> The trouble is that there are other cases that are indistinguishable - >> i.e., when the network interface goes down then up but the reason >> packets aren't getting through is that the network is congested. > > If the network interface goes down, packets aren't going to pass. When > it comes back up again, there is a chance packets might pass. I don't > see how this can be indistinguishable. It's indistinguishable when packets don't pass but the network interface is up. Just because a network interface is up doesn't mean it's safe - or appropriate - to start resending at full rate. >> I.e., sharing information isn't the issue; it's the fact that the >> information your sharing isn't complete. Did your connection manager >> check the path to make sure that the TCP packets will get through? Did >> it do probes in a way that won't create congestion in a case where >> congestion was what brought the path down (or made it appear so)? >> That's exactly why TCP does what it does. Assuming that some >> omniscient entity knows better is a fine academic exercise, but easily >> creates a tragedy of the commons in the real world. > > The connection manager knows when the network is completely down > (network interface down), and it knows when it might start working > again. That's why I'm not proposing that it should tell TCP to go into > fast-retransmit when the cable is up again and DHCP address has been > negotiated and there now is a chance it might work again. I'm proposing > retransmit numbers in the range of 1 or a few seconds, instead of 64. Fast retransmit is intended when the ACKs get through but indicate that a segment was likely lost. Again, just because the network interface comes back doesn't mean that a resent segment will get through. >>> The connection manager also knows that half my TCP sessions are never >>> going to be viable ever again because the IP address they're bound to is >>> gone and is never going to return (because it was on my 4G USB dongle). >> >> How does it "know" the address will never return? Restarting your >> dongle could easily result in reassigning the same address. > > Because I have checkboxed in my 4G connection profile that addresses are > dynamic and will be new each time there is a connection, so the > connection manager knows because I've told it so. Dynamic addresses can still be reassigned as the same, though. There are only three places where things happen regarding TCP: - inside the TCP protocol - at the app layer - on the interface (segment arrivals/departures) If you're talking about modifying the app layer (which could be implemented in the OS, a library, or anywhere), then this isn't a change to TCP, and isn't relevant for either an RFC or this list. If you're talking about modifying TCP for this purpose, it still seems very inappropriate. Joe From mattmathis@google.com Thu Jan 24 14:35: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 4B68D11E80D1 for ; Thu, 24 Jan 2013 14:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.727 X-Spam-Level: X-Spam-Status: No, score=-102.727 tagged_above=-999 required=5 tests=[AWL=0.250, 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 vuBXGqfT2O5k for ; Thu, 24 Jan 2013 14:35:04 -0800 (PST) Received: from mail-ia0-x22f.google.com (ia-in-x022f.1e100.net [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D865311E8099 for ; Thu, 24 Jan 2013 14:35:00 -0800 (PST) Received: by mail-ia0-f175.google.com with SMTP id r4so5465519iaj.20 for ; Thu, 24 Jan 2013 14:35:00 -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:content-transfer-encoding; bh=53cZECbtpUio77i9WAnswJY9DEB9hTZ+4485c72unf0=; b=kTzC5NEOANOlPIHXILmSVy+aTpRNEUOJXwPz9MqwXBx+TRCDTMVsMvFyIKsWRyJrDU iAPD/EOdxdErCgksX4pd8EQ1R71LquAbUN+V799Yfeb8j0x5LmYjBikxr+z05wQGjQz9 3KNuwp+kbBX/xG605/BYY9NoQWbUaqDUuyGDIV8UuWy+IGG424fe8tHUcsgthtfy8wMu b0cB+yE3Yva8LBxo+Wk6C/Exk2c4xSXDf5ESU3n2isBDWCSpDLXfZCjeZj8kUcfNC46H kUrJTRST40LGkBabZxW9hnZySUcoOd3g5EnlsmOAVJH7NNH48AgZ0TE1Z9ADGW21m5nN gDsg== 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:content-transfer-encoding :x-gm-message-state; bh=53cZECbtpUio77i9WAnswJY9DEB9hTZ+4485c72unf0=; b=EiEkVxwAr/UfDT28wAfpUqNOrwsl6ZreS2cfRmmdyZLyoUExXcjBsx1X7eKu1LuyQD 0DMnSb77NV5rvXxF5FgoM1KEJWgmYxIjuj22vFGmBaRapmu7gs7veuzgNm3pQ2HegFSP +ho3Gn0pWz8sF/QnfzogpQ051pLvwC0QGIoJqXC2z5BuLHvEa6IBPG39o/FS0jHUHvkZ ButgWpfHRTnHNg2J7n6VsJAOZh2qhZocZSd5Qbibtq5lTPI0QvhEhR8Gi9oST4I7Bwfm /+YQRhw13rlg+FiLu95p0eb+SfH0A4FQzSm/mWrKMjgkP5x1osY+P1FAPX0qALMioa6/ wluw== MIME-Version: 1.0 X-Received: by 10.50.237.103 with SMTP id vb7mr2640601igc.29.1359066900197; Thu, 24 Jan 2013 14:35:00 -0800 (PST) Received: by 10.64.34.163 with HTTP; Thu, 24 Jan 2013 14:35:00 -0800 (PST) In-Reply-To: <50C06CE6.40909@ericsson.com> References: <20121126212940.20378.58186.idtracker@ietfa.amsl.com> <50C06CE6.40909@ericsson.com> Date: Thu, 24 Jan 2013 14:35:00 -0800 Message-ID: From: Matt Mathis To: Magnus Westerlund Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnnP3twPo04dClI0EQcnTksnfUjQ/bO3d1UEDJduIe1kmFa3UIHvMiVY7/o/pF38EZEBgFacLEIa9yxZiF8sSXc6gOUZFdkytmGXzaYeVS2UI37l3sGMneQzIrekAAnjDJ4RFig/OfkF9AV7i14ZVJ9kEeyvb9N3WZr185uNqPvK0r3UNz6MaAFuliOF6NY73CxI7UD 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: Thu, 24 Jan 2013 22:35:04 -0000 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. 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." 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." 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 =3D 120 to 40*10 =3D 400. There are some distribution o= ver > 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 b= e >> 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=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > From ketkulka@gmail.com Mon Jan 28 08:42: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 0AF2E21F88B9 for ; Mon, 28 Jan 2013 08:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, NO_RELAYS=-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 FUjjV4sBLF6u for ; Mon, 28 Jan 2013 08:42:55 -0800 (PST) Received: from mail-ia0-x22b.google.com (ia-in-x022b.1e100.net [IPv6:2607:f8b0:4001:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id CB46D21F8786 for ; Mon, 28 Jan 2013 08:42:54 -0800 (PST) Received: by mail-ia0-f171.google.com with SMTP id z13so4497147iaz.2 for ; Mon, 28 Jan 2013 08:42:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=AtTuLLXmkVtVk4erSlNiOATJ+r6p9tTcf6ZHfTpgayw=; b=YVmKIgVSxO8J+aXv6NlQi85zx60L1E/3UQi04mDE8ajpItiRUlLe8SlBwViyubKHqz mltS3mM+uCR2ZWQ4pBtUUiDO+HWwUZIY4T6fv9ZVW85vn0rQNpTv+Q3ITELj5DITd08i ScRFTqC2m+Ebrz6CFY1Eq1yxzzFAyi5zIIGFZAOojxlJm/oNo5ou03K7oBf7Ieuiuscp 3kj6Ic54soUlcelyw9R1FHdGKq5GxZBQHUubhgf5WM8DtcN3SL8LcRLaIT9yr1oMcDyp q4a9JQ1AnWdR2v1SM1ucETKIa1SQF9W2Xnq/agGXcsCw/8yIz1LNZY5szBXdIL2vROFt PrJQ== MIME-Version: 1.0 X-Received: by 10.50.13.208 with SMTP id j16mr3261026igc.73.1359391374300; Mon, 28 Jan 2013 08:42:54 -0800 (PST) Received: by 10.64.53.105 with HTTP; Mon, 28 Jan 2013 08:42:54 -0800 (PST) Date: Mon, 28 Jan 2013 22:12:54 +0530 Message-ID: From: Ketan Kulkarni To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [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, 28 Jan 2013 16:42:56 -0000 Hello TCP Experts, This is regarding few observations and suggestion about TCP Fast Open cookie request/response. Part of this discussion was done on netdev mailing list here - http://www.spinics.net/lists/netdev/msg219775.html However, I think the same and some further discussion best belongs here as well. It was observed that - If Fast Open cookie is obtained from a server, client always attempts Fast Open to the same server. This is ok in most of the cases. Suppose the server restarts without Fast Open, it will never ACK the data in SYN from such client and never send the cookie as well. Client will always try the Fast Open and fail - leading the re-transmission of SYN data. As confirmed by Yuchung on netdev, though it may not be performance killer, it seems a little odd. This can happen in multiple cases few of which could be - 1. Server restarts without Fast Open support 2. Network path changes or any middle box just strips out the unknown tcp options - fast open cookie in this case 3. Server expires the cookie and client is trying with expired cookie My view is to provide a way for fast-open client which has obtained a cookie to fallback to initial state when it detects the server it obtained the cookie from is no longer acking the Data in SYN. Detecting upon such condition, the fast-open client should retry cookie request in subsequent connection rather than trying the SYN+Data. Detection could be based on some thresholds but that could be implementation specific. Any thoughts here - I may be missing something? 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. Thanks, Ketan Kulkarni From internet-drafts@ietf.org Mon Jan 28 14:47: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 55F0721F85BB; Mon, 28 Jan 2013 14:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 m2EGhq3FZISA; Mon, 28 Jan 2013 14:46:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C7521F85C3; Mon, 28 Jan 2013 14:46:59 -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: <20130128224659.31522.5886.idtracker@ietfa.amsl.com> Date: Mon, 28 Jan 2013 14:46:59 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-initcwnd-07.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, 28 Jan 2013 22:47:00 -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-07.txt Pages : 23 Date : 2013-01-28 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-initcwnd-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nishida@sfc.wide.ad.jp Wed Jan 30 22:06: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 4BCB721F8499 for ; Wed, 30 Jan 2013 22:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 ivGPkEeO+ixI for ; Wed, 30 Jan 2013 22:06:55 -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 D3B0321F8496 for ; Wed, 30 Jan 2013 22:06:54 -0800 (PST) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 6FE792780AE for ; Thu, 31 Jan 2013 15:06:52 +0900 (JST) Received: by mail-ob0-f176.google.com with SMTP id v19so2524980obq.21 for ; Wed, 30 Jan 2013 22:06:50 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.54.102 with SMTP id i6mr5555024obp.67.1359612410938; Wed, 30 Jan 2013 22:06:50 -0800 (PST) Received: by 10.76.12.234 with HTTP; Wed, 30 Jan 2013 22:06:50 -0800 (PST) In-Reply-To: References: Date: Wed, 30 Jan 2013 22:06:50 -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: Thu, 31 Jan 2013 06:06:55 -0000 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 cabo@tzi.org Thu Jan 31 08:42: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 0964A21F841A for ; Thu, 31 Jan 2013 08:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=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 7uFSHC6XCMEA for ; Thu, 31 Jan 2013 08:42:17 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id E34A721F8888 for ; Thu, 31 Jan 2013 08:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id r0VGg7IP020457 for ; Thu, 31 Jan 2013 17:42:07 +0100 (CET) Received: from [192.168.217.108] (p54894016.dip.t-dialin.net [84.137.64.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A419DC72; Thu, 31 Jan 2013 17:42:07 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 31 Jan 2013 17:42:06 +0100 To: "tcpm@ietf.org list" Message-Id: <8BAC82E4-6D1D-465F-9BE1-9ADE9F4E7DC8@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds" 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, 31 Jan 2013 16:42:18 -0000 (Off-topic...) Just got pointed to this at $DAYJOB. All snake-oil alarms go off just from the buzzwords, so I didn't look at = it in detail. But maybe they have solved bufferbloat (1/6 latency!) and fixed CC in = the process (30x throughput!). They even seem to have put in a PEP. If anyone happens to analyze this and can translate from PR speak to = something someone on this list would understand, please do post a = pointer to your praise/scorcher here. Otherwise we return you to your = regular program... = http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html= Gr=FC=DFe, Carsten PS.: Is it just me or are these getting more frequent recently? From lars@netapp.com Thu Jan 31 09:08: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 DD63C21F866F for ; Thu, 31 Jan 2013 09:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.23 X-Spam-Level: X-Spam-Status: No, score=-10.23 tagged_above=-999 required=5 tests=[AWL=0.369, 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 pBUwKYXl+q6c for ; Thu, 31 Jan 2013 09:08:25 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id AF1EA21F867D for ; Thu, 31 Jan 2013 09:08:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,577,1355126400"; d="scan'208";a="14806192" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 31 Jan 2013 09:08:13 -0800 Received: from vmwexceht01-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r0VH8DLe000130; Thu, 31 Jan 2013 09:08:13 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0328.009; Thu, 31 Jan 2013 09:08:12 -0800 From: "Eggert, Lars" To: Carsten Bormann Thread-Topic: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds" Thread-Index: AQHN/9HxDLGko7cLlUmyOHpnTYngMJhkMY8A Date: Thu, 31 Jan 2013 17:08:11 +0000 Message-ID: References: <8BAC82E4-6D1D-465F-9BE1-9ADE9F4E7DC8@tzi.org> In-Reply-To: <8BAC82E4-6D1D-465F-9BE1-9ADE9F4E7DC8@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <480A3D5C0033E546BB1BCCDF5D5768B8@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org list" Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds" 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, 31 Jan 2013 17:08:26 -0000 Hi, my guess would be that they introduce a non-realistic amount of random (non= -congestion) loss in their simulation to make TCP loo real bad. Their own s= olution probably employs some mechanism that doesn't ramp down when such lo= ss happens. And I'd guess that fairness isn't a concern either. Lars On Jan 31, 2013, at 17:42, Carsten Bormann wrote: > Just got pointed to this at $DAYJOB. > All snake-oil alarms go off just from the buzzwords, so I didn't look at = it in detail. > But maybe they have solved bufferbloat (1/6 latency!) and fixed CC in the= process (30x throughput!). > They even seem to have put in a PEP. >=20 > If anyone happens to analyze this and can translate from PR speak to some= thing someone on this list would understand, please do post a pointer to yo= ur praise/scorcher here. Otherwise we return you to your regular program..= . >=20 > http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.htm= l >=20 > Gr=FC=DFe, Carsten >=20 > PS.: Is it just me or are these getting more frequent recently? From Donald.Smith@CenturyLink.com Thu Jan 31 09:39: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 0760B21F86A9 for ; Thu, 31 Jan 2013 09:39:58 -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 K6czogyKEDfC for ; Thu, 31 Jan 2013 09:39:57 -0800 (PST) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC7E21F86A6 for ; Thu, 31 Jan 2013 09:39:56 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id r0VHdsrZ009287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2013 11:39:55 -0600 (CST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id CAB1F1E0071; Thu, 31 Jan 2013 11:39:49 -0600 (CST) Received: from suomp60i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id A87E81E0086; Thu, 31 Jan 2013 11:39:49 -0600 (CST) Received: from suomp60i.qintra.com (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id r0VHdnpX028476; Thu, 31 Jan 2013 11:39:49 -0600 (CST) Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.qintra.com [151.119.128.29]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id r0VHdmCm028445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jan 2013 11:39:49 -0600 (CST) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex502.ctl.intranet ([2002:9777:801d::9777:801d]) with mapi id 14.02.0318.001; Thu, 31 Jan 2013 10:39:48 -0700 From: "Smith, Donald" To: Carsten Bormann , "tcpm@ietf.org list" Thread-Topic: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds" Thread-Index: AQHN/9HyeTlgzbPFnE2F8B0iqQzb45hjs/L/ Date: Thu, 31 Jan 2013 17:39:47 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D0A2BAE30@PDDCWMBXEX503.ctl.intranet> References: <8BAC82E4-6D1D-465F-9BE1-9ADE9F4E7DC8@tzi.org> In-Reply-To: <8BAC82E4-6D1D-465F-9BE1-9ADE9F4E7DC8@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.70.40.132] Content-Type: multipart/alternative; boundary="_000_68EFACB32CF4464298EA2779B058889D0A2BAE30PDDCWMBXEX503ct_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds" 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, 31 Jan 2013 17:39:58 -0000 --_000_68EFACB32CF4464298EA2779B058889D0A2BAE30PDDCWMBXEX503ct_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Some interesting comments on it here:) http://forums.theregister.co.uk/forum/1/2013/01/30/fujitsu_speedy_data_tran= sfer_protocol/#c_1710380 I didn't write any of those comments but found some pretty spot on your mil= eage may vary. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com ________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] on behalf of Carsten Bo= rmann [cabo@tzi.org] Sent: Thursday, January 31, 2013 9:42 AM To: tcpm@ietf.org list Subject: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Impro= ved Transmissions Speeds" (Off-topic...) Just got pointed to this at $DAYJOB. All snake-oil alarms go off just from the buzzwords, so I didn't look at it= in detail. But maybe they have solved bufferbloat (1/6 latency!) and fixed CC in the p= rocess (30x throughput!). They even seem to have put in a PEP. If anyone happens to analyze this and can translate from PR speak to someth= ing someone on this list would understand, please do post a pointer to your= praise/scorcher here. Otherwise we return you to your regular program... http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html Gr=FC=DFe, Carsten PS.: Is it just me or are these getting more frequent recently? _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --_000_68EFACB32CF4464298EA2779B058889D0A2BAE30PDDCWMBXEX503ct_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Some interesting comments on it here:)

http://forums.theregister.co.uk/for= um/1/2013/01/30/fujitsu_speedy_data_transfer_protocol/#c_1710380

 

 

I didn't write any of those comments but found some pretty spot on your&= nbsp;mileage may vary.

 

(coffee !=3D sleep) & (!coffee =3D=3D sleep)
 Donald.Smith@centuryl= ink.com
From: tcpm-bounces@ietf.org [tcpm-bounces@= ietf.org] on behalf of Carsten Bormann [cabo@tzi.org]
Sent: Thursday, January 31, 2013 9:42 AM
To: tcpm@ietf.org list
Subject: [tcpm] "Fujitsu Develops New Data Transfer Protocol En= abling Improved Transmissions Speeds"

(Off-topic...)

Just got pointed to this at $DAYJOB.
All snake-oil alarms go off just from the buzzwords, so I didn't look at it= in detail.
But maybe they have solved bufferbloat (1/6 latency!) and fixed CC in the p= rocess (30x throughput!).
They even seem to have put in a PEP.

If anyone happens to analyze this and can translate from PR speak to someth= ing someone on this list would understand, please do post a pointer to your= praise/scorcher here.  Otherwise we return you to your regular progra= m...

http://www.fujitsu.com/global/news/pr/archive= s/month/2013/20130129-02.html

Gr=FC=DFe, Carsten

PS.: Is it just me or are these getting more frequent recently?

_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm
--_000_68EFACB32CF4464298EA2779B058889D0A2BAE30PDDCWMBXEX503ct_-- From michael.scharf@alcatel-lucent.com Thu Jan 31 09:42: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 5B2D121F87AC for ; Thu, 31 Jan 2013 09:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.582 X-Spam-Level: X-Spam-Status: No, score=-7.582 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 BNeH0ct4Ds2l for ; Thu, 31 Jan 2013 09:42:46 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3A32621F87AB for ; Thu, 31 Jan 2013 09:42:46 -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 r0VHgiYB016020 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 31 Jan 2013 18:42:44 +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; Thu, 31 Jan 2013 18:42:44 +0100 From: "Scharf, Michael (Michael)" To: "Eggert, Lars" , Carsten Bormann Date: Thu, 31 Jan 2013 18:42:43 +0100 Thread-Topic: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds" Thread-Index: AQHN/9HxDLGko7cLlUmyOHpnTYngMJhkMY8A//+AatA= Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0B397@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <8BAC82E4-6D1D-465F-9BE1-9ADE9F4E7DC8@tzi.org> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "tcpm@ietf.org list" Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds" 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, 31 Jan 2013 17:42:47 -0000 Do we need an RFC that explains to the press, in very simple language, some= very basic tests that a TCP marketing text should pass before publishing i= t on whatever IT news site? Well, probably even that would not help :( Michael > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Eggert, Lars > Sent: Thursday, January 31, 2013 6:08 PM > To: Carsten Bormann > Cc: tcpm@ietf.org list > Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer=20 > Protocol Enabling Improved Transmissions Speeds" >=20 > Hi, >=20 > my guess would be that they introduce a non-realistic amount=20 > of random (non-congestion) loss in their simulation to make=20 > TCP loo real bad. Their own solution probably employs some=20 > mechanism that doesn't ramp down when such loss happens. And=20 > I'd guess that fairness isn't a concern either. >=20 > Lars >=20 > On Jan 31, 2013, at 17:42, Carsten Bormann wrote: > > Just got pointed to this at $DAYJOB. > > All snake-oil alarms go off just from the buzzwords, so I=20 > didn't look at it in detail. > > But maybe they have solved bufferbloat (1/6 latency!) and=20 > fixed CC in the process (30x throughput!). > > They even seem to have put in a PEP. > >=20 > > If anyone happens to analyze this and can translate from PR=20 > speak to something someone on this list would understand,=20 > please do post a pointer to your praise/scorcher here. =20 > Otherwise we return you to your regular program... > >=20 > >=20 > http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02. > > html > >=20 > > Gr=FC=DFe, Carsten > >=20 > > PS.: Is it just me or are these getting more frequent recently? >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > = From touch@isi.edu Thu Jan 31 09:53: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 5DF5321F85DA for ; Thu, 31 Jan 2013 09:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 lQZLoTEIdVV5 for ; Thu, 31 Jan 2013 09:53:28 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFDF21F8517 for ; Thu, 31 Jan 2013 09:53:28 -0800 (PST) Received: from [128.9.184.132] ([128.9.184.132]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r0VHr4oQ013608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Jan 2013 09:53:04 -0800 (PST) Message-ID: <510AAF80.9030609@isi.edu> Date: Thu, 31 Jan 2013 09:53:04 -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: "Eggert, Lars" References: <8BAC82E4-6D1D-465F-9BE1-9ADE9F4E7DC8@tzi.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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 list" Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds" 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, 31 Jan 2013 17:53:29 -0000 Not that new. There were several companies in the mid-90's that did TCP accelerators - by basically ignoring CC. They pop up every few years. Then people tend to realize they want reliable, universal access, and that most of the time TCP is already "optimized" for that; other optimizations tend to come at an expense.. Joe On 1/31/2013 9:08 AM, Eggert, Lars wrote: > Hi, > > my guess would be that they introduce a non-realistic amount of random (non-congestion) loss in their simulation to make TCP loo real bad. Their own solution probably employs some mechanism that doesn't ramp down when such loss happens. And I'd guess that fairness isn't a concern either. > > Lars > > On Jan 31, 2013, at 17:42, Carsten Bormann wrote: >> Just got pointed to this at $DAYJOB. >> All snake-oil alarms go off just from the buzzwords, so I didn't look at it in detail. >> But maybe they have solved bufferbloat (1/6 latency!) and fixed CC in the process (30x throughput!). >> They even seem to have put in a PEP. >> >> If anyone happens to analyze this and can translate from PR speak to something someone on this list would understand, please do post a pointer to your praise/scorcher here. Otherwise we return you to your regular program... >> >> http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html >> >> Grüße, Carsten >> >> PS.: Is it just me or are these getting more frequent recently? > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From touch@isi.edu Thu Jan 31 09:55: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 4E1A921F85DA for ; Thu, 31 Jan 2013 09:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 RBw7W-M5o-iX for ; Thu, 31 Jan 2013 09:55:36 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0CE21F8563 for ; Thu, 31 Jan 2013 09:55:36 -0800 (PST) Received: from [128.9.184.132] ([128.9.184.132]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r0VHt30i013819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Jan 2013 09:55:04 -0800 (PST) Message-ID: <510AAFF8.3070704@isi.edu> Date: Thu, 31 Jan 2013 09:55:04 -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: "Scharf, Michael (Michael)" References: <8BAC82E4-6D1D-465F-9BE1-9ADE9F4E7DC8@tzi.org> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0B397@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0B397@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 list" Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds" 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, 31 Jan 2013 17:55:37 -0000 On 1/31/2013 9:42 AM, Scharf, Michael (Michael) wrote: > Do we need an RFC that explains to the press, in very simple language, some very basic tests that a TCP marketing text should pass before publishing it on whatever IT news site? Right after we write one that explains that the press ought to consider it their job to investigate, not just act as a marketing channel... (good luck with that - most news divisions are now placed under the direction of "entertainment" or "marketing" divisions now) Joe From tsabatini@hotmail.com Thu Jan 31 11:01: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 2110421F84C9 for ; Thu, 31 Jan 2013 11:01:18 -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=[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 P+95nYJzJXZk for ; Thu, 31 Jan 2013 11:01:17 -0800 (PST) Received: from bay0-omc1-s11.bay0.hotmail.com (bay0-omc1-s11.bay0.hotmail.com [65.54.190.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3758721F84C6 for ; Thu, 31 Jan 2013 11:01:17 -0800 (PST) Received: from BAY172-W11 ([65.54.190.61]) by bay0-omc1-s11.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Jan 2013 11:01:16 -0800 X-EIP: [FEhG2oVzlKtB63pqgGywfYSyx8QaF2l5] X-Originating-Email: [tsabatini@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_cd33ae07-728a-4d69-84b4-8a3924e82a0d_" From: Anthony Sabatini To: tcpm Michael Scharf , , Date: Thu, 31 Jan 2013 14:01:16 -0500 Importance: Normal In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0B397@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <8BAC82E4-6D1D-465F-9BE1-9ADE9F4E7DC8@tzi.org>, , <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0B397@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> MIME-Version: 1.0 X-OriginalArrivalTime: 31 Jan 2013 19:01:16.0918 (UTC) FILETIME=[58FCF960:01CDFFE5] Cc: tcpm Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds" 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, 31 Jan 2013 19:01:18 -0000 --_cd33ae07-728a-4d69-84b4-8a3924e82a0d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All - Well now you all know what I have been talking about fotr the last year. F= ujitsu has rediscovered the protocol and techniques I used in creating TDLC= thirty years ago. If you want to know how it works=2C see my submital to = IETF 'TDLC=2C An improved "Selective Repeat" protocol' draft-sabatini-tdlc-= 00=2C or mail me and I will send you a copy. And yes=2C it is that good=2C never re-sending a message that was received= =2C near 100% effective bandwidth utilization=2C automatically adjusts to l= ink availability IN REAL TIME. Yes it is real and you can ALMOST make TCP-= IP that good=2C the problem with TCP-IP is supporting bad legacy decisions. Tony Anthony Sabatini 200 West 20th Street Apt. 1216 New York=2C NY 10011 Phone: (212) 867-7179 Mobile: (917) 224-8388 =20 > From: michael.scharf@alcatel-lucent.com > To: lars@netapp.com=3B cabo@tzi.org > Date: Thu=2C 31 Jan 2013 18:42:43 +0100 > CC: tcpm@ietf.org > Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling= Improved Transmissions Speeds" >=20 > Do we need an RFC that explains to the press=2C in very simple language= =2C some very basic tests that a TCP marketing text should pass before publ= ishing it on whatever IT news site? >=20 > Well=2C probably even that would not help :( >=20 > Michael >=20 >=20 >=20 > > -----Original Message----- > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > > Behalf Of Eggert=2C Lars > > Sent: Thursday=2C January 31=2C 2013 6:08 PM > > To: Carsten Bormann > > Cc: tcpm@ietf.org list > > Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer=20 > > Protocol Enabling Improved Transmissions Speeds" > >=20 > > Hi=2C > >=20 > > my guess would be that they introduce a non-realistic amount=20 > > of random (non-congestion) loss in their simulation to make=20 > > TCP loo real bad. Their own solution probably employs some=20 > > mechanism that doesn't ramp down when such loss happens. And=20 > > I'd guess that fairness isn't a concern either. > >=20 > > Lars > >=20 > > On Jan 31=2C 2013=2C at 17:42=2C Carsten Bormann wrote: > > > Just got pointed to this at $DAYJOB. > > > All snake-oil alarms go off just from the buzzwords=2C so I=20 > > didn't look at it in detail. > > > But maybe they have solved bufferbloat (1/6 latency!) and=20 > > fixed CC in the process (30x throughput!). > > > They even seem to have put in a PEP. > > >=20 > > > If anyone happens to analyze this and can translate from PR=20 > > speak to something someone on this list would understand=2C=20 > > please do post a pointer to your praise/scorcher here. =20 > > Otherwise we return you to your regular program... > > >=20 > > >=20 > > http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02. > > > html > > >=20 > > > Gr=FC=DFe=2C Carsten > > >=20 > > > PS.: Is it just me or are these getting more frequent recently? > >=20 > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = --_cd33ae07-728a-4d69-84b4-8a3924e82a0d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
All -

Well now you all know what I have been talking about fotr the = last year. =3B Fujitsu has rediscovered the protocol and techniques I u= sed in creating TDLC thirty years ago. =3B If you want to know how it w= orks=2C see my submital to IETF 'TDLC=2C An improved "Selective Repeat" pro= tocol' draft-sabatini-tdlc-00=2C or mail me and I will send you a copy.
=
And yes=2C it is that good=2C never re-sending a message that was recei= ved=2C near 100% effective bandwidth utilization=2C automatically adjusts t= o link availability IN REAL TIME. =3B Yes it is real and you can ALMOST= make TCP-IP that good=2C the problem with TCP-IP is supporting bad legacy = decisions.

Tony


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

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

 =3B


>=3B From: michael.scharf@alcatel-lucent.com
>=3B= To: lars@netapp.com=3B cabo@tzi.org
>=3B Date: Thu=2C 31 Jan 2013 18:= 42:43 +0100
>=3B CC: tcpm@ietf.org
>=3B Subject: Re: [tcpm] "Fuji= tsu Develops New Data Transfer Protocol Enabling Improved Transmissions Spe= eds"
>=3B
>=3B Do we need an RFC that explains to the press=2C i= n very simple language=2C some very basic tests that a TCP marketing text s= hould pass before publishing it on whatever IT news site?
>=3B
>= =3B Well=2C probably even that would not help :(
>=3B
>=3B Micha= el
>=3B
>=3B
>=3B
>=3B >=3B -----Original Message-= ----
>=3B >=3B From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf= .org] On
>=3B >=3B Behalf Of Eggert=2C Lars
>=3B >=3B Sent: = Thursday=2C January 31=2C 2013 6:08 PM
>=3B >=3B To: Carsten Bormann=
>=3B >=3B Cc: tcpm@ietf.org list
>=3B >=3B Subject: Re: [tcp= m] "Fujitsu Develops New Data Transfer
>=3B >=3B Protocol Enabling = Improved Transmissions Speeds"
>=3B >=3B
>=3B >=3B Hi=2C
= >=3B >=3B
>=3B >=3B my guess would be that they introduce a non= -realistic amount
>=3B >=3B of random (non-congestion) loss in thei= r simulation to make
>=3B >=3B TCP loo real bad. Their own solution= probably employs some
>=3B >=3B mechanism that doesn't ramp down w= hen such loss happens. And
>=3B >=3B I'd guess that fairness isn't = a concern either.
>=3B >=3B
>=3B >=3B Lars
>=3B >=3B =
>=3B >=3B On Jan 31=2C 2013=2C at 17:42=2C Carsten Bormann <=3Bca= bo@tzi.org>=3B wrote:
>=3B >=3B >=3B Just got pointed to this at= $DAYJOB.
>=3B >=3B >=3B All snake-oil alarms go off just from the= buzzwords=2C so I
>=3B >=3B didn't look at it in detail.
>=3B= >=3B >=3B But maybe they have solved bufferbloat (1/6 latency!) and >=3B >=3B fixed CC in the process (30x throughput!).
>=3B >=3B= >=3B They even seem to have put in a PEP.
>=3B >=3B >=3B
&g= t=3B >=3B >=3B If anyone happens to analyze this and can translate from= PR
>=3B >=3B speak to something someone on this list would underst= and=2C
>=3B >=3B please do post a pointer to your praise/scorcher h= ere.
>=3B >=3B Otherwise we return you to your regular program...<= br>>=3B >=3B >=3B
>=3B >=3B >=3B
>=3B >=3B http://w= ww.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.
>=3B &g= t=3B >=3B html
>=3B >=3B >=3B
>=3B >=3B >=3B Gr=FC=DFe= =2C Carsten
>=3B >=3B >=3B
>=3B >=3B >=3B PS.: Is it jus= t me or are these getting more frequent recently?
>=3B >=3B
>= =3B >=3B _______________________________________________
>=3B >=3B= tcpm mailing list
>=3B >=3B tcpm@ietf.org
>=3B >=3B https://= www.ietf.org/mailman/listinfo/tcpm
>=3B >=3B
>=3B ____________= ___________________________________
>=3B tcpm mailing list
>=3B t= cpm@ietf.org
>=3B https://www.ietf.org/mailman/listinfo/tcpm
=
= --_cd33ae07-728a-4d69-84b4-8a3924e82a0d_-- From michael.scharf@alcatel-lucent.com Thu Jan 31 11:26: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 2F8FF21F8574 for ; Thu, 31 Jan 2013 11:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.249 X-Spam-Level: X-Spam-Status: No, score=-9.249 tagged_above=-999 required=5 tests=[AWL=1.000, 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 GJVm4FiteCM9 for ; Thu, 31 Jan 2013 11:26:34 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id EFBDF21F8536 for ; Thu, 31 Jan 2013 11:26:33 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0VJOXcH012918 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 31 Jan 2013 20:26:29 +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; Thu, 31 Jan 2013 20:26:08 +0100 From: "Scharf, Michael (Michael)" To: Anthony Sabatini , "lars@netapp.com" , "cabo@tzi.org" Date: Thu, 31 Jan 2013 20:26:07 +0100 Thread-Topic: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds" Thread-Index: Ac3/5WElZsax2dETRaOq7FFqXEpvFAAAHJ/w Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0B39A@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <8BAC82E4-6D1D-465F-9BE1-9ADE9F4E7DC8@tzi.org>, , <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0B397@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: tcpm Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds" 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, 31 Jan 2013 19:26:35 -0000 For what it is worth, two of the very basic questions in my proposed RFC wo= uld be: * Can you find the word "Selective Acknowledgments" or the abbreviation "SA= CK" in the marketing text? (Footnote: Please also check for the spelling "S= elective Acknowledgements", and for singular form.) * Can you find the word "measurement" in the marketing text? Ideally in one= sentence with terms such as "Windows", "Linux", "OS X", "BSD"?=20 But, sigh, maybe the challenge is indeed too large. Michael PS: I also might have forgotten some irony tags somewhere. > -----Original Message----- > From: Anthony Sabatini [mailto:tsabatini@hotmail.com]=20 > Sent: Thursday, January 31, 2013 8:01 PM > To: Scharf, Michael (Michael); lars@netapp.com; cabo@tzi.org > Cc: tcpm > Subject: RE: [tcpm] "Fujitsu Develops New Data Transfer=20 > Protocol Enabling Improved Transmissions Speeds" >=20 > All - >=20 > Well now you all know what I have been talking about fotr the=20 > last year. Fujitsu has rediscovered the protocol and=20 > techniques I used in creating TDLC thirty years ago. If you=20 > want to know how it works, see my submital to IETF 'TDLC, An=20 > improved "Selective Repeat" protocol' draft-sabatini-tdlc-00,=20 > or mail me and I will send you a copy. >=20 > And yes, it is that good, never re-sending a message that was=20 > received, near 100% effective bandwidth utilization,=20 > automatically adjusts to link availability IN REAL TIME. Yes=20 > it is real and you can ALMOST make TCP-IP that good, the=20 > problem with TCP-IP is supporting bad legacy decisions. >=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 >=20 >=20 >=20 > > From: michael.scharf@alcatel-lucent.com > > To: lars@netapp.com; cabo@tzi.org > > Date: Thu, 31 Jan 2013 18:42:43 +0100 > > CC: tcpm@ietf.org > > Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer=20 > Protocol Enabling Improved Transmissions Speeds" > >=20 > > Do we need an RFC that explains to the press, in very=20 > simple language, some very basic tests that a TCP marketing=20 > text should pass before publishing it on whatever IT news site? > >=20 > > Well, probably even that would not help :( > >=20 > > Michael > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: tcpm-bounces@ietf.org=20 > [mailto:tcpm-bounces@ietf.org] On Behalf=20 > > > Of Eggert, Lars > > > Sent: Thursday, January 31, 2013 6:08 PM > > > To: Carsten Bormann > > > Cc: tcpm@ietf.org list > > > Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer Protocol=20 > > > Enabling Improved Transmissions Speeds" > > >=20 > > > Hi, > > >=20 > > > my guess would be that they introduce a non-realistic amount of=20 > > > random (non-congestion) loss in their simulation to make TCP loo=20 > > > real bad. Their own solution probably employs some mechanism that=20 > > > doesn't ramp down when such loss happens. And I'd guess that=20 > > > fairness isn't a concern either. > > >=20 > > > Lars > > >=20 > > > On Jan 31, 2013, at 17:42, Carsten Bormann wrote: > > > > Just got pointed to this at $DAYJOB. > > > > All snake-oil alarms go off just from the buzzwords, so I > > > didn't look at it in detail. > > > > But maybe they have solved bufferbloat (1/6 latency!) and > > > fixed CC in the process (30x throughput!). > > > > They even seem to have put in a PEP. > > > >=20 > > > > If anyone happens to analyze this and can translate from PR > > > speak to something someone on this list would understand,=20 > please do=20 > > > post a pointer to your praise/scorcher here. > > > Otherwise we return you to your regular program... > > > >=20 > > > >=20 > > >=20 > http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02. > > > > html > > > >=20 > > > > Gr=FC=DFe, Carsten > > > >=20 > > > > PS.: Is it just me or are these getting more frequent recently? > > >=20 > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcpm > > >=20 > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > = From tsabatini@hotmail.com Thu Jan 31 11:34: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 AAAA621F86A2 for ; Thu, 31 Jan 2013 11:34:06 -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=[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 J877+uUZzr1a for ; Thu, 31 Jan 2013 11:34:05 -0800 (PST) Received: from bay0-omc1-s6.bay0.hotmail.com (bay0-omc1-s6.bay0.hotmail.com [65.54.190.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC5521F865B for ; Thu, 31 Jan 2013 11:34:05 -0800 (PST) Received: from BAY172-W7 ([65.54.190.60]) by bay0-omc1-s6.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Jan 2013 11:34:05 -0800 X-EIP: [hP0+Mlvtshz0vQihquZnUHlWzaIqD3Kt] X-Originating-Email: [tsabatini@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_fbc0ce47-0a9a-43aa-91ec-421265ae3e31_" From: Anthony Sabatini To: tcpm Michael Scharf , , Date: Thu, 31 Jan 2013 14:34:04 -0500 Importance: Normal In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0B39A@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <8BAC82E4-6D1D-465F-9BE1-9ADE9F4E7DC8@tzi.org>, , <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0B397@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>, , <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0B39A@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> MIME-Version: 1.0 X-OriginalArrivalTime: 31 Jan 2013 19:34:05.0574 (UTC) FILETIME=[EE660A60:01CDFFE9] Cc: tcpm Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds" 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, 31 Jan 2013 19:34:06 -0000 --_fbc0ce47-0a9a-43aa-91ec-421265ae3e31_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Michael - You will never see the words SACK or selective acknowledgement any where ne= ar any of these classes of protocol. These protocols recreate the receivin= g stations state at the sending station and therefore what is validly missi= ng (and must be repeated) are most important=2C not what was received. It = is the receiver which must control the transmitter=2C a basic oversight in = how TCP-IP looks at the world. Tony Anthony Sabatini 200 West 20th Street Apt. 1216 New York=2C NY 10011 Phone: (212) 867-7179 Mobile: (917) 224-8388 =20 > From: michael.scharf@alcatel-lucent.com > To: tsabatini@hotmail.com=3B lars@netapp.com=3B cabo@tzi.org > CC: tcpm@ietf.org > Date: Thu=2C 31 Jan 2013 20:26:07 +0100 > Subject: RE: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling= Improved Transmissions Speeds" >=20 > For what it is worth=2C two of the very basic questions in my proposed RF= C would be: >=20 > * Can you find the word "Selective Acknowledgments" or the abbreviation "= SACK" in the marketing text? (Footnote: Please also check for the spelling = "Selective Acknowledgements"=2C and for singular form.) >=20 > * Can you find the word "measurement" in the marketing text? Ideally in o= ne sentence with terms such as "Windows"=2C "Linux"=2C "OS X"=2C "BSD"?=20 >=20 > But=2C sigh=2C maybe the challenge is indeed too large. >=20 > Michael >=20 >=20 > PS: I also might have forgotten some irony tags somewhere. >=20 >=20 > > -----Original Message----- > > From: Anthony Sabatini [mailto:tsabatini@hotmail.com]=20 > > Sent: Thursday=2C January 31=2C 2013 8:01 PM > > To: Scharf=2C Michael (Michael)=3B lars@netapp.com=3B cabo@tzi.org > > Cc: tcpm > > Subject: RE: [tcpm] "Fujitsu Develops New Data Transfer=20 > > Protocol Enabling Improved Transmissions Speeds" > >=20 > > All - > >=20 > > Well now you all know what I have been talking about fotr the=20 > > last year. Fujitsu has rediscovered the protocol and=20 > > techniques I used in creating TDLC thirty years ago. If you=20 > > want to know how it works=2C see my submital to IETF 'TDLC=2C An=20 > > improved "Selective Repeat" protocol' draft-sabatini-tdlc-00=2C=20 > > or mail me and I will send you a copy. > >=20 > > And yes=2C it is that good=2C never re-sending a message that was=20 > > received=2C near 100% effective bandwidth utilization=2C=20 > > automatically adjusts to link availability IN REAL TIME. Yes=20 > > it is real and you can ALMOST make TCP-IP that good=2C the=20 > > problem with TCP-IP is supporting bad legacy decisions. > >=20 > > Tony > >=20 > >=20 > > Anthony Sabatini > > 200 West 20th Street > > Apt. 1216 > > New York=2C NY 10011 > >=20 > > Phone: (212) 867-7179 > > Mobile: (917) 224-8388 > >=20 > > =20 > >=20 > >=20 > >=20 > > > From: michael.scharf@alcatel-lucent.com > > > To: lars@netapp.com=3B cabo@tzi.org > > > Date: Thu=2C 31 Jan 2013 18:42:43 +0100 > > > CC: tcpm@ietf.org > > > Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer=20 > > Protocol Enabling Improved Transmissions Speeds" > > >=20 > > > Do we need an RFC that explains to the press=2C in very=20 > > simple language=2C some very basic tests that a TCP marketing=20 > > text should pass before publishing it on whatever IT news site? > > >=20 > > > Well=2C probably even that would not help :( > > >=20 > > > Michael > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: tcpm-bounces@ietf.org=20 > > [mailto:tcpm-bounces@ietf.org] On Behalf=20 > > > > Of Eggert=2C Lars > > > > Sent: Thursday=2C January 31=2C 2013 6:08 PM > > > > To: Carsten Bormann > > > > Cc: tcpm@ietf.org list > > > > Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer Protocol=20 > > > > Enabling Improved Transmissions Speeds" > > > >=20 > > > > Hi=2C > > > >=20 > > > > my guess would be that they introduce a non-realistic amount of=20 > > > > random (non-congestion) loss in their simulation to make TCP loo=20 > > > > real bad. Their own solution probably employs some mechanism that=20 > > > > doesn't ramp down when such loss happens. And I'd guess that=20 > > > > fairness isn't a concern either. > > > >=20 > > > > Lars > > > >=20 > > > > On Jan 31=2C 2013=2C at 17:42=2C Carsten Bormann wro= te: > > > > > Just got pointed to this at $DAYJOB. > > > > > All snake-oil alarms go off just from the buzzwords=2C so I > > > > didn't look at it in detail. > > > > > But maybe they have solved bufferbloat (1/6 latency!) and > > > > fixed CC in the process (30x throughput!). > > > > > They even seem to have put in a PEP. > > > > >=20 > > > > > If anyone happens to analyze this and can translate from PR > > > > speak to something someone on this list would understand=2C=20 > > please do=20 > > > > post a pointer to your praise/scorcher here. > > > > Otherwise we return you to your regular program... > > > > >=20 > > > > >=20 > > > >=20 > > http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02. > > > > > html > > > > >=20 > > > > > Gr=FC=DFe=2C Carsten > > > > >=20 > > > > > PS.: Is it just me or are these getting more frequent recently? > > > >=20 > > > > _______________________________________________ > > > > tcpm mailing list > > > > tcpm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/tcpm > > > >=20 > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcpm > >=20 > >=20 = --_fbc0ce47-0a9a-43aa-91ec-421265ae3e31_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Michael -

You will never see the words SACK or selective acknowledge= ment any where near any of these classes of protocol. =3B These protoco= ls recreate the receiving stations state at the sending station and therefo= re what is validly missing (and must be repeated) are most important=2C not= what was received. =3B It is the receiver which must control the trans= mitter=2C a basic oversight in how TCP-IP looks at the world.

Tony
Anthony Sabatini
200 =3BWest 20th Street
Apt. 1216
New Y= ork=2C NY 10011

Phone: (212) 867-7179
Mobile: (917) 224-8388
<= br> =3B


>=3B Fr= om: michael.scharf@alcatel-lucent.com
>=3B To: tsabatini@hotmail.com= =3B lars@netapp.com=3B cabo@tzi.org
>=3B CC: tcpm@ietf.org
>=3B D= ate: Thu=2C 31 Jan 2013 20:26:07 +0100
>=3B Subject: RE: [tcpm] "Fujit= su Develops New Data Transfer Protocol Enabling Improved Transmissions Spee= ds"
>=3B
>=3B For what it is worth=2C two of the very basic ques= tions in my proposed RFC would be:
>=3B
>=3B * Can you find the = word "Selective Acknowledgments" or the abbreviation "SACK" in the marketin= g text? (Footnote: Please also check for the spelling "Selective Acknowledg= ements"=2C and for singular form.)
>=3B
>=3B * Can you find the = word "measurement" in the marketing text? Ideally in one sentence with term= s such as "Windows"=2C "Linux"=2C "OS X"=2C "BSD"?
>=3B
>=3B Bu= t=2C sigh=2C maybe the challenge is indeed too large.
>=3B
>=3B = Michael
>=3B
>=3B
>=3B PS: I also might have forgotten som= e irony tags somewhere.
>=3B
>=3B
>=3B >=3B -----Origina= l Message-----
>=3B >=3B From: Anthony Sabatini [mailto:tsabatini@ho= tmail.com]
>=3B >=3B Sent: Thursday=2C January 31=2C 2013 8:01 PM>=3B >=3B To: Scharf=2C Michael (Michael)=3B lars@netapp.com=3B cabo@= tzi.org
>=3B >=3B Cc: tcpm
>=3B >=3B Subject: RE: [tcpm] "Fuj= itsu Develops New Data Transfer
>=3B >=3B Protocol Enabling Improve= d Transmissions Speeds"
>=3B >=3B
>=3B >=3B All -
>=3B = >=3B
>=3B >=3B Well now you all know what I have been talking abo= ut fotr the
>=3B >=3B last year. Fujitsu has rediscovered the prot= ocol and
>=3B >=3B techniques I used in creating TDLC thirty years = ago. If you
>=3B >=3B want to know how it works=2C see my submital= to IETF 'TDLC=2C An
>=3B >=3B improved "Selective Repeat" protocol= ' draft-sabatini-tdlc-00=2C
>=3B >=3B or mail me and I will send yo= u a copy.
>=3B >=3B
>=3B >=3B And yes=2C it is that good=2C = never re-sending a message that was
>=3B >=3B received=2C near 100%= effective bandwidth utilization=2C
>=3B >=3B automatically adjusts= to link availability IN REAL TIME. Yes
>=3B >=3B it is real and y= ou can ALMOST make TCP-IP that good=2C the
>=3B >=3B problem with T= CP-IP is supporting bad legacy decisions.
>=3B >=3B
>=3B >= =3B Tony
>=3B >=3B
>=3B >=3B
>=3B >=3B Anthony Sabat= ini
>=3B >=3B 200 West 20th Street
>=3B >=3B Apt. 1216
>= =3B >=3B New York=2C NY 10011
>=3B >=3B
>=3B >=3B Phone: (= 212) 867-7179
>=3B >=3B Mobile: (917) 224-8388
>=3B >=3B
= >=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
&g= t=3B >=3B >=3B From: michael.scharf@alcatel-lucent.com
>=3B >=3B= >=3B To: lars@netapp.com=3B cabo@tzi.org
>=3B >=3B >=3B Date: T= hu=2C 31 Jan 2013 18:42:43 +0100
>=3B >=3B >=3B CC: tcpm@ietf.org<= br>>=3B >=3B >=3B Subject: Re: [tcpm] "Fujitsu Develops New Data Tran= sfer
>=3B >=3B Protocol Enabling Improved Transmissions Speeds"
= >=3B >=3B >=3B
>=3B >=3B >=3B Do we need an RFC that explai= ns to the press=2C in very
>=3B >=3B simple language=2C some very b= asic tests that a TCP marketing
>=3B >=3B text should pass before p= ublishing it on whatever IT news site?
>=3B >=3B >=3B
>=3B &= gt=3B >=3B Well=2C probably even that would not help :(
>=3B >=3B = >=3B
>=3B >=3B >=3B Michael
>=3B >=3B >=3B
>=3B = >=3B >=3B
>=3B >=3B >=3B
>=3B >=3B >=3B >=3B ----= -Original Message-----
>=3B >=3B >=3B >=3B From: tcpm-bounces@ie= tf.org
>=3B >=3B [mailto:tcpm-bounces@ietf.org] On Behalf
>= =3B >=3B >=3B >=3B Of Eggert=2C Lars
>=3B >=3B >=3B >=3B S= ent: Thursday=2C January 31=2C 2013 6:08 PM
>=3B >=3B >=3B >=3B = To: Carsten Bormann
>=3B >=3B >=3B >=3B Cc: tcpm@ietf.org list>=3B >=3B >=3B >=3B Subject: Re: [tcpm] "Fujitsu Develops New Dat= a Transfer Protocol
>=3B >=3B >=3B >=3B Enabling Improved Trans= missions Speeds"
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B &g= t=3B Hi=2C
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B m= y guess would be that they introduce a non-realistic amount of
>=3B &= gt=3B >=3B >=3B random (non-congestion) loss in their simulation to mak= e TCP loo
>=3B >=3B >=3B >=3B real bad. Their own solution prob= ably employs some mechanism that
>=3B >=3B >=3B >=3B doesn't ra= mp down when such loss happens. And I'd guess that
>=3B >=3B >=3B= >=3B fairness isn't a concern either.
>=3B >=3B >=3B >=3B >=3B >=3B >=3B >=3B Lars
>=3B >=3B >=3B >=3B
>=3B= >=3B >=3B >=3B On Jan 31=2C 2013=2C at 17:42=2C Carsten Bormann <= =3Bcabo@tzi.org>=3B wrote:
>=3B >=3B >=3B >=3B >=3B Just got= pointed to this at $DAYJOB.
>=3B >=3B >=3B >=3B >=3B All snak= e-oil alarms go off just from the buzzwords=2C so I
>=3B >=3B >=3B= >=3B didn't look at it in detail.
>=3B >=3B >=3B >=3B >=3B = But maybe they have solved bufferbloat (1/6 latency!) and
>=3B >=3B = >=3B >=3B fixed CC in the process (30x throughput!).
>=3B >=3B &= gt=3B >=3B >=3B They even seem to have put in a PEP.
>=3B >=3B &= gt=3B >=3B >=3B
>=3B >=3B >=3B >=3B >=3B If anyone happen= s to analyze this and can translate from PR
>=3B >=3B >=3B >=3B = speak to something someone on this list would understand=2C
>=3B >= =3B please do
>=3B >=3B >=3B >=3B post a pointer to your praise= /scorcher here.
>=3B >=3B >=3B >=3B Otherwise we return you to y= our regular program...
>=3B >=3B >=3B >=3B >=3B
>=3B >= =3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B
>=3B >=3B = http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.
&= gt=3B >=3B >=3B >=3B >=3B html
>=3B >=3B >=3B >=3B >= =3B
>=3B >=3B >=3B >=3B >=3B Gr=FC=DFe=2C Carsten
>=3B &= gt=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B >=3B PS.: Is i= t just me or are these getting more frequent recently?
>=3B >=3B >= =3B >=3B
>=3B >=3B >=3B >=3B ________________________________= _______________
>=3B >=3B >=3B >=3B tcpm mailing list
>=3B = >=3B >=3B >=3B tcpm@ietf.org
>=3B >=3B >=3B >=3B https://w= ww.ietf.org/mailman/listinfo/tcpm
>=3B >=3B >=3B >=3B
>=3B= >=3B >=3B _______________________________________________
>=3B &g= t=3B >=3B tcpm mailing list
>=3B >=3B >=3B tcpm@ietf.org
>= =3B >=3B >=3B https://www.ietf.org/mailman/listinfo/tcpm
>=3B >= =3B
>=3B >=3B
= --_fbc0ce47-0a9a-43aa-91ec-421265ae3e31_-- From michael.scharf@alcatel-lucent.com Thu Jan 31 11:43: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 CD2C721F87E7 for ; Thu, 31 Jan 2013 11:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.449 X-Spam-Level: X-Spam-Status: No, score=-9.449 tagged_above=-999 required=5 tests=[AWL=0.800, 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 6e0RL5cuTlqG for ; Thu, 31 Jan 2013 11:43:24 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0F521F853E for ; Thu, 31 Jan 2013 11:43:24 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0VJhIxb001359 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 31 Jan 2013 20:43:22 +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; Thu, 31 Jan 2013 20:43:18 +0100 From: "Scharf, Michael (Michael)" To: Anthony Sabatini , "lars@netapp.com" , "cabo@tzi.org" Date: Thu, 31 Jan 2013 20:43:17 +0100 Thread-Topic: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds" Thread-Index: Ac3/6fZbl8GjOxG8ToCGIG/ZGlrKCAAAEbZA Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0B39B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <8BAC82E4-6D1D-465F-9BE1-9ADE9F4E7DC8@tzi.org>, , <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0B397@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>, , <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0B39A@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: tcpm Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds" 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, 31 Jan 2013 19:43:25 -0000 Well, if a marketing texts includes the term "SACK", there is maybe a sligh= tly higher change that the observed 1000% performance improvement "over TCP= " is achieved at least against at a reasonable baseline. Michael > -----Original Message----- > From: Anthony Sabatini [mailto:tsabatini@hotmail.com]=20 > Sent: Thursday, January 31, 2013 8:34 PM > To: Scharf, Michael (Michael); lars@netapp.com; cabo@tzi.org > Cc: tcpm > Subject: RE: [tcpm] "Fujitsu Develops New Data Transfer=20 > Protocol Enabling Improved Transmissions Speeds" >=20 > Michael - >=20 > You will never see the words SACK or selective=20 > acknowledgement any where near any of these classes of=20 > protocol. These protocols recreate the receiving stations=20 > state at the sending station and therefore what is validly=20 > missing (and must be repeated) are most important, not what=20 > was received. It is the receiver which must control the=20 > transmitter, a basic oversight in how TCP-IP looks at the world. >=20 > Tony >=20 > Anthony Sabatini > 200 West 20th Street > Apt. 1216 > New York, NY 10011 >=20 > Phone: (212) 867-7179 > Mobile: (917) 224-8388 >=20 > =20 >=20 >=20 >=20 > > From: michael.scharf@alcatel-lucent.com > > To: tsabatini@hotmail.com; lars@netapp.com; cabo@tzi.org > > CC: tcpm@ietf.org > > Date: Thu, 31 Jan 2013 20:26:07 +0100 > > Subject: RE: [tcpm] "Fujitsu Develops New Data Transfer=20 > Protocol Enabling Improved Transmissions Speeds" > >=20 > > For what it is worth, two of the very basic questions in my=20 > proposed RFC would be: > >=20 > > * Can you find the word "Selective Acknowledgments" or the=20 > > abbreviation "SACK" in the marketing text? (Footnote: Please also=20 > > check for the spelling "Selective Acknowledgements", and=20 > for singular=20 > > form.) > >=20 > > * Can you find the word "measurement" in the marketing=20 > text? Ideally in one sentence with terms such as "Windows",=20 > "Linux", "OS X", "BSD"?=20 > >=20 > > But, sigh, maybe the challenge is indeed too large. > >=20 > > Michael > >=20 > >=20 > > PS: I also might have forgotten some irony tags somewhere. > >=20 > >=20 > > > -----Original Message----- > > > From: Anthony Sabatini [mailto:tsabatini@hotmail.com] > > > Sent: Thursday, January 31, 2013 8:01 PM > > > To: Scharf, Michael (Michael); lars@netapp.com; cabo@tzi.org > > > Cc: tcpm > > > Subject: RE: [tcpm] "Fujitsu Develops New Data Transfer Protocol=20 > > > Enabling Improved Transmissions Speeds" > > >=20 > > > All - > > >=20 > > > Well now you all know what I have been talking about fotr=20 > the last=20 > > > year. Fujitsu has rediscovered the protocol and=20 > techniques I used in=20 > > > creating TDLC thirty years ago. If you want to know how it works,=20 > > > see my submital to IETF 'TDLC, An improved "Selective Repeat"=20 > > > protocol' draft-sabatini-tdlc-00, or mail me and I will=20 > send you a=20 > > > copy. > > >=20 > > > And yes, it is that good, never re-sending a message that was=20 > > > received, near 100% effective bandwidth utilization,=20 > automatically=20 > > > adjusts to link availability IN REAL TIME. Yes it is real and you=20 > > > can ALMOST make TCP-IP that good, the problem with TCP-IP is=20 > > > supporting bad legacy decisions. > > >=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 > > >=20 > > >=20 > > >=20 > > > > From: michael.scharf@alcatel-lucent.com > > > > To: lars@netapp.com; cabo@tzi.org > > > > Date: Thu, 31 Jan 2013 18:42:43 +0100 > > > > CC: tcpm@ietf.org > > > > Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer > > > Protocol Enabling Improved Transmissions Speeds" > > > >=20 > > > > Do we need an RFC that explains to the press, in very > > > simple language, some very basic tests that a TCP marketing text=20 > > > should pass before publishing it on whatever IT news site? > > > >=20 > > > > Well, probably even that would not help :( > > > >=20 > > > > Michael > > > >=20 > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: tcpm-bounces@ietf.org > > > [mailto:tcpm-bounces@ietf.org] On Behalf > > > > > Of Eggert, Lars > > > > > Sent: Thursday, January 31, 2013 6:08 PM > > > > > To: Carsten Bormann > > > > > Cc: tcpm@ietf.org list > > > > > Subject: Re: [tcpm] "Fujitsu Develops New Data=20 > Transfer Protocol=20 > > > > > Enabling Improved Transmissions Speeds" > > > > >=20 > > > > > Hi, > > > > >=20 > > > > > my guess would be that they introduce a non-realistic=20 > amount of=20 > > > > > random (non-congestion) loss in their simulation to=20 > make TCP loo=20 > > > > > real bad. Their own solution probably employs some mechanism=20 > > > > > that doesn't ramp down when such loss happens. And I'd guess=20 > > > > > that fairness isn't a concern either. > > > > >=20 > > > > > Lars > > > > >=20 > > > > > On Jan 31, 2013, at 17:42, Carsten Bormann=20 > wrote: > > > > > > Just got pointed to this at $DAYJOB. > > > > > > All snake-oil alarms go off just from the buzzwords, so I > > > > > didn't look at it in detail. > > > > > > But maybe they have solved bufferbloat (1/6 latency!) and > > > > > fixed CC in the process (30x throughput!). > > > > > > They even seem to have put in a PEP. > > > > > >=20 > > > > > > If anyone happens to analyze this and can translate from PR > > > > > speak to something someone on this list would understand, > > > please do > > > > > post a pointer to your praise/scorcher here. > > > > > Otherwise we return you to your regular program... > > > > > >=20 > > > > > >=20 > > > > >=20 > > >=20 > http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02. > > > > > > html > > > > > >=20 > > > > > > Gr=FC=DFe, Carsten > > > > > >=20 > > > > > > PS.: Is it just me or are these getting more=20 > frequent recently? > > > > >=20 > > > > > _______________________________________________ > > > > > tcpm mailing list > > > > > tcpm@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/tcpm > > > > >=20 > > > > _______________________________________________ > > > > tcpm mailing list > > > > tcpm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/tcpm > > >=20 > > >=20 >=20 > = From tsabatini@hotmail.com Thu Jan 31 11:53: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 6590B21F84F8 for ; Thu, 31 Jan 2013 11:53:22 -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=[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 JMrutqDPeSH8 for ; Thu, 31 Jan 2013 11:53:21 -0800 (PST) Received: from bay0-omc1-s7.bay0.hotmail.com (bay0-omc1-s7.bay0.hotmail.com [65.54.190.18]) by ietfa.amsl.com (Postfix) with ESMTP id E358921F8467 for ; Thu, 31 Jan 2013 11:53:18 -0800 (PST) Received: from BAY172-W20 ([65.54.190.61]) by bay0-omc1-s7.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Jan 2013 11:53:18 -0800 X-EIP: [sirCScJTRH05Ttd749Sm21hX3MGQwcTn] X-Originating-Email: [tsabatini@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_c1e09593-1206-4a92-bce7-2114cafefc4e_" From: Anthony Sabatini To: tcpm Michael Scharf , tcpm lars , tccpm cabo Date: Thu, 31 Jan 2013 14:53:18 -0500 Importance: Normal In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0B39B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <8BAC82E4-6D1D-465F-9BE1-9ADE9F4E7DC8@tzi.org>, , <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0B397@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>, , <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0B39A@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>, , <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0B39B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> MIME-Version: 1.0 X-OriginalArrivalTime: 31 Jan 2013 19:53:18.0512 (UTC) FILETIME=[9D9A6B00:01CDFFEC] Cc: tcpm Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds" 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, 31 Jan 2013 19:53:22 -0000 --_c1e09593-1206-4a92-bce7-2114cafefc4e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Michael - Theoretical SACK is not PRACTICAL SACK - SACK is effectively disabled in a = high congestion or high error rate environment (a fact I have made comment = on repeatedly). The Fujitsu or TDLC protocol IS NOT SUSCEPTIBLE to congestion collapse. SA= CK as currently defined is=2C SACK with my recommended changes is not. The = obsession wit Reno. Vegas=2C Tahoe et seq. IS THE PROBLEM not a cure=2C SAC= K is an affirmative fix but is effectively neutered by legacy recovery myth= s. Tony Anthony Sabatini 200 West 20th Street Apt. 1216 New York=2C NY 10011 Phone: (212) 867-7179 Mobile: (917) 224-8388 =20 > From: michael.scharf@alcatel-lucent.com > To: tsabatini@hotmail.com=3B lars@netapp.com=3B cabo@tzi.org > CC: tcpm@ietf.org > Date: Thu=2C 31 Jan 2013 20:43:17 +0100 > Subject: RE: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling= Improved Transmissions Speeds" >=20 > Well=2C if a marketing texts includes the term "SACK"=2C there is maybe a= slightly higher change that the observed 1000% performance improvement "ov= er TCP" is achieved at least against at a reasonable baseline. >=20 > Michael >=20 >=20 > > -----Original Message----- > > From: Anthony Sabatini [mailto:tsabatini@hotmail.com]=20 > > Sent: Thursday=2C January 31=2C 2013 8:34 PM > > To: Scharf=2C Michael (Michael)=3B lars@netapp.com=3B cabo@tzi.org > > Cc: tcpm > > Subject: RE: [tcpm] "Fujitsu Develops New Data Transfer=20 > > Protocol Enabling Improved Transmissions Speeds" > >=20 > > Michael - > >=20 > > You will never see the words SACK or selective=20 > > acknowledgement any where near any of these classes of=20 > > protocol. These protocols recreate the receiving stations=20 > > state at the sending station and therefore what is validly=20 > > missing (and must be repeated) are most important=2C not what=20 > > was received. It is the receiver which must control the=20 > > transmitter=2C a basic oversight in how TCP-IP looks at the world. > >=20 > > Tony > >=20 > > Anthony Sabatini > > 200 West 20th Street > > Apt. 1216 > > New York=2C NY 10011 > >=20 > > Phone: (212) 867-7179 > > Mobile: (917) 224-8388 > >=20 > > =20 > >=20 > >=20 > >=20 > > > From: michael.scharf@alcatel-lucent.com > > > To: tsabatini@hotmail.com=3B lars@netapp.com=3B cabo@tzi.org > > > CC: tcpm@ietf.org > > > Date: Thu=2C 31 Jan 2013 20:26:07 +0100 > > > Subject: RE: [tcpm] "Fujitsu Develops New Data Transfer=20 > > Protocol Enabling Improved Transmissions Speeds" > > >=20 > > > For what it is worth=2C two of the very basic questions in my=20 > > proposed RFC would be: > > >=20 > > > * Can you find the word "Selective Acknowledgments" or the=20 > > > abbreviation "SACK" in the marketing text? (Footnote: Please also=20 > > > check for the spelling "Selective Acknowledgements"=2C and=20 > > for singular=20 > > > form.) > > >=20 > > > * Can you find the word "measurement" in the marketing=20 > > text? Ideally in one sentence with terms such as "Windows"=2C=20 > > "Linux"=2C "OS X"=2C "BSD"?=20 > > >=20 > > > But=2C sigh=2C maybe the challenge is indeed too large. > > >=20 > > > Michael > > >=20 > > >=20 > > > PS: I also might have forgotten some irony tags somewhere. > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Anthony Sabatini [mailto:tsabatini@hotmail.com] > > > > Sent: Thursday=2C January 31=2C 2013 8:01 PM > > > > To: Scharf=2C Michael (Michael)=3B lars@netapp.com=3B cabo@tzi.org > > > > Cc: tcpm > > > > Subject: RE: [tcpm] "Fujitsu Develops New Data Transfer Protocol=20 > > > > Enabling Improved Transmissions Speeds" > > > >=20 > > > > All - > > > >=20 > > > > Well now you all know what I have been talking about fotr=20 > > the last=20 > > > > year. Fujitsu has rediscovered the protocol and=20 > > techniques I used in=20 > > > > creating TDLC thirty years ago. If you want to know how it works=2C= =20 > > > > see my submital to IETF 'TDLC=2C An improved "Selective Repeat"=20 > > > > protocol' draft-sabatini-tdlc-00=2C or mail me and I will=20 > > send you a=20 > > > > copy. > > > >=20 > > > > And yes=2C it is that good=2C never re-sending a message that was=20 > > > > received=2C near 100% effective bandwidth utilization=2C=20 > > automatically=20 > > > > adjusts to link availability IN REAL TIME. Yes it is real and you=20 > > > > can ALMOST make TCP-IP that good=2C the problem with TCP-IP is=20 > > > > supporting bad legacy decisions. > > > >=20 > > > > Tony > > > >=20 > > > >=20 > > > > Anthony Sabatini > > > > 200 West 20th Street > > > > Apt. 1216 > > > > New York=2C NY 10011 > > > >=20 > > > > Phone: (212) 867-7179 > > > > Mobile: (917) 224-8388 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > > From: michael.scharf@alcatel-lucent.com > > > > > To: lars@netapp.com=3B cabo@tzi.org > > > > > Date: Thu=2C 31 Jan 2013 18:42:43 +0100 > > > > > CC: tcpm@ietf.org > > > > > Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer > > > > Protocol Enabling Improved Transmissions Speeds" > > > > >=20 > > > > > Do we need an RFC that explains to the press=2C in very > > > > simple language=2C some very basic tests that a TCP marketing text= =20 > > > > should pass before publishing it on whatever IT news site? > > > > >=20 > > > > > Well=2C probably even that would not help :( > > > > >=20 > > > > > Michael > > > > >=20 > > > > >=20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: tcpm-bounces@ietf.org > > > > [mailto:tcpm-bounces@ietf.org] On Behalf > > > > > > Of Eggert=2C Lars > > > > > > Sent: Thursday=2C January 31=2C 2013 6:08 PM > > > > > > To: Carsten Bormann > > > > > > Cc: tcpm@ietf.org list > > > > > > Subject: Re: [tcpm] "Fujitsu Develops New Data=20 > > Transfer Protocol=20 > > > > > > Enabling Improved Transmissions Speeds" > > > > > >=20 > > > > > > Hi=2C > > > > > >=20 > > > > > > my guess would be that they introduce a non-realistic=20 > > amount of=20 > > > > > > random (non-congestion) loss in their simulation to=20 > > make TCP loo=20 > > > > > > real bad. Their own solution probably employs some mechanism=20 > > > > > > that doesn't ramp down when such loss happens. And I'd guess=20 > > > > > > that fairness isn't a concern either. > > > > > >=20 > > > > > > Lars > > > > > >=20 > > > > > > On Jan 31=2C 2013=2C at 17:42=2C Carsten Bormann=20 > > wrote: > > > > > > > Just got pointed to this at $DAYJOB. > > > > > > > All snake-oil alarms go off just from the buzzwords=2C so I > > > > > > didn't look at it in detail. > > > > > > > But maybe they have solved bufferbloat (1/6 latency!) and > > > > > > fixed CC in the process (30x throughput!). > > > > > > > They even seem to have put in a PEP. > > > > > > >=20 > > > > > > > If anyone happens to analyze this and can translate from PR > > > > > > speak to something someone on this list would understand=2C > > > > please do > > > > > > post a pointer to your praise/scorcher here. > > > > > > Otherwise we return you to your regular program... > > > > > > >=20 > > > > > > >=20 > > > > > >=20 > > > >=20 > > http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02. > > > > > > > html > > > > > > >=20 > > > > > > > Gr=FC=DFe=2C Carsten > > > > > > >=20 > > > > > > > PS.: Is it just me or are these getting more=20 > > frequent recently? > > > > > >=20 > > > > > > _______________________________________________ > > > > > > tcpm mailing list > > > > > > tcpm@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/tcpm > > > > > >=20 > > > > > _______________________________________________ > > > > > tcpm mailing list > > > > > tcpm@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/tcpm > > > >=20 > > > >=20 > >=20 > >=20 = --_c1e09593-1206-4a92-bce7-2114cafefc4e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Michael -

Theoretical SACK is not PRACTICAL SACK - SACK is effective= ly disabled in a high congestion or high error rate environment (a fact I h= ave made comment on repeatedly).

The Fujitsu or TDLC protocol IS NOT= SUSCEPTIBLE to congestion collapse. =3B SACK as currently defined is= =2C SACK with my recommended changes is not. The obsession wit Reno. Vegas= =2C Tahoe et seq. IS THE PROBLEM not a cure=2C SACK is an affirmative fix b= ut is effectively neutered by legacy recovery myths.

Tony

Ant= hony Sabatini
200 =3BWest 20th Street
Apt. 1216
New York=2C NY= 10011

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

 = =3B


>=3B From: mich= ael.scharf@alcatel-lucent.com
>=3B To: tsabatini@hotmail.com=3B lars@n= etapp.com=3B cabo@tzi.org
>=3B CC: tcpm@ietf.org
>=3B Date: Thu= =2C 31 Jan 2013 20:43:17 +0100
>=3B Subject: RE: [tcpm] "Fujitsu Devel= ops New Data Transfer Protocol Enabling Improved Transmissions Speeds"
&= gt=3B
>=3B Well=2C if a marketing texts includes the term "SACK"=2C t= here is maybe a slightly higher change that the observed 1000% performance = improvement "over TCP" is achieved at least against at a reasonable baselin= e.
>=3B
>=3B Michael
>=3B
>=3B
>=3B >=3B ----= -Original Message-----
>=3B >=3B From: Anthony Sabatini [mailto:tsab= atini@hotmail.com]
>=3B >=3B Sent: Thursday=2C January 31=2C 2013 8= :34 PM
>=3B >=3B To: Scharf=2C Michael (Michael)=3B lars@netapp.com= =3B cabo@tzi.org
>=3B >=3B Cc: tcpm
>=3B >=3B Subject: RE: [t= cpm] "Fujitsu Develops New Data Transfer
>=3B >=3B Protocol Enablin= g Improved Transmissions Speeds"
>=3B >=3B
>=3B >=3B Michael= -
>=3B >=3B
>=3B >=3B You will never see the words SACK or = selective
>=3B >=3B acknowledgement any where near any of these cla= sses of
>=3B >=3B protocol. These protocols recreate the receiving= stations
>=3B >=3B state at the sending station and therefore what= is validly
>=3B >=3B missing (and must be repeated) are most impor= tant=2C not what
>=3B >=3B was received. It is the receiver which = must control the
>=3B >=3B transmitter=2C a basic oversight in how = TCP-IP looks at the world.
>=3B >=3B
>=3B >=3B Tony
>= =3B >=3B
>=3B >=3B Anthony Sabatini
>=3B >=3B 200 West 20t= h Street
>=3B >=3B Apt. 1216
>=3B >=3B New York=2C NY 10011>=3B >=3B
>=3B >=3B Phone: (212) 867-7179
>=3B >=3B Mo= bile: (917) 224-8388
>=3B >=3B
>=3B >=3B
>=3B >=3B =
>=3B >=3B
>=3B >=3B
>=3B >=3B >=3B From: michael.= scharf@alcatel-lucent.com
>=3B >=3B >=3B To: tsabatini@hotmail.com= =3B lars@netapp.com=3B cabo@tzi.org
>=3B >=3B >=3B CC: tcpm@ietf.o= rg
>=3B >=3B >=3B Date: Thu=2C 31 Jan 2013 20:26:07 +0100
>= =3B >=3B >=3B Subject: RE: [tcpm] "Fujitsu Develops New Data Transfer <= br>>=3B >=3B Protocol Enabling Improved Transmissions Speeds"
>=3B= >=3B >=3B
>=3B >=3B >=3B For what it is worth=2C two of the = very basic questions in my
>=3B >=3B proposed RFC would be:
>= =3B >=3B >=3B
>=3B >=3B >=3B * Can you find the word "Selecti= ve Acknowledgments" or the
>=3B >=3B >=3B abbreviation "SACK" in = the marketing text? (Footnote: Please also
>=3B >=3B >=3B check f= or the spelling "Selective Acknowledgements"=2C and
>=3B >=3B for s= ingular
>=3B >=3B >=3B form.)
>=3B >=3B >=3B
>=3B = >=3B >=3B * Can you find the word "measurement" in the marketing
&g= t=3B >=3B text? Ideally in one sentence with terms such as "Windows"=2C <= br>>=3B >=3B "Linux"=2C "OS X"=2C "BSD"?
>=3B >=3B >=3B
&= gt=3B >=3B >=3B But=2C sigh=2C maybe the challenge is indeed too large.=
>=3B >=3B >=3B
>=3B >=3B >=3B Michael
>=3B >=3B = >=3B
>=3B >=3B >=3B
>=3B >=3B >=3B PS: I also might h= ave forgotten some irony tags somewhere.
>=3B >=3B >=3B
>=3B= >=3B >=3B
>=3B >=3B >=3B >=3B -----Original Message----->=3B >=3B >=3B >=3B From: Anthony Sabatini [mailto:tsabatini@hotm= ail.com]
>=3B >=3B >=3B >=3B Sent: Thursday=2C January 31=2C 201= 3 8:01 PM
>=3B >=3B >=3B >=3B To: Scharf=2C Michael (Michael)=3B= lars@netapp.com=3B cabo@tzi.org
>=3B >=3B >=3B >=3B Cc: tcpm>=3B >=3B >=3B >=3B Subject: RE: [tcpm] "Fujitsu Develops New Data= Transfer Protocol
>=3B >=3B >=3B >=3B Enabling Improved Transm= issions Speeds"
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >= =3B All -
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B We= ll now you all know what I have been talking about fotr
>=3B >=3B t= he last
>=3B >=3B >=3B >=3B year. Fujitsu has rediscovered the = protocol and
>=3B >=3B techniques I used in
>=3B >=3B >= =3B >=3B creating TDLC thirty years ago. If you want to know how it works= =2C
>=3B >=3B >=3B >=3B see my submital to IETF 'TDLC=2C An imp= roved "Selective Repeat"
>=3B >=3B >=3B >=3B protocol' draft-sa= batini-tdlc-00=2C or mail me and I will
>=3B >=3B send you a
&g= t=3B >=3B >=3B >=3B copy.
>=3B >=3B >=3B >=3B
>=3B &= gt=3B >=3B >=3B And yes=2C it is that good=2C never re-sending a messag= e that was
>=3B >=3B >=3B >=3B received=2C near 100% effective = bandwidth utilization=2C
>=3B >=3B automatically
>=3B >=3B = >=3B >=3B adjusts to link availability IN REAL TIME. Yes it is real and= you
>=3B >=3B >=3B >=3B can ALMOST make TCP-IP that good=2C th= e problem with TCP-IP is
>=3B >=3B >=3B >=3B supporting bad leg= acy decisions.
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >= =3B Tony
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B >=3B >=3B >=3B >=3B Anthony Sabatini
>=3B >=3B >=3B >= =3B 200 West 20th Street
>=3B >=3B >=3B >=3B Apt. 1216
>=3B= >=3B >=3B >=3B New York=2C NY 10011
>=3B >=3B >=3B >=3B <= br>>=3B >=3B >=3B >=3B Phone: (212) 867-7179
>=3B >=3B >= =3B >=3B Mobile: (917) 224-8388
>=3B >=3B >=3B >=3B
>=3B= >=3B >=3B >=3B
>=3B >=3B >=3B >=3B
>=3B >=3B >= =3B >=3B
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B = >=3B From: michael.scharf@alcatel-lucent.com
>=3B >=3B >=3B >= =3B >=3B To: lars@netapp.com=3B cabo@tzi.org
>=3B >=3B >=3B >= =3B >=3B Date: Thu=2C 31 Jan 2013 18:42:43 +0100
>=3B >=3B >=3B = >=3B >=3B CC: tcpm@ietf.org
>=3B >=3B >=3B >=3B >=3B Subje= ct: Re: [tcpm] "Fujitsu Develops New Data Transfer
>=3B >=3B >=3B = >=3B Protocol Enabling Improved Transmissions Speeds"
>=3B >=3B &g= t=3B >=3B >=3B
>=3B >=3B >=3B >=3B >=3B Do we need an RFC= that explains to the press=2C in very
>=3B >=3B >=3B >=3B simpl= e language=2C some very basic tests that a TCP marketing text
>=3B &g= t=3B >=3B >=3B should pass before publishing it on whatever IT news sit= e?
>=3B >=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B &g= t=3B Well=2C probably even that would not help :(
>=3B >=3B >=3B &= gt=3B >=3B
>=3B >=3B >=3B >=3B >=3B Michael
>=3B >= =3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B >=3B
>=3B = >=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B >=3B >=3B -= ----Original Message-----
>=3B >=3B >=3B >=3B >=3B >=3B From= : tcpm-bounces@ietf.org
>=3B >=3B >=3B >=3B [mailto:tcpm-bounces= @ietf.org] On Behalf
>=3B >=3B >=3B >=3B >=3B >=3B Of Eggert= =2C Lars
>=3B >=3B >=3B >=3B >=3B >=3B Sent: Thursday=2C Jan= uary 31=2C 2013 6:08 PM
>=3B >=3B >=3B >=3B >=3B >=3B To: Ca= rsten Bormann
>=3B >=3B >=3B >=3B >=3B >=3B Cc: tcpm@ietf.or= g list
>=3B >=3B >=3B >=3B >=3B >=3B Subject: Re: [tcpm] "Fu= jitsu Develops New Data
>=3B >=3B Transfer Protocol
>=3B >= =3B >=3B >=3B >=3B >=3B Enabling Improved Transmissions Speeds"
= >=3B >=3B >=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B &= gt=3B >=3B Hi=2C
>=3B >=3B >=3B >=3B >=3B >=3B
>=3B = >=3B >=3B >=3B >=3B >=3B my guess would be that they introduce a = non-realistic
>=3B >=3B amount of
>=3B >=3B >=3B >=3B &= gt=3B >=3B random (non-congestion) loss in their simulation to
>=3B= >=3B make TCP loo
>=3B >=3B >=3B >=3B >=3B >=3B real bad= . Their own solution probably employs some mechanism
>=3B >=3B >= =3B >=3B >=3B >=3B that doesn't ramp down when such loss happens. And= I'd guess
>=3B >=3B >=3B >=3B >=3B >=3B that fairness isn'= t a concern either.
>=3B >=3B >=3B >=3B >=3B >=3B
>=3B= >=3B >=3B >=3B >=3B >=3B Lars
>=3B >=3B >=3B >=3B >= =3B >=3B
>=3B >=3B >=3B >=3B >=3B >=3B On Jan 31=2C 2013= =2C at 17:42=2C Carsten Bormann
>=3B >=3B <=3Bcabo@tzi.org>=3B = wrote:
>=3B >=3B >=3B >=3B >=3B >=3B >=3B Just got pointed= to this at $DAYJOB.
>=3B >=3B >=3B >=3B >=3B >=3B >=3B Al= l snake-oil alarms go off just from the buzzwords=2C so I
>=3B >=3B = >=3B >=3B >=3B >=3B didn't look at it in detail.
>=3B >=3B &= gt=3B >=3B >=3B >=3B >=3B But maybe they have solved bufferbloat (1= /6 latency!) and
>=3B >=3B >=3B >=3B >=3B >=3B fixed CC in t= he process (30x throughput!).
>=3B >=3B >=3B >=3B >=3B >=3B = >=3B They even seem to have put in a PEP.
>=3B >=3B >=3B >=3B = >=3B >=3B >=3B
>=3B >=3B >=3B >=3B >=3B >=3B >=3B I= f anyone happens to analyze this and can translate from PR
>=3B >=3B= >=3B >=3B >=3B >=3B speak to something someone on this list would = understand=2C
>=3B >=3B >=3B >=3B please do
>=3B >=3B >= =3B >=3B >=3B >=3B post a pointer to your praise/scorcher here.
&g= t=3B >=3B >=3B >=3B >=3B >=3B Otherwise we return you to your reg= ular program...
>=3B >=3B >=3B >=3B >=3B >=3B >=3B
>= =3B >=3B >=3B >=3B >=3B >=3B >=3B
>=3B >=3B >=3B >= =3B >=3B >=3B
>=3B >=3B >=3B >=3B
>=3B >=3B http://= www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.
>=3B &= gt=3B >=3B >=3B >=3B >=3B >=3B html
>=3B >=3B >=3B >= =3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B >=3B >=3B >= =3B Gr=FC=DFe=2C Carsten
>=3B >=3B >=3B >=3B >=3B >=3B >= =3B
>=3B >=3B >=3B >=3B >=3B >=3B >=3B PS.: Is it just me= or are these getting more
>=3B >=3B frequent recently?
>=3B &= gt=3B >=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B >=3B &g= t=3B _______________________________________________
>=3B >=3B >= =3B >=3B >=3B >=3B tcpm mailing list
>=3B >=3B >=3B >=3B &= gt=3B >=3B tcpm@ietf.org
>=3B >=3B >=3B >=3B >=3B >=3B htt= ps://www.ietf.org/mailman/listinfo/tcpm
>=3B >=3B >=3B >=3B >= =3B >=3B
>=3B >=3B >=3B >=3B >=3B _________________________= ______________________
>=3B >=3B >=3B >=3B >=3B tcpm mailing l= ist
>=3B >=3B >=3B >=3B >=3B tcpm@ietf.org
>=3B >=3B &g= t=3B >=3B >=3B https://www.ietf.org/mailman/listinfo/tcpm
>=3B >= =3B >=3B >=3B
>=3B >=3B >=3B >=3B
>=3B >=3B
>= =3B >=3B
= --_c1e09593-1206-4a92-bce7-2114cafefc4e_-- From l.wood@surrey.ac.uk Thu Jan 31 22:19: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 55C9521F886C for ; Thu, 31 Jan 2013 22:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 GE-b7Cufew3r for ; Thu, 31 Jan 2013 22:19:43 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id C262821F8869 for ; Thu, 31 Jan 2013 22:19:42 -0800 (PST) Received: from [195.245.230.131:21014] by server-10.bemta-3.messagelabs.com id 06/33-10609-D7E5B015; Fri, 01 Feb 2013 06:19:41 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-3.tower-78.messagelabs.com!1359699580!25961628!1 X-Originating-IP: [131.227.200.39] X-StarScan-Received: X-StarScan-Version: 6.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15845 invoked from network); 1 Feb 2013 06:19:41 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-3.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 1 Feb 2013 06:19:41 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.98]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Fri, 1 Feb 2013 06:19:40 +0000 From: To: , , , Date: Fri, 1 Feb 2013 06:19:39 +0000 Thread-Topic: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds" Thread-Index: Ac3/5V2jRKEYymvPT62xuZzXCOuRhQAXe5Sk Message-ID: <290E20B455C66743BE178C5C84F124081779FD38E0@EXMB01CMS.surrey.ac.uk> References: <8BAC82E4-6D1D-465F-9BE1-9ADE9F4E7DC8@tzi.org>, , <2A886F9088894347A3BE0CC5B7A85F3E9AA0F0B397@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>, 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcpm@ietf.org Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling Improved Transmissions Speeds" 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 Feb 2013 06:19:44 -0000 Hmmm, Saratoga uses the same ideas as TDLC, although we went for index pair= s rather than the bitmap. Confirmed and Highest Received are in there, as i= s the capability for RTT measurement. TCP SACK is constrained by existing TCP option space. Congestion control is needed when sharing, but when you own and run a dedic= ated private link you can simplify and engineer for throughput. Using Inter= net technology doesn't mean you're on the shared Internet. Lloyd Wood http://saratoga.sf.net/ ________________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Anthony Sa= batini [tsabatini@hotmail.com] Sent: 31 January 2013 19:01 To: tcpm Michael Scharf; lars@netapp.com; cabo@tzi.org Cc: tcpm Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling I= mproved Transmissions Speeds" All - Well now you all know what I have been talking about fotr the last year. F= ujitsu has rediscovered the protocol and techniques I used in creating TDLC= thirty years ago. If you want to know how it works, see my submital to IE= TF 'TDLC, An improved "Selective Repeat" protocol' draft-sabatini-tdlc-00, = or mail me and I will send you a copy. And yes, it is that good, never re-sending a message that was received, nea= r 100% effective bandwidth utilization, automatically adjusts to link avail= ability IN REAL TIME. Yes it is real and you can ALMOST make TCP-IP that g= ood, the problem with TCP-IP is supporting bad legacy decisions. Tony Anthony Sabatini 200 West 20th Street Apt. 1216 New York, NY 10011 Phone: (212) 867-7179 Mobile: (917) 224-8388 > From: michael.scharf@alcatel-lucent.com > To: lars@netapp.com; cabo@tzi.org > Date: Thu, 31 Jan 2013 18:42:43 +0100 > CC: tcpm@ietf.org > Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer Protocol Enabling= Improved Transmissions Speeds" > > Do we need an RFC that explains to the press, in very simple language, so= me very basic tests that a TCP marketing text should pass before publishing= it on whatever IT news site? > > Well, probably even that would not help :( > > Michael > > > > > -----Original Message----- > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > > Behalf Of Eggert, Lars > > Sent: Thursday, January 31, 2013 6:08 PM > > To: Carsten Bormann > > Cc: tcpm@ietf.org list > > Subject: Re: [tcpm] "Fujitsu Develops New Data Transfer > > Protocol Enabling Improved Transmissions Speeds" > > > > Hi, > > > > my guess would be that they introduce a non-realistic amount > > of random (non-congestion) loss in their simulation to make > > TCP loo real bad. Their own solution probably employs some > > mechanism that doesn't ramp down when such loss happens. And > > I'd guess that fairness isn't a concern either. > > > > Lars > > > > On Jan 31, 2013, at 17:42, Carsten Bormann wrote: > > > Just got pointed to this at $DAYJOB. > > > All snake-oil alarms go off just from the buzzwords, so I > > didn't look at it in detail. > > > But maybe they have solved bufferbloat (1/6 latency!) and > > fixed CC in the process (30x throughput!). > > > They even seem to have put in a PEP. > > > > > > If anyone happens to analyze this and can translate from PR > > speak to something someone on this list would understand, > > please do post a pointer to your praise/scorcher here. > > Otherwise we return you to your regular program... > > > > > > > > http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02. > > > html > > > > > > Gr=FC=DFe, Carsten > > > > > > PS.: Is it just me or are these getting more frequent recently? > > > > _______________________________________________ > > 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