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

["Black, David" <[e-mail]>]

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.

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:[e-mail]] On Behalf Of Magnus Westerlund
> Sent: Tuesday, June 14, 2016 4:15 AM
> To: IETF AVTCore WG
> Cc: [e-mail]; tsvwg
> Subject: [tsvwg] WG Last Call on changes: draft-ietf-avtcore-rtp-circuit-breakers-
> 16
> 
> AVT, RTCWEB and TSVWG
> 
> This announces an additional one week WG last call (in AVT) on the
> changes done to "Multimedia Congestion Control: Circuit Breakers for
> Unicast RTP Sessions" that is intended for Proposed Standard. The last
> call concludes on the 21st of June.
> 
> So this last call is deemed necessary due to normative changes in the
> behaviour as result of the conclusions of how to resolve the Discuss
> regarding reaction to ECN markings.
> 
> If there are no issues in this additional WG last call, the draft will
> be approved for publication as it has already passed IESG review.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-16
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-circuit-breakers-16
> 
> Cheers
> 
> Magnus Westerlund
> AVTCORE WG 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]
> ----------------------------------------------------------------------