Subject: [Iccrg] FW: [tana] HEADS UP: charter going for external review
From: [email-masked] (Eddy, Wesley M. (GRC-RCN0)[VZ])
Date: Thu Oct 30 19:17:31 2008

FYI - ICCRG people are likely to have interest in this proposed charter
for a new IETF working group to address some of the issues with
congestion
control that p2p applications have encountered:

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Lars Eggert
>Sent: Thursday, October 30, 2008 3:06 PM
>To: [email-masked]
>Subject: [tana] HEADS UP: charter going for external review
>
>Hi,
>
>FYI, during the informal telechat today, the IESG has agreed to start  
>external review of the WG charter. You can find the charter text that  
>will be sent out by the secretariat for feedback below. (Stas, thanks  
>for incorporating the feedback from the list!) You'll see that we've  
>attempted to improve the WG name, too: "Low Extra Delay Background  
>Transport (LEDBAT) WG".
>
>The wider IETF community now gets one week to comment, and the IESG  
>will then decide whether or not to charter during the telechat next  
>Thursday. Please participate during the charter discussion on 
>the main  
>IETF list.
>
>Finally: I'm looking for additional candidates for a second co-chair.  
>If you are interested and have the cycles, please drop me a private  
>email that explains why you'd be a good choice. There is *no*  
>requirement for having prior IETF chairing experience.
>
>Lars
>
>---
>
>Low Extra Delay Background Transport (LEDBAT) WG
>[Note: The LEDBAT WG stems from the TANA BoF held in Dublin.]
>
>
>Chair(s):
>* Stanislav Shalunov <[email-masked]>
>* 2nd co-chair to be determined
>
>Transport Area Director(s):
>* Magnus Westerlund <[email-masked]>
>* Lars Eggert <[email-masked]>
>
>Transport Area Advisor:
>* Lars Eggert <[email-masked]>
>
>
>Mailing Lists:
>
>General Discussion: [email-masked]
>To Subscribe: [email-masked]
>In Body: (un)subscribe
>Archive: http://www.ietf.org/mail-archive/web/tana/
>[Note: If chartered, mailing list will change to [email-masked].]
>
>
>Description of Working Group:
>
>The LEDBAT WG is chartered to standardize a congestion
>control mechanism that should saturate the bottleneck,
>maintain low delay, and yield to standard TCP.
>
>Applications that transmit large amounts of data for a long
>time with congestion-limited TCP, but without AQM, fill the
>buffer at the head of the bottleneck link. With FIFO queue,
>this increases the delay experienced by other applications.
>With buffer of one RTT, the delay doubles. In some cases,
>the extra delay may be much larger. This is a particularly
>acute and common case is when P2P applications upload over
>thin home uplinks: delays in these cases can sometimes be of
>the order of seconds.
>
>The IETF's standard end-to-end transport protocols have not
>been designed to minimize the extra delay introduced by them
>into the network. TCP, as a side effect of filling the
>buffer until it experiences drop-tail loss, effectively
>maximizes the delay. While this works well for applications
>that are not delay-sensitive, it harms interactive
>applications that share the same bottleneck. VoIP and games
>are particularly affected, but even web browsing may become
>problematic.
>
>LEDBAT is a transport-area WG that will focus on broadly
>applicable techniques that allow large amounts of data to be
>consistently transmitted without substantially affecting the
>delays experienced by other users and applications.
>
>The WG will work on the following:
>
>(1) An experimental congestion control algorithm for
>     less-than-best-effort "background" transmissions, i.e., an
>     algorithm that attempts to scavenge otherwise idle bandwidth
>     for its transmissions in a way that minimizes interference
>     with regular best-effort traffic.
>
>     Desired features of such an algorithm are:
>
>     * saturate the bottleneck
>
>     * eliminate long standing queues and thus keep
>       delay low when no other traffic is present
>
>     * quickly yield to traffic sharing the same bottleneck queue
>       that uses standard TCP congestion control
>
>     * add little to the queueing delays induced by TCP traffic
>
>     * operate well in networks with FIFO queueing with drop-tail
>       discipline
>
>     * be deployable for popular applications that currently
>       comprise noticeable fractions of Internet traffic
>
>     * where available, use explicit congestion notification (ECN),
>       active queue management (AQM), and/or end-to-end
>       differentiated services (DiffServ).
>
>     Application of this algorithm to existing transport
>     protocols (TCP, SCTP, DCCP) is expected to occur in the
>     working groups that maintain those protocols.
>
>     Once experience is gained with this congestion control
>     algorithm on the Internet, the WG will consider if it is
>     appropriate to ask the IESG to advance the document as a
>     Proposed Standard.
>
>(2) A document that clarifies the current practices of
>     application design and reasons behind them and discusses the
>     tradeoffs surrounding the use of many concurrent TCP
>     connections to one destination and/or to different
>     destinations.
>
>     Applications routinely open multiple TCP connections.  For
>     example, P2P applications maintain connections to a number
>     of different peers while web browsers perform concurrent
>     downloads from the same web server.  Application designers
>     pursue different goals when doing so: P2P apps need to
>     maintain a well-connected mesh in the swarm while web
>     browsers mainly use multiple connections to parallelize
>     requests that involve application latency on the web server
>     side.  The IETF transport area community is concerned about
>     this practice, because standard Internet congestion control
>     results in different transport connections sharing
>     bottleneck capacity. When an application uses several
>     non-rate-limited transport connections to transfer through a
>     bottleneck, it may obtain a larger fraction of the
>     bottleneck than if it had used fewer connections. Although
>     capacity is the most commonly considered bottleneck
>     resource, middlebox state table entries are also an
>     important resource for an end system communication. Other
>     resource types may exist, and the guidelines are expected to
>     comprehensively discuss them.
>
>     Applications use a variety of techniques to mitigate these
>     concerns.  These techniques have not always been reviewed by
>     the IETF and their interaction with TCP dynamics is poorly
>     understood.  The WG will document the known techniques,
>     discussing the consequences and, where appropriate, provide
>     guidance to application designers.
>
>
>Goals and Milestones:
>
>Oct 2009  Submit "Multiple Transport Connections in 
>Applications Design"
>           to the IESG for consideration as an Informational RFC
>
>Oct 2009  Submit "Low Extra Delay Background Transport (LEDBAT)"
>           to the IESG for consideration as an Experimental RFC
>
>
>_______________________________________________
>tana mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tana
>

From: [email-masked] (Lisong Xu)
Date: Thu Oct 30 16:27:35 2008
Subject: [Iccrg] CUBIC I-D feedback from an implementor's perspective
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Thanks, Lawrence!

Please see my comments below.
Lisong

Lawrence Stewart wrote:
> Hi All,
> 
> I've been working on and off independently implementing and testing some
> of the proposed congestion control algorithms in FreeBSD as part of our
> NewTCP research project [1]. So far, I've completed a functional HTCP
> and I'm currently working on CUBIC with others planned as future work. I
> have some feedback for the HTCP and CUBIC draft authors based on my
> implementation experiences. Below are my current feedback notes for CUBIC.
> 
> All comments below relate to draft-rhee-tcpm-cubic-01.txt
> 
> 
> Units for variables
> -------------------
> 
> The correct units for variables appear to be ambiguous. (For example, I
> presume cwnd is in pkts, and time t is in seconds - but I couldn't
> find that clearly stated in the I-D.)
> 
> For example in the BSD stack, cwnd is calculated and used in
> bytes, and time is calculated in terms of kernel ticks. However putting
> cwnd in bytes into the CUBIC equations produces results that I believe
> are demonstrably incorrect, whereas using pkts seems to produce expected
> results. Similar problems arise using ticks instead of regular time.
> 
> It might even be worth providing equivalent functions for both pkt and
> byte based cwnd so that the implementor doesn't have to think too hard.
> At the moment, I'm just converting to pkts by dividing cwnd by smss, but
> it's not ideal. And again, similar issues exist using ticks for time.
> 

The unit of Cwnd does not matter for any equation in Section 3. When we 
give the specific example of Cwnd in Section 4, such tables 1 and 2, the 
unit of Cwnd is MSS, as stated in the tables.

> 
> Convention for "beta"
> ---------------------
> 
> The I-D does not use the convention that beta represents the
> multiplicative decrease factor (i.e. cwnd = cwnd * beta on congestion).
> It instead uses beta in the following context: cwnd = cwnd * (1-beta) on
> congestion.
> 
> It took me a while to wrap my head around the I-D's use of the term 
> "multiplicative decrease factor" for beta in this context. I would 
> suggest that it would reduce confusion and implementation errors to 
> either refer to beta in the more usual context i.e. make it 0.8 and 
> modify the I-D's equations appropriately, or change the variable in the 
> I-D to be called something else.
> 
> If the community feels the draft's use of beta is appropriate, then
> perhaps we should standardise the meaning of "beta" somewhere for people
> writing/reading congestion control related documents to cite/refer to so 
> as to avoid each draft having its own interpretation.
> 

You are right that maybe we should standardize it. I myself is sometimes 
confused with the definition of this "multiplicative decrease factor" :-)

> 
> Overloaded variables
> --------------------
> 
> There appears to be overloaded meaning given to some variables. For
> example, as I read it, "beta" in equation 2 is supposed to be cubic beta
> (0.2), but equation 3 refers to a generic beta and in equation 4 beta
> represents reno beta (0.5).
> 
> I would strongly suggest that the draft explicitly differentiate the
> references to beta (e.g. use "cubic_beta" and "reno_beta") and the
> values they should take.
> 
Yes, this is a good suggestion.

> 
> Parentheses in equations
> ------------------------
> 
> I'd suggest adding parentheses to equations (e.g. 3 and 4 in particular)
> to completely rule out any possibility of ambiguous interpretation. For
> example with equation 4, is the last term [(3*beta)/(2-beta)] * (t/RTT)
> or is it (3*beta)/[(2-beta) * (t/RTT)]?
> 

    (alpha/2 * (2-beta)/beta * 1/p)^0.5 (Eq. 3)
is
    [(alpha/2) * ((2-beta)/beta) * (1/p)]^0.5 (Eq. 3)

    W_tcp(t) = W_max*(1-beta) + 3*beta/(2-beta)* t/RTT (Eq. 4)
is
    W_tcp(t) = W_max*(1-beta) + [3*beta/(2-beta)]*(t/RTT) (Eq. 4)

> 
> Explicit help for implementors
> ------------------------------
> 
> I'd suggest adding a new (sub)section somewhere in the document
> focusing on implementation related discussion.
> 
> Calculating the cubic root of a number in the kernel is a non trivial
> task because you need to be able to do it using fixed point math.
> 
> I've nutted out a way to do it but I think this is something algorithm
> authors should be helping people with in the I-D. For CUBIC, we could
> standardise some code fragments that do the necessary calculations and
> insert them as examples in the I-D to give implementors a starting point.
> 

Our original CUBIC code used the bisection method to calculate the cubic 
root. Later it was replaced by a Newton-Raphson method with table 
loopups for small values. This results in more than 10 times performance 
improvement in the cubic root calculation. On average, the bisection
method costs 1032 clocks while the improved version costs only 79 clocks.

You can find more information at
* Hemminger, S. Cubic root benchmark code. 
http://lkml.org/lkml/2007/3/13/331
* Tarreau, W. Cubic optimization.
http://git.kernel.org/?p=linux/kernel/git/davem/net2.6.git;a=commit;h=7e58886b45bc4a309aeaa8178ef89ff767daaf7f 

> 
> TCP friendly region
> -------------------
> 
> The TCP friendly region (section 2.2) concept is still fuzzy for me.
> During which periods of a congestion epoch would one expect the TCP
> friendly region to actually have any effect?
> 
> I think this concept and its importance needs to be explained more
> clearly in the document.
> 

I see. As described in Section 4.1, TCP friendly region has an effect 
when standard TCP performs well. For example, in the following two types 
of networks:
       1. networks with a small bandwidth-delay product (BDP).
       2. networks with a short RTT, but not necessarily a small BDP

> 
> Fast convergence
> ----------------
> 
> Why is the fast convergence heuristic so brutal in it's attempted
> detection of new flows starting up?
> 
> Having the hard check of "is cwnd < cwnd_prev" in place seems far too
> black and white, particularly in BSD where cwnd is in bytes, so a 1 byte
> difference will trigger the more aggressive backoff.
> 
> Perhaps a "is cwnd < 0.97*prev_cwnd" or similar check would soften the
> edge just a little bit?
> 

Actually we have tested something like "cwnd < 0.97*prev_cwnd", but 
there is no obvious difference. This is why we are still using it.

Thanks, Again!

Lisong

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

From: [email-masked] (Lachlan Andrew)
Date: Thu Oct 30 02:07:51 2008
Subject: [Iccrg] CUBIC I-D feedback from an implementor's perspective
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

2008/10/30 Lawrence Stewart <[email-masked]>:
> Below are my current feedback notes for CUBIC.
>
> Units for variables
> -------------------
>
> The correct units for variables appear to be ambiguous. (For example, I
> presume cwnd is in pkts, and time t is in seconds - but I couldn't
> find that clearly stated in the I-D.)
>
> For example in the BSD stack, cwnd is calculated and used in
> bytes
>
> At the moment, I'm just converting to pkts by dividing cwnd by smss, but
> it's not ideal.

Good work, Lawrence.

The issue of whether to measure CWND in multiples of MSS or packets
depends on whether we're trying to fight "bit rate congestion" or
"packet rate congestion".  In the former case (which I believe is more
common), dividing by  smss  seems exactly the right thing to do.

The issue of MSS vs bytes is more interesting.  Current TCP is biased
in favour of flows with large MSS.  When the growth rate of CWND is
non-linear, the units should probably be chosen to minimise this
unfairness (and then the coefficient chosen suitably).

Consider the unfairness between flows with MSS1 and MSS2.  Since CUBIC
has growth like  (cwnd - cwnd_0)^3,  my gut feeling is that if CWND
were measured in bytes, the unfairness would be eliminated, but if it
is measured in MSS (or packets), then the unfairness could be
(MSS1/MSS2)^3.

Has anyone done the algebra carefully, or experiments with different MSS?

Cheers,
Lachlan

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

From: [email-masked] (Lawrence Stewart)
Date: Thu Oct 30 01:22:36 2008
Subject: [Iccrg] CUBIC I-D feedback from an implementor's perspective
Message-ID: <[email-masked]>

Hi All,

I've been working on and off independently implementing and testing some
of the proposed congestion control algorithms in FreeBSD as part of our
NewTCP research project [1]. So far, I've completed a functional HTCP
and I'm currently working on CUBIC with others planned as future work. I
have some feedback for the HTCP and CUBIC draft authors based on my
implementation experiences. Below are my current feedback notes for CUBIC.

All comments below relate to draft-rhee-tcpm-cubic-01.txt

Units for variables
-------------------

The correct units for variables appear to be ambiguous. (For example, I
presume cwnd is in pkts, and time t is in seconds - but I couldn't
find that clearly stated in the I-D.)

For example in the BSD stack, cwnd is calculated and used in
bytes, and time is calculated in terms of kernel ticks. However putting
cwnd in bytes into the CUBIC equations produces results that I believe
are demonstrably incorrect, whereas using pkts seems to produce expected
results. Similar problems arise using ticks instead of regular time.

It might even be worth providing equivalent functions for both pkt and
byte based cwnd so that the implementor doesn't have to think too hard.
At the moment, I'm just converting to pkts by dividing cwnd by smss, but
it's not ideal. And again, similar issues exist using ticks for time.

Convention for "beta"
---------------------

The I-D does not use the convention that beta represents the
multiplicative decrease factor (i.e. cwnd = cwnd * beta on congestion).
It instead uses beta in the following context: cwnd = cwnd * (1-beta) on
congestion.

It took me a while to wrap my head around the I-D's use of the term 
"multiplicative decrease factor" for beta in this context. I would 
suggest that it would reduce confusion and implementation errors to 
either refer to beta in the more usual context i.e. make it 0.8 and 
modify the I-D's equations appropriately, or change the variable in the 
I-D to be called something else.

If the community feels the draft's use of beta is appropriate, then
perhaps we should standardise the meaning of "beta" somewhere for people
writing/reading congestion control related documents to cite/refer to so 
as to avoid each draft having its own interpretation.

Overloaded variables
--------------------

There appears to be overloaded meaning given to some variables. For
example, as I read it, "beta" in equation 2 is supposed to be cubic beta
(0.2), but equation 3 refers to a generic beta and in equation 4 beta
represents reno beta (0.5).

I would strongly suggest that the draft explicitly differentiate the
references to beta (e.g. use "cubic_beta" and "reno_beta") and the
values they should take.

Parentheses in equations
------------------------

I'd suggest adding parentheses to equations (e.g. 3 and 4 in particular)
to completely rule out any possibility of ambiguous interpretation. For
example with equation 4, is the last term [(3*beta)/(2-beta)] * (t/RTT)
or is it (3*beta)/[(2-beta) * (t/RTT)]?

Explicit help for implementors
------------------------------

I'd suggest adding a new (sub)section somewhere in the document
focusing on implementation related discussion.

Calculating the cubic root of a number in the kernel is a non trivial
task because you need to be able to do it using fixed point math.

I've nutted out a way to do it but I think this is something algorithm
authors should be helping people with in the I-D. For CUBIC, we could
standardise some code fragments that do the necessary calculations and
insert them as examples in the I-D to give implementors a starting point.

TCP friendly region
-------------------

The TCP friendly region (section 2.2) concept is still fuzzy for me.
During which periods of a congestion epoch would one expect the TCP
friendly region to actually have any effect?

I think this concept and its importance needs to be explained more
clearly in the document.

Fast convergence
----------------

Why is the fast convergence heuristic so brutal in it's attempted
detection of new flows starting up?

Having the hard check of "is cwnd < cwnd_prev" in place seems far too
black and white, particularly in BSD where cwnd is in bytes, so a 1 byte
difference will trigger the more aggressive backoff.

Perhaps a "is cwnd < 0.97*prev_cwnd" or similar check would soften the
edge just a little bit?

I suspect I'll have more feedback as my implementation effort proceeds,
but the above is a good enough starting point for discussion.

Cheers,
Lawrence

http://caia.swin.edu.au

[1] http://caia.swin.edu.au/urp/newtcp/

From: [email-masked] (Dirceu Cavendish)
Date: Fri Oct 24 17:59:52 2008
Subject: [Iccrg] FW: iccrg - Requested session has been scheduled for IETF 73
Message-ID: <[email-masked]>

Great. Thanks for the info.

Dirceu

________________________________
From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
To: iccrg <[email-masked]>
Sent: Friday, October 24, 2008 9:58:42 AM
Subject: [Iccrg] FW: iccrg - Requested session has been scheduled for IETF 73

FYI, the IETF 73 meeting slot for the ICCRG is now
set to Monday (11/17) at 3:20 PM.

Keep the agenda requests coming; especially if you
have any material for the safety review of CUBIC :).

