Re: [tsvwg] A review of draft-ietf-tsvwg-udp-options-12 zero copy

[Gorry Fairhurst <[e-mail]>]

Tom, do you recall why you hated the mangling of byte order in the 
UDP-Option fragment proposal?

Gorry

On 14/06/2021 05:34, Joseph Touch wrote:
> PS - I should note that I don’t care strongly that we keep this 
> zero-copy support, It’s not important for individual packets; it’s 
> useful only for streams, IMO anyway. If omitting it is fine, then we 
> can make FRAG processing simpler.
>
> The argument for omitting it is:
> - zero-copy is more useful for streams where apps should adjust MTU 
> anyway and thus wouldn’t need FRAG for MTU adjustment
> - zero-copy works fine when the data isn’t UNSAFE (in the body)
> - when data is otherwise UNSAFE, it’s because it is modified 
> (encrypted, compressed, etc.), where zero-copy is not relevant either
>
> Joe



>
>> On Jun 13, 2021, at 9:31 PM, Joseph Touch <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>
>>
>>> On Jun 13, 2021, at 7:20 PM, C. M. Heard <[e-mail] 
>>> <mailto:[e-mail]>> wrote:
>>>
>>>     If we DO support zero-copy and thus want to allow non-terminal
>>>     fragments to have post-fragoption options that operate on each
>>>     fragment, then we would add THISFRAGLEN to the nonterminal
>>>     format and issue different KIND numbers to nonterminal/terminal
>>>     fragment.
>>>
>>>
>>>
>>> I for one would appreciate further discussion of these last points. 
>>> I admit that I have failed to grasp Joe's message on the RDMA 
>>> thread, and I would appreciate some time to think about it.
>>
>> Sure - here’s how it all works. Note that this is relevant mostly for 
>> long transfers with persistent UDP fragmentation; if that is assumed 
>> to be ‘adjusted’ at the app layer (as QUIC does), then we don’t need 
>> zero-copy support...
>>
>> - right now, UDP data can be zero-copied when received into user 
>> space, starting with the user data
>> - if we add options, UDP data can still be zero-copied because it 
>> hasn’t moved (it still begins the payload
>> - however, fragments are different because (esp given the merging of 
>> frag and lite) they don’t start at the beginning of data
>> - they always start after OCS (which I think we should make fit the 
>> uniform KIND/LEN/OCS format of 4 bytes)
>> - if the FRAG comes next, then we can move the frag content around a 
>> little and still support zero-copy
>>
>> notably, we move the first 10 bytes of the fragment to the end
>> 4 for OCS
>> 6 for FRAG (assuming FRAG includes KIND/OPTLEN/FRAGOFFSET/ID/FRAGLEN)
>> that way we can zero-copy the frag packet into place, then just copy 
>> those last 8 bytes over OCS and the FRAG header
>>
>> This method assumes that we try to keep FRAG early in the packet - 
>> preferably right after OCS. The later it comes, the more additional 
>> bytes we need to move to “fix” the copy (beyond the 8 bytes noted above).
>>
>> —
>>
>> This method is the only reason we would want to allow options after 
>> non-terminal fragments - basically to keep the fragment toward the 
>> front of the packet, using the rule that post-noninitial frag options 
>> still operate on the fragment, rather than waiting for reassembly. 
>> The exception is the terminal fragment, where post-terminal fragment 
>> options operate on the reassembled packet.
>>
>> Joe
>>
>>
>>
>>
>