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

[Bob Briscoe <[e-mail]>]

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, in order to address both sides of the disagreement. 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.

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.



Bob

>
> Regards
> 	Sebastian
>
>

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