Subject: [Iccrg] congestion control and visability to the user
From: [email-masked] (Mikael Abrahamsson)
Date: Wed Mar 31 18:52:48 2010

On Wed, 31 Mar 2010, Woundy, Richard wrote:

> I don't want that either. I don't think that is the goal of most
> participants, either.

I must be seriously misinterpreting what I'm reading from some people 
then.

This is fine though, as long what you're saying is what the majority 
fagrees on. I just got very upset at IETF75 when people were talking about 
core congestion like a law of nature and that was the most important 
problem to be handled going forward, because I don't agree with that 
notion at all.

From: [email-masked] (Woundy, Richard)
Date: Wed Mar 31 16:39:32 2010
Subject: [Iccrg] congestion control and visability to the user
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Mikael,

I'll provide my perspective on why I think ECN and congestion exposure
is still worthwhile.

> Apart from the access, the ISP should never congest and thus should
never be dropping packets. Core Network congestion is not something
"natural", it means the ISP is not doing its job properly.

My ISP perspective is that congestion can happen anywhere, but there are
parts of the network that are more likely to experience congestion than
others. The access network is most likely to experience congestion (with
'self' congestion happening more often than 'shared' congestion). Next
most likely would be congestion on the backbone interconnects. Least
likely (and a fairly rare occurrence) would be internal backbone links;
this probably happens when "the ISP is not doing its job properly" or
when there are multiple catastrophic link or routing failures. Even
Google has been guilty of this once or twice.

In an earlier email, you seemed to suggest that interconnects are easy
to manage from a capacity point of view, and you point to
<http://stats.autonomica.se/mrtg/14all.pl%3Fdir=Stockholm%252FGEB%252F.h
tml> as justification. I looked at the Microsoft graph, especially the
'yearly' graph at the bottom,
<http://stats.autonomica.se/perl/14all.pl?log=stockholm.geb.194>. It
appears that in October 2009, traffic quadrupled in just a few days. Do
you know why?

I've seen cases in which a change on the content/application provider
side will cause a significant change (100%+) in traffic on one or more
interconnect links. Consider tunneling traffic as a perfect example.

There is also another consideration for private interconnects -- both
ISPs have to coordinate on a capacity upgrade. Many times, the upgrade
is a higher priority to one ISP than the other. But one ISP can't expand
private interconnect capacity alone. :)

> I'm against the notion that core network congestion is something that
should be focused on handling by some kind of "make core routers aware
of flows so end users get fair access to bw in the core".

For me, "making core routers aware of flows" is not a goal. I didn't
think that was required for either ECN or congestion exposure in core
routers. (Some folks are talking about adding policers to the core, but
that is separate equipment and a different decision from my
perspective.)

Some ISPs are running (W)RED in their cores today. Are you saying they
should turn it off, and vendors should drop support? And why?

> So just to re-iterate, ISPs congesting their cores are breaching their
contracts with end customers, and IETF and more should NOT help them
create an Internet that is sub-par with what we have today.

I don't want that either. I don't think that is the goal of most
participants, either.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mikael Abrahamsson
Sent: Tuesday, March 30, 2010 10:47 PM
To: Michael Welzl
Cc: [email-masked]; Matt Mathis
Subject: Re: [Iccrg] congestion control and visability to the user

On Tue, 30 Mar 2010, Michael Welzl wrote:

> Whether access links are always saturated or not. Sorry if just
> throwing in the RFC 3649 reference was confusing, I meant it
> as a point to illustrate TCP's growing problem with a growing BDP.

I'm still confused. First we were talking about congestion at the core
as 
an unavoidable natural way of things, now all of a sudden we're talking 
about something else. I'm all for enabling TCP and other protocols to 
properly utilize access links, I'm against the notion that core network 
congestion is something that should be focused on handling by some kind
of 
"make core routers aware of flows so end users get fair access to bw in 
the core".

> Sorry, we're at cross-purposes here. My point was that improving 
> congestion control functionality in end hosts still makes sense, and
we 
> just seem to agree here.

Yes.

> So what exactly is the technical development that you consider 
> pointless?

The core thing.

-- 
Mikael Abrahamsson    email: [email-masked]

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

From: [email-masked] (Mikael Abrahamsson)
Date: Wed Mar 31 03:55:30 2010
Subject: [Iccrg] congestion control and visability to the user
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue, 30 Mar 2010, Michael Welzl wrote:

> Whether access links are always saturated or not. Sorry if just
> throwing in the RFC 3649 reference was confusing, I meant it
> as a point to illustrate TCP's growing problem with a growing BDP.

I'm still confused. First we were talking about congestion at the core as 
an unavoidable natural way of things, now all of a sudden we're talking 
about something else. I'm all for enabling TCP and other protocols to 
properly utilize access links, I'm against the notion that core network 
congestion is something that should be focused on handling by some kind of 
"make core routers aware of flows so end users get fair access to bw in 
the core".

> Sorry, we're at cross-purposes here. My point was that improving 
> congestion control functionality in end hosts still makes sense, and we 
> just seem to agree here.

Yes.

> So what exactly is the technical development that you consider 
> pointless?

The core thing.

-- 
Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (Michael Welzl)
Date: Tue Mar 30 23:06:38 2010
Subject: [Iccrg] congestion control and visability to the user
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mar 30, 2010, at 5:59 PM, Mikael Abrahamsson wrote:

> On Tue, 30 Mar 2010, Michael Welzl wrote:
>
>> How can you be so sure? The longer the delay, and the greater
>> the bandwidth, the harder it gets for standard TCP to saturate the
>> bottleneck. See the abstract of RFC 3649 (2nd paragraph), which
>> lays it out quite nicely - what do you think of this, is it  
>> unrealistic,
>> or wrong in your opinion?
>
> I don't get it. First people here are talking about their  
> residential broadband and I answer to that, next I get a reference  
> to a 10 gigabit/s transfer in single session and ask if I think that  
> is true. What problem are we discussing really?

Whether access links are always saturated or not. Sorry if just
throwing in the RFC 3649 reference was confusing, I meant it
as a point to illustrate TCP's growing problem with a growing BDP.

The bandwidth may not be at that magnitude in today's residential
broadband links, but delays can easily have 100ms or more.

>> Surely, like everyone else I know, you have once downloaded
>> something from some sever somewhere on the net
>> at much less than your internet connection's speed - then, how do
>> you know where the bottleneck comes from - is it a slow access
>> link of the server, or the server itself being slow, or TCP not
>> saturating the bottleneck (wherever it is) well? How would you know?
>
> Because I work for an ISP and I have a pretty good idea about what's  
> going on. In my local "ecosystem" I regularily saturate my 100  
> megbait/s residential connection by communicating with other hosts  
> in Sweden. This is with tens of ms of RTT. I've had to implement  
> fair-queue and all on my connection because with FIFO I get  
> 100-200ms buffering and I'm not interested in that affecting my SSH/ 
> web sessions.

Tens of ms of RTT isn't much. I just wonder how you can make
a statement like "access links are always saturated (in your
neck of the woods)" when we're talking about the Internet,
not just Sweden, and you can't really know what's happening
beyond the scope of your ISP.

>> There's nothing expensive to an ISP about changing congestion  
>> control functionality in end hosts.
>
> No, but it'll be quicker.
>
>> There's nothing expensive to a vendor of an ADSL modem about
>> changing congestion control functionality in end hosts.
>
> No, but it'll be quicker.

Sorry, we're at cross-purposes here. My point was that improving
congestion control functionality in end hosts still makes sense,
and we just seem to agree here.

Also, here:

> I don't see end host congestion control functionality working well  
> around FIFO buffering with 200ms max buffer, at least not anywhere  
> near what can be done in the unit actuallly duing the buffering.

we just agree.

So what exactly is the technical development that you consider  
pointless?

Cheers,
Michael

From: [email-masked] (Mikael Abrahamsson)
Date: Tue Mar 30 17:08:32 2010
Subject: [Iccrg] congestion control and visability to the user
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue, 30 Mar 2010, Michael Welzl wrote:

> How can you be so sure? The longer the delay, and the greater
> the bandwidth, the harder it gets for standard TCP to saturate the
> bottleneck. See the abstract of RFC 3649 (2nd paragraph), which
> lays it out quite nicely - what do you think of this, is it unrealistic,
> or wrong in your opinion?

I don't get it. First people here are talking about their residential 
broadband and I answer to that, next I get a reference to a 10 gigabit/s 
transfer in single session and ask if I think that is true. What problem 
are we discussing really?

> Surely, like everyone else I know, you have once downloaded
> something from some sever somewhere on the net
> at much less than your internet connection's speed - then, how do
> you know where the bottleneck comes from - is it a slow access
> link of the server, or the server itself being slow, or TCP not
> saturating the bottleneck (wherever it is) well? How would you know?

Because I work for an ISP and I have a pretty good idea about what's going 
on. In my local "ecosystem" I regularily saturate my 100 megbait/s 
residential connection by communicating with other hosts in Sweden. This 
is with tens of ms of RTT. I've had to implement fair-queue and all on my 
connection because with FIFO I get 100-200ms buffering and I'm not 
interested in that affecting my SSH/web sessions.

> There's nothing expensive to an ISP about changing congestion control 
> functionality in end hosts.

No, but it'll be quicker.

> There's nothing expensive to a vendor of an ADSL modem about
> changing congestion control functionality in end hosts.

No, but it'll be quicker.

I don't see end host congestion control functionality working well around 
FIFO buffering with 200ms max buffer, at least not anywhere near what can 
be done in the unit actuallly duing the buffering.

-- 
Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (Michael Welzl)
Date: Tue Mar 30 12:00:20 2010
Subject: [Iccrg] congestion control and visability to the user
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mar 29, 2010, at 5:34 PM, Mikael Abrahamsson wrote:

> On Mon, 29 Mar 2010, [email-masked] wrote:
>
>> My notion was that it's not, usually, because of standard TCP
>> being "lame" (as Matt rightfully called it).
>
> This is the first time in my 15+ year of networking that I've heard  
> this view of the world. I couldn't disagr ee more. Only time I  
> wasn't able to saturate my access link was when I was using Win95 or  
> so, and it didn't s upport window scaling and my internet connection  
> was 100+ megabit/s and the ftp server was 10ms away. I could n't  
> disagree more with this view of the world.

How can you be so sure? The longer the delay, and the greater
the bandwidth, the harder it gets for standard TCP to saturate the
bottleneck. See the abstract of RFC 3649 (2nd paragraph), which
lays it out quite nicely - what do you think of this, is it unrealistic,
or wrong in your opinion?

Surely, like everyone else I know, you have once downloaded
something from some sever somewhere on the net
at much less than your internet connection's speed - then, how do
you know where the bottleneck comes from - is it a slow access
link of the server, or the server itself being slow, or TCP not
saturating the bottleneck (wherever it is) well? How would you know?

(because I believe that it's hard to know about these things, I
agree with your suggestion to develop some means to make
these things more visible - and Web100, for instance (as Matt
mentioned) wouldn't give you a good answer to that either.
(yes you could deduce things from looking at cwnd in Web100,
but where the bottleneck is you wouldn't know) )

> Again, ISPs only get away with congesting their cores if there isn't  
> enough competition in the market, and that's not a technical  
> problem, it's usually a political problem. Trying to handle this  
> dysfunctional situation by technical means is bound to fail. Why  
> would someone invest in expensive bw capacity/congestion/flow/ 
> fairness technology if said upgrade due to bw constraints is already  
> too expensive?I don't get it.

There's nothing expensive to an ISP about changing congestion
control functionality in end hosts.

> In my experience, the biggest congestion problem is in the upstream  
> direction from my CPE. Any normal user would have an ADSL modem or  
> alike there from some low-end manufacturer who won't invest a dollar  
> more to do anything more than FIFO because they're acting in an  
> extremely tight marketplace where every cent counts. There is  
> already plenty of tech out there to help in this siuation but  
> they've chosen to do nothing. Fair-queue is one which would hugely  
> benefit all ADSL users (or anyone with slow uplinks). This is not  
> being done, and yet people are talking about inveting eve nmore  
> complicated mechanisms?

There's nothing expensive to a vendor of an ADSL modem about
changing congestion control functionality in end hosts.

Cheers,
Michael

From: [email-masked] (Mikael Abrahamsson)
Date: Mon Mar 29 16:43:13 2010
Subject: [Iccrg] congestion control and visability to the user
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 29 Mar 2010, [email-masked] wrote:

> My notion was that it's not, usually, because of standard TCP
> being "lame" (as Matt rightfully called it).

This is the first time in my 15+ year of networking that I've heard this 
view of the world. I couldn't disagr ee more. Only time I wasn't able to 
saturate my access link was when I was using Win95 or so, and it didn't s 
upport window scaling and my internet connection was 100+ megabit/s and 
the ftp server was 10ms away. I could n't disagree more with this view of 
the world.

> However, in this world of CUBIC in Linux, a growing number
> of users with proper buffer sizing / window scaling, and,
> above all, users (or their (P2P) applications) opening as
> many connections as they need, I can imagine that what
> you say is true.

I don't kno wwhat part of the world where this hasn't been true for a 
long++ time, but it's not in my neck of the woods.

> Well of course economical reasons are there. Bandwidth
> costs money. So, is all we're doing here with congestion
> control only about:
> 1) managing fairness within the user's local networks, and
> 2) making the network operate even if ISPs don't investe
> in enough core bandwidth, which apparently hardly ever
> happens?

