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

From: Dan Weber <[email-masked]>
Date: Sat, 25 May 2013 17:04:53 -0600

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

---

From: Kevin Gross <[email-masked]>
Date: Tue, 28 May 2013 12:40:40 -0600

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.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org

On Sat, May 25, 2013 at 5:04 PM, Dan Weber <[email-masked]> wrote:

> When applied to RTP unknowingly, the behavior could be pretty disastrous
> on video content.  Although I doubt it's any worse than actual competing
> 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.
>
> 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
> 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.
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 28 May 2013 19:16:42 +0000

On May 28, 2013, at 11:40 AM, Kevin Gross <[email-masked]<mailto:[email-masked]>> 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
+1-303-447-0517
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 <[email-masked]<mailto:[email-masked]>> 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

---

From: Kevin Gross <[email-masked]>
Date: Tue, 28 May 2013 13:49:59 -0600

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
+1-303-447-0517
Media Network Consultant

On Tue, May 28, 2013 at 1:16 PM, Fred Baker (fred) <[email-masked]> wrote:

>
>  On May 28, 2013, at 11:40 AM, Kevin Gross <[email-masked]> 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.
>
>
>  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
>
>  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
> +1-303-447-0517
> Media Network Consultant
> AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org<http://www.x192.org/>
>
>
>> 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
>> 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.
>>
>    - Make things as simple as possible, but not simpler.
>    Albert Einstein
>
>
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 28 May 2013 20:56:40 +0000

On May 28, 2013, at 12:49 PM, Kevin Gross <[email-masked]<mailto:[email-masked]>> 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
+1-303-447-0517
Media Network Consultant

On Tue, May 28, 2013 at 1:16 PM, Fred Baker (fred) <[email-masked]<mailto:[email-masked]>> wrote:

Kevin Gross
+1-303-447-0517<tel:%2B1-303-447-0517>
Media Network Consultant
AVA Networks - www.AVAnw.com<http://www.avanw.com/>, www.X192.org<http://www.x192.org/>

Thanks,
Dan

-----------------------------------
"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)

---

From: Dan Weber <[email-masked]>
Date: Tue, 28 May 2013 15:58:35 -0600

You're right. I made a mistake in my interpretation of this.  I missed the
part that the next drop is a solid step into the future.   drop1 = t + 100,
drop2 = drop1 + 100/sqrt(2), drop3 = drop2 + 100/sqrt(3) ...

I'm scratching my head at the words I'm looking for with regard to
fairness.  Though I would say the following situation would be unfair
utilization.

The frame rate is 30fps.  Which means net effect that media needs to be
delivered every 33ms.  Now let's say it sends the first (an I-Frame) out on
to the wire which composes of 15 packets, the expected presentation time is
3000 (90Khz clock) or 0.03333 in relative [delay adjusted] absolute time.
 By the time the frame arrives completely, it's 18000 (90khz) or 0.2 [delay
adjusted] absolute time.  The next frame arrives has a time stamp of 6000,
it composes of 6 packets, and arrives in total at 23000 (90khz) or 0.2555
absolute time.  By the time third frame comes in (ts=9000), it's arrival
time is 28000 (90khz) or 0.31111 absolute time.

Isn't there some metric we can use to qualify this behavior?  I was
thinking the CoDel control law using some comparison between expected
arrival time and actual arrival time, but I seem to have lost my thought.

Sorry on the CoDel mistake, seemed so clear at the time...

Thanks,
Dan

---

From: Dan Weber <[email-masked]>
Date: Tue, 28 May 2013 16:15:45 -0600

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) <[email-masked]> wrote:

>
>  On May 28, 2013, at 12:49 PM, Kevin Gross <[email-masked]> wrote:
>
>  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
> +1-303-447-0517
> Media Network Consultant
>>> 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.
>>>

---

From: Kevin Gross <[email-masked]>
Date: Tue, 28 May 2013 17:05:37 -0600

