RE: Treatment of ICMP for PMTU

[Lucas Pardue <[e-mail]>]

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]<mailto:[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