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

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) <gorry@erg.abdn.ac.uk> 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 <touch@isi.edu> 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
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
> 