Again, ISPs only get away with congesting their cores if there isn't 
enough competition in the market, and that's not a technical problem, it's 
usually a political problem. Trying to handle this dysfunctional situation 
by technical means is bound to fail. Why would someone invest in expensive 
bw capacity/congestion/flow/fairness technology if said upgrade due to bw 
constraints is already too expensive?I don't get it.

> XCP was really just an example. The point was that, given
> that we can get a benefit from explicit feedback for
> congestion control, it might be enough to do it on the
> first and last hop, where doing it might actually be feasible.

In my experience, the biggest congestion problem is in the upstream 
direction from my CPE. Any normal user would have an ADSL modem or alike 
there from some low-end manufacturer who won't invest a dollar more to do 
anything more than FIFO because they're acting in an extremely tight 
marketplace where every cent counts. There is already plenty of tech out 
there to help in this siuation but they've chosen to do nothing. 
Fair-queue is one which would hugely benefit all ADSL users (or anyone 
with slow uplinks). This is not being done, and yet people are talking 
about inveting eve nmore complicated mechanisms?

-- 
Mikael Abrahamsson    email: [email-masked]

From: [email-masked] ([email-masked])
Date: Mon Mar 29 13:51:26 2010
Subject: [Iccrg] congestion control and visability to the user
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> On Mon, 29 Mar 2010, [email-masked] wrote:
>
>> For a minute, assume that all users have an extremely
>> well working congestion control mechanism, which would
>> allow them to completely saturate their PE-CE links
>> (from what Matt says, I gather that we're moving towards
>> such a situation, as - I think - we should)
>
> I don't understand your notion here, saturating PE-CE links is done all
> the time, but let's go on...

My notion was that it's not, usually, because of standard TCP
being "lame" (as Matt rightfully called it).

However, in this world of CUBIC in Linux, a growing number
of users with proper buffer sizing / window scaling, and,
above all, users (or their (P2P) applications) opening as
many connections as they need, I can imagine that what
you say is true.

>> Do you, then, assume that core network capacities have
>> to match all this traffic, i.e. be up to N * PE-CE capacity
>> when N is the number of customers?
>> (I'm assuming an extremely inefficient net layout here  :)
>> but I think you get my point)
>
> No, statistical overbooking works extremely well. Day to day variations
> are less than 20% in all networks I've seen, and upgrading core links when
> their peak utilisation start to approach congestion (whatever ones policy
> might be) is quite easy if one just has a basic statistic set of 5 minute
> average usage of the links (mrtg).
>
> For instance look here:
>
> http://stats.autonomica.se/mrtg/14all.pl%3Fdir=Stockholm%252FGEB%252F.html
>
> You'll see that ports have very similar usage patterns over time, and the
> total IX traffic:
>
> http://stats.autonomica.se/mrtg/sums_max/All.html
>
> is EXTREMELY easy to say approximately what'll happen over time. On a PE-P
> link with 500+ users behind it, even with this low number of users it's
> still quite easy to do statistical overbooking and not waste masses of
> unused bw or congest over time.
>
> So just to re-iterate, ISPs congesting their cores are breaching their
> contracts with end customers, and IETF and more should NOT help them
> create an Internet that is sub-par with what we have today. There is no
> technical reason to congest the core, only economical and political (and
> perhaps out of incompetence/ignorance).

Well of course economical reasons are there. Bandwidth
costs money. So, is all we're doing here with congestion
control only about:
1) managing fairness within the user's local networks, and
2) making the network operate even if ISPs don't investe
in enough core bandwidth, which apparently hardly ever
happens?

(plus making it robust for special scenarios, e.g. wireless
access, in the presence of failures, etc etc)

That might just be the case.

>> I agree on that. Since you were in the Stockholm IETF,
>> you must have seen my Ph.D. student Dragana's presentation,
>> which addressed exactly that:
>> http://www.ietf.org/proceedings/75/slides/iccrg-1/iccrg-1_files/v3_document.htm
>> (it seems that her only diagram hasn't survived the conversion,
>> but it should be understandable anyhow)
>
> I agree that first and last hop should be the only congestion points.

That was the only point here, really -

> Can't really say anything about XCP, apart from that if one wants it to be
> implemented in cheap devices, it needs to be easily implemented in
> silicon. Doing it with IP options seems hard? ECN sounds easier because
> it's in the same place of the header all the time.

XCP was really just an example. The point was that, given
that we can get a benefit from explicit feedback for
congestion control, it might be enough to do it on the
first and last hop, where doing it might actually be feasible.

Cheers,
Michael

From: [email-masked] (Mikael Abrahamsson)
Date: Mon Mar 29 12:55:56 2010
Subject: [Iccrg] congestion control and visability to the user
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 29 Mar 2010, [email-masked] wrote:

> For a minute, assume that all users have an extremely
> well working congestion control mechanism, which would
> allow them to completely saturate their PE-CE links
> (from what Matt says, I gather that we're moving towards
> such a situation, as - I think - we should)

I don't understand your notion here, saturating PE-CE links is done all 
the time, but let's go on...

> Do you, then, assume that core network capacities have
> to match all this traffic, i.e. be up to N * PE-CE capacity
> when N is the number of customers?
> (I'm assuming an extremely inefficient net layout here  :)
> but I think you get my point)

No, statistical overbooking works extremely well. Day to day variations 
are less than 20% in all networks I've seen, and upgrading core links when 
their peak utilisation start to approach congestion (whatever ones policy 
might be) is quite easy if one just has a basic statistic set of 5 minute 
average usage of the links (mrtg).

For instance look here:

http://stats.autonomica.se/mrtg/14all.pl%3Fdir=Stockholm%252FGEB%252F.html

You'll see that ports have very similar usage patterns over time, and the 
total IX traffic:

http://stats.autonomica.se/mrtg/sums_max/All.html

is EXTREMELY easy to say approximately what'll happen over time. On a PE-P 
link with 500+ users behind it, even with this low number of users it's 
still quite easy to do statistical overbooking and not waste masses of 
unused bw or congest over time.

So just to re-iterate, ISPs congesting their cores are breaching their 
contracts with end customers, and IETF and more should NOT help them 
create an Internet that is sub-par with what we have today. There is no 
technical reason to congest the core, only economical and political (and 
perhaps out of incompetence/ignorance).

> I agree on that. Since you were in the Stockholm IETF,
> you must have seen my Ph.D. student Dragana's presentation,
> which addressed exactly that:
> http://www.ietf.org/proceedings/75/slides/iccrg-1/iccrg-1_files/v3_document.htm
> (it seems that her only diagram hasn't survived the conversion,
> but it should be understandable anyhow)

I agree that first and last hop should be the only congestion points.

Can't really say anything about XCP, apart from that if one wants it to be 
implemented in cheap devices, it needs to be easily implemented in 
silicon. Doing it with IP options seems hard? ECN sounds easier because 
it's in the same place of the header all the time.

-- 
Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (Mikael Abrahamsson)
Date: Mon Mar 29 12:37:17 2010
Subject: [Iccrg] congestion control and visability to the user
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 29 Mar 2010, Damon Wischik wrote:

> Mikael Abrahamsson wrote:
>> The core router world is more and more going to smaller buffers (< 50ms, 
>> often much lower than that) which makes WRED/ECN less and less usable.
>
> Could you explain this? I thought that ECN was more and more useful, the 
> smaller the buffer. The idea is to run a virtual queue, with capacity e.g. 
> 90% of the link speed, and to mark packets when the virtual queue builds up. 
> This way, the link should be able to maintain a stable utilization of about 
> 90%, and the flows should never see packet drops.

So basically a 90% link speed policer would set ECN on any packets that 
exceed 90% of link speed? Yes, that would work even on cheap L3 equiment 
if they were capable of that action in their policer implementation.

Still haven't seen any implementations doing this, but it makes sense. 
This has nothing to do with buffering though, this can be done on a device 
regardless of size of buffers.

Otoh it would involve actually dropping non-ECN packets at 90% of 
link speed to be effective, right?

-- 
Mikael Abrahamsson    email: [email-masked]

From: [email-masked] ([email-masked])
Date: Mon Mar 29 10:13:49 2010
Subject: [Iccrg] congestion control and visability to the user
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi, Mikael,

You said:

> The customer is paying for a certain access to The Internet, congesting in
> the core basically is a breach of contract. The only congestion on a well
> behaved network is on the access line (PE-CE link).

and:

> I guess your view of the wolrd and mine differes widely. I don't agree
> with you at all. ISPs congesting their cores are doing a bad job and
> should be punished for it.

For a minute, assume that all users have an extremely
well working congestion control mechanism, which would
allow them to completely saturate their PE-CE links
(from what Matt says, I gather that we're moving towards
such a situation, as - I think - we should)

Do you, then, assume that core network capacities have
to match all this traffic, i.e. be up to N * PE-CE capacity
when N is the number of customers?
(I'm assuming an extremely inefficient net layout here  :)
but I think you get my point)

>> I didn't realize how bad it might be until I had a conversation with
>> my son, who mused that he liked his new PC because it was so quick on
>> the network.  However, whenever he is doing anything serious (he is a
>> web designer), everybody else on his home LAN starts to complain.
>
> That is the PE-CE link I was talking about. The PE-P-PE links should never
> go full, then they're not capacity managed correctly. The PE-CE link is
> designed to be a limiting factor (that's what you pay for) and THERE is
> where the intelligent queueing needs to be (or have really small buffers
> that saw-tooth bulk TCP performance so the smaller capacity interactive
> flows have a high probability of succeeding in getting their traffic
> thru).

I agree on that. Since you were in the Stockholm IETF,
you must have seen my Ph.D. student Dragana's presentation,
which addressed exactly that:
http://www.ietf.org/proceedings/75/slides/iccrg-1/iccrg-1_files/v3_document.htm
(it seems that her only diagram hasn't survived the conversion,
but it should be understandable anyhow)

Cheers,
Michael
(also pronounced "Mikael" by most people in these
parts of the world btw  :-)   )

From: [email-masked] (Damon Wischik)
Date: Mon Mar 29 08:17:46 2010
Subject: [Iccrg] congestion control and visability to the user
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Mikael Abrahamsson wrote:
> The core 
> router world is more and more going to smaller buffers (< 50ms, often 
> much lower than that) which makes WRED/ECN less and less usable.

Could you explain this? I thought that ECN was more and more useful, the 
smaller the buffer. The idea is to run a virtual queue, with capacity 
e.g. 90% of the link speed, and to mark packets when the virtual queue 
builds up. This way, the link should be able to maintain a stable 
utilization of about 90%, and the flows should never see packet drops.

Of course, I'm assuming that the link is congested. Your other point was 
that core links should never be congested.

Damon.

From: [email-masked] (Mikael Abrahamsson)
Date: Mon Mar 29 05:08:28 2010
Subject: [Iccrg] congestion control and visability to the user
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Sun, 28 Mar 2010, Matt Mathis wrote:

> Yea, we are all worried about ECN.    ECN capable routers are in wide
> deployment, but nearly all have it turned off by default.

Last I checked, Cisco 12000, 7600, CRS-1 or Juniper T/M series did not do 
ECN and there was no real interest from them to start supporting it 
either.

> Your statement was true for old stacks that have fixed size receiver
> windows.   The new stacks autotune out to 4 or 8 MByte windows.
> Unless you are on a transcontinental  GigE, every connection with
> enough data will cause packet loss or queues somewhere in the network.

Yes, on the access line absolutely, but not in the core.

>  Since all networks are at least slightly oversubscribed at most
> levels, the potential exists for there to be congestion nearly
> everywhere.   Between autotuning and p2p it is no longer possible to
> avoid congestion in the core except by explicitly designing in
> bottlenecks at midlevel interconnects, the network edges or somewhere
> in between.

The customer is paying for a certain access to The Internet, congesting in 
the core basically is a breach of contract. The only congestion on a well 
behaved network is on the access line (PE-CE link).

