Re: [tsvwg] UDP REQ/RES Options - per segment or per datagram

[Joseph Touch <[e-mail]>]

Hi, Mike,

Although I agree with the general principle that we should keep things simple, IMO that’s also on the user. If they want to use any option per-fragment, it’s on them if that over complicates their work. AFACIT, these options are largely opaque at the UDP layer - they don’t authomatically do anything unless it’s defined - as per Gorry’s draft. It’s up to him to decide if there’s a limit to his API and algorithms that use REQ/RES; others can do otherwise.

Again, UDP is all about the U.

Joe

> On Jul 30, 2021, at 5:05 PM, C. M. Heard <[e-mail]> wrote:
> 
> On Wed, Jul 7, 2021 at 9:44 PM Joseph Touch wrote:
> Hi, Mike,
> 
> I’ll try to take this in one shot, but it might be useful to followup in separate threads.
> 
> I am following up in separate threads as suggested. This one is for the REQ/REs options.
> 
>> On Jun 26, 2021, at 4:53 PM, C. M. Heard wrote:
> 
>> The REQ and RES options exist for the benefit of DPLPMTUD and are intended to be sent on a PLPMTU Probe Packet, which itself must not be further fragmented (the probe packet will not serve its purpose if it is fragmented to make it get to its destination). Ideally, these options are used on packets with padding only and no user data; such packets would be generated and consumed entirely within the transport layer or a shim. As they are not subject to fragmentation, they can be considered complete datagrams.
> 
> You assume these are not UDP fragmented; I do not. DPLPMTUD could be used to determine ways to avoid IP fragmentation but that doesn’t mean it prohibits the use of UDP fragmentation. All that is required is that the probes are not *IP* fragmented.
> 
> I want to hear what the authors of draft-fairhurst-tsvwg-udp-options-dplpmtud have to say about this, but I don't see a use case for sending dplpmtud probe packets that use UDP fragmentation. Indeed, that seems to be a completely useless and unnecessary complication.
> 
>  
>> In addition, it seems to me that there is little or no value in taking a REQ option from the user and replicating it on every fragment of a datagram that needs to be fragmented; this causes duplicate REQ tokens. Gorry, any thoughts? (*)
> 
> I don’t see UDP as replicating options without direction from the application layer. This isn’t like IP where there was never intended to be such control. For UDP, we should assume that options are included per fragment or per datagram *at the discretion of the upper layer*.
> 
> What is the reason and benefit of providing that level of control and responsibility? How will the application use the information on responses to UD{ fragments?
> 
> I am reminded of the words of one of my mentors, who described such an excess of flexibility as "independently steerable front wheels".
> 
> We do not need that. We need this spec to be as simple as possible and unambiguous to implement. Making UDP fragments visible to the protocol running on top of UDP without a clear reason to do so is a clear violation of those principles.
> 
> Mike Heard