search

DavidSchinazi / draft-cms-masque-connect-ip

Other
2 stars 1 forks source link

Work what to say about MTU #5

Open martinthomson opened 3 years ago

martinthomson commented 3 years ago

This isn't especially simple. The QUIC-side MTU might change. The QUIC-side MTU is likely smaller than the MTU for the unencapsulated IP packets.

bemasc commented 3 years ago

More fun:

Doing this right seems to require client and server to know the path MTU via intermediaries, treating the end-to-end connection as a single IP hop. The obvious solution is an MTU Header that is clamped by intermediaries ... but that still wouldn't handle mobility. The client and server could reserve an H3 Datagram flow for PMTUD ... that should work, but it sounds slow, complicated, and wasteful.

achernya commented 3 years ago

As a starting point, we could set the inner MTU to 1280 (this is probably over-conservative and we could go higher) and figure out a more robust mechanism to do PMTUD later / in extensions.

DavidSchinazi commented 3 years ago

I definitely agree that reliably figuring out the MTU is a hard problem to solve. I'll note that per-hop MTU has been broken on the Internet for quite a while, since a lot of networks drop or don't send ICMP. Modern protocols have switched to using DPLPMTUD which works end-to-end (see RFC 8899). This means that the world won't end if we don't have a robust mechanism to communicate MTU in CONNECT-IP.

gloinul commented 3 years ago

David I would disagree with that MTU is not relevant to have a good understanding of. However, my conclusion is that it is a common problem for HTTP datagram as functionality. Becasue if the endpoint dont know it one forces them to send them as CAPSULES over the reliable stream, causing HOL, and potential reordering between packets below the MTU and those oversize.

So I think a solution should be defined for how to determine the HTTP datagram MTU between MASQUE client and MASQUE server which with HTTP intermediaries can utilize multiple HTTP connections with different MTU values. Then it is a question of how what additional things CONNECT-IP implementors can do to improve convergence. For example a MASQUE server could actually create ICMP Packet too big (PTB) messages towards the external sender to speed up its convergance, especially over IPv6. And this is one case where ICMPv6 messages are likely to make it back as it is the a endpoint that anyway will send packets with this source address.

So saying that nothing needs to be done is in my opinion a bad answer as it is a question of how the tunneled path will appear.

For the HTTP Datagram MTU discussion I have sent an email to MASQUE WG mailing list to discuss it: https://mailarchive.ietf.org/arch/msg/masque/_fiWFDqS4UDKECR_cQW4bswhUkY/

achernya commented 3 years ago

Magnus, I don't think anyone is saying MTU is not relevant / not something we don't have a good understanding of.

Regarding your examples (MASQUE server could actually create ICMP Packet too big messages), our implementation in QBONE today in fact does synthesize the appropriate ICMP messages. We definitely need an answer, but determining where that answer goes and how it's structured is actually somewhat involved.

gloinul commented 3 years ago

@achernya if we at least are agreeing on that MTU is relevant then that is good. I didn't get that impression from David's comment above.

When it comes to Connect-IP I think in regards to what is needed is that both CONNECT-IP and HTTP Datagram needs text and functionality.

I think HTTP Datagram needs functionality for how to determine what is the supported DATAGRAM MTU between the HTTP endpoints. This enables the HTTP Datagram using application to decide on how it uses the HTTP datagram and if it will need to use reliable stream encapsulation of some data or if it HTTP Datagram provides a sufficient support in all cases.

Connect-IP spec will clearly need to provide specification or recommendations regarding the service MTU. I have seen several different aspects that needs to be covered:

Anything additional that is related to the IP tunneling service that we are defining for MASQUE?

achernya commented 3 years ago

HTTP Datagram and CONNECT-IP have, in my opinion, have slightly different requirements. Datagram could be implemented by allowing the QUIC APIs to natively fragment the datagrams, whereas for CONNECT-IP I think such fragmentation is explicitly undesirable. Also, it is possible, but unlikely, that in CONNECT-IP the end-to-end MTU will be less than the datagram MTU.

DavidSchinazi commented 3 years ago

Responding to @gloinul's comment above, I never said that MTU was not relevant. I said that it's a hard problem to solve and that solving it at this layer isn't the only path forward. In my experience, keeping notions of MTU higher up the protocol stack works better in practice, which is why I'm wondering what solving this at the CONNECT-IP layer provides in a world where DPLPMTUD exists.

gloinul commented 3 years ago

Sorry, for misinterpreting.

The reasons we might be required to solve the MTU at Connect-IP level is to ensure that CONNECT-IP actually supports the requirements of the IPv6 specification. In some usages the MASQUE tunnel will be the link layer for an interface. A link layer that is required to provide at least a 1280 IP MTU, or provide a fragmentation mechanism (which using reliable stream CAPUSULE for the packet can provide) and also enable the interface to have a correct understanding of its link layers MTU.

DavidSchinazi commented 3 years ago

I see what you're saying. We could add a note to CONNECT-IP stating that if the PMTU of the outer QUIC connection becomes too low, CONNECT-IP can use capsules to encode HTTP Datagrams that carry IP packets to allow them to get across the network at a high performance cost.