Subject: [Iccrg] ICCRG review of draft-sridharan-tcpm-ctcp-02
From: [email-masked] (Lachlan Andrew)
Date: Thu Dec 18 00:08:34 2008

Greetings Saverio,

That is a good point, but the self-induced losses are similar to
standard TCP for typical buffer sizes.

Although we didn't include specific figures for retransmissions, Fig
9(a) our PFLDnet paper
<http://netlab.caltech.edu/lachlan/abstract/HybridPFLDnet08.pdf>
shows that it shares bandwidth equally with standard TCP, which
implies that it is not introducing more losses than another standard
flow would.

It's mechanism is different from purely loss-based proposals which are
simply more aggressive.  It is aggressive only when there is no
detectable delay.

If the buffer size is less than one or two packets per flow, it may be
slightly more aggressive.  However, if the flows all have low BDPs
then it won't be much more aggressive (i.e., similar retransmission
rate).  Conversely, if they have large BDPs then CTCP will get much
higher throughput than standard TCP, because standard TCP needs a
large buffer when the per-flow BDP is large.

Cheers,
Lachlan

2008/12/18 Saverio Mascolo <[email-masked]>:
> did someone measure goodput and retransmissions? TCPs using a more
> aggressive probing than VJ TCP usually seem to end up - in  good
> cases- with similar goodput but at the expense of larger packet
> retransmissions, which is not good!
> -saverio

-- 
Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew> <http://netlab.caltech.edu/lachlan>
Ph +61 3 9214 4837

From: [email-masked] (Saverio Mascolo)
Date: Wed Dec 17 22:00:17 2008
Subject: [Iccrg] ICCRG review of draft-sridharan-tcpm-ctcp-02
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

did someone measure goodput and retransmissions? TCPs using a more
aggressive probing than VJ TCP usually seem to end up - in  good
cases- with similar goodput but at the expense of larger packet
retransmissions, which is not good!
-saverio

On Wed, Dec 17, 2008 at 10:45 PM, Eddy, Wesley M. (GRC-RCN0)[VZ]
<[email-masked]> wrote:
> Some time ago the IRTF Internet Congestion Control Research Group
> (ICCRG)
> was asked for its position on the safety of the Compound TCP behaviors
> described in draft-sridharan-tcpm-ctcp for Experimental deployment on
> the Internet.  This is part of the process described here:
> http://www.ietf.org/IESG/content/ions/drafts/ion-tsv-alt-cc.txt
>
> Below is the ICCRG review of the Compound TCP draft for input to TCPM.
> The ICCRG process itself resulted in a couple of iterations of the draft
> to clarify portions.  By my understanding, TCPM should now be using the
> review, the updated draft, and TCPM's own discussion and feedback loop
> to
> decide the fate of the CTCP document with the understanding that TCPM
> has a general charter item allowing TCPM WG Experimental specification
> of
> ICCRG-reviewed congestion control proposals (according to the ION
> above).
>
> ---------------------------
> Wes Eddy
> Network & Systems Architect
> Verizon FNS / NASA GRC
> Office: (216) 433-6682
> ---------------------------
>
>
> ICCRG Compound TCP Safety Review
> --------------------------------
>
> 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 (01) to the original (00)
> internet-draft
> was published.  Based on further RG comments, another update (02) was
> published
> and contains several further clarifications.
>
> 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 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.
>
>
> 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.pd
> f
> 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
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

-- 
Prof. Saverio Mascolo
Dipartimento di Elettrotecnica ed Elettronica
Politecnico di Bari
Via Orabona 4
70125 Bari
Italy
Tel. +39 080 5963621
Fax. +39 080 5963410
email:[email-masked]

http://www-dee.poliba.it/dee-web/Personale/mascolo.html

=================================
 This message may contain confidential and/or legally privileged information.
  If you are not the intended recipient of the message, please destroy it.
 Any unauthorized dissemination, distribution, or copying of the material in
 this message, and any attachments to the message, is strictly forbidden.

From: [email-masked] (Eddy, Wesley M. (GRC-RCN0)[VZ])
Date: Wed Dec 17 21:33:03 2008
Subject: [Iccrg] ICCRG review of draft-sridharan-tcpm-ctcp-02
Message-ID: <[email-masked]>

Some time ago the IRTF Internet Congestion Control Research Group
(ICCRG)
was asked for its position on the safety of the Compound TCP behaviors
described in draft-sridharan-tcpm-ctcp for Experimental deployment on
the Internet.  This is part of the process described here:
http://www.ietf.org/IESG/content/ions/drafts/ion-tsv-alt-cc.txt

Below is the ICCRG review of the Compound TCP draft for input to TCPM.
The ICCRG process itself resulted in a couple of iterations of the draft
to clarify portions.  By my understanding, TCPM should now be using the
review, the updated draft, and TCPM's own discussion and feedback loop
to
decide the fate of the CTCP document with the understanding that TCPM
has a general charter item allowing TCPM WG Experimental specification
of
ICCRG-reviewed congestion control proposals (according to the ION
above).

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

ICCRG Compound TCP Safety Review
--------------------------------

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 (01) to the original (00)
internet-draft
was published.  Based on further RG comments, another update (02) was
published
and contains several further clarifications.

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

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.pd
f
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] (Eddy, Wesley M. (GRC-RCN0)[VZ])
Date: Wed Dec 17 20:58:00 2008
Subject: [Iccrg] Rethinking TCP-friendly I-D is now open for contributions
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

To fill in the background on this, Matt gave a presentation
to the ICCRG at IETF 73 in Minneapolis that proposed work
on a set of documents and laid out some background.  The
slides are here:
http://www3.ietf.org/proceedings/08nov/slides/iccrg-3.pdf

The RG participants in the meeting seemed to largely think
the first proposed document was important to work on.  This
was described as a "vision statement", and I was thinking
of it as a "where we are, how we got here, and where we think
we need to go" description with regards to TCP friendliness
concepts and how the IETF (and IRTF) thinks about congestion
control.

When there's a 00 version of the document available, I think
the RG should review it and if the positive response from
Minneapolis isn't overturned by mail-list comments, then it's
intended to become an ICCRG draft.  It would be good to hear
comments on the list in addition to what happened at the
meeting on this topic, and doing the vision statement work
in the ICCRG.

The second proposed document that Matt talked about was on
a testing "is it safe for the Internet?".  In the meeting,
it seemed to me that we decided that we needed to kick this
proposal into the TMRG for consideration as it seems to be
more within their charter than the ICCRG's, but that work
may also somehow be predicated on the vision statement from
the ICCRG, so we should talk about the path for that too, I
think.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Matt Mathis
>Sent: Tuesday, December 09, 2008 5:17 PM
>To: [email-masked]
>Cc: PAPADIMITRIOU Dimitri
>Subject: [Iccrg] Rethinking TCP-friendly I-D is now open for 
>contributions
>
>A Internet Draft framework is now online (see below).  If you 
>are interested 
>in contributing, please pick a section, and fill it out.  If 
>you expect to 
>take some time, you may want to claim your section on the list 
>to minimize any 
>chances for duplicates.
>
>At this stage the best bet would be to just send me (or the list) 
>new paragraphs in plain text.
>
>I am looking for somebody to be "style czar", to copy edit and 
>help keep the 
>style consistent.   This should be somebody with a sharp sense 
>of the English 
>language, or at least sharper than mine :-)
>
>The draft is online at:
>http://staff.psc.edu/mathis/unfriendly/drafts/draft-mathis-iccr
>g-unfriendly-XX.html
>and .txt
>
>You can also get to it from either: 
>http://staff.psc.edu/mathis/unfriendly/ or 
>http://staff.psc.edu/mathis/unfriendly/drafts/ .
>
>Thanks everyone for your help and support!
>--MM--
>-------------------------------------------
>Matt Mathis     http://staff.psc.edu/mathis
>Work:412.268.3319    Home/Cell:412.654.7529
>-------------------------------------------
>Evil is defined by mortals who think they know
>"The Truth" and use force to apply it to others.
>
>_______________________________________________
>Iccrg mailing list
>[email-masked]
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

