Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)

[Jonathan Morton <[e-mail]>]

> On 10 Mar, 2020, at 10:35 pm, Black, David <[e-mail]> wrote:
> 
> As draft shepherd, let me suggest an alternate way to think about fragmentation and reassembly that may result in simpler text.
>  
> The current situation arises in large part from viewing fragmentation and reassembly as being part of tunnel encapsulation and tunnel decapsulation respectively.
>  
> Instead, I suggest that we view all four of these as separate but related processes, specifically:
>  
> 	• A tunnel ingress encapsulates the inner packet and then fragments the resulting (encapsulated) outer packet if necessary for transmission.
> 		• RFC 6040 and this document specify the ECN requirements for encapsulation.  RFC 3168 specifies ECN requirements for fragmentation.
> 	• A tunnel egress reassembles the outer packet and then decapsulates the resulting (still encapsulated) outer packet to produce the inner packet.
> 		• RFC 3168 specifies ECN requirements for reassembly.  RFC 6040 and this document specify the ECN requirements for decapsulation.
>  
> Optimized implementations may of course mix encapsulation and decapsulation processing with fragmentation and reassembly processing, respectively, but the results are required to be the same as if the above orders of processing were followed and that processing adhered to the requirements listed above.
>  
> I think the result will be clearer, and will also make it obvious that nothing new is being required, especially if “RFC 6040 and this document specify” can be changed to “RFC 6040 specifies” in both sub-bullets above.
>  
> What do you think of this approach?

It seems like a perfectly reasonable approach to me.  We can then focus on what the two existing documents say about their respective parts of the process, and whether they remain compatible with high-fidelity congestion control (and other modern circumstances).

 - Jonathan Morton