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

Bernard Aboba <bernard.aboba@gmail.com> Mon, 04 November 2019 19:10 UTC

Return-Path: <bernard.aboba@gmail.com>
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 9F3C3120816; Mon, 4 Nov 2019 11:10:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 jHToFy_Ld7RB; Mon, 4 Nov 2019 11:10:15 -0800 (PST)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B40E6120114; Mon, 4 Nov 2019 11:10:13 -0800 (PST)
Received: by mail-lf1-x12a.google.com with SMTP id f5so13120140lfp.1; Mon, 04 Nov 2019 11:10:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jMTJuPKj27tohTQCbiGlAKfO8CjPHeUoPwytq2veJMY=; b=YiQu5RxaPgJf0F6B4jW+b3r8/bZC3jANfGTm2uNL9fG9o8PRzSMiavKKicFG0g0Icy DTI3u88b6qk6mZ8rBtC5gMXyZHVO8FBFgOGPOziGCqeB9rvK6VLA/3+Zy1+h6+DS9dl1 B4I0PIsT6KOpCd1u4Q6wEUOqk5L209kQDYrL4bydJWiErJdVbhA5Y1wjn3quUQIQSUXz 87eZ9KqJy6c85kZKI6xHfcYhwODvxxbX6CAv6HOhS61Wx9OJlyNfFrqrF91GyNJODgkU LcFSDxP68HDgu+uwFaguM3ZRIdbwbtyCFiUbe1q0yZgc2vHb1zeNRNHpl8OV1VSEA9VK GtOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jMTJuPKj27tohTQCbiGlAKfO8CjPHeUoPwytq2veJMY=; b=nuRRG9w9AQHEQUXZxoPUvC9TOMGh1YF6c2Uf4g9+4AlZY3WTOd6uoWWWYjbRovfAwr wpVQnPiEn6xeqqVHqeb0ftNk90ogSZuUHn96c3uenJOESlQJJuaopNEwtTTS7G6xSOwB qW+18p2MjiB7VXSLQWiSSyk4CjyATtCw4CXCRjmyLQ37pto0hXiCLi0/ng2of0o9gRRx lyLib1QUabGboF5pZOL7jvkJrj+TKL2idD/P7wjpHwrlMoKgt3kIggxhUejzNpGZiBce KJMRROanTH9nB15kJ/o0CPeuajZVlQzSon7n3MJVEJKdFjqi5gbTH88AnaKpRDq6838k sCbA==
X-Gm-Message-State: APjAAAUgOUktaImFeLkp/HN+XEOFt7SGm0E3bExLiEYchldDHhQAG6To pYk2CIKuGYMt+sA6XLHZnw7qmoA0gPXqEBzSyIe99+Mk
X-Google-Smtp-Source: APXvYqya9WhivT2Duu8EakwXIY46124mInD7C7BZau7f47ET/FkEyIySec8IpGwxzq59WJ7dnAV9vpygk/w8NPR/7fE=
X-Received: by 2002:ac2:5210:: with SMTP id a16mr18133325lfl.156.1572894611632; Mon, 04 Nov 2019 11:10:11 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <5DC063F2.8040502@erg.abdn.ac.uk>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Mon, 4 Nov 2019 11:10:00 -0800
Message-ID: <CAOW+2dvswQFbibg3R_Wh4uyb56sRAeOAEET_SCw1SXhMWQXXTg@mail.gmail.com>
To: gorry@erg.abdn.ac.uk
Cc: Christian Huitema <huitema@huitema.net>, "saag@ietf.org" <saag@ietf.org>, Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>, tsvwg IETF list <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000098774505968a10dc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/UpYKC9OR9lun9UmRIeEPSYgPVfs>
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:10:25 -0000

Gorry said:

"I'm also going to oppose documenting new ideas for how we can go forward"

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

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



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