>-----Original Message-----
>From: IETF Secretariat [mailto:[email-masked]] 
>Sent: Thursday, October 23, 2008 7:36 PM
>To: [email-masked]
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: iccrg - Requested session has been scheduled for IETF 73 
>
>Dear Wesley Eddy,
>
>The sessions that you have requested have been scheduled.
>Below is the scheduled session information followed by 
>the information of sessions that you have requested.
>
>iccrg Session 1 (2 hours)
>Monday, Afternoon Session II 1520-1720
>Room Name: Meeting Room

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

      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20081024/055a0189/attachment.html
>From [email-masked]  Tue Oct 28 20:52:50 2008
From: [email-masked] (Eddy, Wesley M. (GRC-RCN0)[VZ])
Date: Tue Oct 28 20:46:37 2008
Subject: [Iccrg] draft ICCRG meeting agenda for IETF 73
Message-ID: <[email-masked]>

The ICCRG meeting in Minneapolis is set for Monday,
November. 17, from 15:20 - 17:20.  The room is to-be-
announced.  Below is a draft schedule.

Note-Well
Agenda Bashing
RG Status Notes

Dirceu Cavendish
Report from Slow-Start Sub-Group
20 minutes

Michael Scharf
Implementation Issues and Performance of Quick-Start,
Jump-Start, and other Fast Startup Approaches
20 minutes

Matt Mathis
Re-thinking TCP-Friendly
30 minutes

Draft on Open Issues in Internet Congestion Control

Safety Reviews;
	Compound TCP Review Status
	CUBIC Review Status
	H-TCP Review Status

From: [email-masked] (Eddy, Wesley M. (GRC-RCN0)[VZ])
Date: Fri Oct 24 17:53:05 2008
Subject: [Iccrg] FW: iccrg - Requested session has been scheduled for IETF 73
Message-ID: <[email-masked]>

FYI, the IETF 73 meeting slot for the ICCRG is now
set to Monday (11/17) at 3:20 PM.

Keep the agenda requests coming; especially if you
have any material for the safety review of CUBIC :).

>-----Original Message-----
>From: IETF Secretariat [mailto:[email-masked]] 
>Sent: Thursday, October 23, 2008 7:36 PM
>To: [email-masked]
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: iccrg - Requested session has been scheduled for IETF 73 
>
>Dear Wesley Eddy,
>
>The sessions that you have requested have been scheduled.
>Below is the scheduled session information followed by 
>the information of sessions that you have requested.
>
>iccrg Session 1 (2 hours)
>Monday, Afternoon Session II 1520-1720
>Room Name: Meeting Room

From: [email-masked] (Eddy, Wesley M. (GRC-RCN0)[VZ])
Date: Thu Oct 16 17:46:19 2008
Subject: [Iccrg] meeting at IETF 73
Message-ID: <[email-masked]>

FYI - The ICCRG meeting at IETF 73 is currently scheduled
for Wednesday, Nov 19.  It may be moved, as this is in the
same timeslot as TSVAREA which has heavily overlapping
attendance.

I know of a few possible presentations people want to give
in the ICCRG 2-hour timeslot, but to help plan if people
that want to present can give me (before Oct 21):

- Presentation Title
- Expected Time Needed

that would be a big help.  Thanks in advance!  I'll post
a draft agenda to the list after collecting this data.

From: [email-masked] (Magnus Westerlund)
Date: Wed Oct 15 16:17:25 2008
Subject: [Iccrg] Solicting interest in update of ECN handling around tunnels
Message-ID: <[email-masked]>

ICCRG,

This is an solicitation of interest for doing work in TSVWG around
updating the ECN handling for tunnels along the lines of
http://tools.ietf.org/id/draft-briscoe-tsvwg-ecn-tunnel-01.txt

More specifically we are considering to adopt this document as a WG item.

Please provide any feedback to the TSVWG ([email-masked])

Thanks

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
F?r?gatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------