Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt

Hi all,

     Sorry for duplicate e-mail.

     Inline comments.

On ୨୧-୧୦-୧୪ PM 03:19, Hagen Paul Pfeifer wrote:
> On 20 October 2014 21:19, Michael Welzl <michawe@ifi.uio.no> wrote:
>> Hi Hagen,
> Hi Michael
>
>> what if 10 is used as a default (like now) and an upper limit?
> I am not a friend of any static stack global or user configured IW -
> let me explain this.
>
> Consider the IW as a function of time (2014: 10, 2015: 12, ...). Say
> that the IW should increase "savely" over the years. But the IW has
> nothing to do with time! It has something to do with available
> bandwidth (and delay, but skip this for now). The problem is that the
> bandwidth do not increase over time for *all links*.
There was a 
proposal,http://tools.ietf.org/html/draft-allman-tcpm-bump-initcwnd-00;
in this, IW can be set over time. And the reason considers network 
safety, and
performance improvement  due to an increase in network capacity.
I believe IW value depends on available bandwidth; it also depends
more on flow characteristics in the Internet what I observed in my work 
during master thesis.
Large flows (flows with large in data-size) stay for a long time in the 
Internet;
however, small flows want to leave the Internet as soon as possible.
Why not to give them chance to finish early. Moreover, we observed small 
flows get
more benefit compared to large flows, having  a larger IW. This makes IW 
dependent
on flow characteristics. It may be, the available bandwidth is enough to 
accommodate for such change.
Till now, I did not consider network-state in relation to setting IW, 
but we need to consider.

> The bandwidth is
> not equal everywhere to every time for everyone. There are links out
> there with path characteristics from 1990 and older - but the clients
> use modern operating systems and we must make sure that TCP will
> operate in this environment too.
>
> I participate at the Freifunk Mesh in Munich [1]. A mesh network
> providing internet connectivity for the masses. Often the link quality
> is really bad with a lot of MAC layer retransmissions resulting in low
> bandwidth. But people _use_ Freifunk with their Browsers -> modern TCP
> on "classic wifi links".
>
> Now assume a setsockopt() IW of 50 - this will lead to congested
> queues, dropped packets and interflow fairness problems and probably
> non-operative links because the application will re-send packets again
> and gain. Question: what is the right IW for a given application? ->
> it is not application specific - it is link specific!
>
> But we have already a solution to this: the TCP Control Block (RFC
> 2140) (to mention the author of the RFC: Joe Touch! ;)!
>
> The control block is already implemented in Linux network stack and
> cache CW parameters (amongst other things). This is a far better
> approach because it starts conservative in the initial probing phase
> (3/4 segments as specific) and memorize window parameters on a path
> basis (yes, another IW misbelieve: the available bandwidth (IW) is not
> a global value, it change over path and time characteristics). This
> automated approach is the best you can get for your money - there is
> not need for static defines in your kernel. And yes, Joe's I-D might
> be a good starting point to even tune the IW even more.
>
> Last week I met Jerry Chu (the author of IW10) at the LPC14 and he
> told me that some guys start pushing on IW10 - I was hoping that this
> happens not so immediately! ;-)
>
> Hagen
>
>
> [1] https://en.wikipedia.org/wiki/Freifunk
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
All I say, a constant IW may not be a good option. If we can
understand the network during the handshaking, we can get better 
performance.

Regards,
- Runa Barik