Re: [QUIC] Network Path Requirements for QUIC

[Brian Trammell <[e-mail]>]

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

Cheers,

Brian