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

[Tom Herbert <[e-mail]>]

On Sat, Mar 16, 2019, 3:31 PM Derek Fawcus <
[e-mail]> wrote:

> 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.
>
Derek,

It's more accurate to say the proposal is a means to extend the UDP header
(emphasis on word "header" here as opposed to using a trailer). The format
is independent of whether a fragment is carried or not. Since the UDP
length is 8, the standard UDP checksum doesn't cover payload inside surplus
area, so the extended header has a checksum covering the payload and
extended header beyond UDP header (ie options would always be covered by
checksum in the same way the IPv4 and TCP options are).

I will post a revised draft for this once upload opens.

Tom


> > > 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
>
>