> You are off the mark here.  The problem is that the traditional "TCP
> friendly" model does not implement anything that resembles any form of
> fairness except under completely idealistic assumptions.  TCP has been
> lame for 20+ years, such that we failed to notice that the Internet
> does not have a real capacity sharing architecture.  Now that TCP is
> mostly not lame, people are discovering that you do not want to share
> the network with a well functioning bulk TCP transfer.  This has
> actually been known in a theoretical sense for a long time (see RFC
> 2309), but was not often a problem until recently.

I guess your view of the wolrd and mine differes widely. I don't agree 
with you at all. ISPs congesting their cores are doing a bad job and 
should be punished for it.

> I didn't realize how bad it might be until I had a conversation with
> my son, who mused that he liked his new PC because it was so quick on
> the network.  However, whenever he is doing anything serious (he is a
> web designer), everybody else on his home LAN starts to complain.

That is the PE-CE link I was talking about. The PE-P-PE links should never 
go full, then they're not capacity managed correctly. The PE-CE link is 
designed to be a limiting factor (that's what you pay for) and THERE is 
where the intelligent queueing needs to be (or have really small buffers 
that saw-tooth bulk TCP performance so the smaller capacity interactive 
flows have a high probability of succeeding in getting their traffic 
thru).

-- 
Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (Matt Mathis)
Date: Mon Mar 29 04:57:34 2010
Subject: [Iccrg] congestion control and visability to the user
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Sun, Mar 28, 2010 at 9:03 PM, Mikael Abrahamsson <[email-masked]> wrote:

> I participated in IETF75 which was my first and only IETF so far, and I've
> been trying to participate some via the mailing lists after that. I was in
> the ICCRG session and voiced concern regarding ECN, where it sounded there
> as people thought ECN was in wide use today, which it's not and there is
> nothing to suggest to me that it'll ever be. The core router world is more
> and more going to smaller buffers (< 50ms, often much lower than that) which
> makes WRED/ECN less and less usable.

Yea, we are all worried about ECN.    ECN capable routers are in wide
deployment, but nearly all have it turned off by default.

You are correct, at core speeds you never see significant queuing
(this was also mentioned at IETF 77).   However the Approximate Fair
Dropping (AFD) algorithm uses a shadow buffer in TCAM to approximate
WRED in virtual queues.  See: Rong Pan et al "Approximate fairness
through differential dropping", ACM CCR April 2003.  There are newer
papers but they were not published in the standard venues, so I don't
have clean citations for them.   Search for papers by Rong Pan that
start "Approximate Fair...".

> Apart from the access, the ISP should never congest and thus should never be
> dropping packets. Core Network congestion is not something "natural", it
> means the ISP is not doing its job properly.

Your statement was true for old stacks that have fixed size receiver
windows.   The new stacks autotune out to 4 or 8 MByte windows.
Unless you are on a transcontinental  GigE, every connection with
enough data will cause packet loss or queues somewhere in the network.
  Since all networks are at least slightly oversubscribed at most
levels, the potential exists for there to be congestion nearly
everywhere.   Between autotuning and p2p it is no longer possible to
avoid congestion in the core except by explicitly designing in
bottlenecks at midlevel interconnects, the network edges or somewhere
in between.

The problem is that AIMD congestion control does not work well enough
at these scales.   See my the talk that fell off of the ICCRG agenda:
http://staff.psc.edu/mathis/papers/FlowIsolation20100323.pdf  (the
detailed argument is in the first set of backup slides).

> I therefore suggest that what
> is needed is to make is visable to the end user when core network congestion
> is occuring, and provide them means to try to fine what it causing it, so
> they can make an informed decision whether to complain to their service
> provider and might change providers.

You are off the mark here.  The problem is that the traditional "TCP
friendly" model does not implement anything that resembles any form of
fairness except under completely idealistic assumptions.  TCP has been
lame for 20+ years, such that we failed to notice that the Internet
does not have a real capacity sharing architecture.  Now that TCP is
mostly not lame, people are discovering that you do not want to share
the network with a well functioning bulk TCP transfer.  This has
actually been known in a theoretical sense for a long time (see RFC
2309), but was not often a problem until recently.

I didn't realize how bad it might be until I had a conversation with
my son, who mused that he liked his new PC because it was so quick on
the network.  However, whenever he is doing anything serious (he is a
web designer), everybody else on his home LAN starts to complain.

> In the TCP group I made the same suggestion, to standardize an interface
> into the TCP stack so as to make it visible to a statistics collection
> application on the computer so it can present network statistics to the end
> user. Also such speed limiting factors as "TCP window fully open" is
> interesting to know about, ie the speed is limited by RTT/window size.

See Web100.org and RFC 4898, which do all of the above and more.  They
are not out in stock operating systems quite yet....

> I believe today that the users too much see the Internet as a black box they
> have little or no visibility into, and this is where the IETF as a whole
> should put resources into fixing this situation. It should not be done by
> developing testing tools, but instead making the existing traffic able to
> report performance in a standardized way. I also think that any future work
> in congestion control/avoidance should include API etc for external
> applications in a meaningful way to extract this information and present it
> to the user. This might actually need a WG of its own, I don't know.

The network visibility was sort of the insight that lead to the IPPM
WG, some 15+ years ago.  It has proven to be a rather hard problem.

There has been lots of research proposing richer APIs  for managing
performance.  None have caught on.   This has also come up recently in
ICCRG, and will be discussed over the next several years I am sure.

I hope this helps,
--MM--

From: [email-masked] (Mikael Abrahamsson)
Date: Mon Mar 29 04:28:57 2010
Subject: [Iccrg] Re: Easter egg in my flow Isolation (non) talk
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Sun, 28 Mar 2010, Matt Mathis wrote:

> My talk is on the meeting materials page or 
> http://staff.psc.edu/mathis/papers/FlowIsolation20100323.pdf

I strongly oppose the notion here that ISPs can't build out their core 
networks so it doesn't congest. There is no technical reason why it can't 
be done, and the cost of core network is still fairly small on a 
per-subscriber/megabit basis.

Making core routers cope with flows will make them substantially more 
expensive which will make them costlier to upgrade, which is a negative 
spiral. The core should be considered to be fast and stupid and 
intelligence should be in the access layer. I see no reason to change the 
classic IETF view on this.

What we need is per-flow intelligence on the PE-CE link (basically 
fair-queue), this is what is lacking today.

The core congestion seen today has often other reasons than technical, and 
thus doesn't have a technical solution that makes any real sense.

-- 
Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (Matt Mathis)
Date: Mon Mar 29 04:13:36 2010
Subject: [Iccrg] Re: Easter egg in my flow Isolation (non) talk
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Oops, this message seems to have been truncated.....

On Wed, Mar 24, 2010 at 2:42 PM, Matt Mathis <[email-masked]> wrote:
> Due to constraints on the meeting time and the extension for the IW
> discussion, my presentation on Flow Isolation fell off the agenda.
>
> I would like to point out an unrelated mini-talk attached to the end
> of my flow isolation slides, titled "TCP is still lame" (slides
> 30-35). ? It outlines a complete restructuring of the current
> congestion control algorithms. ?My proposal does not change any of the
> principles behind any of the current algorithms, but would completely
> change their implementations to make them far simpler and TCP's
> behavior easier to model. ?Furthermore many of the existing algorithms
> become implicit: ?sshthresh disappears completely, and the initial
> slowstart happens as a side effect of setting cwnd=MAXWIN
>
> I'm guessing the new algorithms would be about 10% of the current code....
>

My talk is on the meeting materials page or
http://staff.psc.edu/mathis/papers/FlowIsolation20100323.pdf

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

From: [email-masked] (Mikael Abrahamsson)
Date: Mon Mar 29 02:11:59 2010
Subject: [Iccrg] congestion control and visability to the user
Message-ID: <[email-masked]>

Hello.

I participated in IETF75 which was my first and only IETF so far, and I've 
been trying to participate some via the mailing lists after that. I was in 
the ICCRG session and voiced concern regarding ECN, where it sounded there 
as people thought ECN was in wide use today, which it's not and there is 
nothing to suggest to me that it'll ever be. The core router world is more 
and more going to smaller buffers (< 50ms, often much lower than that) 
which makes WRED/ECN less and less usable.

It also shows that whatever is invented that involves changing things in 
routers takes 5+ years, if ever, to get implemented. It also means that 
really long core network delays due to congestion is also going away, 
we'll see packet losses straight away. In the ETTH space where cheap and 
small L2 switches are often used, there also quite small buffers are used 
(often < 5ms).

Apart from the access, the ISP should never congest and thus should never 
be dropping packets. Core Network congestion is not something "natural", 
it means the ISP is not doing its job properly. I therefore suggest that 
what is needed is to make is visable to the end user when core network 
congestion is occuring, and provide them means to try to fine what it 
causing it, so they can make an informed decision whether to complain to 
their service provider and might change providers.

In the TCP group I made the same suggestion, to standardize an interface 
into the TCP stack so as to make it visible to a statistics collection 
application on the computer so it can present network statistics to the 
end user. Also such speed limiting factors as "TCP window fully open" is 
interesting to know about, ie the speed is limited by RTT/window size.

I believe today that the users too much see the Internet as a black box 
they have little or no visibility into, and this is where the IETF as a 
whole should put resources into fixing this situation. It should not be 
done by developing testing tools, but instead making the existing traffic 
able to report performance in a standardized way. I also think that any 
future work in congestion control/avoidance should include API etc for 
external applications in a meaningful way to extract this information and 
present it to the user. This might actually need a WG of its own, I don't 
know.

Thoughts?

-- 
Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (Matt Mathis)
Date: Wed Mar 24 18:51:40 2010
Subject: [Iccrg] Easter egg in my flow Isolation (non) talk
Message-ID: <[email-masked]>

Due to constraints on the meeting time and the extension for the IW
discussion, my presentation on Flow Isolation fell off the agenda.

I would like to point out an unrelated mini-talk attached to the end
of my flow isolation slides, titled "TCP is still lame" (slides
30-35).   It outlines a complete restructuring of the current
congestion control algorithms.  My proposal does not change any of the
principles behind any of the current algorithms, but would completely
change their implementations to make them far simpler and TCP's
behavior easier to model.  Furthermore many of the existing algorithms
become implicit:  sshthresh disappears completely, and the initial
slowstart happens as a side effect of setting cwnd=MAXWIN

I'm guessing the new algorithms would be about 10% of the current code....

From: [email-masked] (Murari Sridharan)
Date: Tue Mar 23 21:48:06 2010
Subject: [Iccrg] Increasing ICW
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Changed the title so we can continue discussion from the meeting. Below link describes the approaches we are taking to make the web faster. There are two sets of changes one primarily for the intra-datacenter flows and the other for WAN transfers. The latter work is toying with the idea of increasing ICW.
  A lot of people voiced very valid concerns. We are also very concerned that there may be pockets of the Internet where a large ICW burst can be problematic. However as I mentioned today    morning we should make a data driven decision. We have been experimenting and we will share our results as well.
This is an important discussion to have in tcpm, whether or not the current draft should be adopted by the WG should be debated in the coming meetings. I think we need to consider this being a application driven socket option instead of a global setting.
Thanks
Murari

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murari Sridharan
Sent: Tuesday, March 23, 2010 11:25 AM
To: [email-masked]; [email-masked]
Cc: Matt Mathis; Jitu Padhye; Dave Maltz; Albert Greenberg
Subject: [tcpm] Cloud faster

To follow up on what I mentioned at the mike, here is the work we have been doing and we can help collect data here.

http://research.microsoft.com/en-us/projects/cloudfaster/

Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20100323/1bc4b1b5/attachment-0001.html
>From [email-masked]  Tue Mar 23 23:51:34 2010
From: [email-masked] (Bob Briscoe)
Date: Wed Mar 24 00:00:52 2010
Subject: [Iccrg] Fwd: Re: Slides for ICCRG
In-Reply-To: <[email-masked] cal>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Edwin,

Sorry everyone. I'll get this right on the third try...

Slides on the Internet Capacity Sharing Architecture Design Team are here:
<http://staff.psc.edu/mathis/papers/1003iccrg-icsa-research.pdf> and .ppt
Or here:
<http://www.bobbriscoe.net/present.html>

Bob

