[Bloat] I feel an urge to update this

[Bloat] I feel an urge to update this

[Dave Taht]

http://tools.ietf.org/html/draft-gettys-iw10-considered-harmful-00

I just got some iw10 results on a t1 line... ugh. anyone want a stab at it?

-- 
Dave Täht

https://www.bufferbloat.net/projects/make-wifi-fast

Re: [Bloat] I feel an urge to update this

[Steinar H. Gunderson]

On Sat, Sep 20, 2014 at 02:33:06AM +0300, Dave Taht wrote:
> http://tools.ietf.org/html/draft-gettys-iw10-considered-harmful-00

The pedant in me wants to point out that 4 -> 10 is not “2.5 times worse”,
but “2.5 times as bad” or “1.5 times worse” (just as 4 -> 5 is “20% worse”,
“0.2 times worse” or “1.2 times as bad”).

:-)

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: [Bloat] I feel an urge to update this

[Jonathan Morton]

On 20 Sep, 2014, at 12:03 pm, Steinar H. Gunderson wrote:

> On Sat, Sep 20, 2014 at 02:33:06AM +0300, Dave Taht wrote:
>> http://tools.ietf.org/html/draft-gettys-iw10-considered-harmful-00
> 
> The pedant in me wants to point out that 4 -> 10 is not “2.5 times worse”,
> but “2.5 times as bad” or “1.5 times worse” (just as 4 -> 5 is “20% worse”,
> “0.2 times worse” or “1.2 times as bad”).

ISTR seeing some concrete test data showing that IW10 doesn't even work as designed, unless TCP pacing of some type is used to spread out the burst.  That's *despite* bloated buffers.  Really puts the nail in the coffin, if you ask me.

The recent work on SQM could be added to the list of mitigation measures.  Also, by keeping inter-flow latency low, it greatly reduces the original motivation for IW10 in the first place.

 - Jonathan Morton

Re: [Bloat] I feel an urge to update this

[Michael Welzl]

fwiw:  http://tools.ietf.org/id/draft-sallantin-iccrg-initial-spreading-01.txt

Sent from my iPhone

> On 20. sep. 2014, at 17:55, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
> 
>> On 20 Sep, 2014, at 12:03 pm, Steinar H. Gunderson wrote:
>> 
>>> On Sat, Sep 20, 2014 at 02:33:06AM +0300, Dave Taht wrote:
>>> http://tools.ietf.org/html/draft-gettys-iw10-considered-harmful-00
>> 
>> The pedant in me wants to point out that 4 -> 10 is not “2.5 times worse”,
>> but “2.5 times as bad” or “1.5 times worse” (just as 4 -> 5 is “20% worse”,
>> “0.2 times worse” or “1.2 times as bad”).
> 
> ISTR seeing some concrete test data showing that IW10 doesn't even work as designed, unless TCP pacing of some type is used to spread out the burst.  That's *despite* bloated buffers.  Really puts the nail in the coffin, if you ask me.
> 
> The recent work on SQM could be added to the list of mitigation measures.  Also, by keeping inter-flow latency low, it greatly reduces the original motivation for IW10 in the first place.
> 
> - Jonathan Morton
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] I feel an urge to update this

[Mikael Abrahamsson]

On Sat, 20 Sep 2014, Dave Taht wrote:

> http://tools.ietf.org/html/draft-gettys-iw10-considered-harmful-00
>
> I just got some iw10 results on a t1 line... ugh. anyone want a stab at it?

Is it at all possible to create a solution that works well for all cases?

I pitched a proposal at IETF75 and then again a year ago in TCP/TCPM WGs 
that it might be good if the connection manager could hint the TCP stack, 
or the TCP stack could determine itself by heuristics, that its network 
connection were of a few different degrees of a few criteria which might 
be speed, loss, jitter etc. I perhaps even could tell my connection 
manager that when connected to my home wired or wifi network, "everything" 
is reachable via 50 + megabit/s connectivity. If I then speak to a 10GE 
connected server, there should be no problem for it to do IW10. Basically, 
my thinking is to have something similar to "MSS" but when it comes to 
connectivity.

