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

[Kevin Gross <[e-mail]>]

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.

Kevin Gross
[phone]
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, 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
>
>
>