<html>
<body>
Dirceu,<br><br>
At 20:18 04/04/2008, Dirceu Cavendish wrote:<br>
<blockquote type=cite class=cite cite="">Bob,<br>
I agree that even if we tried hard some form of per-session fairness, a
smart application could work around it. So, effectively, we would be
pushing the problem up the protocol stack. And agree again that, in that
case, &quot;instantaneous&quot; metrics tend to make less and less sense,
once you are looking at it from an application
perspective.</blockquote><br>
Have you read this, which I assume prompted Matt's use of the word
&quot;Heresy&quot;?<br>
Flow Rate Fairness: Dismantling a Religion<br>
&lt;<a href="http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/refb/#rateFairDis" eudora="autourl">
http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/refb/#rateFairDis</a>
&gt;<br><br>
<blockquote type=cite class=cite cite="">About routers, they have the
power to serve packets however way they decide to (and can afford to) do.
With deep packet inspection, one can imagine a router &quot;sorting
packets&quot; on any protocol level, up to soap/http, etc. So, about your
differentiation between &quot;any&quot; router from a special router -
yes, a legacy router may not do unlimited deep packet processing - it
will stop somewhere in the protocol stack. In this case, there is always
the &quot;trick&quot; to work on one level up to forfeit whatever
resource management strategy is being exercised down below...<br>
</blockquote><br>
You've misunderstood my question. It's about which /location/ in the
topology you are assuming routers are at. Have a re-read of the question
below.<br><br>
<br>
Bob<br><br>
<blockquote type=cite class=cite cite="">&nbsp;<br><br>
Dirceu<br><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: Friday, April 4, 2008 12:05:07 PM<br>
Subject: Re: [Iccrg] Heresy following &quot;TCP:
Train-wreck&quot;<br><br>
Dirceau,<br><br>
Why do you want the comparison to be between /sessions/? Given sessions
are defined by identifiers taken arbitrarily many times from a large
number space.<br><br>
And are all your metrics deliberately instantaneous metrics? Or do you
think that fairness should actually be judged over time? <br><br>
And when you say that routers should have the power to share their link
capacity, do you mean any router, or only a router able to see all the
sessions of one user?<br><br>
<br><br>
Bob<br><br>
At 18:50 04/04/2008, Dirceu Cavendish wrote:<br><br>
<blockquote type=cite class=cite cite="">One more heteric coming out of
the woods. However, my disclaimer is that I sympathize with the concept
:-)<br><br>
&nbsp;<br><br>
On top of all technical difficulties, the concept of &quot;fairness&quot;
in itself is elusive. All things being equal, then one session should
have the&nbsp; same (pick one - bandwidth, transaction response time,
packet loss) than the others. The utopy of it comes from the &quot;all
things being equal&quot; part - in the Internet?<br><br>
&nbsp;<br><br>
Zeroing into the bandwidth metric, a per flow queueing would give routers
the power to share their link capacities however they find fit - WFQ,
max-min fairness, etc - independent of other factors, such as sessions
RTTs. In this scenario, and aggressive congestion control would cause its
own traffic to be spilled, so &quot;isolation&quot; of sessions would be
achieved.<br><br>
&nbsp;<br><br>
Dirceu<br><br>
----- Original Message ----<br>
From: Bob Briscoe &lt;rbriscoe@jungle.bt.co.uk&gt;<br>
To: Matt Mathis &lt;mathis@psc.edu&gt;<br>
Cc: iccrg@cs.ucl.ac.uk<br>
Sent: Friday, April 4, 2008 6:53:43 AM<br>
Subject: Re: [Iccrg] Heresy following &quot;TCP:
Train-wreck&quot;<br><br>
Matt,<br><br>
 From one heretic to another...<br><br>
0) Priority to shortest jobs<br>
In your bullet list you missed a point that I believe is the most <br>
important one: about arrivals and departures of whole flows. If you <br>
have a mix of flow activity at a shared bottleneck, some continuously
<br>
streaming and some intermittent (as we do on the Internet), you can <br>
make the intermittent flows go much much faster without hardly <br>
prolonging the completion time of the continuous flows. It's totally
<br>
unfair (and very inefficient) for the intermittent flows to get the <br>
same bit rate as the continuous flows, because their behaviour is <br>
much more multiplexable. A picture may help: <br>
&lt;<a href="http://www.cs.ucl.ac.uk/staff/B.Briscoe/presents/0801cfp/shortestJobsPriority.png" eudora="autourl">
 </a><a href="http://www.cs.ucl.ac.uk/staff/B.Briscoe/presents/0801cfp/shortestJobsPriority.png" eudora="autourl">http://www.cs.ucl.ac.uk/staff/B.Briscoe/presents/0801cfp/shortestJobsPriority.png</a>
