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

[Joe Touch <[e-mail]>]

On 12/9/2016 12:14 PM, Michael Tuexen wrote:
>> On 7 Dec 2016, at 15:54, Michael Welzl <[e-mail]> 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.
> In the API description in https://tools.ietf.org/html/rfc6458 the MTU exposed to the application
> via the API is "the number of bytes available in an SCTP packet for chunks." I think this is the best
> we can do at that interface...
AFAICT, that's 1) in my list, e.g., the largest chunk that SCTP can send
without having SCTP coordinate frag/reassembly. That doesn't itself
indicate whether it's SCTP doing the rest or the network layer.

Joe