Re: [tsvwg] Remaining issues for draft-ietf-tsvwg-udp-options-22

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

On Thu, Jun 29, 2023 at 9:28 AM Erik Auerswald wrote:
>
> > * Section 9.4: Agreed text for the (simplest) way to handle options
> > in fragments of a datagram.
>
> I have to admit that I am utterly confused by section 9.4.
>
> I do not understand how both "[n]on-terminal fragments never have
> options after the fragment" and "The RDOS field enables the FRAG option
> to precede other options in every fragment" can be true at the same time.

It cannot. This is a serious bug in the spec that I have been objecting
to for over a year. If you have not done so already, please review

https://mailarchive.ietf.org/arch/msg/tsvwg/D99trU_nsq4rRGT24gNeeDnkfoE/

> Then "Frag. Start" seems to only be defined for the non-terminal FRAG
> option format, but it is also part of the terminal FRAG option format.

That is not true. "Frag. Start" and "Frag. Offset" are defined in both
terminal and non-terminal fragments (look carefully at Figure 10 and
Figure 11). "Frag. Start" is measured relative to the beginning of the
on-the-wire UDP packet containing the fragment (this includes the UDP
header, but not any lower layer headers). "Frag. Offset" is measured
relative to the beginning of the UDP header of the original UDP datagram,
before fragmentation or after reassembly.

Reassembled Datagram Option Start (RDOS) is present only in terminal
fragments. Like Frag. Offset, it is measured relative to the beginning of
the UDP header of the original UDP datagram, before fragmentation or after
reassembly.

> The RDOS description uses an IMHO surprising order to describe checks
> regarding its value:
>
>   - Case 1: RDOS > Frag. Start of the first fragment (offset=8)
>
>   - Case 2: RDOS == end of the original IP packet
>
>   - Case 3: RDOS < Frag. Start of the first fragment
>
> It seems to me as if case 2 is a subset of case 1, i.e., I'd say that it
> might be easier to comprehend the logic if case 1 would be tightened to:
>
>   Frag. Start of the first fragment (offset=8) < RDOS < end of the
>   original IP packet
>
> It might also be helpful to specify how to treat RDOS == Frag. Start of
> the first fragment.

Comparing RDOS with Frag. Start is just plain nonsense.

The fundamental problem is that RDOS and Frag. Start are referenced to
different entities (reassembled datagram for one, on-the-wire fragment
for the other), and thus are incommensurable (not comparable). The two
are not related.

In theory, RDOS and Frag. Start COULD be made inter-related, at least
in atomic fragments, but only at the expense of a poorly-motivated
complication to an already complicated specification, The expense would
be special-case processing of atomic fragments, which would surely
complicate offload of fragmentation and reassembly.

> I would like to suggest considering a complete rewrite of the FRAG
> description.

I don't think that is necessary. I think if the following text is
removed from Section 9.4, the rest of the section will make sense.

--cut here--
   If RDOS is larger than Frag. Start of the first fragment (offset=8),
   then all the per-packet options occur before the user data as it is
   reassembled. If RDOS points to the end of the original IP packet,
   then there are no per-packet options. If RDOS is smaller than Frag.
   Start of the first fragment, then it indicates the end of the per-
   fragment options (of the first fragment) and the start of per-packet
   options (of the reassembled user data). The RDOS field enables the
   FRAG option to precede other options in every fragment and to enable
   all packet options to precede user data, enabling easier support for
   reassembly offload via DMA and to support limited router option
   processing hardware.
--end--

--cut here--
      Note: per packet options can occur either at the end of the
      original user data or be placed after the FRAG option of the
      first segment, with the Reassembled Datagram Option Start (RDOS)
      in the terminal FRAG option set accordingly. This includes its
      use in atomic fragments, where the terminal option is the initial
      and only fragment.
--end--

It would also help to rework the paragraph under Figure 10 as follows:

OLD
   In the non-terminal FRAG option format, Frag. Start indicates the
   location of the beginning of the fragment data, measured from the
   beginning of the UDP header of the fragment. The fragment data
   follows the remainder of the UDP options and continues to the end of
   the IP datagram (i.e., the end of the surplus area). Those options
   are applied to this UDP fragment. Non-terminal fragments never have
   options after the fragment.

NEW
   Frag. Start indicates the location of the beginning of the fragment
   data, measured from the beginning of the UDP header of the fragment.
   The fragment data follows the remainder of the UDP options and continues
   to the end of the IP datagram (i.e., the end of the surplus area). Those
   options are applied to this UDP fragment.

Granted, with those changes systems that can only process a limited
distance into a packet will be limited to per-fragment options. But
IMO we should not be complicating the design to accommodate such
systems.

Mike Heard