Subject: [Iccrg] LSS and http transaction response time
From: [email-masked] (Dirceu Cavendish)
Date: Fri Jun 13 08:03:07 2008

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: SS_LSS.pdf
Type: application/pdf
Size: 294072 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080612/b0e8b568/SS_LSS-0001.pdf

From: [email-masked] (Lisong Xu)
Date: Wed Jun  4 15:28:18 2008
Subject: [Iccrg] A review of the CUBIC draft
In-Reply-To: <001501c8bfef$7e84cae0$3340a8c0@DCXMWG81>
References: <002201c8bf3b$24d36ab0$d0f5e88a@DCXMWG81> <[email-masked]> <001501c8bfef$7e84cae0$3340a8c0@DCXMWG81>
Message-ID: <[email-masked]>

Dear Kashif and Lachlan,

Thank you for your comments on CUBIC! Sorry for my late reply, and I 
have been traveling for the past two weeks.

We do not have any results of CUBIC in wireless networks yet. We expect 
that in wireless networks, CUBIC should also "behave relatively less 
aggressive to the standard TCP flows (in other words more TCP friendly) 
than some of the other high speed protocols."

Yes, you made a good point. We will perform some experiments to evaluate 
the performance of CUBIC in wireless networks.

Regarding the sentences on page 13 of the draft, you are right that the 
sentences are not accurate. The first sentence should be "CUBIC ensures 
convergence of competing CUBIC flows with the same RTT in the same 
bottleneck links to an equal bandwidth share."

Thank you again for your comments!
Lisong

-- 
Lisong Xu, Assistant Professor
Computer Science & Engineering
University of Nebraska-Lincoln
http://cse.unl.edu/~xu

