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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Mon, 04 November 2019 19:39 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA91012092D for <tsvwg@ietfa.amsl.com>; Mon, 4 Nov 2019 11:39:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuk_bF9fdHc0 for <tsvwg@ietfa.amsl.com>; Mon, 4 Nov 2019 11:39:09 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id A7D0E12083C for <tsvwg@ietf.org>; Mon, 4 Nov 2019 11:39:08 -0800 (PST)
Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id A7E911B00223 for <tsvwg@ietf.org>; Mon, 4 Nov 2019 19:39:03 +0000 (GMT)
Message-ID: <5DC07E57.1020909@erg.abdn.ac.uk>
Date: Mon, 04 Nov 2019 19:39:03 +0000
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
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
To: tsvwg@ietf.org
References: <CABcZeBPajzuEdw8=M1g1i-TAniJ9O+H5dEMxv8c6N3tD=7mSvw@mail.gmail.com> <CALx6S35bSAa_zq=HsF-3e9qC-vRNFRu6dn+O4ak4Hi+c=Tmz5A@mail.gmail.com> <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com> <CABcZeBPfT=B+fOXAkPuoEQQHAtJrefXSgnjOpPC7-4zC_myRsA@mail.gmail.com> <D36061F0-F872-4054-ACF0-C9A88FCEC572@ericsson.com> <2d3c909f-b21c-3916-1eb9-db6de5c661e3@huitema.net> <5DC063F2.8040502@erg.abdn.ac.uk> <CAOW+2dvswQFbibg3R_Wh4uyb56sRAeOAEET_SCw1SXhMWQXXTg@mail.gmail.com>
In-Reply-To: <CAOW+2dvswQFbibg3R_Wh4uyb56sRAeOAEET_SCw1SXhMWQXXTg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/pXPdy3GGgjPze7uFyAEIsL7TdDY>
Subject: Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=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.

Gorry
>
>
> On Mon, Nov 4, 2019 at 9:46 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk 
> <mailto:gorry@erg.abdn.ac.uk>> 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
>     saag@ietf.org <mailto:saag@ietf.org>
>     https://www.ietf.org/mailman/listinfo/saag
>