Subject: [Iccrg] SSDT Scope - summary
From: [email-masked] (Dirceu Cavendish)
Date: Mon Mar 31 08:22:59 2008

Back to Lachlan initial email, it seems that the low hanging fruit of :application limited" re-start
is a good way to start experimenting with faster than SS schemes.

HOWEVER, the characterization of the other cases, as discussed in this thread, is also a valuable contribution.

Dirceu

----- Original Message ----
From: Michael Welzl <[email-masked]>
To: Lachlan Andrew <[email-masked]>
Cc: Dirceu Cavendish <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Monday, March 31, 2008 12:19:37 AM
Subject: Re: [Iccrg] SSDT Scope - summary

> 1. I agree that resuming after "application constrained" is a more
> clear-cut case for more rapid increase.  If we can improve that case,

Me too.

> 2. It isn't clear to me that the possibility of path changes is a
> sufficient reason not to use better slow-start after timeout.

That was just an example - my point is that, generally, we
should assume to know nothing after an RTO

> 2a) We still start from a low rate and build up, stopping if we get a loss

as with original slow start  :)

> 2b) Most route changes will be between "similar" links -- like
> rerouting within a backbone.  We'd only have problems if, for example,
> we were forced off a GbE link onto an ADSL backup link

too much guesswork IMO

> 2c) Even if we do overshoot significantly, we'll get a stack of losses
> and time out again, but this time with a reduced  ssthresh.

as with original slow start

conclusion: while I'm generally in favor of making slow start
a bit faster in its initial phase, your points above don't
convince me that this would better be done when an RTO occurs
during a connection.

> There may be a smarter way to make use of the fact that we have *some*
> information about probability distribution of the BDP.

yup - if we do, as it might be reasonable to assume in
the app-limited case

cheers
michael

      ____________________________________________________________________________________
Special deal for Yahoo! users & friends - No Cost. Get a month of Blockbuster Total Access now 
http://tc.deals.yahoo.com/tc/blockbuster/text3.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080331/2ead91fe/attachment.html
>From [email-masked]  Mon Mar 31 09:22:38 2008
From: [email-masked] (Lachlan Andrew)
Date: Mon Mar 31 09:14:12 2008
Subject: [Iccrg] SSDT Scope - summary
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Greetings Michael,

On 31/03/2008, Michael Welzl <[email-masked]> wrote:
> That was just an example - my point is that, generally, we
>  should assume to know nothing after an RTO

That is roughly the traditional "safe" option (although for some
reason we normally assume ssthresh retained some meaning).  However,
the estimation theorist in me recoils  at the idea of pretending we
know nothing...

>  > 2a) We still start from a low rate and build up, stopping if we get a loss
>
> as with original slow start   :)

But when we first start, we don't know if we're talking to a 300bps
mote or a 100GbE supercomputer.  After a single timeout, we will
generally (???) be using a "similar" network.    If we know *roughly*
where we're going, we know roughly how fast to get there, and don't
need to accelerate in the process.  Linear increase gets going sooner,
and overshoots less.

Anyway, fixing the problem of the initial slow start is probably more
productive.

Cheers,
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] (Lachlan Andrew)
Date: Mon Mar 31 08:22:42 2008
Subject: [Iccrg] ICCRG experimental CC reviews
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Michael,

On 30/03/2008, Michael Welzl <[email-masked]> wrote:
> > There were many stylistic issues the the CTCP draft, like not
>  > specifying parameter values,  the SHOUD/MUST/... terminology, what is
>  > normative vs informative..
>  >
>  > It would be good to write up a "how-to" for drafts, specifying what
>  > format the drafts should have, and what pitfalls to avoid.  That
>  > should speed the process up for future proposals.
>
> This is just an IETF standard, and must therefore already
>  exist somewhere... a few hints are at http://www.ietf.org/ID.html

Most of those guidelines are generic.  I meant things specific to the
call for new congestion controls.  See below.

If everyone submits initial draft meeting those criteria, then the
review process should be faster than the CTCP one was.

>  > Guidelines would help.  Perhaps we should specify that the draft
>  > should point to independent tests (on a non-buggy implementation).
>
> - that should be clear without a guideline IMO.

I was partly having a dig at the CTCP case, where they conscientiously
got SLAC to do some tests, but I believe it was on an early
implementation which had a major bug...  (Sorry Murari :)  For
example, a guideline could suggest that actual CWND histories be
plotted, as well as aggregate quantities, since this exposes many
possible bugs.

In case it helps, I'd suggest guidelines of:
1. As these are intended to be experimental RFCs, they should use
"SHOULD", "MUST" etc. to make clear which options are part of the
proposal.
2. They should specify the ranges of all parameters
3. There should be a clear statement of the algorithm, separated out
from justifications and motivations for the steps.  It should say when
each calculation is performed (once per CWND, once per ACK, at
timeout, ...)
4. Give a summary of the validation experiments, in addition to
informative references
5. The validation examples should plot some CWND histories, since
these would highlight many possibly bugs.
6. State which other options were used in conjunction with this in the
test (e.g. ABC, FRTO, ...)
7. Be careful about corner cases, such as
 a) clipping values to be non-negative
 b) whether values rounded to integers
 c) what to do after timeout or an idle connection
 d) replace phrases like "update x" by "set x to y".
8. Give an open-source implementation

Cheers,
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] (Michael Welzl)
Date: Mon Mar 31 08:11:12 2008
Subject: [Iccrg] SSDT Scope - summary
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> 1. I agree that resuming after "application constrained" is a more
> clear-cut case for more rapid increase.  If we can improve that case,

Me too.

> 2. It isn't clear to me that the possibility of path changes is a
> sufficient reason not to use better slow-start after timeout.

That was just an example - my point is that, generally, we
should assume to know nothing after an RTO

> 2a) We still start from a low rate and build up, stopping if we get a loss

as with original slow start   :)

> 2b) Most route changes will be between "similar" links -- like
> rerouting within a backbone.  We'd only have problems if, for example,
> we were forced off a GbE link onto an ADSL backup link

too much guesswork IMO

> 2c) Even if we do overshoot significantly, we'll get a stack of losses
> and time out again, but this time with a reduced  ssthresh.

as with original slow start

conclusion: while I'm generally in favor of making slow start
a bit faster in its initial phase, your points above don't
convince me that this would better be done when an RTO occurs
during a connection.

> There may be a smarter way to make use of the fact that we have *some*
> information about probability distribution of the BDP.

yup - if we do, as it might be reasonable to assume in
the app-limited case

cheers
michael

From: [email-masked] (Lachlan Andrew)
Date: Mon Mar 31 08:00:27 2008
Subject: [Iccrg] SSDT Scope - summary
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Dirceu and Michael,

1. I agree that resuming after "application constrained" is a more
clear-cut case for more rapid increase.  If we can improve that case,
that is already a win.  (BTW, Sally was the one proposing quadrupling.
 My point was that linear increase avoids the excessive overshoot that
comes with exponential increase, be it quadrupling or doubling, while
simultaneously giving a rapid initial start.)

2. It isn't clear to me that the possibility of path changes is a
sufficient reason not to use better slow-start after timeout.
2a) We still start from a low rate and build up, stopping if we get a loss
2b) Most route changes will be between "similar" links -- like
rerouting within a backbone.  We'd only have problems if, for example,
we were forced off a GbE link onto an ADSL backup link
2c) Even if we do overshoot significantly, we'll get a stack of losses
and time out again, but this time with a reduced  ssthresh.

There may be a smarter way to make use of the fact that we have *some*
information about probability distribution of the BDP.

Cheers,
Lachlan

On 30/03/2008, Michael Welzl <[email-masked]> wrote:
> On Fri, 2008-03-28 at 15:10 -0700, Dirceu Cavendish wrote:
>  > Lachlan,
>  >
>  > I've parsed your reference. I guess your focus is on "application
>  > constrained/idle" scenario.
>  > Of course, in this case, there is no ambiguity about RTO causes...
>
>
> ... and the unknown cause is a problem that I have with
>  the idea of, say, quadrupling after an RTO, based on the
>  reasoning that we have an idea of the BDP.
>
>  I think that, after an RTO, the assumption is that we have
>  no idea about anything in the network anymore. FWIW, it could
>  have been caused by a path change
>
>  Cheers,
>
> Michael
>
>
>  PS: Dirceu - I agree about the proposed scope in your previous message
>
>

-- 
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] (Michael Welzl)
Date: Mon Mar 31 07:01:31 2008
Subject: [Iccrg] SSDT Scope - summary
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Fri, 2008-03-28 at 15:10 -0700, Dirceu Cavendish wrote:
> Lachlan,
>  
> I've parsed your reference. I guess your focus is on "application
> constrained/idle" scenario.
> Of course, in this case, there is no ambiguity about RTO causes...

... and the unknown cause is a problem that I have with
the idea of, say, quadrupling after an RTO, based on the
reasoning that we have an idea of the BDP.

I think that, after an RTO, the assumption is that we have
no idea about anything in the network anymore. FWIW, it could
have been caused by a path change

Cheers,
Michael

PS: Dirceu - I agree about the proposed scope in your previous message

From: [email-masked] (Dirceu Cavendish)
Date: Fri Mar 28 19:01:20 2008
Subject: [Iccrg] SSDT Scope - summary
Message-ID: <[email-masked]>

Lachlan,

I will look at your reference. But taking the risk of a quick reply before that...

One problem I see is how we can differentiate between RTOs for which the path does not change from the ones that are caused by path change...

My problem with Quick Start is its required support from routers, before anything else.

Any solution will have to strike a balance between being too aggressive in certain network scenarios and not being aggressive enough in others. Unless the solution is adaptive...

But definitely, multiple SS issue should be listed as a separate one, although it may be triggered by overshooting of the buffer at large BDP, already listed...

Thanks for pointing that out.
Dirceu

----- Original Message ----
From: Lachlan Andrew <[email-masked]>
To: Dirceu Cavendish <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Friday, March 28, 2008 10:51:09 AM
Subject: Re: [Iccrg] SSDT Scope - summary

Greetings Dirceu,

One "low-hanging fruit" would be to fix a slow start which occurs
after timeout or an idle period, rather than at the start of a
connection.  In these cases, the sender has a good guess at the right
BDP.  In Chicago, Sally gave a presentation suggestion quadrupling
(instead of doubling) up to the guessed BDP.  That helps problem 1,
but exacerbates problem 2.

If we have an estimate of the BDP, then *both* problems can be solved
by increasing the rate linearly (at a suitable rate) rather than
exponentially.  Take a look at
<http://netlab.caltech.edu/lachlan/abstract/AIslowstart.pdf> if you're
interested.

Personally, I'm not a fan of QuickStart/JumpStart, because it doesn't
give other flows enough time to back off.  However, using QuickStart
signalling to specify the final BDP would allow this linear increase
over a suitable number of RTTs for slow start at the start of a
connection too.

$0.02,
Lachlan

On 28/03/2008, Dirceu Cavendish <[email-masked]> wrote:
>
> I went through this week's messages on SS topics, and here is a summary of
> them:
>
> - Transaction latencies taking too long to complete, in a large bandwidth
> delay product networks.
> - Buffer overshoot, causing multiple segment losses/retransmits, potentially
> causing RTOs
>
> The first item can be seen as SS being too conservative/slow, whereas the
> second one may be cast as SS being too aggressive in doubling cwnd when
> current cwnd is large (high BDP networks). So, my proposal would be to scope
> the SSDT as to CHARACTERIZE these two issues first. Depending on how fast we
> go with this work, we can then address/analyze solutions, such as Quick
> Start, limited slow start, and others...But I think a good characterization
> will bring already the features we would like to see in a solution, without
> having to lock ourselves up to any one.
>
> Dirceu
>
>
>
>  ________________________________
> Looking for last minute shopping deals? Find them fast with Yahoo! Search.
> _______________________________________________
>  Iccrg mailing list
>  [email-masked]
>  http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>

-- 
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

      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080328/fdf50548/attachment-0001.html
>From [email-masked]  Fri Mar 28 22:10:43 2008
From: [email-masked] (Dirceu Cavendish)
Date: Fri Mar 28 22:02:22 2008
Subject: [Iccrg] SSDT Scope - summary
Message-ID: <[email-masked]>

Lachlan,

I've parsed your reference. I guess your focus is on "application constrained/idle" scenario.
Of course, in this case, there is no ambiguity about RTO causes...

Rgds,
Dirceu

----- Original Message ----
From: Dirceu Cavendish <[email-masked]>
To: Lachlan Andrew <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Friday, March 28, 2008 12:09:37 PM
Subject: Re: [Iccrg] SSDT Scope - summary

Lachlan,

I will look at your reference. But taking the risk of a quick reply before that...

One problem I see is how we can differentiate between RTOs for which the path does not change from the ones that are caused by path change...

My problem with Quick Start is its required support from routers, before anything else.

Any solution will have to strike a balance between being too aggressive in certain network scenarios and not being aggressive enough in others. Unless the solution is adaptive...

But definitely, multiple SS issue should be listed as a separate one, although it may be triggered by overshooting of the buffer at large BDP, already listed...

Thanks for pointing that out.
Dirceu

----- Original Message ----
From: Lachlan Andrew <[email-masked]>
To: Dirceu Cavendish <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Friday, March 28, 2008 10:51:09 AM
Subject: Re: [Iccrg] SSDT Scope - summary

Greetings Dirceu,

One "low-hanging fruit" would be to fix a slow start which occurs
after timeout or an idle period, rather than at the start of a
connection.  In these cases, the sender has a good guess at the right
BDP.  In Chicago, Sally gave a presentation suggestion quadrupling
(instead of doubling) up to the guessed BDP.  That helps problem 1,
but exacerbates problem 2.

If we have an estimate of the BDP, then *both* problems can be solved
by increasing the rate linearly (at a suitable rate) rather than
exponentially.  Take a look at
<http://netlab.caltech.edu/lachlan/abstract/AIslowstart.pdf> if you're
interested.

Personally, I'm not a fan of QuickStart/JumpStart, because it doesn't
give other flows enough time to back off.  However, using QuickStart
signalling to specify the final BDP would allow this linear increase
over a suitable number of RTTs for slow start at the start of a
connection too.

$0.02,
Lachlan

On 28/03/2008, Dirceu Cavendish <[email-masked]> wrote:
>
> I went through this week's messages on SS topics, and here is a summary of
> them:
>
> - Transaction latencies taking too long to complete, in a large bandwidth
> delay product networks.
> - Buffer overshoot, causing multiple segment losses/retransmits, potentially
> causing RTOs
>
> The first item can be seen as SS being too conservative/slow, whereas the
> second one may be cast as SS being too aggressive in doubling cwnd when
> current cwnd is large (high BDP networks). So, my proposal would be to scope
> the SSDT as to CHARACTERIZE these two issues first. Depending on how fast we
> go with this work, we can then address/analyze solutions, such as Quick
> Start, limited slow start, and others...But I think a good characterization
> will bring already the features we would like to see in a solution, without
> having to lock ourselves up to any one.
>
> Dirceu
>
>
>
>  ________________________________
> Looking for last minute shopping deals? Find them fast with Yahoo! Search.
> _______________________________________________
>  Iccrg mailing list
>  [email-masked]
>  http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>

-- 
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

Looking for last minute shopping deals? Find them fast with Yahoo! Search.

      ____________________________________________________________________________________
Like movies? Here's a limited-time offer: Blockbuster Total Access for one month at no cost. 
http://tc.deals.yahoo.com/tc/blockbuster/text4.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080328/4f6e9a0e/attachment.html
>From [email-masked]  Mon Mar 31 07:05:39 2008
From: [email-masked] (Michael Welzl)
Date: Mon Mar 31 06:57:06 2008
Subject: [Iccrg] ICCRG experimental CC reviews
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> There were many stylistic issues the the CTCP draft, like not
> specifying parameter values,  the SHOUD/MUST/... terminology, what is
> normative vs informative..
> 
> It would be good to write up a "how-to" for drafts, specifying what
> format the drafts should have, and what pitfalls to avoid.  That
> should speed the process up for future proposals.

This is just an IETF standard, and must therefore already
exist somewhere... a few hints are at http://www.ietf.org/ID.html

> Guidelines would help.  Perhaps we should specify that the draft
> should point to independent tests (on a non-buggy implementation).  I
> don't think we should mandate independent re-implementation, but it
> would be good to encourage having at least one open-source
> implementation.

- that should be clear without a guideline IMO.

Cheers,
Michael

From: [email-masked] (Dirceu Cavendish)
Date: Fri Mar 28 17:25:53 2008
Subject: [Iccrg] SSDT Scope - summary
Message-ID: <[email-masked]>

I went through this week's messages on SS topics, and here is a summary of them:

- Transaction latencies taking too long to complete, in a large bandwidth delay product networks.
- Buffer overshoot, causing multiple segment losses/retransmits, potentially causing RTOs

The first item can be seen as SS being too conservative/slow, whereas the second one may be cast as SS being too aggressive in doubling cwnd when current cwnd is large (high BDP networks). So, my proposal would be to scope the SSDT as to CHARACTERIZE these two issues first. Depending on how fast we go with this work, we can then address/analyze solutions, such as Quick Start, limited slow start, and others...But I think a good characterization will bring already the features we would like to see in a solution, without having to lock ourselves up to any one.

Dirceu

      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080328/ad18c091/attachment.html
>From [email-masked]  Fri Mar 28 17:51:09 2008
From: [email-masked] (Lachlan Andrew)
Date: Fri Mar 28 17:42:46 2008
Subject: [Iccrg] SSDT Scope - summary
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Greetings Dirceu,

One "low-hanging fruit" would be to fix a slow start which occurs
after timeout or an idle period, rather than at the start of a
connection.  In these cases, the sender has a good guess at the right
BDP.  In Chicago, Sally gave a presentation suggestion quadrupling
(instead of doubling) up to the guessed BDP.  That helps problem 1,
but exacerbates problem 2.

If we have an estimate of the BDP, then *both* problems can be solved
by increasing the rate linearly (at a suitable rate) rather than
exponentially.  Take a look at
<http://netlab.caltech.edu/lachlan/abstract/AIslowstart.pdf> if you're
interested.

Personally, I'm not a fan of QuickStart/JumpStart, because it doesn't
give other flows enough time to back off.  However, using QuickStart
signalling to specify the final BDP would allow this linear increase
over a suitable number of RTTs for slow start at the start of a
connection too.

$0.02,
Lachlan

On 28/03/2008, Dirceu Cavendish <[email-masked]> wrote:
>
> I went through this week's messages on SS topics, and here is a summary of
> them:
>
> - Transaction latencies taking too long to complete, in a large bandwidth
> delay product networks.
> - Buffer overshoot, causing multiple segment losses/retransmits, potentially
> causing RTOs
>
> The first item can be seen as SS being too conservative/slow, whereas the
> second one may be cast as SS being too aggressive in doubling cwnd when
> current cwnd is large (high BDP networks). So, my proposal would be to scope
> the SSDT as to CHARACTERIZE these two issues first. Depending on how fast we
> go with this work, we can then address/analyze solutions, such as Quick
> Start, limited slow start, and others...But I think a good characterization
> will bring already the features we would like to see in a solution, without
> having to lock ourselves up to any one.
>
> Dirceu
>
>
>
>  ________________________________
> Looking for last minute shopping deals? Find them fast with Yahoo! Search.
> _______________________________________________
>  Iccrg mailing list
>  [email-masked]
>  http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>

-- 
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] (Lachlan Andrew)
Date: Fri Mar 28 16:51:42 2008
Subject: [Iccrg] ICCRG experimental CC reviews
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Greetings Wes,

On 28/03/2008, Eddy, Wesley M. (GRC-RCN0)[VZ] <[email-masked]> wrote:
>  We have been looking at Compound TCP since
>  last summer, but this review incorporates several independent efforts at
>  implementation, experimentation, and simulation (i.e. not just document
>  review).

There were many stylistic issues the the CTCP draft, like not
specifying parameter values,  the SHOUD/MUST/... terminology, what is
normative vs informative..

It would be good to write up a "how-to" for drafts, specifying what
format the drafts should have, and what pitfalls to avoid.  That
should speed the process up for future proposals.

>  The short review may have to hedge its conclusions with
>  a list of unknowns, but it would specifically identify these, whereas
>  the long review may have less unknowns.  As an example, in the Compound
>  TCP review, we have an open question about how it is affected in
>  wireless environments.

Once we get the "TCP evaluation test suite" more polished, that may
help in terms of specifying minimal testing.  (e.g., it specifies a
wireless scenario to be tested.)

>  As a TCPM participant myself, I personally prefer the "short" review to
>  keep proposals to TCPM from spending more time in ICCRG than they do in
>  TCPM :).

I don't think it should be short at the expense of making decisions on
drafts which are ambiguous in major details (like ranges of parameter
values, or which options are part of the "actual" proposal).

Guidelines would help.  Perhaps we should specify that the draft
should point to independent tests (on a non-buggy implementation).  I
don't think we should mandate independent re-implementation, but it
would be good to encourage having at least one open-source
implementation.

Cheers,
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] (Lachlan Andrew)
Date: Fri Mar 28 16:32:16 2008
Subject: [Iccrg] updated RG CTCP review
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Doug,

On 28/03/2008, Douglas Leith <[email-masked]> wrote:
> I'd suggest we wait for the revised draft to be circulated
>  before setting a short two week fuse on the review.
>  How do other people feel ?

I'd second that.

>  Re safety, personally I'd definitely like to see some tests carried
>  out over wireless before proceeding since its such a common last
>  hop.   The concern is that random access wireless (such as 802.11)
>  might have only a weak connection between delay and congestion, and
>  so have implications for the behaviour of delay algorithms.

Experiments would be good, but I'm not worried because
thought-experiments show it is safe.  Random fluctuations in delay
will reduce the delay-based component.  It might kill fairness, but
should not make it worse than a Reno flow, and we know that Reno isn't
clobbered too badly.

>  I also don't think I completely buy the low loss regime argument for
>  safety as it seems to be stated in the iccrg minutes.  That provides
>  safety in the sense of reverting to reno on lower speed links, but
>  surely we do need to think at least a little about safety on higher
>  speed links ?  If such links are rare so that we don't care about
>  safety, then we have no problem.  However, if they are not rare then
>  behaviour on those links should be considered, shouldn't it ?   Since
>  higher speed links here corresponds to a pipe size of 38 packets, I
>  suspect that pipes larger than this are common enough.

Yes, we need to think about it.  FWIW, my thoughts are that it is safe :)

It isn't the pipe size that decides if  dwnd  is used; it is the
Reno-cwnd.  If the Reno cwnd is larger than 38 packets, then the loss
rate is less than about (1/38^2).  If "safety" means "avoiding
congestion collapse", the question is whether congestion collapse can
happen with a low loss rate like that.

If we were pre-Tahoe and using Go-Back-N, then we could get congestion
collapse with an arbitrarily small loss rate if the window was large
enough.  However modern TCP uses Selective Retransmit (except after
timeouts, where the window is reduced to 1 MSS) which means that when
dwnd  is active we should get through at least about  (1 - 1/(38^2) )
of what we transmit.

(In case you're wondering:  No, I'm not on Murari's payroll...)

Perhaps we should have a more precise definition of what is meant by
"safe" and "congestion collapse".  If I recall correctly, the original
definition of congestion collapse was "adding an extra flow reduces
total network throughput".  That is clearly inadequate, because a
simple two-hop parking-lot is usually in congestion collapse according
to that definition: Adding an extra two-hop flow reduces the total
network throughput.

Cheers,
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] (Eddy, Wesley M. (GRC-RCN0)[VZ])
Date: Fri Mar 28 13:23:12 2008
Subject: [Iccrg] ICCRG experimental CC reviews
Message-ID: <[email-masked]>

The ICCRG has been attempting to prepare a "safety review" of Compound
TCP as input to TCPM in deciding how to handle the Compound TCP I-D.
When we finish this, the ICCRG is also going to do the same for CUBIC
and the CUBIC I-D, and other experimental congestion control proposals
that come to TCPM.

In Philadelphia, we discovered that we didn't know what level of review
TCPM desired from the ICCRG.  We have been looking at Compound TCP since
last summer, but this review incorporates several independent efforts at
implementation, experimentation, and simulation (i.e. not just document
review).  The delay involved in this may be greater than what people
bringing congestion control proposals to the IETF would like.  It can be
difficult enough to get them to bring the proposals here in the first
place; as history shows, they can put code into their operating systems
and widely deploy without the help of the IETF.

My question for TCPM is: Would TCPM participants rather have a "short"
review from the ICCRG, on the order of 4 months, that considers the I-D
in question and any immediately-available supporting materials, OR
would TCPM rather have a "long" review from the ICCRG, perhaps a year,
that has a very thorough investigation behind it.  Or something else
completely.  The short review may have to hedge its conclusions with
a list of unknowns, but it would specifically identify these, whereas
the long review may have less unknowns.  As an example, in the Compound
TCP review, we have an open question about how it is affected in
wireless
environments.

As a TCPM participant myself, I personally prefer the "short" review to
keep proposals to TCPM from spending more time in ICCRG than they do in
TCPM :).

From: [email-masked] (Douglas Leith)
Date: Fri Mar 28 09:25:57 2008
Subject: [Iccrg] updated RG CTCP review
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I haven't read the revised review just yet but as I recall there were  
a number of issues raised by people re the current ctcp internet  
draft (ambiguities in the spec, also some fundamental details such as  
how RTT is measured and filtered etc).  I'd suggest we wait for the  
revised draft to be circulated (maybe it has and I missed it ?)  
before setting a short two week fuse on the review so that at least  
we're reviewing the most up to date document.   How do other people  
feel ?

Re safety, personally I'd definitely like to see some tests carried  
out over wireless before proceeding since its such a common last  
hop.   The concern is that random access wireless (such as 802.11)  
might have only a weak connection between delay and congestion, and  
so have implications for the behaviour of delay algorithms.

I also don't think I completely buy the low loss regime argument for  
safety as it seems to be stated in the iccrg minutes.  That provides  
safety in the sense of reverting to reno on lower speed links, but  
surely we do need to think at least a little about safety on higher  
speed links ?  If such links are rare so that we don't care about  
safety, then we have no problem.  However, if they are not rare then  
behaviour on those links should be considered, shouldn't it ?   Since  
higher speed links here corresponds to a pipe size of 38 packets, I  
suspect that pipes larger than this are common enough.

Doug

On 27 Mar 2008, at 13:56, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:

> Based on the responses to the first draft, and the discussion
> we had in Philadelphia, I've prepared an update to the RG's
> Compound TCP review (attached).  Please look this over in
> the next two weeks, and we will forward it to TCPM if no major
> changes are noted by then.
>
> I've added links to some of the implementation and
> experimental results, and to mailing list discussions.
> If there are other links that should be added to provide
> even more backup, please note it to us.
>
> Thanks for your help (and patience!) in completing this first
> review for TCPM.<ctcp- 
> review.txt>_______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Murari Sridharan)
Date: Wed Mar 26 21:46:36 2008
Subject: [Iccrg] SSDT Scope
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I see the confusion in my original mail. I misspoke. I meant to give the two problems that I am aware of of and state some IETF effort in solving each. Quickstart as an example of something that would address problem 1 and some requests that I have seen where customers want to start with a high value of cwnd, and limited slow start as  something that would address #2. For connections that never leave slow start, limited slow start is going to slow things further.

Now as part of SSDT motivation, we should agree on what problems we are solving and given there is some prior effort we should also say why these solutions are not sufficient or alternatively may have deployment blockers.

Thanks
Murari

From: Dirceu Cavendish [mailto:[email-masked]]
Sent: Wednesday, March 26, 2008 1:53 PM
To: Murari Sridharan; [email-masked]
Subject: Re: [Iccrg] SSDT Scope

I am aware how quickStart helps with Web Service transactions. My question was about how limited slow start helps with that, which was I understood from your previous message...

Dirceu

----- Original Message ----
From: Murari Sridharan <[email-masked]>
To: Dirceu Cavendish <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Wednesday, March 26, 2008 1:31:18 PM
Subject: RE: [Iccrg] SSDT Scope
If i am a web app and i have say some small data to transfer, today in slow start it would take multiple round trips to transfer this data, now say i negotiated a rate with quick start or started with higher cwnd i could complete the transaction faster and be done. I have seen customers complain about this esp when they are on high latency low bandwidth links.
________________________________
From: Dirceu Cavendish [[email-masked]]
Sent: Wednesday, March 26, 2008 1:15 PM
To: Murari Sridharan; [email-masked]
Subject: Re: [Iccrg] SSDT Scope
Inline comments:

----- Original Message ----
From: Murari Sridharan <[email-masked]>
To: Dirceu Cavendish <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Wednesday, March 26, 2008 12:21:18 PM
Subject: RE: [Iccrg] SSDT Scope
I have heard two sets of complaints about slow start; one its too slow, in the sense for connections that usually never get out of slow start and are latency sensitive need something faster. Proposals; second is nto really a customer complaint per-se but not good behavior in general, which is that slow start doubles rate before it hits a loss and this overshooting of buffer should be avoided if we can detect it.

Now the first problem is already addressed to some extent by proposals like Limited Slowstart, QuickStart etc . is SSDT?s goal to improve those solutions?

<dc> I confess I am a bit confused with your last statement about limited slow start and quickstart as solutions to connections that usually never get out of slow start. How does limited slow start help there? I would understand limited slow start helping the second issue as described above...

I also would rather keep the discussion about what are the current SS issues worthy to work on, rather than to jump into a discussion on possible solutions of issues that potentially are not found worth pursuing them. Also, it may be that we agree that a tangible and hence worth pursuing contribution would be to come-up with a document describing the relevant limitations of SS, as the ICCRG sees it.

Dirceu
</dc>

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dirceu Cavendish
Sent: Wednesday, March 26, 2008 10:24 AM
To: [email-masked]
Subject: [Iccrg] SSDT Scope

On Michael's advise, I am re-sending this message to the ICCRG mailing list.

Hello people interested in Slow Start.
The first discussion is about the scope of the SSDT group. A good starting point is to list what people have experienced as incovenient behavior of slow start. Once we agree on what to address, we can scope the objectives/goals of the SSDT group.

Our "pain points" are:

- multiple segment losses in high bandwidth delay product networks, when SS opens the cwnd to a large value right before transitioning from SS to CA. This typically causes multiple RTOs...
- Unfairness with different session RTTs.

Feel free to add yours.
Dirceu

----- Original Message ----
From: Lachlan Andrew <[email-masked]>
To: Michael Welzl <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, March 25, 2008 8:04:48 AM
Subject: Re: [Iccrg] "Slow Start" design team

Greetings Michael and Lars,

An advantage of separate mailing lists is that it allows people set up
filters for the mail clients.  That could also be done by asking
people to put a keyword in their email subjects (like slowstartDT).

FWIW, I'm unlikely to subscribe to the DT mailing lists, but wouldn't
mind extra traffic on  iccrg@...

Cheers,
Lachlan

On 25/03/2008, Michael Welzl <[email-masked]<mailto:[email-masked]>> wrote:
> On Tue, 2008-03-25 at 16:05 +0200, Lars Eggert wrote:
>  > On 2008-3-25, at 15:54, ext Michael Welzl wrote:
>  > > The first concrete proposal on the table is (somewhat
>  > > unsurprisingly  :)  ) a design team on Slow Start,
>  > > led by Dirceu himself (which I, not he, suggested).
>  > > I think it's a nice start and definitely worth trying.
>  >
>  > Sounds good.
>  >
>  > > To join the list, send an email to:
>  > > [email-masked]<mailto:[email-masked]>
>  > > with "subscribe YOUR NAME" as the body of the message.
>  >
>  > But why does the DT need its own list? It's not like the ICCRG list is
>  > flooded with traffic, and having the discussions in the open seems
>  > useful.
>
>
> ah, that was just an idea ... after all there should be
>  multiple design teams with multiple lists one day
>
>  we could have it all in the open if people want that,
>  but it just seems to make things a little more organized
>  to me ... dunno, doesn't really matter i suppose
>
>  cheers
>
> michael
>
>
>
>
>  _______________________________________________
>  Iccrg mailing list
>  [email-masked]<mailto:[email-masked]>
>  http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

--
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

_______________________________________________
Iccrg mailing list
[email-masked]<mailto:[email-masked]>
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

________________________________
Never miss a thing. Make Yahoo your homepage.<http://us.rd.yahoo.com/evt=51438/*http:/www.yahoo.com/r/hs>

________________________________
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.<http://us.rd.yahoo.com/evt=51733/*http:/mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ>

________________________________
Looking for last minute shopping deals? Find them fast with Yahoo! Search.<http://us.rd.yahoo.com/evt=51734/*http:/tools.search.yahoo.com/newsearch/category.php?category=shopping>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080326/02593d59/attachment-0001.html
>From [email-masked]  Wed Mar 26 22:13:45 2008
From: [email-masked] (Dirceu Cavendish)
Date: Wed Mar 26 22:05:48 2008
Subject: [Iccrg] SSDT Scope
Message-ID: <[email-masked]>

Murari,

I agree that, together with IDing the issues SSDT will be tackling, we should characterize how the current (IETF) solutions address them, and why there is more work to do.

Dirceu

----- Original Message ----
From: Murari Sridharan <[email-masked]>
To: Dirceu Cavendish <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Wednesday, March 26, 2008 2:54:45 PM
Subject: RE: [Iccrg] SSDT Scope

I see the confusion in my original mail. I misspoke. I meant to give the two problems that I am aware of of and state some IETF effort in solving each. Quickstart as an example of something that would address problem 1 and some requests that I have seen where customers want to start with a high value of cwnd, and limited slow start as  something that would address #2. For connections that never leave slow start, limited slow start is going to slow things further. 
 
Now as part of SSDT motivation, we should agree on what problems we are solving and given there is some prior effort we should also say why these solutions are not sufficient or alternatively may have deployment blockers. 
 
Thanks
Murari
 
From: Dirceu Cavendish [mailto:[email-masked]] 
Sent: Wednesday, March 26, 2008 1:53 PM
To: Murari Sridharan; [email-masked]
Subject: Re: [Iccrg] SSDT Scope
 
I am aware how quickStart helps with Web Service transactions. My question was about how limited slow start helps with that, which was I understood from your previous message...
 
Dirceu
 
----- Original Message ----
From: Murari Sridharan <[email-masked]>
To: Dirceu Cavendish <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Wednesday, March 26, 2008 1:31:18 PM
Subject: RE: [Iccrg] SSDT Scope
If i am a web app and i have say some small data to transfer, today in slow start it would take multiple round trips to transfer this data, now say i negotiated a rate with quick start or started with higher cwnd i could complete the transaction faster and be done. I have seen customers complain about this esp when they are on high latency low bandwidth links. 

From: Dirceu Cavendish [[email-masked]]
Sent: Wednesday, March 26, 2008 1:15 PM
To: Murari Sridharan; [email-masked]
Subject: Re: [Iccrg] SSDT Scope
Inline comments: 
 
----- Original Message ----
From: Murari Sridharan <[email-masked]>
To: Dirceu Cavendish <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Wednesday, March 26, 2008 12:21:18 PM
Subject: RE: [Iccrg] SSDT Scope
I have heard two sets of complaints about slow start; one its too slow, in the sense for connections that usually never get out of slow start and are latency sensitive need something faster. Proposals; second is nto really a customer complaint per-se but not good behavior in general, which is that slow start doubles rate before it hits a loss and this overshooting of buffer should be avoided if we can detect it. 
 
Now the first problem is already addressed to some extent by proposals like Limited Slowstart, QuickStart etc . is SSDT?s goal to improve those solutions?
 