Kashif Munir wrote:
> Dear Lachlan,
> 
> Thanks for the comments. Basically, I am asked to comment on two things.
> 
> One of them is the protocol's impact on competing flows. I believe, it is
> "mainly" about the protocol's fairness to standard TCP in difficult and
> typical scenarios (like those mentioned in your paper "Towards a Common TCP
> Evaluation Suite"). It can only be a relative comparison and by seeing the
> results in the draft and in the CUBIC related papers, it is shown to behave
> relatively less aggressive to the standard TCP flows (in other words more
> TCP friendly) than some of the other high speed protocols. However, it is
> one of the metrics that must be considered along with other metrics. In the
> case of the networks having more loss rate, the performance of CUBIC is no
> worse than that of standard TCP and relatively less aggressive to standard
> TCP than some of the other variants. 
> 
> Although the authors mention that in the case of wireless networks, CUBIC's
> performance is no worse than that of regular TCP; it would be interesting to
> see some results showing its impact on competing flows in that sort of
> environments.
> 
> Regarding RTT-fairness, I agree that there is no point in calling a protocol
> as RTT-fair if it is just for the exceptional case when all RTTs are equal.
> The CUBIC draft does explain it on page numbers 3, 4 and 13 of the draft.
> However, the explanation may further be refined. For example, on page 13 of
> the draft it is mentioned, "CUBIC ensures convergence of competing CUBIC
> flows in he same bottleneck links to an equal bandwidth share. When
> competing flows have different RTTs, their bandwidth shares are linearly
> proportional to the inverse of their RTT ratios." If I have understood
> correctly, the sentences are contradicting. It is possible that two flows
> having different RTTs sharing a same bottleneck link. According to the first
> sentence both flows would share the bandwidth equally but according to the
> second they would not. I would not say that this is not strength of the
> protocol as according to the RFC 5166 (Metrics for the Evaluation of
> Congestion Control Mechanisms), a congestion control mechanism should be
> evaluated in terms of trade-offs between a range of metrics and not just
> only for a single metric.  
> 
> 
> 
> Best Regards,
> Kashif Munir
> -------------------
> PhD Candidate
> Institute of Computer Science
> University of Innsbruck, Austria
> Homepage: http://dps.uibk.ac.at/~kashif/
> 
>  
>  
>  
> -----Original Message-----
> From: Lachlan Andrew [mailto:[email-masked]] 
> Sent: Monday, May 26, 2008 8:00 PM
> To: Kashif Munir
> Cc: iccrg
> Subject: Re: [Iccrg] A review of the CUBIC draft
> 
> Greetings Kashif,
> 
> Thanks for the review.
> 
> 2008/5/26 Kashif Munir <[email-masked]>:
>> The CUBIC protocol can be considered safe for
>> deployment as it does not perform worse than TCP in difficult environments
>> like wireless networks.
> 
> My understanding was that being "safe" is normally about the
> algorithm's impact on *competing* flows, rather than its own
> performance.  Could you please comment on how well other flows fare in
> difficult (and typical) environments when CUBIC is used?
> 
>> the explanation must be clear
>> and consistent throughout the document. It must be clearly specified that
>> the CUBIC flows are only RTT-fair when they have same RTT
> 
> What does RTT fairness mean if all RTTs are equal?
> 
>> and by taking some
>> time for convergence to fair share otherwise the CUBIC flows have their
>> bandwidth shares linearly proportional to the inverse of their RTT ratio.
> 
> Good.  That is more RTT fair than Reno.
> 
> Cheers,
> Lachlan
> 

From: [email-masked] (Bob Briscoe)
Date: Mon Jun  2 19:00:43 2008
Subject: [Iccrg] Re: I-D  ACTION:draft-irtf-iccrg-welzl-congestion-control-open-research-01.tx t
In-Reply-To: <[email-masked] m>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Lachlan,

You're (of course) strictly correct - that I'm a proponent of a 
policing function in the network to regulate e2e congestion control.

But the goal of re-ECN was "What's the minimum necessary in the 
network that's still sufficient to give accountability for causing 
congestion." Only in that sense does it comply with the e2e 
principle. After all, the e2e principle has been clarified as a 
guideline to make designers think long and hard hard before putting 
something in the network.

There is a parallel here with RED and drop-based TCP. Drop is the 
minimum function necessary in the network to make TCP's e2e 
congestion control work. And RED-based drop makes it work 'better' 
(allegedly removing synchronisation etc). So the e2e-ness of TCP is a 
point on a spectrum that isn't quite extreme e2e. And ECN-based TCP 
is a little further inward on the spectrum. And re-ECN is a little 
further in again in order to add accountability.

At least we removed the need for per-flow policing in the network, so 
new congestion controls can evolve - that's the important bit. There 
is still optional per-flow processing in the network, but it can work 
without it.

Bob

At 14:07 02/06/2008, Lachlan Andrew wrote:
>2008/5/30 Bob Briscoe <[email-masked]>:
> >
> > At 15:02 27/05/2008, Michael Scharf wrote:
> >>
> > [snip]
> >>
> >> For instance, [1] concludes that "congestion control is one
> >> function that is not well suited to end-to-end implementation."  I
> >> guess that not everyone will agree to this statement.
> >
> > I for one disagree...
>
>Doesn't it depend on how "end-to-end implementation" is defined?  Bob,
>I thought you championed the idea of re-ECN, which is all about the
>need for network involvement in congestion control.  The end systems
>make the decision, but it isn't "end-to-end" in the sense of
>interaction only between end-to-end peers at layer 4.
>
>Lachlan
>
>--
>Lachlan Andrew Dept of Computer Science, Caltech
>1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
>Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603
>http://netlab.caltech.edu/lachlan

____________________________________________________________________________
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] (Lachlan Andrew)
Date: Mon Jun  2 13:50:13 2008
Subject: [Iccrg] Re: I-D  ACTION:draft-irtf-iccrg-welzl-congestion-control-open-research-01.tx t
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

2008/5/30 Bob Briscoe <[email-masked]>:
>
> At 15:02 27/05/2008, Michael Scharf wrote:
>>
> [snip]
>>
>> For instance, [1] concludes that "congestion control is one
>> function that is not well suited to end-to-end implementation."  I
>> guess that not everyone will agree to this statement.
>
> I for one disagree...

Doesn't it depend on how "end-to-end implementation" is defined?  Bob,
I thought you championed the idea of re-ECN, which is all about the
need for network involvement in congestion control.  The end systems
make the decision, but it isn't "end-to-end" in the sense of
interaction only between end-to-end peers at layer 4.

Lachlan

-- 
Lachlan Andrew Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603
http://netlab.caltech.edu/lachlan

From: [email-masked] (marcelo bagnulo braun)
Date: Mon Jun  2 12:03:24 2008
Subject: [Iccrg] CFP ReArch'08
Message-ID: <[email-masked]>

Now with a more email client friendly format
Sorry for the noise

-------------------------------------------------------------

ReArch?08 - Re-Architecting the Internet
?Exploring what is broken with the Internet architecture
and how to fix it.?

  Madrid, Spain

         9 December, 2008

co-located with ACM CoNEXT'2008 sponsored by ACM Sigcomm

http://www.sigcomm.org/co-next2008/rearch.html

Motivation

