Subject: [rmcat] Unfairness

From: Kevin Gross <[email-masked]>
Date: Mon, 3 Jun 2013 13:05:47 -0600

As discussed again during the conference call today. A tractable way to
define fairness is to start listing things that are clear unfair. Here's a
start on a that list.

   1. Anything that trips one of Colin's circuit breakers -
   http://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/
   2. More than a 3x* discrepancy in bandwidth allocated to competing
   streams over the same network path
   3. More than 3x* delay compared to RTT measurement performed prior to
   starting flow
   4. Less than 33%* bandwidth utilization through a network bottleneck

*All factors made up by yours truly and the number 3. All are subject to
discussion.

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

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 03 Jun 2013 21:54:46 -0400

On 6/3/2013 3:05 PM, Kevin Gross wrote:
> define fairness is to start listing things that are clear unfair. Here's
> a start on a that list.
> 
>  1. Anything that trips one of Colin's circuit breakers
>     - http://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/

For the bandwidth comparison (number 2), the relative RTTs should come
into play to ease the requirement.  Since TCP is not RTT-fair, we should
not hold the RMCAT algorithms to be either.  Of course, if they do
happen to be RTT-fair, we won't complain.  RTT-unfairness no worse
than TCP would seem just fine to me as a goal.

For the RTT measurement (number 3), I think you should specify that
both measurements are performed with the bottleneck loaded.

I don't think low bandwidth utilization (number 4) is evidence of
unfairness.  It's evidence of not being efficient/aggressive enough.

-- 
Wes Eddy
MTI Systems

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Tue, 4 Jun 2013 13:01:01 +0000

Wes,

I agree that RTT-unfairness not appreciably worse than TCP is a worthy goal. But I've got a question for you. First some background.

Given the cumulative ACK nature of TCP - we understand that there is a limit to the goodput attainable by TCP for a given (assumed i.i.d. random) error rate when the TCP session has a large RTT (as the ACKs work on RTT timeframes to keep track of how many bits are on the wire).

However, Kevin's constraint #2 explicitly states "streams on the same network path". Thus those streams have the same RTT. How does your statement "TCP is not RTT fair" even come into play - Kevin's statement only applies for streams on the same network path.

Streams on DIFFERENT paths have different RTTs ... I think we can agree that TCP isn't necessarily fair on those (primarily because the flows with short RTTs can react faster and spend a larger amount of their time at higher data rates). But that doesn't have anything to do with Kevin's constraint #2 - that sounds like a new constraint that you are proposing (fairness across streams with different RTTs).

Michael Ramalho

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wesley Eddy
Sent: Monday, June 03, 2013 9:55 PM
To: Kevin Gross
Cc: rmcat WG
Subject: Re: [rmcat] Unfairness

On 6/3/2013 3:05 PM, Kevin Gross wrote:
> As discussed again during the conference call today. A tractable way 
> to define fairness is to start listing things that are clear unfair. 
> Here's a start on a that list.
> 
>     - 
> http://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breaker
> s/  2. More than a 3x* discrepancy in bandwidth allocated to competing
>     streams over the same network path  3. More than 3x* delay 
> compared to RTT measurement performed prior to
>     starting flow
> *All factors made up by yours truly and the number 3. All are subject 
> to discussion.

For the bandwidth comparison (number 2), the relative RTTs should come into play to ease the requirement.  Since TCP is not RTT-fair, we should not hold the RMCAT algorithms to be either.  Of course, if they do happen to be RTT-fair, we won't complain.  RTT-unfairness no worse than TCP would seem just fine to me as a goal.

For the RTT measurement (number 3), I think you should specify that both measurements are performed with the bottleneck loaded.

I don't think low bandwidth utilization (number 4) is evidence of unfairness.  It's evidence of not being efficient/aggressive enough.

--
Wes Eddy
MTI Systems

---

From: Jim Gettys <[email-masked]>
Date: Tue, 4 Jun 2013 10:29:19 -0400

