Not quoite answering this question, but for DCCP this is clearly also a
transport understanding of the maxmium datagram size, as in RFC 4340:
"A DCCP implementation MUST maintain the maximum packet size (MPS)
allowed for each active DCCP session."
and
"The MPS reported to the application SHOULD be influenced by the size
expected to be required for DCCP headers and options."
Gorry
On 07/12/2016 14:54, Michael Welzl 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.
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
[email protected]
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