<dc> I confess I am a bit confused with your last statement about limited slow start and quickstart as solutions to connections that usually never get out of slow start. How does limited slow start help there? I would understand limited slow start helping the second issue as described above...
 
I also would rather keep the discussion about what are the current SS issues worthy to work on, rather than to jump into a discussion on possible solutions of issues that potentially are not found worth pursuing them. Also, it may be that we agree that a tangible and hence worth pursuing contribution would be to come-up with a document describing the relevant limitations of SS, as the ICCRG sees it.
 
Dirceu
</dc>

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dirceu Cavendish
Sent: Wednesday, March 26, 2008 10:24 AM
To: [email-masked]
Subject: [Iccrg] SSDT Scope
 
On Michael's advise, I am re-sending this message to the ICCRG mailing list.
 
Hello people interested in Slow Start.
The first discussion is about the scope of the SSDT group. A good starting point is to list what people have experienced as incovenient behavior of slow start. Once we agree on what to address, we can scope the objectives/goals of the SSDT group.
 
Our "pain points" are:
 
- multiple segment losses in high bandwidth delay product networks, when SS opens the cwnd to a large value right before transitioning from SS to CA. This typically causes multiple RTOs...
- Unfairness with different session RTTs.
 
Feel free to add yours.
Dirceu
 
----- Original Message ----
From: Lachlan Andrew <[email-masked]>
To: Michael Welzl <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, March 25, 2008 8:04:48 AM
Subject: Re: [Iccrg] "Slow Start" design team

Greetings Michael and Lars,

An advantage of separate mailing lists is that it allows people set up
filters for the mail clients.  That could also be done by asking
people to put a keyword in their email subjects (like slowstartDT).

FWIW, I'm unlikely to subscribe to the DT mailing lists, but wouldn't
mind extra traffic on  iccrg@...

Cheers,
Lachlan

On 25/03/2008, Michael Welzl <[email-masked]> wrote:
> On Tue, 2008-03-25 at 16:05 +0200, Lars Eggert wrote:
>  > On 2008-3-25, at 15:54, ext Michael Welzl wrote:
>  > > The first concrete proposal on the table is (somewhat
>  > > unsurprisingly  :)  ) a design team on Slow Start,
>  > > led by Dirceu himself (which I, not he, suggested).
>  > > I think it's a nice start and definitely worth trying.
>  >
>  > Sounds good.
>  >
>  > > To join the list, send an email to:
>  > > [email-masked]
>  > > with "subscribe YOUR NAME" as the body of the message.
>  >
>  > But why does the DT need its own list? It's not like the ICCRG list is
>  > flooded with traffic, and having the discussions in the open seems
>  > useful.
>
>
> ah, that was just an idea ... after all there should be
>  multiple design teams with multiple lists one day
>
>  we could have it all in the open if people want that,
>  but it just seems to make things a little more organized
>  to me ... dunno, doesn't really matter i suppose
>
>  cheers
>
> michael
>
>
>
>
>  _______________________________________________
>  Iccrg mailing list
>  [email-masked]
>  http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

-- 
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

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

Never miss a thing. Make Yahoo your homepage.

Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

Looking for last minute shopping deals? Find them fast with Yahoo! Search.

      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080326/489bb2a2/attachment.html
>From [email-masked]  Thu Mar 27 13:56:45 2008
From: [email-masked] (Eddy, Wesley M. (GRC-RCN0)[VZ])
Date: Thu Mar 27 13:59:40 2008
Subject: [Iccrg] updated RG CTCP review
Message-ID: <[email-masked]>

Based on the responses to the first draft, and the discussion
we had in Philadelphia, I've prepared an update to the RG's
Compound TCP review (attached).  Please look this over in
the next two weeks, and we will forward it to TCPM if no major
changes are noted by then.

I've added links to some of the implementation and
experimental results, and to mailing list discussions.
If there are other links that should be added to provide
even more backup, please note it to us.

Thanks for your help (and patience!) in completing this first
review for TCPM.
-------------- next part --------------
In July 2007, the ICCRG began reviewing the Compound TCP congestion control
technique described in draft-sridharan-tcpm-ctcp-00 in terms of its safety for
widespread experimental deployment on the public Internet.  This review was
conducted as an input to the IETF TCPM working group, where the draft was being
considered for possible Experimental publication.  The scope of this review
does not include making or endorsing any claims about expected performance
gains from using Compound TCP.

Based on initial RG comments, an update to the original internet-draft was
published.  Based on further RG comments, another update is expected that
contains several clarifications (itemized later within this document).  This
review assumes that those changes are made.

After reviewing the draft and a number of other documents with results from
testing and simulation, three public evaluations were submitted to the ICCRG by
RG participants.  Several follow-on messages and comments were submitted by
these and other RG participants.  Multiple independent implementations have
been done of Compound TCP at this point in time.  Compound TCP has been
experimented with in both simulators, testbeds, and campus/enterprise networks.
On the matter of safety for experimental use, the implementers and experimenters
seem to agree that the algorithm is safe, though in individual implementations,
bugs have been found, unrelated to the algorithm itself. It is possible that
clarifications to the specification will help to avoid this.  The RG seems to
have consensus that (given the expected draft clarifications) the Compound TCP
mechanism is safe for experimental deployment on the public Internet.

References to RG participants' reviews and papers, presentations, and mailing
list messages that contributed to the consensus-forming are provided at the
end of this document.

Its novelty from the current Standards Track congestion control techniques is
that Compound TCP also contains a delay-based component.  Compound TCP's
design only utilizes the delay-based component when loss is low and the
congestion window has already grown large, and in other conditions reversts
to the current Standards Track mechanisms.  This was noted by some reviewers
as one inspiration of confidence.  The simulation results and analysis made
available were also helpful, but were not found to be overwhelmingly convincing
on their own. The implementation experiences, testbed work, and campus
deployments weighed most heavily in the RG's mind as evidence of Compound TCP's
safety.

There was an open discussion item on the use of estimation algorithms for the
queueing delay.  There was also a question lingering about how the algorithm
behaves in wireless environments where latency variations may not be completely
due to congestion, and a security-related question as to the possibility to
disrupt the delay-based component by altering the material used to take delay
samples.  These questions seem to apply to any congestion control algorithm
that utilizes delay as a source of congestion information.

Expected changes from the 01 draft version:

1. Clarify how RTT samples are captured (1323 or some other filter).

2. Clarify definition of baseRTT. (noted by 2 reviewers)

3. Clarify definition of "round" in dwnd update (is it in terms of RTT or cwnd
   worth of packets).

4. What happens to dwnd during slow-start, and when is slow-start
   exited?

5. Clarify dwnd update parameters and specific values or ranges that are safe
   for use (alpha, beta, eta, k) (noted by 3 reviewers)

6. Be precise about clipping dwnd so that it cannot become negative

Public reviews from:
Wesley Eddy (Nov 1, 2007)
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-November/000358.html
Mark Allman (Nov 29, 2007)
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-November/000378.html
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-November/000379.html
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-November/000380.html
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-November/000381.html
Doug Leith (Jan 16, 2008)
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-January/000402.html

Additionally, several thread comments from:
Lachlan Andrew
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-February/000416.html
Michael Welzl
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-February/000411.html
Dino-Martin Lopez-Pacheco
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-February/000415.html

Slides showing design and behavior:
  http://research.microsoft.com/users/dthaler/IETF%20-%20Compound%20TCP.pdf
INFOCOM 2006 paper:
  http://research.microsoft.com/users/dthaler/ctcp-infocom06.pdf
Evaluation by Doug Leith, Lachlan Andrew, Tom Quetchenbach, Bob Shorten,
 and Kfir Lavi, based on independent implementation:
  http://www.hep.man.ac.uk/PFLDnet2008/paper/Leith_DJ_Experimental%20Final.pdf
  http://www.welzl.at/iccrg-mar08-slides/iccrg_compound_mar08.ppt.pdf
Evaluation by SLAC (Yee-Ting Li):
  http://www.slac.stanford.edu/pubs/slactns/tn04/slac-tn-06-005.pdf
Behavior on under-buffered links:
  http://www.hep.man.ac.uk/PFLDnet2008/paper/Kun_T%20Final.pdf
  http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-March/000441.html
>From [email-masked]  Thu Mar 27 17:43:29 2008
From: [email-masked] (Dirceu Cavendish)
Date: Thu Mar 27 17:35:37 2008
Subject: [Iccrg] SSDT Scope
Message-ID: <[email-masked]>

Michael,

I personally prefer some "self-pacing" (ack driven) solution, rather than relying on kernet timers. But I guess solutions can be discussed in the SSDT group, once we agree on the topics to work on.

In case we work on "speeding up" SS topic, your help on evaluating Quick Start versus some other solution will be very helpful. I am glad you have already volunteered to take part on SSDT ;-)...

Rgds,
Dirceu

----- Original Message ----
From: Michael Scharf <[email-masked]>
To: Murari Sridharan <[email-masked]>
Cc: Dirceu Cavendish <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Thursday, March 27, 2008 3:04:32 AM
Subject: Re: [Iccrg] SSDT Scope

Concerning problem #1: I wonder whether it could be time to think of
alternatives to RFC 3390 (in mid-term future).

For instance, would it cause sever problems in today's Internet if the
initial window was further increased by one or two segments?

Or, could some simple form of rate-pacing help those guys that
complain about the speed of Slow-Start when the RTT/BDP is large? For
instance, after the 3-way handshake, one could allow a sender to
increase the cwnd beyond the initial value after 100ms or 200ms if no
new ACK has been received until then. This would help short flows over
a path with a rather large RTT. Maybe such an approach could be
combined with a solution that reduces the aggressiveness of Slow-Start
when cwnd is larger.

(Of course, Quick-Start would be my favorite solution.)

Michael

On Wed, 26 Mar 2008 at 14:54:45, Murari Sridharan wrote:
> I see the confusion in my original mail. I misspoke. I meant to give the two problems that I am aware of of and state some IETF effort in solving each. Quickstart as an example of something that would address problem 1 and some requests that I have seen where customers want to start with a high value of cwnd, and limited slow start as  something that would address #2. For connections that never leave slow start, limited slow start is going to slow things further.
> 
> Now as part of SSDT motivation, we should agree on what problems we are solving and given there is some prior effort we should also say why these solutions are not sufficient or alternatively may have deployment blockers.
> 
> Thanks
> Murari
> 
> From: Dirceu Cavendish [mailto:[email-masked]]
> Sent: Wednesday, March 26, 2008 1:53 PM
> To: Murari Sridharan; [email-masked]
> Subject: Re: [Iccrg] SSDT Scope
> 
> 
> I am aware how quickStart helps with Web Service transactions. My question was about how limited slow start helps with that, which was I understood from your previous message...
> 
> 
> 
> Dirceu
> 
> ----- Original Message ----
> From: Murari Sridharan <[email-masked]>
> To: Dirceu Cavendish <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Wednesday, March 26, 2008 1:31:18 PM
> Subject: RE: [Iccrg] SSDT Scope
> If i am a web app and i have say some small data to transfer, today in slow start it would take multiple round trips to transfer this data, now say i negotiated a rate with quick start or started with higher cwnd i could complete the transaction faster and be done. I have seen customers complain about this esp when they are on high latency low bandwidth links.
> ________________________________
> From: Dirceu Cavendish [[email-masked]]
> Sent: Wednesday, March 26, 2008 1:15 PM
> To: Murari Sridharan; [email-masked]
> Subject: Re: [Iccrg] SSDT Scope
> Inline comments:
> 
> ----- Original Message ----
> From: Murari Sridharan <[email-masked]>
> To: Dirceu Cavendish <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Wednesday, March 26, 2008 12:21:18 PM
> Subject: RE: [Iccrg] SSDT Scope
> I have heard two sets of complaints about slow start; one its too slow, in the sense for connections that usually never get out of slow start and are latency sensitive need something faster. Proposals; second is nto really a customer complaint per-se but not good behavior in general, which is that slow start doubles rate before it hits a loss and this overshooting of buffer should be avoided if we can detect it.
> 
> Now the first problem is already addressed to some extent by proposals like Limited Slowstart, QuickStart etc . is SSDT?s goal to improve those solutions?
> 
> <dc> I confess I am a bit confused with your last statement about limited slow start and quickstart as solutions to connections that usually never get out of slow start. How does limited slow start help there? I would understand limited slow start helping the second issue as described above...
> 
> I also would rather keep the discussion about what are the current SS issues worthy to work on, rather than to jump into a discussion on possible solutions of issues that potentially are not found worth pursuing them. Also, it may be that we agree that a tangible and hence worth pursuing contribution would be to come-up with a document describing the relevant limitations of SS, as the ICCRG sees it.
> 
> Dirceu
> </dc>
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dirceu Cavendish
> Sent: Wednesday, March 26, 2008 10:24 AM
> To: [email-masked]
> Subject: [Iccrg] SSDT Scope
> 
> On Michael's advise, I am re-sending this message to the ICCRG mailing list.
> 
> Hello people interested in Slow Start.
> The first discussion is about the scope of the SSDT group. A good starting point is to list what people have experienced as incovenient behavior of slow start. Once we agree on what to address, we can scope the objectives/goals of the SSDT group.
> 
> Our "pain points" are:
> 
> - multiple segment losses in high bandwidth delay product networks, when SS opens the cwnd to a large value right before transitioning from SS to CA. This typically causes multiple RTOs...
> - Unfairness with different session RTTs.
> 
> Feel free to add yours.
> Dirceu
> 
> ----- Original Message ----
> From: Lachlan Andrew <[email-masked]>
> To: Michael Welzl <[email-masked]>
> Cc: [email-masked]
> Sent: Tuesday, March 25, 2008 8:04:48 AM
> Subject: Re: [Iccrg] "Slow Start" design team
> 
> Greetings Michael and Lars,
> 
> An advantage of separate mailing lists is that it allows people set up
> filters for the mail clients.  That could also be done by asking
> people to put a keyword in their email subjects (like slowstartDT).
> 
> FWIW, I'm unlikely to subscribe to the DT mailing lists, but wouldn't
> mind extra traffic on  iccrg@...
> 
> Cheers,
> Lachlan
> 
> On 25/03/2008, Michael Welzl <[email-masked]<mailto:[email-masked]>> wrote:
> > On Tue, 2008-03-25 at 16:05 +0200, Lars Eggert wrote:
> >  > On 2008-3-25, at 15:54, ext Michael Welzl wrote:
> >  > > The first concrete proposal on the table is (somewhat
> >  > > unsurprisingly  :)  ) a design team on Slow Start,
> >  > > led by Dirceu himself (which I, not he, suggested).
> >  > > I think it's a nice start and definitely worth trying.
> >  >
> >  > Sounds good.
> >  >
> >  > > To join the list, send an email to:
> >  > > [email-masked]<mailto:[email-masked]>
> >  > > with "subscribe YOUR NAME" as the body of the message.
> >  >
> >  > But why does the DT need its own list? It's not like the ICCRG list is
> >  > flooded with traffic, and having the discussions in the open seems
> >  > useful.
> >
> >
> > ah, that was just an idea ... after all there should be
> >  multiple design teams with multiple lists one day
> >
> >  we could have it all in the open if people want that,
> >  but it just seems to make things a little more organized
> >  to me ... dunno, doesn't really matter i suppose
> >
> >  cheers
> >
> > michael
> >
> >
> >
> >
> >  _______________________________________________
> >  Iccrg mailing list
> >  [email-masked]<mailto:[email-masked]>
> >  http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> >
> 
> 
> --
> 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
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]<mailto:[email-masked]>
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 
> 
> ________________________________
> Never miss a thing. Make Yahoo your homepage.<http://us.rd.yahoo.com/evt=51438/*http:/www.yahoo.com/r/hs>
> 
> 
> ________________________________
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.<http://us.rd.yahoo.com/evt=51733/*http:/mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ>
> 
> 
> ________________________________
> Looking for last minute shopping deals? Find them fast with Yahoo! Search.<http://us.rd.yahoo.com/evt=51734/*http:/tools.search.yahoo.com/newsearch/category.php?category=shopping>

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

-- 
Dipl.-Ing. Michael Scharf
Institute of Communication Networks and Computer Engineering  (IKR)
Universit?t Stuttgart, Pfaffenwaldring 47, 70569 Stuttgart, Germany
Phone: +49 711 685-69006 Email: [email-masked]
Fax:  +49 711 685-67983 Web:  www.ikr.uni-stuttgart.de/en/~scharf

      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080327/1034a8bb/attachment-0001.html
>From [email-masked]  Thu Mar 27 10:04:32 2008
From: [email-masked] (Michael Scharf)
Date: Fri Mar 28 07:00:44 2008
Subject: [Iccrg] SSDT Scope
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Concerning problem #1: I wonder whether it could be time to think of
alternatives to RFC 3390 (in mid-term future).

For instance, would it cause sever problems in today's Internet if the
initial window was further increased by one or two segments?

Or, could some simple form of rate-pacing help those guys that
complain about the speed of Slow-Start when the RTT/BDP is large? For
instance, after the 3-way handshake, one could allow a sender to
increase the cwnd beyond the initial value after 100ms or 200ms if no
new ACK has been received until then. This would help short flows over
a path with a rather large RTT. Maybe such an approach could be
combined with a solution that reduces the aggressiveness of Slow-Start
when cwnd is larger.

(Of course, Quick-Start would be my favorite solution.)

Michael

