Re: [tsvwg] Moving the ECN Encapsulation drafts forward ...

[Sebastian Moeller <[e-mail]>]

Hi Bob,


> On Jul 12, 2022, at 13:49, Bob Briscoe <[e-mail]> wrote:
> 
> Sebastian,
> 
> On 12/07/2022 11:52, Sebastian Moeller wrote:
>> Hi David,
>> 
>> 
>>> On Jul 8, 2022, at 23:18, Bob Briscoe <[e-mail]> wrote:
>>> 
>>> David,
>>> 
>>> Thanks for proposing new text that just states the two contrary positions.
>>> 
>>> Jonathan's right that you haven't correctly captured his opinion (altho' I assume you intended to).
>>> I've explained and commented on your text inline, tagged [BB].
>>> 
>>> Even if you capture Jonathan's opinion correctly, I detect from his response that he is still proposing that the draft only states his view, with no compromise.
>>> So you may not have achieved any better consensus anyway.
>>> 
>>> Let me know what the Chairs believe the WG is saying ought to be written into the draft, now you have all these comments.
>>> 
>>> 
>>> On 07/07/2022 16:26, Jonathan Morton wrote:
>>>>> On 6 Jul, 2022, at 8:13 pm, Black, David <David.Black=[e-mail]> wrote:
>>>>> 
>>>>> Beyond that, mentioning the two approaches that have been discussed without offering guidance could help implementers figure out "where to dig", so here's an initial attempt at replacement text:
>>>>> Where framing boundaries do not necessarily align
>>>>> with packet boundaries, ECN markings SHOULD be propagated
>>>>> from layer-2 frame headers to IP packets that may have different
>>>>> boundaries as a consequence of payload segmentation and
>>>>> reassembly for IP forwarding.
>>>>> Two possible implementation approaches to propagating congestion
>>>>> indications are packet counting (e.g., proportion of IP PDUs sent with
>>>>> congestion indications approximately matches the proportion of layer-2
>>>>> frames received with congestion indications) and byte counting (e.g.,
>>>>> number of payload bytes in IP PDUs that have congestion indications
>>>>> is approximately equivalent to the number of bytes in layer-2 frames
>>>>> received with congestion indications).
>>> [BB]
>>> 1) "Two possible" avoids saying that they are incompatible. I think it's best to say it how it is.
>> [snipped here because this is addressed at the idea of having two "incompatible" methods proposed]
>> 
>> 	[SM] I respectfully disagree, an RFC should not propose two incompatible methods/implementations. I consider this to be really fundamental, the endpoints are supposed to interpret the "congestion signal" from the network and act appropriately, a requirement that will work much better if the network employs unambiguous behavior in creating and handling such marks. I understand that real life implementations might differ from an RFC's SHOULD (and that is fine) but I would think it wise for the RFC to not sow the seeds of confusion by proposing incompatible implementations. So IMHO if we can not come to an agreement we are indeed better off by not mentioning any method at all because that would be less confusing.
> 
> [BB2] That's why I proposed the method that includes both byte-counting and a timeout,

	[SM2] This is why I proposed an alternative that does not require a timer/time-out and an accumulating counter. IMHO this needs to be simple and efficient, otherwise no one is going to bother doing this.


> in order to address both sides of the disagreement.

	[SM2] No, my point is we should not have a disagreement here...

> But unfortunately there is such mistrust on this list, that David has had to suggest a way forward where the disagreement is just documented, so that the rest of the draft can be published.

	[SM2] This is IMHO not a matter of trust. An RFC should not recommend two incompatible methods ever. Having alternative methods is fine, but you yourself classified the two approaches as incompatible, and that is something that does not belong in a standard document.


> I would add that the rest of this draft involved a huge amount of work and help from the 3GPP community and the IEEE community, and they were keen to see the IETF publish it (as well as the dependent sister draft rfc6040bis-shim, which is stds track). The issue of reframing is in a corner that is not relevant for most of the readership of this draft.

	[SM2] Understandable, but IMHO not a convincing argument for "standardizing" incompatible methods here. If we can not agree on either compatible alternatives or a single self-consistent recommendation then I think we need to drop both and give no guidance at all.


Regards
	Sebastian

> 
> 
> 
> Bob
> 
>> 
>> Regards
>> 	Sebastian
>> 
>> 
> 
> -- 
> ________________________________________________________________
> Bob Briscoe http://bobbriscoe.net/