Subject: [Tsvwg] What body is qualified to decide on Internet fairness?

From: Bob Briscoe <[email-masked]>
Date: Thu, 14 Jun 2007 13:42:28 +0100

TSVWG,

I believe most of you will now have had time to read my contribution to the 
fairness debate either the I-D or the paper in ACM CCR with similar words:
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#rateFairDis>

First I want to get a debate going around the meta-question of what body is 
qualified to decide on what the fairness goals of the Internet's resource 
sharing protocols should be.

My proposal was essentially that the IETF shouldn't decide on resource 
sharing, but it needs to decide who/what can have control through our 
protocol designs. This prompted some to respond that the TSVWG, or indeed 
the IETF as a whole, isn't really qualified to decide on questions with 
such big economic implications.

My response to start this debate is: The TSVWG has made many pronouncements 
on TCP-fairness in the past (always with the caveat that fairnes is an 
amorphous subject), so the TWSVWG is holding the baby. Now I'm asking the 
TSVWG the question "Who or what should be should be able to have policy 
control of fair resource allocation in our protocols?"

Put another way, if the IETF doesn't want to decide on this, it should make 
the decision not to decide quickly and formally, as this issue is 
fundamental to many of the problems with the Internet Architecture. But 
that would leave a vacuum open for "some other body" to decide.

I actually believe that the IETF is better structured than nearly any other 
body to ensure it reaches answers based on technical merit. However, I 
accept that the IETF doesn't have, and isn't expected to have, expertise 
when decisions require expertise in political economy.

One possible answer is that we trust in our own ability to be able to 
intelligently consult with people we trust on economics. Then the 
individuals that have always made up the IETF can come to rough consensus 
on what the TSVWG should engineer its protocols for. The alternative is to 
accept "kings and voting", quoting Dave Clark.

Bob