At 22:03 23/03/2010, Mallette, Edwin wrote:
>Bob,
>
>The linked presentation is not the same one that you presented in 
>the ICCRG session this morning.  This presentation was on the ietf 
>page entitled iccrg-6.pdf.  If you could send the link to the joint 
>presentation, that would be great - unless I'm completely blind and 
>missed it.  That's always a possibility.
>
>Ed
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Bob Briscoe
>Sent: Tuesday, March 23, 2010 10:34 AM
>To: iccrg IRTF list
>Subject: [Iccrg] Fwd: Re: Slides for ICCRG
>
>Folks,
>
>Apologies for this link not getting out to remote participants until
>after the presentation. The mail queued due to my link to my VPN
>dropping out and I didn't notice.
>
>Also, apologies for the earlier claim that my site gave a link to the
>slides. I had uploaded the slides, but not the new index page linking to them.
>
>Whoops.
>
>
>Bob
>
> >Date: Tue, 23 Mar 2010 16:57:16 +0000
> >To: "iccrg IRTF list" <[email-masked]>
> >From: Bob Briscoe <[email-masked]>
> >Subject: Fwd: Re: Slides for ICCRG
> >
> >Slides being covered right now in ICCRG
> >
> >>http://staff.psc.edu/mathis/papers/FlowIsolation20100323.pdf
> >
> >
> >Bob
> >
> >
> >>DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
> >>         d=gmail.com; s=gamma;
> >>         h=domainkey-signature:mime-version:received:in-reply-to:references
> >>          :date:message-id:subject:from:to:cc:content-type
> >>          :content-transfer-encoding;
> >>         bh=qsiIBmmsGOgZWJ8yb4HNvN8eqH10JQ4cJ3fg0SRUusA=;
> >> 
> b=ZW/8FvOcxKqkKhTi+GUBqFJ9hMekz+u8GDjNj6+g/QYwhrwO84QMKy5brYnVIy3lqU
> >>
> >>2VxJyOr2aza+gBbmRILGh3vkiKhMX6BDthQmmOiG/ae7OSaC/3yqLVtJML8vnug/XzI8
> >>          xlmFmt88dB+efS2OJFSUD3QBL3+btlu3QS0Tw=
> >>DomainKey-Signature: a=rsa-sha1; c=nofws;
> >>         d=gmail.com; s=gamma;
> >>
> >>h=mime-version:in-reply-to:references:date:message-id:subject:from:to
> >>          :cc:content-type:content-transfer-encoding;
> >> 
> b=wEuMa6huoy4QCFenF59BGKFTueM3QFGFEAD+A3XOXPOf/ksiUOi3BvbOI0nFPXthGt
> >>
> >>3XL8oFT3ZPGJ7CHkwpcQBeEuuCOj2Z1oMAW3rO+kM7+M8/uZB1te5itng9YixaJOhGO3
> >>          m4XEwitL8kJ+gTpiVBmiM2qcdIHrPhGzEtktM=
> >>Date: Tue, 23 Mar 2010 10:55:42 -0400
> >>Subject: Re: Slides for ICCRG
> >>From: Matt Mathis <[email-masked]>
> >>To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]"
> >><[email-masked]>
> >>Cc: Bob Briscoe <[email-masked]>
> >>X-OriginalArrivalTime: 23 Mar 2010 14:55:43.0334 (UTC)
> >>FILETIME=[E969B860:01CACA98]
> >>X-Spam-Score: -2.152 () AWL,BAYES_00
> >>X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
> >>X-MIME-Autoconverted: from quoted-printable to 8bit by
> >>bagheera.jungle.bt.co.uk id o2NF5lel028631
> >>X-EsetId: 0F8DF726E5FD943A5DCB
> >>
> >>I just posted some updates to my Flow Isolation talk
> >>http://staff.psc.edu/mathis/papers/FlowIsolation20100323.pdf
> >>
> >>Thanks,
> >>--MM--
> >>-------------------------------------------
> >>Matt Mathis      http://staff.psc.edu/mathis
> >>Work:412.268.3319   Home/Cell:412.654.7529
> >>-------------------------------------------
> >>Evil is defined by mortals who think they know
> >>"The Truth" and use force to apply it to others.
> >>
> >>
> >>
> >>On Mon, Mar 22, 2010 at 4:43 PM, Eddy, Wesley M. (GRC-MS00)[ASRC
> >>AEROSPACE CORP] <[email-masked]> wrote:
> >> > Ok; I'll post them as-is just to make sure there's something
> >> there for remote people to look at, and if you update them, I can
> >> replace them pretty easily.
> >> >
> >> > ________________________________________
> >> > From: Matt Mathis [[email-masked]]
> >> > Sent: Monday, March 22, 2010 4:35 PM
> >> > To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
> >> > Subject: Slides for ICCRG
> >> >
> >> > Draft slides are up at
> >> > http://staff.psc.edu/mathis/papers/FlowIsolation20100323.pdf.  There
> >> > is a small chance that I will make some minor changes later this
> >> > afternoon, so delayed uploading would be good, but not required.
> >> > They are close enough where it would not be a crisis to post the wrong
> >> > set.
> >> >
> >> > Thanks,
> >> > --MM--
> >> > -------------------------------------------
> >> > Matt Mathis      http://staff.psc.edu/mathis
> >> > Work:412.268.3319   Home/Cell:412.654.7529
> >> > -------------------------------------------
> >> > Evil is defined by mortals who think they know
> >> > "The Truth" and use force to apply it to others.
> >
> >________________________________________________________________
> >Bob Briscoe,                                BT Innovate & Design
>
>________________________________________________________________
>Bob Briscoe,                                BT Innovate & Design
>
>
>_______________________________________________
>Iccrg mailing list
>[email-masked]
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>CONFIDENTIALITY NOTICE: This e-mail may contain information that is 
>privileged, confidential or otherwise protected from disclosure. If 
>you are not the intended recipient of this e-mail, please notify the 
>sender immediately by return e-mail, purge it and do not disseminate 
>or copy it.
>
>CONFIDENTIALITY NOTICE: This e-mail may contain information that is 
>privileged, confidential or otherwise protected from disclosure. If 
>you are not the intended recipient of this e-mail, please notify the 
>sender immediately by return e-mail, purge it and do not disseminate 
>or copy it.

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design 

From: [email-masked] (Murari Sridharan)
Date: Tue Mar 23 18:34:41 2010
Subject: [Iccrg] Cloud faster
Message-ID: <[email-masked]>

To follow up on what I mentioned at the mike, here is the work we have been doing and we can help collect data here.

http://research.microsoft.com/en-us/projects/cloudfaster/

Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20100323/2db2f4c1/attachment.html
>From [email-masked]  Tue Mar 23 17:34:15 2010
From: [email-masked] (Bob Briscoe)
Date: Tue Mar 23 21:22:57 2010
Subject: [Iccrg] Fwd: Re: Slides for ICCRG
Message-ID: <[email-masked]>

Folks,

Apologies for this link not getting out to remote participants until 
after the presentation. The mail queued due to my link to my VPN 
dropping out and I didn't notice.

Also, apologies for the earlier claim that my site gave a link to the 
slides. I had uploaded the slides, but not the new index page linking to them.

Whoops.

Bob

>Date: Tue, 23 Mar 2010 16:57:16 +0000
>To: "iccrg IRTF list" <[email-masked]>
>From: Bob Briscoe <[email-masked]>
>Subject: Fwd: Re: Slides for ICCRG
>
>Slides being covered right now in ICCRG
>
>>http://staff.psc.edu/mathis/papers/FlowIsolation20100323.pdf
>
>
>Bob
>
>
>>DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>>         d=gmail.com; s=gamma;
>>         h=domainkey-signature:mime-version:received:in-reply-to:references
>>          :date:message-id:subject:from:to:cc:content-type
>>          :content-transfer-encoding;
>>         bh=qsiIBmmsGOgZWJ8yb4HNvN8eqH10JQ4cJ3fg0SRUusA=;
>>         b=ZW/8FvOcxKqkKhTi+GUBqFJ9hMekz+u8GDjNj6+g/QYwhrwO84QMKy5brYnVIy3lqU
>> 
>>2VxJyOr2aza+gBbmRILGh3vkiKhMX6BDthQmmOiG/ae7OSaC/3yqLVtJML8vnug/XzI8
>>          xlmFmt88dB+efS2OJFSUD3QBL3+btlu3QS0Tw=
>>DomainKey-Signature: a=rsa-sha1; c=nofws;
>>         d=gmail.com; s=gamma;
>> 
>>h=mime-version:in-reply-to:references:date:message-id:subject:from:to
>>          :cc:content-type:content-transfer-encoding;
>>         b=wEuMa6huoy4QCFenF59BGKFTueM3QFGFEAD+A3XOXPOf/ksiUOi3BvbOI0nFPXthGt
>> 
>>3XL8oFT3ZPGJ7CHkwpcQBeEuuCOj2Z1oMAW3rO+kM7+M8/uZB1te5itng9YixaJOhGO3
>>          m4XEwitL8kJ+gTpiVBmiM2qcdIHrPhGzEtktM=
>>Date: Tue, 23 Mar 2010 10:55:42 -0400
>>Subject: Re: Slides for ICCRG
>>From: Matt Mathis <[email-masked]>
>>To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" 
>><[email-masked]>
>>Cc: Bob Briscoe <[email-masked]>
>>X-OriginalArrivalTime: 23 Mar 2010 14:55:43.0334 (UTC) 
>>FILETIME=[E969B860:01CACA98]
>>X-Spam-Score: -2.152 () AWL,BAYES_00
>>X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
>>X-MIME-Autoconverted: from quoted-printable to 8bit by 
>>bagheera.jungle.bt.co.uk id o2NF5lel028631
>>X-EsetId: 0F8DF726E5FD943A5DCB
>>
>>I just posted some updates to my Flow Isolation talk
>>http://staff.psc.edu/mathis/papers/FlowIsolation20100323.pdf
>>
>>Thanks,
>>--MM--
>>-------------------------------------------
>>Matt Mathis      http://staff.psc.edu/mathis
>>Work:412.268.3319   Home/Cell:412.654.7529
>>-------------------------------------------
>>Evil is defined by mortals who think they know
>>"The Truth" and use force to apply it to others.
>>
>>
>>
>>On Mon, Mar 22, 2010 at 4:43 PM, Eddy, Wesley M. (GRC-MS00)[ASRC
>>AEROSPACE CORP] <[email-masked]> wrote:
>> > Ok; I'll post them as-is just to make sure there's something 
>> there for remote people to look at, and if you update them, I can 
>> replace them pretty easily.
>> >
>> > ________________________________________
>> > From: Matt Mathis [[email-masked]]
>> > Sent: Monday, March 22, 2010 4:35 PM
>> > To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
>> > Subject: Slides for ICCRG
>> >
>> > Draft slides are up at
>> > http://staff.psc.edu/mathis/papers/FlowIsolation20100323.pdf.  There
>> > is a small chance that I will make some minor changes later this
>> > afternoon, so delayed uploading would be good, but not required.
>> > They are close enough where it would not be a crisis to post the wrong
>> > set.
>> >
>> > Thanks,
>> > --MM--
>> > -------------------------------------------
>> > Matt Mathis      http://staff.psc.edu/mathis
>> > Work:412.268.3319   Home/Cell:412.654.7529
>> > -------------------------------------------
>> > Evil is defined by mortals who think they know
>> > "The Truth" and use force to apply it to others.
>
>________________________________________________________________
>Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design 

From: [email-masked] (Bob Briscoe)
Date: Tue Mar 23 17:23:24 2010
Subject: [Iccrg] Fwd: Re: Slides for ICCRG
Message-ID: <[email-masked]>

Slides being covered right now in ICCRG

>http://staff.psc.edu/mathis/papers/FlowIsolation20100323.pdf

Bob

>DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>         d=gmail.com; s=gamma;
>         h=domainkey-signature:mime-version:received:in-reply-to:references
>          :date:message-id:subject:from:to:cc:content-type
>          :content-transfer-encoding;
>         bh=qsiIBmmsGOgZWJ8yb4HNvN8eqH10JQ4cJ3fg0SRUusA=;
>         b=ZW/8FvOcxKqkKhTi+GUBqFJ9hMekz+u8GDjNj6+g/QYwhrwO84QMKy5brYnVIy3lqU
>          2VxJyOr2aza+gBbmRILGh3vkiKhMX6BDthQmmOiG/ae7OSaC/3yqLVtJML8vnug/XzI8
>          xlmFmt88dB+efS2OJFSUD3QBL3+btlu3QS0Tw=
>DomainKey-Signature: a=rsa-sha1; c=nofws;
>         d=gmail.com; s=gamma;
>         h=mime-version:in-reply-to:references:date:message-id:subject:from:to
>          :cc:content-type:content-transfer-encoding;
>         b=wEuMa6huoy4QCFenF59BGKFTueM3QFGFEAD+A3XOXPOf/ksiUOi3BvbOI0nFPXthGt
>          3XL8oFT3ZPGJ7CHkwpcQBeEuuCOj2Z1oMAW3rO+kM7+M8/uZB1te5itng9YixaJOhGO3
>          m4XEwitL8kJ+gTpiVBmiM2qcdIHrPhGzEtktM=
>Date: Tue, 23 Mar 2010 10:55:42 -0400
>Subject: Re: Slides for ICCRG
>From: Matt Mathis <[email-masked]>
>To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
>Cc: Bob Briscoe <[email-masked]>
>X-OriginalArrivalTime: 23 Mar 2010 14:55:43.0334 (UTC) 
>FILETIME=[E969B860:01CACA98]
>X-Spam-Score: -2.152 () AWL,BAYES_00
>X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
>X-MIME-Autoconverted: from quoted-printable to 8bit by 
>bagheera.jungle.bt.co.uk id o2NF5lel028631
>X-EsetId: 0F8DF726E5FD943A5DCB
>
>I just posted some updates to my Flow Isolation talk
>http://staff.psc.edu/mathis/papers/FlowIsolation20100323.pdf
>
>Thanks,
>--MM--
>-------------------------------------------
>Matt Mathis      http://staff.psc.edu/mathis
>Work:412.268.3319   Home/Cell:412.654.7529
>-------------------------------------------
>Evil is defined by mortals who think they know
>"The Truth" and use force to apply it to others.
>
>
>
>On Mon, Mar 22, 2010 at 4:43 PM, Eddy, Wesley M. (GRC-MS00)[ASRC
>AEROSPACE CORP] <[email-masked]> wrote:
> > Ok; I'll post them as-is just to make sure there's something 
> there for remote people to look at, and if you update them, I can 
> replace them pretty easily.
> >
> > ________________________________________
> > From: Matt Mathis [[email-masked]]
> > Sent: Monday, March 22, 2010 4:35 PM
> > To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
> > Subject: Slides for ICCRG
> >
> > Draft slides are up at
> > http://staff.psc.edu/mathis/papers/FlowIsolation20100323.pdf.  There
> > is a small chance that I will make some minor changes later this
> > afternoon, so delayed uploading would be good, but not required.
> > They are close enough where it would not be a crisis to post the wrong
> > set.
> >
> > Thanks,
> > --MM--
> > -------------------------------------------
> > Matt Mathis      http://staff.psc.edu/mathis
> > Work:412.268.3319   Home/Cell:412.654.7529
> > -------------------------------------------
> > Evil is defined by mortals who think they know
> > "The Truth" and use force to apply it to others.

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design 

From: [email-masked] (Bob Briscoe)
Date: Sun Mar 21 20:13:30 2010
Subject: [Iccrg] Re: #1/2 draft-mayutan-ledbat-congestionarchitecture-00.txt
In-Reply-To: <[email-masked] m>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20100321/9595057b/attachment.html
>From [email-masked]  Sun Mar 21 20:13:41 2010
From: [email-masked] (Bob Briscoe)
Date: Sun Mar 21 20:23:17 2010
Subject: [Iccrg] Re: #2/2 draft-mayutan-ledbat-congestionarchitecture-00.txt
In-Reply-To: <[email-masked] m>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Mayutan,

At 15:37 21/03/2010, Mayutan A. wrote:
>Hi Bob,
>
>Thanks once again for your feedback. See inline.
>
>On Sun, Mar 21, 2010 at 1:03 AM, Bob Briscoe 
><<mailto:[email-masked]>[email-masked]> wrote:
>Mayutan, Xiaoming, KK,
>
>Mail #2 of 2: Thoughts on the decomposition itself
>
>Bandwidth-estimation module
>---------------------------
>I propose it's better to think of this as a 
>Window-overshoot-mitigation module.
>
>i) Bandwidth is the wrong concept. A cc is looking for how much data 
>it can risk setting off in flight when it's got insufficient 
>information to determine a precise answer. That's a window concept 
>[unit: byte], not a bandwidth concept [unit: b/s]. Take QS. The 
>router thinks in terms of spare b/s. But the transport has to 
>multiply that by RTT to get the initial window it should use.
>
>
>Currently, what I have in mind is the estimation of actual bandwidth 
>to assist the flow-control module and leave it to the flow-control 
>module to convert this to a relevant window size. In theory, this 
>module could indicate window size too. Thanks for the alternate name 
>suggestion.

I'm not concerned about just the name. The semantics of window is 
what I think you need here, not bandwidth. This is important to get right.

[A similar example: Stas Shalunov pointed out to me once (I think 
repeating someone else) that if MTU had been defined in units of 
time, not bytes, packets would have grown naturally as link 
technology increased and data networking would have evolved very 
differently. Effectively the MTU is the liaison concept between IETF 
and IEEE. Similarly, the interface to your top module is important to 
get in the right units.]

>ii) It's not so much about estimating the right window. It's more 
>about ensuring the window is not too wrong, while trying to 
>otherwise be as greedy as possible.
>
>
>By estimation, I meant the above. Thanks for phrasing it well. I 
>should probably use a different word here or the name suggested by you.

Cheers

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20100321/8880de75/attachment.html
>From [email-masked]  Mon Mar 22 20:02:05 2010
From: [email-masked] (Eddy,
	Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP])
Date: Mon Mar 22 20:14:25 2010
Subject: [Iccrg] RE: IETF 77 agenda
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Note that the session originally planned for Thursday was swapped to a Wednesday morning timeslot.

The ICCRG meetings are now scheduled for:

Tuesday morning 9:00 - 11:30 in Palos Verdes
and
Wednesday morning 9:00 - 11:30 in California D

For remote participatoin, you can find links to the streaming audio and presentation material from here:
http://tools.ietf.org/agenda/77
and search for "iccrg".

________________________________________
From: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
Sent: Monday, March 08, 2010 12:28 PM
To: [email-masked]
Subject: IETF 77 agenda

I've posted a draft agenda for the ICCRG sessions at IETF 77 here:
http://www.ietf.org/proceedings/10mar/agenda/iccrg.txt

Despite having 2 sessions, it's still a packed agenda, so I'm
planning to stay close to times allotted.  Please keep this in
mind when preparing presentations.

The mailing list has been relatively quiet for some time, so
please feel free to post background or other discussion
material which might help us to save time in presentations or
encourage discussion.

If there are revisions to timeslots, titles, etc. needed, just
let Michael and I know.

See you in Anaheim.

--
Wes Eddy
MTI Systems
>From [email-masked]  Tue Mar 23 16:16:25 2010
From: [email-masked] (Bob Briscoe)
Date: Tue Mar 23 16:25:49 2010
Subject: [Iccrg] Report re Wes's talk right now: ICCRG related IETF stuff
Message-ID: <[email-masked]>

Folks,

In 2008, we had a workshop with a bunch of IETF & IRTF people at 
Sholss Dagstuhl in Germany on interelation between Transport & 
Network layer that identified interactions between things going on at 
each layer. It particularly focused on the interaction between 
locator-ID split developments and congestion control. But also some 
of the other things Wes just mentioned.

Here's the report:

Dagstuhl Perspectives Workshop on End-to-End Protocols for the Future 
Internet, Jari Arkko (Ericsson) Bob Briscoe (BT), Lars Eggert 
(Nokia), Anja Feldmann (TU Berlin & DT) and Mark Handley (UCL), ACM 
Computer Communications Review (Editorial Zone) 39(2) 42--46 (Apr 2009).
<http://www.bobbriscoe.net/pubs.html#dagstuhl-fi>

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design 

From: [email-masked] (Mayutan A.)
Date: Sun Mar 21 15:28:51 2010
Subject: [Iccrg] Re: #1/2 draft-mayutan-ledbat-congestionarchitecture-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello Bob,

Thanks a lot for your feedback. See inline for comments.

On Sun, Mar 21, 2010 at 12:48 AM, Bob Briscoe <[email-masked]>wrote:

> Mayutan, Xiaoming, KK,
>
> It seems a good idea to try to decompose the sub-functions of CC. I suspect
> this is best kept to the CC design process though (primarily ICCRG). Rather
> than an organising principle for standardisation as well (as suggested in
> the draft).
>

Our primary focus was to attempt such a decoupling in the LEDBAT WG for a
scavenger transport protocol, before attempting a more general one in the
ICCRG.

>
> So I'll split my thoughts into 2 mails:
> #1 (this one) Applicability of the decomposition: design, or standards too?
> #2 (next) thoughts on the decomposition itself
>
> Sub-questions to help determine whether we should decompose CC standards:
>
> Q1. Are we likely to need lots of different scavenger CCs, or are we more
> likely to be refining and improving a single track of progressively more
> generic/graceful/cool ones?
> A1. I say we probably need just one track
>

I would agree to having just one track too, but based on a decoupled
architecture (not completely decoupled though). This would make it easier to
propose extensions. For e.g, if someone comes up with a better delay based
congestion detection tool, or a more efficient available bandwidth
estimation tool, we could just standardize the mechanism. The mechanism
could then be used not only by a scavenger protocol, but also by other
congestion control protocols. To phrase it differently, once the LEDBAT WG
standardizes a one-way delay based scavenger protocol, other CC protocols
may want to use the one-way delay based mechanism to detect congestion, but
their reaction to detected congestion might vary from that of a scavenger CC
protocol.

>
> Q2. Does experience show that the sub-functions are cleanly separated, to
> the extent that they could be plugged together in different ways?
> A2. I think the skill of designing a good congestion control is about how
> well the parts complement each other. In fact, one theme of the talk I'm
> planning for ICCRG this week is that we need to be more careful to think
> about the cross-effects of some flows in slow-start on others in congestion
> avoidance (& vv) when designing CC.
>

I agree that the various modules need to complement each other. This draft
is an attempt to study how and to what extent can we decouple the various
components.

So rather than showing Fig 1 as if there is one common interface between the
> paris of modules, it's more important to show that the interface depends on
> which type of outer module is used. For instance "CONGESTION_DETECTED" could
> be a binary congestion event, or a delay variable, or a QS bit-rate.
>

Currently, what I had in mind was a binary indicator
(congested/not-congested) or a multilevel indicator.  We need to give more
thought to whether we require multiple interfaces between the modules or
could we come up with a method to map the various indicators to a common
"CONGESTION_DETECTED" indicator.

>
>
> Here's an example of where we've already got more modularisation than we
> should have in the TCP standards (in your I-D's terminology, the flow
> control module behaviour should depend on the which congestion detection
> module we choose):
>
> If my window is 30x yours, and I get 40 ECN marks within one RTT and you
> get 1, I should reduce more than once within the RTT. Whereas if I get 40
> drops in one RTT, it's more correct to only reduce once.
>
> Reasoning: If congestion detection is by ECN not drop, it implies the
> congestion must be from AQM not tail drop. Whereas 40 drops can mean a whole
> load of synchronised tail drop, 40 ECN marks can't mean synchronised drop.
> So I should take 40 ECN marks more seriously.
>
> I would take this example as a pro for a decoupled architecture. The
congestion-detection module could take this into consideration while mapping
the
obtained indication to the  "CONGESTION_DETECTED"  variable. The flow
control module could be designed based on just the value returned by the
"CONGESTION_DETECTED" variable and need not have to differentiate between a
drop, an ecn marking or increase in delay.

>
> Finally, another thought on applicability: This I-D isn't only applicable
> to scavenger CCs. It's clearly applicable to all CC design work (again
> primarily ICCRG).
>
> That's not to say it can't help LEDBAT in future. LEDBAT is on the
> experimental track, so it would be fine if we learn something from this
> decomposition that can help improve LEDBAT between experimental and Proposed
> Standard stages.
>

Yes, we are planning to present it at the LEDBAT and make a short
presentation at the ICCRG too. We feel that the LEDBAT WG might be a good
starting point, and that the approach could be extended to all kinds of
congestion control protocols.

Mayutan

>
> Bob
>
>
> At 19:40 03/03/2010, Mayutan A. wrote:
>
>  We have submitted a new draft to the LEDBAT WG and are planning to make a
>> short presentation at the LEDBAT WG and the ICCRG.
>> We are looking forward to all your comments.
>> <
>> http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00
>> >
>> http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00
>>
>>
>> Feedback is welcome,
>> Mayutan Arumaithurai
>>
>
>
>
>
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design
>

-- 
Mayutan Arumaithurai
0049-551-2712647 (Home number)
0049-176-20322049 (mobile number)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20100321/6a8d9f42/attachment.html
>From [email-masked]  Sun Mar 21 15:37:58 2010
From: [email-masked] (Mayutan A.)
Date: Sun Mar 21 15:47:22 2010
Subject: [Iccrg] Re: #2/2 draft-mayutan-ledbat-congestionarchitecture-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Bob,

Thanks once again for your feedback. See inline.

On Sun, Mar 21, 2010 at 1:03 AM, Bob Briscoe <[email-masked]>wrote:

> Mayutan, Xiaoming, KK,
>
> Mail #2 of 2: Thoughts on the decomposition itself
>
> Bandwidth-estimation module
> ---------------------------
> I propose it's better to think of this as a Window-overshoot-mitigation
> module.
>
> i) Bandwidth is the wrong concept. A cc is looking for how much data it can
> risk setting off in flight when it's got insufficient information to
> determine a precise answer. That's a window concept [unit: byte], not a
> bandwidth concept [unit: b/s]. Take QS. The router thinks in terms of spare
> b/s. But the transport has to multiply that by RTT to get the initial window
> it should use.
>