Looks like an oversubscribed link with bufferbloat. We've discussed
detecting/addressing this with a *delay-based* approach. CoDel and PIE are
delay-based. Maybe that's the thread you lost?

The other class of congestion control (e.g. TCP) is *loss-based* which
wouldn't work here (wouldn't start working until it was way too late).

Kevin Gross
+1-303-447-0517
Media Network Consultant

On Tue, May 28, 2013 at 3:58 PM, Dan Weber <[email-masked]> wrote:

> On Tue, May 28, 2013 at 12:40 PM, Kevin Gross <[email-masked]>wrote:
>

---

From: Dan Weber <[email-masked]>
Date: Tue, 28 May 2013 18:21:59 -0600

Well, that's probably it.  A delay based approach seems necessary for
measuring queue performance.  You can't have net queue exit time be any
longer than the intended duration of the frame otherwise the frame won't
make it there in time for presentation.  Can't you just use CoDel's method
of calculating queue performance as a metric of fairness or maybe even
something more dumbed down?  e.g. last packet of frame arrival time minus
the first RTP packet arrival time of same frame >=  lesser of 2x frame
duration or 100ms.  It's not a wonderful condition, but it says that's it's
clearly within the scope of congestion.  Yet in light of this, you might be
surprised at how many current "working" implementations can't meet that
spec, and actually depend on buffer bloat to support their poor behavior
over multiple frames.

And to be clear, my definition of congestion is "Anything that won't let me
get to the place I need to be in the time for allowed."  So if there's
heavy traffic we need to leave early, or consider getting more occupants to
ride in the HOV lane.

Thanks,
Dan

On Tue, May 28, 2013 at 5:05 PM, Kevin Gross <[email-masked]> wrote:

> detecting/addressing this with a *delay-based* approach. CoDel and PIE
> are delay-based. Maybe that's the thread you lost?
>
>> You're right. I made a mistake in my interpretation of this.  I missed
>> the part that the next drop is a solid step into the future.   drop1 = t +
>> 100, drop2 = drop1 + 100/sqrt(2), drop3 = drop2 + 100/sqrt(3) ...
>>
>>>> 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.
>>>>
>>>> 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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 29 May 2013 10:41:04 +0000

On May 29, 2013, at 1:15 AM, Dan Weber <[email-masked]> wrote:

> 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.

I dont think that is the right move. There are so many skilled receiver-side concealment algorithms that can deal with the loss of a few packets. but if you drop the entire frame, until the encoder deals with that, you will likely be in serious trouble. And you will likely have wasted all the bits you already transmitted successfully for that particular frame.

OTOH, it is true that if you miss certain header info, the remaining bits are useless for that slice/frame/GOP/etc. but do you really think that the middle boxes should investigate the bitstream in that detail? This looks to me as a non-starter.

>  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

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Wed, 29 May 2013 14:12:30 +0000

Dan,

Thanks for all the chatter your post resulted in ;-).

One of the reasons why I proposed that the initial RMCAT candidates are tested in an environment where sources are smooth (i.e., producing data at the envelope of the estimated available bit rate) is that fairness is very difficult to quantify with a variable bit rate source with arbitrary peak/instantaneous rate to average rate ratios.

Note your discussion below immediately focuses on your definition of “unfairness” by means of a 30 fps video flow example in the usual GOP framework (with an I-frame burst).

Somehow you expect the network to accommodate your bursts OR if it can’t to do something “intelligent to you” (like drop the entire frame).

[Note: Ali presented some counter-argument to this point … let me ignore that here … but I do note that Ali has performed a LOT of work in this area!]

Back in the day of IntSev, we had VBR TSPECS in which you could define your flow’s bursting via a token bucket representation (i.e., characterization) of the envelope of your expected rate variability. That is, if you characterized YOUR APPLICATION and provided “the Network” with a VBR TSPEC (via RSVP) … and that TSPEC was accepted by an end-to-end IntServ-capable network … you would have exactly what you want! However, none of this is being proposed here (IntServ/RSVP and even AQMs are somewhat out-of-scope for RMCAT – although I agree discussing them in the context of RMCAT makes sense).

Given these constraints, it appears unreasonable for the RMCAT protocol to explicitly accommodate your idea of fairness precisely because we are not assuming the ability to signal the network as to your applications bursting profile.

I think we need to get out of the situation where we consider fairness in the context of anyone’s pet-application (yours is apparently some video application running at 30 fps). The RMCAT transport protocol should be agnostic to today’s applications as possible (real-time 3D holography will be here before you know it!).

As a parting aside, video encoder vendors are quickly realizing the benefits of generating as smooth a video source as possible and to pace their output to the wire.

Off Soapbox,

Michael Ramalho

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Weber
Sent: Tuesday, May 28, 2013 5:59 PM
To: Kevin Gross
Cc: rmcat WG
Subject: Re: [rmcat] "Soup Nazi" RTP Congestion Control

You're right. I made a mistake in my interpretation of this.  I missed the part that the next drop is a solid step into the future.   drop1 = t + 100, drop2 = drop1 + 100/sqrt(2), drop3 = drop2 + 100/sqrt(3) ...

I'm scratching my head at the words I'm looking for with regard to fairness.  Though I would say the following situation would be unfair utilization.

The frame rate is 30fps.  Which means net effect that media needs to be delivered every 33ms.  Now let's say it sends the first (an I-Frame) out on to the wire which composes of 15 packets, the expected presentation time is 3000 (90Khz clock) or 0.03333 in relative [delay adjusted] absolute time.  By the time the frame arrives completely, it's 18000 (90khz) or 0.2 [delay adjusted] absolute time.  The next frame arrives has a time stamp of 6000, it composes of 6 packets, and arrives in total at 23000 (90khz) or 0.2555 absolute time.  By the time third frame comes in (ts=9000), it's arrival time is 28000 (90khz) or 0.31111 absolute time.

Isn't there some metric we can use to qualify this behavior?  I was thinking the CoDel control law using some comparison between expected arrival time and actual arrival time, but I seem to have lost my thought.

Thanks,
Dan

On Tue, May 28, 2013 at 12:40 PM, Kevin Gross <[email-masked]<mailto:[email-masked]>> 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.

Kevin Gross
+1-303-447-0517<tel:%2B1-303-447-0517>
Media Network Consultant
AVA Networks - www.AVAnw.com<http://www.avanw.com/>, www.X192.org<http://www.X192.org>

Thanks,
Dan

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Wed, 29 May 2013 16:44:39 +0200

