Re: [tsvwg] UDP Options: on forcing the use of UDP CS=0 in connection with FRAG+LITE

[Joe Touch <[e-mail]>]

To be a little more specific:

> On Jul 1, 2019, at 1:18 PM, Joe Touch <[e-mail]> wrote:
> 
> 
> 
>> On Jul 1, 2019, at 12:49 PM, C. M. Heard <[e-mail]> wrote:
>> 
>>> You haven’t addressed the data copying issue.
>> 
>> Yes, I have, in
>> https://mailarchive.ietf.org/arch/msg/tsvwg/RJBWi_tiW6M_phfc22zKuVn_vh4
>> 
>> Can you please respond to that message and explain exactly why you think
>> that the proposal in the thread "DP Options: how to do FRAG without LITE
>> and forced UDP CS=0" imposes data movement requirements for packet
>> reassembly beyond those required by FRAG+LITE (or FRAG without LITE) in
>> in draft-ietf-tsvwg-udp-options-07? I sure don't see it.
> 
> When I’m done moving a small, fixed number of bytes, the existing FRAG+LITE option leaves the fragment at the head of the packet.
> 
> When you’re done, the frag is after a variable length string of options.
> 
> Yes, both need to be gathered together. No, they’re not the same - some UDP hardware and software implementations treat the offset where they expect the data to start as “special”; yours could be anywhere.

Consider mbufs chains where headers are in separate mbufs than the body.

In that case, the existing FRAG+LITE would need to just chain the bodies together and alter their length

In the new proposal, there would be a potentially variable offset from the head of each mbuf in the chain.

Those might have very different overheads…

Joe