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

["C. M. Heard" <[e-mail]>]

On Mon, Jul 1, 2019 at 1:19 PM Joe Touch wrote:
> On Jul 1, 2019, at 12:49 PM, C. M. Heard wrote:
> > On Mon, Jul 1, 2019 at 12:27 PM Joe Touch  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.
...
> To be a little more specific:
>
> 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…

YMMV, but I find that argument to be unconvincing. Any not conspicuously
deficient mbuf design needs to be able to easily trim off variable length
headers from the start of a packet (e.g., by having a starting offset), or
else it would not be able to efficiently accommodate IP options/extension
headers, TCP options, tunnel encapsulation headers, and so on.

Mike