There was no interest anywhere in this, everybody wanted for each 
connection to be living in its own universe with little prior knowledge 
about what's been going on before it.

I just don't see how we can make things work well when we try to create 
TCP to handle everything from 1500ms to 0.1ms of RTT, and everything from 
19200bps to 100GE in speed.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: [Bloat] I feel an urge to update this

[Jonathan Morton]

On 23 Sep, 2014, at 8:48 am, Mikael Abrahamsson wrote:

> I just don't see how we can make things work well when we try to create TCP to handle everything from 1500ms to 0.1ms of RTT, and everything from 19200bps to 100GE in speed.

Move that lower bound down to 2400bps.  People are still using Iridium!

	http://www.revk.uk/2014/09/back-to-future-i-mean-past.html

 - Jonathan Morton

Re: [Bloat] I feel an urge to update this

[David Lang]

On Tue, 23 Sep 2014, Mikael Abrahamsson wrote:

> On Sat, 20 Sep 2014, Dave Taht wrote:
>
>> http://tools.ietf.org/html/draft-gettys-iw10-considered-harmful-00
>> 
>> I just got some iw10 results on a t1 line... ugh. anyone want a stab at it?
>
> Is it at all possible to create a solution that works well for all cases?
>
> I pitched a proposal at IETF75 and then again a year ago in TCP/TCPM WGs that 
> it might be good if the connection manager could hint the TCP stack, or the 
> TCP stack could determine itself by heuristics, that its network connection 
> were of a few different degrees of a few criteria which might be speed, loss, 
> jitter etc. I perhaps even could tell my connection manager that when 
> connected to my home wired or wifi network, "everything" is reachable via 50 
> + megabit/s connectivity. If I then speak to a 10GE connected server, there 
> should be no problem for it to do IW10. Basically, my thinking is to have 
> something similar to "MSS" but when it comes to connectivity.
>
> There was no interest anywhere in this, everybody wanted for each connection 
> to be living in its own universe with little prior knowledge about what's 
> been going on before it.

The problem is that you don't know what the connectivity is going to be. (unless 
you are connecting to the same IP as an existing connection). Your first few 
hops are fairly predictable, but after that you have no idea if you are going to 
be connecting to a server on a low bandwidth link, one behind a very congested 
router, or one with better connectivity than you have.

> I just don't see how we can make things work well when we try to create TCP 
> to handle everything from 1500ms to 0.1ms of RTT, and everything from 
> 19200bps to 100GE in speed.

Actually, at this point, we know exactly what would need to be done to make TCP 
work across this entire range (as long as the connection speed doesn't vary too 
rapidly), the problem is getting the hardware manufacturers on board to actually 
deploy it.

using fq_codel on every bottleneck link will make TCP work pretty well across 
that entire range of connectivity

David Lang

Re: [Bloat] I feel an urge to update this

[Mikael Abrahamsson]

On Wed, 24 Sep 2014, David Lang wrote:

> The problem is that you don't know what the connectivity is going to be. 
> (unless you are connecting to the same IP as an existing connection). 
> Your first few hops are fairly predictable, but after that you have no 
> idea if you are going to be connecting to a server on a low bandwidth 
> link, one behind a very congested router, or one with better 
> connectivity than you have.

I am not saying that we *know*, but we might have a pretty good idea. 
Better than to do the same thing regardless of circumstances. If I know my 
home connection is 250/50 megabit/s, then there is no reason to treat it 
like a 0.1 megabit/s connection or a 10GE connection.

> using fq_codel on every bottleneck link will make TCP work pretty well 
> across that entire range of connectivity

Well, that'll fix one thing, but for instance the IW4 and IW10 debate. I'm 
sure IW10 works *great* on a 100/100 megabit/s connection when the server 
is 10GE connected, but it's less than optimal for a 0.1 megabit/s 
connection.

So why can't the client hint the server that, hmm, I seem to be on a 
fairly slow connection here, don't send me too much at once? Or it can 
hint that hey, it seems most times I get pretty large TCP window sizes, so 
it's ok to start with IW10?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: [Bloat] I feel an urge to update this

[David Lang]