> Back in the day of IntSev, we had VBR TSPECS in which you could define 
> your flow’s bursting via a token bucket representation (i.e., 
> characterization) of the envelope of your expected rate variability. 
> That is, if you characterized YOUR APPLICATION and provided “the 
> Network” with a VBR TSPEC (via RSVP) … and that TSPEC was accepted by 
> an end-to-end IntServ-capable network … you would have exactly what 
> you want! However, none of this is being proposed here (IntServ/RSVP 
> and even AQMs are somewhat out-of-scope for RMCAT – although I agree 
> discussing them in the context of RMCAT makes sense).
>
I would not say that discussing the effect of AQMs are out of scope for 
RMCAT. I think in the requirements it says a RMCAT solution need to work 
when AQM = true.
>
> Given these constraints, it appears unreasonable for the RMCAT 
> protocol to explicitly accommodate your idea of fairness precisely 
> because we are not assuming the ability to signal the network as to 
> your applications bursting profile.
>
+1
>
> I think we need to get out of the situation where we consider fairness 
> in the context of anyone’s pet-application (yours is apparently some 
> video application running at 30 fps). The RMCAT transport protocol 
> should be agnostic to today’s applications as possible (real-time 3D 
> holography will be here before you know it!).
>
> As a parting aside, video encoder vendors are quickly realizing the 
> benefits of generating as smooth a video source as possible and to 
> pace their output to the wire.
>
from adaptation point of view, when the congestion control algorithm is 
recommending an available bandwidth value to the encoder it should 
actually allow some headroom for "applications bursting profile" and VBR 
nature of video source.
>
> Off Soapbox,
>
> Michael Ramalho
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Dan Weber
> *Sent:* Tuesday, May 28, 2013 5:59 PM
> *To:* Kevin Gross
> *Cc:* rmcat WG
> *Subject:* Re: [rmcat] "Soup Nazi" RTP Congestion Control
>
> the part that the next drop is a solid step into the future.   drop1 = 
> t + 100, drop2 = drop1 + 100/sqrt(2), drop3 = drop2 + 100/sqrt(3) ...
>
> The frame rate is 30fps.  Which means net effect that media needs to 
> be delivered every 33ms.  Now let's say it sends the first (an 
> I-Frame) out on to the wire which composes of 15 packets, the expected 
> presentation time is 3000 (90Khz clock) or 0.03333 in relative [delay 
> adjusted] absolute time.  By the time the frame arrives completely, 
> it's 18000 (90khz) or 0.2 [delay adjusted] absolute time.  The next 
> frame arrives has a time stamp of 6000, it composes of 6 packets, and 
> arrives in total at 23000 (90khz) or 0.2555 absolute time.  By the 
> time third frame comes in (ts=9000), it's arrival time is 28000 
> (90khz) or 0.31111 absolute time.
>
> 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.
>
>
>     Kevin Gross
>
>     +1-303-447-0517 <tel:%2B1-303-447-0517>
>
>     Media Network Consultant
>
>     <http://www.X192.org>
>     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.
>
>     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
>     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
>     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.
>
>     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
>     use more bandwidth than /immediately necessary/ it provides great
>     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.
>

-- 

Zahed

==================================================
ANM ZAHEDUZZAMAN SARKER

Ericsson AB
Multimedia Technologies
Laboratoriegränd 11
97128 Luleå, Sweden
Phone +46 10 717 37 43
Fax +46 920 996 21
SMS/MMS +46 76 115 37 43
[email-masked]
www.ericsson.com

==================================================

---

From: Dan Weber <[email-masked]>
Date: Wed, 29 May 2013 09:32:04 -0600

On Wed, May 29, 2013 at 4:41 AM, Ali C. Begen (abegen) <[email-masked]>wrote:

> > 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.
>
> I dont think that is the right move. There are so many skilled
> receiver-side concealment algorithms that can deal with the loss of a few
> packets. but if you drop the entire frame, until the encoder deals with
> that, you will likely be in serious trouble. And you will likely have
> wasted all the bits you already transmitted successfully for that
> particular frame.
>
> OTOH, it is true that if you miss certain header info, the remaining bits
> are useless for that slice/frame/GOP/etc. but do you really think that the
> middle boxes should investigate the bitstream in that detail? This looks to
> me as a non-starter.
>
> My concern with this is that the application layer is often stupid.  Even
if you decide to transmit the frame, and then drop the packets towards the
end of the frame, the application should be notified of the affected frame.
 I think it' is unreasonable  to expect the application designers to be
experts on both the network layer and the application layer as well as RTP.
 Many of us speaking here have had the fortunate benefit of working on all
of these, but we're more the exception to the rule.   The mechanism that is
developed needs to have intuitive behavior for the the implementers of the
other layers so that they can adequately adjust.  We know for certain that
no mechanism that does not include feedback to the other layers is not
worthwhile in meeting RMCAT objectives.

Although, I think we can all agree that an effective congestion control
should have a clearly defined unit of work that is more application
specific.  I've used "frame" and "message" somewhat interchangeably, and I
think this puts things in the proper perspective.

Thanks,
Dan

---

From: Dan Weber <[email-masked]>
Date: Wed, 29 May 2013 09:44:19 -0600

On Wed, May 29, 2013 at 8:12 AM, Michael Ramalho (mramalho) <
[email-masked]> wrote:

