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

> On 7 Dec 2016, at 15:54, Michael Welzl <michawe@ifi.uio.no> 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...

Best regards
Michael
> 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