Subject: [Iccrg] Question on RFC 2988 - TCP Retransmission timer
From: [email-masked] (Lachlan Andrew)
Date: Fri Aug 31 18:25:57 2007

Greetings Ian,

Since you've had no replies, here's my $0.02 worth.

I haven't seen any specific research on that.

Linux currently uses much higher precision timestamps than the old BSD
implementations to which the RFC refers, so it shouldn't really be an
issue.

The fact that Vegas works in Linux also shows that its timestamping
doesn't have systematic errors that would require a more conservative
timeout.

I agree that 1s is a terribly high minimum.  It looks like time for an
update to RFC 2988 :)

Cheers,
Lachlan

On 29/08/2007, Ian McDonald <[email-masked]> wrote:
> After some discussion on the Linux networking list I thought I'd ask
> the question here.
>
> In RFC 2988 Section 2.4 says:
>    (2.4) Whenever RTO is computed, if it is less than 1 second then the
>          RTO SHOULD be rounded up to 1 second.
>
>          Traditionally, TCP implementations use coarse grain clocks to
>          measure the RTT and trigger the RTO, which imposes a large
>          minimum value on the RTO.  Research suggests that a large
>          minimum RTO is needed to keep TCP conservative and avoid
>          spurious retransmissions [AP99].  Therefore, this
>          specification requires a large minimum RTO as a conservative
>          approach, while at the same time acknowledging that at some
>          future point, research may show that a smaller minimum RTO is
>          acceptable or superior.
>
> Given that Linux, BSD etc use 200 milliseconds, not 1 second I am
> wondering whether there has in fact been any research done as
> mentioned in last sentence. It seems a very high timeout especially on
> two locally connected devices.

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

From: [email-masked] (Michael Welzl)
Date: Thu Aug 30 08:32:51 2007
Subject: [Iccrg] Call for reviewers for CUBIC
Message-ID: <[email-masked]>

Dear all,

As you probably know, the ICCRG has agreed to obtain reviews
on experimental congestion control proposals before they
are brought to the IETF. While the competence to actually
decide about acceptance or not is with the IETF, it is expected
that they will take our reviews into account. This process
is outlined here:
http://www.ietf.org/IESG/content/ions/drafts/ion-tsv-alt-cc.txt

Right now, we are looking for reviews on
draft-rhee-tcpm-cubic-00.txt:
http://www3.tools.ietf.org/group/irtf/trac/attachment/wiki/ICCRG_cubic/draft-rhee-tcpm-cubic-00.txt
(note the small "Original format" link at the bottom if you
want plain ascii)

We would like to get feedback within 2 1/2 months
(earlier if possible).

If you're interested in doing a review, please send a note
to Wes and me. Reviews should be sent to the list; while
we explicitly encourage open reviews, you can also directly
send them to us for anonymization before reflecting them out
to the list, if desired.

Reviewers are strongly advised to:

* read draft-ietf-tsvwg-cc-alt-04:
  http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-cc-alt-04.txt

* consider not only the draft alone, but also papers referenced
  therein, where the authors should have carried out an evaluation
  of their mechanism, including studies which show the impact of the
  new mechanism on standard TCP. When looking at such studies,
  this document is recommended to be used for guidance:
  http://www.ietf.org/internet-drafts/draft-irtf-tmrg-metrics-09.txt

  There's now a small page on related resources at:
  http://www3.tools.ietf.org/group/irtf/trac/wiki/ICCRG_cubic
  Suggestions are welcome, just let me know if I should add some
  to this page.

One main conclusion that we are looking for is whether you agree
with the statement on safeness which is included in the abstract
of the draft (and obviously, we'd like to know how you arrived
at your decision). The requirement for including such a statement
is specified in section 2 of draft-ietf-tsvwg-cc-alt-04:

  Each alternate congestion control algorithm published is required to
  include a statement in the abstract indicating whether or not the
  proposal is considered safe for use on the Internet.  Each alternate
  congestion control algorithm published is also required to include a
  statement in the abstract describing environments where the protocol
  is not recommended for deployment.  There may be environments where
  the protocol is deemed *safe* for use, but still is not
  *recommended* for use because it does not perform well for the user.

We expect reviewers to have thoroughly read all the necessary
material. Generally, the more careful, complete and descriptive
a review is the more credence it will be given.

Thanks in advance to anyone who volunteers!

Cheers,
Michael

From: [email-masked] (Ian McDonald)
Date: Wed Aug 29 23:29:21 2007
Subject: [Iccrg] Question on RFC 2988 - TCP Retransmission timer
Message-ID: <[email-masked]>

After some discussion on the Linux networking list I thought I'd ask
the question here.

In RFC 2988 Section 2.4 says:
   (2.4) Whenever RTO is computed, if it is less than 1 second then the
         RTO SHOULD be rounded up to 1 second.

         Traditionally, TCP implementations use coarse grain clocks to
         measure the RTT and trigger the RTO, which imposes a large
         minimum value on the RTO.  Research suggests that a large
         minimum RTO is needed to keep TCP conservative and avoid
         spurious retransmissions [AP99].  Therefore, this
         specification requires a large minimum RTO as a conservative
         approach, while at the same time acknowledging that at some
         future point, research may show that a smaller minimum RTO is
         acceptable or superior.

Given that Linux, BSD etc use 200 milliseconds, not 1 second I am
wondering whether there has in fact been any research done as
mentioned in last sentence. It seems a very high timeout especially on
two locally connected devices.

Apologies if I'm asking on the wrong list.

Regards,

Ian
-- 
Web1: http://wand.net.nz/~iam4/
Web2: http://www.jandi.co.nz
Blog: http://iansblog.jandi.co.nz

From: [email-masked] (Lachlan Andrew)
Date: Wed Aug 29 00:56:58 2007
Subject: [Iccrg] Re: Appropriate rate given corruption
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Shiv,

On 28/08/07, Shivkumar Kalyanaraman <[email-masked]> wrote:
> So if the erasure rate of a channel with nominal bit
> rate C is p, then the shannon capacity of that erasure channel is C(1-p).
>
> Now think of a network with new links (indexed by j) where the link
> capacities are replaced with Cj(1-pj). Kelly's theory can then be applied
> to this revised network to define a notion of fairness.

That applies if there is per-hop erasure correction.  In the case
where TCP is exposed to the erasures, it is a little more complicated
than that.
a) We need to model the thinning of downstream traffic, as well as the
reduction in capacity of the lossy link
b) Kelly's framework doesn't distinguish between the "sent rate" and
the "received rate".  With significant loss, we need to consider the
fact that utility is only derived from the received rate.
c) Most lossy links are wireless.  In the common case that the
wireless link is a "bus", the loss rate is typically different for
different receivers (i.e., different flows).  That is why I modelled
the loss rate as a property of the flow at the link, rather than just
the link.

> a scheme that offers superior reliability due to better coding (eg: hybrid
> ARQ/FEC) should not be considered unfair compared to a scheme that uses
> all the same congestion detection/response mechanisms but uses a less
> effective reliability strategy (eg: window ARQ/SACK etc).

Absolutely.  Fairness should IMO be measured in terms of how much harm
is caused vs how much benefit is received.  If two flows cause equal
incremental  harm per extra unit of send-rate, then the one which
receives greater  incremental  benefit per extra unit send-rate should
have its rate increased.

Cheers,
Lachlan

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

From: [email-masked] (Shivkumar Kalyanaraman)
Date: Tue Aug 28 23:49:01 2007
Subject: [Iccrg] Re: Appropriate rate given corruption
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Lachlan, Michael,

When we designed LT-TCP, we viewed erasure loss
differently from congestion loss/ECN marks. An erasure loss essentially
reduces the capacity of the link. The process of adding FEC (whether at
the link layer to mask it or transport layer to add reliability) is a
"coding" function. So if the erasure rate of a channel with nominal bit
rate C is p, then the shannon capacity of that erasure channel is C(1-p).

Now think of a network with new links (indexed by j) where the link
capacities are replaced with Cj(1-pj). Kelly's theory can then be applied
to this revised network to define a notion of fairness. The special
case of TCP-friendliness would be the case when  all users
picked the same "TCP-friendly utility function" ...

However the TCP throughput formula could mix up matters.
By adding the aggregate loss rate (erasure + congestion) and using the TCP
formula leads to a significantly lower equilibrium rate for a flow on a
lossy channel -- since one would be mixing the effects of reliability &
congestion.

Fairness seems to be appropriate at the level of congestion control (i.e.
equilibrium rates relative to allowed utility functions). However, a
scheme that offers superior reliability due to better coding (eg: hybrid
ARQ/FEC) should not be considered unfair compared to a scheme that uses
all the same congestion detection/response mechanisms but uses a less
effective reliability strategy (eg: window ARQ/SACK etc).

We view this as a matter of disentangling the effects of congestion
control and reliability. TCP friendliness that includes the effect of
reliability would mean that TCP SACK would be unfriendly to TCP Reno
(just to make the point... granted that there are both congestion
control/reliability differences in these schemes).

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

On Tue, 28 Aug 2007, Lachlan Andrew wrote:

> Greetings Michael,
>
> Good.  It seems we're coming to a common understanding.  I'll try to
> be more explicit about the assumptions...
>
> Next I claim that:
>
> 5. If we use a "tcp friendly" flow control without unnecessary
> saw-tooth oscillation (like TFRC) then  p_i = 0  if the link isn't
> overloaded (sum of rates < capacity), and  p_i  increases as the
> amount of overload increases.
>
> 6. Define  U(x) = -(K^2)/x  as a "utility function".    Then  the
> response function of TCP is
>     D(p) = K/sqrt(p) =  (U')^{-1}(x),
> namely the inverse of the derivative of the utility.  (As an aside, if
>  x  is the receive rate, this is proportional to how long it takes to
> download a file of a given size, and negated since we get more benefit
> from shorter download times.)
>
> Combining 1, 2, 5 and 6 gives
>
> 7. TFRC solves Kelly's "utility maximization" problem, with the above
> utility function, if "utility" is assumed to be derived from the
> send   rate, rather than the    receive    rate.
>
> For reference, that utility maximization problem is
>     max sum_i U(x_i)    over all rates  x_i  for each flow  i
> subject to
>     R x <= c
> where
>    x=(x_i)  is a vector of rates (one per flow)
>    c=(c_l) is a vector of capacities (one per link)
>    R=(r_{il})  is a "routing matrix", where  r_{il}  is the amount of
> traffic flowing over link  l  for each unit of traffic in flow  i.
> Without any loss,  r_{il} = 1 if the link is on the path, or 0
> otherwise.  If there is loss upstream, then  r_{il}  will be slightly
> less than 1 if the link is on the path, but for a givne amount of
> loss, there will still be a well-defined "r_{il}" value.
>
> Unless you're familiar with the Kelly/Low framework, it isn't
> "obvious" that  7.  is true.  However, checking  Low and Lapsely '99
> shows that  6.  is the basic relation that has to hold.
>
> Do you accept all (any :)  of these claims?
>
> Cheers,
> Lachlan
>
>
> For reference, the things we agreed on were:
>
> 1. TCP responds with a rate approximately   K/sqrt(p)  where  K  is a
> constant dependent on such things as RTT and packet size,  and  p  is
> the total loss probability
>
> 2. On a path with multiple bottlenecks, with loss rates  p_i,  the
> total loss rate is approximately (and not more than) the sum of the p_i.
>
> 3. As a result, TCP gives at least the same rate to multi-hop flows
> than a hypothetical scheme which gave a rate  K/sqrt(sum p_i) <=
> K/sqrt(p)
>
> 4. Consider a network only one link  l_0 which
> corrupts packets, which transmits fraction  r  of the packets it
> receives.  Then each received packet on a flow traversing  l_0
> creates as much additional congestion as a flow in a modified network
> such that
>   (a) there is no loss
>   (b) each link  l_i  upstream of  l_0  is replaced by "1/r" links,
> each with the same amount of congestion as  l_i  had in the original
> network.
>
>
> --
> Lachlan Andrew  Dept of Computer Science, Caltech
> 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
> Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

From: [email-masked] (Lachlan Andrew)
Date: Tue Aug 28 20:03:05 2007
Subject: [Iccrg] Re: Appropriate rate given corruption
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Greetings Michael,

Good.  It seems we're coming to a common understanding.  I'll try to
be more explicit about the assumptions...

Next I claim that:

5. If we use a "tcp friendly" flow control without unnecessary
saw-tooth oscillation (like TFRC) then  p_i = 0  if the link isn't
overloaded (sum of rates < capacity), and  p_i  increases as the
amount of overload increases.

6. Define  U(x) = -(K^2)/x  as a "utility function".    Then  the
response function of TCP is
    D(p) = K/sqrt(p) =  (U')^{-1}(x),
namely the inverse of the derivative of the utility.  (As an aside, if
 x  is the receive rate, this is proportional to how long it takes to
download a file of a given size, and negated since we get more benefit
from shorter download times.)

Combining 1, 2, 5 and 6 gives

7. TFRC solves Kelly's "utility maximization" problem, with the above
utility function, if "utility" is assumed to be derived from the
send   rate, rather than the    receive    rate.

For reference, that utility maximization problem is
    max sum_i U(x_i)    over all rates  x_i  for each flow  i
subject to
    R x <= c
where
   x=(x_i)  is a vector of rates (one per flow)
   c=(c_l) is a vector of capacities (one per link)
   R=(r_{il})  is a "routing matrix", where  r_{il}  is the amount of
traffic flowing over link  l  for each unit of traffic in flow  i.
Without any loss,  r_{il} = 1 if the link is on the path, or 0
otherwise.  If there is loss upstream, then  r_{il}  will be slightly
less than 1 if the link is on the path, but for a givne amount of
loss, there will still be a well-defined "r_{il}" value.

Unless you're familiar with the Kelly/Low framework, it isn't
"obvious" that  7.  is true.  However, checking  Low and Lapsely '99
shows that  6.  is the basic relation that has to hold.

Do you accept all (any :)  of these claims?

Cheers,
Lachlan

For reference, the things we agreed on were:

1. TCP responds with a rate approximately   K/sqrt(p)  where  K  is a
constant dependent on such things as RTT and packet size,  and  p  is
the total loss probability

2. On a path with multiple bottlenecks, with loss rates  p_i,  the
total loss rate is approximately (and not more than) the sum of the p_i.

3. As a result, TCP gives at least the same rate to multi-hop flows
than a hypothetical scheme which gave a rate  K/sqrt(sum p_i) <=
K/sqrt(p)

4. Consider a network only one link  l_0 which
corrupts packets, which transmits fraction  r  of the packets it
receives.  Then each received packet on a flow traversing  l_0
creates as much additional congestion as a flow in a modified network
such that
  (a) there is no loss
  (b) each link  l_i  upstream of  l_0  is replaced by "1/r" links,
each with the same amount of congestion as  l_i  had in the original
network.

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

From: [email-masked] (Michael Welzl)
Date: Tue Aug 28 07:39:32 2007
Subject: [Iccrg] Re: Appropriate rate given corruption
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> > > Do you agree that
> >
> > > 2. On a path with multiple bottlenecks, with loss rates  p_i,  the
> > > total loss rate is slightly    less   than the sum of the p_i.   That
> > > is,  p = 1-product(1-p_i) < (sum p_i)
> >
> > No.
> >
> > I don't understand why the total loss rate of
> > the path would be slightly less than the sum of the p_i
> > and not precisely that sum.
> 
> *grin*  Last thread, I made the approximation that  p = sum p_i, and
> you correctly pointed out that, strictly,
>     p = 1 - product(1-p_i)
> because the probability a packet gets through is the probability it
> gets through on the first link *and* the second *and* the third, ...

Argh! I'm terribly sorry. I remember sending yesterday's
email *before* I had my first cup of coffee, which apparently
was a big mistake. You're right of course.

Now I already had a cup, and will now fetch another one
before I continue - hold on...

okay I'm back  :-)

> If you're happy with the approximation  p = sum p_i,  we can go with
> that and it will (greatly) simplify my later arguments.

I guess my main problem with your original emails was
the mixture of
1) assumptions which weren't all explicitly stated
2) a counter-intuitive message
3) and just the fact that it all is complicated

All three things combined were a little too much for me.

Now, as long as I understand the assumptions and they
are explicitly written, I think I can handle them. So,
if assuming that sum greatly simplifies your later
arguments, that's okay with me.

> However, if you want to more precise and go with  p = 1 -
> product(1-p_i)  then we'll need to use the fact that
>     1 - product(1-p_i)  <=  sum  p_i
> This follows immediately by induction.  We don't need the inequality
> to be strict.

Okay, I get it. Fine with me to take the simpler road
now, though.

> > The way I think about it, there is only one
> > bottleneck along a path per definition (so the p_i's will
> > all be close to zero except for one of them, which
> > represents the bottleneck).
> 
> OK.  In the optimization flow control literature, the term
> "bottleneck" is used to mean any link which has non-zero p_i.  That
> means that a link which is a bottleneck for *any* flow using that link
> will be a "bottleneck" for all flows using that link.

Okay, I understand.

> Do you agree that,
>    If one flow loses packets at a link due to congestion (non-zero p_i)
>    then that congestion will cause all flows to lose some packets on
>    that link eventually (not necessarily all in the same "congestion event")?
> That is the basis behind AIMD giving fairness.

Yes.

> > > 3. As a result, TCP gives slightly  higher  rate to multi-hop flows
> > > than a hypothetical scheme which gave a rate  K/sqrt(sum p_i) <=
> > > K/sqrt(p)
> >
> > No because this is based on 2, which I disagree with.
> 
> Again, we can try for a slightly weaker statement, based on 2a:
> 3a. TCP gives   no smaller   rate to multi-hop flows
>       than would a hypothetical scheme which gave a rate
>       K/sqrt(sum p_i) <= K/sqrt(p)
> 
> If you are happy with the approximation that  p = sum p_i  then  3a
> follows immediately.

Okay.

Cheers,
Michael

From: [email-masked] (Lachlan Andrew)
Date: Mon Aug 27 19:15:40 2007
Subject: [Iccrg] Re: Appropriate rate given corruption
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Michael,

On 26/08/07, Michael Welzl <[email-masked]> wrote:
> On Sun, 2007-08-26 at 16:16 -0700, Lachlan Andrew wrote:
> > Do you agree that
>
> > 2. On a path with multiple bottlenecks, with loss rates  p_i,  the
> > total loss rate is slightly    less   than the sum of the p_i.   That
> > is,  p = 1-product(1-p_i) < (sum p_i)
>
> No.
>
> I don't understand why the total loss rate of
> the path would be slightly less than the sum of the p_i
> and not precisely that sum.

*grin*  Last thread, I made the approximation that  p = sum p_i, and
you correctly pointed out that, strictly,
    p = 1 - product(1-p_i)
because the probability a packet gets through is the probability it
gets through on the first link *and* the second *and* the third, ...

If you're happy with the approximation  p = sum p_i,  we can go with
that and it will (greatly) simplify my later arguments.

However, if you want to more precise and go with  p = 1 -
product(1-p_i)  then we'll need to use the fact that
    1 - product(1-p_i)  <=  sum  p_i
This follows immediately by induction.  We don't need the inequality
to be strict.

> The way I think about it, there is only one
> bottleneck along a path per definition (so the p_i's will
> all be close to zero except for one of them, which
> represents the bottleneck).

OK.  In the optimization flow control literature, the term
"bottleneck" is used to mean any link which has non-zero p_i.  That
means that a link which is a bottleneck for *any* flow using that link
will be a "bottleneck" for all flows using that link.

Do you agree that,
   If one flow loses packets at a link due to congestion (non-zero p_i)
   then that congestion will cause all flows to lose some packets on
   that link eventually (not necessarily all in the same "congestion event")?
That is the basis behind AIMD giving fairness.

It isn't important for my arguments how *common* it is in the real
internet for a flow to have multiple links with non-zero  p_i; just
how TCP would respond if it did happen.

If you like, we can just try to agree on the weaker statement:
2a. The total loss rate is   not greater   than the sum of the p_i.

> > 3. As a result, TCP gives slightly  higher  rate to multi-hop flows
> > than a hypothetical scheme which gave a rate  K/sqrt(sum p_i) <=
> > K/sqrt(p)
>
> No because this is based on 2, which I disagree with.

Again, we can try for a slightly weaker statement, based on 2a:
3a. TCP gives   no smaller   rate to multi-hop flows
      than would a hypothetical scheme which gave a rate
      K/sqrt(sum p_i) <= K/sqrt(p)

If you are happy with the approximation that  p = sum p_i  then  3a
follows immediately.

Cheers,
Lachlan

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

From: [email-masked] (Wesley Eddy)
Date: Mon Aug 27 15:24:58 2007
Subject: [Iccrg] update to cc-rfcs draft
Message-ID: <[email-masked]>

Michael and I completed an update of the cc-rfcs document that surveys
the published RFCs dealing with congestion control:

http://www.ietf.org/internet-drafts/draft-irtf-iccrg-cc-rfcs-02.txt

Most of the changes come from the detailed review that Gorry sent us,
along with some other comments from Sally Floyd, Mark Allman, Stephen
Farrell, and Lars Eggert.  We also added a few more RFCs to the list.

We realize that since RFC 5033 was *just* published, we need to add
this to the draft, but aside from this, we'd also like to know if
the update suffices to address people's comments.  A colorized rfcdiff
is available for efficient checking:

http://roland.grc.nasa.gov/~weddy/shared/iccrg/cc-rfcs-01-to-02-diff.html

If possible, we'd like to finish revision of this within the RG by the
end of September and move it forward.  Thanks for your comments and
reviews :).

-- 
Wesley M. Eddy
Verizon Federal Network Systems

From: [email-masked] (Michael Welzl)
Date: Mon Aug 27 07:24:00 2007
Subject: [Iccrg] Re: Appropriate rate given corruption
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Sun, 2007-08-26 at 16:16 -0700, Lachlan Andrew wrote:
> Greetings Michael,
> 
> Our previous discussion on the appropriate rate for congestion control
> in the presence of corruption got a bit stuck on details.    If you
> have the time, I'd like to try again, starting with some things I
> think we can agree on.

Okay - I think that's a good approach, thanks!

> Do you agree that
> 
> 1. TCP responds with a rate approximately   K/sqrt(p)  where  K  is a
> constant dependent on such things as RTT and packet size,  and  p  is
> the total loss probability

Yes.

> 2. On a path with multiple bottlenecks, with loss rates  p_i,  the
> total loss rate is slightly    less   than the sum of the p_i.   That
> is,  p = 1-product(1-p_i) < (sum p_i)

No.

First of all, the way I think about it, there is only one
bottleneck along a path per definition (so the p_i's will
all be close to zero except for one of them, which
represents the bottleneck).

Secondly, I don't understand why the total loss rate of
the path would be slightly less than the sum of the p_i
and not precisely that sum.

> 3. As a result, TCP gives slightly  higher  rate to multi-hop flows
> than a hypothetical scheme which gave a rate  K/sqrt(sum p_i) <=
> K/sqrt(p)

No because this is based on 2, which I disagree with.

> 4. (More of a stretch)  Consider a network only one link  l_0 which
> corrupts packets, which transmits fraction  r  of the packets it
> receives.  Then each received packet on a flow traversing  l_0
> creates as much additional congestion as a flow in a modified network
> such that
>   (a) there is no loss
>   (b) each link  l_i  upstream of  l_0  is replaced by "1/r" links,
> each with the same amount of congestion as  l_i  had in the original
> network.

Yes.

Cheers,
Michael

From: [email-masked] (Lachlan Andrew)
Date: Mon Aug 27 00:17:59 2007
Subject: [Iccrg] Appropriate rate given corruption
Message-ID: <[email-masked]>

Greetings Michael,

Our previous discussion on the appropriate rate for congestion control
in the presence of corruption got a bit stuck on details.    If you
have the time, I'd like to try again, starting with some things I
think we can agree on.

Do you agree that

1. TCP responds with a rate approximately   K/sqrt(p)  where  K  is a
constant dependent on such things as RTT and packet size,  and  p  is
the total loss probability

2. On a path with multiple bottlenecks, with loss rates  p_i,  the
total loss rate is slightly    less   than the sum of the p_i.   That
is,  p = 1-product(1-p_i) < (sum p_i)

3. As a result, TCP gives slightly  higher  rate to multi-hop flows
than a hypothetical scheme which gave a rate  K/sqrt(sum p_i) <=
K/sqrt(p)

4. (More of a stretch)  Consider a network only one link  l_0 which
corrupts packets, which transmits fraction  r  of the packets it
receives.  Then each received packet on a flow traversing  l_0
creates as much additional congestion as a flow in a modified network
such that
  (a) there is no loss
  (b) each link  l_i  upstream of  l_0  is replaced by "1/r" links,
each with the same amount of congestion as  l_i  had in the original
network.

If you disagree with any, let's discuss that before continuing.

Cheers,
Lachlan

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

From: [email-masked] (Murari Sridharan)
Date: Wed Aug 22 16:55:48 2007
Subject: [Iccrg] Call for reviewers for CTCP
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Lachlan, I'll make the appropriate changes to clarify things better and send out an update including answers to your questions below in a couple of days.

Thanks

-----Original Message-----
From: Lachlan Andrew [mailto:[email-masked]]
Sent: Tuesday, August 21, 2007 7:12 PM
To: Michael Welzl
Cc: [email-masked]; Murari Sridharan
Subject: Re: [Iccrg] Call for reviewers for CTCP

Greetings all,

On 21/08/07, Michael Welzl <[email-masked]> wrote:
> SECOND CALL - so far we received nothing! are there no volunteers
> on this list?   (i.e. isn't there anyone else who wants to submit
> submit a proposal one day?   :-D   )

Before deciding on the safeness of CTCP, I'd recommend tidying up some
loose ends in this draft, as below.  I think these are mainly problems
with the explanations, rather than the algorithm.

Cheers,
Lachlan

- Calculation of BaseRTT is not clear.
   "The basertt is a value that tracks the minimum RTT sample
    measured seen so far and it is used as an estimation of the
    transmission delay of a single packet. Basertt is usually cleared if a
    retransmission timeout is hit. It is a good idea to re-measure the
    basertt incase the network conditions have changed."

  o Does "usually cleared" mean that the algorithm clears it, or not?
  o When baseRTT is "cleared", does that mean "set to 0", "set to
infinity" or ...?
  o Setting to infinity is the most aggressive setting, and so it is not clear
    that this is the appropriate response to a timeout.
  o What does "re-measure" mean?  In Vegas, the baseRTT is continually being
    measured.
  o This belongs in the algorithm description, not "Implementation issues"

- The adaptive calculation of  gamma  is unclear and hence unconvincing.
  o There is a big leap from the thought experiment without CTCP to what
    CTCP can actually observe.
  o From this description, it seems that  Q  is always
    less-than-or-equal-to the number of packets the CTCP flow has in
    the buffer.  In that case, choosing  gamma <= Q implies that the
    CTCP always has more than  gamma  packets in the buffer, and always
    reverts to standard TCP.  (This description is inconsistent with
    the pseudocode below it, which evaluates  Q  only at times of loss.)
  o The line "Q is calculated as follows" is followed by equations which
    don't mention  Q.

- No numeric value is given for  eta  (although it is described as
  "very important to preserve...TCP fairness").

- equations (3) and (4) contradict (5) and (7).  Which is the actual update
  rule for dwnd?  (I assume (3) and (4) are meant to apply to  wnd.)

- In (8), brackets are missing around  (2-k)  in the denominator

- In Section 5, B/m+l  should presumably be  B/(m+l).  (Brackets are used
  every time they are not needed, and omitted every time they are needed.)
  Also,  B  is undefined.

- (10) doesn't follow from (8), because the constant coefficient in terms of
  alpha  and  beta  is missing from (8).

- In the sentence "The expected throughput gives the estimation of throughput
  CTCP gets if it does not overrun the network path", what does
  "overrun the network path" mean?  Does that mean "induce queueing"?

- Neither FAST nor AFRICA halves its window if the delay becomes large.
  (Hamilton's Delay-based-AIMD is the only scheme I'm aware of which does.)

- If CTCP is to be "TCP-friendly" but less sensitive to RTT, I don't understand
  what will happen when it shares with two flows of unequal RTT.
  Which TCP flow will it get the same rate as?
  (It doesn't matter, but casts doubt on the claim that it gives "the
same" rate as TCP.)

- End of section 4:  "Later sections" -- specify the section

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

From: [email-masked] (Lars Eggert)
Date: Wed Aug 22 08:03:22 2007
Subject: [Iccrg] Call for reviewers for CTCP
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 2007-8-22, at 5:12, ext Lachlan Andrew wrote:
> Before deciding on the safeness of CTCP, I'd recommend tidying up some
> loose ends in this draft, as below.  I think these are mainly problems
> with the explanations, rather than the algorithm.

Related to that, because CTCP - and the other upcoming proposals -  
aim to become Experimental protocol specifications, I'd highly  
recommend to use RFC2119 terminology (MUST/SHOULD/MAY/etc.) for the  
algorithm descriptions. At least once they hit the IETF that'll be  
important, and doing this now will probably clarify at least some of  
the ambiguities.

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/20070822/bf8453af/smime.bin
>From [email-masked]  Wed Aug 22 08:09:37 2007
From: [email-masked] (Michael Welzl)
Date: Wed Aug 22 08:10:43 2007
Subject: [Iccrg] Call for reviewers for CTCP
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Okay now,

We have 2 volunteers (thanks!!). Before they start, I suggest
that the authors update their draft, based on the comments
from Lachlan in his prior email and the comment from Lars below.

Simply update, announce it to the list, and we will tell the
reviewers to get started

Cheers,
Michael

On Wed, 2007-08-22 at 09:49 +0300, Lars Eggert wrote:
> On 2007-8-22, at 5:12, ext Lachlan Andrew wrote:
> > Before deciding on the safeness of CTCP, I'd recommend tidying up some
> > loose ends in this draft, as below.  I think these are mainly problems
> > with the explanations, rather than the algorithm.
> 
> Related to that, because CTCP - and the other upcoming proposals -  
> aim to become Experimental protocol specifications, I'd highly  
> recommend to use RFC2119 terminology (MUST/SHOULD/MAY/etc.) for the  
> algorithm descriptions. At least once they hit the IETF that'll be  
> important, and doing this now will probably clarify at least some of  
> the ambiguities.
> 
> Lars

From: [email-masked] (Lachlan Andrew)
Date: Wed Aug 22 03:14:22 2007
Subject: [Iccrg] Call for reviewers for CTCP
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings all,

On 21/08/07, Michael Welzl <[email-masked]> wrote:
> SECOND CALL - so far we received nothing! are there no volunteers
> on this list?   (i.e. isn't there anyone else who wants to submit
> submit a proposal one day?   :-D   )

Before deciding on the safeness of CTCP, I'd recommend tidying up some
loose ends in this draft, as below.  I think these are mainly problems
with the explanations, rather than the algorithm.

Cheers,
Lachlan

- Calculation of BaseRTT is not clear.
   "The basertt is a value that tracks the minimum RTT sample
    measured seen so far and it is used as an estimation of the
    transmission delay of a single packet. Basertt is usually cleared if a
    retransmission timeout is hit. It is a good idea to re-measure the
    basertt incase the network conditions have changed."

  o Does "usually cleared" mean that the algorithm clears it, or not?
  o When baseRTT is "cleared", does that mean "set to 0", "set to
infinity" or ...?
  o Setting to infinity is the most aggressive setting, and so it is not clear
    that this is the appropriate response to a timeout.
  o What does "re-measure" mean?  In Vegas, the baseRTT is continually being
    measured.
  o This belongs in the algorithm description, not "Implementation issues"

- The adaptive calculation of  gamma  is unclear and hence unconvincing.
  o There is a big leap from the thought experiment without CTCP to what
    CTCP can actually observe.
  o From this description, it seems that  Q  is always
    less-than-or-equal-to the number of packets the CTCP flow has in
    the buffer.  In that case, choosing  gamma <= Q implies that the
    CTCP always has more than  gamma  packets in the buffer, and always
    reverts to standard TCP.  (This description is inconsistent with
    the pseudocode below it, which evaluates  Q  only at times of loss.)
  o The line "Q is calculated as follows" is followed by equations which
    don't mention  Q.

- No numeric value is given for  eta  (although it is described as
  "very important to preserve...TCP fairness").

- equations (3) and (4) contradict (5) and (7).  Which is the actual update
  rule for dwnd?  (I assume (3) and (4) are meant to apply to  wnd.)

- In (8), brackets are missing around  (2-k)  in the denominator

- In Section 5, B/m+l  should presumably be  B/(m+l).  (Brackets are used
  every time they are not needed, and omitted every time they are needed.)
  Also,  B  is undefined.

- (10) doesn't follow from (8), because the constant coefficient in terms of
  alpha  and  beta  is missing from (8).

- In the sentence "The expected throughput gives the estimation of throughput
  CTCP gets if it does not overrun the network path", what does
  "overrun the network path" mean?  Does that mean "induce queueing"?

- Neither FAST nor AFRICA halves its window if the delay becomes large.
  (Hamilton's Delay-based-AIMD is the only scheme I'm aware of which does.)

- If CTCP is to be "TCP-friendly" but less sensitive to RTT, I don't understand
  what will happen when it shares with two flows of unequal RTT.
  Which TCP flow will it get the same rate as?
  (It doesn't matter, but casts doubt on the claim that it gives "the
same" rate as TCP.)

- End of section 4:  "Later sections" -- specify the section

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

From: [email-masked] (Michael Welzl)
Date: Tue Aug 21 15:04:51 2007
Subject: [Iccrg] Call for reviewers for CTCP
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

SECOND CALL - so far we received nothing! are there no volunteers
on this list?   (i.e. isn't there anyone else who wants to submit
submit a proposal one day?   :-D   )

Cheers,
Michael

PS: as has been rightly pointed out, that "statement on safeness"
which I referred to in this email is in fact not in the abstract
of this draft but in the conclusion section

On Thu, 2007-08-09 at 16:08 +0200, Michael Welzl wrote:
> Dear all,
> 
> As you probably know, the ICCRG has agreed to obtain reviews
> on experimental congestion control proposals before they
> are brought to the IETF. While the competence to actually
> decide about acceptance or not is with the IETF, it is expected
> that they will take our reviews into account. This process
> is outlined here:
> http://www.ietf.org/IESG/content/ions/drafts/ion-tsv-alt-cc.txt
> 
> 
> Right now, we are looking for reviews on
> draft-sridharan-tcpm-ctcp-00.txt:
> http://research.microsoft.com/users/dthaler/draft-sridharan-tcpm-ctcp-00.txt
> 
> for which it was requested that the draft would eventually become
> a WG item of the TCPM Working Group.
> 
> The authors recently sent a few related pointers to the list; if
> you lost that message, it's here in the archive:
> http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-July/000249.html
> 
> 
> We would like to get feedback within 2 1/2 months
> (earlier if possible).
> 
> If you're interested in doing a review, please send a note
> to Wes and me. Reviews should be sent to the list; while
> we explicitly encourage open reviews, you can also directly
> send them to us for anonymization before reflecting them out
> to the list, if desired.
> 
> Reviewers are strongly advised to:
> 
> * read draft-ietf-tsvwg-cc-alt-04:
>   http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-cc-alt-04.txt
> 
> * consider not only the draft alone, but also papers referenced
>   therein, where the authors should have carried out an evaluation
>   of their mechanism, including studies which show the impact of the
>   new mechanism on standard TCP. When looking at such studies,
>   this document is recommended to be used for guidance:
>   http://www.ietf.org/internet-drafts/draft-irtf-tmrg-metrics-09.txt
> 
> 
> One main conclusion that we are looking for is whether you agree
> with the statement on safeness which is included in the abstract
> of the draft (and obviously, we'd like to know how you arrived
> at your decision). The requirement for including such a statement
> is specified in section 2 of draft-ietf-tsvwg-cc-alt-04:
> 
>   Each alternate congestion control algorithm published is required to
>   include a statement in the abstract indicating whether or not the
>   proposal is considered safe for use on the Internet.  Each alternate
>   congestion control algorithm published is also required to include a
>   statement in the abstract describing environments where the protocol
>   is not recommended for deployment.  There may be environments where
>   the protocol is deemed *safe* for use, but still is not
>   *recommended* for use because it does not perform well for the user.
> 
> 
> We expect reviewers to have thoroughly read all the necessary
> material. Generally, the more careful, complete and descriptive
> a review is the more credence it will be given.
> 
> Thanks in advance to anyone who volunteers!
> 
> Cheers,
> Michael
> 
> 
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Lachlan Andrew)
Date: Thu Aug 16 03:46:08 2007
Subject: [Iccrg] Re: [Tmrg] A reminder about An NS2 TCP Evaluation Tool Suite
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Greetings Gang Wang,

Your tool looks nice.  Here are some suggestions:

1. Each topology seems to specify a single bottleneck capacity and
RTT.  Is there a way to make it test for a a range of capacities, like
10, 100, 155 and 622 Mbps?

2. It specifies a diff_RTT variable so that flows can have different
RTTs, but it seems that RTTs are equally spaced within the allowed
range.  This equal spacing may cause artefacts.  More importantly,
real RTTs aren't uniformly distributed.  It would be good to have a
more realistic distribution of RTTs.  (If they're generated randomly,
it will be important to make it repeatable still.)

3. Jain's measure of fairness does not reflect the user's experience.
  - A fairness measure should give more weight to flows receiving very
low throughput.  If 10 flows get equal throughput, and one flow gets
nothing, that is very unfair, but scores highly in Jain's index.
  - This can partly be overcome by applying Jain's index to the
*download times* instead of the rates.  As an approximation of the
download time, you could use the reciprocal of the rate.
  - Jain's measure also doesn't consider the impact of multiple
bottlenecks.  In a parking-lot topology with links of unequal
capacity, the "fairest" solution IMO is for the flow which only uses
the high-capacity link not to be restricted by the fact that there is
another low-capacity link which it doesn't use.  Jain's index only
gives a high score if the high-capacity link is under-utilized.

4. The parking lot topology is very symmetric.  It would be
interesting to look at parking-lot topologies with different
bandwidths on the different bottlenecks.

Cheers,
Lachlan

On 07/08/07, Wang gang <[email-masked]> wrote:
>
> Dear colleagues,
>
> We have released the tool 'An NS2 TCP Evaluation Tool Suite' for some time.
> Since
> then, we have received some feed back from users. We expect to receive wider
> comments,
> and seek collaborations or contributions to make the tool towards a useful
> one.
>
> The download page is,
> http://labs.nec.com.cn/tcpeval.htm
>
>
> Here is a brief introduction,
> This tool is motivated by the observation that there is significant overlap
> among (but lack
> of an agreed set of) the topologies, traffic, and metrics used by many
> researchers in the
> evaluation of TCP alternatives: effort could be saved by starting research
> from an existing
> framework.  As such, our tool includes several typical topologies and
> traffic models; it measures
> some of the most important metrics commonly used in TCP evaluation; and it
> can automatically
> generate simulation statistics and graphs ready for inclusion in latex and
> html documents.  The
> tool also contains an extendable open-source framework.  With community
> effort, we hope the
> tool evolves into a widely accepted, well-defined set of TCP performance
> evaluation benchmarks.
>
> Best Regards.
>
> Gang Wang.
>
> ----------------------------------------
> Gang Wang
> NEC Labs, China
> 010-62705962/63  (ext.511)
>
> [email-masked]
>
>
>
> _______________________________________________
> Tmrg-interest mailing list
> [email-masked]
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest
>
>

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

From: [email-masked] (Mark Allman)
Date: Tue Aug 14 16:05:05 2007
Subject: [Iccrg] Call for reviewers for CTCP
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

I am confused ....

> One main conclusion that we are looking for is whether you agree
> with the statement on safeness which is included in the abstract
> of the draft (and obviously, we'd like to know how you arrived
> at your decision).

Err.  Perhaps you could tell us what statement in the abstract you are
talking about.  My reading of the abstract (appended below for easy
access) is that it includes no such statement and therefore the question
you ask above makes no sense to me.

allman

   This document proposes Compound TCP (CTCP), a modification to TCP's 
   congestion control mechanism for use with TCP connections with large 
   congestion windows. The key idea behind CTCP is to add a scalable 
   delay-based component to the standard TCP's loss-based congestion 
   control. The sending rate of CTCP is controlled by both loss and 
   delay components. The delay-based component has a scalable window 
   increasing rule that not only efficiently uses the link capacity, 
   but on sensing queue build up, gracefully reduces the sending rate. 
   We have implemented CTCP on Microsoft's Windows and we have done 
   extensive testing on production links and in Windows Beta 
   deployments. We also engaged with Stanford Linear Accelerator Center 
   to evaluate the properties of CTCP. The results so far are very 
   encouraging. This document describes the Compound TCP algorithm in 
   detail, and solicits experimentation and feedback from the wider 
   community. In this document, we collectively refer to any TCP 
   congestion control algorithm that employs a linear increase function 
   for congestion control, including TCP Reno and all its variants as 
   Standard TCP. 

-------------- 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/20070814/4b08640a/attachment.bin
>From [email-masked]  Tue Aug 14 18:34:26 2007
From: [email-masked] (Murari Sridharan)
Date: Tue Aug 14 18:35:53 2007
Subject: [Iccrg] Call for reviewers for CTCP
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Mark, the text is in the conclusions section. My bad.

"Compound TCP has been implemented as an optional component in Microsoft
Windows Vista Operating System. 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. 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."

Thanks
Murari

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Allman
Sent: Tuesday, August 14, 2007 8:03 AM
To: Michael Welzl
Cc: [email-masked]
Subject: Re: [Iccrg] Call for reviewers for CTCP

I am confused ....

> One main conclusion that we are looking for is whether you agree with
> the statement on safeness which is included in the abstract of the
> draft (and obviously, we'd like to know how you arrived at your
> decision).

Err.  Perhaps you could tell us what statement in the abstract you are talking about.  My reading of the abstract (appended below for easy
access) is that it includes no such statement and therefore the question you ask above makes no sense to me.

allman

   This document proposes Compound TCP (CTCP), a modification to TCP's
   congestion control mechanism for use with TCP connections with large
   congestion windows. The key idea behind CTCP is to add a scalable
   delay-based component to the standard TCP's loss-based congestion
   control. The sending rate of CTCP is controlled by both loss and
   delay components. The delay-based component has a scalable window
   increasing rule that not only efficiently uses the link capacity,
   but on sensing queue build up, gracefully reduces the sending rate.
   We have implemented CTCP on Microsoft's Windows and we have done
   extensive testing on production links and in Windows Beta
   deployments. We also engaged with Stanford Linear Accelerator Center
   to evaluate the properties of CTCP. The results so far are very
   encouraging. This document describes the Compound TCP algorithm in
   detail, and solicits experimentation and feedback from the wider
   community. In this document, we collectively refer to any TCP
   congestion control algorithm that employs a linear increase function
   for congestion control, including TCP Reno and all its variants as
   Standard TCP.

From: [email-masked] (Dirceu Cavendish)
Date: Thu Aug  9 23:21:05 2007
Subject: [Iccrg] LT-TCP followup
Message-ID: <[email-masked]>

Dear Andrew,

I sense we are in violent agreement in various points, although coming from different perspectives. See below...

----- Original Message ----
From: Lachlan Andrew <[email-masked]>
To: Dirceu Cavendish <[email-masked]>
Cc: [email-masked]
Sent: Thursday, August 9, 2007 2:28:27 PM
Subject: Re: [Iccrg] LT-TCP followup

Greetings Dirceu,

On 09/08/07, Dirceu Cavendish <[email-masked]> wrote:
> So it makes sense to me to ask: "how well can we design a CC scheme
> with as little new features from routers as possible?"

Agreed.  Larry Dunn has convinced me of that.

My point was that we ideally don't want to design protocols which
*rely* on undesirable  artefacts  of current networks, which we might
otherwise want (and be able) to get rid of.  One such artefact is that
current networks have very long queueing delay during congestion
(because of Reno's "need" for bandwidth-delay droptail buffers).

<DC> Agree. CC protocols that maitain a high queueing delay are not desirable. I
alluded to that as "operating points" of a cc scheme in my presentation in Chicago. Due to the inherent template of AIMD based on packet loss/no-loss detection, many TCPs tend to operate at heavy queue filling levels. But the operating point of a cc scheme can be tuned to low queueing delays as well. This is a matter of design.
</DC>

> Explicit signalling requires specific
> router behavior from the get go, AND it is difficult to guarantee anything
> if not adopted by all routers on a session path.

That is true if the explicit signalling is used to say "slow down".
What Michael proposed was something to say "*don't* slow down, that
wasn't congestion".  The absence of that signal doesn't break
anything.

<DC> Agree. But some people also advocate that L2 corruption loss should cause rate reduction, as a thread on this list has shown. In this context, then, I assume a router would decide that THAT particular corruption loss was spurious, hence a drastic rate/window reduction should not be exercised.
</DC>

If a single router on the path knows that it is wireless, and likely
to drop packets without congestion, then even if only that one router
implements the signalling, then we avoid unnecessary window halving.
The wireline/core routers needn't be touched.

<DC> Agree once more. However, persistent corruption losses in an AMC channel may trigger a mode change, with wireless service capacity reduction. In this scenario, it makes sense to me that the TCP sources slow down, as service bit rate has significantly reduced ( at a likely session bottleneck).
</DC>

Conversely, consider the case of implicit signalling:  A single
congested queue drops many packets without introducing queueing delay
(perhaps it has a small buffer).  If this treated as heavy
"corruption" by the congestion control, then the source doesn't slow
down enough, and congestion persists.

<DC> Lets take the extreme case. Wireless channel, with no storage space whatsoever. If it is an adaptive channel (AMC), the channel will reduce its modulation rate in order to achieve an acceptable BER. If not, the wireless channel may indeed become a black hole. In this case, rate reduction is unlikely to help, and the TCP should and will take more drastic action (e.g., new slow start), triggered by RTOs, excessive retransmissions, etc...
</DC>

(Minor comments below.)

Cheers,
Lachlan

> specific router behavior may interfere with some such passive schemes.
> But that is the same as specific receiver misbehavior (either maliciously or
> not).

Sort of...  If we can devise a way for routers not to delay packets
despite persistent congestion, that is "progress", not "misbehaviour".
However, if it causes all losses to be treated as non-congestion
losses and so breaks congestion control, it is likely to be
"disallowed" by the IETF.

> I guess it is widespread consensus today that complexity at the end points
> is best, so routers should keep its simplicity

Yes, although wireless devices are likely to be cheap/simple devices.
It was pointed out at the open mike session in Chicago that this
particular "axiom" was just a description of what suited the 1980s
networks, and should be reconsidered now.  (Not necessarily changed,
just reconsidered.)

<DC> Just want to state that I am not all for dirty cheap routers, but simply routers where added complexity is well justified.
</DC>

> Fortunately most routers adopt droptail queues.

Why is it that fortunate?  It ensures large queueing delays and makes
ECN impossible (increasing loss/inefficiency).

<DC> Not necessarily. If you assume current TCPs, than I can see your concern. That is, if TCPs slow down only as a reaction to packet drop, then routers should signal "random" drops in advance in order to keep their queues at low filling levels. But IMO it is much easier to fix and end-point behavior so as to shift the cc operating point to a low queueing delay, than to instruct every router to try and trigger a rate reduction in order to keep their buffers' level low, which to me amounts to try to "fool" TCP senders into believing that router queues are about to overflow. In any event, let me restate that I agree that large queues are not the desirable operating point of a session/network.
</DC>

> I am not advocating routers
> imposing "unecessary queue delays" (I am not sure what you mean by that)

As I pointed out, routers which drop packets based on a virtual queue
will not incur queueing delays when they are congested.  Any queueing
delay which is not due to the buffer smoothing packet-level burstiness
is unnecessary.

(An example of a protocol which forces unncessary queueing delay is
Reno, which forces people to buffer one bandwidth-delay product of
data so that a single flow can get high utilisation.  If we didn't use
Reno, queueing delays would be much smaller, improving user QoS.)

<DC> Again, I concur with your point. I am just not sure that I agree with the remedy. However, there can be many solutions to decreasing queueing delays in a TCP session, so we dont need to agree on a single one (but hopefully will understand each other's solution :-). Our experience with Reno shows a "medium" bottleneck queue utilization (filling level). There are less agressive protocols (our :-), CCP), and more aggressive ones (Fast).

Dirceu
</DC>

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

       
____________________________________________________________________________________
Need a vacation? Get great deals
to amazing places on Yahoo! Travel.
http://travel.yahoo.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070809/e5029444/attachment.html
>From [email-masked]  Fri Aug 10 00:37:48 2007
From: [email-masked] (Lachlan Andrew)
Date: Fri Aug 10 00:39:36 2007
Subject: [Iccrg] LT-TCP followup
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Greetings Dirceu,

On 09/08/07, Dirceu Cavendish <[email-masked]> wrote:
>
> I sense we are in violent agreement in various points

*grin*  Yep, I think so.

> Our experience with
> Reno shows a "medium" bottleneck queue utilization (filling level). There
> are less agressive protocols (our :-), CCP), and more aggressive ones
> (Fast).

Certainly there are more aggressive protocols than Reno.  Regarding
FAST, it depends a lot on the setting of its parameter "alpha" and the
number of flows actually bottlenecked at one router.  There are
variants of FAST which scale much better with the number of flows than
the NS2 version does.

Cheers,
Lachlan

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

From: [email-masked] (Dirceu Cavendish)
Date: Thu Aug  9 18:39:12 2007
Subject: [Iccrg] LT-TCP followup
Message-ID: <[email-masked]>

Hi Andrew.

Passive congestion probing is appealing because it does not require specific signalling from routers, hence it can be deployed with little effort. On the other hand, specific router behavior may interfere with some such passive schemes.
But that is the same as specific receiver misbehavior (either maliciously or not).
I guess it is widespread consensus today that complexity at the end points is best, so routers should keep its simplicity (not belittling routers many functions of today). Fortunately most routers adopt droptail queues. It is up to IETF to point to the direction most appropriate for queue management, and hence, router behavior of the future. I am not advocating routers imposing "unecessary queue delays" (I am not sure what you mean by that) for the purpose of congestion signalling. Explicit signalling requires specific router behavior from the get go, AND it is difficult to guarantee anything if not adopted by all routers on a session path. Even worse, performance of CC acting on explicit congestion information is not guaranteed even if ECN is supported by all routers on a session, assuming that routers generating such information is not aware of specific TCP session details, such as rtts, or speed of rate adjustments. In addition, it is hard to specify
 a particular ECN to be supported by routers, without nailing down what TCP senders will do with that information.

In my previous experience with designing network layer protocols, a big impairment was to overcome the hurdle of touching every single network element for deplying a new protocol. I've learned to be sympathetic to the issue. So it makes sense to me to ask: "how well can we design a CC scheme with as little new features from routers as possible?" Notice that I am not excluding ECN solutions - they could be overlayed on top of passive probing schemes, as they are currently on TCPs...

Dirceu

----- Original Message ----
From: Lachlan Andrew <[email-masked]>
To: Dirceu Cavendish <[email-masked]>
Cc: Michael Welzl <[email-masked]>; Shivkumar Kalyanaraman <[email-masked]>; "RAMAKRISHNAN, KADANGODE K (K. K.)" <[email-masked]>; [email-masked]; Vijay Subramanian <[email-masked]>
Sent: Thursday, August 9, 2007 10:08:57 AM
Subject: Re: [Iccrg] LT-TCP followup

Greetings Dirceu,

On 09/08/07, Dirceu Cavendish <[email-masked]> wrote:
>
> Various TCP variants today track rtts, which would allow differentiation
> between corruption loss and overflow loss. Obviously, in a extremely worst
> case scenario, a packet loss overflow could occur at a single packet with no
> "rtt evidence" (rtt increase) on "surrounding" packets of a TCP stream. But
> IMHO most of the scenarios I've seen, the rtt increase evidence is there.

In most current scenarios, RED isn't used.  If RED is used, congestion
loss can happen with negligible RTT increase.  An even more extreme
case would be a router which ran an AQM on a   virtual   queue, in
which case even severe congestion need not affect RTT at all (and
combined with ECN could give congestion indication without impairing
either loss or delay).

I'm all for considering both delay and loss, but we should think
carefully before encouraging a mechanism that relies too much on
delays, which may force future standards to mandate that routers
induce unnecessary delays during congestion.  I'd prefer to encourage
explicit signalling as the primary mechanism, and just use performance
degradation (loss, delay, jitter) if it is still present after we
account for the explicit signals.

Cheers,
Lachlan

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

       
____________________________________________________________________________________
Choose the right car based on your needs.  Check out Yahoo! Autos new Car Finder tool.
http://autos.yahoo.com/carfinder/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070809/f7ef995d/attachment.html
>From [email-masked]  Thu Aug  9 22:28:27 2007
From: [email-masked] (Lachlan Andrew)
Date: Thu Aug  9 22:30:02 2007
Subject: [Iccrg] LT-TCP followup
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Greetings Dirceu,

On 09/08/07, Dirceu Cavendish <[email-masked]> wrote:
> So it makes sense to me to ask: "how well can we design a CC scheme
> with as little new features from routers as possible?"

Agreed.  Larry Dunn has convinced me of that.

My point was that we ideally don't want to design protocols which
*rely* on undesirable  artefacts  of current networks, which we might
otherwise want (and be able) to get rid of.  One such artefact is that
current networks have very long queueing delay during congestion
(because of Reno's "need" for bandwidth-delay droptail buffers).

> Explicit signalling requires specific
> router behavior from the get go, AND it is difficult to guarantee anything
> if not adopted by all routers on a session path.

That is true if the explicit signalling is used to say "slow down".
What Michael proposed was something to say "*don't* slow down, that
wasn't congestion".  The absence of that signal doesn't break
anything.

If a single router on the path knows that it is wireless, and likely
to drop packets without congestion, then even if only that one router
implements the signalling, then we avoid unnecessary window halving.
The wireline/core routers needn't be touched.

Conversely, consider the case of implicit signalling:  A single
congested queue drops many packets without introducing queueing delay
(perhaps it has a small buffer).  If this treated as heavy
"corruption" by the congestion control, then the source doesn't slow
down enough, and congestion persists.

(Minor comments below.)

Cheers,
Lachlan

> specific router behavior may interfere with some such passive schemes.
> But that is the same as specific receiver misbehavior (either maliciously or
> not).

Sort of...  If we can devise a way for routers not to delay packets
despite persistent congestion, that is "progress", not "misbehaviour".
 However, if it causes all losses to be treated as non-congestion
losses and so breaks congestion control, it is likely to be
"disallowed" by the IETF.

> I guess it is widespread consensus today that complexity at the end points
> is best, so routers should keep its simplicity

Yes, although wireless devices are likely to be cheap/simple devices.
It was pointed out at the open mike session in Chicago that this
particular "axiom" was just a description of what suited the 1980s
networks, and should be reconsidered now.  (Not necessarily changed,
just reconsidered.)

> Fortunately most routers adopt droptail queues.

Why is it that fortunate?  It ensures large queueing delays and makes
ECN impossible (increasing loss/inefficiency).

> I am not advocating routers
> imposing "unecessary queue delays" (I am not sure what you mean by that)

As I pointed out, routers which drop packets based on a virtual queue
will not incur queueing delays when they are congested.  Any queueing
delay which is not due to the buffer smoothing packet-level burstiness
is unnecessary.

(An example of a protocol which forces unncessary queueing delay is
Reno, which forces people to buffer one bandwidth-delay product of
data so that a single flow can get high utilisation.  If we didn't use
Reno, queueing delays would be much smaller, improving user QoS.)

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

From: [email-masked] (Michael Welzl)
Date: Thu Aug  9 17:15:18 2007
Subject: [Iccrg] LT-TCP followup
References: <[email-masked]>
Message-ID: <000a01c7daa0$49502480$0200a8c0@fun>

>Various TCP variants today track rtts, which would allow differentiation
between corruption loss and overflow loss. >Obviously, in a extremely worst
case scenario, a packet loss overflow could occur at a single packet with no
"rtt >evidence" (rtt increase) on "surrounding" packets of a TCP stream. But
IMHO most of the scenarios I've seen, the rtt >increase evidence is there.

i know, and I think I didn't say anything to discourage using other
implicit feedback too; this being said, rtt increase is misleading too,
how do you distinguish a growing queue from link layer arq happening
because of corruption?

>Notice that mistakenly taken a corruption loss as overflow loss does not
necessarily have to have a big impact on a TCP >session. It is bad enough
for VJ (alpha=2) TCP, but other controllers can be much more "immune" to
sporadic "misreading" >of packet loss information.

ok, i can imagine that

cheers
michael

From: [email-masked] (Dirceu Cavendish)
Date: Thu Aug  9 17:18:28 2007
Subject: [Iccrg] LT-TCP followup
Message-ID: <[email-masked]>

Michael,

Various TCP variants today track rtts, which would allow differentiation between corruption loss and overflow loss. Obviously, in a extremely worst case scenario, a packet loss overflow could occur at a single packet with no "rtt evidence" (rtt increase) on "surrounding" packets of a TCP stream. But IMHO most of the scenarios I've seen, the rtt increase evidence is there.

Notice that mistakenly taken a corruption loss as overflow loss does not necessarily have to have a big impact on a TCP session. It is bad enough for VJ (alpha=2) TCP, but other controllers can be much more "immune" to sporadic "misreading" of packet loss information.

Dirceu

----- Original Message ----
From: Michael Welzl <[email-masked]>
To: Dirceu Cavendish <[email-masked]>
Cc: [email-masked]; Shivkumar Kalyanaraman <[email-masked]>; "RAMAKRISHNAN, KADANGODE K (K. K.)" <[email-masked]>; [email-masked]; Vijay Subramanian <[email-masked]>
Sent: Thursday, August 9, 2007 6:23:53 AM
Subject: Re: [Iccrg] LT-TCP followup

Hi,

It's worse: even with ECN all over the place, a queue
can overflow, and then a packet can be dropped due
to congestion. It's just less likely.

Hence, the only reliable way to avoid missing
a congestion signal in the Internet of today
is to assume that a packet loss is due to
congestion - which makes it impossible to rely
on the same signal as a sign of corruption - and
hence, an altogether different (i.e. explicit)
signal is the best way to signal corruption IMO

that's why I suggested using ETEN (and I agree
that your TCP variant would probably still work
very well if combined with it!)

cheers
michael

On Wed, 2007-08-08 at 10:47 -0700, Dirceu Cavendish wrote:
> The problem with ECN is that, as in any router assisted CC solution,
> it requires an all routers' support. If a single router is not ECN
> enabled, little can be guaranteed about CC's performance.
> Of course, any ECN solution in a mix path environment should perform
> at least as well as when there is no ECN router support at all in the
> session path. That is why I am more infavor of CC schemes with
> implicit CC info, not explicit. I believe it is possible to
> differentiate between (b) and (c) cases below with implicit feedback
> information...
>  
> Dirceu
> 
> 
> ----- Original Message ----
> From: Lachlan Andrew <[email-masked]>
> To: Shivkumar Kalyanaraman <[email-masked]>
> Cc: "RAMAKRISHNAN, KADANGODE K (K. K.)" <[email-masked]>;
> [email-masked]; Vijay Subramanian <[email-masked]>
> Sent: Wednesday, August 8, 2007 10:15:12 AM
> Subject: Re: [Iccrg] LT-TCP followup
> 
> Greetings Shiv,
> 
> If we use ECN to distinguish between congestion and loss, how can we
> detect that "there is loss that is caused due to congestion on the
> path (and ECN signals are absent)" and know to revert to TCP-SACK?
> 
> The problem is that the flow may be ECN-enabled, and there may be (a)
> some ECN packets, (b) some packets lost due to corruption, and (c)
> some packets lost due to congestion of a non-ECN queue.  How can we
> distinguish (b) from (c)?
> 
> Thanks,
> Lachlan
> 
> On 08/08/2007, Shivkumar Kalyanaraman <[email-masked]> wrote:
> >
> > If ECN is used, the likelihood of congestion related loss may be
> > minimized. However, if there is congestion related loss, because
> either
> > ECN is absent, or there are also end-systems that do not respond to
> ECN,
> > then LT-TCP will have a robust method for safely reverting back to
> > TCP-SACK behavior. When there is loss that is caused due to
> congestion
> > on the path (and ECN signals are absent), LT-TCP will revert back to
> > TCP-SACK.
> 
> > best
> > -Shiv
> >
> > On Mon, 6 Aug 2007, Michael Welzl wrote:
> >
> > > in the presence of
> > > packet loss (which can always be due to an overflowing queue,
> > > ECN notwithstanding), the right thing to do is to assume
> congestion.
> 
> 
> -- 
> Lachlan Andrew  Dept of Computer Science, Caltech
> 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
> Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 
> 
> 
> 
> ______________________________________________________________________
> Shape Yahoo! in your own image. Join our Network Research Panel today!
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

       
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070809/ac0e0999/attachment-0001.html
>From [email-masked]  Thu Aug  9 17:22:21 2007
From: [email-masked] (Dirceu Cavendish)
Date: Thu Aug  9 17:31:11 2007
Subject: [Iccrg] LT-TCP followup
Message-ID: <[email-masked]>

Michael,

----- Original Message ----
From: Michael Welzl <[email-masked]>
To: Dirceu Cavendish <[email-masked]>
Cc: [email-masked]; Shivkumar Kalyanaraman <[email-masked]>; "RAMAKRISHNAN, KADANGODE K (K. K.)" <[email-masked]>; [email-masked]; Vijay Subramanian <[email-masked]>
Sent: Thursday, August 9, 2007 9:13:55 AM
Subject: Re: [Iccrg] LT-TCP followup

>Various TCP variants today track rtts, which would allow differentiation
between corruption loss and overflow loss. >Obviously, in a extremely worst
case scenario, a packet loss overflow could occur at a single packet with no
"rtt >evidence" (rtt increase) on "surrounding" packets of a TCP stream. But
IMHO most of the scenarios I've seen, the rtt >increase evidence is there.

i know, and I think I didn't say anything to discourage using other
implicit feedback too; this being said, rtt increase is misleading too,
how do you distinguish a growing queue from link layer arq happening
because of corruption?

<DC> You may not WANT to distinguish between a L2 queue increase due to L2 corruption recovery schemes and a L3 router queue overflow. For instance, a L2 with retransmission may signal corruption to higher layers exactly by overflowing its interface queues. One can look at that as L2 corruption causing a decrease in the L2 link capacity, causing "congestion", similar to an AMC wireless link, that changes its coding/bit rate in response to channel fading.

Dirceu
</DC>

>Notice that mistakenly taken a corruption loss as overflow loss does not
necessarily have to have a big impact on a TCP >session. It is bad enough
for VJ (alpha=2) TCP, but other controllers can be much more "immune" to
sporadic "misreading" >of packet loss information.

ok, i can imagine that

cheers
michael

       
____________________________________________________________________________________
Got a little couch potato? 
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070809/7653a247/attachment.html
>From [email-masked]  Thu Aug  9 18:08:57 2007
From: [email-masked] (Lachlan Andrew)
Date: Thu Aug  9 18:09:55 2007
Subject: [Iccrg] LT-TCP followup
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Greetings Dirceu,

On 09/08/07, Dirceu Cavendish <[email-masked]> wrote:
>
> Various TCP variants today track rtts, which would allow differentiation
> between corruption loss and overflow loss. Obviously, in a extremely worst
> case scenario, a packet loss overflow could occur at a single packet with no
> "rtt evidence" (rtt increase) on "surrounding" packets of a TCP stream. But
> IMHO most of the scenarios I've seen, the rtt increase evidence is there.

In most current scenarios, RED isn't used.  If RED is used, congestion
loss can happen with negligible RTT increase.  An even more extreme
case would be a router which ran an AQM on a   virtual   queue, in
which case even severe congestion need not affect RTT at all (and
combined with ECN could give congestion indication without impairing
either loss or delay).

I'm all for considering both delay and loss, but we should think
carefully before encouraging a mechanism that relies too much on
delays, which may force future standards to mandate that routers
induce unnecessary delays during congestion.  I'd prefer to encourage
explicit signalling as the primary mechanism, and just use performance
degradation (loss, delay, jitter) if it is still present after we
account for the explicit signals.

Cheers,
Lachlan

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

From: [email-masked] (Michael Welzl)
Date: Thu Aug  9 15:10:01 2007
Subject: [Iccrg] Call for reviewers for CTCP
Message-ID: <[email-masked]>

Dear all,

As you probably know, the ICCRG has agreed to obtain reviews
on experimental congestion control proposals before they
are brought to the IETF. While the competence to actually
decide about acceptance or not is with the IETF, it is expected
that they will take our reviews into account. This process
is outlined here:
http://www.ietf.org/IESG/content/ions/drafts/ion-tsv-alt-cc.txt

Right now, we are looking for reviews on
draft-sridharan-tcpm-ctcp-00.txt:
http://research.microsoft.com/users/dthaler/draft-sridharan-tcpm-ctcp-00.txt

for which it was requested that the draft would eventually become
a WG item of the TCPM Working Group.

The authors recently sent a few related pointers to the list; if
you lost that message, it's here in the archive:
http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-July/000249.html

We would like to get feedback within 2 1/2 months
(earlier if possible).

If you're interested in doing a review, please send a note
to Wes and me. Reviews should be sent to the list; while
we explicitly encourage open reviews, you can also directly
send them to us for anonymization before reflecting them out
to the list, if desired.

Reviewers are strongly advised to:

* read draft-ietf-tsvwg-cc-alt-04:
  http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-cc-alt-04.txt

* consider not only the draft alone, but also papers referenced
  therein, where the authors should have carried out an evaluation
  of their mechanism, including studies which show the impact of the
  new mechanism on standard TCP. When looking at such studies,
  this document is recommended to be used for guidance:
  http://www.ietf.org/internet-drafts/draft-irtf-tmrg-metrics-09.txt

One main conclusion that we are looking for is whether you agree
with the statement on safeness which is included in the abstract
of the draft (and obviously, we'd like to know how you arrived
at your decision). The requirement for including such a statement
is specified in section 2 of draft-ietf-tsvwg-cc-alt-04:

  Each alternate congestion control algorithm published is required to
  include a statement in the abstract indicating whether or not the
  proposal is considered safe for use on the Internet.  Each alternate
  congestion control algorithm published is also required to include a
  statement in the abstract describing environments where the protocol
  is not recommended for deployment.  There may be environments where
  the protocol is deemed *safe* for use, but still is not
  *recommended* for use because it does not perform well for the user.

We expect reviewers to have thoroughly read all the necessary
material. Generally, the more careful, complete and descriptive
a review is the more credence it will be given.

Thanks in advance to anyone who volunteers!

Cheers,
Michael

From: [email-masked] (Wesley Eddy)
Date: Thu Aug  9 15:00:27 2007
Subject: [Iccrg] LT-TCP followup
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu, Aug 09, 2007 at 03:23:53PM +0200, Michael Welzl wrote:
> 
> that's why I suggested using ETEN (and I agree
> that your TCP variant would probably still work
> very well if combined with it!)
> 

Just as another participant, I think this is the right idea for making
this work practical.  Using ETEN's signaling, but LT-TCP's response
might be seen as combining the best features of each.

It also may be good to consider whether the raw rate of losses due to
errors is even easier or more robust to use than trying to signal
individual losses.  CETEN's signaling would provide this and could be
used with LT-TCP rather than the two responses that we explored
(weighted coin-flipping and adapting the decrease factor):

http://www.icir.org/mallman/papers/ceten-ccr-oct2004.ps

-- 
Wesley M. Eddy
Verizon Federal Network Systems

From: [email-masked] (Michael Welzl)
Date: Thu Aug  9 14:25:21 2007
Subject: [Iccrg] LT-TCP followup
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

It's worse: even with ECN all over the place, a queue
can overflow, and then a packet can be dropped due
to congestion. It's just less likely.

Hence, the only reliable way to avoid missing
a congestion signal in the Internet of today
is to assume that a packet loss is due to
congestion - which makes it impossible to rely
on the same signal as a sign of corruption - and
hence, an altogether different (i.e. explicit)
signal is the best way to signal corruption IMO

that's why I suggested using ETEN (and I agree
that your TCP variant would probably still work
very well if combined with it!)