C
omputing "fairness" from packet streams even over the same path is really
tough in today's internet due to bufferbloat when the paths saturate; as
delay goes up, TCP's ability to "fairly" share bandwidth over that path
slows.  My understanding from a conversation with Van Jacobson is that the
responsiveness to TCP for sharing is quadratic with the delay (true TCP
wizards feel free to correct me).

So while in the very long time, TCP over the same path will average out ok,
the time scale gets very long (many seconds).  I believe we see this in the
RRUL test results over bloated paths, which plot the bandwidth for four
connections versus time.  The tests over bloated paths show wide swings of
bandwidth for the flows on very long time scales.

And since your bottleneck link today has no AQM running, you also often
see TCP synchronization effects.

Also note that reverse path utilization (at least of TCP) suffers badly in
the current world; one of the nice results of the fq_codel tests is showing
much better utilization in the return direction.

The best you can do is to design an algorithm (if needed) that works ok for
the day we get the network fixed....  In the meanwhile, if you perform
experiments to test algorithms and code, don't expect to see sane behavior
in the network (unless you are running something like fq_codel at your
bottlenecks). It won't be. Sigh....

                                                - JIm

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 04 Jun 2013 10:42:54 -0400

> Streams on DIFFERENT paths have different RTTs ... I think we can agree that TCP isn't necessarily fair on those (primarily because the flows with short RTTs can react faster and spend a larger amo…

I may have (mis)interpreted "on the same network path" to mean only
that there was a shared subpath between the set of end-to-end paths.
If the end-to-end paths are identical, then the RTTs are obviously
the same.  I'm using "path" and "subpath" in the RFC 2330 sense (a
subpath is itself a path).

-- 
Wes Eddy
MTI Systems

---

From: Kevin Gross <[email-masked]>
Date: Tue, 4 Jun 2013 11:00:47 -0600

Thanks for the discussion. It looks like there are some things I should
clarify. The fairness I'm talking about here is with respect to someone
trying to get a stream through a network path. RMCAT is going to define
some congestion control algorithm that will throttle the stream at the
sender. I look at the throttling applied to my stream and compare it to
network conditions and throttling applied to other streams. If I would
assess the throttling is either significantly too constricting or overly
generous, we have unfairness.

Where I've said "network path", I mean an end-to-end path. I appreciate
that there may be multiple paths between two ends and we'd need to detect
that to avoid false triggering some of these tests.

It is difficult to compare apples to oranges so (2) is a comparison of RTP
flows. If someone is able to contribute an unfairness statement about RTP
to TCP, please do. I am also not a TCP expert and was not able to come up
with anything easy here.

(3) is saying we won't be the sole cause of grossly increased delays
(presumably caused by bufferbloat) across the network. The RTT measurement
doesn't have to be for an unloaded path because we're trying to compare
performance with and without the new stream.

If we're looking at this from the perspective of someone originating a
stream (4) demonstrates a kind of unfairness (punishment without crime)
where less than desired bandwidth is allowed by the throttling but there's
presumably no good reason for the restriction.

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

On Tue, Jun 4, 2013 at 8:42 AM, Wesley Eddy <[email-masked]> wrote:

> > I agree that RTT-unfairness not appreciably worse than TCP is a worthy
> goal. But I've got a question for you. First some background.
> >
> > Given the cumulative ACK nature of TCP - we understand that there is a
> limit to the goodput attainable by TCP for a given (assumed i.i.d. random)
> error rate when the TCP session has a large RTT (as the ACKs work on RTT
> timeframes to keep track of how many bits are on the wire).
> >
> > However, Kevin's constraint #2 explicitly states "streams on the same
> network path". Thus those streams have the same RTT. How does your
> statement "TCP is not RTT fair" even come into play - Kevin's statement
> only applies for streams on the same network path.
> >
> > Streams on DIFFERENT paths have different RTTs ... I think we can agree
> that TCP isn't necessarily fair on those (primarily because the flows with
> short RTTs can react faster and spend a larger amount of their time at
> higher data rates). But that doesn't have anything to do with Kevin's
> constraint #2 - that sounds like a new constraint that you are proposing
> (fairness across streams with different RTTs).
> >
>
>