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

> On 13 Dec 2016, at 11:05, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> 
> 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)<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
>> _______________________________________________
>> Taps mailing list
>> Taps@ietf.org
>> 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.

I agree; that seems to be what I ended up proposing above.

> (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.

Agreed; I think that was Joe's item 1) ("the size of the message that CAN be delivered at all").

> (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.

These two are hard to parse, making me wonder if they mean what was intended. E.g. for (3): applications are always allowed to fragment their data as they wish, right?  Did you mean to say "Apps need to be allowed to allow to fragment datagrams more than MPS" ?  :-)   I think so...

> 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).

Makes perfect sense to me. Anyway it seems (if I parse them right) that (3) and (4) are just Joe's "native transmission desired" boolean.

So in conclusion, IIUC, this is just a way of saying that:
your item 1: you (as I) also think we should have a "Maximum Packet Size" type thing in addition to what Joe said,
your items 2, 3 and 4: you (as I) agree to offer the other things that Joe also thinks should be offered

Right?

Cheers,
Michael