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

[Michael Welzl <[e-mail]>]

> On 09 Dec 2016, at 09:46, Gorry Fairhurst <[e-mail]> wrote:
> 
> On 09/12/2016 08:09, Michael Welzl wrote:
>>> On 07 Dec 2016, at 20:29, Joe Touch<[e-mail]>  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

I agree with all that.
But combining this with the wish to have message dependencies, a wish that is in both draft-trammell-post-sockets and draft-mcquistin-taps-low-latency-services, yet also not supported by any of the already defined transport protocols, it gets clear that we must define some extra functionality for a TAPS system, when we get to charter item 3.

These things can be achieved by only changing the implementation of transports to locally provide some more of its internal information to a system on top; they don't change anything on the wire...

Cheers,
Michael