The Internet architecture has been remarkably successful in
allowing a planet-scale internetwork to form. However, this
architecture is losing its original simplicity and
transparency as new classes of applications, operational and
management requirements, business models, security mechanisms
and scalability enablers give rise to point solutions that
extend the architecture without regard to the original design
principles.

While these mechanisms are necessary for Internet operation
under current economical, technical and social conditions,
their combination has significantly reduced the potential for
incremental evolution of the Internet architecture. This loss
of flexibility is already being felt as the number of Internet
nodes grows by another order of magnitude.

Several substantial Future Internet initiatives have started
in Europe, the US and Asia, and the vendor and network
operator communities are also actively discussing the
limitations of the current Internet architecture as well as
its potential evolution.

This workshop will discuss what the real underlying problems
are with the Internet and how we might fix them so that the
Internet architecture re-gains its simplicity and
transparency and is fit for another 30+ years, so that the
architectural simplicity and clarity of the Internet can be
regained and retained for another 30+ years.

This workshop solicits original, high-quality papers that
analyze, and discuss ideas for a new Internet architecture,
including specific improvements to current Internet protocols,
especially at the internetworking, transport and application
layers, new internetworking components that integrate into
the existing architecture and ideas for clean-slate
internetworking architectures.

Topics

ReArch'08 covers all aspects related to the current and future
Internet architecture including, but not limited to, how the
following impact on that architecture:

    New networking paradigms
    New business models
    New routing architectures
    New traffic engineering and congestion control mechanisms
    Measurements and analysis that characterize the real
      architectural limitations
    New architecture proposals and their implications for
      research
    New protocols that address the limitations
    Studies of interactions between stakeholders of the
      Internet and the architecture itself
    Design principles and interfaces to accommodate the
      conflicting interests of stakeholders in the architecture
    Principles of evolving future architectures
    Requirements for interworking with the existing Internet,
      and for deployability.

Papers that present interesting, fresh ideas at an early stage
are more suitable for this workshop than highly polished results
or incremental refinements of previous work. Submissions may
include position papers that point out new directions and
stimulate discussion; position papers should be clearly marked.
Submissions must be original and not already published in any
other conference proceedings or journal. Proceedings of the
workshop will be published in the ACM Digital Library.

Submissions

Submitted papers must be at most 6 pages long (including figures,
tables, references, etc.) in the standard ACM double column format.
All text must use font sizes of 10 points or larger. Longer
submissions will not be reviewed. The review process is single-blind.
Submissions will be done via EDAS.

Submission Deadline:         15 August 2008
Notification:                10 October 2008

Workshop Co-Chairs
Olivier Bonaventure - UCLouvain
Marcelo Bagnulo - UC3M
Joe Touch - USC/ISI

Technical Program Committee

Mark Allman           ICSI
Jari Arkko            Ericsson
Bob Briscoe           BT Group
Ken Calvert           University of Kentucky
Brian Carpenter       University of Auckland
Maoke Chen            Tsinghua University
Kenjiro Cho           IIJ
Jon Crowcroft         University of Cambridge
Philip Eardley        BT Group
Lars Eggert           Nokia Research Center
Kevin Fall            Intel Research
Pierre Francois       UCLouvain
Robert Hancock        Roke Manor Research
Mark Handley          University College London
Christian Huitema     Microsoft
Daniel Massey         Colorado State University
Martin May            ETH Zurich
Pekka Nikander        Ericsson Research Nomadiclab
Craig Partridge       BBN Technologies
Peter Steenkiste      Carnegie Mellon University
Iljitsch van Beijnum  IMDEA Metworks
Tilman Wolf           University of Massachusetts

From: [email-masked] (marcelo bagnulo braun)
Date: Mon Jun  2 10:59:48 2008
Subject: [Iccrg] CFP ReArch'08
Message-ID: <[email-masked]>

Sorry if you receive multiple copies

--------------------------------------------------------------

ReArch?08 - Re-Architecting the Internet
?Exploring what is broken with the Internet architecture 
and how to fix it.?

  Madrid, Spain

         9 December, 2008

co-located with ACM CoNEXT'2008 sponsored by ACM Sigcomm

http://www.sigcomm.org/co-next2008/rearch.html

Motivation

The Internet architecture has been remarkably successful in 
allowing a planet-scale internetwork to form. However, this 
architecture is losing its original simplicity and 
transparency as new classes of applications, operational 
and management requirements, business models, security 
mechanisms and scalability enablers give rise to point 
solutions that extend the architecture without regard to the 
original design principles.

