<html>
<body>
Dirceu,<br><br>
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
&quot;<pre>Fairness in Packet Switching Systems</pre>&quot;, 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.
<br><br>
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. <br>
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:<br>
a) that flow rate equality isn't what governs fairness on the
Internet<br>
b) if it was, the Internet would now be utterly unbearable<br><br>
responses inline...<br><br>
At 17:07 05/04/2008, Dirceu Cavendish wrote:<br>
<blockquote type=cite class=cite cite="">Comments below...<br><br>
----- Original Message ----<br>
From: Bob Briscoe &lt;rbriscoe@jungle.bt.co.uk&gt;<br>
To: Dirceu Cavendish &lt;dirceu_cavendish@yahoo.com&gt;<br>
Cc: Matt Mathis &lt;mathis@psc.edu&gt;; iccrg@cs.ucl.ac.uk<br>
Sent: Saturday, April 5, 2008 3:42:24 AM<br>
Subject: Re: [Iccrg] Heresy following &quot;TCP:
Train-wreck&quot;<br><br>
Dirceau,<br><br>
At 21:29 04/04/2008, Dirceu Cavendish wrote:<br>
&gt;Regarding place in the network, I mean everywhere - I guess all, as
<br>
&gt;per your question.<br><br>
So then, a follow-on question is: if there are flows passing through
<br>
router R1 from a user, how does R1 take account of flows from the <br>
same user not going through R1 at all?<br><br>
IOW, I'm questioning whether the fairness question should be focused
<br>
on sharing out each link (whether between flows or users) as it has <br>
been for the last n decades, or whether that was a distraction <br>
because we should have been looking at how much traffic is crossing <br>
trust boundaries between the principals (individuals, organisations,
<br>
network operators), and how much of that traffic is causing <br>
congestion on /any/ other link. For instance, you have to be able to
<br>
bring swarmcasting (e.g. BitTorrent) into your fairness framework.<br>
<br>
&lt;dc&gt; 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.</blockquote><br>
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).<br><br>
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.<br><br>
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.<br><br>
<blockquote type=cite class=cite cite="">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.</blockquote><br>
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.<br><br>
<blockquote type=cite class=cite cite="">&nbsp;<br>
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
:-)</blockquote><br>
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 &quot;only vulnerable when there's an 'r' in the
month&quot;.<br><br>
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.<br><br>
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?<br><br>
<br><br>
Bob<br><br>
<br>
<blockquote type=cite class=cite cite="">Cheers,<br>
Dirceu<br>
&lt;/dc&gt;<br>
&nbsp;<br><br>
I think that's where Matt is going as well - moving the focus of <br>
fairness to the edges (the trust boundaries).<br><br>
<br>
Bob<br><br>
<br>
____________________________________________________________________________<br>
Bob Briscoe,
&lt;<a href="mailto:bob.briscoe@bt.com">bob.briscoe@bt.com</a>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Networks Research Centre, BT
Research<br>
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5
3RE,UK.&nbsp;&nbsp;&nbsp; +44 1473 645196 <br><br>
<br><br>
<br>
<br>
You rock. That's why Blockbuster's offering you
<a href="http://us.rd.yahoo.com/evt=47523/*http://tc.deals.yahoo.com/tc/blockbuster/text5.com">
one month of Blockbuster Total Access</a>, No Cost. </blockquote>
<x-sigsep><p></x-sigsep>
____________________________________________________________________________<br>
Bob Briscoe, &lt;bob.briscoe@bt.com&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Networks Research Centre, BT Research<br>
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5
3RE,UK.&nbsp;&nbsp;&nbsp; +44 1473 645196</body>
</html>