[tsvwg] ecn-encap-guidelines reframing section

[Bob Briscoe <[e-mail]>]

David,

On 22/03/2021 22:00, Black, David wrote:
> ---------------------------------
>
> 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 ...

[BB] Er...hum...
You seem to have forgotten that you are talking about just dumping the 
point that I believe was missing from RFC3168. We came to a long-fought 
agreement that we would not decide on this before publishing these 
drafts. But now you are proposing we decide on this before publishing 
these drafts.

>
> 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:

[BB] The whole problem I identified with only thinking in terms of the 
second SHOULD is that you end up with either inflated or deflated 
marking, depending respectively whether frames are smaller or larger 
than packets. That is the whole point of the need for the two 
contradictory requirements.

>
>> 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.

[BB] No tracking of a long-term average is needed in the implementation, 
only in the /requirement/. One example implementation would be a single 
counter per aggregate (for the first SHOULD) and a timeout for the 
second SHOULD. The two override each other to create a compromise that 
addresses each requirement in the traffic scenarios where it is most 
applicable.

If you want me to give example pseudocode in this email, I would love 
to. But I thought we agreed that we are not going to solve the dilemma 
in this text, we are just going to state the requirements. Having worked 
on this draft for so many years, and having developed what I believe is 
a solution, I find that highly unsatisfactory. But we agreed to it.



Bob

>
> 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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/