On Thu, 25 Sep 2014, Mikael Abrahamsson wrote:

> On Wed, 24 Sep 2014, David Lang wrote:
>
>> The problem is that you don't know what the connectivity is going to be. 
>> (unless you are connecting to the same IP as an existing connection). Your 
>> first few hops are fairly predictable, but after that you have no idea if 
>> you are going to be connecting to a server on a low bandwidth link, one 
>> behind a very congested router, or one with better connectivity than you 
>> have.
>
> I am not saying that we *know*, but we might have a pretty good idea. Better 
> than to do the same thing regardless of circumstances. If I know my home 
> connection is 250/50 megabit/s, then there is no reason to treat it like a 
> 0.1 megabit/s connection or a 10GE connection.

well, even if you have a 10GE connection, you don't know how heavily it's going 
to be used.

>> using fq_codel on every bottleneck link will make TCP work pretty well 
>> across that entire range of connectivity
>
> Well, that'll fix one thing, but for instance the IW4 and IW10 debate. I'm 
> sure IW10 works *great* on a 100/100 megabit/s connection when the server is 
> 10GE connected, but it's less than optimal for a 0.1 megabit/s connection.
>
> So why can't the client hint the server that, hmm, I seem to be on a fairly 
> slow connection here, don't send me too much at once? Or it can hint that 
> hey, it seems most times I get pretty large TCP window sizes, so it's ok to 
> start with IW10?

what happens if the wrong hint is given? (either accidently or maliciously)

The approach of starting slow and ramping up works well, except in the case 
where you have lots of very short connections. So I don't see a benefit of 
trying to hint slowness. There may be some value in hinting for faster ramp-ups, 
but what will that do to fairness with existing systems?

My knee-jerk reaction is that this adds a lot of new failure modes without a 
significant benefit.

But we have a number of companies who want to have things downloaded and used as 
quickly as possible, so if this sort of thing really does help, then I would 
expect that they would be experimenting with tweaking the TCP stack to ramp up 
faster (although, you would also be expecting outcrys about "how dare 
$bigcompany ignore the TCP defaults and be more agressive, that doesn't compete 
fairly with $normaltraffic)

David Lang

Re: [Bloat] I feel an urge to update this

[Mikael Abrahamsson]

On Thu, 25 Sep 2014, David Lang wrote:

> well, even if you have a 10GE connection, you don't know how heavily 
> it's going to be used.

No, but I will have a hunch. I don't need to *know*, I need to have a 
decent probability of being right.

> what happens if the wrong hint is given? (either accidently or maliciously)

Then you get IW10 instead of IW4. Right now if I am correct, Google does 
IW10 all across the board.

> The approach of starting slow and ramping up works well, except in the 
> case where you have lots of very short connections. So I don't see a 
> benefit of trying to hint slowness. There may be some value in hinting 
> for faster ramp-ups, but what will that do to fairness with existing 
> systems?

In my world, core network congestion isn't something that is permanent and 
continous, but an anomaly. So since the only port that should be 
congesting is my access port, I don't care about fairness. Also, we're not 
talking about starting off with a 1M TCP window to blast a huge chunk of 
data down the wire, we're talking about perhaps being a bit more agressive 
in increasing the window from a slightly higher initial level, let's say 
IW10 and instead of doubling, tripling window size, if the client hints 
they have a fast connection, and if the client says they have a slow 
connection, IW4 and increase 1.5x instead?

Use same mechanisms as today, but tweak them to be a bit more or less 
agressive depending on what the client has hinted.

I mean, why do we send MSS in TCP? Couldn't we just have a generic probing 
mechanism to test what MTU works? Well, that would be inefficient, so MSS 
helps. Same here.

