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 >
- [tsvwg] Comments on draft-ietf-tsvwg-transport-en… Eric Rescorla
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Bernard Aboba
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Tom Herbert
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Martin Thomson
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Mirja Kuehlewind
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Eric Rescorla
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Mirja Kuehlewind
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Kathleen Moriarty
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Tom Herbert
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Christian Huitema
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Christian Huitema
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Bernard Aboba
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Gorry Fairhurst
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Gorry Fairhurst
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Tom Herbert
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Bernard Aboba
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Gorry Fairhurst
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Tom Herbert
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Martin Thomson
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Tom Herbert
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Eric Rescorla
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Gorry Fairhurst
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Eric Rescorla
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Joe Touch
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… David Schinazi
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Martin Thomson
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Mirja Kuehlewind
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Frode Kileng
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Peter Gutmann
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Colin Perkins
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Stephen Farrell
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… David Schinazi
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Martin Thomson
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Peter Gutmann
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Tom Herbert
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Colin Perkins
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… David Schinazi
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Bernard Aboba
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Gorry Fairhurst
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Phillip Hallam-Baker
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Phillip Hallam-Baker
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Peter Gutmann
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Kathleen Moriarty
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Eric Rescorla
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Tom Herbert
- Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-t… Peter Gutmann