Re: [CCWG] Review of draft-ietf-ccwg-rfc5033bis-03

[Eric Kinnear <[e-mail]>]

Thank you Magnus! I’ve imported each item as issues at the below links.

Much appreciated,
Eric


> On Apr 3, 2024, at 12:29 PM, Magnus Westerlund <magnus.westerlund=[e-mail]> wrote:
> 
> Hi,
>  
> I have reviewed draft-ietf-ccwg-rfc5033bis-03 and have a small number of comments.
>  
> A. Section 2:
> “Algorithms that are designed for special environments (e.g., data centers) and forbidden from use in the Internet would, of course, instead seek real-world data for those environments.”
>  
> I reacted to the use of “forbidden” in this sentence. Would not “not intended at all for use in the Internet” be a better formulation? Because forbidden want me to invoke the Protocol Police if someone ever attempted to use it. 

https://github.com/ietf-wg-ccwg/rfc5033bis/issues/109
"Forbidden" in Section 2 · Issue #109 · ietf-wg-ccwg/rfc5033bis
github.com

>  
> B. Section 3.2.2:
>  
> “Note that in many deployments, real-time traffic is directed into distinct queues via Differentiated Services Code Points (DSCP) or other mechanisms, which substantially reduces the interplay with other traffic. However, a proposal targeting Internet use MUST NOT assume that all paths support specific mechanisms.”
>  
> Although there are clearly a number of network especially access networks that do deploy and use DSCP classes for its real-time media traffic I think this sentence is misleading. I would think that the majority of the WebRTC traffic carrying audio and video will in fact not be marked or have DSCP markings that survive into the general Internet. I would at least suggest to rewrite the above first sentence to indicate that although this may occur, the CC algorithm under consideration will have to deal with this type of traffic.

https://github.com/ietf-wg-ccwg/rfc5033bis/issues/110
Indicate that a lack of DSCP is more common than we imply · Issue #110 · ietf-wg-ccwg/rfc5033bis
github.com

>  
> C. Circuit Breakers
>  
> I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.

https://github.com/ietf-wg-ccwg/rfc5033bis/issues/111
Mention circuit breakers? · Issue #111 · ietf-wg-ccwg/rfc5033bis
github.com

>  
> D. Section 5.8:
>  
> What is the verdict on RFC 6356? Is it not worth bringing this up in relation to concurrent usage? RFC 8041 do bring up additional experience with also other algorithms for MP-TCP that have been tried. I would at least claim “At the time of writing, there are no IETF standards for concurrent multipath congestion control in the general Internet.” that this sentence is factual wrong as RFC 6356 is an IETF experimental specification.  
>  
> I do think this section brings up important aspects to consider. However, it also point to some interesting challenges in reasoning and responsibility between functionalities whenmanaging different paths. Looking at the text I think we have scheduler application data, path availability checks  as well as congestion control all impacting what is happening. What is truly congestion control here?

https://github.com/ietf-wg-ccwg/rfc5033bis/issues/112
Mention RFC6356? · Issue #112 · ietf-wg-ccwg/rfc5033bis
github.com


>  
> Cheers
>  
> Magnus Westerlund
>  
>  
>  
>  
>  
>  
>  
> -- 
> CCWG mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ccwg