&gt;<br><br>
If you're intrigued by how we'd move to such a world, I recently <br>
posted a bit more on this here: <br>
&lt;<a href="http://episteme.arstechnica.com/eve/forums?a=tpc&amp;s=50009562&amp;f=174096756&amp;m=703000231931&amp;r=160007441931#160007441931" eudora="autourl">
 </a><a href="http://episteme.arstechnica.com/eve/forums?a=tpc&amp;s=50009562&amp;f=174096756&amp;m=703000231931&amp;r=160007441931#160007441931" eudora="autourl">http://episteme.arstechnica.com/eve/forums?a=tpc&amp;s=50009562&amp;f=174096756&amp;m=703000231931&amp;r=160007441931#160007441931</a>
&gt;<br><br>
Now thoughts on your main points:<br><br>
1) Fair queuing<br>
Many broadband deployments already do some form of per-flow FQ <br>
(usually WFQ) at the most likely bottleneck (the broadband remote <br>
access server, BRAS). I'm less sure what common practice is in <br>
broadband cellular networks. I believe WFQ is not such an obvious <br>
choice for radio access because of the unpredictable radio link rate.
<br>
I think there are a range of schemes, some distributed at the base <br>
station and others centralised at the radio network controller
(RNC).<br><br>
Incidentally, back to the first point, I recently realised that most
<br>
deployed per-flow FQ tends to help short duration flows, by giving <br>
higher priority at the start of a flow and reducing the longer each <br>
flow continues. Altho this helps a little bit today, it's also <br>
actually a huge potential problem for the future - same problem as <br>
TCP: it still converges to the incorrect goal of sharing out bit-rate
<br>
equally for each flow at the bottleneck - tho at least at a BRAS it's
<br>
done separately per each user.<br><br>
My point about priority to shortest jobs (and your point about huge <br>
differences between no.s of flows per app) shows that flow rates need
<br>
to be /very/ unequal to be fair. So per-flow FQ embedded in the <br>
network will be fighting what we really need to do in the transport <br>
in future (tho operators would obviously turn off per-flow FQ if they
<br>
were trying to encourage the new world I'm talking about).<br><br>
<br>
2) Edge bottlenecks protecting core<br>
Although it would be nice, we can't mandate that the core be <br>
protected by bottlenecks at the edge. Technology limits &amp; economics
<br>
determine these things, not the IETF/IRTF:<br>
* At present technology trends are moving bottlenecks gradually <br>
closer to the core as access rates increase, because the newest <br>
access is now using the same technology as the core (optics) and <br>
there's nothing faster on the horizon.<br>
* However, economics always pushes the bottleneck location the other
<br>
way - outwards. The cost of a bps of logical channel capacity follows
<br>
about a square root (?) law wrt to the bandwidth of the physical pipe
<br>
in which the logical channel sits. Ie. where you need many physical <br>
cables/fibres to cover a dispersed area, the cost per bps is much <br>
greater than where each bps can be provided within a few large
pipes.<br><br>
The net effect of these two opposing forces is pushing bottlenecks <br>
inwards at the moment - particularly onto border routers. The message
<br>
of a talk I gave to a recent workshop (on photonics research and <br>
future Internet design) was that the challenge is to find ways to <br>
push complex trust-related stuff currently done at border routers <br>
outward to the edge, so we can have dumb all-optical interconnection
<br>
without electronics: <br>
&lt;<a href="http://www.cs.ucl.ac.uk/staff/B.Briscoe/present.html#0709ecoc-fid" eudora="autourl">
 </a><a href="http://www.cs.ucl.ac.uk/staff/B.Briscoe/present.html#0709ecoc-fid" eudora="autourl">http://www.cs.ucl.ac.uk/staff/B.Briscoe/present.html#0709ecoc-fid</a>