Currently, what I have in mind is the estimation of actual bandwidth to
assist the flow-control module and leave it to the flow-control module to
convert this to a relevant window size. In theory, this module could
indicate window size too. Thanks for the alternate name suggestion.

>
> ii) It's not so much about estimating the right window. It's more about
> ensuring the window is not too wrong, while trying to otherwise be as greedy
> as possible.
>

By estimation, I meant the above. Thanks for phrasing it well. I should
probably use a different word here or the name suggested by you.

> Flow-control module
> -------------------
> Unfortunately ambiguous terminology.
> How about Load-response module?
>

Yes, this sounds good too.

>
> Suggestions for additional functions?
> ------------------------------------
> - Congestion signal conditioning (filtering out synchronised loss within a
> RTT, smoothing in TFRC, etc)
>
> Finally, it needs to be stated explicitly whether this decomposition is
> meant to be all within the sender, or within the transport
> (sender-receiver-pair), or too abstract for this question to be relevant.
>

The decomposition could be performed within the sender, and might be
necessary within the transport depending on the choice of the bandwidth
estimation mechanism. According to me, this kind of a decomposition is
implicitly followed in some of the current specifications. For e.g TCP
variants state that an ECN marking is to be treated similar to a loss, or
that the reaction to loss is to halve the congestion window, similar to that
performed by standard TCP.

>
>
> Bob
>
>
> At 19:40 03/03/2010, Mayutan A. wrote:
>
>  We have submitted a new draft to the LEDBAT WG and are planning to make a
>> short presentation at the LEDBAT WG and the ICCRG.
>> We are looking forward to all your comments.
>> <
>> http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00
>> >
>> http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00
>>
>>
>> Feedback is welcome,
>> Mayutan Arumaithurai
>>
>
>
>
>
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design
>

-- 
Mayutan Arumaithurai
0049-551-2712647 (Home number)
0049-176-20322049 (mobile number)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20100321/e5bbb08d/attachment-0001.html
>From [email-masked]  Sun Mar 21 18:57:02 2010
From: [email-masked] (Bob Briscoe)
Date: Sun Mar 21 19:06:46 2010
Subject: [Iccrg] Support requested: Start of WGLC for Tunnelling of ECN 
 (draft-ietf-tsvwg-ecn-tunnel)
Message-ID: <[email-masked]>

ICCRG folks,

Note the ecn-tunnel draft is now in w-g last call. Having a single 
consistent treatment of the ECN field through tunnels is important 
for using ECN in future.

The TSVWG Chairs are looking for messages of support (or not) on the 
[email-masked] list.

Tunnel behaviour has diverged in its treatment of the ECN field.
* At ingress, IPsec tunnels copy ECN, but some non-IPsec tunnels do a 
partial copy. This draft proposes to harmonise all tunnelling so the 
ECN field is copied, as IPsec does.
* At egress, this draft also ensures tunnels can support one or two 
severity levels of congestion notification. This adds support for PCN 
and would ease deployment of e2e approaches like VCP (Stoica's "One 
more bit is enough") in future.

Preferably post your messages to tsvwg before Monday's TSVWG session, 
altho you have until 12 Apr.

See below, which includes a link to the draft for the whole story.

Cheers

Bob

>Date: Fri, 12 Mar 2010 15:03:45 +0000
>From: Gorry Fairhurst <[email-masked]>
>Reply-To: [email-masked]
>Organization: The University of Aberdeen is a charity registered in Scotland,
>  No SC013683.
>To: tsvwg WG <[email-masked]>
>CC: Bob Briscoe <[email-masked]>,
>         tsvwg chair <[email-masked]>
>Subject: Start of WGLC for Tunnelling of ECN  (draft-ietf-tsvwg-ecn-tunnel)
>
>
>This email announces the beginning of a working group last call for
>draft-ietf-tsvwg-ecn-tunnel-08, "Tunnelling of Explicit Congestion 
>Notification". This document is now thought by the authors to be 
>ready to proceed to be published as a Proposed Standard. Please send 
>any comments to the TSVWG list.
>
>The draft is available at:
>https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-tunnel/
>
>The document will  be forwarded in parallel to the Security Directorate
>for a Security Review.
>
>The last call will run for FOUR weeks, ending Monday, 12th April 
>2010 (since it will cover an IETF meeting period). Emails saying "I 
>support" or "I don't support" are also most helpful in judging the consensus.
>
>James and Gorry
>(TSVWG Chairs)
>
>
>P.S. A copy of this mail will be sent also to the PCN WG for info.

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design  

From: [email-masked] (Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP])
Date: Sun Mar 21 02:53:09 2010
Subject: [Iccrg] #2/2 draft-mayutan-ledbat-congestionarchitecture-00.txt
In-Reply-To: <"ess3.cs.uc.624:21.02.10.01.42.15"@cs.ucl.ac.uk>
References: <"ess3.cs.uc.624:21.02.10.01.42.15"@cs.ucl.ac.uk>
Message-ID: <[email-masked]>

The decomposition struck me as a nice start for an abstraction,
though it seems to me like the implementation is probably a lot
more complex :).  I think the interfaces between modules are
probably quite a bit more complex when fleshed out, and then
it could be "fun" to try to orchestrate the data flow between the
modules (who gets to look at, and react to, packets first, who
gets to handle timers first, do modules operate in serial or in
parallel with one another, etc.).

I think I agree with some of Bob's comments, but I have a more
basic question that would be good to clear up, if possible, before
the presentation.  To me, it seems like the "flow-control module" is
hooked up to a set of sensors that tell it how fast it might be able to
go (the "bandwidth-estimation module") and another set of sensors
that tell it when it needs to slow down (the "congestion-detection
module").  But if we rely on same ACK traffic within a flow to feed
both of those sets of sensors, then isn't that division a bit artificial?

I took a little bit of a leap in reading it by assuming that maybe you
would have this incorporated with something like the Congestion
Manager (RFC 3124) so maybe the sets of signals would be shared
between flows as appropriate, in which case it then made a little more
sense to me to split the bandwidth-estimation from the congestion-
detection since they might each be happening through other
processes outside of the flow controlled by an individual flow-
controller.  But the document didn't exactly say this, so I don't know
if that's an assumption or part of the rationale for this decomposition
or not.

Also, there might be potential for the modules to fight with each other
a bit ... won't doing some types of packet probing in the bandwidth-
estimation module adversely impact a delay-based congestion-
detection module, for instance.  I guess there may be certain
combinations that are to be avoided?

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Bob Briscoe [[email-masked]]
Sent: Saturday, March 20, 2010 8:03 PM
To: Mayutan A.; Xiaoming Fu; KK RAMAKRISHNAN
Cc: [email-masked]; iccrg
Subject: [Iccrg] #2/2 draft-mayutan-ledbat-congestionarchitecture-00.txt

Mayutan, Xiaoming, KK,

Mail #2 of 2: Thoughts on the decomposition itself

Bandwidth-estimation module
---------------------------
I propose it's better to think of this as a Window-overshoot-mitigation module.

i) Bandwidth is the wrong concept. A cc is looking for how much data
it can risk setting off in flight when it's got insufficient
information to determine a precise answer. That's a window concept
[unit: byte], not a bandwidth concept [unit: b/s]. Take QS. The
router thinks in terms of spare b/s. But the transport has to
multiply that by RTT to get the initial window it should use.

ii) It's not so much about estimating the right window. It's more
about ensuring the window is not too wrong, while trying to otherwise
be as greedy as possible.

Flow-control module
-------------------
Unfortunately ambiguous terminology.
How about Load-response module?

Suggestions for additional functions?
------------------------------------
- Congestion signal conditioning (filtering out synchronised loss
within a RTT, smoothing in TFRC, etc)

Finally, it needs to be stated explicitly whether this decomposition
is meant to be all within the sender, or within the transport
(sender-receiver-pair), or too abstract for this question to be relevant.

Bob

At 19:40 03/03/2010, Mayutan A. wrote:

>We have submitted a new draft to the LEDBAT WG and are planning to
>make a short presentation at the LEDBAT WG and the ICCRG.
>We are looking forward to all your comments.
><http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00>http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00
>
>
>Feedback is welcome,
>Mayutan Arumaithurai

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

_______________________________________________
Iccrg mailing list
[email-masked]
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>From [email-masked]  Sun Mar 21 13:01:23 2010
From: [email-masked] (Michael Welzl)
Date: Sun Mar 21 13:11:14 2010
Subject: [ledbat] [Iccrg] #2/2 
	draft-mayutan-ledbat-congestionarchitecture-00.txt
In-Reply-To: <[email-masked]>
References: <"ess3.cs.uc.624:21.02.10.01.42.15"@cs.ucl.ac.uk>
	<[email-masked]>
Message-ID: <[email-masked]>

Hi,

Sorry if I'm simply getting something wrong here - I might...
but really, I wonder what's the point in trying to standardize something
as described in this draft?

The "CC. other than LEDBAT" case:

Pluggable congestion control already exists in Linux and BSD, and
seems to work fine there, without the need for a standard. What exactly
would become better because of this draft?

It seems to me that following such a new specification would probably  
mean
a major code rewrite, with no benefits attained except for being able to
say that it complies to this specification.

The LEDBAT case:

I think that, what LEDBAT needs is a specified encapsulation, i.e.
something explaining how the packets and ACKs look, or how this
could be implemented by, e.g., changing TCP a bit without changing
the way packets look (it seems likely that this could be done,
and because of TCP's great ability to fly through firewalls, it seems
to be a good choice to me).
- but how does this generic building block description help LEDBAT?

Again, sorry if this is just me misunderstanding things.

Cheers,
Michael

On Mar 21, 2010, at 3:43 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE  
CORP] wrote:

> The decomposition struck me as a nice start for an abstraction,
> though it seems to me like the implementation is probably a lot
> more complex :).  I think the interfaces between modules are
> probably quite a bit more complex when fleshed out, and then
> it could be "fun" to try to orchestrate the data flow between the
> modules (who gets to look at, and react to, packets first, who
> gets to handle timers first, do modules operate in serial or in
> parallel with one another, etc.).
>
> I think I agree with some of Bob's comments, but I have a more
> basic question that would be good to clear up, if possible, before
> the presentation.  To me, it seems like the "flow-control module" is
> hooked up to a set of sensors that tell it how fast it might be able  
> to
> go (the "bandwidth-estimation module") and another set of sensors
> that tell it when it needs to slow down (the "congestion-detection
> module").  But if we rely on same ACK traffic within a flow to feed
> both of those sets of sensors, then isn't that division a bit  
> artificial?
>
> I took a little bit of a leap in reading it by assuming that maybe you
> would have this incorporated with something like the Congestion
> Manager (RFC 3124) so maybe the sets of signals would be shared
> between flows as appropriate, in which case it then made a little more
> sense to me to split the bandwidth-estimation from the congestion-
> detection since they might each be happening through other
> processes outside of the flow controlled by an individual flow-
> controller.  But the document didn't exactly say this, so I don't know
> if that's an assumption or part of the rationale for this  
> decomposition
> or not.
>
> Also, there might be potential for the modules to fight with each  
> other
> a bit ... won't doing some types of packet probing in the bandwidth-
> estimation module adversely impact a delay-based congestion-
> detection module, for instance.  I guess there may be certain
> combinations that are to be avoided?
>
>
> ________________________________________
> From: [email-masked] [[email-masked]] On  
> Behalf Of Bob Briscoe [[email-masked]]
> Sent: Saturday, March 20, 2010 8:03 PM
> To: Mayutan A.; Xiaoming Fu; KK RAMAKRISHNAN
> Cc: [email-masked]; iccrg
> Subject: [Iccrg] #2/2 draft-mayutan-ledbat- 
> congestionarchitecture-00.txt
>
> Mayutan, Xiaoming, KK,
>
> Mail #2 of 2: Thoughts on the decomposition itself
>
> Bandwidth-estimation module
> ---------------------------
> I propose it's better to think of this as a Window-overshoot- 
> mitigation module.
>
> i) Bandwidth is the wrong concept. A cc is looking for how much data
> it can risk setting off in flight when it's got insufficient
> information to determine a precise answer. That's a window concept
> [unit: byte], not a bandwidth concept [unit: b/s]. Take QS. The
> router thinks in terms of spare b/s. But the transport has to
> multiply that by RTT to get the initial window it should use.
>
> ii) It's not so much about estimating the right window. It's more
> about ensuring the window is not too wrong, while trying to otherwise
> be as greedy as possible.
>
> Flow-control module
> -------------------
> Unfortunately ambiguous terminology.
> How about Load-response module?
>
> Suggestions for additional functions?
> ------------------------------------
> - Congestion signal conditioning (filtering out synchronised loss
> within a RTT, smoothing in TFRC, etc)
>
> Finally, it needs to be stated explicitly whether this decomposition
> is meant to be all within the sender, or within the transport
> (sender-receiver-pair), or too abstract for this question to be  
> relevant.
>
>
>
>
> Bob
>
>
> At 19:40 03/03/2010, Mayutan A. wrote:
>
>> We have submitted a new draft to the LEDBAT WG and are planning to
>> make a short presentation at the LEDBAT WG and the ICCRG.
>> We are looking forward to all your comments.
>> <http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00 
>> >http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00
>>
>>
>> Feedback is welcome,
>> Mayutan Arumaithurai
>
>
>
>
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> _______________________________________________
> ledbat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ledbat