On Wed, 26 Mar 2008 at 14:54:45, Murari Sridharan wrote:
> I see the confusion in my original mail. I misspoke. I meant to give the two problems that I am aware of of and state some IETF effort in solving each. Quickstart as an example of something that would address problem 1 and some requests that I have seen where customers want to start with a high value of cwnd, and limited slow start as  something that would address #2. For connections that never leave slow start, limited slow start is going to slow things further.
> 
> Now as part of SSDT motivation, we should agree on what problems we are solving and given there is some prior effort we should also say why these solutions are not sufficient or alternatively may have deployment blockers.
> 
> Thanks
> Murari
> 
> From: Dirceu Cavendish [mailto:[email-masked]]
> Sent: Wednesday, March 26, 2008 1:53 PM
> To: Murari Sridharan; [email-masked]
> Subject: Re: [Iccrg] SSDT Scope
> 
> 
> I am aware how quickStart helps with Web Service transactions. My question was about how limited slow start helps with that, which was I understood from your previous message...
> 
> 
> 
> Dirceu
> 
> ----- Original Message ----
> From: Murari Sridharan <[email-masked]>
> To: Dirceu Cavendish <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Wednesday, March 26, 2008 1:31:18 PM
> Subject: RE: [Iccrg] SSDT Scope
> If i am a web app and i have say some small data to transfer, today in slow start it would take multiple round trips to transfer this data, now say i negotiated a rate with quick start or started with higher cwnd i could complete the transaction faster and be done. I have seen customers complain about this esp when they are on high latency low bandwidth links.
> ________________________________
> From: Dirceu Cavendish [[email-masked]]
> Sent: Wednesday, March 26, 2008 1:15 PM
> To: Murari Sridharan; [email-masked]
> Subject: Re: [Iccrg] SSDT Scope
> Inline comments:
> 
> ----- Original Message ----
> From: Murari Sridharan <[email-masked]>
> To: Dirceu Cavendish <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Wednesday, March 26, 2008 12:21:18 PM
> Subject: RE: [Iccrg] SSDT Scope
> I have heard two sets of complaints about slow start; one its too slow, in the sense for connections that usually never get out of slow start and are latency sensitive need something faster. Proposals; second is nto really a customer complaint per-se but not good behavior in general, which is that slow start doubles rate before it hits a loss and this overshooting of buffer should be avoided if we can detect it.
> 
> Now the first problem is already addressed to some extent by proposals like Limited Slowstart, QuickStart etc . is SSDT?s goal to improve those solutions?
> 
> <dc> I confess I am a bit confused with your last statement about limited slow start and quickstart as solutions to connections that usually never get out of slow start. How does limited slow start help there? I would understand limited slow start helping the second issue as described above...
> 
> I also would rather keep the discussion about what are the current SS issues worthy to work on, rather than to jump into a discussion on possible solutions of issues that potentially are not found worth pursuing them. Also, it may be that we agree that a tangible and hence worth pursuing contribution would be to come-up with a document describing the relevant limitations of SS, as the ICCRG sees it.
> 
> Dirceu
> </dc>
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dirceu Cavendish
> Sent: Wednesday, March 26, 2008 10:24 AM
> To: [email-masked]
> Subject: [Iccrg] SSDT Scope
> 
> On Michael's advise, I am re-sending this message to the ICCRG mailing list.
> 
> Hello people interested in Slow Start.
> The first discussion is about the scope of the SSDT group. A good starting point is to list what people have experienced as incovenient behavior of slow start. Once we agree on what to address, we can scope the objectives/goals of the SSDT group.
> 
> Our "pain points" are:
> 
> - multiple segment losses in high bandwidth delay product networks, when SS opens the cwnd to a large value right before transitioning from SS to CA. This typically causes multiple RTOs...
> - Unfairness with different session RTTs.
> 
> Feel free to add yours.
> Dirceu
> 
> ----- Original Message ----
> From: Lachlan Andrew <[email-masked]>
> To: Michael Welzl <[email-masked]>
> Cc: [email-masked]
> Sent: Tuesday, March 25, 2008 8:04:48 AM
> Subject: Re: [Iccrg] "Slow Start" design team
> 
> Greetings Michael and Lars,
> 
> An advantage of separate mailing lists is that it allows people set up
> filters for the mail clients.  That could also be done by asking
> people to put a keyword in their email subjects (like slowstartDT).
> 
> FWIW, I'm unlikely to subscribe to the DT mailing lists, but wouldn't
> mind extra traffic on  iccrg@...
> 
> Cheers,
> Lachlan
> 
> On 25/03/2008, Michael Welzl <[email-masked]<mailto:[email-masked]>> wrote:
> > On Tue, 2008-03-25 at 16:05 +0200, Lars Eggert wrote:
> >  > On 2008-3-25, at 15:54, ext Michael Welzl wrote:
> >  > > The first concrete proposal on the table is (somewhat
> >  > > unsurprisingly  :)  ) a design team on Slow Start,
> >  > > led by Dirceu himself (which I, not he, suggested).
> >  > > I think it's a nice start and definitely worth trying.
> >  >
> >  > Sounds good.
> >  >
> >  > > To join the list, send an email to:
> >  > > [email-masked]<mailto:[email-masked]>
> >  > > with "subscribe YOUR NAME" as the body of the message.
> >  >
> >  > But why does the DT need its own list? It's not like the ICCRG list is
> >  > flooded with traffic, and having the discussions in the open seems
> >  > useful.
> >
> >
> > ah, that was just an idea ... after all there should be
> >  multiple design teams with multiple lists one day
> >
> >  we could have it all in the open if people want that,
> >  but it just seems to make things a little more organized
> >  to me ... dunno, doesn't really matter i suppose
> >
> >  cheers
> >
> > michael
> >
> >
> >
> >
> >  _______________________________________________
> >  Iccrg mailing list
> >  [email-masked]<mailto:[email-masked]>
> >  http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> >
> 
> 
> --
> 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
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]<mailto:[email-masked]>
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 
> 
> ________________________________
> Never miss a thing. Make Yahoo your homepage.<http://us.rd.yahoo.com/evt=51438/*http:/www.yahoo.com/r/hs>
> 
> 
> ________________________________
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.<http://us.rd.yahoo.com/evt=51733/*http:/mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ>
> 
> 
> ________________________________
> Looking for last minute shopping deals? Find them fast with Yahoo! Search.<http://us.rd.yahoo.com/evt=51734/*http:/tools.search.yahoo.com/newsearch/category.php?category=shopping>

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

-- 
Dipl.-Ing. Michael Scharf
Institute of Communication Networks and Computer Engineering  (IKR)
Universit?t Stuttgart, Pfaffenwaldring 47, 70569 Stuttgart, Germany
Phone: +49 711 685-69006 Email: [email-masked]
Fax:   +49 711 685-67983 Web:   www.ikr.uni-stuttgart.de/en/~scharf

From: [email-masked] (Murari Sridharan)
Date: Wed Mar 26 19:14:54 2008
Subject: [Iccrg] SSDT Scope
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I have heard two sets of complaints about slow start; one its too slow, in the sense for connections that usually never get out of slow start and are latency sensitive need something faster. Proposals; second is nto really a customer complaint per-se but not good behavior in general, which is that slow start doubles rate before it hits a loss and this overshooting of buffer should be avoided if we can detect it.

Now the first problem is already addressed to some extent by proposals like Limited Slowstart, QuickStart etc . is SSDT's goal to improve those solutions?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dirceu Cavendish
Sent: Wednesday, March 26, 2008 10:24 AM
To: [email-masked]
Subject: [Iccrg] SSDT Scope

On Michael's advise, I am re-sending this message to the ICCRG mailing list.

Hello people interested in Slow Start.
The first discussion is about the scope of the SSDT group. A good starting point is to list what people have experienced as incovenient behavior of slow start. Once we agree on what to address, we can scope the objectives/goals of the SSDT group.

Our "pain points" are:

- multiple segment losses in high bandwidth delay product networks, when SS opens the cwnd to a large value right before transitioning from SS to CA. This typically causes multiple RTOs...
- Unfairness with different session RTTs.

Feel free to add yours.
Dirceu

----- Original Message ----
From: Lachlan Andrew <[email-masked]>
To: Michael Welzl <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, March 25, 2008 8:04:48 AM
Subject: Re: [Iccrg] "Slow Start" design team

Greetings Michael and Lars,

An advantage of separate mailing lists is that it allows people set up
filters for the mail clients.  That could also be done by asking
people to put a keyword in their email subjects (like slowstartDT).

FWIW, I'm unlikely to subscribe to the DT mailing lists, but wouldn't
mind extra traffic on  iccrg@...

Cheers,
Lachlan

On 25/03/2008, Michael Welzl <[email-masked]<mailto:[email-masked]>> wrote:
> On Tue, 2008-03-25 at 16:05 +0200, Lars Eggert wrote:
>  > On 2008-3-25, at 15:54, ext Michael Welzl wrote:
>  > > The first concrete proposal on the table is (somewhat
>  > > unsurprisingly  :)  ) a design team on Slow Start,
>  > > led by Dirceu himself (which I, not he, suggested).
>  > > I think it's a nice start and definitely worth trying.
>  >
>  > Sounds good.
>  >
>  > > To join the list, send an email to:
>  > > [email-masked]<mailto:[email-masked]>
>  > > with "subscribe YOUR NAME" as the body of the message.
>  >
>  > But why does the DT need its own list? It's not like the ICCRG list is
>  > flooded with traffic, and having the discussions in the open seems
>  > useful.
>
>
> ah, that was just an idea ... after all there should be
>  multiple design teams with multiple lists one day
>
>  we could have it all in the open if people want that,
>  but it just seems to make things a little more organized
>  to me ... dunno, doesn't really matter i suppose
>
>  cheers
>
> michael
>
>
>
>
>  _______________________________________________
>  Iccrg mailing list
>  [email-masked]<mailto:[email-masked]>
>  http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

--
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

_______________________________________________
Iccrg mailing list
[email-masked]<mailto:[email-masked]>
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

________________________________
Never miss a thing. Make Yahoo your homepage.<http://us.rd.yahoo.com/evt=51438/*http:/www.yahoo.com/r/hs>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080326/acd69307/attachment.html
>From [email-masked]  Wed Mar 26 20:15:10 2008
From: [email-masked] (Dirceu Cavendish)
Date: Wed Mar 26 20:07:23 2008
Subject: [Iccrg] SSDT Scope
Message-ID: <[email-masked]>

Inline comments:

----- Original Message ----
From: Murari Sridharan <[email-masked]>
To: Dirceu Cavendish <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Wednesday, March 26, 2008 12:21:18 PM
Subject: RE: [Iccrg] SSDT Scope

I have heard two sets of complaints about slow start; one its too slow, in the sense for connections that usually never get out of slow start and are latency sensitive need something faster. Proposals; second is nto really a customer complaint per-se but not good behavior in general, which is that slow start doubles rate before it hits a loss and this overshooting of buffer should be avoided if we can detect it. 
 
Now the first problem is already addressed to some extent by proposals like Limited Slowstart, QuickStart etc . is SSDT?s goal to improve those solutions?
 
<dc> I confess I am a bit confused with your last statement about limited slow start and quickstart as solutions to connections that usually never get out of slow start. How does limited slow start help there? I would understand limited slow start helping the second issue as described above...

I also would rather keep the discussion about what are the current SS issues worthy to work on, rather than to jump into a discussion on possible solutions of issues that potentially are not found worth pursuing them. Also, it may be that we agree that a tangible and hence worth pursuing contribution would be to come-up with a document describing the relevant limitations of SS, as the ICCRG sees it.

Dirceu
</dc>

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dirceu Cavendish
Sent: Wednesday, March 26, 2008 10:24 AM
To: [email-masked]
Subject: [Iccrg] SSDT Scope
 
On Michael's advise, I am re-sending this message to the ICCRG mailing list.
 
Hello people interested in Slow Start.
The first discussion is about the scope of the SSDT group. A good starting point is to list what people have experienced as incovenient behavior of slow start. Once we agree on what to address, we can scope the objectives/goals of the SSDT group.
 
Our "pain points" are:
 
- multiple segment losses in high bandwidth delay product networks, when SS opens the cwnd to a large value right before transitioning from SS to CA. This typically causes multiple RTOs...
- Unfairness with different session RTTs.
 
Feel free to add yours.
Dirceu
 
----- Original Message ----
From: Lachlan Andrew <[email-masked]>
To: Michael Welzl <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, March 25, 2008 8:04:48 AM
Subject: Re: [Iccrg] "Slow Start" design team

Greetings Michael and Lars,

An advantage of separate mailing lists is that it allows people set up
filters for the mail clients.  That could also be done by asking
people to put a keyword in their email subjects (like slowstartDT).

FWIW, I'm unlikely to subscribe to the DT mailing lists, but wouldn't
mind extra traffic on  iccrg@...

Cheers,
Lachlan

On 25/03/2008, Michael Welzl <[email-masked]> wrote:
> On Tue, 2008-03-25 at 16:05 +0200, Lars Eggert wrote:
>  > On 2008-3-25, at 15:54, ext Michael Welzl wrote:
>  > > The first concrete proposal on the table is (somewhat
>  > > unsurprisingly  :)  ) a design team on Slow Start,
>  > > led by Dirceu himself (which I, not he, suggested).
>  > > I think it's a nice start and definitely worth trying.
>  >
>  > Sounds good.
>  >
>  > > To join the list, send an email to:
>  > > [email-masked]
>  > > with "subscribe YOUR NAME" as the body of the message.
>  >
>  > But why does the DT need its own list? It's not like the ICCRG list is
>  > flooded with traffic, and having the discussions in the open seems
>  > useful.
>
>
> ah, that was just an idea ... after all there should be
>  multiple design teams with multiple lists one day
>
>  we could have it all in the open if people want that,
>  but it just seems to make things a little more organized
>  to me ... dunno, doesn't really matter i suppose
>
>  cheers
>
> michael
>
>
>
>
>  _______________________________________________
>  Iccrg mailing list
>  [email-masked]
>  http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

-- 
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

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

Never miss a thing. Make Yahoo your homepage.

      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080326/a2c92549/attachment-0001.html
>From [email-masked]  Wed Mar 26 20:25:04 2008
From: [email-masked] (Dirceu Cavendish)
Date: Wed Mar 26 20:16:52 2008
Subject: [Iccrg] SSDT Scope
Message-ID: <[email-masked]>

Injong,

I did not mean to say that this is a problem of SS ONLY. TCP is also biased to rtts...
In case of SS, there is a cwnd size over which the source becomes effectively limited by its interface speed, not the cwnd value, any longer. And the larger the RTT is, the higher this value becomes.
So, sessions with shorter RTTs will achieve this "interface speed" ceiling sooner than later, hence SS bias towards shorter RTT sessions...

Also, in my view, we do not have a MAIN problem as yet. All we are trying to do is to come up with a laundry list of SS limitations. We may not be able to work on all of them, and hence it is important to discuss the relevance of the issues as they come up. I have my preferences, and I certainly would rank the multiple segment losses, non-smooth transition between SS and CA higher in my list. But it also bothers me when experimenting with multiple RTT sessions, and one grabs most of the bottleneck baidwidth, starving others.

Dirceu

----- Original Message ----
From: Injong Rhee <[email-masked]>
To: [email-masked]
Sent: Wednesday, March 26, 2008 12:04:07 PM
Subject: Re: [Iccrg] SSDT Scope

>>- Unfairness with different session RTTs.

Why is this a problem with slow start? I guess that the main subject  
is that the original SS is too aggressive as it doubles cwnd by 2 (or  
some factor close to it due to delayed acks) per RTT, and under large  
BDP, there are a huge number of packets overshot at the time of  
losses. The question is how to detect when to finish the ss and  
transit to ca so that we don't have such high losses. 

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

      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080326/bbfdf72d/attachment.html
>From [email-masked]  Wed Mar 26 20:31:18 2008
From: [email-masked] (Murari Sridharan)
Date: Wed Mar 26 20:26:33 2008
Subject: [Iccrg] SSDT Scope
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

If i am a web app and i have say some small data to transfer, today in slow start it would take multiple round trips to transfer this data, now say i negotiated a rate with quick start or started with higher cwnd i could complete the transaction faster and be done. I have seen customers complain about this esp when they are on high latency low bandwidth links.
________________________________
From: Dirceu Cavendish [[email-masked]]
Sent: Wednesday, March 26, 2008 1:15 PM
To: Murari Sridharan; [email-masked]
Subject: Re: [Iccrg] SSDT Scope

Inline comments:

----- Original Message ----
From: Murari Sridharan <[email-masked]>
To: Dirceu Cavendish <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Wednesday, March 26, 2008 12:21:18 PM
Subject: RE: [Iccrg] SSDT Scope

I have heard two sets of complaints about slow start; one its too slow, in the sense for connections that usually never get out of slow start and are latency sensitive need something faster. Proposals; second is nto really a customer complaint per-se but not good behavior in general, which is that slow start doubles rate before it hits a loss and this overshooting of buffer should be avoided if we can detect it.

Now the first problem is already addressed to some extent by proposals like Limited Slowstart, QuickStart etc . is SSDT?s goal to improve those solutions?

<dc> I confess I am a bit confused with your last statement about limited slow start and quickstart as solutions to connections that usually never get out of slow start. How does limited slow start help there? I would understand limited slow start helping the second issue as described above...

I also would rather keep the discussion about what are the current SS issues worthy to work on, rather than to jump into a discussion on possible solutions of issues that potentially are not found worth pursuing them. Also, it may be that we agree that a tangible and hence worth pursuing contribution would be to come-up with a document describing the relevant limitations of SS, as the ICCRG sees it.

Dirceu
</dc>

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dirceu Cavendish
Sent: Wednesday, March 26, 2008 10:24 AM
To: [email-masked]
Subject: [Iccrg] SSDT Scope

On Michael's advise, I am re-sending this message to the ICCRG mailing list.

Hello people interested in Slow Start.
The first discussion is about the scope of the SSDT group. A good starting point is to list what people have experienced as incovenient behavior of slow start. Once we agree on what to address, we can scope the objectives/goals of the SSDT group.

Our "pain points" are:

- multiple segment losses in high bandwidth delay product networks, when SS opens the cwnd to a large value right before transitioning from SS to CA. This typically causes multiple RTOs...
- Unfairness with different session RTTs.

