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

[Gorry Fairhurst <[e-mail]>]

On 13/12/2016 09:13, Michael Welzl wrote:
> Hi,
>
> This direction definitely makes sense to me, too. I see some tension here, though - on the one hand, Joe is (as usual) arguing "cleanliness", i.e. keep layering right. On the other hand, applications tend to want to know a message size that doesn't get fragmented along an IPv4 path (as identified by the authors of draft-trammell-post-sockets and draft-mcquistin-taps-low-latency-services).
> Raising the abstraction level is fine, but I think Joe's suggestion below misses something.
>
> In an earlier email, Joe wrote about these two sizes:
>
> ***
> 1) the size of the message that CAN be delivered at all
>
> 2) the size of the message that can be delivered without network-layer
> fragmentation
> ***
> and stated that 2) should not be exposed.
>
> So, in the proposal below, "largest transmission size" is 1) from above, and sending it would fail if it's bigger than 2) above AND "native transmission desired" is set to TRUE. So this is how the application would then do its own form of PMTUD.
>
> Given that we don't know which protocol we're running over, probing strategies that involve common MTU sizes (like using the table in section 7.1 of RFC1191) can't work. So it's not the world's most efficient PMTUD that applications will be using, to eventually find the value of 2).
> A protocol like SCTP is even going to do PMTUD on its own, so it could provide a number for 2), which would have less overhead than requiring applications to do their own PMTUD.  =>   If we have to "go dirty" anyway, which we already do by exposing the binary "native transmission desired", why not offer the value of 2) as well?
> In other words: how is this boolean better than offering 2) ?
>
> Cheers,
> Michael
>
>
>
>> On 12 Dec 2016, at 21:53, Gorry (erg)<[e-mail]>  wrote:
>>
>> This is fine - it looks a like what I pointed to in the DCCP spec. But specifically,  I agree you don't need the DF flag visible - if you have a way to convey the info needed to set the flag at the transport (and anything else appropriate -as you note). I am all in favour of such appropriate abstraction.
>>
>> Gorry
>>
>>> On 12 Dec 2016, at 19:09, Joe Touch<[e-mail]>  wrote:
>>>
>>>> On 12/12/2016 10:58 AM, Gorry Fairhurst wrote:
>>>>> IMO, the app should never need to play with DF. It needs to know what it
>>>>> thinks the transport can deliver - which might include transport
>>>>> frag/reassembly and network frag/reassembly.
>>>> How does the App handle probes for path MTU then in UDP?
>>>>
>>>> Gorry
>>> I think there needs to be two parts to the API:
>>>
>>> - largest transmission size
>>> - native transmission desired (true/false)
>>>
>>> If the app says "YES" to native transmission size, then that would suggest that UDP would do *nothing* and pass that same kind of flag down to IP, where IP would not only set DF=1, but also not source fragment.
>>>
>>> I.e., I don't think it's the app's job to know how to explicitly control a mechanism two layers down, and DF isn't really what you want anyway. DF isn't the same as "don't source fragment".
>>>
>>> Joe
>>> _______________________________________________
>>> Taps mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/taps
> _______________________________________________
> Taps mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/taps
So I'd like to return to RFCs that have been through part of this 
discussion before,

(1) I think we need a parameter returned to the App that is equivalent 
to Maximum Packet Size, MPS, in DCCP (RFC4340). It is useful to know how 
many bytes the app can send with reasonable chance of unfragmented delivery.

(2) It's helpful for Apps to be able to retrieve the upper size allowed 
with potential fragmentation - that could be useful in determinine probe 
sizes for an application.  Apps should know the hard limt, In DCCP this 
is 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 permitted for 
the local Interface MTU. This limit lets the App also take into 
consideration other size constraints in the stack below the API.

(3) Apps need to be allowed to fragment datagrams more than MPS - This 
is not expected as the default, the stack needs to be told.

(4) Apps need to be allowed to not allow datagram fragmentation - The 
stack needs to be told. You could do this by using the DF semantics 
(i.e., don't source fragment a DF-marked packet). Thinking more, this 
seems the easiest.

Sorry, if this goes over what I said before, but I think we should first 
explore the approaches that have already been put forward in RFCs 
(alebit these were not RFCs about UDP).

Gorry