From: [email-masked] (Bob Briscoe)
Date: Sun Mar 21 01:51:06 2010
Subject: [Iccrg] #1/2 draft-mayutan-ledbat-congestionarchitecture-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <"ess3.cs.uc.630:21.02.10.01.42.31"@cs.ucl.ac.uk>

Mayutan, Xiaoming, KK,

It seems a good idea to try to decompose the sub-functions of CC. I 
suspect this is best kept to the CC design process though (primarily 
ICCRG). Rather than an organising principle for standardisation as 
well (as suggested in the draft).

So I'll split my thoughts into 2 mails:
#1 (this one) Applicability of the decomposition: design, or standards too?
#2 (next) thoughts on the decomposition itself

Sub-questions to help determine whether we should decompose CC standards:

Q1. Are we likely to need lots of different scavenger CCs, or are we 
more likely to be refining and improving a single track of 
progressively more generic/graceful/cool ones?
A1. I say we probably need just one track

Q2. Does experience show that the sub-functions are cleanly 
separated, to the extent that they could be plugged together in different ways?
A2. I think the skill of designing a good congestion control is about 
how well the parts complement each other. In fact, one theme of the 
talk I'm planning for ICCRG this week is that we need to be more 
careful to think about the cross-effects of some flows in slow-start 
on others in congestion avoidance (& vv) when designing CC.

So rather than showing Fig 1 as if there is one common interface 
between the paris of modules, it's more important to show that the 
interface depends on which type of outer module is used. For instance 
"CONGESTION_DETECTED" could be a binary congestion event, or a delay 
variable, or a QS bit-rate.

Here's an example of where we've already got more modularisation than 
we should have in the TCP standards (in your I-D's terminology, the 
flow control module behaviour should depend on the which congestion 
detection module we choose):

If my window is 30x yours, and I get 40 ECN marks within one RTT and 
you get 1, I should reduce more than once within the RTT. Whereas if 
I get 40 drops in one RTT, it's more correct to only reduce once.

Reasoning: If congestion detection is by ECN not drop, it implies the 
congestion must be from AQM not tail drop. Whereas 40 drops can mean 
a whole load of synchronised tail drop, 40 ECN marks can't mean 
synchronised drop. So I should take 40 ECN marks more seriously.

Finally, another thought on applicability: This I-D isn't only 
applicable to scavenger CCs. It's clearly applicable to all CC design 
work (again primarily ICCRG).

That's not to say it can't help LEDBAT in future. LEDBAT is on the 
experimental track, so it would be fine if we learn something from 
this decomposition that can help improve LEDBAT between experimental 
and Proposed Standard stages.

Bob

At 19:40 03/03/2010, Mayutan A. wrote:

>We have submitted a new draft to the LEDBAT WG and are planning to 
>make a short presentation at the LEDBAT WG and the ICCRG.
>We are looking forward to all your comments.
><http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00>http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00
>
>
>Feedback is welcome,
>Mayutan Arumaithurai

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design  

From: [email-masked] (Apple)
Date: Wed Mar 10 16:30:09 2010
Subject: [Iccrg] {SPAM?} Your FREE 1 Year Warranty Extension! - from Apple Inc.
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20100310/ff1f0033/attachment.html
>From [email-masked]  Sun Mar 21 00:03:09 2010
From: [email-masked] (Bob Briscoe)
Date: Sun Mar 21 01:50:51 2010
Subject: [Iccrg] #2/2 draft-mayutan-ledbat-congestionarchitecture-00.txt
Message-ID: <"ess3.cs.uc.624:21.02.10.01.42.15"@cs.ucl.ac.uk>

Mayutan, Xiaoming, KK,

Mail #2 of 2: Thoughts on the decomposition itself

Bandwidth-estimation module
---------------------------
I propose it's better to think of this as a Window-overshoot-mitigation module.

i) Bandwidth is the wrong concept. A cc is looking for how much data 
it can risk setting off in flight when it's got insufficient 
information to determine a precise answer. That's a window concept 
[unit: byte], not a bandwidth concept [unit: b/s]. Take QS. The 
router thinks in terms of spare b/s. But the transport has to 
multiply that by RTT to get the initial window it should use.

ii) It's not so much about estimating the right window. It's more 
about ensuring the window is not too wrong, while trying to otherwise 
be as greedy as possible.

Flow-control module
-------------------
Unfortunately ambiguous terminology.
How about Load-response module?

Suggestions for additional functions?
------------------------------------
- Congestion signal conditioning (filtering out synchronised loss 
within a RTT, smoothing in TFRC, etc)

Finally, it needs to be stated explicitly whether this decomposition 
is meant to be all within the sender, or within the transport 
(sender-receiver-pair), or too abstract for this question to be relevant.

Bob

At 19:40 03/03/2010, Mayutan A. wrote:

>We have submitted a new draft to the LEDBAT WG and are planning to 
>make a short presentation at the LEDBAT WG and the ICCRG.
>We are looking forward to all your comments.
><http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00>http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00
>
>
>Feedback is welcome,
>Mayutan Arumaithurai

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design  

From: [email-masked] (Jerry Chu)
Date: Tue Mar  9 00:46:00 2010
Subject: [Iccrg] Re: I-D Action:draft-hkchu-tcpm-initcwnd-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

The link to the paper below has been fixed. Sorry for the delay.

Jerry

On Tue, Mar 2, 2010 at 2:50 PM, Jerry Chu <[email-masked]> wrote:

> Our first draft proposal to raise the initial congestion window was
> submitted
> a couple of days ago and is available at
>
> http://www.ietf.org/id/draft-hkchu-tcpm-initcwnd-00.txt
>
> A paper with the title "An Argument for Increasing TCP?s Initial Congestion
> Window" detailing our large scale experiments will soon be available at
>
> http://code.google.com/speed/articles/tcp_initcwnd_paper.pdf
> (The link is not there yet due to a last minute snag. Hopefully it
> will be fixed asap.)
>
> Comments are welcome.
>
> Jerry
>
>
> -----------------------------------------------------------------------------------------------------------
> From: [email-masked]
> To: [email-masked]
> Reply-to: [email-masked]
> Subject: I-D Action:draft-hkchu-tcpm-initcwnd-00.txt
> X-RSN: 1/0/935/28943/32298
> X-HREF: http://www.ietf.org/ibin/c5i?mid=6&rid=49&k1=935&k2=32298
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> Title : Increasing TCP's Initial Window
> Author(s) : J. Chu, et al.
> Filename : draft-hkchu-tcpm-initcwnd-00.txt
> Pages : 16
> Date : 2010-02-28
>
> This document proposes an increase in the permitted TCP initial
> window (IW) from between 2 and 4 segments, as specified in RFC 3390,
> to 10 segments. It discusses the motivation behind the increase, the
> advantages and disadvantages of the higher initial window, and
> presents results from several large scale experiments showing that
> the higher initial window improves the overall performance of many
> web services without risking congestion collapse. Finally, it
> outlines a list of concerns to be addressed in future tests.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hkchu-tcpm-initcwnd-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20100308/b6b234b7/attachment.html
>From [email-masked]  Tue Mar  9 19:25:29 2010
From: [email-masked] (Jerry Chu)
Date: Tue Mar  9 19:36:23 2010
Subject: [Iccrg] Re: [tcpm] I-D Action:draft-hkchu-tcpm-initcwnd-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Tue, Mar 9, 2010 at 3:34 AM, Costin Raiciu <[email-masked]> wrote:

> Hi,
>
> I've skimmed your paper hoping to see big improvements in loading  times
>
> However, the reductions in download times you find are below 10% - and this
> is the best case only a subset of traffic is increasing the initial cwnd.
>

I don't know about you, but imagine a simple change that can deliver a 10%
improvement
(in average) over ALL web traffic regardless of the response sizes (some are
much less than
10 segments), access speed,..., etc. That is A LOT to me!

But of course we'll need to carefully study and understand the possible
negative impact too.

> The experiments in 4.2 show that using Maps in the slowDC scenario can
> negatively affect the download time too for some users, by roughly the same
> amount.

Yes there will always be someone, somewhere, who will be negatively impacted
by any
change to TCP. Ultimately t's a benefit vs cost tradeoff. The negative
impact as shown in
Table 8 is limited to only 4% of the traffic in SlowDC, which is expected to
be one of the
worst performing DCs. Is it fair to write off the win from the rest of 96%
of traffic?

> When all traffic uses the initial cwnd of 10 I expect to see
> smaller improvements or even increases in download times for all web
> traffic.
>

Not sure why you expected so. Note that we strived to turn on IW=10 on the
whole DC scale
in order to measure the worse impact (when a user gets upto IW=10 bursts
from all Google
servers).

> Thus, the 10% average improvement does not seem very compelling to me.

Again the 10% is only the AVERAGE, which in the case of web search includes
a long
backend process time. The micro-level RTT saving is much larger as shown in
the table in
section 5 of the I-D.

Also don't forget to pay attention to the rest of the data in the paper
(besides the gross
average of 10% improvement). When we sliced and diced the data, many are
showing > 20%
latency improvments (Figure 5, 6, Table 6...)

> Have you tested upload speeds? As DSL uploads are 128-256Kbps, I expect
> using an initial cwnd of 10 packets will result in increased loading times
> for web uploads, for instance, in the best case. As DSL lines have buffers
> roughly of that length, causing burst of 10 packets will negatively affect
> all other ongoing connections.
>

Not sure where you get the "10 pkts" data from. My home cable modem (yes
it's faster than
DSL) seems to have many seconds of uplink buffer space). But large buffer
creates a whole
set of different problems and is being address by LEDBAT (?), 10 pkt bursts
seem to be the
least of the problems.

> So it seems to me this may be a good idea to standardize for servers, and
> not for regular hosts. And even for servers, it is hard to understand the
> effects when everybody uses this large init_cwnd.
>

Agreed about the last point. Will need help from folks on this list to
charter a plan forward.

Thanks,

Jerry

>
> Cheers,
> Costin
>
> On 9 Mar 2010, at 00:35, Jerry Chu wrote:
>
> > The link to the paper below has been fixed. Sorry for the delay.
> >
> > Jerry
> >
> > On Tue, Mar 2, 2010 at 2:50 PM, Jerry Chu <[email-masked]> wrote:
> > Our first draft proposal to raise the initial congestion window was
> submitted
> > a couple of days ago and is available at
> >
> > http://www.ietf.org/id/draft-hkchu-tcpm-initcwnd-00.txt
> >
> > A paper with the title "An Argument for Increasing TCP?s Initial
> Congestion
> > Window" detailing our large scale experiments will soon be available at
> >
> > http://code.google.com/speed/articles/tcp_initcwnd_paper.pdf
> > (The link is not there yet due to a last minute snag. Hopefully it
> > will be fixed asap.)
> >
> > Comments are welcome.
> >
> > Jerry
> >
> >
> -----------------------------------------------------------------------------------------------------------
> > From: [email-masked]
> > To: [email-masked]
> > Reply-to: [email-masked]
> > Subject: I-D Action:draft-hkchu-tcpm-initcwnd-00.txt
> > X-RSN: 1/0/935/28943/32298
> > X-HREF: http://www.ietf.org/ibin/c5i?mid=6&rid=49&k1=935&k2=32298
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >
> > Title : Increasing TCP's Initial Window
> > Author(s) : J. Chu, et al.
> > Filename : draft-hkchu-tcpm-initcwnd-00.txt
> > Pages : 16
> > Date : 2010-02-28
> >
> > This document proposes an increase in the permitted TCP initial
> > window (IW) from between 2 and 4 segments, as specified in RFC 3390,
> > to 10 segments. It discusses the motivation behind the increase, the
> > advantages and disadvantages of the higher initial window, and
> > presents results from several large scale experiments showing that
> > the higher initial window improves the overall performance of many
> > web services without risking congestion collapse. Finally, it
> > outlines a list of concerns to be addressed in future tests.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-hkchu-tcpm-initcwnd-00.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > tcpm mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tcpm
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20100309/d70be277/attachment.html
>From [email-masked]  Wed Mar 10 06:07:17 2010
From: [email-masked] (Jerry Chu)
Date: Wed Mar 10 06:18:07 2010
Subject: [Iccrg] Re: [tcpm] I-D Action:draft-hkchu-tcpm-initcwnd-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Tue, Mar 9, 2010 at 7:35 PM, rick jones <[email-masked]> wrote:
>
> On Mar 9, 2010, at 11:25 AM, Jerry Chu wrote:
>>
>> I don't know about you, but imagine a simple change that can deliver a 10%
>> improvement
>> (in average) over ALL web traffic regardless of the response sizes (some
>> are much less than
>> 10 segments), access speed,..., etc. That is A LOT to me!
>
> Indeed, 10% average improvement is impressive.
>
> Is there a way to tease-out what the "typical" cwnd becomes in both the base
> and exp cases? ?Say from those services with larger responses? Does it
> become 8*MSS? ?12*MSS etc? ?That would help show how "close to the edge" 10
> segments might be yes?

