Re: [tsvwg] ecn-encap-guidelines reframing section

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

Bob,

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

Well ... not exactly ... because it appears to me that the reframing section (4.6) of the ecn-encap-guidelines draft does not address IP packet reassembly from IP fragments, and hence falls outside the scope of RFC 3168.

That said, I nonetheless concur with your sense that it would be good to preserve flexibility for addressing this area in a more specific fashion in the future.

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

My current inclination is that we may be best served by postponing a decision on whether inflated/deflated marking is a bug or a feature, roughly analogous to what we've agreed to for the rfc6040update-shim draft.  The second "SHOULD" is clearly consistent with that approach, as propagating congestion indications quickly reduces the latency of transport protocol congestion response, which is a "good thing" on its own:

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

Turning to the first "SHOULD," this paragraph from one of Markku's messages frames the conundrum well (at least for me):

	I'm very well aware of the strong case that RFC 7141 makes for 
	packet-mode drop, and it makes this problem even much trickier to solve. 
	However, if we concentrate only on the problem of dropping small fragments 
	and reassembling them, the byte-mode drop together with reassembly logic 
	in RFC 3168 results in the correct outcome.

Of course, a significant aspect of the situation here is that reframing is not just about small fragments.

It's ironic that you (Bob) as an author of RFC 7141 are advocating byte-mode in this context - that's not intended to imply self-contradiction, unsoundness of argument, etc., but rather to serve as an indication of the complexity and subtlety of this situation.  Definitively resolving this situation now appears to require digging in well beyond this high-level byte-mode vs. packet-mode discussion, a journey that I'd really like to avoid in the hope of landing these drafts in our AD's lap in the near future.

So, in what may be an attempt to "have my cake and eat it too" I'd like to suggest rewriting the first SHOULD in terms of an observation that does not directly opine on byte-mode vs. packet-mode and does not use RFC 2119 keywords, e.g.:

OLD
     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.
NEW
     For environments in which protocol and/or application response to
     congestion is sensitive to the number of bytes in IP packets with
     congestion indications rather than the number of IP packets with
     congestion indications, encapsulators and decapsulators ought to
     approximately preserve the proportion of PDUs with congestion
     indications arriving and leaving.  See RFC 7141 [RFC7141] for further
     discussion.

Would something like that text work?

Thanks, --David

-----Original Message-----
From: Bob Briscoe <[e-mail]> 
Sent: Tuesday, March 23, 2021 7:24 PM
To: Black, David; Jonathan Morton
Cc: Markku Kojo; Joe Touch; Markku Kojo; [e-mail]; [e-mail]
Subject: ecn-encap-guidelines reframing section


[EXTERNAL EMAIL] 

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/