> On 7 Dec 2016, at 15:54, Michael Welzl <mich...@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 _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
