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

[Bernard Aboba <[e-mail]>]

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 <[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.
> >
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag
>