Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)

Bob Briscoe <ietf@bobbriscoe.net> Mon, 16 March 2020 08:47 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2253A213C for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 01:47:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9luGKuL1GGCw for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 01:47:36 -0700 (PDT)
Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C4D53A2137 for <tsvwg@ietf.org>; Mon, 16 Mar 2020 01:47:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=e6akXxEy98BmRBWhsEBAUUi/40n3pdA4PopXC8ah3sE=; b=879+sPq6uxejQXRvL7L03woaQ IVXvp1OsbyvtImI1A93TiKXSftX2UuTsi2NQQ6vHKoe6hPZZ/rwkOugp3YefWiJcr/7+VZKwCme1t Xqrr65UVqHxH0b0G58rIGMvTA1QMkYUnyW7ewFUprAqAmVvoakAxnNXE9h5Knuf3gWxNSZ0rsDmhS GhWiMH0GOFLISwuvVNOXfYa6gIm7EZDjWDx0eWO9gRwER7xRDYqq1KBTwdVYZhLjqROciRDYxivuI f7VPfL3P+e1lnFB2abs0nZrsVIueLFRgk2C9mawOeYTcdgTekas4I/GXYW6nFUbeG/jTU9EauUhsI gqqi6dKfQ==;
Received: from host-79-78-166-168.static.as9105.net ([79.78.166.168]:58544 helo=[192.168.2.5]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <ietf@bobbriscoe.net>) id 1jDlPJ-0068oA-SC; Mon, 16 Mar 2020 08:47:34 +0000
To: Joseph Touch <touch@strayalpha.com>
Cc: Sebastian Moeller <moeller0@gmx.de>, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <CE03DB3D7B45C245BCA0D24327794936306F8925@MX307CL04.corp.emc.com> <2873ab79-19ad-0541-e3a4-d1d28dbc7ba0@bobbriscoe.net> <B6D58310-41E0-4172-B555-D28E7926A0B5@gmail.com> <3ee6e427-9dc9-e885-21a9-df9e35d99006@bobbriscoe.net> <C1696430-D2D2-48BB-AB17-EFB77EE474DE@gmail.com> <5d8f11f3-9def-14b1-4923-4eb02caf51eb@bobbriscoe.net> <50B14177-EB29-4273-839C-D22CCC47511E@gmail.com> <4f66ba3e-9eed-03cd-7f45-a1d7d10ec697@bobbriscoe.net> <FF777393-47B2-4B53-AD41-5883B2D67CC5@gmail.com> <264398ad-59eb-7cfd-0276-35ae0f0120a5@bobbriscoe.net> <44EB050C-C35C-47A0-BC78-3EEDB683B507@gmail.com> <c802dddc-8a55-47ea-9976-06771d39c952@bobbriscoe.net> <B3A657D0-EA9D-45EC-8003-21D158F83E06@gmx.de> <ea8fd9d7-82bc-7da0-a08d-31a2d46abe36@bobbriscoe.net> <D0036DCD-424F-46B0-819B-D9E60828CB50@gmx.de> <8acc44d5-d003-2a92-460e-81f31a26cc9b@bobbriscoe.net> <83D1EDCB-068A-4C3C-AB25-62CA11F30E26@strayalpha.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <8ed283a3-3f97-f76e-824c-a0cd727cc39e@bobbriscoe.net>
Date: Mon, 16 Mar 2020 08:47:33 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <83D1EDCB-068A-4C3C-AB25-62CA11F30E26@strayalpha.com>
Content-Type: multipart/alternative; boundary="------------DC10007E661D743F9FD5623F"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/xGjU5xEZ7O47PcSbFCnp1a7Ljdg>
Subject: Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Mar 2020 08:47:38 -0000

Joe,

On 15/03/2020 19:53, Joseph Touch wrote:
>
>> [BB] I should add that PLPMTUD and clamping the max packet size 
>> complement each other.
>
> Except that PLPMTUD works over authenticated or encrypted transport 
> headers and clamping does not.
>
> Clamping could be useful if the information were in an IP header that 
> could be ignored by routers that don’t care (e.g, by not slowing them 
> down, as IP options do).

[BB] I think I see what the terminology problem is here.

I was using the term MSS clamping from this measurement study by Gorry's 
group:
https://iain.learmonth.me/stuff/pubs/UsableMTU2018.pdf
but it uses the same term whether networks do the clamping or 
end-systems do. In my sentence that you've quoted, I was using it to 
mean the sender limiting the size of the IP payload to a lower value 
than could have actually traversed the path. Sorry for not making that 
clear.

Also, in case it wasn't clear, when I said clamping and PLPMTUD 
complement each other, I meant the sender initially clamping the payload 
size, then subsequently using PLPMTUD and removing its clamp to use a 
larger, more efficient packet size instead.



Bob

>
> Joe

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/