Re: [tcpm] 2nd WGLC for draft-ietf-tcpm-rfc8312bis

[Bob Briscoe <[e-mail]>]

Joe,

On 23/02/2022 15:17, [e-mail] wrote:
> Hi, Bob (et al.),
>
>> On Feb 21, 2022, at 4:11 PM, Bob Briscoe <[e-mail]> wrote:
>>
>> Yoshi, Markku,
>>
>> Many of the technical points Markku raised were important omissions 
>> from the rfc8312bis draft. Whatever status we give the eventual RFC, 
>> they should be highlighted as areas that need further work, either 
>> known weaknesses or just areas where we don't have enough data to 
>> know whether they are weaknesses. I tried to help find useful 
>> references for experiments already done around those points, and I 
>> tried to help write such text.
>>
>> However, I cannot agree with some of Markku's statements about process.
>>
>>
>>       #1: The rules can change
>>
>> ...
>>
>>
>>       #2: There is no TCP-compatibility requirement
>>
>> Yes, CUBIC is not TCP-compatible. But that's a feature, not a bug. 
>> Words like 'TCP-compatible' or 'fair' sound nice, but do not be 
>> fooled into thinking that an RFC recommends or requires you to behave 
>> in a certain way just because it has used a nice-sounding word for it.
>>
>> For an RFC to recommend or require something, it has to say SHOULD or 
>> MUST. So when BCP 41 [RFC2914] defines 'TCP-compatible', and talks 
>> about what is necessary to be 'fair', it implies nothing about 
>> whether you should or must be TCP-compatible, or fair; unless it 
>> actually says you SHOULD or MUST be TCP-compatible, or fair. *No RFC 
>> says that.*
>
> RFC 5681 "*TCP Congestion Control**”***(standards-track) says 
> (emphasis mine below):
>
> 3 <https://datatracker.ietf.org/doc/html/rfc5681#section-3>. 
> Congestion Control Algorithms
>
>     This section defines the four congestion control algorithms: slow
>     start, congestion avoidance, fast retransmit, and fast recovery,
>     developed in [Jac88  <https://datatracker.ietf.org/doc/html/rfc5681#ref-Jac88>] and [Jac90  <https://datatracker.ietf.org/doc/html/rfc5681#ref-Jac90>].  In some situations, it may be
>     beneficial for a TCP sender to be more conservative than the
>     algorithms allow; however, a T*CP MUST NOT be more aggressive than the following algorithms allow 
> (that is, MUST NOT send data when the value of cwnd computed by the 
> following algorithms would not allow the data to be sent)*.
>
> That looks like a MUST that defines fairness to me.

[BB] Nice point. I usually consider that requirements in an RFC mandate 
what implementers have to do to claim compliance with that RFC. But this 
one does indeed seem to be setting its reach much wider, to any 
implementation of the TCP protocol, not just implementations of this CC.

If that is how we are meant to read it, it contradicts BCP 133 [RFC5033] 
that I quoted earlier. So, I guess people will pick which one they prefer.

As far as implementation compliance is concerned, hardly any TCP 
implementation in use complies with this mandate any more. And even at 
the time it was published (2009), it already wasn't being followed by 
many/most Windows and Linux machines (Compound and Cubic were introduced 
in 2006). I notice this wording was added in RFC2581 (1999), so the 
non-compliance crept up on the IETF, and by republishing these words 
unchanged, I guess this looks like the IETF perpetuating a pious hope 
that TCPs will comply.

So, if we do make CUBIC PS, it will need to update this para in RFC5681.



Bob

>
> Joe
>

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/