cheers
michael

On Wed, 2007-08-08 at 10:47 -0700, Dirceu Cavendish wrote:
> The problem with ECN is that, as in any router assisted CC solution,
> it requires an all routers' support. If a single router is not ECN
> enabled, little can be guaranteed about CC's performance.
> Of course, any ECN solution in a mix path environment should perform
> at least as well as when there is no ECN router support at all in the
> session path. That is why I am more infavor of CC schemes with
> implicit CC info, not explicit. I believe it is possible to
> differentiate between (b) and (c) cases below with implicit feedback
> information...
>  
> Dirceu
> 
> 
> ----- Original Message ----
> From: Lachlan Andrew <[email-masked]>
> To: Shivkumar Kalyanaraman <[email-masked]>
> Cc: "RAMAKRISHNAN, KADANGODE K (K. K.)" <[email-masked]>;
> [email-masked]; Vijay Subramanian <[email-masked]>
> Sent: Wednesday, August 8, 2007 10:15:12 AM
> Subject: Re: [Iccrg] LT-TCP followup
> 
> Greetings Shiv,
> 
> If we use ECN to distinguish between congestion and loss, how can we
> detect that "there is loss that is caused due to congestion on the
> path (and ECN signals are absent)" and know to revert to TCP-SACK?
> 
> The problem is that the flow may be ECN-enabled, and there may be (a)
> some ECN packets, (b) some packets lost due to corruption, and (c)
> some packets lost due to congestion of a non-ECN queue.  How can we
> distinguish (b) from (c)?
> 
> Thanks,
> Lachlan
> 
> On 08/08/2007, Shivkumar Kalyanaraman <[email-masked]> wrote:
> >
> > If ECN is used, the likelihood of congestion related loss may be
> > minimized. However, if there is congestion related loss, because
> either
> > ECN is absent, or there are also end-systems that do not respond to
> ECN,
> > then LT-TCP will have a robust method for safely reverting back to
> > TCP-SACK behavior. When there is loss that is caused due to
> congestion
> > on the path (and ECN signals are absent), LT-TCP will revert back to
> > TCP-SACK.
> 
> > best
> > -Shiv
> >
> > On Mon, 6 Aug 2007, Michael Welzl wrote:
> >
> > > in the presence of
> > > packet loss (which can always be due to an overflowing queue,
> > > ECN notwithstanding), the right thing to do is to assume
> congestion.
> 
> 
> -- 
> Lachlan Andrew  Dept of Computer Science, Caltech
> 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
> Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 
> 
> 
> 
> ______________________________________________________________________
> Shape Yahoo! in your own image. Join our Network Research Panel today!
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Bob Briscoe)
Date: Wed Aug  8 20:24:54 2007
Subject: [Iccrg]  draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt
In-Reply-To: <[email-masked] m>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Lachlan,

At 02:30 08/08/2007, Lachlan Andrew wrote:
>Greetings Bob,
>
>On 07/08/07, dimitri papadimitriou <[email-masked]> wrote:
> > Bob Briscoe wrote:
> > > - what's the minimum information intensity of congestion notification
> > > (More than 1-bit per packet? Is sensing congestion delay variation a
> > > sufficient alternative?)
> >
> > yes this is imho an important point. would deserve additional discussion
> > on this list. i would distinguish intensity from encoding granularity
> > and significance.
>
>Yes, you raised this point in October last year too.  At the time, I
>think the consensus was that we need to distinguish between "1
>information-theoretic bit per packet" and "1 protocol bit per packet",
>which generally gives much less information.

Yes, this is what I was trying to say (badly) by using the word intensity.

>That may be related to
>Dimitri's point about separating the signalling rate from the
>semantics of the signal.
>
> >From a control theory point of view, there's recently been a lot of
>work on the minimum information-theoretic signal rate required to
>"stabilise" a system (e.g,
><http://www.ee.unimelb.edu.au/staff/gnair/NairPIEEE.pdf>).  I'm not
>sure how much of that relates to congestion control, where
>undershooting the rate is much preferable to overshooting.

Tx for ref

Cheers

Bob

>To decide how much feed back is "needed", we need to decide what
>performance measures to use, and what performance level is "needed" --
>e.g. do we need unused bandwidth to be taken up again within   x
>RTTs/seconds/minutes of being released by another flow?  Do we need
>overload to abate within  x  RTTs?
>
>Cheers,
>Lachlan
>
>--
>Lachlan Andrew  Dept of Computer Science, Caltech
>1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
>Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603

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

From: [email-masked] (Bob Briscoe)
Date: Wed Aug  8 19:49:25 2007
Subject: [Iccrg]  draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Dimitri,

At 23:45 07/08/2007, dimitri papadimitriou wrote:
>>Also:
>>- Is a good system & equipment design goal to sacrificially throttle 
>>bit-rate to avoid CPU overload (so the brain can still work out what to 
>>do about congestion)?
>
>what do you mean with "sacrificially throttle" ?

I guess I didn't explain myself well. We'd like researchers not to have to 
think up alternaitves to smart congestion control (e.g. XCP or even AQM) 
that achieve the same effect, but can be implemented in cheap, lower layer 
equipment. The research issue is whether we will be able to rely on the 
same 'sacrifical throttling' as we do now to avoid this issue.

Example 1/ A route lookup engine requires a certain min amount of time to 
do the most complex address lookup. Usually the line feeding a route lookup 
processor is sized so that even a stream of the smallest possible packets, 
with the lowest possible cache hit rate, couldn't arrive at the route 
lookup engine faster than it could look-up the addresses. In this case, the 
bit rate of the line is sized to effectively sacrifically throwing away 
excess packets to protect the route lookup processor.

Example 2/ Even if all the L3 routers feeding into the L2 network were 
outputting at line rate and the traffic matrix was the worst possible - all 
converging on the lowest capacity L2 switch - the capacities could be 
arranged so that any L2 switch could not ever be overloaded (aside from 
failures). Then if the operator wants everything to do AQM or ECN or 
something, only the L3 routers need to do AQM. The L2 switches don't have 
to have any AQM code, because they will 'never' get overloaded. So the L3 
routers are effectively sacrifically throttling traffic on behalf of the L2 
network.

Example 3/ A single transmission line is actually a degenerate case of both 
the above examples, where the queue feeding the line sacrificially 
throttles traffic so that the line doesn't have to discard excess traffic 
at the phy layer (where the analogue signal would screw up, instead of the 
queue discarding whole packets). However, this is an example where a 
processor is protecting a phys component, rather than the other way round.

My point was simply that we should be able to rely on sensible system 
design and not have to say that deploying smarts at all layers is a 
research issue. But, for the resons below (about packet sizes), we might 
have to worry about how to put smarts in lower layers as well.

>>- distinguishing per-packet congestion from per-byte congestion (similar 
>>problem to distinguishing congestion from wireless transmission losses)?
>
>you made that comment during the "corruption loss" discussion, do you see 
>this as a separate discussion point now ? note also relationship with the 
>packet size (former).

It's a separate discussion point. It just has strong parallels with the 
corruption loss issue (ie a solution to one might solve the other).

>>- ever-widening range of packet sizes: if design equipment for larger ave 
>>pkt size, gets overloaded with flurries of small packets.
>
>you made that comment during the "small packet size" discussion -> i
>guess this would like to see a discussion about impact wrt relative avg 
>size and range ?

Yup. Ideally as links get faster, we'd like to only have to deal with 
larger packets, but we're never going to be able to have a flag day 
stopping people sending smaller packets (partly because there will always 
be slower links connected to faster links in the Internet).

This is likely to become a big issue in the future when considered against 
the first point about sacrifical protection of processors by bit rate 
throttles: packet header processors will always have to be able to handle 
streams of packets with 0byte payloads.

Currently, we tend to assume congestion is by bits. But these worrying 
thoughts imply we could start to see more per-packet congestion appearing 
alongside per-bit congestion. That complicates matters greatly.

Background to this issue is discussed in 
draft-briscoe-tsvwg-byte-packet-marking-00.txt that I recently posted. But 
that I-D only hints at the 'sky is falling' thoughts of this email.

Cheers

Bob

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

From: [email-masked] (Dirceu Cavendish)
Date: Wed Aug  8 18:50:16 2007
Subject: [Iccrg] LT-TCP followup
Message-ID: <[email-masked]>

The problem with ECN is that, as in any router assisted CC solution, it requires an all routers' support. If a single router is not ECN enabled, little can be guaranteed about CC's performance.
Of course, any ECN solution in a mix path environment should perform at least as well as when there is no ECN router support at all in the session path. That is why I am more infavor of CC schemes with implicit CC info, not explicit. I believe it is possible to differentiate between (b) and (c) cases below with implicit feedback information...

Dirceu

----- Original Message ----
From: Lachlan Andrew <[email-masked]>
To: Shivkumar Kalyanaraman <[email-masked]>
Cc: "RAMAKRISHNAN, KADANGODE K (K. K.)" <[email-masked]>; [email-masked]; Vijay Subramanian <[email-masked]>
Sent: Wednesday, August 8, 2007 10:15:12 AM
Subject: Re: [Iccrg] LT-TCP followup

Greetings Shiv,

If we use ECN to distinguish between congestion and loss, how can we
detect that "there is loss that is caused due to congestion on the
path (and ECN signals are absent)" and know to revert to TCP-SACK?

The problem is that the flow may be ECN-enabled, and there may be (a)
some ECN packets, (b) some packets lost due to corruption, and (c)
some packets lost due to congestion of a non-ECN queue.  How can we
distinguish (b) from (c)?

Thanks,
Lachlan

On 08/08/2007, Shivkumar Kalyanaraman <[email-masked]> wrote:
>
> If ECN is used, the likelihood of congestion related loss may be
> minimized. However, if there is congestion related loss, because either
> ECN is absent, or there are also end-systems that do not respond to ECN,
> then LT-TCP will have a robust method for safely reverting back to
> TCP-SACK behavior. When there is loss that is caused due to congestion
> on the path (and ECN signals are absent), LT-TCP will revert back to
> TCP-SACK.

> best
> -Shiv
>
> On Mon, 6 Aug 2007, Michael Welzl wrote:
>
> > in the presence of
> > packet loss (which can always be due to an overflowing queue,
> > ECN notwithstanding), the right thing to do is to assume congestion.

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

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

       
____________________________________________________________________________________
Sick sense of humor? Visit Yahoo! TV's 
Comedy with an Edge to see what's on, when. 
http://tv.yahoo.com/collections/222
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070808/25546a10/attachment-0001.html
>From [email-masked]  Wed Aug  8 18:52:58 2007
From: [email-masked] (Cesar Marcondes)
Date: Wed Aug  8 18:54:29 2007
Subject: [Iccrg] ICCRG Meeting Presentation (TCP Libra and TCP Performance
	Evaluation Tool)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Dear Sally,

Thanks a lot for exposing our work.

Yes, I'm aware of the tool by by Gang Wang, Yong Xia, and David
Harrison. In fact, I have been investigating the other tool and also
reference in our website.

The difference should be that our tool aims comparative and
reproducible evaluations in complex network topologies and traffic
mix. So, as it is now, it may be considered in a later stage of TCP
evaluation, since, it focus on statistical behaviors. We are in touch
with the Yong Xia and Wang Gang and we look forward on a joint effort.

Thank again for your comments and we would appreciate further comments
and support.

Best regards,
Cesar

On 8/7/07, Sally Floyd <[email-masked]> wrote:
> Cesar -
>
> >    "TCP Evaluation Suite" - Assuming that the proposed congestion
> > control schemes would be in general used in the Internet, it is
> > important to study the interaction among flows of different schemes.
> > Thus, this new simulation "TCP evaluation suite" can assess
> > interaction among different congestion control proposals, by applying
> > the same experiment setup, including network configuration, flow
> > parameters, and workload. Finally, qualitative comparison automatic
> > graphs can be generated assessing flow-by-flow behavior of different
> > schemes.
>
> Thanks for the pointer to your TCP Evaluation Suite at
> "http://netlab.cs.ucla.edu/tcpsuite/".  I have added a pointer to
> it on the TMRG web page at "http://www.icir.org/tmrg/".
>
> Gang Wang, Yong Xia, and David Harrison have also worked on a TCP
> evaluation suite, discussed in their internet-draft
> draft-irtf-tmrg-ns2-tcp-tool-00.txt on "An NS2 TCP Evaluation Tool".
> Their tool is available from "http://labs.nec.com.cn/tcpeval.htm".
>
> The two TCP evaluation suites have somewhat different roles and
> purposes;  yours is based on NS-2 Linux, and is specifically focused
> on high bandwidth-delay environments.  Still, it seems to me that
> it would be good for someone to look at the differences between the
> two evaluation suites, and see where it would be useful for each
> evaluation suite to borrow scenarios or approaches from the other.
>
> Take care,
> - Sally
> http://www.icir.org/floyd/
>
>

From: [email-masked] (Lachlan Andrew)
Date: Wed Aug  8 18:16:13 2007
Subject: [Iccrg] LT-TCP followup
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Shiv,

If we use ECN to distinguish between congestion and loss, how can we
detect that "there is loss that is caused due to congestion on the
path (and ECN signals are absent)" and know to revert to TCP-SACK?

The problem is that the flow may be ECN-enabled, and there may be (a)
some ECN packets, (b) some packets lost due to corruption, and (c)
some packets lost due to congestion of a non-ECN queue.  How can we
distinguish (b) from (c)?

Thanks,
Lachlan

On 08/08/2007, Shivkumar Kalyanaraman <[email-masked]> wrote:
>
> If ECN is used, the likelihood of congestion related loss may be
> minimized. However, if there is congestion related loss, because either
> ECN is absent, or there are also end-systems that do not respond to ECN,
> then LT-TCP will have a robust method for safely reverting back to
> TCP-SACK behavior. When there is loss that is caused due to congestion
> on the path (and ECN signals are absent), LT-TCP will revert back to
> TCP-SACK.

> best
> -Shiv
>
> On Mon, 6 Aug 2007, Michael Welzl wrote:
>
> > in the presence of
> > packet loss (which can always be due to an overflowing queue,
> > ECN notwithstanding), the right thing to do is to assume congestion.

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

From: [email-masked] (Shivkumar Kalyanaraman)
Date: Wed Aug  8 17:41:16 2007
Subject: [Iccrg] LT-TCP followup
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Michael,

We used ECN as an unambiguous indication of congestion so that we could
disambiguate that from packet corruption. ECN has been in the standards
process and has been making steady progress both in the IETF standards
track and vendor implementation. This motivated our use of ECN. However,
if ETEN unambiguously signals corruption (instead of ECN), we could use
that approach as well. We would be happy to use whichever mechanism is
widely available and the group suggests that we use that. LT-TCP would
(we strongly believe) work equally well with either approach.

If ECN is used, the likelihood of congestion related loss may be
minimized. However, if there is congestion related loss, because either
ECN is absent, or there are also end-systems that do not respond to ECN,
then LT-TCP will have a robust method for safely reverting back to
TCP-SACK behavior. When there is loss that is caused due to congestion
on the path (and ECN signals are absent), LT-TCP will revert back to
TCP-SACK.

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

On Mon, 6 Aug 2007, Michael Welzl wrote:

> Hi,
>
> While, as you know, I'm a fan of the LT-TCP idea, this:
>
> > KK> This is not quite correct. Let me clarify what we do. We respond to
> > congestion, in the same way that TCP does and we depend on ECN for
> > congestion indications. So, to that extent, we are following the "letter
> > of the law" for TCP. If ECN exists in the end-end path and works as it
> > is intended to, then "lost packets" would be primarily due to corruption
> > and not congestion. In the past, the design of TCP has intricately tied
> > together the reliability and congestion components together, with the
> > strong assumption that packet loss implied congestion. It was
> > by-and-large true then, because we didn't have as much wireless as we
> > have today or might have in the future. So, if the intent and "law" of
> > TCP is to respond to congestion, then we try to remain within those
> > boundaries.
>
> ...is unacceptable in my opinion. It's okay as a theoretical
> exercise, but I wouldn't want to see a practical solution
> assume that only ECN signals congestion, and packet loss
> doesn't.
>
> As I mentioned before, the right thing to do would be to flip
> it around, and *only* assume that there was corruption when you
> have a reliable signal saying so. Otherwise, in the presence of
> packet loss (which can always be due to an overflowing queue,
> ECN notwithstanding), the right thing to do is to assume congestion.
>
> Examples of such signals include the data checksum option in
> DCCP, and ETEN:  http://www.ir.bbn.com/projects/pace/eten/
> ... and (sorry for repeating myself) ETEN+LT-TCP would be a
> real winner in my opinion.
>
> Cheers,
> Michael
>
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

From: [email-masked] (Michael Welzl)
Date: Wed Aug  8 15:49:11 2007
Subject: [Iccrg]  draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi all,

Just a quick comment (and only my personal opinion): somehow,
this discussion ended up on the ICCRG list, but I think that
this document is not even in shape for a broader review from
the group up to now.

Personally, my suggestion would be not to waste your time
with half baked stuff, and just give it some more time
before we get back to you with it.

But that's of course only my very personal opinion...

Cheers,
Michael

On Wed, 2007-08-08 at 10:14 +0200, dimitri papadimitriou wrote:
> dirceu
> 
> Dirceu Cavendish wrote:
> > Dimitri,
> > 
> > Comments on my first pass on you document follows. 
> 
> i will address along the the review (stay tuned)
> 
> > Quick question: 
> > is the document main purpose to only raise CC questions/issues? 
> > Or to also eventually capture/document answers to those issues?
> 
> main purpose is description/analysis of open problems/issues in Internet
> congestion control (at least those known today) that have research 
> potential
> 
> if a (partial) answer or initial results are progressively maturing i 
> would then suggest to put them in perspective (but this document is not 
> the place to describe the resulting research activities)
> 
> much thanks for commenting,
> -dimitri.
> 
> > Rgds, Dirceu 
> > ***Comments:draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt
> > 
> > 
> > General comments: 1- There should be a session "CC objectives",
> > discussing previous (e.g. TCP) and what is understood to be
> > current/modern CC objectives. For instance, retransmission avoidance
> > and stability were not previous objectives. Also, RTT fairness was
> > not a concern in previous TCPs. As it is, the objectives are
> > scattered all over the document (e.g., session 3.1.1). The clearer
> > the objectives are, the easier the text discussion it will be.
> > 
> > 2- The document starts with router support as its first challenging
> > topic. Assuming a low to high level of complexity organization, the
> > first challenge should embrace address CC schemes that do not involve
> > router support at all. For instance, what are the limitation of CC
> > schemes that do not have router support. How much can routers "get in
> > the way" of such cc schemes. Another challenge/topic should be cc
> > with support for specific applications' requirements (quick ramp up,
> > no/minimum retransmissions, etc).
> > 
> > 3- The material strikes to me to be biased towards new CC protocols
> > with router support. It would be nice to have the "no router support"
> > in the discussions of the various topics. For instance, "3.6
> > Challenge 6: Multi-domain Congestion Control" material assumes
> > entirely ECN. An interesting question could be: "What type of CC can
> > we have that does not rely on router support?"
> > 
> > "With increasing the per-flow bandwidth-delay product increases, 
> > ~~~~~~~~~~
> > ~~~~~~~~~ TCP becomes inefficient and prone to instability,
> > regardless of the queuing scheme. XCP, which generalizes ECN, has
> > been developed to address these issues, using per-packet feedback. By
> > decoupling resource utilization/congestion control from fairness
> > control, XCP outperforms TCP in conventional and high bandwidth-delay
> >  environments, and remains efficient, fair, scalable, and stable 
> > regardless of the link capacity, the round trip delay, and the number
> >  of sources."
> > 
> > "[PAP02] shows that when flows with different RTTs are applied, XCP 
> > sometimes discriminates among heterogeneous traffic flows, even if 
> > ~~~~~~~ XCP is generally fair to different flows even if they belong
> > to ~~~~~~~ significantly heterogeneous flows." "- Is it possible to
> > design robust mechanisms that offer significant benefits without
> > additional risks?" ~~~~~ additional risks, or drawbacks? "procedures
> > one the one end, and additional per packet processing on ~~~ on the
> > other end of the solution space." "The congestion control algorithms
> > have to deal with this variety in ~~~^~~~ of conditions an efficient
> > way."
> > 
> > "In-band signaling can be considered to be an appropriate choice: 
> > Since notifications are piggy-packet along with data traffic, there 
> > ~~~~~~~~~~~~ piggybacked? is less overhead and implementation
> > complexity remains limited. Path- coupled out-of-band signaling could
> > however be possible, too."
> > 
> > 3.3 Challenge 3: Corruption Loss "The IETF has not yet specified how
> > a congestion control mechanism should react to corruption." To me,
> > transport layer CC reaction to corruption loss is a layer violation. 
> > I am not a purist on OSI layering, but there are practical
> > consequences to layering violation. For instance, is L4CC to react to
> > the corruption on every L2? If yes, should there be an standard way
> > of L2/L3 to report upward packet/frame corruption? Should (and could)
> > there be a single reaction way from a L4CC point of view to packet
> > corruption?
> > 
> > 3.5 Challenge 5: Pseudo-Wires I think that when discussing different
> > types of traffic, such as TDM, it should be mentioned how traffic
> > priorities can be played into the problem. This is because indeed
> > priority bits are available as a helper to differentiate packet 
> > delivery/interference. For instance, in the example of a second P2,
> > TDM traffic could be mapped into a higher priority traffic, in a
> > scenario where INTENTIONALLY P2 wants to squeeze "regular" TCP
> > streams out if needed be. This is what traffic engineering is about,
> > and it should not be ruled out as unlawful as TCP unfriendly. OF
> > course, in this case, P2 would receive packets from P1 with their
> > TOS/diffserv bits set accordingly.
> > 
> > 3.6 Challenge 6: Multi-domain Congestion Control There seems to be a
> > bias in the discussion towards explicit support of routers. Besides
> > the multi-domain CC example mentioned earlier, implicit feedback
> > could do away with proxy/gateway concerns on explicit feedback
> > information across domains. 3.7 Challenge 7: Precedence for Elastic
> > Traffic "The idea to distinguish several classes of best-effort
> > traffic dates ~~~~~(drop) is rather old, since it would be beneficial
> > to address the relative delay sensitivities of different elastic
> > applications."
> > 
> > 
> > 
> > ----- Original Message ---- From: dimitri papadimitriou
> > <[email-masked]> To: Bob Briscoe <[email-masked]> 
> > Cc: iccrg IRTF list <[email-masked]> Sent: Tuesday, August 7,
> > 2007 3:45:21 PM Subject: Re: [Iccrg]
> > draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt
> > 
> > 
> > bob
> > 
> > thx for the feedback - see inline
> > 
> > Bob Briscoe wrote:
> >> Michael, Dimitri,
> >> 
> >> During the presentation of this at the last ICCRG mtg I identified
> >> some extra challenges or adjuncts to the existing ones, which I'll
> >> record here and add a few review comments too (tho I'll do a full
> >> review later and at the same time I contribute some better
> >> thought-thru text if req'd).
> >> 
> >> Challenge 1 sort of misses the top level question that you
> >> (Michael) articulated well at the previous ICCRG mtg in LA: -
> >> What's the minimum support in network elements for future-proofed 
> >> (incl hi-speed) congestion control?
> > 
> > i would consider this as a baseline issue was probably overlooked in
> > the text but needs to be indeed spelled out
> > 
> >> Note the term "network elements" not "routers" - as Tim Shepard
> >> said, we have to work with congestion in lower layers too (and if
> >> doing explicit congestion notification, we have to propagate
> >> congestion info up the layers).
> > 
> > this will be part of the updated version (including the terminology)
> > 
> >> I can probably contribute text to "Challenge 8. Misbehaving S&Rs".
> >> For instance, I have a fair idea of which aspects of the DoS
> >> problem might be solved by better congestion control.
> > 
> > ok. any contribution along this challenge would help progressing the
> > document.
> > 
> >> I think we need a "Challenge 9: Multicast Congestion Control" Both
> >> streamed-media and messaging types of multicast.
> > 
> > agreed. a second cut should also look at higher hanging fruits. topic
> > was (side) discussed also with other contributors.
> > 
> >> Other more detailed questions:
> >> 
> >> An additional question in 3.1.4 (which should probably be entitled
> >>  feed-forward notification, not feedback) - what's the minimum
> >> information intensity of congestion notification (More than 1-bit
> >> per packet? Is sensing congestion delay variation a sufficient
> >> alternative?)
> > 
> > yes this is imho an important point. would deserve additional
> > discussion on this list. i would distinguish intensity from encoding
> > granularity and significance.
> > 
> >> Also: - Is a good system & equipment design goal to sacrificially
> >> throttle bit-rate to avoid CPU overload (so the brain can still
> >> work out what to do about congestion)?
> > 
> > what do you mean with "sacrificially throttle" ?
> > 
> >> - distinguishing per-packet congestion from per-byte congestion
> >> (similar problem to distinguishing congestion from wireless
> >> transmission losses)?
> > 
> > you made that comment during the "corruption loss" discussion, do you
> >  see this as a separate discussion point now ? note also relationship
> >  with the packet size (former).
> > 
> >> - ever-widening range of packet sizes: if design equipment for
> >> larger ave pkt size, gets overloaded with flurries of small
> >> packets.
> > 
> > you made that comment during the "small packet size" discussion -> i 
> > guess this would like to see a discussion about impact wrt relative
> > avg size and range ?
> > 
> > thx, -d.
> > 
> > _______________________________________________ Iccrg mailing list 
> > [email-masked] http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> > 
> > 
> > 
> > ____________________________________________________________________________________
> >  Be a better Globetrotter. Get better travel answers from someone who
> > knows. Yahoo! Answers - Check it out. 
> > http://answers.yahoo.com/dir/?link=list&sid=396545469
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Dirceu Cavendish)
Date: Wed Aug  8 03:10:15 2007
Subject: [Iccrg]  draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt
Message-ID: <[email-masked]>

Dimitri,

Comments on my first pass on you document follows. Quick question: is the document main purpose to only raise CC questions/issues? Or to also eventually capture/document answers to those issues?

Rgds,
Dirceu
***Comments:draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt

General comments:
1- There should be a session "CC objectives", discussing previous
(e.g. TCP) and what is understood to be current/modern CC objectives.
For instance, retransmission avoidance and stability were not previous
objectives. Also, RTT fairness was not a concern in previous TCPs.
As it is, the objectives are scattered all over the document
(e.g., session 3.1.1). The clearer the objectives are, the easier the text
discussion it will be.

2- The document starts with router support as its first challenging topic.
Assuming a low to high level of complexity organization, the first
challenge should embrace address CC schemes that do not involve router
support at all. For instance, what are the limitation of CC schemes that
do not have router support. How much can routers "get in the way" of
such cc schemes. Another challenge/topic should be cc with support for
specific applications' requirements (quick ramp up, no/minimum retransmissions, etc).

3- The material strikes to me to be biased towards new CC protocols with
router support. It would be nice to have the "no router support" in the discussions
of the various topics. For instance, "3.6 Challenge 6: Multi-domain Congestion Control"
material assumes entirely ECN. An interesting question could be: "What type of CC
can we have that does not rely on router support?"

"With increasing the per-flow bandwidth-delay product increases,
      ~~~~~~~~~~                                                   ~~~~~~~~~
TCP 
   becomes inefficient and prone to instability, regardless of the 
   queuing scheme. XCP, which generalizes ECN, has been developed to 
   address these issues, using per-packet feedback. By decoupling 
   resource utilization/congestion control from fairness control, XCP 
   outperforms TCP in conventional and high bandwidth-delay 
   environments, and remains efficient, fair, scalable, and stable 
   regardless of the link capacity, the round trip delay, and the number 
   of sources."

"[PAP02] shows that when flows with different RTTs are applied, XCP 
   sometimes discriminates among heterogeneous traffic flows, even if
                                                                                        ~~~~~~~
   XCP is generally fair to different flows even if they belong to
                                                        ~~~~~~~
   significantly heterogeneous flows."
"- Is it possible to design robust mechanisms that offer significant  
     benefits without additional risks?"
                                 ~~~~~ additional risks, or drawbacks?
"procedures one the one end, and additional per packet processing on
           ~~~ on
   the other end of the solution space."
"The congestion control algorithms have to deal with this variety in
                                                                                       ~~~^~~~ of conditions 
   an efficient way."

"In-band signaling can be considered to be an appropriate choice: 
   Since notifications are piggy-packet along with data traffic, there
                           ~~~~~~~~~~~~ piggybacked? 
   is less overhead and implementation complexity remains limited. Path-
   coupled out-of-band signaling could however be possible, too."

3.3 Challenge 3: Corruption Loss 
    "The IETF has not yet specified how a congestion control mechanism 
   should react to corruption."
To me, transport layer CC reaction to corruption loss is a layer violation.
I am not a purist on OSI layering, but there are practical consequences to
layering violation. For instance, is L4CC to react to the corruption on
every L2? If yes, should there be an standard way of L2/L3 to report upward
packet/frame corruption? Should (and could) there be a single reaction way
from a L4CC point of view to packet corruption?

3.5 Challenge 5: Pseudo-Wires
I think that when discussing different types of traffic, such as TDM, it should
be mentioned how traffic priorities can be played into the problem. This is
because indeed priority bits are available as a helper to differentiate packet
delivery/interference. For instance, in the example of a second P2, TDM traffic could
be mapped into a higher priority traffic, in a scenario where INTENTIONALLY P2 wants
to squeeze "regular" TCP streams out if needed be. This is what traffic engineering
is about, and it should not be ruled out as unlawful as TCP unfriendly. OF course,
in this case, P2 would receive packets from P1 with their TOS/diffserv bits set
accordingly.

3.6 Challenge 6: Multi-domain Congestion Control 
There seems to be a bias in the discussion towards explicit support of routers.
Besides the multi-domain CC example mentioned earlier, implicit feedback could do
away with proxy/gateway concerns on explicit feedback information across domains.
3.7 Challenge 7: Precedence for Elastic Traffic
"The idea to distinguish several classes of best-effort traffic dates 
                                                                ~~~~~(drop)
   is rather old, since it would be beneficial to address the relative 
   delay sensitivities of different elastic applications."

----- Original Message ----
From: dimitri papadimitriou <[email-masked]>
To: Bob Briscoe <[email-masked]>
Cc: iccrg IRTF list <[email-masked]>
Sent: Tuesday, August 7, 2007 3:45:21 PM
Subject: Re: [Iccrg] draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt

bob

thx for the feedback - see inline

Bob Briscoe wrote:
> Michael, Dimitri,
> 
> During the presentation of this at the last ICCRG mtg I identified some 
> extra challenges or adjuncts to the existing ones, which I'll record 
> here and add a few review comments too (tho I'll do a full review later 
> and at the same time I contribute some better thought-thru text if req'd).
> 
> Challenge 1 sort of misses the top level question that you (Michael) 
> articulated well at the previous ICCRG mtg in LA:
> - What's the minimum support in network elements for future-proofed 
> (incl hi-speed) congestion control?

i would consider this as a baseline issue was probably overlooked
in the text but needs to be indeed spelled out

> Note the term "network elements" not "routers" - as Tim Shepard said, we 
> have to work with congestion in lower layers too (and if doing explicit 
> congestion notification, we have to propagate congestion info up the 
> layers).

this will be part of the updated version (including the
terminology)

> I can probably contribute text to "Challenge 8. Misbehaving S&Rs". For 
> instance, I have a fair idea of which aspects of the DoS problem might 
> be solved by better congestion control.

ok. any contribution along this challenge would help progressing
the document.

> I think we need a "Challenge 9: Multicast Congestion Control"
> Both streamed-media and messaging types of multicast.

agreed. a second cut should also look at higher hanging fruits.
topic was (side) discussed also with other contributors.

> Other more detailed questions:
> 
> An additional question in 3.1.4 (which should probably be entitled 
> feed-forward notification, not feedback)
> - what's the minimum information intensity of congestion notification 
> (More than 1-bit per packet? Is sensing congestion delay variation a 
> sufficient alternative?)

yes this is imho an important point. would deserve additional discussion
on this list. i would distinguish intensity from encoding granularity 
and significance.

> Also:
> - Is a good system & equipment design goal to sacrificially throttle 
> bit-rate to avoid CPU overload (so the brain can still work out what to 
> do about congestion)?

what do you mean with "sacrificially throttle" ?

> - distinguishing per-packet congestion from per-byte congestion (similar 
> problem to distinguishing congestion from wireless transmission losses)?

you made that comment during the "corruption loss" discussion, do you 
see this as a separate discussion point now ? note also relationship 
with the packet size (former).

> - ever-widening range of packet sizes: if design equipment for larger 
> ave pkt size, gets overloaded with flurries of small packets.

you made that comment during the "small packet size" discussion -> i
guess this would like to see a discussion about impact wrt relative avg 
size and range ?

thx,
-d.

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

       
____________________________________________________________________________________
Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070807/5638fb57/attachment-0001.html
>From [email-masked]  Wed Aug  8 04:03:48 2007
From: [email-masked] (Dirceu Cavendish)
Date: Wed Aug  8 08:47:15 2007
Subject: [Iccrg] 
	draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt
Message-ID: <[email-masked]>

Creeping up into other people's topic, if I am allowed...

----- Original Message ----
From: Lachlan Andrew <[email-masked]>
To: [email-masked]; [email-masked]
Cc: iccrg IRTF list <[email-masked]>
Sent: Tuesday, August 7, 2007 6:30:31 PM
Subject: Re: [Iccrg] draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt

[lots of stuff deleted, so as to focus on a specific point...]

>From a control theory point of view, there's recently been a lot of
work on the minimum information-theoretic signal rate required to
"stabilise" a system (e.g,
<http://www.ee.unimelb.edu.au/staff/gnair/NairPIEEE.pdf>).  I'm not
sure how much of that relates to congestion control, where
undershooting the rate is much preferable to overshooting.

To decide how much feed back is "needed", we need to decide what
performance measures to use, and what performance level is "needed" --
e.g. do we need unused bandwidth to be taken up again within   x
RTTs/seconds/minutes of being released by another flow?  Do we need
overload to abate within  x  RTTs?

<DC> I am assuming that "how much feedback is needed" to mean how often feedback info
should be received from the context above. From a control theoretical point of view, a CC
scheme tries to "follow" the dynamics of the disturbance of the system, which in this case can
be taken as available bandwidth (could be something else, such as queue levels). Suppose that as the result of a disturbance at time To, the response curve of the monitored variable has a maximum frequency component of Fmax. Then, we need to "sample" this variable at least as much as 2 x Fmax, the Nyquist sampling frequency. Obviously that this fact plays a role only on schemes that the "monitored variable" is multibit. For a single bit variable, such as loss, one needs to sample the system as often as the "bit flips". In practical terms, it means that for loss based AIMD CC the controller needs to be informed at every loss event.
<DC/>

Cheers,
Lachlan

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

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

       
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. 
http://answers.yahoo.com/dir/?link=list&sid=396545433
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070807/a5ee7738/attachment.html
>From [email-masked]  Wed Aug  8 09:14:03 2007
From: [email-masked] (dimitri papadimitriou)
Date: Wed Aug  8 09:44:20 2007
Subject: [Iccrg] 
	draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

dirceu

Dirceu Cavendish wrote:
> Dimitri,
> 
> Comments on my first pass on you document follows. 

i will address along the the review (stay tuned)

> Quick question: 
> is the document main purpose to only raise CC questions/issues? 
> Or to also eventually capture/document answers to those issues?

main purpose is description/analysis of open problems/issues in Internet
congestion control (at least those known today) that have research 
potential

if a (partial) answer or initial results are progressively maturing i 
would then suggest to put them in perspective (but this document is not 
the place to describe the resulting research activities)

much thanks for commenting,
-dimitri.

> Rgds, Dirceu 
> ***Comments:draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt
> 
> 
> General comments: 1- There should be a session "CC objectives",
> discussing previous (e.g. TCP) and what is understood to be
> current/modern CC objectives. For instance, retransmission avoidance
> and stability were not previous objectives. Also, RTT fairness was
> not a concern in previous TCPs. As it is, the objectives are
> scattered all over the document (e.g., session 3.1.1). The clearer
> the objectives are, the easier the text discussion it will be.
> 
> 2- The document starts with router support as its first challenging
> topic. Assuming a low to high level of complexity organization, the
> first challenge should embrace address CC schemes that do not involve
> router support at all. For instance, what are the limitation of CC
> schemes that do not have router support. How much can routers "get in
> the way" of such cc schemes. Another challenge/topic should be cc
> with support for specific applications' requirements (quick ramp up,
> no/minimum retransmissions, etc).
> 
> 3- The material strikes to me to be biased towards new CC protocols
> with router support. It would be nice to have the "no router support"
> in the discussions of the various topics. For instance, "3.6
> Challenge 6: Multi-domain Congestion Control" material assumes
> entirely ECN. An interesting question could be: "What type of CC can
> we have that does not rely on router support?"
> 
> "With increasing the per-flow bandwidth-delay product increases, 
> ~~~~~~~~~~
> ~~~~~~~~~ TCP becomes inefficient and prone to instability,
> regardless of the queuing scheme. XCP, which generalizes ECN, has
> been developed to address these issues, using per-packet feedback. By
> decoupling resource utilization/congestion control from fairness
> control, XCP outperforms TCP in conventional and high bandwidth-delay
>  environments, and remains efficient, fair, scalable, and stable 
> regardless of the link capacity, the round trip delay, and the number
>  of sources."
> 
> "[PAP02] shows that when flows with different RTTs are applied, XCP 
> sometimes discriminates among heterogeneous traffic flows, even if 
> ~~~~~~~ XCP is generally fair to different flows even if they belong
> to ~~~~~~~ significantly heterogeneous flows." "- Is it possible to
> design robust mechanisms that offer significant benefits without
> additional risks?" ~~~~~ additional risks, or drawbacks? "procedures
> one the one end, and additional per packet processing on ~~~ on the
> other end of the solution space." "The congestion control algorithms
> have to deal with this variety in ~~~^~~~ of conditions an efficient
> way."
> 
> "In-band signaling can be considered to be an appropriate choice: 
> Since notifications are piggy-packet along with data traffic, there 
> ~~~~~~~~~~~~ piggybacked? is less overhead and implementation
> complexity remains limited. Path- coupled out-of-band signaling could
> however be possible, too."
> 
> 3.3 Challenge 3: Corruption Loss "The IETF has not yet specified how
> a congestion control mechanism should react to corruption." To me,
> transport layer CC reaction to corruption loss is a layer violation. 
> I am not a purist on OSI layering, but there are practical
> consequences to layering violation. For instance, is L4CC to react to
> the corruption on every L2? If yes, should there be an standard way
> of L2/L3 to report upward packet/frame corruption? Should (and could)
> there be a single reaction way from a L4CC point of view to packet
> corruption?
> 
> 3.5 Challenge 5: Pseudo-Wires I think that when discussing different
> types of traffic, such as TDM, it should be mentioned how traffic
> priorities can be played into the problem. This is because indeed
> priority bits are available as a helper to differentiate packet 
> delivery/interference. For instance, in the example of a second P2,
> TDM traffic could be mapped into a higher priority traffic, in a
> scenario where INTENTIONALLY P2 wants to squeeze "regular" TCP
> streams out if needed be. This is what traffic engineering is about,
> and it should not be ruled out as unlawful as TCP unfriendly. OF
> course, in this case, P2 would receive packets from P1 with their
> TOS/diffserv bits set accordingly.
> 
> 3.6 Challenge 6: Multi-domain Congestion Control There seems to be a
> bias in the discussion towards explicit support of routers. Besides
> the multi-domain CC example mentioned earlier, implicit feedback
> could do away with proxy/gateway concerns on explicit feedback
> information across domains. 3.7 Challenge 7: Precedence for Elastic
> Traffic "The idea to distinguish several classes of best-effort
> traffic dates ~~~~~(drop) is rather old, since it would be beneficial
> to address the relative delay sensitivities of different elastic
> applications."
> 
> 
> 
> ----- Original Message ---- From: dimitri papadimitriou
> <[email-masked]> To: Bob Briscoe <[email-masked]> 
> Cc: iccrg IRTF list <[email-masked]> Sent: Tuesday, August 7,
> 2007 3:45:21 PM Subject: Re: [Iccrg]
> draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt
> 
> 
> bob
> 
> thx for the feedback - see inline
> 
> Bob Briscoe wrote:
>> Michael, Dimitri,
>> 
>> During the presentation of this at the last ICCRG mtg I identified
>> some extra challenges or adjuncts to the existing ones, which I'll
>> record here and add a few review comments too (tho I'll do a full
>> review later and at the same time I contribute some better
>> thought-thru text if req'd).
>> 
>> Challenge 1 sort of misses the top level question that you
>> (Michael) articulated well at the previous ICCRG mtg in LA: -
>> What's the minimum support in network elements for future-proofed 
>> (incl hi-speed) congestion control?
> 
> i would consider this as a baseline issue was probably overlooked in
> the text but needs to be indeed spelled out
> 
>> Note the term "network elements" not "routers" - as Tim Shepard
>> said, we have to work with congestion in lower layers too (and if
>> doing explicit congestion notification, we have to propagate
>> congestion info up the layers).
> 
> this will be part of the updated version (including the terminology)
> 
>> I can probably contribute text to "Challenge 8. Misbehaving S&Rs".
>> For instance, I have a fair idea of which aspects of the DoS
>> problem might be solved by better congestion control.
> 
> ok. any contribution along this challenge would help progressing the
> document.
> 
>> I think we need a "Challenge 9: Multicast Congestion Control" Both
>> streamed-media and messaging types of multicast.
> 
> agreed. a second cut should also look at higher hanging fruits. topic
> was (side) discussed also with other contributors.
> 
>> Other more detailed questions:
>> 
>> An additional question in 3.1.4 (which should probably be entitled
>>  feed-forward notification, not feedback) - what's the minimum
>> information intensity of congestion notification (More than 1-bit
>> per packet? Is sensing congestion delay variation a sufficient
>> alternative?)
> 
> yes this is imho an important point. would deserve additional
> discussion on this list. i would distinguish intensity from encoding
> granularity and significance.
> 
>> Also: - Is a good system & equipment design goal to sacrificially
>> throttle bit-rate to avoid CPU overload (so the brain can still
>> work out what to do about congestion)?
> 
> what do you mean with "sacrificially throttle" ?
> 
>> - distinguishing per-packet congestion from per-byte congestion
>> (similar problem to distinguishing congestion from wireless
>> transmission losses)?
> 
> you made that comment during the "corruption loss" discussion, do you
>  see this as a separate discussion point now ? note also relationship
>  with the packet size (former).
> 
>> - ever-widening range of packet sizes: if design equipment for
>> larger ave pkt size, gets overloaded with flurries of small
>> packets.
> 
> you made that comment during the "small packet size" discussion -> i 
> guess this would like to see a discussion about impact wrt relative
> avg size and range ?
> 
> thx, -d.
> 
> _______________________________________________ Iccrg mailing list 
> [email-masked] http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 
> 
> 
> ____________________________________________________________________________________
>  Be a better Globetrotter. Get better travel answers from someone who
> knows. Yahoo! Answers - Check it out. 
> http://answers.yahoo.com/dir/?link=list&sid=396545469

From: [email-masked] (Lachlan Andrew)
Date: Wed Aug  8 02:31:51 2007
Subject: [Iccrg]  draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Bob,

On 07/08/07, dimitri papadimitriou <[email-masked]> wrote:
> Bob Briscoe wrote:
> > - what's the minimum information intensity of congestion notification
> > (More than 1-bit per packet? Is sensing congestion delay variation a
> > sufficient alternative?)
>
> yes this is imho an important point. would deserve additional discussion
> on this list. i would distinguish intensity from encoding granularity
> and significance.

Yes, you raised this point in October last year too.  At the time, I
think the consensus was that we need to distinguish between "1
information-theoretic bit per packet" and "1 protocol bit per packet",
which generally gives much less information.  That may be related to
Dimitri's point about separating the signalling rate from the
semantics of the signal.

>From a control theory point of view, there's recently been a lot of
work on the minimum information-theoretic signal rate required to
"stabilise" a system (e.g,
<http://www.ee.unimelb.edu.au/staff/gnair/NairPIEEE.pdf>).  I'm not
sure how much of that relates to congestion control, where
undershooting the rate is much preferable to overshooting.

To decide how much feed back is "needed", we need to decide what
performance measures to use, and what performance level is "needed" --
e.g. do we need unused bandwidth to be taken up again within   x
RTTs/seconds/minutes of being released by another flow?  Do we need
overload to abate within  x  RTTs?

Cheers,
Lachlan

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

From: [email-masked] (Sally Floyd)
Date: Wed Aug  8 00:11:20 2007
Subject: [Iccrg] ICCRG Meeting Presentation (TCP Libra and TCP Performance Evaluation Tool)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Cesar -

>    "TCP Evaluation Suite" - Assuming that the proposed congestion
> control schemes would be in general used in the Internet, it is
> important to study the interaction among flows of different schemes.
> Thus, this new simulation "TCP evaluation suite" can assess
> interaction among different congestion control proposals, by applying
> the same experiment setup, including network configuration, flow
> parameters, and workload. Finally, qualitative comparison automatic
> graphs can be generated assessing flow-by-flow behavior of different
> schemes.

Thanks for the pointer to your TCP Evaluation Suite at
"http://netlab.cs.ucla.edu/tcpsuite/".  I have added a pointer to
it on the TMRG web page at "http://www.icir.org/tmrg/".

Gang Wang, Yong Xia, and David Harrison have also worked on a TCP
evaluation suite, discussed in their internet-draft
draft-irtf-tmrg-ns2-tcp-tool-00.txt on "An NS2 TCP Evaluation Tool".
Their tool is available from "http://labs.nec.com.cn/tcpeval.htm".

The two TCP evaluation suites have somewhat different roles and
purposes;  yours is based on NS-2 Linux, and is specifically focused
on high bandwidth-delay environments.  Still, it seems to me that
it would be good for someone to look at the differences between the
two evaluation suites, and see where it would be useful for each
evaluation suite to borrow scenarios or approaches from the other.

Take care,
- Sally
http://www.icir.org/floyd/

From: [email-masked] (dimitri papadimitriou)
Date: Tue Aug  7 23:46:49 2007
Subject: [Iccrg]  draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

bob

thx for the feedback - see inline

Bob Briscoe wrote:
> Michael, Dimitri,
> 
> During the presentation of this at the last ICCRG mtg I identified some 
> extra challenges or adjuncts to the existing ones, which I'll record 
> here and add a few review comments too (tho I'll do a full review later 
> and at the same time I contribute some better thought-thru text if req'd).
> 
> Challenge 1 sort of misses the top level question that you (Michael) 
> articulated well at the previous ICCRG mtg in LA:
> - What's the minimum support in network elements for future-proofed 
> (incl hi-speed) congestion control?

i would consider this as a baseline issue was probably overlooked
in the text but needs to be indeed spelled out

> Note the term "network elements" not "routers" - as Tim Shepard said, we 
> have to work with congestion in lower layers too (and if doing explicit 
> congestion notification, we have to propagate congestion info up the 
> layers).

this will be part of the updated version (including the
terminology)

> I can probably contribute text to "Challenge 8. Misbehaving S&Rs". For 
> instance, I have a fair idea of which aspects of the DoS problem might 
> be solved by better congestion control.

ok. any contribution along this challenge would help progressing
the document.

> I think we need a "Challenge 9: Multicast Congestion Control"
> Both streamed-media and messaging types of multicast.

agreed. a second cut should also look at higher hanging fruits.
topic was (side) discussed also with other contributors.

> Other more detailed questions:
> 
> An additional question in 3.1.4 (which should probably be entitled 
> feed-forward notification, not feedback)
> - what's the minimum information intensity of congestion notification 
> (More than 1-bit per packet? Is sensing congestion delay variation a 
> sufficient alternative?)

yes this is imho an important point. would deserve additional discussion
on this list. i would distinguish intensity from encoding granularity 
and significance.

> Also:
> - Is a good system & equipment design goal to sacrificially throttle 
> bit-rate to avoid CPU overload (so the brain can still work out what to 
> do about congestion)?

what do you mean with "sacrificially throttle" ?

> - distinguishing per-packet congestion from per-byte congestion (similar 
> problem to distinguishing congestion from wireless transmission losses)?

you made that comment during the "corruption loss" discussion, do you 
see this as a separate discussion point now ? note also relationship 
with the packet size (former).

> - ever-widening range of packet sizes: if design equipment for larger 
> ave pkt size, gets overloaded with flurries of small packets.

you made that comment during the "small packet size" discussion -> i
guess this would like to see a discussion about impact wrt relative avg 
size and range ?

thx,
-d.

From: [email-masked] (Lachlan Andrew)
Date: Tue Aug  7 20:56:04 2007
Subject: [Iccrg] LT-TCP followup
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <002001c7d609$3e2a7c90$0200a8c0@fun> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Michael,

Executive summary:
- The "loss additivity" approximation is conservative.  TCP is more agressive.
- Assuming equal loss on multiple links introduces the worst case
error to that assumption.
- The "equal rate through the flow" assumption is only made in my
claim that TCP is  alpha=2 fair, not in our analysis of high loss
networks
- To discuss fairness, we need to separate "cost" from "benefit".

On 06/08/07, Michael Welzl <[email-masked]> wrote:
> > Applications certainly can produce variable rate data.
>
> ...the rate jumps to a higher value
> because the limit no longer exists". ... re-routing to a new path (which
> I'd consider a more reasonable example for a flow to suddenly cause
> a certain amount of congestion, as a congestion control mechanism would
> normally prevent an application from such "jumps").

Yes, rerouting could certainly cause that.  I wasn't meaning to imply
that the change was sudden -- I thought Jain's definition just refered
to the direction of the change.  But anyway, I think we roughly agree
here that TCP's current behaviour can (safely) induce what Jain called
congestion collapse.

> > For sources which produce congestion,  p  *is* very small.
> >  A window of a mere 10 packets needs roughly p = 10^-2.
>
> "For sources which produce congestion", p can be anything.

Ahh, yes.  If the flow doesn't follow TCP then  p  certainly can be
anything.  What I meant was "for a flow which reacts to congestion
(not corruption) like TCP does, any flow with a non-negligible  p
will be throttled to fewer than 10 packets, which will no longer cause
congestion".  On reflection, I agree 10 packets may still cause
congestion on a very slow link, or if enough flows do it.

However, that means that TCP is marginally *more* aggressive than what
I'm proposing.  It responds to the true aggregate receive loss rate,
and I'm suggesting responding to the (larger) sum of loss rates.  Of
course, when/if it comes to implementing this allocation, we may need
to revisit whether my suggestion of simply scaling the old TCP window
will be suitable.  It's not yet clear to me if that will be aggressive
or conservative.

> The larger p is, the more important I'd consider it to
> reasonably estimate it.

Agreed.  However, in "reasonable", I'd include a model more
conservative than the current Internet, which Kelly's sum model is.

> In the real Internet, p is very small indeed. However, p is
> also under the influence of your own flow, which will make
> the 2p estimate worse.

Yes, I was careless in how I listed "constant flow rate" in "assumptions".

It is one of the assumptions that I make in saying that TCP
corresponds to  alpha=2  fairness.  For the secnario in which TCP was
designed for, which assumes low-corruption, the influence of our own
flow will be the same on the two links, except for packets dropped due
to congestion.  Using ECN instead of dropping, those packets will also
influence the second link, and so this doesn't make  2p  any worse.

In the proposed high-corruption behaviour, we include the reduction in
load on later links the in model.  (That is why we only get "nice"
results for the case when corruption is only the last link, or only
before the first link.  The general case is still a work-in-progress,
but I expect it to be between these two extremes.)

> > > Since in fact p of the second hop will be less than
> > > p of the first hop
> >
> > a) Replace "loss" by "ECN" and this doesn't apply.
>
> Why? Just like packets can only be dropped once along
> a path, they can also only be ECN-marked once.

OK, I thought that you meant "the traffic will be reduced by the act
of congestion dropping", and so even in the symmetric case, there will
be marginally less congestion on the second link".  ECN will avoid
that one -- as mentioned above.

> > > with all these weird
> > > assumptions as a basis, it makes it hard for me to intuitively
> > > understand what you say.
> >
> > The assumptions are:
> > - flow rate is roughly constant through the life of the path -- which
> > is a 1% or better approximation for current networks
>
> Who says that?

Thanks for challenging me on this one.  It is worse than I had
expected.  I just checked <http://www.internettrafficreport.com/>  and
found that Australia (my home) has 0% loss, while the rest of the
world is hovering around an incredible 15%, meaning that TCP-compliant
windows are only about 4 packets!?!?

> Since the first hop is not unlikely to be the bottleneck,
> the outgoing rate after the first router can be significantly lower.

There can be transients while the queue is building, but in
equilibrium, ACK-clocking ensures that on average, what goes in either
goes on to the next hop, is dropped/marked due to congestion (which
adds to outgoing rate if ECN is used) or is corrupted (which the
design of the current TCP ignores, but is correctly handled as the
exception to this assumption in our model).

> parking lot scenario that we discussed, where you argue
> that the assumption that p of the two-hop flow is 2*p of
> the one-hop flows, we also have the assumption that p
> is constant throughout the network, which I absolutely
> don't believe to be true in reality.

Nor do I.  It is just the worst case.  Consider two links with  p_1
and  p_2 = k p_1, where  k<=1  without loss of generality.  Then
1-(1-p_1)(1-p_2) = (1+k)p_1 - k(p_1)^2.  The smaller  k  is (the less
equally the losses are shared), the smaller the error term is relative
to the sum term.  For example,
p_1 = 10%,  p_2 = 10%,  absolute error = 1%   relative error = 5%
p_1 = 10%,  p_2 = 4%, absolute error = 0.4%,  relative error = 3%
p_1 = 20%,  p_2 = 4%, absolute error = 0.8%,  relative error = 3%

> > - loss probability is cumulative through the network -- again 1% or better
>
> Who says that? Do you have measurements to back this up?

Before answering this:
1. Remember that this is conservative when modelling current TCP.  TCP
actually responds as if the loss probability is the  lower  of the two
values, while I'm proposing responding to the  higher  of the two
values.
2.  I was being slightly optimistic, and thinking of the *absolute*
error as being 1% loss or better.  The *relative* error could be up to
10% in some quite conceivable cases.

>From <http://www.icir.org/floyd/ccmeasure.html>, the global loss rate
was 4% in 2000.  If  that comes from  p = 4% on one link and none
elsewhere, then the sum rule is exact.  Otherwise, the worst case is
p_1 = 2%, p_2 = 2%, giving an absolute error of 0.04%, and a relative
error of 1%.

Of course, many individual flows will have higher loss rates.
However, as you pointed out, most flows (especially low rate = high
loss ones) have only one significant bottleneck at some point in the
access network.  In that case, the approximation is even better

> > - each "lost packet" causes one "loss event"
>
> Quite improbable. Losses are typically clustered in the
> Internet;

Granted.  In the theory community, it has been a "standard"
assumption, but on reflection I don't think I need it (see the better
approximation below).

> > - packet loss probability is equal for all flows
>
> I could live with this one if you'd assume that all
> flows traverse exactly the same path.

You're absolutely right.  I meant "packet loss probability   at a
given link   is equal for all flows".  Obviously if different flows
use different links then they can have totally unrelated loss rates :)

> > I believe they're all pretty standard...
>
> No, I think they're all completely wrong

*grin*  OK.  David and I will keep looking for evidence.

> > ...and more intuitive than
> > replacing the last two by something more accurate.

Actually, I take that back.  The last two can be replaced by:
- Each loss event is caused by a congestion event at a single queue
- Each flow using a queue has an equal probability of observing a
congestion event at that queue.

(I think the first of these actually also makes the "sum of loss
probabilities" point moot too, so that leaves us with these two plus
"- The total reduction in load due to congestion loss is small".)

The first is hard to verify because "congestion event" at a queue is
hard to define, and harder to measure.  However, I believe it is more
accurate than what I originally said, if most queues are droptail.  It
is certainly compatible with your observations, and it is also
compatible with the intuition of a queue which is almost overflowing
"bumping up against being full" several times before subsiding
appreciably.

I agree that the second isn't exact but this assumption, or some
variant, is the basis for any notion that it is even possible
loss-based congestion control to be fair.  It isn't quite accurate
when, for example, TFRC flows share with non-TFRC flows, but has only
recently been recognised as being an approximation rather than fact.
As evidence, I'd cite every paper that shows Reno over one link is
fair.

> Note that I'm not playing devil's advocate - I honestly
> believe that they're completely wrong. For instance,
> you'll probably lose some packets at some bottleneck
> along the path, and lose nothing in most other routers,
> as opposed to losing the same amount everywhere - if
> that's the case, this renders some of your assumptions
> above wrong.

OK.  The assumptions that I meant to say (as opposed to what I did
say...) are fairly standard.  I agree that you'll generally only have
one major bottleneck; if that seems to violate one of the assumption,
then I didn't explain the assumption clearly.  Which does it violate?

> > If we suddenly cause 10 times the congestion
> > per received packet, TCP would start giving us
> > data at about 1/3  ( 1/sqrt(10) ) the rate.
> >
> > If we want to have the same response when we suddently cause 10 times
> > the congestion per received packet because of 90% corruption, then we
> > need to send at a rate about 10/3 higher, so we still get data at a
> > rate of about 1/3 the original.
>
> I'm honestly very sorry, but I still don't get it. Why 10/3?

If you're happy that we want to *receive* at the same rate in the two
cases  (1/3 of the original short-route/corruption-free rate) then
sending at rate 10/3  times the original corruption-free rate follows
from the fact that we need to  send  at 10 times the rate that we
receive.

> > TCP originally specified sending rates because it specified an
> > algorithm run at the sender, not a fairness paradigm.  In a
> > non-collapsed world with reliable links, sending rate is approximately
> > receiving rate, so TCP essentially specifies both sending rates and
> > receiving rates.
>
> I can't live with the "non-collapsed world with a reliable links"
> assumption here. We're talking about severe cases in our examples -
> severe corruption, possibly severe congestion.

True.  I was talking about the world that VJ was trying to create, not
the one he was trying to avoid.  If everyone followed his TCP, then in
the "loss = congestion" world view, he was specifying the rate that
flow would achieve.

You're absolutely right that we're looking at a different case here,
which is why we need to revisit the principles rather than the
specifics.  To me, the principle is "everyone should get fair benefit,
balanced by how much congestion they cause".  Neither side of that
balance directly corresponds to sending rate, although it is related
to both.  VJ used send rate as a surrogate for both benefit and
congestion-causing, because Kelly hadn't come along yet to show us how
they relate.

> > Sending rate:  reflects actual harm done to the network.
> > Receiving rate:  determines actual benefit done to the user.
> >
> > In the tradeoff between congestion caused and data delivered,
> > the sensible (to me) "rate" of the flow is the data delivered.
>
> As a measure of "harm done to the network", I agree, but not
> as the rate that we want to control.

Sorry, I'm not sure what you mean.  It sounds like you think I'm
saying that "data delivered is a measure of harm done to the network",
which isn't what I meant.  The way I see it, we have
  Cost:    measured by corruption loss (or ECN, or ...)
  Benefit: data received by a flow
I believe we should decide how to balance these two (in a way which is
fair to existing flows) and then choose the sending rate to achieve
that.

> If you want to match the
> receive rate of TCP, I'd suggest to invent a new term  :)

OK, I'm happy to do that.  "TCP-fair" comes to mind.  The term
"minimum expected delay" has been used for this type of fairness, but
"square-root formula fair" may sound more familiar.  I'll call it
whatever is most likely to get it adopted :)

Cheers,
Lachlan

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

From: [email-masked] (Wesley Eddy)
Date: Tue Aug  7 15:14:50 2007
Subject: [Iccrg] Re: [tcpm] Compound TCP: draft-sridharan-tcpm-ctcp-00.txt
In-Reply-To: <[email-masked] nd.corp.microsoft.com>
References: <[email-masked] d.corp.microsoft.com> <[email-masked] osoft.com>
Message-ID: <[email-masked]>

On Thu, Jul 26, 2007 at 08:29:07AM -0700, Murari Sridharan wrote:
> Posting our IETF presentation and few papers (as requested by iccrg) in pdf format
> ...

I started a new IRTF wiki page for holding pointers relevant to CTCP
evaluation and put links to Murari's documents there along with some
others that google found:
http://www3.tools.ietf.org/group/irtf/trac/wiki/ICCRG_ctcp

If there are others that should be added, or if these should be modified,
please let me know.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

From: [email-masked] (Bela Berde)
Date: Tue Aug  7 13:38:58 2007
Subject: Fwd: Re: [Iccrg]  draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt
Message-ID: <[email-masked]>

-------- Original-Nachricht --------
Datum: Tue, 07 Aug 2007 14:36:11 +0200
Von: "Bela Berde" <[email-masked]>
An: Bob Briscoe <[email-masked]>
Betreff: Re: [Iccrg] 	draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt

Dear All,
The network element issue, as Bob identifies, is partly introduced in the unpublished version of the draft. 
This was in section Other Challenge 3.9.1 The text provides the idea of network elements for the specific support of the end-to-end congestion control. 
(The section is called "Distant Equipment for Congestion Control Support"; clearly distant means: not host-based.)
Here the word "support" can be broadened etc. 
Your comments are welcome.
Sincerely,
 
-------- Original-Nachricht --------
Datum: Tue, 07 Aug 2007 13:14:30 +0100
Von: Bob Briscoe <[email-masked]>
An: [email-masked], [email-masked]
CC: iccrg IRTF list <[email-masked]>
Betreff: [Iccrg] 	draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt

> Michael, Dimitri,
> 
> During the presentation of this at the last ICCRG mtg I identified some 
> extra challenges or adjuncts to the existing ones, which I'll record here 
> and add a few review comments too (tho I'll do a full review later and at 
> the same time I contribute some better thought-thru text if req'd).
> 
> Challenge 1 sort of misses the top level question that you (Michael) 
> articulated well at the previous ICCRG mtg in LA:
> - What's the minimum support in network elements for future-proofed (incl 
> hi-speed) congestion control?
> 
> Note the term "network elements" not "routers" - as Tim Shepard said, we 
> have to work with congestion in lower layers too (and if doing explicit 
> congestion notification, we have to propagate congestion info up the
> layers).
> 
> I can probably contribute text to "Challenge 8. Misbehaving S&Rs". For 
> instance, I have a fair idea of which aspects of the DoS problem might be 
> solved by better congestion control.
> 
> I think we need a "Challenge 9: Multicast Congestion Control"
> Both streamed-media and messaging types of multicast.
> 
> Other more detailed questions:
> 
> An additional question in 3.1.4 (which should probably be entitled 
> feed-forward notification, not feedback)
> - what's the minimum information intensity of congestion notification
> (More 
> than 1-bit per packet? Is sensing congestion delay variation a sufficient 
> alternative?)
> 
> Also:
> - Is a good system & equipment design goal to sacrificially throttle 
> bit-rate to avoid CPU overload (so the brain can still work out what to do
> about congestion)?
> - distinguishing per-packet congestion from per-byte congestion (similar 
> problem to distinguishing congestion from wireless transmission losses)?
> - ever-widening range of packet sizes: if design equipment for larger ave 
> pkt size, gets overloaded with flurries of small packets.
> 
> 
> 
> 
> Bob
> 
> 
> ____________________________________________________________________________
> Bob Briscoe, <[email-masked]>      Networks Research Centre, BT
> Research
> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473
> 645196 
> 
> 
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

-- 
Psssst! Schon vom neuen GMX MultiMessenger geh?rt?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

From: [email-masked] (Michael Welzl)
Date: Tue Aug  7 13:29:05 2007
Subject: [Iccrg]  Re: draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Tue, 2007-08-07 at 13:14 +0100, Bob Briscoe wrote:
> Michael, Dimitri,
> 
> During the presentation of this at the last ICCRG mtg I identified some 
> extra challenges or adjuncts to the existing ones, which I'll record here 
> and add a few review comments too (tho I'll do a full review later and at 
> the same time I contribute some better thought-thru text if req'd).

Great!

> Challenge 1 sort of misses the top level question that you (Michael) 
> articulated well at the previous ICCRG mtg in LA:
> - What's the minimum support in network elements for future-proofed (incl 
> hi-speed) congestion control?

Thanks for "articulated well"  :-)   and interesting feedback...
indeed that would be a main point to focus on IMO

> Note the term "network elements" not "routers" - as Tim Shepard said, we 
> have to work with congestion in lower layers too (and if doing explicit 
> congestion notification, we have to propagate congestion info up the layers).

yep

> I can probably contribute text to "Challenge 8. Misbehaving S&Rs". For 
> instance, I have a fair idea of which aspects of the DoS problem might be 
> solved by better congestion control.

Great, I appreciate that!

> I think we need a "Challenge 9: Multicast Congestion Control"
> Both streamed-media and messaging types of multicast.

Right!!! I knew that there were several things that we overlooked
so far, that's one that I didn't think of

> Other more detailed questions:
> 
> An additional question in 3.1.4 (which should probably be entitled 
> feed-forward notification, not feedback)
> - what's the minimum information intensity of congestion notification (More 
> than 1-bit per packet? Is sensing congestion delay variation a sufficient 
> alternative?)
> 
> Also:
> - Is a good system & equipment design goal to sacrificially throttle 
> bit-rate to avoid CPU overload (so the brain can still work out what to do 
> about congestion)?
> - distinguishing per-packet congestion from per-byte congestion (similar 
> problem to distinguishing congestion from wireless transmission losses)?
> - ever-widening range of packet sizes: if design equipment for larger ave 
> pkt size, gets overloaded with flurries of small packets.

I must admit that I didn't give everything in the document a detailed
read yet - I was planning to do so in a general update which I wanted
to do, well, early this week  :(   so a little later, it seems ...

anyway, in that update, I'll see if I can somehow answer your questions
(or avoid them being raised  :)  )  - thanks!

Cheers,
Michael

From: [email-masked] (Bob Briscoe)
Date: Tue Aug  7 13:15:48 2007
Subject: [Iccrg]  draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt
Message-ID: <[email-masked]>

Michael, Dimitri,

During the presentation of this at the last ICCRG mtg I identified some 
extra challenges or adjuncts to the existing ones, which I'll record here 
and add a few review comments too (tho I'll do a full review later and at 
the same time I contribute some better thought-thru text if req'd).

Challenge 1 sort of misses the top level question that you (Michael) 
articulated well at the previous ICCRG mtg in LA:
- What's the minimum support in network elements for future-proofed (incl 
hi-speed) congestion control?

Note the term "network elements" not "routers" - as Tim Shepard said, we 
have to work with congestion in lower layers too (and if doing explicit 
congestion notification, we have to propagate congestion info up the layers).

I can probably contribute text to "Challenge 8. Misbehaving S&Rs". For 
instance, I have a fair idea of which aspects of the DoS problem might be 
solved by better congestion control.

I think we need a "Challenge 9: Multicast Congestion Control"
Both streamed-media and messaging types of multicast.

Other more detailed questions:

An additional question in 3.1.4 (which should probably be entitled 
feed-forward notification, not feedback)
- what's the minimum information intensity of congestion notification (More 
than 1-bit per packet? Is sensing congestion delay variation a sufficient 
alternative?)

Also:
- Is a good system & equipment design goal to sacrificially throttle 
bit-rate to avoid CPU overload (so the brain can still work out what to do 
about congestion)?
- distinguishing per-packet congestion from per-byte congestion (similar 
problem to distinguishing congestion from wireless transmission losses)?
- ever-widening range of packet sizes: if design equipment for larger ave 
pkt size, gets overloaded with flurries of small packets.

Bob

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

From: [email-masked] (Michael Welzl)
Date: Tue Aug  7 07:50:39 2007
Subject: [Iccrg] LT-TCP followup
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <002001c7d609$3e2a7c90$0200a8c0@fun> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Lachlan,

> Thanks for taking the time to try to understand this, and for your
> clear statements of your objections.  This is really clarifying things
> for me.

You're welcome - but it's really me who has to thank you for
taking the time to explain it in such detail! This conversation
is getting very interesting - as you know, I'm very interested
in the response to corruption and would hence love to see a
sound suggestion - that's why I'm very happy that you brought
us this proposal.

You made things quite clear here - this last email of yours is
much easier for me to understand than the prior ones. There are
several explanations from you in this email to which I would
only answer "Ah, okay, now I get it, thanks!" (e.g. the
economic analogy). Instead of doing so, I'll speed things up
by simply removing all these parts.

> Applications certainly can produce variable rate data.  It might be a
> particulary active scene in a video.  It might be that you're logging
> data from an experiment where something suddenly happens.  It might be
> that you're using telnet and suddenly 'cat' a file.

Now I understand that your scenario is: "first the application limits
the rate, then, all of a sudden, the rate jumps to a higher value
because the limit no longer exists". This seems to be the same idea
as further below, where you describe re-routing to a new path (which
I'd consider a more reasonable example for a flow to suddenly cause
a certain amount of congestion, as a congestion control mechanism would
normally prevent an application from such "jumps").

> > This assumes
> > that the packet loss ratio experienced by the two-hop flow is
> > exactly 2 times the packet loss ratio experienced by the one-hop
> > flows, which isn't true.
> > Even if we assume that p doesn't depend on the rate of the
> > flows under consideration (which is a story in itself...),
> > then p only becomes approximately 2p in the 2-hop case if
> > p is very small.
> > ... 2p-p^2...
> 
> I agree that this is not exactly true for loss rates, but it is as
> good an approximation as replacing bursty rates by a fluid limit.  For
> sources which produce congestion,  p  *is* very small.  A window of a
> mere 10 packets needs roughly p = 10^-2.  Approximating, 0.0199 by
> 0.02 is trivial compared to assuming AIMD has a well-defined rate.

"For sources which produce congestion", p can be anything.
The larger p is, the more important I'd consider it to
reasonably estimate it.

In the real Internet, p is very small indeed. However, p is
also under the influence of your own flow, which will make
the 2p estimate worse.

> > Since in fact p of the second hop will be less than
> > p of the first hop
> 
> a) Replace "loss" by "ECN" and this doesn't apply.

Why? Just like packets can only be dropped once along
a path, they can also only be ECN-marked once.

> > with all these weird
> > assumptions as a basis, it makes it hard for me to intuitively
> > understand what you say.
> 
> The assumptions are:
> - flow rate is roughly constant through the life of the path -- which
> is a 1% or better approximation for current networks

Who says that? Since the first hop is not unlikely to be the bottleneck,
the outgoing rate after the first router can be significantly lower.

> - loss probability is cumulative through the network -- again 1% or better

Who says that? Do you have measurements to back this up?

My personal guess is that this is quite wrong. In the simple
parking lot scenario that we discussed, where you argue
that the assumption that p of the two-hop flow is 2*p of
the one-hop flows, we also have the assumption that p
is constant throughout the network, which I absolutely
don't believe to be true in reality.

> - each "lost packet" causes one "loss event"

Quite improbable. Losses are typically clustered in the
Internet; in recent measurements that we did, we usually
lost 1, 2 or 3 packets in a row. If that happens within
a RTT, it's all one "loss event" (one event that a sender
should react to).

> - packet loss probability is equal for all flows

I could live with this one if you'd assume that all
flows traverse exactly the same path. In our parking
lot scenario, they don't, and as I said above, I don't
buy the assumption that the packet loss probability
is equal throughout the network - so I don't buy that
assumption too.

> I believe they're all pretty standard, and more intuitive than
> replacing the last two by something more accurate.

No, I think they're all completely wrong, and it's up
to you to show that they're not (i.e. back them up
with measurements).

Note that I'm not playing devil's advocate - I honestly
believe that they're completely wrong. For instance,
you'll probably lose some packets at some bottleneck
along the path, and lose nothing in most other routers,
as opposed to losing the same amount everywhere - if
that's the case, this renders some of your assumptions
above wrong.

> > > when the flow
> > > suddenly starts losing 90% of its packets, the TCP-fair thing to do
> > > would be to reduce its payload by *less* than a factor of 10.  Of
> > > course, to do that it needs to increase the sending rate slightly.
> >
> > If I understand you
> > correctly, what you're saying is, in order for the TCP receiver
> > to get exactly as many packets as it would get if there was
> > no corruption, the sender would have to increase the sending rate.
> No, I didn't mean that.  If we suddenly cause 10 times the congestion
> per received packet (re-routed over a path with 10 times the number of
> equally-congested links, but the same RTT), TCP would start giving us
> data at about 1/3  ( 1/sqrt(10) ) the rate.
> 
> If we want to have the same response when we suddently cause 10 times
> the congestion per received packet because of 90% corruption, then we
> need to send at a rate about 10/3 higher, so we still get data at a
> rate of about 1/3 the original.

I'm honestly very sorry, but I still don't get it. Why 10/3?

> > > This flow causes more congestion than the lossless flow, the same as a
> > > two-hop flow causes more congestion than a one-hop flow.  That is just
> > > what TCP's fairness scheme implies.
> >
> > Of course it causes more congestion, but why would TCP-friendliness
> > imply that you do that? It's all about the sending rate, not the
> > throughput as seen by the receiver.
> 
> I agree this is the biggest conceptual leap.  Where's Bob Briscoe when
> you need him? :)
> 
> TCP originally specified sending rates because it specified an
> algorithm run at the sender, not a fairness paradigm.  In a
> non-collapsed world with reliable links, sending rate is approximately
> receiving rate, so TCP essentially specifies both sending rates and
> receiving rates.  (If anyone on this list remembers discussion of why

I can't live with the "non-collapsed world with a reliable links"
assumption here. We're talking about severe cases in our examples -
severe corruption, possibly severe congestion.

> VJ introduced CWND at the sender, instead of getting the receiver to
> limit the window it advertised, I'd be hapy to hear it.)
> 
> When we start looking at networks where "sending rate" and "receiving
> rate" are significantly different, we must choose whether to keep TCPs
> receiving rate or its sending rate.  Let's look at reasons for each:
> 
> Sending rate:  reflects actual harm done to the network.
> Receiving rate:  determines actual benefit done to the user.
> 
> In Kelly's framework, the "harm done to the network" is correctly
> captured by the *congestion level*.  The sending rate is at best a
> surrogate for that, since the same sending rate causes different
> amounts of harm in different settings.  In the tradeoff between
> congestion caused and data delivered, the sensible (to me) "rate" of
> the flow is the data delivered.

As a measure of "harm done to the network", I agree, but not
as the rate that we want to control.

> > > In that case, being TCP-friendly implies we  should
> > > increasing the send-rate of flows suffering packet corruption.
> >
> > If I understood you correctly, I disagree. that's because
> > TCP-friendliness is about the sending rate. I think that
> > the earliest RFC to define it is RFC 2309:
> >
> >    We introduce the term "TCP-compatible" for a flow that behaves under
> >    congestion like a flow produced by a conformant TCP.  A TCP-
> >    compatible flow is responsive to congestion notification, and in
> >    steady-state it uses no more bandwidth than a conformant TCP running
> >    under comparable conditions (drop rate, RTT, MTU, etc.)
> >
> > Despite the slightly different term, it's clear that this is
> > about the bandwidth that is used, not about the rate at
> > which the receiver is supposed to get its data.
> 
> True.  It also answers the question that we're revisiting: "what
> impact on rate should the drop rate have?"  This says that if a packet
> is dropped due to a corrupt checksum, then it has to slow the source
> at least as much as Reno does for congestion loss.  That's clearly not
> the right response to corruption.
> 
> This is the RFC that we're moving forward from.  Let's not be
> constrained by its wording, but by what is sensible/fair (and then of
> course a backward-compatible implementation).  If a good reason can be
> put forward why the tradeoff between   congestion and sending rate
> (a "cost/cost" tradeoff) is more appropriate than the tradeoff between
>   congestion and receiving rate   (a "cost/benefit" tradeoff), I'm all
> ears.

I agree about moving forward from that RFC - but anyhow,
that's the common understanding of TCP-friendliness (as
a ton of other material shows), so you really can't call
your design TCP-friendly if it doesn't match that. That
was my point.

> > Somewhat - but at that point, I'd say that either I still
> > don't fully understanding it, or the main message is simply:
> > "in order for a receiver to get as much as it would
> > get from a standard TCP sender without corruption in
> > the network, the sender has to increase its rate".
> 
> As above, this is definitely  not  what I'm calling the TCP-friendly
> case.  (It's the "max-min" case in my draft, which is very different.)
>  We should definitely get less data through when we cause more
> congestion.  It's purely a question of how much less.

Okay, I get that now, but still don't understand the calculation
(the 10/3 above).

> I think there are two parts:
> 1) Using Mo and Walrand's  "alpha=2 fairness",  what is the "fair" rate?
> 2) Should TCP-friendliness refer to the receive rate or the send rate?
> 
> Should we focus on the first of these first?  Or do you think that
> would be a waste of time if we'll never agree on the second?

I think that you really can't use the term "TCP-friendliness"
if you refer to the receive rate. It's been defined otherwise,
and used a lot in that fashion. If you want to match the
receive rate of TCP, I'd suggest to invent a new term  :)

Cheers,
Michael

From: [email-masked] (Michael Welzl)
Date: Tue Aug  7 07:37:50 2007
Subject: [Iccrg] Re: Procedure for obtaining ICCRG reviews
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 2007-08-06 at 19:49 -0400, Mark Allman wrote:
> > Before I use it for the CTCP draft (which is the only one
> > on our table so far), 
> 
> Note, as far as I can tell CTCP has not been brought to the IETF.
> Perhaps I have that wrong, but it seems that someone should be
> announcing such things to the TCPM list at least in parallel with some
> ICCRG effort that is supposedly for the IETF's benefit.

Okay - I think Wes and I can easily agree to let TCPM
(and TSVWG in case of XCP) know when we start the review
process for a proposal.

Just to bring you up to speed regarding CTCP, the authors
sent the draft together with some pointers to related work
to the list (see:
http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2007-July/000249.html )
and are now waiting for us to start the process.

That's all - although some others indicated their interest
in submitting proposals (Injong Rhee for CUBIC, Doug Leigh
for HTCP), we don't have another proposal on the table for
the time being.

I agree with everything else in your email, so I don't even
address it. Everything that you suggest is totally fine with me.

Cheers,
Michael

From: [email-masked] (Mark Allman)
Date: Tue Aug  7 02:50:57 2007
Subject: [Iccrg] Procedure for obtaining ICCRG reviews
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> > clear to me (if I put my reviewers hat on for a moment) how to make  
> > that decision in a consistent way - perhaps the cautious thing is  
> > simply to default to 2a if an algorithm passes basic tests.   ID  
> > draft-ietf-tsvwg-cc-alt-04.txt deals with general principles but  
> > these still need to be turned into practice. Worth discussing on the  
> > iccrg surely ?
> 
> Hmm... I honestly think that these general principles are as good as
> it gets - I don't see how we could reasonably agree on more practical,
> detailed guidelines that talk about things like timeout thresholds
> etc, like you mention.
> 
> I think that it's general principles + common sense (which will be
> quite subjective, but this will be okay because we consider you an
> expert :) )

I agree with Michael here, except that I'd change his "common sense" to
"engineering judgment".  CC-ALT is a set of things that researchers
should think about, talk about and generally address when proposing new
CC schemes.  CC-ALT is also a set of things that IETF reviewers should
use to *guide* their thinking about some proposal (CC-ALT is not
exhaustive, however).  I doubt very much that we could come up with a
hard-and-fast checklist of things that would turn the process into
deciding "how safe?" into a mechanical process.  We have the high-level
guidance (IMO, but I co-wrote it, so ...).  As we consider proposals we
need to carefully consider how they *address* the topics in the
high-level guidance and whether we buy that a solid evaluation has been
performed or whether it is somehow lacking.  (And, of course, in the
latter case by describing what we think is lacking about the
evaluation.)

I don't know if that helps or not.

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/20070806/363f755e/attachment.bin
>From [email-masked]  Tue Aug  7 00:49:42 2007
From: [email-masked] (Mark Allman)
Date: Tue Aug  7 02:55:13 2007
Subject: [Iccrg] Re: Procedure for obtaining ICCRG reviews
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> Before I use it for the CTCP draft (which is the only one
> on our table so far), 

Note, as far as I can tell CTCP has not been brought to the IETF.
Perhaps I have that wrong, but it seems that someone should be
announcing such things to the TCPM list at least in parallel with some
ICCRG effort that is supposedly for the IETF's benefit.

> As you probably know, ICCRG has agreed to obtain reviews
> on experimental congestion control proposals before they
> are brought to the IETF (specifically the TCPM group). While
> the competence to actually decide about acceptance or not is
> with TCPM, it is expected that they will take our reviews
> into account. This process is outlined here:
> http://www.ietf.org/IESG/content/ions/drafts/ion-tsv-alt-cc.txt

As far as templates go I think "TCPM" should be an "XXX" because it is
possible for things to be tracked elsewhere within the IETF.  E.g., it
seems likely that TSVWG---instead of TCPM---would handle something like
XCP since it is not TCP.

> If you're interested in doing a review, please send a note
> to Wes and me. Reviews can be sent to the list, or directly
> to us for anonymization before reflecting them out to the
> list, if desired.

Since this is a community effort and not peer review, I'd like to see
your note encourage folks to make their reviews open and signed.  (I.e.,
to use the anonymization scheme as a 'last resort'.)

> * consider not only the draft alone, but also papers referenced
>   therein, where the authors should have carried out a performance 
>   evaluation of their mechanism, including studies which show the

Nit: I'd change "performance evaluation" to "evaluation". 

>   impact of the new mechanism on standard TCP. When looking at
>   such studies, this document is recommended to be used for guidance:
>   http://www.ietf.org/internet-drafts/draft-irtf-tmrg-metrics-09.txt
> 
> Reviews should include one of the following final recommendations:
> 
> * Experimental 1:
>   The proposed mechanism is judged to be safe to deploy for
>   best-effort traffic in the global Internet and further
>   investigated in that environment.
> 
> * Experimental 2 A:
>   While promising, the proposed mechanism is not deemed safe
>   enough for widespread deployment as best-effort traffic on
>   the Internet, but can be specified to facilitate investigations
>   in simulation, testbeds, or controlled environments.
> 
> * Experimental 2 B:
>   The IETF does not yet have sufficient understanding to decide
>   if the algorithm is or is not safe for deployment on the Internet.
> 
> * Informational:
>   The proposed mechanism does not meet the criteria for recommending
>   publication of the draft as an Experimental RFC. It should be
>   considered for publication as an Informational RFC for the benefit
>   of the IETF and IRTF communit, provided that it carries an
>   explicit warning against using the scheme in the global Internet.
>   
> * Not ready:
>   The draft is not ready for publication as an Experimental or
>   Informational RFC.
> 
> A review can be as short as a selection from the list of options,
> although preferably it would include at least some brief
> discussion or justification. No matter how long the feedback
> is, we expect reviewers to have thoroughly read all the
> necessary material.

First, I would note in here that if the TCPM group (or at least this
*participant*) gets a review that is simply a selection from the above
list then that review may not carry much weight.  The more careful,
complete and descriptive a review is the more credence it will be given,
I strongly suspect.  It might be good to note this in your summation
above.

Second, I am not sure if I like the list.  Every time I try to make a
'which option do you like best?' list people always start adding
options.  Maybe I am lousy with lists.  ;)  The CC-ALT document (in the
rfc-ed queue) that Sally and I wrote says that draft authors have to
make statements in their documents about the "safeness" of their scheme
for use in the global Internet.  The text from our document:

    Each alternate congestion control algorithm published is required to
    include a statement in the abstract indicating whether or not the
    proposal is considered safe for use on the Internet.  Each alternate
    congestion control algorithm published is also required to include a
    statement in the abstract describing environments where the protocol
    is not recommended for deployment.  There may be environments where
    the protocol is deemed *safe* for use, but still is not
    *recommended* for use because it does not perform well for the user.

So, perhaps instead of choosing which option the reviewers think is
appropriate from a canned list that might not be quite right for a
particular proposal, the question for reviewers should be whether or not
they buy the statement-on-safeness included in the draft itself.  Of
course, with the reviewers showing their work at how they arrived at
their decision.

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/20070806/53f203b0/attachment.bin
>From [email-masked]  Tue Aug  7 07:01:46 2007
From: [email-masked] (Murari Sridharan)
Date: Tue Aug  7 07:04:30 2007
Subject: [Iccrg] Re: Procedure for obtaining ICCRG reviews
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Mark, we presented CTCP at the Chicago IETF and also sent the draft on the mailing lists.

Thanks
Murari

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Allman
Sent: Monday, August 06, 2007 4:50 PM
To: Michael Welzl
Cc: [email-masked]
Subject: [Iccrg] Re: Procedure for obtaining ICCRG reviews

> Before I use it for the CTCP draft (which is the only one on our table
> so far),

Note, as far as I can tell CTCP has not been brought to the IETF.
Perhaps I have that wrong, but it seems that someone should be announcing such things to the TCPM list at least in parallel with some ICCRG effort that is supposedly for the IETF's benefit.

> As you probably know, ICCRG has agreed to obtain reviews on
> experimental congestion control proposals before they are brought to
> the IETF (specifically the TCPM group). While the competence to
> actually decide about acceptance or not is with TCPM, it is expected
> that they will take our reviews into account. This process is outlined
> here:
> http://www.ietf.org/IESG/content/ions/drafts/ion-tsv-alt-cc.txt

As far as templates go I think "TCPM" should be an "XXX" because it is possible for things to be tracked elsewhere within the IETF.  E.g., it seems likely that TSVWG---instead of TCPM---would handle something like XCP since it is not TCP.

> If you're interested in doing a review, please send a note to Wes and
> me. Reviews can be sent to the list, or directly to us for
> anonymization before reflecting them out to the list, if desired.

Since this is a community effort and not peer review, I'd like to see your note encourage folks to make their reviews open and signed.  (I.e., to use the anonymization scheme as a 'last resort'.)

> * consider not only the draft alone, but also papers referenced
>   therein, where the authors should have carried out a performance
>   evaluation of their mechanism, including studies which show the

Nit: I'd change "performance evaluation" to "evaluation".

>   impact of the new mechanism on standard TCP. When looking at
>   such studies, this document is recommended to be used for guidance:
>   http://www.ietf.org/internet-drafts/draft-irtf-tmrg-metrics-09.txt
>
> Reviews should include one of the following final recommendations:
>
> * Experimental 1:
>   The proposed mechanism is judged to be safe to deploy for
>   best-effort traffic in the global Internet and further
>   investigated in that environment.
>
> * Experimental 2 A:
>   While promising, the proposed mechanism is not deemed safe
>   enough for widespread deployment as best-effort traffic on
>   the Internet, but can be specified to facilitate investigations
>   in simulation, testbeds, or controlled environments.
>
> * Experimental 2 B:
>   The IETF does not yet have sufficient understanding to decide
>   if the algorithm is or is not safe for deployment on the Internet.
>
> * Informational:
>   The proposed mechanism does not meet the criteria for recommending
>   publication of the draft as an Experimental RFC. It should be
>   considered for publication as an Informational RFC for the benefit
>   of the IETF and IRTF communit, provided that it carries an
>   explicit warning against using the scheme in the global Internet.
>
> * Not ready:
>   The draft is not ready for publication as an Experimental or
>   Informational RFC.
>
> A review can be as short as a selection from the list of options,
> although preferably it would include at least some brief discussion or
> justification. No matter how long the feedback is, we expect reviewers
> to have thoroughly read all the necessary material.

First, I would note in here that if the TCPM group (or at least this
*participant*) gets a review that is simply a selection from the above list then that review may not carry much weight.  The more careful, complete and descriptive a review is the more credence it will be given, I strongly suspect.  It might be good to note this in your summation above.

Second, I am not sure if I like the list.  Every time I try to make a 'which option do you like best?' list people always start adding options.  Maybe I am lousy with lists.  ;)  The CC-ALT document (in the rfc-ed queue) that Sally and I wrote says that draft authors have to make statements in their documents about the "safeness" of their scheme for use in the global Internet.  The text from our document:

    Each alternate congestion control algorithm published is required to
    include a statement in the abstract indicating whether or not the
    proposal is considered safe for use on the Internet.  Each alternate
    congestion control algorithm published is also required to include a
    statement in the abstract describing environments where the protocol
    is not recommended for deployment.  There may be environments where
    the protocol is deemed *safe* for use, but still is not
    *recommended* for use because it does not perform well for the user.

So, perhaps instead of choosing which option the reviewers think is appropriate from a canned list that might not be quite right for a particular proposal, the question for reviewers should be whether or not they buy the statement-on-safeness included in the draft itself.  Of course, with the reviewers showing their work at how they arrived at their decision.

allman

From: [email-masked] (Lachlan Andrew)
Date: Mon Aug  6 18:00:08 2007
Subject: [Iccrg] LT-TCP followup
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <002001c7d609$3e2a7c90$0200a8c0@fun> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Michael,

Thanks for taking the time to try to understand this, and for your
clear statements of your objections.  This is really clarifying things
for me.

On 06/08/07, Michael Welzl <[email-masked]> wrote:
> > > > Lachlan Wrote
> > Intuitively, the wireless links being the last hop is the worst case,
> > because it causes the most congestion for a given received rate.
>
> you assume that the receiving
> end point of the wireless link drops any corrupt packet
> anyway (otherwise I absolutely don't understand why
> this would be the worst case)

I assume that the "packet lost" indicator is no larger than the
original packet.  If it is equal in size (like a changed checksum),
then loss anywhere is "equal worst-case".  If the packet is replaced
by a small ack-like "corruption flag", then loss on/after the last
congested link is strictly the worst case.

The latter approach is motivated by the suggestion earlier in this
list that burst-errors make packets either totally garbled or totally
reliable, but a link can still tell that a garbled packet was
received.  (It doesn't deal with the fact that we wouldn't know which
flow the packet belonged to, but that may be able to come from the
"link layer prediction" that Wes said was being used for
interplanetary IP header compression.)

> > flow which gets  1/k  of its packets through is exactly analogous to a
> > flow which uses  k  congested hops.  For a given receive rate, both
> > use  k  times "their share" of the resources, compared with a
> > single-hop lossless flow.
>
> Sorry: I just tried hard, but I don't understand that analogy.
> Maybe that's the problem. I can think of proportional fairness
> in terms of multiple congested resources, but I never understood
> how this relates to flows which have their packets dropped because
> of corruption.

It might help to think in terms of the economic analogy:  You get
charged for each packet you send through each link (at a level that
depends on how congested each link is), and you get benefit from each
packet you receive.  The amount you get charged is the same whether it
is charged at  k  links, or you are charged  k  times as much at one
link.  For a given "willingness to pay", you'll send at the same rate
in either case.

> > Imagine a two-hop "parking lot" topology, in
> > which the two-hop flow is application limited.
>
> What do you mean with application limited?
>
> Normally, to me, this means that the application can't send
> at the rate at which it should (according to what the network
> allows - i.e. a TCP can't increase it's rate as the congestion
> control mechanism normally would). Then why would it increase
> its sending rate at all? It can't!

Applications certainly can produce variable rate data.  It might be a
particulary active scene in a video.  It might be that you're logging
data from an experiment where something suddenly happens.  It might be
that you're using telnet and suddenly 'cat' a file.

> > "Proportional fairness" (which in our contexts allocates equal send
> > rate to users, regardless of drop rate) would allocate 2/3 of each
> > bottleneck capacity to the one-hop flows, and 1/3 of each capacity to
> > the two-hop flow.  That corresponds to setting a window proportional
> > to  1/p  for a drop rate of  p.  In this simple case, the long flow
> > causes twice the congestion per unit throughput (the same amount on
> > two routers), and consequently gets half the rate.  Good.
> >
> > TCP is "more fair", and gives a higher rate to the low-throughput
> > flow, by setting the window proportional to  1/sqrt(p).  (Is that
> > "acceptable"?  That's not for me to justify...)  This gives a ratio of
> > 1:sqrt(2) instead of 1:2 in the rates.  Thus, the flow with the lower
> > rate is allowed to create more total congestion.  This is "fair",
> > because it is the underdog and needs help.
>
> This assumes
> that the packet loss ratio experienced by the two-hop flow is
> exactly 2 times the packet loss ratio experienced by the one-hop
> flows, which isn't true.
> Even if we assume that p doesn't depend on the rate of the
> flows under consideration (which is a story in itself...),
> then p only becomes approximately 2p in the 2-hop case if
> p is very small.
> ... 2p-p^2...

I agree that this is not exactly true for loss rates, but it is as
good an approximation as replacing bursty rates by a fluid limit.  For
sources which produce congestion,  p  *is* very small.  A window of a
mere 10 packets needs roughly p = 10^-2.  Approximating, 0.0199 by
0.02 is trivial compared to assuming AIMD has a well-defined rate.

> Since in fact p of the second hop will be less than
> p of the first hop

a) Replace "loss" by "ECN" and this doesn't apply.
b) Again, this is a 1% approximation, trivial compared with the 50%
approximation of AIMD, or the x% approximation that RTT fairness or
jumbo frames are somehow "fair".

> with all these weird
> assumptions as a basis, it makes it hard for me to intuitively
> understand what you say.

The assumptions are:
- flow rate is roughly constant through the life of the path -- which
is a 1% or better approximation for current networks
- loss probability is cumulative through the network -- again 1% or better
- each "lost packet" causes one "loss event"
- packet loss probability is equal for all flows

I believe they're all pretty standard, and more intuitive than
replacing the last two by something more accurate.

> > when the flow
> > suddenly starts losing 90% of its packets, the TCP-fair thing to do
> > would be to reduce its payload by *less* than a factor of 10.  Of
> > course, to do that it needs to increase the sending rate slightly.
>
> If I understand you
> correctly, what you're saying is, in order for the TCP receiver
> to get exactly as many packets as it would get if there was
> no corruption, the sender would have to increase the sending rate.

No, I didn't mean that.  If we suddenly cause 10 times the congestion
per received packet (re-routed over a path with 10 times the number of
equally-congested links, but the same RTT), TCP would start giving us
data at about 1/3  ( 1/sqrt(10) ) the rate.

If we want to have the same response when we suddently cause 10 times
the congestion per received packet because of 90% corruption, then we
need to send at a rate about 10/3 higher, so we still get data at a
rate of about 1/3 the original.

> > This flow causes more congestion than the lossless flow, the same as a
> > two-hop flow causes more congestion than a one-hop flow.  That is just
> > what TCP's fairness scheme implies.
>
> Of course it causes more congestion, but why would TCP-friendliness
> imply that you do that? It's all about the sending rate, not the
> throughput as seen by the receiver.

I agree this is the biggest conceptual leap.  Where's Bob Briscoe when
you need him? :)

TCP originally specified sending rates because it specified an
algorithm run at the sender, not a fairness paradigm.  In a
non-collapsed world with reliable links, sending rate is approximately
receiving rate, so TCP essentially specifies both sending rates and
receiving rates.  (If anyone on this list remembers discussion of why
VJ introduced CWND at the sender, instead of getting the receiver to
limit the window it advertised, I'd be hapy to hear it.)

When we start looking at networks where "sending rate" and "receiving
rate" are significantly different, we must choose whether to keep TCPs
receiving rate or its sending rate.  Let's look at reasons for each:

Sending rate:  reflects actual harm done to the network.
Receiving rate:  determines actual benefit done to the user.

In Kelly's framework, the "harm done to the network" is correctly
captured by the *congestion level*.  The sending rate is at best a
surrogate for that, since the same sending rate causes different
amounts of harm in different settings.  In the tradeoff between
congestion caused and data delivered, the sensible (to me) "rate" of
the flow is the data delivered.

> > In that case, being TCP-friendly implies we  should
> > increasing the send-rate of flows suffering packet corruption.
>
> If I understood you correctly, I disagree. that's because
> TCP-friendliness is about the sending rate. I think that
> the earliest RFC to define it is RFC 2309:
>
>    We introduce the term "TCP-compatible" for a flow that behaves under
>    congestion like a flow produced by a conformant TCP.  A TCP-
>    compatible flow is responsive to congestion notification, and in
>    steady-state it uses no more bandwidth than a conformant TCP running
>    under comparable conditions (drop rate, RTT, MTU, etc.)
>
> Despite the slightly different term, it's clear that this is
> about the bandwidth that is used, not about the rate at
> which the receiver is supposed to get its data.

True.  It also answers the question that we're revisiting: "what
impact on rate should the drop rate have?"  This says that if a packet
is dropped due to a corrupt checksum, then it has to slow the source
at least as much as Reno does for congestion loss.  That's clearly not
the right response to corruption.

This is the RFC that we're moving forward from.  Let's not be
constrained by its wording, but by what is sensible/fair (and then of
course a backward-compatible implementation).  If a good reason can be
put forward why the tradeoff between   congestion and sending rate
(a "cost/cost" tradeoff) is more appropriate than the tradeoff between
  congestion and receiving rate   (a "cost/benefit" tradeoff), I'm all
ears.

> Somewhat - but at that point, I'd say that either I still
> don't fully understanding it, or the main message is simply:
> "in order for a receiver to get as much as it would
> get from a standard TCP sender without corruption in
> the network, the sender has to increase its rate".

As above, this is definitely  not  what I'm calling the TCP-friendly
case.  (It's the "max-min" case in my draft, which is very different.)
 We should definitely get less data through when we cause more
congestion.  It's purely a question of how much less.

I think there are two parts:
1) Using Mo and Walrand's  "alpha=2 fairness",  what is the "fair" rate?
2) Should TCP-friendliness refer to the receive rate or the send rate?

Should we focus on the first of these first?  Or do you think that
would be a waste of time if we'll never agree on the second?

Cheers,
Lachlan

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

From: [email-masked] (Michael Welzl)
Date: Mon Aug  6 14:52:41 2007
Subject: [Iccrg] LT-TCP followup
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

While, as you know, I'm a fan of the LT-TCP idea, this:

> KK> This is not quite correct. Let me clarify what we do. We respond to
> congestion, in the same way that TCP does and we depend on ECN for
> congestion indications. So, to that extent, we are following the "letter
> of the law" for TCP. If ECN exists in the end-end path and works as it
> is intended to, then "lost packets" would be primarily due to corruption
> and not congestion. In the past, the design of TCP has intricately tied
> together the reliability and congestion components together, with the
> strong assumption that packet loss implied congestion. It was
> by-and-large true then, because we didn't have as much wireless as we
> have today or might have in the future. So, if the intent and "law" of
> TCP is to respond to congestion, then we try to remain within those
> boundaries.

...is unacceptable in my opinion. It's okay as a theoretical
exercise, but I wouldn't want to see a practical solution
assume that only ECN signals congestion, and packet loss
doesn't.

As I mentioned before, the right thing to do would be to flip
it around, and *only* assume that there was corruption when you
have a reliable signal saying so. Otherwise, in the presence of
packet loss (which can always be due to an overflowing queue,
ECN notwithstanding), the right thing to do is to assume congestion.

Examples of such signals include the data checksum option in
DCCP, and ETEN:  http://www.ir.bbn.com/projects/pace/eten/
... and (sorry for repeating myself) ETEN+LT-TCP would be a
real winner in my opinion.

Cheers,
Michael

From: [email-masked] (Michael Welzl)
Date: Mon Aug  6 14:33:35 2007
Subject: [Iccrg] LT-TCP followup
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <002001c7d609$3e2a7c90$0200a8c0@fun> <[email-masked]>
Message-ID: <[email-masked]>

> > > Lachlan Wrote
> > >
> > > No, we consider the whole path.  The assumption is just that that the
> > > wireless link is the *last* hop.
> >
> > Hmm... I don't think that this makes much of a difference for what
> > I was trying to say; see below...
> 
> The difference is that, in the framework we consider, we still
> consider the congestion caused by the excess transmissions.
> Intuitively, the wireless links being the last hop is the worst case,
> because it causes the most congestion for a given received rate.

This probably means that you assume that the receiving
end point of the wireless link drops any corrupt packet
anyway (otherwise I absolutely don't understand why
this would be the worst case), which it however shouldn't
do for packets which experience corruption and where upper
layers could detect it (e.g. UDP-Lite packets).

> > That reminds me of the old congestion collapse scenario in one
> > of the early Raj Jain papers, where a source which doesn't
> > know about the small capacity of its last hop yet sends at
> > a high rate can contribute to congestion on a hop before that,
> > thereby causing the total throughput of the network to
> > decrease even when sending rates are increased.
> 
> Yes, at Marina Del Rey you also mentioned the "two hop congestion
> collapse" problem.  That may be a good way to explain my point.  A

Indeed that's exactly the scenario which I meant here.

> flow which gets  1/k  of its packets through is exactly analogous to a
> flow which uses  k  congested hops.  For a given receive rate, both
> use  k  times "their share" of the resources, compared with a
> single-hop lossless flow.  TCP doesn't give each flow a rate in

Sorry: I just tried hard, but I don't understand that analogy.
Maybe that's the problem. I can think of proportional fairness
in terms of multiple congested resources, but I never understood
how this relates to flows which have their packets dropped because
of corruption.

> proportion to 1/k -- it gives it a rate in proportion to 1/\sqrt(k),
> allowing the "resource intensive" flow to consume more resources.
> 
> 
> Unfortunately, current TCP behaviour fits Jain's original definition
> of congestion collapse.  Imagine a two-hop "parking lot" topology, in
> which the two-hop flow is application limited.  If the two-hop flow
> increases its sending rate, then the total network throughput goes
> down.  I believe this is Jain's definition of congestion collapse.

I don't know because I again don't quite get it. What do you
mean with application limited?

Normally, to me, this means that the application can't send
at the rate at which it should (according to what the network
allows - i.e. a TCP can't increase it's rate as the congestion
control mechanism normally would). Then why would it increase
its sending rate at all? It can't!

> That is all fixed by saying measuring the change in utility instead of
> throughput.  The extra benefit to the two-hop flow outweighs the
> disadvantage to the two short flows; because it has a lower current
> rate, the percentage increase it gets is much larger than their
> percentage decreases.

Because it's a log utility function?

