Subject: [Iccrg] ctcp review: document quibbles (4 of 4)
From: [email-masked] (Lachlan Andrew)
Date: Fri Nov 30 21:12:22 2007

Greetings Mark,

On 29/11/2007, Mark Allman <[email-masked]> wrote:
>   + Eqn 2: Is 1/(cwnd+dwnd) right?  What if a connection is awnd
>     limited?  Or, not using the entire window?  Seems like this should
>     be FlightSize.

Well spotted, but note that  1/(cwnd+dwnd)  is more conservative than
FlightSize.  If the connection isn't using the full   cwnd+dwnd,
there is a case not to increase it faster than 1/(cwnd+dwnd).

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] (Mark Allman)
Date: Thu Nov 29 23:32:20 2007
Subject: [Iccrg] ctcp review: ipr (2 of 4)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> This is very important to TCPM, but I don't think it impacts ICCRG
> unless there is a possibility that the IPR somehow makes it unsafe to
> the network, which I think is probably quite a stretch, and not what
> you were trying to say, right?

I was not trying to say that IPR makes CTCP unsafe.

It could set up an unfairness in the Internet, perhaps.

(And, I noted that I sent all my comments to the ICCRG list sort of just
because this is where the discussion is right now.)

allman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20071129/768da379/attachment.bin
>From [email-masked]  Thu Nov 29 23:38:29 2007
From: [email-masked] (Mark Allman)
Date: Thu Nov 29 23:34:07 2007
Subject: [Iccrg] ctcp review: big picture issues (3 of 4)
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> Would it be correct to say that we think for a scheme to be called
> "safe for production Internet use" that its parameters need to all be
> accompanied by some particular values or guidance on a range of
> values?

Well, I am not sure if that makes it "unsafe".  But, it makes judging
the safety difficult (at least).

allman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20071129/71f78315/attachment.bin
>From [email-masked]  Fri Nov 30 08:35:51 2007
From: [email-masked] (Murari Sridharan)
Date: Fri Nov 30 08:31:24 2007
Subject: [Iccrg] ctcp review: safety (1 of 4)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I see 3 key asks based on reading the mails, Lachlan has been stressing on some of these as well.

1. The draft is missing standards language (SHOULD, MUST etc)
2. The exact parameters used must be clearly documented as this can skew the fairness/safety implications of the algorithm if arbitrary values are chosen.
3. A better documentation of experiments run, possibly a summary
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Allman
Sent: Thursday, November 29, 2007 10:13 AM
To: [email-masked]
Subject: [Iccrg] ctcp review: safety (1 of 4)

[[ I am sending four notes to the ICCRG list about the C-TCP document
   that I agree to review.  I am just dividing things up along the lines
   of my major points instead of constructing one massive email.  Some
   of these issues are perhaps not germane within the context of the
   RG.  But, the line between what the RG cares about and what the TCPM
   WG cares about are blurry enough in my head that I am sending all my
   comments here for the moment.  If useful, I will repeat them within
   TCPM.

   Also, let me note that this review is from me as an individual and
   does not in any way represent any feelings as TCPM co-chair. ]]

It seems the central question for the RG (if I understand correctly) has to do with the safety of the proposal.  The statement in the draft says:

  Compound TCP has been implemented as an optional component in
  Microsoft Windows Vista. It has been tested and experimented through
  broad Windows Vista beta deployments where it has been verified to
  meet its objectives without causing any adverse impact. The Stanford
  Linear Accelerator Center (SLAC) has also evaluated Compound TCP on
  production links. Based on testing and evaluation done so far, we
  believe Compound TCP is safe to deploy on the current Internet. We
  welcome additional analysis, testing and evaluation of Compound TCP by
  Internet community at large and continue to do additional testing
  ourselves.

I am of a mixed mind as to whether I buy this statement.

  + Just looking at the math in the document I am inclined to buy that
    the scheme is pretty safe.  I like the diff_reno notion as using
    what a Reno connection might plausibly attain as an input into the
    scheme.

  + But, the document gives no sense of the experiments that actually
    show this works out in practice.  I don't think this needs to be a
    research paper that goes into fine-grained details, but the draft
    tries to say "we have good results" without even trying to summarize
    or distill the high-order bits from these results.

    There are references to research papers that give these results.  In
    a later note I will have more to say about these.

So, for safety sake, I sort of buy the analytical stuff and don't buy the experimental stuff.  Since I am muddled and tend to believe reality before math I guess if I had to pick I'd vote that I do not buy the statement above.  That is, I'd rather see a statement that said CTCP was not ready for prime-time, but needs more experimentation before we can make that assessment.

allman

From: [email-masked] ([email-masked])
Date: Thu Nov 29 22:00:21 2007
Subject: [Iccrg] ctcp review: big picture issues (3 of 4)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Thu, Nov 29, 2007 at 01:13:31PM -0500, Mark Allman wrote:
>  
>   - The response function has a bunch of knobs.  But, there is really no
>     guidance on turning those knobs.  Some of the results in the papers
>     referenced do deal with turning those knobs.  But, it seems to me
>     that this is such a key facet of an implementation that the draft
>     needs to help an implementer understand how sensitive those knobs
>     are.  This pertains to the last point.  If the document intends for
>     these to be constants and not knobs (i.e., MUSTs) then this concern
>     at least diminishes quite a bit, if not going away.  But, if these
>     are not supposed to be hard-and-fast then the document really needs
>     to help an implementer understand the impact of various tunings.

Since 3 reviewers have now noted this, it's starting to sound like the
RG is expressing a concern about lightly-documented parameters.  Would
it be correct to say that we think for a scheme to be called "safe for
production Internet use" that its parameters need to all be accompanied
by some particular values or guidance on a range of values?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20071129/ac3325db/attachment.bin
>From [email-masked]  Thu Nov 29 22:18:40 2007
From: [email-masked] (Lachlan Andrew)
Date: Thu Nov 29 22:14:22 2007
Subject: [Iccrg] ctcp review: big picture issues (3 of 4)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On 29/11/2007, [email-masked] <[email-masked]> wrote:
> On Thu, Nov 29, 2007 at 01:13:31PM -0500, Mark Allman wrote:
> Would it be correct to say that we think for a scheme to be called "safe for
> production Internet use" that its parameters need to all be accompanied
> by some particular values or guidance on a range of values?

Yep, I'd vote for that as a requirement.  The range could be specified
as "arbitrary", provided there was a justification that "arbitrary"
values are safe.

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] (Mark Allman)
Date: Thu Nov 29 18:08:54 2007
Subject: [Iccrg] ctcp review: safety (1 of 4)
Message-ID: <[email-masked]>

[[ I am sending four notes to the ICCRG list about the C-TCP document
   that I agree to review.  I am just dividing things up along the lines
   of my major points instead of constructing one massive email.  Some
   of these issues are perhaps not germane within the context of the
   RG.  But, the line between what the RG cares about and what the TCPM
   WG cares about are blurry enough in my head that I am sending all my
   comments here for the moment.  If useful, I will repeat them within
   TCPM.

   Also, let me note that this review is from me as an individual and
   does not in any way represent any feelings as TCPM co-chair. ]]

It seems the central question for the RG (if I understand correctly) has
to do with the safety of the proposal.  The statement in the draft says:

  Compound TCP has been implemented as an optional component in
  Microsoft Windows Vista. It has been tested and experimented through
  broad Windows Vista beta deployments where it has been verified to
  meet its objectives without causing any adverse impact. The Stanford
  Linear Accelerator Center (SLAC) has also evaluated Compound TCP on
  production links. Based on testing and evaluation done so far, we
  believe Compound TCP is safe to deploy on the current Internet. We
  welcome additional analysis, testing and evaluation of Compound TCP by
  Internet community at large and continue to do additional testing
  ourselves.

I am of a mixed mind as to whether I buy this statement.

  + Just looking at the math in the document I am inclined to buy that
    the scheme is pretty safe.  I like the diff_reno notion as using
    what a Reno connection might plausibly attain as an input into the
    scheme.

  + But, the document gives no sense of the experiments that actually
    show this works out in practice.  I don't think this needs to be a
    research paper that goes into fine-grained details, but the draft
    tries to say "we have good results" without even trying to summarize
    or distill the high-order bits from these results.

    There are references to research papers that give these results.  In
    a later note I will have more to say about these.

So, for safety sake, I sort of buy the analytical stuff and don't buy
the experimental stuff.  Since I am muddled and tend to believe reality
before math I guess if I had to pick I'd vote that I do not buy the
statement above.  That is, I'd rather see a statement that said CTCP was
not ready for prime-time, but needs more experimentation before we can
make that assessment.

allman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20071129/8c43908e/attachment.bin
>From [email-masked]  Thu Nov 29 18:13:24 2007
From: [email-masked] (Mark Allman)
Date: Thu Nov 29 18:09:12 2007
Subject: [Iccrg] ctcp review: ipr (2 of 4)
Message-ID: <[email-masked]>

[[ I am sending four notes to the ICCRG list about the C-TCP document
   that I agree to review.  I am just dividing things up along the lines
   of my major points instead of constructing one massive email.  Some
   of these issues are perhaps not germane within the context of the
   RG.  But, the line between what the RG cares about and what the TCPM
   WG cares about are blurry enough in my head that I am sending all my
   comments here for the moment.  If useful, I will repeat them within
   TCPM.

   Also, let me note that this review is from me as an individual and
   does not in any way represent any feelings as TCPM co-chair. ]]

An IPR statement about this draft has been issued and can be slurped
from:

    http://datatracker.ietf.org/ipr/878/

Punch line terms: Reasonable and Non-Discriminatory License to All
Implementers with Possible Royalty/Fee.

We have precedent for turning out TCP-related experimental RFCs that are
encumbered.  I personally remain opposed to encumbered technology
relating to our core protocols---and especially so when the terms are
not defensive in nature.

allman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20071129/9c4235bb/attachment.bin
>From [email-masked]  Thu Nov 29 18:13:31 2007
From: [email-masked] (Mark Allman)
Date: Thu Nov 29 18:09:13 2007
Subject: [Iccrg] ctcp review: big picture issues (3 of 4)
Message-ID: <[email-masked]>

[[ I am sending four notes to the ICCRG list about the C-TCP document
   that I agree to review.  I am just dividing things up along the lines
   of my major points instead of constructing one massive email.  Some
   of these issues are perhaps not germane within the context of the
   RG.  But, the line between what the RG cares about and what the TCPM
   WG cares about are blurry enough in my head that I am sending all my
   comments here for the moment.  If useful, I will repeat them within
   TCPM.

   Also, let me note that this review is from me as an individual and
   does not in any way represent any feelings as TCPM co-chair. ]]

Several big picture sort of things about the document ...

  - The document isn't written using standards language (e.g., MUST,
    SHOULD, etc.).  This causes me some heartburn in the particular case
    of parameter setting.  MUST we set the parameters as you suggest?
    Or, is this guidance?  Or, is it merely an illustration?

  - The response function has a bunch of knobs.  But, there is really no
    guidance on turning those knobs.  Some of the results in the papers
    referenced do deal with turning those knobs.  But, it seems to me
    that this is such a key facet of an implementation that the draft
    needs to help an implementer understand how sensitive those knobs
    are.  This pertains to the last point.  If the document intends for
    these to be constants and not knobs (i.e., MUSTs) then this concern
    at least diminishes quite a bit, if not going away.  But, if these
    are not supposed to be hard-and-fast then the document really needs
    to help an implementer understand the impact of various tunings.

  - As I said in another note, a summary of the experiments would be
    useful.

    But, beyond this, I skimmed through the infocom and pfldnet papers
    (the latter which I read in detail some time back) and I have a
    pretty big problem with the experiments.  The problem is when the
    network is setup with dummynet to induce random losses with some
    probability then these schemes run in a network that does not
    include congestion.  And, I don't understand how *congestion
    control* can be effectively evaluated in the absence of
    *congestion*.  So, 

      + Loss != congestion.  Enough congestion causes loss, for sure.
        But, loss can happen for all sorts of reasons.  And, congestion
        causes more than loss (e.g., increased queue sizes and delays).

      + It somehow seems non-sensical to not have actual congestion with
        actual queue build-up when assessing delay-based congestion
        control.  I am not saying that there was none in the
        experiments, but we are at least led to believe that the queue
        was able to absorb all the congestion.  If that is the case then
        the contention wasn't really all that great.

    For me, all this adds up to being pretty skeptical of the overall
    results that show CTCP to be "better".  

    For sure, CTCP performs better in this environment, but that is to
    be expected because it is more aggressive.  I don't feel like I have
    an accurate sense of the implications of this aggressiveness.

    Further, there is this paper that is perhaps preliminary and perhaps
    about old data, but that shows that congestion window size and delay
    are not correlated.  Every time I think about delay-based congestion
    control I think about this paper.  If there is no correlation in
    real networks (where this data is from) then how is this scheme
    going to work?

      Is the Round-trip Time Correlated with the Number of Packets in
      Flight?
      Saad Biaz, Auburn University
      Nitin H. Vaidya, University of Illinois at Urbana-Champaign 
      Internet Measurement Conference, 2003

allman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20071129/399e2c50/attachment.bin
>From [email-masked]  Thu Nov 29 18:13:35 2007
From: [email-masked] (Mark Allman)
Date: Thu Nov 29 18:09:15 2007
Subject: [Iccrg] ctcp review: document quibbles (4 of 4)
Message-ID: <[email-masked]>

[[ I am sending four notes to the ICCRG list about the C-TCP document
   that I agree to review.  I am just dividing things up along the lines
   of my major points instead of constructing one massive email.  Some
   of these issues are perhaps not germane within the context of the
   RG.  But, the line between what the RG cares about and what the TCPM
   WG cares about are blurry enough in my head that I am sending all my
   comments here for the moment.  If useful, I will repeat them within
   TCPM.

   Also, let me note that this review is from me as an individual and
   does not in any way represent any feelings as TCPM co-chair. ]]

Small comments:

  + Sec 1: What is a "mixed network environment"?  I think from the
    context following this I understand it, but I suggest spelling out
    what you mean.

  + Sec 1: "indicator of congestion," --> "indicator of congestion
    (i.e., queue build-up),"

  + Very end of section 2: drop rate of 10^-3 with what RTT?  Also, by
    "TCP." I think you mean "Standard TCP."

  + Sec 3: "in one RTT." --> "to be injected into the network in one
    RTT."

  + Eqn 2: Is 1/(cwnd+dwnd) right?  What if a connection is awnd
    limited?  Or, not using the entire window?  Seems like this should
    be FlightSize.

  + Sec 3: "during slow start." --> "during slow start as Standard TCP."

  + Sec 3: "trip delay seen by a packet over" --> "trip delay observed"
    (packets do not experience round trips; they only go one way)

  + Sec 3: The calculation of "expected", etc. assumes "wnd" is fully
    utilized.

  + Some intuition behind the constants chosen would be useful.

  + I don't think [CTCPI06] is normative.  (Or, at least should be.)

allman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20071129/dd363ae5/attachment.bin
>From [email-masked]  Thu Nov 29 21:59:49 2007
From: [email-masked] ([email-masked])
Date: Thu Nov 29 21:56:47 2007
Subject: [Iccrg] ctcp review: ipr (2 of 4)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Thu, Nov 29, 2007 at 01:13:24PM -0500, Mark Allman wrote:
>  
> An IPR statement about this draft has been issued and can be slurped
> from:
> 
>     http://datatracker.ietf.org/ipr/878/
> 
> Punch line terms: Reasonable and Non-Discriminatory License to All
> Implementers with Possible Royalty/Fee.
> 
> We have precedent for turning out TCP-related experimental RFCs that are
> encumbered.  I personally remain opposed to encumbered technology
> relating to our core protocols---and especially so when the terms are
> not defensive in nature.

This is very important to TCPM, but I don't think it impacts ICCRG
unless there is a possibility that the IPR somehow makes it unsafe
to the network, which I think is probably quite a stretch, and not
what you were trying to say, right?

From: [email-masked] (Lachlan Andrew)
Date: Wed Nov 21 22:43:12 2007
Subject: [Iccrg] review of Compound TCP draft
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Doug,

On 21/11/2007, Douglas Leith <[email-masked]> wrote:
> How about if the spoofing makes the base delay look higher e.g. by
> tinkering with tcp timestamps.   Would that mean the estimated queue
> delay would be too low and so make a flow more aggressive ?

Good suggestion.  I don't think that *changing* the timestamp would
help (it is normally too coarse to use for queue estimation, and
messes with PAWS), but you could use it to estimate the one-way delay,
and then pace out the ACKs to pretend there was no forward queueing
delay.

You'd have to account for clock drift.  Perhaps you could start by
deliberately having very long delays (like 1s), and gradually reducing
them over time.

There's lots of fun to be had.  I don't think any of it would bring
enough benefit to the user to be a dangerous exploit, but worth
looking into.

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] ([email-masked])
Date: Wed Nov 21 21:23:23 2007
Subject: [Iccrg] review of Compound TCP draft
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked] osoft.com> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, Nov 21, 2007 at 12:52:30PM -0800, Lachlan Andrew wrote:
> 
> On 21/11/2007, Murari Sridharan <[email-masked]> wrote:
> > "One thought, that might be fruitless:  Given the delay-based component,
> > is CTCP increasingly vulnerable to ACK-spoofing attacks in comparison
> > to normal TCP?"
> >
> > Can you clarify the exact attack here. Are you suggesting that if somebody (in the middle) can inject ACKs in the window it might make things worse since our RTT samples are skewed to be much smaller and as a result we might increase aggressively thinking there is no congestion? If so why is this a problem only to delay based algorithms I think any high-speed algorithm that is ack clocked is equally vulnerable.
> 
> I think Wes's concern is that the algorithm might be fooled into
> thinking there is less queueing delay, and hence increase the window
> faster.  Purely loss-based algorithm will not increase their windows
> faster based on their estimate of the queueing, and so are less
> sensitive.  (Of course, proxies which reduce the RTT can still
> increase the throughput of loss-based algorithms.)
> 
> I think that the algorithm is OK, because spoofing ACKs is likely to
> make the estimated *base* RTT lower, which makes *all* other delays
> seem to be delayed.  Thus an attacker would be likely to get a lower
> overall rate by spoofing ACKs.  It is a good point and should be
> mentioned in the draft as a point for investigation, since my "thought
> experiment" is not conclusive.
> 

Yeah, I think this is basically where I was going, though I didn't (and
still haven't) really thought about it carefully :) ... Just to be
clear, I wasn't necessarily posing an actual concern needing to be
addressed, just asking a "what if" question with regards to
ack-spoofing.  The topic is actually larger than CTCP.  We understand
how ack spoofing affects congestion controllers based on either number
of segments or bytes acked (e.g. [1], and others), but maybe there's
interesting research in how it affects controllers that use delay as an
input?  I don't know myself, and it may turn out to be
not-so-interesting at all ...

[1] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson,
    "TCP Congestion Control With a Misbehaving Receiver", ACM
    Computer Communication Review, 29(5), October 1999.

From: [email-masked] (Douglas Leith)
Date: Wed Nov 21 21:06:34 2007
Subject: [Iccrg] review of Compound TCP draft
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

How about if the spoofing makes the base delay look higher e.g. by  
tinkering with tcp timestamps.   Would that mean the estimated queue  
delay would be too low and so make a flow more aggressive ?

Doug

Hamilton Institute
www.hamilton.ie

On 21 Nov 2007, at 20:52, Lachlan Andrew wrote:

> Greetings Murari
>
> On 21/11/2007, Murari Sridharan <[email-masked]> wrote:
>> "One thought, that might be fruitless:  Given the delay-based  
>> component,
>> is CTCP increasingly vulnerable to ACK-spoofing attacks in comparison
>> to normal TCP?"
>>
>> Can you clarify the exact attack here. Are you suggesting that if  
>> somebody (in the middle) can inject ACKs in the window it might  
>> make things worse since our RTT samples are skewed to be much  
>> smaller and as a result we might increase aggressively thinking  
>> there is no congestion? If so why is this a problem only to delay  
>> based algorithms I think any high-speed algorithm that is ack  
>> clocked is equally vulnerable.
>
> I think Wes's concern is that the algorithm might be fooled into
> thinking there is less queueing delay, and hence increase the window
> faster.  Purely loss-based algorithm will not increase their windows
> faster based on their estimate of the queueing, and so are less
> sensitive.  (Of course, proxies which reduce the RTT can still
> increase the throughput of loss-based algorithms.)
>
> I think that the algorithm is OK, because spoofing ACKs is likely to
> make the estimated *base* RTT lower, which makes *all* other delays
> seem to be delayed.  Thus an attacker would be likely to get a lower
> overall rate by spoofing ACKs.  It is a good point and should be
> mentioned in the draft as a point for investigation, since my "thought
> experiment" is not conclusive.
>
> 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
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Lachlan Andrew)
Date: Wed Nov 21 20:49:54 2007
Subject: [Iccrg] review of Compound TCP draft
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Murari

On 21/11/2007, Murari Sridharan <[email-masked]> wrote:
> "One thought, that might be fruitless:  Given the delay-based component,
> is CTCP increasingly vulnerable to ACK-spoofing attacks in comparison
> to normal TCP?"
>
> Can you clarify the exact attack here. Are you suggesting that if somebody (in the middle) can inject ACKs in the window it might make things worse since our RTT samples are skewed to be much smaller and as a result we might increase aggressively thinking there is no congestion? If so why is this a problem only to delay based algorithms I think any high-speed algorithm that is ack clocked is equally vulnerable.

I think Wes's concern is that the algorithm might be fooled into
thinking there is less queueing delay, and hence increase the window
faster.  Purely loss-based algorithm will not increase their windows
faster based on their estimate of the queueing, and so are less
sensitive.  (Of course, proxies which reduce the RTT can still
increase the throughput of loss-based algorithms.)

I think that the algorithm is OK, because spoofing ACKs is likely to
make the estimated *base* RTT lower, which makes *all* other delays
seem to be delayed.  Thus an attacker would be likely to get a lower
overall rate by spoofing ACKs.  It is a good point and should be
mentioned in the draft as a point for investigation, since my "thought
experiment" is not conclusive.

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] (Murari Sridharan)
Date: Wed Nov 21 20:25:02 2007
Subject: [Iccrg] review of Compound TCP draft
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Thanks for taking time to review. I'll revise draft based on input from you and Lachlan. I see your point on the usefulness of the implementation section I will try and strengthen it better with details on how we decide how many samples to take etc.

"One thought, that might be fruitless:  Given the delay-based component,
is CTCP increasingly vulnerable to ACK-spoofing attacks in comparison
to normal TCP?"

Can you clarify the exact attack here. Are you suggesting that if somebody (in the middle) can inject ACKs in the window it might make things worse since our RTT samples are skewed to be much smaller and as a result we might increase aggressively thinking there is no congestion? If so why is this a problem only to delay based algorithms I think any high-speed algorithm that is ack clocked is equally vulnerable.

Thanks
Murari

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, November 01, 2007 8:22 AM
To: [email-masked]
Subject: [Iccrg] review of Compound TCP draft

Here is a review I did of the Compound TCP draft, submitted just as a
normal participant in the group (not as co-chair), of the recently
submitted draft version (draft-sridharan-tcpm-ctcp-01).

Short Review:

The document's intended status is Experimental, for use on the open
Internet.  Based on looking at both the draft and several other
references, I think this is appropriate.  However, the draft on its own
may not have enough information on the exact parameter values (or
ranges) that should be used as guidance to implementers.  I specifically
refer to the dwnd formula on page 7; gamma is discussed at some length,
but alpha, beta, eta, and k are less well explained.  Since I believe
the authors can easily fix this in an updated draft by discussing the
particular values used in their implementations (which have shown
themselves to be very safe, in my opinion), I think this is a rather
minor issue.

Longer Review:

1) minor/editorial comment, in the abstract:

I know what is meant, but the phrase "gracefully reduces" is not quite
right, I think.  It might be better as "proactively reduces".

2) minor/editorial comment:

There's a missing linebreak between the last paragraph of the Introduction
and the heading for "2. Design Goals" at the top of page 5.

3) minor/editorial in section 2:

"the network resource and" -> "the network's resources and" ?

4) in section 2:

The logic is incomplete behind saying HSTCP "is now an experimental IETF
RFC" and using that alone to justify basing CTCP's agressiveness on
HSTCP.  I believe, what you want to say is that HSTCP hasn't been known
to exhibit severe issues in deployment or testing experiences, and
*that's* what makes it a reasonable baseline, NOT that it's an RFC.

5) minor/editorial in section 3:

"the delay component is effective" ->
"the delay component is only activated" ?

6) clarity in section 3 on basertt:

"It is continually measured and updated to track changing network
conditions."

I think you should say something more like it tracks the minimum RTT
sample observed over the course of the connection, or something more
specific than the current sentence alone?

7) "actual" throughput in section 3:

Since this is computed based on SRTT (an estimate itself from the
EWMA), is this really "actual", or "estimated actual" ... not overly
important, just a matter of confusion on my part.

8) clarity in section 3 on dwnd parameters:

Need more data on values/ranges for alpha, beta, eta, and k, I think.
It seems possible that poor selections could influence CTCP's
friendliness, though I have not analyzed this.

9) section 5 - windows measured in bytes, not packets

There is much discussion of window components in terms of packets in
this section: "estimating the backlogged packets", "30 packets", etc. in
this section.  There needs to be some mention of conversion between
number of packets and number of bytes, since the window is in bytes (say
based on MSS).  A couple of sentences could clarify this.

10) praise:

Section 6 on "implementation issues" is excellent, and a good addition,
even though it might not be strictly needed to understand the protocol.
It may be somewhat proprietary, but I think it would be helpful if you
could give just slightly more information on the number of RTT samples
that's kept.  I'm curious whether poor tuning of this could
significantly influence performance or fairness, and since I believe
your implementation to be quite well-behaved, it's a good basis for
others to parameterize from.

11) section 7: bytes/packets

"Only when the congestion window is greater than 38 packets" should
be 38 MSS ?

12) Security Considerations

One thought, that might be fruitless:  Given the delay-based component,
is CTCP increasingly vulnerable to ACK-spoofing attacks in comparison
to normal TCP?

13) references

Should the INFOCOM paper be normative?

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

From: [email-masked] (Murari Sridharan)
Date: Wed Nov 21 20:31:50 2007
Subject: [Iccrg] RE: updated CTCP draft
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Good points I'll add appropriate bounds for the constants and also clarify how dwnd stays positive.

-----Original Message-----
From: Lachlan Andrew [mailto:[email-masked]]
Sent: Tuesday, November 20, 2007 7:57 PM
To: Murari Sridharan; iccrg IRTF list
Subject: Re: updated CTCP draft

Greetings Murari,

I've finally started reading your draft -- sorry for the delay.

I'll get back to you once I've read it properly, but here are a couple
of preliminary points:

- I don't think it can be declared "safe" yet, since the "Control Law"
section doesn't specify  alpha.  A later section says "we use
alpha=1/8", but the draft doesn't say that that is part of the
*requirements* of the algorithm.  I could implement this with
alpha=10000 and claim that it satisfies the protocol description.  If
you want to say these parameters are tunable, you might want to
specify a range in which they can be varied, and specify a "default"
value in the algorithm description.

- Someone recommended using MUST, SHOULD, RECOMMENDED, MAY etc
according to the normal practice for normative RFCs.  I'd say you
"SHOULD" do that (you don't have to if there is a good reason not to,
but otherwise please do it).

- It seems that  dwnd  can become negative if diff<gamma.  In
particular,  if  dwnd(t)=0, then  dwnd(t+1) = -1.  Is that what you
mean?  In an RFC, I believe it is important to be very precise about
things like clipping.

- I'd much rather see a separation of  algorithm/implementation  from
justification/motivation.  As one of many examples, discussion of
fairness doesn't (to me) belong in the section defining the algorithm.
 This will also make clearer whether "automatic setting of gamma" is
part of the algorithm or not.  Unlike the other points, this doesn't
affect whether or not it is "safe", so it is up to you, but I think it
will make the document much easier to use.

Cheers,
Lachlan

On 30/10/2007, Murari Sridharan <[email-masked]> wrote:
>
> Lachlan you must have seen my mail to iccrg on the updated draft, this had a
> few more cosmetic changes, some more cleanups than the doc I sent out, but
> from a technical stand point it's the same.
>
> http://www.ietf.org/internet-drafts/draft-sridharan-tcpm-ctcp-01.txt
>
> Thanks

--
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 Nov 21 04:04:30 2007
Subject: [Iccrg] Re: updated CTCP draft
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Greetings Murari,

I've finally started reading your draft -- sorry for the delay.

I'll get back to you once I've read it properly, but here are a couple
of preliminary points:

- I don't think it can be declared "safe" yet, since the "Control Law"
section doesn't specify  alpha.  A later section says "we use
alpha=1/8", but the draft doesn't say that that is part of the
*requirements* of the algorithm.  I could implement this with
alpha=10000 and claim that it satisfies the protocol description.  If
you want to say these parameters are tunable, you might want to
specify a range in which they can be varied, and specify a "default"
value in the algorithm description.

- Someone recommended using MUST, SHOULD, RECOMMENDED, MAY etc
according to the normal practice for normative RFCs.  I'd say you
"SHOULD" do that (you don't have to if there is a good reason not to,
but otherwise please do it).

- It seems that  dwnd  can become negative if diff<gamma.  In
particular,  if  dwnd(t)=0, then  dwnd(t+1) = -1.  Is that what you
mean?  In an RFC, I believe it is important to be very precise about
things like clipping.

- I'd much rather see a separation of  algorithm/implementation  from
justification/motivation.  As one of many examples, discussion of
fairness doesn't (to me) belong in the section defining the algorithm.
 This will also make clearer whether "automatic setting of gamma" is
part of the algorithm or not.  Unlike the other points, this doesn't
affect whether or not it is "safe", so it is up to you, but I think it
will make the document much easier to use.

Cheers,
Lachlan

On 30/10/2007, Murari Sridharan <[email-masked]> wrote:
>
> Lachlan you must have seen my mail to iccrg on the updated draft, this had a
> few more cosmetic changes, some more cleanups than the doc I sent out, but
> from a technical stand point it's the same.
>
> http://www.ietf.org/internet-drafts/draft-sridharan-tcpm-ctcp-01.txt
>
> Thanks

-- 
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] (Lars Eggert)
Date: Mon Nov 12 10:27:58 2007
Subject: [Iccrg] Re: [tsv-area] bringing experimental congestion control to the IETF
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 2007-11-9, at 15:42, ext Lars Eggert wrote:
> Related to my note from this spring, I'd like to note that the  
> Linux kernel developers have chosen to again make standard TCP  
> NewReno the default congestion control mechanism in kernel 2.6.23.

Apparently, I was misinformed. The config file default is still  
CUBIC, but depending on how the kernel is compiled, i.e., whether  
some or all TCP variants are compiled as modules or not, other  
variants can end up being the boot-time default.

Lars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20071112/69c522eb/smime.bin
>From [email-masked]  Fri Nov 16 15:19:36 2007
From: [email-masked] (Michael Welzl)
Date: Fri Nov 16 15:25:22 2007
Subject: [Iccrg] CFP: Elsevier FGCS special section on Networks for Grid
	Applications
Message-ID: <[email-masked]>

Hi all,

I thought this might interest you, as there is some work on
highspeed-tcp's done in the context of Grid networking
(e.g. UDT)...

cheers,
Michael

---

Call for Papers
Elsevier Future Generation Computer Systems

The International Journal of Grid Computing:
Theory, Methods and Applications

Special Section on Networks for Grid Applications

Grid developers and practitioners are increasingly realising the
importance of an efficient network support. Entire classes of
applications would greatly benefit from a network-aware Grid middleware,
able to effectively manage the network resource in terms of scheduling,
access and use. Conversely, the peculiar requirements of Grid
applications provide stimulating drivers for new challenging research
towards the development of Grid-aware networks.

Cooperation between Grid middleware and network infrastructure driven by
a common control plane is a key factor to effectively empower the global
Grid platform for the execution of network-intensive applications,
requiring massive data transfers, very fast and low-latency connections,
and stable and guaranteed transmission rates. Big e-science projects, as
well as industrial and engineering applications for data analysis, image
processing, multimedia, or visualisation just to name a few are awaiting
an efficient Grid network support. They would be boosted by a global
Grid platform enabling end-to-end dynamic bandwidth allocation,
broadband and low-latency access, interdomain access control, and other
network performance monitoring capabilities.

As a natural extension of the discussion forum provided by the GridNets
conference series, this special section aims at gathering top-quality
contributions to the most debated topics currently tackled in Grid
networking research. Topics include, but are not limited to:

* Network architectures and technologies for grids
* The network as a first class Grid resource: network resource
information publication, brokering and co-scheduling with other Grid
resources
* Interaction of the network with distributed data management systems
* Network monitoring, traffic characterisation and performance analysis
* Inter-layer interactions: optical layer with higher layer protocols,
integration among layers
* Experience with pre-production Grid network infrastructures and
exchange points
* Peer-to-peer network enhancements applied to the Grid
* Network support for wireless and ad hoc grids
* Data replication and multicasting strategies and novel data transport
protocols
* Fault-tolerance, self healing networks
* Security and scalability issues when connecting a large number of
sites within a virtual organization VPN
* Simulations
* New concepts and requirements which may fundamentally reshape the
evolution of Networks
* Integration of advanced optical networking technologies into the Grid
environment
* End to end lightpath provisioning software systems and emergent
standards

Submission of Papers
====================

The submitted papers should present original work that should not have
been published or be under review elsewhere. Papers concerning works
presented at the Gridnets 2007 conference can be submitted, provided
that new and original results are included. The submitted paper must be
formatted according to the formatting rules of the FGCS
(http://www.elsevier.com/locate/fgcs). Please follow the FGCS guidelines
for more information on paper submission, at 
http://www.elsevier.com/framework_products/promis_misc/gfafuture.pdf

The files should be submitted through the website
http://ees.elsevier.com/fgcs/

Please register at the website and upload editable source files for
manuscript and figures, selecting the article type:
SS: GRIDNETS 2007 - Spinnato

Also include vitae (short biographies and photographs) for all authors.
The system will then prepare a pdf file for approval. When the
?approval? button is clicked, the paper will be submitted.

Please include a cover page which lists the following:

* Title of paper
* Name and affiliation of corresponding author.
* Address and e-mail address of each author.
* Name and affiliation of all authors.
* Address and e-mail address of corresponding author.
* Abstract of paper.
* A maximum of 5 keywords.

Important Dates
===============

Deadline for paper submission: 9 December 2007 
Notification of decision: 31 January 2008 
Revised paper due: 31 March 2008
Publication: to be determined

Guest Editors
=============

Pascale Vicat-Blanc Primet ([email-masked]), INRIA, ENS-Lyon
Michael Welzl ([email-masked]), University of Innsbruck
Piero Spinnato ([email-masked]), LNGS - INFN 
Chris Edwards ([email-masked]), Lancaster University

From: [email-masked] (Lars Eggert)
Date: Fri Nov  9 23:41:09 2007
Subject: [Iccrg] Re: [tsv-area] bringing experimental congestion control to the IETF
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 2007-3-12, at 1:06, Lars Eggert wrote:
> Several widely-deployed operating systems already implement non-RFC- 
> compliant congestion control mechanisms. This is happening without  
> much community review and often without a publicly available  
> technical specification, which is troubling.

Related to my note from this spring, I'd like to note that the Linux  
kernel developers have chosen to again make standard TCP NewReno the  
default congestion control mechanism in kernel 2.6.23.

http://www-didc.lbl.gov/TCP-tuning/linux.html

Lars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20071109/68c5a119/smime.bin
>From [email-masked]  Mon Nov 12 07:13:36 2007
From: [email-masked] (Michael Welzl)
Date: Mon Nov 12 07:11:20 2007
Subject: [Iccrg] [Fwd: CFP: PFLDNET2008 Protocols for very long distance
 high speed networks]
Message-ID: <[email-masked]>

FYI
Note that this is co-located with the next ICCRG meeting (on
3-4 March 2008 at the same place).

Cheers,
Michael

> 
>                            CALL FOR PAPERS 
> 
>                              PFLDNET2008
> 
>  
> 
>                                    
> 
>                    Sixth International Workshop on
> 
>               Protocols for FAST Long-Distance Networks
> 
>                             5-7 March 2008
> 
>         The Schuster Building, The University of Manchester, UK
> 
>                                    
> 
>              http://www.hep.man.ac.uk/PFLDnet2008/cfp.php
> 
>                                    
> 
>                                    
> 
> Important Dates
> 
> Initial Abstract submission:
> 
> 
> Monday 10 December, 2007
> 
> 
> Notification of acceptance:
> 
> 
> Monday 14 January, 2008
> 
> 
> Early (discounted) Registration:
> 
> 
> Monday 4 February, 2008
> 
> 
> Final paper submission:
> 
> 
> Friday 22 February, 2008
> 
> 
> Workshop:
> 
> 
> Wednesday, Thursday, Friday, 
> 
> 5 to 7 March, 2008
> 
> 
> 
>                                    
> 
>              -------------------------------------------
> 
> With the emergence of hybrid network facilities, future networks will
> increasingly contain high bandwidth, high delay paths. Protocols for
> fast, long distance networks will have to expand from experimental
> testbeds and into the wider world. In that process, it is increasingly
> important for protocols which achieve high utilization on fast, long
> distance networks also to have the qualities required for widespread
> use, such as fairness and scalability to many users.
> 
>  
> 
> The goal of the International Protocols for Fast Long-Distance
> Networks workshop series is to bring together researchers and
> practitioners from all continents in this area to exchange ideas and
> experience. This single-track workshop will provide researchers and
> technologists with a focused, highly interactive opportunity to
> present, discuss and exchange experience on leading research,
> development and future directions in high performance transport and
> application protocols over fast long-distance networks.
> 
> In order to facilitate discussions, attendance will be limited to 60
> participants. Please register early to ensure your participation.
> Depending on the number of people who register, we may need to
> restrict the number of people from a given organization to allow for a
> broader representation of the research community. Registration will
> open on 8 October 2008.
> 
> PFLDnet2008 solicits papers which will further research on protocols
> for tomorrow's high speed Internet, at all stages along the continuum
> from the requirements of today's Grid networks, through optical
> transports, throughbenchmarking of proposals, to the selection of the
> next generation of TCP and other transport protocols.
> 
> Participants wishing to present a paper should upload a four-page
> extended abstact to the submission site by Monday 10 December 2007.
> Final papers should be typically 4-5 pages, but no longer than 6
> pages.
> 
> Scope: (choose at least one of the subject areas below - multiple
> selections are possible)
> 
> Protocol issues in fast long-distance networks:
> 
> Protocol development
> 
> Enhancements of TCP and its variants
> 
> Novel data transport protocols designed for new Networks and
> Application Services
> 
> Explicit signaling protocols: Optimization criteria and deployment
> strategies
> 
> Pacing and shaping of TCP and UDP traffic
> 
> Parallel transfers and multistreaming
> 
> Performance evaluation
> 
> Modeling and simulation-based results
> 
> Experiments on real networks and actual measurements
> 
> Protocol benchmarking
> 
> Hardware-specific issues
> 
> Transport over optical networks
> 
> Protocol implementation and hardware issues (PCs, NICs, TOEs, routers,
> switches, etc.)
> 
> End system performance
> 
> Data replications and striping
> 
> RDMA over WANs
> 
> Application focus
> 
> Requirements and experience from applications with demanding network
> performance requirements 
> 
> Bulk-data transfer applications both TCP and non-TCP based
> 
> Transport service for Grids
> 
> QoS and scalability issues
> 
> Multicast over fast long-distance networks
> 
> Fiber To The Home (FTTH)
> 
>  
> 
> Authors whose papers are selected for presentation will have the
> option to submit a revised paper, to be published on the PFLDnet 2008
> web site and in the PFLDnet 2008 proceedings. We propose to collect
> the best papers from PFLDnet 2008 and make a joint publication with
> those from PFLDnet 2007 in a special edition of a journal, if the
> authors are interested.
> 
>  
> 
> COMMITTEES
> 
> Co-Chairs:
> 
> Richard Hughes-Jones (Manchester - UK) 
> 
> Pascale Vicat-Blanc Primet (INRIA - FR)
> 
> Steering Committee:
> 
> Lachlan Andrew (Caltech - USA)
> 
> Tomohiro Kudoh (AIST - JP) 
> 
> Michael Welzl (University of Innsbruck - AT)
> 
> 
> Technical Program Committee:
> 
> Michael Welzl (University of Innsbruck - AT) (Co-chair)
> 
> Bill Allcock (Argonne - USA) 
> 
> Eitan Altman (INRIA - FR)
> 
> Lachlan Andrew (Caltech - USA)
> 
> Chadi Barakat (INRIA - FR) 
> 
> Richard Carlson (Internet2 - USA)
> 
> Jean-Laurent Costeux (Orange - FR)
> 
> Dirceu Cavendish (KIT - JP)
> 
> Les Cottrell (SLAC - USA) 
> 
> Michel Diaz (LAAS - FR)
> 
> Larry Dunn (Cisco - USA) 
> 
> Lars Eggert (NEC - DE)
> 
> Ted Faber (ISI - USA)
> 
> Wu-Chun Feng (Virginia Tech - USA)
> 
> Sally Floyd (ICIR - USA)
> 
> Paola Grosso (University of Amsterdam- NL)
> 
> Go Hasegawa (Osaka University - JP)
> 
> Richard Hughes-Jones (Manchester - UK) (Co-chair)
> 
> Dina Katabi (MIT - USA) 
> 
> Katsushi Kobayashi (NICT - JP)
> 
> Tomohiro Kudoh (AIST - JP)
> 
> Cees de Laat (University of Amsterdam - NL)
> 
> Jason Leigh (EVL - USA) 
> 
> Doug Leith (Hamilton Institute - IE) (Co-chair)
> 
> Steven Low (caltech - USA) 
> 
> Saverio Mascolo (University of Bari - IT)
> 
> Masayuki Murata (Osaka University - JP)
> 
> Anders Persson (SUN - USA) 
> 
> Balakrishna Prabhu (CWI -NL) 
> 
> Injong Rhee (North Carolina State University - USA) 
> 
> Hideyuki Shimonishi (NEC - JP)
> 
> Dimitra Simeonidou (Essex - UK) 
> 
> Martin Swany (Delaware - US) 
> 
> Robin Tasker (Daresbury Lab - UK)
> 
> Brian Tierney (Lawrence Berkeley Laboratories - USA)
> 
> Pascale Vicat-Blanc Primet (INRIA - FR) (Co-chair)
> 
> David X. Wei (Caltech - USA)
> 
> Wesley Eddy (NASA -USA) 
> 
> Local Arrangements:
> 
> Anne Morrow (Manchester - UK)
> 
> Stephen Kershaw (Manchester - UK)
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  

From: [email-masked] (Michael Welzl)
Date: Fri Nov  9 07:55:49 2007
Subject: [Iccrg] Re: [Tmrg] slides for Sally's discussion at the CalTach meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

These slides are great!

I think that, while it's now common to include at least
one or two TCP-friendliness tests based on one scenario
in studies about high speed CC variants, there is still
too little focus in most current work on the impact that
such mechanisms have on other traffic (and therefore
I'm cc'ing ICCRG  :-)  ).

