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

[Mirja Kuehlewind <[e-mail]>]

See below.

> Am 05.11.2019 um 21:19 schrieb 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.

What I’m hearing is that 2-3 people think this is not aligned but don’t actually say why exactly they think that while there are a bunch of people supporting this document ( throughout the whole wg process).

Mirja

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