Re: [tsvwg] Fragmentation & ECN encapsulation drafts, one more try

[Jonathan Morton <[e-mail]>]

> On 18 Mar, 2020, at 2:49 pm, Black, David <[e-mail]> wrote:
> 
> Given how we got to this point, I believe that the rough consensus of the TSVWG WG is not to use either of these drafts to update RFC 3168, and instead to use a new draft to propose changes to RFC 3168 for fairness across fragmented and non-fragmented flows.

Agreed.

> Another important reason for a new draft is that this WG and other impacted WGs need to discuss the implementation impacts of the proposed changes, as implementations can be expected to have complied with the “MUST” in section 5.3 of RFC 3168 that results in fragmented IPv4 flows receiving more congestion indications that similar-sized flows that are not fragmented.  That discussion and determination of what to do is going to take a while, including a broad WG Last Call that includes all the affected areas of the IETF – that’s much better done via a new draft focused on that topic rather than the existing rfc6040update-shim draft.

Fair.

> However, the path forward cannot just delete Section 5 of the rfc6040update-shim draft, thereby ignoring the concern, as we do have a WGLC comment to resolve that requires stating something about fragmentation.  I suggest that the overall goal should be to state as little as possible.  There appear to be 3 things that need to be dealt with:
> 	• When a tunnel ingress fragments a packet, the ECN field in every fragment has the same value as the original packet.
> 		• This was implicit in RFC 3168, at least as I read Section 5.3 of RFC 3168.
> 		• It makes sense to state this explicitly with a MUST and have that statement update RFC 6040.  Such a statement would not be changed by the new draft to propose updates to RFC 3168.

Okay.

> 	• When a packet is reassembled by a tunnel egress, and one of the fragments is marked with CE, RFC 3168 specifies what to do.
> 		• Given the desire to change RFC 3168, that is all that should be stated here..
> 		• That avoids repeating or reinforcing text from RFC 3168 for which changes may be proposed in the not too distant future.

Yes.

> 	• When a packet is reassembled by a tunnel egress, and none of the fragments are marked with CE, RFC 3168 does not specify what to do.
> 		• In fact, RFC 3168 even allows use of an ECN value that was in none of the fragments (see the last paragraph in Section 5.3 of RFC 3168), but I’d be surprised to find “running code” that behaves that way.
> 		• I think I’ve seen some list discussion to the effect that RFC 3168 applies a bitwise “logical OR” across the ECN field values in the fragments - RFC 3168 does not do that.  The use of “logical OR” in the text below (from Bob) refers to case 2 above – if any fragment is marked with CE and the reassembled packet is forwarded, then RFC 3168 requires the reassembled packet to be marked with CE.

I think it may have been suggested that applying a bitwise-OR across all ECN fields of fragments would be an expedient and high-performance implementation of the logical-OR requirement over CE marks, so may have been used in practice.  Additional logic would be needed to catch the case where one but not all of the fragments carried Not-ECT, whether or not this was done instead of a true logical-OR.

Because of the laxness of the RFC-3168 specification with respect to mixed codepoints, an implementation that did this would still be conformant.  And because ECN codepoints are normally the same across fragments (except for CE marks set on the tunnel path), it wouldn't have shown any noticeable bad effects.

I'm in favour of trying to tighten this language a bit, while accepting that implementations of this type *may* be out there in practice.

> 		• Going back to earlier list discussion (October of last year), the clear outcome was to use the ECN value from “any” fragment in the reassembled packet, with the implementation choosing the fragment from which that value is obtained.
> 		• Trying to walk a fine line, I’d suggest crafting text to states that using the ECN value from one of the fragment is a suggested implementation that meets the requirements of RFC 3168, and leave it there without applying a “SHOULD” keyword to that behavior, lest that keyword have to be updated in the not too distant future by proposed changes to RFC 3168.

This seems like a reasonable proposal for RFC-6040.

 - Jonathan Morton