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

[Mirja Kuehlewind <[e-mail]>]

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. 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.


    >
    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