> But we have a number of companies who want to have things downloaded and 
> used as quickly as possible, so if this sort of thing really does help, 
> then I would expect that they would be experimenting with tweaking the 
> TCP stack to ramp up faster (although, you would also be expecting 
> outcrys about "how dare $bigcompany ignore the TCP defaults and be more 
> agressive, that doesn't compete fairly with $normaltraffic)

Errr, google and IW10? So, already done!?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: [Bloat] I feel an urge to update this

[David Lang]

On Thu, 25 Sep 2014, Mikael Abrahamsson wrote:

> On Thu, 25 Sep 2014, David Lang wrote:
>
>> well, even if you have a 10GE connection, you don't know how heavily it's 
>> going to be used.
>
> No, but I will have a hunch. I don't need to *know*, I need to have a decent 
> probability of being right.
>
>> what happens if the wrong hint is given? (either accidently or maliciously)
>
> Then you get IW10 instead of IW4. Right now if I am correct, Google does IW10 
> all across the board.

What is the problem with making this assumption? Why should we try to change 
every device on the Internet to provide this information instead of just using 
this as the default?

>> The approach of starting slow and ramping up works well, except in the case 
>> where you have lots of very short connections. So I don't see a benefit of 
>> trying to hint slowness. There may be some value in hinting for faster 
>> ramp-ups, but what will that do to fairness with existing systems?
>
> In my world, core network congestion isn't something that is permanent and 
> continous, but an anomaly. So since the only port that should be congesting 
> is my access port, I don't care about fairness.

Well, you are asking for the entire Internet to be changed, so your proposal 
needs to account for the rest of the Internet outside of your world. And there 
we do have to worry about fairness.

David Lang

Re: [Bloat] I feel an urge to update this

[Mikael Abrahamsson]

On Thu, 25 Sep 2014, David Lang wrote:

> What is the problem with making this assumption? Why should we try to 
> change every device on the Internet to provide this information instead 
> of just using this as the default?

Read the email that started this thread.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: [Bloat] I feel an urge to update this

[Dave Taht]

On Thu, Sep 25, 2014 at 6:00 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> On Thu, 25 Sep 2014, David Lang wrote:
>
>> What is the problem with making this assumption? Why should we try to
>> change every device on the Internet to provide this information instead of
>> just using this as the default?
>
> Read the email that started this thread.

One saving grace of the IW10 deployment so far is that it is (mostly)
limited to Linux, and that methods, such as pacing/initial
spreading/fq, to cope with it better, are developing concurrently.

It's not all bad - on GigE ethernet networks, it's ok, IW10 may well
be useful in wifi packet aggregation, etc, but it does do potentially
a great deal of damage to networks running at very low rates. My
concern has largely been the collateral damage it causes network
uploads from the edge, where vastly lower rates are common.

It could be mitigated further in a desktop deployment by (for example)
sticking with IW4 for everything going out a default gateway, and
steps taken to make sure applications like bittorrent/transmission
used a lower default. I have no idea what the IW is for android, but
that should perhaps be lower also. I think ledbat shouldn't have an IW
at all....

I would not mind if IW information was carried as a payload in dhcp/hnetd/etc...

I have no problem with people suggesting changes here that require
"changing the entire internet". We seem to have done that a couple
times, already. :) It would be nice if we could calculate the damage
it causes along whatever portion of the internet is running at below
10Mbit....

A simple question - how many T1 lines are left in the world?



> --
> Mikael Abrahamsson    email: swmike@swm.pp.se



-- 
Dave Täht

https://www.bufferbloat.net/projects/make-wifi-fast

Re: [Bloat] I feel an urge to update this

[Mikael Abrahamsson]

On Thu, 25 Sep 2014, Dave Taht wrote:

> A simple question - how many T1 lines are left in the world?

If you change the question to "how many people are behind links that are 
or will be at 1.5 megabit/s or slower" I'd say billions. Some are behind 
GSM/EDGE networks, some are on very slow ADSL lines etc.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: [Bloat] I feel an urge to update this

[Rick Jones]

>> using fq_codel on every bottleneck link will make TCP work pretty well
>> across that entire range of connectivity
>
> Well, that'll fix one thing, but for instance the IW4 and IW10 debate.
> I'm sure IW10 works *great* on a 100/100 megabit/s connection when the
> server is 10GE connected, but it's less than optimal for a 0.1 megabit/s
> connection.
>
> So why can't the client hint the server that, hmm, I seem to be on a
> fairly slow connection here, don't send me too much at once? Or it can
> hint that hey, it seems most times I get pretty large TCP window sizes,
> so it's ok to start with IW10?

Well, there has been such a thing present in TCP from "The Beginning" 
though not named as such.  Such a client could always advertise a 
smaller (initial) receive window...  One which would allow only IW3 or 
whatever value was appropriate.

rick jones

Re: [Bloat] I feel an urge to update this

[Mikael Abrahamsson]

On Thu, 25 Sep 2014, Rick Jones wrote:

> Well, there has been such a thing present in TCP from "The Beginning" 
> though not named as such.  Such a client could always advertise a 
> smaller (initial) receive window...  One which would allow only IW3 or 
> whatever value was appropriate.

I'm sure there are ways to solve this, but my take from the "TCP people" 
was that there was not seen to be any need to do anything else than what 
is done today, ie all TCP connections are self contained and learns 
nothing from each other.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: [Bloat] I feel an urge to update this

[Rick Jones]

On 09/25/2014 10:26 AM, Mikael Abrahamsson wrote:
> On Thu, 25 Sep 2014, Rick Jones wrote:
>
>> Well, there has been such a thing present in TCP from "The Beginning"
>> though not named as such.  Such a client could always advertise a
>> smaller (initial) receive window...  One which would allow only IW3 or
>> whatever value was appropriate.
>
> I'm sure there are ways to solve this, but my take from the "TCP people"
> was that there was not seen to be any need to do anything else than what
> is done today, ie all TCP connections are self contained and learns
> nothing from each other.

Well, I cannot speak for "TCP people" but I would think that what a 
given TCP connection decides to advertise as its receive window, and 
whether that decision would need/must depend on what other TCP 
connections have seen are separate, but related.

The main point I wished to make was if one did indeed wish to have a 
receiver behind a slow pipe wish to be able to keep a sender up on a 
fast pipe from actually doing IW10, there was no need for any new signal 
flowing from one end to the other, just setting the receive window 
appropriately.  The TCP stack on the slow-connection device could (and 
perhaps should) be configured for things like (initial) receive windows 
with that in mind.

rick jones

Re: [Bloat] I feel an urge to update this

[Manolis Sifalakis]

A couple of remarks to try and contribute to this discussion, one 
philosophical and one engineering.

The philosophical first. There is a presentation taking place in a room 
and it is possibly at q&a phase. You have several ppl entering the room 
at several time points. What if every person entering the room, 
immediately throws aggressively questions without even having spent time 
to listen and understand the context of presentation and discussion. 
Imagine this happening again and again. Consider what are the chances 
that a meaningful communication and discussion will take place...  or 
simply how would you like that as a person in the audience?

The more technical next. Doubling and tripling IW for short lived 
sessions (each of which will attain --only-- exponential growth in its 
anyway short lifetime) means that a large number of high-freq transient 
components will be added to and removed from the signal that the AQM 
sees (and tries to adapt to). Is that something desired ? Will it 
improve or worsen the way an AQM adapts?  Increasing IW is not only a 
matter of initial value, it also affects the starting growth rate (since 
the relation is not linear).

Manos


On 25/09/14 19:49, Rick Jones wrote:
> On 09/25/2014 10:26 AM, Mikael Abrahamsson wrote:
>> On Thu, 25 Sep 2014, Rick Jones wrote:
>>
>>> Well, there has been such a thing present in TCP from "The Beginning"
>>> though not named as such.  Such a client could always advertise a
>>> smaller (initial) receive window...  One which would allow only IW3 or
>>> whatever value was appropriate.
>>
>> I'm sure there are ways to solve this, but my take from the "TCP people"
>> was that there was not seen to be any need to do anything else than what
>> is done today, ie all TCP connections are self contained and learns
>> nothing from each other.
>
> Well, I cannot speak for "TCP people" but I would think that what a
> given TCP connection decides to advertise as its receive window, and
> whether that decision would need/must depend on what other TCP
> connections have seen are separate, but related.
>
> The main point I wished to make was if one did indeed wish to have a
> receiver behind a slow pipe wish to be able to keep a sender up on a
> fast pipe from actually doing IW10, there was no need for any new signal
> flowing from one end to the other, just setting the receive window
> appropriately.  The TCP stack on the slow-connection device could (and
> perhaps should) be configured for things like (initial) receive windows
> with that in mind.
>
> rick jones
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] I feel an urge to update this