&gt;<br><br>
3) RTT fairness<br>
I'd say this is only a small part of the problem, because it's <br>
relatively easy to solve in the transport alone - e.g. FAST TCP <br>
[Jin04:FAST_TCP] ensures its dynamics are slower for longer RTTs but,
<br>
even tho it takes longer to get there, it ends up at the same rate as
<br>
competing FAST TCPs with shorter RTTs.<br><br>
<br>
Bob<br><br>
[Jin04:FAST_TCP] Cheng Jin, David Wei and Steven Low &quot;FAST TCP:
<br>
Motivation, Architecture, Algorithms, Performance&quot;, In &quot;Proc.
IEEE <br>
Conference on Computer Communications (Infocomm'04)&quot; (March,
2004)<br><br>
<br><br>
At 17:35 02/04/2008, Matt Mathis wrote:<br>
&gt;I just attended the &quot;The Future of TCP: Train-wreck or
Evolution?&quot; <br>
&gt;at Stanford last week, and it solidified my thoughts on a subject
<br>
&gt;that is sure to be controversial.<br>
&gt;<br>
&gt;I think it is time to abandon the concept of &quot;TCP-Friendly&quot;
and <br>
&gt;instead expect the network to protect itself and other users from
<br>
&gt;aggressive protocols and applications.&nbsp; For the moment I am
going to <br>
&gt;assume two mechanisms, although I suspect that there will prove to be
more.<br>
&gt;<br>
&gt;1) Deploy some form of Fair Queuing at the edges of the network.<br>
&gt;<br>
&gt;2) Protect the core by bottlenecks at the edges of the Internet.<br>
&gt;<br>
&gt;I observe that both of these mechanisms are already being <br>
&gt;implemented due to existing market forces, and the natural <br>
&gt;consequence of their implementation is to make TCP-friendliness a
<br>
&gt;whole lot less important.&nbsp; I admit that it is not clear at this
<br>
&gt;point if these two mechanisms will ultimately prove to be sufficient
<br>
&gt;to address fairness all situations, such as over loaded core <br>
&gt;routers, but I suspect that sufficient mechanisms do exist.<br>
&gt;<br>
&gt;Supporting arguments:<br>
&gt;<br>
&gt;FQ is already being deployed at the edges to solve several existing
<br>
&gt;and growing fairness problems:<br>
&gt;<br>
&gt;* Non-IETF, UDP protocols that are non-responsive.<br>
&gt;<br>
&gt;* P2P and other applications that open huge numbers of
connections.<br>
&gt;<br>
&gt;* Stock TCP is egregiously unfair when very short RTT flows compete
with wide<br>
&gt;&nbsp; area flows.&nbsp; This can be a real killer in a number of
settings such as data<br>
&gt;&nbsp; centers and university campuses.&nbsp; The symptoms of this
problem will become<br>
&gt;&nbsp; more pronounced as TCP autotuning continues to be rolled out
in Vista,<br>
&gt;&nbsp; Linux, and various BSDs.<br>
&gt;<br>
&gt;* Autotuning will also greatly magnify RFC 2309 [1] problems, since
every<br>
&gt;&nbsp; single TCP flow with sufficient data will cause congestion
somewhere in the<br>
&gt;&nbsp; network.&nbsp; At the very least this will gradually force the
retirement of<br>
&gt;&nbsp; drop-tail equipment, creating the opportunity for RED and/or
FQ.&nbsp; Since RED<br>
&gt;&nbsp; by itself is insufficient to solve the other fairness
problems, it will not<br>
&gt;&nbsp; be the first choice replacement.<br>
&gt;<br>
&gt;I should note that &quot;Fair Queuing&quot;is overly specific.&nbsp;
The network <br>
&gt;needs to do something to large flows to prevent them from <br>
&gt;overwhelming smaller flows and to limit queue occupancy.&nbsp; FQ is
one <br>
&gt;way, but there are others.<br>
&gt;<br>
&gt;If you have ever shared a drop-tail home router with a teenager, you
<br>
&gt;might have observed some of these issues first hand, as has <br>
&gt;Comcast.[2] As I understand it, some form of enforced fairness is
<br>
&gt;now part of all commercial broadband services.<br>
&gt;<br>
&gt;The core of the Internet is already mostly protected by bottlenecks
<br>
&gt;at the edges.&nbsp; This is because ISPs can balance the allocation
of <br>
&gt;revenue from customers between the relatively expensive access link,
<br>
&gt;its own backbone links and interconnections to other ISPs.&nbsp;
Since <br>
&gt;congestion in the core has proven to cause complaints from <br>
&gt;commercial customers (and perhaps SLA problems), most providers are
<br>
&gt;careful to keep adequate capacity in the core, and can do so pretty
<br>
&gt;easily, as long as their duty cycle models hold true.<br>
&gt;<br>
&gt;Are these two mechanisms sufficient to make TCP-friendliness <br>
&gt;completely moot? Probably not.<br>
&gt;<br>
&gt;We still have some work to do:<br>
&gt;<br>
&gt;First, stop whining about non-TCP-friendly protocols.&nbsp; The are
here <br>
&gt;to stay and they can't hear us.&nbsp; We are wasting our breath and
<br>
&gt;impeding real progress in well designed alternatives to <br>
&gt;&quot;TCP-friendly&quot;.&nbsp; This concept came from an era when
the Internet was <br>
&gt;a gentleman's club, but now it needs to be retired.<br>
&gt;<br>
&gt;Second, blame the network when the network deserves it.&nbsp; In
<br>
&gt;particular if there are drop tail queues without AQM, be very <br>
&gt;suspicious of RFC2309 problems.&nbsp; In fact every drop tail queue
<br>
&gt;without AQM should be viewed as a bug waiting to bite <br>
&gt;someone.&nbsp; Likewise remember that &quot;TCP-friendly&quot; is
extremely unfair <br>
&gt;when the RTTs are extremely different.<br>
&gt;<br>
&gt;Third, think about the hard cases: over loaded interconnects, <br>
&gt;failure conditions, etc.&nbsp; Can FQ be approximated at core <br>
&gt;scales?&nbsp; Where else are my proposed mechanisms
insufficient?&nbsp; I sure <br>
&gt;there are some.<br>
&gt;<br>
&gt;Fourth, start dreaming about what it would take to make Moore's law
<br>
&gt;apply to end-to-end protocol performance, as it does to just about
<br>
&gt;everything else in the computing universe.&nbsp; I suspect that in
some <br>
&gt;future hindsight, we will come to realize that TCP-friendly was <br>
&gt;actually a untenable position, and has held us back from important
innovations.<br>
&gt;<br>
&gt;[1] RFC2309 &quot;Recommendations on Queue Management and Congestion
<br>
&gt;Avoidance in the Internet&quot;, Bob Braden, et al.<br>
&gt;<br>
&gt;[2] Richard Bennett &quot;New and Improved Traffic Shaping&quot;
<br>
&gt;<a href="http://bennett.com/blog/index.php/archives/2008/03/27/new-and-improved-traffic-shaping/" eudora="autourl">
 </a><a href="http://bennett.com/blog/index.php/archives/2008/03/27/new-and-improved-traffic-shaping/" eudora="autourl">http://bennett.com/blog/index.php/archives/2008/03/27/new-and-improved-traffic-shaping/</a>
<br>
&gt;------------------<br>
&gt;<br>
&gt;It was a very stimulating conference!<br>
&gt;Thanks Nandita and everyone else who made it happen!<br>
&gt;--MM--<br>
&gt;-------------------------------------------<br>
&gt;Matt Mathis&nbsp;&nbsp;&nbsp;
<a href="http://staff.psc.edu/mathis">http://staff.psc.edu/mathis</a><br>
&gt;Work:412.268.3319&nbsp;&nbsp;&nbsp; Home/Cell:412.654.7529<br>
&gt;-------------------------------------------<br>
&gt;<br>
&gt;<br>
&gt;_______________________________________________<br>
&gt;Iccrg mailing list<br>
&gt;<a href="mailto:Iccrg@cs.ucl.ac.uk">Iccrg@cs.ucl.ac.uk</a><br>
&gt;<a href="http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg" eudora="autourl">
 </a><a href="http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg" eudora="autourl">http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg</a><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>
Iccrg mailing list<br>
<a href="mailto:Iccrg@cs.ucl.ac.uk">Iccrg@cs.ucl.ac.uk</a><br>
<a href="http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg" eudora="autourl">
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg</a><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><br>
____________________________________________________________________________<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 <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>