Cheers,
Michael

On Thu, 2007-11-08 at 11:44 -0800, Sally Floyd wrote:
> http://www.icir.org/floyd/talks/impactOfNewCC.ppt
> 
> - Sally
> http://www.icir.org/floyd/
> 
> _______________________________________________
> Tmrg-interest mailing list
> [email-masked]
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest

From: [email-masked] (Sally Floyd)
Date: Tue Nov  6 22:01:55 2007
Subject: [Iccrg] Re:
In-Reply-To: <000601c82064$8f339540$723bccc1@HPSM>
References: <000601c82064$8f339540$723bccc1@HPSM>
Message-ID: <[email-masked]>

Saverio -

> what do you mean by "different level of congestion"?

Include "uncongested" scenarios, e.g., with low levels
of link utilization.  And include highly "congested" scenarios,
with high levels of link utilization and a range of packet
dropping and/or marking rates.

With the "different levels of congestion" produced by
scenarios with different levels of traffic.  E.g., the number
of web sessions started each second, the number of
long-lived flows, etc.

I don't have a proposal for a single metric that captures
the "level of congestion" in congested and uncongested
scenarios, however.  (It is not clear to me that we need one.)

- Sally

> On 11/6/07, Sally Floyd <[email-masked]> wrote:
> >> - The rise time of a single flow to an empty systems is not very
>> > interesting, because it many measures the impact of slow start.
>>
>> Actually, the flow completion time in an uncongested system can be
>> a quite interesting thing to measure, particularly if one is
>> evaluating one of the many proposals for start-ups faster than
>> slow-start.??(One of these proposals is Quick-Start, RFC 4782; some
>> of the others are discussed in Appendix A of RFC 4782.)
>>
>> I would recommend having scenarios include the case of a
>> generally-uncongested link, as well as including cases with various
>> levels of congestion, with metrics including per-flow transfer
>> times, fairness, and aggregate packet drop rates.??This should
>> illustrate some of the good and potentially-bad aspects of protocols
>> with fast start-ups.
>>
>> - Sally
>> http://www.icir.org/floyd/
>>
>> RFC 4782:??http://www.ietf.org/rfc/rfc4782.txt
>>
>> _______________________________________________
>> Tmrg-interest mailing list
>> [email-masked]
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest
>
>
>
- Sally
http://www.icir.org/floyd/

From: [email-masked] (Saverio Mascolo)
Date: Tue Nov  6 11:05:38 2007
Subject: [Iccrg] (no subject)
Message-ID: <000601c82064$8f339540$723bccc1@HPSM>

what do you mean by "different level of congestion"?
sm

On 11/6/07, Sally Floyd <[email-masked]> wrote:
  > - The rise time of a single flow to an empty systems is not very
  > interesting, because it many measures the impact of slow start.

  Actually, the flow completion time in an uncongested system can be
  a quite interesting thing to measure, particularly if one is
  evaluating one of the many proposals for start-ups faster than
  slow-start.  (One of these proposals is Quick-Start, RFC 4782; some
  of the others are discussed in Appendix A of RFC 4782.)

  I would recommend having scenarios include the case of a
  generally-uncongested link, as well as including cases with various
  levels of congestion, with metrics including per-flow transfer
  times, fairness, and aggregate packet drop rates.  This should
  illustrate some of the good and potentially-bad aspects of protocols
  with fast start-ups.

  - Sally
  http://www.icir.org/floyd/

  RFC 4782:  http://www.ietf.org/rfc/rfc4782.txt

  _______________________________________________
  Tmrg-interest mailing list
  [email-masked]
  http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20071106/4c188372/attachment.html
>From [email-masked]  Tue Nov  6 11:13:54 2007
From: [email-masked] (=?ISO-8859-2?Q?S=E1ndor_Moln=E1r?=)
Date: Tue Nov  6 11:15:47 2007
Subject: [Iccrg] suggestions on fairness metrics to the TCP evaluation suite
	round-table
Message-ID: <[email-masked]>

Hi All,

We have recently completed a project on the fairness analysis of high
speed transport protocols. One of our result is that we suggest a new
performance metric (saturation time) that can be important from the
dynamical aspects of interacting protocols. We have found that the
short-term dynamics could have significant impacts on long-term
fairness. We hope it is relevant to the topic of TCP evaluation suite
round-table, especially to convergence time. Our results can be found in
our downloadable technical report, see below.

The website of our project:
http://qosip.tmit.bme.hu/~sonkoly/Tcp/

The technical report can be downloaded from:
http://qosip.tmit.bme.hu/~sonkoly/Tcp/files/Technical_Report.pdf

I also included the abstract of the report.

Abstract
---------
The short-term dynamics of competing high speed TCP flows could have
surprising impacts on their long-term fairness.  As a result, this could
have a severe impact on the co-existence and, finally, the deployment
feasibility of different seemingly promising proposals for the next
generation networks. However, to our best knowledge, no root-cause
analysis of the observation is available. This is the major motivation
of our work.

The contribution of the paper is twofold. First, we present our
comprehensive performance evaluation results of both inter- and
intra-protocol fairness behavior of different TCP versions to get an
overall view of these protocols. The analysis has revealed not only the
equilibrium behavior but also the transient characteristics with the
dynamic behavior. Second, we have performed a root-cause analysis to get
a deeper understanding in the case of some of the promising TCP
versions. This study not only fills the "black holes", the questions
which remained unanswered in some cases but rather goes deeper and
investigates questions which have never been asked yet. The analysis
spans multiple dimensions: flow-level, packet-level, queueing and
spectral analysis. Three loss-based (HighSpeed TCP, Scalable TCP and BIC
TCP) approaches and the delay-based FAST are investigated in details
with both dumb-bell and parking-lot topologies.

Regards,
Sandor

From: [email-masked] (Lachlan Andrew)
Date: Mon Nov  5 23:58:36 2007
Subject: [Iccrg] Re: flow completion times in uncongested systems
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Sally,

On 05/11/2007, Sally Floyd <[email-masked]> wrote:
> > - The rise time of a single flow to an empty systems is not very
> > interesting, because it many measures the impact of slow start.
>
> Actually, the flow completion time in an uncongested system can be
> a quite interesting thing to measure, particularly if one is
> evaluating one of the many proposals for start-ups faster than
> slow-start.  (One of these proposals is Quick-Start, RFC 4782; some
> of the others are discussed in Appendix A of RFC 4782.)

True.  I should have said that this is a very different quantity from
the responsiveness of the algorithm to control the window after slow
start.  As you say, it is of independent interest.

> I would recommend having scenarios include the case of a
> generally-uncongested link, as well as including cases with various
> levels of congestion, with metrics including per-flow transfer
> times, fairness, and aggregate packet drop rates.  This should
> illustrate some of the good and potentially-bad aspects of protocols
> with fast start-ups.

Yes, testing a range of levels of congestion is good.  My concern was
that we should not just measure the performance of a post-slow-start
modification by observing slow-start behaviour.

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 Nov  5 23:41:59 2007
Subject: [Iccrg] Re: TCP evaluation suite round-table
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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

-- 
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] (Sally Floyd)
Date: Mon Nov  5 23:38:09 2007
Subject: [Iccrg] flow completion times in uncongested systems
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> - The rise time of a single flow to an empty systems is not very
> interesting, because it many measures the impact of slow start.

Actually, the flow completion time in an uncongested system can be
a quite interesting thing to measure, particularly if one is
evaluating one of the many proposals for start-ups faster than
slow-start.  (One of these proposals is Quick-Start, RFC 4782; some
of the others are discussed in Appendix A of RFC 4782.)

I would recommend having scenarios include the case of a
generally-uncongested link, as well as including cases with various
levels of congestion, with metrics including per-flow transfer
times, fairness, and aggregate packet drop rates.  This should
illustrate some of the good and potentially-bad aspects of protocols
with fast start-ups.

- Sally
http://www.icir.org/floyd/

RFC 4782:  http://www.ietf.org/rfc/rfc4782.txt

From: [email-masked] ([email-masked])
Date: Thu Nov  1 17:23:02 2007
Subject: [Iccrg] congestion control in popular press
Message-ID: <[email-masked]>

This article is in the "popular press" (not a technical paper, or
specification, or anything), but it does talk about congestion control,
and I thought it might be interesting to others in the RG:

http://discovermagazine.com/2007/nov/this-man-wants-to-control-the-internet

My main gripe was that it didn't quite explain *why* a refrigerator
sending a warning when milk was about to expire would melt-down the
Internet, but just assumed we'd belive it :).

From: [email-masked] ([email-masked])
Date: Thu Nov  1 15:24:06 2007
Subject: [Iccrg] review of Compound TCP draft
Message-ID: <[email-masked]>

Here is a review I did of the Compound TCP draft, submitted just as a
normal participant in the group (not as co-chair), of the recently
submitted draft version (draft-sridharan-tcpm-ctcp-01).

Short Review:

The document's intended status is Experimental, for use on the open
Internet.  Based on looking at both the draft and several other
references, I think this is appropriate.  However, the draft on its own
may not have enough information on the exact parameter values (or
ranges) that should be used as guidance to implementers.  I specifically
refer to the dwnd formula on page 7; gamma is discussed at some length,
but alpha, beta, eta, and k are less well explained.  Since I believe
the authors can easily fix this in an updated draft by discussing the
particular values used in their implementations (which have shown
themselves to be very safe, in my opinion), I think this is a rather
minor issue.

Longer Review:

1) minor/editorial comment, in the abstract:

I know what is meant, but the phrase "gracefully reduces" is not quite
right, I think.  It might be better as "proactively reduces".

2) minor/editorial comment:

There's a missing linebreak between the last paragraph of the Introduction
and the heading for "2. Design Goals" at the top of page 5.

3) minor/editorial in section 2:

"the network resource and" -> "the network's resources and" ?

4) in section 2:

The logic is incomplete behind saying HSTCP "is now an experimental IETF
RFC" and using that alone to justify basing CTCP's agressiveness on
HSTCP.  I believe, what you want to say is that HSTCP hasn't been known
to exhibit severe issues in deployment or testing experiences, and
*that's* what makes it a reasonable baseline, NOT that it's an RFC.

5) minor/editorial in section 3:

"the delay component is effective" ->
"the delay component is only activated" ?

6) clarity in section 3 on basertt:

"It is continually measured and updated to track changing network
conditions."

I think you should say something more like it tracks the minimum RTT
sample observed over the course of the connection, or something more
specific than the current sentence alone?

7) "actual" throughput in section 3:

Since this is computed based on SRTT (an estimate itself from the
EWMA), is this really "actual", or "estimated actual" ... not overly
important, just a matter of confusion on my part.

8) clarity in section 3 on dwnd parameters:

Need more data on values/ranges for alpha, beta, eta, and k, I think.
It seems possible that poor selections could influence CTCP's
friendliness, though I have not analyzed this.

9) section 5 - windows measured in bytes, not packets

There is much discussion of window components in terms of packets in
this section: "estimating the backlogged packets", "30 packets", etc. in
this section.  There needs to be some mention of conversion between
number of packets and number of bytes, since the window is in bytes (say
based on MSS).  A couple of sentences could clarify this.

10) praise:

Section 6 on "implementation issues" is excellent, and a good addition,
even though it might not be strictly needed to understand the protocol.
It may be somewhat proprietary, but I think it would be helpful if you
could give just slightly more information on the number of RTT samples
that's kept.  I'm curious whether poor tuning of this could
significantly influence performance or fairness, and since I believe
your implementation to be quite well-behaved, it's a good basis for
others to parameterize from.

11) section 7: bytes/packets

"Only when the congestion window is greater than 38 packets" should
be 38 MSS ?

12) Security Considerations

One thought, that might be fruitless:  Given the delay-based component,
is CTCP increasingly vulnerable to ACK-spoofing attacks in comparison
to normal TCP?

13) references

Should the INFOCOM paper be normative?