> "Proportional fairness" (which in our contexts allocates equal send
> rate to users, regardless of drop rate) would allocate 2/3 of each
> bottleneck capacity to the one-hop flows, and 1/3 of each capacity to
> the two-hop flow.  That corresponds to setting a window proportional
> to  1/p  for a drop rate of  p.  In this simple case, the long flow
> causes twice the congestion per unit throughput (the same amount on
> two routers), and consequently gets half the rate.  Good.
> 
> TCP is "more fair", and gives a higher rate to the low-throughput
> flow, by setting the window proportional to  1/sqrt(p).  (Is that
> "acceptable"?  That's not for me to justify...)  This gives a ratio of
> 1:sqrt(2) instead of 1:2 in the rates.  Thus, the flow with the lower
> rate is allowed to create more total congestion.  This is "fair",
> because it is the underdog and needs help.

I'm having a lot of trouble trying to grasp all that. I already
have a problem with the sentence: "that corresponds to setting
a window proportional to 1/p for a drop rate of p". This assumes
that the packet loss ratio experienced by the two-hop flow is
exactly 2 times the packet loss ratio experienced by the one-hop
flows, which isn't true.

Even if we assume that p doesn't depend on the rate of the
flows under consideration (which is a story in itself...),
then p only becomes approximately 2p in the 2-hop case if
p is very small.

If a flow traverses two hops, and we assume that the packet
loss probability is independent and equal to p at both
hops, the probability that a packet is dropped for that flow
is the probability that it is dropped at the first hop, plus
the probability that it is not dropped at the first hop and
it is dropped at the second hop.

In other words, it's p + (1-p)*p, which is 2p-p^2, which
is only reasonably close to 2p for small values of p,
and, as I said, this is even assuming that p is independent.

Since in fact p of the second hop will be less than
p of the first hop as it is under the influence of
my own two-hop flow, too, and the rate of this flow
is reduced along the path, the real total p of the
two-hop flow will be even less.

Now this may or may not change the intuition of what you're
trying to say here, but in any case, with all these weird
assumptions as a basis, it makes it hard for me to intuitively
understand what you say.

> We can have a whole family, where the rate is proportional to
> p^{-1/alpha};  proportional fairness uses  alpha=1,  TCP uses
> alpha=2.  (Again, this isn't just what I'm proposing; this is what TCP
> already does for flows of equal RTT.)

okay...

> > Consider a long path with a wireless last hop. Consider a source
> > which sends across this path, and let's say that all of a sudden,
> > 90% of the packets are lost due to corruption, and that situation
> > stays stable for a while. You argue that the sender should increase
> > its rate.
> >
> > Now consider the first hop, which is the bottleneck, and assume that
> > all other flows sharing it get 100% of their packets across most of
> > the time (they don't traverse a wireless network).
> >
> > The  part that I don't get is: why can it be acceptable for the
> > single sender which only gets 10% of its packets across anyway
> > to increase its rate, and thereby increase the chance for all others
> > to experience congestion?
> 
> That comes down to the whole issue of "what is fair?"  TCP wasn't
> design to be fair for non-identical flows -- that is why flows with a
> larger MSS or shorter RTT get higher throughput.

okay...

> The best way I know of to answer fairness questions is in terms of
> Kelly's utility maximisation.  The conversation would be:
> A: Why should the high-loss flow get less effective throughput?
> B: Because it creates more congestion per byte of throughput
> A: How much less throughput should it get?
> B: That depends on how much benefit it loses by sending at the lower rate.
> 
> Let's be specific.  Assume there are two flows sharing a 1Gbps link.
> The "proportional fair" allocation (accounting for loss) would be that
> User A gets 500Mbps throughput, while user B gets 500Mpbs through the
> link, but only 50Mbps reaches the destination.  Intuitively, this
> again corresponds to each flow causing the same amount of congestion.

Yes...

> However, remember that TCP is "more fair" than proportional fairness,
> by giving extra bandwidth to the flows which get the least,
> corresponding to  alpha=2.  Thus, in your example, when the flow
> suddenly starts losing 90% of its packets, the TCP-fair thing to do
> would be to reduce its payload by *less* than a factor of 10.  Of
> course, to do that it needs to increase the sending rate slightly.

What?? I'm lost. The part that I don't get is the last sentence.
This whole business with the square root is the sender behavior,
not the reception rate of the receiver. If I understand you
correctly, what you're saying is, in order for the TCP receiver
to get exactly as many packets as it would get if there was
no corruption, the sender would have to increase the sending rate.
Who says that you should do that?

> This flow causes more congestion than the lossless flow, the same as a
> two-hop flow causes more congestion than a one-hop flow.  That is just
> what TCP's fairness scheme implies.

Of course it causes more congestion, but why would TCP-friendliness
imply that you do that? It's all about the sending rate, not the
throughput as seen by the receiver.

> In this example, the ratio would be 1:sqrt(10%).  User A would get
> 240Mbps throughput (and use 240Mbps of bandwidth), while User B would
> get 76Mbps throughput (and use 760Mbps of bandwidth).
> 
> For comparison, in a 10-hop parking lot with lossless 316Mbps links,
> each one-hop flow would get 240Mbps, and the 10-hop flow would get
> 76Mbps, using 760 "link * Mbps".
> 
> > I was also not aware that you're making a concrete proposal
> > for a certain behavior - at least back in Marina Del Rey, I thought that
> > you're merely trying to point out an interesting counterintutive issue
> 
> True.  I don't have a particular protocol (I'll put my vote behind
> LT-TCP :) and I'm not sure if we should be TCP-friendly or
> proportionally fair.  However, I think fairness should be consistently
> designed in to protocols, rather than just "emerging" from a set of
> rules.  In that case, being TCP-friendly implies we  should
> increasing the send-rate of flows suffering packet corruption.

If I understood you correctly, I disagree. that's because
TCP-friendliness is about the sending rate. I think that
the earliest RFC to define it is RFC 2309:

   We introduce the term "TCP-compatible" for a flow that behaves under
   congestion like a flow produced by a conformant TCP.  A TCP-
   compatible flow is responsive to congestion notification, and in
   steady-state it uses no more bandwidth than a conformant TCP running
   under comparable conditions (drop rate, RTT, MTU, etc.)

Despite the slightly different term, it's clear that this is
about the bandwidth that is used, not about the rate at
which the receiver is supposed to get its data.

> > In any case it would be helpful if you could explain it by means of
> > one or two simple examples like the one I gave above.
> 
> I hope the above example explains the intuition.

Somewhat - but at that point, I'd say that either I still
don't fully understanding it, or the main message is simply:
"in order for a receiver to get as much as it would
get from a standard TCP sender without corruption in
the network, the sender has to increase its rate".

If this is what you're saying, it's obviously true, but
this doesn't have anything to do with TCP-friendliness
and doesn't convince me in the least that this is
appropriate behavior.

Cheers,
Michael

From: [email-masked] (Lachlan Andrew)
Date: Sat Aug  4 19:55:28 2007
Subject: [Iccrg] LT-TCP followup
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings KK,

Thanks for your detailed reply.  Now a long one from me...

Although the email below sounds argumentative, it isn't meant to be.
My calculations essentially justify LT-TCP's decision not to reduce
its rate in response to non-congestion loss.   We just differ in how
"TCP-like" we think this is.

On 04/08/07, RAMAKRISHNAN, K. K. <[email-masked]> wrote:
>
> -----Original Message-----
> From: Lachlan Andrew [mailto:[email-masked]]
> Sent: Friday, August 03, 2007 4:48 PM
> To: RAMAKRISHNAN, KADANGODE K (K. K.)
> Cc: Michael Welzl; [email-masked]; David Hayes; Vijay Subramanian;
> Shivkumar Kalyanaraman
> Subject: Re: [Iccrg] LT-TCP followup
>
> My understanding is that you don't respond to lost packets.  That
> seems very far from following the "letter of the law" of TCP.
>
> KK> Let me clarify what we do. We respond to
> congestion, in the same way that TCP does and we depend on ECN for
> congestion indications. So, to that extent, we are following the "letter
> of the law" for TCP.

By "the letter of the law", I meant what RFC 2581 requires:
]   Therefore, when the first loss in a window of data is detected,
]   ssthresh MUST be set to no more than the value given by equation (3).
]   Second, until all lost segments in the window of data in question are
]   repaired, the number of segments transmitted in each RTT MUST be no
]   more than half the number of outstanding segments when the loss was
]   detected.

I don't think LT-TCP does this when a loss is detected, which is what
I meant when I said that it doesn't follow the *letter* of the law (as
I agree it shouldn't).

> So, if the intent and "law" of
> TCP is to respond to congestion, then we try to remain within those
> boundaries.

Yes, that is what I meant by the "spirit of the law".  I agree
entirely that you keep within the spirit of the law.

So far I think that we agree that LT-TCP does the window-manipulations
that were the "intent" of TCP, rather than following the "MUST"s of
RFC 2581 (or SACK, or ...).  I think the disagreement is whether the
intent was for TCP to specify window manipulations or to specify how
fast a data-stream can be sent.  Is that correct?

> KK> We agree with you that ultimately application performance should be
> the main criterion. But from a resource perspective each individual
> entity (e.g., flow) that qualifies to be treated distinctly, may be
> viewed as getting an equal share (e.g., when max-min is the criterion
> for fairness).

> Then, the total load (data, headers, other "stuff" like
> FEC) all get bundled into the share that the entity is eligible for.
> There are multiple fairness goals, and that is why we have discussions
> about what is the right thing to do.

Exactly.  I'm just not quite sure what fairness goal LT-TCP has (or
most other new TCP algorithms).  Since this is the IRTF, not the IETF,
I think we can take a more progressive position and state what
fairness we are trying to achieve, and then tailor the algorithms to
achieve it, rather than trying to make the smallest possible changes
to existing (unfair) algorithms.  Do you agree?

To me, fairness goals are expressed in terms of the "response
function" (uniquely determined by Kelly's "utility" function).  What I
did was take the utility function for TCP's *existing* response
function (1/sqrt(p)) and optimise that given loss in the network.

Note also that TCP doesn't give max-min fairness.  If its aim were to
give max-min fairness to the TCP streams, then streams with lower
throughput would be given *more* preferential treatment than I'm
advocating, not less...

> If SACK has a small enough RTT, then even at high loss
> rates it will get almost full link utilisation.  What does LT-TCP do
> then?
>
> KK> We do not measure the capacity that a competing TCP-SACK flow does
> not use. If the channel is idled because TCP-SACK suffers a timeout, it
> is only then that LT-TCP would be able to utilize that bandwidth. In the
> case that there is a small enough RTT and SACK is good enough even under
> the high loss rate to NOT experience a timeout, then TCP-SACK and LT-TCP
> would use that link fairly.

Are you saying that LT-TCP will have the same window as SACK if there
are corruption losses?  I thought that LT-TCP didn't reduce its window
based on missing packets, but SACK does.  Sorry that I don't remember
the details of the experiments you reported in Feb -- are they on
line?

Alternatively, are you saying that LT-TCP has a larger window, but for
some other reason it still limits its rate to be equal to SACK?

Note that I'm not saying LT-TCP *should* be constrained to have
exactly the same rate as SACK, even when SACK can fully utilise the
bandwidth.  Some unfairness during the transition to a better (fair)
set of protocols is fine by me.

>> We would like to emphasize that LT-TCP's
>> advantage is only that it may use the residual capacity that is left
>> un-utilized by TCP-SACK in such environments.
>
> My understanding is that a flow which sends fast enough to induce
> congestion losses will always slow down a competing flow which
> responds to losses.
>
> KK> If a flow induces congestion - period - and responds to ECN, then it
> will not slow down a competing flow that also responds to congestion
> indication. The issue, which you raise is: what happens when loss is the
> primary source of congestion indication. This is where we need to
> separate the two: congestion indication, and lossy channels. We used ECN
> to disambiguate them.

Consider a link such that two flows with loss probabilities  p=0.02
would saturate the link.
If we have 1% packet losses and 1% ECN marks, SACK will respond to a
loss rate of 2%, while LT-TCP will respond to a loss rate of 1%, and
hence send faster even though two SACK flows could saturate the link.
If LT-TCP slowed down toward half the link capacity, then the
congestion would reduce.  Then (loss+ECN) would drop, and so SACK
would increase to pick up the slack.

(Again, I'm not saying this is bad; just that it contradicts the
statement that LT-TCP only takes bandwidth SACK could not utilise.)

> KK> The main issue is
> whether we are changing the mechanism, and what is "the mechanism"? If
> loss as being the sole indication of congestion is the dominant part of
> "the mechanism", yes we are diverging from that.

Yes, to me treating loss as a sign of congestion is fundamental to the
mechanism of TCP.  All other decisions seem to stem from that
limitation.  There are (and were in '88) many better ways to control
rate if we're not limited to measuring rare events like packet loss.

Although I also don't like using loss as the primary congestion
measure, it does have the distinct advantage that it also reponds to
layer 2 congestion, which explicit-signalling (like ECN) doesn't.

> And honestly, we have tried to retain
> backward compatibility, not just appear to be backwards compatible.

Yes, I didn't mean to seem to accuse you of "window dressing".  It
comes down to the difference between backward-*compatible* algorithms
vs *similar* algorithms.

My point was just that ignoring loss is intrinsically a   much
bigger departure from standard TCP than simply allocating rate to the
payload rather than the payload+header (as is done when any TCP flow
is tunnelled).  Emphasising the similarity on the level of
window-manipulations is probably sensible for getting LT-TCP
standardised, but taking the approach of choosing desired flow-level
properties (like rate allocation) and then designing
backward-*compatible* algorithms  to implement them seems to me a
better way to develop the internet.  The latter is the approach that
TFRC has taken.

The reason that LT-TCP is good is because because of the flow-level
properties it has, not because the equations are similar to TCP.  My
calculations can be used to show the "optimality" (by some measure) of
LT-TCP's flow-level properties, or to tweak it to make it "more
optimal" (by using TCP-like measures throughout, instead of mixing
TCP-friendliness with Proportional Fairness).

Cheers,
Lachlan

P.S.
Speaking of tunnels, perhaps LT-TCP's mechanisms could be implemented
like IPsec, as a tunnel.  If we tunnel SACK in a new FEC-enabled IPfec
(or IP-LT), then we're allocating TCP's full "fair" rate to the
payload...  (This isn't a serious suggestion -- it's much more
aggressive than what I was proposing.  I'm just saying that
payload-rate allocation is not unheard-of in the IETF.)

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

From: [email-masked] (RAMAKRISHNAN, KADANGODE K (K. K.))
Date: Sat Aug  4 15:17:49 2007
Subject: [Iccrg] LT-TCP followup
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hello Lachlan,
Thank you for your note.
My responses appear below, in-line.

-----Original Message-----
From: Lachlan Andrew [mailto:[email-masked]] 
Sent: Friday, August 03, 2007 4:48 PM
To: RAMAKRISHNAN, KADANGODE K (K. K.)
Cc: Michael Welzl; [email-masked]; David Hayes; Vijay Subramanian;
Shivkumar Kalyanaraman
Subject: Re: [Iccrg] LT-TCP followup

Greetings KK,

On 03/08/07, RAMAKRISHNAN, KADANGODE K (K. K.) <[email-masked]>
wrote:
> We are very appreciative of the support for LT-TCP from the
> group. Thank you.

Yes, I hope it gets standardised.

> Here are a few points, in response to both Lachlan and Michael's
emails.
>
> 1) In response to Lachlan Andrew's email, we realize that the fairness
> criterion may be up to debate. In LT-TCP, we have been trying to not
> pick a new one, and remain within the constraints that the Internet
and
> TCP operate under.
[deleted]
> We continue to remain within
> the current TCP framework of sending as many bytes into the network
> as the window would allow, with the window dynamics remaining
> strictly in accordance with current TCP flow and congestion avoidance
> mechanisms.

My understanding is that you don't respond to lost packets.  That
seems very far from following the "letter of the law" of TCP. 

KK> This is not quite correct. Let me clarify what we do. We respond to
congestion, in the same way that TCP does and we depend on ECN for
congestion indications. So, to that extent, we are following the "letter
of the law" for TCP. If ECN exists in the end-end path and works as it
is intended to, then "lost packets" would be primarily due to corruption
and not congestion. In the past, the design of TCP has intricately tied
together the reliability and congestion components together, with the
strong assumption that packet loss implied congestion. It was
by-and-large true then, because we didn't have as much wireless as we
have today or might have in the future. So, if the intent and "law" of
TCP is to respond to congestion, then we try to remain within those
boundaries.

If you say that you are following the "spirit" of the law (which I agree
you
are), then I would suggest that the spirit of the law is about how
much data that is transported.  If the FEC were done at a layer below
TCP (where IMHO it belongs), then it wouldn't be included as part of
the application rate.  Why should it be included now?

KK> We agree with you that ultimately application performance should be
the main criterion. But from a resource perspective each individual
entity (e.g., flow) that qualifies to be treated distinctly, may be
viewed as getting an equal share (e.g., when max-min is the criterion
for fairness). Then, the total load (data, headers, other "stuff" like
FEC) all get bundled into the share that the entity is eligible for.
There are multiple fairness goals, and that is why we have discussions
about what is the right thing to do.

> We would like to emphasize that LT-TCP's
> advantage is only that it may use the residual capacity that is left
> un-utilized by TCP-SACK in such environments.

I've heard that argument used before (for HS-TCP etc), but never
really understood it.  How do you measure how much capacity TCP-SACK
can't use?  If SACK has a small enough RTT, then even at high loss
rates it will get almost full link utilisation.  What does LT-TCP do
then?

KK> We do not measure the capacity that a competing TCP-SACK flow does
not use. If the channel is idled because TCP-SACK suffers a timeout, it
is only then that LT-TCP would be able to utilize that bandwidth. In the
case that there is a small enough RTT and SACK is good enough even under
the high loss rate to NOT experience a timeout, then TCP-SACK and LT-TCP
would use that link fairly. That was our intent when we showed a few
slides in the February ICCRG meeting on LT-TCP being fair and achieving
the same window/throughput as TCP-SACK. 

My understanding is that a flow which sends fast enough to induce
congestion losses will always slow down a competing flow which
responds to losses.

KK> If a flow induces congestion - period - and responds to ECN, then it
will not slow down a competing flow that also responds to congestion
indication. The issue, which you raise is: what happens when loss is the
primary source of congestion indication. This is where we need to
separate the two: congestion indication, and lossy channels. We used ECN
to disambiguate them. If there is another way to disambiguate the two,
we'd definitely consider it. So, we want to make sure we make it clear.
LT-TCP does not ignore congestion and keep sending. It does everything
we all have come to understand is needed up to now about congestion
avoidance.

> 2) In response to Michael's (and thereby Sally's concern): we do not
> want to send, or keep sending, at a high rate, to overcome loss. We
> only send as much as the traditional TCP window flow and congestion
> avoidance mechanisms will allow.

Isn't the main difference that you don't consider packet erasures when
implementing the congestion avoidance mechanism?  I strongly agree
that is a  Good Thing  to do, but I don't think you can argue that
you're not *fundamentally* changing the mechanism.

KK> We are glad you say it is a good thing to do. The main issue is
whether we are changing the mechanism, and what is "the mechanism"? If
loss as being the sole indication of congestion is the dominant part of
"the mechanism", yes we are diverging from that. But if the congestion
avoidance algorithms that include the increase/decrease, timeout (when
the end-system believes that the channel is severely congested) etc.,
are "the mechanism", we have tried not to change these. 

If we're fundamentally changing the mechanism, I think we should work
out what we "should" do, rather than what changes the fewest "lines of
code" in the specifications...  We don't want to be overly constrained
by an   appearance   of backward compatibility.
KK> We certainly sympathize with the view that we should explore what
the "right thing to do" should be. We are ready to take input and vector
the design of LT-TCP towards the consensus view of what that is. The
difficulty is that there may be many views of that goal. From our
perspective, we wanted to see how well a sensibly put together set of
components for loss-tolerance (as distinct from congestion control and
avoidance) could be put together and work well with the existing TCP
congestion control functions. And we wanted to demonstrate how the
intricately-tied-together functionality of reliability and congestion
avoidance could be teased apart. And honestly, we have tried to retain
backward compatibility, not just appear to be backwards compatible.
Which is why we say that LT-TCP would switch back to TCP-SACK in the
absence of ECN as a congestion indication, rather than trying to invent
something else.

Once again, LT-TCP does what I'd argue is "right for proportional
fairness", so perhaps we're just disagreeing about terminology, and I
should take back the suggestion of changing LT-TCP :)

Cheers,
Lachlan
KK> Thanks for your input and I hope this clarifies a bit more of what
we've done and why...
-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603

From: [email-masked] (Lachlan Andrew)
Date: Sat Aug  4 00:57:17 2007
Subject: [Iccrg] LT-TCP followup
In-Reply-To: <002001c7d609$3e2a7c90$0200a8c0@fun>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <002001c7d609$3e2a7c90$0200a8c0@fun>
Message-ID: <[email-masked]>

Greetings Michael,

On 03/08/07, Michael Welzl <[email-masked]> wrote:
> > Lachlan Wrote
> >
> > No, we consider the whole path.  The assumption is just that that the
> > wireless link is the *last* hop.
>
> Hmm... I don't think that this makes much of a difference for what
> I was trying to say; see below...

The difference is that, in the framework we consider, we still
consider the congestion caused by the excess transmissions.
Intuitively, the wireless links being the last hop is the worst case,
because it causes the most congestion for a given received rate.

> That reminds me of the old congestion collapse scenario in one
> of the early Raj Jain papers, where a source which doesn't
> know about the small capacity of its last hop yet sends at
> a high rate can contribute to congestion on a hop before that,
> thereby causing the total throughput of the network to
> decrease even when sending rates are increased.

Yes, at Marina Del Rey you also mentioned the "two hop congestion
collapse" problem.  That may be a good way to explain my point.  A
flow which gets  1/k  of its packets through is exactly analogous to a
flow which uses  k  congested hops.  For a given receive rate, both
use  k  times "their share" of the resources, compared with a
single-hop lossless flow.  TCP doesn't give each flow a rate in
proportion to 1/k -- it gives it a rate in proportion to 1/\sqrt(k),
allowing the "resource intensive" flow to consume more resources.

Unfortunately, current TCP behaviour fits Jain's original definition
of congestion collapse.  Imagine a two-hop "parking lot" topology, in
which the two-hop flow is application limited.  If the two-hop flow
increases its sending rate, then the total network throughput goes
down.  I believe this is Jain's definition of congestion collapse.

That is all fixed by saying measuring the change in utility instead of
throughput.  The extra benefit to the two-hop flow outweighs the
disadvantage to the two short flows; because it has a lower current
rate, the percentage increase it gets is much larger than their
percentage decreases.

"Proportional fairness" (which in our contexts allocates equal send
rate to users, regardless of drop rate) would allocate 2/3 of each
bottleneck capacity to the one-hop flows, and 1/3 of each capacity to
the two-hop flow.  That corresponds to setting a window proportional
to  1/p  for a drop rate of  p.  In this simple case, the long flow
causes twice the congestion per unit throughput (the same amount on
two routers), and consequently gets half the rate.  Good.

TCP is "more fair", and gives a higher rate to the low-throughput
flow, by setting the window proportional to  1/sqrt(p).  (Is that
"acceptable"?  That's not for me to justify...)  This gives a ratio of
1:sqrt(2) instead of 1:2 in the rates.  Thus, the flow with the lower
rate is allowed to create more total congestion.  This is "fair",
because it is the underdog and needs help.

We can have a whole family, where the rate is proportional to
p^{-1/alpha};  proportional fairness uses  alpha=1,  TCP uses
alpha=2.  (Again, this isn't just what I'm proposing; this is what TCP
already does for flows of equal RTT.)

> Consider a long path with a wireless last hop. Consider a source
> which sends across this path, and let's say that all of a sudden,
> 90% of the packets are lost due to corruption, and that situation
> stays stable for a while. You argue that the sender should increase
> its rate.
>
> Now consider the first hop, which is the bottleneck, and assume that
> all other flows sharing it get 100% of their packets across most of
> the time (they don't traverse a wireless network).
>
> The  part that I don't get is: why can it be acceptable for the
> single sender which only gets 10% of its packets across anyway
> to increase its rate, and thereby increase the chance for all others
> to experience congestion?

That comes down to the whole issue of "what is fair?"  TCP wasn't
design to be fair for non-identical flows -- that is why flows with a
larger MSS or shorter RTT get higher throughput.

The best way I know of to answer fairness questions is in terms of
Kelly's utility maximisation.  The conversation would be:
A: Why should the high-loss flow get less effective throughput?
B: Because it creates more congestion per byte of throughput
A: How much less throughput should it get?
B: That depends on how much benefit it loses by sending at the lower rate.

Let's be specific.  Assume there are two flows sharing a 1Gbps link.
The "proportional fair" allocation (accounting for loss) would be that
User A gets 500Mbps throughput, while user B gets 500Mpbs through the
link, but only 50Mbps reaches the destination.  Intuitively, this
again corresponds to each flow causing the same amount of congestion.

However, remember that TCP is "more fair" than proportional fairness,
by giving extra bandwidth to the flows which get the least,
corresponding to  alpha=2.  Thus, in your example, when the flow
suddenly starts losing 90% of its packets, the TCP-fair thing to do
would be to reduce its payload by *less* than a factor of 10.  Of
course, to do that it needs to increase the sending rate slightly.
This flow causes more congestion than the lossless flow, the same as a
two-hop flow causes more congestion than a one-hop flow.  That is just
what TCP's fairness scheme implies.

In this example, the ratio would be 1:sqrt(10%).  User A would get
240Mbps throughput (and use 240Mbps of bandwidth), while User B would
get 76Mbps throughput (and use 760Mbps of bandwidth).

For comparison, in a 10-hop parking lot with lossless 316Mbps links,
each one-hop flow would get 240Mbps, and the 10-hop flow would get
76Mbps, using 760 "link * Mbps".

> I was also not aware that you're making a concrete proposal
> for a certain behavior - at least back in Marina Del Rey, I thought that
> you're merely trying to point out an interesting counterintutive issue

True.  I don't have a particular protocol (I'll put my vote behind
LT-TCP :) and I'm not sure if we should be TCP-friendly or
proportionally fair.  However, I think fairness should be consistently
designed in to protocols, rather than just "emerging" from a set of
rules.  In that case, being TCP-friendly implies we  should
increasing the send-rate of flows suffering packet corruption.

> In any case it would be helpful if you could explain it by means of
> one or two simple examples like the one I gave above.

I hope the above example explains the intuition.

Have a good trip,
Lachlan

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

From: [email-masked] (Lachlan Andrew)
Date: Fri Aug  3 21:49:17 2007
Subject: [Iccrg] LT-TCP followup
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings KK,

On 03/08/07, RAMAKRISHNAN, KADANGODE K (K. K.) <[email-masked]> wrote:
> We are very appreciative of the support for LT-TCP from the
> group. Thank you.

Yes, I hope it gets standardised.

> Here are a few points, in response to both Lachlan and Michael's emails.
>
> 1) In response to Lachlan Andrew's email, we realize that the fairness
> criterion may be up to debate. In LT-TCP, we have been trying to not
> pick a new one, and remain within the constraints that the Internet and
> TCP operate under.
[deleted]
> We continue to remain within
> the current TCP framework of sending as many bytes into the network
> as the window would allow, with the window dynamics remaining
> strictly in accordance with current TCP flow and congestion avoidance
> mechanisms.

My understanding is that you don't respond to lost packets.  That
seems very far from following the "letter of the law" of TCP.  If you
say that you are following the "spirit" of the law (which I agree you
are), then I would suggest that the spirit of the law is about how
much data that is transported.  If the FEC were done at a layer below
TCP (where IMHO it belongs), then it wouldn't be included as part of
the application rate.  Why should it be included now?

> We would like to emphasize that LT-TCP's
> advantage is only that it may use the residual capacity that is left
> un-utilized by TCP-SACK in such environments.

I've heard that argument used before (for HS-TCP etc), but never
really understood it.  How do you measure how much capacity TCP-SACK
can't use?  If SACK has a small enough RTT, then even at high loss
rates it will get almost full link utilisation.  What does LT-TCP do
then?

My understanding is that a flow which sends fast enough to induce
congestion losses will always slow down a competing flow which
responds to losses.

> 2) In response to Michael's (and thereby Sally's concern): we do not
> want to send, or keep sending, at a high rate, to overcome loss. We
> only send as much as the traditional TCP window flow and congestion
> avoidance mechanisms will allow.

Isn't the main difference that you don't consider packet erasures when
implementing the congestion avoidance mechanism?  I strongly agree
that is a  Good Thing  to do, but I don't think you can argue that
you're not *fundamentally* changing the mechanism.

If we're fundamentally changing the mechanism, I think we should work
out what we "should" do, rather than what changes the fewest "lines of
code" in the specifications...  We don't want to be overly constrained
by an   appearance   of backward compatibility.

Once again, LT-TCP does what I'd argue is "right for proportional
fairness", so perhaps we're just disagreeing about terminology, and I
should take back the suggestion of changing LT-TCP :)

Cheers,
Lachlan

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

From: [email-masked] (Michael Welzl)
Date: Fri Aug  3 21:12:11 2007
Subject: [Iccrg] LT-TCP followup
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <002001c7d609$3e2a7c90$0200a8c0@fun>

> > 5 In Marina Del Rey (and a preceding email), Lachlan presented
> >   his theory which contradicts the intuition in item #3 above.
> >   Could it be that you *only* consider a wireless link, not
> >   the rest of the path? That could be a reason for your idea
> >   of actually increasing the rate to make sense in your setup,
> >   but not in practice
> 
> No, we consider the whole path.  The assumption is just that that the
> wireless link is the *last* hop.  I agree that this doesn't consider
> the problem of uploading from a wireless link (which is still
> work-in-progress), but it certainly covers a very large fraction of
> the current cases.

Hmm... I don't think that this makes much of a difference for what
I was trying to say; see below...

> I was deliberately trying to make it sound counter-intuitive.  If it

Sure, I get that, but my problem is: on the one hand, I don't fully
understand your proposal (I just took a look at the paper you
pointed to - the last time I read it I'm sure it was only 2 pages
long, and I failed to fully grasp it - so please forgive me, I
should probably see if I can understand the updated version).
On the other, it just doesn't intuitively make sense to me, which
I think that it should eventually also do, once I take a closer
look at it with an example.

Consider a long path with a wireless last hop. Consider a source
which sends across this path, and let's say that all of a sudden,
90% of the packets are lost due to corruption, and that situation
stays stable for a while. You argue that the sender should increase
its rate.

Now consider the first hop, which is the bottleneck, and assume that
all other flows sharing it get 100% of their packets across most of
the time (they don't traverse a wireless network).

The  part that I don't get is: why can it be acceptable for the
single sender which only gets 10% of its packets across anyway
to increase its rate, and thereby increase the chance for all others
to experience congestion?

That reminds me of the old congestion collapse scenario in one
of the early Raj Jain papers, where a source which doesn't
know about the small capacity of its last hop yet sends at
a high rate can contribute to congestion on a hop before that,
thereby causing the total throughput of the network to
decrease even when sending rates are increased.

> I'm not sure what specific part of our/John Leslie's proposal you
> don't find acceptable, but if you tell me then I'll gladly do what I
> can to fix it :)

It's not unlikely that I'll find it acceptable once I've fully understood
it! So far, I was also not aware that you're making a concrete proposal
for a certain behavior - at least back in Marina Del Rey, I thought that
you're merely trying to point out an interesting counterintutive issue
(which I didn't, and still don't fully comprehend).

