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

Hi all,

     Inline comments,
________________________________________
From: tcpm <tcpm-bounces@ietf.org> on behalf of Hagen Paul Pfeifer <hagen@jauu.net>
Sent: Tuesday, October 21, 2014 3:19 PM
To: Michael Welzl; Joe Touch
Cc: tcpm@ietf.org
Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt

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

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
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm