On 09/12/2016 08:09, Michael Welzl wrote:
On 07 Dec 2016, at 20:29, Joe Touch<[email protected]> wrote:
FYI, there are two different "largest messages" at the transport layer:
1) the size of the message that CAN be delivered at all
True... I wasn't thinking of that, but yes.
2) the size of the message that can be delivered without network-layer
fragmentation (there are no guarantees about link-layer - see ATM or the
recent discussion on tunnel MTUs on INTAREA)
MTU generally refers to the *link payload*. At that point, transports
have to account for network headers, network options, transport headers,
and transport options too. See RFC6691.
MSS refers to the transport message size AFAICT. It is *sometimes* tuned
to MTU-headers but not always.
E.g., for IPv6, link MTU is required to be at least 1280, but the
src-dst transit MTU is required to be at least 1500. So a transport that
wants to match sizes and reduce fragmentation issues would pick
1280-IPh-IPo-TCPh-TCPo, but a transport is supposed to be able to trust
that 1500-IPh-IPo-TCPh-TCPo can still get through at least some of the time.
So I'm getting the impression that the answer to my question really is that, to
figure out 2) (which I was concerned with), an application programmer needs to
do the calculation her/himself.
Not a big deal - and maybe some systems offer a function to give you the size
of a message that won't be fragmented.
However: this calculation is transport protocol dependent, which we really
don't want to have in TAPS.
I conclude: a TAPS system must implement a local function to provide this
information, both 1) and 2) above.
Referning back to DCCP as a RFC reference which agrees with this.
I agree with (2) for a datagram transport, similar to MPS in DCCP. If
you are going to allow different transports to be selected by TAPS -
it's hard to know even if the transport below the TAPS API will finally
need to choose to add an option to satisfy the service (e.g., timestamp,
checksum, whatever ) and the size of such an option likely varies
depending on the finally chosen protocol. To me, this suggests it useful
to know how many bytes the app can send with reasonable chance of
unfragmented delivery.
Apps should be allowed to send more if they wish, If an app is doing
datagram path MTU discovery, this may resilt in raising the maximum
unfragmented datagram size.
I'm OK with being able to retrieve the absolute maximum allowed - that
could be useful in determinine probe sizes for an application doing path
MTU discovery. In DCCP there is a hard limt, called the current
congestion control maximum packet size (CCMPS), the largest permitted by
the stack using the current congestion control method. That's bound to
be less than or equal to what is permittd for the local Interface MTU.
Gorry
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
