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

Gorry Fairhurst <> Mon, 04 November 2019 19:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA91012092D for <>; Mon, 4 Nov 2019 11:39:20 -0800 (PST)
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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nuk_bF9fdHc0 for <>; Mon, 4 Nov 2019 11:39:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A7D0E12083C for <>; Mon, 4 Nov 2019 11:39:08 -0800 (PST)
Received: from GF-MacBook-Pro.local ( []) by (Postfix) with ESMTPSA id A7E911B00223 for <>; Mon, 4 Nov 2019 19:39:03 +0000 (GMT)
Message-ID: <>
Date: Mon, 04 Nov 2019 19:39:03 +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
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 19:39:24 -0000

See in-line,

On 04/11/2019, 19:10, Bernard Aboba wrote:
> Gorry said:
> "I'm also going to oppose documenting new ideas for how we can go forward"
If there are specs we should have included, and are used, I'd be happy 
as always to see these and discover more.
> [BA] The problem is that the "current practices" described in the 
> document are more representative of where we were 10+ years ago, than 
> where we are today, with Infrastructure as a Service (IAAS), Platform 
> As A Service,  and Application as a Service (AAAS) providers all 
> operating at enormous scale, all measuring performance using "new 
> ideas" (developed largely outside the IETF).
You seem to have shifted a layer above the IETF transport - and yes it's 
important to understand interactions at this level to understand 
QoE.Many of these service will run on TCP?

This ID is specifically about transport performance - and debugging 
transport v network interactions.
> "The RTP people are still in IETF"
> [BA] The way realtime applications performance assessment has been 
> conducted has changed markedly over the last decade, particularly as 
> the world has moved toward the development and deployment of web-based 
> applications (e.g. Electron, React, PWAs, etc.) where performance data 
> is collected by the Application as a Service Provider rather than the 
> network operator (though the two may collaborate).
That may also be common, but many of these seem to be TCP-based 
currently and may transition to QUIC -  are you claiming that all 
operators - enterprises, private networks, small ISPs, large ISP, 
transit, etc all manage using the same tools and only look at apps data? 
That really is not the story I have been hearing.

> On Mon, Nov 4, 2019 at 9:46 AM Gorry Fairhurst < 
> <>> wrote:
>     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
>     transport...
>     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.
>     Gorry
>     _______________________________________________
>     saag mailing list
> <>