>  Dan,****
>
> ** **
>
> Thanks for all the chatter your post resulted in ;-).****
>
> ** **
>
> One of the reasons why I proposed that the initial RMCAT candidates are
> tested in an environment where sources are smooth (i.e., producing data at
> the envelope of the estimated available bit rate) is that fairness is very
> difficult to quantify with a variable bit rate source with arbitrary
> peak/instantaneous rate to average rate ratios.****
>
> **
>
I'm sold on this point.  This is a paradoxical situation.  Each sender
sends data who has no real control over the underlying media stream.  When
the behavior changes, everyone thinks its their fault and beings to adjust
accordingly.  It's kind of like being in a situation where someone snapped
at you because they were having a bad day, and you take it personally
because you thought it was your doing.  In reality, you didn't know that it
was truly outside of your control, but responded anyway.  This behavior
isn't helpful, and we should do what we can to minimize it.

>  **
>
>
> Given these constraints, it appears unreasonable for the RMCAT protocol to
> explicitly accommodate your idea of fairness precisely because we are not
> assuming the ability to signal the network as to your applications bursting
> profile.****
>
> ** **
>
> I think we need to get out of the situation where we consider fairness in
> the context of anyone’s pet-application (yours is apparently some video
> application running at 30 fps). The RMCAT transport protocol should be
> agnostic to today’s applications as possible (real-time 3D holography will
> be here before you know it!).****
>
> **
>
Point taken.

>  **
> benefits of generating as smooth a video source as possible and to pace
> their output to the wire.
>
Maybe we should consider an additional RFC to present recommendations for
audio/video codec implementations on best practice behavior for support in
a real time media environment.

> ****
>
> ** **
>
> Off Soapbox,****
>
> ** **
>
> Michael Ramalho****
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Dan Weber
> *Subject:* Re: [rmcat] "Soup Nazi" RTP Congestion Control****
>
> ** **
>
> drop2 = drop1 + 100/sqrt(2), drop3 = drop2 + 100/sqrt(3) ...****
>
> ** **
>
> utilization.****
> ** **
> time is 28000 (90khz) or 0.31111 absolute time.****
>
> ** **
>
> arrival time and actual arrival time, but I seem to have lost my thought.*
> ***
>
> ** **
>
> Sorry on the CoDel mistake, seemed so clear at the time...****
>
> ** **
>
> Thanks,****
>
> Dan****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> On Tue, May 28, 2013 at 12:40 PM, Kevin Gross <[email-masked]>
> wrote:****
>
> substantial.****
> ** **
> inventors.****
> ****
> Kevin Gross****
> +1-303-447-0517****
> Media Network Consultant****
>
> AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org****
>
> ** **
>
> On Sat, May 25, 2013 at 5:04 PM, Dan Weber <[email-masked]> wrote:****
>
> Hi guys,
>
> Dan****
> ** **
>  ** **

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 30 May 2013 04:32:49 +0000

Hi Dan,

I have to agree with the other commenters. AQM in a router is fundamentally different than CC in an endpoint. AQM manages a per-hop queue to absorb bursts while avoiding persistent queues. It knows the absolute transit time of each packet through the queue and its depth, and can try to minimize either or both.

If I understand your proposal, you want the sender to treat the entire network as a big queue, using receiver feedback as a proxy for direct measurement of packet transit times through the “queue”. To get absolute transit times, the sender and receiver would need tight time sync, which seems extreme to require. (RTP has never required this, even for things which seem related to time sync like a/v (lip) sync.) Without time sync, you can only measure RTT (like RTP), which can be skewed by the reverse path. Or you can measure inter-arrival jitter (again like RTP), which can be skewed by an unknown base delay. Either way, I don’t think you get reliable measurements for the absolute queue depth/delay that CoDel or other AQMs want. If the sender acts on relative rather than absolute delays, that resembles the current RMCAT candidates rather than CoDel or other AQMs.

Regarding the “Nazi” aspect (no video for you, if you burst), I can’t tell if you were serious or just wanted “Nazi” on the Berlin agenda for laughs. I certainly laughed… :)