While these mechanisms are necessary for Internet operation 
under current economical, technical and social conditions, 
their combination has significantly reduced the potential 
for incremental evolution of the Internet architecture. This 
loss of flexibility is already being felt as the number of 
Internet nodes grows by another order of magnitude.

Several substantial Future Internet initiatives have started 
in Europe, the US and Asia, and the vendor and network operator
communities are also actively discussing the limitations of 
the current Internet architecture as well as its potential 
evolution.

This workshop will discuss what the real underlying problems 
are with the Internet and how we might fix them so that the 
Internet architecture re-gains its simplicity and transparency 
and is fit for another 30+ years, so that the architectural 
simplicity and clarity of the Internet can be regained and 
retained for another 30+ years.

This workshop solicits original, high-quality papers that 
analyze, and discuss ideas for a new Internet architecture, 
including specific improvements to current Internet protocols,
especially at the internetworking, transport and application 
layers, new internetworking components that integrate into 
the existing architecture and ideas for clean-slate 
internetworking architectures.

Topics

ReArch'08 covers all aspects related to the current and 
future Internet architecture including, but not limited 
to, how the following impact on that architecture:

    New networking paradigms
    New business models
    New routing architectures
    New traffic engineering and congestion control 
     mechanisms
    Measurements and analysis that characterize the 
     real architectural limitations
    New architecture proposals and their implications 
     for research
    New protocols that address the limitations
    Studies of interactions between stakeholders of the 
     Internet and the architecture itself
    Design principles and interfaces to accommodate the 
     conflicting interests of stakeholders in the architecture
    Principles of evolving future architectures
    Requirements for interworking with the existing Internet, 
     and for deployability.

Papers that present interesting, fresh ideas at an early 
stage are more suitable for this workshop than highly 
polished results or incremental refinements of previous work.
Submissions may include position papers that point out new 
directions and stimulate discussion; position papers should 
be clearly marked. Submissions must be original and not 
already published in any other conference proceedings or 
journal. Proceedings of the workshop will be published in the 
ACM Digital Library.

Submissions

Submitted papers must be at most 6 pages long (including 
figures, tables, references, etc.) in the standard ACM 
double column format. All text must use font sizes of 10 
points or larger. Longer submissions will not be reviewed. 
The review process is single-blind. Submissions will be 
done via EDAS.

Submission Deadline:	 	15 August 2008 
Notification: 		 	10 October 2008

Workshop Co-Chairs
Olivier Bonaventure - UCLouvain
Marcelo Bagnulo - UC3M
Joe Touch - USC/ISI

Technical Program Committee

Mark Allman    	      ICSI
Jari Arkko 	      Ericsson
Bob Briscoe 	      BT Group
Ken Calvert           University of Kentucky
Brian Carpenter       University of Auckland
Maoke Chen 	      Tsinghua University
Kenjiro Cho 	      IIJ
Jon Crowcroft 	      University of Cambridge
Philip Eardley 	      BT Group
Lars Eggert 	      Nokia Research Center
Kevin Fall            Intel Research
Pierre Francois       UCLouvain
Robert Hancock 	      Roke Manor Research
Mark Handley 	      University College London
Christian Huitema     Microsoft
Daniel Massey         Colorado State University
Martin May   	      ETH Zurich
Pekka Nikander        Ericsson Research Nomadiclab
Craig Partridge       BBN Technologies
Peter Steenkiste      Carnegie Mellon University
Iljitsch van Beijnum  IMDEA Metworks
Tilman Wolf 	      University of Massachusetts

From: [email-masked] (Michael Scharf)
Date: Mon Jun  2 07:05:57 2008
Subject: [Iccrg] Re: I-D  ACTION:draft-irtf-iccrg-welzl-congestion-control-open-research-01.tx t
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 28 May 2008 at 14:15:11, Michael Welzl wrote:
> > Can anyone recommend relevant references other than [1]?
> > 
> > Michael
> > 
> > 
> > [1] T. Moors: "A critical review of "End-to-end arguments in system
> > design"", Proc. International Conference on Communications (ICC), 2002
> 
> yes, i can. there's a (IMO) great discussion of the e2e argument in
> the Joe Touch / James Sterbenz book:
> "High-Speed Networking: A Systematic Approach to High-Bandwidth Low
> Latency Communication"
> Wiley, 2001
> 
> David Reed also has some things on his website, at
> http://www.reed.com/dpr/ under "papers" and "thoughts",
> respectively

Michael, Bob, thanks for these references. I will have a look at them
and write a short paragraph that summarizes their findings.

Michael