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

[Michael Welzl <[e-mail]>]

Hi all,

In line -

> On 21. okt. 2014, at 16.12, Runa Barik <[e-mail]> wrote:
> 
> Hi all,
> 
>      Inline comments,
> ________________________________________
> From: tcpm <[e-mail]> on behalf of Hagen Paul Pfeifer <[e-mail]>
> Sent: Tuesday, October 21, 2014 3:19 PM
> To: Michael Welzl; Joe Touch
> Cc: [e-mail]
> Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt
> 
> On 20 October 2014 21:19, Michael Welzl <[e-mail]> 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.  

I’ll note that the above paragraph is from Runa, not Hagen, and get back to this point below


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

Up to here, I agree with you.


> Question: what is the right IW for a given application? ->
> it is not application specific - it is link specific!

Here I’m not so sure, unless we go for extremes of course, as in your IW50 example. Generally I do see the point of Runa above, in trying to let short flows finish fast and get out of the network, it’s a double benefit somehow.


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

Interesting; while RFC 2140 is absolutely on my radar (we do some quite closely related work in RMCAT), I forgot that it talks about IW. Can you provide more detail about what is implemented in Linux for the IW there - I thought by default none of this is happening for IW in Linux, all flows just get 10?

I agree that Ensemble Sharing could make sense for IW… however, thanks to ECMP, there is of course no guarantee that different connections to the same IP address really do traverse the same bottleneck. So an approach that uses e.g. IW1 for later-joining connections to the same IP address may be doing the exact right thing or may be too conservative, depending on whether ECMP is in place or not. Further, by applying this limitation only on later connections to the same IP address, it may not kick in often enough.

Alternatively, giving a different IW to flows depending on their size may be doing the right thing more or less often… either way it’s heuristics I guess. I think both options are worth considering. Generally, giving a large IW only to short flows does strike me as reasonable because long flows simply won’t benefit much from it.

My point in my previous email was only that no additional harm comes from letting the application tell the transport layer a desired IW (or maybe rather flow size, to allow transport to do the calculation), provided that an upper limit is imposed by the transport.

Cheers,
Michael