Re: [rmcat] "Soup Nazi" RTP Congestion Control

["Fred Baker (fred)" <[e-mail]>]

On May 28, 2013, at 11:40 AM, Kevin Gross <[e-mail]<mailto:[e-mail]>> wrote:

I don't know where you get the idea that codel drops packets in bursts. It drops one packet per "interval". "Interval" starts at 100 ms and is reduced slowly (71, 58, 50, 45 ms...) until congestion abates. Codel is effective on TCP flows because the loss happens promptly, not because the loss is substantial.

Codel is designed to be applied on a per-hop basis. I don't see how it can be applied at a receiver for an end-to-end connection as you are apparently proposing and still behave as generally intended by its inventors.

I was scratching my head on that as well.

In context, you would do well to also consider PIE:

http://tools.ietf.org/html/draft-pan-tsvwg-pie
  "PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem",
  Rong Pan, Preethi Natarajan, Chiara Piglione, Mythili Prabhu, 10-Dec-12

It has the same caveat, of being designed to operate hop by hop. CoDel specifically talks about dropping, and Van will tell you he's not fond of ECN, but IMHO it could be applied to ECN as well. The PIE draft explicitly mentions ECN marking as a possibility. That would feed into

https://tools.ietf.org/html/rfc6679
6679 Explicit Congestion Notification (ECN) for RTP over UDP. M.
     Westerlund, I. Johansson, C. Perkins, P. O'Hanlon, K. Carlberg.
     August 2012. (Format: TXT=148560 bytes) (Status: PROPOSED STANDARD)

In short, ECN is intended to trigger a TCP/SCTP sender to reduce its effective window a bit. RFC 3168 says "do the same thing you would in the event of loss", which for loss-triggered TCPs (newReno, CUBIC) means to either set it to some value (used to be one), multiply it by some fractional value (1/2, 7/8, or whatever), or reset it to the last value that didn't result in such a trigger. I would expect that in the RTP context it might insert some form of seder traffic shaping/pacing (if one presumes that a codec has certain mean and maximum rates, it might default to allowing the sender to send at its maximum rate, and might when told to reduce the rate in the direction of the mean - and if the mean is still too quick, ask the application to reduce its rate by changing codecs).


Kevin Gross
[phone]
Media Network Consultant
AVA Networks - www.AVAnw.com<http://www.avanw.com/>, www.X192.org<http://www.x192.org/>


On Sat, May 25, 2013 at 5:04 PM, Dan Weber <[e-mail]<mailto:[e-mail]>> wrote:
Hi guys,

I've been reviewing CoDel, and it's clear how it works reasonably well for TCP.  It's only slightly more complicated than an implementation using a fixed timestamp per packet expiration.  The minor difference occurs when it goes into its dropping state which uses a square root scaling factor for the time based on the number of previously dropped packets in a sequence.  This takes advantage of a known behavior of TCP congestion control algorithms which expect congestion to happen in large bursts.

When applied to RTP unknowingly, the behavior could be pretty disastrous on video content.  Although I doubt it's any worse than actual competing content with no AQM, a particular case does stand out.  When CoDel is in place where there is no competing traffic and the RTP sender bursts the wire without pacing in respect to maximum stream bitrate, CoDel is likely to burst drop packets because of overflow on the queue time.  I think this behavior is extremely desirable.  This will bring awareness to all vendors and implementors that their implementations were working despite the fact that they were improper.

This kind of behavior can be enhanced and augmented in a way that can be used to expedite the implementation of effective RTP Congestion Control.   If we were to implement receiver side CoDel for dropping "frames" or "messages" of RTP packets on new implementations, we could become the "Soup Nazi" and start effectively identifying improper implementations as well as rendering them inoperable.  If implemented by one of the major WebRTC browser implementations, a chain reaction may develop that forces implementation of RTP congestion control up the pipeline.  If useful feedback is delivered back to the sender, which really needs to be net translated to frames processed and frames dropped, an application with its encoder could reasonably adjust.  This may solve fairness related problems because the receiver could identify if the sender overflowed the queues by evaluating actual arrival time compared with frame presentation time (converted RTP timestamps).  If the receiver enforces this constraint, fairness on RTP streams is effectively in force because implementations are rendered inoperable, and it works safely within the scope of CoDel.  This implies that TCP would be only at most affected in the same way that another TCP stream would.

And finally this leads to my suggested solution for sender side congestion control.  Based on my assumption that CoDel implementation for AQM is on the horizon across routers in the next 5 to 10 years, a reasonable suggestion for RTP Congestion control may lead to CoDel over CoDel.  An enhanced version of CoDel for implementation in the RTP stack (or at the codec encapsulation layer) provides clear frame demarcation and packet mapping (frame no == packets n..m), and drops entire frames based on: an assumption (or determination) of targeted maximum bandwidth and (optional, but highly recommended) some form of ECN.  Notifications are then provided back to the application as to which frames were dropped, and the application can make the decision on how it seeks to change its behavior if at all [This combines well with the receiver based notification.  If it chooses not to, the RTP stack enforces "fairness" by degrading the application performance in full units.  A good implementation of this should use FEC to maintain a constant bitrate despite the variations of the bitrate in the underlying stream.  While it does use more bandwidth than immediately necessary it provides great stability for the stream in cooperation with both long lived TCP streams and short lived bursty streams.  It also prevents unfair competition from TCP.  In addition, it provides additional resiliency for handling intermittent packets loss from WiFi and other wireless/cellular transmissions.

I think the benefits of this solution outweigh any other that has been proposed, and solves many of the difficult challenges presented.  While I have not yet build a full working model, It should work in at least as many places as CoDel works, and much research has been done and continues to be done on how well CoDel handles fairness.

I would love to hear everyone's thoughts on this.  Please send me your feedback.

Thanks,
Dan



  *   Make things as simple as possible, but not simpler.
Albert Einstein