Re: [tsvwg] transport-encrypt-14 review, pt 1

Gorry Fairhurst <> Fri, 10 April 2020 07:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ECBFE3A187E; Fri, 10 Apr 2020 00:45:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wWiprSEk5piI; Fri, 10 Apr 2020 00:45:30 -0700 (PDT)
Received: from ( [IPv6:2001:630:42:150::2]) by (Postfix) with ESMTP id 61DAF3A1921; Fri, 10 Apr 2020 00:45:30 -0700 (PDT)
Received: from GF-MacBook-Pro.local ( []) by (Postfix) with ESMTPSA id EA9A11B001CF; Fri, 10 Apr 2020 08:09:11 +0100 (BST)
To: Joseph Touch <>, Martin Duke <>
Cc:, tsvwg <>
References: <> <>
From: Gorry Fairhurst <>
Message-ID: <>
Date: Fri, 10 Apr 2020 08:09:11 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------BA4C09DF153D57A3A29473B5"
Content-Language: en-GB
Archived-At: <>
Subject: Re: [tsvwg] transport-encrypt-14 review, pt 1
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Apr 2020 07:45:36 -0000

On 09/04/2020 21:20, Joseph Touch wrote:
>> On Apr 9, 2020, at 12:44 PM, Martin Duke < 
>> <>> wrote:
>> - Conversely, middlebox interference with headers does enable 
>> performance enhancing proxies for extraordinary link types like 
>> satellite.
> Those are only “extraordinary” only in the “been around for 50 years 
> in the Arpanet/Internet”. That understanding goes back as far as RFC 
> 346 and IEN 8.
> Additionally, ground nets often experience similar BW delay products, 
> which can be the dominant driver.
> There are known ways to help TCP over such links that don’t involve 
> these sort of steps, documented as far back as RFC 2488, some of which 
> are now being incorporated (faster window growth and recovery, ala Hybla).
> I.e., just because a mechanism CAN rely on these headers doesn’t mean 
> that’s the only - or even safe - way to do so.
> Joe

I'm with Joe there are MANY ways that devices sitting in the network 
*do* presently change TCP headers. This is not at all restricted to 
specific technologies such as Satellite. TCP ACK 
filtering/decimation/etc is commonly used on a variety of paths to 
reduce return link traffic in WiFi, Docsis, LTE, etc. PEPs have split 
TCP in many ways where delay and/or loss is important, devices that 
track or change rwnd are out there, as are other devices that have 
modified other things for better or worese. However we already have 
RFC3135, RFC3449, a variety of header compression specs, and more 
recently RFC8404. All of which delve into these topics.

In an earlier thread, I motivated restoring the focus on methods that 
observe headers and do not "manipulate" these. It's true that when the 
WG decided to add the "ossification" examples at the start iof the 
document, that these were nearly all related to changing headers, but 
still I think the focus of the remainder should be on methods that do 
not change headers - That also is the set of methods that could be 
compatible with end-to-end authentication.