Re: [tsvwg] Alternative version of the UDP FRAG option

[Derek Fawcus <[e-mail]>]

On Sat, Mar 16, 2019 at 11:37:35AM -0700, Tom Herbert wrote:
> > So that allows a format like:
> >
> > UDP header (Length=8) | Surplus area header | Options | Payload

Tom,
   I underand this suggestion to be an proposal for an alternate way of
encoding LITE data - i.e. providing a UDP-Lite like service.

If that is incorrect, then please ignore the following.

> > That’s DOA for legacy receivers.
> 
> Legacy receivers see a UDP datagram with zero payload, just like LITE.

Actually, that is not what LITE does.

LITE as Joe has it (and also my proposed hack to your framing) would
provide the following.

Assume a UDP-Lite like payload, with some payload having checksum
coverage, some being unprotected.

1) Two new peers communicating would see the expected UDP-Lite behaviour.
   The coverred data should arrive, the uncovered data may arrive
   corrupted.

2) For a legacy peer receiving from a new peer, they would only
   receive the portion of the payload having checksum coverage.
   If the packet was sent with UDP CS=0, they'd still receive
   the same data, but without checksum coverage.

   i.e. in effect the packet would arrive truncated, with all of
   the data beyond the coverage length discarded.  So not only
   is it 'corrupted', but the length information is lost.

Depending upon what use is being made of the LITE data,
i.e. some metadata in the checksummed area, that loss may
be significant.  However I'm not sure if it is useful
for a legacy application (as opposed to a legacy UDP stack).

So in effect, the legacy peer only sees the portion of the packet that
is potentially coverred by the checksum coverage field in the UDP-Lite RFC.

With this proposal,  they'd see a zero length packet.

So you need to consider LITE alone separate from LITE+FRAG.
The lattr is currently propoposed for sending Segmented UDP data,
and would have the behaviour you mention.

This is where Mike is suggesting an alternate encoding for
Segmented data using a new FRAG alone scheme; hence in
effect splitting LITE and FRAG in to distinct pure use
cases.

DF