Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim:SuggestedFragmentation/Reassemblytext

["Black, David" <[e-mail]>]

First, the good news - the reassembly text in Section 5 of rfc6040update-shim
draft looks good:

   Section 5.3 of [RFC3168] defines the process that a tunnel egress
   follows to reassemble sets of outer fragments
   [I-D.ietf-intarea-tunnels] into packets.

   During reassembly of outer fragments [I-D.ietf-intarea-tunnels], if
   the ECN fields of the outer headers being reassembled into a single
   packet consist of a mixture of Not-ECT and other ECN codepoints, the
   packet MUST be discarded.

   If there is mix of ECT(0) and ECT(1) fragments, then the reassembled
   packet MUST be set to either ECT(0) or ECT(1).  In this case,
   reassembly SHOULD take into account that the RFC series has so far
   ensured that ECT(0) and ECT(1) can either be considered equivalent,
   or they can provide 2 levels of congestion severity, where the
   ranking of severity from highest to lowest is CE, ECT(1), ECT(0)
   [RFC6040].

I would slightly rephrase the first paragraph as follows:

   Section 5.3 of [RFC3168] specifies ECN requirements for tunnel egress
   reassembly of sets of outer fragments [I-D.ietf-intarea-tunnels] into IP packets
   when at least one of the fragments is CE-marked.  If none of the fragments
   in a set to be reassembled is CE-marked, then the following two additional
   requirements apply:

and then itemize the second and third paragraphs (e.g., number them 1. and 2.).

The rationale for this rephrasing is that Section 5.3 of RFC 3168 does not specify
a process, but rather imposes requirements on what is allowed.  I also believe
that this text the bulk of what's needed to address the reassembly comment
that's been holding up these drafts.

---------------------------------

Moving onto the ecn-encap draft (Section 4.6), the text involved concerns
how to propagate layer 2 frame congestion marks to IP packets which might
be fragments.  As this text is not dealing with reassembly of IP fragments, it
cannot be in conflict with the reassembly text in RFC 3168, which has nothing
to say about layer 2 frame congestion marks:

   Congestion indications SHOULD be propagated on the basis that an
   encapsulator or decapsulator SHOULD approximately preserve the
   proportion of PDUs with congestion indications arriving and leaving.

   The mechanism for propagating congestion indications SHOULD ensure
   that any incoming congestion indication is propagated immediately,
   not held awaiting the possibility of further congestion indications
   to be sufficient to indicate congestion on an outgoing PDU.

Bob initially suggested the following:

> Possible resolution of the contradiction: the "SHOULD approximately preserve
> the proportion" is a rough long term average goal while "SHOULD ensure that
> incoming congestion indication is propagated immediately" is a requirement
> for after there has been some period (TBD) without any marking. 

I'm going to go one step further and suggest removing the first "SHOULD" - the
whole notion of rate-based marking of IP packets reassembled from fragments
is what got us into the tarpit for the rfc6040update-shim draft, and the first
"SHOULD" appears to be headed into the same tarpit, only perhaps deeper
as the frames involved may contain multiple packets and/or fragments and/or
portions of packets and/or portions of fragments.  That's not exactly pretty ...

For replacement, my initial sense matches Jonathan's, in particular that a layer 2
congestion mark ought not to result in congestion marking multiple IP packets:

> I would say that one mark applied at link layer should result in one mark applied
> to one IP packet.  Exactly which one doesn't really matter, as long as it has some
> tangible connection to the frame that was marked.  Word it that way, and we'll
> be fine.  In particular, this method should work for *both* conventional and
> high-fidelity sensitive traffic.

That also has the useful simplification of not asking the implementation of this draft
to roughly track a long term average in some fashion.

Thanks, --David

-----Original Message-----
From: Jonathan Morton <[e-mail]> 
Sent: Sunday, March 21, 2021 2:42 PM
To: Bob Briscoe
Cc: Markku Kojo; Joe Touch; Markku Kojo; [e-mail]; [e-mail]
Subject: Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim:SuggestedFragmentation/Reassemblytext


[EXTERNAL EMAIL] 

> On 20 Mar, 2021, at 8:27 pm, Bob Briscoe <[e-mail]> wrote:
> 
> It's not enough to make ecn-encap the same as shim. The reassembly logic in RFC3168 is only defined when packets are reassembled from /smaller/ fragments. When a L2 frame is /larger/ than an IP packet, or /overlaps/ the boundary between IP packets, the reassembly logic in RFC3168 makes is undefined - it makes no sense. 
> 
> For instance, some link layers treat IP packets as a continuous byte stream, then break the stream into the largest possible frames, like so: 
> 
> ----------------->+<---------------------------->+<------------------------------>+<----
>         Fr1       |                Fr2           |             Fr3                |     
> +-------------+-------------+-------------+-------------+-------------+-------------+---
> |   Pkt1      |    Pkt2     |    Pkt3     |   Pkt4      |    Pkt5     |   Pkt6      |
> +-------------+-------------+-------------+-------------+-------------+-------------+---
> 
> Then, say Fr2 was marked. On decap should Pkt2, Pkt3 & Pkt4 be marked, or just Pkt3 & Pkt4?

I would say that one mark applied at link layer should result in one mark applied to one IP packet.  Exactly which one doesn't really matter, as long as it has some tangible connection to the frame that was marked.  Word it that way, and we'll be fine.  In particular, this method should work for *both* conventional and high-fidelity sensitive traffic.

 - Jonathan Morton