Re: [tsvwg] RDMA Support by UDP FRAG Option

[Joe Touch <[e-mail]>]

> On Jun 18, 2021, at 10:22 AM, Tom Herbert <[e-mail]> wrote:
> 
> On Fri, Jun 18, 2021 at 8:11 AM Joseph Touch <[e-mail]> wrote:
>> 
>> 
>> 
>> On Jun 18, 2021, at 2:36 AM, Gorry Fairhurst <[e-mail]> wrote:
>> 
>> Please look at draft-herbert-udp-space-hdr-01 for my proposal as to
>> how the UDP surplus space should be formatted. If there is interest, I
>> could update draft to include considerations for UDP options
>> fragmentation and reassembly offload as well as header/data split
>> which is needed for zero-copy receive (i.e. packet headers are DMA'ed
>> into one set of buffers to be processed by the stack, payload is
>> DMA'ed to another set of buffers to be processed by the application).
>> 
>> Tom
>> 
>> ...
>> I think it would be good for the WG to focus on how to finish draft-ietf-tsvwg-udp-options, but I do seem some opportunities to use some of these ideas for making the fragment header - because that also places all data in the "option”.
>> 
>> 
>> The difference between this draft and where we are (and have been before that draft):
>> 1. it adds an option area length field
>> 2. it requires length on all packets with options
>> 3. It requires OCS on all packets with options
>> 
>> (1) repeats TCP's mistake of limiting the options space (see draft-ietf-tcpm-tcp-edo)
> 
> Allowing an unlimited size and number of options repeats the same
> mistake in RFC8200, the only use case for unlimited options is Denial
> of Service attack.

Receivers can always decide to drop packets with whatever they deem as too large an option area.  We don’t need to bake a fixed number in the option definition. 

>> (1) undermines the use of FRAGs where fragments are larger than 1K (not to mention being smaller for per-frag options)
> 
> I don't know what that means.

Please read the draft. 

>> (2) adds a field that is not needed in packets that are not FRAGs
> 
> Not sure to which fields you are referring.

The length field. 

>> (3) requires checks that are redundant on packets already protected, undermining the flexibility that continues to be available via UDP CS=0
>> 
> UDP checksum is required to be non-zero for IPv6,

Please recheck 8200 and 6936. Zero is still allowed for tunneled packets. 

> which means this
> point is being rendered moot as IPv6 deployment continues. Besides
> that, as I've mentioned several times now, if the checksum is in a TLV
> then the checksum cannot protect against it's type field being
> corrupted and also the checksum serves to validate that the surplus
> space is indeed UDP options and not some random bits some hosts
> decided to put in there.
> 
>> I don’t understand “places all the data in the ‘option’”. It doesn’t appear to do that unless used with FRAG, which we already do in the WG doc.
>> 
>> Joe
>