From rs@netapp.com  Sun Apr  1 12:38:41 2012
Return-Path: <rs@netapp.com>
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 AE8C421F89C5 for <tcpm@ietfa.amsl.com>; Sun,  1 Apr 2012 12:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.11
X-Spam-Level: 
X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Wy4PBaSN1A2 for <tcpm@ietfa.amsl.com>; Sun,  1 Apr 2012 12:38:41 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 01C6521F89C3 for <tcpm@ietf.org>; Sun,  1 Apr 2012 12:38:40 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,353,1330934400"; d="scan'208";a="637851786"
Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 01 Apr 2012 12:38:39 -0700
Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q31Jccoh013088; Sun, 1 Apr 2012 12:38:38 -0700 (PDT)
Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.76]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0247.003; Sun, 1 Apr 2012 12:38:30 -0700
From: "Scheffenegger, Richard" <rs@netapp.com>
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
Thread-Topic: [tcpm] A new ID on TCP option space extension. 
Thread-Index: AQHND6zi+FLNXvh+KUCdkIbbd2jp65aGV8AA
Date: Sun, 1 Apr 2012 19:38:29 +0000
Message-ID: <25995122-D162-44B5-859C-AB89133C111C@netapp.com>
References: <012C3117EDDB3C4781FD802A8C27DD4F13C4D1@SACEXCMBX02-PRD.hq.netapp.com> <20120331140258.3AADC109F66B@lawyers.icir.org> <1F8E0A684D3FF54680294BCFE57A7DB504C9287B@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <1F8E0A684D3FF54680294BCFE57A7DB504C9287B@xmb-sjc-23e.amer.cisco.com>
Accept-Language: de-AT, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-ID: <24FC7934EB87B04F9A49414C1B2090BF@tahoe.netapp.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: David Borman <dab@weston.borman.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "mallman@icir.org" <mallman@icir.org>
Subject: Re: [tcpm] A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Apr 2012 19:38:41 -0000

Hi Anantha

I beliefe delayed negotiation for timestamps would be comparatively easy, c=
ompared to dynamically disabling it at some time later during the session. =
I have the stromg suspicion that some stack may already do this - but most =
likely due to a buggy 1323 implementation more than anything... At least wh=
en i did some tests for my ts nego draft, some stacks reacted like that whe=
n temporarily disabling ts. But in my tests,  ts were negotiated for during=
 syn.

Properly disabling ts will be an order of magnitude more involved i guess.

But just delaying ts nego would free precious syn option space, which has b=
ecome increasingly important.

Best regards,
  Richard




Am 01.04.2012 um 04:12 schrieb "Anantha Ramaiah (ananth)" <ananth@cisco.com=
>:

> <just got back to SFO. Catching up...>
>=20
> RTTM has been touted to be the main use for timestamps which includes
> solution to the Karn's ambiguity problem. The other one is PAWS and
> w.r.t I agree it is wastage of TCP option bytes and the idea of turning
> on PAWS detection dynamically (using timestamps) makes sense to me.
> Changing the timestamp semantics means change to many TCP/IP stacks
> (variables like ts_val, ts_recent would not be interpreted as before,
> all other debugging tools etc., may need to understand this change)
>=20
> Even if we are planning to do so, I thought you meant to negotiate the
> capability during SYN (don't send the timestamp value) and send
> timestamps when needed. Or are we saying that we are trying to negotiate
> the option when needed, this sounds like a bigger change in semantics
> since every TCP option is only negotiated during SYN as it stands today.
> To make this more useful, you would want to not only turn on this
> capability when needed, also turn off when not needed.
>=20
> Didn't we already have a RFC 1323bis document? Is that expired or did it
> make it to the RFC 1323 update ? If not, you could always fold this idea
> (assuming there is a consensus) into that document. Not sure whether we
> would want multiple RFC 1323bis documents...
>=20
> Just my 2 cents..
>=20
> -Anantha
>=20
>> -----Original Message-----
>> From: mallman@icir.org [mailto:mallman@icir.org]
>> Sent: Saturday, March 31, 2012 7:03 AM
>> To: Scheffenegger, Richard
>> Cc: David Borman; tcpm@ietf.org; Anantha Ramaiah (ananth)
>> Subject: Re: [tcpm] A new ID on TCP option space extension.
>>=20
>>=20
>>> Actually, allowing for delay-based congestion algorithms like
> LEDBET,
>>> CTCP may be a stronger use case for timestamps.
>>=20
>> That is absolutely fine.  I am not saying we should rid the world of
>> timestamps.  I am saying that we should re-arrange the world such that
>> TCP connections do not have to use timestamps because they *might*
> need
>> them later.  If there is some good reason to use them from the onset
> of
>> the connection, great, use them.  But,
>>=20
>> - If RTTM is the reason to use the TS option then I haven't seen the
>>   empirical evidence that says this is at all helpful and so I am
>>   pretty dubious.
>>=20
>> - If PAWS is the reason to use the TS option then I don't see why
>> we'd
>>   waste the bytes on the TS option for connections that send less
>> than
>>   4GB (i.e., that will not wrap the sequence space).  So, being able
>>   to turn on the TS option mid-connection when PAWS is required
> makes
>>   good sense to me.
>>=20
>> So, I am voting for an RFC 1323bis that calls for negotiating
>> timestamps only when they are needed.  And, if some new use needs to
> do
>> so at the beginning of the connection and use them throughout then we
>> should absolutely not preclude that.
>>=20
>> allman
>>=20
>>=20
>=20


From ananth@cisco.com  Sun Apr  1 17:47:22 2012
Return-Path: <ananth@cisco.com>
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 B703921F86D4 for <tcpm@ietfa.amsl.com>; Sun,  1 Apr 2012 17:47:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXPBwYT4o+bi for <tcpm@ietfa.amsl.com>; Sun,  1 Apr 2012 17:47:22 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id E6B9F21F86D1 for <tcpm@ietf.org>; Sun,  1 Apr 2012 17:47:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=4502; q=dns/txt; s=iport; t=1333327641; x=1334537241; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=tt+1zcnaEZjMQ20kVs5eOSaMSt3hkoai8018nQr747w=; b=G5bZJ47r58KlFtUCys5VLVrj5AK0HOghtc8IF9zDcrThUBO86Bpw5xOm R7l4bG4Z0biHnk1tOgoy/4998xT4/JaPYs3jY1dqhI6OPYYJD8LHK3+Zm VmyK74tmonxGUEP8Uf7VtEJRFScIcgwXUd65DCBRJyVJa8dUgydEwjkUY w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAO71eE+rRDoH/2dsb2JhbABDuQqBB4IJAQEBBBIBHQo/DAQCAQgRBAEBCwYXAQYBRQkIAgQTCBMHh2YBoBuWGZA5YwSIWJtQgWiDB4E0BxA
X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208";a="35495535"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 02 Apr 2012 00:47:21 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q320lLfZ028125; Mon, 2 Apr 2012 00:47:21 GMT
Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Sun, 1 Apr 2012 17:47:21 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 1 Apr 2012 17:47:20 -0700
Message-ID: <1F8E0A684D3FF54680294BCFE57A7DB504C928C0@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <25995122-D162-44B5-859C-AB89133C111C@netapp.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] A new ID on TCP option space extension. 
Thread-Index: AQHND6zi+FLNXvh+KUCdkIbbd2jp65aGV8AAgABbtQA=
References: <012C3117EDDB3C4781FD802A8C27DD4F13C4D1@SACEXCMBX02-PRD.hq.netapp.com> <20120331140258.3AADC109F66B@lawyers.icir.org> <1F8E0A684D3FF54680294BCFE57A7DB504C9287B@xmb-sjc-23e.amer.cisco.com> <25995122-D162-44B5-859C-AB89133C111C@netapp.com>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Scheffenegger, Richard" <rs@netapp.com>
X-OriginalArrivalTime: 02 Apr 2012 00:47:21.0261 (UTC) FILETIME=[298285D0:01CD106A]
Cc: David Borman <dab@weston.borman.com>, tcpm@ietf.org, mallman@icir.org
Subject: Re: [tcpm] A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 00:47:22 -0000

Agreed. All I was trying to say is that when we are planning to change,
we could always cover the solution from all angles as much as possible.
Of course, there are these middleboxes (firewalls) which can come in the
way of delayed negotiation.

-Anantha

> -----Original Message-----
> From: Scheffenegger, Richard [mailto:rs@netapp.com]
> Sent: Sunday, April 01, 2012 12:38 PM
> To: Anantha Ramaiah (ananth)
> Cc: mallman@icir.org; David Borman; tcpm@ietf.org
> Subject: Re: [tcpm] A new ID on TCP option space extension.
>=20
> Hi Anantha
>=20
> I beliefe delayed negotiation for timestamps would be comparatively
> easy, compared to dynamically disabling it at some time later during
> the session. I have the stromg suspicion that some stack may already
do
> this - but most likely due to a buggy 1323 implementation more than
> anything... At least when i did some tests for my ts nego draft, some
> stacks reacted like that when temporarily disabling ts. But in my
> tests,  ts were negotiated for during syn.
>=20
> Properly disabling ts will be an order of magnitude more involved i
> guess.
>=20
> But just delaying ts nego would free precious syn option space, which
> has become increasingly important.
>=20
> Best regards,
>   Richard
>=20
>=20
>=20
>=20
> Am 01.04.2012 um 04:12 schrieb "Anantha Ramaiah (ananth)"
> <ananth@cisco.com>:
>=20
> > <just got back to SFO. Catching up...>
> >
> > RTTM has been touted to be the main use for timestamps which
includes
> > solution to the Karn's ambiguity problem. The other one is PAWS and
> > w.r.t I agree it is wastage of TCP option bytes and the idea of
> > turning on PAWS detection dynamically (using timestamps) makes sense
> to me.
> > Changing the timestamp semantics means change to many TCP/IP stacks
> > (variables like ts_val, ts_recent would not be interpreted as
before,
> > all other debugging tools etc., may need to understand this change)
> >
> > Even if we are planning to do so, I thought you meant to negotiate
> the
> > capability during SYN (don't send the timestamp value) and send
> > timestamps when needed. Or are we saying that we are trying to
> > negotiate the option when needed, this sounds like a bigger change
in
> > semantics since every TCP option is only negotiated during SYN as it
> stands today.
> > To make this more useful, you would want to not only turn on this
> > capability when needed, also turn off when not needed.
> >
> > Didn't we already have a RFC 1323bis document? Is that expired or
did
> > it make it to the RFC 1323 update ? If not, you could always fold
> this
> > idea (assuming there is a consensus) into that document. Not sure
> > whether we would want multiple RFC 1323bis documents...
> >
> > Just my 2 cents..
> >
> > -Anantha
> >
> >> -----Original Message-----
> >> From: mallman@icir.org [mailto:mallman@icir.org]
> >> Sent: Saturday, March 31, 2012 7:03 AM
> >> To: Scheffenegger, Richard
> >> Cc: David Borman; tcpm@ietf.org; Anantha Ramaiah (ananth)
> >> Subject: Re: [tcpm] A new ID on TCP option space extension.
> >>
> >>
> >>> Actually, allowing for delay-based congestion algorithms like
> > LEDBET,
> >>> CTCP may be a stronger use case for timestamps.
> >>
> >> That is absolutely fine.  I am not saying we should rid the world
of
> >> timestamps.  I am saying that we should re-arrange the world such
> >> that TCP connections do not have to use timestamps because they
> >> *might*
> > need
> >> them later.  If there is some good reason to use them from the
onset
> > of
> >> the connection, great, use them.  But,
> >>
> >> - If RTTM is the reason to use the TS option then I haven't seen
the
> >>   empirical evidence that says this is at all helpful and so I am
> >>   pretty dubious.
> >>
> >> - If PAWS is the reason to use the TS option then I don't see why
> >> we'd
> >>   waste the bytes on the TS option for connections that send less
> >> than
> >>   4GB (i.e., that will not wrap the sequence space).  So, being
able
> >>   to turn on the TS option mid-connection when PAWS is required
> > makes
> >>   good sense to me.
> >>
> >> So, I am voting for an RFC 1323bis that calls for negotiating
> >> timestamps only when they are needed.  And, if some new use needs
to
> > do
> >> so at the beginning of the connection and use them throughout then
> we
> >> should absolutely not preclude that.
> >>
> >> allman
> >>
> >>
> >


From mallman@icir.org  Sun Apr  1 18:53:06 2012
Return-Path: <mallman@icir.org>
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 8201621F8743 for <tcpm@ietfa.amsl.com>; Sun,  1 Apr 2012 18:53:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eh0z-GblGn23 for <tcpm@ietfa.amsl.com>; Sun,  1 Apr 2012 18:53:06 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAC121F8653 for <tcpm@ietf.org>; Sun,  1 Apr 2012 18:53:06 -0700 (PDT)
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 q321r3rD008546; Sun, 1 Apr 2012 18:53:03 -0700 (PDT)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id F3AF110B3990; Sun,  1 Apr 2012 21:53:06 -0400 (EDT)
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <1F8E0A684D3FF54680294BCFE57A7DB504C9287B@xmb-sjc-23e.amer.cisco.com>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Blue on Black
X-URL-0: http://www.icir.org/mallman-files/Document97461.jpg
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma1666-1"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Sun, 01 Apr 2012 21:53:06 -0400
Sender: mallman@icir.org
Message-Id: <20120402015306.F3AF110B3990@lawyers.icir.org>
Cc: David Borman <dab@weston.borman.com>, tcpm@ietf.org
Subject: Re: [tcpm] A new ID on TCP option space extension.
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 <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 01:53:06 -0000

----------ma1666-1
Content-Type: text/plain
Content-Disposition: inline


> To make this more useful, you would want to not only turn on this
> capability when needed, also turn off when not needed.

I am with Richard in thinking turning it off is a lot more complicated
than turning it on.

Can you sketch why this would be more useful?

allman




----------ma1666-1
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iEYEARECAAYFAk95BoIACgkQWyrrWs4yIs4P+ACcCpRgK2UsHQjG58m8rhBPD23K
ExcAn3c1xheOocFh5xq1ZelU7Tb/JrZd
=EJa4
-----END PGP SIGNATURE-----
----------ma1666-1--

From ananth@cisco.com  Sun Apr  1 19:17:40 2012
Return-Path: <ananth@cisco.com>
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 D4EAC11E80AA for <tcpm@ietfa.amsl.com>; Sun,  1 Apr 2012 19:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPsVni5SOoUZ for <tcpm@ietfa.amsl.com>; Sun,  1 Apr 2012 19:17:40 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4205F11E8085 for <tcpm@ietf.org>; Sun,  1 Apr 2012 19:17:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=2032; q=dns/txt; s=iport; t=1333333060; x=1334542660; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Y6QlDI7k/QVegt0FcAs10yhwCOTcY3xoqvA69PO8+Ew=; b=eEqCGJ5d8ZfXACrkN/sJPCX3p/K4n5IGBLdmNE5l//lwPbxUn1n5rwK/ y0QymrmvKJ6cBfZDAVmwC4krP9iH2ojeRaIdQSPu2xhkLHtALzjrurr4j 4XokaGCe+aAatlCs4FpwL2ZATIpI77AjoUWYtrZEg2H2Utek1F/lB1cvF M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EANsLeU+rRDoG/2dsb2JhbABEuHyBB4IJAQEBBBIBHQo/DAQCAQgRBAEBCwYXAQYBRQkIAQEEEwgah2YBm1+dfo14gkFjBIhYm1CBaIMHgTQH
X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208";a="38616769"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 02 Apr 2012 02:17:40 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q322HeVG019674; Mon, 2 Apr 2012 02:17:40 GMT
Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Sun, 1 Apr 2012 19:17:39 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 1 Apr 2012 19:17:38 -0700
Message-ID: <1F8E0A684D3FF54680294BCFE57A7DB504C928D4@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <20120402015306.F3AF110B3990@lawyers.icir.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] A new ID on TCP option space extension. 
Thread-Index: Ac0Qc1kDQjw/aGqeTSugK+AoXYyrvwAACcTQ
References: <1F8E0A684D3FF54680294BCFE57A7DB504C9287B@xmb-sjc-23e.amer.cisco.com> <20120402015306.F3AF110B3990@lawyers.icir.org>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: <mallman@icir.org>
X-OriginalArrivalTime: 02 Apr 2012 02:17:39.0661 (UTC) FILETIME=[C720BFD0:01CD1076]
Cc: David Borman <dab@weston.borman.com>, tcpm@ietf.org
Subject: Re: [tcpm] A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 02:17:40 -0000

Hi Mark,

> -----Original Message-----
> From: mallman@icir.org [mailto:mallman@icir.org]
> Sent: Sunday, April 01, 2012 6:53 PM
> To: Anantha Ramaiah (ananth)
> Cc: Scheffenegger, Richard; David Borman; tcpm@ietf.org
> Subject: Re: [tcpm] A new ID on TCP option space extension.
>=20
>=20
> > To make this more useful, you would want to not only turn on this
> > capability when needed, also turn off when not needed.
>=20
> I am with Richard in thinking turning it off is a lot more complicated
> than turning it on.
>=20
> Can you sketch why this would be more useful?

A clarification :  What I meant is that you can turn it on, but sending
timestamps option every TCP packet (segment) is optional.  I was
thinking along the following lines.

a) during 3 way handshake we could just negotiate the option itself.
This is going to be a new TCP option (if we do not want to change the
semantics of the original TCP option and get caught with the sanity
checking of firewalls + the difficulty of reliably negotiating the
option in the midway of a TCP connection) This would be an option-kind
(just like SACK permitted) so 2 bytes.
=20
b) whenever needed send timestamps during the lifetime of the TCP
connection.=20

c) the catch is whether you want to use the *same* option kind which
would imply that the timestamps option would be a variable length option
either 2 bytes or 10 bytes. Or else have another option just like SACK
option to send the timestamp values, but this would mean that you cannot
send timestamp value during SYN using the same option code.

IMO, this would be a cleaner approach than negotiating the TCP option
during the midway of the connection, which is a change in semantics for
TCP option and it may not go well with middleboxes etc., Stacks can also
migrate to using the newer timestamp option eventually and eventually
deprecate the old timestamp option.

I hope it makes sense or did I miss something here?

Thanks,
-Anantha
>=20
> allman
>=20
>=20


From mallman@icir.org  Sun Apr  1 19:31:52 2012
Return-Path: <mallman@icir.org>
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 62FEA11E80AA for <tcpm@ietfa.amsl.com>; Sun,  1 Apr 2012 19:31:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLUi+Ox4qp1J for <tcpm@ietfa.amsl.com>; Sun,  1 Apr 2012 19:31:51 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4382921F866A for <tcpm@ietf.org>; Sun,  1 Apr 2012 19:31:44 -0700 (PDT)
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 q322VfvO011452; Sun, 1 Apr 2012 19:31:42 -0700 (PDT)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 40E8C10B4A12; Sun,  1 Apr 2012 22:31:45 -0400 (EDT)
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <1F8E0A684D3FF54680294BCFE57A7DB504C928D4@xmb-sjc-23e.amer.cisco.com>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Blue on Black
X-URL-0: http://www.icir.org/mallman-files/Document22648.doc
X-URL-1: http://www.icir.org/mallman-files/Document1537.xlsx
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma3984-1"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Sun, 01 Apr 2012 22:31:45 -0400
Sender: mallman@icir.org
Message-Id: <20120402023145.40E8C10B4A12@lawyers.icir.org>
Cc: David Borman <dab@weston.borman.com>, tcpm@ietf.org
Subject: Re: [tcpm] A new ID on TCP option space extension.
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 <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 02:31:52 -0000

----------ma3984-1
Content-Type: text/plain
Content-Disposition: inline


> IMO, this would be a cleaner approach than negotiating the TCP option
> during the midway of the connection, which is a change in semantics
> for TCP option and it may not go well with middleboxes etc., Stacks
> can also migrate to using the newer timestamp option eventually and
> eventually deprecate the old timestamp option.

I liked David's sketch of how to negotiate when you wanted to start
using timestamps and not in the 3WHS.  That made pretty good sense to me
and I bet has a very high value of Just Works.  I don't see defining a
whole new timestamp option with dramatically different properties just
to change a single property (i.e., when to start using them).

OKing options in the SYN is---IMHO---just historic artifact.  I am sure
someone can remind us of the machine that crashed or caught fire or
something when an unknown option was received after the 3WHS.  This was
bad and made us then go an negotiate everything in the 3WHS.  But, I am
not aware of this being a hazard we should worry about in 2012.

And, defined and undefined options after the 3WHS that are not
negotiated during the 3WHS worked in a large fraction of the cases for
us when we studied it a while back.  So, this doesn't worry me too much.
It is also a comment that at the time middleboxes just ignored unknown
options in the middle of connections (see out CCR 2005 paper;
http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps).  I guess who knows
if that has changed.  My gut wonders why it would have---i.e., why would
middleboxes much care?  Clearly there are middleboxes that care about
the sequence space and so options like SACK get munged.  But, since this
isn't a sequence space option I am not hugely worried about this case.
It'd be nice to see some more recent data.

allman




----------ma3984-1
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iEYEARECAAYFAk95D5EACgkQWyrrWs4yIs4eXgCfRL4LoKWVkpzVYrdTAZ8fxaVf
xssAnRAevAppHvgxQ+BWMDYZR+5T3MO3
=4tHm
-----END PGP SIGNATURE-----
----------ma3984-1--

From ananth@cisco.com  Sun Apr  1 21:49:21 2012
Return-Path: <ananth@cisco.com>
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 0B92921F86C5 for <tcpm@ietfa.amsl.com>; Sun,  1 Apr 2012 21:49:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAfA5J10ZlLm for <tcpm@ietfa.amsl.com>; Sun,  1 Apr 2012 21:49:19 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5898E21F86C3 for <tcpm@ietf.org>; Sun,  1 Apr 2012 21:49:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=3077; q=dns/txt; s=iport; t=1333342159; x=1334551759; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=E9OZSTfK0kYqQUjDmz3alky6VsjnI+ro/THShG3L3w8=; b=LgYJWFNu8IyuXSRhmQWoKBB8YXMUV3CSWYZvi5Cernv36pVC99ApikAk s1Zx22NmsxVRDrI+H4R1PYvhS1F2Prt43bqduJbU+ixb1j3KN8JgjSm+/ hB99JLOMKKl9BwTmy+OQoSV8UP57ArcfSn6qEkBajF4Zocz1ob+zcbFmT g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAAYveU+rRDoH/2dsb2JhbABEuH6BB4IJAQEBBBIBHQo/DAQCAQgRBAEBCwYXAQYBRQkIAQEEEwgah2YBm1yeEY14gkFjBIhYm1CBaIMH
X-IronPort-AV: E=Sophos;i="4.75,355,1330905600"; d="scan'208";a="38631381"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 02 Apr 2012 04:49:13 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q324nCme023288; Mon, 2 Apr 2012 04:49:12 GMT
Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Sun, 1 Apr 2012 21:49:11 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 1 Apr 2012 21:49:10 -0700
Message-ID: <1F8E0A684D3FF54680294BCFE57A7DB504C928EA@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <20120402023145.40E8C10B4A12@lawyers.icir.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] A new ID on TCP option space extension. 
Thread-Index: Ac0QeL8k/0VrROqEQ1SVz2ho5dyGcgADjdYg
References: <1F8E0A684D3FF54680294BCFE57A7DB504C928D4@xmb-sjc-23e.amer.cisco.com> <20120402023145.40E8C10B4A12@lawyers.icir.org>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: <mallman@icir.org>
X-OriginalArrivalTime: 02 Apr 2012 04:49:11.0904 (UTC) FILETIME=[F286EE00:01CD108B]
Cc: David Borman <dab@weston.borman.com>, tcpm@ietf.org
Subject: Re: [tcpm] A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 04:49:21 -0000

> -----Original Message-----
> From: mallman@icir.org [mailto:mallman@icir.org]
> Sent: Sunday, April 01, 2012 7:32 PM
> To: Anantha Ramaiah (ananth)
> Cc: Scheffenegger, Richard; David Borman; tcpm@ietf.org
> Subject: Re: [tcpm] A new ID on TCP option space extension.
>=20
>=20
> > IMO, this would be a cleaner approach than negotiating the TCP
option
> > during the midway of the connection, which is a change in semantics
> > for TCP option and it may not go well with middleboxes etc., Stacks
> > can also migrate to using the newer timestamp option eventually and
> > eventually deprecate the old timestamp option.
>=20
> I liked David's sketch of how to negotiate when you wanted to start
> using timestamps and not in the 3WHS.  That made pretty good sense to
> me and I bet has a very high value of Just Works.  I don't see
defining
> a whole new timestamp option with dramatically different properties
> just to change a single property (i.e., when to start using them).

Ok, maybe having a new TCP option for this purpose is height of
paranoia. RFC 1323 is very common and implementations have followed the
wordings of RFC verbatim esp, the place where it says :-

      We must pay careful attention to compatibility, i.e., to
      interoperation with existing implementations.  The only TCP option
      defined previously, MSS, may appear only on a SYN segment.  Every
      implementation should (and we expect that most will) ignore
      unknown options on SYN segments.  However, some buggy TCP
      implementation might be crashed by the first appearance of an
      option on a non-SYN segment.  Therefore, for each of the
      extensions defined below, TCP options will be sent on non-SYN
      segments only when an exchange of options on the SYN segments has
      indicated that both sides understand the extension.  Furthermore,
      an extension option will be sent in a <SYN,ACK> segment only if
      the corresponding option was received in the initial <SYN>
      segment.

So, some over zealous firewalls, would interpret this to mean an attack
(since it would crash the end system, if it is buggy) may strip this
option OR would drop the packet. Sorry if I am sounding like
hand-waving, we should get some recent data as you say below. [I am also
planning to check our firewall implementations and get back...]

In any case, that should not prevent one from writing an ID which
updates RFC 1323. I fully support it for obvious reasons :-) I have 2
questions :-

- Are we only going to target timestamps Or make it generic looking to
say other TCP options can also be negotiated mid-way? Or are we going to
say that only timestamp would be an exception? For example I would think
negotiating a window scale in the middle of the TCP connection may be
complicated.

- I asked this before. There was already a rfc 1323 bis document before.
If we are only going to focus on timestamps, then why not revive that
document?. Not sure why that document did not make through.

-Anantha

From rs@netapp.com  Mon Apr  2 02:38:14 2012
Return-Path: <rs@netapp.com>
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 0352721F889E for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 02:38:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.555
X-Spam-Level: 
X-Spam-Status: No, score=-9.555 tagged_above=-999 required=5 tests=[AWL=0.445,  BAYES_00=-2.599, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYK95FN4GSpk for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 02:38:12 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9A78E21F889F for <tcpm@ietf.org>; Mon,  2 Apr 2012 02:38:12 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,355,1330934400"; d="scan'208";a="637926508"
Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 02 Apr 2012 02:38:12 -0700
Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q329cCNK017056; Mon, 2 Apr 2012 02:38:12 -0700 (PDT)
Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.76]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0247.003; Mon, 2 Apr 2012 02:38:02 -0700
From: "Scheffenegger, Richard" <rs@netapp.com>
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>, "mallman@icir.org" <mallman@icir.org>
Thread-Topic: [tcpm] A new ID on TCP option space extension. 
Thread-Index: AQHNEHi++FLNXvh+KUCdkIbbd2jp65aHbEoA///VNPA=
Date: Mon, 2 Apr 2012 09:38:02 +0000
Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F14DEDD@SACEXCMBX02-PRD.hq.netapp.com>
References: <1F8E0A684D3FF54680294BCFE57A7DB504C928D4@xmb-sjc-23e.amer.cisco.com> <20120402023145.40E8C10B4A12@lawyers.icir.org> <1F8E0A684D3FF54680294BCFE57A7DB504C928EA@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <1F8E0A684D3FF54680294BCFE57A7DB504C928EA@xmb-sjc-23e.amer.cisco.com>
Accept-Language: de-AT, 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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: David Borman <dab@weston.borman.com>, "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 09:38:14 -0000

Anantha,

There are a bunch of mid-stream, temporary options for MP-TCP; Actually, I'=
m more concerned because TS are not a "unknown" option for middleboxes, but=
 middleboxes may have code to interpret these (check the semantics etc).

During the MP-TCP option testing, late negotiation of TS was obviously not =
tested.

On the other hand, any implementation that wants to go with late TS negotia=
tion must be prepared that Timestamps may not be negotiated / reflected the=
n - and treat this in a graceful way. If the reason for late TS negotiation=
 failing is the other TCP end not supporting it, or any random middlebox re=
moving the option because of RFC1323 semantic checks, doesn't make any diff=
erence.

The only thing that we really should verify is, if there are middleboxes th=
at will actually terminate a TCP session, when all of a sudden the TS optio=
n appears... I hope this won't be the case, but it needs to be verified.

So, if you can verify the firewall code and it's interactions, that would b=
e a very good starting point, thanks a lot!

For a 1323bis, I think we should limit this late negotiation to timestamps =
for now; other options are really beneficial from the start (SACK, MPTCP,MS=
S), while stil others would require some definition of new semantics if lat=
e negotiation would be used (WS).


I have been asked to look at 1323bis and try to revive it - currently in th=
e process of updating the formatting, references and boilerplate to the cur=
rent standard;=20

This is a short list of the issues that were raised during RFC1323bis discu=
ssions (and that I was able to dig up; if anyone has more info, please let =
me know):

* Window reduction during recovery bug - Matt
* RTO adjustments (no need to use every sample, one update per RTT enough) =
- Mark
* Enabling TS (PAWS) midstream - David, Matt, and others
* PAWS and non-DF segments (incorrectly reassembled packets, not captured b=
y TCP checksum) [?]
* References / interaction with SACK (TS check does not look if SACK is pre=
sent - to cover certain cased of lost ACKs that inflate RTO) [?]
* Updating TS.recent - Kacheon Poon

However, it appears that the majority of these points is already addressed =
in the last 1323bis draft. Perhaps some more explicit text is needed there =
though (i.e. the use of the maximum seen Rcv.Window when sending retransmis=
sions instead of the current advertised Rcv.Window; currently there is only=
 a pointer to RFC1122 and as an implementer, extrapolating the last sentenc=
e from there is not necessarily intuitive).
 =20
Best regards,

Richard Scheffenegger

> -----Original Message-----
> From: Anantha Ramaiah (ananth) [mailto:ananth@cisco.com]
> Sent: Montag, 02. April 2012 06:49
> To: mallman@icir.org
> Cc: Scheffenegger, Richard; David Borman; tcpm@ietf.org
> Subject: RE: [tcpm] A new ID on TCP option space extension.
>=20
>=20
>=20
> > -----Original Message-----
> > From: mallman@icir.org [mailto:mallman@icir.org]
> > Sent: Sunday, April 01, 2012 7:32 PM
> > To: Anantha Ramaiah (ananth)
> > Cc: Scheffenegger, Richard; David Borman; tcpm@ietf.org
> > Subject: Re: [tcpm] A new ID on TCP option space extension.
> >
> >
> > > IMO, this would be a cleaner approach than negotiating the TCP
> option
> > > during the midway of the connection, which is a change in semantics
> > > for TCP option and it may not go well with middleboxes etc., Stacks
> > > can also migrate to using the newer timestamp option eventually and
> > > eventually deprecate the old timestamp option.
> >
> > I liked David's sketch of how to negotiate when you wanted to start
> > using timestamps and not in the 3WHS.  That made pretty good sense to
> > me and I bet has a very high value of Just Works.  I don't see
> defining
> > a whole new timestamp option with dramatically different properties
> > just to change a single property (i.e., when to start using them).
>=20
> Ok, maybe having a new TCP option for this purpose is height of paranoia.
> RFC 1323 is very common and implementations have followed the wordings
> of RFC verbatim esp, the place where it says :-
>=20
>       We must pay careful attention to compatibility, i.e., to
>       interoperation with existing implementations.  The only TCP option
>       defined previously, MSS, may appear only on a SYN segment.  Every
>       implementation should (and we expect that most will) ignore
>       unknown options on SYN segments.  However, some buggy TCP
>       implementation might be crashed by the first appearance of an
>       option on a non-SYN segment.  Therefore, for each of the
>       extensions defined below, TCP options will be sent on non-SYN
>       segments only when an exchange of options on the SYN segments has
>       indicated that both sides understand the extension.  Furthermore,
>       an extension option will be sent in a <SYN,ACK> segment only if
>       the corresponding option was received in the initial <SYN>
>       segment.
>=20
> So, some over zealous firewalls, would interpret this to mean an attack (=
since
> it would crash the end system, if it is buggy) may strip this option OR w=
ould
> drop the packet. Sorry if I am sounding like hand-waving, we should get
> some recent data as you say below. [I am also planning to check our firew=
all
> implementations and get back...]
>=20
> In any case, that should not prevent one from writing an ID which updates
> RFC 1323. I fully support it for obvious reasons :-) I have 2 questions :=
-
>=20
> - Are we only going to target timestamps Or make it generic looking to sa=
y
> other TCP options can also be negotiated mid-way? Or are we going to say
> that only timestamp would be an exception? For example I would think
> negotiating a window scale in the middle of the TCP connection may be
> complicated.
>=20
> - I asked this before. There was already a rfc 1323 bis document before.
> If we are only going to focus on timestamps, then why not revive that
> document?. Not sure why that document did not make through.
>=20
> -Anantha

From bob.briscoe@bt.com  Mon Apr  2 08:06:23 2012
Return-Path: <bob.briscoe@bt.com>
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 8701721F84C9 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 08:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZuQWH4P-fCC for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 08:06:19 -0700 (PDT)
Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 0641F21F85B6 for <tcpm@ietf.org>; Mon,  2 Apr 2012 08:06:16 -0700 (PDT)
Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 2 Apr 2012 16:06:11 +0100
Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 2 Apr 2012 16:06:10 +0100
Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.247.3; Mon, 2 Apr 2012 16:06:03 +0100
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1333379177464; Mon, 2 Apr 2012 16:06:17 +0100
Received: from MUT.jungle.bt.co.uk ([10.215.130.204])	by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q32F61vO029953; Mon, 2 Apr 2012 16:06:01 +0100
Message-ID: <201204021506.q32F61vO029953@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 2 Apr 2012 16:05:51 +0100
To: <mallman@icir.org>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <20120330142840.209BF1054DD8@lawyers.icir.org>
References: <201203301322.q2UDMIcc009352@bagheera.jungle.bt.co.uk> <20120330142840.209BF1054DD8@lawyers.icir.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] IW10 & queuebloat
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 15:06:23 -0000

Mark,

1/ There may be some missing context for those not at the Paris tcpm meeting...

Just because I mentioned the two things in the same email, I didn't 
mean I want IW10 to stall on the outcome of the experiment I would 
like to see. I merely sent my email to correct a remark from Jerry 
(in Paris) that seems to have been said in haste (after the chairs 
moved discussion to the list).

2/ That said, I do want to correct a perception that I chose DCTCP 
because it's *my* notion of what the future Internet will be like. 
DCTCP is in the Windows 8 Server Edition Beta. Therefore it is 
reasonable to assume that DCTCP could be a major part of the future 
mix of TCP response algorithms, even though (for now) Microsoft has 
arranged DCTCP to only enable itself in sub-20ms RTT environments 
where the OS is also configured with a "data-center" template.

More generally, we do have some responsibility to check whether 
combinations of new approaches will be counterproductive.


3/ Increasing IW a little should improve performance. Increasing IW 
too much would worsen performance on average. This is not an exact 
science, it all depends which environments we consider to be the ones 
we care about. The idea of developments like DCTCP is to leave plenty 
of spare buffer to absorb bursts, so that we are less sensitive to 
the chosen value of IW. But we don't want IW to grow so much 
(ultimately) that it just negates any hard-won benefit we might one 
day see, if we can find a way to widely deploy advances like 
DCTCP  on the public Internet.



Bob

At 15:28 30/03/2012, Mark Allman wrote:

>With all due respect Bob,
>
>Bob:
> > > I would like to see experiments with IW10 in a simulation
> > > modelling how the Internet is likely to be in future (with more
> > > DCTCP-like protocols and shallower AQM) rather than just how the
> > > Internet is now. I'm not saying whether IW10 is good or bad for
> > > "queuebloat", because I haven't done such experiments.
>
>More Bob:
> > I'd love to see the people who are making the proposal pay for the
> > research ;)
>
>Surely the bar for getting something standardized these days is not
>assessing how a proposal measures up to someone's notion of "how the
>Internet is likely to be in [the] future".
>
>Put another way, I don't think you'd appreciate this bar being applied
>to your proposals and my volumous notions about the future Internet,
>would you?  (Hint: I am *full* of (ahem) "vision".)
>
>Silliness.
>
>
>Dear TCPM chairs, Can we please WGLC IW10?  We have been talking about
>it for eons.  There is much empirical / simulation / testbed assessment
>of it.  The pros and cons have been discussed to death.  Everyone will
>never agree with it.  But, lets put a stake in the ground and see where
>we're at WRT WG consensus.  If we have consensus then lets move it.  If
>we don't have consensus then lets table it.  It is time.
>
>allman
>
>
>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design  


From bob.briscoe@bt.com  Mon Apr  2 08:24:28 2012
Return-Path: <bob.briscoe@bt.com>
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 E424C21F8532 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 08:24:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Level: 
X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.800,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YduoWWDKpp8j for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 08:24:28 -0700 (PDT)
Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id EEF0721F8531 for <tcpm@ietf.org>; Mon,  2 Apr 2012 08:24:27 -0700 (PDT)
Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 2 Apr 2012 16:24:26 +0100
Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 2 Apr 2012 16:24:25 +0100
Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.247.3; Mon, 2 Apr 2012 16:24:24 +0100
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1333380279146; Mon, 2 Apr 2012 16:24:39 +0100
Received: from MUT.jungle.bt.co.uk ([10.215.130.204])	by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q32FOLQG030023; Mon, 2 Apr 2012 16:24:21 +0100
Message-ID: <201204021524.q32FOLQG030023@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 2 Apr 2012 16:24:23 +0100
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <1F8E0A684D3FF54680294BCFE57A7DB504C9245F@xmb-sjc-23e.amer. cisco.com>
References: <1F8E0A684D3FF54680294BCFE57A7DB504C9245F@xmb-sjc-23e.amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Initial Window units.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 15:24:29 -0000

Anantha,

I agree bytes are a more appropriate unit to specify the likely 
constraint than packets. Ie. IW=14600B.

No-one will ever guess we made up that number; it looks really quite 
scientific.

Even tho the IW comes after a 3WHS, when the PMTU will have been 
discovered, I still think bytes are a more appropriate unit. Anyway 
with TCP Fast Open (TFO) the 3WHS could have occurred on a path with 
a different PMTU.



Bob

At 12:02 30/03/2012, Anantha Ramaiah (ananth) wrote:
>Content-Class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01CD0E64.9F29AC5F"
>
>Hi,
>     I had brought this question to Jerry offline.  TCP communicates 
> receive window in bytes (sliding window is based on bytes) So, it 
> would be useful to have the initial window as bytes. Oh, yeah the 
> "bytes versus packet" argument again J Is that an issue? Maybe not 
> but with larger IW's it probably would..
>
>     Consider the case of IW=10, and the stack doesn't do PMTU, then 
> we end up putting more segments on the network, in case of 
> fragmentation in the path). Even with PMTU,  PMTU convergence takes 
> time and it can complicate things.  Would it be useful to list this 
> relationship and recommend a lesser IW if the MSS > 1500?  In such 
> cases the # of bytes would be useful metric.  Another point in 
> favor of this thought would be that Jerry mentioned that anything 
> above than IW=10 wasn't that useful for many web objects.. so 
> having  IW in bytes versus packets seems useful.  Basically I am 
> nervous about the high watermark (cap) of IW in packets, would 
> think it is safer if bytes were used instead.
>
>-Anantha
>_______________________________________________
>tcpm mailing list
>tcpm@ietf.org
>https://www.ietf.org/mailman/listinfo/tcpm

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design 


From michael.scharf@alcatel-lucent.com  Mon Apr  2 09:32:42 2012
Return-Path: <michael.scharf@alcatel-lucent.com>
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 ED8E021F859F for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 09:32:42 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZVy9PBVVGza for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 09:32:42 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id C349F21F857F for <tcpm@ietf.org>; Mon,  2 Apr 2012 09:32:28 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q32GWOa4025691 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Apr 2012 18:32:24 +0200
Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 2 Apr 2012 18:32:23 +0200
From: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
To: Bob Briscoe <bob.briscoe@bt.com>, "Anantha Ramaiah (ananth)" <ananth@cisco.com>
Date: Mon, 2 Apr 2012 18:32:22 +0200
Thread-Topic: [tcpm] Initial Window units.
Thread-Index: Ac0Q5Lkx+BglF5XGQOWSEusIsOr+xAACPGXw
Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E88EF75842F@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>
References: <1F8E0A684D3FF54680294BCFE57A7DB504C9245F@xmb-sjc-23e.amer.cisco.com> <201204021524.q32FOLQG030023@bagheera.jungle.bt.co.uk>
In-Reply-To: <201204021524.q32FOLQG030023@bagheera.jungle.bt.co.uk>
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" <tcpm@ietf.org>
Subject: Re: [tcpm] Initial Window units.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 16:32:43 -0000

Bob, Anantha,

draft-ietf-tcpm-initcwnd-03 recommends the following threshold (in bytes):

min (10*MSS, max (2*MSS, 14600))=20
=20
Do you suggest to change this? If so, how?

Michael


> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20
> Behalf Of Bob Briscoe
> Sent: Monday, April 02, 2012 5:24 PM
> To: Anantha Ramaiah (ananth)
> Cc: tcpm@ietf.org
> Subject: Re: [tcpm] Initial Window units.
>=20
> Anantha,
>=20
> I agree bytes are a more appropriate unit to specify the=20
> likely constraint than packets. Ie. IW=3D14600B.
>=20
> No-one will ever guess we made up that number; it looks=20
> really quite scientific.
>=20
> Even tho the IW comes after a 3WHS, when the PMTU will have=20
> been discovered, I still think bytes are a more appropriate=20
> unit. Anyway with TCP Fast Open (TFO) the 3WHS could have=20
> occurred on a path with a different PMTU.
>=20
>=20
>=20
> Bob
>=20
> At 12:02 30/03/2012, Anantha Ramaiah (ananth) wrote:
> >Content-Class: urn:content-classes:message
> >Content-Type: multipart/alternative;
> >         boundary=3D"----_=3D_NextPart_001_01CD0E64.9F29AC5F"
> >
> >Hi,
> >     I had brought this question to Jerry offline.  TCP=20
> communicates =20
> >receive window in bytes (sliding window is based on bytes) So, it =20
> >would be useful to have the initial window as bytes. Oh, yeah the =20
> >"bytes versus packet" argument again J Is that an issue?=20
> Maybe not  but=20
> >with larger IW's it probably would..
> >
> >     Consider the case of IW=3D10, and the stack doesn't do=20
> PMTU, then we=20
> > end up putting more segments on the network, in case of=20
> fragmentation=20
> > in the path). Even with PMTU,  PMTU convergence takes time=20
> and it can=20
> > complicate things.  Would it be useful to list this=20
> relationship and=20
> > recommend a lesser IW if the MSS > 1500?  In such cases the=20
> # of bytes=20
> > would be useful metric.  Another point in favor of this=20
> thought would=20
> > be that Jerry mentioned that anything above than IW=3D10 wasn't that=20
> > useful for many web objects.. so having  IW in bytes versus packets=20
> > seems useful.  Basically I am nervous about the high=20
> watermark (cap)=20
> > of IW in packets, would think it is safer if bytes were=20
> used instead.
> >
> >-Anantha
> >_______________________________________________
> >tcpm mailing list
> >tcpm@ietf.org
> >https://www.ietf.org/mailman/listinfo/tcpm
>=20
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design=20
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
> =

From andre@freebsd.org  Mon Apr  2 09:58:38 2012
Return-Path: <andre@freebsd.org>
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 C5BE721F865F for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 09:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwQGZlbgC2YN for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 09:58:38 -0700 (PDT)
Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by ietfa.amsl.com (Postfix) with ESMTP id 82F3721F865D for <tcpm@ietf.org>; Mon,  2 Apr 2012 09:58:37 -0700 (PDT)
Received: (qmail 79494 invoked from network); 2 Apr 2012 16:57:03 -0000
Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender <andre@freebsd.org>) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for <bob.briscoe@bt.com>; 2 Apr 2012 16:57:03 -0000
Message-ID: <4F79DABB.7040609@freebsd.org>
Date: Mon, 02 Apr 2012 18:58:35 +0200
From: Andre Oppermann <andre@freebsd.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Bob Briscoe <bob.briscoe@bt.com>
References: <1F8E0A684D3FF54680294BCFE57A7DB504C9245F@xmb-sjc-23e.amer.cisco.com> <201204021524.q32FOLQG030023@bagheera.jungle.bt.co.uk>
In-Reply-To: <201204021524.q32FOLQG030023@bagheera.jungle.bt.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>
Subject: Re: [tcpm] Initial Window units.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 16:58:38 -0000

On 02.04.2012 17:24, Bob Briscoe wrote:
> Anantha,
>
> I agree bytes are a more appropriate unit to specify the likely constraint than packets. Ie. IW=14600B.
>
> No-one will ever guess we made up that number; it looks really quite scientific.
>
> Even tho the IW comes after a 3WHS, when the PMTU will have been discovered, I still think bytes are
> a more appropriate unit. Anyway with TCP Fast Open (TFO) the 3WHS could have occurred on a path with
> a different PMTU.

The 3WHS doesn't truly discover the PMTU.  Only the first full sized
packet would do that.  In reality most devices that are in front of
a link that reduces the MTU employ MSS fixup's for transiting SYN's.
Which in turn breaks TCP-AO if it is deployed beyond link local.

-- 
Andre

From andre@freebsd.org  Mon Apr  2 10:16:53 2012
Return-Path: <andre@freebsd.org>
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 E45A421F8565 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 10:16:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_26=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tz9XSpD4-bSH for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 10:16:53 -0700 (PDT)
Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by ietfa.amsl.com (Postfix) with ESMTP id E3EF121F8549 for <tcpm@ietf.org>; Mon,  2 Apr 2012 10:16:52 -0700 (PDT)
Received: (qmail 79639 invoked from network); 2 Apr 2012 17:15:18 -0000
Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender <andre@freebsd.org>) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for <rs@netapp.com>; 2 Apr 2012 17:15:18 -0000
Message-ID: <4F79DF02.5080606@freebsd.org>
Date: Mon, 02 Apr 2012 19:16:50 +0200
From: Andre Oppermann <andre@freebsd.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Scheffenegger, Richard" <rs@netapp.com>
References: <1F8E0A684D3FF54680294BCFE57A7DB504C928D4@xmb-sjc-23e.amer.cisco.com> <20120402023145.40E8C10B4A12@lawyers.icir.org> <1F8E0A684D3FF54680294BCFE57A7DB504C928EA@xmb-sjc-23e.amer.cisco.com> <012C3117EDDB3C4781FD802A8C27DD4F14DEDD@SACEXCMBX02-PRD.hq.netapp.com>
In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F14DEDD@SACEXCMBX02-PRD.hq.netapp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: David Borman <dab@weston.borman.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, "mallman@icir.org" <mallman@icir.org>
Subject: Re: [tcpm] A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 17:16:54 -0000

On 02.04.2012 11:38, Scheffenegger, Richard wrote:
>
> Anantha,
>
> There are a bunch of mid-stream, temporary options for MP-TCP; Actually, I'm more concerned
> because TS are not a "unknown" option for middleboxes, but middleboxes may have code to interpret
> these (check the semantics etc).
>
> During the MP-TCP option testing, late negotiation of TS was obviously not tested.
>
> On the other hand, any implementation that wants to go with late TS negotiation must be prepared
> that Timestamps may not be negotiated / reflected then - and treat this in a graceful way. If the
> reason for late TS negotiation failing is the other TCP end not supporting it, or any random
> middlebox removing the option because of RFC1323 semantic checks, doesn't make any difference.
>
> The only thing that we really should verify is, if there are middleboxes that will actually
> terminate a TCP session, when all of a sudden the TS option appears... I hope this won't be the
> case, but it needs to be verified.

It's really difficult to change the behavior of a system that was very
clearly spelled out 20 years ago.  It's too ingrained everywhere, too
many (rightful) assumptions have been made and any change will just
open a new can of worms.

> So, if you can verify the firewall code and it's interactions, that would be a very good starting
> point, thanks a lot!

We're even having trouble with ordering of options.  Don't walk into
the fragile lands of obscure errors.

> For a 1323bis, I think we should limit this late negotiation to timestamps for now; other options
> are really beneficial from the start (SACK, MPTCP,MSS), while stil others would require some
> definition of new semantics if late negotiation would be used (WS).

I strongly recommend against changing RFC1323 timestamps in any way.
Make it new options but leave the current behavior as it is.

> I have been asked to look at 1323bis and try to revive it - currently in the process of updating
> the formatting, references and boilerplate to the current standard;
>
> This is a short list of the issues that were raised during RFC1323bis discussions (and that I was
> able to dig up; if anyone has more info, please let me know):
>
> * Window reduction during recovery bug - Matt

?

 > * RTO adjustments (no need to use every sample, on update per RTT enough) - Mark

Agreed as MAY.

> * Enabling TS (PAWS) midstream - David, Matt, and others

Disagreed due to interop issues.  The current behavior is engraved in
stone in 20 years worth of implementations of any kind.  We have enough
trouble keeping TCP fully interoperable as it is.  Don't add yet another
fuzzy failure case.  Even worse that connections may suddenly fail mid-
transfer without anyone knowing why (because firefall gets tripped up).

And don't forget that timestamps add some entropy to the already limited
32^2 sequence space.

> * PAWS and non-DF segments (incorrectly reassembled packets, not captured by TCP checksum) [?]

Shit happens... What can you do short of TCP-AO?

 > * References / interaction with SACK (TS check does not look if SACK is
 > present - to cover certain cased of lost ACKs that inflate RTO) [?]

The presence of SACK removes ambiguity from timestamps and also from
the somewhat brittle window update logic (see my long post from some
two years ago).

 > * Updating TS.recent - Kacheon Poon

Updating TS.recent with SACK would be nice.

> However, it appears that the majority of these points is already addressed in the last 1323bis
> draft. Perhaps some more explicit text is needed there though (i.e. the use of the maximum seen
> Rcv.Window when sending retransmissions instead of the current advertised Rcv.Window; currently
> there is only a pointer to RFC1122 and as an implementer, extrapolating the last sentence from
> there is not necessarily intuitive).

-- 
Andre

From bob.briscoe@bt.com  Mon Apr  2 10:21:20 2012
Return-Path: <bob.briscoe@bt.com>
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 E089821F8518 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 10:21:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.199
X-Spam-Level: 
X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.400,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzwJWxjU4PWG for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 10:21:20 -0700 (PDT)
Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9B60F21F84D3 for <tcpm@ietf.org>; Mon,  2 Apr 2012 10:21:19 -0700 (PDT)
Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 2 Apr 2012 18:21:14 +0100
Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 2 Apr 2012 18:21:16 +0100
Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.247.3; Mon, 2 Apr 2012 18:21:08 +0100
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1333387283433; Mon, 2 Apr 2012 18:21:23 +0100
Received: from MUT.jungle.bt.co.uk ([10.215.130.204])	by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q32HL63G030413; Mon, 2 Apr 2012 18:21:07 +0100
Message-ID: <201204021721.q32HL63G030413@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 2 Apr 2012 18:16:13 +0100
To: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E88EF75842F@FRMRSSXCHMBSE3. dc-m.alcatel-lucent.com>
References: <1F8E0A684D3FF54680294BCFE57A7DB504C9245F@xmb-sjc-23e.amer.cisco.com> <201204021524.q32FOLQG030023@bagheera.jungle.bt.co.uk> <2A886F9088894347A3BE0CC5B7A85F3E88EF75842F@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>
Subject: Re: [tcpm] Initial Window units.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 17:21:21 -0000

Michael,

That's good.

Sorry - we were reacting to the abbreviation 'IW10' rather than 
checking the draft. Slap wrists. Won't do it again.


Bob

At 17:32 02/04/2012, Scharf, Michael (Michael) wrote:
>Bob, Anantha,
>
>draft-ietf-tcpm-initcwnd-03 recommends the following threshold (in bytes):
>
>min (10*MSS, max (2*MSS, 14600))
>
>Do you suggest to change this? If so, how?
>
>Michael
>
>
> > -----Original Message-----
> > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On
> > Behalf Of Bob Briscoe
> > Sent: Monday, April 02, 2012 5:24 PM
> > To: Anantha Ramaiah (ananth)
> > Cc: tcpm@ietf.org
> > Subject: Re: [tcpm] Initial Window units.
> >
> > Anantha,
> >
> > I agree bytes are a more appropriate unit to specify the
> > likely constraint than packets. Ie. IW=14600B.
> >
> > No-one will ever guess we made up that number; it looks
> > really quite scientific.
> >
> > Even tho the IW comes after a 3WHS, when the PMTU will have
> > been discovered, I still think bytes are a more appropriate
> > unit. Anyway with TCP Fast Open (TFO) the 3WHS could have
> > occurred on a path with a different PMTU.
> >
> >
> >
> > Bob
> >
> > At 12:02 30/03/2012, Anantha Ramaiah (ananth) wrote:
> > >Content-Class: urn:content-classes:message
> > >Content-Type: multipart/alternative;
> > >         boundary="----_=_NextPart_001_01CD0E64.9F29AC5F"
> > >
> > >Hi,
> > >     I had brought this question to Jerry offline.  TCP
> > communicates
> > >receive window in bytes (sliding window is based on bytes) So, it
> > >would be useful to have the initial window as bytes. Oh, yeah the
> > >"bytes versus packet" argument again J Is that an issue?
> > Maybe not  but
> > >with larger IW's it probably would..
> > >
> > >     Consider the case of IW=10, and the stack doesn't do
> > PMTU, then we
> > > end up putting more segments on the network, in case of
> > fragmentation
> > > in the path). Even with PMTU,  PMTU convergence takes time
> > and it can
> > > complicate things.  Would it be useful to list this
> > relationship and
> > > recommend a lesser IW if the MSS > 1500?  In such cases the
> > # of bytes
> > > would be useful metric.  Another point in favor of this
> > thought would
> > > be that Jerry mentioned that anything above than IW=10 wasn't that
> > > useful for many web objects.. so having  IW in bytes versus packets
> > > seems useful.  Basically I am nervous about the high
> > watermark (cap)
> > > of IW in packets, would think it is safer if bytes were
> > used instead.
> > >
> > >-Anantha
> > >_______________________________________________
> > >tcpm mailing list
> > >tcpm@ietf.org
> > >https://www.ietf.org/mailman/listinfo/tcpm
> >
> > ________________________________________________________________
> > Bob Briscoe,                                BT Innovate & Design
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
> >

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design 


From andre@freebsd.org  Mon Apr  2 11:20:05 2012
Return-Path: <andre@freebsd.org>
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 560DD21F8653 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 11:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.185
X-Spam-Level: 
X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXeKwic8LjE3 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 11:20:05 -0700 (PDT)
Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8B81421F8638 for <tcpm@ietf.org>; Mon,  2 Apr 2012 11:20:04 -0700 (PDT)
Received: (qmail 79948 invoked from network); 2 Apr 2012 18:18:30 -0000
Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender <andre@freebsd.org>) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for <tcpm@ietf.org>; 2 Apr 2012 18:18:30 -0000
Message-ID: <4F79EDD3.9020509@freebsd.org>
Date: Mon, 02 Apr 2012 20:20:03 +0200
From: Andre Oppermann <andre@freebsd.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: tcpm@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [tcpm] A reminder to standards writers
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 18:20:05 -0000

I want to send a reminder to standard writers like we are here on TCPM.

Recently I've seen a cavalier approach in that clarity and simplicity
gets lost in clever engineering and sophistication, not to speak of
redefining long standing and established behavior of certain aspects
of standards.

(To be) widely deployed standards have keep in mind:

1. Standards are write once, but read and implement many many times.
    Both many thousand to hundred-thousand times.  It may be become
    part of a university course curriculum.

    Some of the readers and implementers even have poor English knowledge,
    easily trip over unclear wording and end up with something slightly
    different than what was intended.

2. Standards must be clear and concise and avoid any ambiguities to
    facilitate painless interoperability.

    Interoperability doesn't converge on plug-fests, it should be obvious
    from reading the standard.  "USL" (use the source, Luke) is not an
    option.  Neither is "do it like large vendor X does".

3. When a standard was specified in a particular way, stick to it.
    Update asap but only to clarify ambiguities and to ensure interop.

4. Ideally publish a generally available test suite testing for positive
    and negative specifications of the standard.

Thank you for your cooperation.

-- 
Andre

From ananth@cisco.com  Mon Apr  2 11:27:04 2012
Return-Path: <ananth@cisco.com>
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 D3A0E21F8653 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 11:27:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIRKZqBLQoid for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 11:27:04 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0A91721F86B5 for <tcpm@ietf.org>; Mon,  2 Apr 2012 11:27:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=4619; q=dns/txt; s=iport; t=1333391224; x=1334600824; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=QE8W/uxLJ2EVs9aSyf9AFWSgDkdIL2SyNNpyQkFceRM=; b=ehfAaTC9KkM68v6S9eQSnA0aQA/ThdpxS4BOgIWUp0zYWij6mxFyvM09 UH7wFCjNI+8utHdNuWrsVI0+7hlW3fSh7zotJV+uhNj9oy1th9XffbK6j WHMfqU5KgTaC9oqtb+y42ZLplwleIVPGTp8eSTM7fhy4i5vOwwdfFAWrZ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAFLueU+rRDoI/2dsb2JhbABDuAiBB4IJAQEBBAEBAQ8BHQo0BAcMBAIBCBEEAQEBCgYXAQYBJh8JCAEBBBMIFgSHZgELn36XIwSQC2MEiFibUIFogwc
X-IronPort-AV: E=Sophos;i="4.75,358,1330905600"; d="scan'208";a="38722651"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 02 Apr 2012 18:27:03 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q32IR36u030659; Mon, 2 Apr 2012 18:27:03 GMT
Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 2 Apr 2012 11:27:03 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 2 Apr 2012 11:27:02 -0700
Message-ID: <1F8E0A684D3FF54680294BCFE57A7DB504C92AFA@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <201204021721.q32HL63G030413@bagheera.jungle.bt.co.uk>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] Initial Window units.
Thread-Index: Ac0Q9Qh75f/O2hkHTSu/hTklxorMuAAA6uUw
References: <1F8E0A684D3FF54680294BCFE57A7DB504C9245F@xmb-sjc-23e.amer.cisco.com><201204021524.q32FOLQG030023@bagheera.jungle.bt.co.uk><2A886F9088894347A3BE0CC5B7A85F3E88EF75842F@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <201204021721.q32HL63G030413@bagheera.jungle.bt.co.uk>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Bob Briscoe" <bob.briscoe@bt.com>, "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
X-OriginalArrivalTime: 02 Apr 2012 18:27:03.0548 (UTC) FILETIME=[338193C0:01CD10FE]
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Initial Window units.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 18:27:04 -0000

Michael,
    The value looks fine. I guess more clarification can be added.. I
see that the section titled "TCP motivation" is similar in wordings to
RFC 3390 (same section) However in RFC 3390, it is more clearer, it
doesn't only give the formula but also says something  like :-

"Equivalently, the upper bound for the initial window size is based on
   the MSS, as follows:

       If (MSS <=3D 1095 bytes)
           then win <=3D 4 * MSS;
       If (1095 bytes < MSS < 2190 bytes)
           then win <=3D 4380;
       If (2190 bytes <=3D MSS)
           then win <=3D 2 * MSS;"

something of this sort would be useful, here as well.=20

(You could use the MTU plateau values defined in RFC 1191, but that may
be outdated)

-Anantha

  =20


> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf
Of
> Bob Briscoe
> Sent: Monday, April 02, 2012 10:16 AM
> To: Scharf, Michael (Michael)
> Cc: tcpm@ietf.org; Anantha Ramaiah (ananth)
> Subject: Re: [tcpm] Initial Window units.
>=20
> Michael,
>=20
> That's good.
>=20
> Sorry - we were reacting to the abbreviation 'IW10' rather than
> checking the draft. Slap wrists. Won't do it again.
>=20
>=20
> Bob
>=20
> At 17:32 02/04/2012, Scharf, Michael (Michael) wrote:
> >Bob, Anantha,
> >
> >draft-ietf-tcpm-initcwnd-03 recommends the following threshold (in
> bytes):
> >
> >min (10*MSS, max (2*MSS, 14600))
> >
> >Do you suggest to change this? If so, how?
> >
> >Michael
> >
> >
> > > -----Original Message-----
> > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On
> > > Behalf Of Bob Briscoe
> > > Sent: Monday, April 02, 2012 5:24 PM
> > > To: Anantha Ramaiah (ananth)
> > > Cc: tcpm@ietf.org
> > > Subject: Re: [tcpm] Initial Window units.
> > >
> > > Anantha,
> > >
> > > I agree bytes are a more appropriate unit to specify the
> > > likely constraint than packets. Ie. IW=3D14600B.
> > >
> > > No-one will ever guess we made up that number; it looks
> > > really quite scientific.
> > >
> > > Even tho the IW comes after a 3WHS, when the PMTU will have
> > > been discovered, I still think bytes are a more appropriate
> > > unit. Anyway with TCP Fast Open (TFO) the 3WHS could have
> > > occurred on a path with a different PMTU.
> > >
> > >
> > >
> > > Bob
> > >
> > > At 12:02 30/03/2012, Anantha Ramaiah (ananth) wrote:
> > > >Content-Class: urn:content-classes:message
> > > >Content-Type: multipart/alternative;
> > > >         boundary=3D"----_=3D_NextPart_001_01CD0E64.9F29AC5F"
> > > >
> > > >Hi,
> > > >     I had brought this question to Jerry offline.  TCP
> > > communicates
> > > >receive window in bytes (sliding window is based on bytes) So, it
> > > >would be useful to have the initial window as bytes. Oh, yeah the
> > > >"bytes versus packet" argument again J Is that an issue?
> > > Maybe not  but
> > > >with larger IW's it probably would..
> > > >
> > > >     Consider the case of IW=3D10, and the stack doesn't do
> > > PMTU, then we
> > > > end up putting more segments on the network, in case of
> > > fragmentation
> > > > in the path). Even with PMTU,  PMTU convergence takes time
> > > and it can
> > > > complicate things.  Would it be useful to list this
> > > relationship and
> > > > recommend a lesser IW if the MSS > 1500?  In such cases the
> > > # of bytes
> > > > would be useful metric.  Another point in favor of this
> > > thought would
> > > > be that Jerry mentioned that anything above than IW=3D10 wasn't
> that
> > > > useful for many web objects.. so having  IW in bytes versus
> packets
> > > > seems useful.  Basically I am nervous about the high
> > > watermark (cap)
> > > > of IW in packets, would think it is safer if bytes were
> > > used instead.
> > > >
> > > >-Anantha
> > > >_______________________________________________
> > > >tcpm mailing list
> > > >tcpm@ietf.org
> > > >https://www.ietf.org/mailman/listinfo/tcpm
> > >
> > > ________________________________________________________________
> > > Bob Briscoe,                                BT Innovate & Design
> > >
> > > _______________________________________________
> > > tcpm mailing list
> > > tcpm@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tcpm
> > >
>=20
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

From touch@isi.edu  Mon Apr  2 11:44:24 2012
Return-Path: <touch@isi.edu>
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 AC82021F8659 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 11:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnzmL1BwQY1g for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 11:44:24 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id F013021F8656 for <tcpm@ietf.org>; Mon,  2 Apr 2012 11:44:23 -0700 (PDT)
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 q32IhXiQ023971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Apr 2012 11:43:33 -0700 (PDT)
Message-ID: <4F79F355.2020000@isi.edu>
Date: Mon, 02 Apr 2012 11:43:33 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Yuchung Cheng <ycheng@google.com>
References: <201203301322.q2UDMIcc009352@bagheera.jungle.bt.co.uk> <20120330142840.209BF1054DD8@lawyers.icir.org> <CAK6E8=d=gLDtG6REXXG2TWdSxMOCfeZX-40hjj7THcVVCM+Xuw@mail.gmail.com>
In-Reply-To: <CAK6E8=d=gLDtG6REXXG2TWdSxMOCfeZX-40hjj7THcVVCM+Xuw@mail.gmail.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 list <tcpm@ietf.org>, mallman@icir.org
Subject: Re: [tcpm] IW10 & queuebloat
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 18:44:24 -0000

On 3/30/2012 10:41 AM, Yuchung Cheng wrote:
...
> A gentle reminder the intended status is experimental which calls for more
> experiments like what Bob and others are suggesting.

 From the TAO of the IETF:

---
Experimental RFCs are for specifications that may be interesting, but 
for which it is unclear if there will be much interest in implementing 
them, or whether they will work once deployed. That is, a specification 
might solve a problem, but if it is not clear that many people think 
that the problem is important, or think that they will bother fixing the 
problem with the specification, the specification might be labeled an 
Experimental RFC. If, later, the specification becomes popular (or 
proves that it works well), it can be re-issued as a standards-track 
RFC. Experimental RFCs are also used to get people to experiment with a 
technology that looks like it might be standards-track material, but for 
which there are still unanswered questions.
---

AFAICT, this proposal isn't experimental at all if the point is to 
deploy it as default in widely-used systems on the Internet.

IMO, experimental RFCs ought to require an explanation of the experiment 
expected. It's disingenuous (at best) and misleading to call IW10 
"experimental".

Joe

From ycheng@google.com  Mon Apr  2 12:03:54 2012
Return-Path: <ycheng@google.com>
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 798E521F8682 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 12:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYSw62-M6bJ6 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 12:03:53 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C501C21F857D for <tcpm@ietf.org>; Mon,  2 Apr 2012 12:03:53 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so2315655obb.31 for <tcpm@ietf.org>; Mon, 02 Apr 2012 12:03:53 -0700 (PDT)
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-system-of-record; bh=GnXaozDPWxNS8kw4EsYRcAR/tNiY00ERGZyHIUzKrNE=; b=dGP9URZtLyrE0VttI5fmoQUKIegQCFm3K3C8wxAszDiASIpjoZgS2q9cW/yG4+8G0A snKaexRo2Klx0+FDlip6K8geQiKBDmUIq4cpa6f7ogsMcOrcWstTQC5cssSye8hsADyv OnG7JKkj4Z1uEI+LgBpGfHPvRM3t0lj6qaEQ+irKxAAxxfWXrVhe/gO1AEA7RRQIedZn uOPpGWhE7YP4zzuf+5cdYmc1N8o8VKaSuHaVv1tNUHDj+miktPCyYYP5uTbQKkdj+u49 /N25iU2iUVS9eONIYjrKaVADR1E+/CPQqwjNhGfllmZGk/YmH6ckSYf2KCcHqqsHiNi+ OyTw==
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-system-of-record:x-gm-message-state; bh=GnXaozDPWxNS8kw4EsYRcAR/tNiY00ERGZyHIUzKrNE=; b=mv1vhvHd7MKJp3WrnOwZd7cndEUJX2nIlWBITauwI69KQ2r1kEbrqE1res+vIfXG5l GQ4MNBDM0490Wyad2DumaQhe5YKppX6nhOaosgOuqbasBn5m7mhjrgVaoiQm96cjx2CB PHtw2NhP/UieVTh3x6iDzGurDfQPUhMnRVwN8fla4fZmlFbKx+zxrgQAbv2EzSAinzs2 hAyiUZjQtlN5Yr7BZ7SoLU39FoeXd0w9IhnTlEBJ+exbsqxkUUYuWBR7QcpMSdPbZ757 r4tgT5jcM1Cl/EuuEx48mc3JFoGEyv59UbOyjKgR+HSAmnKWYo/JXMk0Yj0rjfM4Z5sP bHqw==
Received: by 10.182.119.101 with SMTP id kt5mr14339157obb.70.1333393433464; Mon, 02 Apr 2012 12:03:53 -0700 (PDT)
Received: by 10.182.119.101 with SMTP id kt5mr14339142obb.70.1333393433367; Mon, 02 Apr 2012 12:03:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.74.233 with HTTP; Mon, 2 Apr 2012 12:03:31 -0700 (PDT)
In-Reply-To: <4F79F355.2020000@isi.edu>
References: <201203301322.q2UDMIcc009352@bagheera.jungle.bt.co.uk> <20120330142840.209BF1054DD8@lawyers.icir.org> <CAK6E8=d=gLDtG6REXXG2TWdSxMOCfeZX-40hjj7THcVVCM+Xuw@mail.gmail.com> <4F79F355.2020000@isi.edu>
From: Yuchung Cheng <ycheng@google.com>
Date: Mon, 2 Apr 2012 12:03:31 -0700
Message-ID: <CAK6E8=eVmy+_=74E5y3dNJWDvvmtJMZ+vh6tSkXgL+_hC54+Qw@mail.gmail.com>
To: Joe Touch <touch@isi.edu>
Content-Type: text/plain; charset=ISO-8859-1
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQnGi/mvjoXkpgd4Hl1qHQHACQfCZF4yeYZwVYjdLM17qtVxm2sgfwysbqfdZdKvVK5K3niaNnVaXq01YL4iY+GCY1npZWBGLhuAd5ZLSdFiv0lMEmxxEHM7FhgU1qebwf72CQfY
Cc: tcpm IETF list <tcpm@ietf.org>, mallman@icir.org
Subject: Re: [tcpm] IW10 & queuebloat
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 19:03:54 -0000

On Mon, Apr 2, 2012 at 11:43 AM, Joe Touch <touch@isi.edu> wrote:
>
>
> On 3/30/2012 10:41 AM, Yuchung Cheng wrote:
> ...
>
>> A gentle reminder the intended status is experimental which calls for more
>> experiments like what Bob and others are suggesting.
>
>
> From the TAO of the IETF:
>
> ---
> Experimental RFCs are for specifications that may be interesting, but for
> which it is unclear if there will be much interest in implementing them, or
> whether they will work once deployed. That is, a specification might solve a
> problem, but if it is not clear that many people think that the problem is
> important, or think that they will bother fixing the problem with the
> specification, the specification might be labeled an Experimental RFC. If,
> later, the specification becomes popular (or proves that it works well), it
> can be re-issued as a standards-track RFC. Experimental RFCs are also used
> to get people to experiment with a technology that looks like it might be
> standards-track material, but for which there are still unanswered
> questions.
> ---
>
> AFAICT, this proposal isn't experimental at all if the point is to deploy it
> as default in widely-used systems on the Internet.

which part in our draft talks the point you mentioned? we'll be happy
to correct it.

"""
2.  TCP Modification

   This document proposes an increase in the permitted upper bound for
   TCP's initial window (IW) to 10 segments depending on the MSS. This
   increase is optional: a TCP MAY start with an initial window that is
   smaller than 10 segments.

   More precisely, the upper bound for the initial window will be

         min (10*MSS, max (2*MSS, 14600))                            (1)
"""

"""
12. Usage and Deployment Recommendations

   Further experiments are required before a larger initial window shall
   be enabled by default in the Internet. The existing measurement
   results indicate that this does not cause significant harm to other
   traffic. However, widespread use in the Internet could reveal issues
   not known yet, e.g., regarding fairness or impact on latency-
   sensitive traffic such as VoIP.
"""


>
> IMO, experimental RFCs ought to require an explanation of the experiment
> expected. It's disingenuous (at best) and misleading to call IW10
> "experimental".
We didn't get to determine the status, the WG did.

From pasi.sarolahti@iki.fi  Mon Apr  2 12:12:08 2012
Return-Path: <pasi.sarolahti@iki.fi>
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 3C05821F870F for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 12:12:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpiP0dA34lds for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 12:12:07 -0700 (PDT)
Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by ietfa.amsl.com (Postfix) with ESMTP id 86DA321F86E4 for <tcpm@ietf.org>; Mon,  2 Apr 2012 12:11:50 -0700 (PDT)
Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id q32JBnGH012093 for <tcpm@ietf.org>; Mon, 2 Apr 2012 22:11:49 +0300
Received: from smtp-2.hut.fi ([130.233.228.92]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 25431-1183 for <tcpm@ietf.org>; Mon,  2 Apr 2012 22:11:48 +0300 (EEST)
Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id q32JBjW0012088 for <tcpm@ietf.org>; Mon, 2 Apr 2012 22:11:46 +0300
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id DA6BC1E172 for <tcpm@ietf.org>; Mon,  2 Apr 2012 22:11:45 +0300 (EEST)
X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi
Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pIadmYXQHJTL for <tcpm@ietf.org>; Mon,  2 Apr 2012 22:11:41 +0300 (EEST)
Received: from [192.168.1.65] (dsl-hkibrasgw4-fe5cdf00-46.dhcp.inet.fi [80.223.92.46]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id C1FC61E155 for <tcpm@ietf.org>; Mon,  2 Apr 2012 22:11:41 +0300 (EEST)
From: Pasi Sarolahti <pasi.sarolahti@iki.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 2 Apr 2012 22:11:45 +0300
Message-Id: <A9F4FF22-BD84-48BB-B638-917EDE14F7FF@iki.fi>
To: tcpm@ietf.org
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi
Subject: [tcpm] Draft minutes of the TCPM meeting at IETF-83
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 19:12:08 -0000

Hi,

Draft minutes of the TCPM meeting are available at =
http://www.ietf.org/proceedings/83/minutes/minutes-83-tcpm.txt . Please =
send corrections to the chairs or to mailing list.

Many thanks to Michael and Richard for the impressive work on collecting =
the notes!

- Pasi


From touch@isi.edu  Mon Apr  2 12:55:21 2012
Return-Path: <touch@isi.edu>
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 E0E7521F8723 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 12:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.599
X-Spam-Level: 
X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ux3V++I3vBKU for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 12:55:19 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC8621F8724 for <tcpm@ietf.org>; Mon,  2 Apr 2012 12:55:19 -0700 (PDT)
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 q32JslmY014196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Apr 2012 12:54:47 -0700 (PDT)
Message-ID: <4F7A0407.8090105@isi.edu>
Date: Mon, 02 Apr 2012 12:54:47 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Yuchung Cheng <ycheng@google.com>
References: <201203301322.q2UDMIcc009352@bagheera.jungle.bt.co.uk> <20120330142840.209BF1054DD8@lawyers.icir.org> <CAK6E8=d=gLDtG6REXXG2TWdSxMOCfeZX-40hjj7THcVVCM+Xuw@mail.gmail.com> <4F79F355.2020000@isi.edu> <CAK6E8=eVmy+_=74E5y3dNJWDvvmtJMZ+vh6tSkXgL+_hC54+Qw@mail.gmail.com>
In-Reply-To: <CAK6E8=eVmy+_=74E5y3dNJWDvvmtJMZ+vh6tSkXgL+_hC54+Qw@mail.gmail.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 list <tcpm@ietf.org>, mallman@icir.org
Subject: Re: [tcpm] IW10 & queuebloat
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 19:55:22 -0000

On 4/2/2012 12:03 PM, Yuchung Cheng wrote:
> On Mon, Apr 2, 2012 at 11:43 AM, Joe Touch<touch@isi.edu>  wrote:
>>
>>
>> On 3/30/2012 10:41 AM, Yuchung Cheng wrote:
>> ...
>>
>>> A gentle reminder the intended status is experimental which calls for more
>>> experiments like what Bob and others are suggesting.
>>
>>
>>  From the TAO of the IETF:
>>
>> ---
>> Experimental RFCs are for specifications that may be interesting, but for
>> which it is unclear if there will be much interest in implementing them, or
>> whether they will work once deployed. That is, a specification might solve a
>> problem, but if it is not clear that many people think that the problem is
>> important, or think that they will bother fixing the problem with the
>> specification, the specification might be labeled an Experimental RFC. If,
>> later, the specification becomes popular (or proves that it works well), it
>> can be re-issued as a standards-track RFC. Experimental RFCs are also used
>> to get people to experiment with a technology that looks like it might be
>> standards-track material, but for which there are still unanswered
>> questions.
>> ---
>>
>> AFAICT, this proposal isn't experimental at all if the point is to deploy it
>> as default in widely-used systems on the Internet.
>
> which part in our draft talks the point you mentioned? we'll be happy
> to correct it.
>
> """
> 2.  TCP Modification
>
>     This document proposes an increase in the permitted upper bound for
>     TCP's initial window (IW) to 10 segments depending on the MSS. This
>     increase is optional: a TCP MAY start with an initial window that is
>     smaller than 10 segments.
>
>     More precisely, the upper bound for the initial window will be
>
>           min (10*MSS, max (2*MSS, 14600))                            (1)
> """
>
> """
> 12. Usage and Deployment Recommendations
>
>     Further experiments are required before a larger initial window shall
>     be enabled by default in the Internet. The existing measurement
>     results indicate that this does not cause significant harm to other
>     traffic. However, widespread use in the Internet could reveal issues
>     not known yet, e.g., regarding fairness or impact on latency-
>     sensitive traffic such as VoIP.
> """

This is inconsistent with the following, from the Intro:

    We recommend that all TCP implementations have a settable TCP IW
    parameter. As of 2011 an appropriate value for this parameter is 10
    segments as long as there is a reasonable effort to monitor for
    possible interactions with other Internet applications and services.
    Furthermore, it is understood that the appropriate value for IW is
    likely to continue to rise in the future, but this document does not
    include any supporting evidence for larger values of IW.


>> IMO, experimental RFCs ought to require an explanation of the experiment
>> expected. It's disingenuous (at best) and misleading to call IW10
>> "experimental".
 >
> We didn't get to determine the status, the WG did.

Agreed, but it's now your responsibility to ensure that the doc reflects 
that status.

Joe

From touch@isi.edu  Mon Apr  2 13:11:08 2012
Return-Path: <touch@isi.edu>
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 DEB6021F871E for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 13:11:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.599
X-Spam-Level: 
X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uwpI2PUayPe for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 13:11:08 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 465F221F8599 for <tcpm@ietf.org>; Mon,  2 Apr 2012 13:11:08 -0700 (PDT)
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 q32KAfYZ007976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Apr 2012 13:10:41 -0700 (PDT)
Message-ID: <4F7A07C1.2060701@isi.edu>
Date: Mon, 02 Apr 2012 13:10:41 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Brandon Williams <brandon.williams@akamai.com>
References: <4F747B99.9030701@akamai.com> <4F74BD64.20903@isi.edu> <4F74D2FB.7060109@akamai.com> <4F74E00B.5060006@akamai.com>
In-Reply-To: <4F74E00B.5060006@akamai.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] draft-williams-overlaypath-ip-tcp-rfc-00
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 20:11:09 -0000

Hi, Brandon,

Thanks for the quick turn on this issue.

Typically, the IANA Considerations section would list the specific 
assignments in detail and provide enough information for IANA to assign 
values:

E.g., for IPv4, to list the Class and Copied flags, etc.

...AND for the RFC-Editor to be able to update the text accordingly.

E.g., use TBD-IP4, TBD-IP6, TBD-TCP rather than just "TBD" in locations 
where each is referred to by value.

So that section could use some expansion, but that can happen as the doc 
is updated. The removal of proposed values was more critical, and thanks 
for doing that quickly.

Joe

On 3/29/2012 3:19 PM, Brandon Williams wrote:
> I have submitted a revised version of the draft which no longer
> inappropriately refers to specific option numbers that have not been
> assigned by IANA. Please let me know if the revision does not meet your
> expectations for clarity in this regard.
>
> Thank you,
> --Brandon
>
>
> A new version of I-D, draft-williams-overlaypath-ip-tcp-rfc-01.txt has
> been successfully submitted by Brandon Williams and posted to the IETF
> repository.
>
> Filename: draft-williams-overlaypath-ip-tcp-rfc
> Revision: 01
> Title: Overlay Path Option for IP and TCP
> Creation date: 2012-03-29
> WG ID: Individual Submission
> Number of pages: 15
>
> Abstract:
> Data transport through overlay networks often uses either connection
> termination or network address translation (NAT) in such a way that
> the public IP addresses of the true endpoint machines involved in the
> data transport are invisible to each other. This document describes
> IPv4, IPv6, and TCP options for communicating this information from
> the overlay network to the endpoint machines.
>
> On 03/29/2012 05:24 PM, Brandon Williams wrote:
>> Thank you for taking the time to look the document over and for noting
>> this shortcoming. You are absolutely right that the document should not
>> have been published with any reference to unassigned numbers. I should
>> have realized that this would be unacceptable.
>>
>> I will make that change and publish a version 01 ASAP in order to
>> facilitate further discussion.
>>
>> --Brandon
>>
>> On 03/29/2012 03:52 PM, Joe Touch wrote:
>>> This doc needs to be updated immediately, and references to numbers not
>>> assigned by IANA replaced with TBDs. Notably IP option 218, TCP option
>>> 30, etc. are NOT assigned by IANA.
>>>
>>> There is no such thing as "provisional pending IANA approval"; this
>>> document establishes squatting, period.
>>>
>>> This document should be revised before being further discussed.
>>>
>>> Joe
>>>
>>>
>>> On 3/29/2012 8:11 AM, Brandon Williams wrote:
>>>> An Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>>
>>>> Title : Overlay Path Option for IP and TCP
>>>> Author : Brandon Williams
>>>> Filename : draft-williams-overlaypath-ip-tcp-rfc-00.txt
>>>> Pages : 15
>>>> Date : 2012-01-17
>>>>
>>>> This document proposes IPv4, IPv6, and TCP options for
>>>> communicating the true IP address of a TCP connection endpoint
>>>> to its peer when that address is hidden due to the use of NAT on
>>>> an overlay network.
>>>>
>>>> A URL for this Internet-Draft is:
>>>> http://www.ietf.org/id/draft-williams-overlaypath-ip-tcp-rfc-00.txt
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> This Internet-Draft can be retrieved at:
>>>> http://www.ietf.org/id/draft-williams-overlaypath-ip-tcp-rfc-00.txt
>>>>
>>
>

From rs@netapp.com  Mon Apr  2 13:41:13 2012
Return-Path: <rs@netapp.com>
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 85B4A21F8732 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 13:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.253
X-Spam-Level: 
X-Spam-Status: No, score=-9.253 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAfC+wSV2FP4 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 13:41:12 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3A75921F86FA for <tcpm@ietf.org>; Mon,  2 Apr 2012 13:41:12 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,358,1330934400"; d="scan'208";a="638072799"
Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 02 Apr 2012 13:41:06 -0700
Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q32Kf5rm024376; Mon, 2 Apr 2012 13:41:05 -0700 (PDT)
Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.76]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0247.003; Mon, 2 Apr 2012 13:40:56 -0700
From: "Scheffenegger, Richard" <rs@netapp.com>
To: Andre Oppermann <andre@freebsd.org>
Thread-Topic: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
Thread-Index: Ac0RCoq8TplyYNdFQxSPsKEZcZ7hMQ==
Date: Mon, 2 Apr 2012 20:40:55 +0000
Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F1533DE@SACEXCMBX02-PRD.hq.netapp.com>
Accept-Language: de-AT, 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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: David Borman <dab@weston.borman.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, "mallman@icir.org" <mallman@icir.org>
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 20:41:13 -0000

Hi Andre,

nice to hear from you!

See inline

Richard Scheffenegger

>> The only thing that we really should verify is, if there are middleboxes=
=20
>> that will actually terminate a TCP session, when all of a sudden the=20
>> TS option appears... I hope this won't be the case, but it needs to be v=
erified.
>=20
> It's really difficult to change the behavior of a system that was very
> clearly spelled out 20 years ago.  It's too ingrained everywhere, too
> many (rightful) assumptions have been made and any change will just
> open a new can of worms.

I think Joe rightfully said some time back, that we shouldn't limit ourselv=
es by trying to work around implementation bugs in some stacks. The issue a=
bout the TCP SYN option space getting really scarce really fast now won't g=
o away when we don't try to address this.


>> For a 1323bis, I think we should limit this late negotiation to=20
>> timestamps for now; other options are really beneficial from=20
>> the start (SACK, MPTCP,MSS), while stil others would require=20
>> some definition of new semantics if late negotiation would=20
>> be used (WS).
>=20
> I strongly recommend against changing RFC1323 timestamps in any way.
> Make it new options but leave the current behavior as it is.

Perhaps we need a new TCP option number and new semantics to address late n=
egotiation. After all, the experiments conducted during MPTCP showed, that =
a majority of middleboxes won't fuss with unknown options once they are all=
owed through.  Perhaps we can get away by defining additional semantics to =
the current TCP TS option.=20

Right now, I think it is too early to make a facts-based decision either wa=
y.

Therefore, I want to run some small-scale tests with TBIT against a bunch o=
f popular OS and see how they react when TS show up in mid-connection...



>> * Window reduction during recovery bug - Matt
>=20
> ?

>From my casual understanding (more knowledgeable people please correct my i=
gnorance):

When the receiver's buffer cannot be delivered up to the application, and a=
t the same instance you have a loss; eventually, the receiver buffer will b=
e announced as ("0"<<WS) [which is still 0], thus potentially preventing th=
e sender from retransmitting the lost packet (because now it is outside the=
 receive window), even though the actual receive window on the receiver sid=
e is still  ("1"<<WS - 1) open...

Basically a rounding-error due to the WS scale shifting.

This suggested fix, as I understood it from Matt, is to either keep track o=
f the largest receive window ever seen on the session, and use that for ret=
ransmissions, while the currently signaled receive window is used for newly=
 injected packets; or use (Recv.Window + 1) << Recv.WSopt during retransmis=
sions.

Currently, such a stall may lead to a terminated session (ie. if the receiv=
er app waits for a certain amount of data, that is blocked due to the retra=
nsmission never coming through because of the zero window advertised).




> > * Enabling TS (PAWS) midstream - David, Matt, and others
>=20
> Disagreed due to interop issues.  The current behavior is engraved in
> stone in 20 years worth of implementations of any kind.  We have enough
> trouble keeping TCP fully interoperable as it is.  Don't add yet another
> fuzzy failure case.  Even worse that connections may suddenly fail mid-
> transfer without anyone knowing why (because firefall gets tripped up).

See comments above. As long as a middlebox only stops forwarding packets, b=
ut doesn't remove state or actively terminates sessions, a graceful retry m=
ay work so that the session is not completely stalled (ie. if a RTO occurs =
while trying to do delayed TS negotiation, stop trying to use TS on this se=
ssion in the future; so we may need to define the state machine for delayed=
 negotiation in some detail to cover (most) failure modes...

> And don't forget that timestamps add some entropy to the already limited
> 32^2 sequence space.

Must have been 2^32. Also note that may people don't deploy TS because of t=
he perceived reduction in net bandwidth (~0,82% "slower" when doing dumb bu=
lk transfer tests over "nice" links). Using "delayed" TS could happen quite=
 far into "bulk" transfers, so that more sessions can make use of Timestamp=
s once they need it, but don't have to carry the burden as long as they don=
't require TS. All the small object transfers up to 1 GB may be eligible to=
 run without TS, if the server doesn't want to use TS heuristics for fast T=
CP Port recycling [but strictly speaking, that part is beyond the specs any=
way].
=20
> > * References / interaction with SACK (TS check does not look if SACK is
> > present - to cover certain cased of lost ACKs that inflate RTO) [?]
>=20
> The presence of SACK removes ambiguity from timestamps and also from
> the somewhat brittle window update logic (see my long post from some
> two years ago).

Well, I looked at one implementation of RTTM, and there was no check on the=
 presence of SACKs there. Thus an ACK (containing a SACK block) after a los=
t ACK during forward loss will probably still inflate RTTvar and thus RTO; =
this is probably more of an issue with Karn's algorithm (as that is being r=
eferenced in RFC1323).



From brandon.williams@akamai.com  Mon Apr  2 14:01:23 2012
Return-Path: <brandon.williams@akamai.com>
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 67A7321F8475 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 14:01:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mupn3W5jNGPa for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 14:01:22 -0700 (PDT)
Received: from prod-mail-xrelay01.akamai.com (prod-mail-xrelay01.akamai.com [72.246.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id BFAE121F85C7 for <tcpm@ietf.org>; Mon,  2 Apr 2012 14:01:21 -0700 (PDT)
Received: from prod-mail-xrelay01.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 12383CF1A8 for <tcpm@ietf.org>; Mon,  2 Apr 2012 21:01:21 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay01.akamai.com (Postfix) with ESMTP id F2A96CF181 for <tcpm@ietf.org>; Mon,  2 Apr 2012 21:01:20 +0000 (GMT)
Received: from [0.0.0.0] (callahan.kendall.corp.akamai.com [172.17.12.11]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id DF71D47BF1 for <tcpm@ietf.org>; Mon,  2 Apr 2012 21:01:20 +0000 (GMT)
Message-ID: <4F7A13A0.3050605@akamai.com>
Date: Mon, 02 Apr 2012 17:01:20 -0400
From: Brandon Williams <brandon.williams@akamai.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: "tcpm@ietf.org" <tcpm@ietf.org>
References: <4F747B99.9030701@akamai.com> <4F74BD64.20903@isi.edu> <4F74D2FB.7060109@akamai.com> <4F74E00B.5060006@akamai.com> <4F7A07C1.2060701@isi.edu>
In-Reply-To: <4F7A07C1.2060701@isi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [tcpm] draft-williams-overlaypath-ip-tcp-rfc-00
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 21:01:23 -0000

Thanks for the additional explanation Joe. That will help me to make the 
necessary clarifications in the next edit.

--Brandon

On 04/02/2012 04:10 PM, Joe Touch wrote:
> Hi, Brandon,
>
> Thanks for the quick turn on this issue.
>
> Typically, the IANA Considerations section would list the specific
> assignments in detail and provide enough information for IANA to assign
> values:
>
> E.g., for IPv4, to list the Class and Copied flags, etc.
>
> ...AND for the RFC-Editor to be able to update the text accordingly.
>
> E.g., use TBD-IP4, TBD-IP6, TBD-TCP rather than just "TBD" in locations
> where each is referred to by value.
>
> So that section could use some expansion, but that can happen as the doc
> is updated. The removal of proposed values was more critical, and thanks
> for doing that quickly.
>
> Joe
>
> On 3/29/2012 3:19 PM, Brandon Williams wrote:
>> I have submitted a revised version of the draft which no longer
>> inappropriately refers to specific option numbers that have not been
>> assigned by IANA. Please let me know if the revision does not meet your
>> expectations for clarity in this regard.
>>
>> Thank you,
>> --Brandon
>>
>>
>> A new version of I-D, draft-williams-overlaypath-ip-tcp-rfc-01.txt has
>> been successfully submitted by Brandon Williams and posted to the IETF
>> repository.
>>
>> Filename: draft-williams-overlaypath-ip-tcp-rfc
>> Revision: 01
>> Title: Overlay Path Option for IP and TCP
>> Creation date: 2012-03-29
>> WG ID: Individual Submission
>> Number of pages: 15
>>
>> Abstract:
>> Data transport through overlay networks often uses either connection
>> termination or network address translation (NAT) in such a way that
>> the public IP addresses of the true endpoint machines involved in the
>> data transport are invisible to each other. This document describes
>> IPv4, IPv6, and TCP options for communicating this information from
>> the overlay network to the endpoint machines.
>>
>> On 03/29/2012 05:24 PM, Brandon Williams wrote:
>>> Thank you for taking the time to look the document over and for noting
>>> this shortcoming. You are absolutely right that the document should not
>>> have been published with any reference to unassigned numbers. I should
>>> have realized that this would be unacceptable.
>>>
>>> I will make that change and publish a version 01 ASAP in order to
>>> facilitate further discussion.
>>>
>>> --Brandon
>>>
>>> On 03/29/2012 03:52 PM, Joe Touch wrote:
>>>> This doc needs to be updated immediately, and references to numbers not
>>>> assigned by IANA replaced with TBDs. Notably IP option 218, TCP option
>>>> 30, etc. are NOT assigned by IANA.
>>>>
>>>> There is no such thing as "provisional pending IANA approval"; this
>>>> document establishes squatting, period.
>>>>
>>>> This document should be revised before being further discussed.
>>>>
>>>> Joe
>>>>
>>>>
>>>> On 3/29/2012 8:11 AM, Brandon Williams wrote:
>>>>> An Internet-Draft is available from the on-line Internet-Drafts
>>>>> directories.
>>>>>
>>>>> Title : Overlay Path Option for IP and TCP
>>>>> Author : Brandon Williams
>>>>> Filename : draft-williams-overlaypath-ip-tcp-rfc-00.txt
>>>>> Pages : 15
>>>>> Date : 2012-01-17
>>>>>
>>>>> This document proposes IPv4, IPv6, and TCP options for
>>>>> communicating the true IP address of a TCP connection endpoint
>>>>> to its peer when that address is hidden due to the use of NAT on
>>>>> an overlay network.
>>>>>
>>>>> A URL for this Internet-Draft is:
>>>>> http://www.ietf.org/id/draft-williams-overlaypath-ip-tcp-rfc-00.txt
>>>>>
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>
>>>>> This Internet-Draft can be retrieved at:
>>>>> http://www.ietf.org/id/draft-williams-overlaypath-ip-tcp-rfc-00.txt
>>>>>
>>>
>>

-- 
Brandon Williams; Principal Software Engineer
Cloud Engineering; Akamai Technologies Inc.

From touch@isi.edu  Mon Apr  2 14:06:27 2012
Return-Path: <touch@isi.edu>
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 6CA0F21F8523 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 14:06:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.932
X-Spam-Level: 
X-Spam-Status: No, score=-105.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tfLxgFZ+H0F for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 14:06:26 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id DBE1321F851C for <tcpm@ietf.org>; Mon,  2 Apr 2012 14:06:26 -0700 (PDT)
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 q32L5UtQ015700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Apr 2012 14:05:30 -0700 (PDT)
Message-ID: <4F7A149A.7050909@isi.edu>
Date: Mon, 02 Apr 2012 14:05:30 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Scheffenegger, Richard" <rs@netapp.com>
References: <012C3117EDDB3C4781FD802A8C27DD4F1533DE@SACEXCMBX02-PRD.hq.netapp.com>
In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F1533DE@SACEXCMBX02-PRD.hq.netapp.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: "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, David Borman <dab@weston.borman.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "mallman@icir.org" <mallman@icir.org>
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 21:06:27 -0000

Hi, all,

Three observations:

1. Late negotiation is very difficult. TCP's state diagram only 
understands one ESTABLISHED state. Before that state, TCP's state 
mechanism ensures an ordering so that the SYN options can be coordinated.

After that, while ESTABLISHED, there's no way to ensure that options are 
transmitted reliably and in-order.

We can easily define a single SYN option that, in effect, says "if you 
agree to this option, you're no longer TCP". Options can have sequence 
numbers of their own, and be retransmitted asynchronously and 
acknowledged independently of the data.

That's a mess, IMO, and should be avoided. Yes, one example of that mess 
is called MPTCP.

2. Alternately, we can consolidate some of the options, as was done with 
TCP-CT. The current header requires:
    o  SACK permitted (2 bytes) [RFC2018][RFC3517]
    o  Timestamps (10 bytes) [RFC1323]
    o  Window scale (3 bytes) [RFC1323]

We can knock that 15 (typically allocated as 16) bytes down to half that 
- 7 (allocated as 8) easily:

	1 byte kind
	1 byte length
	1 byte scale value
	4 bytes TSval

The SYN-ACK would send TSSecr in the TSval location, and the sender 
would cache TSval (matched with the ISN) to recover it when receiving 
the SYN-ACK.

That helps reduce the current use of the SYN space by half, and similar 
approaches that aggregate other typical option sets to reduce the number 
of KIND/LENGTH bytes might be useful, but overall this plays in the 
margins at best.

3. What's really needed is a way to get beyond the 40-byte limit - 
primarily in SYNs, but even in subsequent segments -- and there's 
provably no way to do that which is backward compatible (for SYNs) and 
NAT-transparent (for data segments).

Do we really need to go around this block again?

Joe

From rick.jones2@hp.com  Mon Apr  2 14:12:15 2012
Return-Path: <rick.jones2@hp.com>
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 7036A21F866A for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 14:12:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjTnHtf0luYf for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 14:12:14 -0700 (PDT)
Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7147B21F8575 for <tcpm@ietf.org>; Mon,  2 Apr 2012 14:12:10 -0700 (PDT)
Received: from g4t0009.houston.hp.com (g4t0009.houston.hp.com [16.234.32.26]) by g4t0015.houston.hp.com (Postfix) with ESMTP id A13598081; Mon,  2 Apr 2012 21:12:09 +0000 (UTC)
Received: from [16.89.64.213] (tardy.cup.hp.com [16.89.64.213]) by g4t0009.houston.hp.com (Postfix) with ESMTP id 94308C469; Mon,  2 Apr 2012 21:12:07 +0000 (UTC)
Message-ID: <4F7A1626.6060709@hp.com>
Date: Mon, 02 Apr 2012 14:12:06 -0700
From: Rick Jones <rick.jones2@hp.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Lightning/1.0b2 Thunderbird/3.1.20
MIME-Version: 1.0
To: "Scheffenegger, Richard" <rs@netapp.com>
References: <012C3117EDDB3C4781FD802A8C27DD4F1533DE@SACEXCMBX02-PRD.hq.netapp.com>
In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F1533DE@SACEXCMBX02-PRD.hq.netapp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, David Borman <dab@weston.borman.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "mallman@icir.org" <mallman@icir.org>
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 21:12:15 -0000

>> And don't forget that timestamps add some entropy to the already limited
>> 32^2 sequence space.
>
> Must have been 2^32. Also note that may people don't deploy TS
> because of the perceived reduction in net bandwidth (~0,82% "slower"
> when doing dumb bulk transfer tests over "nice" links). Using
> "delayed" TS could happen quite far into "bulk" transfers, so that
> more sessions can make use of Timestamps once they need it, but don't
> have to carry the burden as long as they don't require TS. All the
> small object transfers up to 1 GB may be eligible to run without TS,
> if the server doesn't want to use TS heuristics for fast TCP Port
> recycling [but strictly speaking, that part is beyond the specs
> anyway].

"Far" is probably relative.  4GB is not all that "far" in time at 10 GbE 
speeds.  And at 10 GbE speeds, a human being probably won't perceive the 
difference that ~0.82% makes).  At << 10 GbE speeds, disabling 
timestamps to get a measly ~0.82% of throughput seems silly.  Even with 
acknowledgement that adding little to little results in a great pile...

To a human - at least this human - the smallest difference in transfer 
time that "matters" is one minute.

To save me one minute, I need a 100 minute transfer. (Handwaving math 
since it isn't 1%)  4GB-1 of data in 100 minutes is ~5.7 Mbit/s.  Any 
slower than that and I'm talking about a transfer time where, to a human 
at least ~0.82% is epsilon.  Any faster than that, and I save 
progressively less than a minute.

If I'm talking about a transfer that takes more than 100 minutes at that 
~5.7Mbit/s, then I'm talking about a transfer where timestamps will 
end-up being added-on, which makes my savings go to epsilon the longer 
the transfer.  And if it was an automated transfer, perhaps a video 
stream? we hope it wasn't cutting things so fine that the loss of that 
~0.82% 4GB in isn't going to screw with its timing.  Probably right when 
the movie got to the good part.

If people are desperate enough for ~0.82% more throughput, we'll "never" 
get them to light-up IPv6...   As ironic as it sounds, I'd think we 
would want timestamps on universally to make the hit from the IPv6 
header look less.  Unless, perhaps, one day, we can get the IEEE to 
accept larger frame sizes...

rick jones

From jishac@nasa.gov  Mon Apr  2 15:02:31 2012
Return-Path: <jishac@nasa.gov>
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 BBADD21F86B4 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 15:02:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.977
X-Spam-Level: 
X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVbUgIlbFEOe for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 15:02:30 -0700 (PDT)
Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by ietfa.amsl.com (Postfix) with ESMTP id 38C8721F86AD for <tcpm@ietf.org>; Mon,  2 Apr 2012 15:02:30 -0700 (PDT)
Received: from ndjsppt03.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 75290182E43 for <tcpm@ietf.org>; Mon,  2 Apr 2012 17:02:24 -0500 (CDT)
Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt05.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q32M2NfE001157 for <tcpm@ietf.org>; Mon, 2 Apr 2012 17:02:24 -0500
Received: from mail-wg0-f44.google.com (74.125.82.44) by smtp01.ndc.nasa.gov (198.117.1.161) with Microsoft SMTP Server (TLS) id 8.3.245.1; Mon, 2 Apr 2012 17:02:23 -0500
Received: by wgbdr13 with SMTP id dr13so2140624wgb.13        for <tcpm@ietf.org>; Mon, 02 Apr 2012 15:02:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.95.129 with SMTP id dk1mr34271612wib.3.1333404140959; Mon, 02 Apr 2012 15:02:20 -0700 (PDT)
Received: by 10.180.81.226 with HTTP; Mon, 2 Apr 2012 15:02:20 -0700 (PDT)
In-Reply-To: <4F7A0407.8090105@isi.edu>
References: <201203301322.q2UDMIcc009352@bagheera.jungle.bt.co.uk> <4F79F355.2020000@isi.edu> <4F7A0407.8090105@isi.edu>
Date: Mon, 2 Apr 2012 18:02:20 -0400
Message-ID: <CANPnThZ9gB23p3SCpUPKMJRwog4=271z1Top4z6LWpZ9XvzkMw@mail.gmail.com>
From: Joseph Ishac <jishac@nasa.gov>
To: Joe Touch <touch@isi.edu>
Content-Type: text/plain; charset="ISO-8859-1"
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-04-02_04:2012-04-02, 2012-04-02, 1970-01-01 signatures=0
Cc: tcpm IETF list <tcpm@ietf.org>, "mallman@icir.org" <mallman@icir.org>
Subject: Re: [tcpm] IW10 & queuebloat
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 22:02:31 -0000

On Mon, Apr 02, 2012 at 02:54:47PM -0500, Joe Touch wrote:
> >>  From the TAO of the IETF:
> >>
> >> ---
> >> Experimental RFCs are for specifications that may be interesting, but for
> >> which it is unclear if there will be much interest in implementing them, or
> >> whether they will work once deployed. That is, a specification might solve a
> >> problem, but if it is not clear that many people think that the problem is
> >> important, or think that they will bother fixing the problem with the
> >> specification, the specification might be labeled an Experimental RFC. If,
> >> later, the specification becomes popular (or proves that it works well), it
> >> can be re-issued as a standards-track RFC. Experimental RFCs are also used
> >> to get people to experiment with a technology that looks like it might be
> >> standards-track material, but for which there are still unanswered
> >> questions.
> >> ---
> >>
> >> AFAICT, this proposal isn't experimental at all if the point is to deploy it
> >> as default in widely-used systems on the Internet.

No where in the TAO do I see it discouraging use on production servers,
nor do I see anything that specifies how many servers is "too many" or
the magic number to "become popular".  I'd imagine that the more servers
that implement the option, the more data that's available to determine
if it works well, and if others take interest in the specification.

> > which part in our draft talks the point you mentioned? we'll be happy
> > to correct it.
> >
> > """
> > 2.  TCP Modification
> >
> >     This document proposes an increase in the permitted upper bound for
> >     TCP's initial window (IW) to 10 segments depending on the MSS. This
> >     increase is optional: a TCP MAY start with an initial window that is
> >     smaller than 10 segments.
> >
> >     More precisely, the upper bound for the initial window will be
> >
> >           min (10*MSS, max (2*MSS, 14600))                            (1)
> > """
> >
> > """
> > 12. Usage and Deployment Recommendations
> >
> >     Further experiments are required before a larger initial window shall
> >     be enabled by default in the Internet. The existing measurement
> >     results indicate that this does not cause significant harm to other
> >     traffic. However, widespread use in the Internet could reveal issues
> >     not known yet, e.g., regarding fairness or impact on latency-
> >     sensitive traffic such as VoIP.
> > """
>
> This is inconsistent with the following, from the Intro:
>
>     We recommend that all TCP implementations have a settable TCP IW
>     parameter. As of 2011 an appropriate value for this parameter is 10
>     segments as long as there is a reasonable effort to monitor for
>     possible interactions with other Internet applications and services.
>     Furthermore, it is understood that the appropriate value for IW is
>     likely to continue to rise in the future, but this document does not
>     include any supporting evidence for larger values of IW.

I assume the contention is with the word "all"?

I don't think it's necessary to introduce wiggle words into every part
of an experimental draft.  That by noting the draft as experimental, I
can read the above section of the introduction without treating it as a
levied requirement or BCP.  The text helps to highlight the overall goal
and vision of the experimental option, which in turn would help
highlight how one might actually experiment with it and who might be
interested in the concept (in this case the author argues "everyone").

> >> IMO, experimental RFCs ought to require an explanation of the experiment
> >> expected. It's disingenuous (at best) and misleading to call IW10
> >> "experimental".

I would claim that the goal of the document should focus more on the
concept and not exactly what type of experiment needs to be run.  The
very nature of experimentation means that there may be ways or angles to
test a concept or hypothesis... I wouldn't burden the document with
trying to capture all of them or how to analyze the data.  In fact
different analysis of the impact is what will help determine if the
concept succeeds or fails.

I would consider IW10 ready for WGLC.

-Joseph

From ananth@cisco.com  Mon Apr  2 15:06:59 2012
Return-Path: <ananth@cisco.com>
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 DE9FE21F85CE for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 15:06:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YD-Ytka-UkX3 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 15:06:58 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id A229E21F84CF for <tcpm@ietf.org>; Mon,  2 Apr 2012 15:06:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=1925; q=dns/txt; s=iport; t=1333404402; x=1334614002; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=EmHWc+J7AMLVhlwp6ViIRw+OMifSsKNIeezV+mxXW7E=; b=RgfchCQK9H+vBOyTfl/RgDc08NPdNC8zTGlbxFpCcR2KDXiHdInFNx10 ydZSp7y8cm3sCDbx0uQCdeDUzvxLtTodsAqCuojsRmNtlMbcko2OKE8zp 5/eescOc4okHo9Gb0RNOjezd6XF6FsBQuzmHqmlZKla5WvWUJwV+wM38i s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAAAiek+rRDoJ/2dsb2JhbABFDrdxgQeCCQEBAQMBEgEdCj8FCwIBCCIGGAYBVgEBBBsTB4diBAGbZJ8UkAtjBIhYm1CBaIIwVw
X-IronPort-AV: E=Sophos;i="4.75,359,1330905600"; d="scan'208";a="38665631"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 02 Apr 2012 22:06:42 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q32M6gTH028605; Mon, 2 Apr 2012 22:06:42 GMT
Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 2 Apr 2012 15:06:42 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 2 Apr 2012 15:06:39 -0700
Message-ID: <1F8E0A684D3FF54680294BCFE57A7DB504C92C51@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <4F7A149A.7050909@isi.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
Thread-Index: Ac0RFF+P3iURfEarTSSn1OMg70kAWgAA593Q
References: <012C3117EDDB3C4781FD802A8C27DD4F1533DE@SACEXCMBX02-PRD.hq.netapp.com> <4F7A149A.7050909@isi.edu>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Joe Touch" <touch@isi.edu>, "Scheffenegger, Richard" <rs@netapp.com>
X-OriginalArrivalTime: 02 Apr 2012 22:06:42.0349 (UTC) FILETIME=[E2AF05D0:01CD111C]
Cc: David Borman <dab@weston.borman.com>, tcpm@ietf.org, mallman@icir.org
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 22:06:59 -0000

> Do we really need to go around this block again?

Answer : Yes, please see the motivation section of the document.

At least the reason for writing this document is to basically re-visit
this whole TCP option thing. List all the methods and see if there is
something that can be done. May be we would end up with (something -
caveats), assuming there is a consensus. Nothing is perfect, PMTU wasn't
perfect to begin with,  did we say that stop doing PMTU since there is
ICMP blackholing?  RFC 4281 was written to circumvent the issues... For
example TCP-AO would not work with NAT ALG's today, but didn't we write
an RFC? I am sure we can keep getting some "imperfect examples" if one
looks around.  Before writing this document I did chat to the chairs and
other folks and there seemed to a general interest in reviving this TCP
option debate.=20

To me, the biggest hurdle is the middleboxes (NAT and firewall), that is
where we need some data to be collected and may be some lines that need
to be drawn. I would like to note that the draft mentions a paper
(Michio Honda et al) titled "is it still possible to extend TCP"? which
provides the list of experiments conducted to observe middlebox
behaviors.

I would think it would be prudent to continue the discussion in the
lines of "can we do something with the timestamp option" ? (which is
where the current thread started) can we compress options (TCP option
cookies OR have some different encoding/grouping etc.,?, you cited
TCP-CT or sending multiple duplicate segments?, or "happy-eyeballs" in
the lines done for v6 etc.,  Again, I am sure no solution wouldn't
satisfy all the corner cases, but you could always experiment "a chosen
one" and eventually the middleboxes would change. IPv6 was not supported
by the middleboxes a while ago, but no I don't see any middlebox
dropping a IPv6 packet today!

-Anantha=20
>=20
> Joe

From touch@isi.edu  Mon Apr  2 15:10:42 2012
Return-Path: <touch@isi.edu>
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 1DDC121F85E5 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 15:10:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.099
X-Spam-Level: 
X-Spam-Status: No, score=-104.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbHMtnKYZtVP for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 15:10:41 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 5C39621F870A for <tcpm@ietf.org>; Mon,  2 Apr 2012 15:10:41 -0700 (PDT)
Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q32MAOOE027531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Apr 2012 15:10:24 -0700 (PDT)
Message-ID: <4F7A23D0.3090909@isi.edu>
Date: Mon, 02 Apr 2012 15:10:24 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Joseph Ishac <jishac@nasa.gov>
References: <201203301322.q2UDMIcc009352@bagheera.jungle.bt.co.uk> <4F79F355.2020000@isi.edu> <4F7A0407.8090105@isi.edu> <CANPnThZ9gB23p3SCpUPKMJRwog4=271z1Top4z6LWpZ9XvzkMw@mail.gmail.com>
In-Reply-To: <CANPnThZ9gB23p3SCpUPKMJRwog4=271z1Top4z6LWpZ9XvzkMw@mail.gmail.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 list <tcpm@ietf.org>, "mallman@icir.org" <mallman@icir.org>
Subject: Re: [tcpm] IW10 & queuebloat
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 22:10:42 -0000

On 4/2/2012 3:02 PM, Joseph Ishac wrote:
> On Mon, Apr 02, 2012 at 02:54:47PM -0500, Joe Touch wrote:
>>>>    From the TAO of the IETF:
>>>>
>>>> ---
>>>> Experimental RFCs are for specifications that may be interesting, but for
>>>> which it is unclear if there will be much interest in implementing them, or
>>>> whether they will work once deployed. That is, a specification might solve a
>>>> problem, but if it is not clear that many people think that the problem is
>>>> important, or think that they will bother fixing the problem with the
>>>> specification, the specification might be labeled an Experimental RFC. If,
>>>> later, the specification becomes popular (or proves that it works well), it
>>>> can be re-issued as a standards-track RFC. Experimental RFCs are also used
>>>> to get people to experiment with a technology that looks like it might be
>>>> standards-track material, but for which there are still unanswered
>>>> questions.
>>>> ---
>>>>
>>>> AFAICT, this proposal isn't experimental at all if the point is to deploy it
>>>> as default in widely-used systems on the Internet.
>
> No where in the TAO do I see it discouraging use on production servers,
> nor do I see anything that specifies how many servers is "too many" or
> the magic number to "become popular".  I'd imagine that the more servers
> that implement the option, the more data that's available to determine
> if it works well, and if others take interest in the specification.
>
>>> which part in our draft talks the point you mentioned? we'll be happy
>>> to correct it.
>>>
>>> """
>>> 2.  TCP Modification
>>>
>>>      This document proposes an increase in the permitted upper bound for
>>>      TCP's initial window (IW) to 10 segments depending on the MSS. This
>>>      increase is optional: a TCP MAY start with an initial window that is
>>>      smaller than 10 segments.
>>>
>>>      More precisely, the upper bound for the initial window will be
>>>
>>>            min (10*MSS, max (2*MSS, 14600))                            (1)
>>> """
>>>
>>> """
>>> 12. Usage and Deployment Recommendations
>>>
>>>      Further experiments are required before a larger initial window shall
>>>      be enabled by default in the Internet. The existing measurement
>>>      results indicate that this does not cause significant harm to other
>>>      traffic. However, widespread use in the Internet could reveal issues
>>>      not known yet, e.g., regarding fairness or impact on latency-
>>>      sensitive traffic such as VoIP.
>>> """
>>
>> This is inconsistent with the following, from the Intro:
>>
>>      We recommend that all TCP implementations have a settable TCP IW
>>      parameter. As of 2011 an appropriate value for this parameter is 10
>>      segments as long as there is a reasonable effort to monitor for
>>      possible interactions with other Internet applications and services.
>>      Furthermore, it is understood that the appropriate value for IW is
>>      likely to continue to rise in the future, but this document does not
>>      include any supporting evidence for larger values of IW.
>
> I assume the contention is with the word "all"?

All should have settable IWs.

The objection is to the claim that the appropriate default is 10.

This is inconsistent with the document's own assertion in section 12 
(the first sentence).

> I don't think it's necessary to introduce wiggle words into every part
> of an experimental draft.  That by noting the draft as experimental, I
> can read the above section of the introduction without treating it as a
> levied requirement or BCP.  The text helps to highlight the overall goal
> and vision of the experimental option, which in turn would help
> highlight how one might actually experiment with it and who might be
> interested in the concept (in this case the author argues "everyone").

The intro is in direct conflict with the recommendations in sec 12.

>>>> IMO, experimental RFCs ought to require an explanation of the experiment
>>>> expected. It's disingenuous (at best) and misleading to call IW10
>>>> "experimental".
>
> I would claim that the goal of the document should focus more on the
> concept and not exactly what type of experiment needs to be run.  The
> very nature of experimentation means that there may be ways or angles to
> test a concept or hypothesis... I wouldn't burden the document with
> trying to capture all of them or how to analyze the data.  In fact
> different analysis of the impact is what will help determine if the
> concept succeeds or fails.

The key here is that an experiment involves:

	- collecting data
	- reporting data
	- analyzing results

What data is relevant to collect?

Where is that data reported?

What is the expected outcome, i.e., predict some alternate results and 
say what would happen.

Without these, it's not an experiment.

Joe

>
> I would consider IW10 ready for WGLC.
>
> -Joseph

From touch@isi.edu  Mon Apr  2 15:20:47 2012
Return-Path: <touch@isi.edu>
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 1DD7621F86B6 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 15:20:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.799
X-Spam-Level: 
X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3Ku5KNx0C1Z for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 15:20:46 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 976DF21F8697 for <tcpm@ietf.org>; Mon,  2 Apr 2012 15:20:46 -0700 (PDT)
Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q32MK6Gg026942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Apr 2012 15:20:07 -0700 (PDT)
Message-ID: <4F7A2616.4090308@isi.edu>
Date: Mon, 02 Apr 2012 15:20:06 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
References: <012C3117EDDB3C4781FD802A8C27DD4F1533DE@SACEXCMBX02-PRD.hq.netapp.com> <4F7A149A.7050909@isi.edu> <1F8E0A684D3FF54680294BCFE57A7DB504C92C51@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <1F8E0A684D3FF54680294BCFE57A7DB504C92C51@xmb-sjc-23e.amer.cisco.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: David Borman <dab@weston.borman.com>, tcpm@ietf.org, mallman@icir.org
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 22:20:47 -0000

On 4/2/2012 3:06 PM, Anantha Ramaiah (ananth) wrote:
>
>> Do we really need to go around this block again?
>
> Answer : Yes, please see the motivation section of the document.

I agree with your claim that there is a need.

I disagree with the claim that there's a solution. Although no solutions 
are perfect, there are some that are simply not possible - this is one 
of them.

The only possible solution is to extend the option for segments after 
the SYN using an option in the SYN
	1. at best that helps non-SYN segments

	2. it also has the easy potential to be
	corrupted by middleboxes

		corruption is both possible and currently likely

		corruption detection is impossible without adding
		(yet another) checksum, which slows things down
		at best

It's provable that there is no SYN option extension that is backward 
compatible. Non-backward compatible solutions are as trivial as the 
above, and as (not) useful.

Option compression reduces the current use of option space, but does 
nothing to extend it beyond 40.

I see no point in reviving this. It'd be better to nail it shut and call 
it dead.

Joe

PS- Regarding other imperfect solutions:
> .... For
> example TCP-AO would not work with NAT ALG's today, but didn't we write
> an RFC?

FWIW, as noted during the design, a NAT ALG is an attack that TCP-AO is 
intended to detect.


From ananth@cisco.com  Mon Apr  2 16:07:22 2012
Return-Path: <ananth@cisco.com>
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 E15EE21F8686 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 16:07:22 -0700 (PDT)
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=-1.150, BAYES_00=-2.599, MANGLED_PREMTR=2.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apTBAhQxstUI for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 16:07:22 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 14B1521F8666 for <tcpm@ietf.org>; Mon,  2 Apr 2012 16:07:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=4636; q=dns/txt; s=iport; t=1333408042; x=1334617642; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ljf8Z4Fnl7SwhTF7/xSKQA06PutRe2DVnZ13PMSpJsI=; b=NtUWp6cNN/DYI+ql3nfH5RgZyJNK/rNqLZOsNCP2Y+b++8BBbYiIHqoi fV3RGrhyuiBFyS128s5JBJoN946PCXm4O6M+AExZP0/8MBrcIzAe9MKCe G3v0KpyhV33WCEeGFEbXk8D6vLp26s+X8lycrn3Ncn5nj/hx9oW0frxeJ 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAAYwek+rRDoH/2dsb2JhbABFDrdxgQeCCQEBAQMBEgEdCj8FBwQCAQgRBAEBAQoGFwEGAUUJCAEBBBMIEweHYgQBm22fFJALYwSIWJtQgWiCMFc
X-IronPort-AV: E=Sophos;i="4.75,359,1330905600"; d="scan'208";a="38673648"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 02 Apr 2012 23:07:21 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q32N7Lf1023517; Mon, 2 Apr 2012 23:07:21 GMT
Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 2 Apr 2012 16:07:21 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 2 Apr 2012 16:07:21 -0700
Message-ID: <1F8E0A684D3FF54680294BCFE57A7DB504C92C9A@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <4F7A2616.4090308@isi.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
Thread-Index: Ac0RHterBbepypGnTDqJHKLsOXsl0QAAeeVw
References: <012C3117EDDB3C4781FD802A8C27DD4F1533DE@SACEXCMBX02-PRD.hq.netapp.com> <4F7A149A.7050909@isi.edu> <1F8E0A684D3FF54680294BCFE57A7DB504C92C51@xmb-sjc-23e.amer.cisco.com> <4F7A2616.4090308@isi.edu>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Joe Touch" <touch@isi.edu>
X-OriginalArrivalTime: 02 Apr 2012 23:07:21.0692 (UTC) FILETIME=[5BE6B1C0:01CD1125]
Cc: David Borman <dab@weston.borman.com>, tcpm@ietf.org, mallman@icir.org
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 23:07:23 -0000

Joe,

> -----Original Message-----
> From: Joe Touch [mailto:touch@isi.edu]
> Sent: Monday, April 02, 2012 3:20 PM
> To: Anantha Ramaiah (ananth)
> Cc: Scheffenegger, Richard; Andre Oppermann; David Borman;
> tcpm@ietf.org; mallman@icir.org
> Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option
> space extension.
>=20
>=20
>=20
> On 4/2/2012 3:06 PM, Anantha Ramaiah (ananth) wrote:
> >
> >> Do we really need to go around this block again?
> >
> > Answer : Yes, please see the motivation section of the document.
>=20
> I agree with your claim that there is a need.
>=20
> I disagree with the claim that there's a solution. Although no
> solutions are perfect, there are some that are simply not possible -
> this is one of them.

"Simply not possible" - I am afraid that isn't the consensus. This is
one of the reasons for reviving the draft. We have not discussed the
other methods for instance, which were not debated (atleast I did not
see that in the list) For example you cited in one of your earlier post
that "after SYN it is not an issue, only getting it in SYN is
problematic". Assuming you really meant what you said, it means that if
we can squeeze the ones that needs to be negotiated in SYN and rest
after the 3WHS then is is ok. Then schemes like "sending multiple
SYN's", option encoding to save space etc., would come into play. In
your earlier post you also cited that" it is ok if someone wants to
write a draft for extending TCP option space after SYN's" So, this is
again not complete but should serve as a intermediate step. [I guess you
are saying the same thing below]=20


>=20
> The only possible solution is to extend the option for segments after
> the SYN using an option in the SYN
> 	1. at best that helps non-SYN segments
>=20
> 	2. it also has the easy potential to be
> 	corrupted by middleboxes
>=20
> 		corruption is both possible and currently likely
>=20
> 		corruption detection is impossible without adding
> 		(yet another) checksum, which slows things down
> 		at best

Well, anything you do that alters the meaning of the TCP DO field is
susceptible for middlebox issues. The current draft gives examples and
classifies it based on the middlebox property (M1 to M6)

>=20
> It's provable that there is no SYN option extension that is backward
> compatible. Non-backward compatible solutions are as trivial as the
> above, and as (not) useful.

Please explain. If you read my draft I do list proposals that are
"backward compatible" w.r.t to end hosts. Middleboxes does prove to be
an issue, but I believe I have listed proposals where which probably has
better chances with middle boxes but maybe less efficient.

>=20
> Option compression reduces the current use of option space, but does
> nothing to extend it beyond 40.
>=20
> I see no point in reviving this. It'd be better to nail it shut and
> call it dead.

Well, I disagree here since we have not debated every solution  and
things like trying to save some option space in SYN (eg timestamp
discussion) *does* count as "step in the right direction" that help the
TCP option space conservation. Another point which I wish to repeat is :
when the discussions happened on this topic earlier, there was not a
stronger use case for TCP option space, things have changed now
(changing more as there are new TCP options evolving) and that may
encourage different opinions on this topic. This is one of the other
motivating factors for writing the draft. Of course I can see that your
mileage varies here.


> PS- Regarding other imperfect solutions:
> > .... For
> > example TCP-AO would not work with NAT ALG's today, but didn't we
> > write an RFC?
>=20
> FWIW, as noted during the design, a NAT ALG is an attack that TCP-AO
is
> intended to detect.

Ah, you call it a "design choice", but the point is that it does not
interoperate with a property of the middlebox. Period. We made a
decision to stick with that. I am not questioning the decision here, as
the use cases of TCP-AO may not be susceptible to such an issue. This is
what I call "drawing the line", I am afraid we haven't had that sort of
discussion given the fresh use cases, so it would be a bad idea to pull
down the curtains on this one, it would be pre-mature, IMO. Ok, I'll
happy to hear thoughts from other participants, if the consensus is to
shutdown this investigation (let alone document the issues which acts as
a reference point for future), needless to mention, then there is no
point wasting any energy in the draft. =20

-Anantha


From touch@isi.edu  Mon Apr  2 16:24:20 2012
Return-Path: <touch@isi.edu>
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 EFEE321F8659 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 16:24:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.932
X-Spam-Level: 
X-Spam-Status: No, score=-105.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfozOkKHaBAS for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 16:24:19 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0E821F8656 for <tcpm@ietf.org>; Mon,  2 Apr 2012 16:24:19 -0700 (PDT)
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 q32NO4QR005624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Apr 2012 16:24:04 -0700 (PDT)
Message-ID: <4F7A3514.5040804@isi.edu>
Date: Mon, 02 Apr 2012 16:24:04 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
References: <012C3117EDDB3C4781FD802A8C27DD4F1533DE@SACEXCMBX02-PRD.hq.netapp.com> <4F7A149A.7050909@isi.edu> <1F8E0A684D3FF54680294BCFE57A7DB504C92C51@xmb-sjc-23e.amer.cisco.com> <4F7A2616.4090308@isi.edu> <1F8E0A684D3FF54680294BCFE57A7DB504C92C9A@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <1F8E0A684D3FF54680294BCFE57A7DB504C92C9A@xmb-sjc-23e.amer.cisco.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: David Borman <dab@weston.borman.com>, tcpm@ietf.org, mallman@icir.org
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 23:24:20 -0000

Amanth,

Cutting things down a bit...

On 4/2/2012 4:07 PM, Anantha Ramaiah (ananth) wrote:
...
>> I disagree with the claim that there's a solution. Although no
>> solutions are perfect, there are some that are simply not possible -
>> this is one of them.
>
> "Simply not possible" - I am afraid that isn't the consensus.

Consensus doesn't make it happen. A solution does, and no viable 
solution has been proposed.

...
> For example you cited in one of your earlier post
> that "after SYN it is not an issue, only getting it in SYN is
> problematic". Assuming you really meant what you said, it means that if
> we can squeeze the ones that needs to be negotiated in SYN and rest
> after the 3WHS then is is ok.

Yes, but then any rewriting middlebox that doesn't understand the option 
will ignore it and the options will move around and be intermingled with 
the data. That's not a viable alternative.

> Then schemes like "sending multiple
> SYN's", option encoding to save space etc., would come into play.

Encoding to save space saves space; it doesn't create more space.

Sending multiple SYNs isn't a solution either, as it would interact 
badly with NATs.

 > In
> your earlier post you also cited that" it is ok if someone wants to
> write a draft for extending TCP option space after SYN's" So, this is
> again not complete but should serve as a intermediate step. [I guess you
> are saying the same thing below]

I also point out that this is a meaningless step for two reasons:

1) the key place where space is limited is the SYNs

2) such an option won't survive anything that rewrites segments

>> The only possible solution is to extend the option for segments after
>> the SYN using an option in the SYN
>> 	1. at best that helps non-SYN segments
>>
>> 	2. it also has the easy potential to be
>> 	corrupted by middleboxes
>>
>> 		corruption is both possible and currently likely
>>
>> 		corruption detection is impossible without adding
>> 		(yet another) checksum, which slows things down
>> 		at best
>
> Well, anything you do that alters the meaning of the TCP DO field is
> susceptible for middlebox issues. The current draft gives examples and
> classifies it based on the middlebox property (M1 to M6)

We can classify it, but we can't get around it.

>> It's provable that there is no SYN option extension that is backward
>> compatible. Non-backward compatible solutions are as trivial as the
>> above, and as (not) useful.
>
> Please explain. If you read my draft I do list proposals that are
> "backward compatible" w.r.t to end hosts.

TCP is allowed - and supposed - to ignore options it doesn't understand.

An option in the SYN creates more option space, either by redefining the 
DO field (e.g., to have a scale beyond x4), or by specifically 
interpreting the SYN data as option.

An endpoint that doesn't understand these legitimately ignores the 
option, and then interprets the extended space as data.

Sending multiple SYNs has even more problems - how do you know how long 
to wait to get all the ones you need? What happens when you get a set of 
SYNs that conflict? And what do NATs do with all these SYNs?

> Middleboxes does prove to be
> an issue, but I believe I have listed proposals where which probably has
> better chances with middle boxes but maybe less efficient.
>
>> Option compression reduces the current use of option space, but does
>> nothing to extend it beyond 40.
>>
>> I see no point in reviving this. It'd be better to nail it shut and
>> call it dead.
>
> Well, I disagree here since we have not debated every solution  and
> things like trying to save some option space in SYN (eg timestamp
> discussion) *does* count as "step in the right direction" that help the
> TCP option space conservation. Another point which I wish to repeat is :
> when the discussions happened on this topic earlier, there was not a
> stronger use case for TCP option space, things have changed now
> (changing more as there are new TCP options evolving) and that may
> encourage different opinions on this topic. This is one of the other
> motivating factors for writing the draft. Of course I can see that your
> mileage varies here.

Your argument - and all its details - recurs in the IETF every 5-6 
years. The counterarguments that will kill this are:

	- the SYN is where space is really needed

	- saving space isn't sufficient; new space needs to be created

	- there is no backwards-compatible way to solve SYN extension

You can continue to try all possible combinations and hope there's a 
hole in that argument, but if that's your approach here, maybe you ought 
to let the WG know... that's not the same as a consensus solution.

>> PS- Regarding other imperfect solutions:
>>> .... For
>>> example TCP-AO would not work with NAT ALG's today, but didn't we
>>> write an RFC?
>>
>> FWIW, as noted during the design, a NAT ALG is an attack that TCP-AO
> is
>> intended to detect.
>
> Ah, you call it a "design choice", but the point is that it does not
> interoperate with a property of the middlebox. Period.

It does with the experimental extension I wrote. Period.

The only reason that's not in TCP-AO is the WG wasn't sure whether it 
was needed.

This was a design choice. It's not a protocol limitation.

Joe

From ananth@cisco.com  Mon Apr  2 18:24:42 2012
Return-Path: <ananth@cisco.com>
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 ED1B321F85F8 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 18:24:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.435
X-Spam-Level: 
X-Spam-Status: No, score=-10.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YhvbO8dz4it for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 18:24:41 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 14FF721F85CE for <tcpm@ietf.org>; Mon,  2 Apr 2012 18:24:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=4071; q=dns/txt; s=iport; t=1333416280; x=1334625880; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=eFDXlljjAByd9l+MtTzZJMevERRUXZTG8KOiXVcDNn4=; b=gdL9Zwz5x8WVUebJQ8UT8Anx87ciGIiABhn6+n1ioenQZEKV+7RNx0fQ upriWFgtfH6xOxRWyLbg/GRF341J5HIxL+MoiV4yoo0HvJ0ixDAc0v5Ls lmxiP4O+B9mZqdwH7VmMcY7xH773AeCIoimyesO+fwNde6sZhHGeItR/R s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAIlQek+rRDoJ/2dsb2JhbABDDrgCgQeCCQEBAQMBEgEdCj8QAgEIIgYYBgFWAQEEGxMHh2IEAaAmlzmQC2MEiFibUIFogjBX
X-IronPort-AV: E=Sophos;i="4.75,360,1330905600"; d="scan'208";a="35663799"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 03 Apr 2012 01:24:40 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q331Oe7r012024; Tue, 3 Apr 2012 01:24:40 GMT
Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 2 Apr 2012 18:24:40 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 2 Apr 2012 18:24:31 -0700
Message-ID: <1F8E0A684D3FF54680294BCFE57A7DB504C92D15@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <4F7A3514.5040804@isi.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
Thread-Index: Ac0RJ7q/0sZgqy35QW2fFrOIBENFswADQ4Ng
References: <012C3117EDDB3C4781FD802A8C27DD4F1533DE@SACEXCMBX02-PRD.hq.netapp.com> <4F7A149A.7050909@isi.edu> <1F8E0A684D3FF54680294BCFE57A7DB504C92C51@xmb-sjc-23e.amer.cisco.com> <4F7A2616.4090308@isi.edu> <1F8E0A684D3FF54680294BCFE57A7DB504C92C9A@xmb-sjc-23e.amer.cisco.com> <4F7A3514.5040804@isi.edu>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Joe Touch" <touch@isi.edu>
X-OriginalArrivalTime: 03 Apr 2012 01:24:40.0632 (UTC) FILETIME=[8AB12B80:01CD1138]
Cc: David Borman <dab@weston.borman.com>, tcpm@ietf.org, mallman@icir.org
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 01:24:42 -0000

<snip>

>=20
> We can classify it, but we can't get around it.
>=20
> >> It's provable that there is no SYN option extension that is
backward
> >> compatible. Non-backward compatible solutions are as trivial as the
> >> above, and as (not) useful.
> >
> > Please explain. If you read my draft I do list proposals that are
> > "backward compatible" w.r.t to end hosts.
>=20
> TCP is allowed - and supposed - to ignore options it doesn't
> understand.

That's obvious. I believe I have listed the shortcomings and analyzed
multiple solutions w.r.t to each property in the draft.

>=20
> An option in the SYN creates more option space, either by redefining
> the DO field (e.g., to have a scale beyond x4), or by specifically
> interpreting the SYN data as option.
>=20
> An endpoint that doesn't understand these legitimately ignores the
> option, and then interprets the extended space as data.
>=20
> Sending multiple SYNs has even more problems - how do you know how
long
> to wait to get all the ones you need? What happens when you get a set
> of SYNs that conflict? And what do NATs do with all these SYNs?

How long to wait, what happens if SYN's get dropped, arrive in different
order etc., has been discussed. The "happy eyeballs" scheme has some of
the issues. Not sure about the concern on NAT's since our NAT
implementations do handle duplicate SYN's. =20

<snip>

> > Well, I disagree here since we have not debated every solution  and
> > things like trying to save some option space in SYN (eg timestamp
> > discussion) *does* count as "step in the right direction" that help
> > the TCP option space conservation. Another point which I wish to
> repeat is :
> > when the discussions happened on this topic earlier, there was not a
> > stronger use case for TCP option space, things have changed now
> > (changing more as there are new TCP options evolving) and that may
> > encourage different opinions on this topic. This is one of the other
> > motivating factors for writing the draft. Of course I can see that
> > your mileage varies here.
>=20
> Your argument - and all its details - recurs in the IETF every 5-6
> years. The counterarguments that will kill this are:
>=20
> 	- the SYN is where space is really needed
>=20
> 	- saving space isn't sufficient; new space needs to be created
>=20
> 	- there is no backwards-compatible way to solve SYN extension
>=20
> You can continue to try all possible combinations and hope there's a
> hole in that argument, but if that's your approach here, maybe you
> ought to let the WG know... that's not the same as a consensus
> solution.

Well, the abstract already covers the intentions of the draft, IMO.

>=20
> >> PS- Regarding other imperfect solutions:
> >>> .... For
> >>> example TCP-AO would not work with NAT ALG's today, but didn't we
> >>> write an RFC?
> >>
> >> FWIW, as noted during the design, a NAT ALG is an attack that
TCP-AO
> > is
> >> intended to detect.
> >
> > Ah, you call it a "design choice", but the point is that it does not
> > interoperate with a property of the middlebox. Period.
>=20
> It does with the experimental extension I wrote. Period.

We are talking about NAT-ALG,  which looks at the TCP payload. In your
experimental extension, it simply gives provision to the basic NAT
functionality by not including the stuff which NAT munges around (IP
address and port) of the TCP/IP headers. (even that has practical
deployment issues since you never know where is a NAT unless you use
some neighbor discovery protocol)  It has no provision to circumvent the
NAT-ALG issues where you need to use the TCP DO offset to get to the
application payload and then fix the appropriate contents like FTP port
information etc., Repeat : this is the biggest headache for all TCP
option space proposals. Both TCP-AO and TCP option proposals *are*
susceptible to this issue for the sake of comparison. [ I may agree it
is not a fair comparison but in theory the issue is there]=20

-Anantha


From mallman@icir.org  Mon Apr  2 19:06:04 2012
Return-Path: <mallman@icir.org>
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 45C0221F8683 for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 19:06:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaD1iRD6XEin for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 19:06:03 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0B521F8658 for <tcpm@ietf.org>; Mon,  2 Apr 2012 19:06:03 -0700 (PDT)
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 q33261aV008288; Mon, 2 Apr 2012 19:06:01 -0700 (PDT)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9C36910F8358; Mon,  2 Apr 2012 22:06:01 -0400 (EDT)
To: Joe Touch <touch@isi.edu>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <4F7A149A.7050909@isi.edu> 
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Haircut
X-URL-0: http://www.icir.org/mallman-files/Document17319.pdf
X-URL-1: http://www.icir.org/mallman-files/Document93782.xls
X-URL-2: http://www.icir.org/mallman-files/Document36640.xlsx
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma23302-1"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 02 Apr 2012 22:06:01 -0400
Sender: mallman@icir.org
Message-Id: <20120403020601.9C36910F8358@lawyers.icir.org>
Cc: David Borman <dab@weston.borman.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
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 <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 02:06:04 -0000

----------ma23302-1
Content-Type: text/plain
Content-Disposition: inline


> Three observations:

I like powers of two (although, I had to stretch to get there!):

(0) Yes, there is only one ESTABLISHED, but WRT the timestamp option
    that is not germane.  Because of how timestamps work we can turn
    them on mid-stream pretty easily.  Borman sketched the scheme.  Turn
    them on in a data-carrying packet and watch for the ACK of that
    sequence number.  If it comes back with the expected timestamp we
    just verified the other end received it and echoed back the right
    thing and so is likely to play ball.  For some other option that
    doesn't have the same sort of echoing operation then I agree that
    reliability might be an issue.  But, for timestamps I think the path
    is pretty clear.

(1) Further, everything doesn't have to be negotiated in the SYN.  We
    have precedent for this.  E.g., DSACK is not negotiated in the SYN.
    If a host doesn't support DSACK then a DSACK SACK block will look
    pretty weird and nonsensical.  But, we evolved SACK without an
    explicit negotiation.  It seems at least plausible that we can
    change this one (**one***) thing about timestamps (when to start
    using them) in a similar fashion (*plausible*; see next point).

(2) We should know the failure cases.  As someone said, MPTCP stuff has
    shown that middleboxes don't much care about options.  Our work that
    I pointed to yesterday---which admittedly is a little old---shows
    that a TS in the middle of the stream without a TS in the SYN works
    just fine in the vast, vast majority of the cases.  If we go down
    this road someone should do the experiments to understand how often
    such a change will cause issues (connection crash, middlebox
    interaction, TS ignored, etc.).  But, I don't see any evidence that
    says we should take this off the table.

(4) More generally, I think if we decide we need more option space in
    the SYN it is fine to fire two SYNs (i.e., start two connections).
    I mean, its ugly and its a hack and it isn't ideal.  But, that
    pretty much describes the entirety of the world, right?  It would
    work.  Yeah, we'd have to decide some things about how long to wait
    and how to rip down the unneeded state and whatever.  But, it isn't
    like this is somehow science fiction.  So, we should stop saying
    this is just somehow impossible.

(5) You might not call it "TCP".  I might.  But, really, I don't much
    care.  I mean, its just arguing My Grandfather's Axe and so we might
    as well just get ourselves a couple of beers, belly up to the bar
    and dig into the finer points of axe heads, eh?  At the end of the
    day it doesn't matter if it's my Grandfather's axe or not as long as
    it chops the wood nobody gives a shit, right?

(6) I also agree with you that using the current space smarter is
    cleaner than trying to create new space.  But, also this has its
    limits.  I think timestamps in every packet on the *off chance* [*]
    that you'll need PAWS is just damn wasteful of the constrained
    resource.  We should be smarter.

    [*] Off chance: Sending at least 4GB **and** sending fast enough to
        cycle the sequence space fast enough for there to exist
        confusion about whether some sequence number is new or old.

(7) TCP timestamps as motivation for IPv6 ... man is IPv6 in some
    serious trouble! :-)

allman




----------ma23302-1
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iEYEARECAAYFAk96WwkACgkQWyrrWs4yIs4RWwCfWEMm6BGWDzKvROd7blm7yUOU
v28AnRAMmNHpwpnW4clHdLb/ndFBir/E
=FNqz
-----END PGP SIGNATURE-----
----------ma23302-1--

From mallman@icir.org  Mon Apr  2 19:09:31 2012
Return-Path: <mallman@icir.org>
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 A8DB521F875E for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 19:09:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuItwdu9ecJU for <tcpm@ietfa.amsl.com>; Mon,  2 Apr 2012 19:09:31 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 43F9021F875D for <tcpm@ietf.org>; Mon,  2 Apr 2012 19:09:31 -0700 (PDT)
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 q3329ULh008550; Mon, 2 Apr 2012 19:09:30 -0700 (PDT)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 69D3510FC2E3; Mon,  2 Apr 2012 22:09:30 -0400 (EDT)
To: Joe Touch <touch@isi.edu>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <4F79F355.2020000@isi.edu> 
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Haircut
X-URL-0: http://www.icir.org/mallman-files/Document6021.html
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma23513-1"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 02 Apr 2012 22:09:30 -0400
Sender: mallman@icir.org
Message-Id: <20120403020930.69D3510FC2E3@lawyers.icir.org>
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] IW10 & queuebloat
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 <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 02:09:31 -0000

----------ma23513-1
Content-Type: text/plain
Content-Disposition: inline


> IMO, experimental RFCs ought to require an explanation of the
> experiment expected.

I have made such comments sometimes.  But, I don't think IW10 needs
that.  I think the docs that need to sketch an experiment---at least on
the mailing list---are those for which the experiment isn't obvious.  It
seems pretty obvious what an IW10 experiment would try to get at.  Hell,
the WG has been looking at experiments involving IW10 for a long time
now. 

allman




----------ma23513-1
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iEYEARECAAYFAk96W9kACgkQWyrrWs4yIs4AOQCghRsDpy39AMMYnly1mNQEvIMl
pi0AnijarQ4gYBkBqux9Fs+jHPaoyO1P
=QmA6
-----END PGP SIGNATURE-----
----------ma23513-1--

From rs@netapp.com  Tue Apr  3 01:34:50 2012
Return-Path: <rs@netapp.com>
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 9F35121F861A for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 01:34:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.159
X-Spam-Level: 
X-Spam-Status: No, score=-10.159 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWU-z0jetKZq for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 01:34:49 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id A292C21F8619 for <tcpm@ietf.org>; Tue,  3 Apr 2012 01:34:49 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,362,1330934400"; d="scan'208";a="638173754"
Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 03 Apr 2012 01:34:49 -0700
Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q338YlA8007565; Tue, 3 Apr 2012 01:34:48 -0700 (PDT)
Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.76]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0247.003; Tue, 3 Apr 2012 01:34:37 -0700
From: "Scheffenegger, Richard" <rs@netapp.com>
To: Joe Touch <touch@isi.edu>, "Anantha Ramaiah (ananth)" <ananth@cisco.com>
Thread-Topic: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
Thread-Index: Ac0RCoq8TplyYNdFQxSPsKEZcZ7hMQARHdsAAAIiuYAAAHhBAAABpnKAAACVdgAAA9sd4A==
Date: Tue, 3 Apr 2012 08:34:37 +0000
Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F155682@SACEXCMBX02-PRD.hq.netapp.com>
References: <012C3117EDDB3C4781FD802A8C27DD4F1533DE@SACEXCMBX02-PRD.hq.netapp.com> <4F7A149A.7050909@isi.edu> <1F8E0A684D3FF54680294BCFE57A7DB504C92C51@xmb-sjc-23e.amer.cisco.com> <4F7A2616.4090308@isi.edu> <1F8E0A684D3FF54680294BCFE57A7DB504C92C9A@xmb-sjc-23e.amer.cisco.com> <4F7A3514.5040804@isi.edu>
In-Reply-To: <4F7A3514.5040804@isi.edu>
Accept-Language: de-AT, 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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: David Borman <dab@weston.borman.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "mallman@icir.org" <mallman@icir.org>
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 08:34:50 -0000

Hi Joe,

I think you confused me around what your point really is.

You say, during a connection, option space is not limited, there is no prob=
lem.

You mention, there is no way of reliably signaling options during a connect=
ion, so one cann't use that to move some options from a SYN down to later i=
n the connection.

You appear to be saying, saving space in the SYN option space is not a prop=
er solution.

Finally, you assess that there is no foolproof method of extending the SYN =
option space at all...

This leaves me to speculate, that what you are saying is that TCP is frozen=
 and we should tear down TCPM.

This sounds very depressing indeed.


However, if we can give precedent as to how to properly negotiate certain o=
ptions later during a connection (and IMHO, TS are an ideal candidate here =
as the encoding doesn't need to change; some stacks may already implicitly =
support this even due to "incomplete" implementation of all the checks), pe=
ople in need of more negotiated TCP options may have a framework they could=
 use without inventing the wheel over and over again. And true, perhaps a s=
eparate state machine is needed to track late option negotiation - to make =
sure the session ends up in a defined state.

Also, bundling some typically used options together and saving SYN option s=
pace thereby should also not be ruled out. You actually give a good example=
, even though I would probably encode MSS in the high bits (nibble) of the =
WS byte for some typical MSS values, and allowing the current options to be=
 present in addition, taking priority over the consolidated values (i.e. if=
 your MSS is odd,  you can bundle the consolidated option with an explicit =
option).

To me at least, that approach using consolidation and late negotiation appe=
ars as the path forward, as it won't violate current specs. Only middleboxe=
s too eager to lock down TCP in a frozen state may pose problems.

Richard Scheffenegger

> -----Original Message-----
> From: Joe Touch [mailto:touch@isi.edu]
> Sent: Dienstag, 03. April 2012 01:24
> To: Anantha Ramaiah (ananth)
> Cc: Scheffenegger, Richard; Andre Oppermann; David Borman;
> tcpm@ietf.org; mallman@icir.org
> Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option
> space extension.
>=20
> Amanth,
>=20
> Cutting things down a bit...
>=20
> On 4/2/2012 4:07 PM, Anantha Ramaiah (ananth) wrote:
> ...
> >> I disagree with the claim that there's a solution. Although no
> >> solutions are perfect, there are some that are simply not possible -
> >> this is one of them.
> >
> > "Simply not possible" - I am afraid that isn't the consensus.
>=20
> Consensus doesn't make it happen. A solution does, and no viable solution
> has been proposed.
>=20
> ...
> > For example you cited in one of your earlier post that "after SYN it
> > is not an issue, only getting it in SYN is problematic". Assuming you
> > really meant what you said, it means that if we can squeeze the ones
> > that needs to be negotiated in SYN and rest after the 3WHS then is is
> > ok.
>=20
> Yes, but then any rewriting middlebox that doesn't understand the option
> will ignore it and the options will move around and be intermingled with =
the
> data. That's not a viable alternative.
>=20
> > Then schemes like "sending multiple
> > SYN's", option encoding to save space etc., would come into play.
>=20
> Encoding to save space saves space; it doesn't create more space.
>=20
> Sending multiple SYNs isn't a solution either, as it would interact badly=
 with
> NATs.
>=20
>  > In
> > your earlier post you also cited that" it is ok if someone wants to
> > write a draft for extending TCP option space after SYN's" So, this is
> > again not complete but should serve as a intermediate step. [I guess
> > you are saying the same thing below]
>=20
> I also point out that this is a meaningless step for two reasons:
>=20
> 1) the key place where space is limited is the SYNs
>=20
> 2) such an option won't survive anything that rewrites segments
>=20
> >> The only possible solution is to extend the option for segments after
> >> the SYN using an option in the SYN
> >> 	1. at best that helps non-SYN segments
> >>
> >> 	2. it also has the easy potential to be
> >> 	corrupted by middleboxes
> >>
> >> 		corruption is both possible and currently likely
> >>
> >> 		corruption detection is impossible without adding
> >> 		(yet another) checksum, which slows things down
> >> 		at best
> >
> > Well, anything you do that alters the meaning of the TCP DO field is
> > susceptible for middlebox issues. The current draft gives examples and
> > classifies it based on the middlebox property (M1 to M6)
>=20
> We can classify it, but we can't get around it.
>=20
> >> It's provable that there is no SYN option extension that is backward
> >> compatible. Non-backward compatible solutions are as trivial as the
> >> above, and as (not) useful.
> >
> > Please explain. If you read my draft I do list proposals that are
> > "backward compatible" w.r.t to end hosts.
>=20
> TCP is allowed - and supposed - to ignore options it doesn't understand.
>=20
> An option in the SYN creates more option space, either by redefining the =
DO
> field (e.g., to have a scale beyond x4), or by specifically interpreting =
the SYN
> data as option.
>=20
> An endpoint that doesn't understand these legitimately ignores the option=
,
> and then interprets the extended space as data.
>=20
> Sending multiple SYNs has even more problems - how do you know how long
> to wait to get all the ones you need? What happens when you get a set of
> SYNs that conflict? And what do NATs do with all these SYNs?
>=20
> > Middleboxes does prove to be
> > an issue, but I believe I have listed proposals where which probably
> > has better chances with middle boxes but maybe less efficient.
> >
> >> Option compression reduces the current use of option space, but does
> >> nothing to extend it beyond 40.
> >>
> >> I see no point in reviving this. It'd be better to nail it shut and
> >> call it dead.
> >
> > Well, I disagree here since we have not debated every solution  and
> > things like trying to save some option space in SYN (eg timestamp
> > discussion) *does* count as "step in the right direction" that help
> > the TCP option space conservation. Another point which I wish to repeat=
 is :
> > when the discussions happened on this topic earlier, there was not a
> > stronger use case for TCP option space, things have changed now
> > (changing more as there are new TCP options evolving) and that may
> > encourage different opinions on this topic. This is one of the other
> > motivating factors for writing the draft. Of course I can see that
> > your mileage varies here.
>=20
> Your argument - and all its details - recurs in the IETF every 5-6 years.=
 The
> counterarguments that will kill this are:
>=20
> 	- the SYN is where space is really needed
>=20
> 	- saving space isn't sufficient; new space needs to be created
>=20
> 	- there is no backwards-compatible way to solve SYN extension
>=20
> You can continue to try all possible combinations and hope there's a hole=
 in
> that argument, but if that's your approach here, maybe you ought to let t=
he
> WG know... that's not the same as a consensus solution.
>=20
> >> PS- Regarding other imperfect solutions:
> >>> .... For
> >>> example TCP-AO would not work with NAT ALG's today, but didn't we
> >>> write an RFC?
> >>
> >> FWIW, as noted during the design, a NAT ALG is an attack that TCP-AO
> > is
> >> intended to detect.
> >
> > Ah, you call it a "design choice", but the point is that it does not
> > interoperate with a property of the middlebox. Period.
>=20
> It does with the experimental extension I wrote. Period.
>=20
> The only reason that's not in TCP-AO is the WG wasn't sure whether it was
> needed.
>=20
> This was a design choice. It's not a protocol limitation.
>=20
> Joe

From touch@isi.edu  Tue Apr  3 08:07:15 2012
Return-Path: <touch@isi.edu>
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 46ECC11E80CA for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 08:07:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkfowC3DE8s0 for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 08:07:14 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9F31C11E80C7 for <tcpm@ietf.org>; Tue,  3 Apr 2012 08:07:14 -0700 (PDT)
Received: from [192.168.1.95] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q33F4FaI015075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 3 Apr 2012 08:04:26 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Joe Touch <touch@isi.edu>
In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F155682@SACEXCMBX02-PRD.hq.netapp.com>
Date: Tue, 3 Apr 2012 08:04:18 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <DF70DB8D-411E-4B47-8014-0A4AC12AF780@isi.edu>
References: <012C3117EDDB3C4781FD802A8C27DD4F1533DE@SACEXCMBX02-PRD.hq.netapp.com> <4F7A149A.7050909@isi.edu> <1F8E0A684D3FF54680294BCFE57A7DB504C92C51@xmb-sjc-23e.amer.cisco.com> <4F7A2616.4090308@isi.edu> <1F8E0A684D3FF54680294BCFE57A7DB504C92C9A@xmb-sjc-23e.amer.cisco.com> <4F7A3514.5040804@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F155682@SACEXCMBX02-PRD.hq.netapp.com>
To: "Scheffenegger, Richard" <rs@netapp.com>
X-Mailer: Apple Mail (2.1257)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: David Borman <dab@weston.borman.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, "mallman@icir.org" <mallman@icir.org>
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 15:07:15 -0000

On Apr 3, 2012, at 1:34 AM, Scheffenegger, Richard wrote:

> Hi Joe,
>=20
> I think you confused me around what your point really is.
>=20
> You say, during a connection, option space is not limited, there is no =
problem.
>=20
> You mention, there is no way of reliably signaling options during a =
connection, so one cann't use that to move some options from a SYN down =
to later in the connection.
>=20
> You appear to be saying, saving space in the SYN option space is not a =
proper solution.
>=20
> Finally, you assess that there is no foolproof method of extending the =
SYN option space at all...
>=20
> This leaves me to speculate, that what you are saying is that TCP is =
frozen and we should tear down TCPM.

Well, you could also interpret that as "we've reached a place in TCPM =
where there are some areas of TCP that cannot be expanded without =
compromising ubiquity, backward compatibility, etc.". That shouldn't be =
surprising.

This is TCP, and we're in TCPM, not UTM (a universal Turning Machine).

> This sounds very depressing indeed.
>=20
>=20
> However, if we can give precedent as to how to properly negotiate =
certain options later during a connection (and IMHO, TS are an ideal =
candidate here as the encoding doesn't need to change; some stacks may =
already implicitly support this even due to "incomplete" implementation =
of all the checks), people in need of more negotiated TCP options may =
have a framework they could use without inventing the wheel over and =
over again. And true, perhaps a separate state machine is needed to =
track late option negotiation - to make sure the session ends up in a =
defined state.

We'd need to define a TWHS *inside* TCP to ensure that we handshake =
option negotiation after the initial TWHS. That's TCP on TCP. Yuk.

> Also, bundling some typically used options together and saving SYN =
option space thereby should also not be ruled out. You actually give a =
good example, even though I would probably encode MSS in the high bits =
(nibble) of the WS byte for some typical MSS values, and allowing the =
current options to be present in addition, taking priority over the =
consolidated values (i.e. if your MSS is odd,  you can bundle the =
consolidated option with an explicit option).

I didn't rule it out, I just said it had limited benefit. It won't =
result in more than 40 bytes of option space in a SYN.

FWIW, sending multiple SYNs will be incompatible with legacy endpoints =
unless every SYN includes the options needed for the legacy connection =
(since any SYN could get there first). What happens if the SYN options =
differ and you're talking to a legacy endpoint? How will you know which =
options are ackd, given the potential loss of SYN-ACKs? (the SYNs need =
to have the same ISNs or you risk having higher ISN SYNs reset the =
connection) Further, sending multiple SYNs kills the use of data (if you =
ACK the data, then the ISNs will need to increase, and then if they =
arrive in order they'll kill a legacy connection). Double-yuk.

> To me at least, that approach using consolidation and late negotiation =
appears as the path forward, as it won't violate current specs. Only =
middleboxes too eager to lock down TCP in a frozen state may pose =
problems.


My definition of TCP, however, requires:

	- is compatible with legacy TCPs in all current ways, i.e.,
		- allows SYN data
		- allows any existing TCP option, space permitting
		- connects with legacy TCPs with the first SYN

If any of the above aren't true (at least), it isn't TCP anymore.=20

Joe=

From touch@isi.edu  Tue Apr  3 08:50:22 2012
Return-Path: <touch@isi.edu>
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 214CD11E80B5 for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 08:50:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omfLb09v6Qde for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 08:50:21 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 79BFC11E80AE for <tcpm@ietf.org>; Tue,  3 Apr 2012 08:50:21 -0700 (PDT)
Received: from [192.168.1.95] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q33FnEch023025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 3 Apr 2012 08:49:24 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Joe Touch <touch@isi.edu>
In-Reply-To: <20120403020930.69D3510FC2E3@lawyers.icir.org>
Date: Tue, 3 Apr 2012 08:49:15 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <9B742845-F3B8-4B8C-A726-AF756DF49E24@isi.edu>
References: <20120403020930.69D3510FC2E3@lawyers.icir.org>
To: mallman@icir.org
X-Mailer: Apple Mail (2.1257)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] IW10 & queuebloat
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 15:50:22 -0000

On Apr 2, 2012, at 7:09 PM, Mark Allman wrote:

>=20
>> IMO, experimental RFCs ought to require an explanation of the
>> experiment expected.
>=20
> I have made such comments sometimes.  But, I don't think IW10 needs
> that.  I think the docs that need to sketch an experiment---at least =
on
> the mailing list---are those for which the experiment isn't obvious.  =
It
> seems pretty obvious what an IW10 experiment would try to get at.  =
Hell,
> the WG has been looking at experiments involving IW10 for a long time
> now.=20

FWIW, I'm talking about:

- how does an individual user know whether this is good or bad, and when =
to start/stop participating in the experiment?

- how will the IETF community gather some of that information?

If the argument is "try it" as an experiment, then the mere lack of =
explicit reports to the contrary will be taken as evidence it's safe (as =
per many "it's been deployed, so it's safe" arguments in this group in =
the past). That doesn't cut it.

I don't expect a scientist-level experiment, but at least a way for =
users to know when to play and when not, and a way for the community to =
have POSITIVE information (rather than the lack of negative) is needed =
here.

Joe=

From andre@freebsd.org  Tue Apr  3 09:25:00 2012
Return-Path: <andre@freebsd.org>
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 DAB9811E815C for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 09:25:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level: 
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_45=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLam48AT0jDD for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 09:25:00 -0700 (PDT)
Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by ietfa.amsl.com (Postfix) with ESMTP id 96FA111E8157 for <tcpm@ietf.org>; Tue,  3 Apr 2012 09:24:59 -0700 (PDT)
Received: (qmail 26629 invoked from network); 3 Apr 2012 16:23:13 -0000
Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender <andre@freebsd.org>) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for <rs@netapp.com>; 3 Apr 2012 16:23:13 -0000
Message-ID: <4F7B2458.9050503@freebsd.org>
Date: Tue, 03 Apr 2012 18:24:56 +0200
From: Andre Oppermann <andre@freebsd.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Scheffenegger, Richard" <rs@netapp.com>
References: <012C3117EDDB3C4781FD802A8C27DD4F1533DE@SACEXCMBX02-PRD.hq.netapp.com>
In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F1533DE@SACEXCMBX02-PRD.hq.netapp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: David Borman <dab@weston.borman.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, "mallman@icir.org" <mallman@icir.org>
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 16:25:01 -0000

On 02.04.2012 22:40, Scheffenegger, Richard wrote:
> Hi Andre,
>
> nice to hear from you!
>
> See inline
>
> Richard Scheffenegger
>
>>> The only thing that we really should verify is, if there are middleboxes that will actually
>>> terminate a TCP session, when all of a sudden the TS option appears... I hope this won't be
>>> the case, but it needs to be verified.
>>
>> It's really difficult to change the behavior of a system that was very clearly spelled out 20
>> years ago.  It's too ingrained everywhere, too many (rightful) assumptions have been made and
>> any change will just open a new can of worms.
>
> I think Joe rightfully said some time back, that we shouldn't limit ourselves by trying to work
> around implementation bugs in some stacks. The issue about the TCP SYN option space getting
> really scarce really fast now won't go away when we don't try to address this.

Unfortunately with this proposed change you end up with exactly
the opposite of what you're claiming here.  The timestamp option
is clearly defined as negotiated as SYN and ever after present
on all segments.  This has been implemented for 20 years.

Now you come around and want to change that in a way that probably
trips up enough compliant stacks and firewalls that it end with
a drama like the PMTU discovery saga on PPPoEoA DSL and filtered
ICMP needfrags.

Please don't.  The few bytes are not worth it.

>>> For a 1323bis, I think we should limit this late negotiation to timestamps for now; other
>>> options are really beneficial from the start (SACK, MPTCP,MSS), while stil others would
>>> require some definition of new semantics if late negotiation would be used (WS).
>>
>> I strongly recommend against changing RFC1323 timestamps in any way. Make it new options but
>> leave the current behavior as it is.
>
> Perhaps we need a new TCP option number and new semantics to address late negotiation. After all,
> the experiments conducted during MPTCP showed, that a majority of middleboxes won't fuss with
> unknown options once they are allowed through.  Perhaps we can get away by defining additional
> semantics to the current TCP TS option.

We even have trouble with the order of options on SYN segments.  What
makes you believe you can get away with anything?

> Right now, I think it is too early to make a facts-based decision either way.
>
> Therefore, I want to run some small-scale tests with TBIT against a bunch of popular OS and see
> how they react when TS show up in mid-connection...

Please do.  And then you test across a large deployed section of
middle-boxes doing NAT and firewalling and whatnot.

>>> * Window reduction during recovery bug - Matt
>>
>> ?
>
>> From my casual understanding (more knowledgeable people please correct my ignorance):
>
> When the receiver's buffer cannot be delivered up to the application, and at the same instance
> you have a loss; eventually, the receiver buffer will be announced as ("0"<<WS) [which is still
> 0], thus potentially preventing the sender from retransmitting the lost packet (because now it is
> outside the receive window), even though the actual receive window on the receiver side is still
> ("1"<<WS - 1) open...
>
> Basically a rounding-error due to the WS scale shifting.
>
> This suggested fix, as I understood it from Matt, is to either keep track of the largest receive
> window ever seen on the session, and use that for retransmissions, while the currently signaled
> receive window is used for newly injected packets; or use (Recv.Window + 1)<<  Recv.WSopt during
> retransmissions.
>
> Currently, such a stall may lead to a terminated session (ie. if the receiver app waits for a
> certain amount of data, that is blocked due to the retransmission never coming through because of
> the zero window advertised).

Agreed.

>>> * Enabling TS (PAWS) midstream - David, Matt, and others
>>
>> Disagreed due to interop issues.  The current behavior is engraved in stone in 20 years worth
>> of implementations of any kind.  We have enough trouble keeping TCP fully interoperable as it
>> is.  Don't add yet another fuzzy failure case.  Even worse that connections may suddenly fail
>> mid- transfer without anyone knowing why (because firefall gets tripped up).
>
> See comments above. As long as a middlebox only stops forwarding packets, but doesn't remove
> state or actively terminates sessions, a graceful retry may work so that the session is not
> completely stalled (ie. if a RTO occurs while trying to do delayed TS negotiation, stop trying to
> use TS on this session in the future; so we may need to define the state machine for delayed
> negotiation in some detail to cover (most) failure modes...

Too complex and brittle.  See comments above.

Finish up RFC1323bis to remove edge-cases and ambiguities from
RFC1323 and get it out of the door.  Then another experimental
RFC can be furbished exploring new behaviors.  There is no need
to bundle this together.  Actually it is harmful.

>> And don't forget that timestamps add some entropy to the already limited 32^2 sequence space.
>
> Must have been 2^32. Also note that may people don't deploy TS because of the perceived reduction
> in net bandwidth (~0,82% "slower" when doing dumb bulk transfer tests over "nice" links). Using
> "delayed" TS could happen quite far into "bulk" transfers, so that more sessions can make use of
> Timestamps once they need it, but don't have to carry the burden as long as they don't require
> TS. All the small object transfers up to 1 GB may be eligible to run without TS, if the server
> doesn't want to use TS heuristics for fast TCP Port recycling [but strictly speaking, that part
> is beyond the specs anyway].
>
>>> * References / interaction with SACK (TS check does not look if SACK is present - to cover
>>> certain cased of lost ACKs that inflate RTO) [?]
>>
>> The presence of SACK removes ambiguity from timestamps and also from the somewhat brittle
>> window update logic (see my long post from some two years ago).
>
> Well, I looked at one implementation of RTTM, and there was no check on the presence of SACKs
> there. Thus an ACK (containing a SACK block) after a lost ACK during forward loss will probably
> still inflate RTTvar and thus RTO; this is probably more of an issue with Karn's algorithm (as
> that is being referenced in RFC1323).

These things should be fleshed out in RFC1323bis.  Not new fancy
stuff of questionable value and deployability.

-- 
Andre

From mallman@icir.org  Tue Apr  3 09:27:02 2012
Return-Path: <mallman@icir.org>
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 19DA421F84C8 for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 09:27:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5L-arbYHpCv for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 09:27:01 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7F121F84BD for <tcpm@ietf.org>; Tue,  3 Apr 2012 09:27:01 -0700 (PDT)
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 q33GR01P026849; Tue, 3 Apr 2012 09:27:00 -0700 (PDT)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 0FECF110F69F; Tue,  3 Apr 2012 12:27:00 -0400 (EDT)
To: Joe Touch <touch@isi.edu>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <9B742845-F3B8-4B8C-A726-AF756DF49E24@isi.edu> 
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Low Rider
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma9427-1"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Tue, 03 Apr 2012 12:27:00 -0400
Sender: mallman@icir.org
Message-Id: <20120403162700.0FECF110F69F@lawyers.icir.org>
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] IW10 & queuebloat
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 <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 16:27:02 -0000

----------ma9427-1
Content-Type: text/plain
Content-Disposition: inline


> - how does an individual user know whether this is good or bad, and
>   when to start/stop participating in the experiment? 

They won't.

Even if you write something down in an RFC.

> - how will the IETF community gather some of that information?

Same way we have previously done when we advance things.  We look at the
available evidence and decide.


My vote: The experiment is obvious.  The document is fine without
sketching out experiments.

allman




----------ma9427-1
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iEYEARECAAYFAk97JNMACgkQWyrrWs4yIs7E5ACfYPzA8h8zHrrLqAPJqg99+Dyr
XcgAnRlj3DqcpXcSdNHY0isWXdI58RcH
=Q1mX
-----END PGP SIGNATURE-----
----------ma9427-1--

From andre@freebsd.org  Tue Apr  3 09:34:37 2012
Return-Path: <andre@freebsd.org>
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 BF3F911E8152 for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 09:34:37 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFd5b2wVbtkK for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 09:34:37 -0700 (PDT)
Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by ietfa.amsl.com (Postfix) with ESMTP id DEC8C11E8143 for <tcpm@ietf.org>; Tue,  3 Apr 2012 09:34:36 -0700 (PDT)
Received: (qmail 26675 invoked from network); 3 Apr 2012 16:32:52 -0000
Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender <andre@freebsd.org>) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for <ananth@cisco.com>; 3 Apr 2012 16:32:52 -0000
Message-ID: <4F7B269A.9050301@freebsd.org>
Date: Tue, 03 Apr 2012 18:34:34 +0200
From: Andre Oppermann <andre@freebsd.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
References: <012C3117EDDB3C4781FD802A8C27DD4F1533DE@SACEXCMBX02-PRD.hq.netapp.com> <4F7A149A.7050909@isi.edu> <1F8E0A684D3FF54680294BCFE57A7DB504C92C51@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <1F8E0A684D3FF54680294BCFE57A7DB504C92C51@xmb-sjc-23e.amer.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: David Borman <dab@weston.borman.com>, tcpm@ietf.org, mallman@icir.org, Joe Touch <touch@isi.edu>
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 16:34:37 -0000

On 03.04.2012 00:06, Anantha Ramaiah (ananth) wrote:
>
>> Do we really need to go around this block again?
>
> Answer : Yes, please see the motivation section of the document.

Please decouple much needed progress on RFC1323bis to clarify
implementation issues and edge cases from the whole TCP options
space debate!  Different wars!

-- 
Andre

From ananth@cisco.com  Tue Apr  3 10:01:50 2012
Return-Path: <ananth@cisco.com>
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 7AE2721F85AE for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 10:01:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.455
X-Spam-Level: 
X-Spam-Status: No, score=-10.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjdrlHTZwc1F for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 10:01:49 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 99BF721F85B7 for <tcpm@ietf.org>; Tue,  3 Apr 2012 10:01:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=360; q=dns/txt; s=iport; t=1333472509; x=1334682109; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=8rRxtoPqIlRMKhOXtmZ1aJZCx/+vdcsgDSxAiWgLEfI=; b=Da89V/vawEVWIfJr1Z/mXI7L8Gj4M1enuPIuxhcDwYCuaUl4p3oQqLd1 VRzBjYzfUzD3CjFvPPgMbaBAFyuH2qTjriaZnt40/dzcwvHoYpSLJj1KN 6o8PJ/AhbXjvChozOWjMqbrROO3ttaqPXtoDmysGUXVvOJdZB1xfW8GF3 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAO8re0+rRDoG/2dsb2JhbABDuBKBB4IJAQEBAwESAR0KPxACAQgiBhgGAVYBAQQbGodiBAGfeZcYkANjBIhYm1KBaYMH
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="36298578"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 03 Apr 2012 17:01:43 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q33H1gsD024674; Tue, 3 Apr 2012 17:01:43 GMT
Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 3 Apr 2012 10:01:42 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 3 Apr 2012 10:01:41 -0700
Message-ID: <1F8E0A684D3FF54680294BCFE57A7DB504C92F36@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <4F7B269A.9050301@freebsd.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
Thread-Index: Ac0Rt6rdfsRm+Vm/TNGSdOlXIvO1lAAAG8zg
References: <012C3117EDDB3C4781FD802A8C27DD4F1533DE@SACEXCMBX02-PRD.hq.netapp.com> <4F7A149A.7050909@isi.edu> <1F8E0A684D3FF54680294BCFE57A7DB504C92C51@xmb-sjc-23e.amer.cisco.com> <4F7B269A.9050301@freebsd.org>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Andre Oppermann" <andre@freebsd.org>
X-OriginalArrivalTime: 03 Apr 2012 17:01:42.0807 (UTC) FILETIME=[71B84270:01CD11BB]
Cc: David Borman <dab@weston.borman.com>, tcpm@ietf.org, mallman@icir.org, Joe Touch <touch@isi.edu>
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 17:01:50 -0000

> >> Do we really need to go around this block again?
> >
> > Answer : Yes, please see the motivation section of the document.
>=20
> Please decouple much needed progress on RFC1323bis to clarify
> implementation issues and edge cases from the whole TCP options space
> debate!  Different wars!

Makes sense, these issues are not related.

-Anantha

From andre@freebsd.org  Tue Apr  3 10:04:56 2012
Return-Path: <andre@freebsd.org>
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 4C0FF21F8734 for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 10:04:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+To6W+6EZ5n for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 10:04:55 -0700 (PDT)
Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECCE21F85F7 for <tcpm@ietf.org>; Tue,  3 Apr 2012 10:04:55 -0700 (PDT)
Received: (qmail 26829 invoked from network); 3 Apr 2012 17:03:08 -0000
Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender <andre@freebsd.org>) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for <jishac@nasa.gov>; 3 Apr 2012 17:03:08 -0000
Message-ID: <4F7B2DB3.20200@freebsd.org>
Date: Tue, 03 Apr 2012 19:04:51 +0200
From: Andre Oppermann <andre@freebsd.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Joseph Ishac <jishac@nasa.gov>
References: <201203301322.q2UDMIcc009352@bagheera.jungle.bt.co.uk> <4F79F355.2020000@isi.edu> <4F7A0407.8090105@isi.edu> <CANPnThZ9gB23p3SCpUPKMJRwog4=271z1Top4z6LWpZ9XvzkMw@mail.gmail.com>
In-Reply-To: <CANPnThZ9gB23p3SCpUPKMJRwog4=271z1Top4z6LWpZ9XvzkMw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tcpm IETF list <tcpm@ietf.org>, "mallman@icir.org" <mallman@icir.org>, Joe Touch <touch@isi.edu>
Subject: Re: [tcpm] IW10 & queuebloat
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 17:04:56 -0000

On 03.04.2012 00:02, Joseph Ishac wrote:
> On Mon, Apr 02, 2012 at 02:54:47PM -0500, Joe Touch wrote:
>>> which part in our draft talks the point you mentioned? we'll be happy
>>> to correct it.
>>>
>>> """
>>> 2.  TCP Modification
>>>
>>>      This document proposes an increase in the permitted upper bound for
>>>      TCP's initial window (IW) to 10 segments depending on the MSS. This
>>>      increase is optional: a TCP MAY start with an initial window that is
>>>      smaller than 10 segments.
>>>
>>>      More precisely, the upper bound for the initial window will be
>>>
>>>            min (10*MSS, max (2*MSS, 14600))                            (1)
>>> """
>>>
>>> """
>>> 12. Usage and Deployment Recommendations
>>>
>>>      Further experiments are required before a larger initial window shall
>>>      be enabled by default in the Internet. The existing measurement
>>>      results indicate that this does not cause significant harm to other
>>>      traffic. However, widespread use in the Internet could reveal issues
>>>      not known yet, e.g., regarding fairness or impact on latency-
>>>      sensitive traffic such as VoIP.
>>> """
>>
>> This is inconsistent with the following, from the Intro:
>>
>>      We recommend that all TCP implementations have a settable TCP IW
>>      parameter. As of 2011 an appropriate value for this parameter is 10
>>      segments as long as there is a reasonable effort to monitor for
>>      possible interactions with other Internet applications and services.
>>      Furthermore, it is understood that the appropriate value for IW is
>>      likely to continue to rise in the future, but this document does not
>>      include any supporting evidence for larger values of IW.
>
> I assume the contention is with the word "all"?

I'm very uneasy with arbitrary user-settable numeric IW parameters.

Half-knowledge abounds in user-circles and I see too many users and
sysadmins randomly cranking up every possible network related value
under the assumption that it makes it "faster" and "better".  l33t

With arbitrary IW values this backfires in a big and very non-obvious
way.  I'm all for letting people shoot into their own foot, however
in this case they are into shooting everbody else's foot as well without
being aware of it.  Upon that at least partial congestion collapse follows.
I can already hear the ringing of 1982 calling the phone booth down the road.

The Internet and TCP only survives (and survived) because of the
cooperative restraint of a very large majority of the participants.
If more than just a few give up the restraint we have the tragedy
of the commons again.  This we supposedly learned early in the 80's
after some troublesome times with little goodput.  Lets not break it
too easily again.

-- 
Andre


From touch@isi.edu  Tue Apr  3 10:32:23 2012
Return-Path: <touch@isi.edu>
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 2169811E8095 for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 10:32:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.028
X-Spam-Level: 
X-Spam-Status: No, score=-104.028 tagged_above=-999 required=5 tests=[AWL=-1.429, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAOvS5e9h61s for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 10:32:22 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 8398D11E808C for <tcpm@ietf.org>; Tue,  3 Apr 2012 10:32:22 -0700 (PDT)
Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q33HW6R9004744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Apr 2012 10:32:07 -0700 (PDT)
Message-ID: <4F7B3416.3010100@isi.edu>
Date: Tue, 03 Apr 2012 10:32:06 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: mallman@icir.org
References: <20120403020601.9C36910F8358@lawyers.icir.org>
In-Reply-To: <20120403020601.9C36910F8358@lawyers.icir.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: David Borman <dab@weston.borman.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 17:32:23 -0000

On 4/2/2012 7:06 PM, Mark Allman wrote:
>
>> Three observations:
>
> I like powers of two (although, I had to stretch to get there!):
>
> (0) Yes, there is only one ESTABLISHED, but WRT the timestamp option
>      that is not germane.  Because of how timestamps work we can turn
>      them on mid-stream pretty easily.

IMO, if timestamps are optional on a per-packet basis, this is fine. 
That's not changing "state" mid-stream, though.

>	... Borman sketched the scheme.  Turn
>      them on in a data-carrying packet and watch for the ACK of that
>      sequence number.

Hmm. That presumes:
	a) that midbox devices preserve sequence numbers in TCP headers
	(they don't necessarily when they rewrite the stream)

	b) the endpoints keep per-segment state (retain a list of
	sequence numbers with timestamps)

	c) TCP sends back ACKs with sequence numbers that match the
	packets sent (which they are NOT required to do at all).

These are all highly problematic, IMO.

...
> (1) Further, everything doesn't have to be negotiated in the SYN.
...

	Sure. You can then create a TWHS for anything later - on top
	of the ESTABLISHED state.

	This doesn't hold for options that are 'optional' at any time;
	for those, you don't need to negotiate when to enable them, and
	how to handle segments that come out of order that don't yet
	support them vs. later ones that might.

> (2) We should know the failure cases.  As someone said, MPTCP stuff has
>      shown that middleboxes don't much care about options.  Our work that
>      I pointed to yesterday---which admittedly is a little old---shows
>      that a TS in the middle of the stream without a TS in the SYN works
>      just fine in the vast, vast majority of the cases.
...

	Operational evidence that something works doesn't mean that it's
	OK; it means you haven't found an implementation that doesn't
	work. That's a dangerous way to extend TCP.

> (4) More generally, I think if we decide we need more option space in
>      the SYN it is fine to fire two SYNs (i.e., start two connections).
...

	If you intend this to work with legacy TCP, then the options
	you need to have for legacy connections need to be in BOTH SYNs.

	You also can't have data in either SYN, because if you do the
	sequence number will increase, the other SYN will be interpreted
	as out of window, and it will kill the connection.

	You also need to copy the ISNs (same reason as above).

	You also need to ensure that the old SYNs are out of the net
	before you start using the connection for data, or the old SYN
	will kill the connection.

	That's a partial list of the problems. So this interferes with
	legacy TCP way too much, IMO.

> (5) You might not call it "TCP".  I might. ...

	IMO, TCP options need to play nice with other TCP options.

	Any option that doesn't isn't TCP anymore. We saw a recent
	proposal for a protocol that uses TCP's protocol number
	and a few key fields, but isn't TCP.

	If that's where you're going, please take the work outside TCPM
	at least.

> (6) I also agree with you that using the current space smarter is
>      cleaner than trying to create new space.  But, also this has its
>      limits.  I think timestamps in every packet on the *off chance* [*]
>      that you'll need PAWS is just damn wasteful of the constrained
>      resource.  We should be smarter.

Timestamps are starting to be used for a lot of other things (time-wait 
issues, randomness in various seeds, etc.). Be careful before calling 
them optional all over the place.

> (7) TCP timestamps as motivation for IPv6 ... man is IPv6 in some
>      serious trouble! :-)

I never said this, but yes, and not just for that reason ;-)

Joe

From fgont@si6networks.com  Tue Apr  3 10:47:10 2012
Return-Path: <fgont@si6networks.com>
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 7713E21F869A for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 10:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHC36S7mWChA for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 10:47:10 -0700 (PDT)
Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id B364121F8698 for <tcpm@ietf.org>; Tue,  3 Apr 2012 10:47:09 -0700 (PDT)
Received: from static-qvn-qvu-166143.business.bouyguestelecom.com ([89.81.166.143] helo=[192.168.101.213]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <fgont@si6networks.com>) id 1SF7on-0001nR-23; Tue, 03 Apr 2012 19:46:57 +0200
Message-ID: <4F7B3788.2050106@si6networks.com>
Date: Tue, 03 Apr 2012 19:46:48 +0200
From: Fernando Gont <fgont@si6networks.com>
Organization: SI6 Networks
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>
References: <20120403020601.9C36910F8358@lawyers.icir.org> <4F7B3416.3010100@isi.edu>
In-Reply-To: <4F7B3416.3010100@isi.edu>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: David Borman <dab@weston.borman.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, mallman@icir.org
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 17:47:10 -0000

Hi, Joe,

A few comments...

On 04/03/2012 07:32 PM, Joe Touch wrote:
>>     ... Borman sketched the scheme.  Turn
>>      them on in a data-carrying packet and watch for the ACK of that
>>      sequence number.
> 
> Hmm. That presumes:
>     a) that midbox devices preserve sequence numbers in TCP headers
>     (they don't necessarily when they rewrite the stream)

Does this matter? SEQ-rewrite is transparent to the endpoint (for
instance, that's why it can actually work). Am I missing something?



>     b) the endpoints keep per-segment state (retain a list of
>     sequence numbers with timestamps)

Yes, this is what Borman said, IIRC.



>     c) TCP sends back ACKs with sequence numbers that match the
>     packets sent (which they are NOT required to do at all).

Not necessarily. You simply stick the option to a sequence number, and
resend the option whenever that sequence number is resent -- and stop
sending the option when that SEQ has been ack'ed.



>> (4) More generally, I think if we decide we need more option space in
>>      the SYN it is fine to fire two SYNs (i.e., start two connections).
> ...
> 
>     If you intend this to work with legacy TCP, then the options
>     you need to have for legacy connections need to be in BOTH SYNs.
> 
>     You also can't have data in either SYN, because if you do the
>     sequence number will increase, 

IIRC, some implementations can't handle data in the SYN, anyway. -- not
to mention that SYN-cookies don't support data in the SYN.


> the other SYN will be interpreted
>     as out of window, and it will kill the connection.

No. It will be considered a stale segment, and an ACK will be sent. It's
*in window* SYNs that kill the connections.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




From rs@netapp.com  Tue Apr  3 11:32:26 2012
Return-Path: <rs@netapp.com>
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 2BB3821F8692 for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 11:32:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.571
X-Spam-Level: 
X-Spam-Status: No, score=-9.571 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPHSswWpcfL6 for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 11:32:25 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6878221F8688 for <tcpm@ietf.org>; Tue,  3 Apr 2012 11:32:25 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,364,1330934400"; d="scan'208";a="638329555"
Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 03 Apr 2012 11:32:25 -0700
Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q33IWNic029229; Tue, 3 Apr 2012 11:32:23 -0700 (PDT)
Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.76]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0247.003; Tue, 3 Apr 2012 11:32:14 -0700
From: "Scheffenegger, Richard" <rs@netapp.com>
To: Andre Oppermann <andre@freebsd.org>, "Anantha Ramaiah (ananth)" <ananth@cisco.com>
Thread-Topic: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
Thread-Index: Ac0RCoq8TplyYNdFQxSPsKEZcZ7hMQARHdsAAAIiuYAAJrGMAAAK4GNw
Date: Tue, 3 Apr 2012 18:32:12 +0000
Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F157B35@SACEXCMBX02-PRD.hq.netapp.com>
References: <012C3117EDDB3C4781FD802A8C27DD4F1533DE@SACEXCMBX02-PRD.hq.netapp.com> <4F7A149A.7050909@isi.edu> <1F8E0A684D3FF54680294BCFE57A7DB504C92C51@xmb-sjc-23e.amer.cisco.com> <4F7B269A.9050301@freebsd.org>
In-Reply-To: <4F7B269A.9050301@freebsd.org>
Accept-Language: de-AT, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.104.60.116]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Joe Touch <touch@isi.edu>, David Borman <dab@weston.borman.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "mallman@icir.org" <mallman@icir.org>
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 18:32:26 -0000

Agreed!=20

>From what I have read in 1323bis, these are the things which need some poli=
sh:

Only a few nits and all the necessary boilerplate updates before a new vers=
ion could be posted and discussed in the WG; (with or without the stuff men=
tioned below:)


The SACK interaction (ignoring TS whenever SACK is present during RTTM) is =
not yet described (even though presence of a SACK, except DSACK, is an indi=
cation of loss);

A few historic RFC references could potentially be removed (they are alread=
y in RFC1323).=20

The Window Reduction Bug described may warrant a more specific wording for =
implementers than what is currently in 1323bis (reference to 1122...)

Updating some references ie 5681 instead 2581 for TCP congestion control.


The discussion around TS extensions really is something for a dedicated exp=
erimental draft later -> exclude in 1323bis, that needs to be proposed stan=
dard.


Richard Scheffenegger

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of
> Andre Oppermann
> Sent: Dienstag, 03. April 2012 18:35
> To: Anantha Ramaiah (ananth)
> Cc: David Borman; tcpm@ietf.org; mallman@icir.org; Joe Touch
> Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option
> space extension.
>=20
> On 03.04.2012 00:06, Anantha Ramaiah (ananth) wrote:
> >
> >> Do we really need to go around this block again?
> >
> > Answer : Yes, please see the motivation section of the document.
>=20
> Please decouple much needed progress on RFC1323bis to clarify
> implementation issues and edge cases from the whole TCP options space
> debate!  Different wars!
>=20
> --
> Andre
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

From andre@freebsd.org  Tue Apr  3 11:52:13 2012
Return-Path: <andre@freebsd.org>
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 E58DD21F85E6 for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 11:52:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.479
X-Spam-Level: 
X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WA14s3kEXPq4 for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 11:52:12 -0700 (PDT)
Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6764A21F84D0 for <tcpm@ietf.org>; Tue,  3 Apr 2012 11:52:11 -0700 (PDT)
Received: (qmail 27295 invoked from network); 3 Apr 2012 18:50:18 -0000
Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender <andre@freebsd.org>) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for <touch@isi.edu>; 3 Apr 2012 18:50:18 -0000
Message-ID: <4F7B46D1.7040502@freebsd.org>
Date: Tue, 03 Apr 2012 20:52:01 +0200
From: Andre Oppermann <andre@freebsd.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>
References: <20120403020601.9C36910F8358@lawyers.icir.org> <4F7B3416.3010100@isi.edu>
In-Reply-To: <4F7B3416.3010100@isi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: David Borman <dab@weston.borman.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, mallman@icir.org
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 18:52:13 -0000

On 03.04.2012 19:32, Joe Touch wrote:
> On 4/2/2012 7:06 PM, Mark Allman wrote:
>> (6) I also agree with you that using the current space smarter is
>> cleaner than trying to create new space. But, also this has its
>> limits. I think timestamps in every packet on the *off chance* [*]
>> that you'll need PAWS is just damn wasteful of the constrained
>> resource. We should be smarter.
>
> Timestamps are starting to be used for a lot of other things (time-wait issues, randomness in
> various seeds, etc.). Be careful before calling them optional all over the place.

Full ACK.

-- 
Andre


From andre@freebsd.org  Tue Apr  3 12:07:43 2012
Return-Path: <andre@freebsd.org>
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 CE2CB21F8646 for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 12:07:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level: 
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z68mxtuV5kcL for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 12:07:43 -0700 (PDT)
Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD0E11E817A for <tcpm@ietf.org>; Tue,  3 Apr 2012 12:07:38 -0700 (PDT)
Received: (qmail 27406 invoked from network); 3 Apr 2012 19:05:52 -0000
Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender <andre@freebsd.org>) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for <touch@isi.edu>; 3 Apr 2012 19:05:52 -0000
Message-ID: <4F7B4A77.7060203@freebsd.org>
Date: Tue, 03 Apr 2012 21:07:35 +0200
From: Andre Oppermann <andre@freebsd.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>
References: <20120403020601.9C36910F8358@lawyers.icir.org> <4F7B3416.3010100@isi.edu> <4F7B46D1.7040502@freebsd.org>
In-Reply-To: <4F7B46D1.7040502@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: David Borman <dab@weston.borman.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, mallman@icir.org
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 19:07:44 -0000

On 03.04.2012 20:52, Andre Oppermann wrote:
> On 03.04.2012 19:32, Joe Touch wrote:
>> On 4/2/2012 7:06 PM, Mark Allman wrote:
>>> (6) I also agree with you that using the current space smarter is
>>> cleaner than trying to create new space. But, also this has its
>>> limits. I think timestamps in every packet on the *off chance* [*]
>>> that you'll need PAWS is just damn wasteful of the constrained
>>> resource. We should be smarter.
>>
>> Timestamps are starting to be used for a lot of other things (time-wait issues, randomness in
>> various seeds, etc.). Be careful before calling them optional all over the place.
>
> Full ACK.

Bringing up another angle:

Every congestion control algorithm that wants to take delay changes
into consideration depends on RTTM for high precision and frequency
feedback.  That's why we should allow it to be updated in the case
of retransmits in the presence of SACK.

The RTO calculation doesn't need the high frequency measurements and
could do with once or a couple of time per RTT.

-- 
Andre

From touch@isi.edu  Tue Apr  3 12:45:04 2012
Return-Path: <touch@isi.edu>
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 C3B5011E80E3 for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 12:45:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.849
X-Spam-Level: 
X-Spam-Status: No, score=-103.849 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x23NazMwMCIO for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 12:45:04 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id F061A11E80AE for <tcpm@ietf.org>; Tue,  3 Apr 2012 12:45:03 -0700 (PDT)
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 q33JiSuk004187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Apr 2012 12:44:28 -0700 (PDT)
Message-ID: <4F7B531C.2030403@isi.edu>
Date: Tue, 03 Apr 2012 12:44:28 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Andre Oppermann <andre@freebsd.org>
References: <20120403020601.9C36910F8358@lawyers.icir.org> <4F7B3416.3010100@isi.edu> <4F7B46D1.7040502@freebsd.org>
In-Reply-To: <4F7B46D1.7040502@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: David Borman <dab@weston.borman.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, mallman@icir.org
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 19:45:04 -0000

PS - why not compress timestamps?

Send only the low byte in both directions; treat the high bytes as 
either phantoms or sent only as needed / periodically (as we did with 
64-bit seqnos in TCP-AO).

That would save 6 of the 10 bytes for most of the packets (if not nearly 
all of them). That's most of the bang for the buck. Ultimately, if you 
compress whatever set of options you expect together as a single field, 
you'll knock off another 2 as well, so that TS maintenance costs only 2 
bytes per packet.

Joe

On 4/3/2012 11:52 AM, Andre Oppermann wrote:
> On 03.04.2012 19:32, Joe Touch wrote:
>> On 4/2/2012 7:06 PM, Mark Allman wrote:
>>> (6) I also agree with you that using the current space smarter is
>>> cleaner than trying to create new space. But, also this has its
>>> limits. I think timestamps in every packet on the *off chance* [*]
>>> that you'll need PAWS is just damn wasteful of the constrained
>>> resource. We should be smarter.
>>
>> Timestamps are starting to be used for a lot of other things
>> (time-wait issues, randomness in
>> various seeds, etc.). Be careful before calling them optional all over
>> the place.
>
> Full ACK.
>

From andre@freebsd.org  Tue Apr  3 12:59:02 2012
Return-Path: <andre@freebsd.org>
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 B5C6811E8111 for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 12:59:02 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xfe7nuepc1iS for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 12:59:02 -0700 (PDT)
Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by ietfa.amsl.com (Postfix) with ESMTP id BE65211E80C6 for <tcpm@ietf.org>; Tue,  3 Apr 2012 12:59:01 -0700 (PDT)
Received: (qmail 27674 invoked from network); 3 Apr 2012 19:57:14 -0000
Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender <andre@freebsd.org>) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for <rs@netapp.com>; 3 Apr 2012 19:57:14 -0000
Message-ID: <4F7B5682.5000509@freebsd.org>
Date: Tue, 03 Apr 2012 21:58:58 +0200
From: Andre Oppermann <andre@freebsd.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Scheffenegger, Richard" <rs@netapp.com>
References: <012C3117EDDB3C4781FD802A8C27DD4F1533DE@SACEXCMBX02-PRD.hq.netapp.com> <4F7A149A.7050909@isi.edu> <1F8E0A684D3FF54680294BCFE57A7DB504C92C51@xmb-sjc-23e.amer.cisco.com> <4F7B269A.9050301@freebsd.org> <012C3117EDDB3C4781FD802A8C27DD4F157B35@SACEXCMBX02-PRD.hq.netapp.com>
In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F157B35@SACEXCMBX02-PRD.hq.netapp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Joe Touch <touch@isi.edu>, David Borman <dab@weston.borman.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, "mallman@icir.org" <mallman@icir.org>
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 19:59:02 -0000

On 03.04.2012 20:32, Scheffenegger, Richard wrote:
>
> Agreed!
>
>> From what I have read in 1323bis, these are the things which need some polish:
>
> Only a few nits and all the necessary boilerplate updates before a new version could be posted
> and discussed in the WG; (with or without the stuff mentioned below:)
>
>
> The SACK interaction (ignoring TS whenever SACK is present during RTTM) is not yet described
> (even though presence of a SACK, except DSACK, is an indication of loss);
>
> A few historic RFC references could potentially be removed (they are already in RFC1323).
>
> The Window Reduction Bug described may warrant a more specific wording for implementers than what
> is currently in 1323bis (reference to 1122...)
>
> Updating some references ie 5681 instead 2581 for TCP congestion control.
>
>
> The discussion around TS extensions really is something for a dedicated experimental draft later
> ->  exclude in 1323bis, that needs to be proposed standard.

Full ACK to all of them.

-- 
Andre

> Richard Scheffenegger
>
>> -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf
>> Of Andre Oppermann Sent: Dienstag, 03. April 2012 18:35 To: Anantha Ramaiah (ananth) Cc: David
>> Borman; tcpm@ietf.org; mallman@icir.org; Joe Touch Subject: Re: [tcpm] Timestamps rejuvenated
>> was: A new ID on TCP option space extension.
>>
>> On 03.04.2012 00:06, Anantha Ramaiah (ananth) wrote:
>>>
>>>> Do we really need to go around this block again?
>>>
>>> Answer : Yes, please see the motivation section of the document.
>>
>> Please decouple much needed progress on RFC1323bis to clarify implementation issues and edge
>> cases from the whole TCP options space debate!  Different wars!
>>
>> -- Andre _______________________________________________ tcpm mailing list tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>
>


From ananth@cisco.com  Tue Apr  3 13:32:09 2012
Return-Path: <ananth@cisco.com>
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 4AB0111E8201 for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 13:32:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.471
X-Spam-Level: 
X-Spam-Status: No, score=-10.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vkqcbzuCybp for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 13:32:08 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 984BE11E81FF for <tcpm@ietf.org>; Tue,  3 Apr 2012 13:32:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=2088; q=dns/txt; s=iport; t=1333485128; x=1334694728; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Hq7CgEt9RgRr+4FxVMTLOvvELmenLwfXkmagSME+UM0=; b=kbv02V7oDb6Q8bpQmc2aBazLf5XUGrfnrl1QFGyOAMuVOxg2Kn6xip5d Ri1xvv9UyswnYe7p16m0xKvBYNNRZMZnV7RdVwOL83ApMUsjwPa8EzEM3 P+xeOW7Ns0xqtrxkac9RyKjkl+Y2gPZ6AQEl78/kPT6xw7BV7aldXfLAJ 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAJZde0+rRDoJ/2dsb2JhbABFDrgHgQeCCQEBAQMBEgEdCj8MBAIBCBEEAQEBCgYXAQYBRQkIAQEEARIIGodiBAGbQp53kANjBIhYm1KBaYIwVw
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="38915968"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 03 Apr 2012 20:32:08 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q33KW8X7015905; Tue, 3 Apr 2012 20:32:08 GMT
Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 3 Apr 2012 13:32:08 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 3 Apr 2012 13:32:07 -0700
Message-ID: <1F8E0A684D3FF54680294BCFE57A7DB504C9307B@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <4F7B531C.2030403@isi.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
Thread-Index: Ac0R0kHJQ6X/rnBQTKS1b2vk7bLcmQABIjWw
References: <20120403020601.9C36910F8358@lawyers.icir.org> <4F7B3416.3010100@isi.edu> <4F7B46D1.7040502@freebsd.org> <4F7B531C.2030403@isi.edu>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Joe Touch" <touch@isi.edu>, "Andre Oppermann" <andre@freebsd.org>
X-OriginalArrivalTime: 03 Apr 2012 20:32:08.0083 (UTC) FILETIME=[D6F87E30:01CD11D8]
Cc: David Borman <dab@weston.borman.com>, tcpm@ietf.org, mallman@icir.org
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 20:32:09 -0000

> -----Original Message-----
> From: Joe Touch [mailto:touch@isi.edu]
> Sent: Tuesday, April 03, 2012 12:44 PM
> To: Andre Oppermann
> Cc: mallman@icir.org; David Borman; tcpm@ietf.org; Anantha Ramaiah
> (ananth)
> Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option
> space extension.
>=20
> PS - why not compress timestamps?

???
In one your earlier posts you said :-

<Begin Quote>
Option compression reduces the current use of option space, but does
nothing to extend it beyond 40.

I see no point in reviving this. It'd be better to nail it shut and call
it dead.

<End Quote>

I should be glad that at least you are now thinking in the right
direction :-) Since you won't be suggesting this if does not buy us
anything, after all we are talking about different ways to conserve TCP
option space!

-Anantha

>=20
> Send only the low byte in both directions; treat the high bytes as
> either phantoms or sent only as needed / periodically (as we did with
> 64-bit seqnos in TCP-AO).
>=20
> That would save 6 of the 10 bytes for most of the packets (if not
> nearly all of them). That's most of the bang for the buck. Ultimately,
> if you compress whatever set of options you expect together as a
single
> field, you'll knock off another 2 as well, so that TS maintenance
costs
> only 2 bytes per packet.
>=20
> Joe
>=20
> On 4/3/2012 11:52 AM, Andre Oppermann wrote:
> > On 03.04.2012 19:32, Joe Touch wrote:
> >> On 4/2/2012 7:06 PM, Mark Allman wrote:
> >>> (6) I also agree with you that using the current space smarter is
> >>> cleaner than trying to create new space. But, also this has its
> >>> limits. I think timestamps in every packet on the *off chance* [*]
> >>> that you'll need PAWS is just damn wasteful of the constrained
> >>> resource. We should be smarter.
> >>
> >> Timestamps are starting to be used for a lot of other things
> >> (time-wait issues, randomness in
> >> various seeds, etc.). Be careful before calling them optional all
> over
> >> the place.
> >
> > Full ACK.
> >

From touch@isi.edu  Tue Apr  3 13:34:56 2012
Return-Path: <touch@isi.edu>
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 6E1AD11E8205 for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 13:34:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.71
X-Spam-Level: 
X-Spam-Status: No, score=-103.71 tagged_above=-999 required=5 tests=[AWL=-1.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhdZFJkpT+oX for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 13:34:55 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id DDA6A11E81F5 for <tcpm@ietf.org>; Tue,  3 Apr 2012 13:34:55 -0700 (PDT)
Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q33KYhBL012654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Apr 2012 13:34:44 -0700 (PDT)
Message-ID: <4F7B5EE4.30007@isi.edu>
Date: Tue, 03 Apr 2012 13:34:44 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
References: <20120403020601.9C36910F8358@lawyers.icir.org> <4F7B3416.3010100@isi.edu> <4F7B46D1.7040502@freebsd.org> <4F7B531C.2030403@isi.edu> <1F8E0A684D3FF54680294BCFE57A7DB504C9307B@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <1F8E0A684D3FF54680294BCFE57A7DB504C9307B@xmb-sjc-23e.amer.cisco.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: David Borman <dab@weston.borman.com>, tcpm@ietf.org, mallman@icir.org
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 20:34:56 -0000

On 4/3/2012 1:32 PM, Anantha Ramaiah (ananth) wrote:
>
>> -----Original Message-----
>> From: Joe Touch [mailto:touch@isi.edu]
>> Sent: Tuesday, April 03, 2012 12:44 PM
>> To: Andre Oppermann
>> Cc: mallman@icir.org; David Borman; tcpm@ietf.org; Anantha Ramaiah
>> (ananth)
>> Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option
>> space extension.
>>
>> PS - why not compress timestamps?
>
> ???
> In one your earlier posts you said :-
>
> <Begin Quote>
> Option compression reduces the current use of option space, but does
> nothing to extend it beyond 40.
>
> I see no point in reviving this. It'd be better to nail it shut and call
> it dead.
>
> <End Quote>

"This" means a way to *extend* the option space (the title of your doc, 
and it's focus).

There's nothing wrong with compressing it, but it won't solve the big 
picture - the 40-byte limit.

Joe

From ananth@cisco.com  Tue Apr  3 13:41:37 2012
Return-Path: <ananth@cisco.com>
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 3F64D21F865B for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 13:41:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.484
X-Spam-Level: 
X-Spam-Status: No, score=-10.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2rVhgxUWuNR for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 13:41:36 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id A752A21F8683 for <tcpm@ietf.org>; Tue,  3 Apr 2012 13:41:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=812; q=dns/txt; s=iport; t=1333485696; x=1334695296; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=qzQVx+mCYS31ZkF/HGLMH90l1g/kS+BE90+yKp4pL4g=; b=Jq39PzVAS+qASNiZ3XZxjRrhJzAcgyDBFO8btg33mQygoJJacyQoEbKC rVm/y53K143IMzzFro6hMz7AvTGtJdx19sf7W4STIF1Grdu8KyhHLV/GL u4YoL/U0/dAdm20gFuauNnAOY28Irotmr3gere30ZckKH3T1upw9M6Hig 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAKtfe0+rRDoJ/2dsb2JhbABFDrgHgQeCCgEBBBIBHQo/EAIBCCIGGAYBVgEBBBsah2YBm0meeIsDhQBjBIhYm1KBaYIwV4E1
X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="36338591"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 03 Apr 2012 20:41:36 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q33KfaOc023721; Tue, 3 Apr 2012 20:41:36 GMT
Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 3 Apr 2012 13:41:36 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 3 Apr 2012 13:41:35 -0700
Message-ID: <1F8E0A684D3FF54680294BCFE57A7DB504C93089@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <4F7B5EE4.30007@isi.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
Thread-Index: Ac0R2TxpH4f0uiYvQPmcEQdVohEShAAAB96w
References: <20120403020601.9C36910F8358@lawyers.icir.org> <4F7B3416.3010100@isi.edu> <4F7B46D1.7040502@freebsd.org> <4F7B531C.2030403@isi.edu> <1F8E0A684D3FF54680294BCFE57A7DB504C9307B@xmb-sjc-23e.amer.cisco.com> <4F7B5EE4.30007@isi.edu>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Joe Touch" <touch@isi.edu>
X-OriginalArrivalTime: 03 Apr 2012 20:41:36.0290 (UTC) FILETIME=[29A60020:01CD11DA]
Cc: David Borman <dab@weston.borman.com>, tcpm@ietf.org, mallman@icir.org
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 20:41:37 -0000

> > ???
> > In one your earlier posts you said :-
> >
> > <Begin Quote>
> > Option compression reduces the current use of option space, but does
> > nothing to extend it beyond 40.
> >
> > I see no point in reviving this. It'd be better to nail it shut and
> > call it dead.
> >
> > <End Quote>
>=20
> "This" means a way to *extend* the option space (the title of your
doc,
> and it's focus).
>=20
> There's nothing wrong with compressing it, but it won't solve the big
> picture - the 40-byte limit.
>=20
> Joe

"extension" can be implicit as well, i.e, if you make room for more
options to be packed, then you have indirectly extended it, you can pick
on the "English" if you want. (pl read sections 4.6 and 4.8 of the draft
which are relevant to the current discussion)

-Anantha

From rs@netapp.com  Tue Apr  3 13:51:59 2012
Return-Path: <rs@netapp.com>
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 35B2721F8564 for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 13:51:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.228
X-Spam-Level: 
X-Spam-Status: No, score=-10.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJ-ke26hegvV for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 13:51:58 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5E23921F85A4 for <tcpm@ietf.org>; Tue,  3 Apr 2012 13:51:58 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,364,1330934400"; d="scan'208";a="638366673"
Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 03 Apr 2012 13:51:58 -0700
Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q33KpvE7021524; Tue, 3 Apr 2012 13:51:57 -0700 (PDT)
Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.76]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0247.003; Tue, 3 Apr 2012 13:51:44 -0700
From: "Scheffenegger, Richard" <rs@netapp.com>
To: Andre Oppermann <andre@freebsd.org>, Joe Touch <touch@isi.edu>
Thread-Topic: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
Thread-Index: AQHNEb+4TuhW6vUdnECpZ9dcRbkQqJaJ546AgAAEWYD//6UQ8A==
Date: Tue, 3 Apr 2012 20:51:46 +0000
Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F158C38@SACEXCMBX02-PRD.hq.netapp.com>
References: <20120403020601.9C36910F8358@lawyers.icir.org> <4F7B3416.3010100@isi.edu> <4F7B46D1.7040502@freebsd.org> <4F7B4A77.7060203@freebsd.org>
In-Reply-To: <4F7B4A77.7060203@freebsd.org>
Accept-Language: de-AT, 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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: David Borman <dab@weston.borman.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, "mallman@icir.org" <mallman@icir.org>
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 20:51:59 -0000

Andre,

Actually, specific CC algos want even more fine-grained measurements, One-W=
ay Delay Variation; LEDBAT has been finalized by the IETF (but within TCP, =
it currently can not get the necessary input signals properly).

Having an understanding on both ends about what the timestamps represent, w=
ould be very beneficial for these mechanisms! Current approach here is to h=
ave a limited set of probable timestamp clock rates, and trying to match th=
e observed timestamp values into one of these bins. Or simply assuming the =
other end with run at a specific timestamp clock rate...

Finally, during reordering / loss, these mechanisms probably want a differe=
nt semantic to obtain the most accurate OWDV measurements. That is somethin=
g I intended to address with my timestamp-negotiation draft...


Richard Scheffenegger



> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of
> Andre Oppermann
> Sent: Dienstag, 03. April 2012 21:08
> To: Joe Touch
> Cc: David Borman; tcpm@ietf.org; Anantha Ramaiah (ananth);
> mallman@icir.org
> Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option
> space extension.
>=20
> On 03.04.2012 20:52, Andre Oppermann wrote:
> > On 03.04.2012 19:32, Joe Touch wrote:
> >> On 4/2/2012 7:06 PM, Mark Allman wrote:
> >>> (6) I also agree with you that using the current space smarter is
> >>> cleaner than trying to create new space. But, also this has its
> >>> limits. I think timestamps in every packet on the *off chance* [*]
> >>> that you'll need PAWS is just damn wasteful of the constrained
> >>> resource. We should be smarter.
> >>
> >> Timestamps are starting to be used for a lot of other things
> >> (time-wait issues, randomness in various seeds, etc.). Be careful befo=
re
> calling them optional all over the place.
> >
> > Full ACK.
>=20
> Bringing up another angle:
>=20
> Every congestion control algorithm that wants to take delay changes into
> consideration depends on RTTM for high precision and frequency feedback.
> That's why we should allow it to be updated in the case of retransmits in=
 the
> presence of SACK.
>=20
> The RTO calculation doesn't need the high frequency measurements and
> could do with once or a couple of time per RTT.
>=20
> --
> Andre
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

From michael.scharf@alcatel-lucent.com  Tue Apr  3 14:14:35 2012
Return-Path: <michael.scharf@alcatel-lucent.com>
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 79B3711E8106 for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 14:14:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.249
X-Spam-Level: 
X-Spam-Status: No, score=-8.249 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+ATfWKZMlVB for <tcpm@ietfa.amsl.com>; Tue,  3 Apr 2012 14:14:34 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC4311E809D for <tcpm@ietf.org>; Tue,  3 Apr 2012 14:14:33 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q33LEV00002891 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Apr 2012 23:14:31 +0200
Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 3 Apr 2012 23:14:31 +0200
From: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
To: Joe Touch <touch@isi.edu>
Date: Tue, 3 Apr 2012 23:14:31 +0200
Thread-Topic: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
Thread-Index: Ac0RJ+Slkqr1hKQ+R+So3ImuCJtn1wAtEVsg
Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E88EF75844A@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>
References: <012C3117EDDB3C4781FD802A8C27DD4F1533DE@SACEXCMBX02-PRD.hq.netapp.com> <4F7A149A.7050909@isi.edu> <1F8E0A684D3FF54680294BCFE57A7DB504C92C51@xmb-sjc-23e.amer.cisco.com> <4F7A2616.4090308@isi.edu> <1F8E0A684D3FF54680294BCFE57A7DB504C92C9A@xmb-sjc-23e.amer.cisco.com> <4F7A3514.5040804@isi.edu>
In-Reply-To: <4F7A3514.5040804@isi.edu>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] Timestamps rejuvenated was: A new ID on TCP option space extension.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 21:14:35 -0000

> Your argument - and all its details - recurs in the IETF=20
> every 5-6 years. The counterarguments that will kill this are:
>=20
> 	- the SYN is where space is really needed
>=20
> 	- saving space isn't sufficient; new space needs to be created
>=20
> 	- there is no backwards-compatible way to solve SYN extension
>=20
> You can continue to try all possible combinations and hope=20
> there's a hole in that argument, but if that's your approach=20
> here, maybe you ought to let the WG know... that's not the=20
> same as a consensus solution.

My observation is that we keep having this discussion on the TCPM list ever=
y 5-6 *months*.

If we invested only half of the energy of these threads into xml2rfc (or wh=
atever other draft generation tool), we'd easily have some informational dr=
aft that at least explains the drawbacks and the costs of each "solution" o=
r "non-solution" (whatever you prefer).

And while such a document might not be of any benefit to all of us that obv=
iously know every past e-mail in the TCPM list archive, it might perhaps be=
 useful at least for some naive PhD students (or, e. g., other IETF WGs) th=
at continuously come up with fancy new SYN options...

Just a thought

Michael (obviously as individual)

From roehricht@kit.edu  Wed Apr  4 00:19:56 2012
Return-Path: <roehricht@kit.edu>
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 6733521F86AB for <tcpm@ietfa.amsl.com>; Wed,  4 Apr 2012 00:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level: 
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-PtcNUCqkYQ for <tcpm@ietfa.amsl.com>; Wed,  4 Apr 2012 00:19:55 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id B125321F8668 for <tcpm@ietf.org>; Wed,  4 Apr 2012 00:19:54 -0700 (PDT)
Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25  id 1SFKVR-0008Ac-33; Wed, 04 Apr 2012 09:19:53 +0200
Received: from i72xmartin.tm.uni-karlsruhe.de ([141.3.71.56]) by irams1.ira.uni-karlsruhe.de with esmtpsa port 587  id 1SFKVQ-0001gw-Ut; Wed, 04 Apr 2012 09:19:48 +0200
Message-ID: <4F7BF614.8090207@kit.edu>
Date: Wed, 04 Apr 2012 09:19:48 +0200
From: =?ISO-8859-1?Q?Martin_R=F6hricht?= <roehricht@kit.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>
References: <201203301322.q2UDMIcc009352@bagheera.jungle.bt.co.uk> <20120330142840.209BF1054DD8@lawyers.icir.org> <CAK6E8=d=gLDtG6REXXG2TWdSxMOCfeZX-40hjj7THcVVCM+Xuw@mail.gmail.com> <4F79F355.2020000@isi.edu>
In-Reply-To: <4F79F355.2020000@isi.edu>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de)
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1333523993.851968000
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] IW10 & queuebloat
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Apr 2012 07:19:56 -0000

Hi Joe,

On 02.04.2012 20:43 Joe Touch wrote:
> If, later, the specification becomes popular (or proves that it works
> well), it can be re-issued as a standards-track RFC.

just out of curiosity: has that ever happened or do you know of any RFCs
that moved from experimental to standards track?

Martin

From michael.scharf@alcatel-lucent.com  Wed Apr  4 00:26:17 2012
Return-Path: <michael.scharf@alcatel-lucent.com>
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 AFFD121F8700 for <tcpm@ietfa.amsl.com>; Wed,  4 Apr 2012 00:26:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.432
X-Spam-Level: 
X-Spam-Status: No, score=-9.432 tagged_above=-999 required=5 tests=[AWL=0.517,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaDFAigl0UXo for <tcpm@ietfa.amsl.com>; Wed,  4 Apr 2012 00:26:17 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1F921F86DE for <tcpm@ietf.org>; Wed,  4 Apr 2012 00:26:16 -0700 (PDT)
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 q347PTMp022204 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Apr 2012 09:26:15 +0200
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; Wed, 4 Apr 2012 09:25:57 +0200
From: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
To: =?iso-8859-1?Q?Martin_R=F6hricht?= <roehricht@kit.edu>
Date: Wed, 4 Apr 2012 09:25:56 +0200
Thread-Topic: [tcpm] IW10 & queuebloat
Thread-Index: Ac0SM4INO3F5XjlTRA6qK97fQums0QAAILJw
Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E88EF758450@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>
References: <201203301322.q2UDMIcc009352@bagheera.jungle.bt.co.uk> <20120330142840.209BF1054DD8@lawyers.icir.org> <CAK6E8=d=gLDtG6REXXG2TWdSxMOCfeZX-40hjj7THcVVCM+Xuw@mail.gmail.com> <4F79F355.2020000@isi.edu> <4F7BF614.8090207@kit.edu>
In-Reply-To: <4F7BF614.8090207@kit.edu>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] IW10 & queuebloat
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Apr 2012 07:26:17 -0000

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20
> Behalf Of Martin R=F6hricht
> Sent: Wednesday, April 04, 2012 9:20 AM
> To: Joe Touch
> Cc: tcpm IETF list
> Subject: Re: [tcpm] IW10 & queuebloat
>=20
> Hi Joe,
>=20
> On 02.04.2012 20:43 Joe Touch wrote:
> > If, later, the specification becomes popular (or proves=20
> that it works=20
> > well), it can be re-issued as a standards-track RFC.
>=20
> just out of curiosity: has that ever happened or do you know=20
> of any RFCs that moved from experimental to standards track?

RFC 4138 -> RFC 5682

Michael

From Alexander.Zimmermann@comsys.rwth-aachen.de  Wed Apr  4 00:26:56 2012
Return-Path: <Alexander.Zimmermann@comsys.rwth-aachen.de>
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 B531921F8709 for <tcpm@ietfa.amsl.com>; Wed,  4 Apr 2012 00:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level: 
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q24GpHWcUuNS for <tcpm@ietfa.amsl.com>; Wed,  4 Apr 2012 00:26:56 -0700 (PDT)
Received: from mail-i4.nets.rwth-aachen.de (mail-i4.nets.rwth-aachen.de [137.226.12.21]) by ietfa.amsl.com (Postfix) with ESMTP id 1F57121F8707 for <tcpm@ietf.org>; Wed,  4 Apr 2012 00:26:56 -0700 (PDT)
Received: from messenger.nets.rwth-aachen.de (messenger.nets.rwth-aachen.de [137.226.13.40]) by mail-i4.nets.rwth-aachen.de (Postfix) with ESMTP id DF21613DA05; Wed,  4 Apr 2012 09:26:46 +0200 (CEST)
Received: from MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28]) by MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28%12]) with mapi; Wed, 4 Apr 2012 09:26:46 +0200
From: Alexander Zimmermann <Alexander.Zimmermann@comsys.rwth-aachen.de>
To: =?iso-8859-1?Q?Martin_R=F6hricht?= <roehricht@kit.edu>, Joe Touch <touch@isi.edu>
Thread-Topic: [tcpm] IW10 & queuebloat
Thread-Index: AQHNDlNEnAdTrEb92UiMoB0OA+eZmpaCh4cAgABMMxX///DlAIAANccAgATIboCAAmWgAIAAI15y
Date: Wed, 4 Apr 2012 07:26:22 +0000
Message-ID: <4BE4A6C9593C6F4C96C937BED5606EEC159424C8@MESSENGER.nets.rwth-aachen.de>
References: <201203301322.q2UDMIcc009352@bagheera.jungle.bt.co.uk> <20120330142840.209BF1054DD8@lawyers.icir.org> <CAK6E8=d=gLDtG6REXXG2TWdSxMOCfeZX-40hjj7THcVVCM+Xuw@mail.gmail.com> <4F79F355.2020000@isi.edu>,<4F7BF614.8090207@kit.edu>
In-Reply-To: <4F7BF614.8090207@kit.edu>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] IW10 & queuebloat
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Apr 2012 07:26:56 -0000

Hi Martin,

yes: F-RTO.

Regards
Alex

________________________________________
Von: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org]&quot; im Auftrag von &qu=
ot;Martin R=F6hricht [roehricht@kit.edu]
Gesendet: Mittwoch, 4. April 2012 09:19
An: Joe Touch
Cc: tcpm IETF list
Betreff: Re: [tcpm] IW10 & queuebloat

Hi Joe,

On 02.04.2012 20:43 Joe Touch wrote:
> If, later, the specification becomes popular (or proves that it works
> well), it can be re-issued as a standards-track RFC.

just out of curiosity: has that ever happened or do you know of any RFCs
that moved from experimental to standards track?

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

From michael.scharf@alcatel-lucent.com  Wed Apr  4 01:58:40 2012
Return-Path: <michael.scharf@alcatel-lucent.com>
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 EEF1A21F86AA for <tcpm@ietfa.amsl.com>; Wed,  4 Apr 2012 01:58:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.819
X-Spam-Level: 
X-Spam-Status: No, score=-9.819 tagged_above=-999 required=5 tests=[AWL=0.430,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8O00mKoofhgT for <tcpm@ietfa.amsl.com>; Wed,  4 Apr 2012 01:58:40 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 191D521F86A8 for <tcpm@ietf.org>; Wed,  4 Apr 2012 01:58:39 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q348wC1f016420 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <tcpm@ietf.org>; Wed, 4 Apr 2012 10:58:38 +0200
Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 4 Apr 2012 10:58:33 +0200
From: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
To: tcpm IETF list <tcpm@ietf.org>
Date: Wed, 4 Apr 2012 10:58:32 +0200
Thread-Topic: Summary of feedback on draft-ietf-tcpm-initcwnd-03
Thread-Index: Ac0SQRzUvpwMv2xSSu+5IRJQre5Iig==
Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E88EF758455@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13
Subject: [tcpm] Summary of feedback on draft-ietf-tcpm-initcwnd-03
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Apr 2012 08:58:41 -0000

Hi all,

Here is a summary of what the chairs understood as feedback to be added to =
the next version of draft-ietf-tcpm-initcwnd-03, which we plan to WGLC:

* The wording at the beginning of the draft (and possibly the title) must b=
etter highlight the experimental status of the document.

* The document should say that at time of publication there is only limited=
 experimental data regarding the impact on non-TCP traffic.

* In Section 12, the lost packets during the initial burst is explicitly me=
ntioned as one performance metric that SHOULD be monitored.

* The document explicitly states that further work and experiments are need=
ed regarding a backoff mechanism, most notably to avoid repeated connection=
 setup attempts to the same host that each suffer from loss caused by a too=
 large initial window. My suggested phrasing would be: "The sender SHOULD c=
ache information about connection setups using an initial window larger tha=
n allowed by RFC 3390, and it SHOULD fall back to the initial window allowe=
d by RFC 3390 if there is evidence of performance issues. Further experimen=
ts are needed on the design of such a cache and corresponding heuristics."=
=20

If there are any additional comments or thoughts, please let us know. Pleas=
e focus on suggestions for specific text.=20

Thanks

Michael


From mallman@icir.org  Wed Apr  4 04:46:58 2012
Return-Path: <mallman@icir.org>
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 2B32E21F86A1 for <tcpm@ietfa.amsl.com>; Wed,  4 Apr 2012 04:46:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.449
X-Spam-Level: 
X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfdiWt3KoeAb for <tcpm@ietfa.amsl.com>; Wed,  4 Apr 2012 04:46:57 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5D01F21F867F for <tcpm@ietf.org>; Wed,  4 Apr 2012 04:46:57 -0700 (PDT)
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 q34BktTO012067; Wed, 4 Apr 2012 04:46:56 -0700 (PDT)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B9037114116E; Wed,  4 Apr 2012 07:46:56 -0400 (EDT)
To: =?ISO-8859-1?Q?Martin_R=F6hricht?= <roehricht@kit.edu>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <4F7BF614.8090207@kit.edu> 
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: King's Highway
X-URL-0: http://www.icir.org/mallman-files/Document25130.pdf
X-URL-1: http://www.icir.org/mallman-files/Document7338.xlsx
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma13488-1"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Wed, 04 Apr 2012 07:46:56 -0400
Sender: mallman@icir.org
Message-Id: <20120404114656.B9037114116E@lawyers.icir.org>
Cc: tcpm IETF list <tcpm@ietf.org>, Joe Touch <touch@isi.edu>
Subject: Re: [tcpm] IW10 & queuebloat
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 <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Apr 2012 11:46:58 -0000

----------ma13488-1
Content-Type: text/plain
Content-Disposition: inline


> just out of curiosity: has that ever happened or do you know of any
> RFCs that moved from experimental to standards track?

It happened the last time we increased the initial window.  RFC 2414 is
the experimental version.  That became RFC 3390 which is PS version.
The initial window from 3390 was then rolled into RFC 5681 which is a
draft standard.

allman




----------ma13488-1
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iEYEARECAAYFAk98NLAACgkQWyrrWs4yIs480wCfagJWAao1XLuFLBNNxkstdSkV
M8kAn3N6hPMa+h2LBR2ZajKShXIQVYOf
=UftT
-----END PGP SIGNATURE-----
----------ma13488-1--

From touch@isi.edu  Wed Apr  4 07:14:23 2012
Return-Path: <touch@isi.edu>
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 7432121F8800 for <tcpm@ietfa.amsl.com>; Wed,  4 Apr 2012 07:14:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.449
X-Spam-Level: 
X-Spam-Status: No, score=-104.449 tagged_above=-999 required=5 tests=[AWL=-2.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvobyvooYZq1 for <tcpm@ietfa.amsl.com>; Wed,  4 Apr 2012 07:14:22 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id AA09821F8717 for <tcpm@ietf.org>; Wed,  4 Apr 2012 07:14:22 -0700 (PDT)
Received: from [192.168.1.96] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q34EDtF9024616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Apr 2012 07:13:58 -0700 (PDT)
Message-ID: <4F7C5723.6050808@isi.edu>
Date: Wed, 04 Apr 2012 07:13:55 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Martin_R=F6hricht?= <roehricht@kit.edu>
References: <201203301322.q2UDMIcc009352@bagheera.jungle.bt.co.uk> <20120330142840.209BF1054DD8@lawyers.icir.org> <CAK6E8=d=gLDtG6REXXG2TWdSxMOCfeZX-40hjj7THcVVCM+Xuw@mail.gmail.com> <4F79F355.2020000@isi.edu> <4F7BF614.8090207@kit.edu>
In-Reply-To: <4F7BF614.8090207@kit.edu>
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 list <tcpm@ietf.org>
Subject: Re: [tcpm] IW10 & queuebloat
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Apr 2012 14:14:23 -0000

Others answered with a few examples. There may be more. Regardless of 
how many or few, that's a viable - and appropriate - path.

Joe

On 4/4/2012 12:19 AM, Martin Röhricht wrote:
> Hi Joe,
>
> On 02.04.2012 20:43 Joe Touch wrote:
>> If, later, the specification becomes popular (or proves that it works
>> well), it can be re-issued as a standards-track RFC.
>
> just out of curiosity: has that ever happened or do you know of any RFCs
> that moved from experimental to standards track?
>
> Martin

From jishac@nasa.gov  Wed Apr  4 15:58:04 2012
Return-Path: <jishac@nasa.gov>
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 5E6A111E80C5 for <tcpm@ietfa.amsl.com>; Wed,  4 Apr 2012 15:58:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsWF3ZokYc5P for <tcpm@ietfa.amsl.com>; Wed,  4 Apr 2012 15:58:03 -0700 (PDT)
Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by ietfa.amsl.com (Postfix) with ESMTP id A05EB11E808C for <tcpm@ietf.org>; Wed,  4 Apr 2012 15:58:03 -0700 (PDT)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id D31522D878C; Wed,  4 Apr 2012 17:58:02 -0500 (CDT)
Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt02.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q34Mw2uF017425;  Wed, 4 Apr 2012 17:58:02 -0500
Received: from firebird1.grc.nasa.gov (139.88.111.69) by smtp01.ndc.nasa.gov (198.117.1.161) with Microsoft SMTP Server (TLS) id 8.3.245.1; Wed, 4 Apr 2012 17:58:02 -0500
Received: by firebird1.grc.nasa.gov (Postfix, from userid 500)	id C96D317F498;  Wed,  4 Apr 2012 18:58:01 -0400 (EDT)
Date: Wed, 4 Apr 2012 18:58:01 -0400
From: Joseph Ishac <jishac@nasa.gov>
To: Joe Touch <touch@isi.edu>
Message-ID: <20120404225801.GA9592@firebird1.grc.nasa.gov>
Mail-Followup-To: Joe Touch <touch@isi.edu>, Yuchung Cheng <ycheng@google.com>, tcpm IETF list <tcpm@ietf.org>, "mallman@icir.org" <mallman@icir.org>
References: <201203301322.q2UDMIcc009352@bagheera.jungle.bt.co.uk> <4F79F355.2020000@isi.edu> <4F7A0407.8090105@isi.edu> <CANPnThZ9gB23p3SCpUPKMJRwog4=271z1Top4z6LWpZ9XvzkMw@mail.gmail.com> <4F7A23D0.3090909@isi.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4F7A23D0.3090909@isi.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-04-04_07:2012-04-04, 2012-04-04, 1970-01-01 signatures=0
Cc: tcpm IETF list <tcpm@ietf.org>, "mallman@icir.org" <mallman@icir.org>
Subject: Re: [tcpm] IW10 & queuebloat
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Joseph Ishac <jishac@nasa.gov>
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Apr 2012 22:58:04 -0000

On Mon, Apr 02, 2012 at 05:10:24PM -0500, Joe Touch wrote:
> >>> """
> >>> 12. Usage and Deployment Recommendations
> >>>
> >>>      Further experiments are required before a larger initial window shall
> >>>      be enabled by default in the Internet. The existing measurement
> >>>      results indicate that this does not cause significant harm to other
> >>>      traffic. However, widespread use in the Internet could reveal issues
> >>>      not known yet, e.g., regarding fairness or impact on latency-
> >>>      sensitive traffic such as VoIP.
> >>> """
> >>
> >> This is inconsistent with the following, from the Intro:
> >>
> >>      We recommend that all TCP implementations have a settable TCP IW
> >>      parameter. As of 2011 an appropriate value for this parameter is 10
> >>      segments as long as there is a reasonable effort to monitor for
> >>      possible interactions with other Internet applications and services.
> >>      Furthermore, it is understood that the appropriate value for IW is
> >>      likely to continue to rise in the future, but this document does not
> >>      include any supporting evidence for larger values of IW.
> >
> > I assume the contention is with the word "all"?
> 
> All should have settable IWs.
> 
> The objection is to the claim that the appropriate default is 10.
> 
> This is inconsistent with the document's own assertion in section 12 
> (the first sentence).

I think there is a distinction between "enabling this option in general"
(Section 12) and "if you enable this option, we think a good value is
10" (Intro, Par 5)  which is how the two sentences read to me.

Perhaps to better clarify, the line in the into should reference the
appropriate sections of the text that support those statements?  I
suggest paragraph 5 of the intro tweaked to something like:

"We recommend that all TCP implementations have a settable TCP IW
parameter as long as there is a reasonable effort to monitor for
possible interactions with other Internet applications and services as
described in Section 12.  Furthermore, Section 10 details why 10
segments may be an appropriate value for this parameter, and while that
value may continue to rise in the future, this document does not include
any supporting evidence for values of IW larger than 10."

> > I would claim that the goal of the document should focus more on the
> > concept and not exactly what type of experiment needs to be run.  The
> > very nature of experimentation means that there may be ways or angles to
> > test a concept or hypothesis... I wouldn't burden the document with
> > trying to capture all of them or how to analyze the data.  In fact
> > different analysis of the impact is what will help determine if the
> > concept succeeds or fails.
> 
> The key here is that an experiment involves:
> 
> 	- collecting data
> 	- reporting data
> 	- analyzing results
> 
> What data is relevant to collect?
> 
> Where is that data reported?
> 
> What is the expected outcome, i.e., predict some alternate results and 
> say what would happen.
> 
> Without these, it's not an experiment.

I understand those are important parts of experimenting, and the draft
already mentions some metrics of interest and cites more detailed
experiments, which is more than sufficient.  "Where is that data
reported?" sounds like you are suggesting that the draft needs to spell
out how to "report" findings, and I disagree.  The community has avenues
for that including the mailing list.

-Joseph

From roehricht@kit.edu  Thu Apr  5 00:12:09 2012
Return-Path: <roehricht@kit.edu>
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 E1B8521F85ED for <tcpm@ietfa.amsl.com>; Thu,  5 Apr 2012 00:12:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level: 
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkdnJotCXRSj for <tcpm@ietfa.amsl.com>; Thu,  5 Apr 2012 00:12:09 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 500E421F85EC for <tcpm@ietf.org>; Thu,  5 Apr 2012 00:12:08 -0700 (PDT)
Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25  id 1SFgrQ-0004M0-RE; Thu, 05 Apr 2012 09:12:07 +0200
Received: from i72xmartin.tm.uni-karlsruhe.de ([141.3.71.56]) by irams1.ira.uni-karlsruhe.de with esmtpsa port 587  id 1SFgrQ-0003r5-MU; Thu, 05 Apr 2012 09:12:00 +0200
Message-ID: <4F7D45C0.5020001@kit.edu>
Date: Thu, 05 Apr 2012 09:12:00 +0200
From: =?ISO-8859-1?Q?Martin_R=F6hricht?= <roehricht@kit.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>
References: <201203301322.q2UDMIcc009352@bagheera.jungle.bt.co.uk> <20120330142840.209BF1054DD8@lawyers.icir.org> <CAK6E8=d=gLDtG6REXXG2TWdSxMOCfeZX-40hjj7THcVVCM+Xuw@mail.gmail.com> <4F79F355.2020000@isi.edu> <4F7BF614.8090207@kit.edu> <4F7C5723.6050808@isi.edu>
In-Reply-To: <4F7C5723.6050808@isi.edu>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de)
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1333609927.173269000
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] IW10 & queuebloat
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2012 07:12:10 -0000

Hi,

thanks for the examples. Sure, this is an appropriate way as long as it
is used. :-) I was just not aware of any RFCs to which that happened
within the last years.

Martin

On 04.04.2012 16:13 Joe Touch wrote:
> Others answered with a few examples. There may be more. Regardless of 
> how many or few, that's a viable - and appropriate - path.
> 
> Joe
> 
> On 4/4/2012 12:19 AM, Martin Röhricht wrote:
>> Hi Joe,
>>
>> On 02.04.2012 20:43 Joe Touch wrote:
>>> If, later, the specification becomes popular (or proves that it works
>>> well), it can be re-issued as a standards-track RFC.
>>
>> just out of curiosity: has that ever happened or do you know of any RFCs
>> that moved from experimental to standards track?
>>
>> Martin

From gorry@erg.abdn.ac.uk  Thu Apr  5 00:15:19 2012
Return-Path: <gorry@erg.abdn.ac.uk>
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 6EF3311E80FB for <tcpm@ietfa.amsl.com>; Thu,  5 Apr 2012 00:15:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFzyoQ5juFM7 for <tcpm@ietfa.amsl.com>; Thu,  5 Apr 2012 00:15:18 -0700 (PDT)
Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 6D91F11E8079 for <tcpm@ietf.org>; Thu,  5 Apr 2012 00:15:17 -0700 (PDT)
Received: from Gorry.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id q357FBNp019229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <tcpm@ietf.org>; Thu, 5 Apr 2012 08:15:11 +0100 (BST)
Message-ID: <4F7D467F.6000502@erg.abdn.ac.uk>
Date: Thu, 05 Apr 2012 08:15:11 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: The University of Aberdeen is a charity registered in Scotland,  No SC013683. 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: tcpm@ietf.org
References: <201203301322.q2UDMIcc009352@bagheera.jungle.bt.co.uk> <4F79F355.2020000@isi.edu> <4F7A0407.8090105@isi.edu> <CANPnThZ9gB23p3SCpUPKMJRwog4=271z1Top4z6LWpZ9XvzkMw@mail.gmail.com> <4F7A23D0.3090909@isi.edu> <20120404225801.GA9592@firebird1.grc.nasa.gov>
In-Reply-To: <20120404225801.GA9592@firebird1.grc.nasa.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ERG-MailScanner: Found to be clean
X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk
Subject: Re: [tcpm] IW10 & queuebloat
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2012 07:15:19 -0000

I agree to making the experiments clearer at the start:
- Safety of the method for TCP
- Safety of the method for other Internet traffic
- Selection of suitable fall-back methods, when need.

Gorry

On 04/04/2012 23:58, Joseph Ishac wrote:
> On Mon, Apr 02, 2012 at 05:10:24PM -0500, Joe Touch wrote:
>>>>> """
>>>>> 12. Usage and Deployment Recommendations
>>>>>
>>>>>       Further experiments are required before a larger initial window shall
>>>>>       be enabled by default in the Internet. The existing measurement
>>>>>       results indicate that this does not cause significant harm to other
>>>>>       traffic. However, widespread use in the Internet could reveal issues
>>>>>       not known yet, e.g., regarding fairness or impact on latency-
>>>>>       sensitive traffic such as VoIP.
>>>>> """
>>>>
>>>> This is inconsistent with the following, from the Intro:
>>>>
>>>>       We recommend that all TCP implementations have a settable TCP IW
>>>>       parameter. As of 2011 an appropriate value for this parameter is 10
>>>>       segments as long as there is a reasonable effort to monitor for
>>>>       possible interactions with other Internet applications and services.
>>>>       Furthermore, it is understood that the appropriate value for IW is
>>>>       likely to continue to rise in the future, but this document does not
>>>>       include any supporting evidence for larger values of IW.
>>>
>>> I assume the contention is with the word "all"?
>>
>> All should have settable IWs.
>>
>> The objection is to the claim that the appropriate default is 10.
>>
>> This is inconsistent with the document's own assertion in section 12
>> (the first sentence).
>
> I think there is a distinction between "enabling this option in general"
> (Section 12) and "if you enable this option, we think a good value is
> 10" (Intro, Par 5)  which is how the two sentences read to me.
>
> Perhaps to better clarify, the line in the into should reference the
> appropriate sections of the text that support those statements?  I
> suggest paragraph 5 of the intro tweaked to something like:
>
> "We recommend that all TCP implementations have a settable TCP IW
> parameter as long as there is a reasonable effort to monitor for
> possible interactions with other Internet applications and services as
> described in Section 12.  Furthermore, Section 10 details why 10
> segments may be an appropriate value for this parameter, and while that
> value may continue to rise in the future, this document does not include
> any supporting evidence for values of IW larger than 10."
>
>>> I would claim that the goal of the document should focus more on the
>>> concept and not exactly what type of experiment needs to be run.  The
>>> very nature of experimentation means that there may be ways or angles to
>>> test a concept or hypothesis... I wouldn't burden the document with
>>> trying to capture all of them or how to analyze the data.  In fact
>>> different analysis of the impact is what will help determine if the
>>> concept succeeds or fails.
>>
>> The key here is that an experiment involves:
>>
>> 	- collecting data
>> 	- reporting data
>> 	- analyzing results
>>
>> What data is relevant to collect?
>>
>> Where is that data reported?
>>
>> What is the expected outcome, i.e., predict some alternate results and
>> say what would happen.
>>
>> Without these, it's not an experiment.
>
> I understand those are important parts of experimenting, and the draft
> already mentions some metrics of interest and cites more detailed
> experiments, which is more than sufficient.  "Where is that data
> reported?" sounds like you are suggesting that the draft needs to spell
> out how to "report" findings, and I disagree.  The community has avenues
> for that including the mailing list.
>
> -Joseph
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
>


From gorry@erg.abdn.ac.uk  Thu Apr  5 00:15:20 2012
Return-Path: <gorry@erg.abdn.ac.uk>
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 68A7E11E80E7 for <tcpm@ietfa.amsl.com>; Thu,  5 Apr 2012 00:15:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cd1haPTVXlBU for <tcpm@ietfa.amsl.com>; Thu,  5 Apr 2012 00:15:20 -0700 (PDT)
Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 976E611E8079 for <tcpm@ietf.org>; Thu,  5 Apr 2012 00:15:19 -0700 (PDT)
Received: from Gorry.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id q357FEFh019231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Apr 2012 08:15:15 +0100 (BST)
Message-ID: <4F7D4682.2010009@erg.abdn.ac.uk>
Date: Thu, 05 Apr 2012 08:15:14 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: The University of Aberdeen is a charity registered in Scotland,  No SC013683. 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
References: <2A886F9088894347A3BE0CC5B7A85F3E88EF758455@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>
In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E88EF758455@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ERG-MailScanner: Found to be clean
X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] Summary of feedback on draft-ietf-tcpm-initcwnd-03
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2012 07:15:20 -0000

I think this captures my issues, except that I think it is important to 
clarify that new connections from the "host" or "sending interface" 
SHOULD fall back to the initial window allowed in....

I'm happy to work with the I-D Editors to precision wording if this 
helps, but overall I think we are ready for a WGLC.

Gorry


On 04/04/2012 09:58, Scharf, Michael (Michael) wrote:
> Hi all,
>
> Here is a summary of what the chairs understood as feedback to be added to the next version of draft-ietf-tcpm-initcwnd-03, which we plan to WGLC:
>
> * The wording at the beginning of the draft (and possibly the title) must better highlight the experimental status of the document.
>
> * The document should say that at time of publication there is only limited experimental data regarding the impact on non-TCP traffic.
>
> * In Section 12, the lost packets during the initial burst is explicitly mentioned as one performance metric that SHOULD be monitored.
>
> * The document explicitly states that further work and experiments are needed regarding a backoff mechanism, most notably to avoid repeated connection setup attempts to the same host that each suffer from loss caused by a too large initial window. My suggested phrasing would be: "The sender SHOULD cache information about connection setups using an initial window larger than allowed by RFC 3390, and it SHOULD fall back to the initial window allowed by RFC 3390 if there is evidence of performance issues. Further experiments are needed on the design of such a cache and corresponding heuristics."
>
> If there are any additional comments or thoughts, please let us know. Please focus on suggestions for specific text.
>
> Thanks
>
> Michael
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
>


From touch@isi.edu  Thu Apr  5 11:21:26 2012
Return-Path: <touch@isi.edu>
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 278D921F8642 for <tcpm@ietfa.amsl.com>; Thu,  5 Apr 2012 11:21:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.432
X-Spam-Level: 
X-Spam-Status: No, score=-103.432 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0d3glo2kkur for <tcpm@ietfa.amsl.com>; Thu,  5 Apr 2012 11:21:25 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 48D5921F84B5 for <tcpm@ietf.org>; Thu,  5 Apr 2012 11:21:25 -0700 (PDT)
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 q35ILJ37022848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Apr 2012 11:21:20 -0700 (PDT)
Message-ID: <4F7DE29F.9070504@isi.edu>
Date: Thu, 05 Apr 2012 11:21:19 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
References: <2A886F9088894347A3BE0CC5B7A85F3E88EF758455@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>
In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E88EF758455@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 list <tcpm@ietf.org>
Subject: Re: [tcpm] Summary of feedback on draft-ietf-tcpm-initcwnd-03
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2012 18:21:26 -0000

On 4/4/2012 1:58 AM, Scharf, Michael (Michael) wrote:
> Hi all,
>
> Here is a summary of what the chairs understood as feedback to be added to the next version of draft-ietf-tcpm-initcwnd-03, which we plan to WGLC:
>
> * The wording at the beginning of the draft (and possibly the title) must better highlight the experimental status of the document.
>
> * The document should say that at time of publication there is only limited experimental data regarding the impact on non-TCP traffic.
>
> * In Section 12, the lost packets during the initial burst is explicitly mentioned as one performance metric that SHOULD be monitored.

FWIW, draft-touch-tcpm-automatic-iw explains how to detect that without 
impact during regular operation ;-)

Joe

>
> * The document explicitly states that further work and experiments are needed regarding a backoff mechanism, most notably to avoid repeated connection setup attempts to the same host that each suffer from loss caused by a too large initial window. My suggested phrasing would be: "The sender SHOULD cache information about connection setups using an initial window larger than allowed by RFC 3390, and it SHOULD fall back to the initial window allowed by RFC 3390 if there is evidence of performance issues. Further experiments are needed on the design of such a cache and corresponding heuristics."
>
> If there are any additional comments or thoughts, please let us know. Please focus on suggestions for specific text.
>
> Thanks
>
> Michael
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

From touch@isi.edu  Thu Apr  5 11:22:33 2012
Return-Path: <touch@isi.edu>
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 3C8BB21F86A3 for <tcpm@ietfa.amsl.com>; Thu,  5 Apr 2012 11:22:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.368
X-Spam-Level: 
X-Spam-Status: No, score=-103.368 tagged_above=-999 required=5 tests=[AWL=-0.769, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLfojlvkAO0K for <tcpm@ietfa.amsl.com>; Thu,  5 Apr 2012 11:22:32 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 62A3721F869D for <tcpm@ietf.org>; Thu,  5 Apr 2012 11:22:32 -0700 (PDT)
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 q35IMHq5023056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Apr 2012 11:22:17 -0700 (PDT)
Message-ID: <4F7DE2D9.6050709@isi.edu>
Date: Thu, 05 Apr 2012 11:22:17 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: gorry@erg.abdn.ac.uk
References: <2A886F9088894347A3BE0CC5B7A85F3E88EF758455@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <4F7D4682.2010009@erg.abdn.ac.uk>
In-Reply-To: <4F7D4682.2010009@erg.abdn.ac.uk>
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 list <tcpm@ietf.org>
Subject: Re: [tcpm] Summary of feedback on draft-ietf-tcpm-initcwnd-03
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2012 18:22:33 -0000

On 4/5/2012 12:15 AM, Gorry Fairhurst wrote:
> I think this captures my issues, except that I think it is important to
> clarify that new connections from the "host" or "sending interface"
> SHOULD fall back to the initial window allowed in....

FWIW, that is mentioned briefly at the end of Sec 2, but could be better 
included in the summary recommendations in Sec 12.

Joe

>
> I'm happy to work with the I-D Editors to precision wording if this
> helps, but overall I think we are ready for a WGLC.
>
> Gorry
>
>
> On 04/04/2012 09:58, Scharf, Michael (Michael) wrote:
>> Hi all,
>>
>> Here is a summary of what the chairs understood as feedback to be
>> added to the next version of draft-ietf-tcpm-initcwnd-03, which we
>> plan to WGLC:
>>
>> * The wording at the beginning of the draft (and possibly the title)
>> must better highlight the experimental status of the document.
>>
>> * The document should say that at time of publication there is only
>> limited experimental data regarding the impact on non-TCP traffic.
>>
>> * In Section 12, the lost packets during the initial burst is
>> explicitly mentioned as one performance metric that SHOULD be monitored.
>>
>> * The document explicitly states that further work and experiments are
>> needed regarding a backoff mechanism, most notably to avoid repeated
>> connection setup attempts to the same host that each suffer from loss
>> caused by a too large initial window. My suggested phrasing would be:
>> "The sender SHOULD cache information about connection setups using an
>> initial window larger than allowed by RFC 3390, and it SHOULD fall
>> back to the initial window allowed by RFC 3390 if there is evidence of
>> performance issues. Further experiments are needed on the design of
>> such a cache and corresponding heuristics."
>>
>> If there are any additional comments or thoughts, please let us know.
>> Please focus on suggestions for specific text.
>>
>> Thanks
>>
>> Michael
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

From touch@isi.edu  Thu Apr  5 11:24:31 2012
Return-Path: <touch@isi.edu>
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 6473321F86D8 for <tcpm@ietfa.amsl.com>; Thu,  5 Apr 2012 11:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.313
X-Spam-Level: 
X-Spam-Status: No, score=-103.313 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FavaPvy8Xzbr for <tcpm@ietfa.amsl.com>; Thu,  5 Apr 2012 11:24:30 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id E238E21F86D4 for <tcpm@ietf.org>; Thu,  5 Apr 2012 11:24:30 -0700 (PDT)
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 q35INclJ023473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Apr 2012 11:23:38 -0700 (PDT)
Message-ID: <4F7DE32A.8000407@isi.edu>
Date: Thu, 05 Apr 2012 11:23:38 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: gorry@erg.abdn.ac.uk
References: <2A886F9088894347A3BE0CC5B7A85F3E88EF758455@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <4F7D4682.2010009@erg.abdn.ac.uk> <4F7DE2D9.6050709@isi.edu>
In-Reply-To: <4F7DE2D9.6050709@isi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] Summary of feedback on draft-ietf-tcpm-initcwnd-03
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2012 18:24:31 -0000

PS - +1 on ready for WGLC

On 4/5/2012 11:22 AM, Joe Touch wrote:
>
>
> On 4/5/2012 12:15 AM, Gorry Fairhurst wrote:
>> I think this captures my issues, except that I think it is important to
>> clarify that new connections from the "host" or "sending interface"
>> SHOULD fall back to the initial window allowed in....
>
> FWIW, that is mentioned briefly at the end of Sec 2, but could be better
> included in the summary recommendations in Sec 12.
>
> Joe
>
>>
>> I'm happy to work with the I-D Editors to precision wording if this
>> helps, but overall I think we are ready for a WGLC.
>>
>> Gorry
>>
>>
>> On 04/04/2012 09:58, Scharf, Michael (Michael) wrote:
>>> Hi all,
>>>
>>> Here is a summary of what the chairs understood as feedback to be
>>> added to the next version of draft-ietf-tcpm-initcwnd-03, which we
>>> plan to WGLC:
>>>
>>> * The wording at the beginning of the draft (and possibly the title)
>>> must better highlight the experimental status of the document.
>>>
>>> * The document should say that at time of publication there is only
>>> limited experimental data regarding the impact on non-TCP traffic.
>>>
>>> * In Section 12, the lost packets during the initial burst is
>>> explicitly mentioned as one performance metric that SHOULD be monitored.
>>>
>>> * The document explicitly states that further work and experiments are
>>> needed regarding a backoff mechanism, most notably to avoid repeated
>>> connection setup attempts to the same host that each suffer from loss
>>> caused by a too large initial window. My suggested phrasing would be:
>>> "The sender SHOULD cache information about connection setups using an
>>> initial window larger than allowed by RFC 3390, and it SHOULD fall
>>> back to the initial window allowed by RFC 3390 if there is evidence of
>>> performance issues. Further experiments are needed on the design of
>>> such a cache and corresponding heuristics."
>>>
>>> If there are any additional comments or thoughts, please let us know.
>>> Please focus on suggestions for specific text.
>>>
>>> Thanks
>>>
>>> Michael
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>>
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm

From touch@isi.edu  Thu Apr  5 11:34:43 2012
Return-Path: <touch@isi.edu>
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 56D4C21F864C for <tcpm@ietfa.amsl.com>; Thu,  5 Apr 2012 11:34:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.116
X-Spam-Level: 
X-Spam-Status: No, score=-105.116 tagged_above=-999 required=5 tests=[AWL=1.183, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3p++e6l3Cot for <tcpm@ietfa.amsl.com>; Thu,  5 Apr 2012 11:34:42 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id DD7E921F8647 for <tcpm@ietf.org>; Thu,  5 Apr 2012 11:34:42 -0700 (PDT)
Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q35IYFI0007187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Apr 2012 11:34:15 -0700 (PDT)
Message-ID: <4F7DE5A7.3010707@isi.edu>
Date: Thu, 05 Apr 2012 11:34:15 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Martin_R=F6hricht?= <roehricht@kit.edu>
References: <201203301322.q2UDMIcc009352@bagheera.jungle.bt.co.uk> <20120330142840.209BF1054DD8@lawyers.icir.org> <CAK6E8=d=gLDtG6REXXG2TWdSxMOCfeZX-40hjj7THcVVCM+Xuw@mail.gmail.com> <4F79F355.2020000@isi.edu> <4F7BF614.8090207@kit.edu> <4F7C5723.6050808@isi.edu> <4F7D45C0.5020001@kit.edu>
In-Reply-To: <4F7D45C0.5020001@kit.edu>
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 list <tcpm@ietf.org>
Subject: Re: [tcpm] IW10 & queuebloat
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2012 18:34:43 -0000

If you want a current example, MPTCP is in the process of that excursion 
*as we speak* (I think it's WAY premature, but they're trying).

Joe

On 4/5/2012 12:12 AM, Martin Röhricht wrote:
> Hi,
>
> thanks for the examples. Sure, this is an appropriate way as long as it
> is used. :-) I was just not aware of any RFCs to which that happened
> within the last years.
>
> Martin
>
> On 04.04.2012 16:13 Joe Touch wrote:
>> Others answered with a few examples. There may be more. Regardless of
>> how many or few, that's a viable - and appropriate - path.
>>
>> Joe
>>
>> On 4/4/2012 12:19 AM, Martin Röhricht wrote:
>>> Hi Joe,
>>>
>>> On 02.04.2012 20:43 Joe Touch wrote:
>>>> If, later, the specification becomes popular (or proves that it works
>>>> well), it can be re-issued as a standards-track RFC.
>>>
>>> just out of curiosity: has that ever happened or do you know of any RFCs
>>> that moved from experimental to standards track?
>>>
>>> Martin

From cabo@tzi.org  Thu Apr  5 12:27:58 2012
Return-Path: <cabo@tzi.org>
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 A754A21F866A for <tcpm@ietfa.amsl.com>; Thu,  5 Apr 2012 12:27:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.099
X-Spam-Level: 
X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyP1dDIrePIy for <tcpm@ietfa.amsl.com>; Thu,  5 Apr 2012 12:27:58 -0700 (PDT)
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 E4D1521F8665 for <tcpm@ietf.org>; Thu,  5 Apr 2012 12:27:57 -0700 (PDT)
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 q35JRoQG018271; Thu, 5 Apr 2012 21:27:50 +0200 (CEST)
Received: from [192.168.217.117] (p5489AB9F.dip.t-dialin.net [84.137.171.159]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C3B7B7A1; Thu,  5 Apr 2012 21:27:49 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <4F7D45C0.5020001@kit.edu>
Date: Thu, 5 Apr 2012 21:27:47 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <E72CAE19-F67F-44AF-9B4B-390DE920B74A@tzi.org>
References: <201203301322.q2UDMIcc009352@bagheera.jungle.bt.co.uk> <20120330142840.209BF1054DD8@lawyers.icir.org> <CAK6E8=d=gLDtG6REXXG2TWdSxMOCfeZX-40hjj7THcVVCM+Xuw@mail.gmail.com> <4F79F355.2020000@isi.edu> <4F7BF614.8090207@kit.edu> <4F7C5723.6050808@isi.edu> <4F7D45C0.5020001@kit.edu>
To: =?iso-8859-1?Q?Martin_R=F6hricht?= <roehricht@kit.edu>
X-Mailer: Apple Mail (2.1257)
Cc: tcpm IETF list <tcpm@ietf.org>, Joe Touch <touch@isi.edu>
Subject: Re: [tcpm] IW10 & queuebloat
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2012 19:27:58 -0000

On Apr 5, 2012, at 09:12, Martin R=F6hricht wrote:

> I was just not aware of any RFCs to which that happened
> within the last years.

Two off the top of my head (and transport protocols to boot):

RFC 3941 (exp, Nov 2004) -> RFC 5401 (stds track, Nov 2008)
RFC 3940 (exp, Nov 2004) -> RFC 5740 (stds track, Nov 2009)

(RFC 5740 is also my personal record of maturation time, resulting from =
work I started to do around 1993.  But that's a long story...)

Gr=FC=DFe, Carsten


From wwwrun@rfc-editor.org  Fri Apr  6 14:13:30 2012
Return-Path: <wwwrun@rfc-editor.org>
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 6E95E11E80CC; Fri,  6 Apr 2012 14:13:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.841
X-Spam-Level: 
X-Spam-Status: No, score=-103.841 tagged_above=-999 required=5 tests=[AWL=1.236, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QB0sr8Gfxemq; Fri,  6 Apr 2012 14:13:29 -0700 (PDT)
Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id 72B6F11E80DC; Fri,  6 Apr 2012 14:13:29 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id DA357B1E018; Fri,  6 Apr 2012 14:13:10 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20120406211310.DA357B1E018@rfc-editor.org>
Date: Fri,  6 Apr 2012 14:13:10 -0700 (PDT)
Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org
Subject: [tcpm] RFC 6582 on The NewReno Modification to TCP's Fast Recovery Algorithm
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Apr 2012 21:13:30 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6582

        Title:      The NewReno Modification to TCP's 
                    Fast Recovery Algorithm 
        Author:     T. Henderson, S. Floyd,
                    A. Gurtov, Y. Nishida
        Status:     Standards Track
        Stream:     IETF
        Date:       April 2012
        Mailbox:    thomas.r.henderson@boeing.com, 
                    floyd@acm.org, 
                    gurtov@ee.oulu.fi,
                    nishida@wide.ad.jp
        Pages:      16
        Characters: 35413
        Obsoletes:  RFC3782

        I-D Tag:    draft-ietf-tcpm-rfc3782-bis-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6582.txt

RFC 5681 documents the following four intertwined TCP
congestion control algorithms: slow start, congestion avoidance, fast
retransmit, and fast recovery.  RFC 5681 explicitly allows
certain modifications of these algorithms, including modifications
that use the TCP Selective Acknowledgment (SACK) option (RFC 2883),
and modifications that respond to "partial acknowledgments" (ACKs
that cover new data, but not all the data outstanding when loss was
detected) in the absence of SACK.  This document describes a specific
algorithm for responding to partial acknowledgments, referred to as
"NewReno".  This response to partial acknowledgments was first proposed
by Janey Hoe.  This document obsoletes RFC 3782.  [STANDARDS-TRACK]

This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From M.Lloyd@F5.com  Tue Apr 10 12:52:56 2012
Return-Path: <M.Lloyd@F5.com>
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 4C39D11E814B for <tcpm@ietfa.amsl.com>; Tue, 10 Apr 2012 12:52:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Level: 
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MReU7aHuYHuo for <tcpm@ietfa.amsl.com>; Tue, 10 Apr 2012 12:52:55 -0700 (PDT)
Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 43AC311E814A for <tcpm@ietf.org>; Tue, 10 Apr 2012 12:52:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=M.Lloyd@f5.com; q=dns/txt; s=seattle; t=1334087575; x=1365623575; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=l+HMyTr2wvbg9L3ca9jZ4HMIY+276qjDpf6OZPAceBA=; b=DJn9tUVhjxRIzxxdAQ5gKByRoPZXQ/NhSLrGqRKDlgGRttIwpOi+VB4b nD5novhVAnw1ieK2dLlbSl0Me0orjbPXyQJbim7Waq8PM3WL267e91LW8 FkY/b5Qr5r0gIDKOu7z8uQ4ui3Gqwwn3tpLLoiEdi0nUKqeEbfcm2m6eW U=;
X-IronPort-AV: E=Sophos;i="4.73,1,1325462400";  d="scan'208";a="42845997"
Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.240]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 10 Apr 2012 19:52:54 +0000
Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS01.olympus.F5Net.com ([fe80::1426:3a3a:3f57:ef23%15]) with mapi id 14.02.0283.003; Tue, 10 Apr 2012 12:52:53 -0700
From: Mark Lloyd <M.Lloyd@F5.com>
To: "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: Minimum RTO
Thread-Index: Ac0XUohcmbM7TRaYTSmihLMk0Ba66g==
Date: Tue, 10 Apr 2012 19:52:52 +0000
Message-ID: <2A08B7ACA17C9F4BAA8D5395DF908D731DED9A27@SEAEMBX02.olympus.F5Net.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.16.200]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [tcpm] Minimum RTO
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 19:52:56 -0000

Reading RFC 6298

http://tools.ietf.org/html/rfc6298


 (2.4) Whenever RTO is computed, if it is less than 1 second, then the
=A0=A0=A0=A0=A0=A0=A0=A0 RTO SHOULD be rounded up to 1 second.


While troubleshooting a problem that involves minimum RTO, I found that RFC=
 6298 suggests a 1 second value for minimum RTO that is not honored in the =
implementations I have tested, and even in these implementation TCP does no=
t do a good job of handling packet loss in a common scenario I tested.=20

I use two Linux hosts as my test. They are setup to imitate the kind of con=
nection that would be used for a database or RPC transaction.

My server does a netcat command that loops back data as it is received:

touch /tmp/testfile
tail -f /tmp/testfile | sudo nc -l 1000 >>/tmp/testfile

The client sends data, then echos a response simulating a TCP conversation =
of small transactions.

touch=A0 /tmp/testfile
echo hello >/tmp/testfile
tail -f /tmp/testfile | nc 10.10.30.121 1000 >>/tmp/testfile

I then setup a wan emulator to simulate a 1% loss rate back to the client.=
=20

I'm showing frames leading up to the packet loss to show the what the traff=
ic looks like up to the packet loss.=A0

Server side:

Frm=A0=A0=A0 Time =A0=A0=A0=A0=A0=A0=A0=A0=20
Num=A0=A0=A0 Delta=A0=A0=A0=A0=A0=A0=A0=A0=20
1941=A0=A0 0.0000830=A0=A0=A0=A0 Server -> Client=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646100 =
- 1538646106, Ack=3D1257857589,=20
1942=A0=A0 0.0005920=A0=A0=A0=A0 Client -> Server=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857589 =
- 1257857595, Ack=3D1538646106
1943=A0=A0 0.0000920=A0=A0=A0=A0 Server -> Client=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646106 =
- 1538646112, Ack=3D1257857595
1944=A0=A0 0.0005590=A0=A0=A0=A0 Client -> Server=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857595 =
- 1257857601, Ack=3D1538646112
1945=A0=A0 0.0000730=A0=A0=A0=A0 Server -> Client=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646112 =
- 1538646118, Ack=3D1257857601
1946=A0=A0 0.0005770=A0=A0=A0=A0 Client -> Server=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857601 =
- 1257857607, Ack=3D1538646118
1947=A0=A0 0.0000930=A0=A0=A0=A0 Server -> Client=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646118 =
- 1538646124, Ack=3D1257857607
1948=A0=A0 0.0006190=A0=A0=A0=A0 Client -> Server=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857607 =
- 1257857613, Ack=3D1538646124
1949=A0=A0 0.0000790=A0=A0=A0=A0 Server -> Client=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646124 =
- 1538646130, Ack=3D1257857613
1950=A0=A0 0.0005110=A0=A0=A0=A0 Client -> Server=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857613 =
- 1257857619, Ack=3D1538646130
1951=A0=A0 0.0000850=A0=A0=A0=A0 Server -> Client=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646130 =
- 1538646136, Ack=3D1257857619
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Packet 1951 will be lost in t=
ransit. Note 205ms gap.

1952=A0=A0 0.2053670=A0=A0=A0=A0 Client -> Server=A0=A0=A0=A0 TCP:[ReTransm=
it #1950]Flags=3D...AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6,=
 Seq=3D1257857613 - 1257857619
1953=A0=A0 0.0000420=A0=A0=A0=A0 Server -> Client=A0=A0=A0=A0 TCP:Flags=3D.=
..A...., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D0, Seq=3D1538646136,=
 Ack=3D1257857619
1954=A0=A0 0.0007630=A0=A0=A0=A0 Server -> Client=A0=A0=A0=A0 TCP:[ReTransm=
it #1951] Flags=3D...AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6=
, Seq=3D1538646130 - 1538646136, Ack=3D1257857619
1955=A0=A0 0.0006640=A0=A0=A0=A0 Client -> Server=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857619 =
- 1257857625, Ack=3D1538646136

Client side:

1928=A0=A0 0.0006400=A0=A0=A0=A0 Server -> Client=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646094 =
- 1538646100, Ack=3D1257857583
1929=A0=A0 0.0000690=A0=A0=A0=A0 Client -> Server=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857583 =
- 1257857589, Ack=3D1538646100
1930=A0=A0 0.0006200=A0=A0=A0=A0 Server -> Client=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646100 =
- 1538646106, Ack=3D1257857589
1931=A0=A0 0.0000690=A0=A0=A0=A0 Client -> Server=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857589 =
- 1257857595, Ack=3D1538646106
1932=A0=A0 0.0006300=A0=A0=A0=A0 Server -> Client=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646106 =
- 1538646112, Ack=3D1257857595
1933=A0=A0 0.0000730=A0=A0=A0=A0 Client -> Server=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857595 =
- 1257857601, Ack=3D1538646112
1934=A0=A0 0.0005230=A0=A0=A0=A0 Server -> Client=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646112 =
- 1538646118, Ack=3D1257857601
1935=A0=A0 0.0000830=A0=A0=A0=A0 Client -> Server=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857601 =
- 1257857607, Ack=3D1538646118
1936=A0=A0 0.0006140=A0=A0=A0=A0 Server -> Client=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646118 =
- 1538646124, Ack=3D1257857607
1937=A0=A0 0.0000750=A0=A0=A0=A0 Client -> Server=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857607 =
- 1257857613, Ack=3D1538646124
1938=A0=A0 0.0006230=A0=A0=A0=A0 Server -> Client=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646124 =
- 1538646130, Ack=3D1257857613
1939=A0=A0 0.0000650=A0=A0=A0=A0 Client -> Server=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857613 =
- 1257857619, Ack=3D1538646130
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0 Packet does not arrive from ser=
ver. Client retransmits in 205ms.

1940=A0=A0 0.2053300=A0=A0=A0=A0 Client -> Server=A0=A0=A0=A0 TCP:[ReTransm=
it #1939] Flags=3D...AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6=
, Seq=3D1257857613 - 1257857619, Ack=3D1538646130
1941=A0=A0 0.0006840=A0=A0=A0=A0 Server -> Client=A0=A0=A0=A0 TCP:Flags=3D.=
..A...., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D0, Seq=3D1538646136,=
 Ack=3D1257857619
1942=A0=A0 0.0006970=A0=A0=A0=A0 Server -> Client=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646130 =
- 1538646136, Ack=3D1257857619,
1943=A0=A0 0.0001120=A0=A0=A0=A0 Client -> Server=A0=A0=A0=A0 TCP:Flags=3D.=
..AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857619 =
- 1257857625, Ack=3D15386461

Linux responds in ~200ms, not the suggested 1 second, but this is still not=
 very helpful. =A0The RTO =A0of 200ms recovers better than the suggested mi=
nimum RTO, but 200ms is way too long as we have a sub-millisecond RTT. A si=
milar test with a Windows host showed a minimum RTO of ~300ms.=20


1. Why was the now quaint 1 second minimum RTO carried over into RFC 6298?=
=20
2. Is there a way we can get the minimum RTO down below even 200ms in a low=
 latency network without breaking other TCP features?

I can see some discussion on the internet about this but I don't see moveme=
nt to come up reasonable modern value the most recent RFC 6298.

e.g. http://www.icir.org/mallman/papers/draft-allman-tcpm-rto-consider-00.t=
xt


    Also, note, that in addition to the experiments discussed in [AP99],
    the Linux TCP implementation has been using various non-standard RTO
    mechanisms for many years seemingly without large scale problems
    (e.g., using different EWMA gains).  Also, a number of
    implementations use minimum RTOs that are less than the 1 second
    specified in [RFC2988].  While the precise implications of this may
    show more spurious retransmits (per [AP99]) we are aware of no large
    scale problems caused by this change to the minimum RTO

Mark Lloyd | Enterprise Network Engineer
F5 Networks=20



From hkchu@google.com  Tue Apr 10 13:57:07 2012
Return-Path: <hkchu@google.com>
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 E47B411E814B for <tcpm@ietfa.amsl.com>; Tue, 10 Apr 2012 13:57:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vho5CGRVhGPY for <tcpm@ietfa.amsl.com>; Tue, 10 Apr 2012 13:57:06 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A014811E8149 for <tcpm@ietf.org>; Tue, 10 Apr 2012 13:57:05 -0700 (PDT)
Received: by lbok13 with SMTP id k13so200948lbo.31 for <tcpm@ietf.org>; Tue, 10 Apr 2012 13:57:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=8RTa1zdPkKR1E8fktgbEK0UpoIbvFYTwRPLlhRRYRHI=; b=IMhcND8MsB0dwvdOpri0VrxVkpBhgal1UMBWG/dcWrgMRUjYdAukRYPAWxnNbabr1l pt5DyBTmSp3v0efcAR7ZEvOJXwxBITqPHaNlqIP48K+8FIHovV3f0JWR5kg5muMHUtvV YdoWhlFLcVIN5CXcfihZTiQ9TLMEaCm3y7TKWvIt8UbD/t8isc5yTLJ9VyzpVRS4FGTx avkhQ0mEtYVZrGFu+bPKYOK/dPuD5r3MJkF/yD2a6LR/+eOkGrtcfw/OrcW4cMiLP+hq 57AHKZEtfnHnLoZuJunkiEAr9l2ulOhIhJCWNka7v/1aREkWJsv3V8c2S/GlZdsGzOOf ZL/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=8RTa1zdPkKR1E8fktgbEK0UpoIbvFYTwRPLlhRRYRHI=; b=dsQk/UNrlbEiESuMKT8vRBqC2kaNsM5YUwvAavdKr4QLuCwCVeVWi3amJKLM/+1Fda b3sObfowJNbDhVuznWJ7/6CqMZFIfVT2Yu5cgKMNF4j3sjypZzpW+JzcJoqqpzERkGYB EzkF04IDwobVlLE4qyycHt7rzYuRh0X4dmoltgTfooehN2ajnAFkERw5Cyj0zxZ2pd4p uqhZNlkq3HMFdb6DvSY+5jRBPiSpLI7i4sUgrk/rdHxzmXQLQCVhlmTsePOAZzRo3q8d 7NUbNN50rEqbux4CUQOPqAlK6/QG7YVyrtNS47vrIcQeH6IUcpMG27UjFYVZfx4MMNpO 7t9A==
Received: by 10.152.103.134 with SMTP id fw6mr16023975lab.20.1334091424578; Tue, 10 Apr 2012 13:57:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.103.134 with SMTP id fw6mr16023969lab.20.1334091424484; Tue, 10 Apr 2012 13:57:04 -0700 (PDT)
Received: by 10.152.29.236 with HTTP; Tue, 10 Apr 2012 13:57:04 -0700 (PDT)
In-Reply-To: <2A08B7ACA17C9F4BAA8D5395DF908D731DED9A27@SEAEMBX02.olympus.F5Net.com>
References: <2A08B7ACA17C9F4BAA8D5395DF908D731DED9A27@SEAEMBX02.olympus.F5Net.com>
Date: Tue, 10 Apr 2012 13:57:04 -0700
Message-ID: <CAPshTCh_vn6qKAs8_X3VFVT=nBOL4rg80s7SMjk=KDiG3yjHmw@mail.gmail.com>
From: Jerry Chu <hkchu@google.com>
To: Mark Lloyd <M.Lloyd@f5.com>
Content-Type: multipart/alternative; boundary=f46d040716eb744eed04bd595dfd
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQkBDiz0P6BvT3AW5Ze1Oyh/bzIFCN972b7NacWH7oD8hEfjubho7E+NWpYMqaZV8iqiJY+NAs0dEV59UixLTsK2ESg9I/T1bRCWvgMnuiz8hwNgof00+awiSBKNfL0fkXWkniHW
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] Minimum RTO
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 20:57:08 -0000

--f46d040716eb744eed04bd595dfd
Content-Type: text/plain; charset=ISO-8859-1

Mark,

RFC6298 is mainly for reducing the initial RTO from 3secs to 1sec. We
did not touch the minimum RTO due to a lack of consensus and also
for fear of opening a prolonged debate. Besides, OSes have reduced
minRTO anyway as you noted.

Personally I don't think a somewhat arbitrary RTO lower bound is really
necessary, but delayed acks complicate the matter.

Jerry

On Tue, Apr 10, 2012 at 12:52 PM, Mark Lloyd <M.Lloyd@f5.com> wrote:

> Reading RFC 6298
>
> http://tools.ietf.org/html/rfc6298
>
>
>  (2.4) Whenever RTO is computed, if it is less than 1 second, then the
>          RTO SHOULD be rounded up to 1 second.
>
>
> While troubleshooting a problem that involves minimum RTO, I found that
> RFC 6298 suggests a 1 second value for minimum RTO that is not honored in
> the implementations I have tested, and even in these implementation TCP
> does not do a good job of handling packet loss in a common scenario I
> tested.
>
> I use two Linux hosts as my test. They are setup to imitate the kind of
> connection that would be used for a database or RPC transaction.
>
> My server does a netcat command that loops back data as it is received:
>
> touch /tmp/testfile
> tail -f /tmp/testfile | sudo nc -l 1000 >>/tmp/testfile
>
> The client sends data, then echos a response simulating a TCP conversation
> of small transactions.
>
> touch  /tmp/testfile
> echo hello >/tmp/testfile
> tail -f /tmp/testfile | nc 10.10.30.121 1000 >>/tmp/testfile
>
> I then setup a wan emulator to simulate a 1% loss rate back to the client.
>
> I'm showing frames leading up to the packet loss to show the what the
> traffic looks like up to the packet loss.
>
> Server side:
>
> Frm    Time
> Num    Delta
> 1941   0.0000830     Server -> Client     TCP:Flags=...AP...,
> SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646100 - 1538646106,
> Ack=1257857589,
> 1942   0.0005920     Client -> Server     TCP:Flags=...AP...,
> SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857589 - 1257857595,
> Ack=1538646106
> 1943   0.0000920     Server -> Client     TCP:Flags=...AP...,
> SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646106 - 1538646112,
> Ack=1257857595
> 1944   0.0005590     Client -> Server     TCP:Flags=...AP...,
> SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857595 - 1257857601,
> Ack=1538646112
> 1945   0.0000730     Server -> Client     TCP:Flags=...AP...,
> SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646112 - 1538646118,
> Ack=1257857601
> 1946   0.0005770     Client -> Server     TCP:Flags=...AP...,
> SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857601 - 1257857607,
> Ack=1538646118
> 1947   0.0000930     Server -> Client     TCP:Flags=...AP...,
> SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646118 - 1538646124,
> Ack=1257857607
> 1948   0.0006190     Client -> Server     TCP:Flags=...AP...,
> SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857607 - 1257857613,
> Ack=1538646124
> 1949   0.0000790     Server -> Client     TCP:Flags=...AP...,
> SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646124 - 1538646130,
> Ack=1257857613
> 1950   0.0005110     Client -> Server     TCP:Flags=...AP...,
> SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857613 - 1257857619,
> Ack=1538646130
> 1951   0.0000850     Server -> Client     TCP:Flags=...AP...,
> SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646130 - 1538646136,
> Ack=1257857619
>                                          Packet 1951 will be lost in
> transit. Note 205ms gap.
>
> 1952   0.2053670     Client -> Server     TCP:[ReTransmit
> #1950]Flags=...AP..., SrcPort=55552, DstPort=1001, PayloadLen=6,
> Seq=1257857613 - 1257857619
> 1953   0.0000420     Server -> Client     TCP:Flags=...A....,
> SrcPort=1001, DstPort=55552, PayloadLen=0, Seq=1538646136, Ack=1257857619
> 1954   0.0007630     Server -> Client     TCP:[ReTransmit #1951]
> Flags=...AP..., SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646130 -
> 1538646136, Ack=1257857619
> 1955   0.0006640     Client -> Server     TCP:Flags=...AP...,
> SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857619 - 1257857625,
> Ack=1538646136
>
> Client side:
>
> 1928   0.0006400     Server -> Client     TCP:Flags=...AP...,
> SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646094 - 1538646100,
> Ack=1257857583
> 1929   0.0000690     Client -> Server     TCP:Flags=...AP...,
> SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857583 - 1257857589,
> Ack=1538646100
> 1930   0.0006200     Server -> Client     TCP:Flags=...AP...,
> SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646100 - 1538646106,
> Ack=1257857589
> 1931   0.0000690     Client -> Server     TCP:Flags=...AP...,
> SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857589 - 1257857595,
> Ack=1538646106
> 1932   0.0006300     Server -> Client     TCP:Flags=...AP...,
> SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646106 - 1538646112,
> Ack=1257857595
> 1933   0.0000730     Client -> Server     TCP:Flags=...AP...,
> SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857595 - 1257857601,
> Ack=1538646112
> 1934   0.0005230     Server -> Client     TCP:Flags=...AP...,
> SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646112 - 1538646118,
> Ack=1257857601
> 1935   0.0000830     Client -> Server     TCP:Flags=...AP...,
> SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857601 - 1257857607,
> Ack=1538646118
> 1936   0.0006140     Server -> Client     TCP:Flags=...AP...,
> SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646118 - 1538646124,
> Ack=1257857607
> 1937   0.0000750     Client -> Server     TCP:Flags=...AP...,
> SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857607 - 1257857613,
> Ack=1538646124
> 1938   0.0006230     Server -> Client     TCP:Flags=...AP...,
> SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646124 - 1538646130,
> Ack=1257857613
> 1939   0.0000650     Client -> Server     TCP:Flags=...AP...,
> SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857613 - 1257857619,
> Ack=1538646130
>                                          Packet does not arrive from
> server. Client retransmits in 205ms.
>
> 1940   0.2053300     Client -> Server     TCP:[ReTransmit #1939]
> Flags=...AP..., SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857613 -
> 1257857619, Ack=1538646130
> 1941   0.0006840     Server -> Client     TCP:Flags=...A....,
> SrcPort=1001, DstPort=55552, PayloadLen=0, Seq=1538646136, Ack=1257857619
> 1942   0.0006970     Server -> Client     TCP:Flags=...AP...,
> SrcPort=1001, DstPort=55552, PayloadLen=6, Seq=1538646130 - 1538646136,
> Ack=1257857619,
> 1943   0.0001120     Client -> Server     TCP:Flags=...AP...,
> SrcPort=55552, DstPort=1001, PayloadLen=6, Seq=1257857619 - 1257857625,
> Ack=15386461
>
> Linux responds in ~200ms, not the suggested 1 second, but this is still
> not very helpful.  The RTO  of 200ms recovers better than the suggested
> minimum RTO, but 200ms is way too long as we have a sub-millisecond RTT. A
> similar test with a Windows host showed a minimum RTO of ~300ms.
>
>
> 1. Why was the now quaint 1 second minimum RTO carried over into RFC 6298?
> 2. Is there a way we can get the minimum RTO down below even 200ms in a
> low latency network without breaking other TCP features?
>
> I can see some discussion on the internet about this but I don't see
> movement to come up reasonable modern value the most recent RFC 6298.
>
> e.g.
> http://www.icir.org/mallman/papers/draft-allman-tcpm-rto-consider-00.txt
>
>
>    Also, note, that in addition to the experiments discussed in [AP99],
>    the Linux TCP implementation has been using various non-standard RTO
>    mechanisms for many years seemingly without large scale problems
>    (e.g., using different EWMA gains).  Also, a number of
>    implementations use minimum RTOs that are less than the 1 second
>    specified in [RFC2988].  While the precise implications of this may
>    show more spurious retransmits (per [AP99]) we are aware of no large
>    scale problems caused by this change to the minimum RTO
>
> Mark Lloyd | Enterprise Network Engineer
> F5 Networks
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

--f46d040716eb744eed04bd595dfd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Mark,<div><br></div><div>RFC6298 is mainly for reducing the initial RTO fro=
m 3secs to 1sec. We</div><div>did not touch the minimum RTO due to a lack o=
f consensus and also</div><div>for fear of opening a prolonged debate. Besi=
des, OSes have reduced</div>
<div>minRTO anyway as you noted.</div><div><br></div><div>Personally I don&=
#39;t think a somewhat arbitrary RTO lower bound is really</div><div>necess=
ary, but delayed acks complicate the matter.</div><div><br></div><div>Jerry=
<br>
<br><div class=3D"gmail_quote">On Tue, Apr 10, 2012 at 12:52 PM, Mark Lloyd=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:M.Lloyd@f5.com">M.Lloyd@f5.com</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Reading RFC 6298<br>
<br>
<a href=3D"http://tools.ietf.org/html/rfc6298" target=3D"_blank">http://too=
ls.ietf.org/html/rfc6298</a><br>
<br>
<br>
=A0(2.4) Whenever RTO is computed, if it is less than 1 second, then the<br=
>
=A0=A0=A0=A0=A0=A0=A0=A0 RTO SHOULD be rounded up to 1 second.<br>
<br>
<br>
While troubleshooting a problem that involves minimum RTO, I found that RFC=
 6298 suggests a 1 second value for minimum RTO that is not honored in the =
implementations I have tested, and even in these implementation TCP does no=
t do a good job of handling packet loss in a common scenario I tested.<br>

<br>
I use two Linux hosts as my test. They are setup to imitate the kind of con=
nection that would be used for a database or RPC transaction.<br>
<br>
My server does a netcat command that loops back data as it is received:<br>
<br>
touch /tmp/testfile<br>
tail -f /tmp/testfile | sudo nc -l 1000 &gt;&gt;/tmp/testfile<br>
<br>
The client sends data, then echos a response simulating a TCP conversation =
of small transactions.<br>
<br>
touch=A0 /tmp/testfile<br>
echo hello &gt;/tmp/testfile<br>
tail -f /tmp/testfile | nc 10.10.30.121 1000 &gt;&gt;/tmp/testfile<br>
<br>
I then setup a wan emulator to simulate a 1% loss rate back to the client.<=
br>
<br>
I&#39;m showing frames leading up to the packet loss to show the what the t=
raffic looks like up to the packet loss.=A0<br>
<br>
Server side:<br>
<br>
Frm=A0=A0=A0 Time =A0=A0=A0=A0=A0=A0=A0=A0<br>
Num=A0=A0=A0 Delta=A0=A0=A0=A0=A0=A0=A0=A0<br>
1941=A0=A0 0.0000830=A0=A0=A0=A0 Server -&gt; Client=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646=
100 - 1538646106, Ack=3D1257857589,<br>
1942=A0=A0 0.0005920=A0=A0=A0=A0 Client -&gt; Server=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857=
589 - 1257857595, Ack=3D1538646106<br>
1943=A0=A0 0.0000920=A0=A0=A0=A0 Server -&gt; Client=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646=
106 - 1538646112, Ack=3D1257857595<br>
1944=A0=A0 0.0005590=A0=A0=A0=A0 Client -&gt; Server=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857=
595 - 1257857601, Ack=3D1538646112<br>
1945=A0=A0 0.0000730=A0=A0=A0=A0 Server -&gt; Client=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646=
112 - 1538646118, Ack=3D1257857601<br>
1946=A0=A0 0.0005770=A0=A0=A0=A0 Client -&gt; Server=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857=
601 - 1257857607, Ack=3D1538646118<br>
1947=A0=A0 0.0000930=A0=A0=A0=A0 Server -&gt; Client=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646=
118 - 1538646124, Ack=3D1257857607<br>
1948=A0=A0 0.0006190=A0=A0=A0=A0 Client -&gt; Server=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857=
607 - 1257857613, Ack=3D1538646124<br>
1949=A0=A0 0.0000790=A0=A0=A0=A0 Server -&gt; Client=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646=
124 - 1538646130, Ack=3D1257857613<br>
1950=A0=A0 0.0005110=A0=A0=A0=A0 Client -&gt; Server=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857=
613 - 1257857619, Ack=3D1538646130<br>
1951=A0=A0 0.0000850=A0=A0=A0=A0 Server -&gt; Client=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646=
130 - 1538646136, Ack=3D1257857619<br>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Packet 1951 will be lost in t=
ransit. Note 205ms gap.<br>
<br>
1952=A0=A0 0.2053670=A0=A0=A0=A0 Client -&gt; Server=A0=A0=A0=A0 TCP:[ReTra=
nsmit #1950]Flags=3D...AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=
=3D6, Seq=3D1257857613 - 1257857619<br>
1953=A0=A0 0.0000420=A0=A0=A0=A0 Server -&gt; Client=A0=A0=A0=A0 TCP:Flags=
=3D...A...., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D0, Seq=3D1538646=
136, Ack=3D1257857619<br>
1954=A0=A0 0.0007630=A0=A0=A0=A0 Server -&gt; Client=A0=A0=A0=A0 TCP:[ReTra=
nsmit #1951] Flags=3D...AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=
=3D6, Seq=3D1538646130 - 1538646136, Ack=3D1257857619<br>
1955=A0=A0 0.0006640=A0=A0=A0=A0 Client -&gt; Server=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857=
619 - 1257857625, Ack=3D1538646136<br>
<br>
Client side:<br>
<br>
1928=A0=A0 0.0006400=A0=A0=A0=A0 Server -&gt; Client=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646=
094 - 1538646100, Ack=3D1257857583<br>
1929=A0=A0 0.0000690=A0=A0=A0=A0 Client -&gt; Server=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857=
583 - 1257857589, Ack=3D1538646100<br>
1930=A0=A0 0.0006200=A0=A0=A0=A0 Server -&gt; Client=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646=
100 - 1538646106, Ack=3D1257857589<br>
1931=A0=A0 0.0000690=A0=A0=A0=A0 Client -&gt; Server=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857=
589 - 1257857595, Ack=3D1538646106<br>
1932=A0=A0 0.0006300=A0=A0=A0=A0 Server -&gt; Client=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646=
106 - 1538646112, Ack=3D1257857595<br>
1933=A0=A0 0.0000730=A0=A0=A0=A0 Client -&gt; Server=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857=
595 - 1257857601, Ack=3D1538646112<br>
1934=A0=A0 0.0005230=A0=A0=A0=A0 Server -&gt; Client=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646=
112 - 1538646118, Ack=3D1257857601<br>
1935=A0=A0 0.0000830=A0=A0=A0=A0 Client -&gt; Server=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857=
601 - 1257857607, Ack=3D1538646118<br>
1936=A0=A0 0.0006140=A0=A0=A0=A0 Server -&gt; Client=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646=
118 - 1538646124, Ack=3D1257857607<br>
1937=A0=A0 0.0000750=A0=A0=A0=A0 Client -&gt; Server=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857=
607 - 1257857613, Ack=3D1538646124<br>
1938=A0=A0 0.0006230=A0=A0=A0=A0 Server -&gt; Client=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646=
124 - 1538646130, Ack=3D1257857613<br>
1939=A0=A0 0.0000650=A0=A0=A0=A0 Client -&gt; Server=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857=
613 - 1257857619, Ack=3D1538646130<br>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0 Packet does not arrive from ser=
ver. Client retransmits in 205ms.<br>
<br>
1940=A0=A0 0.2053300=A0=A0=A0=A0 Client -&gt; Server=A0=A0=A0=A0 TCP:[ReTra=
nsmit #1939] Flags=3D...AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=
=3D6, Seq=3D1257857613 - 1257857619, Ack=3D1538646130<br>
1941=A0=A0 0.0006840=A0=A0=A0=A0 Server -&gt; Client=A0=A0=A0=A0 TCP:Flags=
=3D...A...., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D0, Seq=3D1538646=
136, Ack=3D1257857619<br>
1942=A0=A0 0.0006970=A0=A0=A0=A0 Server -&gt; Client=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D1001, DstPort=3D55552, PayloadLen=3D6, Seq=3D1538646=
130 - 1538646136, Ack=3D1257857619,<br>
1943=A0=A0 0.0001120=A0=A0=A0=A0 Client -&gt; Server=A0=A0=A0=A0 TCP:Flags=
=3D...AP..., SrcPort=3D55552, DstPort=3D1001, PayloadLen=3D6, Seq=3D1257857=
619 - 1257857625, Ack=3D15386461<br>
<br>
Linux responds in ~200ms, not the suggested 1 second, but this is still not=
 very helpful. =A0The RTO =A0of 200ms recovers better than the suggested mi=
nimum RTO, but 200ms is way too long as we have a sub-millisecond RTT. A si=
milar test with a Windows host showed a minimum RTO of ~300ms.<br>

<br>
<br>
1. Why was the now quaint 1 second minimum RTO carried over into RFC 6298?<=
br>
2. Is there a way we can get the minimum RTO down below even 200ms in a low=
 latency network without breaking other TCP features?<br>
<br>
I can see some discussion on the internet about this but I don&#39;t see mo=
vement to come up reasonable modern value the most recent RFC 6298.<br>
<br>
e.g. <a href=3D"http://www.icir.org/mallman/papers/draft-allman-tcpm-rto-co=
nsider-00.txt" target=3D"_blank">http://www.icir.org/mallman/papers/draft-a=
llman-tcpm-rto-consider-00.txt</a><br>
<br>
<br>
 =A0 =A0Also, note, that in addition to the experiments discussed in [AP99]=
,<br>
 =A0 =A0the Linux TCP implementation has been using various non-standard RT=
O<br>
 =A0 =A0mechanisms for many years seemingly without large scale problems<br=
>
 =A0 =A0(e.g., using different EWMA gains). =A0Also, a number of<br>
 =A0 =A0implementations use minimum RTOs that are less than the 1 second<br=
>
 =A0 =A0specified in [RFC2988]. =A0While the precise implications of this m=
ay<br>
 =A0 =A0show more spurious retransmits (per [AP99]) we are aware of no larg=
e<br>
 =A0 =A0scale problems caused by this change to the minimum RTO<br>
<br>
Mark Lloyd | Enterprise Network Engineer<br>
F5 Networks<br>
<br>
<br>
_______________________________________________<br>
tcpm mailing list<br>
<a href=3D"mailto:tcpm@ietf.org">tcpm@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tcpm" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/tcpm</a><br>
</blockquote></div><br></div>

--f46d040716eb744eed04bd595dfd--

From mallman@icir.org  Wed Apr 11 06:32:33 2012
Return-Path: <mallman@icir.org>
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 1601111E8141 for <tcpm@ietfa.amsl.com>; Wed, 11 Apr 2012 06:32:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.58
X-Spam-Level: 
X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiEakuNh2h8A for <tcpm@ietfa.amsl.com>; Wed, 11 Apr 2012 06:32:32 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5045211E8122 for <tcpm@ietf.org>; Wed, 11 Apr 2012 06:32:32 -0700 (PDT)
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 q3BDWUFi000250; Wed, 11 Apr 2012 06:32:30 -0700 (PDT)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9CDE012451DD; Wed, 11 Apr 2012 09:32:29 -0400 (EDT)
To: Mark Lloyd <M.Lloyd@f5.com>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <2A08B7ACA17C9F4BAA8D5395DF908D731DED9A27@SEAEMBX02.olympus.F5Net.com>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: My City of Ruin
X-URL-0: http://www.icir.org/mallman-files/Document81412.jpg
X-URL-1: http://www.icir.org/mallman-files/Document15841.xls
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma34794-1"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Wed, 11 Apr 2012 09:32:29 -0400
Sender: mallman@icir.org
Message-Id: <20120411133229.9CDE012451DD@lawyers.icir.org>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] Minimum RTO
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 <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 13:32:33 -0000

----------ma34794-1
Content-Type: text/plain
Content-Disposition: inline


> 1. Why was the now quaint 1 second minimum RTO carried over into RFC
>    6298?  

As Jerry noted, we have no idea what else to do.  There is no empirical
evidence that says we have a better general value.  That doesn't mean it
needs to be 1sec.  It just means we have no good basis for some other
arbitrary number.

And, we empirically know 1sec is fairly safe in terms of spurious RTOs.

One of the things I have found over many years of talking to many people
about this is that they do precisely what you showed in your email: they
observe that the min means you wait too long for needed retransmissions.
Well, for needed retransmits *anything* is too long.
I.e., we could wait 1msec and retransmit and *that* would delay us by
1msec over some ideal.  So, no matter what the min is, it is too
conservative.

However, that doesn't take into account the other side of the equation,
which is that aggressiveness leads to unnecessary retransmits and those
lead to collapsing the cwnd.  Now, that might not be an issue for tiny
db transactions.  And, we might be able to undo things with a bit of
effort and a bit of delay.  But, in general, this is the balancing act
one is trying to perform.  You want to wait just long enough to
unambiguously determine you need a rexmt, but no longer.  If you fall on
either side of that point then you're sacrificing performance in one way
or the other.

> 2. Is there a way we can get the minimum RTO down below even 200ms in
>    a low latency network without breaking other TCP features? 

I think a couple of things ...

  - In your own internal, low-latency network you can tune your TCP to
    use whatever min you want.  Who cares?  If you end up shooting
    yourself in the foot then, well, its your own damn foot.

  - My *hunch* is that a general setting of less than 200msec would
    probably mean a reduction in overall performance.  That doesn't mean
    it would do so in your particular environment.  It means that if
    some general purpose OS set it to something under 200msec then I
    would bet a single beer that would not be an overall helpful
    setting.

  - But, that said, I think in general we should get out of the
    parameter setting business where we can (per the quote from the
    expired I-D in your note).  In this case, the process fails safe.
    I.e., if you're too aggressive with the RTO estimator (because you
    tweaked the min or the gains or whatever) then it means you
    retransmit when you don't need to.  And, so (a) there is no
    congestion to react to, but you're reacting anyway and (b) even if
    there is some congestion you are reacting conservatively by using a
    cwnd of one and employing exponential backoff.  So, as long as a few
    big picture principles are used I think the details do not need to
    be uniformly applied.  (It doesn't hurt to write down RTO estimators
    as particular ways to do things---a la RFC 6298---but there is IMHO
    no reason everyone has to use the same RTO estimator.

> e.g. http://www.icir.org/mallman/papers/draft-allman-tcpm-rto-consider-00.txt

This has expired.  It didn't gain a lot of traction.  I'd be happy to do
a quick pass through it for any comments that never got rolled in and
re-issue it if folks think it is useful.  I personally think it is The
Way To Go.  But, I am not WG consensus.

allman




----------ma34794-1
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iEYEARECAAYFAk+Fh+0ACgkQWyrrWs4yIs5FigCfcsaQJrEM6v2kdevfwUt/mMi7
kYMAoJ744p9FlxppyQTDa6s+KAfJW4ip
=OGTi
-----END PGP SIGNATURE-----
----------ma34794-1--

From ananth@cisco.com  Wed Apr 11 08:21:58 2012
Return-Path: <ananth@cisco.com>
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 39E6921F846F for <tcpm@ietfa.amsl.com>; Wed, 11 Apr 2012 08:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.153
X-Spam-Level: 
X-Spam-Status: No, score=-10.153 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYgod5FCmv52 for <tcpm@ietfa.amsl.com>; Wed, 11 Apr 2012 08:21:56 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4624221F848C for <tcpm@ietf.org>; Wed, 11 Apr 2012 08:21:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=4620; q=dns/txt; s=iport; t=1334157714; x=1335367314; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=EfE2k8nh+jF0Jr1LrBTinThkVOyZ9sM+DVvxl0Xj8rM=; b=QpnVHaoPaSVxNM78CnwQWzVzASJT+HNtOg4vht/Eot42qZeFd1hq9+6C 1RvBjdxzwbPVmntry0loHnFVxiW0UL8QPT3ntYRYNQb7QwIWUPpjsa/w0 yuslNsIkw553bk3tNyJnZ9syIf0KQi+jdbFKeW5QjtqlXpOeortZEhEOi k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EACqhhU+rRDoI/2dsb2JhbABFuU6BB4IJAQEBBBIBHQotBQoDDAQCAQgRBAEBCwYFEgEGAUUJCAEBBAESCAEZh2sBC5pgoCmOFoJNYwSIWptfgWmDB4E8
X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="37455936"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 11 Apr 2012 15:21:53 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3BFLrUl032755; Wed, 11 Apr 2012 15:21:53 GMT
Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 11 Apr 2012 08:21:53 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 11 Apr 2012 08:21:52 -0700
Message-ID: <1F8E0A684D3FF54680294BCFE57A7DB504DE5508@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <20120411133229.9CDE012451DD@lawyers.icir.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] Minimum RTO
Thread-Index: Ac0X55Ci9JXst32QRqKbGvJxkZ3q5wADVt+Q
References: <2A08B7ACA17C9F4BAA8D5395DF908D731DED9A27@SEAEMBX02.olympus.F5Net.com> <20120411133229.9CDE012451DD@lawyers.icir.org>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: <mallman@icir.org>, "Mark Lloyd" <M.Lloyd@f5.com>
X-OriginalArrivalTime: 11 Apr 2012 15:21:53.0338 (UTC) FILETIME=[D305D1A0:01CD17F6]
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Minimum RTO
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 15:21:58 -0000

Hi Mark(s),

FWIW, just as a data point.  Our main Os'es (some of them in the field
for more than 20+ years, although I suspect the RTO change would have
been there for at least 10+ years) have been using min RTO less than 1
sec. in the range (300ms - 600ms). In some cases we had to go back to
the 1 sec (esp in case of WAN optimization proxies which is over a WAN
link where spurious timeout's were interfering with the throughput.)
However for most of the other apps, sub-second RTO's have been working
ok.

In other words, most implementations (if I can say that) have been
relaxing the min RTO restriction. It is treated like a SHOULD (MAY?)
instead of a MUST.=20

I support the "rto-reconsider" draft.

Thanks,
-Anantha

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf
Of
> Mark Allman
> Sent: Wednesday, April 11, 2012 6:32 AM
> To: Mark Lloyd
> Cc: tcpm@ietf.org
> Subject: Re: [tcpm] Minimum RTO
>=20
>=20
> > 1. Why was the now quaint 1 second minimum RTO carried over into RFC
> >    6298?
>=20
> As Jerry noted, we have no idea what else to do.  There is no
empirical
> evidence that says we have a better general value.  That doesn't mean
> it needs to be 1sec.  It just means we have no good basis for some
> other arbitrary number.
>=20
> And, we empirically know 1sec is fairly safe in terms of spurious
RTOs.
>=20
> One of the things I have found over many years of talking to many
> people about this is that they do precisely what you showed in your
> email: they observe that the min means you wait too long for needed
> retransmissions.
> Well, for needed retransmits *anything* is too long.
> I.e., we could wait 1msec and retransmit and *that* would delay us by
> 1msec over some ideal.  So, no matter what the min is, it is too
> conservative.
>=20
> However, that doesn't take into account the other side of the
equation,
> which is that aggressiveness leads to unnecessary retransmits and
those
> lead to collapsing the cwnd.  Now, that might not be an issue for tiny
> db transactions.  And, we might be able to undo things with a bit of
> effort and a bit of delay.  But, in general, this is the balancing act
> one is trying to perform.  You want to wait just long enough to
> unambiguously determine you need a rexmt, but no longer.  If you fall
> on either side of that point then you're sacrificing performance in
one
> way or the other.
>=20
> > 2. Is there a way we can get the minimum RTO down below even 200ms
in
> >    a low latency network without breaking other TCP features?
>=20
> I think a couple of things ...
>=20
>   - In your own internal, low-latency network you can tune your TCP to
>     use whatever min you want.  Who cares?  If you end up shooting
>     yourself in the foot then, well, its your own damn foot.
>=20
>   - My *hunch* is that a general setting of less than 200msec would
>     probably mean a reduction in overall performance.  That doesn't
> mean
>     it would do so in your particular environment.  It means that if
>     some general purpose OS set it to something under 200msec then I
>     would bet a single beer that would not be an overall helpful
>     setting.
>=20
>   - But, that said, I think in general we should get out of the
>     parameter setting business where we can (per the quote from the
>     expired I-D in your note).  In this case, the process fails safe.
>     I.e., if you're too aggressive with the RTO estimator (because you
>     tweaked the min or the gains or whatever) then it means you
>     retransmit when you don't need to.  And, so (a) there is no
>     congestion to react to, but you're reacting anyway and (b) even if
>     there is some congestion you are reacting conservatively by using
a
>     cwnd of one and employing exponential backoff.  So, as long as a
> few
>     big picture principles are used I think the details do not need to
>     be uniformly applied.  (It doesn't hurt to write down RTO
> estimators
>     as particular ways to do things---a la RFC 6298---but there is
IMHO
>     no reason everyone has to use the same RTO estimator.
>=20
> > e.g.
> > http://www.icir.org/mallman/papers/draft-allman-tcpm-rto-consider-
> 00.t
> > xt
>=20
> This has expired.  It didn't gain a lot of traction.  I'd be happy to
> do a quick pass through it for any comments that never got rolled in
> and re-issue it if folks think it is useful.  I personally think it is
> The Way To Go.  But, I am not WG consensus.
>=20
> allman
>=20
>=20


From hagen@jauu.net  Wed Apr 11 09:56:35 2012
Return-Path: <hagen@jauu.net>
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 86DAC21F84E6 for <tcpm@ietfa.amsl.com>; Wed, 11 Apr 2012 09:56:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.534
X-Spam-Level: *
X-Spam-Status: No, score=1.534 tagged_above=-999 required=5 tests=[AWL=-3.631,  BAYES_40=-0.185, GB_SUMOF=5, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUZs-6IIaHjw for <tcpm@ietfa.amsl.com>; Wed, 11 Apr 2012 09:56:35 -0700 (PDT)
Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by ietfa.amsl.com (Postfix) with ESMTP id CC55C21F84DE for <tcpm@ietf.org>; Wed, 11 Apr 2012 09:56:34 -0700 (PDT)
Received: by geheimer.internetendpunkt.de (Postfix, from userid 33) id 76EC5F44181; Wed, 11 Apr 2012 18:56:33 +0200 (CEST)
To: Mark Lloyd <M.Lloyd@F5.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Date: Wed, 11 Apr 2012 18:56:33 +0200
From: Hagen Paul Pfeifer <hagen@jauu.net>
In-Reply-To: <2A08B7ACA17C9F4BAA8D5395DF908D731DED9A27@SEAEMBX02.olympus.F5Net.com>
References: <2A08B7ACA17C9F4BAA8D5395DF908D731DED9A27@SEAEMBX02.olympus.F5Net.com>
Message-ID: <d30b847cb69c00d198eef2447cdec8a1@localhost>
X-Sender: hagen@jauu.net
User-Agent: RoundCube Webmail/0.1-rc1
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Minimum RTO
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 16:56:35 -0000

On Tue, 10 Apr 2012 19:52:52 +0000, Mark Lloyd <M.Lloyd@F5.com> wrote:
 
> 1. Why was the now quaint 1 second minimum RTO carried over into RFC
6298? 
> 2. Is there a way we can get the minimum RTO down below even 200ms in a
> low latency network without breaking other TCP features?

Maybe a helpful link:

http://utopia.duth.gr/~ipsaras/minrto-networking07-psaras.pdf

Hagen

PS: the IETF do not focus on low latency networks. The sum of all network
characteristics is important. (just as a reminder).

PPS: with Linux you can already modify the minimum RTO via a per route
option (RTAX_RTO_MIN via iproute)

From muraris@microsoft.com  Wed Apr 11 10:04:43 2012
Return-Path: <muraris@microsoft.com>
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 61F6C21F8505 for <tcpm@ietfa.amsl.com>; Wed, 11 Apr 2012 10:04:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poJUoIrv9Qqq for <tcpm@ietfa.amsl.com>; Wed, 11 Apr 2012 10:04:42 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4F86B21F8504 for <tcpm@ietf.org>; Wed, 11 Apr 2012 10:04:42 -0700 (PDT)
Received: from mail15-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 11 Apr 2012 17:04:41 +0000
Received: from mail15-va3 (localhost [127.0.0.1])	by mail15-va3-R.bigfish.com (Postfix) with ESMTP id A347B1E05AC; Wed, 11 Apr 2012 17:04:41 +0000 (UTC)
X-SpamScore: -26
X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail15-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=muraris@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail15-va3 (localhost.localdomain [127.0.0.1]) by mail15-va3 (MessageSwitch) id 1334163879774294_4230; Wed, 11 Apr 2012 17:04:39 +0000 (UTC)
Received: from VA3EHSMHS024.bigfish.com (unknown [10.7.14.244])	by mail15-va3.bigfish.com (Postfix) with ESMTP id B431CE006E; Wed, 11 Apr 2012 17:04:39 +0000 (UTC)
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS024.bigfish.com (10.7.99.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 11 Apr 2012 17:04:37 +0000
Received: from TK5EX14MBXC299.redmond.corp.microsoft.com ([169.254.2.71]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0283.004; Wed, 11 Apr 2012 17:04:16 +0000
From: Murari Sridharan <muraris@microsoft.com>
To: "mallman@icir.org" <mallman@icir.org>, Mark Lloyd <M.Lloyd@f5.com>
Thread-Topic: [tcpm] Minimum RTO
Thread-Index: Ac0XUohcmbM7TRaYTSmihLMk0Ba66gAlQICAAAdSWUA=
Date: Wed, 11 Apr 2012 17:04:16 +0000
Message-ID: <EF5EF2B13ED09B4F871D9A0DBCA463C21C3CAE22@TK5EX14MBXC299.redmond.corp.microsoft.com>
References: <2A08B7ACA17C9F4BAA8D5395DF908D731DED9A27@SEAEMBX02.olympus.F5Net.com> <20120411133229.9CDE012451DD@lawyers.icir.org>
In-Reply-To: <20120411133229.9CDE012451DD@lawyers.icir.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.70]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] Minimum RTO
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 17:04:43 -0000

We have tried to solve these problems by creating templates, so we have a D=
atacenter template, Internet template and so on. The defaults are appropria=
tely chosen for each template. If the user knows better he can configure a =
template or we configure automatically based on latency characteristics. Mo=
re often than not its enough to differentiate a super low latency datacente=
r network and Internet correctly. If the admin knows better they can config=
ure one. This allowed us to satisfy the diverse needs. There is also a cust=
om template for experimental stuff like larger initial CWnd etc.=20

Thanks

-----Original Message-----
From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Mar=
k Allman
Sent: Wednesday, April 11, 2012 6:32 AM
To: Mark Lloyd
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Minimum RTO


> 1. Why was the now quaint 1 second minimum RTO carried over into RFC
>    6298? =20

As Jerry noted, we have no idea what else to do.  There is no empirical evi=
dence that says we have a better general value.  That doesn't mean it needs=
 to be 1sec.  It just means we have no good basis for some other arbitrary =
number.

And, we empirically know 1sec is fairly safe in terms of spurious RTOs.

One of the things I have found over many years of talking to many people ab=
out this is that they do precisely what you showed in your email: they obse=
rve that the min means you wait too long for needed retransmissions.
Well, for needed retransmits *anything* is too long.
I.e., we could wait 1msec and retransmit and *that* would delay us by 1msec=
 over some ideal.  So, no matter what the min is, it is too conservative.

However, that doesn't take into account the other side of the equation, whi=
ch is that aggressiveness leads to unnecessary retransmits and those lead t=
o collapsing the cwnd.  Now, that might not be an issue for tiny db transac=
tions.  And, we might be able to undo things with a bit of effort and a bit=
 of delay.  But, in general, this is the balancing act one is trying to per=
form.  You want to wait just long enough to unambiguously determine you nee=
d a rexmt, but no longer.  If you fall on either side of that point then yo=
u're sacrificing performance in one way or the other.

> 2. Is there a way we can get the minimum RTO down below even 200ms in
>    a low latency network without breaking other TCP features?=20

I think a couple of things ...

  - In your own internal, low-latency network you can tune your TCP to
    use whatever min you want.  Who cares?  If you end up shooting
    yourself in the foot then, well, its your own damn foot.

  - My *hunch* is that a general setting of less than 200msec would
    probably mean a reduction in overall performance.  That doesn't mean
    it would do so in your particular environment.  It means that if
    some general purpose OS set it to something under 200msec then I
    would bet a single beer that would not be an overall helpful
    setting.

  - But, that said, I think in general we should get out of the
    parameter setting business where we can (per the quote from the
    expired I-D in your note).  In this case, the process fails safe.
    I.e., if you're too aggressive with the RTO estimator (because you
    tweaked the min or the gains or whatever) then it means you
    retransmit when you don't need to.  And, so (a) there is no
    congestion to react to, but you're reacting anyway and (b) even if
    there is some congestion you are reacting conservatively by using a
    cwnd of one and employing exponential backoff.  So, as long as a few
    big picture principles are used I think the details do not need to
    be uniformly applied.  (It doesn't hurt to write down RTO estimators
    as particular ways to do things---a la RFC 6298---but there is IMHO
    no reason everyone has to use the same RTO estimator.

> e.g.=20
> http://www.icir.org/mallman/papers/draft-allman-tcpm-rto-consider-00.t
> xt

This has expired.  It didn't gain a lot of traction.  I'd be happy to do a =
quick pass through it for any comments that never got rolled in and re-issu=
e it if folks think it is useful.  I personally think it is The Way To Go. =
 But, I am not WG consensus.

allman





From Karen.Nielsen@tieto.com  Tue Apr 17 05:50:52 2012
Return-Path: <Karen.Nielsen@tieto.com>
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 ED0A121F866D; Tue, 17 Apr 2012 05:50:51 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+GyFSjwfaYz; Tue, 17 Apr 2012 05:50:46 -0700 (PDT)
Received: from ebb05.tieto.com (ebb05.tieto.com [131.207.168.36]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9B321F8646; Tue, 17 Apr 2012 05:50:45 -0700 (PDT)
X-AuditID: 83cfa824-b7b52ae00000768b-b2-4f8d67248680
Received: from FIHGA-EXHUB01.eu.tieto.com ( [131.207.136.34]) by ebb05.tieto.com (SMTP Mailer) with SMTP id DC.99.30347.4276D8F4; Tue, 17 Apr 2012 15:50:44 +0300 (EEST)
Received: from EXMB03.eu.tieto.com ([169.254.2.108]) by FIHGA-EXHUB01.eu.tieto.com ([131.207.136.34]) with mapi; Tue, 17 Apr 2012 15:50:25 +0300
From: <Karen.Nielsen@tieto.com>
To: <tsvwg-bounces@ietf.org>, <tcpm@ietf.org>
Date: Tue, 17 Apr 2012 15:50:23 +0300
Thread-Topic: CWND increase after under-utilization in congestion avoidance
Thread-Index: Ac0cmKe99Udign6vTCyd7fkv3Fmh0w==
Message-ID: <CF340E42AED0874C81947E18863DE77B14355D604F@EXMB03.eu.tieto.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CF340E42AED0874C81947E18863DE77B14355D604FEXMB03eutieto_"
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: [tcpm] CWND increase after under-utilization in congestion avoidance
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Apr 2012 12:50:52 -0000

--_000_CF340E42AED0874C81947E18863DE77B14355D604FEXMB03eutieto_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

SCTP as prescribed by RFC4960 operates with CWND validation in that CWND in=
crease always
is subject to its fully usage. That is, CWND only may increase when flights=
ize >=3D CWND.
Opposed to TCP, as standardized by RFC5681, CWND is thus not necessarily in=
creased even when partial_bytes_ack
increases beyond the present CWND.

An implementation which boldly augments the partial_bytes_ack during the ti=
me where a CWND is underutilized (but the connection is not idle) may obser=
ve that the partial_bytes_ack increases to a very high value, possibly it i=
ncreases to
a value many times higher than the CWND.

The question now arises what should happen once the CWND resumes fully util=
ization and thus may be increased. That is, is the intention of the standar=
d of SCTP CC to have :

1.      the CWND now be increased as during "normal" congestion control avo=
idance, i.e., one MTU per acked CWND amount  of data

-        Or to have -

2.      the CWND now be allowed to recapture the growth that it did not rea=
lize due to under-utilization but which may be recaptured from the partial_=
bytes_ack value. I.e., let it be increased one MTU per SACK until partial_b=
ytes_ack has been decreased below CWND, one CWND at a time.

>From an implementation perspective the question likely turns into a questio=
n about the maintaining of the partial_bytes_ack value during the period of=
 time when the CWND is underutilized. E.g., should then partial_bytes_ack b=
e decreased with CWND for each times it increases beyond the CWND or should=
 it be allowed to increase unlimited.  But first we need to find out what t=
he intention of the standard is....

The above of course is subject to cumulative SACKs and other details like t=
hat. I hope that we can leave such details out of the discussion.


I hope that you may help.


Thanks in advance!



BR, Karen

--_000_CF340E42AED0874C81947E18863DE77B14355D604FEXMB03eutieto_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta http-equi=
v=3DContent-Type content=3D"text/html; charset=3Dus-ascii"><meta name=3DGen=
erator content=3D"Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:847790449;
	mso-list-type:hybrid;
	mso-list-template-ids:-967946310 -2083592246 67698691 67698693 67698689 67=
698691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:Symbol;
	mso-fareast-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";}
@list l1
	{mso-list-id:1071656159;
	mso-list-type:hybrid;
	mso-list-template-ids:1273820408 67698703 67698691 67698693 67698689 67698=
691 67698693 67698689 67698691 67698693;}
@list l1:level1
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l2
	{mso-list-id:1624582301;
	mso-list-type:hybrid;
	mso-list-template-ids:-921541068 -374453356 67698691 67698693 67698689 676=
98691 67698693 67698689 67698691 67698693;}
@list l2:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:54.0pt;
	text-indent:-18.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:Calibri;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>Hi,<o:p></o:p></=
p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>SCTP as pr=
escribed by RFC4960 operates with CWND validation in that CWND increase alw=
ays<o:p></o:p></p><p class=3DMsoNormal>is subject to its fully usage. That =
is, CWND only may increase when flightsize &gt;=3D CWND. <o:p></o:p></p><p =
class=3DMsoNormal>Opposed to TCP, as standardized by RFC5681, CWND is thus =
not necessarily increased even when partial_bytes_ack<o:p></o:p></p><p clas=
s=3DMsoNormal>increases beyond the present CWND.<o:p></o:p></p><p class=3DM=
soNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>An implementation which =
boldly augments the partial_bytes_ack during the time where a CWND is under=
utilized (but the connection is not idle) may observe that the partial_byte=
s_ack increases to a very high value, possibly it increases to<o:p></o:p></=
p><p class=3DMsoNormal>a value many times higher than the CWND. &nbsp;<o:p>=
</o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Th=
e question now arises what should happen once the CWND resumes fully utiliz=
ation and thus may be increased. That is, is the intention of the standard =
of SCTP CC to have :<o:p></o:p></p><p class=3DMsoListParagraph style=3D'tex=
t-indent:-18.0pt;mso-list:l1 level1 lfo2'><![if !supportLists]><span style=
=3D'mso-list:Ignore'>1.<span style=3D'font:7.0pt "Times New Roman"'>&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; </span></span><![endif]>the CWND now be increased a=
s during &#8220;normal&#8221; congestion control avoidance, i.e., one MTU p=
er acked CWND amount&nbsp; of data<o:p></o:p></p><p class=3DMsoListParagrap=
h style=3D'margin-left:54.0pt;text-indent:-18.0pt;mso-list:l2 level1 lfo3'>=
<![if !supportLists]><span style=3D'mso-list:Ignore'>-<span style=3D'font:7=
.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><=
/span><![endif]>Or to have -<o:p></o:p></p><p class=3DMsoListParagraph styl=
e=3D'text-indent:-18.0pt;mso-list:l1 level1 lfo2'><![if !supportLists]><spa=
n style=3D'mso-list:Ignore'>2.<span style=3D'font:7.0pt "Times New Roman"'>=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><![endif]>the CWND now be allo=
wed to recapture the growth that it did not realize due to under-utilizatio=
n but which may be recaptured from the partial_bytes_ack value. I.e., let i=
t be increased one MTU per SACK until partial_bytes_ack has been decreased =
below CWND, one CWND at a time.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nb=
sp;</o:p></p><p class=3DMsoNormal>From an implementation perspective the qu=
estion likely turns into a question about the maintaining of the partial_by=
tes_ack value during the period of time when the CWND is underutilized. E.g=
., should then partial_bytes_ack be decreased with CWND for each times it i=
ncreases beyond the CWND or should it be allowed to increase unlimited. &nb=
sp;But first we need to find out what the intention of the standard is&#823=
0;.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoN=
ormal>The above of course is subject to cumulative SACKs and other details =
like that. I hope that we can leave such details out of the discussion.<o:p=
></o:p></p><p class=3DMsoListParagraph><o:p>&nbsp;</o:p></p><p class=3DMsoN=
ormal>I hope that you may help.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nb=
sp;</o:p></p><p class=3DMsoListParagraph style=3D'margin-left:0cm'>Thanks i=
n advance!<o:p></o:p></p><p class=3DMsoListParagraph style=3D'margin-left:0=
cm'><o:p>&nbsp;</o:p></p><p class=3DMsoListParagraph style=3D'margin-left:0=
cm'>BR, Karen<o:p></o:p></p></div></body></html>=

--_000_CF340E42AED0874C81947E18863DE77B14355D604FEXMB03eutieto_--

From mattmathis@google.com  Tue Apr 17 13:36:58 2012
Return-Path: <mattmathis@google.com>
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 CE96C11E80CB for <tcpm@ietfa.amsl.com>; Tue, 17 Apr 2012 13:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KciHcG9x0Rml for <tcpm@ietfa.amsl.com>; Tue, 17 Apr 2012 13:36:41 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E47E11E80CC for <tcpm@ietf.org>; Tue, 17 Apr 2012 13:36:39 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so6156596bku.31 for <tcpm@ietf.org>; Tue, 17 Apr 2012 13:36:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=/Sa42fE+qlpfxkOG4gxizV0ybLo8J0FpmcJmaa1z0GE=; b=cJBQbq8RgpHe5Ur/lDhcdRW0qhc4s/m5gcwa2bGaNA4l8EUmQdp9IipP9UzG58hERH S/kPE04nlTFNfP6V8Kp/ddVY9XFp/bxqNFJiG2HLAAd7iWwUEorQr3x943IFn/ZCbf7v XFV6LkuZ3nfNN84J0va4swkKq0aAv/8nj0OaYjfgBhxQsieQ1LrUSV5s94bm26nddiov V/Zl3q9DWhw0KDLxdTiPwYMUT/ZuWbQHMXBLFBWcIdGF8k2tbHPsAfSDuw6m+8aGtFKM YPo5kanjC0RN1xy/YNfs5xXZ5Pt80E81MmJ7DIta2UJjVYlAeBxSfaVZu1PiKgcGxnbQ AdCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=/Sa42fE+qlpfxkOG4gxizV0ybLo8J0FpmcJmaa1z0GE=; b=czxBDcZaEFYzNYDOuQmoe/LCRC2nkqZvDBfLKF6Ws0WzX8SttS6xhshggLXcNV/zQe B+wsb0QQbKAzya0SQ4MtKFk9AA0kC+ItMY8i5rcXX7ATU0D1ISEnTO2BWooQJz2ex5lN awMP16Axo6BTp1HlPYMakYsQiD9A3C1fnRKzV/VA2T8GPDwF7cOzSgY37pIJw0qXBFaL TemwPLCSaxYf3BvgDRMWcE+n6qV2do5tyu26mSmp8/q/8IcGjN3ritv3Me5APEJCywMB sPn9dxadLVVtDnQ0IuX4S5R5sNM/LtKky6EKhkAJmHeUzxyhmAaYo0UARxzVF6I5YbH+ yJeQ==
Received: by 10.204.129.203 with SMTP id p11mr5282778bks.58.1334694998312; Tue, 17 Apr 2012 13:36:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.129.203 with SMTP id p11mr5282768bks.58.1334694998142; Tue, 17 Apr 2012 13:36:38 -0700 (PDT)
Received: by 10.204.232.138 with HTTP; Tue, 17 Apr 2012 13:36:38 -0700 (PDT)
In-Reply-To: <CF340E42AED0874C81947E18863DE77B14355D604F@EXMB03.eu.tieto.com>
References: <CF340E42AED0874C81947E18863DE77B14355D604F@EXMB03.eu.tieto.com>
Date: Tue, 17 Apr 2012 13:36:38 -0700
Message-ID: <CAH56bmBe9A2ubUf1J6yM-hXMbaBHy-_XjaEMKGDV7G+7hWkuQw@mail.gmail.com>
From: Matt Mathis <mattmathis@google.com>
To: Karen.Nielsen@tieto.com
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmz+/HKYcH7+pdKTtqRDAnEfFiwugGIHoyMzENSmKDc3yV+ueR1SbxCHGu8c7uNYJsou7F6YDK8m6QkA7BbuQzodrwJb16rR6UnPwgXukXMyxv7jCcOJ7DXpj8ynymGBNF+oOsc
Cc: tcpm@ietf.org
Subject: Re: [tcpm] CWND increase after under-utilization in congestion avoidance
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Apr 2012 20:36:59 -0000

Well, my opinion would be that as long as  flightsize >=3D cwnd at least
once recently it should be ok to continue to raise cwnd.  Note that
raising cwnd probably causes the predicate to become not true.  Also
"recently" should be no shorter than one RTT, but may be a longer (the
details are not so important).   The point is that as long as FS
reaches cwnd at least once per RTT, it is fine to continue to grow the
window.  I believe I have seen it implemented "as long as FS comes
close to cwnd..."

In the big picture is it important not to keep raising cwnd if cwnd in
not controlling the connection, because then you have no way to know
if it is a valid measure of anything useful.  However, as long as cwnd
has been "tested" it is fine to keep pushing it up.

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



On Tue, Apr 17, 2012 at 5:50 AM,  <Karen.Nielsen@tieto.com> wrote:
> Hi,
>
>
>
> SCTP as prescribed by RFC4960 operates with CWND validation in that CWND
> increase always
>
> is subject to its fully usage. That is, CWND only may increase when
> flightsize >=3D CWND.
>
> Opposed to TCP, as standardized by RFC5681, CWND is thus not necessarily
> increased even when partial_bytes_ack
>
> increases beyond the present CWND.
>
>
>
> An implementation which boldly augments the partial_bytes_ack during the
> time where a CWND is underutilized (but the connection is not idle) may
> observe that the partial_bytes_ack increases to a very high value, possib=
ly
> it increases to
>
> a value many times higher than the CWND.
>
>
>
> The question now arises what should happen once the CWND resumes fully
> utilization and thus may be increased. That is, is the intention of the
> standard of SCTP CC to have :
>
> 1.=A0=A0=A0=A0=A0 the CWND now be increased as during =93normal=94 conges=
tion control
> avoidance, i.e., one MTU per acked CWND amount=A0 of data
>
> -=A0=A0=A0=A0=A0=A0=A0 Or to have -
>
> 2.=A0=A0=A0=A0=A0 the CWND now be allowed to recapture the growth that it=
 did not
> realize due to under-utilization but which may be recaptured from the
> partial_bytes_ack value. I.e., let it be increased one MTU per SACK until
> partial_bytes_ack has been decreased below CWND, one CWND at a time.
>
>
>
> From an implementation perspective the question likely turns into a quest=
ion
> about the maintaining of the partial_bytes_ack value during the period of
> time when the CWND is underutilized. E.g., should then partial_bytes_ack =
be
> decreased with CWND for each times it increases beyond the CWND or should=
 it
> be allowed to increase unlimited. =A0But first we need to find out what t=
he
> intention of the standard is=85.
>
>
>
> The above of course is subject to cumulative SACKs and other details like
> that. I hope that we can leave such details out of the discussion.
>
>
>
> I hope that you may help.
>
>
>
> Thanks in advance!
>
>
>
> BR, Karen
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

From Karen.Nielsen@tieto.com  Wed Apr 18 00:25:47 2012
Return-Path: <Karen.Nielsen@tieto.com>
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 F36F721F8624; Wed, 18 Apr 2012 00:25:46 -0700 (PDT)
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=[AWL=0.001,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmfi8kBEIfa2; Wed, 18 Apr 2012 00:25:43 -0700 (PDT)
Received: from ebb05.tieto.com (ebb05.tieto.com [131.207.168.36]) by ietfa.amsl.com (Postfix) with ESMTP id 3773A21F85E7; Wed, 18 Apr 2012 00:25:41 -0700 (PDT)
X-AuditID: 83cfa824-b7d03ae000000a92-34-4f8e6c74808e
Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb05.tieto.com (SMTP Mailer) with SMTP id 09.5C.02706.47C6E8F4; Wed, 18 Apr 2012 10:25:40 +0300 (EEST)
Received: from EXMB03.eu.tieto.com ([169.254.2.108]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Wed, 18 Apr 2012 10:25:28 +0300
From: <Karen.Nielsen@tieto.com>
To: <mattmathis@google.com>
Date: Wed, 18 Apr 2012 10:25:26 +0300
Thread-Topic: [tcpm] CWND increase after under-utilization in congestion avoidance
Thread-Index: Ac0c2cpBnjqIMcfVSrOQ3+AFwCMyoQAVWJ3w
Message-ID: <CF340E42AED0874C81947E18863DE77B14355D61DC@EXMB03.eu.tieto.com>
References: <CF340E42AED0874C81947E18863DE77B14355D604F@EXMB03.eu.tieto.com> <CAH56bmBe9A2ubUf1J6yM-hXMbaBHy-_XjaEMKGDV7G+7hWkuQw@mail.gmail.com>
In-Reply-To: <CAH56bmBe9A2ubUf1J6yM-hXMbaBHy-_XjaEMKGDV7G+7hWkuQw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: tcpm@ietf.org, tsvwg@ietf.org
Subject: Re: [tcpm] CWND increase after under-utilization in congestion avoidance
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Apr 2012 07:25:47 -0000

Hi,

Thanks a lot!=20

My main concern is the slope of the increase of the CWND after a period of =
CWND underutilization in congestion avoidance phase.

My general understanding of the standards is that during slow start one may=
 raise the CWND per received (S)ACK whereas during congestion avoidance gen=
erally CWND may be increase by one MTU only per RTT. Then some of the more =
experimental CC algorithms allow for slow start slope increase after a pack=
et loss, but that may be a sidetrack here. At least my question really goes=
 to the base standard of SCTP as specified in RFC4960. But I assume that th=
e question is equally relevant for a TCP implementation that implements CWN=
D validation in some form.

The assumption here is that we are in congestion avoidance phase, but also =
that the accumulated partical_bytes_ack can allow for several increases of =
the CWND within the same RTT as SACKs will be returned. Provided that the a=
pplication continues to fill the increasing CWND, the question is whether S=
CTP (TCP) then is allowed to proactively increase the CWND several times pe=
r RTT (slow start slope) or whether the increase should be limited to be do=
ne one per RTT (congestion avoidance slope).

Thanks!

BR, Karen

-----Original Message-----
From: Matt Mathis [mailto:mattmathis@google.com]=20
Sent: 17. april 2012 22:37
To: Nielsen Karen
Cc: tcpm@ietf.org
Subject: Re: [tcpm] CWND increase after under-utilization in congestion avo=
idance

Well, my opinion would be that as long as  flightsize >=3D cwnd at least
once recently it should be ok to continue to raise cwnd.  Note that
raising cwnd probably causes the predicate to become not true.  Also
"recently" should be no shorter than one RTT, but may be a longer (the
details are not so important).   The point is that as long as FS
reaches cwnd at least once per RTT, it is fine to continue to grow the
window.  I believe I have seen it implemented "as long as FS comes
close to cwnd..."

In the big picture is it important not to keep raising cwnd if cwnd in
not controlling the connection, because then you have no way to know
if it is a valid measure of anything useful.  However, as long as cwnd
has been "tested" it is fine to keep pushing it up.

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



On Tue, Apr 17, 2012 at 5:50 AM,  <Karen.Nielsen@tieto.com> wrote:
> Hi,
>
>
>
> SCTP as prescribed by RFC4960 operates with CWND validation in that CWND
> increase always
>
> is subject to its fully usage. That is, CWND only may increase when
> flightsize >=3D CWND.
>
> Opposed to TCP, as standardized by RFC5681, CWND is thus not necessarily
> increased even when partial_bytes_ack
>
> increases beyond the present CWND.
>
>
>
> An implementation which boldly augments the partial_bytes_ack during the
> time where a CWND is underutilized (but the connection is not idle) may
> observe that the partial_bytes_ack increases to a very high value, possib=
ly
> it increases to
>
> a value many times higher than the CWND.
>
>
>
> The question now arises what should happen once the CWND resumes fully
> utilization and thus may be increased. That is, is the intention of the
> standard of SCTP CC to have :
>
> 1.=A0=A0=A0=A0=A0 the CWND now be increased as during "normal" congestion=
 control
> avoidance, i.e., one MTU per acked CWND amount=A0 of data
>
> -=A0=A0=A0=A0=A0=A0=A0 Or to have -
>
> 2.=A0=A0=A0=A0=A0 the CWND now be allowed to recapture the growth that it=
 did not
> realize due to under-utilization but which may be recaptured from the
> partial_bytes_ack value. I.e., let it be increased one MTU per SACK until
> partial_bytes_ack has been decreased below CWND, one CWND at a time.
>
>
>
> From an implementation perspective the question likely turns into a quest=
ion
> about the maintaining of the partial_bytes_ack value during the period of
> time when the CWND is underutilized. E.g., should then partial_bytes_ack =
be
> decreased with CWND for each times it increases beyond the CWND or should=
 it
> be allowed to increase unlimited. =A0But first we need to find out what t=
he
> intention of the standard is..
>
>
>
> The above of course is subject to cumulative SACKs and other details like
> that. I hope that we can leave such details out of the discussion.
>
>
>
> I hope that you may help.
>
>
>
> Thanks in advance!
>
>
>
> BR, Karen
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

From gorry@erg.abdn.ac.uk  Wed Apr 18 09:12:32 2012
Return-Path: <gorry@erg.abdn.ac.uk>
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 24D8921F854B for <tcpm@ietfa.amsl.com>; Wed, 18 Apr 2012 09:12:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oP+E4O6Nr2Le for <tcpm@ietfa.amsl.com>; Wed, 18 Apr 2012 09:12:27 -0700 (PDT)
Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 555DC21F8552 for <tcpm@ietf.org>; Wed, 18 Apr 2012 09:12:26 -0700 (PDT)
Received: from Gorry.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id q3IGCK7i014762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Apr 2012 17:12:21 +0100 (BST)
Message-ID: <4F8EE7E5.7010502@erg.abdn.ac.uk>
Date: Wed, 18 Apr 2012 17:12:21 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: The University of Aberdeen is a charity registered in Scotland,  No SC013683. 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Matt Mathis <mattmathis@google.com>
References: <CF340E42AED0874C81947E18863DE77B14355D604F@EXMB03.eu.tieto.com> <CAH56bmBe9A2ubUf1J6yM-hXMbaBHy-_XjaEMKGDV7G+7hWkuQw@mail.gmail.com>
In-Reply-To: <CAH56bmBe9A2ubUf1J6yM-hXMbaBHy-_XjaEMKGDV7G+7hWkuQw@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-ERG-MailScanner: Found to be clean
X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk
Cc: tcpm@ietf.org
Subject: Re: [tcpm] CWND increase after under-utilization in congestion avoidance
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Apr 2012 16:12:32 -0000

+1

We have this individual draft that suggests how TCP should behave in 
similar cases (we plan to update this soon):
https://datatracker.ietf.org/doc/draft-fairhurst-tcpm-newcwv/

Gorry

On 17/04/2012 21:36, Matt Mathis wrote:
> Well, my opinion would be that as long as  flightsize>= cwnd at least
> once recently it should be ok to continue to raise cwnd.  Note that
> raising cwnd probably causes the predicate to become not true.  Also
> "recently" should be no shorter than one RTT, but may be a longer (the
> details are not so important).   The point is that as long as FS
> reaches cwnd at least once per RTT, it is fine to continue to grow the
> window.  I believe I have seen it implemented "as long as FS comes
> close to cwnd..."
>
> In the big picture is it important not to keep raising cwnd if cwnd in
> not controlling the connection, because then you have no way to know
> if it is a valid measure of anything useful.  However, as long as cwnd
> has been "tested" it is fine to keep pushing it up.
>
> Thanks,
> --MM--
> The best way to predict the future is to create it.  - Alan Kay
>
>
>
> On Tue, Apr 17, 2012 at 5:50 AM,<Karen.Nielsen@tieto.com>  wrote:
>> Hi,
>>
>>
>>
>> SCTP as prescribed by RFC4960 operates with CWND validation in that CWND
>> increase always
>>
>> is subject to its fully usage. That is, CWND only may increase when
>> flightsize>= CWND.
>>
>> Opposed to TCP, as standardized by RFC5681, CWND is thus not necessarily
>> increased even when partial_bytes_ack
>>
>> increases beyond the present CWND.
>>
>>
>>
>> An implementation which boldly augments the partial_bytes_ack during the
>> time where a CWND is underutilized (but the connection is not idle) may
>> observe that the partial_bytes_ack increases to a very high value, possibly
>> it increases to
>>
>> a value many times higher than the CWND.
>>
>>
>>
>> The question now arises what should happen once the CWND resumes fully
>> utilization and thus may be increased. That is, is the intention of the
>> standard of SCTP CC to have :
>>
>> 1.      the CWND now be increased as during “normal” congestion control
>> avoidance, i.e., one MTU per acked CWND amount  of data
>>
>> -        Or to have -
>>
>> 2.      the CWND now be allowed to recapture the growth that it did not
>> realize due to under-utilization but which may be recaptured from the
>> partial_bytes_ack value. I.e., let it be increased one MTU per SACK until
>> partial_bytes_ack has been decreased below CWND, one CWND at a time.
>>
>>
>>
>>  From an implementation perspective the question likely turns into a question
>> about the maintaining of the partial_bytes_ack value during the period of
>> time when the CWND is underutilized. E.g., should then partial_bytes_ack be
>> decreased with CWND for each times it increases beyond the CWND or should it
>> be allowed to increase unlimited.  But first we need to find out what the
>> intention of the standard is….
>>
>>
>>
>> The above of course is subject to cumulative SACKs and other details like
>> that. I hope that we can leave such details out of the discussion.
>>
>>
>>
>> I hope that you may help.
>>
>>
>>
>> Thanks in advance!
>>
>>
>>
>> BR, Karen
>>
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
>


From mattmathis@google.com  Wed Apr 18 11:13:44 2012
Return-Path: <mattmathis@google.com>
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 561EA11E8087 for <tcpm@ietfa.amsl.com>; Wed, 18 Apr 2012 11:13:44 -0700 (PDT)
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.833, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyY-dCf3yOzJ for <tcpm@ietfa.amsl.com>; Wed, 18 Apr 2012 11:13:40 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id D16F611E8085 for <tcpm@ietf.org>; Wed, 18 Apr 2012 11:13:39 -0700 (PDT)
Received: by wibhj6 with SMTP id hj6so766504wib.13 for <tcpm@ietf.org>; Wed, 18 Apr 2012 11:13:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=hS4DRMCAEjWF/AVGQ4J5ltOv5wIh6YQF6KA9IbHqggw=; b=LX10cTiep+HLx7kS0pa3QBXxt9sCoNeE0FzguigWNB+e8I2XEOv7Z1HPyU2KZDEq1Z qNnzSWYYTe9RBeqa2jAXs7MvsjNXfnqs00nxaWkijOE4Dpuf9/yNRGCnLtPY3WWZYC01 QqGlTWUOi09qrKZJcp51pWwpGI/YaGCk+Aj6ZK4VK1gYuuoZxyFy9qBwpLs5Oc1vOden /ngCAMXWJ0kFUnoXvedljaSBVrx86f29o+qDFYh2KccXoX1XIbtvTEhHpIGKjzzoZPdz O5y/hFWhsLou5GzTOUQ9bAF5uAmWEe4LoZIFgpIRMa79qlBjpLrwUKh81ST136lZe4Jh nv6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=hS4DRMCAEjWF/AVGQ4J5ltOv5wIh6YQF6KA9IbHqggw=; b=TfTgXsm4/cjCz3PucgodlFH82tDJZ8cmDNBcf0zglboxR/kZrMVYsFQUk7eh6pD9TD qX++m+2/IkEj+eWtJBOqbPfGveupSC9SEZAJ7FXEWbM0u0ITAwZnMON1ou++/0daVAu5 5MbvJ72C2fm2go+HZTwfvfS6tDkRfQ5I5vvVm7lJVUUJsxKhENMFLDFb7cYP+kDgebb9 SnYunReTWGRCo3UgR3OJ3nn4oi8nqVHtPB3wfatMbQhPPJKtX/LOmpGkeRDfhS4BvnZ6 vJY26+NgV/5yd4MjdGT79Ejnl+fSGlDYhE+Z+kah6xmw35nHXDU46LLqj56zduUwUK/8 dGAQ==
Received: by 10.216.136.138 with SMTP id w10mr2059918wei.75.1334772818840; Wed, 18 Apr 2012 11:13:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.136.138 with SMTP id w10mr2059904wei.75.1334772818501; Wed, 18 Apr 2012 11:13:38 -0700 (PDT)
Received: by 10.216.217.85 with HTTP; Wed, 18 Apr 2012 11:13:38 -0700 (PDT)
In-Reply-To: <4F8EE7E5.7010502@erg.abdn.ac.uk>
References: <CF340E42AED0874C81947E18863DE77B14355D604F@EXMB03.eu.tieto.com> <CAH56bmBe9A2ubUf1J6yM-hXMbaBHy-_XjaEMKGDV7G+7hWkuQw@mail.gmail.com> <4F8EE7E5.7010502@erg.abdn.ac.uk>
Date: Wed, 18 Apr 2012 11:13:38 -0700
Message-ID: <CAH56bmAEDvUxxx_U5YcDj9aE-Ws8Hok016OcVD6_BaMxBZ+wPQ@mail.gmail.com>
From: Matt Mathis <mattmathis@google.com>
To: gorry@erg.abdn.ac.uk
Content-Type: multipart/alternative; boundary=0016e6d99f39b3e26c04bdf80361
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQk5j2c8M6HXsA9oJeMVjT03jnG5ukyEc7R/x/Ot3981OuS+0EipCOy8sa+/TSEeAxqb7Np01DN8dZgP+/j4hl25qaHpPtBnRoa2Q1bupdNJ2qhdfK2UoyuKs4/EqqzgNwJveMpQ
Cc: tcpm@ietf.org
Subject: Re: [tcpm] CWND increase after under-utilization in congestion avoidance
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Apr 2012 18:13:44 -0000

--0016e6d99f39b3e26c04bdf80361
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Gorry, I would love to hear how Laminar might affect your thinking.....

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



On Wed, Apr 18, 2012 at 9:12 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk>wrot=
e:

> +1
>
> We have this individual draft that suggests how TCP should behave in
> similar cases (we plan to update this soon):
> https://datatracker.ietf.org/**doc/draft-fairhurst-tcpm-**newcwv/<https:/=
/datatracker.ietf.org/doc/draft-fairhurst-tcpm-newcwv/>
>
> Gorry
>
>
> On 17/04/2012 21:36, Matt Mathis wrote:
>
>> Well, my opinion would be that as long as  flightsize>=3D cwnd at least
>> once recently it should be ok to continue to raise cwnd.  Note that
>> raising cwnd probably causes the predicate to become not true.  Also
>> "recently" should be no shorter than one RTT, but may be a longer (the
>> details are not so important).   The point is that as long as FS
>> reaches cwnd at least once per RTT, it is fine to continue to grow the
>> window.  I believe I have seen it implemented "as long as FS comes
>> close to cwnd..."
>>
>> In the big picture is it important not to keep raising cwnd if cwnd in
>> not controlling the connection, because then you have no way to know
>> if it is a valid measure of anything useful.  However, as long as cwnd
>> has been "tested" it is fine to keep pushing it up.
>>
>> Thanks,
>> --MM--
>> The best way to predict the future is to create it.  - Alan Kay
>>
>>
>>
>> On Tue, Apr 17, 2012 at 5:50 AM,<Karen.Nielsen@tieto.com>  wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> SCTP as prescribed by RFC4960 operates with CWND validation in that CWN=
D
>>> increase always
>>>
>>> is subject to its fully usage. That is, CWND only may increase when
>>> flightsize>=3D CWND.
>>>
>>> Opposed to TCP, as standardized by RFC5681, CWND is thus not necessaril=
y
>>> increased even when partial_bytes_ack
>>>
>>> increases beyond the present CWND.
>>>
>>>
>>>
>>> An implementation which boldly augments the partial_bytes_ack during th=
e
>>> time where a CWND is underutilized (but the connection is not idle) may
>>> observe that the partial_bytes_ack increases to a very high value,
>>> possibly
>>> it increases to
>>>
>>> a value many times higher than the CWND.
>>>
>>>
>>>
>>> The question now arises what should happen once the CWND resumes fully
>>> utilization and thus may be increased. That is, is the intention of the
>>> standard of SCTP CC to have :
>>>
>>> 1.      the CWND now be increased as during =93normal=94 congestion con=
trol
>>> avoidance, i.e., one MTU per acked CWND amount  of data
>>>
>>> -        Or to have -
>>>
>>> 2.      the CWND now be allowed to recapture the growth that it did not
>>> realize due to under-utilization but which may be recaptured from the
>>> partial_bytes_ack value. I.e., let it be increased one MTU per SACK unt=
il
>>> partial_bytes_ack has been decreased below CWND, one CWND at a time.
>>>
>>>
>>>
>>>  From an implementation perspective the question likely turns into a
>>> question
>>> about the maintaining of the partial_bytes_ack value during the period =
of
>>> time when the CWND is underutilized. E.g., should then partial_bytes_ac=
k
>>> be
>>> decreased with CWND for each times it increases beyond the CWND or
>>> should it
>>> be allowed to increase unlimited.  But first we need to find out what t=
he
>>> intention of the standard is=85.
>>>
>>>
>>>
>>> The above of course is subject to cumulative SACKs and other details li=
ke
>>> that. I hope that we can leave such details out of the discussion.
>>>
>>>
>>>
>>> I hope that you may help.
>>>
>>>
>>>
>>> Thanks in advance!
>>>
>>>
>>>
>>> BR, Karen
>>>
>>>
>>> ______________________________**_________________
>>> tcpm mailing list
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/**listinfo/tcpm<https://www.ietf.org/mailm=
an/listinfo/tcpm>
>>>
>>>  ______________________________**_________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/**listinfo/tcpm<https://www.ietf.org/mailma=
n/listinfo/tcpm>
>>
>>
>>
>

--0016e6d99f39b3e26c04bdf80361
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Gorry, I would love to hear how Laminar might affect your thinking.....<div=
><br></div><div>Thanks,<br clear=3D"all">--MM--<br>The best way to predict =
the future is to create it. =A0- Alan Kay<br><br>
<br><br><div class=3D"gmail_quote">On Wed, Apr 18, 2012 at 9:12 AM, Gorry F=
airhurst <span dir=3D"ltr">&lt;<a href=3D"mailto:gorry@erg.abdn.ac.uk">gorr=
y@erg.abdn.ac.uk</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+1<br>
<br>
We have this individual draft that suggests how TCP should behave in simila=
r cases (we plan to update this soon):<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-fairhurst-tcpm-newcwv/" t=
arget=3D"_blank">https://datatracker.ietf.org/<u></u>doc/draft-fairhurst-tc=
pm-<u></u>newcwv/</a><span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
Gorry</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
On 17/04/2012 21:36, Matt Mathis wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Well, my opinion would be that as long as =A0flightsize&gt;=3D cwnd at leas=
t<br>
once recently it should be ok to continue to raise cwnd. =A0Note that<br>
raising cwnd probably causes the predicate to become not true. =A0Also<br>
&quot;recently&quot; should be no shorter than one RTT, but may be a longer=
 (the<br>
details are not so important). =A0 The point is that as long as FS<br>
reaches cwnd at least once per RTT, it is fine to continue to grow the<br>
window. =A0I believe I have seen it implemented &quot;as long as FS comes<b=
r>
close to cwnd...&quot;<br>
<br>
In the big picture is it important not to keep raising cwnd if cwnd in<br>
not controlling the connection, because then you have no way to know<br>
if it is a valid measure of anything useful. =A0However, as long as cwnd<br=
>
has been &quot;tested&quot; it is fine to keep pushing it up.<br>
<br>
Thanks,<br>
--MM--<br>
The best way to predict the future is to create it. =A0- Alan Kay<br>
<br>
<br>
<br>
On Tue, Apr 17, 2012 at 5:50 AM,&lt;<a href=3D"mailto:Karen.Nielsen@tieto.c=
om" target=3D"_blank">Karen.Nielsen@tieto.com</a>&gt; =A0wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hi,<br>
<br>
<br>
<br>
SCTP as prescribed by RFC4960 operates with CWND validation in that CWND<br=
>
increase always<br>
<br>
is subject to its fully usage. That is, CWND only may increase when<br>
flightsize&gt;=3D CWND.<br>
<br>
Opposed to TCP, as standardized by RFC5681, CWND is thus not necessarily<br=
>
increased even when partial_bytes_ack<br>
<br>
increases beyond the present CWND.<br>
<br>
<br>
<br>
An implementation which boldly augments the partial_bytes_ack during the<br=
>
time where a CWND is underutilized (but the connection is not idle) may<br>
observe that the partial_bytes_ack increases to a very high value, possibly=
<br>
it increases to<br>
<br>
a value many times higher than the CWND.<br>
<br>
<br>
<br>
The question now arises what should happen once the CWND resumes fully<br>
utilization and thus may be increased. That is, is the intention of the<br>
standard of SCTP CC to have :<br>
<br>
1. =A0 =A0 =A0the CWND now be increased as during =93normal=94 congestion c=
ontrol<br>
avoidance, i.e., one MTU per acked CWND amount =A0of data<br>
<br>
- =A0 =A0 =A0 =A0Or to have -<br>
<br>
2. =A0 =A0 =A0the CWND now be allowed to recapture the growth that it did n=
ot<br>
realize due to under-utilization but which may be recaptured from the<br>
partial_bytes_ack value. I.e., let it be increased one MTU per SACK until<b=
r>
partial_bytes_ack has been decreased below CWND, one CWND at a time.<br>
<br>
<br>
<br>
=A0From an implementation perspective the question likely turns into a ques=
tion<br>
about the maintaining of the partial_bytes_ack value during the period of<b=
r>
time when the CWND is underutilized. E.g., should then partial_bytes_ack be=
<br>
decreased with CWND for each times it increases beyond the CWND or should i=
t<br>
be allowed to increase unlimited. =A0But first we need to find out what the=
<br>
intention of the standard is=85.<br>
<br>
<br>
<br>
The above of course is subject to cumulative SACKs and other details like<b=
r>
that. I hope that we can leave such details out of the discussion.<br>
<br>
<br>
<br>
I hope that you may help.<br>
<br>
<br>
<br>
Thanks in advance!<br>
<br>
<br>
<br>
BR, Karen<br>
<br>
<br>
______________________________<u></u>_________________<br>
tcpm mailing list<br>
<a href=3D"mailto:tcpm@ietf.org" target=3D"_blank">tcpm@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tcpm" target=3D"_blank">ht=
tps://www.ietf.org/mailman/<u></u>listinfo/tcpm</a><br>
<br>
</blockquote>
______________________________<u></u>_________________<br>
tcpm mailing list<br>
<a href=3D"mailto:tcpm@ietf.org" target=3D"_blank">tcpm@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tcpm" target=3D"_blank">ht=
tps://www.ietf.org/mailman/<u></u>listinfo/tcpm</a><br>
<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div>

--0016e6d99f39b3e26c04bdf80361--

From touch@isi.edu  Wed Apr 18 12:15:41 2012
Return-Path: <touch@isi.edu>
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 37C9421F84C9 for <tcpm@ietfa.amsl.com>; Wed, 18 Apr 2012 12:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Suirbnof7XC for <tcpm@ietfa.amsl.com>; Wed, 18 Apr 2012 12:15:37 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 26D9221F84AA for <tcpm@ietf.org>; Wed, 18 Apr 2012 12:15:37 -0700 (PDT)
Received: from [207.151.141.45] ([207.151.141.45]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q3IJFBHD015858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Apr 2012 12:15:21 -0700 (PDT)
Message-ID: <4F8F12BE.60808@isi.edu>
Date: Wed, 18 Apr 2012 12:15:10 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: gorry@erg.abdn.ac.uk
References: <CF340E42AED0874C81947E18863DE77B14355D604F@EXMB03.eu.tieto.com> <CAH56bmBe9A2ubUf1J6yM-hXMbaBHy-_XjaEMKGDV7G+7hWkuQw@mail.gmail.com> <4F8EE7E5.7010502@erg.abdn.ac.uk>
In-Reply-To: <4F8EE7E5.7010502@erg.abdn.ac.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org, Matt Mathis <mattmathis@google.com>
Subject: Re: [tcpm] CWND increase after under-utilization in congestion avoidance
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Apr 2012 19:15:41 -0000

I am wondering how this is expected to play out. If it's OK to send at 
the last rate - unless you hear of loss - after the app stops or things 
drain, then why not do the same during the beginning of a connection 
(which happens at most once per connection)?

We discussed the issue of restart-after-idle several times - and had 
some proposals for "use it or lose it" a while ago (it's on my idle 
queue). However, this proposal seems to easily make things much worse IMO.

I don't think TCP should "try first and recover if fail"; its premise is 
"start gently". I think that should apply to restarts as much - if not 
more - than the connection start.

Joe

On 4/18/2012 9:12 AM, Gorry Fairhurst wrote:
> +1
>
> We have this individual draft that suggests how TCP should behave in
> similar cases (we plan to update this soon):
> https://datatracker.ietf.org/doc/draft-fairhurst-tcpm-newcwv/
>
> Gorry
>
> On 17/04/2012 21:36, Matt Mathis wrote:
>> Well, my opinion would be that as long as flightsize>= cwnd at least
>> once recently it should be ok to continue to raise cwnd. Note that
>> raising cwnd probably causes the predicate to become not true. Also
>> "recently" should be no shorter than one RTT, but may be a longer (the
>> details are not so important). The point is that as long as FS
>> reaches cwnd at least once per RTT, it is fine to continue to grow the
>> window. I believe I have seen it implemented "as long as FS comes
>> close to cwnd..."
>>
>> In the big picture is it important not to keep raising cwnd if cwnd in
>> not controlling the connection, because then you have no way to know
>> if it is a valid measure of anything useful. However, as long as cwnd
>> has been "tested" it is fine to keep pushing it up.
>>
>> Thanks,
>> --MM--
>> The best way to predict the future is to create it. - Alan Kay
>>
>>
>>
>> On Tue, Apr 17, 2012 at 5:50 AM,<Karen.Nielsen@tieto.com> wrote:
>>> Hi,
>>>
>>>
>>>
>>> SCTP as prescribed by RFC4960 operates with CWND validation in that CWND
>>> increase always
>>>
>>> is subject to its fully usage. That is, CWND only may increase when
>>> flightsize>= CWND.
>>>
>>> Opposed to TCP, as standardized by RFC5681, CWND is thus not necessarily
>>> increased even when partial_bytes_ack
>>>
>>> increases beyond the present CWND.
>>>
>>>
>>>
>>> An implementation which boldly augments the partial_bytes_ack during the
>>> time where a CWND is underutilized (but the connection is not idle) may
>>> observe that the partial_bytes_ack increases to a very high value,
>>> possibly
>>> it increases to
>>>
>>> a value many times higher than the CWND.
>>>
>>>
>>>
>>> The question now arises what should happen once the CWND resumes fully
>>> utilization and thus may be increased. That is, is the intention of the
>>> standard of SCTP CC to have :
>>>
>>> 1. the CWND now be increased as during “normal” congestion control
>>> avoidance, i.e., one MTU per acked CWND amount of data
>>>
>>> - Or to have -
>>>
>>> 2. the CWND now be allowed to recapture the growth that it did not
>>> realize due to under-utilization but which may be recaptured from the
>>> partial_bytes_ack value. I.e., let it be increased one MTU per SACK
>>> until
>>> partial_bytes_ack has been decreased below CWND, one CWND at a time.
>>>
>>>
>>>
>>> From an implementation perspective the question likely turns into a
>>> question
>>> about the maintaining of the partial_bytes_ack value during the
>>> period of
>>> time when the CWND is underutilized. E.g., should then
>>> partial_bytes_ack be
>>> decreased with CWND for each times it increases beyond the CWND or
>>> should it
>>> be allowed to increase unlimited. But first we need to find out what the
>>> intention of the standard is….
>>>
>>>
>>>
>>> The above of course is subject to cumulative SACKs and other details
>>> like
>>> that. I hope that we can leave such details out of the discussion.
>>>
>>>
>>>
>>> I hope that you may help.
>>>
>>>
>>>
>>> Thanks in advance!
>>>
>>>
>>>
>>> BR, Karen
>>>
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

From mattmathis@google.com  Wed Apr 18 12:23:20 2012
Return-Path: <mattmathis@google.com>
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 CA70E11E8089 for <tcpm@ietfa.amsl.com>; Wed, 18 Apr 2012 12:23:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.56
X-Spam-Level: 
X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wytyk6FKxxCT for <tcpm@ietfa.amsl.com>; Wed, 18 Apr 2012 12:23:16 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 41E6311E8088 for <tcpm@ietf.org>; Wed, 18 Apr 2012 12:23:16 -0700 (PDT)
Received: by wibhj6 with SMTP id hj6so816167wib.13 for <tcpm@ietf.org>; Wed, 18 Apr 2012 12:23:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=HOMCVvmIyn+672v9BKf6uknPY01zZLREQa0FqYbydkQ=; b=PLuYemwHRiDa3Sff5aq3ShP8uH8yPkWK2LEBCQGfo72Qs+cx4UFNb3+qwxaKtslwCp dLvhncE5vp6MD1pp/tv+6BuMq4jnHT7XKasLoT7Gf8ymtcVS2pr6Hhdwujxj1UMflZOZ kgZnhqZKrmVN0patmzalS0eKKCjWLLV2p0n0aeV+iZkhxR99e2O657Ha9PD3s4F8hzrC RvnvXRfbfl7TeApL8iLrqyrarJ1txtz3g4LUQV0hoiIR14a/oKoyvlBUvarT4GWBpzLO Yxr7uaCqu6mPfBxdhi5iStiFII1RCNQJOUKvfYD4ieheqQMSZXu6WCd09f02Cgo5yDdr WMrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=HOMCVvmIyn+672v9BKf6uknPY01zZLREQa0FqYbydkQ=; b=Jj+Du31Aykimn9d7qkP/RJR/M0G5Lstwm786MVSFjLcgTbrNhd3u+rLshPgfKLc7xe BH8n9Ttc+bHr9d8PkhUkyr/cLJM4AaTJpNTVHOrSUD5uzNP4S7yiihol4pnJY3vz5jSV X1vfrrsFYN4zbw0sPl4bWxe3Nje1o0ectxf7tF78j4KhMp9kzF0MBEoYHeg5EW9gemNz 6HdIy2G8hGBP+4vT05VsUP7e1mt52IZ+jddjdc2u7ZU9OrWcxjyh1WbfNZugHDkkeqva 1rAvzUIFiQ84E8j7truAkap6ahS7zZ1UXd3D1jsIYWOIFqHwKHfKmbtwdzKoY8pygzLa 44vQ==
Received: by 10.216.136.138 with SMTP id w10mr2185697wei.75.1334776995422; Wed, 18 Apr 2012 12:23:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.136.138 with SMTP id w10mr2185690wei.75.1334776995227; Wed, 18 Apr 2012 12:23:15 -0700 (PDT)
Received: by 10.216.217.85 with HTTP; Wed, 18 Apr 2012 12:23:15 -0700 (PDT)
In-Reply-To: <4F8F12BE.60808@isi.edu>
References: <CF340E42AED0874C81947E18863DE77B14355D604F@EXMB03.eu.tieto.com> <CAH56bmBe9A2ubUf1J6yM-hXMbaBHy-_XjaEMKGDV7G+7hWkuQw@mail.gmail.com> <4F8EE7E5.7010502@erg.abdn.ac.uk> <4F8F12BE.60808@isi.edu>
Date: Wed, 18 Apr 2012 12:23:15 -0700
Message-ID: <CAH56bmCJ+TH55F66b5muSC9wRAi_unRHq_3iXECzw8yyopPd+g@mail.gmail.com>
From: Matt Mathis <mattmathis@google.com>
To: Joe Touch <touch@isi.edu>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQlOQ7W7FUo8Jnt/2lPCUsR3XI7ygsXPXLpybXfSOEZGWnq6bWEowAzJqRb3soOsQGKQ0Z6gWV5HplNUCbS0J0jXLkbnFB5F1X7V66pao2f8xe5msnaI+eLrX/rFCG6SOTbd1IW7
Cc: tcpm@ietf.org
Subject: Re: [tcpm] CWND increase after under-utilization in congestion avoidance
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Apr 2012 19:23:20 -0000

Joe "this proposal" refers to Gory's draft, correct?

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

On Wed, Apr 18, 2012 at 12:15 PM, Joe Touch <touch@isi.edu> wrote:
> I am wondering how this is expected to play out. If it's OK to send at th=
e
> last rate - unless you hear of loss - after the app stops or things drain=
,
> then why not do the same during the beginning of a connection (which happ=
ens
> at most once per connection)?
>
> We discussed the issue of restart-after-idle several times - and had some
> proposals for "use it or lose it" a while ago (it's on my idle queue).
> However, this proposal seems to easily make things much worse IMO.
>
> I don't think TCP should "try first and recover if fail"; its premise is
> "start gently". I think that should apply to restarts as much - if not mo=
re
> - than the connection start.
>
> Joe
>
>
> On 4/18/2012 9:12 AM, Gorry Fairhurst wrote:
>>
>> +1
>>
>> We have this individual draft that suggests how TCP should behave in
>> similar cases (we plan to update this soon):
>> https://datatracker.ietf.org/doc/draft-fairhurst-tcpm-newcwv/
>>
>> Gorry
>>
>> On 17/04/2012 21:36, Matt Mathis wrote:
>>>
>>> Well, my opinion would be that as long as flightsize>=3D cwnd at least
>>> once recently it should be ok to continue to raise cwnd. Note that
>>> raising cwnd probably causes the predicate to become not true. Also
>>> "recently" should be no shorter than one RTT, but may be a longer (the
>>> details are not so important). The point is that as long as FS
>>> reaches cwnd at least once per RTT, it is fine to continue to grow the
>>> window. I believe I have seen it implemented "as long as FS comes
>>> close to cwnd..."
>>>
>>> In the big picture is it important not to keep raising cwnd if cwnd in
>>> not controlling the connection, because then you have no way to know
>>> if it is a valid measure of anything useful. However, as long as cwnd
>>> has been "tested" it is fine to keep pushing it up.
>>>
>>> Thanks,
>>> --MM--
>>> The best way to predict the future is to create it. - Alan Kay
>>>
>>>
>>>
>>> On Tue, Apr 17, 2012 at 5:50 AM,<Karen.Nielsen@tieto.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> SCTP as prescribed by RFC4960 operates with CWND validation in that CW=
ND
>>>> increase always
>>>>
>>>> is subject to its fully usage. That is, CWND only may increase when
>>>> flightsize>=3D CWND.
>>>>
>>>> Opposed to TCP, as standardized by RFC5681, CWND is thus not necessari=
ly
>>>> increased even when partial_bytes_ack
>>>>
>>>> increases beyond the present CWND.
>>>>
>>>>
>>>>
>>>> An implementation which boldly augments the partial_bytes_ack during t=
he
>>>> time where a CWND is underutilized (but the connection is not idle) ma=
y
>>>> observe that the partial_bytes_ack increases to a very high value,
>>>> possibly
>>>> it increases to
>>>>
>>>> a value many times higher than the CWND.
>>>>
>>>>
>>>>
>>>> The question now arises what should happen once the CWND resumes fully
>>>> utilization and thus may be increased. That is, is the intention of th=
e
>>>> standard of SCTP CC to have :
>>>>
>>>> 1. the CWND now be increased as during =93normal=94 congestion control
>>>> avoidance, i.e., one MTU per acked CWND amount of data
>>>>
>>>> - Or to have -
>>>>
>>>> 2. the CWND now be allowed to recapture the growth that it did not
>>>> realize due to under-utilization but which may be recaptured from the
>>>> partial_bytes_ack value. I.e., let it be increased one MTU per SACK
>>>> until
>>>> partial_bytes_ack has been decreased below CWND, one CWND at a time.
>>>>
>>>>
>>>>
>>>> From an implementation perspective the question likely turns into a
>>>> question
>>>> about the maintaining of the partial_bytes_ack value during the
>>>> period of
>>>> time when the CWND is underutilized. E.g., should then
>>>> partial_bytes_ack be
>>>> decreased with CWND for each times it increases beyond the CWND or
>>>> should it
>>>> be allowed to increase unlimited. But first we need to find out what t=
he
>>>> intention of the standard is=85.
>>>>
>>>>
>>>>
>>>> The above of course is subject to cumulative SACKs and other details
>>>> like
>>>> that. I hope that we can leave such details out of the discussion.
>>>>
>>>>
>>>>
>>>> I hope that you may help.
>>>>
>>>>
>>>>
>>>> Thanks in advance!
>>>>
>>>>
>>>>
>>>> BR, Karen
>>>>
>>>>
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> tcpm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>>
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm

From touch@isi.edu  Wed Apr 18 12:26:20 2012
Return-Path: <touch@isi.edu>
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 8E4E411E8085 for <tcpm@ietfa.amsl.com>; Wed, 18 Apr 2012 12:26:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1DRB2bjN2zv for <tcpm@ietfa.amsl.com>; Wed, 18 Apr 2012 12:26:16 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 911E811E8080 for <tcpm@ietf.org>; Wed, 18 Apr 2012 12:26:16 -0700 (PDT)
Received: from [207.151.141.45] ([207.151.141.45]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q3IJPaWE017557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Apr 2012 12:25:45 -0700 (PDT)
Message-ID: <4F8F152F.9030803@isi.edu>
Date: Wed, 18 Apr 2012 12:25:35 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Matt Mathis <mattmathis@google.com>
References: <CF340E42AED0874C81947E18863DE77B14355D604F@EXMB03.eu.tieto.com> <CAH56bmBe9A2ubUf1J6yM-hXMbaBHy-_XjaEMKGDV7G+7hWkuQw@mail.gmail.com> <4F8EE7E5.7010502@erg.abdn.ac.uk> <4F8F12BE.60808@isi.edu> <CAH56bmCJ+TH55F66b5muSC9wRAi_unRHq_3iXECzw8yyopPd+g@mail.gmail.com>
In-Reply-To: <CAH56bmCJ+TH55F66b5muSC9wRAi_unRHq_3iXECzw8yyopPd+g@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org
Subject: Re: [tcpm] CWND increase after under-utilization in congestion avoidance
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Apr 2012 19:26:20 -0000

Yes.

On 4/18/2012 12:23 PM, Matt Mathis wrote:
> Joe "this proposal" refers to Gory's draft, correct?
>
> Thanks,
> --MM--
> The best way to predict the future is to create it.  - Alan Kay
>
> On Wed, Apr 18, 2012 at 12:15 PM, Joe Touch<touch@isi.edu>  wrote:
>> I am wondering how this is expected to play out. If it's OK to send at the
>> last rate - unless you hear of loss - after the app stops or things drain,
>> then why not do the same during the beginning of a connection (which happens
>> at most once per connection)?
>>
>> We discussed the issue of restart-after-idle several times - and had some
>> proposals for "use it or lose it" a while ago (it's on my idle queue).
>> However, this proposal seems to easily make things much worse IMO.
>>
>> I don't think TCP should "try first and recover if fail"; its premise is
>> "start gently". I think that should apply to restarts as much - if not more
>> - than the connection start.
>>
>> Joe
>>
>>
>> On 4/18/2012 9:12 AM, Gorry Fairhurst wrote:
>>>
>>> +1
>>>
>>> We have this individual draft that suggests how TCP should behave in
>>> similar cases (we plan to update this soon):
>>> https://datatracker.ietf.org/doc/draft-fairhurst-tcpm-newcwv/
>>>
>>> Gorry
>>>
>>> On 17/04/2012 21:36, Matt Mathis wrote:
>>>>
>>>> Well, my opinion would be that as long as flightsize>= cwnd at least
>>>> once recently it should be ok to continue to raise cwnd. Note that
>>>> raising cwnd probably causes the predicate to become not true. Also
>>>> "recently" should be no shorter than one RTT, but may be a longer (the
>>>> details are not so important). The point is that as long as FS
>>>> reaches cwnd at least once per RTT, it is fine to continue to grow the
>>>> window. I believe I have seen it implemented "as long as FS comes
>>>> close to cwnd..."
>>>>
>>>> In the big picture is it important not to keep raising cwnd if cwnd in
>>>> not controlling the connection, because then you have no way to know
>>>> if it is a valid measure of anything useful. However, as long as cwnd
>>>> has been "tested" it is fine to keep pushing it up.
>>>>
>>>> Thanks,
>>>> --MM--
>>>> The best way to predict the future is to create it. - Alan Kay
>>>>
>>>>
>>>>
>>>> On Tue, Apr 17, 2012 at 5:50 AM,<Karen.Nielsen@tieto.com>  wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> SCTP as prescribed by RFC4960 operates with CWND validation in that CWND
>>>>> increase always
>>>>>
>>>>> is subject to its fully usage. That is, CWND only may increase when
>>>>> flightsize>= CWND.
>>>>>
>>>>> Opposed to TCP, as standardized by RFC5681, CWND is thus not necessarily
>>>>> increased even when partial_bytes_ack
>>>>>
>>>>> increases beyond the present CWND.
>>>>>
>>>>>
>>>>>
>>>>> An implementation which boldly augments the partial_bytes_ack during the
>>>>> time where a CWND is underutilized (but the connection is not idle) may
>>>>> observe that the partial_bytes_ack increases to a very high value,
>>>>> possibly
>>>>> it increases to
>>>>>
>>>>> a value many times higher than the CWND.
>>>>>
>>>>>
>>>>>
>>>>> The question now arises what should happen once the CWND resumes fully
>>>>> utilization and thus may be increased. That is, is the intention of the
>>>>> standard of SCTP CC to have :
>>>>>
>>>>> 1. the CWND now be increased as during “normal” congestion control
>>>>> avoidance, i.e., one MTU per acked CWND amount of data
>>>>>
>>>>> - Or to have -
>>>>>
>>>>> 2. the CWND now be allowed to recapture the growth that it did not
>>>>> realize due to under-utilization but which may be recaptured from the
>>>>> partial_bytes_ack value. I.e., let it be increased one MTU per SACK
>>>>> until
>>>>> partial_bytes_ack has been decreased below CWND, one CWND at a time.
>>>>>
>>>>>
>>>>>
>>>>>  From an implementation perspective the question likely turns into a
>>>>> question
>>>>> about the maintaining of the partial_bytes_ack value during the
>>>>> period of
>>>>> time when the CWND is underutilized. E.g., should then
>>>>> partial_bytes_ack be
>>>>> decreased with CWND for each times it increases beyond the CWND or
>>>>> should it
>>>>> be allowed to increase unlimited. But first we need to find out what the
>>>>> intention of the standard is….
>>>>>
>>>>>
>>>>>
>>>>> The above of course is subject to cumulative SACKs and other details
>>>>> like
>>>>> that. I hope that we can leave such details out of the discussion.
>>>>>
>>>>>
>>>>>
>>>>> I hope that you may help.
>>>>>
>>>>>
>>>>>
>>>>> Thanks in advance!
>>>>>
>>>>>
>>>>>
>>>>> BR, Karen
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> tcpm mailing list
>>>>> tcpm@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>>
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> tcpm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>>
>>>>
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm

From jakob.heitz@ericsson.com  Wed Apr 18 13:02:40 2012
Return-Path: <jakob.heitz@ericsson.com>
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 340EF21F844D for <tcpm@ietfa.amsl.com>; Wed, 18 Apr 2012 13:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.46
X-Spam-Level: 
X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAZvXJwNug+p for <tcpm@ietfa.amsl.com>; Wed, 18 Apr 2012 13:02:39 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDD121F8443 for <tcpm@ietf.org>; Wed, 18 Apr 2012 13:02:30 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q3IK2HFv010449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Apr 2012 15:02:21 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.157]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 18 Apr 2012 16:02:17 -0400
From: Jakob Heitz <jakob.heitz@ericsson.com>
To: Joe Touch <touch@isi.edu>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>
Date: Wed, 18 Apr 2012 16:02:15 -0400
Thread-Topic: [tcpm] CWND increase after under-utilization in congestion avoidance
Thread-Index: Ac0dl7CoMVYywNrXQriCt1bDXazZQQABg8Lg
Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391F08DA8428@EUSAACMS0701.eamcs.ericsson.se>
References: <CF340E42AED0874C81947E18863DE77B14355D604F@EXMB03.eu.tieto.com> <CAH56bmBe9A2ubUf1J6yM-hXMbaBHy-_XjaEMKGDV7G+7hWkuQw@mail.gmail.com> <4F8EE7E5.7010502@erg.abdn.ac.uk> <4F8F12BE.60808@isi.edu>
In-Reply-To: <4F8F12BE.60808@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Matt Mathis <mattmathis@google.com>
Subject: Re: [tcpm] CWND increase after under-utilization in congestion	avoidance
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Apr 2012 20:02:40 -0000

I think TCP should do what's best for TCP, not
what's best for the Internet. The Internet is quite
capable of taking care of itself these days.

Please explain how "start gently" makes TCP fast.

On Wednesday, April 18, 2012 12:15 PM, Joe Touch <> wrote:

> I am wondering how this is expected to play out. If it's OK to send at
> the last rate - unless you hear of loss - after the app stops or
> things drain, then why not do the same during the beginning of a
> connection (which happens at most once per connection)?
>=20
> We discussed the issue of restart-after-idle several times - and had
> some proposals for "use it or lose it" a while ago (it's on my idle
> queue). However, this proposal seems to easily make things much worse
> IMO.=20
>=20
> I don't think TCP should "try first and recover if fail"; its premise
> is "start gently". I think that should apply to restarts as much - if
> not more - than the connection start.
>=20
> Joe

--=20
Jakob Heitz.=

From touch@isi.edu  Wed Apr 18 13:12:42 2012
Return-Path: <touch@isi.edu>
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 81FAC21F84CD for <tcpm@ietfa.amsl.com>; Wed, 18 Apr 2012 13:12:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.599
X-Spam-Level: 
X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqSbkcmjWT8C for <tcpm@ietfa.amsl.com>; Wed, 18 Apr 2012 13:12:42 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0332C21F84C8 for <tcpm@ietf.org>; Wed, 18 Apr 2012 13:12:41 -0700 (PDT)
Received: from [207.151.141.45] ([207.151.141.45]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q3IKBAHl028038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Apr 2012 13:11:19 -0700 (PDT)
Message-ID: <4F8F1FDE.5020708@isi.edu>
Date: Wed, 18 Apr 2012 13:11:10 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Jakob Heitz <jakob.heitz@ericsson.com>
References: <CF340E42AED0874C81947E18863DE77B14355D604F@EXMB03.eu.tieto.com> <CAH56bmBe9A2ubUf1J6yM-hXMbaBHy-_XjaEMKGDV7G+7hWkuQw@mail.gmail.com> <4F8EE7E5.7010502@erg.abdn.ac.uk> <4F8F12BE.60808@isi.edu> <7309FCBCAE981B43ABBE69B31C8D21391F08DA8428@EUSAACMS0701.eamcs.ericsson.se>
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391F08DA8428@EUSAACMS0701.eamcs.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" <tcpm@ietf.org>, Matt Mathis <mattmathis@google.com>
Subject: Re: [tcpm] CWND increase after under-utilization in congestion avoidance
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Apr 2012 20:12:42 -0000

On 4/18/2012 1:02 PM, Jakob Heitz wrote:
> I think TCP should do what's best for TCP, not
> what's best for the Internet. The Internet is quite
> capable of taking care of itself these days.

I'm not sure how to address your viewpoint. It's so drastically 
inconsistent with how TCP has evolved and been shepherded by this WG and 
the IETF it's hard to know where to start.

> Please explain how "start gently" makes TCP fast.

It doesn't. That's a different optimization that is contrary to much of 
the design of TCP.

TCP is intended to go 'only as fast as it can while being fair to other 
TCPs and without causing problems' - both for itself and the rest of the 
Internet.

Joe

>
> On Wednesday, April 18, 2012 12:15 PM, Joe Touch<>  wrote:
>
>> I am wondering how this is expected to play out. If it's OK to send at
>> the last rate - unless you hear of loss - after the app stops or
>> things drain, then why not do the same during the beginning of a
>> connection (which happens at most once per connection)?
>>
>> We discussed the issue of restart-after-idle several times - and had
>> some proposals for "use it or lose it" a while ago (it's on my idle
>> queue). However, this proposal seems to easily make things much worse
>> IMO.
>>
>> I don't think TCP should "try first and recover if fail"; its premise
>> is "start gently". I think that should apply to restarts as much - if
>> not more - than the connection start.
>>
>> Joe
>

From jakob.heitz@ericsson.com  Wed Apr 18 14:01:31 2012
Return-Path: <jakob.heitz@ericsson.com>
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 6F19511E80C0 for <tcpm@ietfa.amsl.com>; Wed, 18 Apr 2012 14:01:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.474
X-Spam-Level: 
X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ER+Bg5hmYotw for <tcpm@ietfa.amsl.com>; Wed, 18 Apr 2012 14:01:31 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id E186911E80B4 for <tcpm@ietf.org>; Wed, 18 Apr 2012 14:01:30 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q3IL0Gxl016843 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Apr 2012 16:01:23 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.157]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 18 Apr 2012 17:01:17 -0400
From: Jakob Heitz <jakob.heitz@ericsson.com>
To: Joe Touch <touch@isi.edu>
Date: Wed, 18 Apr 2012 17:01:16 -0400
Thread-Topic: [tcpm] CWND increase after under-utilization in congestion avoidance
Thread-Index: Ac0dn6E9Q4Fp+9/lQ1qzgt0E9NvTjgABn64A
Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391F08DA84E3@EUSAACMS0701.eamcs.ericsson.se>
References: <CF340E42AED0874C81947E18863DE77B14355D604F@EXMB03.eu.tieto.com> <CAH56bmBe9A2ubUf1J6yM-hXMbaBHy-_XjaEMKGDV7G+7hWkuQw@mail.gmail.com> <4F8EE7E5.7010502@erg.abdn.ac.uk> <4F8F12BE.60808@isi.edu> <7309FCBCAE981B43ABBE69B31C8D21391F08DA8428@EUSAACMS0701.eamcs.ericsson.se> <4F8F1FDE.5020708@isi.edu>
In-Reply-To: <4F8F1FDE.5020708@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Matt Mathis <mattmathis@google.com>
Subject: Re: [tcpm] CWND increase after under-utilization in congestion avoidance
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Apr 2012 21:01:31 -0000

On Wednesday, April 18, 2012 1:11 PM, Joe Touch <mailto:touch@isi.edu> wrot=
e:

>> Please explain how "start gently" makes TCP fast.
>=20
> It doesn't.

That's the issue.

--=20
Jakob Heitz.=

From wes@mti-systems.com  Wed Apr 18 14:35:50 2012
Return-Path: <wes@mti-systems.com>
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 DBA2511E8095 for <tcpm@ietfa.amsl.com>; Wed, 18 Apr 2012 14:35:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSk3JdDaKZDL for <tcpm@ietfa.amsl.com>; Wed, 18 Apr 2012 14:35:50 -0700 (PDT)
Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by ietfa.amsl.com (Postfix) with ESMTP id 37DFD11E8094 for <tcpm@ietf.org>; Wed, 18 Apr 2012 14:35:50 -0700 (PDT)
Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr14.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3ILZmPt016648 for <tcpm@ietf.org>; Wed, 18 Apr 2012 17:35:48 -0400
Authentication-Results: cm-omr6 smtp.user=wes@mti-systems.com; auth=pass (PLAIN)
X-Authenticated-UID: wes@mti-systems.com
Received: from [192.206.187.24] ([192.206.187.24:27939] helo=[172.27.250.175]) by cm-omr6 (envelope-from <wes@mti-systems.com>) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id EF/36-22382-3B33F8F4; Wed, 18 Apr 2012 17:35:47 -0400
Message-ID: <4F8F33B1.6040701@mti-systems.com>
Date: Wed, 18 Apr 2012 17:35:45 -0400
From: Wesley Eddy <wes@mti-systems.com>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Jakob Heitz <jakob.heitz@ericsson.com>
References: <CF340E42AED0874C81947E18863DE77B14355D604F@EXMB03.eu.tieto.com> <CAH56bmBe9A2ubUf1J6yM-hXMbaBHy-_XjaEMKGDV7G+7hWkuQw@mail.gmail.com> <4F8EE7E5.7010502@erg.abdn.ac.uk> <4F8F12BE.60808@isi.edu> <7309FCBCAE981B43ABBE69B31C8D21391F08DA8428@EUSAACMS0701.eamcs.ericsson.se>
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391F08DA8428@EUSAACMS0701.eamcs.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Matt Mathis <mattmathis@google.com>, Joe Touch <touch@isi.edu>
Subject: Re: [tcpm] CWND increase after under-utilization in congestion	avoidance
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Apr 2012 21:35:51 -0000

On 4/18/2012 4:02 PM, Jakob Heitz wrote:
> I think TCP should do what's best for TCP, not
> what's best for the Internet. The Internet is quite
> capable of taking care of itself these days.
> 
> Please explain how "start gently" makes TCP fast.


How about by avoiding time spent detecting and responding
to losses?  That's good for TCP.

"Fast" in terms of throughput is a pretty naive metric to
optimize, when we also need to avoid packet losses and
excessive delays presented to the application.  I think
those concerns lead to careful consideration of the issue.

-- 
Wes Eddy
MTI Systems

From perfgeek@mac.com  Wed Apr 18 19:00:07 2012
Return-Path: <perfgeek@mac.com>
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 887BA11E8089 for <tcpm@ietfa.amsl.com>; Wed, 18 Apr 2012 19:00:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24x-RZpCr1mn for <tcpm@ietfa.amsl.com>; Wed, 18 Apr 2012 19:00:06 -0700 (PDT)
Received: from nk11p00mm-asmtp007.mac.com (nk11p00mm-asmtp007.mac.com [17.158.161.6]) by ietfa.amsl.com (Postfix) with ESMTP id EACA821F8491 for <tcpm@ietf.org>; Wed, 18 Apr 2012 19:00:06 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from [192.168.1.65] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by nk11p00mm-asmtp007.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0M2P007RGEVCQR50@nk11p00mm-asmtp007.mac.com> for tcpm@ietf.org; Thu, 19 Apr 2012 01:59:38 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580,1.0.260,0.0.0000 definitions=2012-04-19_01:2012-04-18, 2012-04-19, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1204180351
From: rick jones <perfgeek@mac.com>
In-reply-to: <4F8F12BE.60808@isi.edu>
Date: Wed, 18 Apr 2012 18:59:35 -0700
Message-id: <801E8118-4659-44C7-B3E7-1FC92D9BD9FF@mac.com>
References: <CF340E42AED0874C81947E18863DE77B14355D604F@EXMB03.eu.tieto.com> <CAH56bmBe9A2ubUf1J6yM-hXMbaBHy-_XjaEMKGDV7G+7hWkuQw@mail.gmail.com> <4F8EE7E5.7010502@erg.abdn.ac.uk> <4F8F12BE.60808@isi.edu>
To: Joe Touch <touch@isi.edu>
X-Mailer: Apple Mail (2.1084)
Cc: tcpm@ietf.org, Matt Mathis <mattmathis@google.com>
Subject: Re: [tcpm] CWND increase after under-utilization in congestion avoidance
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Apr 2012 02:00:07 -0000

On Apr 18, 2012, at 12:15 PM, Joe Touch wrote:

> I am wondering how this is expected to play out. If it's OK to send at the last rate - unless you hear of loss - after the app stops or things drain, then why not do the same during the beginning of a connection (which happens at most once per connection)?
> 
> We discussed the issue of restart-after-idle several times - and had some proposals for "use it or lose it" a while ago (it's on my idle queue). However, this proposal seems to easily make things much worse IMO.
> 
> I don't think TCP should "try first and recover if fail"; its premise is "start gently". I think that should apply to restarts as much - if not more - than the connection start.

I've never been all that fond of slow-start after idle, taking the position that at connection start TCP (presumably) knows nothing but it knows *something* in the middle of a connection.  Yes, it may age quickly, so if you were to go to the extreme and ask about it being idle for days, hours or maybe even minutes I might agree that what it knows is old and increasingly suspect, but for a few RTOs I'd be inclined to let it start where it left-off.

rick jones
there is no rest for the wicked, yet the virtuous have no pillows


From touch@isi.edu  Thu Apr 19 09:46:08 2012
Return-Path: <touch@isi.edu>
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 7E9B121F8702 for <tcpm@ietfa.amsl.com>; Thu, 19 Apr 2012 09:46:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.743
X-Spam-Level: 
X-Spam-Status: No, score=-104.743 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQK9XVDIV3O3 for <tcpm@ietfa.amsl.com>; Thu, 19 Apr 2012 09:46:04 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5F57A21F8703 for <tcpm@ietf.org>; Thu, 19 Apr 2012 09:46:04 -0700 (PDT)
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 q3JGjapW028287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Apr 2012 09:45:36 -0700 (PDT)
Message-ID: <4F904130.5020108@isi.edu>
Date: Thu, 19 Apr 2012 09:45:36 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: rick jones <perfgeek@mac.com>
References: <CF340E42AED0874C81947E18863DE77B14355D604F@EXMB03.eu.tieto.com> <CAH56bmBe9A2ubUf1J6yM-hXMbaBHy-_XjaEMKGDV7G+7hWkuQw@mail.gmail.com> <4F8EE7E5.7010502@erg.abdn.ac.uk> <4F8F12BE.60808@isi.edu> <801E8118-4659-44C7-B3E7-1FC92D9BD9FF@mac.com>
In-Reply-To: <801E8118-4659-44C7-B3E7-1FC92D9BD9FF@mac.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, Matt Mathis <mattmathis@google.com>
Subject: Re: [tcpm] CWND increase after under-utilization in congestion avoidance
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Apr 2012 16:46:08 -0000

On 4/18/2012 6:59 PM, rick jones wrote:
>
> On Apr 18, 2012, at 12:15 PM, Joe Touch wrote:
>
>> I am wondering how this is expected to play out. If it's OK to send at the last rate - unless you hear of loss - after the app stops or things drain, then why not do the same during the beginning of a connection (which happens at most once per connection)?
>>
>> We discussed the issue of restart-after-idle several times - and had some proposals for "use it or lose it" a while ago (it's on my idle queue). However, this proposal seems to easily make things much worse IMO.
>>
>> I don't think TCP should "try first and recover if fail"; its premise is "start gently". I think that should apply to restarts as much - if not more - than the connection start.
>
> I've never been all that fond of slow-start after idle, taking the position that at connection start TCP (presumably) knows nothing but it knows *something* in the middle of a connection.  Yes, it may age quickly, so if you were to go to the extreme and ask about it being idle for days, hours or maybe even minutes I might agree that what it knows is old and increasingly suspect, but for a few RTOs I'd be inclined to let it start where it left-off.

You might look at the "use it or lose it" approaches that were proposed 
a few years ago:

http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt

The point is that the CWND info should 'decay'. We didn't converge on 
the timescale of that decay.

However, decaying CWND within a connection during restart is no 
different than the idea of decaying CWND between successive connections 
- see RFC 2140.

While I agree that the decay should be considered, I suspect that the 
vast majority of the cases go idle long enough that they're no different 
from connection starts, though.

Joe

From michael.scharf@alcatel-lucent.com  Wed Apr 25 01:23:51 2012
Return-Path: <michael.scharf@alcatel-lucent.com>
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 1686B21F8766 for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 01:23:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.942
X-Spam-Level: 
X-Spam-Status: No, score=-7.942 tagged_above=-999 required=5 tests=[AWL=-1.693, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmJpYZFksLeC for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 01:23:50 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 46DEA21F8711 for <tcpm@ietf.org>; Wed, 25 Apr 2012 01:23:49 -0700 (PDT)
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 q3P8NASA000346 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <tcpm@ietf.org>; Wed, 25 Apr 2012 10:23:47 +0200
Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.54]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 25 Apr 2012 10:23:27 +0200
From: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
To: tcpm IETF list <tcpm@ietf.org>
Date: Wed, 25 Apr 2012 10:23:26 +0200
Thread-Topic: Charter update - feedback
Thread-Index: Ac0ivLAN4EBcz+fFTwaCR6FvN5Br5Q==
Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E8903583C3D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Subject: [tcpm] Charter update - feedback
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Apr 2012 08:23:51 -0000

Dear all,

we rephrased the suggested TCPM charter update based on the feedback receiv=
ed so far. Most notably, we tried to address the comments from Gorry, Lars,=
 and Matt in Paris, and we removed some duplicate text. We also rephrased t=
he paragraph regarding congestion control in order to emphasize that TCPM's=
 focus is protocol standardization, not research of algorithms.

As already mentioned, the intention is just to get rid of legacy text in th=
e current charter - the scope of TCPM shall not be changed or extended.

Please let us know if you have any suggestions or comments.

Thanks

Michael




TCP Maintenance and Minor Extensions (tcpm)
-------------------------------------------

Description of Working Group: ***DRAFT***

TCP is currently the Internet's predominant transport protocol.
TCPM is the working group within the IETF that handles small TCP
changes, i.e., minor extensions to TCP algorithms and protocol
mechanisms. The TCPM WG serves several purposes:=20

* The WG mostly focuses on maintenance issues (e.g., bug=20
fixes) and modest changes to the protocol, algorithms, and
interfaces that maintain TCP's utility.

* The WG is a venue for moving current TCP specifications=20
along the standards track (as community energy is available=20
for such efforts).=20

* The focus of the working group is TCP. In cases where small
changes are directly applicable to other transports (e.g., SCTP
or DCCP), the mappings to other transports may be specified
alongside that for TCP, but other significant additions and changes
to other transports are not in scope.

TCPM also provides a venue for standardization of incremental
enhancements of TCP's standard congestion control, but such changes
may require additional review by the IRTF Congestion Control Research
Group (ICCRG). Fundamental changes to TCP or its congestion control
algorithms (e.g., departure from loss-based congestion control) will
be handled by other working groups or will require rechartering.

TCP's congestion control algorithms are the model followed by alternate
transports (e.g., SCTP or DCCP), which are standardized in other
working groups, such as the Transport Area WG (tsvwg). In the past, the
IETF has worked on several documents about algorithms that are specified
for multiple protocols (e.g., TCP and SCTP) in the same document. Which
WG shepherds such documents will be determined on a case-by-case basis. In
any case, the TCPM WG will remain in close contact with other relevant
WGs working on these protocols to ensure openness and stringent review
from all angles.

New TCPM milestones that fall within the scope specified within
the charter can be added after concensus on acceptance in the working
group and approval by the responsible Area Director.=

From john@jlc.net  Wed Apr 25 07:40:25 2012
Return-Path: <john@jlc.net>
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 5165B21F8737 for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 07:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.088
X-Spam-Level: 
X-Spam-Status: No, score=-106.088 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJjLTqprPSfS for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 07:40:24 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id AC06E21F8715 for <tcpm@ietf.org>; Wed, 25 Apr 2012 07:40:24 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id C8F3033C20; Wed, 25 Apr 2012 10:40:23 -0400 (EDT)
Date: Wed, 25 Apr 2012 10:40:23 -0400
From: John Leslie <john@jlc.net>
To: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
Message-ID: <20120425144023.GX99904@verdi>
References: <2A886F9088894347A3BE0CC5B7A85F3E8903583C3D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E8903583C3D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>
User-Agent: Mutt/1.4.1i
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] Charter update - feedback
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Apr 2012 14:40:25 -0000

Scharf, Michael (Michael) <michael.scharf@alcatel-lucent.com> wrote:
> 
> As already mentioned, the intention is just to get rid of legacy text
> in the current charter - the scope of TCPM shall not be changed or
> extended.

   Hmm... "rechartering" to me implies at least clarification of scope
where it is ambiguous...

> Please let us know if you have any suggestions or comments.

   Neither the current charter nor this proposed one clearly encourages
or discourages work on what I'll call "expanding TCP option space" -- by
which I mean almost anything to reduce the logjam of options trying to
squeeze into 40 bytes.

   IMHO, this deserves very high priority, and can be sufficiently
solved if we just accept it as a priority.

   In any case, it is my strong belief that either
- we should work on it, or
- we should send this work somewhere else.

   I specifically ask that we clarify whether such work is in-scope.

--
John Leslie <john@jlc.net>

From mattmathis@google.com  Wed Apr 25 08:38:38 2012
Return-Path: <mattmathis@google.com>
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 DEBFD21F87B3 for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 08:38:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuwL4Gbgxhxm for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 08:38:38 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 269B521F87B0 for <tcpm@ietf.org>; Wed, 25 Apr 2012 08:38:37 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so149615wgb.13 for <tcpm@ietf.org>; Wed, 25 Apr 2012 08:38:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=xehAK1vShHcL6DySrfQQljFrEQTjiRiBC1dB8V+D0iU=; b=N0RzXT0Hz4SWgkdxnNO+dQY4UPp3RA7tOGWTX4fowqZ0iWndGvY+YU+ZBOVAWPKSJl j9yqyBKiIKAPbaBqMJrgS+D2mEN/IlduTi6FCouyeHu1G2bT2ESGpruPKSB5QNP6Jb8b R29+RjhV0ksY2LQ+5w9iswJm/9IASGyBOzcKjjhYz2HVAi0CSZKLMFDrSdAEsQZB8j5t RMNRmGrwmvwN70X98F66q9ZY0sOkJFOKmUz4K8XKdWCgVEdegJacfROxggeWOkBfGnMl eapsOqSWoBkbknWVXrnwL1WgAwoWm8QDD+SSgKfNjBXsflhOhqXOo8gVyIfq4Js2ncDq D47A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=xehAK1vShHcL6DySrfQQljFrEQTjiRiBC1dB8V+D0iU=; b=VlVVqAl4EUoQyLUoupkyXnSnvejo1FtrzmkazrnaXek/iaDmTGmSM37VZDTTFXcuxp nGZl4xaBifPij7e7AXFoD0PsPX5yB+3/CxeNcj6AYh9iAyYXh4ieoipsBsBreRTXhVhK eZX+xKfBd64kThYkgxS+nrU15mY2CqwVP+gjSXEZ69nGvbKQRN3+IjnqMassw3hZdQEy gkzpkCZ5F3bbGtWGVUnPmBkuWD34t9WFeAM/3jml1SclgVqsZSm5JMi94i1ao/zXVNu9 b2LG+m4F1hTzqB4FzIMUeDK3G6fn+6oOKFMSOIm9lBvd7jheay9CbuD0dJh6Yn2Y1PxJ vthQ==
Received: by 10.180.93.196 with SMTP id cw4mr7717229wib.19.1335368317263; Wed, 25 Apr 2012 08:38:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.93.196 with SMTP id cw4mr7717198wib.19.1335368317066; Wed, 25 Apr 2012 08:38:37 -0700 (PDT)
Received: by 10.216.217.85 with HTTP; Wed, 25 Apr 2012 08:38:36 -0700 (PDT)
In-Reply-To: <20120425144023.GX99904@verdi>
References: <2A886F9088894347A3BE0CC5B7A85F3E8903583C3D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <20120425144023.GX99904@verdi>
Date: Wed, 25 Apr 2012 08:38:36 -0700
Message-ID: <CAH56bmBabQwSFz48RySW8zb5DuEdV0mFsojZA3TP-A+K1MuQ5w@mail.gmail.com>
From: Matt Mathis <mattmathis@google.com>
To: John Leslie <john@jlc.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQkbgPzUQiayKJLPj5LCNiBg+7RPmVvh1zd2Q8vjnd/oywBzqUK7AtKc1z4yCbmDIdmhW17HJFduioBFKLpWhOE0oBY642ZBv6iRf311M3IdpqN12ua9cW9EDTYC5VlY+SBhyXnC
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] Charter update - feedback
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Apr 2012 15:38:39 -0000

John, People introduce ideas to extend the option space from time to
time.   I don't think they are excluded from tcpm (or other places for
that matter), however no such idea has succeeded in "leaving the
launch pad".   Usually there is an obvious flaw that the author failed
to notice but gets discovered fairly quickly in hallway conversations.

I even heard a new one in Paris, that wasn't quite fleshed out enough
to be an ID yet.

Many many people have worked on this from time to time, but legacy and
NATs kill everything.

If somebody discovers something new, that seems to work they will have
no trouble getting attention in tcpm, I assure you.   There may be a
conversation with the chairs or ADs to select which WG, but it would
not be a barrier to being introduced someplace.

Generally IETF WGs don't take on work for which there are no workable
solutions on the table.   That role belongs to the IRTF.

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


On Wed, Apr 25, 2012 at 7:40 AM, John Leslie <john@jlc.net> wrote:
> Scharf, Michael (Michael) <michael.scharf@alcatel-lucent.com> wrote:
>>
>> As already mentioned, the intention is just to get rid of legacy text
>> in the current charter - the scope of TCPM shall not be changed or
>> extended.
>
> =A0 Hmm... "rechartering" to me implies at least clarification of scope
> where it is ambiguous...
>
>> Please let us know if you have any suggestions or comments.
>
> =A0 Neither the current charter nor this proposed one clearly encourages
> or discourages work on what I'll call "expanding TCP option space" -- by
> which I mean almost anything to reduce the logjam of options trying to
> squeeze into 40 bytes.
>
> =A0 IMHO, this deserves very high priority, and can be sufficiently
> solved if we just accept it as a priority.
>
> =A0 In any case, it is my strong belief that either
> - we should work on it, or
> - we should send this work somewhere else.
>
> =A0 I specifically ask that we clarify whether such work is in-scope.
>
> --
> John Leslie <john@jlc.net>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

From touch@isi.edu  Wed Apr 25 08:47:16 2012
Return-Path: <touch@isi.edu>
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 0A34F21F871E for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 08:47:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.882
X-Spam-Level: 
X-Spam-Status: No, score=-103.882 tagged_above=-999 required=5 tests=[AWL=-1.283, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwFhI-HE7mhV for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 08:47:15 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 82A3321F86D9 for <tcpm@ietf.org>; Wed, 25 Apr 2012 08:47:15 -0700 (PDT)
Received: from [192.168.1.95] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q3PFkp0n028036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Apr 2012 08:46:55 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Joe Touch <touch@isi.edu>
In-Reply-To: <20120425144023.GX99904@verdi>
Date: Wed, 25 Apr 2012 08:47:10 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <2C0EA634-D035-4C4C-802C-A780B02F3B0E@isi.edu>
References: <2A886F9088894347A3BE0CC5B7A85F3E8903583C3D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <20120425144023.GX99904@verdi>
To: John Leslie <john@jlc.net>
X-Mailer: Apple Mail (2.1257)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] Charter update - feedback
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Apr 2012 15:47:16 -0000

On Apr 25, 2012, at 7:40 AM, John Leslie wrote:
...
>   Neither the current charter nor this proposed one clearly encourages
> or discourages work on what I'll call "expanding TCP option space" -- =
by
> which I mean almost anything to reduce the logjam of options trying to
> squeeze into 40 bytes.
>=20
>   IMHO, this deserves very high priority, and can be sufficiently
> solved if we just accept it as a priority.
>=20
>   In any case, it is my strong belief that either
> - we should work on it, or
> - we should send this work somewhere else.
>=20
>   I specifically ask that we clarify whether such work is in-scope.

The charter shouldn't make that conclusion, IMO. That's for the WG to =
decide based on a given proposal.

If you have a *viable* (see below) proposal, let's hear it...

Viable, IMO:
- compatible with legacy TCP in the same SYN exchange
- compatible with known proxy behavior, including segment rewriting =
(where not already prevented by authentication or encryption)
- extends the space of SYNs not just subsequent segments

AFAICT, that set is null. It'd also be nice to be able to know when it =
fails because an intermediate interferes but the endpoints agreed, but =
I'm not sure that's a strict requirement.

There is only one solution I've ever heard of that might work at all - =
TCPv2 in TCPv1 (or TCPv2 in UDP). But that's trivial.

Joe=

From michael.scharf@alcatel-lucent.com  Wed Apr 25 10:11:32 2012
Return-Path: <michael.scharf@alcatel-lucent.com>
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 9DE8021F876C for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 10:11:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.73
X-Spam-Level: 
X-Spam-Status: No, score=-9.73 tagged_above=-999 required=5 tests=[AWL=0.519,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEtJkjZp9p6d for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 10:11:26 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 93FEB21F8754 for <tcpm@ietf.org>; Wed, 25 Apr 2012 10:11:25 -0700 (PDT)
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 q3PHBMQJ008205 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Apr 2012 19:11:23 +0200
Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.54]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 25 Apr 2012 19:11:23 +0200
From: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
To: John Leslie <john@jlc.net>
Date: Wed, 25 Apr 2012 19:11:21 +0200
Thread-Topic: [tcpm] Charter update - feedback
Thread-Index: Ac0i8WAT69tWcMZOQz60FG0Vjxj+zAAB8z7Q
Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E8903583C58@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>
References: <2A886F9088894347A3BE0CC5B7A85F3E8903583C3D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <20120425144023.GX99904@verdi>
In-Reply-To: <20120425144023.GX99904@verdi>
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 list <tcpm@ietf.org>
Subject: Re: [tcpm] Charter update - feedback
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Apr 2012 17:11:32 -0000

>    Neither the current charter nor this proposed one clearly=20
> encourages or discourages work on what I'll call "expanding=20
> TCP option space" -- by which I mean almost anything to=20
> reduce the logjam of options trying to squeeze into 40 bytes.
>
>    IMHO, this deserves very high priority, and can be=20
> sufficiently solved if we just accept it as a priority.
>=20
>    In any case, it is my strong belief that either
> - we should work on it, or
> - we should send this work somewhere else.
>=20
>    I specifically ask that we clarify whether such work is in-scope.

My view on this is:

1. A survey and analysis of the problems of option space extension could be=
 in-scope of the existing TCPM charter, as well as the suggested charter up=
date (since the scope is the same), provided that the well-known constraint=
s are fulfilled, e. g., WG energy and consensus on a document.

2. At least a subset of the known solutions seems to be beyond a minor TCP =
modification (e. g., TCPx2), and therefore they might not be in scope of th=
e current or suggested new TCPM charter.


My understanding is that we currently don't have consensus whether the prob=
lem can indeed be solved in a non-disruptive way, and we don't known if suc=
h a solution could/would get deployed in the Internet. Given that constrain=
ts, I think that the TCPM charter must not ask for a solution right now. Th=
e charter can obviously be changed once we have more support in the communi=
ty and consensus regarding solutions.

Anyway, TCPM certainly welcomes further technical discussions.

Michael

From wes@mti-systems.com  Wed Apr 25 10:20:10 2012
Return-Path: <wes@mti-systems.com>
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 95E9421F87E6 for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 10:20:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.149
X-Spam-Level: 
X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=1.450,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5r7GGFVC5rN for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 10:20:09 -0700 (PDT)
Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id 2D62121F87E1 for <tcpm@ietf.org>; Wed, 25 Apr 2012 10:20:09 -0700 (PDT)
Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q3PHK8Nx003360 for <tcpm@ietf.org>; Wed, 25 Apr 2012 13:20:08 -0400
Authentication-Results: cm-omr1 smtp.user=wes@mti-systems.com; auth=pass (PLAIN)
X-Authenticated-UID: wes@mti-systems.com
Received: from [107.50.164.185] ([107.50.164.185:10244] helo=[192.168.43.65]) by cm-omr1 (envelope-from <wes@mti-systems.com>) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id B1/1C-23914-642389F4; Wed, 25 Apr 2012 13:20:08 -0400
Message-ID: <4F98323A.9010500@mti-systems.com>
Date: Wed, 25 Apr 2012 13:19:54 -0400
From: Wesley Eddy <wes@mti-systems.com>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>
References: <2A886F9088894347A3BE0CC5B7A85F3E8903583C3D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <20120425144023.GX99904@verdi> <2C0EA634-D035-4C4C-802C-A780B02F3B0E@isi.edu>
In-Reply-To: <2C0EA634-D035-4C4C-802C-A780B02F3B0E@isi.edu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] Charter update - feedback
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Apr 2012 17:20:10 -0000

On 4/25/2012 11:47 AM, Joe Touch wrote:
> 
> On Apr 25, 2012, at 7:40 AM, John Leslie wrote:
> ...
>>   Neither the current charter nor this proposed one clearly encourages
>> or discourages work on what I'll call "expanding TCP option space" -- by
>> which I mean almost anything to reduce the logjam of options trying to
>> squeeze into 40 bytes.
>>
>>   IMHO, this deserves very high priority, and can be sufficiently
>> solved if we just accept it as a priority.
>>
>>   In any case, it is my strong belief that either
>> - we should work on it, or
>> - we should send this work somewhere else.


I believe this (TCPM) is the place, if such work is to be done.
Anantha's draft (and the collected email archives since maybe
2004ish) pretty clearly show that TCPM *has* been working on
this for some time, and has simply not found an acceptable
solution with consensus to proceed:
https://datatracker.ietf.org/doc/draft-ananth-tcpm-tcpoptext/


>>   I specifically ask that we clarify whether such work is in-scope.
> 
> The charter shouldn't make that conclusion, IMO. That's for the WG to decide based on a given proposal.


Agreed; if an approach exists to support it as a "minor extension"
then it would be in scope, but that needs to be evaluated along
with the viability of a given proposal.

I would support (as individual and as AD) doing an Informational
snapshot of the collected thoughts and proposals to-date and why
each has fallen down.  It could be a milestone though and not
necessarily part of the charter text.  I think Anantha's document
is a reasonable starting point and the approach of trying to
identify requirements to evaluate against echoes Joe's three
criteria for a solution which he's reiterated several times to the
list, and I think are somewhat accepted.

-- 
Wes Eddy
MTI Systems

From ananth@cisco.com  Wed Apr 25 10:59:31 2012
Return-Path: <ananth@cisco.com>
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 5468621F885B for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 10:59:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.572
X-Spam-Level: 
X-Spam-Status: No, score=-9.572 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_FWDLOOK=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGUjM71PbkOT for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 10:59:30 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id ACB9521F8859 for <tcpm@ietf.org>; Wed, 25 Apr 2012 10:59:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=3937; q=dns/txt; s=iport; t=1335376770; x=1336586370; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=dK0kV8l2zMvHaptHJL6P3ruX7gGjV8eLBWZzxHEoJCI=; b=kqWsRlLzP/AWPUZAdGITjI5ZFp7zOWs7vKDAfphFsCQlGwAvDgZbFl/7 IQ5hgtb5GbPGHiGlkJzg7Gb8c0O0Zq6UYlhgkkEL05tybDwCRKaI6syEH iRGVmE2KvG5pGKhXUDPvx1Owsk0ghsAigp89/dZcQC3h1Cu/4dfqLjYvW I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EALQ6mE+rRDoI/2dsb2JhbABFsU2BB4IJAQEBBBIBHQo/DAQCAQgRBAEBCwYXAQYBRQkIAQEEARIIEweHbAELmz+gI499YwSIY44pjUSBaYMJgTQHAQ
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="39567366"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 25 Apr 2012 17:59:29 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3PHxSuZ012918; Wed, 25 Apr 2012 17:59:28 GMT
Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 25 Apr 2012 10:59:28 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 25 Apr 2012 10:59:24 -0700
Message-ID: <1F8E0A684D3FF54680294BCFE57A7DB504FACD5F@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <CAH56bmBabQwSFz48RySW8zb5DuEdV0mFsojZA3TP-A+K1MuQ5w@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] Charter update - feedback
Thread-Index: Ac0i+X+eAgf1OgRVTwOjwvhlkAeWpQADWCNg
References: <2A886F9088894347A3BE0CC5B7A85F3E8903583C3D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com><20120425144023.GX99904@verdi> <CAH56bmBabQwSFz48RySW8zb5DuEdV0mFsojZA3TP-A+K1MuQ5w@mail.gmail.com>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Matt Mathis" <mattmathis@google.com>, "John Leslie" <john@jlc.net>
X-OriginalArrivalTime: 25 Apr 2012 17:59:28.0367 (UTC) FILETIME=[28713FF0:01CD230D]
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] Charter update - feedback
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Apr 2012 17:59:31 -0000

<Catching up>

Hi,

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf
Of
> Matt Mathis
> Sent: Wednesday, April 25, 2012 8:39 AM
> To: John Leslie
> Cc: tcpm IETF list
> Subject: Re: [tcpm] Charter update - feedback
>=20
> John, People introduce ideas to extend the option space from time to
> time.   I don't think they are excluded from tcpm (or other places for
> that matter), however no such idea has succeeded in "leaving the
> launch pad".   Usually there is an obvious flaw that the author failed
> to notice but gets discovered fairly quickly in hallway conversations.
>=20
> I even heard a new one in Paris, that wasn't quite fleshed out enough
> to be an ID yet.

I don't want to cause a rat-hole on this topic. I assume you are talking
about :-

http://tools.ietf.org/html/draft-ananth-tcpm-tcpoptext-00


Yes, the TCP option space issue has been discussed before, yes there
were proposals on table. Nothing went forward. ?One of the main reasons
was : Initially the TCP option space issue was perceived as "solution in
search of a problem" when there were some early proposals made on this
topic. Of course every solution had the issue with middleboxes (with
varying degrees) Things changed later on, many folks including the
chairs were happy to revisit this discussion, at least to document the
issues, instead of having periodic email discussions now and then and
then let it die. This is the reason I (volunteered) wrote the ID, main
motivation to rejuvenate the discussions and document whatever the comes
out it. I would like to add that, if we can simply the requirements,
then there is a scope for arriving at a solution that probably works for
most of the cases and rest of cases it may not (IMO). [ can I point out
many RFC's where caveats are made and documented and moved on] FWIW, in
my document I cite a reference which did some experimentation on
middleboxes and came to conclusion that "it is still possible to extend
TCP, but careful design choices need to be made".

So please read the document and provide comments. If this topic is not
as interesting as some congestion/flow control change, SACK extensions,
Initial window change OR TCP fast open or any such thing, then that is
fine, so be it. I don't need to beat the drum again to emphasize how
important this problem for TCP's evolution. IMO, this work is fully
within the scope of TCPM, many folks are interested to revive this
discussion. For example things like "Timestamps modification
suggestion", where you don't need to send timestamps every packet or on
3 way handshake are useful extensions (FWIW, the TCP option space
document also mentions it). I think, Tim Shepherd came to the mike when
I quickly presented in Paris and mentioned some 80 bits (am I saying
this correct?) of the TCP header that can be "reused" to scavenge TCP
option space. We haven't really had discussions (forward looking) to
continue those ideas and beat it to death. I am sure if we chose to move
along discussing this seriously, there would more ideas on table and
maybe we can converge with something.

Ok, I guess we need to answer the following questions :-=20

- do we want revive TCP option space issue discussions given that it has
become a real issue now?
- If so, can we use the above document as a starting point? Or any other
plans?

If we cannot answer the above 2 simple questions, I see no value in this
discussion.=20

Chairs, can you outline the next steps for this document? As what needs
to be done w.r.t the document? (above link)

$0.02,
-Anantha

PS:  Joe, in case you are planning to reply to this email, then can you
please focus on the above 2 questions, Yes I heard your viewpoints are
but I have simply expressed my opinion, hence I feel there is no need to
nitpick on some statements above.=20


<snip>

From ananth@cisco.com  Wed Apr 25 11:11:28 2012
Return-Path: <ananth@cisco.com>
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 2A6A021F881C for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 11:11:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.369
X-Spam-Level: 
X-Spam-Status: No, score=-10.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxP2a04QSwsN for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 11:11:26 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id A228621F87DD for <tcpm@ietf.org>; Wed, 25 Apr 2012 11:11:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=1594; q=dns/txt; s=iport; t=1335377485; x=1336587085; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Zjf7vciTzX7MPLapKWwELKjQ6Eix6WvjJf0Irjz6nK0=; b=jnQTrgT03f+U5zqB5IFYyumBRii0KhVugNxdZGa10H/D20S+pQAlH6gV lOAOWD8cSXFQMvzma5J4eedwLBxEkTc0rNoqrhLio1sP/2RTcGs/N51sH FSkLbxwfGxIrqB9MNypskf9CkGpoxkl4cfmKQhF7MYkCVx9W3QtifzIs6 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAPs8mE+rRDoH/2dsb2JhbABFDrE/gQeCCQEBAQMBAQEBDwEdCjQLBQsCAQgiBhgGASYwAQEEARIIEweHaAQBC5s1oB4EiWuGEmMEiGObbYFpgjBZ
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="42055615"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 25 Apr 2012 18:11:21 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3PIBLmX014157; Wed, 25 Apr 2012 18:11:21 GMT
Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 25 Apr 2012 11:11:21 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 25 Apr 2012 11:11:20 -0700
Message-ID: <1F8E0A684D3FF54680294BCFE57A7DB504FACD77@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <2C0EA634-D035-4C4C-802C-A780B02F3B0E@isi.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] Charter update - feedback
Thread-Index: Ac0i+rN6TyP8Cr7mQu2bxDnfezW/sgAEsMYQ
References: <2A886F9088894347A3BE0CC5B7A85F3E8903583C3D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com><20120425144023.GX99904@verdi> <2C0EA634-D035-4C4C-802C-A780B02F3B0E@isi.edu>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Joe Touch" <touch@isi.edu>, "John Leslie" <john@jlc.net>
X-OriginalArrivalTime: 25 Apr 2012 18:11:21.0034 (UTC) FILETIME=[D1399AA0:01CD230E]
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] Charter update - feedback
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Apr 2012 18:11:28 -0000

> The charter shouldn't make that conclusion, IMO. That's for the WG to
> decide based on a given proposal.
>=20
> If you have a *viable* (see below) proposal, let's hear it...
>=20
> Viable, IMO:
> - compatible with legacy TCP in the same SYN exchange
> - compatible with known proxy behavior, including segment rewriting
> (where not already prevented by authentication or encryption)
> - extends the space of SYNs not just subsequent segments
>=20
> AFAICT, that set is null. It'd also be nice to be able to know when it
> fails because an intermediate interferes but the endpoints agreed, but
> I'm not sure that's a strict requirement.
>=20
> There is only one solution I've ever heard of that might work at all -
> TCPv2 in TCPv1 (or TCPv2 in UDP). But that's trivial.

Well, I am afraid that is not the universal opinion, just your opinion.
For instance you were opposed on the timestamps modification proposal
which others supported. Some folks are fine to "if we have to fire up 2
SYN's" but you weren't. If we want to list the requirements of what all
conditions that TCP option space proposals need to satisfy, we can list
it. (my document already classifies it to some extent) We can also need
debate as to which conditions that can be relaxed. (MUST/SHOULD/MAY if
you wiil). We can't jump to a solution unless there is a consensus on
the requirements.

[Just to avoid going round in circles]

-Anantha
>=20
> Joe
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

From touch@isi.edu  Wed Apr 25 11:16:10 2012
Return-Path: <touch@isi.edu>
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 3234A21F8885 for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 11:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.499
X-Spam-Level: 
X-Spam-Status: No, score=-105.499 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MB4j9E7UNgHv for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 11:16:09 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1504E21F8871 for <tcpm@ietf.org>; Wed, 25 Apr 2012 11:16:08 -0700 (PDT)
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 q3PIFEjk026558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Apr 2012 11:15:14 -0700 (PDT)
Message-ID: <4F983F32.5040704@isi.edu>
Date: Wed, 25 Apr 2012 11:15:14 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0
MIME-Version: 1.0
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
References: <2A886F9088894347A3BE0CC5B7A85F3E8903583C3D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com><20120425144023.GX99904@verdi> <CAH56bmBabQwSFz48RySW8zb5DuEdV0mFsojZA3TP-A+K1MuQ5w@mail.gmail.com> <1F8E0A684D3FF54680294BCFE57A7DB504FACD5F@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <1F8E0A684D3FF54680294BCFE57A7DB504FACD5F@xmb-sjc-23e.amer.cisco.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 list <tcpm@ietf.org>, Matt Mathis <mattmathis@google.com>
Subject: Re: [tcpm] Charter update - feedback
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Apr 2012 18:16:10 -0000

Hi, all,

On 4/25/2012 10:59 AM, Anantha Ramaiah (ananth) wrote:
...
> Ok, I guess we need to answer the following questions :-
>
> - do we want revive TCP option space issue discussions given that it has
> become a real issue now?

You suggest earlier attempts were viewed as proposed solutions in search 
of a problem.

The issue has, IMO, always been (and continues to be):

	regardless of the problem or need,
	does a viable solution exist?

I gave a list of requirements for a viable solution. We should start by 
agreeing on that set before *assuming* a solution exists.

Joe

From touch@isi.edu  Wed Apr 25 11:19:39 2012
Return-Path: <touch@isi.edu>
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 9216D21F88A1 for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 11:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.532
X-Spam-Level: 
X-Spam-Status: No, score=-105.532 tagged_above=-999 required=5 tests=[AWL=1.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2FwDB8qL18o for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 11:19:39 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0180821F889E for <tcpm@ietf.org>; Wed, 25 Apr 2012 11:19:38 -0700 (PDT)
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 q3PIJ6eO026945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Apr 2012 11:19:06 -0700 (PDT)
Message-ID: <4F98401A.6050201@isi.edu>
Date: Wed, 25 Apr 2012 11:19:06 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0
MIME-Version: 1.0
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
References: <2A886F9088894347A3BE0CC5B7A85F3E8903583C3D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com><20120425144023.GX99904@verdi> <2C0EA634-D035-4C4C-802C-A780B02F3B0E@isi.edu> <1F8E0A684D3FF54680294BCFE57A7DB504FACD77@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <1F8E0A684D3FF54680294BCFE57A7DB504FACD77@xmb-sjc-23e.amer.cisco.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 list <tcpm@ietf.org>
Subject: Re: [tcpm] Charter update - feedback
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Apr 2012 18:19:39 -0000

On 4/25/2012 11:11 AM, Anantha Ramaiah (ananth) wrote:
>> The charter shouldn't make that conclusion, IMO. That's for the WG to
>> decide based on a given proposal.
>>
>> If you have a *viable* (see below) proposal, let's hear it...
>>
>> Viable, IMO:
>> - compatible with legacy TCP in the same SYN exchange
>> - compatible with known proxy behavior, including segment rewriting
>> (where not already prevented by authentication or encryption)
>> - extends the space of SYNs not just subsequent segments
>>
>> AFAICT, that set is null. It'd also be nice to be able to know when it
>> fails because an intermediate interferes but the endpoints agreed, but
>> I'm not sure that's a strict requirement.
>>
>> There is only one solution I've ever heard of that might work at all -
>> TCPv2 in TCPv1 (or TCPv2 in UDP). But that's trivial.
>
> Well, I am afraid that is not the universal opinion, just your opinion.
> For instance you were opposed on the timestamps modification proposal
> which others supported.

I demonstrated problems with them.

> Some folks are fine to "if we have to fire up 2
> SYN's" but you weren't.

I demonstrated problems with them too - notably when an endpoint uses L2 
load balancing.

 > If we want to list the requirements of what all
> conditions that TCP option space proposals need to satisfy, we can list
> it. (my document already classifies it to some extent) We can also need
> debate as to which conditions that can be relaxed. (MUST/SHOULD/MAY if
> you wiil). We can't jump to a solution unless there is a consensus on
> the requirements.

Yes, I agree.

Joe

From ananth@cisco.com  Wed Apr 25 11:28:51 2012
Return-Path: <ananth@cisco.com>
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 AF82721F88C5 for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 11:28:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.381
X-Spam-Level: 
X-Spam-Status: No, score=-10.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFu6cKwUwQfy for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 11:28:51 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9747E21F88CB for <tcpm@ietf.org>; Wed, 25 Apr 2012 11:28:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=2482; q=dns/txt; s=iport; t=1335378528; x=1336588128; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=c8GIrvLRb5F1toVsbrWzn3Evc+is43cOP0U87pH7WX8=; b=da3RjAYW3gfnt/cswbw59is2bAJyJnGqV7PPeiN4h53YVHIB6ntWL2aG bFv81vxE+nzE8F1mznD90PvsrRUsUgeiEaH+Dq/0jmuSGnXeFCedwKBaR HrHEpgtC8yVyRRFLXmoNRVpGxWOO6gHIRZNQzcdR8HQ06FaCPTlhkMfsr 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAJlBmE+rRDoJ/2dsb2JhbABFDrE/gQeCCQEBAQMBEgEdCj8MBAIBCBEEAQEBCgYXAQYBRQkIAQEEEwgTB4doBAGbN6Ahj31jBIhjm22BaYIwWQ
X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="39573876"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 25 Apr 2012 18:28:48 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3PISmJ3003471; Wed, 25 Apr 2012 18:28:48 GMT
Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 25 Apr 2012 11:28:48 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 25 Apr 2012 11:28:47 -0700
Message-ID: <1F8E0A684D3FF54680294BCFE57A7DB504FACDA1@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <4F98401A.6050201@isi.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] Charter update - feedback
Thread-Index: Ac0jD/xjxQOFMfjXQ3CCUsTi6D6ExwAAB66Q
References: <2A886F9088894347A3BE0CC5B7A85F3E8903583C3D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com><20120425144023.GX99904@verdi> <2C0EA634-D035-4C4C-802C-A780B02F3B0E@isi.edu> <1F8E0A684D3FF54680294BCFE57A7DB504FACD77@xmb-sjc-23e.amer.cisco.com> <4F98401A.6050201@isi.edu>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Joe Touch" <touch@isi.edu>
X-OriginalArrivalTime: 25 Apr 2012 18:28:48.0130 (UTC) FILETIME=[4157C620:01CD2311]
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] Charter update - feedback
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Apr 2012 18:28:51 -0000

> -----Original Message-----
> From: Joe Touch [mailto:touch@isi.edu]
> Sent: Wednesday, April 25, 2012 11:19 AM
> To: Anantha Ramaiah (ananth)
> Cc: John Leslie; tcpm IETF list
> Subject: Re: [tcpm] Charter update - feedback
>=20
>=20
>=20
> On 4/25/2012 11:11 AM, Anantha Ramaiah (ananth) wrote:
> >> The charter shouldn't make that conclusion, IMO. That's for the WG
> to
> >> decide based on a given proposal.
> >>
> >> If you have a *viable* (see below) proposal, let's hear it...
> >>
> >> Viable, IMO:
> >> - compatible with legacy TCP in the same SYN exchange
> >> - compatible with known proxy behavior, including segment rewriting
> >> (where not already prevented by authentication or encryption)
> >> - extends the space of SYNs not just subsequent segments
> >>
> >> AFAICT, that set is null. It'd also be nice to be able to know when
> >> it fails because an intermediate interferes but the endpoints
> agreed,
> >> but I'm not sure that's a strict requirement.
> >>
> >> There is only one solution I've ever heard of that might work at
all
> >> -
> >> TCPv2 in TCPv1 (or TCPv2 in UDP). But that's trivial.
> >
> > Well, I am afraid that is not the universal opinion, just your
> opinion.
> > For instance you were opposed on the timestamps modification
proposal
> > which others supported.
>=20
> I demonstrated problems with them.
>=20
> > Some folks are fine to "if we have to fire up 2 SYN's" but you
> > weren't.
>=20
> I demonstrated problems with them too - notably when an endpoint uses
> L2 load balancing.

Fine, you "demonstrated some problems" but that doesn't mean that we
can't continue discussing them  esp, when there are others who did not
think there was a "demonstrated problem" :-)

>=20
>  > If we want to list the requirements of what all
> > conditions that TCP option space proposals need to satisfy, we can
> > list it. (my document already classifies it to some extent) We can
> > also need debate as to which conditions that can be relaxed.
> > (MUST/SHOULD/MAY if you wiil). We can't jump to a solution unless
> > there is a consensus on the requirements.
>=20
> Yes, I agree.

Ok, then. I am fine to take that route (IMO, the logical route) we
always do this in any product development, don't we ? Requirements first
and solution next.  IMO, the document attempts to support such a line of
thinking.  I'll let chairs to decide on the next steps.

-Anantha
>=20
> Joe

From john@jlc.net  Wed Apr 25 11:46:25 2012
Return-Path: <john@jlc.net>
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 92CF721F888D for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 11:46:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.111
X-Spam-Level: 
X-Spam-Status: No, score=-106.111 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rio25NdbEKev for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 11:46:25 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id BB46221F887B for <tcpm@ietf.org>; Wed, 25 Apr 2012 11:46:24 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 8F47033C21; Wed, 25 Apr 2012 14:46:24 -0400 (EDT)
Date: Wed, 25 Apr 2012 14:46:24 -0400
From: John Leslie <john@jlc.net>
To: Wesley Eddy <wes@mti-systems.com>
Message-ID: <20120425184624.GC99904@verdi>
References: <2A886F9088894347A3BE0CC5B7A85F3E8903583C3D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <20120425144023.GX99904@verdi> <2C0EA634-D035-4C4C-802C-A780B02F3B0E@isi.edu> <4F98323A.9010500@mti-systems.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4F98323A.9010500@mti-systems.com>
User-Agent: Mutt/1.4.1i
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] Charter update - feedback
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Apr 2012 18:46:25 -0000

   I apologize if this is out-of-scope, but it feels at least as in-scope
as what I'm responding to:

Wesley Eddy <wes@mti-systems.com> wrote:
> On 4/25/2012 11:47 AM, Joe Touch wrote:
>> On Apr 25, 2012, at 7:40 AM, John Leslie wrote:
>> ...
>>> Neither the current charter nor this proposed one clearly encourages
>>> or discourages work on what I'll call "expanding TCP option space" -- by
>>> which I mean almost anything to reduce the logjam of options trying to
>>> squeeze into 40 bytes.
>>>
>>> IMHO, this deserves very high priority, and can be sufficiently
>>> solved if we just accept it as a priority.
>>>
>>> In any case, it is my strong belief that either
>>> - we should work on it, or
>>> - we should send this work somewhere else.
> 
> I believe this (TCPM) is the place, if such work is to be done.
> Anantha's draft (and the collected email archives since maybe
> 2004ish) pretty clearly show that TCPM *has* been working on
> this for some time, and has simply not found an acceptable
> solution with consensus to proceed:
> 
>>> I specifically ask that we clarify whether such work is in-scope.
>> 
>> The charter shouldn't make that conclusion, IMO. That's for the WG
>> to decide based on a given proposal.
> 
> Agreed; if an approach exists to support it as a "minor extension"
> then it would be in scope, but that needs to be evaluated along
> with the viability of a given proposal.
> 
> I would support (as individual and as AD) doing an Informational
> snapshot of the collected thoughts and proposals to-date and why
> each has fallen down. It could be a milestone though and not
> necessarily part of the charter text.

   That is acceptable to me.

> I think Anantha's document is a reasonable starting point and the
> approach of trying to identify requirements to evaluate against
> echoes Joe's three criteria for a solution which he's reiterated
> several times to the list, and I think are somewhat accepted.

   "Somewhat accepted" may overstate the case...

   Joe wrote:

>> Viable, IMO:
>> - compatible with legacy TCP in the same SYN exchange

   This is easy. I think we do accept this.

>> - compatible with known proxy behavior, including segment rewriting
>>   (where not already prevented by authentication or encryption)

   This is open-ended. I think we need to list proxy behaviors we
wish to be "compatible" with -- and we should clarify what we mean
by "compatible". (Clearly, we can't expect to get option negotiation
through a proxy which strips out every attempt, but we can recognize
that our attempts are being stripped.)

>> - extends the space of SYNs not just subsequent segments

   We should be able to extend the space in the responding SYN, but
not in the originating SYN. What we need instead is to enable
additional options from the originating endpoint to be processed
"as if they were in an initial SYN".

   Given rewording to that effect, I think the requirements would be
reasonable to include in a tcp-option-extension Informational RFC.

--
John Leslie <john@jlc.net>

From michael.scharf@alcatel-lucent.com  Wed Apr 25 12:31:10 2012
Return-Path: <michael.scharf@alcatel-lucent.com>
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 69D6421F88DC for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 12:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.788
X-Spam-Level: 
X-Spam-Status: No, score=-7.788 tagged_above=-999 required=5 tests=[AWL=-1.539, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyRRP6RsYnQb for <tcpm@ietfa.amsl.com>; Wed, 25 Apr 2012 12:31:09 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by ietfa.amsl.com (Postfix) with ESMTP id 37E2821F88C7 for <tcpm@ietf.org>; Wed, 25 Apr 2012 12:31:08 -0700 (PDT)
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 q3PJV39R023028 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Apr 2012 21:31:03 +0200
Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.54]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 25 Apr 2012 21:31:03 +0200
From: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>, Matt Mathis <mattmathis@google.com>, John Leslie <john@jlc.net>
Date: Wed, 25 Apr 2012 21:31:00 +0200
Thread-Topic: [tcpm] Charter update - feedback
Thread-Index: Ac0i+X+eAgf1OgRVTwOjwvhlkAeWpQADWCNgAAG547A=
Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E8903583C5F@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>
References: <2A886F9088894347A3BE0CC5B7A85F3E8903583C3D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com><20120425144023.GX99904@verdi> <CAH56bmBabQwSFz48RySW8zb5DuEdV0mFsojZA3TP-A+K1MuQ5w@mail.gmail.com> <1F8E0A684D3FF54680294BCFE57A7DB504FACD5F@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <1F8E0A684D3FF54680294BCFE57A7DB504FACD5F@xmb-sjc-23e.amer.cisco.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.13
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] Charter update - feedback
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Apr 2012 19:31:10 -0000

> http://tools.ietf.org/html/draft-ananth-tcpm-tcpoptext-00
>=20
> Ok, I guess we need to answer the following questions :-=20
>=20
> - do we want revive TCP option space issue discussions given=20
> that it has become a real issue now?
> - If so, can we use the above document as a starting point?=20
> Or any other plans?
>=20
> If we cannot answer the above 2 simple questions, I see no=20
> value in this discussion.=20
>=20
> Chairs, can you outline the next steps for this document? As=20
> what needs to be done w.r.t the document? (above link)

I agree with Wes that a document that surveys and analyzes existing proposa=
ls would be helpful, heading for informational. I think that your draft is =
a good starting point for such a survey,
and it would be important to include the mailing list feedback and then pre=
sent an updated version in the next meeting, to have more discussion time. =
(Note that the draft was submitted post-deadline for Paris.)


As individual, my impression that the draft requires more work before it ca=
n become a WG item.

For instance, I think that the requirement H1 would benefit from a more fin=
e-grained analysis. Some keywords out of my head (sorry, I've not carefully=
 thought of that list): interaction with data in SYNs?, SYN cookies?, issue=
s with concurrent SYNs?, TCP offloading impact?, robustness to packet-reord=
ering?, load balancing?, etc. It would be excellent to first come up with a=
 comprehensive list of possible problems, and then match the known schemes =
against this, in order to show what the downsides and costs are. Obviously,=
 the requirements for SYNs and non-SYNs are different.

I also don't know whether the solution list is complete. For instance, RFC =
6013 happens to talk about option space extension... And, BTW, some naive g=
uy asked a naive question a long time ago: http://www.ietf.org/mail-archive=
/web/tcpm/current/msg03700.html ;) The list thread explains why that questi=
on was really naive. But there might be more ideas like that out there.=20


Also as indivudual, I would disagree with the scope of the document if the =
plan was to converge or specify a (single) solution therein. I could unders=
tand the current title and abstract in this way. A better wording for the t=
itle would be something like "Survey and analysis of TCP option space exten=
sions proposals". In my optionion, it would make sense to first work on a d=
ocument that comprehensively lists the problems and surveys known solution,=
 and have consensus on the list of pros and cons... That document does not =
have trade them off. Any any actual specification should be done separately=
.

Michael

PS: I am personally convinced that TCPM should adopt documents once their c=
ontent is somewhat mature (i. e., not necessarily -00).=

From rs@netapp.com  Thu Apr 26 07:19:26 2012
Return-Path: <rs@netapp.com>
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 2301C21E809C for <tcpm@ietfa.amsl.com>; Thu, 26 Apr 2012 07:19:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.265
X-Spam-Level: 
X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-v3nMIdJ6i6 for <tcpm@ietfa.amsl.com>; Thu, 26 Apr 2012 07:19:25 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 38DA121E809B for <tcpm@ietf.org>; Thu, 26 Apr 2012 07:19:25 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,486,1330934400"; d="scan'208";a="643613724"
Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 26 Apr 2012 07:19:10 -0700
Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q3QEJ9m3001837; Thu, 26 Apr 2012 07:19:10 -0700 (PDT)
Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.248]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0247.003; Thu, 26 Apr 2012 07:18:24 -0700
From: "Scheffenegger, Richard" <rs@netapp.com>
To: Joe Touch <touch@isi.edu>, "Anantha Ramaiah (ananth)" <ananth@cisco.com>
Thread-Topic: [tcpm] Charter update - feedback
Thread-Index: Ac0ivLAN4EBcz+fFTwaCR6FvN5Br5QAb1TGAAAJVFwAABQjzAAAARXAAABpxepA=
Date: Thu, 26 Apr 2012 14:19:09 +0000
Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F1C0883@SACEXCMBX02-PRD.hq.netapp.com>
References: <2A886F9088894347A3BE0CC5B7A85F3E8903583C3D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com><20120425144023.GX99904@verdi> <2C0EA634-D035-4C4C-802C-A780B02F3B0E@isi.edu> <1F8E0A684D3FF54680294BCFE57A7DB504FACD77@xmb-sjc-23e.amer.cisco.com> <4F98401A.6050201@isi.edu>
In-Reply-To: <4F98401A.6050201@isi.edu>
Accept-Language: de-AT, 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-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] Charter update - feedback
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Apr 2012 14:19:26 -0000

Richard Scheffenegger

NetApp
rs@netapp.com
+43 1 3676811 3146 Office (2143 3146 - internal)
+43 676 654 3146 Mobile
www.netapp.com=A0=A0

EURO PLAZA
Geb=E4ude G, Stiege 7, 3.OG
Am Euro Platz 2
A-1120 Wien



> -----Original Message-----
> From: Joe Touch
> Sent: Mittwoch, 25. April 2012 20:19
> To: Anantha Ramaiah (ananth)
> Cc: tcpm IETF list
> Subject: Re: [tcpm] Charter update - feedback
>=20
> > Well, I am afraid that is not the universal opinion, just your opinion.
> > For instance you were opposed on the timestamps modification proposal
> > which others supported.
>=20
> I demonstrated problems with them.
=20

True; However, the timestamp option is one of the few (legacy) options, whe=
re the lack of support (or unsuccessful negotiation) does not threaten an e=
xisting flow; RTTM and thus RTO calculation become less frequent, and there=
 exists a chance of accepting old packets which can corrupt the data (under=
 specific circumstances).

But especially with timestamps, a "soft" negotiation - sending them for 1 R=
TT window worth of packets, and discontinue if the receiver doesn't react -=
 should be rather straight forwards.=20

I also agree, we will have to work out the feasibility of this approach (i.=
e. will certain home routers reboot when they encounter timestamps in a flo=
w where they didn't expect them? Or a NAT / IDS drop all subsequent packets=
, effectively terminating the connection - but wouldn't that rather be brok=
en behavior of a non-conformant middlebox rather then a shortcoming of the =
mechanism? And do we really need to carter for all the implementation bugs =
or broken configurations? ).=20


Coming up with a generic means of reliably negotiating options during a ses=
sion - as a side mechanism of TCP - may be another worthwhile effort.

Of course, some features / functionalities simply don't lend themselves to =
"late" negotiation (i.e. MSS must be known before data packets flow; WS cou=
ld, however, be made dynamic, if carried with each segment - perhaps in som=
e of Tim's "orphaned" bits, with an implicit scaling of 0 if not signaled. =
Which, BTW, should address the issue Matt pointed out w.r.t. window scaling=
 and deadlocks on window reductions.

I think, one key point here is, that whenever a new SYN option is proposed,=
 to also check if this really needs to be a one-time negotiation during the=
 handshake, or if such a mechanism could work with its signaling being unre=
liable during the actual flow. That would not address the core issue (limit=
ed option space during SYN), but perhaps alleviate some of the pressure?

Best regards,
   Richard
=20

From michael.scharf@alcatel-lucent.com  Thu Apr 26 07:49:06 2012
Return-Path: <michael.scharf@alcatel-lucent.com>
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 88F5721F8671 for <tcpm@ietfa.amsl.com>; Thu, 26 Apr 2012 07:49:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.634
X-Spam-Level: 
X-Spam-Status: No, score=-9.634 tagged_above=-999 required=5 tests=[AWL=0.615,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoXTw7SCrFIB for <tcpm@ietfa.amsl.com>; Thu, 26 Apr 2012 07:49:05 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8A17921F8680 for <tcpm@ietf.org>; Thu, 26 Apr 2012 07:49:05 -0700 (PDT)
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 q3QEma1t001602 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 Apr 2012 16:48:59 +0200
Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.54]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 26 Apr 2012 16:48:41 +0200
From: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
To: "Scheffenegger, Richard" <rs@netapp.com>, Joe Touch <touch@isi.edu>, "Anantha Ramaiah (ananth)" <ananth@cisco.com>
Date: Thu, 26 Apr 2012 16:48:40 +0200
Thread-Topic: [tcpm] Charter update - feedback
Thread-Index: Ac0ivLAN4EBcz+fFTwaCR6FvN5Br5QAb1TGAAAJVFwAABQjzAAAARXAAABpxepAAARal4A==
Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E8903583C99@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>
References: <2A886F9088894347A3BE0CC5B7A85F3E8903583C3D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com><20120425144023.GX99904@verdi> <2C0EA634-D035-4C4C-802C-A780B02F3B0E@isi.edu> <1F8E0A684D3FF54680294BCFE57A7DB504FACD77@xmb-sjc-23e.amer.cisco.com> <4F98401A.6050201@isi.edu> <012C3117EDDB3C4781FD802A8C27DD4F1C0883@SACEXCMBX02-PRD.hq.netapp.com>
In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F1C0883@SACEXCMBX02-PRD.hq.netapp.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] Charter update - feedback
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Apr 2012 14:49:06 -0000

> I think, one key point here is, that whenever a new SYN=20
> option is proposed, to also check if this really needs to be=20
> a one-time negotiation during the handshake, or if such a=20
> mechanism could work with its signaling being unreliable=20
> during the actual flow. That would not address the core issue=20
> (limited option space during SYN), but perhaps alleviate some=20
> of the pressure?

For what it is worth, I've posted on the MPTCP list recently that this appr=
oach should be carefully studied when going to StdTrack, for the option tha=
t has to negotiate the use of MPTCP and that thus should be present in ever=
y SYN. In my understanding, MPTCP requires reliable transport of some contr=
ol data in non-SYN segments anyway.

I still try to fully understand the trade-off between postponing of informa=
tion transport to non-SYNs vs. a full option space extension scheme allowin=
g more than 40B in segments. Apparently, there is overlap between both appr=
oaches.

Michael (random researcher)