Mo

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Weber
Sent: Saturday, May 25, 2013 7:05 PM
To: [email-masked]
Subject: [rmcat] "Soup Nazi" RTP Congestion Control

Hi guys,

Thanks,
Dan

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 30 May 2013 20:45:46 +0000

From: Dan Weber <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 29, 2013 6:32 PM
To: "Ali C. Begen" <[email-masked]<mailto:[email-masked]>>
Cc: "Fred Baker (fred)" <[email-masked]<mailto:[email-masked]>>, rmcat WG <[email-masked]<mailto:[email-masked]>>, Kevin Gross <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rmcat] "Soup Nazi" RTP Congestion Control

On Wed, May 29, 2013 at 4:41 AM, Ali C. Begen (abegen) <[email-masked]<mailto:[email-masked]>> wrote:

My concern with this is that the application layer is often stupid.

Many would say the same thing for the transport/network layers, which is also often true.

 Even if you decide to transmit the frame, and then drop the packets towards the end of the frame, the application should be notified of the affected frame.  I think it' is unreasonable  to expect the application designers to be experts on both the network layer and the application layer as well as RTP.

Sure but you cannot solve this problem by overtaking the control of everything in your "transport" layer and then behaving the app like a small child. In my book, it is the app that sits on top of everything and all other layers have to serve the app layer. They can provide hints, feedback or whatever but it is the app layer who should make the final call.

 Many of us speaking here have had the fortunate benefit of working on all of these, but we're more the exception to the rule.   The mechanism that is developed needs to have intuitive behavior for the the implementers of the other layers so that they can adequately adjust.  We know for certain that no mechanism that does not include feedback to the other layers is not worthwhile in meeting RMCAT objectives.

No disagreement here. Feedback yes, dictation no.

Although, I think we can all agree that an effective congestion control should have a clearly defined unit of work that is more application specific.  I've used "frame" and "message" somewhat interchangeably, and I think this puts things in the proper perspective.

Thanks,
Dan

---

From: Kevin Gross <[email-masked]>
Date: Thu, 30 May 2013 18:11:46 -0600

A delay-based approach is going to need to be part of the solution because
I believe congestion control needs to work on networks with AQM and
networks without AQM. It probably can't fix the use case Dan has outlined
but we need to be sure that it doesn't do anything stupid in this case
either. The only way to avoid stupidity on a buffer-bloated network is to
pay attention to delay. It is not necessarily the case that sender and
receiver must have common clock in order to be delay sensitive. In Dan's
example, for instance, the receiver can notice the increasing gap between
the media timeline and packet arrival times.

It is probably too early to go deeper into solutions at this point but I do
think this discussion has surfaced a number of interesting requirements

   1. Support AQM networks
   2. Support buffer-bloated networks
   3. Support tail-drop networks
   4. Any solution requiring for synchronized clocks is undesirable
   5. Handle bursty flows (I think we've already discussed this and agreed
   it is eventually important but that it will not be one of our initial test
   cases)
   6. Contemplate both delay-sensitive and loss-sensitive approaches

Kevin Gross
+1-303-447-0517
Media Network Consultant

On Wed, May 29, 2013 at 10:32 PM, Mo Zanaty (mzanaty) <[email-masked]>wrote:

>  If I understand your proposal, you want the sender to treat the entire
> network as a big queue, using receiver feedback as a proxy for direct
> measurement of packet transit times through the “queue”. To get absolute
> transit times, the sender and receiver would need tight time sync, which
> seems extreme to require. (RTP has never required this, even for things
> which seem related to time sync like a/v (lip) sync.) Without time sync,
> you can only measure RTT (like RTP), which can be skewed by the reverse
> path. Or you can measure inter-arrival jitter (again like RTP), which can
> be skewed by an unknown base delay. Either way, I don’t think you get
> reliable measurements for the absolute queue depth/delay that CoDel or
> other AQMs want. If the sender acts on relative rather than absolute
> delays, that resembles the current RMCAT candidates rather than CoDel or
> other AQMs.
>
>
>