[Rick Jones]

On 09/27/2014 01:59 AM, Manolis Sifalakis wrote:
> A couple of remarks to try and contribute to this discussion, one
> philosophical and one engineering.
>
> The philosophical first. There is a presentation taking place in a room
> and it is possibly at q&a phase. You have several ppl entering the room
> at several time points. What if every person entering the room,
> immediately throws aggressively questions without even having spent time
> to listen and understand the context of presentation and discussion.
> Imagine this happening again and again. Consider what are the chances
> that a meaningful communication and discussion will take place...  or
> simply how would you like that as a person in the audience?

I believe I see where you are going, but the analogy is missing one key 
piece.  That is that before entering the room, each person must make a 
request to enter (send a TCP SYN), which must be acknowledged by the 
presenter (SYN|ACK).  When the presenter gives each person permission to 
enter, she also tells them how many questions they may ask, in the form 
of the value for the (initial) TCP receive window in the SYN|ACK.

When the presenter knows she has a number of questions already 
outstanding, and/or she knows that the questions will be arriving 
through a small pipe, she can tell each person entering the room they 
may ask only a small number of questions.

> The more technical next. Doubling and tripling IW for short lived
> sessions (each of which will attain --only-- exponential growth in its
> anyway short lifetime) means that a large number of high-freq transient
> components will be added to and removed from the signal that the AQM
> sees (and tries to adapt to). Is that something desired ? Will it
> improve or worsen the way an AQM adapts?  Increasing IW is not only a
> matter of initial value, it also affects the starting growth rate (since
> the relation is not linear).

I have a sneaking suspicion "we" (the collective group of folks working 
on "the internet" as it were) went through a similar debate over IW3 
versus IW1.  And ten years from now we will probably have a similar 
debate over IW30 versus IW10 :)

My understanding was the concern put forth was that a slow receiver 
might be overwhelmed by communicating with a well-connected sender using 
IW10.  And someone suggested there should be a signal the slow receiver 
could send to the well-connected sender that said "Don't do IW10."  All 
I am saying is that if we do indeed have a slow receiver, it already has 
such a "signal" - the TCP receive window.  Even if the well-connected 
sender was using IW1000, it must still love, honor and respect the 
classic TCP receive window.

How well an AQM will like or adapt to a bunch of loud-mouth mice versus 
a soft-spoken elephant I do not pretend to know.  But while I have a 
soft spot for some quixotic things - for example, the (IMO) mis-use of 
impact and impacted :) and will complain about other things unlikely 
ever to change (for example, the Linux TCP stack's seeming willingness 
to go "Grow the receive window huge and let congestion control sort it 
out." I really, really doubt the IW10 genie is ever going back into the 
bottle.  I'm also not really all that upset with IW10 in the first 
place, but then I was one who thought that counting the ACK of the SYN 
or SYN|ACK when growing the congestion window was fine.

rick jones

>
> Manos
>
>
> On 25/09/14 19:49, Rick Jones wrote:
>> On 09/25/2014 10:26 AM, Mikael Abrahamsson wrote:
>>> On Thu, 25 Sep 2014, Rick Jones wrote:
>>>
>>>> Well, there has been such a thing present in TCP from "The Beginning"
>>>> though not named as such.  Such a client could always advertise a
>>>> smaller (initial) receive window...  One which would allow only IW3 or
>>>> whatever value was appropriate.
>>>
>>> I'm sure there are ways to solve this, but my take from the "TCP people"
>>> was that there was not seen to be any need to do anything else than what
>>> is done today, ie all TCP connections are self contained and learns
>>> nothing from each other.
>>
>> Well, I cannot speak for "TCP people" but I would think that what a
>> given TCP connection decides to advertise as its receive window, and
>> whether that decision would need/must depend on what other TCP
>> connections have seen are separate, but related.
>>
>> The main point I wished to make was if one did indeed wish to have a
>> receiver behind a slow pipe wish to be able to keep a sender up on a
>> fast pipe from actually doing IW10, there was no need for any new signal
>> flowing from one end to the other, just setting the receive window
>> appropriately.  The TCP stack on the slow-connection device could (and
>> perhaps should) be configured for things like (initial) receive windows
>> with that in mind.
>>
>> rick jones
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] I feel an urge to update this

