Re: [tsvwg] RDMA Support by UDP FRAG Option

[Joseph Touch <[e-mail]>]

> 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)
(1) undermines the use of FRAGs where fragments are larger than 1K (not to mention being smaller for per-frag options)
(2) adds a field that is not needed in packets that are not FRAGs
(3) requires checks that are redundant on packets already protected, undermining the flexibility that continues to be available via UDP CS=0

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