Brief summary of the position I suggested in the I-D (but pls read it if 
you haven't):
===========================================================================
My contribution was to say that the IETF shouldn't decide on resource 
sharing, but instead it should develop protocols to reveal the true costs 
of each user's actions - ie congestion caused to others on the same network 
and on other networks. So that each network operator can decide how much 
and whether to limit the share of these costs that each of its users 
causes. Then, the share allocated to each user of each network could 
effectively be decided by 'the invisible hand of the global market' but it 
could be overridden by social/regulatory control (e.g. universal service 
usage obligations, etc) in each jurisdiction. Jurisdictions could be 
countries or private networks connected to the Internet (e.g. "this 
University decrees that all users get equal rights to cause congestion to 
others"). All this is in the I-D. And there's proper protocol design behind 
it all (in referenced I-Ds).

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 14 Jun 2007 09:57:31 -0400

> such big economic implications.

When I think about all the work people have done on fairness mechanisms,
nearly all of it resides outside the IETF in either academic work or
products (e.g. AQMs, BW caps, etc.).  OF course, the TCP and TFRC
congestion control algorithms affect fairness, but from the IETF's
perspective it seems like we focus more on making sure they attain some
sustainable level of performance that's reasonably efficient, rather
than focusing on meeting some particular fairness concept.  Certainly
with TFRC's design fairness was more of a consideration than with TCP's
design, but the 'F' does stand for 'friendly' and is wrapped up in the
notion of TCP-compatible, which isn't quite the same as 'fair'.

So my opinion (that might be wrong) is that the IETF's goal has
implicitly been (and should continue to be) to produce efficient
protocols that don't melt down the network, but have no explicit design
goal of meeting any particular notion of fairness.

If, based on some particular concept of fairness, obtaining a fair allocation
requires protocol mechanisms that need interoperability (i.e. *not* just
AQMs, rate-limits, or other "within-a-router" goop), then that could be
work that the IETF does.  This seems like where re-ECN falls in, maybe.
But, the IETF has not, and probably should not, endorse or mandate that
transports conform to specific fairness concepts, as we have null
ability to predict how the network and its usage evolve.

Does this agree or disagree with what your position is?

-- 
Wesley M. Eddy
Verizon Federal Network Systems

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 14 Jun 2007 15:29:54 +0100

Wes,

>Does this agree or disagree with what your position is?

Well, this sort-of agrees with what I'm saying, but only by side-stepping 
the biggest issue...

I think you're heavily underplaying the sway that the implicit assumption 
of flow-rate fairness has had over everything the IETF has done. That has 
led the outcome (in terms of shares of resources) to a very distorted place 
(mainly because it ensures instantaneous equality which hugely favours 
long-running flows).

The question can be put most pointedly as: once we take that flow rate 
fairness consensus away, what fairness control do we put in TCP, which 
after all still accounts for over 90% of all traffic globally? TCP's cc 
algo is unquestionably the TSV-AREA's baby.

Bob

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 14 Jun 2007 13:44:27 -0400

> Well, this sort-of agrees with what I'm saying, but only by side-stepping 

That's what I expected :).

> (mainly because it ensures instantaneous equality which hugely favours 

This is the part I'm not sure about, and maybe this is because I wasn't
around in 1988 when some of these decisions started to be made.  I'm not
quite convinced (yet) that flow-rate fairness is the basis of all that
we've done.  It doesn't seem completely evident from the original
sources, nor is it what was achieved!  As you've pointed out, our
mechanisms have pretty bad RTT unfairness, when evaluated in the
flow-rate paradigm.  To me, it seems like this is clear evidence that
flow-rate fairness wasn't a primary goal, or it would've been better
acheived, but maybe someone with a longer beard can either verify or
correct that.  It would be interesting to hear.

> algo is unquestionably the TSV-AREA's baby.

That would be the right question if there was definite consensus that
there was both (1) a TCP basis in flow-rate fairness, and (2) a need to
remove that basis.

I'm not totally convinced of (1); in fact I fully disagree with it,
based on my understanding of source material.  In the 1988 Jacobson and
Karels paper, the end-host congestion control design is done without any
attempt at fairness.  Fairness is mentioned mainly in the section on
gateway-mechanisms, NOT end-host mechanisms.  The discovery that this
design resulted in flow-rate fairness seems to have come later in history,
and been a happy side-effect.

As for (2), if there isn't a basis, how can we remove it?  I think our
disagreement is whether flow-rate fairness is a basis or a side-effect
in TCP congestion control.  Do we agree on that?

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 15 Jun 2007 00:32:26 +0100

Wes,

At 18:44 14/06/2007, Wesley Eddy wrote:
>around in 1988 when some of these decisions started to be made.

You make it sound as if people explicitly decided to do fairness based on 
equal flow rates. I don't think there was any explicit acknowledgement that 
there was ever any other option. From my reading of the literature trail 
(see below) it was just 'obvious' at the time.

>I'm not
>sources, nor is it what was achieved!

Let's first correct your reading of Jacobson & Karels (1988) that is the 
nub of your argument.

The part about end-host mechanisms (top p10) says the gateway is stateless 
therefore it cannot know about fair shares. And it talks about two 
connections that converge to windows that each have half the available 
bandwidth.

Then the part on future work on gateways seems to contradict that, saying 
transport endpoints cannot insure [= ensure] fair sharing of capacity. 
"Only at the gateways is there enough information to control sharing and 
fair allocation."

But this and the next para are talking about future work being needed on 
/enforcement/ of fair sharing - nothing to do with whether the endpoint 
algorithms /can/ reach a fair share, but to do with whether they can be 
/made/ to. That's what the terms insuring fair sharing and controlling fair 
sharing mean here when you read it in context.

>As you've pointed out, our
>acheived,

I think you're missing the wood for the trees. The precision of the 
fairness wasn't particularly important at the time. I don't think you can 
reverse engineer what the fairness goal was from whether it was exactly 
achieved. You have to read the passing references to fairness being about 
flow rate equality (as above).

The wood (not the trees) is the thousands of papers written on mechanisms 
with network fairness goals that assume equal flow rates at a bottleneck 
are fair, without question. Whether they ignore segment sizes or RTT issues 
is NOT the issue...

The point at issue is that this whole tradition is completely broken, as 
fairness is nothing to do with rates at all. And certainly nothing to do 
with flows. You're very quickly getting the big issue lost in some side detail.

>but maybe someone with a longer beard can either verify or

I guess Raj Jain, KK Ramakrishnan and Dah-Ming Chiu are still around to ask 
- and a number of others.

---------------------------------------------------------------------------
All the rest of the mail below this line is detail to convince you I've 
done my homework. But, honestly, this really is indulging in fiddling while 
Rome burns.

I checked the sources v carefully before writing "flow rate fairness...". 
Not all are described in the potted history in my section "The Seminal 
Literature", but a lot are.

VJ's algorithm was strongly influenced by the work in Jain, KK & Chiu's 
famous DEC-TR-506 from 1987.
<http://www.cse.wustl.edu/~jain/papers/dectr510.htm>

You can trace back from that to Jain's fairness index (originally a 1984 
DEC Tech Report):
<http://www.cse.wustl.edu/~jain/papers/ftp/fairness.pdf>
which deliberately abstracts away from the metric being allocated 
(mentioning throughput,  delay, power, throughput-hop product, even income 
distribution etc).

In hindsight Jain's fairness index would be orthogonal to whether the 
metric is integrated over time or not, but there's no evidence that anyone 
was thinking of anything but instantaneous metrics - indeed the example of 
variable window flow control in SNA that they used only found the minimum 
instantaneous fairness. And certainly, equality of any metric was 
considered fair without question. In general, fairness was described among 
users, although there was a free shifting between flows and users as if 
they were broadly the same thing.

Jain's fairness index paper has a good set of refs from around 1980-1982, 
none of which take a radically different view.

That's the way people were thinking by the time we get to Jacobson & Karels 
(1988). As I explained above. I think you must have searched for "fair" 
through the text and read a bit either side of each hit. You need to read 
pp10-12 in context to find that there was no question of anything other 
than rate equality between flows at a bottleneck being the fair thing to 
do. Like all good religions, by then it wasn't even recognised as a belief. 
It was a hegemony.

One of Sally's papers written 3 years after that (1991), titled 
"Connections with Multiple Congested Gateways in Packet-Switched Networks" 
aimed to get flows to have equal rates even if one went through multiple 
bottlenecks and the other didn't, or if they had different RTTs. Removing 
RTT 'unfairness' has been quite a common goal in many many papers since, 
despite VJ's original arguments that it was a design feature.

The place where I saw the most explicitly stated shift from per-user to 
per-flow fairness was in the classic fair queuing paper (Demers, Keshav, 
Shenker). But this was 1989, after VJ. But it was in a different tradition 
starting from the edge of a network where rate fairness was evolving from 
the notion that all the outgoing shares from an access router should be 
proportional to the sizes of the incoming access links.

They explicitly argued that per-flow was a good approximation that biased 
about right towards larger servers, which got a higher share because they 
served more clients. They recognised this might encourage clients to fake 
multiple flows, but like most incentive problems, that was set aside and 
forgotten by engineers who were happy to pick up the core idea and ignore 
the security problems.

>and been a happy side-effect.

Well I hope my response above convinced you you've read it wrongly.

>in TCP congestion control.  Do we agree on that?

I'm afraid I believe you've gone completely wrong here. There's decades of 
evidence to show that the fairness goal was assumed to be about flow rate 
equality, including in Jacobson & Karels. Very much so.

Can we get back to the question? What body should decide on Internet 
fairness? Please. This is important.

Bob

---

From: Lars Eggert <[email-masked]>
Date: Fri, 15 Jun 2007 10:25:42 +0300

Hi,

On 2007-6-15, at 2:32, ext Bob Briscoe wrote:
> Can we get back to the question? What body should decide on  
> Internet fairness? Please. This is important.

it very much depends on what you mean by "decides."

If folks want to propose modifications to the Internet's existing  
protocols or new Internet protocols that are establishing a different  
fairness point, IMO the IETF is venue. (After consensus forming,  
discussion on interactions with existing protocols and traffic, etc.,  
etc.) It's a difficult chunk of work, because it touches many pieces  
of the existing system, but with sufficient motivation, the IETF  
could decide to take on this work.

However, the results will be IETF _recommendations_, as usual. And as  
usual, deployment of IETF recommendations is a different matter. In  
the end, vendors and operators need to be sufficiently convinced such  
that they decide to implement and roll out any new stuff.  
Applicability statements and similar documents by the IETF can help,  
but to get such broader architectural changes deployed, you'd IMO  
need an educational/informational campaign that the IETF doesn't have  
the expertise or the cycles for. (One key question of that campaign  
will be: how does the new fairness stuff interact with the old  
fairness stuff, since we can't have a flag day.)

Lars

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 15 Jun 2007 20:31:18 +0100

Lars,

>it very much depends on what you mean by "decides."

Well, the full 'question within a question' that I asked in the original 
posting is what I mean:

Which body should decide the question: "In the design of IETF protocols, 
who or what should be able to have policy control of fair resource 
allocation?"?

The problem is that any IETF decision that gives (or fails to give) someone 
or something control of resource allocation is a political decision. The 
solution I proposed at least allows control over who has control to be 
decided by market selection, local government regulation or similar.

Actually, Lars, I'm glad you've come in on this thread, as this question 
was in part prompted by the chat you & I had after my talk in Prague, after 
I said I intended the I-D on fairness to become a WG item (intent: 
informational) once it had gone through another round of toning down. You 
said the IETF would probably have trouble endorsing a change of this 
magnitude as it wouldn't feel competent to make a decision (correct me if 
I'm paraphrasing wrongly).

So I was left thinking that what you said was true, but the IETF would be 
somehow abdicating it's responsibility if it didn't make a decision.

So it is good to hear what you're saying below, which essentially says the 
IETF could and should handle this subject (not deciding on what is fair, 
but deciding on a policy control architecture to allow various actors to 
determine what fairness outcome we get).

>could decide to take on this work.

Good.

Under the category of "proposed modifications to existing protocols", I 
guess we have the re-ECN work, and we've got a temporary home for that in 
an informal gathering that plans to meet via a list and to meet co-located 
at IETFs (a bit like HIP started out).

Under the category of "sufficient motivation", I intended the I-D on 
fairness to be the start of that.

Now, it's clearer that this is a subject TSVWG ought to tackle, see the 
next mail thread I'm about to start "Does anyone have a defence in favour 
of flow rate fairness?"

>that they decide to implement and roll out any new stuff.

Of course. I get healthy interest when I talk about it to vendors and 
operators, but I'm aware that has to transform into more than interest.

>the expertise or the cycles for.

Yup. I'm well aware of that, and in my own small way I'm trying to get that 
started - and some influential people are stepping up to help too.

>(One key question of that campaign

Yes, there's already a section added to the 01 version of the draft in 
internet-drafts and linked above on transition. I recall discussing this on 
the list too (I think with Sally or Mark A?).

I'm about to go off-list for a week...

Thanks

Bob

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 15 Jun 2007 22:58:14 -0400

Bob: thanks for bearing with me.  It looks like we've both been through a
similar literature trail, but differed ever-so-slightly in context and
interpretation.

> with flows. You're very quickly getting the big issue lost in some side 

I fully agree with this, but the side issue is significant because the
IETF's forest of RFCs and tools only shares a few trees with all that
academic stuff!  My tack is simply that, *within the IETF* (not within another
forest -- and a dumpster -- of somewhat-related academic papers), I
don't think we've had as much of an obsession with equal flow-rates.  On
the contrary, we've conciously developed a number of things that support
or create unequal rates.  We believe in congestion control, but not
based on any religion, only based on keeping the network usable for all
legitimate purposes.

What I mean is that rather than being disciples of the flow-rate
religion in the IETF, I think we have a lot of "unitarians" who see the
merits in other ideas, and simply build protocol toolboxes that can be
used flexibly by our employers/customers/selves.  As an individual
contributor, I certainly support work on mechanisms to enable
cost-fairness, but I don't at all support trying to make it into our
single religion (not yet, at least).

We don't have RFCs that say "do flow-rate fairness, it's the end-all
be-all metric to be met, and death to all others".  Speaking as just
another individual contributor, I don't believe we should (or even need
to) be so bold as to make a statement like this about cost-fairness.  It
seems like this is what you're wrangling at.

> done my homework.

I never doubted it, and your sharing of it is certainly appreciated.  I
imagine it will happen a few more times as the related work progresses,
and hope your keyboard holds up!  Thanks immensely.

---

From: Lars Eggert <[email-masked]>
Date: Sat, 16 Jun 2007 11:29:22 +0300

Hi,

On 2007-6-15, at 22:31, ext Bob Briscoe wrote:
> Well, the full 'question within a question' that I asked in the  
> original posting is what I mean:
>
> Which body should decide the question: "In the design of IETF  
> protocols, who or what should be able to have policy control of  
> fair resource allocation?"?

Understood. That original question is actually much broader -  
bandwidth is obviously only one of the resources involved in  
transmitting across a network. Your existing drafts focus on  
bandwidth, is this still the focus are are you broadening it to any  
resource?

> The problem is that any IETF decision that gives (or fails to give)  
> someone or something control of resource allocation is a political  
> decision. The solution I proposed at least allows control over who  
> has control to be decided by market selection, local government  
> regulation or similar.

Designing a distributed algorithm that controls access to and use of  
a shared resource is hard, especially for the "dumb" Internet where  
the intelligence is only at the edge. Our current, end-system-driven  
congestion control mechanisms by and large result in a shared use of  
the network that is at least not grossly unfair. Sure, maybe it can  
be driven to the point of complete unfairness if a sufficient number  
of end systems in one region of the network decide to cheat, but  
that's because the network has little ways to enforce any sort of  
fairness.

Your proposal (which you know I find interesting) changes that very  
fundamentally. There is a policing function in the network that  
drives shared resource use towards a (market- or provider-defined)  
fairness point. That makes the problem of designing this distributed  
control system easier, because it doesn't need to be completely end- 
system-driven anymore. (Actually, it completely removes the need to  
do anything at the end system, because the policer will mangle the  
traffic an end system sends until it conforms to its current  
allotment.) But all this also means that the network absolutely needs  
to have this new policing function, which is something the Internet  
has never required.

That's a pretty big architectural change.

(Aside: For some resources - think router queues, we actually have  
designed multiple different algorithms that manage the resource. But  
that's a local resource under the control of one entity.)

> Actually, Lars, I'm glad you've come in on this thread, as this  
> question was in part prompted by the chat you & I had after my talk  
> in Prague, after I said I intended the I-D on fairness to become a  
> WG item (intent: informational) once it had gone through another  
> round of toning down. You said the IETF would probably have trouble  
> endorsing a change of this magnitude as it wouldn't feel competent  
> to make a decision (correct me if I'm paraphrasing wrongly).

My IETF week is a complete haze and I can never remember what I  
said :-) but this sounds pretty close to what I probably have said.  
Basically, having this document come out of TSVWG means that the WG  
has consensus on wanting to make this sort of informational statement  
on fairness to the wider community. I don't think we have that  
consensus yet.

> So I was left thinking that what you said was true, but the IETF  
> would be somehow abdicating it's responsibility if it didn't make a  
> decision.

Not adopting this draft *would be* a decision, too. It'd indicate  
that the WG did not have consensus to issue the informational  
statement in the draft as a WG statement.

> So it is good to hear what you're saying below, which essentially  
> says the IETF could and should handle this subject (not deciding on  
> what is fair, but deciding on a policy control architecture to  
> allow various actors to determine what fairness outcome we get).

Right. I do believe that this topic is in scope for the IETF, meaning  
probably mostly the transport area, but other areas impacted by an  
architectural change of this magnitude need to have a say as well.

> Under the category of "proposed modifications to existing  
> protocols", I guess we have the re-ECN work, and we've got a  
> temporary home for that in an informal gathering that plans to meet  
> via a list and to meet co-located at IETFs (a bit like HIP started  
> out).

Yep, I'm glad you got that set up, and as I've told you off-list, I'm  
happy to help you get a room for the informal bar-BOF meetings.

> Under the category of "sufficient motivation", I intended the I-D  
> on fairness to be the start of that.
>
> Now, it's clearer that this is a subject TSVWG ought to tackle, see  
> the next mail thread I'm about to start "Does anyone have a defence  
> in favour of flow rate fairness?"

That's a pretty confrontational way to start a consensus discussion.  
You may get the desired silence this way, but you may also generate  
silence this way when the time comes to hum for adoption. There are  
probably more productive ways of building consensus.

But let me give you the start of a defense: What we currently have is  
not ideal or optimal, but it has worked OK for a long time for many  
different network scenarios, in the sense that congestion collapse  
has been prevented and end systems can generally get a share of the  
network for their use. It's a best-effort sort of resource sharing  
that is mostly based on end-system mechanisms, which let the network  
stay dumb.

> Of course. I get healthy interest when I talk about it to vendors  
> and operators, but I'm aware that has to transform into more than  
> interest.

It'd be interesting to determine if this is because re-ECN is a much  
cheaper way to do policing? I mean, operators can police the traffic  
that an end system generates now already, but with re-ECN, the  
infrastructure cost for this should go down a lot, due to the use of  
congestion marking. What's the main features that operators like?

> Yup. I'm well aware of that, and in my own small way I'm trying to  
> get that started - and some influential people are stepping up to  
> help too.
>
> Yes, there's already a section added to the 01 version of the draft  
> in internet-drafts and linked above on transition. I recall  
> discussing this on the list too (I think with Sally or Mark A?).

Lars

PS: I'm very much agreeing with what Wes writes in his thread of  
responses - my understanding of the history in this space pretty much  
matches his.

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 17 Jun 2007 00:24:40 +0100

Wes,

At 03:58 16/06/2007, Wesley Eddy wrote:
>used flexibly by our employers/customers/selves.

Yes, in the IETF I definitely recognise more desire (and need) to allow a 
broad church than in most specific research papers. But actually the whole 
forest of research has much more diversity, and some examples have it 
within one paper.

However, over recent years, there has been a tendency for flow rate 
equality to become more of a touchstone in the IETF (esp. in DCCP profile 
work - perhaps because this w-g is more heavily populated from the academic 
community).

Thing is, when you're doing wire protocols and frameworks (like DCCP), you 
can  allow for different goals. But when you're doing algos (e.g. a DCCP 
profile itself) you're making fairness decisions.

And I don't think it can be denied that TCP fairness had been creeping in 
more and more as a goal to converge on (approximately) in the IETF. I think 
to say anything else would be revisionist re-writing of the last few year's 
at the IETF - the sort of re-write people might want to do in hindsight now 
we realise it was getting a bit like a bunch of people all clutching at the 
only belief system they had, no matter how flakey. You only have to look at 
the concerns over hi-speed cc, which were all framed in terms of TCP-fairness.

>As an individual

Let's be clear here. Cost fairness and flow rate fairness are not in the 
same set (a point made in the paper about prop fairness & weighted prop 
fairness). So making out they are alternatives is misguided.

Cost fairness isn't a set of flow rates that you can predict like flow rate 
fairness is. It is merely visibility of the costs of any particular set of 
rates.

That's why I'm trying to frame this debate not about what the commandments 
are, but about who the IETF enables to write them (ie the market, 
operators, regulators etc, vs the IETF).

It's eventually about putting a policy control parameter into 
TCP/CCID2/CCID4 etc, so the code author (and the standards author) is no 
longer in control of the outcome.

But before that, it has to be about putting in a framework to make the 
costs visible, so once you give app-writers and users that parameter, 
there's someone there who can push back to make sure they use it responsibly.

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 17 Jun 2007 01:51:05 +0100

Lars,

>bandwidth, is this still the focus are are you broadening it to any

I can't quite parse the question... bandwidth isn't a resource, it's a 
property of any particular resource. So you might mean:
i) either "broadening to any other property of resources" (like e.g. delay)
ii) or "broadening to any other resource [than wireline]" (like spectrum)

* If you meant i) other properties like delay etc, the fairness religion 
I-D has a para explaining why it's sensible to focus on bandwidth:

