Subject: [conex] Notes of Nandita's original (Jul'10) review of ConEx

From: Bob Briscoe <[email-masked]>
Date: Sun, 13 Mar 2011 19:36:33 +0000

Nandita and ConEx list,

Here's a transcription and explanation of the scrawlings from my 
notebook, recording insights I got from discussing v useful review 
comments Nandita gave early in ConEx's life (27 July 2010 in 
Maastricht). We should have shared these sooner, but better late than never.

==1/ Possible entry points to introduce ConEx==

* Congestion-volume as a metric

* Downstream congestion
   - enabling traffic control at the ingress of an internetwork
   - as a customer-state-collection architecture
     (when compared with RCP/XCP/XCHOKe/AFD architecture)

Explanation:
RCP/XCP/XCHOKe/AFD and WFQ all assume an architecture where each 
forwarding box (or at least selected boxes) manages fairness between 
flows (or perhaps customers). However, fairness needs a metric that 
accumulates:
- over time (and doesn't accumulate when a customer is idle),
- over all the boxes in an internetwork that might be used by a 
customer at different times or in parallel.

Because fairness control needs this per customer state, it is more 
practical to apply control at a 'customer edge' node, rather than at 
every forwarding node. Otherwise every node has to distribute its 
state about each customer to every other node.

By exposing downstream congestion, ConEx continually carries that 
state in packets to the an ingress customer edge (policy) node. This 
could be brought to the egress instead (by ECN), but ConEx brings it 
to the ingress where engineering control can be applied before 
traffic can harm anything.

Operators use volume in a similar "state collection architecture" to 
that of ConEx. Except, volume doesn't change along a flow, whereas 
congestion-volume does, so volume is already easy to measure at the 
ingress 'customer-edge' without needing a new protocol.

==2/ Points that Nandita didn't want overlooked==

* The internetwork aspect of ConEx
Shouldn't just be mentioned as an incidental, given network 
neutrality and information asymmetry issues. Information between 
autonomous networks is central to the benefits of ConEx and should be 
brought out.

==3/ A useful(?) analogy==

* Weight inflation - motivates congestion-volume

If n users are sharing a bottleneck, they send the same volume 
whether each uses 1 TCP, or each uses 10 TCPs (ie weight=10). But the 
overall congestion is roughly 100 times greater in the latter case. 
Like monetary inflation, everyone increasing their weights just 
reduces the value of weight. Weighting ends up achieving nothing, but 
causing more and more harm.

With only volume, not congestion-volume, as a metric, there will be 
no incentive or ability to push back against this inflationary pressure.

==4/ An overlooked requirement===

* ConEx should be independent of the specific congestion signal mechanism
   (e.g. should work with QCN as well as with ECN)

To derive downstream congestion, we know it works when regular ECN is 
subtracted from ConEx. But it should also be possible to measure 
downstream congestion if the underlying link layer is signalling 
congestion backwards hop-by-hop, as in QCN.

HTH

Bob

PS. I am getting reports from some people that they cannot reply to 
my emails or forward them. If anyone has problems replying to this 
email, let me know by composing a new email to [email-masked] - 
I'm trying to diagnose the problem.

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 14 Mar 2011 14:15:24 +0100

Hi Bob and others

I am interested in some more explanation to the weight-inflation argument. Is there any document that describes this in more detail ?

Regards
Ingemar

-----Original Message-----
From: Bob Briscoe [mailto:[email-masked]] 
Sent: den 13 mars 2011 20:37
To: Nandita Dukkipati
Cc: ConEx IETF list
Subject: [conex] Notes of Nandita's original (Jul'10) review of ConEx

Snip-snip...

If n users are sharing a bottleneck, they send the same volume whether each uses 1 TCP, or each uses 10 TCPs (ie weight=10). But the overall congestion is roughly 100 times greater in the latter case. 
Like monetary inflation, everyone increasing their weights just reduces the value of weight. Weighting ends up achieving nothing, but causing more and more harm.

With only volume, not congestion-volume, as a metric, there will be no incentive or ability to push back against this inflationary pressure.

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 14 Mar 2011 17:49:20 +0000

Ingemar,

At 13:15 14/03/2011, Ingemar Johansson S wrote:
>Hi Bob and others
>
>I am interested in some more explanation to the weight-inflation 
>argument. Is there any document that describes this in more detail ?

I think there might have been a mention of it in Jon Crowcroft's 
paper on MulTCP. However, you get the same effect whether you use n 
TCPs or MulTCP with the parameter set to n.

It's basically a simple argument. If everyone is pushing to get 
through a narrow gap, the speed they get through is always the same, 
whether they all push hard, or whether they all don't. The only 
outcome of all pushing harder is to cause more bruises.

With TCP, the square root relation between window & congestion means 
that if you try to push 10x more TCPs through the same gap, 
congestion increases to reduce everyone's window to 1/10 of before. 
So by the TCP equation, congestion will have to be 100x greater (in theory).

Does that help?

Crowcroft, J. & Oechslin, P., "Differentiated End to End Internet 
Services using a Weighted Proportional Fair Sharing TCP," Computer 
Communication Review 28(3):53--69 In: April Vol.28 No.3 pp.53-69 ACM 
(July 1998)  URL: ftp://cs.ucl.ac.uk/darpa/multcp.ps.gz or 
http://www.cs.ucl.ac.uk/staff/J.Crowcroft/hipparch/pricing.html

Bob

>whether each uses 1 TCP, or each uses 10 TCPs (ie weight=10). But 
>the overall congestion is roughly 100 times greater in the latter case.
>reduces the value of weight. Weighting ends up achieving nothing, 
>but causing more and more harm.
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 14 Mar 2011 20:46:28 +0100

Hi

Found the paper thanks !(the link is broken though). 

I believe that it answers the first part, however I am looking for a bit more explanation to 
"With only volume, not congestion-volume, as a metric, there will be
 no incentive or ability to push back against this inflationary pressure"
I believe I can buy the argument but it would be good to see a better explanation somewhere.
Also, what about policing of bitrate ?

Regards
Ingemar

________________________________________
Från: Bob Briscoe [[email-masked]]
Skickat: den 14 mars 2011 18:49
Till: Ingemar Johansson S
Kopia: ConEx IETF list; Nandita Dukkipati
Ämne: RE: [conex] Notes of Nandita's original (Jul'10) review of  ConEx

Ingemar,

Does that help?

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 14 Mar 2011 21:31:28 +0000

Ingemar,

At 19:46 14/03/2011, Ingemar Johansson S wrote:
>I believe that it answers the first part, 
>however I am looking for a bit more explanation to

Well, the scenario is artificial but designed to 
illustrate a point. The users all have the same 
volume to send. If they divide it over 10 TCPs 
each, they still transfer the same volume, but 
cause 100x more congestion in the process.

So if they are volume capped it will make no 
difference to them whether they transfer using 10 
TCPs or 1. But if they are congestion-volume 
capped, they will avoid using multiple TCPs 
unless they really need to go fast (sufficiently 
to be willing to use up their quota).

>I believe I can buy the argument but it would be 
>good to see a better explanation somewhere.

Again, the scenario is designed to illustrate 
that they all get the same bit-rate whether they 
all use 1 TCP or 10. So none of them get any more 
bit-rate than the others in either case.

Bob