Subject: [Iccrg] RE: Ledbat presentation slots for Hiroshima
From: [email-masked] (Murari Sridharan)
Date: Fri Oct 30 00:51:43 2009

Here is the agenda.

LEDBAT WG Meeting, IETF 76
Friday, November 13
Cattleya East

9:00 AM Preliminaries (10 mts)

9:10-9:40 Low Extra Delay Background  Transport (LEDBAT), S. Shalunov (30 minutes)
http://tools.ietf.org/id/draft-ietf-ledbat-congestion-00.txt
Looks like there were some minor edits made but the version is still 00? Is this correct Stas?
http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-ledbat-congestion-00.txt

9:40-10:10 LEDBAT Practices and Recommendations for Managing Multiple Concurrent TCP Connections, R. Penno (30 minutes)
http://tools.ietf.org/id/draft-penno-ledbat-app-practices-recommendations-01.txt

10:10 - 10:30 Next Steps and Wrap-up (20 minutes)

Thanks
Murari

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murari Sridharan
Sent: Tuesday, October 13, 2009 9:04 AM
To: [email-masked]; [email-masked]
Subject: [ledbat] Ledbat presentation slots for Hiroshima

Hi,

We'll hopefully get the updated drafts soon. Meanwhile please send agenda requests. We know we will have two slots for each of the WG documents. Michael won't be making any updates to the LEDBAT survey document for Hiroshima.

Other than the above I'd like to propose a few topics that I think will help the WG immensely. I am cross-posting the invite to ICCRG folks as well. As we are working on finalizing a lower than best-effort transport that is based on delay measurement there have been questions around experimental data/discussion around proving/disproving late comer's advantage, whether flows can be starved, fairness in the presence of multiple flows etc. As with all congestion control laws the one being discussed has a choice of parameter values to choose from. A lot of the work here is building on earlier work on delay and loss based algorithms so it would be good to hear views form others who have done this type of work in the past. I know there are folks that have implementation experience with delay and loss based algorithms. May be you have some interesting data to share that is relevant to the problem being discussed. You can look at the current proposal at http://tools.ietf.org/html/draft-shulanov-ledbat-congestion

If you are interested, please send us details including title/topic, presenter name and requested time.

Thanks

Murari

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20091030/5427d5ee/attachment.html
>From [email-masked]  Fri Oct 30 14:01:36 2009
From: [email-masked] (Woundy, Richard)
Date: Fri Oct 30 13:43:05 2009
Subject: [Iccrg] RE: [ledbat] Ledbat presentation slots for Hiroshima
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

I suspect the diff is against
http://tools.ietf.org/html/draft-shalunov-ledbat-congestion-00, since
the previous draft prior to approval as an official WG item.

 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murari Sridharan
Sent: Thursday, October 29, 2009 9:10 PM
To: [email-masked]; [email-masked]
Subject: Re: [ledbat] Ledbat presentation slots for Hiroshima

Here is the agenda. 

LEDBAT WG Meeting, IETF 76

Friday, November 13

Cattleya East

9:00 AM Preliminaries (10 mts)

9:10-9:40 Low Extra Delay Background  Transport (LEDBAT), S. Shalunov
(30 minutes)

http://tools.ietf.org/id/draft-ietf-ledbat-congestion-00.txt

Looks like there were some minor edits made but the version is still 00?
Is this correct Stas?

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-ledbat-c
ongestion-00.txt

9:40-10:10 LEDBAT Practices and Recommendations for Managing Multiple
Concurrent TCP Connections, R. Penno (30 minutes)

http://tools.ietf.org/id/draft-penno-ledbat-app-practices-recommendation
s-01.txt

10:10 - 10:30 Next Steps and Wrap-up (20 minutes)

Thanks

Murari 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murari Sridharan
Sent: Tuesday, October 13, 2009 9:04 AM
To: [email-masked]; [email-masked]
Subject: [ledbat] Ledbat presentation slots for Hiroshima

Hi,

We'll hopefully get the updated drafts soon. Meanwhile please send
agenda requests. We know we will have two slots for each of the WG
documents. Michael won't be making any updates to the LEDBAT survey
document for Hiroshima. 

