Re: [QUIC] Network Path Requirements for QUIC

[Jana Iyengar <[e-mail]>]

On Thu, Jun 16, 2016 at 2:12 AM, Brian Trammell <[e-mail]> wrote:

> hi Jana, all,
>
> (adding [e-mail])
>
> On one point, below:
>
> > On 16 Jun 2016, at 03:41, Jana Iyengar <[e-mail]> wrote:
> >
> > Hi Dan,
> >
> >> draft-wing-quic-network-req tries to up-level its recommendations by
> saying 'we need consent' rather than suggesting how to achieve it.  Consent
> could be achieved in probably 3 or 4 different ways, and we need a
> technique that works with multicast QUIC and with persistent QUIC
> connections.  It's up to WG to agree consent is
> >> necessary, then to agree how to accomplish consent.  We have identified
> other things that impact the network and need discussion in the working
> group (some small, some larger):  Should the network clear its state
> immediately after QUIC public reset, set timer, wait for a little while.
> Is the network's sole identification the QUIC version in the
> client-initiated connection, and can we avoid the network treating that
> specially (which will be good and bad, I am remembering network treatment
> of  IKE's UDP 500 and 4500).  If QUIC endpoint sends or receives many bogus
> QUIC packets, how can network help stop or rate limit those, to defend the
> links and defend other hosts on that network.  If path drops state due to a
> timeout (or crash, or software update, or whatever), how should the
> endpoints learn and how should they react.  Those previous things are
> discussed in the I-D.  In addition, QUIC complicates network diagnostics
> and measurements, as well, which will be added in a later version of the
> I-D.
> >
> > I understand what the draft describes, and as I said, I think this is
> useful when the wg is discussing what is visible in the QUIC header and
> what isn't. The wg can decide whether to care about a particular middlebox
> function or not.
> >
> > That said, I think this may be one of our core disagreements: absent
> agreement on what middlebox functions are essential, it's hard to argue how
> QUIC should solve for them. We saw a very similar conversation play out in
> MPTCP. There were many questions about how legacy middleboxes would treat
> MPTCP options and modifications to TCP header bits. The problem was that
> there were too many boogeymen middleboxes out there, and it was usually
> anybody's guess how important any one particular behavior was. There was
> small-scale measurement work done that helped direct the conversation, but
> this is tricky territory -- tricky largely because of the lack of
> substantial data about particular middlebox behaviors and their prevalence
> and importance.
> >
> > In terms of how these apply to QUIC, we have data from the current
> deployment of QUIC, and that can hopefully be brought to bear on the
> decisions in the working group. Beyond that, I think it's all thin ice. We
> can certainly try and get consensus on specific middlebox behaviors as
> important, but that conversation is more general than just QUIC, and since
> your draft is precisely such a list, I'd argue that it probably belongs in
> PLUS, TSVAREA/TSVWG, or INTAREA.
>
> PLUS BoF proponent hat on: I think there is a point here that might make
> sense to add to the PLUS draft charter that would naturally feed into QUIC:
>
> - Define a view of "essential middlebox functions", and a description of
> the information from endpoints required to drive them.
>
> As you say, part of the problem is there is no agreement on either of
> these questions. A focused discussion here could hopefully come to some
> consensus. QUIC isn't really the place for this IMO, since the answer is
> bigger than one instance of a new protocol over UDP. I'm not sure a general
> INTAREA/TSVAREA activity would have the right focus, and I'm not sure it's
> really in scope for TSVWG.
>
> draft-wing-quic-network-req looks to me (slightly rearranged and with the
> QUIC-specific language stripped out) as a candidate document for this work
> item. It's alsouseful input to the engineering work on a universal shim
> protocol we intend to do in PLUS. (And as a bonus, if both QUIC and PLUS
> are working from a common, defined view of what sort of functions are
> essential, future integration between them won't be complicated by
> differing architectural views).
>

+1.

- jana