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

[Eric Rescorla <[e-mail]>]

On Mon, Nov 4, 2019 at 10:02 AM Mirja Kuehlewind <
[e-mail]> wrote:

> Hi Christian,
>
> please see two comments below (marked with [MK]).
>
> Mirja
>
> On 04.11.19, 18:46, "Gorry Fairhurst" <[e-mail]> 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.
>
> [MK] This is not what the draft is asking for.
>
>     >
>     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.
>
> [MK] The purpose of this draft is exactly to find and document consensus
> in the transport area and in the IETF. I don't think any individual at this
> points knows what the consensus actually is.


Well, in that case this document shouldn't be being advanced.


This document has support in tsvwg (otherwise it would not have been
> adopted as wg document) and I also don't think there is anything in the
> draft that contradicts any work in the QUIC group.
>

Well, I think what you're hearing is that people think that it is badly
aligned with the consensus of other parts of the IETF.

-Ekr