RE: Treatment of ICMP for PMTU

[Mikkel Fahnøe Jørgensen <[e-mail]>]

Hi Lukas, thanks for working on this.

It’s a bit much for me swallow in detail so I can only provide some general
thoughts.

QUIC recently added extension frames that require IANA registry, but there
is an endless supply.
This could be used to define semantics suitable for lossless packets in a
very straightforward manner that may be simpler than Partial Reliability
once that lands because you just add a tunnel header and ship the frame as
if it were a UDP packet without ACK’ing it. There needs to focus on flow
control all the same. That could be tricky.

Now, adding extension random frames for something that aims to be standard
outside of QUIC is probably not optimal, especially considering that
QUIC/v2 is sort of expected to deliver something similar. In fact, this
could be great input for a v2 use case. I imagine there won’t be a one size
suits all partial reliability feature. In part because tunneling doesn’t
even want partial reliability, just unreliability - i.e. not attempt at
ordering what is received, if it is received.

Additionally, the constraint that tunneling should happen not just over
QUIC but QUIC/HTTP adds additional constraints because QUIC/HTTP would not
automatically add an extension frame. It might even not really support
partial reliability in v2 in a way that is well suited for the problem. On
the other hand, QUIC/HTTP seems to be infinitely hackable, so you could
abuse unistreams to create packets - but likely that would sink
unsuspecting end-points not optimized for that.

Now, I don’t know that much about HTTP tunnelling - but - it might be
possible to use QUIC/HTTP as a signalling path and create a separate QUIC
connection for payload with either an extension frame, or a future v2
unreliability feature, or even an official tunnelling frame.

Given that QUIC is encrypted, it becomes harder for middleware to block
non-HTTP, so the question is: why does it need to be over HTTP? If the
answer is that middelware still knows too much - perhaps QUIC should fix
that.

So, I think the best option would probably be to wait for v2 and do some
studies with extension frames meanwhile and possibly play with signalling
via QUIC/HTTP if it must be HTTP.


But all of this just based on intuition and no deep knowledge of tunneling
protocols.

Mikkel


On 6 July 2018 at 17.00.44, Lucas Pardue ([e-mail]) wrote:

Mikkel, Igor,

In case you don't follow HTTPbis: I have published an I-D [1] [2] that
surveys options for tunneling of UDP and IP. It presents some options for
framing but it is not exhaustive. There's a slot on the agenda to discuss
things there.

I added a HoL section in response to your earlier comments. I'm looking for
input on whether such tunneling should depend on partial reliability in
QUIC (bearing in mind that there may be some desire to support TCP-based
HTTP).

Kind regards
Lucas

[1]
https://tools.ietf.org/html/draft-pardue-httpbis-http-network-tunnelling-00
[2] https://lists.w3.org/Archives/Public/ietf-http-wg/2018JulSep/0025.html

------------------------------
*From:* QUIC [[e-mail]] on behalf of Mikkel Fahnøe Jørgensen [
[e-mail]]
*Sent:* 28 June 2018 11:07
*To:* Lucas Pardue; IETF QUIC WG; Martin Duke; Lubashev, Igor
*Subject:* RE: Treatment of ICMP for PMTU

I think QUIC needs a tunnel extension frame.

On 28 June 2018 at 11.25.20, Lucas Pardue ([e-mail]) wrote:

Igor Lubashev wrote:

>I think I see what you are talking about.
>
>At least the way it is specced in H2 and HTTP/QUIC, CONNECT proxies forward
>data streams, not packets. Hence, MTU concept on a tunnel-stream is
>meaningless. The text says it explicitly: "Note that the size and number
of TCP
>segments is not guaranteed to map predictably to the size and number of
>HTTP DATA or QUIC STREAM frames." From the client's perspective there is
>only one PMTU that is relevant -- the one to the proxy. The proxy will keep
>tracks of the PMTUs to the CONNECT endpoints itself and will generate TCP
>segments accordingly.

Right, that's how I was seeing it.

>Trying to design a CONNECT-like method to proxy an entire QUIC connection
>over a single QUIC stream would create HOLB for QUIC packets to and from
>the proxy. Some sort of a partially reliable QUIC stream could help here.

Both you and Mikkel have identified HOL as something that needs more
thought. Thanks. Mikkel's view is a little more extreme, to paraphrase "HOL
is enough to make QUIC not QUIC". I've taken the view that it may be
desirable to tunnel QUIC over TLS/TCP too (perhaps using HTTP/2 frames), so
I view HOL avoidance as an optimisation rather than a requirement. Partial
reliability (of streams, or of some new frame type) could help solve that
puzzle. Now I think about it, a complimentary mitigation could be to
reserve a set of tunnel-streams to provide some basic multiplexing.
However, the complexity of that might not be worth it.

>This proxying scheme would require an extension to CONNECT to open a
>UDP/IP tunnel instead of a TCP/IP tunnel. That extension would also mandate
>that HTTP/QUIC DATA frame corresponds to a UDP frame. I suspect that it
>would be a very good idea for such a proxy to add a new frame for providing
>ICMP-like explicit PMTU feedback to the sender (why leave the sender
>guessing and probing, if the PMTU is already known to the proxy?).

This is good feedback. Thanks!

Kind regards
Lucas