Feel free to add yours.
Dirceu

----- Original Message ----
From: Lachlan Andrew <[email-masked]>
To: Michael Welzl <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, March 25, 2008 8:04:48 AM
Subject: Re: [Iccrg] "Slow Start" design team

Greetings Michael and Lars,

An advantage of separate mailing lists is that it allows people set up
filters for the mail clients.  That could also be done by asking
people to put a keyword in their email subjects (like slowstartDT).

FWIW, I'm unlikely to subscribe to the DT mailing lists, but wouldn't
mind extra traffic on  iccrg@...

Cheers,
Lachlan

On 25/03/2008, Michael Welzl <[email-masked]<mailto:[email-masked]>> wrote:
> On Tue, 2008-03-25 at 16:05 +0200, Lars Eggert wrote:
>  > On 2008-3-25, at 15:54, ext Michael Welzl wrote:
>  > > The first concrete proposal on the table is (somewhat
>  > > unsurprisingly  :)  ) a design team on Slow Start,
>  > > led by Dirceu himself (which I, not he, suggested).
>  > > I think it's a nice start and definitely worth trying.
>  >
>  > Sounds good.
>  >
>  > > To join the list, send an email to:
>  > > [email-masked]<mailto:[email-masked]>
>  > > with "subscribe YOUR NAME" as the body of the message.
>  >
>  > But why does the DT need its own list? It's not like the ICCRG list is
>  > flooded with traffic, and having the discussions in the open seems
>  > useful.
>
>
> ah, that was just an idea ... after all there should be
>  multiple design teams with multiple lists one day
>
>  we could have it all in the open if people want that,
>  but it just seems to make things a little more organized
>  to me ... dunno, doesn't really matter i suppose
>
>  cheers
>
> michael
>
>
>
>
>  _______________________________________________
>  Iccrg mailing list
>  [email-masked]<mailto:[email-masked]>
>  http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

--
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

_______________________________________________
Iccrg mailing list
[email-masked]<mailto:[email-masked]>
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

________________________________
Never miss a thing. Make Yahoo your homepage.<http://us.rd.yahoo.com/evt=51438/*http:/www.yahoo.com/r/hs>

________________________________
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.<http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080326/404fa079/attachment.html
>From [email-masked]  Wed Mar 26 20:52:38 2008
From: [email-masked] (Dirceu Cavendish)
Date: Wed Mar 26 20:44:41 2008
Subject: [Iccrg] SSDT Scope
Message-ID: <[email-masked]>

I am aware how quickStart helps with Web Service transactions. My question was about how limited slow start helps with that, which was I understood from your previous message...

Dirceu

----- Original Message ----
From: Murari Sridharan <[email-masked]>
To: Dirceu Cavendish <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Wednesday, March 26, 2008 1:31:18 PM
Subject: RE: [Iccrg] SSDT Scope

If i am a web app and i have say some small data to transfer, today in slow start it would take multiple round trips to transfer this data, now say i negotiated a rate with quick start or started with higher cwnd i could complete the transaction faster and be done. I have seen customers complain about this esp when they are on high latency low bandwidth links. 

From: Dirceu Cavendish [[email-masked]]
Sent: Wednesday, March 26, 2008 1:15 PM
To: Murari Sridharan; [email-masked]
Subject: Re: [Iccrg] SSDT Scope

Inline comments: 

----- Original Message ----
From: Murari Sridharan <[email-masked]>
To: Dirceu Cavendish <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Wednesday, March 26, 2008 12:21:18 PM
Subject: RE: [Iccrg] SSDT Scope

I have heard two sets of complaints about slow start; one its too slow, in the sense for connections that usually never get out of slow start and are latency sensitive need something faster. Proposals; second is nto really a customer complaint per-se but not good behavior in general, which is that slow start doubles rate before it hits a loss and this overshooting of buffer should be avoided if we can detect it. 
 
Now the first problem is already addressed to some extent by proposals like Limited Slowstart, QuickStart etc . is SSDT?s goal to improve those solutions?
 
<dc> I confess I am a bit confused with your last statement about limited slow start and quickstart as solutions to connections that usually never get out of slow start. How does limited slow start help there? I would understand limited slow start helping the second issue as described above...
 
I also would rather keep the discussion about what are the current SS issues worthy to work on, rather than to jump into a discussion on possible solutions of issues that potentially are not found worth pursuing them. Also, it may be that we agree that a tangible and hence worth pursuing contribution would be to come-up with a document describing the relevant limitations of SS, as the ICCRG sees it.
 
Dirceu
</dc>

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dirceu Cavendish
Sent: Wednesday, March 26, 2008 10:24 AM
To: [email-masked]
Subject: [Iccrg] SSDT Scope
 
On Michael's advise, I am re-sending this message to the ICCRG mailing list.
 
Hello people interested in Slow Start.
The first discussion is about the scope of the SSDT group. A good starting point is to list what people have experienced as incovenient behavior of slow start. Once we agree on what to address, we can scope the objectives/goals of the SSDT group.
 
Our "pain points" are:
 
- multiple segment losses in high bandwidth delay product networks, when SS opens the cwnd to a large value right before transitioning from SS to CA. This typically causes multiple RTOs...
- Unfairness with different session RTTs.
 
Feel free to add yours.
Dirceu
 
----- Original Message ----
From: Lachlan Andrew <[email-masked]>
To: Michael Welzl <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, March 25, 2008 8:04:48 AM
Subject: Re: [Iccrg] "Slow Start" design team

Greetings Michael and Lars,

An advantage of separate mailing lists is that it allows people set up
filters for the mail clients.  That could also be done by asking
people to put a keyword in their email subjects (like slowstartDT).

FWIW, I'm unlikely to subscribe to the DT mailing lists, but wouldn't
mind extra traffic on  iccrg@...

Cheers,
Lachlan

On 25/03/2008, Michael Welzl <[email-masked]> wrote:
> On Tue, 2008-03-25 at 16:05 +0200, Lars Eggert wrote:
>  > On 2008-3-25, at 15:54, ext Michael Welzl wrote:
>  > > The first concrete proposal on the table is (somewhat
>  > > unsurprisingly  :)  ) a design team on Slow Start,
>  > > led by Dirceu himself (which I, not he, suggested).
>  > > I think it's a nice start and definitely worth trying.
>  >
>  > Sounds good.
>  >
>  > > To join the list, send an email to:
>  > > [email-masked]
>  > > with "subscribe YOUR NAME" as the body of the message.
>  >
>  > But why does the DT need its own list? It's not like the ICCRG list is
>  > flooded with traffic, and having the discussions in the open seems
>  > useful.
>
>
> ah, that was just an idea ... after all there should be
>  multiple design teams with multiple lists one day
>
>  we could have it all in the open if people want that,
>  but it just seems to make things a little more organized
>  to me ... dunno, doesn't really matter i suppose
>
>  cheers
>
> michael
>
>
>
>
>  _______________________________________________
>  Iccrg mailing list
>  [email-masked]
>  http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

-- 
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

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

Never miss a thing. Make Yahoo your homepage.

Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080326/72a35f66/attachment-0001.html
>From [email-masked]  Wed Mar 26 21:01:02 2008
From: [email-masked] (Eddy, Wesley M. (GRC-RCN0)[VZ])
Date: Wed Mar 26 20:52:59 2008
Subject: [Iccrg] philadelphia meeting minutes
In-Reply-To: <002b01c88f68$9f372060$0200a8c0@fun>
References: <[email-masked]><[email-masked]><[email-masked]>
	<002b01c88f68$9f372060$0200a8c0@fun>
Message-ID: <[email-masked]>

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Michael Welzl
>Sent: Wednesday, March 26, 2008 1:41 PM
>
>> 1. "Consensus" of the ICCRG is not entirely clear.  Does it 
>mean that 
>> everyone *subscribed* to the list agrees, or everyone who *posts* to 
>> the list agrees, or that those who attend meetings (Manchester?
>> Philadelphia?) agree?

The IETF usually talks about "rough consensus" rather than "consensus",
in my experience :).

>My god, this is the one big IETF mystery that I've been 
>wondering about all these years. I'll be happy to see the 
>explanation...

This was raised within the context of how we conduct safety
reviews of transport protocols (in general), and what our
"exit strategy" is for finishing reviews once started.  For
CTCP, it seems that we've hit a point where we have basic
agreement both in the meetings and on the list, so that lets
us put the question of establishing consensus off for a little
bit at least ... however, it becomes important again when
discussing CUBIC and then future proposals that are brought
here.  For CTCP, it seems to me like most reviewers arrived
at similar conclusions and didn't dispute the conclusions of
others, so we did not have difficulty obtaining "rough
consensus".

*I believe*, that if at some point it seems like it will be
difficult and time-consuming to obtain consensus, then we have
the leeway to issue a review that says there wasn't consensus
but that N reviewers backed by some list of material (papers,
emails, etc.) felt a proposal was safe for a stated level of
experimentation, and that M reviewers backed by some other
list of material felt that it was only safe for a lower level
of experimentation.  I may be wrong.

From: [email-masked] (Dirceu Cavendish)
Date: Wed Mar 26 18:42:47 2008
Subject: [Iccrg] SSDT Scope
Message-ID: <[email-masked]>

Excellent point, Lachlan. We have also experienced "slowness" of Web Service transactions...I second that...

Dirceu

----- Original Message ----
From: Lachlan Andrew <[email-masked]>
To: Dirceu Cavendish <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, March 26, 2008 11:32:52 AM
Subject: Re: [Iccrg] SSDT Scope

On 26/03/2008, Dirceu Cavendish <[email-masked]> wrote:
>
> Our "pain points" are:
>
> - multiple segment losses in high bandwidth delay product networks, when SS
> opens the cwnd to a large value right before transitioning from SS to CA.
> This typically causes multiple RTOs...
> - Unfairness with different session RTTs.
>
> Feel free to add yours.

I'd add excessively slow start-up on large BDP underutilized paths.
That is the cause of excessive file completion times for SS-dominated
flows.

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

      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080326/b00e1d10/attachment-0001.html
>From [email-masked]  Wed Mar 26 19:04:07 2008
From: [email-masked] (Injong Rhee)
Date: Wed Mar 26 18:56:20 2008
Subject: [Iccrg] SSDT Scope
Message-ID: <[email-masked]>

 >>- Unfairness with different session RTTs.

Why is this a problem with slow start? I guess that the main subject  
is that the original SS is too aggressive as it doubles cwnd by 2 (or  
some factor close to it due to delayed acks) per RTT, and under large  
BDP, there are a huge number of packets overshot at the time of  
losses. The question is how to detect when to finish the ss and  
transit to ca so that we don't have such high losses. 

From: [email-masked] (Lachlan Andrew)
Date: Wed Mar 26 18:24:48 2008
Subject: [Iccrg] SSDT Scope
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 26/03/2008, Dirceu Cavendish <[email-masked]> wrote:
>
> Our "pain points" are:
>
> - multiple segment losses in high bandwidth delay product networks, when SS
> opens the cwnd to a large value right before transitioning from SS to CA.
> This typically causes multiple RTOs...
> - Unfairness with different session RTTs.
>
> Feel free to add yours.

I'd add excessively slow start-up on large BDP underutilized paths.
That is the cause of excessive file completion times for SS-dominated
flows.

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] (Dirceu Cavendish)
Date: Wed Mar 26 17:15:58 2008
Subject: [Iccrg] SSDT Scope
Message-ID: <[email-masked]>

On Michael's advise, I am re-sending this message to the ICCRG mailing list.

Hello people interested in Slow Start.
The first discussion is about the scope of the SSDT group. A good starting point is to list what people have experienced as incovenient behavior of slow start. Once we agree on what to address, we can scope the objectives/goals of the SSDT group.

Our "pain points" are:

- multiple segment losses in high bandwidth delay product networks, when SS opens the cwnd to a large value right before transitioning from SS to CA. This typically causes multiple RTOs...
- Unfairness with different session RTTs.

Feel free to add yours.
Dirceu

----- Original Message ----
From: Lachlan Andrew <[email-masked]>
To: Michael Welzl <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, March 25, 2008 8:04:48 AM
Subject: Re: [Iccrg] "Slow Start" design team

Greetings Michael and Lars,

An advantage of separate mailing lists is that it allows people set up
filters for the mail clients.  That could also be done by asking
people to put a keyword in their email subjects (like slowstartDT).

FWIW, I'm unlikely to subscribe to the DT mailing lists, but wouldn't
mind extra traffic on  iccrg@...

Cheers,
Lachlan

On 25/03/2008, Michael Welzl <[email-masked]> wrote:
> On Tue, 2008-03-25 at 16:05 +0200, Lars Eggert wrote:
>  > On 2008-3-25, at 15:54, ext Michael Welzl wrote:
>  > > The first concrete proposal on the table is (somewhat
>  > > unsurprisingly  :)  ) a design team on Slow Start,
>  > > led by Dirceu himself (which I, not he, suggested).
>  > > I think it's a nice start and definitely worth trying.
>  >
>  > Sounds good.
>  >
>  > > To join the list, send an email to:
>  > > [email-masked]
>  > > with "subscribe YOUR NAME" as the body of the message.
>  >
>  > But why does the DT need its own list? It's not like the ICCRG list is
>  > flooded with traffic, and having the discussions in the open seems
>  > useful.
>
>
> ah, that was just an idea ... after all there should be
>  multiple design teams with multiple lists one day
>
>  we could have it all in the open if people want that,
>  but it just seems to make things a little more organized
>  to me ... dunno, doesn't really matter i suppose
>
>  cheers
>
> michael
>
>
>
>
>  _______________________________________________
>  Iccrg mailing list
>  [email-masked]
>  http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

-- 
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

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

      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080326/bc79e096/attachment.html
>From [email-masked]  Wed Mar 26 17:41:28 2008
From: [email-masked] (Michael Welzl)
Date: Wed Mar 26 17:30:31 2008
Subject: [Iccrg] philadelphia meeting minutes
References: <[email-masked]><[email-masked]>
	<[email-masked]>
Message-ID: <002b01c88f68$9f372060$0200a8c0@fun>

> 1. "Consensus" of the ICCRG is not entirely clear.  Does it mean that
> everyone *subscribed* to the list agrees, or everyone who *posts* to
> the list agrees, or that those who attend meetings (Manchester?
> Philadelphia?) agree?

My god, this is the one big IETF mystery that I've been wondering
about all these years. I'll be happy to see the explanation...

Cheers,
Michael

From: [email-masked] (Lachlan Andrew)
Date: Wed Mar 26 16:11:42 2008
Subject: [Iccrg] philadelphia meeting minutes
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

I should also add:

1. "Consensus" of the ICCRG is not entirely clear.  Does it mean that
everyone *subscribed* to the list agrees, or everyone who *posts* to
the list agrees, or that those who attend meetings (Manchester?
Philadelphia?) agree?

2. If anyone wants to experiment with the Linux re-implementation of
CTCP, take a look at <http://netlab.caltech.edu/lachlan/ctcp/>.  It
currently doesn't support  abc  or pacing of window increases.  I
believe Vista does these but it was not specified in the latest draft
that I saw.

Cheers,
Lachlan

On 26/03/2008, Lachlan Andrew <[email-masked]> wrote:
> Thanks Wes.
>
>  People asked for a reference for the "Hamilton" tests (which were
>  actually joint work with Caltech... :)  Our PFLDnet paper is at
>  <http://netlab.caltech.edu/lachlan/abstract/HybridPFLDnet08.pdf>.
>
>  Cheers,
>  Lachlan
>
>
>  On 26/03/2008, Eddy, Wesley M. (GRC-RCN0)[VZ] <[email-masked]> wrote:
>  > Preliminary minutes from the Philadelphia meeting are online at:
>  >  http://www.ietf.org/proceedings/08mar/minutes/iccrg.txt
>  >
>  >  We have until April 30 to make corrections if anything is wrong
>  >  or incomplete.
>  >
>  >  _______________________________________________
>  >  Iccrg mailing list
>  >  [email-masked]
>  >  http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>  >
>
>
>
> --
>  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
>

-- 
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] (Lachlan Andrew)
Date: Wed Mar 26 16:05:09 2008
Subject: [Iccrg] philadelphia meeting minutes
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Thanks Wes.

People asked for a reference for the "Hamilton" tests (which were
actually joint work with Caltech... :)  Our PFLDnet paper is at
<http://netlab.caltech.edu/lachlan/abstract/HybridPFLDnet08.pdf>.

Cheers,
Lachlan

On 26/03/2008, Eddy, Wesley M. (GRC-RCN0)[VZ] <[email-masked]> wrote:
> Preliminary minutes from the Philadelphia meeting are online at:
>  http://www.ietf.org/proceedings/08mar/minutes/iccrg.txt
>
>  We have until April 30 to make corrections if anything is wrong
>  or incomplete.
>
>  _______________________________________________
>  Iccrg mailing list
>  [email-masked]
>  http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

-- 
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] (Eddy, Wesley M. (GRC-RCN0)[VZ])
Date: Wed Mar 26 13:00:31 2008
Subject: [Iccrg] philadelphia meeting minutes
Message-ID: <[email-masked]>

Preliminary minutes from the Philadelphia meeting are online at:
http://www.ietf.org/proceedings/08mar/minutes/iccrg.txt

We have until April 30 to make corrections if anything is wrong
or incomplete.

From: [email-masked] (Dirceu Cavendish)
Date: Tue Mar 25 17:06:58 2008
Subject: [Iccrg] "Slow Start" design team
Message-ID: <[email-masked]>

I believe that a mailing list could facilitate the "narrowness" of the work to be done about a given topic. Having all the work open to a wider audience the people committed to doing the work might dilute the efforts, pulling threads in many directions. Of course everyone in ICCRG may join the list, so the DT structure could degenerate into a full ICCRG group participation. But the idea of a DT is to allow QUICK progress towards a narrow goal.
Having a wider discussion about potentially every step of the work does not sound a good strategy to me.

