Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt

Gorry Fairhurst <> Mon, 04 November 2019 17:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 655801208F3; Mon, 4 Nov 2019 09:46:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NZ5VTrVFP-A7; Mon, 4 Nov 2019 09:46:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0FB17120232; Mon, 4 Nov 2019 09:46:35 -0800 (PST)
Received: from GF-MacBook-Pro.local ( []) by (Postfix) with ESMTPSA id 3AAFF1B000A3; Mon, 4 Nov 2019 17:46:28 +0000 (GMT)
Message-ID: <>
Date: Mon, 04 Nov 2019 17:46:26 +0000
From: Gorry Fairhurst <>
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Christian Huitema <>
CC: Mirja Kuehlewind <>, Eric Rescorla <>, tsvwg IETF list <>, "" <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
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: Mon, 04 Nov 2019 17:46:39 -0000

Just focussing on the end...

On 04/11/2019, 16:29, Christian Huitema wrote:
>> [MK] That’s not the intention here. But we also need to consider ways 
>> to interact with the network where this brings benefit to both the 
>> network and the performance of the end-to-end traffic. There are 
>> situation where this is the case. And I don’t think one makes sense 
>> without the other.
> You seem to be arguing for something like "performance enhancing 
> proxies". End-to-end encryption is indeed a way to opt out of such 
> proxying. Measurements so far indicate that opting out has very little 
> impact on actual performance, and that whatever impact there is could 
> be reduced by improvements in end-to-end algorithms. In fact, in many 
> cases, end to end performance is better without such proxies. But the 
> real reason for the opposition to the concept is ossification. 
> Enabling such proxies would quickly ossify the new transports, and a 
> such there is a strong consensus in the end-to-end transport designers 
> to use encryption and prevent interference by such devices.
On PEPs: The current case for many of the network segments I see is that 
QUIC is quite good, but it is considerably worse (currently) than a PEP 
using Split-TCP. That's not to say it can't improve - but that's not 
true yet. However: It's curious that people keep going back to PEPs, 
because network devices that change the transport header were 
specifically out-of-scope for this ID!
> This does not mean that network level deployment have no role in the 
> future. I could see for example tunnels deployed that use FEC or local 
> retransmission to mask the poor performance of a particular subnet. Or 
> I could see end-to-end devices opting into some kinds of application 
> level caching services in order to improve performance. But the draft 
> should be clear: transport protocols do not have to enable 
> interference with the transport bits.
There are also many operators - e.g., enterprise who rely on the methods 
currently mentioned in this draft. In this case, they also actually *do* 
care about the performance of the networks they operate. They also do 
care about the topics, which matters most depends on which organisation.
> My take is that this draft should not be published as is. It should be 
> rewritten to actually reflect the consensus of the transport area, 
> which has to reflect in particular the work in the QUIC working group.
I suspect the information you wish to see about QUIC's design is 
actually available. I'm not sure documenting QUIC is helpful here, if 
the QUIC WG wants to so that, can't it be added to the manageability draft?

I dispute the claim that the entire transport area has the same 
priorities as that voiced at the QUIC WG. I think this discussion needs 
to look outside the QUIC working group and examine other transports and 
WGs. As far as I know the RTP people are still doing specs in the IETF, 
as are various other transport working groups. Also, this draft has been 
presented at OPsec, and has contributors from other areas outside 

My assertion is that *current* practice is using transport header 
information & header authentication/encryption is becoming common, let's 
set out what the current facts are. I'm also going to oppose documenting 
new ideas for how we can go forward - as Spencer insisted when this was 
chartered: Proposing new methods belong in a different draft - paraphrased.