In any case it would be helpful if you could explain it by means of
one or two simple examples like the one I gave above.

Cheers,
Michael

From: [email-masked] (Lachlan Andrew)
Date: Fri Aug  3 20:02:03 2007
Subject: [Iccrg] LT-TCP followup
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Michael,

Thanks for your reply.

On 02/08/07, Michael Welzl <[email-masked]> wrote:
>
> 5 In Marina Del Rey (and a preceding email), Lachlan presented
>   his theory which contradicts the intuition in item #3 above.
>   Could it be that you *only* consider a wireless link, not
>   the rest of the path? That could be a reason for your idea
>   of actually increasing the rate to make sense in your setup,
>   but not in practice

No, we consider the whole path.  The assumption is just that that the
wireless link is the *last* hop.  I agree that this doesn't consider
the problem of uploading from a wireless link (which is still
work-in-progress), but it certainly covers a very large fraction of
the current cases.

I was deliberately trying to make it sound counter-intuitive.  If it
is phrased as "the application should send  slower  by a factor of
(1-e)^{1/2}", does that make it sound more acceptable?  The key to
remember is that the rate   received   (for LT-TCP, that is the rate
before FEC encoding) is less that the rate   sent   (i.e., the rate
after FEC encoding).  I agree that the former should go down, but
there is a case for the latter to go up.  This is in keeping with what
John Leslie  proposed:

On 09/09/06, John Leslie <[email-masked]> wrote:
> Michael Welzl <[email-masked]> wrote:
> > The correct reaction to corruption.
>
>    Actually, there is one: increase the reundancy of coding.
>
>    This actually will result in a hopefully-slight _increase_ in bandwidth
> demand. This is _not_ wrong!

What my calculations do is show that (a) for max-min or "TCP-friendly"
fairness, John is right that the bandwidth demand goes up, (b) For
proportional fairness, TCP-HACK, FAST and LT-TCP are right that the
bandwidth demand should be unchanged (with the increased redundancy,
as FEC or retransmissions, lowering the payload rate).

When I suggested changing LT-TCP, that was just removing the
incongruity that LT-TCP aims to be TCP-friendly, and so it would be
sensible for it to have response (a).

> 6 K K Ramakrishnan presented LT-TCP in Marina Del Rey too,
>   and now there's this follow-up. Given the unknown *rate*
>   response to corruption, in my very personal opinion,
>   this seems to be the first acceptable proposal

I agree that LT-TCP is the first practical proposal, as a way to
implement the control.

However, as you say Michael, it doesn't address the problem of the
"unknown *rate* response".  My guess is that it includes the FEC
overhead as part of the allowed rate, and causes the application to
send at reduced rate  (1-e)  where  e  is the bit erasure probability.
 At the level of abstraction used in my model, that is the same as
"ignoring the loss in calculating the sending rate", which (when all
of the loss is on the last hop) gives proportional fairness.

LT-TCP answers the application's question "*How* do I send at a lower
rate when my link has errors", but not "*Why* do I send at a lower
rate, by a factor of (1-e)?  Why not (1-e)^2?  Why not (1-e)^{1/2}?"

I'm not sure what specific part of our/John Leslie's proposal you
don't find acceptable, but if you tell me then I'll gladly do what I
can to fix it :)

Cheers,
Lachlan

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

From: [email-masked] (RAMAKRISHNAN, KADANGODE K (K. K.))
Date: Fri Aug  3 17:58:49 2007
Subject: [Iccrg] LT-TCP followup
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

We are very appreciative of the support for LT-TCP from the
group. Thank you. Here are a few points, in response to both Lachlan and
Michael's emails.

1) In response to Lachlan Andrew's email, we realize that the fairness
criterion may be up to debate. In LT-TCP, we have been trying to not
pick a new one, and remain within the constraints that the Internet and
TCP
operate under. The criteria suggested by Lachlan that the fairness
should be based on the received goodput emphasizes that a flow
experiencing loss deserves a larger share of the bandwidth than
other flows through the rest of the network, because the utility as
perceived by the receiver (and hence the application) is the primary
measure of interest. Although we may agree that the utility as
perceived by the application is what ultimately matters in an
egalitarian world, we have been more restrained in our approach. This
is driven by the need to have our protocol enhancements be widely
applicable, where the bottleneck link for a flow may not be the
wireless hop and there may be one or more wireless hops that are
anywhere in the path. As a consequence, we continue to remain within
the current TCP framework of sending as many bytes into the network
as the window would allow, with the window dynamics remaining
strictly in accordance with current TCP flow and congestion avoidance
mechanisms. The question that has come up is that under loss, TCP
(e.g., SACK) may not get as high a throughput as LT-TCP when both
flow through a lossy link. We would like to emphasize that LT-TCP's
advantage is only that it may use the residual capacity that is left
un-utilized by TCP-SACK in such environments.  When TCP builds up its
demand (e.g., after a transient loss event), LT-TCP continues to
remain "TCP-friendly".

2) In response to Michael's (and thereby Sally's concern): we do not
want to send, or keep sending, at a high rate, to overcome loss. We
only send as much as the traditional TCP window flow and congestion
avoidance mechanisms will allow. The difference is in what we send
within that window.  As a result, the fairness achieved is the same as
TCP.  The load of this flow going over a lossy wireless path is no
different from another flow that is not going over the wireless
path. The load shares on the non-wireless paths therefore do not
change from TCP, which we believe is important. At the same time,
within that share for the flow, we attempt to maximize the utility for
the flow in the presence of losses. We size the amount of loss
tolerance to get the optimal goodput for the flow, without it
adversely impacting other flows. With the combination of link layer
enhancements (Hybrid ARQ), we can also strike a balance between
goodput and end-end delay.  This is why we determine how much FEC to
add, and to balance that FEC based on a proactive size of FEC based on
the loss observed, and a reactive FEC based on the short-term feedback
of SACK.

3) We do not add overhead when there is no loss. Therefore, there is
no "deadweight" overhead when the flow goes over a lossless path. As
such, the LT-TCP enhancements to TCP can be general and used always. 
It does not have to be "turned on" once we determine we are on
a wireless path or any such method.

4) We use ECN to disambiguate between congestion and packet corruption
or erasure. We realize that it has taken 20 years for ECN to get where
it has, and it may take a while longer before it gets ubiquitously used
:-). 
So, we do make sure that if the environment does not have ECN in the
end-end
path, then we will turn off the use of LT-TCP, so that we have the
reaction to loss due to congestion as used by traditional TCP. If
there is another, more direct, indicator of packet corruption, we are
happy to use it and we think our mechanisms will work just as well.

Thank you very much,
   K. K. Ramakrishnan, Shiv Kalyanaraman and Vijay Subramanian.
----
K. K. Ramakrishnan                  Email: [email-masked]
AT&T Labs-Research, Rm. A117        Tel: (973)360-8764
180 Park Ave, Florham Park, NJ 07932    Fax: (973) 360-8871
      URL: http://www.research.att.com/info/kkrama

From: [email-masked] (Michael Welzl)
Date: Fri Aug  3 13:26:24 2007
Subject: [Iccrg] Procedure for obtaining ICCRG reviews
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> As you probably know, I did already contribute to that document Michael.

Yes I know, but....

> > I don't want to get into a discussion
> > of safety criteria here when this was/is already done elsewhere.
> 
> I guess my real point was to flag up that reviewers are going to have  
> to make a decision between, say, recommendation 1 (safe to deploy)  
> and recommendation 2a (safe in controlled environments).  Its not  

... it's just that I just hoped that the document sufficiently
deals with all the issues related to these categories as it
also defines them.

Assuming that it does, I thought that we don't need to discuss
such details anymore when we're deciding on the process.

So let me take another look at the document: recommendation
"Experimental 1" is only possible if guidelines 1, 3, 4, 8
are fulfilled.

It's obvious to default to "Experimental 2a" or 2b otherwise;
while Quick-Start is a nice example of a 2a-but-not-2b case,
I'm not sure how to derive a guideline for a reviewer that
would make it easier to distinguish between these two cases.

As for recommendation "Informational", that would be used for
a mechanism that is considered dangerous to use on the Internet,
i.e. not at all fulfilling the guidelines, but still of enough
interest to the community to justify publishing it as Informational
in the opinion of the reviewer.

> clear to me (if I put my reviewers hat on for a moment) how to make  
> that decision in a consistent way - perhaps the cautious thing is  
> simply to default to 2a if an algorithm passes basic tests.   ID  
> draft-ietf-tsvwg-cc-alt-04.txt deals with general principles but  
> these still need to be turned into practice. Worth discussing on the  
> iccrg surely ?

Hmm... I honestly think that these general principles are as good
as it gets - I don't see how we could reasonably agree on more
practical, detailed guidelines that talk about things like
timeout thresholds etc, like you mention.

I think that it's general principles + common sense (which will
be quite subjective, but this will be okay because we consider
you an expert  :)  )

Cheers,
Michael

From: [email-masked] (Douglas Leith)
Date: Fri Aug  3 21:22:13 2007
Subject: [Iccrg] Procedure for obtaining ICCRG reviews
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 3 Aug 2007, at 10:15, Michael Welzl wrote:

> On Fri, 2007-08-03 at 09:51 +0100, Douglas Leith wrote:
>> It might be worth trying to clarify what is meant by "safe to deploy"
>> when making one of these recommendations.  For example, one argument
>> is that inclusion of
>> timeout functionality with backoff of the timeout threshold is enough
>> for "safety" since it will prevent complete congestion collapse (at
>> high loss rates operation will revert back to standard TCP
>> behaviour).  Is this enough ?  In any case, its probably a good idea
>> to distinguish "safety" from  "performance" per se.
>
> As I said, the recommendations were derived from
> draft-ietf-tsvwg-cc-alt-04.txt - so what we're now doing is
> actually discuss this draft itself, which states:
>
> "    The minimum requirements for approval for widespread  
> deployment in
>     the global Internet include the following guidelines (1) on
>     assessing the impact on standard congestion control, (3) on
>     investigation of the proposed mechanism in a range of  
> environments,
>     guideline (4) on protection against congestion collapse and
>     guideline (8), discussing whether the mechanism allows for
>     incremental deployment."
>
> The guidelines themselves are part of that document. I suggest
> that you look them up, and criticize them directly in tsvwg
> if you disagree with them.

As you probably know, I did already contribute to that document Michael.

> I don't want to get into a discussion
> of safety criteria here when this was/is already done elsewhere.

I guess my real point was to flag up that reviewers are going to have  
to make a decision between, say, recommendation 1 (safe to deploy)  
and recommendation 2a (safe in controlled environments).  Its not  
clear to me (if I put my reviewers hat on for a moment) how to make  
that decision in a consistent way - perhaps the cautious thing is  
simply to default to 2a if an algorithm passes basic tests.   ID  
draft-ietf-tsvwg-cc-alt-04.txt deals with general principles but  
these still need to be turned into practice. Worth discussing on the  
iccrg surely ?

Doug

From: [email-masked] (Michael Welzl)
Date: Fri Aug  3 10:16:22 2007
Subject: [Iccrg] Procedure for obtaining ICCRG reviews
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Fri, 2007-08-03 at 09:51 +0100, Douglas Leith wrote:
> It might be worth trying to clarify what is meant by "safe to deploy"  
> when making one of these recommendations.  For example, one argument  
> is that inclusion of
> timeout functionality with backoff of the timeout threshold is enough  
> for "safety" since it will prevent complete congestion collapse (at  
> high loss rates operation will revert back to standard TCP  
> behaviour).  Is this enough ?  In any case, its probably a good idea  
> to distinguish "safety" from  "performance" per se.

As I said, the recommendations were derived from
draft-ietf-tsvwg-cc-alt-04.txt - so what we're now doing is
actually discuss this draft itself, which states:

"    The minimum requirements for approval for widespread deployment in
    the global Internet include the following guidelines (1) on
    assessing the impact on standard congestion control, (3) on
    investigation of the proposed mechanism in a range of environments,
    guideline (4) on protection against congestion collapse and
    guideline (8), discussing whether the mechanism allows for
    incremental deployment."

The guidelines themselves are part of that document. I suggest
that you look them up, and criticize them directly in tsvwg
if you disagree with them. I don't want to get into a discussion
of safety criteria here when this was/is already done elsewhere.

Cheers,
Michael

From: [email-masked] (Douglas Leith)
Date: Fri Aug  3 09:54:49 2007
Subject: [Iccrg] Procedure for obtaining ICCRG reviews
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

It might be worth trying to clarify what is meant by "safe to deploy"  
when making one of these recommendations.  For example, one argument  
is that inclusion of
timeout functionality with backoff of the timeout threshold is enough  
for "safety" since it will prevent complete congestion collapse (at  
high loss rates operation will revert back to standard TCP  
behaviour).  Is this enough ?  In any case, its probably a good idea  
to distinguish "safety" from  "performance" per se.

Doug

On 3 Aug 2007, at 08:46, Michael Welzl wrote:

> Hi all,
>
> Before I use it for the CTCP draft (which is the only one
> on our table so far), I would like to solicit comments
> on the email which I'm planning to use for obtaining
> reviews.
>
> In particular, I wonder what you think about the final
> recommendation idea, which I derived from section 2 of
> draft-ietf-tsvwg-cc-alt-04.txt - any suggestions are
> welcome.
>
> Cheers,
> Michael
>
>
> ===========================================
>
> Dear all,
>
> As you probably know, ICCRG has agreed to obtain reviews
> on experimental congestion control proposals before they
> are brought to the IETF (specifically the TCPM group). While
> the competence to actually decide about acceptance or not is
> with TCPM, it is expected that they will take our reviews
> into account. This process is outlined here:
> http://www.ietf.org/IESG/content/ions/drafts/ion-tsv-alt-cc.txt
>
> Right now, we are looking for reviews on draft-xyz:
> http://...
>
> We would like to get feedback within 2 1/2 months
> (earlier if possible).
>
> If you're interested in doing a review, please send a note
> to Wes and me. Reviews can be sent to the list, or directly
> to us for anonymization before reflecting them out to the
> list, if desired.
>
> Reviewers are strongly advised to:
>
> * read draft-ietf-tsvwg-cc-alt-04:
>   http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-cc-alt-04.txt
>
> * consider not only the draft alone, but also papers referenced
>   therein, where the authors should have carried out a performance
>   evaluation of their mechanism, including studies which show the
>   impact of the new mechanism on standard TCP. When looking at
>   such studies, this document is recommended to be used for guidance:
>   http://www.ietf.org/internet-drafts/draft-irtf-tmrg-metrics-09.txt
>
>
> Reviews should include one of the following final recommendations:
>
> * Experimental 1:
>   The proposed mechanism is judged to be safe to deploy for
>   best-effort traffic in the global Internet and further
>   investigated in that environment.
>
> * Experimental 2 A:
>   While promising, the proposed mechanism is not deemed safe
>   enough for widespread deployment as best-effort traffic on
>   the Internet, but can be specified to facilitate investigations
>   in simulation, testbeds, or controlled environments.
>
> * Experimental 2 B:
>   The IETF does not yet have sufficient understanding to decide
>   if the algorithm is or is not safe for deployment on the Internet.
>
> * Informational:
>   The proposed mechanism does not meet the criteria for recommending
>   publication of the draft as an Experimental RFC. It should be
>   considered for publication as an Informational RFC for the benefit
>   of the IETF and IRTF communit, provided that it carries an
>   explicit warning against using the scheme in the global Internet.
>
> * Not ready:
>   The draft is not ready for publication as an Experimental or
>   Informational RFC.
>
>
> A review can be as short as a selection from the list of options,
> although preferably it would include at least some brief
> discussion or justification. No matter how long the feedback
> is, we expect reviewers to have thoroughly read all the
> necessary material.
>
> Thanks in advance to anyone who volunteers!
>
> Cheers,
> Michael
>
> ===========================================
>
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Michael Welzl)
Date: Fri Aug  3 08:47:48 2007
Subject: [Iccrg] Procedure for obtaining ICCRG reviews
Message-ID: <[email-masked]>

Hi all,

Before I use it for the CTCP draft (which is the only one
on our table so far), I would like to solicit comments
on the email which I'm planning to use for obtaining
reviews.

In particular, I wonder what you think about the final
recommendation idea, which I derived from section 2 of
draft-ietf-tsvwg-cc-alt-04.txt - any suggestions are
welcome.

Cheers,
Michael

===========================================

Dear all,

As you probably know, ICCRG has agreed to obtain reviews
on experimental congestion control proposals before they
are brought to the IETF (specifically the TCPM group). While
the competence to actually decide about acceptance or not is
with TCPM, it is expected that they will take our reviews
into account. This process is outlined here:
http://www.ietf.org/IESG/content/ions/drafts/ion-tsv-alt-cc.txt

Right now, we are looking for reviews on draft-xyz:
http://...

We would like to get feedback within 2 1/2 months
(earlier if possible).

If you're interested in doing a review, please send a note
to Wes and me. Reviews can be sent to the list, or directly
to us for anonymization before reflecting them out to the
list, if desired.

Reviewers are strongly advised to:

* read draft-ietf-tsvwg-cc-alt-04:
  http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-cc-alt-04.txt

* consider not only the draft alone, but also papers referenced
  therein, where the authors should have carried out a performance 
  evaluation of their mechanism, including studies which show the
  impact of the new mechanism on standard TCP. When looking at
  such studies, this document is recommended to be used for guidance:
  http://www.ietf.org/internet-drafts/draft-irtf-tmrg-metrics-09.txt

Reviews should include one of the following final recommendations:

* Experimental 1:
  The proposed mechanism is judged to be safe to deploy for
  best-effort traffic in the global Internet and further
  investigated in that environment.

* Experimental 2 A:
  While promising, the proposed mechanism is not deemed safe
  enough for widespread deployment as best-effort traffic on
  the Internet, but can be specified to facilitate investigations
  in simulation, testbeds, or controlled environments.

* Experimental 2 B:
  The IETF does not yet have sufficient understanding to decide
  if the algorithm is or is not safe for deployment on the Internet.

* Informational:
  The proposed mechanism does not meet the criteria for recommending
  publication of the draft as an Experimental RFC. It should be
  considered for publication as an Informational RFC for the benefit
  of the IETF and IRTF communit, provided that it carries an
  explicit warning against using the scheme in the global Internet.
  
* Not ready:
  The draft is not ready for publication as an Experimental or
  Informational RFC.

A review can be as short as a selection from the list of options,
although preferably it would include at least some brief
discussion or justification. No matter how long the feedback
is, we expect reviewers to have thoroughly read all the
necessary material.

Thanks in advance to anyone who volunteers!

Cheers,
Michael

===========================================

From: [email-masked] (Michael Welzl)
Date: Fri Aug  3 07:32:20 2007
Subject: [Iccrg] LT-TCP followup
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

This is an interesting discussion.

I'd like to share my very personal, subjective view of the
IETF/IRTF related history regarding the congestion control
reaction with you:

1 in the research community, we had some proposals like
  TCP HACK, which simply suggested *not* to react to
  corruption at all

2 in the IETF, no corruption detection mechanism existed
  for a long time. After the long discussions preceding
  the specification of UDP-Lite, and the later addition
  of partial and separate checksums to DCCP, we now have
  the question of how to react to corruption when we see
  it on the table

3 during the DCCP discussions, Sally Floyd said that it's
  obviously not desirable to keep sending at a high rate
  in the presence of corruption. To me, this is intuitively
  clear: consider a source that sends at a high rate across
  a path which starts out with a wireless network but then
  includes lots of additional non-wireless hops. This source
  then contributes to congestion on these additional hops -
  or, in the absence of congestion, it increases the chance
  that congestion would occur

4 the group agreed that it can't decide on a correct
  behavior to corruption, thus left this issue open in
  the specification, pointing to future research

5 In Marina Del Rey (and a preceding email), Lachlan presented
  his theory which contradicts the intuition in item #3 above.
  Could it be that you *only* consider a wireless link, not
  the rest of the path? That could be a reason for your idea
  of actually increasing the rate to make sense in your setup,
  but not in practice

6 K K Ramakrishnan presented LT-TCP in Marina Del Rey too,
  and now there's this follow-up. Given the unknown *rate*
  response to corruption, in my very personal opinion,
  this seems to be the first acceptable proposal

Cheers,
Michael

On Thu, 2007-08-02 at 18:29 -0700, Lachlan Andrew wrote:
> Greetings all,
> 
> Vijay Subramanian's email reminded me to remind the group of my
> presentation to the ICCRG in February on what rate "should" be used
> when there are corruption losses.
> 
> An incomplete write-up is available at
> <http://netlab.caltech.edu/~lachlan/abstract/TCP_with_erasures.pdf>,
> but the main points are as follows:
> 
> If flows experience non-corruption loss, we still want to allocate
> rate "fairly".  In general multi-link networks, fairness cannot be
> measured by seeing how far rates are from equal, and is better
> measured using Kelly's utility maximisation framework.
> 
> The draft studies the (common) special case where the loss is on the
> last link, such as when downloading data from a wireless hot-spot.  If
> loss is high, we must distinguish between fairness of send rates and
> of receive rates.  We claim that fairness should be of receive rates,
> but that send rates should be used when calculating the level of
> congestion in the network.  In this framework:
> 
> - If we aim to get maximum throughput (ignoring fairness), the only
> flows which should transmit are those which have the minimum loss.
> - If we aim to get max-min fairness, the send rate should scale up as
> 1/(1-e)  where  e  is the erasure rate (that is, retransmissions don't
> count at all as part of our "fair rate")
> - If we want proportional fairness (as FAST implements) we should send
> at the *same* rate regardless of how much loss there is on the last
> hop.
> ******
> - If we want the same fairness that TCP-friendliness implies (which
> corresponds to "alpha=2" in Mo and Walrand's terminology and which I
> think is what LT-TCP wants) then we should actually send at a slightly
> *higher* rate (by a factor of 1/sqrt(1-e)) when there is loss than
> when there is no loss.
> ******
> 
> Agreement or disagreement would be welcome.
> 
> The above draft doesn't consider the implementation at all.  I'd
> encourage the LT-TCP designers to think about whether LT-TCP
> can/should be modified to use this "fair" rate, and I'd be happy to
> discuss it either on- or off-list.
> 
> Cheers,
> Lachlan
> 
> On 02/08/07, Vijay Subramanian <[email-masked]> wrote:
> >
> > At the end of the ICCRG meeting in Chicago , Wesley Eddy suggested that we
> > provide some input on how LT-TCP, our enhancements to TCP, can help in solving
> > some of the open research issues that are being currently addressed in the
> > ICCRG.
> >
> > Challenge 3.3: Corruption Loss
> > The draft poses the challenges: How should corruption be detected and what
> > should be the response?
> >
> > ... In particular, under no-loss conditions,
> > LT-TCP introduces no overhead and the behavior is identical to that of
> > TCP-SACK.
> 

From: [email-masked] (Lachlan Andrew)
Date: Fri Aug  3 02:30:57 2007
Subject: [Iccrg] LT-TCP followup
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Greetings all,

Vijay Subramanian's email reminded me to remind the group of my
presentation to the ICCRG in February on what rate "should" be used
when there are corruption losses.

An incomplete write-up is available at
<http://netlab.caltech.edu/~lachlan/abstract/TCP_with_erasures.pdf>,
but the main points are as follows:

If flows experience non-corruption loss, we still want to allocate
rate "fairly".  In general multi-link networks, fairness cannot be
measured by seeing how far rates are from equal, and is better
measured using Kelly's utility maximisation framework.

The draft studies the (common) special case where the loss is on the
last link, such as when downloading data from a wireless hot-spot.  If
loss is high, we must distinguish between fairness of send rates and
of receive rates.  We claim that fairness should be of receive rates,
but that send rates should be used when calculating the level of
congestion in the network.  In this framework:

- If we aim to get maximum throughput (ignoring fairness), the only
flows which should transmit are those which have the minimum loss.
- If we aim to get max-min fairness, the send rate should scale up as
1/(1-e)  where  e  is the erasure rate (that is, retransmissions don't
count at all as part of our "fair rate")
- If we want proportional fairness (as FAST implements) we should send
at the *same* rate regardless of how much loss there is on the last
hop.
******
- If we want the same fairness that TCP-friendliness implies (which
corresponds to "alpha=2" in Mo and Walrand's terminology and which I
think is what LT-TCP wants) then we should actually send at a slightly
*higher* rate (by a factor of 1/sqrt(1-e)) when there is loss than
when there is no loss.
******

Agreement or disagreement would be welcome.

The above draft doesn't consider the implementation at all.  I'd
encourage the LT-TCP designers to think about whether LT-TCP
can/should be modified to use this "fair" rate, and I'd be happy to
discuss it either on- or off-list.

Cheers,
Lachlan

On 02/08/07, Vijay Subramanian <[email-masked]> wrote:
>
> At the end of the ICCRG meeting in Chicago , Wesley Eddy suggested that we
> provide some input on how LT-TCP, our enhancements to TCP, can help in solving
> some of the open research issues that are being currently addressed in the
> ICCRG.
>
> Challenge 3.3: Corruption Loss
> The draft poses the challenges: How should corruption be detected and what
> should be the response?
>
> ... In particular, under no-loss conditions,
> LT-TCP introduces no overhead and the behavior is identical to that of
> TCP-SACK.

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

From: [email-masked] (Vijay Subramanian)
Date: Thu Aug  2 22:05:02 2007
Subject: [Iccrg] LT-TCP followup
Message-ID: <[email-masked]>

Hi folks,

At the end of the ICCRG meeting in Chicago , Wesley Eddy suggested that we
provide some input on how LT-TCP, our enhancements to TCP, can help in solving
some of the open research issues that are being currently addressed in the
ICCRG. To this end, we look at 3 challenges outlined in the draft and discuss
how these can be impacted by our work.

Following are some notes regarding how LT-TCP can contribute to solving the open 
research issues
outlined in M. Welzl, D. Papadimitriou, M. Scharf, "Open Research Issues in
Internet Congestion Control". The draft can be found at
http://www.ietf.org/internet-drafts/draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt

Section 3.2: Dynamic Range of Requirements:
The draft notes that TCP is required to operate under a wide variety of
scenarios and dynamically changing conditions. We note that TCP is designed for
low end-to-end loss rates. For example, even robust variants such as TCP-SACK
are unable to perform well for packet loss rates above 5%. As wireless networks
become ubiquitous, we expect to see an increase in the end-end loss rate
especially as cell sizes get smaller and accommodate higher data rates. An
enhancement of TCP is needed to enable it to be robust to higher loss rates and
we believe LT-TCP fills this gap.

Challenge 3.3: Corruption Loss
The draft poses the challenges: How should corruption be detected and what
should be the response?  LT-TCP solves this problem by making use of Explicit
Congestion Notification (ECN). The draft by Welzl et. al. discusses possible
feedback options of which ECN is one (and the simplest). In an ECN environment,
LT-TCP assumes packet loss is caused by corruption and ECN signals are assumed
to be the primary indicators of congestion.  Of course, if ECN is not supported
in the end-end path, LT-TCP can fallback to TCP-SACK behavior.

The additional question of how to react to corruption is addressed by noting
that techniques of error and erasure correction have proven to be efficient in
dealing with losses at PHY/MAC layers. We naturally extend TCP-SACK with
Forward Error Correction (FEC) to cope with high losses. But unlike the PHY/MAC
layer solutions, our design of LT-TCP adopts FEC at the granularity of packet.
The FEC is designed to be adaptive and scales according to the estimated loss
rate, and is partitioned into a proactive (based on medium-term loss rate
estimation) and reactive (based on the short-term measure of loss). Information
already available in SACK blocks can be used to tune the FEC and minimize
overhead.  By seamlessly enhancing TCP-SACK with FEC, we can not only provide
protection against high losses but do so with minimal overhead and changes to
the existing TCP framework.  The overhead of error protection introduced by
LT-TCP scales with the loss rate. In particular, under no-loss conditions,
LT-TCP introduces no overhead and the behavior is identical to that of
TCP-SACK.

Challenge: Impact on Latency: Challenge 7 talks about the requirements of
elastic traffic.  Interactive applications have delay constraints. Clearly, as
the loss rate increases, increased retransmissions and higher link layer
latencies (due to these retransmissions) will increase the time taken to
deliver a packet to the receiving application.

LT-TCP minimizes latency through the use of FEC, to proactively protect against
packet erasures in a lossy environment.  Since FEC packets can be used to
recover lost data packets, retransmissions of data packets (as in current TCP
variants) can be complemented with FEC packets under these conditions.  A
sufficient subset of the FEC block can be used to recover the original data
packets. This has the potential to significant reduce the in data transfer time
in lossy environments, compared to retransmission driven recovery techniques.
LT-TCP adds virtually no additional delay in a loss-free environment.

Any feedback or suggestions are highly appreciated.

Thanks,

Vijay Subramanian

Networks Lab, RPI :
Phone: 518-276-8289
http://poisson.ecse.rpi.edu/~vijay