Re: [Taps] MTU / equivalent at the transport layer

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
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps