Re: [QUIC] Does charter-ietf-quic-00-04 need to be on this week's telechat agenda?

[joel jaeggli <[e-mail]>]

On 9/14/16 9:42 AM, Spencer Dawkins at IETF wrote:
> Hi, Lars,
>
> On Wed, Sep 14, 2016 at 11:24 AM, Eggert, Lars <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Quick question on this sentence:
>     > The QUIC protocol need not be defined to
>     > enable each of these abilities in the same way they are
>     presently enabled for
>     > TCP, but the working group must consider the tradeoffs between
>     manageability and
>     > other goals.
>     I can understand "need not be defined in the same way" to mean
>     "need not be defined *at all*" or "need not be defined in the same
>     way *but* need to be defined".
>
>     Is the intent here the latter, i.e., are we requiring QUIC to
>     support all management abilities currently possible with TCP (of
>     which the charter text only hints at a few)?
>
>
> I'd bet that coming up with a complete list of what people do today
> would be a challenge, all by itself.
>  
>
>     If the intent is the former, it would be good to make it explicit
>     that the group may decide to not support some currently possible
>     management abilities.
>
>
> I read "must consider the tradeoffs" to not require that all
> management abilities currently possible be supported (if that's not
> true, there is no tradeoff to consider, right)?
>
I think these are considerations not requirements. I'm unconvinced that
manageability considerations are trade-offs anymore than responsiveness
to congestion is a trade-off with being first in line.
> But that wasn't clear to you. Can you propose text?
>  
>
>     In any case, the text should talk about what's enabled for *TLS
>     over TCP*, because we surely don't want to require QUIC to support
>     DPI-based abilities that are possible with unencrypted TCP?
>
As far as I'm concerned unecrypted tcp shouldn't really be a thing that
exists outside the confines of relatively narrow use cases. the cases
where it is generally appropriate for "web traffic" are  effectively
nonexistent.
> You're on to something here, but trying to make that distinction
> during External Review seems to me, to be falling down the rat-hole of
> people doing DPI with unencrypted TCP who can't do DPI when endpoints
> turn on TLS, or switch to SCTP/DTLS/UDP as in WebRTC, or end up with
> opportunistic encryption as in TCPINC, or ... you see what I mean. See
> https://datatracker.ietf.org/doc/draft-nrooney-marnew-report/ for the
> two-day version ...
>
> I'd be comfortable with "in the same way they are presently enabled"
> dropping the mention of TCP, which might sidestep that particular
> rat-hole. 
>
> And to be blunt, we haven't come up with a good response to the
> concerns GSMA expressed at the MaRNEW workshop, and I think we should
> try harder, but I really don't want to import a PLUS discussion into
> QUIC charter review.
>
> But please let me know what you think.
>
> Spencer