Re: [tsvwg] Way forward for UDP option FRAGs with limited router hardwara

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

On Tue, Apr 5, 2022 at 8:34 AM Joe Touch wrote:

> A few more notes:
>
> I was assuming “offset=0” is the starting fragment offset, though the
> current text indicates this would be offset=8. We can pick either starting
> point (i.e., either the start of the original UDP header or the end of that
> header). So read the note below with that context, i.e., ‘whatever the
> offset of the first fragment is’…
>
> And throughout the rest, I’m giving a broad quick summary; please try to
> focus on the basic idea and assume we can work out the rough edges that
> don’t concur with text in the current draft, unless you see a deal-breaker
> that I missed. I.e., when this proposal differs with the doc, assume the
> doc will be pulled in line with this proposal...
>

Understood and agreed to. I don't much care whether FRAG.OFFSET = 0 or
FRAG.OFFSET = 8 indicates the first fragment, as long as the final spec
tells a consistent story. For definiteness in the example that I provide
below, I will assume that all offsets are measured with respect to the
appropriate UDP header, so FRAG.OFFSET = 8 indicates the first fragment in
that example.

On Mon, Apr 4, 2022 at 9:14 AM Joe Touch  wrote:
>
>> I think there may already be a way forward here that allows users to pick
>> from a variety of ways to support FRAGs that may satisfy the needs of
>> constrained-implementations of router header processing.
>>
>> The current draft defines the terminal FRAG option as follows:
>>
>>                    +--------+--------+--------+--------+
>>                    | Kind=3 | Len=12 |   Frag. Start   |
>>                    +--------+--------+--------+--------+
>>                    |           Identification          |
>>                    +--------+--------+--------+--------+
>>                    |  Frag. Offset   | Dgram Opt Start |
>>                    +--------+--------+--------+--------+
>>
>>                 Figure 11   UDP terminal FRAG option format
>>
>>
>> We can simply allow Dgram Opt Start (DOS) to be anywhere, not just at the
>> end of the user data.
>>
>
> %%
> To be more clear: we can REDEFINE DOS to be anywhere...
>
>
>> I.e.: if DOS is larger than FRAGSTART, then the per-packet options are at
>> the end of the packet.
>>
>
> %%
> To be more clear again, the NEW definition of DOS would be:
>
> If DOS is larger than the FRAGSTART *of the first fragment (offset=0)*
> then the per-packet options are at the end of the packet.
>
>
> If DOS is smaller than FRAGSTART, then it indicates the end of the
>> per-fragment options and start of per-packet options, all of which precede
>> the frag data.
>>
>
> %%
> And again more clearly:
>
> If DOS is s smaller than the  FRAGSTART *of the first fragment
> (offset=0)*, then it indicates the end of the per-fragment options and
> start of per-packet options, all of which precede the frag data.
>
> [ ... ]

> - Frag. Start indicates the location of the beginning of the fragment
> data, ***measured from the beginning of the UDP header of the fragment***.
>
>
> That definition would stay.
>
> - The terminal FRAG option format adds a Datagram Option Start pointer,
> ***measured from the start of the original UDP datagram  header***,
>
>
> That part stays, but the next is now CHANGED as above (see %%):
>
> indicating the end of the reassembled data and the start of the surplus
> area after the original UDP datagram.
>
>
> The changed text would be something like:
>
> Indicating the start of the options, which could occur either after the
> original UDP datagram or before.
>
> [ ... ]

> I’m allowing DOS to point before the FRAGSTART of the fragment when
> FRAGOFFSET is zero, which then becomes the demarcation between per-fragment
> and per-packet options.
>
>
With apologies, I am still having a very hard time figuring out how this is
supposed to work. FRAG.START is an offset ***within a fragment*** and any
data in that fragment that occurs before that point contains per-fragment
options that are not part of the reassembled packet. That applies in
particular to the first fragment (wherein FRAG.OFFSET is eight, if we
reckon such offsets with respect to the start of the UDP header). DOS,
which appears in the final fragment only, is an offset ***within the
reassembled datagram***, as is FRAG.OFFSET. To my small mind, it seems
that FRAG.START
is ***incommensurate*** with DOS. I'm not sure what it means to say that
DOS points before FRAG.START, since they are offsets within different data
structures. Also, when there are multiple fragments, DOS appears in a
***different*** fragment than the FRAG.START with which it is to be
compared.

Moreover: it is not difficult to concoct an example of an atomic fragment,
constructed under the rules in -18, that has DOS numerically smaller than
FRAG.START. Start with a UDP datagram having the usual 8-byte UDP header,
32 bytes of UDP user data (so UDP Length = 40), and some trailing
per-datagram options -- for definiteness, let's say OCS and a TIME option,
for a total of 12 bytes (though this does not really matter). Let's suppose
that we wish to  encrypt this using a per-fragment UENC option; again for
definiteness, I assume that the UENC option uses a 16-byte MAC and so has a
total length of 20 bytes. The on-the-wire packet will then have a UDP
header that is 8 bytes long with its length field set to 8, a two-byte OCS,
two one-byte NOPs for alignment, a terminal FRAG option with a length of 12
bytes, and a UENC option with a length of 20 bytes. Irrespective of the
order of the FRAG and UENC options, we have FRAG.START = 44, FRAG.OFFSET =
8, and DOS = 40.


> This is preferable to using the FRAG option itself as the demarcation (as
> Tom had suggested) because it allows FRAG to remain up front, enabling DMA
> without long-chain TLV searches.
>
> Again, *IF WE ALLOW DOS to point before the first FRAGSTART*, then we do
> give up having the reassembled packet have exactly the same format as if it
> were not fragmented. I would prefer to not do this, especially to support a
> router hardware implementation decision that has no basis in RFC
> requirements, but we can if it’s consensus to do so.
>
>
If I understand the ***intent*** of the proposal to allow DOS to point
before the first FRAG.START, it is to allow a special format for
reassembled packets, in addition to the one already in -18, wherein the
reassembled packet has exactly the same format as if it were not
fragmented. If we give that up in some cases, I would MUCH prefer to end up
with just one one format for reassembled packets. Specifically: I think we
should keep the existing format for unfragmented packets that contain
options in an (optional) trailer, and have another format with all options
at the front for packets that lack conventional UDP data. And if we take
that route, my sense is that we would be better off to adopt something
along the lines of what is proposed in
https://datatracker.ietf.org/doc/html/draft-herbert-udp-space-hdr for those
packets. I can see how to make that work, and in the cases that I have
worked out, it saves space compared to having a FRAG option as in -18 and
still satisfies the desideratum of having the FRAG control information
early to facilitate DMA offload for reassembly. I'll take the time to
provide details if there is WG interest. If not, I am satisfied to proceed
with -18 (modulo polishing of rough edges) with documentation of the
limitations as Mr. Herbert requests.

Mike Heard




>