Other than the above I'd like to propose a few topics that I think will
help the WG immensely. I am cross-posting the invite to ICCRG folks as
well. As we are working on finalizing a lower than best-effort transport
that is based on delay measurement there have been questions around
experimental data/discussion around proving/disproving late comer's
advantage, whether flows can be starved, fairness in the presence of
multiple flows etc. As with all congestion control laws the one being
discussed has a choice of parameter values to choose from. A lot of the
work here is building on earlier work on delay and loss based algorithms
so it would be good to hear views form others who have done this type of
work in the past. I know there are folks that have implementation
experience with delay and loss based algorithms. May be you have some
interesting data to share that is relevant to the problem being
discussed. You can look at the current proposal at
http://tools.ietf.org/html/draft-shulanov-ledbat-congestion

If you are interested, please send us details including title/topic,
presenter name and requested time. 

Thanks

Murari 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20091030/2c453162/attachment.html

From: [email-masked] (Douglas Leith)
Date: Fri Oct 23 07:53:06 2009
Subject: [Iccrg] sending rate of a TCP flow
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Depends on the buffering, but here's one reference that applies to  
drop-tail queues (fluid work is all for AQMs):

A positive systems model of TCP-like congestion control: Asymptotic  
results. IEEE/ACM Transactions on Networking, 14(3), pp616-629, link: http://www.hamilton.ie/net/unsynchronised_final.pdf

Might also be worth noting that the TCP-friendly equation (I presume  
you mean Padhye's fluid model ?) is really for a single flow in a  
"bath of noise" i.e. where packet loss is independent of TCP  
congestion control action.  This is definitely *not* valid for  
multiple flows sharing a single queue in a dumbell topology since the  
loss rate experienced by each flow can (and generally will) be  
different if they have different RTTs - its easy to see this by  
considering an example where flow backoffs are synchronised.

Doug

www.hamilton.ie

On 23 Oct 2009, at 04:42, [email-masked] wrote:

> Hello,
>
> Based on the TCP-friendly equation, sending rate of a TCP flow  
> depends on
> RTT, MSS, and loss rate.
>
> hypothesis: When N long-lived TCP flows (with the same RTT and MSS  
> values)
> share a bottleneck link in a dumbbell  topology (all the edge links  
> have
> the same delay and bandwidth), I expect each TCP flow to have the same
> sending rate -- Assume no other cross traffic in the network and  
> drop-tail
> queues.
>
> Do you know any references (simulation-, emulation-, or real
> experiment-based studies) that prove this hypothesis or the opposite?
>
>
> thanks,
> ilknur Aydin
> ps. Please let me know if there is a more appropriate mailing list  
> to post
> this question.
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] ([email-masked])
Date: Fri Oct 23 04:24:42 2009
Subject: [Iccrg] sending rate of a TCP flow
Message-ID: <[email-masked]>

Hello,

Based on the TCP-friendly equation, sending rate of a TCP flow depends on
RTT, MSS, and loss rate.

hypothesis: When N long-lived TCP flows (with the same RTT and MSS values)
share a bottleneck link in a dumbbell  topology (all the edge links have
the same delay and bandwidth), I expect each TCP flow to have the same
sending rate -- Assume no other cross traffic in the network and drop-tail
queues.

Do you know any references (simulation-, emulation-, or real
experiment-based studies) that prove this hypothesis or the opposite?

thanks,
ilknur Aydin
ps. Please let me know if there is a more appropriate mailing list to post
this question.

From: [email-masked] (Murari Sridharan)
Date: Tue Oct 13 16:53:06 2009
Subject: [Iccrg] Ledbat presentation slots for Hiroshima
Message-ID: <[email-masked]>

Hi,

We'll hopefully get the updated drafts soon. Meanwhile please send agenda requests. We know we will have two slots for each of the WG documents. Michael won't be making any updates to the LEDBAT survey document for Hiroshima.

Other than the above I'd like to propose a few topics that I think will help the WG immensely. I am cross-posting the invite to ICCRG folks as well. As we are working on finalizing a lower than best-effort transport that is based on delay measurement there have been questions around experimental data/discussion around proving/disproving late comer's advantage, whether flows can be starved, fairness in the presence of multiple flows etc. As with all congestion control laws the one being discussed has a choice of parameter values to choose from. A lot of the work here is building on earlier work on delay and loss based algorithms so it would be good to hear views form others who have done this type of work in the past. I know there are folks that have implementation experience with delay and loss based algorithms. May be you have some interesting data to share that is relevant to the problem being discussed. You can look at the current proposal at http://tools.ietf.org/html/draft-shulanov-ledbat-congestion

If you are interested, please send us details including title/topic, presenter name and requested time.

Thanks

Murari

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20091013/2c80a02b/attachment.html
>From [email-masked]  Mon Oct 19 10:24:22 2009
From: [email-masked] (philip.eardley)
Date: Mon Oct 19 10:10:25 2009
Subject: [Iccrg] Congestion Exposure (CONEX) Bof in Hiroshima
Message-ID: <[email-masked]>

An alert of the Congestion Exposure (CONEX) Bof in Hiroshima - currently
scheduled for Tues 15.20 - 18.10. 

Best wishes,

Philip Eardley & Leslie Daigle (BoF Chairs)

Congestion Exposure (CONEX)

(was re-ECN)

Description

Congestion Exposure (ConEx) is a proposed new IETF activity to enable
congestion to be exposed along the forwarding path of the Internet. By
revealing expected congestion in the IP header of every packet,
congestion exposure provides a generic network capability which allows
greater freedom over how capacity is shared. Such information could be
used for many purposes, including congestion policing, accountability
and inter-domain SLAs. It may also open new approaches to QoS and
traffic engineering.

The Internet is, in essence, about pooling resources. The ability to
share capacity has been paramount to its success and has traditionally
been managed through the voluntary use of TCP congestion control.
However, TCP alone is unable to prevent bandwidth intensive
applications, such as peer-to-peer or streaming video, from causing
enough congestion to severely limit the user-experience of many other
end-hosts. This has led ISPs to deploy ad-hoc solutions such as volume
accounting, rate policing and deep packet inspection in an attempt to
distribute capacity differently. The consequences of such practices are
increasingly leading to calls for government regulations and stifling
innovation at the transport and application layer (see for example, the
problem statement I-D (ref below) and RFC5594).

We believe these problems stem from the lack of a network-layer system
for accountability -- among all parties -- for sending traffic which
causes congestion. We propose a metric where IP packets carry
information about the expected rest-of-path congestion, so that any
network node may estimate how much congestion it is likely to cause by
forwarding traffic. A network operator can then count the volume of
congestion about to be caused by an aggregate of traffic as easily as it
can count the volume of bytes entering its network today. Once ISPs can
see rest-of-path congestion, they can actively discourage users from
causing large volumes of congestion, discourage other networks from
allowing their users to cause congestion, and more meaningfully
differentiate between the qualities of services offered from potential
connectivity partners. Meanwhile end-hosts may be freed from rate
restrictions where their traffic causes little congestion.

The purpose of the BoF is to explore the support for and viability of
pursuing an IETF activity to define a basic protocol to expose the
expected rest-of-path congestion in the IP header. Any such protocol
should work with minimal changes to the existing network, in particular
it should work with unmodified routers. There is already one existing
proposal that builds on ECN to provide rest-of-path congestion
information in every IP header and other proposals may come forward.

If supported, an eventual WG would focus on the development of that
protocol as its main work item. Additional work items could include
detailing the motivations for congestion exposure, a threat analysis of
the subsequent protocol, providing feedback on experimental trials and
describing deployment considerations. Importantly, the proposed WG would
encourage experimentation but not deliberate on how congestion exposure
should be used: our concern would be how flexibly the resulting protocol
can support differing needs at run-time, rather than dictating a
particular usage at design time.

Related Internet-Drafts include:  

http://www.ietf.org/id/draft-moncaster-congestion-exposure-problem-01.tx
t 

http://www.ietf.org/id/draft-briscoe-tsvwg-re-ecn-tcp-08.txt 

http://www.ietf.org/id/draft-briscoe-tsvwg-re-ecn-tcp-motivation-01.txt

 

Other useful reference material:  

http://www.bobbriscoe.net/projects/refb/FairerFasterWP.pdf  

Mailing list for discussion: 

[email-masked]   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20091019/c161801b/attachment.html
>From [email-masked]  Mon Oct 19 20:10:14 2009
From: [email-masked] (Stefan Hirschmann)
Date: Mon Oct 19 19:53:01 2009
Subject: [Iccrg] SFQ and maximum bucket size
Message-ID: <[email-masked]>

Hi!

I looked into the ns-2 source and found the following code:
=====================================
  if ( (used >= (left >> 1))
       || (left < buckets_ && used > fairshare)
       || (left <= 0)) {
     drop(pkt);
     return;
   }
=====================================
source: ns-2/queue/sfq.c line number 217

The consequence is, that the number of packets in a bucket cannot be 
larger than 1/3 queue limit. (left >> 1 is equal to: left/2 - left%2).

Now my question: Where is this property specified? I read a few SFQ 
papers, but could not find the answer.

