[Iccrg] Heresy following "TCP: Train-wreck"

Mon Apr 7 23:55:07 BST 2008

Dear Bob,

Let me state one thing clearly, first of all. I am NOT disagreeing that flow rate equality as a fairness criterion has its problems. So, you do not have to be defensive, as your last paragraph below.

Second, about routing, I think you were the one who did not captured what I wanted to say - communication is always a two way process, so I take the blame as well. I understand that multiple sessions do not require diverse routes in order to "confuse" routers, so as to defeat some fairness scheme. However, one may imagine that, the same way the router of application "attachment" is able to correlate multiple session into a single application - as one of your papers mention, a core router might be able to do it, provided that all sessions follow the same path. When that is not the case, then the situation is REALLY hopeless...That is what I meant.

I believe we are in violent agreement, overall :-)...

Dirceu

----- Original Message ----
From: Bob Briscoe <rbriscoe at jungle.bt.co.uk>
To: Dirceu Cavendish <dirceu_cavendish at yahoo.com>
Cc: Matt Mathis <mathis at psc.edu>; iccrg at cs.ucl.ac.uk
Sent: Monday, April 7, 2008 3:43:31 PM
Subject: Re: [Iccrg] Heresy following "TCP: Train-wreck"

Dirceu,

I suggest everyone on this list reads John Nagle's RFC970 from 1985 - not the first half which is archaic now, but the second half on "
Fairness in Packet Switching Systems
", which introduced Fair Queuing. It's salutory reading. Fortunately descendents of that algorithm are in most consumer access servers (DSL, cable, cellular). Otherwise the Internet would be completely up the shoot. 

Admittedly FQ is also based on bogus science, but at least it's deployed to share backhaul links per-user, not per-flow. And at least many deployments use WFQ adapting its weights to be inversely proportional to the count of bytes seen in a flow. 
Fortunately, TCP is only left to arbitrate fairness where there's not too much contention (cores, campuses and enterprises). If fairness on those highly contended backhaul links had been left to TCP, the Internet would now be completely useless (as exemplified by our recent I-D draft-briscoe-tsvwg-relax-fairness-00.txt, which shows what the Internet would be like if left solely to TCP). This teaches us two things:
a) that flow rate equality isn't what governs fairness on the Internet
b) if it was, the Internet would now be utterly unbearable

responses inline...

At 17:07 05/04/2008, Dirceu Cavendish wrote:

Comments below...

----- Original Message ----
From: Bob Briscoe <rbriscoe at jungle.bt.co.uk>
To: Dirceu Cavendish <dirceu_cavendish at yahoo.com>
Cc: Matt Mathis <mathis at psc.edu>; iccrg at cs.ucl.ac.uk
Sent: Saturday, April 5, 2008 3:42:24 AM
Subject: Re: [Iccrg] Heresy following "TCP: Train-wreck"

Dirceau,

At 21:29 04/04/2008, Dirceu Cavendish wrote:
>Regarding place in the network, I mean everywhere - I guess all, as 
>per your question.

So then, a follow-on question is: if there are flows passing through 
router R1 from a user, how does R1 take account of flows from the 
same user not going through R1 at all?

IOW, I'm questioning whether the fairness question should be focused 
on sharing out each link (whether between flows or users) as it has 
been for the last n decades, or whether that was a distraction 
because we should have been looking at how much traffic is crossing 
trust boundaries between the principals (individuals, organisations, 
network operators), and how much of that traffic is causing 
congestion on /any/ other link. For instance, you have to be able to 
bring swarmcasting (e.g. BitTorrent) into your fairness framework.

<dc> The routing of TCP sessions is typically not under control of the application. Otherwise, I agree that it is difficult to enforce even the simple link level share of resources.

I don't think you've understood me. I'm not saying an app controls its routing. I'm saying an app controls which other endpoints it talks to (like BitTorrent).

I'm also saying that fairness should be the same whether an app or a user splits a flow into subflows or not. And it should be the same whether it splits its transfer activity across multiple endpoints.

I'm asserting that it is only practical to judge the fairness of a specific user using equipment at the point where that user attaches to another network, not at all the routers in the Internet through which that user's flows pass.

About BitTorrent type of applications, it would be nice to have some sort of fairness concept between these types of application, and across to other applications. But then, assuming there are N types of applications in the Internet (which I dont have to say N can be large), one would need to provide fairness definitions for N(N-1) cases.

Well, the metric (congestion volume) I gave in the paper I quoted applies for all applications, over all topologies, and over any timescale. And it's enforceable. And any form of fairness can be agreed around it among any sub-group of Internet users. And it relates correctly to fairness in real life.

So I guess the question is: where do we stop with the fairness issue. We can draw a parallel with security - how much paranoid are we about it :-)

Security paranoia isn't a parallel at all. The difference here is that there's been a huge mistake. A valid analogy would be if 'secure' had been defined to mean "only vulnerable when there's an 'r' in the month".

I'm not saying the prevailing view is merely different from mine, I'm saying flow-rate equality has been a whopping great massive 20 year long mistake.

What do you expect me to do if I've identified a mistake? Just shut up and continue to pretend I believe in the mistake? So we can continue to progress backwards, while I know which way is forwards?

Bob

Cheers,
Dirceu
</dc>

I think that's where Matt is going as well - moving the focus of 
fairness to the edges (the trust boundaries).

Bob

____________________________________________________________________________
Bob Briscoe, <bob.briscoe at bt.com >      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 

You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. 
____________________________________________________________________________
Bob Briscoe, <bob.briscoe at bt.com>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 

      ____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.  
http://tc.deals.yahoo.com/tc/blockbuster/text5.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080407/70f2459c/attachment-0001.html