My proposal then would be to discuss the SCOPE of the SS DT within ICCRG mailing list, and then move to a SSDT mailing list for the bulk of the work...Is there a good compromise between people on both sides of the aisle?

I also wish to clarify that I would be "facilitating" the DT, not leading it :-)
Dirceu

----- Original Message ----
From: John Leslie <[email-masked]>
To: Michael Welzl <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, March 25, 2008 8:05:54 AM
Subject: Re: [Iccrg] "Slow Start" design team

Michael Welzl <[email-masked]> wrote:
> 
> A design team should have a very narrow focus, its own
> mailing list, and be led by someone who is willing and
> able to push the whole thing along.

   Agreed.

> The first concrete proposal on the table is (somewhat
> unsurprisingly  :)  ) a design team on Slow Start,
> led by Dirceu himself (which I, not he, suggested).
> I think it's a nice start and definitely worth trying.
> 
> To join the list, send an email to:
> [email-masked]
> with "subscribe YOUR NAME" as the body of the message.

   I'm not sure a Design Team should be quite that open,
though I'd certainly welcome frequent interaction with the
main iccrg list.

   In any case, I'm holding off on joining that list...

> The first question that should be discussed in this
> list (not here - let's try and move this discussion there
> already) is what exactly the team should focus on:
> 
> * enhancements to the end of slow start (like Dirceu
>   presented at our meeting)
> 
> * different slow start enhancements (like the paper from
>   Injong's group at PFLDNet)
> 
> * something else?

   I strongly recommend nailing down the problem that
Slow-Start is supposed to solve. Without firm agreement
on that, I'm afraid we'll get a random-walk problem.

> * is this only about TCP, or also for other protocols?

   That might be the wrong question. We should start with
a description of what we're trying to fix; then work on
whether fixing it within TCP is even the right place to
start.

--
John Leslie <[email-masked]>

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

      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080325/4b2df846/attachment.html
>From [email-masked]  Wed Mar 26 06:58:58 2008
From: [email-masked] (Michael Welzl)
Date: Wed Mar 26 06:51:10 2008
Subject: [Iccrg] "Slow Start" design team
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi all,

Based on the comments recently received, I'm in favor of sticking
with the original plan, of using a separate mailing list.

- and I also agree that the scope discussion should take
place here - but just this one.

Cheers,
Michael

On Tue, 2008-03-25 at 10:14 -0700, Dirceu Cavendish wrote:
> I believe that a mailing list could facilitate the "narrowness" of the
> work to be done about a given topic. Having all the work open to a
> wider audience the people committed to doing the work might dilute the
> efforts, pulling threads in many directions. Of course everyone in
> ICCRG may join the list, so the DT structure could degenerate into a
> full ICCRG group participation. But the idea of a DT is to allow QUICK
> progress towards a narrow goal.
> Having a wider discussion about potentially every step of the work
> does not sound a good strategy to me.
> 
> My proposal then would be to discuss the SCOPE of the SS DT within
> ICCRG mailing list, and then move to a SSDT mailing list for the bulk
> of the work...Is there a good compromise between people on both sides
> of the aisle?
> 
> I also wish to clarify that I would be "facilitating" the DT, not
> leading it :-)
> Dirceu
> 
> ----- Original Message ----
> From: John Leslie <[email-masked]>
> To: Michael Welzl <[email-masked]>
> Cc: [email-masked]
> Sent: Tuesday, March 25, 2008 8:05:54 AM
> Subject: Re: [Iccrg] "Slow Start" design team
> 
> Michael Welzl <[email-masked]> wrote:
> > 
> > A design team should have a very narrow focus, its own
> > mailing list, and be led by someone who is willing and
> > able to push the whole thing along.
> 
>   Agreed.
> 
> > The first concrete proposal on the table is (somewhat
> > unsurprisingly  :)  ) a design team on Slow Start,
> > led by Dirceu himself (which I, not he, suggested).
> > I think it's a nice start and definitely worth trying.
> > 
> > To join the list, send an email to:
> > [email-masked]
> > with "subscribe YOUR NAME" as the body of the message.
> 
>   I'm not sure a Design Team should be quite that open,
> though I'd certainly welcome frequent interaction with the
> main iccrg list.
> 
>   In any case, I'm holding off on joining that list...
> 
> > The first question that should be discussed in this
> > list (not here - let's try and move this discussion there
> > already) is what exactly the team should focus on:
> > 
> > * enhancements to the end of slow start (like Dirceu
> >  presented at our meeting)
> > 
> > * different slow start enhancements (like the paper from
> >  Injong's group at PFLDNet)
> > 
> > * something else?
> 
>   I strongly recommend nailing down the problem that
> Slow-Start is supposed to solve. Without firm agreement
> on that, I'm afraid we'll get a random-walk problem.
> 
> > * is this only about TCP, or also for other protocols?
> 
>   That might be the wrong question. We should start with
> a description of what we're trying to fix; then work on
> whether fixing it within TCP is even the right place to
> start.
> 
> --
> John Leslie <[email-masked]>
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 
> 
> 
> 
> 
> ______________________________________________________________________
> Looking for last minute shopping deals? Find them fast with Yahoo!
> Search.

From: [email-masked] (John Leslie)
Date: Tue Mar 25 14:57:59 2008
Subject: [Iccrg] "Slow Start" design team
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <20080325150554.GH25340@verdi>

Michael Welzl <[email-masked]> wrote:
> 
> A design team should have a very narrow focus, its own
> mailing list, and be led by someone who is willing and
> able to push the whole thing along.

   Agreed.

> The first concrete proposal on the table is (somewhat
> unsurprisingly  :)  ) a design team on Slow Start,
> led by Dirceu himself (which I, not he, suggested).
> I think it's a nice start and definitely worth trying.
> 
> To join the list, send an email to:
> [email-masked]
> with "subscribe YOUR NAME" as the body of the message.

   I'm not sure a Design Team should be quite that open,
though I'd certainly welcome frequent interaction with the
main iccrg list.

   In any case, I'm holding off on joining that list...

> The first question that should be discussed in this
> list (not here - let's try and move this discussion there
> already) is what exactly the team should focus on:
> 
> * enhancements to the end of slow start (like Dirceu
>   presented at our meeting)
> 
> * different slow start enhancements (like the paper from
>   Injong's group at PFLDNet)
> 
> * something else?

   I strongly recommend nailing down the problem that
Slow-Start is supposed to solve. Without firm agreement
on that, I'm afraid we'll get a random-walk problem.

> * is this only about TCP, or also for other protocols?

   That might be the wrong question. We should start with
a description of what we're trying to fix; then work on
whether fixing it within TCP is even the right place to
start.

--
John Leslie <[email-masked]>

From: [email-masked] (Lachlan Andrew)
Date: Tue Mar 25 14:56:53 2008
Subject: [Iccrg] "Slow Start" design team
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Michael and Lars,

An advantage of separate mailing lists is that it allows people set up
filters for the mail clients.  That could also be done by asking
people to put a keyword in their email subjects (like slowstartDT).

FWIW, I'm unlikely to subscribe to the DT mailing lists, but wouldn't
mind extra traffic on  iccrg@...

Cheers,
Lachlan

On 25/03/2008, Michael Welzl <[email-masked]> wrote:
> On Tue, 2008-03-25 at 16:05 +0200, Lars Eggert wrote:
>  > On 2008-3-25, at 15:54, ext Michael Welzl wrote:
>  > > The first concrete proposal on the table is (somewhat
>  > > unsurprisingly  :)  ) a design team on Slow Start,
>  > > led by Dirceu himself (which I, not he, suggested).
>  > > I think it's a nice start and definitely worth trying.
>  >
>  > Sounds good.
>  >
>  > > To join the list, send an email to:
>  > > [email-masked]
>  > > with "subscribe YOUR NAME" as the body of the message.
>  >
>  > But why does the DT need its own list? It's not like the ICCRG list is
>  > flooded with traffic, and having the discussions in the open seems
>  > useful.
>
>
> ah, that was just an idea ... after all there should be
>  multiple design teams with multiple lists one day
>
>  we could have it all in the open if people want that,
>  but it just seems to make things a little more organized
>  to me ... dunno, doesn't really matter i suppose
>
>  cheers
>
> michael
>
>
>
>
>  _______________________________________________
>  Iccrg mailing list
>  [email-masked]
>  http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

-- 
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] (Michael Welzl)
Date: Tue Mar 25 14:22:46 2008
Subject: [Iccrg] "Slow Start" design team
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue, 2008-03-25 at 16:05 +0200, Lars Eggert wrote:
> On 2008-3-25, at 15:54, ext Michael Welzl wrote:
> > The first concrete proposal on the table is (somewhat
> > unsurprisingly  :)  ) a design team on Slow Start,
> > led by Dirceu himself (which I, not he, suggested).
> > I think it's a nice start and definitely worth trying.
> 
> Sounds good.
> 
> > To join the list, send an email to:
> > [email-masked]
> > with "subscribe YOUR NAME" as the body of the message.
> 
> But why does the DT need its own list? It's not like the ICCRG list is  
> flooded with traffic, and having the discussions in the open seems  
> useful.

ah, that was just an idea ... after all there should be
multiple design teams with multiple lists one day

we could have it all in the open if people want that,
but it just seems to make things a little more organized
to me ... dunno, doesn't really matter i suppose

cheers
michael

From: [email-masked] (Lars Eggert)
Date: Tue Mar 25 13:57:41 2008
Subject: [Iccrg] "Slow Start" design team
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 2008-3-25, at 15:54, ext Michael Welzl wrote:
> The first concrete proposal on the table is (somewhat
> unsurprisingly  :)  ) a design team on Slow Start,
> led by Dirceu himself (which I, not he, suggested).
> I think it's a nice start and definitely worth trying.

Sounds good.

> To join the list, send an email to:
> [email-masked]
> with "subscribe YOUR NAME" as the body of the message.

But why does the DT need its own list? It's not like the ICCRG list is  
flooded with traffic, and having the discussions in the open seems  
useful.

Lars

From: [email-masked] (Michael Welzl)
Date: Tue Mar 25 13:46:04 2008
Subject: [Iccrg] "Slow Start" design team
Message-ID: <[email-masked]>

Dear all,

At the Manchester ICCRG meeting, some concern was raised
about this group being too broad and unable to make
concrete developments. I am against "removing" the breadth,
but still in favor of finding focus for some topics.
At the meeting, Dirceu Cavendish made a suggestion which
both Wes and I are very happy with: to start "design teams",
small temporary (max 1/2 year) groups where concrete things
are developed.

A design team should have a very narrow focus, its own
mailing list, and be led by someone who is willing and
able to push the whole thing along.

The first concrete proposal on the table is (somewhat
unsurprisingly  :)  ) a design team on Slow Start,
led by Dirceu himself (which I, not he, suggested).
I think it's a nice start and definitely worth trying.

To join the list, send an email to:
[email-masked]
with "subscribe YOUR NAME" as the body of the message.

The first question that should be discussed in this
list (not here - let's try and move this discussion there
already) is what exactly the team should focus on:

* enhancements to the end of slow start (like Dirceu
  presented at our meeting)

* different slow start enhancements (like the paper from
  Injong's group at PFLDNet)

* something else?

* is this only about TCP, or also for other protocols?

I would like to leave these decisions up to the team
leader, that's why we should move the discussion there.
If you're interested, please join this list. I just did -
see you there!

Cheers,
Michael

From: [email-masked] (Lachlan Andrew)
Date: Mon Mar 17 21:36:46 2008
Subject: [Iccrg] TCP evaluation suite round-table
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Preethi,

On 17/03/2008, Preethi Natarajan <[email-masked]> wrote:
>
>  Are there any recommendations for cross-traffic generation/Tmix
>  "connection vector" parameters used in "Towards a Common TCP Evaluation
>  Suite"?.
>  Specifically, any pointers to details such as the number of
>  FTP/HTTP/voice sessions to use, "think" time for HTTP sessions etc.

Not yet.  The plan is to produce standard connection vectors, probably
some snippets from the actual traces that the Tmix team have been
using.

We'll keep you informed of any developments.

Cheers,
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] (Preethi Natarajan)
Date: Mon Mar 17 16:07:20 2008
Subject: [Iccrg] TCP evaluation suite round-table
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello all,

Are there any recommendations for cross-traffic generation/Tmix 
"connection vector" parameters used in "Towards a Common TCP Evaluation 
Suite"?.
Specifically, any pointers to details such as the number of 
FTP/HTTP/voice sessions to use, "think" time for HTTP sessions etc.

Thanks for your help,

Preethi

On 11/5/2007 6:42 PM, Lachlan Andrew wrote:
> Greetings all,
>
> Thanks to those who have agreed to attend the TCP evaluation round
> table.  If anyone else would like to attend by EVO video conference,
> please let me know.
>
> There is still time to give feedback on the tentative schedule at
> <http://wil.cs.caltech.edu/mwiki/index.php?title=Round_table_agenda>
>
> I've also tentatively allocated a "discussion leader" to each session,
> as follows:
>
> Thursday:
> Lachlan Andrew 	 Opening discussion of scope of this meeting
> Cesar Marcondes          Benchmarking Scenario Parameters (Bandwidth,
> Delay, Buffer)
> Lars Eggert 	Measure of Utilization
> Bob Shorten	Overall Responsiveness / Convergence Time Discussion
> Sally Floyd 	New algorithms Impact on Cross-Traffic
>
> Friday:
> Sangtae Ha 	Managing the Curse of Dimensionality on Core Tests
> Gang Wang 	Basic Core Scenarios
> Larry Dunn 	Basic Cross-Traffic Models
>
>
> Bob, will you be OK to lead the discussion by voice link, or do you
> think it would be better for someone present in person to do it?
>
>
> My current hope is that we can write up the agreement as a PFLDnet
> paper, with the discussion leaders writing the first draft of their
> respective sections.  Ideally it would be good for this to progress
> into a TMRG draft, but I don't think we'll get there this week.
>
> Cheers,
> Lachlan
>
>   

From: [email-masked] (Murari Sridharan)
Date: Tue Mar 11 14:53:35 2008
Subject: [Iccrg] More evidence on safety of the protocol
Message-ID: <[email-masked]>

Skipped content of type multipart/alternative-------------- next part --------------
An embedded message was scrubbed...
From: Sally Floyd <[email-masked]>
Subject: Re: CTCP - Internet Draft
Date: Thu, 29 Nov 2007 11:16:06 -0800
Size: 2803
Url: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080311/9f8ee693/attachment.mht
-------------- next part --------------
An embedded message was scrubbed...
From: Kun Tan <[email-masked]>
Subject: RE: CTCP - Internet Draft
Date: Tue, 27 Nov 2007 22:39:05 -0800
Size: 3438
Url: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080311/9f8ee693/attachment-0001.mht
>From [email-masked]  Wed Mar 12 14:55:59 2008
From: [email-masked] (Michael Welzl)
Date: Wed Mar 12 14:49:59 2008
Subject: [Iccrg] Re: [tcpm] Separate header checksums and WiFi
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hi all,

[ Answering an email from January 2007 (my, my, how time flies  :-(  ),
and including ICCRG because I recently mentioned this study there,
so it might be of interest to them too ]

We finally did that:

Michael Welzl, Mattia Rossi, Andrea Fumagalli, Marco Tacca, "TCP/IP over
IEEE 802.11b WLAN: the Challenge of Harnessing Known-Corrupt Data",
accepted for publication, IEEE ICC 2008 (International Conference on
Communications), 19-23 May 2008, Beijing, China.

Available from
http://www.welzl.at/research/projects/corruption/index.html
(until somebody tells me that I misread the legal bits and
am not allowed to do so)

Cheers,
Michael

On Wed, 2007-01-31 at 09:14 -0800, Joe Touch wrote:
> Beyond what Ethan is suggesting, this is useful to write up more fully
> and publish, e.g., at Globecom or ICC. Negative results, as Ethan notes,
> are critical to the community as a whole.
> 
> Joe
> 
> Ethan Blanton wrote:
> > Michael Welzl spake unto us the following wisdom:
> >> I figured that the only convincing way to prove him
> >> wrong is to actually do a real-life test. I did, and
> >> proved him right  :)  that is, disabling checksums for
> >> parts of packets doesn't yield much of a benefit in
> >> WiFi networks, where it seems that frames are delivered
> >> in an all-or-nothing fashion.
> > 
> > I have to applaud this move.  All too often we only talk about the
> > things we did that *worked*, and the same questions about things that
> > any number of people would tell you doesn't work come up over and
> > over.  For this particular topic, there is now a citation, so the next
> > guy won't have to go try it himself.  Thank you.
> > 
> > Ethan
> > 
> > 
> > 
> > ------------------------------------------------------------------------
> > 
> > _______________________________________________
> > tcpm mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/tcpm
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tcpm

From: [email-masked] (Michael Welzl)
Date: Tue Mar 11 07:35:39 2008
Subject: [Iccrg] Manchester ICCRG minutes
Message-ID: <[email-masked]>

Hi all,

Stephen Kershaw from Manchester University took notes
at our meeting in Manchester; they're attached. Thank
you Stephen!

cheers,
Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Manchester_ICCRG_notes.doc
Type: application/msword
Size: 75264 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080311/a796e58a/Manchester_ICCRG_notes-0001.doc
>From [email-masked]  Tue Mar 11 14:46:42 2008
From: [email-masked] (Murari Sridharan)
Date: Tue Mar 11 14:40:38 2008
Subject: FW: [Iccrg] ctcp review: big picture issues (3 of 4)
Message-ID: <[email-masked]>

Following up on Mark's questions from yesterday's ICCRG meeting.

Mark here is the link I mentioned, the paper is also at the following link

http://www.hep.man.ac.uk/PFLDnet2008/paper/Kun_T%20Final.pdf

Almost all graphs here are due to real congestion (except Fig 7) and since this is improving CTCP behavior under very low buffered links we use buffer sizes as low as 0.6% BDP and losses are truly congestion based as number of flows increase, background traffic is added etc.

