Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-13.txt

[Joseph Touch <[e-mail]>]

> On Jun 20, 2021, at 10:20 AM, Jonathan Morton <[e-mail]> wrote:
> 
>> On 20 Jun, 2021, at 8:12 pm, Paul Vixie <[e-mail]> wrote:
>> 
>>> Note that TCP bursts up to 10 packets right now anyway,
>>> so I don???t see why UDP fragments couldn???t do the same.
>> 
>> if tcp sends more than three before it has any estimate of the congestion
>> window, then i withdraw my suggestion of "3". however, i ask that some
>> guidance be offered about not transmitting fragments back to back, if the
>> number is larger than "2". and i do hope the number will be larger than "2",
>> due to page/MTU sizes.
> 
> I think a crucial point here is that TCP only sends as much data as the receiver has positively indicated as it is ready to accept (ie. the rwnd), *regardless* of congestion control considerations.  It's entirely feasible to have a TCP receiver that can only handle 4KB outstanding at a time, and support for that was baked into TCP from the beginning.
> 
> The fragmentation handling is analogous to that, but due to the nature of UDP, the sender might not have information about the receiver's capabilities at send time.  So the question is about how much data and what complexity of fragmentation the sender may assume the receiver has a-priori.  I would suggest that this assumption should be conservative due to the interoperability principle.

Only UDP receivers capable of options would be doing reassembly anyway.

If we bake in “min of 10”, then that’s what the receiver would do if it implemented UDP options.

So we’re deciding that right now.

Joe