Right, I understand this. I said *it could8 use larger headers. So sounds like we are in agremement. That is, if we can't agree on 1400 because protocols have been spec'ed for smaller ones, that is where we are headed. In the opposite direction we wantn to go.
Hence, there is no way to technically fix this. And fragmentation is *not the solution*. It will cause more packet loss and time-out buffers in receivers. But what apps can do, and I know many that do is to send a packet train of MTU sized packets with FEC. So when there is loss, the receiver can build the packets via erasure codes. Dino > On Dec 7, 2021, at 10:42 AM, Tom Herbert <t...@herbertland.com> wrote: > > On Mon, Dec 6, 2021 at 6:17 PM Dino Farinacci <farina...@gmail.com> wrote: >> >>> Dino, >> >> Hey Tom. I should make it clear that I am replying to email in the context >> of "user requirements", that means end user requirements. Hence my comment >> about 1400. >> >>> Definitely at least for a limited domain. For instance, AFAIK Google >>> is using 9K MTUs in their internal networks. Whether the benefits of a >> >> I am well aware of this but this is server to server and isn't related to >> end-user requirements. And note, internal networks don't have an MTU problem >> because they can force 9K MTUs. >> >>> larger MTU scales to the whole Internet is probably still an open >> >> Right. >> >>> question, however QUIC seems to require at least an MTU of 1280 bytes >> >> I have tested QUIC over LISP and when interface MTUs are 1400, you can send >> 1280-byte packets over IPv4 (1280+8+8+20)=1316 and over IPv6 >> (1280+8+8+40)=1336 which keeps the packets <= 1400. So any protocol above IP >> could send more than 1280 (120 bytes more to reach 1400-byte MTUs) with >> plenty of room for tunnels (even nested tunnels to 2 levels). >> >>> so there are some attempts to enforce a baseline MTU for the Internet >>> greater than the specified minimums (at least greater than 64 bytes or >>> 576 bytes for IPv4 MTU minimums. >> >> Yes, and I vote for 1400. Just because I have tested it in many cases over >> many years on a LISP overlay. In cases for data center MTU, I would suggest >> 8900 (9000-100) and be consistent saying we save 100 bytes of packet >> head-room for overlays. >> > > QUIC has already set the de facto standard for minimum MTU on the > Internet as well as the minimum reserved space in the MTU for > extension headers or other overhead. From RFC9000: > > QUIC assumes a minimum IP packet size of at least 1280 bytes. This is > the IPv6 minimum size [IPv6] and is also supported by most modern IPv4 > networks. > > -and- > > Note: This requirement to support a UDP payload of 1200 bytes limits > the space available for IPv6 extension headers to 32 bytes or IPv4 > options to 52 bytes if the path only supports the IPv6 minimum MTU of > 1280 bytes. > >>> Tom >> >> Thanks, >> Dino >> _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area