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

[Gorry Fairhurst <[e-mail]>]

On 05/11/2019, 19:58, Eric Rescorla wrote:
>
>
> On Mon, Nov 4, 2019 at 10:02 AM Mirja Kuehlewind 
> <[e-mail] <mailto:[e-mail]>> 
> wrote:
>
>     Hi Christian,
>
>     please see two comments below (marked with [MK]).
>
>     Mirja
>
>     On 04.11.19, 18:46, "Gorry Fairhurst" <[e-mail]
>     <mailto:[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

Than ks Ekr, but of course, I don't agree on your thoughts. Which is why 
this needs to be carefully considered.

Gorry