Yes it's certainly doable but one problem with most of the services is
that there are
fewer larger responses, interleaved with many smaller responses, and the vast
majority of HTTP connections don't persist long enough to allow cwnd/ssthresh to
converge in a more meaningful way.

In order to perform a more detailed analysis on some network properties, we are
thinking about instrumenting a bulk data service like Youtube to avoid the above
mentioned problem, as described in section 11.2 of the I-D. The idea
is to monitor
some key TCP parameters at various stage of a connection (and Linux kernel
already conveniently provide "TCP_INFO" socket option). But before we proceed
we like to first hear suggestions from the lists. This is because any
large scale
experiment can be very time/resource consuming. In this case we'll likely have
to set up a different logging system for Youtube, may even have to
build and deploy
a different kernel with the right instrumentation (TCP_INFO may not provide all
the info we'll need) to many thousand machines..., etc.

>
> WRT the retransmissions (table 7 in the paper), is it safe to ass-u-me that
> the increase in retransmissions means a corresponding increase in "Internet"
> bandwidth consumed to deliver the given quantity of data?

I don't see why not. (Am I missing something?)

Thanks,

Jerry

>
> rick jones
> there is no rest for the wicked, yet the virtuous have no pillows
> wisdom teeth are impacted, people and things are affected by the effects of
> events :)
>

From: [email-masked] (Mayutan A.)
Date: Thu Mar  4 10:49:14 2010
Subject: [Iccrg] New draft for review:  draft-mayutan-ledbat-congestionarchitecture-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Lisong,

Thanks a lot for your feedback. I will incorporate the changes you suggested
and submit a new version before the -01 deadline.

Thanks once again,
Mayutan

On Thu, Mar 4, 2010 at 4:00 AM, Lisong Xu <[email-masked]> wrote:

> Mayutan, Xiaoming, and K. K.,
>
> Thanks for your work. Below are some quick comments.
>
> 1. Section 3 "Design goals". There are actually 8 goals: 1, 2, ..., 8
> instead of 1, 1, ... ,7.
>
> 2. It would be better to explain what "network friendly" means.
>
> 3. It would be better to explain the difference between "TCP", "Standard
> TCP", and "network friendly TCP". Are they referring to the same TCP or
> different TCP's?
>
> Thanks
> Lisong
>
>
>
> On 3/3/2010 1:40 PM, Mayutan A. wrote:
>
>>
>> We have submitted a new draft to the LEDBAT WG and are planning to make
>> a short presentation at the LEDBAT WG and the ICCRG.
>> We are looking forward to all your comments.
>> http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00
>>
>> The basic idea is to have an architecture framework, to enable the
>> standardization of the various mechanisms of a network friendly
>> congestion control such as available bandwidth estimation, flow control
>> and congestion detection separately. This could result in pluggable
>> components that could be used in the overall congestion control
>> protocol/s. Though the draft is intended for the LEDBAT WG, it could
>> easily be extended to congestion control protocols in general.
>>
>> Abstract:
>>
>>    The Low Extra Delay Background Transport (LEDBAT) working group is
>>    considering protocols for an alternative congestion control protocol
>>    that enables a delay-insensitive networking application to minimize
>>
>>    the extra queueing delay it causes to other applications because of
>>    additional queueing at the bottleneck, when these connections
>>    carrying traffic for such applications attempt to use the available
>>    bandwidth.
>>
>>
>>
>>    This document proposes an architectural framework for LEDBAT
>>    congestion control mechanisms, based on existing work on congestion
>>    control protocols and the requirements of the LEDBAT working group.
>>
>>    The architectural framework consists of a LEDBAT-congestion control
>>    (LEDBAT-CC) suite that provides flexibility in utilizing different
>>    components for providing congestion control for transport connections
>>
>>    carrying delay-insensitive traffic.  The LEDBAT-CC suite of protocols
>>    is envisioned to support the multiple alternative mechanisms for
>>    bandwidth estimation, congestion detection and indication and end-
>>    system flow control to comprise a network friendly congestion
>>
>>    avoidance protocol.
>>
>>
>>    This document is inspired by the need to standardize the various
>>    components that constitute the network friendly congestion control
>>    protocol to avoid having to individually standardize a multitude of
>>
>>    distinct and monolithic solutions.
>>
>>
>> Feedback is welcome,
>> Mayutan Arumaithurai
>>
>>
>>
>> _______________________________________________
>> Iccrg mailing list
>> [email-masked]
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>
>
> --
> Lisong Xu, Assistant Professor
> Computer Science & Engineering
> University of Nebraska-Lincoln
> http://cse.unl.edu/~xu <http://cse.unl.edu/%7Exu>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

-- 
Mayutan Arumaithurai
0049-551-2712647 (Home number)
0049-176-20322049 (mobile number)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20100304/adeb75ec/attachment.html
>From [email-masked]  Mon Mar  8 17:28:07 2010
From: [email-masked] (Eddy,
	Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP])
Date: Mon Mar  8 17:39:35 2010
Subject: [Iccrg] IETF 77 agenda
Message-ID: <[email-masked]>

I've posted a draft agenda for the ICCRG sessions at IETF 77 here:
http://www.ietf.org/proceedings/10mar/agenda/iccrg.txt

Despite having 2 sessions, it's still a packed agenda, so I'm
planning to stay close to times allotted.  Please keep this in
mind when preparing presentations.

The mailing list has been relatively quiet for some time, so
please feel free to post background or other discussion
material which might help us to save time in presentations or
encourage discussion.

If there are revisions to timeslots, titles, etc. needed, just
let Michael and I know.

See you in Anaheim.

--
Wes Eddy
MTI Systems

From: [email-masked] (Mayutan A.)
Date: Wed Mar  3 19:55:48 2010
Subject: [Iccrg] New draft for review:  draft-mayutan-ledbat-congestionarchitecture-00.txt
Message-ID: <[email-masked]>

We have submitted a new draft to the LEDBAT WG and are planning to make a
short presentation at the LEDBAT WG and the ICCRG.
We are looking forward to all your comments.
http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00

The basic idea is to have an architecture framework, to enable the
standardization of the various mechanisms of a network friendly congestion
control such as available bandwidth estimation, flow control and congestion
detection separately. This could result in pluggable components that could
be used in the overall congestion control protocol/s. Though the draft is
intended for the LEDBAT WG, it could easily be extended to congestion
control protocols in general.

Abstract:

   The Low Extra Delay Background Transport (LEDBAT) working group is
   considering protocols for an alternative congestion control protocol
   that enables a delay-insensitive networking application to minimize
   the extra queueing delay it causes to other applications because of
   additional queueing at the bottleneck, when these connections
   carrying traffic for such applications attempt to use the available
   bandwidth.

   This document proposes an architectural framework for LEDBAT
   congestion control mechanisms, based on existing work on congestion
   control protocols and the requirements of the LEDBAT working group.
   The architectural framework consists of a LEDBAT-congestion control
   (LEDBAT-CC) suite that provides flexibility in utilizing different
   components for providing congestion control for transport connections
   carrying delay-insensitive traffic.  The LEDBAT-CC suite of protocols
   is envisioned to support the multiple alternative mechanisms for
   bandwidth estimation, congestion detection and indication and end-
   system flow control to comprise a network friendly congestion
   avoidance protocol.

   This document is inspired by the need to standardize the various
   components that constitute the network friendly congestion control
   protocol to avoid having to individually standardize a multitude of
   distinct and monolithic solutions.

Feedback is welcome,
Mayutan Arumaithurai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20100303/ca3f058d/attachment.html
>From [email-masked]  Thu Mar  4 03:00:48 2010
From: [email-masked] (Lisong Xu)
Date: Thu Mar  4 03:12:37 2010
Subject: [Iccrg] New draft for review: 
	draft-mayutan-ledbat-congestionarchitecture-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Mayutan, Xiaoming, and K. K.,

Thanks for your work. Below are some quick comments.

1. Section 3 "Design goals". There are actually 8 goals: 1, 2, ..., 8 
instead of 1, 1, ... ,7.

2. It would be better to explain what "network friendly" means.

3. It would be better to explain the difference between "TCP", "Standard 
TCP", and "network friendly TCP". Are they referring to the same TCP or 
different TCP's?

Thanks
Lisong

On 3/3/2010 1:40 PM, Mayutan A. wrote:
>
> We have submitted a new draft to the LEDBAT WG and are planning to make
> a short presentation at the LEDBAT WG and the ICCRG.
> We are looking forward to all your comments.
> http://tools.ietf.org/html/draft-mayutan-ledbat-congestionarchitecture-00
>
> The basic idea is to have an architecture framework, to enable the
> standardization of the various mechanisms of a network friendly
> congestion control such as available bandwidth estimation, flow control
> and congestion detection separately. This could result in pluggable
> components that could be used in the overall congestion control
> protocol/s. Though the draft is intended for the LEDBAT WG, it could
> easily be extended to congestion control protocols in general.
>
> Abstract:
>
>     The Low Extra Delay Background Transport (LEDBAT) working group is
>     considering protocols for an alternative congestion control protocol
>     that enables a delay-insensitive networking application to minimize
>
>     the extra queueing delay it causes to other applications because of
>     additional queueing at the bottleneck, when these connections
>     carrying traffic for such applications attempt to use the available
>     bandwidth.
>
>
>
>     This document proposes an architectural framework for LEDBAT
>     congestion control mechanisms, based on existing work on congestion
>     control protocols and the requirements of the LEDBAT working group.
>
>     The architectural framework consists of a LEDBAT-congestion control
>     (LEDBAT-CC) suite that provides flexibility in utilizing different
>     components for providing congestion control for transport connections
>
>     carrying delay-insensitive traffic.  The LEDBAT-CC suite of protocols
>     is envisioned to support the multiple alternative mechanisms for
>     bandwidth estimation, congestion detection and indication and end-
>     system flow control to comprise a network friendly congestion
>
>     avoidance protocol.
>
>
>     This document is inspired by the need to standardize the various
>     components that constitute the network friendly congestion control
>     protocol to avoid having to individually standardize a multitude of
>
>     distinct and monolithic solutions.
>
>
> Feedback is welcome,
> Mayutan Arumaithurai
>
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

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

From: [email-masked] (Jerry Chu)
Date: Tue Mar  2 23:02:37 2010
Subject: [Iccrg] I-D Action:draft-hkchu-tcpm-initcwnd-00.txt
Message-ID: <[email-masked]>

Our first draft proposal to raise the initial congestion window was submitted
a couple of days ago and is available at

http://www.ietf.org/id/draft-hkchu-tcpm-initcwnd-00.txt

A paper with the title "An Argument for Increasing TCP?s Initial Congestion
Window" detailing our large scale experiments will soon be available at

http://code.google.com/speed/articles/tcp_initcwnd_paper.pdf
(The link is not there yet due to a last minute snag. Hopefully it
will be fixed asap.)

Comments are welcome.

Jerry

-----------------------------------------------------------------------------------------------------------
From: [email-masked]
To: [email-masked]
Reply-to: [email-masked]
Subject: I-D Action:draft-hkchu-tcpm-initcwnd-00.txt
X-RSN: 1/0/935/28943/32298
X-HREF: http://www.ietf.org/ibin/c5i?mid=6&rid=49&k1=935&k2=32298

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title : Increasing TCP's Initial Window
Author(s) : J. Chu, et al.
Filename : draft-hkchu-tcpm-initcwnd-00.txt
Pages : 16
Date : 2010-02-28

This document proposes an increase in the permitted TCP initial
window (IW) from between 2 and 4 segments, as specified in RFC 3390,
to 10 segments. It discusses the motivation behind the increase, the
advantages and disadvantages of the higher initial window, and
presents results from several large scale experiments showing that
the higher initial window improves the overall performance of many
web services without risking congestion collapse. Finally, it
outlines a list of concerns to be addressed in future tests.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hkchu-tcpm-initcwnd-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/