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

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
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
>