"While on the subject of assumptions, we should add that the benefit
of a real-time application depends on jitter, not just transfer rate.
But simple scaling arguments show that it will be possible for
network operators to minimise congestion delay as networks increase
in capacity ([SelfMan] S.2), an argument supported by recent research
showing that router buffers are often significantly
oversized [BufSizUp]."

* If you meant ii) other types of resource, see Vasilios Siris's 2002 
Mobicom paper linked from
<http://www.ics.forth.gr/netlab/wireless.html>
I thought I had ref'd it, but I hadn't - I will in -02.

This explains how to combine congestion of different resources on different 
links into a unified ECN signal at the IP layer across them. Meaning "how 
to" both technically and how to in terms of the relative weights that 
economics tells you they should have. A sentence from the abstract:

"An important feature of the framework is that it incorporates both the 
congestion for shared resources in wireless and wired networks, and the 
cost for battery power at mobile hosts."

* Or you may have meant iii) packet-congestible as well as bit-congestible 
resources. In which case, if you wait an hour or so, I'll have posted the 
I-D on that that I've been promising James (& Steve Blake because it's also 
relevant to PCN).

Nearly every resource serving the Internet layer that we see getting 
congested, whether spectrum, radio transmitter power, line capacity or 
whatever tends to be bit congestible. Resources that are packet congestible 
tend to be designed as part of a system protected by a bit congestible 
resource.