[Manolis Sifalakis]

Hi Rick,

On 29/09/14 19:28, Rick Jones wrote:
> On 09/27/2014 01:59 AM, Manolis Sifalakis wrote:
>> A couple of remarks to try and contribute to this discussion, one
>> philosophical and one engineering.
>>
>> The philosophical first. There is a presentation taking place in a room
>> and it is possibly at q&a phase. You have several ppl entering the room
>> at several time points. What if every person entering the room,
>> immediately throws aggressively questions without even having spent time
>> to listen and understand the context of presentation and discussion.
>> Imagine this happening again and again. Consider what are the chances
>> that a meaningful communication and discussion will take place...  or
>> simply how would you like that as a person in the audience?
>
> I believe I see where you are going, but the analogy is missing one key
> piece.  That is that before entering the room, each person must make a
> request to enter (send a TCP SYN), which must be acknowledged by the
> presenter (SYN|ACK).  When the presenter gives each person permission to
> enter, she also tells them how many questions they may ask, in the form
> of the value for the (initial) TCP receive window in the SYN|ACK.
>
> When the presenter knows she has a number of questions already
> outstanding, and/or she knows that the questions will be arriving
> through a small pipe, she can tell each person entering the room they
> may ask only a small number of questions.
>

Fair enough. Particularly when it comes to the control the receiver side 
can exert.

On second thought however..., the recv window is intended to set an 
upper bound (cap) to an otherwise nominally well behaving sender, and 
not to regulate the aggressiveness of the sender (init wnd and rate of 
growth). The two are similar but not the same. I m not sure about the 
effects of managing them in tandem, since setting the cap will not 
necessarily resolve the effects of aggressive behaviour.

>> The more technical next. Doubling and tripling IW for short lived
>> sessions (each of which will attain --only-- exponential growth in its
>> anyway short lifetime) means that a large number of high-freq transient
>> components will be added to and removed from the signal that the AQM
>> sees (and tries to adapt to). Is that something desired ? Will it
>> improve or worsen the way an AQM adapts?  Increasing IW is not only a
>> matter of initial value, it also affects the starting growth rate (since
>> the relation is not linear).
>
> I have a sneaking suspicion "we" (the collective group of folks working
> on "the internet" as it were) went through a similar debate over IW3
> versus IW1.  And ten years from now we will probably have a similar
> debate over IW30 versus IW10 :)
>

possibly! .. and it is habitual for the older to be more conservative ;)

> My understanding was the concern put forth was that a slow receiver
> might be overwhelmed by communicating with a well-connected sender using
> IW10.  And someone suggested there should be a signal the slow receiver
> could send to the well-connected sender that said "Don't do IW10."  All
> I am saying is that if we do indeed have a slow receiver, it already has
> such a "signal" - the TCP receive window.  Even if the well-connected
> sender was using IW1000, it must still love, honor and respect the
> classic TCP receive window.
>

I see your point.. and the effect you advocate.

I m just not convinced of the philosophy "Let em be aggressive, we can 
always call police *after* should there be need". This can have 
side-effects that "police" may not be effectively addressing (for 
en-path queueing par example).

> How well an AQM will like or adapt to a bunch of loud-mouth mice versus
> a soft-spoken elephant I do not pretend to know.  But while I have a
> soft spot for some quixotic things - for example, the (IMO) mis-use of
> impact and impacted :) and will complain about other things unlikely
> ever to change (for example, the Linux TCP stack's seeming willingness
> to go "Grow the receive window huge and let congestion control sort it
> out." I really, really doubt the IW10 genie is ever going back into the
> bottle.  I'm also not really all that upset with IW10 in the first
> place, but then I was one who thought that counting the ACK of the SYN
> or SYN|ACK when growing the congestion window was fine.
>
> rick jones
>

M.