[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.