The I-D is actually about where to make allowance for packet size - network 
layer or transport. Answer: Transport.

>the network that is at least not grossly unfair.

I fundamentally beg to differ. If we're talking about comparing how much 
congestion two flows cause, TCP gives a user who runs one 10sec flow in two 
days the same rate as another user who runs one flow for 48hr while they 
are competing for the same bottleneck. Over its lifetime, the longer one 
might cause 20,000 times more congestion than the short flow. Is it not 
grossly unfair to only allow the 10sec flow an equal instantaneous rate 
(aside from the question of whether we can be fair to flows, not users, of 
course)?

What I'm getting at is that TCP /is/ turning out to be driving the system 
to gross unfairness, as certain apps have evolved to exploit the fact that 
TCP favours apps with lots of flows and apps with long running flows.

>Sure, maybe it can

All known p2p filesharing uses TCP, but it's still grossly unfair in terms 
of the amount of congestion users cause who've paid the same as other users 
who are using TCP for Web & email, say.

I'm not whinging that it's unfair personally, I'm just saying you can't say 
TCP is keeping things anywhere near fair. It's orders of magnitude more 
unfair than it needs to be (e.g. if we used Jain's fairness index with 
total user utility as the metric).

>system-driven anymore.

Yup.

>(Actually, it completely removes the need to
>allotment.)

It could do theoretically, but that's not actually what I'd recommend or 
expect. I'd recommend that a network-based policer only polices the 
envelope for the whole user, not each flow, 'cos it's not best placed to. 
Such a bulk policer merely encourages the user (or app authors) to push 
down the weight in the endpoint algo of costly (harmful) apps and push up 
the weight in the algo of cheap (benign) ones.

>But all this also means that the network absolutely needs

Yup.

>that's a local resource under the control of one entity.)

You're talking WFQ etc, I guess.

>on fairness to the wider community. I don't think we have that

See new thread I started, trying to see whether /how much people's opinions 
have moved.

>statement in the draft as a WG statement.

Understood.

>architectural change of this magnitude need to have a say as well.

Definitely int-area, given I'm proposing a field to police congestion in 
the net layer. But we need to get consensus sorted in the transport area 
that understands the issues, long before we approach the area that owns the 
bit fields :)

>happy to help you get a room for the informal bar-BOF meetings.

Cool

>probably more productive ways of building consensus.

I certainly don't desire silence. But I certainly do need advice on 
diplomacy ;)

>that is mostly based on end-system mechanisms, which let the network

In those two senses it's worked (stability and you get /a/ share). And it's 
fairly efficient at using the capacity there is. But sharing out the usage 
'properly' is actually a fairly important part of what the resource control 
system should be doing. And it's not. Big time.

