> On 13 Dec 2016, at 11:05, Gorry Fairhurst <[email protected]> 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)<[email protected]> 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<[email protected]> 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
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/taps
>> _______________________________________________
>> Taps mailing list
>> [email protected]
>> 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
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
