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

[Dan Weber <[e-mail]>]

I think the behavior is right if the RTP congestion control mechanism drops
the entire frame and notifies the application it wouldn't be delivered
within the appropriate time frame.  The mechanism by which it determines
this is still open for discussion.  I particularly liked the thought that
if any one packet of the frame would have to wait in the user space RTP
packet queue (i.e. while pacing) for sending and exceeded a certain
threshold (e.g. 100ms scaled down), then the entire frame should be
dropped.  This could potentially give enough benefit to the application
encoder to be notified that those N successive pictures weren't usable as
references in addition to the fact that the frames were never sent.  The
encoder could update the state for the next available encoded frame leaving
a better user experience.

Dan

On Tue, May 28, 2013 at 2:56 PM, Fred Baker (fred) <[e-mail]> wrote:

>
>  On May 28, 2013, at 12:49 PM, Kevin Gross <[e-mail]> wrote:
>
>  We should definitely keep AQM (including ECN) in mind in this work but I
> don't think this is the right place to have a PIE vs CoDel discussion.
>
>
>  I didn't intend to introduce a "vs"; my point, if anything, is to not
> limit one's thinking to CoDel, and to suggest a way that hop-by-hop AQM
> would be effectively used in RTP congestion control.
>
>   Kevin Gross
> [phone]
> Media Network Consultant
> AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org<http://www.x192.org/>
>
>
> On Tue, May 28, 2013 at 1:16 PM, Fred Baker (fred) <[e-mail]> wrote:
>
>>
>>  On May 28, 2013, at 11:40 AM, Kevin Gross <[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]> 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
>>
>>
>>
>
>  -----------------------------------
> "We are learning to do a great many clever things...The next great task
> will be to learn not to do them."
>
> - G. K. Chesterton (1874-1936)
>
>
>
>
>