Re: [tsvwg] design assumptions - draft-ietf-udp-options - trying to see the bigger picture

[Gorry Fairhurst <[e-mail]>]

On 18/07/2019, 17:46, Joe Touch wrote:
>
>
>
> On 2019-07-18 09:31, Gorry Fairhurst wrote:
>
>> The thread split, so this is a reply to Joe.
>>
>> On 18/07/2019, 15:50, Joe Touch wrote:
>>> Hi, Gorry,
>>>
>>> True LITE (not just LITE with no user data) is definitely complex...
>>>
>>>> On Jul 18, 2019, at 3:38 AM, Gorry Fairhurst<[e-mail] 
>>>> <mailto:[e-mail]>>  wrote:
>>>>
>>>> I'm trying to understand LITE and the related topics more...
>>>>
>>>> (1) One use-case is to mimic UDP-Lite for layer2 networks that wish to do cross-layer optimisation.
>>> This is the case that makes the most complications for us.
>>>
>>>> ... I would concur this requires strong coordination with the App and Link design, UDP-Lite remains a suitable method, I would agree that adding this to another protocol is not helpful.
>>> If we take this off the table, things get a little simpler...
>>>
>>>> (2) A second use-case is to support router/network device encapsulation (i.e. tunnels)
>>>> where the network device has no visibility deep into the payload. Such devices existed
>>>> and continue to exist. This was a motivation in GRE/UDP. However, for
>>>> IPv6 a zero UDP checksum is restricted to specific uses-cases, and not a host function
>>>> - because as Lloyd pointed out this erodes ability to detect rogue UDP datagrams.
>>> Tunnels are links, and links terminate at both routers and hosts.
>>>
>>> This doesn't erode anything; it follows the IPv6 policy of not duplicating the same kind of check at multiple layers (i.e., it's odd that we keep citing IPv6 as the reason we can't set UDP to zero, when in fact the reason we can drop the checksum for tunnels is exactly the same reasoning used to drop the header checksum in IPv6 - thankfully that's now understood).
>>>
>> Expecting hosts to set zero checksum is something we need to be 
>> careful about. If Frag did not do this, I'd expect easier acceptance.
> Any endpoint supporting a tunnel would want to do this. It's 
> nonsensical to claim that hosts wouldn't do it but routers might. 
> Hosts are tunnel endpoints too.
That's an issue for the WG to think on then.
>>>> (3) A third use-case is when the packet contains another checksum (also the case
>>>> for some tunnels), and we could save the cost of a second checksum.  I am not
>>>> persauded that this is a real cost when comes to a frag/reassembly algorithm.
>>>
>>>> (4) Some other future use, as yet unknown?
>>>>
>>>> The more I think about LITE the less I really am persauded (1) is needed.
>>>>
>>>> I think (2) could be useful, but I don't yet see someone asking for that,
>>> That's part of the issue with computing the checksum over the fragment parts vs. whole...
>> Sure - or we compute an *additional* checksum when we have fragments. 
>> It will cost (a little), but if it solves DNS issues, then I'd 
>> already be excited.
>>>> and I'd expect hosts to see the entire payload, so at least a host implementation does not seem to need that.
>>> Hosts don't want to touch the data twice to check the fragments AND check the reassembled set.
>> Right, that's a question I would like tested.
> That sort of demand cuts both ways - "show me it DOESN"T cost" too. We 
> have lots of experience with zero-copy that says it does EXCEPT during 
> the ONE move in/out to the wire.
Well, I'm hoping others will chime-ion.
>>
>> There are other cases: e.g. Frag usually involves a move, doing 
>> checksum and move can be efficient.
> The way FRAG+LITE is defined the only move is to the first few bytes 
> (the swap). That's exactly why it won't be efficient otherwise - it 
> requires staging the fragments somewhere else which involves a copy.
Do you moev to reassemble, or just leave a chain of fragments?
>>> (and the byte swap in the current LITE is part of RDMA-like zero-copy placement of fragments once received into a single place before making that final check).
>>>
>>>> I'm hessitant to agree that the complexity of LITE is worth the perceived cost saving
>>>> and there may be other ways that don't need this:
>>>> (*) Hardware  off-load of the checksum (e.g. Tom Herbert commened) means the cost can
>>>> be minimal.
>>> Hardware offload doesn't help if checksumming is done multiple times.
>> Well, it save the per-fragment CPU processing. The host then only 
>> needs to worry
>> about other checks.
>>>> (*) For a method designed just for reassembly, it is also possible to
>>>> "checksum" the fragment checksums in a fragementation protocol to provide
>>>> equivalent one-pass checksum.
>>> But it's not equivalent. Remember that data in the host can have errors once each fragment is received too. TCP gives up on that because it HAS to deliver each fragment once previous ones were received; UDP doesn't.
>> Yes - what you I proposed would be weaker.  Doing seprate reassembly 
>> check would be the best thing.
> That's exactly what's in the current doc - post-reassembly checksum.
Yes.
>> ...
>>>> And so back to Frag:
>>>>
>>>> I'm concerned that DPLPMTU, Frag and Lite have much more complexity in their design than other parts of the spec - and more consideration is needed on their use.
>>>>
>>>> For DPLPMTU (#6) the complexity is in another spec (which seems correct to me). I'd be interested whether a separate spec of Frag is also one way to ensure we get experience with the core spec, and then consider how to design Frag (#5, #8).
>>> We can, but IMO the criticality of fragmentation support means that it's not particularly relevant to have UDP options that don't support fragmentation.
>> I think we are making progress on this and other threads. Let's see 
>> how far we get by the time of the meeting.
> If we want a summary by the meeting, then we need to hit the pause 
> button please. I don't have time to track the numerous changes if they 
> continue between now and then.
> And I won't be on the call during th meeting, so perhaps we can focus 
> on converging on what's been said up to now (which might be useful in 
> of itself, though).
> Joe
I agree it's time to start banking the outcomes. I think it may be soon 
(already!) time to stop proposing new stuff and let Joe collect issues, 
and find out who thinks he is heading the best direction.

Gorry