If you also look at the SLAC results from real networks those obviously count as well. Also from the wiki if you look at the following presentation there are slides in the end which is trying to look at the stability of the protocol with high level of statistical multiplexing at the bottleneck link. This should give you some idea about worst case behavior of having a very small gamma and also these are results where losses are purely due to congestion. Slides 21/22.

http://research.microsoft.com/users/dthaler/IETF%20-%20Compound%20TCP.pdf

Thanks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Murari Sridharan
Sent: Tuesday, December 04, 2007 3:40 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Iccrg] ctcp review: big picture issues (3 of 4)

Sorry, that reference is to the ICCRG Wiki

http://www3.tools.ietf.org/group/irtf/trac/wiki/ICCRG_ctcp

The link is gamma parameter tuning.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, December 04, 2007 3:38 PM
To: Murari Sridharan
Cc: Lachlan Andrew; [email-masked]
Subject: Re: [Iccrg] ctcp review: big picture issues (3 of 4)

> If you look at our gamma auto-tuning paper there are a number of such
> experiments.

Can you make that reference a tad more specific?

Thanks,
allman

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

From: [email-masked] (Volker Hilt)
Date: Sun Mar  9 22:15:56 2008
Subject: [Iccrg] SIP overload talk
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Dear all,

the TSVAREA meeting is 1740-1950 ET on Tuesday, March 11. I had the 
start time wrong in my last email. Sorry! The meeting agenda can be 
found at:
http://www.ietf.org/proceedings/08mar/agenda/tsvarea.txt

Volker

Volker Hilt wrote:
> Dear all,
> 
> a slightly shortened version of the SIP overload control talk is on the 
> agenda for the Transport Area Open Meeting at the upcoming IETF meeting 
> in Philadelphia. This meeting is on Tuesday, March 11 at 1850-1950 ET. 
> Since the audio wasn't working well this morning, that might be another 
> opportunity to attend the talk and it is another opportunity to provide 
> comments and feedback!
> 
> Thanks,
> 
> Volker
> 
> 
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Bob Briscoe)
Date: Wed Mar  5 10:57:20 2008
Subject: [Iccrg] Promised ref to sensor net pushback lit review
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080305/03abb124/attachment.html
>From [email-masked]  Wed Mar  5 13:40:39 2008
From: [email-masked] (Murari Sridharan)
Date: Wed Mar  5 13:38:44 2008
Subject: [Iccrg] proposed Compound TCP review
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Regarding BaseRTT the effect of that value on the algorithm behavior is fairly deterministic and straightforward.

While dwnd is active (non-zero) and cwnd is still catching up, baseRTT is used to detect congestion. BaseRTT tracks the lowest RTT measured since the last timeout. Again for correctness we don't go by one sample but averaged over a window worth of samples. So reverse path queueing for instance is going to show up as congestion.

Once Cwnd catches up and Dwnd becomes zero then basertt has no real effect since the loss based flow is fully taken over at that point.

I don't understand the security implication, are you talking about optimistic ACKs skewing the baseRTT to be lower than it is? Firstly that attack exists for regular TCP but in our case if we measure the baseRTT to be lower than normal, then any actual sample is only going to make us think that the link is congested. One more thing to note here is that DWND is independent of RTT in the sense that the amount of packets it keeps backlogged in the queue is not a function of RTT so I don't see what the security implications here could be. Also note that RTT samples are taken only at the sender and not based on echoed value from receiver.

Thanks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Douglas Leith
Sent: Tuesday, March 04, 2008 9:02 AM
To: Eddy, Wesley M. (GRC-RCN0)[VZ]
Cc: iccrg
Subject: Re: [Iccrg] proposed Compound TCP review

I'm not so clear about the correctness of the following sentence:

"Compound TCP's design only utilizes the delay-based
component when the loss-rate is low and the congestion window
has been able to grow large already based on the current
Standards Track mechanisms."

As I understand it, the delay based increase action is used whenever
the estimated queueing delay is low.   Since it is a fairly
aggressive increase (similar to HS-TCP) it seems possible that the
delay window can  reach large values even when the loss rate is quite
high (and so the standard Reno cwnd would be relatively low).

If that's correct then the above sentence doesn't seem quite right.
For example under conditions with high loss rates (e.g. due to non-
congestive loss) it might be possible for the delay component to
dominate CTCP behaviour, although I have seen no studies of this.  It
might be worth checking such scenarios in view of the apparent
importance of the above sentence in the stated case for the safety of
CTCP.

I think it might also be useful to include some discussion (at a
minimum it would at leats be worth highlighting that they aren't
covered by this document) of the following issues:

1. The CTCP delay component operates on the basis of *estimated*
queueing delay.  What is the impact, if any, of errors in the
estimated value ?  Reverse path queueing and errors in baseRTT
estimation spring to mind here as possible issues that could create
estimation errors.    Also, Constantine Dovrolis and others have
already highlighted possible sampling issues when trying to use delay
to infer congestion on heavily multiplexed links where delay may be
only weakly correlated with congestion.

2. Operation over wireless.  I've seen no studies of operation over
802.11 wireless, which is ubiquitous as a last hop.  Since its a
random access technology, there is not necessarily a strong
connection between variations in delay and network queue occupancy (I
have some measurements illustrating this).  The baseRTT also varies
with network load (number of contending stations) at a wireless hop
and this might have implications for estimating queueing delay.

3. Security implications of use of delay.   The use of a new
measurement for congestion control immediately raises concerns about
security.  Can the measurement be spoofed, or otherwise manipulated
to create an advantage ?  Does it create new avenues for denial of
service attack etc ?   If delay is measured via packet time-stamps it
seems pretty likely that a receiver could do all sorts of interesting
things by manipulating the timestamp echoed back to the sender.    I
reckon this can be addressed by using delay measurements derived at
the sender side only (this is now done in Linux for example, and may
well be already done in Vista although I haven't seen it stated
anywhere), but it seems worth a comment and perhaps a little more
thought.

Lastly, I don't know how people fell about this but it might well be
worth prefacing the review with some statement of terms of
reference.  At the moment the review seems to focus on safety and
suitability for release as an experimental RFC.    That's fine but an
obvious question is should there be any comment on performance or
likely benefits to be gained from use of the algorithm ?  If not (and
I guess this will be the case) it might be a good idea to state up
front that analysis of performance benefits is out of scope for this
document, to avoid potential misunderstandings in the future.

Doug

Prof. Douglas Leith
Hamilton Institute
www.hamilton.ie

On 4 Mar 2008, at 16:07, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:

> Attached is a proposed RG review of the Compound TCP draft that we
> were
> asked to consider the safety of for experimental deployment on the
> Internet,
> on behalf of TCPM.
>
> We had several mails on-list about this in recent months, and now that
> discussion has slowed down, I believe we may be ready to close on this
> and submit an official RG review to TCPM.  Please review the attached
> text
> for accuracy, and comment on it.  I drafted it with help from the list
> archives, and believe it captures a consensus that the RG has at a
> high-level.
>
> Replies via email that either support this, or suggest clarifications,
> improvements, or fixes are welcomed at this time.  I also set aside
> time during the Philadelphia meeting that we can use to discuss or
> revise this in real-time face-to-face.  Also, let us know if it is
> wildly inaccurate or doesn't capture your individual concerns at a
> high-level.  Thanks for your help.<ctcp-
> review.txt>_______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

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

From: [email-masked] (Volker Hilt)
Date: Wed Mar  5 10:38:28 2008
Subject: [Iccrg] SIP overload talk
Message-ID: <[email-masked]>

Dear all,

a slightly shortened version of the SIP overload control talk is on the 
agenda for the Transport Area Open Meeting at the upcoming IETF meeting 
in Philadelphia. This meeting is on Tuesday, March 11 at 1850-1950 ET. 
Since the audio wasn't working well this morning, that might be another 
opportunity to attend the talk and it is another opportunity to provide 
comments and feedback!

Thanks,

Volker

From: [email-masked] (Bob Briscoe)
Date: Wed Mar  5 10:20:02 2008
Subject: [Iccrg] About the live stream
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Folks,

Michael has asked me to let you know we'll carry on with his own talk 
until the break at 11:00 UTC when we'll try again to sort out the 
audio (tho I understand some people are now getting it).

Video should be more visible now.

Bob

At 09:52 05/03/2008, Michael Welzl wrote:
>Hi,
>
>You can log in to our meeting as explained here:
>http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-March/000423.html
>
>People told me that there is no audio, and the slides are
>hardly visible. We are trying to fix the audio problem;
>since this is a very small room, I can't move the camera
>around to fix the slide problem. However, I will ask people
>after this talk to give me their slides *in advance* and
>upload them as I get them to this page:
>http://www.welzl.at/iccrg-mar08-slides/
>
>sorry for not having converted all of the slides to pdf
>yet, it's the best I can do on the fly. I'll convert them
>when the meeting is over.
>
>So far, you missed my introduction, which is really
>not a big deal, and sadly you are missing the ongoing
>talk by Volker about SIP overload control. At least
>I'll upload his slides right after his talk. For the
>rest of the day, I'll make sure that the slides are
>available before the talks, and hopefully you'll hear
>people talking.
>
>Sorry for the trouble!
>
>Cheers,
>Michael
>
>
>_______________________________________________
>Iccrg mailing list
>[email-masked]
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

____________________________________________________________________________
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] (Bob Briscoe)
Date: Wed Mar  5 10:06:40 2008
Subject: [Iccrg] Preliminary agenda for the next meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <005701c87af0$87bf9ac0$0200a8c0@fun> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Michael,

My slides are at:
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/present.html#0803iccrg>
Byte and Packet Congestion Notification

For the list: Michael will also upload these to the wiki, but for now 
the above will do.

Cheers

Bob

At 07:04 04/03/2008, Michael Welzl wrote:
>On Mon, 2008-03-03 at 23:55 +0000, Bob Briscoe wrote:
> > Michael,
> >
> > At 16:31 29/02/2008, Michael Welzl wrote:
> > >Bob - regarding your previous email, would you like to give
> > >a talk about this stuff in Manchester? It surely would be of interest
> > >to the group
> > >
> > >if so, give me a title and suggested length please.
> >
> > Tx for registration & the invite [repeat email for the list].
> >
> > Title: Packet Size & Congestion Control
> > Time:  20mins (incl Q&A)
>
>Thanks!
>I squeezed into the agenda, right after my talk about
>the open issues draft. I think that this is a good
>position because it fits content-wise, and only cuts the
>open discussion down from 1 full hour (too much anyway)
>to 40 mins (still a lot):
>http://www3.tools.ietf.org/group/irtf/trac/wiki/Agenda08
>
>(ignore the "Agenda.2.doc" attachment - this exists because
>I didn't check the "overwrite" box at first and don't seem
>to have the rights to delete this file...)
>
>
> > Background I-D:
> > Byte and Packet Congestion Notification
> > draft-briscoe-tsvwg-byte-pkt-mark-02.txt
> >
> > If this is too late or there's no longer any space in the agenda,
> > just let me know - I'll be preparing the slides tomorrow assuming
> > it's OK. Sorry - this is the first time I've connected to email since Fri.
>
>No worries!
>
>Cheers,
>Michael

____________________________________________________________________________
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: Wed Mar  5 09:46:59 2008
Subject: [Iccrg] About the live stream
Message-ID: <[email-masked]>

Hi,

You can log in to our meeting as explained here:
http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-March/000423.html

People told me that there is no audio, and the slides are
hardly visible. We are trying to fix the audio problem;
since this is a very small room, I can't move the camera
around to fix the slide problem. However, I will ask people
after this talk to give me their slides *in advance* and
upload them as I get them to this page:
http://www.welzl.at/iccrg-mar08-slides/

sorry for not having converted all of the slides to pdf
yet, it's the best I can do on the fly. I'll convert them
when the meeting is over.

So far, you missed my introduction, which is really
not a big deal, and sadly you are missing the ongoing
talk by Volker about SIP overload control. At least
I'll upload his slides right after his talk. For the
rest of the day, I'll make sure that the slides are
available before the talks, and hopefully you'll hear
people talking.

Sorry for the trouble!

Cheers,
Michael

From: [email-masked] (Murari Sridharan)
Date: Wed Mar  5 09:41:21 2008
Subject: [Iccrg] proposed Compound TCP review
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Just to clarify the value 38 for triggering dwnd comes from the low_window idea proposed in HighSpeed TCP which corresponds to a packet drop rate of 10^-3.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Murari Sridharan
Sent: Tuesday, March 04, 2008 1:04 PM
To: Douglas Leith; Eddy, Wesley M. (GRC-RCN0)[VZ]
Cc: iccrg
Subject: RE: [Iccrg] proposed Compound TCP review

For the delay window (scalability component) to kick in following conditions have to be met. CWnd >= roughly 38 packets or 57000 bytes && CWnd >= SsThresh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Douglas Leith
Sent: Tuesday, March 04, 2008 9:02 AM
To: Eddy, Wesley M. (GRC-RCN0)[VZ]
Cc: iccrg
Subject: Re: [Iccrg] proposed Compound TCP review

I'm not so clear about the correctness of the following sentence:

"Compound TCP's design only utilizes the delay-based
component when the loss-rate is low and the congestion window
has been able to grow large already based on the current
Standards Track mechanisms."

As I understand it, the delay based increase action is used whenever
the estimated queueing delay is low.   Since it is a fairly
aggressive increase (similar to HS-TCP) it seems possible that the
delay window can  reach large values even when the loss rate is quite
high (and so the standard Reno cwnd would be relatively low).

If that's correct then the above sentence doesn't seem quite right.
For example under conditions with high loss rates (e.g. due to non-
congestive loss) it might be possible for the delay component to
dominate CTCP behaviour, although I have seen no studies of this.  It
might be worth checking such scenarios in view of the apparent
importance of the above sentence in the stated case for the safety of
CTCP.

I think it might also be useful to include some discussion (at a
minimum it would at leats be worth highlighting that they aren't
covered by this document) of the following issues:

1. The CTCP delay component operates on the basis of *estimated*
queueing delay.  What is the impact, if any, of errors in the
estimated value ?  Reverse path queueing and errors in baseRTT
estimation spring to mind here as possible issues that could create
estimation errors.    Also, Constantine Dovrolis and others have
already highlighted possible sampling issues when trying to use delay
to infer congestion on heavily multiplexed links where delay may be
only weakly correlated with congestion.

2. Operation over wireless.  I've seen no studies of operation over
802.11 wireless, which is ubiquitous as a last hop.  Since its a
random access technology, there is not necessarily a strong
connection between variations in delay and network queue occupancy (I
have some measurements illustrating this).  The baseRTT also varies
with network load (number of contending stations) at a wireless hop
and this might have implications for estimating queueing delay.

3. Security implications of use of delay.   The use of a new
measurement for congestion control immediately raises concerns about
security.  Can the measurement be spoofed, or otherwise manipulated
to create an advantage ?  Does it create new avenues for denial of
service attack etc ?   If delay is measured via packet time-stamps it
seems pretty likely that a receiver could do all sorts of interesting
things by manipulating the timestamp echoed back to the sender.    I
reckon this can be addressed by using delay measurements derived at
the sender side only (this is now done in Linux for example, and may
well be already done in Vista although I haven't seen it stated
anywhere), but it seems worth a comment and perhaps a little more
thought.

Lastly, I don't know how people fell about this but it might well be
worth prefacing the review with some statement of terms of
reference.  At the moment the review seems to focus on safety and
suitability for release as an experimental RFC.    That's fine but an
obvious question is should there be any comment on performance or
likely benefits to be gained from use of the algorithm ?  If not (and
I guess this will be the case) it might be a good idea to state up
front that analysis of performance benefits is out of scope for this
document, to avoid potential misunderstandings in the future.

Doug

Prof. Douglas Leith
Hamilton Institute
www.hamilton.ie

On 4 Mar 2008, at 16:07, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:

> Attached is a proposed RG review of the Compound TCP draft that we
> were
> asked to consider the safety of for experimental deployment on the
> Internet,
> on behalf of TCPM.
>
> We had several mails on-list about this in recent months, and now that
> discussion has slowed down, I believe we may be ready to close on this
> and submit an official RG review to TCPM.  Please review the attached
> text
> for accuracy, and comment on it.  I drafted it with help from the list
> archives, and believe it captures a consensus that the RG has at a
> high-level.
>
> Replies via email that either support this, or suggest clarifications,
> improvements, or fixes are welcomed at this time.  I also set aside
> time during the Philadelphia meeting that we can use to discuss or
> revise this in real-time face-to-face.  Also, let us know if it is
> wildly inaccurate or doesn't capture your individual concerns at a
> high-level.  Thanks for your help.<ctcp-
> review.txt>_______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

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

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

From: [email-masked] (Michael Welzl)
Date: Wed Mar  5 09:09:33 2008
Subject: [Iccrg] RE: proposed Compound TCP review
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

hm - I just told everyone that one reason for having
the extra meeting in Philly in addition to this one
is that the CTCP authors couldn't come to the one
here in Manchester  :)   well - sorry for that confusion

Zitat von Murari Sridharan <[email-masked]>:

> Thanks Wes for the summary, I am attending the ICCRG meeting at PFLDNet and
> also will be attending IETF in philly, I am hoping to clarify answers to some
> of these questions and also make those changes in the draft and resubmit it.
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Eddy, Wesley M. (GRC-RCN0)[VZ]
> Sent: Tuesday, March 04, 2008 8:08 AM
> To: iccrg
> Subject: [Iccrg] proposed Compound TCP review
>
> Attached is a proposed RG review of the Compound TCP draft that we were asked
> to consider the safety of for experimental deployment on the Internet, on
> behalf of TCPM.
>
> We had several mails on-list about this in recent months, and now that
> discussion has slowed down, I believe we may be ready to close on this and
> submit an official RG review to TCPM.  Please review the attached text for
> accuracy, and comment on it.  I drafted it with help from the list archives,
> and believe it captures a consensus that the RG has at a high-level.
>
> Replies via email that either support this, or suggest clarifications,
> improvements, or fixes are welcomed at this time.  I also set aside time
> during the Philadelphia meeting that we can use to discuss or revise this in
> real-time face-to-face.  Also, let us know if it is wildly inaccurate or
> doesn't capture your individual concerns at a high-level.  Thanks for your
> help.
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

