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

[Tom Herbert <[e-mail]>]

On Mon, Mar 11, 2019 at 9:11 PM C. M. Heard <[e-mail]> wrote:
>
> On Mon, Mar 11, 2019 at 9:26 AM C. M. Heard <[e-mail]> wrote:
> > I'd like to float a different idea, namely, putting the UDP user data
> > inside the FRAG option itself.
>
> Well, that proposal was rather obviously flawed by limiting fragment
> sizes to ~240 bytes. My apologies. I withdraw the FRAG proposal in
>
> https://mailarchive.ietf.org/arch/msg/tsvwg/JZ8ohgwMs9eRPRQ6KJDqUZTJxSk
>
> However, I think that the following simpler version will actually work:
> maintain the format of the FRAG option as currently defined, but instead
> of having the option capture preceding conventional or LITE user data as
> fragment data, insist that it appear ***last*** in the option list and
> have it capture all remaining octets in the packet as fragment data. By
> convention, if this option appears, OCS would cover all UDP options as
> well as all octets in the UDP trailer that follow the FRAG option.
>
> The following requirements would apply:
>
>    >> When the FRAG option appears, it MUST come last in the UDP options
>    list.  All remaining options in the packet are interpreted as fragment
>    data.
>
Hi Mike,

Thinking about this, it occurs to me be that the LITE option isn't
needed. The assumption in the UDP options draft is that a receiver
needs the UDP payload to immediately follow the UDP header, but the
UDP payload can be anywhere in the surplus area as long as it's
aligned to four bytes. A receiver will know how to handle it and
deliver the UDP data to the application (e.g. by maintaining a pointer
to the data).

So that allows a format like:

UDP header (Length=8) | Surplus area header | Options | Payload

The surplus area header contains the header length and a checksum
covering the surplus space (four bytes altogether). The three headers
can thought of as an extended UDP header, so the format becomes:

Extended UDP header | Payload

Which looks a whole lot like any other protocol format with a variable
length header such as TCP or IPv4.

Tom

>
>    >> OCS, if present, covers both the FRAG option and the trailing
>    fragment data.
>
>
>    >> A host that wishes to signal that it is able to accept and process
>    the FRAG option MAY do so by transmitting an unfragmented datagram
>    with an empty terminal FRAG option whose Offset and Checksum fields
>    are set to zero.
>
>
>    >> Non-empty FRAG options MUST NOT be present in packets with ordinary
>    UDP user data or LITE data. Any such options MUST be silently dropped.
>
>
>    >> UDP options other than OCS and padding MUST NOT accompany the FRAG
>    option in non-terminal fragments.  Any such options MUST be silently
>    dropped.  All other options that apply to a reassembled packet must
>    accompany the FRAG header in the terminal fragment.
>
>
> This proposal does not suffer from the disadvantage that a legacy receiver
> could misinterpret a UDP fragment as a complete datagram, as does the
> currently-defined version of FRAG without LITE.  And it avoids the problem
> that OCS does not cover the currently defined version of FRAG+LITE.
>
> Note that because of their unusual property of capturing following or
> preceding data, FRAG and LITE would have to be mandatory to
> recognize, but I do not believe that they should be mandatory to
> generate or process. An implementation that cannot process these
> options should silently drop packets that contain them.
>
> There's probably something wrong; if so, please tell me what it is.
>
> Mike Heard