Re: Treatment of ICMP for PMTU

["Gorry (erg)" <[e-mail]>]

> On 28 Jun 2018, at 12:07, Mikkel Fahnøe Jørgensen <[e-mail]> wrote:
> 
> 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 
>> 

And when you say:
“
for ICMP w/ on-path proof, I think it makes sense to allow a reduction in PMTU up to 1280.”  
- I agree the values could be trusted.
- what then also happens when PTB message indicated less than 1280, does the sender close the connection? Or ignore the message and wait to see if there is a timeout?

Gorry