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

> On 9 Dec 2016, at 21:23, Joe Touch <touch@isi.edu> wrote:
> 
> 
> 
> On 12/9/2016 12:14 PM, Michael Tuexen wrote:
>>> 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...
> 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
You need to take the DATA or I-DATA chunk header into account...
It is "the number of bytes in the packet for chunks", not "the number
of bytes for the chunk value for DATA (or I-DATA) chunks".
> indicate whether it's SCTP doing the rest or the network layer.
As I said, that is what is exposed to the upper layer via the API.
SCTP itself has procedures to detect the PMTU (of each path).
It does PMTU discovery by interacting with the IP layer...

Best regards
Michael
> 
> Joe
> 
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps