Subject: [Iccrg] Flow Rate Fairness: Dismantling a Religion
From: [email-masked] (Doan B. Hoang)
Date: Fri Oct 27 04:16:16 2006

My comment on Bob's paper. It is a bit long (about 2 pages)

Overall, I believe this ?cost-base fairness? approach is refreshing 
because it enlarges the scope of congestion/fairness and potentially 
opens up a better class of solutions for both network operators and 
network users.
Solutions from this approach may allow a network operator to operate its 
network effectively by separating its internal concerns from its 
external concerns. Internally, it may manage its network in any way it 
sees fit (flow rate, implicit, explicit, etc.). Externally, it has more 
freedom in providing new classes of solutions to satisfy its customers 
from the network edge (cost-based, fairness, security, mobility, etc)
Solutions from this approach may deliver network users (customers) 
proper means to deploy better strategies (in using the network) to 
deliver the required performance for their applications.
I believe that this approach deserves further exploration.
However, to make effective the argument for cost-base fairness, the 
paper should define its scope more clearly. In particular, it should 
point out that
1) Congestion and Fairness are to distinct issues.
2) One can provide a perfect solution to congestion problem without 
being fair
3) Solving ?fairness? problem might have noting to do with network 
congestion.
4) The users constitute only one part of the network congestion problem. 
Congestion occurs when the network operator do no provision network 
resources adequately, or manage their resources properly. It may occur 
when users exploit the network aggressively. It may occur as a result of 
some random events such as unpredictable traffic patterns.
5) When congestion is not caused by users, should they be penalized?

Most of the arguments for ?cost-based fairness? appear in the 
introduction of the paper hence, I mainly comment on this section. 
Further comments will be provided if necessary. Bob?s words are in quotes.

Introduction

?Relative flow rates should be the outcome of another fairness 
mechanism, not the mechanism itself?
You can say this about the outcome of everything if you stand above the 
problem and see it from a larger perspective. However, doing so is not 
always appropriate as from this enlarged problem scope, undesirable 
complexities may entail.
In this case (cost-based), it is a good position to take as we need 
better solutions for congestion control and fairness.

?The metric required to arbitrate cost fairness is simply volume of 
congestion, that is congestion times the bit rate of each user causing 
it, taken over time.?
Very reasonable metric provided that information can be collected 
accurately and timely, otherwise it can be useless.

?this isn?t just some dry academic fairness debate?
Great. Many of us academic are not dry and quite ?fair?.

?because flow rate fairness isn?t even capable of reasoning about 
questions like, ?How many flows is it fair to start between two 
endpoints? or over different routes?? or, ?..?

Flow rate fairness does not have to answer to these questions as they 
are outside of its scope.
Let me explain this. From the network operator view point, it will 
optimize its operational cost and maximize thee return for the use of 
its resources. The operation can be divided in two components: internal 
and external. Internally, it can use whatever congestion control 
mechanisms and fairness measure to maximize its performance. Externally, 
this is the job of edge devices that interface with the customers. The 
operator may monitor its customers, performs policing their traffic 
according to their SLA, or it may even play along with the customers, 
taking their welfare into account if it chooses to do so. For example, 
the network operator may take fairness among customers (or economic 
entities) into account if it thinks that would help in keeping its 
customers and raising its revenue and minimizing the cost of internal 
operation.
Here, your ?cost-based? fairness may play an interesting role. It is a 
game between network operator (edge devices) and its customers. Network 
operator tries to satisfy its customers based on its current resources 
AND prevent customers from exploit its resources unfairly. The customers 
try everything to get at least what they pay for, even to get more than 
their ?fair share? (regardless of how fairshare is defined). They may 
want to spit their flow, mark their packet favorably, etc.
Cost-based fairshare may be effective here, providing one can define the 
?cost? and its ?atomic unit cost? on which ?fairness? can be defined. 
Furthermore, there must be some rules by which customers and their 
network operator both agree upon; otherwise ?cost-based fairness? will 
encounter the same problem that ?flow-rate fairness? encountered.

?In 1997, the basis of the dominant consensus was completely undermined, 
but it didn?t even notice?
Even now we cannot describe congestion adequately due to the limitations 
of mathematics as well of our understanding of the phenomenon. A paper 
by Jean Bolot [1] deals nicely with one-bottleneck congestion and I 
stress ?one bottle-neck?. More than that, who knows!
Even now we cannot describe essential characteristics of Internet 
traffic mathematically, again partly due to the limitations of 
mathematics, partly due to the lack of measurement data!
Kelly brilliantly introduced some nice ideas from another domain to 
networks with the hope that this price-based control could apply 
effectively in the new domain. Currently, we do not even have a proper 
model of how customers behave or react to priced-based admission control 
in a large scale. Unless you can do so, network operator will not take 
it up.

?novel p2p applications have started to thoroughly exploit this vacuum 
with no guilt or shame, by just running more flows for longer?
I would not blame P2P applications. Everyone wants to get as much as 
they can out of the network legitimately. Is it true that network 
operator has been squeezing as much as they can out of their customers 
legitimately? It is here that we may provide solutions that help both sides?

?Fair allocation of rates between flows isn?t based on any respected 
definition of fairness from philosophy or the social sciences.?
Who says that our society is fair and the social sciences that go with 
it are fair? They are not. Look at the global economic situation. It is 
only fair to those who can push their wares but not others. 
Occasionally, it breaks down just like any other systems with even more 
serious consequences.

I have done some work on congestion, DiffServ, Edge-to-Edge, and 
End-to-End QoS. We may continue the discussion in this forum if it is 
?fair? to other respected researchers.

[1] Bolot, J., and Shankar, A., ?Dynamic Behaviour of Rate-based Flow 
Control Mechanisms,? ACM Computer Communication Review, 20(4): 35-49, 1990.

Cheers,

Doan

Bob Briscoe wrote:

> ICCRG folks,
>
> Here's the memo on deconstructing the Internet community's dominant 
> fairness ideology that I promised. It should appear in internet-drafts 
> shortly, but you can pull the tech report off my Web site now if you 
> prefer.
>
> To some of you it will not be anything new, but I have found that very 
> many people have got into a trap in their thinking, so I'm trying to 
> jump people out of what is actually a self-referential dogma. Concepts 
> of fairness in TCP, WFQ and so on are all afflicted with this dogma 
> which is actually way off beam relative to any reasonable views of 
> fairness in real life. It's deliberately blunt and simplified.
>
> Flow Rate Fairness: Dismantling a Religion
> <http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/2020comms/refb/fair_tr.pdf> 
>
>
> Abstract: We were moved to write this memo because the applied 
> research and standards communities in networking are using completely 
> unrealistic and impractical fairness criteria. The issue is not 
> whether they should use this or that allocation scheme; they don't 
> even allocate the right thing and they don't allocate it between the 
> right entities. We explain as bluntly as we can that sharing out flow 
> rates (as TCP and many other popular fairness mechanisms do) has no 
> intellectual heritage from any concept of fairness in philosophy or 
> social science, or indeed real life. Comparing and controlling flow 
> rates alone will never achieve fairness and should never again be 
> claimed as a fairness mechanism for production networks. Instead, a 
> realistic fairness mechanism must share out the `cost' of each users 
> actions on others.
>
> Here's the same text formatted as an I-D, but it becomes twice as long:
> <http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#rateFairDis>
>
> I may not be able to get into discussions over the next week or so, 
> given other deadlines...
>
>
> Bob
>
>
>
> ____________________________________________________________________________ 
>
> 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
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

-- 
Doan B. Hoang
University of Technology, Sydney	
URL: http://research.it.uts.edu.au/arn

From: [email-masked] (Michael Welzl)
Date: Tue Oct 24 07:58:08 2006
Subject: [Iccrg] draft-irtf-iccrg-cc-rfcs-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

Thanks a lot for your feedback!

On Mon, 2006-10-23 at 19:34, Lachlan Andrew wrote:
> Greetings Michael,
> 
> On a brief reading, this overview looks very helpful, especially to
> people like me who know very little of the RFC literature.  (Others
> who know that literature better may be able to comment on what if
> anything is missing.)

Great to hear that! And yep, others *should* comment if
anything is missing - folks, please take a look!

> It may be useful to expand section 3.  At least mentioning RFC 2001
> would seem reasonable.  Also, even an un-annotated list of subsequent

Agreed - Wesley, let's do this in our next update.

> congestion-related RFCs would be useful.  References to the IETF
> schemes you mention (HS-TCP, H-TCP, limited slow start) would be
> appropriate, especially those like H-TCP which are not mentioned in
> RFC 4614.  There is also a case for including references to the

We didn't include an IETF reference for H-TCP because it's
just a draft, and we decided to exclude drafts for now.

> non-IETF schemes (FAST, BIC/CUBIC, STCP); it could be argued that if
> they're worth mentioning, they're worth citing.

... or remove them altogether  :)   Not 100% sure what's the
better choice here... citing them makes sense, but then again,
why cite only mechanisms 1-4 and not 5-8? I'm not sure I want
to go down that road... a solution might be to cite an overview
from our bibliography and avoid mentioning names of mechanisms.

What do the others think?

Cheers,
Michael

From: [email-masked] (Doan B. Hoang)
Date: Tue Oct 24 01:38:24 2006
Subject: [Iccrg] Meeting agenda (really! :-) )
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Michael Welzl wrote:

>>As I pointed out in one of the previous emails that everyone is tired of 
>>all the TCP variants
>>which are mostly useless or of dubious value and the someone else is 
>>summarizing all these
>>variants!!!
>>
>>I sugest that we think up a list of approaches that have not been tried 
>>before with a short
>>discussion on each item on the list. It does not matter how peculiar the 
>>approaches that we
>>come up. I believe this is more exciting than another summary or survey, 
>>yet potentially
>>opens up new solutions (or no go solutions). For example, the 
>>"cost-based" approach promoted by Bob Briscoe
>>is one.
>>    
>>
>
>I agree about doing something else than just a survey,
>but I'd find it hard to do a list of things that have
>not been done before at all (heck, if I knew any good
>ones, I'd do them myself  :-)   ). In fact, while I
>like the "cost based" approach a lot and think that
>Bob's work looks truly interesting, it's not in the
>category of "work that hasn't been tried before".
>  
>
True. We all would like to try them ourselves. That is exactly what we 
want to germinate: new
ideas. There is no harm in asking questions that you do not know the 
answer. What
is valuable is that you can provide the basis on which your question is 
based upon.
For example, if there are so many TCP variants then there must be 
something fundamentally
wrong with it? and if there is a cure then one of the variants must have 
done it long time ago?
TCP congestion control needs or deserves a major fix? and where should 
it be fixed?
A devil advocate if you like.

>1. there's all this work on congestion pricing,
>the mackie-mazon auction scheme and so on ...
>  
>
These may not be new but they cross-fertilize. Kelly's work is just that.

>2. there's Bob's own work  :)
>  
>
Good for a debate at the February meeting? Stirring few people up?

>I think that the list that Keshav asked me to start
>with is a good idea. Now I just need to find the time
>(enough time to also clear my head a little bit before
>I get started with this... I really need a fresh mind
>  
>
Yes, the time!

>for it)
>
>Cheers,
>Michael
>  
>

-- 
Doan B. Hoang
University of Technology, Sydney	
URL: http://research.it.uts.edu.au/arn

From: [email-masked] (Lachlan Andrew)
Date: Mon Oct 23 18:36:00 2006
Subject: [Iccrg] draft-irtf-iccrg-cc-rfcs-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Michael,

On a brief reading, this overview looks very helpful, especially to
people like me who know very little of the RFC literature.  (Others
who know that literature better may be able to comment on what if
anything is missing.)

It may be useful to expand section 3.  At least mentioning RFC 2001
would seem reasonable.  Also, even an un-annotated list of subsequent
congestion-related RFCs would be useful.  References to the IETF
schemes you mention (HS-TCP, H-TCP, limited slow start) would be
appropriate, especially those like H-TCP which are not mentioned in
RFC 4614.  There is also a case for including references to the
non-IETF schemes (FAST, BIC/CUBIC, STCP); it could be argued that if
they're worth mentioning, they're worth citing.

$0.02
Lachlan

On 23 Oct 2006 08:19:23 +0200, Michael Welzl <[email-masked]> wrote:
> The amount of feedback that we received in response to the
> email below was close to zero. Could you please take a look
> at it and tell us what you think?

> > It's available
> > at http://www.ietf.org/internet-drafts/draft-irtf-iccrg-cc-rfcs-00.txt

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603

From: [email-masked] (Michael Welzl)
Date: Mon Oct 23 16:42:56 2006
Subject: [Iccrg] Meeting agenda (really! :-) )
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> As I pointed out in one of the previous emails that everyone is tired of 
> all the TCP variants
> which are mostly useless or of dubious value and the someone else is 
> summarizing all these
> variants!!!
> 
> I sugest that we think up a list of approaches that have not been tried 
> before with a short
> discussion on each item on the list. It does not matter how peculiar the 
> approaches that we
> come up. I believe this is more exciting than another summary or survey, 
> yet potentially
> opens up new solutions (or no go solutions). For example, the 
> "cost-based" approach promoted by Bob Briscoe
> is one.

I agree about doing something else than just a survey,
but I'd find it hard to do a list of things that have
not been done before at all (heck, if I knew any good
ones, I'd do them myself  :-)   ). In fact, while I
like the "cost based" approach a lot and think that
Bob's work looks truly interesting, it's not in the
category of "work that hasn't been tried before".

1. there's all this work on congestion pricing,
the mackie-mazon auction scheme and so on ...

2. there's Bob's own work  :)

I think that the list that Keshav asked me to start
with is a good idea. Now I just need to find the time
(enough time to also clear my head a little bit before
I get started with this... I really need a fresh mind
for it)

Cheers,
Michael

From: [email-masked] (Doan B. Hoang)
Date: Mon Oct 23 15:56:00 2006
Subject: [Iccrg] Meeting agenda (really! :-) )
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Michael Welzl wrote:

>>>So, does everyone agree that future congestion control protocols must
>>>be implicit, TCP friendly, and primarily
>>>delay-based with fail-over to a standard loss-based algorithm?
>>>      
>>>
>>Actually I disagree with all of these conclusions.
>>    
>>
>
>and so will many others, I suppose.
>  
>
Implicit, explicit controls are all relative. If you get explicit 
information for your control algorithm at a minimum cost, you
will certainly go with explicit.
Implicit solution for large networks takes a long tme to converge and is 
not applicable for short flows.
I would not rule out explicit congestion control protocols.

Delay-based algorithm is rather tricky as users and their traffic have 
different time constants. fair to one is always
unfair to another.

>My point was that writing a survey document is useless because
>that has been done before. We could take an existing
>one and try to draw conclusions from it (just like we're
>doing now, by criticizing conclusions of others). For this,
>we could also use a document which doesn't arrive at any
>conclusions at all but just presents a overview:
>http://www.welzl.at/research/publications/GFD.55.pdf
>
>... but repeating this effort seems to be a waste of time to
>me, no matter if we agree with the conclusions made in one
>of these documents or not.
>  
>
As I pointed out in one of the previous emails that everyone is tired of 
all the TCP variants
which are mostly useless or of dubious value and the someone else is 
summarizing all these
variants!!!

I sugest that we think up a list of approaches that have not been tried 
before with a short
discussion on each item on the list. It does not matter how peculiar the 
approaches that we
come up. I believe this is more exciting than another summary or survey, 
yet potentially
opens up new solutions (or no go solutions). For example, the 
"cost-based" approach promoted by Bob Briscoe
is one.

>Cheers,
>Michael
>
>
>_______________________________________________
>Iccrg mailing list
>[email-masked]
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>  
>
Cheers,
Doan

-- 
Doan B. Hoang
URL: http://research.it.uts.edu.au/arn

From: [email-masked] (Doan B. Hoang)
Date: Mon Oct 23 15:21:52 2006
Subject: [Iccrg] Flow Rate Fairness: Dismantling a Religion
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Bob,

I have read your "Flow Rate Fairness: Dismantling a Religion" paper with 
great interest.
It is rather refreshing to look at congestion from a cost-based fairness 
approach. This may lead
to more interesting and more effective solutions to network congestion 
as the cost--based
approach takes into account users' strategy in maximizing their utility 
(either legitimately or by
exploiting loopholes).

However, I would not say that "flow rate approach" community has been 
barking on the wrong tree. Rather,
the flow rate approach is more network-centric; it does not take users 
(external to the network) and their strategies
into account. The flow rate approach is thus narrower in scope than the 
cost-based approach.

I will provide some comments on your paper in another email.

Doan

Bob Briscoe wrote:

> ICCRG folks,
>
> Here's the memo on deconstructing the Internet community's dominant 
> fairness ideology that I promised. It should appear in internet-drafts 
> shortly, but you can pull the tech report off my Web site now if you 
> prefer.
>
> To some of you it will not be anything new, but I have found that very 
> many people have got into a trap in their thinking, so I'm trying to 
> jump people out of what is actually a self-referential dogma. Concepts 
> of fairness in TCP, WFQ and so on are all afflicted with this dogma 
> which is actually way off beam relative to any reasonable views of 
> fairness in real life. It's deliberately blunt and simplified.
>
> Flow Rate Fairness: Dismantling a Religion
> <http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/2020comms/refb/fair_tr.pdf> 
>
>
> Abstract: We were moved to write this memo because the applied 
> research and standards communities in networking are using completely 
> unrealistic and impractical fairness criteria. The issue is not 
> whether they should use this or that allocation scheme; they don't 
> even allocate the right thing and they don't allocate it between the 
> right entities. We explain as bluntly as we can that sharing out flow 
> rates (as TCP and many other popular fairness mechanisms do) has no 
> intellectual heritage from any concept of fairness in philosophy or 
> social science, or indeed real life. Comparing and controlling flow 
> rates alone will never achieve fairness and should never again be 
> claimed as a fairness mechanism for production networks. Instead, a 
> realistic fairness mechanism must share out the `cost' of each users 
> actions on others.
>
> Here's the same text formatted as an I-D, but it becomes twice as long:
> <http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#rateFairDis>
>
> I may not be able to get into discussions over the next week or so, 
> given other deadlines...
>
>
> Bob
>
>
>
> ____________________________________________________________________________ 
>
> 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
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

-- 
Doan B. Hoang
University of Technology, Sydney	
URL: http://research.it.uts.edu.au/arn

From: [email-masked] (David Ros)
Date: Mon Oct 23 10:59:28 2006
Subject: [Iccrg] CFP: NET-COOP'07
Message-ID: <[email-masked]>

(We apologize if you receive multiple copies of this message)

CALL FOR PAPERS

NET-COOP'2007	

International Conference on Network Control and Optimization (Euro-FGI
event: WP.IA.7.5)
1st Edition
June 5-7, 2007, Avignon, France	

http://www.lia.univ-avignon.fr/html/netcoop2007/net-coop.html

SCOPE
Internet communications and services are experiencing an increase in
volume and diversity both in their capacity and demand along with an
underlying increase in the complexity of their control and optimization,
mainly due to heterogeneity in architecture as well as usage. The need
for new ways of effectively and fairly allocating resources belonging to
a wide set of not necessarily cooperative networks to a collection of
possibly competing users is urgent.

This workshop aims at developing research on control and optimization of
the Internet, ranging from performance evaluation and optimization of
general stochastic networks to more specific targets such as lower-layer
functionalities in mobile networks, routing for computational grids,
game theoretic approaches to access control, cooperation, competition
and adversary capacities in diverse environments.

The main themes for NET-COOP are (but not restricted to):
*	Flow and congestion control in networks
*	Optimisation and control theoretical tools in networking
*	Game theoretic analysis of networks, incentive pricing, inducing
collaboration
*	Hierarchical optimisation in networking
*	Scheduling transmissions in networking
*	Control of queuing networks
*	Optimisation of wireless networks
*	Resource allocation and their optimisation
*	Transport protocols
*	Computational grids
*	Competitive routing

IMPORTANT DATES
Deadline for submissions: December 5, 2006
Notification of acceptance: February 5, 2007
Camera ready version: March 5, 2007
Workshop date: June 5-7, 2007

PAPERS AND SUBMISSION
Papers are solicited as full papers (in English), of no more than 10
single-spaced pages, each of which will be subject to a full review
process. The conference proceedings are being considered for publication
as hard-copy and electronically by Springer Verlag, Heidelberg, Germany,
in the Lecture Notes in Computer Science (LNCS) Series. In preparing
their manuscript, authors are invited to follow the LNCS guidelines (see
http://www.springer.de/comp/lncs/authors.html).

Papers can be submitted via the conference web site:
http://www.lia.univ-avignon.fr/html/netcoop2007/net-coop.html

A best student paper award will be granted.

Contact:
Tijani Chahed ([email-masked])
Bruno Tuffin ([email-masked])
http://www.lia.univ-avignon.fr/html/netcoop2007/net-coop.html

Co-sponsored by:
IEEE Control Systems Society (pending)
IFIP TC-6 and TC-7 (pending)

General Chair:
Jorma Virtamo (HUT, Finland)

Program Co-Chairs:
Tijani Chahed (GET/INT, France)
Bruno Tuffin (INRIA, France)

Program Committee:
Ivo Adan (UTE, The Netherlands)
Kostya Avratchenkov (INRIA, France)
Tamer Basar (University of Illinois, USA)
Vivek Borkar (TIFR, India)
Onno Boxma (UTE, The Netherlands)
Antonio Capone (Politecnico di Milano, Italy)
R. Chandramouli (Stevens Institute of Technology, USA)
Costas Courcoubetis (Athens University of Economics and Business,  
Greece)
Serguei Foss (Heriot-Watt University, UK)
Brigitte Jaumard (Concordia University, Canada)
Hisao Kameda (University of Tsukuba, Japan)
Peter Key (Microsoft Research, UK)
Arzad Kherani (IIT, India)
Anurag Kumar (IISC, India)
Harold J. Kushner (Brown University, USA)
Steven Low (CIT, USA)
John Lui (The Chinese University of Hong Kong, Hong Kong)
Patrick Maill? (GET/ENST Bretagne, France)
Michel Mandjes (CWI, The Netherlands)
Peter Marbach (University of Toronto, Canada)
Ravi Mazumdar (University of Waterloo, Canada)
Boris Miller (IITP, Russia)
Isi Mitrani (University of Newcastle, UK)
Jose Nino-Mora (Universidad Juan Carlos III de Madrid, Spain)
Fernando Paganini (Universidad ORT, Uruguay)
Guy Pujolle (University of Paris 6, France)
Rudesindo N??ez Queija (CWI, The Netherlands)
Zari Rachev (University of California at Santa Barbara, USA)
Jacques Resing (Eindhoven University of Technology, The Netherlands)
Ulrich Rieder (University of Ulm, Germany)
David Ros (GET/ENST-Bretagne, France)
Sanjay Shakkottai ( The University of Texas at Austin, USA)
George Stamoulis (Athens University of Economics and Business, Greece)
Nicolas Stier (Columbia University, USA)
Pascale Vicat-Blanc (ENS-Lyon, France)
Jorma Virtamo (HUT, Finland)

Organizing committee:
Eitan Altman, INRIA
Ephie Deriche, INRIA
Rachid Elazouzi, Avignon
Yezekael Hayel, Avignon
Tania Jimenez, U. Avignon

From: [email-masked] (Michael Welzl)
Date: Mon Oct 23 07:19:44 2006
Subject: [Iccrg] draft-irtf-iccrg-cc-rfcs-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Folks,

The amount of feedback that we received in response to the
email below was close to zero. Could you please take a look
at it and tell us what you think?

Thanks!!

Cheers,
Michael

On Tue, 2006-10-10 at 17:50, Michael Welzl wrote:
> Dear all,
> 
> Wesley Eddy and I finished the first version of our overview
> of congestion control related efforts in the IETF. It's available
> at http://www.ietf.org/internet-drafts/draft-irtf-iccrg-cc-rfcs-00.txt
> and there's now a link in our Wiki.
> 
> We would greatly appreciate any comments - especially as we
> made this a RG item and intend to publish this as an RFC,
> meaning that we also need RG consensus.
> 
> Cheers,
> Michael
> 
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Bob Briscoe)
Date: Tue Oct 17 01:39:30 2006
Subject: [Iccrg] Flow Rate Fairness: Dismantling a Religion
Message-ID: <[email-masked]>

ICCRG folks,

Here's the memo on deconstructing the Internet community's dominant 
fairness ideology that I promised. It should appear in internet-drafts 
shortly, but you can pull the tech report off my Web site now if you prefer.

To some of you it will not be anything new, but I have found that very many 
people have got into a trap in their thinking, so I'm trying to jump people 
out of what is actually a self-referential dogma. Concepts of fairness in 
TCP, WFQ and so on are all afflicted with this dogma which is actually way 
off beam relative to any reasonable views of fairness in real life. It's 
deliberately blunt and simplified.

Flow Rate Fairness: Dismantling a Religion
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/2020comms/refb/fair_tr.pdf>

Abstract: We were moved to write this memo because the applied research and 
standards communities in networking are using completely unrealistic and 
impractical fairness criteria. The issue is not whether they should use 
this or that allocation scheme; they don't even allocate the right thing 
and they don't allocate it between the right entities. We explain as 
bluntly as we can that sharing out flow rates (as TCP and many other 
popular fairness mechanisms do) has no intellectual heritage from any 
concept of fairness in philosophy or social science, or indeed real life. 
Comparing and controlling flow rates alone will never achieve fairness and 
should never again be claimed as a fairness mechanism for production 
networks. Instead, a realistic fairness mechanism must share out the `cost' 
of each users actions on others.

Here's the same text formatted as an I-D, but it becomes twice as long:
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#rateFairDis>

I may not be able to get into discussions over the next week or so, given 
other deadlines...

Bob

____________________________________________________________________________
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: [email-masked] (Bob Briscoe)
Date: Tue Oct 17 00:57:11 2006
Subject: [Iccrg] Meeting agenda (really! :-) )
In-Reply-To: <[email-masked] >
References: <[email-masked]> <[email-masked]> <[email-masked]> <002a01c6d770$66b9cf00$0200a8c0@fun> <[email-masked]>
Message-ID: <[email-masked]>

Lachlan,

At 18:21 11/10/2006, Lachlan Andrew wrote:
>Greetings Bob,
>
>On 11/10/06, Bob Briscoe <[email-masked]> wrote:
>>
>>1/ I have a paper that
>>deconstructs the dominant understanding of
>>fairness used in congestion control
>
>That sounds fascinating, and I look forward to hearing about it.

See next mail.

>>2/ We may also have work presentable by Feb on what per datagram congestion
>>'signalling' bandwidth is necessary for hi speed congestion control as flow
>>rates increase. What do I mean by signalling bandwidth? As an example,
>>packet discard or ECN gives 1 bit per packet of signalling bandwidth. FAST
>>claims to use congestion loss to give multibit feedback per packet, but we
>>aim to quantify what 'multibit' means in this case, and why you get less
>>signalling bandwidth per packet from measuring congestion delay as link
>>speeds increase. The aim is to quantify at what point congestion
>>delay-based approaches would get less than 1 bit per packet signalling
>>bandwidth
>
>That also sounds very interesting.  Do you have link to a draft of
>that?

The draft is far too rough to give out yet. It's more the whole thought 
framework - not just the signalling bandwidth, but a complete consideration 
of the network-transport interface. Let me work on it more.

>Information theory suggests that you get something like  log(1+
>delay / jitter)  [adjusted for jitter not being i.i.d. Gaussian...].
>Is that the principle you use?

But the other question is, what buffer sizes are we likely to see as link 
rates scale, to quantify the scaling of this with capacity. As you probably 
know, there's a lot of research progress in that area at the moment.

>One thing to note is that the 1 bit you get from dropping or ECN has
>to be used carefully or it also degrates at high bandwidths.  In
>particular, if you use normal AIMD, then the information you get per
>congestion epoch is the number of packets in that epoch.  That is, you
>get  O(log(N)/N)  bits of ECN information per packet if the TCP epoch
>length is  N.  (Even if you are not using AIMD yourself, if someone
>else uses the same ECN marks and does use AIMD, then you are limited
>to marking one every  N  packets.)

Exactly. The problem is that the signal must be stateless and aggregate 
statelessly. Then with just 1 /protocol/ bit per packet it takes n times 
more packets to signal a congestion level that is n times smaller. 
Therefore, as congestion rises, the numerically higher signals `overtake' 
the numerically lower ones (which may be yet another possible cause of the 
characteristic epoch lengths we see in queues).

>Using packet drops instead of ECN gives about  p log(1/p)  bits per
>packet if the link utilisation is to be at least  1-p on links
>upstream of the bottleneck,  which is again very much less than 1
>unless the utilisation is allowed to drop to 50%.
>
>It would be very interesting to quantify when delay-based signalling
>gives less than loss-based signalling, rather than when it gives less
>than 1 bit per packet.

Yes, you're right - I was being sloppy with my language. I was being 
ambiguous between protocol bits and information bits.

>You might be interested in some non-AIMD ECN schemes.  In principle,
>schemes like that of Thommes and Coates
><http://www.tsp.ece.mcgill.ca/Networks/projects/pdf/thommes_ACMTN06.pdf>
>can actually give O(1) bit per packet.
>
>That scheme is very sensitive to a particular quantisation parameter,
>but we have a related scheme
><http://netlab.caltech.edu/~lachlan/abstract/ADPM_CL.pdf>,
><http://netlab.caltech.edu/~lachlan/abstract/ADPM_Allerton06.pdf>
>which scales nicely to give information faster when the congestion
>level changes faster.
>
>It still only gives  O(log(k)/k)  bits per packet, but that "k" is
>adapted to the time-scale of changes in congestion level, rather than
>some epoch length.  If the congestion level changes slowly, you don't
>need much information per packet, but if it changes quickly, this
>scheme gives up to 1 bit per packet.  More importantly, the marking
>uses the ECN bits   without   interfering with the way TCP uses those
>bits.

I've just done a deadline and working towards two at the end of the week, 
so I can't take all this in now. I''l have a look. THanks - this is v 
interesting conversation.

Cheers

Bob

>Cheers,
>Lachlan
>
>--
>Lachlan Andrew  Dept of Computer Science, Caltech
>1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
>Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603

____________________________________________________________________________
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: [email-masked] (Bob Briscoe)
Date: Tue Oct 17 00:27:58 2006
Subject: [Iccrg] Meeting agenda (really! :-) )
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Keshav,

I fully understood your thesis.

If a bottleneck had capacity to be able to allow some users to get a lot 
more capacity, wouldn't it be uncongested? As we are talking about 
congestion control, I assumed we were considering a scenario where traffic 
demand is in an epoch that congests the resource (or risks congesting the 
resource).

If it's not congested, we certainly do move into a realm where anyone can 
have any rate and it doesn't alter fairness, because fairness is measured 
by how much volume of congestion each user causes. (My next mail announces 
the posting I promised which justifies this latter assertion.)

But, for me, the whole point of congestion control, and iccrg in 
particular, is to ensure large amounts of capacity are highly utilised 
while still ensuring low loss, low congestion delay and fair allocations.

I imagine that some/many hi-capacity networks will be burstily congested 
but often there just won't be sufficient demand to fill capacity. However, 
every time demand happens to all arrive at once, congestion control has to 
work in all the 4 dimensions just mentioned.

Bob

At 14:51 12/10/2006, S. Keshav wrote:

>On Oct 12, 2006, at 5:00 AM, Bob Briscoe wrote:
>Bob,
>
>>Keshav,
>>
>>At 20:41 11/10/2006, S. Keshav wrote:
>>>Bob,
>>>This sounds like a good discussion to have. The need for fairness has
>>>been grossly exaggerated, in my opinion, and is hard to justify. If
>>>scheme A is fair to all users, and scheme B is unfair, but every user
>>>with scheme B gets more than the same user with scheme A, would you
>>>prefer B to A? I would.
>>
>>Of course. But such a situation would be extremely unusual. All the
>>practical scenarios involve conflicts of interests, with some users
>>getting more and some less.
>I guess this assumes that you are already at the Pareto frontier. As
>I discussed in my earlier email, it is not clear to me that this is
>necessarily the case with today's transport protocols (especially
>when one of the hops is on a wireless link). A hypothetical unfair
>scheme that improves every flow's performance would certainly be
>better than wasting resources.
>
>>I have to disagree that the need for fairness is hard to justify.
>>In particular, in a non-co-operative environment (like the
>>Internet, which is after all the object of debate), if the view of
>>fairness that prevails cannot be /enforced/, then some users can
>>take orders of magnitude more than their 'fair' share. Then, what
>>is the point of even having a congestion control protocol?
>Let me restate my thesis:
>Consider congestion control scheme A that guarantees fair allocations
>to all flows. Suppose I come up with scheme B that is not fair, but
>every flow that got an allocation r with A gets >= r with B. Some
>flows may indeed get *much* more than others, but every flow does
>better. I argue that scheme B is better than scheme A. Or, more
>obliquely, capitalism trumps socialism :-)
>
>Now, your objection is that fairness needs to be enforced. But what I
>propose is to have the fair share be the lower bound on the
>allocation for all flows. That is the point of the congestion control
>scheme. (For that matter, if only a majority of flows improve,
>perhaps scheme B is still better.)
>
>>>
>>>--Paraphrased requirements (eliding application level
>>>requirements) --
>
>BTW - this is not my wording - I just cut and paste if from the
>survey that Michael pointed to. I put it out as fodder for discussion
>
>regards
>keshav

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

From: [email-masked] (Michael Welzl)
Date: Fri Oct 13 13:19:34 2006
Subject: [Iccrg] Meeting agenda (really! :-) )
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu, 2006-10-12 at 17:52, S. Keshav wrote:
> Michael,
> 	I think such a list is useful, and certainly an achievable first  
> step in getting to agreement on general principles. Can you start off  
> with a list based on your survey?

Okay! but, on a side note, I don't think that the survey
(at least this particular one) is very helpful here. I can
still come up with such a list as a starting point.

I'm not 100% convinced about its usefulness and would like
to see a little more feedback (folks - this is not me telling
Keshav that I won't do it unless others comment, this is me
asking everyone else for their opinion!).

Clearly, it won't be the same thing, but I think it's worth
pointing out that there's a certain relationship between
such a list and draft-irtf-tmrg-metrics-04.txt
(which isn't a checklist, but looks at metrics of concern
to congestion control mechanisms).

Perhaps, with some work, we could arrive at a document
in the style of RFC 3426.

Cheers,
Michael

From: [email-masked] (Lachlan Andrew)
Date: Thu Oct 12 19:46:50 2006
Subject: [Iccrg] Re: TCP requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Keshav,

On 12/10/06, S. Keshav <[email-masked]> wrote:
> However, over the long term, you may achieve
> max-min-fair-share, but *not* Pareto optimality.

> I think the confusion arises from the fact that there are two time-
> scales of interest.

The key is max-min-fair-*share*.  That is max-min on a reduced
feasible region, like the "constrained Max-min" concept introduced in
the paper "Understanding XCP".  To me that is not "max-min", but
you're right that it is often said that non-Pareto protocols like XCP
are max-min fair.

Anyway, I didn't mean to detract from Bob's and your original point
that seeking fairness at all costs is not good, and should be
discussed.

Thanks for your patience,
Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603

From: [email-masked] (S. Keshav)
Date: Thu Oct 12 18:21:41 2006
Subject: [Iccrg] Meeting agenda (really! :-) )
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Michael,
	I think such a list is useful, and certainly an achievable first  
step in getting to agreement on general principles. Can you start off  
with a list based on your survey?

thanks

keshav

On Oct 12, 2006, at 10:55 AM, Michael Welzl wrote:

> What I can imagine is that we could agree on some sort of
> a checklist for congestion control mechanisms.
...
> Would that make any sense - would such a list be helpful
> at all?

From: [email-masked] (Michael Welzl)
Date: Thu Oct 12 18:58:57 2006
Subject: [Iccrg] Meeting agenda (really! :-) )
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> I agree that we don't need another survey! However, as one of the  

Great!

> authors of this survey, would you say that there are general  
> principles that you can state? A discussion on these in this list,  
> and in person during PFLD, would be very useful.

Very hard to do right (as shown by the example that you
quoted from the other reference), but...

> Looking forward, I think that the goal of this discussion would be to  
> use agreed-upon general principles to narrow down the field of  
> potential schemes/mechanisms to consider for a next-generation  
> congestion control mechanism. In particular, given that Linux/ 
> Microsoft are well on their way to making some schemes de facto  
> solutions, if we find that these schemes violate agreed-upon  
> principles, then we should raise this objection with due urgency.

... worthwhile, especially in the light of these recent events.

Stating principles may be easy, but agreeing on some may not -
or they become so general and vague that they are not very
useful for the above purpose (like "a congestion control
mechanism must be efficient").

What I can imagine is that we could agree on some sort of
a checklist for congestion control mechanisms. In fact,
if you look at some congestion control papers from the
last few years, you can tell that such a checklist already
exists, albeit implicitly, in people's (author's and
paper reviewer's ;-)  ) minds...

Like:

A congestion control mechanism should...

* be stable
* not experience a significant performance degradation when
  links have a large bw*delay product
* work well with not only 1 or 10 but 100 or 1000 or more users

etc. etc.

Would that make any sense - would such a list be helpful
at all? Most of the items on it seem like common knowledge
to me... but then again, some may not.

Cheers,
Michael

From: [email-masked] (S. Keshav)
Date: Thu Oct 12 16:29:54 2006
Subject: [Iccrg] Meeting agenda (really! :-) )
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Michael,
>
>  For this,
> we could also use a document which doesn't arrive at any
> conclusions at all but just presents a overview:
> http://www.welzl.at/research/publications/GFD.55.pdf
>
> ... but repeating this effort seems to be a waste of time to
> me, no matter if we agree with the conclusions made in one
> of these documents or not.
>

I agree that we don't need another survey! However, as one of the  
authors of this survey, would you say that there are general  
principles that you can state? A discussion on these in this list,  
and in person during PFLD, would be very useful.

Looking forward, I think that the goal of this discussion would be to  
use agreed-upon general principles to narrow down the field of  
potential schemes/mechanisms to consider for a next-generation  
congestion control mechanism. In particular, given that Linux/ 
Microsoft are well on their way to making some schemes de facto  
solutions, if we find that these schemes violate agreed-upon  
principles, then we should raise this objection with due urgency.

thanks
keshav

From: [email-masked] (S. Keshav)
Date: Thu Oct 12 16:28:39 2006
Subject: [Iccrg] Meeting agenda (really! :-) )
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Oct 12, 2006, at 5:00 AM, Bob Briscoe wrote:
Bob,

> Keshav,
>
> At 20:41 11/10/2006, S. Keshav wrote:
>> Bob,
>> This sounds like a good discussion to have. The need for fairness has
>> been grossly exaggerated, in my opinion, and is hard to justify. If
>> scheme A is fair to all users, and scheme B is unfair, but every user
>> with scheme B gets more than the same user with scheme A, would you
>> prefer B to A? I would.
>
> Of course. But such a situation would be extremely unusual. All the  
> practical scenarios involve conflicts of interests, with some users  
> getting more and some less.
>
I guess this assumes that you are already at the Pareto frontier. As  
I discussed in my earlier email, it is not clear to me that this is  
necessarily the case with today's transport protocols (especially  
when one of the hops is on a wireless link). A hypothetical unfair  
scheme that improves every flow's performance would certainly be  
better than wasting resources.

> I have to disagree that the need for fairness is hard to justify.  
> In particular, in a non-co-operative environment (like the  
> Internet, which is after all the object of debate), if the view of  
> fairness that prevails cannot be /enforced/, then some users can  
> take orders of magnitude more than their 'fair' share. Then, what  
> is the point of even having a congestion control protocol?
>
Let me restate my thesis:
Consider congestion control scheme A that guarantees fair allocations  
to all flows. Suppose I come up with scheme B that is not fair, but  
every flow that got an allocation r with A gets >= r with B. Some  
flows may indeed get *much* more than others, but every flow does  
better. I argue that scheme B is better than scheme A. Or, more  
obliquely, capitalism trumps socialism :-)

Now, your objection is that fairness needs to be enforced. But what I  
propose is to have the fair share be the lower bound on the  
allocation for all flows. That is the point of the congestion control  
scheme. (For that matter, if only a majority of flows improve,  
perhaps scheme B is still better.)

>>
>> --Paraphrased requirements (eliding application level  
>> requirements) --

BTW - this is not my wording - I just cut and paste if from the  
survey that Michael pointed to. I put it out as fodder for discussion

regards
keshav

From: [email-masked] (S. Keshav)
Date: Thu Oct 12 16:02:51 2006
Subject: [Iccrg] Re: TCP requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

/* 'm ccing ICCRG on this discussion because it touches on a point  
that Michael brought up in his mail to the group */

Lachlan,

>>         Well, in general, simultaneously achieving Pareto  
>> optimality and
>> fairness is hard. Pareto optimality is easy to achieve when you only
>> consider scheduling, because all work-conserving disciplines are
>> Pareto optimal. However, once you take transport effects into
>> account, especially congestion signals, achieving the Pareto frontier
>> is not a given. Consider a bit-setting scheme such as DECbit. If you
>> have a long RTT flow, you could set bits on an over-limit flow, that
>> would take effect only after a while, and then would persist for 2
>> RTTs (because DECbit takes control actions once every 2 RTTs).
>
> Thanks for your explanation, but I don't quite understand it.  In that
> situation, with dynamics, it isn't clear what quantity we are being
> Pareto or max-min with respect to; time average rates? instantaneous
> rates at some time?  I'm only used to thinking of a single average
> rate per (long lived) flow.
>
We can consider the Pareto frontier with respect to at least two  
quantities:

1. Instantaneous (or short-term) rates, measured say, over the time  
scale of a few ms:
We can achieve Pareto optimality at this time scale with any work- 
conserving scheduling discipline. A (max-min) fair scheduling  
discipline can achieve both Pareto optimality and fairness.

2. Time-average rates, measured over several RTTs (10s to 100s of ms):
Here, things are harder because of feedback at the transport layer.  
When modulated by a transport layer, the sum of time average rates of  
all the flows at a bottleneck link may not sum up to the link rate  
(especially with small buffers and long RTTs). Then, Pareto  
optimality will not be achieved. As a thought experiment, consider a  
WFQ scheduler with only 1 packet of buffering per flow, which drops  
packets whenever a flow has more than one packet in its queue. If you  
send TCP over this, you are going to achieve short-term Pareto  
optimality trivially. However, over the long term, you may achieve  
max-min-fair-share, but *not* Pareto optimality.

>> Clearly, to achieve max-min fairness, the control mechanism will lead
>> you to a non-Pareto allocation.

> Perhaps I'm misunderstanding either max-min fairness or
> Pareto-optimality, but I thought that definition of max-min implied
> Pareto-optimality.  If a particular DECbit solution is non-Pareto,
> then one user can increase without hurting any other (definition of
> non-Pareto); hence it can increase without hurting any worse-off user,
> which I thought was the definition of being not max-min.

I think the confusion arises from the fact that there are two time- 
scales of interest. I hope my example above clarifies the situation.  
In particular, I could have a scheduling discipline that does not  
have one buffer statically allocated per flow,but pools buffers and  
serves FIFO. With TCP, my guess is that you will do *better* than WFQ  
(in terms of sum of average rates).

regards
keshav

From: [email-masked] (Michael Welzl)
Date: Thu Oct 12 14:48:54 2006
Subject: [Iccrg] Meeting agenda (really! :-) )
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> >So, does everyone agree that future congestion control protocols must
> >be implicit, TCP friendly, and primarily
> >delay-based with fail-over to a standard loss-based algorithm?
> 
> Actually I disagree with all of these conclusions.

and so will many others, I suppose.

My point was that writing a survey document is useless because
that has been done before. We could take an existing
one and try to draw conclusions from it (just like we're
doing now, by criticizing conclusions of others). For this,
we could also use a document which doesn't arrive at any
conclusions at all but just presents a overview:
http://www.welzl.at/research/publications/GFD.55.pdf

... but repeating this effort seems to be a waste of time to
me, no matter if we agree with the conclusions made in one
of these documents or not.

Cheers,
Michael

From: [email-masked] (Bob Briscoe)
Date: Thu Oct 12 11:41:14 2006
Subject: [Iccrg] Meeting agenda (really! :-) )
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Keshav,

At 20:41 11/10/2006, S. Keshav wrote:
>Bob,
>This sounds like a good discussion to have. The need for fairness has
>been grossly exaggerated, in my opinion, and is hard to justify. If
>scheme A is fair to all users, and scheme B is unfair, but every user
>with scheme B gets more than the same user with scheme A, would you
>prefer B to A? I would.

Of course. But such a situation would be extremely unusual. All the 
practical scenarios involve conflicts of interests, with some users getting 
more and some less.

I have to disagree that the need for fairness is hard to justify. In 
particular, in a non-co-operative environment (like the Internet, which is 
after all the object of debate), if the view of fairness that prevails 
cannot be /enforced/, then some users can take orders of magnitude more 
than their 'fair' share. Then, what is the point of even having a 
congestion control protocol?

But to enforce a view of fairness, the enforcers (deliberately 
non-specific) have to know what fair means in the first place.

>         So, a discussion of fairness, and its relationship to congestion is
>well worth having.
>
>Let me also handle Michael's comment from a while back:
>>  Michael Welzl wrote:
>>>Also, such overviews exist - how much
>>>should the overview differ from, say, this one:
>>>http://transport.internet2.edu/transport-design-space.pdf
>>>or the others in our Wiki?
>
>Good point. Since this work has already been done, it would be useful
>for ICCRG to bless them, assuming we agree with the conclusions. For
>the benefit of readers on this list, here is the set of requirements
>and conclusions from the paper Michael pointed to:
>
>--Paraphrased requirements (eliding application level requirements) --
>3. .. deployable without the need to negotiate with organizational
>information technology departments
>that might have standardized on.

I don't think we need be so specific. 'Incremental deployment and 
incentives properly considered' would be sufficient. Deployment into some 
environments requires the IT dept to veto (eg into machines in my company - 
but strangely not my laptop ;), in others it doesn't.

>4. Ability to transfer at speed that are close to 1Gb/s in near term
>and 10 Gb/s in medium term
>with, preferably, no fundamental limitations on performance in longer
>term.
>5. Ability to be used both for straightforward bulk file transfer and
>advanced interactive multimedia applications that can require
>unreliable (and partially reliable) datagram service.
>6. Tolerance for minor non-congestive packet loss.
>7. Lack of dependence on network upgrades or configuration changes,
>especially those that involve
>all routers along the path.

Again, good guidance, but too specific. I'd rather see this statement as a 
suggested example of the statement 'Incremental deployment and incentives 
properly considered', rather than a law. Our own (so far unpublished) work 
we would actually meet your requirement, but I don't think we should rule 
out other approaches that don't meet it if they can justify their position.

For instance, in my review of QuickStart (expired I-D on my pubs page) I 
proposed a simple mathematical deployment model to show that 'incrementally 
deployable' was too bold a claim for QuickStart, but that doesn't mean it 
isn't a useful experimental step in some environments.

>8. Usability over a wide range of scenarios without complex tuning.
>9. Ability to be tuned for the most unusual of circumstances (such as
>lossy radio links).

Contradicts 8, but I know what you mean - just needs wordsmithing.

>10. Reasonable fairness among instantiations of itself and some
>measure of fairness towards conventional TCP.

Well, this one I fundamentally disagree with, but a deconstruction requires 
a paper, not an e-mail... so watch this space.

>--Paraphrased conclusions--
>... we draw the following conclusions for the transport tool (the
>requirements
>mentioned below are listed in section 1):
>
>1. The congestion control scheme needs to be TCP friendly without
>emulating TCP (see requirement 10).

Ditto

>3. The tool is to be based on transport with implicit congestion
>signaling (see requirement 7).

This may be proved impossible at high link speeds (see below) - what then? 
I think this is part of the debate - too early to gainsay as a requirement.

>4. The implicit congestion signaling scheme (to be used according to
>conclusion 3) is to be primarily
>delay-based with fail-over to a standard loss-based algorithm when
>persistent congestion is
>detected (see requirements 6, 4, and 10).

Again, part of the debate, not a requirement, IMHO.

As link speeds increase, congestion delay decreases (especially given the 
conclusions people are coming to on small buffers). Then congestion delay 
becomes an extremely imprecise measure of congestion (see thread just 
started on per packet congestion signalling channel bandwidth).

>So, does everyone agree that future congestion control protocols must
>be implicit, TCP friendly, and primarily
>delay-based with fail-over to a standard loss-based algorithm?

Actually I disagree with all of these conclusions.

Cheers

Bob

____________________________________________________________________________
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: [email-masked] (Michael Welzl)
Date: Thu Oct 12 08:46:03 2006
Subject: [Iccrg] TCP requirements
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 2006-10-11 at 23:20, Lachlan Andrew wrote:
> Greetings Keshav,
> 
> On 11/10/06, S. Keshav <[email-masked]> wrote:
> > If scheme A is fair to all users, and scheme B is unfair, but every user
> > with scheme B gets more than the same user with scheme A, would you
> > prefer B to A? I would.
> 
> Very good point.  However, most concepts of fairness (like max-min
> fairness and utility maximisation) already eliminate that possibility.
>  They define all "fair" points to be on the "Pareto-optimal" boundary,
> where it is impossible for all users to improve simultaneously.  A
> point where everyone gets equal rate isn't necessarily "fair".

But a real mechanism only approximates one of these fairness
concepts. For practical evaluation of "fairness" of a congestion
control mechanism, one tends to neglect this Pareto optimality,
i.e. the rates of flows are usually compared without taking
the "distance" from the optimum into account.

Thus, in practice, you can have the situation that Keshav
describes above...

Cheers,
Michael

From: [email-masked] (Lachlan Andrew)
Date: Wed Oct 11 23:44:59 2006
Subject: [Iccrg] TCP requirements
Message-ID: <[email-masked]>

Greetings Keshav,

On 11/10/06, S. Keshav <[email-masked]> wrote:
> If scheme A is fair to all users, and scheme B is unfair, but every user
> with scheme B gets more than the same user with scheme A, would you
> prefer B to A? I would.

Very good point.  However, most concepts of fairness (like max-min
fairness and utility maximisation) already eliminate that possibility.
 They define all "fair" points to be on the "Pareto-optimal" boundary,
where it is impossible for all users to improve simultaneously.  A
point where everyone gets equal rate isn't necessarily "fair".

> So, a discussion of fairness, and its relationship to congestion is
> well worth having.

Agreed!

Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603

From: [email-masked] (S. Keshav)
Date: Wed Oct 11 22:09:53 2006
Subject: [Iccrg] Meeting agenda (really! :-) )
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bob,
This sounds like a good discussion to have. The need for fairness has  
been grossly exaggerated, in my opinion, and is hard to justify. If  
scheme A is fair to all users, and scheme B is unfair, but every user  
with scheme B gets more than the same user with scheme A, would you  
prefer B to A? I would.
	So, a discussion of fairness, and its relationship to congestion is  
well worth having.

> It will help answer the question in this thread about striping  
> aross multiple paths, and generally completely re-boots most  
> people's understanding of fairness, showing just how impractical  
> and unrealistic the current way we think about fairness is.
>
>
>
Let me also handle Michael's comment from a while back:
>  Michael Welzl wrote:
>> > 1. What we know. Known 'good' approaches - i.e. whats common to the
>> > proposals out there.
>>
>> but what exactly shall we expect to learn from / accomplish with  
>> this?
>> I mean, we can write an overview, looking at commonalities ... to
>> be concrete, I think this can be something like "delay has been used
>> as a congestion measure in ... Vegas, FAST, ... it has the following
>> advantages, the following disadvantages..."  ... and so on and so  
>> forth.
>>
>> That might be nice, but I'm having a hard time imagining that this
>> will take us anywhere. Also, such overviews exist - how much
>> should the overview differ from, say, this one:
>> http://transport.internet2.edu/transport-design-space.pdf
>> or the others in our Wiki?
>>
>> And what would it accomplish that the others don't?

Good point. Since this work has already been done, it would be useful  
for ICCRG to bless them, assuming we agree with the conclusions. For  
the benefit of readers on this list, here is the set of requirements  
and conclusions from the paper Michael pointed to:

--Paraphrased requirements (eliding application level requirements) --
3. .. deployable without the need to negotiate with organizational  
information technology departments
that might have standardized on.
4. Ability to transfer at speed that are close to 1Gb/s in near term  
and 10 Gb/s in medium term
with, preferably, no fundamental limitations on performance in longer  
term.
5. Ability to be used both for straightforward bulk file transfer and  
advanced interactive multimedia applications that can require  
unreliable (and partially reliable) datagram service.
6. Tolerance for minor non-congestive packet loss.
7. Lack of dependence on network upgrades or configuration changes,  
especially those that involve
all routers along the path.
8. Usability over a wide range of scenarios without complex tuning.
9. Ability to be tuned for the most unusual of circumstances (such as  
lossy radio links).
10. Reasonable fairness among instantiations of itself and some  
measure of fairness towards conventional TCP.

--Paraphrased conclusions--
... we draw the following conclusions for the transport tool (the  
requirements
mentioned below are listed in section 1):

1. The congestion control scheme needs to be TCP friendly without  
emulating TCP (see requirement 10).
3. The tool is to be based on transport with implicit congestion  
signaling (see requirement 7).
4. The implicit congestion signaling scheme (to be used according to  
conclusion 3) is to be primarily
delay-based with fail-over to a standard loss-based algorithm when  
persistent congestion is
detected (see requirements 6, 4, and 10).

So, does everyone agree that future congestion control protocols must  
be implicit, TCP friendly, and primarily
delay-based with fail-over to a standard loss-based algorithm?

thanks
keshav

From: [email-masked] (Shivkumar Kalyanaraman)
Date: Wed Oct 11 20:21:45 2006
Subject: [Iccrg] Meeting agenda (really! :-) )
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

talking of bits of feedback, perhaps our recent SIGCOMM 2005 paper may be
of interest:

http://www.acm.org/sigs/sigcomm/sigcomm2005/techprog.html
One More Bit Is Enough
Yong Xia, RPI.
Lakshminarayanan Subramanian, Berkeley.
Ion Stoica, Berkeley.
Shivkumar Kalyanaraman, RPI.

best
-Shiv
===
Shivkumar Kalyanaraman
Professor, Dept of ECSE, Rensselaer Polytechnic Institute (RPI)
110, 8th Street, Room JEC 6003, Troy NY 12180-3590
Ph: 518 276 8979   Fax: 518 276 4403
WWW: http://www.ecse.rpi.edu/Homepages/shivkuma
Google: "Shiv RPI"

On Wed, 11 Oct 2006, Lachlan Andrew wrote:

> Greetings Bob,
>
> On 11/10/06, Bob Briscoe <[email-masked]> wrote:
> >
> > 1/ I have a paper that
> > deconstructs the dominant understanding of
> > fairness used in congestion control
>
> That sounds fascinating, and I look forward to hearing about it.
>
> > 2/ We may also have work presentable by Feb on what per datagram congestion
> > 'signalling' bandwidth is necessary for hi speed congestion control as flow
> > rates increase. What do I mean by signalling bandwidth? As an example,
> > packet discard or ECN gives 1 bit per packet of signalling bandwidth. FAST
> > claims to use congestion loss to give multibit feedback per packet, but we
> > aim to quantify what 'multibit' means in this case, and why you get less
> > signalling bandwidth per packet from measuring congestion delay as link
> > speeds increase. The aim is to quantify at what point congestion
> > delay-based approaches would get less than 1 bit per packet signalling
> > bandwidth
>
> That also sounds very interesting.  Do you have link to a draft of
> that?  Information theory suggests that you get something like  log(1+
> delay / jitter)  [adjusted for jitter not being i.i.d. Gaussian...].
> Is that the principle you use?
>
> One thing to note is that the 1 bit you get from dropping or ECN has
> to be used carefully or it also degrates at high bandwidths.  In
> particular, if you use normal AIMD, then the information you get per
> congestion epoch is the number of packets in that epoch.  That is, you
> get  O(log(N)/N)  bits of ECN information per packet if the TCP epoch
> length is  N.  (Even if you are not using AIMD yourself, if someone
> else uses the same ECN marks and does use AIMD, then you are limited
> to marking one every  N  packets.)
>
> Using packet drops instead of ECN gives about  p log(1/p)  bits per
> packet if the link utilisation is to be at least  1-p on links
> upstream of the bottleneck,  which is again very much less than 1
> unless the utilisation is allowed to drop to 50%.
>
> It would be very interesting to quantify when delay-based signalling
> gives less than loss-based signalling, rather than when it gives less
> than 1 bit per packet.
>
> You might be interested in some non-AIMD ECN schemes.  In principle,
> schemes like that of Thommes and Coates
> <http://www.tsp.ece.mcgill.ca/Networks/projects/pdf/thommes_ACMTN06.pdf>
> can actually give O(1) bit per packet.
>
> That scheme is very sensitive to a particular quantisation parameter,
> but we have a related scheme
> <http://netlab.caltech.edu/~lachlan/abstract/ADPM_CL.pdf>,
> <http://netlab.caltech.edu/~lachlan/abstract/ADPM_Allerton06.pdf>
> which scales nicely to give information faster when the congestion
> level changes faster.
>
> It still only gives  O(log(k)/k)  bits per packet, but that "k" is
> adapted to the time-scale of changes in congestion level, rather than
> some epoch length.  If the congestion level changes slowly, you don't
> need much information per packet, but if it changes quickly, this
> scheme gives up to 1 bit per packet.  More importantly, the marking
> uses the ECN bits   without   interfering with the way TCP uses those
> bits.
>
> Cheers,
> Lachlan
>
> --
> Lachlan Andrew  Dept of Computer Science, Caltech
> 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
> Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

From: [email-masked] (Lachlan Andrew)
Date: Wed Oct 11 20:03:55 2006
Subject: [Iccrg] Meeting agenda (really! :-) )
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <002a01c6d770$66b9cf00$0200a8c0@fun> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Bob,

On 11/10/06, Bob Briscoe <[email-masked]> wrote:
>
> 1/ I have a paper that
> deconstructs the dominant understanding of
> fairness used in congestion control

That sounds fascinating, and I look forward to hearing about it.

> 2/ We may also have work presentable by Feb on what per datagram congestion
> 'signalling' bandwidth is necessary for hi speed congestion control as flow
> rates increase. What do I mean by signalling bandwidth? As an example,
> packet discard or ECN gives 1 bit per packet of signalling bandwidth. FAST
> claims to use congestion loss to give multibit feedback per packet, but we
> aim to quantify what 'multibit' means in this case, and why you get less
> signalling bandwidth per packet from measuring congestion delay as link
> speeds increase. The aim is to quantify at what point congestion
> delay-based approaches would get less than 1 bit per packet signalling
> bandwidth

That also sounds very interesting.  Do you have link to a draft of
that?  Information theory suggests that you get something like  log(1+
delay / jitter)  [adjusted for jitter not being i.i.d. Gaussian...].
Is that the principle you use?

One thing to note is that the 1 bit you get from dropping or ECN has
to be used carefully or it also degrates at high bandwidths.  In
particular, if you use normal AIMD, then the information you get per
congestion epoch is the number of packets in that epoch.  That is, you
get  O(log(N)/N)  bits of ECN information per packet if the TCP epoch
length is  N.  (Even if you are not using AIMD yourself, if someone
else uses the same ECN marks and does use AIMD, then you are limited
to marking one every  N  packets.)

Using packet drops instead of ECN gives about  p log(1/p)  bits per
packet if the link utilisation is to be at least  1-p on links
upstream of the bottleneck,  which is again very much less than 1
unless the utilisation is allowed to drop to 50%.

It would be very interesting to quantify when delay-based signalling
gives less than loss-based signalling, rather than when it gives less
than 1 bit per packet.

You might be interested in some non-AIMD ECN schemes.  In principle,
schemes like that of Thommes and Coates
<http://www.tsp.ece.mcgill.ca/Networks/projects/pdf/thommes_ACMTN06.pdf>
can actually give O(1) bit per packet.

That scheme is very sensitive to a particular quantisation parameter,
but we have a related scheme
<http://netlab.caltech.edu/~lachlan/abstract/ADPM_CL.pdf>,
<http://netlab.caltech.edu/~lachlan/abstract/ADPM_Allerton06.pdf>
which scales nicely to give information faster when the congestion
level changes faster.

It still only gives  O(log(k)/k)  bits per packet, but that "k" is
adapted to the time-scale of changes in congestion level, rather than
some epoch length.  If the congestion level changes slowly, you don't
need much information per packet, but if it changes quickly, this
scheme gives up to 1 bit per packet.  More importantly, the marking
uses the ECN bits   without   interfering with the way TCP uses those
bits.

Cheers,
Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603

From: [email-masked] (Michael Welzl)
Date: Wed Oct 11 18:42:09 2006
Subject: [Iccrg] Meeting agenda (really! :-) )
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

I fully agree (and more, I'm very happy about this proposal!),
if Keshav also does.

Cheers,
Michael

On Wed, 2006-10-11 at 17:54, Bob Briscoe wrote:
> Michael,
> 
> 1/ I have a paper close to finishing (just got friendly reviews back) that 
> I would like to present. It deconstructs the dominant understanding of 
> fairness used in congestion control, explaining why fair allocation of 
> rates to flows is the wrong question. It explains why flows aren't entities 
> that we would expect to be fair to (and rate is the wrong thing to allocate 
> anyway).
> 
> It will help answer the question in this thread about striping aross 
> multiple paths, and generally completely re-boots most people's 
> understanding of fairness, showing just how impractical and unrealistic the 
> current way we think about fairness is.
> 
> This work has huge implications on router-allocated flow rate fairness like 
> XCP (and RCP if one allows that RCP has less ambitious fairness goals in 
> the first place). It should get a good debate going.
> 
> This is also intrinsic to our deeply held views on the definition of 
> congestion, so it will contribute strongly to that debate (Lou Burness's 
> contribution to the mailing list debate on that ages ago seemed to go 
> undebated).
> 
> 2/ We may also have work presentable by Feb on what per datagram congestion 
> 'signalling' bandwidth is necessary for hi speed congestion control as flow 
> rates increase. What do I mean by signalling bandwidth? As an example, 
> packet discard or ECN gives 1 bit per packet of signalling bandwidth. FAST 
> claims to use congestion loss to give multibit feedback per packet, but we 
> aim to quantify what 'multibit' means in this case, and why you get less 
> signalling bandwidth per packet from measuring congestion delay as link 
> speeds increase. The aim is to quantify at what point congestion 
> delay-based approaches would get less than 1 bit per packet signalling 
> bandwidth. Finally, we have a hypothesis on how to solve the problem more 
> generally, which we may have proved by Feb, but that's a bit ambitious.
> 
> So, for the moment, I'd rather just offer the fairness work, but watch this 
> space.
> 
> 
> Bob
> 
> At 21:08 13/09/2006, Michael Welzl wrote:
> > > I think it would be interesting to try to come up with two things
> > > 1. What we know. Known 'good' approaches - i.e. whats common to the
> > > proposals out there.
> >
> >but what exactly shall we expect to learn from / accomplish with this?
> >I mean, we can write an overview, looking at commonalities ... to
> >be concrete, I think this can be something like "delay has been used
> >as a congestion measure in ... Vegas, FAST, ... it has the following
> >advantages, the following disadvantages..."  ... and so on and so forth.
> >
> >That might be nice, but I'm having a hard time imagining that this
> >will take us anywhere. Also, such overviews exist - how much
> >should the overview differ from, say, this one:
> >http://transport.internet2.edu/transport-design-space.pdf
> >or the others in our Wiki?
> >
> >And what would it accomplish that the others don't?
> >
> >Cheers,
> >Michael
> >
> >
> >_______________________________________________
> >Iccrg mailing list
> >[email-masked]
> >http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 
> ____________________________________________________________________________
> 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: [email-masked] (Bob Briscoe)
Date: Wed Oct 11 18:44:53 2006
Subject: [Iccrg] Meeting agenda (really! :-) )
In-Reply-To: <002a01c6d770$66b9cf00$0200a8c0@fun>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Michael,

1/ I have a paper close to finishing (just got friendly reviews back) that 
I would like to present. It deconstructs the dominant understanding of 
fairness used in congestion control, explaining why fair allocation of 
rates to flows is the wrong question. It explains why flows aren't entities 
that we would expect to be fair to (and rate is the wrong thing to allocate 
anyway).

It will help answer the question in this thread about striping aross 
multiple paths, and generally completely re-boots most people's 
understanding of fairness, showing just how impractical and unrealistic the 
current way we think about fairness is.

This work has huge implications on router-allocated flow rate fairness like 
XCP (and RCP if one allows that RCP has less ambitious fairness goals in 
the first place). It should get a good debate going.

This is also intrinsic to our deeply held views on the definition of 
congestion, so it will contribute strongly to that debate (Lou Burness's 
contribution to the mailing list debate on that ages ago seemed to go 
undebated).

2/ We may also have work presentable by Feb on what per datagram congestion 
'signalling' bandwidth is necessary for hi speed congestion control as flow 
rates increase. What do I mean by signalling bandwidth? As an example, 
packet discard or ECN gives 1 bit per packet of signalling bandwidth. FAST 
claims to use congestion loss to give multibit feedback per packet, but we 
aim to quantify what 'multibit' means in this case, and why you get less 
signalling bandwidth per packet from measuring congestion delay as link 
speeds increase. The aim is to quantify at what point congestion 
delay-based approaches would get less than 1 bit per packet signalling 
bandwidth. Finally, we have a hypothesis on how to solve the problem more 
generally, which we may have proved by Feb, but that's a bit ambitious.

So, for the moment, I'd rather just offer the fairness work, but watch this 
space.

Bob

At 21:08 13/09/2006, Michael Welzl wrote:
> > I think it would be interesting to try to come up with two things
> > 1. What we know. Known 'good' approaches - i.e. whats common to the
> > proposals out there.
>
>but what exactly shall we expect to learn from / accomplish with this?
>I mean, we can write an overview, looking at commonalities ... to
>be concrete, I think this can be something like "delay has been used
>as a congestion measure in ... Vegas, FAST, ... it has the following
>advantages, the following disadvantages..."  ... and so on and so forth.
>
>That might be nice, but I'm having a hard time imagining that this
>will take us anywhere. Also, such overviews exist - how much
>should the overview differ from, say, this one:
>http://transport.internet2.edu/transport-design-space.pdf
>or the others in our Wiki?
>
>And what would it accomplish that the others don't?
>
>Cheers,
>Michael
>
>
>_______________________________________________
>Iccrg mailing list
>[email-masked]
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

____________________________________________________________________________
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: [email-masked] (Michael Welzl)
Date: Tue Oct 10 18:14:05 2006
Subject: [Iccrg] draft-irtf-iccrg-cc-rfcs-00.txt
Message-ID: <[email-masked]>

Dear all,

Wesley Eddy and I finished the first version of our overview
of congestion control related efforts in the IETF. It's available
at http://www.ietf.org/internet-drafts/draft-irtf-iccrg-cc-rfcs-00.txt
and there's now a link in our Wiki.

We would greatly appreciate any comments - especially as we
made this a RG item and intend to publish this as an RFC,
meaning that we also need RG consensus.

Cheers,
Michael

From: [email-masked] (Lachlan Andrew)
Date: Mon Oct  9 03:29:21 2006
Subject: [Iccrg] Fwd: CFP - PFLDnet2007 -- Extended deadline
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Fifth International Workshop on Protocols for Fast, Long Distance networks, 2007
     (PFLDnet2007)
7, 8 February 2007,  ISI, Marina Del Rey (Los Angeles), California

http://wil.cs.caltech.edu/pfldnet2007/cfp.php

PAPER SUBMISSION DEADLINE:  EXTENDED to 20 OCTOBER, 2006

Future networks will increasingly contain high bandwidth, high delay
paths. Protocols for fast, long distance networks will have to expand
from experimental testbeds and into the wider world. In that process,
it is increasingly important for protocols which achieve high
utilization on fast, long distance networks also to have the qualities
required for widespread use, such as fairness and scalability to many
users.

PFLDnet2007 solicits papers which will further research towards on
protocols for tomorrow's high speed internet, at all stages along the
continuum from the requirements of today's grid networks, through
benchmarking of proposals, to the final selection of the next
generation of TCP.

Participants wishing to present a paper should upload a full paper to
the submission site by Friday 20 October, 2006.
Papers should be typically 4-5 pages, but no longer than 6 pages.

Scope: (choose at least one of the subject areas below - multiple
selections possible)

   * Protocol issues in fast long-distance networks
   * Protocol development
         o Enhancements of TCP and its variants
         o Novel data transport protocols designed for new application services
         o Explicit signaling protocols: Optimization criteria and
deployment strategies
         o Pacing and shaping of TCP and UDP traffic
         o Parallel transfers and multistreaming
   * Performance evaluation
         o Modeling and simulation-based results
         o Experiments on real networks and actual measurements
         o Protocol benchmarking
   * Hardware-specific issues
         o Transport over optical networks
         o RDMA over WANs
         o Protocol implementation and hardware issues (PCs, NICs,
TOEs, routers, switches, etc.)
         o Data replications and striping
   * Application focus
         o Requirements and experience from bandwidth demanding applications
         o Bulk-data transfer applications both TCP and non-TCP based
         o Transport service for Grids
         o QoS and scalability issues
         o Multicast over fast long-distance networks

Authors whose papers are selected for presentation will have the
option to submit a revised paper, to be published on the PFLDnet 2007
web site and in the PFLDnet 2007 proceedings.

Conference Co-Chairs:
   Lachlan Andrew
   Aaron Falk
   Medy Sanadidi

TPC Co-Chairs:
   Lachlan Andrew
   Doug Leith
   Medy Sanadidi

Important Dates
   ***Initial paper submission deadline: EXTENDED to Friday 20 October, 2006***
   Acceptance notification: Monday 4 December, 2006
   Final paper submission: Wednesday 24 January, 2007
   Workshop: Wednesday and Thursday, 7 and 8 February, 2007

--
Lachlan Andrew, Aaron Falk, Doug Leith and Medy Sanadidi
co-chairs / TPC co-chairs