Thanks in advance for any informations.

Cheers Stefan

From: [email-masked] (Lawrence Stewart)
Date: Tue Oct 13 01:40:52 2009
Subject: [Iccrg] H-TCP I-D feedback from an implementor's perspective
Message-ID: <[email-masked]>

Hi All,

Finally got around to writing up an initial review of the H-TCP draft. 
Apologies to those who have been waiting a long time for this. As part 
of the NewTCP research project I'm involved with, we independently 
implemented H-TCP for FreeBSD, and a lot of the feedback stems from that 
experience. Anyone interested in experimental TCP work should have a 
look at [1] for various patches, tools and papers. Thanks also to 
Lachlan Andrew for providing feedback on my feedback!

Questions, comments and discussion welcomed.

Cheers,
Lawrence

http://caia.swin.edu.au

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

All comments below relate to draft-leith-tcp-htcp-06.txt. Some of the 
general comments in particular are also relevant to a number of other 
congestion control algorithm drafts.

P.X refers to paragraph X on that page.

##########

General

- What is a packet? An SMSS sized segment? An average sized segment? 
Need to somehow acknowledge stacks that are not packet based.

- Perhaps have a note explaining that parts of the algorithm defined in 
external papers are explicitly not included in the draft (reason why not 
overly important, but feel free to provide an explanation if you feel 
like it).

- Could break out a number of discussion points into an implementer's 
section? I'd also like to see a public domain code snippet in the draft 
that demonstrates fixed point math calculation of f_alpha.

- Does appropriate byte counting and/or delayed ack change the dynamics 
of the algorithm?

- How often should alpha be evaluated? Does the answer change with 
respect to above point about ABC and/or delayed ack?

- "Cubic" => "CUBIC" throughout.

- Streamline uses of "Beta" vs "Backoff factor" vs "mult. decrease 
factor". Ditto for alpha/additive increase/increase factor.

- Need somewhere to define terms e.g. AIMD, cwnd, "mult. decrease 
factor", etc.

- I would like to see explicit mention of what to do with ssthresh.

##########

Page 2

- P.1, Duplicate "to".

##########

Page 4

- P.1, Duplicate "to".

- P.4, "...this proposal also increases the multiplicative decrease 
factor..." reads like you're referring to the H-TCP proposal.

- P.4, "increasing the multiplicative decrease factor to increase 
aggressiveness" is confusing if interpreted as "increasing the factor by 
which we multiplicatively decrease". Consider revising.

- P.4, Move note defining multiplicative decrease elsewhere with some 
other definitions.

- P.5, "...networks of TCP flows..." I think "networks" in this context 
is unfamiliar.

- P.5, Missing a reference for CUBIC (draft-rhee-tcpm-cubic-02.txt 
perhaps?).

- P.5, Should potentially revise wording re CUBIC due to latest CUBIC 
draft's attempt at addressing convergence issues.

##########

Page 6

- P.1, "...an increasing function of flow cwnd..." is somewhat ambiguous 
(instantaneous value of cwnd? No, but could read like that) and possibly 
misleading. CUBIC for example uses time since congestion as well as a 
memory of the previous value of cwnd at congestion. Consider revising.

- P.1, Should probably note that CUBIC uses time since congestion as well.

- P.1, "...increase the aggressivness of the AIMD increase..." poorly 
worded sentence with lots of "increase". Consider revising.

- P.2, RFC2591 is the wrong reference. RFC2581 is probably what you meant.

- P.3, I suspect providing a reference to a document that explores 
reasoning for the Delta_L value would be a good idea. A value of 1 
second will seem long to people who want to push the envelope with a 
high speed algorithm like H-TCP i.e. you should show some good 
reasoning/theory/results so that people won't second guess you.

##########

Page 8

- P.2, I believe there is a standard definition of friendliness (needs a 
citation), but more fundamentally, do we really care about friendliness 
in such a spec? Ditto for responsiveness and efficiency.

- P.2 "This an indication..."

- P.4, Meaning and relevance of the last sentence re "similar efficiency 
gains to standard TCP" is unclear to me. More discussion needed here.

##########

Page 10

- RTT should perhaps be referred to as RTT_min and some discussion added 
to highlight the subtle details/issues (e.g. smoothed/instantaneous RTT, 
how long before we can trust RTT estimate, RTT with delayed ACK, 
hysteresis for min RTT).

- Formula + P.3, Suggest changing K to rho as in other H-TCP documents.

- P.3, More discussion required re "low speed conditions".

##########