Subject: "Is there CC?" is the wrong question...

From: Matt Mathis <[email-masked]>
Date: Fri, 7 Mar 2014 00:20:50 -0800

The ongoing debate about tunnels and congestion control is over the wrong
question. The presence of congestion control in the tunnel is neither
sufficient nor necessary to protect the network from the tunnel.

Let me define two terms: traffic or applications are "elastic" if
increasing loss causes decreasing presented load and "regenerative" if
increasing loss causes increased load (from the sender to the loss point).
  Clearly regenerative traffic is a bad thing because it can cause "latchup"
and congestion collapse like behaviors.  You would think that regenerative
protocols would be rare, but they are not.

The problem is that it is trivial to construct applications that are
regenerative.  For example, if you use TCP to deliver low rate CBR
(constant bit rate) traffic, then the TCP retransmissions are regenerative
until the loss rate is sufficient to cause the system to fail. This sounds
like a corner case, but it is not.  Suppose you are serving 250 kb/s flows
to forty thousand individual near clients (20 mS RTT). These flows will do
a reasonable job of meeting their target rates at up to several percent
loss (I'm guessing 3%).  If I vary the load by increasing the number of
flows into a fixed 10 Gb/s shared bottleneck, the total loss rate will
suddenly spiral out of control once the aggregate target goodput exceeds
the link capacity.  The loss rate will rise until some or all of flows fail
to meet the required performance.

I point out that *every* non-throughput maximizing protocol or
application using retransmissions to implement reliable delivery has the
potential to be regenerative, because the net goodput is determined by some
other part of the system.  The presence of CC is not at all sufficient to
eliminate pathological behaviors.

As long as the tunnel does not itself do something regenerative (for
example by repairing losses to protect its payload) the tunnel does not
change the extent to which its traffic is regenerative.

Congestion control helps because it makes throughput maximizing traffic
extremely elastic, which can absorb (offset) other regenerative traffic.
 It also guarantees that at some scale all traffic will ultimately become
elastic.  However this transition is typically way beyond the point where
non-background applications are useful.   Furthermore there are other
mechanisms that can make traffic elastic, for example by users abandoning
applications when they don't work.

We have been asking the wrong question about tunnels and everything else.
The real question is "Under what condition is the traffic regenerative?" or
alternatively "Is there sufficient elastic traffic to offset the
regenerative traffic in the ensemble?  Is the regeneration sufficient to
cause latchup?   These questions are orthogonal to the presence of
congestion control.

(There is also a similar set of questions about goodput vs throughput and
useless data arriving at the receiver, again related to the strength of the
retransmission strategy and not the presence of CC.)

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat privacy and
security as matters of life and death, because for some users, they are.

---

From: Scott Brim <[email-masked]>
Date: Fri, 7 Mar 2014 09:03:18 +0000

As I understand it, the ultimate complaint is that the encapsulation
allows traffic to be routed to a part of the Internet that might never
have seen such traffic before, by using UDP to get past blocking
points (NATs, for example). I suspect the concern is that such areas
might not be able to handle even dropping a traffic load that is
normal in other parts of the Internet.

---

From: John Leslie <[email-masked]>
Date: Fri, 7 Mar 2014 06:02:57 -0500

> sufficient nor necessary to protect the network from the tunnel.

   +1

> increasing loss causes increased load (from the sender to the loss point).

   ... good to introduce terms for this distinction...

> protocols would be rare, but they are not.

   :^(

> like a corner case, but it is not.

   +1

> Suppose you are serving 250 kb/s flows to forty thousand individual near
> clients (20 mS RTT). These flows will do a reasonable job of meeting
> their target rates at up to several percent loss (I'm guessing 3%).

   3% is pretty high... :^(

> If I vary the load by increasing the number of flows into a fixed
> 10 Gb/s shared bottleneck, the total loss rate will suddenly spiral
> out of control once the aggregate target goodput exceeds the link
> capacity. The loss rate will rise until some or all of flows fail

   (having wreaked havoc in the meantime...)

> eliminate pathological behaviors.

   +1

> change the extent to which its traffic is regenerative.

   Alas, hardware tunnels frequently do regenerative stuff. :^(

> extremely elastic, which can absorb (offset) other regenerative traffic.

   "Helps" meaning avoiding congestion-collapse...

> elastic.

   That sounds overly optimistic.

> However this transition is typically way beyond the point where
> mechanisms that can make traffic elastic, for example by users
> abandoning applications when they don't work.

   (having wreaked havoc in the meantime...)

> We have been asking the wrong question about tunnels and everything
> else. The real question is "Under what condition is the traffic
> regenerative?" or alternatively "Is there sufficient elastic traffic
> to offset the regenerative traffic in the ensemble? Is the regeneration
> sufficient to cause latchup?

   At first blush, any regenerative traffic that doesn't stop repeated
transmissions fairly quickly leads to significant damage.

> These questions are orthogonal to the presence of congestion control.

   Yes. We could be in trouble even with "congestion control" on _all_
traffic if the reaction time is too slow. And certainly the presence
of congestion control on a subset of the traffic won't remove the
issue.

--
John Leslie <[email-masked]>

---

From: John Leslie <[email-masked]>
Date: Fri, 7 Mar 2014 06:05:49 -0500

Scott Brim <[email-masked]> wrote:
> points (NATs, for example).

   This actually isn't a separate issue. Indeed, encapsulation can cause
that; but plenty of other stuff causes the same thing.

> I suspect the concern is that such areas might not be able to handle
> even dropping a traffic load that is normal in other parts of the
> Internet.

   I don't understand that statment. :^(

---

From: Scott Brim <[email-masked]>
Date: Fri, 7 Mar 2014 11:24:58 +0000

> that; but plenty of other stuff causes the same thing.

A separate issue from what? Can cause what same thing?  Are you saying
the essential issue is to avoid causing congestion in a part of the
network that has never seen it before, or that that is a subset of
some larger issue, or ... ?

>    I don't understand that statment.

Let's try a Socratic approach: Why do you think it's a problem to
increase traffic in a part of the Internet, by injecting what is
considered ordinary traffic in other parts?

swb

---

From: John Leslie <[email-masked]>
Date: Fri, 7 Mar 2014 06:34:58 -0500

Scott Brim <[email-masked]> wrote:
> A separate issue from what? Can cause what same thing?

   I guess it's fair game: If I don't understand something you wrote,
you're entitled to not understand something I wrote... ;^}

   I meant simply that many things cause traffic to appear on a portion
of the Internet that hasn't seen it before.

> Are you saying the essential issue is to avoid causing congestion in
> a part of the network that has never seen it before,

   No. (I wasn't speaking to any "essential issue"; and I was largely
still saying +1 to Matt.)

> or that that is a subset of some larger issue,

   Yes.

> or ... ?

   No.

> considered ordinary traffic in other parts?

   I didn't realize I thought that...

   Nor, AFAICT, do I think that's a problem worth considering. Whatever
traffic any part of the internet sees is pretty random.

---

From: Joe Touch <[email-masked]>
Date: Fri, 07 Mar 2014 09:54:53 -0800

On 3/7/2014 12:20 AM, Matt Mathis wrote:
> The ongoing debate about tunnels and congestion control is over the
> wrong question. The presence of congestion control in the tunnel is
> neither sufficient nor necessary to protect the network from the tunnel.
>

Now you've completely lost me.

If congestion isn't increased loss due to increased load (and then CC 
isn't what you call "elastic"), what is?

I agree that TCP's CC can be at odds with its error recovery, and that 
this can be amplified if there are lots of flows that share a path, but 
that's not saying that CC failed IMO. Just that TCP doesn't to the best 
job of prioritizing CC over error recovery in some environments.

Joe

---

From: Scott Brim <[email-masked]>
Date: Fri, 7 Mar 2014 21:23:17 +0000

> still saying +1 to Matt.)

Oh. Ok. Done. Thanks.

Scott

---

From: Matt Mathis <[email-masked]>
Date: Fri, 7 Mar 2014 15:31:32 -0800

My point is that if losses are small enough where the average goodput is is
controlled by the application (and not CC) then the retransmits needed to
repair the losses INCREASE the load.

Thanks,
--MM--

On Fri, Mar 7, 2014 at 9:54 AM, Joe Touch <[email-masked]> wrote:

> that's not saying that CC failed IMO. Just that TCP doesn't to the best job
> of prioritizing CC over error recovery in some environments.
>
> Joe
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 07 Mar 2014 16:44:28 -0800

On 3/7/2014 3:31 PM, Matt Mathis wrote:
> My point is that if losses are small enough where the average goodput is
> is controlled by the application (and not CC) then the retransmits
> needed to repair the losses INCREASE the load.

No disagreement there, but IMO that just means that your reliability 
algorithm is interfering with your ability to enforce congestion control 
- and I'm not surprised it happens in TCP.

But I don't think we need to use new terms for it, and I don't think "is 
there CC?" is the wrong question. It's the right question, but often has 
the wrong answer.

Joe