I want to try to get people to understand what problems we would NOT have 
if we also had a resource control framework that wasn't orders of magnitude 
off an economic fairness optimum.

I don't think we'd have deep packet inspection boxes inferring which apps 
are overusing the Internet and throttling/blocking them. So we wouldn't 
have solely today's apps frozen into the Internet, with a block on anything 
new for tomorrow. We'd have fibre installed everywhere by now, lots more 
wireless infrastructure, etc etc, 'cos the investment incentives wouldn't 
be blown away by other businesses coming in and grabbing neaarly all the 
capacity at no cost to them. We'd have apple pie, motherhood, sweetness and 
light. I can't prove any of this, but we're kicking off some economics work 
to try to start putting some meat on these arguments.

>congestion marking. What's the main features that operators like?

It's not cheapness. DPI is actually fairly cheap in box terms.

It's more the ability to control the thing they really want to control, 
rather than having to control a load of higher layer knobs and keep running 
an arms race and keep arguing over the validity of what they're doing - 
they don't want to be fighting their customers I guess. They want to have a 
nice clean deal.

So you could put all that into management cost terms. But I don't think 
that's really it.

It's not that they would have more control - they feel they've got that 
with DPI. I think it's about control of something bigger.

>responses - my understanding of the history in this space pretty much

Well, you'll see I'm still disagreeing. I think he is (so you too are) 
underplaying the guiding influence TCP-fairness has grown into as an 
organising principle over people's thoughts. You surely can't deny that in, 
say, discussions on goals for hi-speed cc, or in the DCCP w-g.

Bob

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 18 Jun 2007 10:05:53 -0400

> say, discussions on goals for hi-speed cc, or in the DCCP w-g.

I think the organizing principle is rather "do no harm":

It was recognized that best-effort service was not going to allow
widespread voice, video, and other services to easily and usably
coexist on the Internet.  Architectures for QoS were developed in the
IETF in order to allow these applications to fruitfully blossom.

For whatever reasons, best-effort is still predominantly the only
service available for a lot of end users, so the high-rate applications
need to be deployed side-by-side with existing applications.  In
high-speed congestion control, a rule-of-thumb has been to "do no harm"
when competing against legacy TCP flows on a best-effort network
(evident in RFC 3649).  This way we don't need a flag day, and we can
safely deploy some classes of high-rate applications within the existing
mix of applications on best-effort networks.

In such heterogeneous deployment it is not a goal to be flow-rate fair
with TCP when there is ample capacity, and never has been.  However, in
a homogeneous deployment of congestion controllers on a best-effort
network, absent of malicious/devious users, flow-rate fairness is a
perfectly reasonable goal, but but this may be more appropriate to
explain in your parallel thread on defending this notion.