From: [email-masked] (Matt Mathis)
Date: Tue Dec  9 22:05:51 2008
Subject: [Iccrg] Rethinking TCP-friendly I-D is now open for contributions
Message-ID: <[email-masked]>

A Internet Draft framework is now online (see below).  If you are interested 
in contributing, please pick a section, and fill it out.  If you expect to 
take some time, you may want to claim your section on the list to minimize any 
chances for duplicates.

At this stage the best bet would be to just send me (or the list) 
new paragraphs in plain text.

I am looking for somebody to be "style czar", to copy edit and help keep the 
style consistent.   This should be somebody with a sharp sense of the English 
language, or at least sharper than mine :-)

The draft is online at:
http://staff.psc.edu/mathis/unfriendly/drafts/draft-mathis-iccrg-unfriendly-XX.html
and .txt

You can also get to it from either: http://staff.psc.edu/mathis/unfriendly/ or 
http://staff.psc.edu/mathis/unfriendly/drafts/ .

Thanks everyone for your help and support!
--MM--
-------------------------------------------
Matt Mathis     http://staff.psc.edu/mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.

From: [email-masked] (Matt Mathis)
Date: Thu Dec  4 15:31:32 2008
Subject: [Iccrg] Next steps at relaxing the "TCP-friendly" paradigm.
Message-ID: <[email-masked]>

During my presentation there was consensus for the RG to work on a "Vision 
Statement", which might become a prototype of a new congestion control 
architectural document.

If you are interested in helping, please let me know.

I plan to start the conversation about the draft on the regular RG list. 
However, if this becomes problem, I have a mail list ready to go.

Thansk,
--MM--
-------------------------------------------
Matt Mathis     http://staff.psc.edu/mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.

From: [email-masked] (Saverio Mascolo)
Date: Wed Dec  3 14:39:59 2008
Subject: [Iccrg] Initial value of dwnd
In-Reply-To: <[email-masked]>
References: <D2AA6DF1AEE4404F8D983B68BAC97CD20527805E@ftrdmel3> <[email-masked]>
Message-ID: <[email-masked]>

we have tested newreno (only ietf standard), bic (linux default), cubic and
westwood+ over commercial hsdpa card. we run 3000 experiments (down and up
links).
main results were:
1. similar downlink goodputs but with much more timeouts and packet loss
ratio when using bic/cubic (3 times timeouts and 2 times packet loss ratio)
2. larger rtt experienced when using bic/cubic

also cwnd dynamics do not look great!

more details can be found at:

http://c3lab.poliba.it/index.php/TCP_over_Hsdpa

saverio

On Fri, Nov 14, 2008 at 8:58 AM, denis.collange <
[email-masked]> wrote:

>
> Hello,
>
> We have a question concerning the Compound TCP draft, along the lines of
> point 4 in *
> http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-March/000468.html*<http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-March/000468.html>("4. What happens to dwnd during slow-start, and when is slow-start
> exited?")
>
> The draft states that "dwnd is initialized to zero while the connection is
> in slow start" (p. 6), and then "Delay-based component only kicks in when
> cwnd is larger than some threshold, currently set to 38 packets assuming
> 1500 byte MTU" (p.11).
>
> However, starting from zero, the recursion (3) on p. 7 gives a negative
> value, so that dwnd would always be set to 0. In order for dwmd to be
> positive the initial value needs to be such that:
>
>         alpha*dwnd(t)^k - 1 > 0
> (if dwnd is restricted to integer values a larger initial value might be
> needed depending on how the rounding is done).
>
> Clearly an initial value of 38 does satisfy this requirement but it is not
> clear whether this is the initial value that should be assigned to dwnd
> after slow-start or when the cwnd is larger then the specified threshold (38
> in the draft).
>
> We think that the draft should clearly state the initial value for dwnd
> every time the delay component is activated.  It might also be interesting
> to comment on why the window update function is not the same as in the
> previously published papers about Compound TCP.
>
> Thanks,
>
> Denis and Alberto
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>

-- 
Prof. Saverio Mascolo
Dipartimento di Elettrotecnica ed Elettronica
Politecnico di Bari
Via Orabona 4
70125 Bari
Italy
Tel. +39 080 5963621
Fax. +39 080 5963410
email:[email-masked] <[email-masked]>

http://www-dee.poliba.it/dee-web/Personale/mascolo.html

=================================
This message may contain confidential and/or legally privileged information.
 If you are not the intended recipient of the message, please destroy it.
Any unauthorized dissemination, distribution, or copying of the material in
this message, and any attachments to the message, is strictly forbidden.

-- 
Prof. Saverio Mascolo
Dipartimento di Elettrotecnica ed Elettronica
Politecnico di Bari
Via Orabona 4
70125 Bari
Italy
Tel. +39 080 5963621
Fax. +39 080 5963410
email:[email-masked] <[email-masked]>

http://www-dee.poliba.it/dee-web/Personale/mascolo.html

=================================
This message may contain confidential and/or legally privileged information.
 If you are not the intended recipient of the message, please destroy it.
Any unauthorized dissemination, distribution, or copying of the material in
this message, and any attachments to the message, is strictly forbidden.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20081203/51e25659/attachment.html
>From [email-masked]  Thu Dec  4 04:32:21 2008
From: [email-masked] (Lachlan Andrew)
Date: Thu Dec  4 04:21:17 2008
Subject: [Iccrg] Initial value of dwnd
In-Reply-To: <D2AA6DF1AEE4404F8D983B68BAC97CD20527805E@ftrdmel3>
References: <D2AA6DF1AEE4404F8D983B68BAC97CD20527805E@ftrdmel3>
Message-ID: <[email-masked]>

Greetings Denis,

Since no-one has replied, here's my non-authoritative understanding of this.

2008/11/14 denis.collange <[email-masked]>:
>
> We have a question concerning the Compound TCP draft, along the lines of
> point 4 in http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2008-March/000468.html
> ("4. What happens to dwnd during slow-start, and when is slow-start
> exited?")
>
> The draft states that "dwnd is initialized to zero while the connection is
> in slow start" (p. 6), and then "Delay-based component only kicks in when
> cwnd is larger than some threshold, currently set to 38 packets assuming
> 1500 byte MTU" (p.11).
>
> However, starting from zero, the recursion (3) on p. 7 gives a negative
> value, so that dwnd would always be set to 0. In order for dwmd to be
> positive the initial value needs to be such that:
>
>         alpha*dwnd(t)^k - 1 > 0
> (if dwnd is restricted to integer values a larger initial value might be
> needed depending on how the rounding is done).

I believe the update rule in the draft is wrong.  The INFOCOM paper
used  (wnd)^k  instead of  (dwnd)^k (as you hint below), and I believe
that is what Vista uses.  Under that rule, the initial value of  dwnd
can be zero as stated.

That is the rule used in the Linux re-implementation at
<http://netlab.caltech.edu/lachlan/ctcp/>

Cheers,
Lachlan

> We think that the draft should clearly state the initial value for dwnd
> every time the delay component is activated.  It might also be interesting
> to comment on why the window update function is not the same as in the
> previously published papers about Compound TCP.

-- 
Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew> <http://netlab.caltech.edu/lachlan>
Ph +61 3 9214 4837