Re: [tsvwg] A counterproposal to Section 5.5 of draft-ietf-tsvwg-udp-options-12

[Joseph Touch <[e-mail]>]

Hi, Mike, 

> On Jun 3, 2021, at 7:22 PM, C. M. Heard <[e-mail]> wrote:
> 
> TSVWG,
> 
> In a previous message, I made some rather unkind comments about he FRAG option as proposed in Section 5.5 of draft-ietf-tsvwg-udp-options-12. In this missive I wish to present proposed relacement text for the entire section. 

Your proposal focuses on making the  FRAG option last in non-terminal fragments.

FIRST, note that “offset” in the FRAG option should really be named “”frag length”; it’s there so there can be options after the frags and (at least originally) helped the FRAG/LITE combination support RDMA.

I appreciate that this was garbled/lost in the conversion from FRAG/LITE to just FRAG; I’ll be fixing that.

Overall, I think this proposal does raise two issues indirectly:
a. Do we need to support RDMA for fragments
b. Do we need a post-reassembly checksum

See below for details. Until we answer those, we don’t quite know how to proceed.

Joe

—

So regarding a new format, I think the only real question is whether we keep RDMA support. Here’s why:

Regarding non-terminal FRAG be last:
- we could require options before the non-terminal frags
- however, that also means that we need to consider whether not having FRAG as early as possible would impact RDMA
	right now, we recommend moving it early to make RDMA move fewer bytes to ‘adjust’

Regarding the formats: 
- I prefer uniform TLV format even for options whose length doesn’t change (yes, even changing OCS to do this; only NOP and EOL should be exceptions)
- we still need options after the terminal fragment, e.g., if someone wants to perform AE on the reassembled packet but not the individual fragments (which could improve performance and reduce overhead), or if there are other behaviors (time, echo, etc.) intended on the reassembled packet but not any individual fragment (such as echo only when the whole packet gets there, not just the terminal one).

The question of whether we need a MF bit (or byte) depends on whether we want to retain the post-reassembly required checksum or not. Yes, it’s possible this might not be needed, but it was added by what I understood to be consensus. If we don’t need that, we can drop it.

So at that point, we really have only a few decisions:

- do we want/need RDMA support?
	if not, we ditch the frag length in non-terminal frags

- do we want to ditch the required post-reassembly checksum?
	if so, we ditch that field in the terminal frag

THEN we compare the answers to decide how to handle the MF issue:
	- if we still end up with different length options, length indicates MF
	- if not, we might be better off burning two codepoints on FRAG/TERMFRAG than a byte
	(a single byte throws off our fields as odd-length AND needs to be checked for values not 0 or 1)

Joe