FYI, there are two different "largest messages" at the transport layer:
1) the size of the message that CAN be delivered at all 2) the size of the message that can be delivered without network-layer fragmentation (there are no guarantees about link-layer - see ATM or the recent discussion on tunnel MTUs on INTAREA) MTU generally refers to the *link payload*. At that point, transports have to account for network headers, network options, transport headers, and transport options too. See RFC6691. MSS refers to the transport message size AFAICT. It is *sometimes* tuned to MTU-headers but not always. E.g., for IPv6, link MTU is required to be at least 1280, but the src-dst transit MTU is required to be at least 1500. So a transport that wants to match sizes and reduce fragmentation issues would pick 1280-IPh-IPo-TCPh-TCPo, but a transport is supposed to be able to trust that 1500-IPh-IPo-TCPh-TCPo can still get through at least some of the time. Joe On 12/7/2016 6:54 AM, Michael Welzl wrote: > Hi all, > > I have a problem with one particular primitive, or lack of it, in UDP, > UDP-Lite and SCTP. It's something I just don't get. > > Consider this text from draft-fairhurst-taps-transports-usage-udp: > > "GET_INTERFACE_MTU: The GET_INTERFACE_MTU function a network-layer > function that indicates the largest unfragmented IP packet that > may be sent." > > Indeed, this is a network-layer function. It's about the interface, not about > UDP. Does that mean that, to decide how many bytes fit in the payload of a > packet, the programmer needs to know if it's IPv4 or IPv6, with or without > options, and do the calculation? > If so, isn't it extremely odd that UDP doesn't offer a primitive that > provides a more useful number: the available space in its payload, in bytes? > > I also have the same question for SCTP. For TCP, it's obvious that the > application shouldn't bother, but not for UDP or SCTP. > At the last meeting, knowing the MTU was mentioned as one of the needs that > latency-critical protocols have. I understand that - but I didn't include > this primitive in the last version of the usage draft because it is a > network-layer primitive... now I don't know how to approach this. > > Thoughts? Suggestions? > > Cheers, > Michael > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
