On 12/9/2016 12:14 PM, Michael Tuexen wrote: >> On 7 Dec 2016, at 15:54, Michael Welzl <[email protected]> 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 _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