From: [email-masked] (Murari Sridharan)
Date: Tue Mar  4 21:00:50 2008
Subject: [Iccrg] RE: proposed Compound TCP review
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Thanks Wes for the summary, I am attending the ICCRG meeting at PFLDNet and also will be attending IETF in philly, I am hoping to clarify answers to some of these questions and also make those changes in the draft and resubmit it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eddy, Wesley M. (GRC-RCN0)[VZ]
Sent: Tuesday, March 04, 2008 8:08 AM
To: iccrg
Subject: [Iccrg] proposed Compound TCP review

Attached is a proposed RG review of the Compound TCP draft that we were asked to consider the safety of for experimental deployment on the Internet, on behalf of TCPM.

We had several mails on-list about this in recent months, and now that discussion has slowed down, I believe we may be ready to close on this and submit an official RG review to TCPM.  Please review the attached text for accuracy, and comment on it.  I drafted it with help from the list archives, and believe it captures a consensus that the RG has at a high-level.

Replies via email that either support this, or suggest clarifications, improvements, or fixes are welcomed at this time.  I also set aside time during the Philadelphia meeting that we can use to discuss or revise this in real-time face-to-face.  Also, let us know if it is wildly inaccurate or doesn't capture your individual concerns at a high-level.  Thanks for your help.

From: [email-masked] (Murari Sridharan)
Date: Tue Mar  4 20:58:22 2008
Subject: [Iccrg] proposed Compound TCP review
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

For the delay window (scalability component) to kick in following conditions have to be met. CWnd >= roughly 38 packets or 57000 bytes && CWnd >= SsThresh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Douglas Leith
Sent: Tuesday, March 04, 2008 9:02 AM
To: Eddy, Wesley M. (GRC-RCN0)[VZ]
Cc: iccrg
Subject: Re: [Iccrg] proposed Compound TCP review

I'm not so clear about the correctness of the following sentence:

"Compound TCP's design only utilizes the delay-based
component when the loss-rate is low and the congestion window
has been able to grow large already based on the current
Standards Track mechanisms."

As I understand it, the delay based increase action is used whenever
the estimated queueing delay is low.   Since it is a fairly
aggressive increase (similar to HS-TCP) it seems possible that the
delay window can  reach large values even when the loss rate is quite
high (and so the standard Reno cwnd would be relatively low).

If that's correct then the above sentence doesn't seem quite right.
For example under conditions with high loss rates (e.g. due to non-
congestive loss) it might be possible for the delay component to
dominate CTCP behaviour, although I have seen no studies of this.  It
might be worth checking such scenarios in view of the apparent
importance of the above sentence in the stated case for the safety of
CTCP.

I think it might also be useful to include some discussion (at a
minimum it would at leats be worth highlighting that they aren't
covered by this document) of the following issues:

1. The CTCP delay component operates on the basis of *estimated*
queueing delay.  What is the impact, if any, of errors in the
estimated value ?  Reverse path queueing and errors in baseRTT
estimation spring to mind here as possible issues that could create
estimation errors.    Also, Constantine Dovrolis and others have
already highlighted possible sampling issues when trying to use delay
to infer congestion on heavily multiplexed links where delay may be
only weakly correlated with congestion.

2. Operation over wireless.  I've seen no studies of operation over
802.11 wireless, which is ubiquitous as a last hop.  Since its a
random access technology, there is not necessarily a strong
connection between variations in delay and network queue occupancy (I
have some measurements illustrating this).  The baseRTT also varies
with network load (number of contending stations) at a wireless hop
and this might have implications for estimating queueing delay.

3. Security implications of use of delay.   The use of a new
measurement for congestion control immediately raises concerns about
security.  Can the measurement be spoofed, or otherwise manipulated
to create an advantage ?  Does it create new avenues for denial of
service attack etc ?   If delay is measured via packet time-stamps it
seems pretty likely that a receiver could do all sorts of interesting
things by manipulating the timestamp echoed back to the sender.    I
reckon this can be addressed by using delay measurements derived at
the sender side only (this is now done in Linux for example, and may
well be already done in Vista although I haven't seen it stated
anywhere), but it seems worth a comment and perhaps a little more
thought.

Lastly, I don't know how people fell about this but it might well be
worth prefacing the review with some statement of terms of
reference.  At the moment the review seems to focus on safety and
suitability for release as an experimental RFC.    That's fine but an
obvious question is should there be any comment on performance or
likely benefits to be gained from use of the algorithm ?  If not (and
I guess this will be the case) it might be a good idea to state up
front that analysis of performance benefits is out of scope for this
document, to avoid potential misunderstandings in the future.

Doug

Prof. Douglas Leith
Hamilton Institute
www.hamilton.ie

On 4 Mar 2008, at 16:07, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:

> Attached is a proposed RG review of the Compound TCP draft that we
> were
> asked to consider the safety of for experimental deployment on the
> Internet,
> on behalf of TCPM.
>
> We had several mails on-list about this in recent months, and now that
> discussion has slowed down, I believe we may be ready to close on this
> and submit an official RG review to TCPM.  Please review the attached
> text
> for accuracy, and comment on it.  I drafted it with help from the list
> archives, and believe it captures a consensus that the RG has at a
> high-level.
>
> Replies via email that either support this, or suggest clarifications,
> improvements, or fixes are welcomed at this time.  I also set aside
> time during the Philadelphia meeting that we can use to discuss or
> revise this in real-time face-to-face.  Also, let us know if it is
> wildly inaccurate or doesn't capture your individual concerns at a
> high-level.  Thanks for your help.<ctcp-
> review.txt>_______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

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

From: [email-masked] (Eddy, Wesley M. (GRC-RCN0)[VZ])
Date: Tue Mar  4 16:06:32 2008
Subject: [Iccrg] proposed Compound TCP review
Message-ID: <[email-masked]>

Attached is a proposed RG review of the Compound TCP draft that we were
asked to consider the safety of for experimental deployment on the
Internet,
on behalf of TCPM.

We had several mails on-list about this in recent months, and now that
discussion has slowed down, I believe we may be ready to close on this
and submit an official RG review to TCPM.  Please review the attached
text
for accuracy, and comment on it.  I drafted it with help from the list
archives, and believe it captures a consensus that the RG has at a
high-level.

Replies via email that either support this, or suggest clarifications,
improvements, or fixes are welcomed at this time.  I also set aside
time during the Philadelphia meeting that we can use to discuss or
revise this in real-time face-to-face.  Also, let us know if it is
wildly inaccurate or doesn't capture your individual concerns at a
high-level.  Thanks for your help.
-------------- next part --------------
In July 2007, the ICCRG began reviewing the Compound TCP
congestion control technique described in
draft-sridharan-tcpm-ctcp-00 in terms of its safety for
widespread experimental deployment on the public Internet.
This review was conducted as an input to the IETF TCPM
working group, where the draft was being considered for
possible Experimental publication.

Based on initial RG comments, an update to the original
internet-draft was published.  Based on further RG comments,
another update is expected that contains several clarifications
(itemized at the end of this document).  This review assumes
that those changes are made.

After reviewing the draft and a number of other documents
with results from testing and simulation, three public
evaluations were submitted to the ICCRG by RG participants.
Several follow-on messages and comments were submitted by
these and other RG participants.  The RG seems to have
consensus that (given the expected draft clarifications)
the Compound TCP mechanism is safe for experimental deployment
on the public Internet.

Its novelty from the current Standards Track congestion control
techniques is that Compound TCP also contains a delay-based
component.  Compound TCP's design only utilizes the delay-based
component when the loss-rate is low and the congestion window
has been able to grow large already based on the current
Standards Track mechanisms.  This was noted by some reviewers
as a major inspiration of confidence.  The simulation results
and analysis made available were also helpful, but were not found
to be overwhelmingly convincing.

Expected changes from the 01 draft version:

1. Clarify how RTT samples are captured (1323 or some other filter).

2. Clarify definition of baseRTT. (noted by 2 reviewers)

3. Clarify definition of "round" in dwnd update (is it in terms of
   RTT or cwnd worth of packets).

4. What happens to dwnd during slow-start, and when is slow-start
   exited?

5. Clarify dwnd update parameters and specific values or ranges
   that are safe for use (alpha, beta, eta, k)
   (noted by 3 reviewers)

6. Be precise about clipping dwnd so that it cannot become negative

Public reviews from:
Wesley Eddy (Nov 1, 2007)
Mark Allman (Nov 29, 2007)
Doug Leith (Jan 16, 2008)

additionally, several thread comments from:
Lachlan Andrew
Michael Welzl
Dino-Martin Lopez-Pacheco
>From [email-masked]  Tue Mar  4 17:01:58 2008
From: [email-masked] (Douglas Leith)
Date: Tue Mar  4 17:02:15 2008
Subject: [Iccrg] proposed Compound TCP review
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I'm not so clear about the correctness of the following sentence:

"Compound TCP's design only utilizes the delay-based
component when the loss-rate is low and the congestion window
has been able to grow large already based on the current
Standards Track mechanisms."

As I understand it, the delay based increase action is used whenever  
the estimated queueing delay is low.   Since it is a fairly  
aggressive increase (similar to HS-TCP) it seems possible that the  
delay window can  reach large values even when the loss rate is quite  
high (and so the standard Reno cwnd would be relatively low).

If that's correct then the above sentence doesn't seem quite right.   
For example under conditions with high loss rates (e.g. due to non- 
congestive loss) it might be possible for the delay component to  
dominate CTCP behaviour, although I have seen no studies of this.  It  
might be worth checking such scenarios in view of the apparent  
importance of the above sentence in the stated case for the safety of  
CTCP.

I think it might also be useful to include some discussion (at a  
minimum it would at leats be worth highlighting that they aren't  
covered by this document) of the following issues:

1. The CTCP delay component operates on the basis of *estimated*  
queueing delay.  What is the impact, if any, of errors in the  
estimated value ?  Reverse path queueing and errors in baseRTT  
estimation spring to mind here as possible issues that could create  
estimation errors.    Also, Constantine Dovrolis and others have  
already highlighted possible sampling issues when trying to use delay  
to infer congestion on heavily multiplexed links where delay may be  
only weakly correlated with congestion.

2. Operation over wireless.  I've seen no studies of operation over  
802.11 wireless, which is ubiquitous as a last hop.  Since its a  
random access technology, there is not necessarily a strong  
connection between variations in delay and network queue occupancy (I  
have some measurements illustrating this).  The baseRTT also varies  
with network load (number of contending stations) at a wireless hop  
and this might have implications for estimating queueing delay.

3. Security implications of use of delay.   The use of a new  
measurement for congestion control immediately raises concerns about  
security.  Can the measurement be spoofed, or otherwise manipulated  
to create an advantage ?  Does it create new avenues for denial of  
service attack etc ?   If delay is measured via packet time-stamps it  
seems pretty likely that a receiver could do all sorts of interesting  
things by manipulating the timestamp echoed back to the sender.    I  
reckon this can be addressed by using delay measurements derived at  
the sender side only (this is now done in Linux for example, and may  
well be already done in Vista although I haven't seen it stated  
anywhere), but it seems worth a comment and perhaps a little more  
thought.

Lastly, I don't know how people fell about this but it might well be  
worth prefacing the review with some statement of terms of  
reference.  At the moment the review seems to focus on safety and  
suitability for release as an experimental RFC.    That's fine but an  
obvious question is should there be any comment on performance or  
likely benefits to be gained from use of the algorithm ?  If not (and  
I guess this will be the case) it might be a good idea to state up  
front that analysis of performance benefits is out of scope for this  
document, to avoid potential misunderstandings in the future.

Doug

Prof. Douglas Leith
Hamilton Institute
www.hamilton.ie

On 4 Mar 2008, at 16:07, Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:

> Attached is a proposed RG review of the Compound TCP draft that we  
> were
> asked to consider the safety of for experimental deployment on the
> Internet,
> on behalf of TCPM.
>
> We had several mails on-list about this in recent months, and now that
> discussion has slowed down, I believe we may be ready to close on this
> and submit an official RG review to TCPM.  Please review the attached
> text
> for accuracy, and comment on it.  I drafted it with help from the list
> archives, and believe it captures a consensus that the RG has at a
> high-level.
>
> Replies via email that either support this, or suggest clarifications,
> improvements, or fixes are welcomed at this time.  I also set aside
> time during the Philadelphia meeting that we can use to discuss or
> revise this in real-time face-to-face.  Also, let us know if it is
> wildly inaccurate or doesn't capture your individual concerns at a
> high-level.  Thanks for your help.<ctcp- 
> review.txt>_______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Michael Welzl)
Date: Tue Mar  4 06:59:25 2008
Subject: [Iccrg] Preliminary agenda for the next meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <005701c87af0$87bf9ac0$0200a8c0@fun> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 2008-03-03 at 23:55 +0000, Bob Briscoe wrote:
> Michael,
> 
> At 16:31 29/02/2008, Michael Welzl wrote:
> >Bob - regarding your previous email, would you like to give
> >a talk about this stuff in Manchester? It surely would be of interest
> >to the group
> >
> >if so, give me a title and suggested length please.
> 
> Tx for registration & the invite [repeat email for the list].
> 
> Title: Packet Size & Congestion Control
> Time:  20mins (incl Q&A)

Thanks!
I squeezed into the agenda, right after my talk about
the open issues draft. I think that this is a good
position because it fits content-wise, and only cuts the
open discussion down from 1 full hour (too much anyway)
to 40 mins (still a lot):
http://www3.tools.ietf.org/group/irtf/trac/wiki/Agenda08

(ignore the "Agenda.2.doc" attachment - this exists because
I didn't check the "overwrite" box at first and don't seem
to have the rights to delete this file...)

> Background I-D:
> Byte and Packet Congestion Notification
> draft-briscoe-tsvwg-byte-pkt-mark-02.txt
> 
> If this is too late or there's no longer any space in the agenda, 
> just let me know - I'll be preparing the slides tomorrow assuming 
> it's OK. Sorry - this is the first time I've connected to email since Fri.

No worries!

Cheers,
Michael

From: [email-masked] (Bob Briscoe)
Date: Mon Mar  3 23:58:44 2008
Subject: [Iccrg] Preliminary agenda for the next meeting
In-Reply-To: <005701c87af0$87bf9ac0$0200a8c0@fun>
References: <[email-masked]> <[email-masked]> <005701c87af0$87bf9ac0$0200a8c0@fun>
Message-ID: <[email-masked]>

Michael,

At 16:31 29/02/2008, Michael Welzl wrote:
>Bob - regarding your previous email, would you like to give
>a talk about this stuff in Manchester? It surely would be of interest
>to the group
>
>if so, give me a title and suggested length please.

Tx for registration & the invite [repeat email for the list].

Title: Packet Size & Congestion Control
Time:  20mins (incl Q&A)

Background I-D:
Byte and Packet Congestion Notification
draft-briscoe-tsvwg-byte-pkt-mark-02.txt

If this is too late or there's no longer any space in the agenda, 
just let me know - I'll be preparing the slides tomorrow assuming 
it's OK. Sorry - this is the first time I've connected to email since Fri.

Bob

____________________________________________________________________________
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: Mon Mar  3 10:02:00 2008
Subject: [Iccrg] Meeting details
Message-ID: <[email-masked]>

Dear all,

Here are some more details about the forthcoming ICCRG meeting.
I delayed this message a bit because I offered to Bob to
give a talk and wanted to include it here in case he agrees,
but I can't wait forever... if Bob agrees to give a talk,
we will just add it at the very end of the day. Except for this
detail, the agenda at
http://www3.tools.ietf.org/group/irtf/trac/wiki/Agenda08
is finalized.

LOGISTICS:
==========

The meeting will be held at:

University of Manchester
School of Physics and Astronomy (Schuster Building)
Brunswick Street
Manchester. M13 9PL

on Wednesday 5th March 2008

Seminar Room, 3rd Floor of the Schuster Building

The meeting web page is at
http://www3.tools.ietf.org/group/irtf/trac/wiki/Agenda08

The University campus map can be found

http://www.manchester.ac.uk/visitors/travel/maps/.

Schuster Building is No. 54 on the map.

If you are arriving in Manchester by train taxis from
Piccadilly are very frequent and will cost around ?5.00.
Taxis are also available for those travelling from
Manchester Airport at a cost of approximately ?20.

REGISTRATION:
=============

In addition to the speakers in the agenda, the following
people told me that they will attend the meeting:

Filipe Abrantes
Jo?o Ara?jo
Lars Eggert
Michael Scharf
Yehia El Khatib
Tom Petch
Bob Briscoe
Anrnaud Jacquet

If you want to come and can't find your name in this list
or the agenda, please send an email to Anne Morrow
<[email-masked]> and myself. If you forget
to do this and just show up, that will still be okay but
you won't have a name badge.

STREAMING:
==========

A live video/audio feed will be available. 

1.  Open browser and go to the following URL:
http://mcu3.es.net

Ignore sign in name, conference id, pin and stream rate

2. Click on
    "Click here to log in"
    Username: guest

3  Under "User Options" Click on
    View conference list

4. Click on
    7353638

   (this number should be in the list at the time of our meeting -
    if it isn't, stay tuned for messages on the list...)

Some people may have to install Real Player and Quick Player. In a
test that I made with the people on site, Real Player got caught
in a constant-buffering mode, but Quicktime worked for me... you
have a choice on the website, so just try which one works best
for you.

Looking forward to seeing (some of) you in Manchester!
Have a good trip,

Cheers,
Michael