Re: [tsvwg] A review of draft-ietf-tsvwg-udp-options-12

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

On Fri, Jun 11, 2021 at 4:43 AM  Mohamed Boucadair wrote:

> Hi Joe, all,
>
> Regarding the FRAG option, I'm not sure there was a consensus this is a
> MUST to implement/support.
>
> Unless I'm mistaken, I didn't even remember a conclusion for one of the
> main threads when FRAG and other "design assumptions" were discussed back
> in 07/2019.
>
> As indicated in
> https://mailarchive.ietf.org/arch/msg/tsvwg/rfh1wBYzlIHIzeVQruT5BVd8BRA/,
> I do still think that we would better focus on key foundations and build
> over them. FRAG can be defined properly in a separate document. It can be
> tagged as unsafe but it does not need to be mandatory to implement.


>
Indeed, as far as I can tell, that discussion never did achieve consensus
on the matter of whether fragmentation is a requirement. So let's discuss.
Here's my position:

While I agree that it is not appropriate to require every implementation of
UDP options to support reassembly of fragments, I do believe that the FRAG
mechanism needs to be in the base specification of UDP options if we are
going to have it at all. It interacts with other options, and thus should
not be deferred to a future document.

On Fri, Jun 11, 2021 at 7:37 AM Gorry Fairhurst wrote:

> On the one hand: I can ses it would be nice to have many things in the
> common standard and immediately available to use.
>
> On the other hand: There seems to me to be singificantly more complexity
> and choice in managing reassembly than in the other aspects of UDP
> options- I can see how this could vary depending on usage: how much
> memory to use for reassembly, and what size is considered acceptable. To
> me, that makes it seems reasonable to ask whether a minimal implemention
> needs to offer this.
>
> I know when someone in Aberdeen University implemented an earlier rev.
> of UDP-Options, this was the part that wasn't done.
>
>
I believe that the references are:
https://datatracker.ietf.org/meeting/101/materials/slides-101-tsvwg-sessa-53-tom-jones-udp-options-implementation-02
https://datatracker.ietf.org/meeting/101/materials/minutes-101-tsvwg-02

On Fri, Jun 11, 2021 at 9:40 AM Joseph Touch wrote:

> I agree with everyone that FRAG support shouldn’t be open-ended. Maybe we
> can say MUST implement at least 2-fragment reassembly, SHOULD implement up
> to 9K (that’s the upper bound on most MTUs that aren’t 64K AFAICT).
>
> I understand it’s the last thing to be implemented because it’s hard, but
> that alone isn’t a reason to make it optional. Maybe we should just skip
> RDMA support as unnecessary; RDMA perhaps should tune to MTU rather than
> rely on long streams of UDP fragments.


>
As I stated in the review, I believe that all implementations of UDP
options should be required to recognize the FRAG option, but I believe that
it is a bridge too far to require actual reassembly of fragments. It would
IMO be fair to require implementations of UDP options to be able to process
and accept a datagram that consists of a single fragment that is both an
initial fragment and a terminal fragment. That is needed to support UNSAFE
options.  It is also straightforward and stateless; actual reassembly of
fragments is neither.

I also advocate that sending a MRSS (Maximum Reassembled Segment Size)
option be an unambiguous indication that an implementation supports
reassembly of fragments. My take is that the number of fragments that can
be accepted is an implementation-defined limit and thus a Quality of
Implementation matter and does not need to be standardized. A sender that
has received both the MSS and MRSS options from a particular destination
will have a very strong hint on when and how to fragment a datagram sent to
that destination.

FWIW, I think that the MRSS option is a valuable addition to the spec. I
wish I'd thought of it!

Thanks and regards,

Mike Heard