Re: [AVTCORE] [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-16

[Magnus Westerlund <[e-mail]>]

Hi,

Please see below.

Den 2016-06-14 kl. 15:20, skrev Black, David:
> In the new ECN text in Section 7, I see:
>
>    Given the above issues, implementations MAY ignore ECN-CE marks when	
>    determining if the congestion circuit breaker triggers, since	
>    excessive persistent congestion will eventually lead to packet loss	
>    that will trigger the circuit breaker.  Doing this will protect the	
>    network from congestion collapse, but might result in sub-optimal	
>    user experience for competing flows that share the bottleneck queue,	
>    since that queue will be driven to overflow, inducing high latency.
>    If this is a concern, the only current guidance is for	
>    implementations to treat ECN-CE marked packets as equivalent to lost	
>    packets, whilst being aware that this might trigger the circuit	
>    breaker prematurely in future, depending on how AQM and ECN	
>    deployment evolves.  Developers that implement a circuit breaker	
>    based on ECN-CE marks will need to track future developments in AQM	
>    standards and deployed ECN marking behaviour, and ensure their	
>    implementations are updated to match.
>
> I think "MAY" is inappropriate here - this text reads like a "SHOULD NOT"
> requirement with an explanation of what happens when something else
> is done.   Proposed rewrite:
>
>    Given the above issues, implementations SHOULD NOT ignore ECN-CE marks
>    when	determining whether to trigger the congestion circuit breaker, even	
>    though excessive persistent congestion will eventually lead to packet loss	
>    that triggers the circuit breaker.   Relying on packet loss protects the	
>    network from congestion collapse, but might result in sub-optimal	
>    user experience for competing flows that share the bottleneck queue,	
>    since that queue will be driven to overflow, inducing higher latency.
>
>    Current implementation guidance is for
>    implementations to treat ECN-CE marked packets as equivalent to lost	
>    packets, whilst being aware that this might trigger the circuit	
>    breaker prematurely in the future, depending on how AQM and ECN	
>    deployment evolves.  Developers that implement a circuit breaker	
>    based on ECN-CE marks will need to track future developments in AQM	
>    standards and deployed ECN marking behaviour, and ensure their	
>    implementations are updated to match.
>
> The original "MAY" language invites implementers to completely ignore
> ECN-CE marks, which I think is very bad advice.

So in the discussion between Mirja, the authors and me in attempting to 
resolve the discuss we ended up in MAY for a reason. We on the call 
agreed after a lengthy discussion that treating a ECN-CE mark the same 
way as a loss, is not appropriate. This despite that current in force 
specification indicate that would be the answer. However, as indicated 
in the updated text, there are a number of ongoing work that indicates 
that is not the expected actual marking behavior.

This resulted in another issue, there are no specified marking behavior 
that we define an appropriate response based on. When such a behavior is 
defined one can update circuit breaker with a well defined response to 
ECN-CE marks. So due to the lack of defined behavior we didn't see a 
possibility for using SHOULD NOT, as we can't point to what should be 
implemented. Thus we chose to propose MAY as it then is open to the 
implementation if they can find a well working response or completely 
ignore this.

So far I lack evidence for any significant deployment of ECN for RTP, 
unfortunately. This lessens the impact of this choice.

Secondly, ignoring the ECN-CE marks for a circuit breaker we believe 
will have a limited impact. If the implementation only have circuit 
breaker, i.e. no full fledged congestion controller and uses ECN, they 
can in worst case drive the buffer into the overload regime where it 
starts dropping packets. So if the flow does cause persistent congestion 
it will drive the AQM into packet drops and thus triggering of the 
circuit breaker. Yes, it will be unfair and push away responsive flows. 
But, that will happen also without ECN, is not something that the 
circuit breaker can protect against.

I hope this makes it clearer why we arrived at MAY and don't see the 
possibility to use SHOULD strength wording regarding ECN-CE marks.

Cheers

Magnus Westerlund
AVTCORE Chair.


----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------