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

From: Youjianjie <[email-masked]>
Date: Mon, 20 Oct 2014 06:32:53 +0000

Hi all,

This document discusses a method to configure TCP's initial congestion window by a new API.
Your questions and comments are appreciated.

Best Regards,
Jianjie

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2014年10月20日 14:26
收件人: Youjianjie; Huangyihong (Rachel); Huangyihong (Rachel); Youjianjie
主题: New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt

A new version of I-D, draft-you-tcpm-configuring-tcp-initial-window-00.txt
has been successfully submitted by Jianjie You and posted to the IETF repository.

Name:		draft-you-tcpm-configuring-tcp-initial-window
Revision:	00
Title:		Configuring TCP's Initial Window
Document date:	2014-10-19
Group:		Individual Submission
Pages:		8
URL:            http://www.ietf.org/internet-drafts/draft-you-tcpm-configuring-tcp-initial-window-00.txt
Status:         https://datatracker.ietf.org/doc/draft-you-tcpm-configuring-tcp-initial-window/
Htmlized:       http://tools.ietf.org/html/draft-you-tcpm-configuring-tcp-initial-window-00

Abstract:
   This document discusses that TCP's initial congestion window is not a
   constant in different use cases.  It proposes a flexible method to
   configure the initial window in order to keep up with the current
   network state.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Runa Barik <[email-masked]>
Date: Mon, 20 Oct 2014 09:41:55 +0000

Hi all,

First, I appreciate the authors submitting a draft on this work. In this draft, TCP Initial Window (IW) is computed based on the size of the resources, say flow-size. However, it is more important to consider when the application does not know the size in advance. And the authors set the IW using socket options. 

I worked on the problem related to deciding the TCP Initial Window (IW) in my Master thesis `` Improving Latency of Mice in the Internet: An Approach Based on TCP Initial Window" (problem focus started in 2011) under Dr. Dinil Mon Divakaran in IIT Mandi, India. We concluded that a constant value of IW is not appropriate both from Simulations, and Analytical tech, and understood that IW can be a function of resources in sender-side, and network state. For simplicity, we considered IW as a function  of flow-size. There are a couple of papers already published in WWIC'12, LCN'13, NoF'14 (accepted for publication). We also implemented an user library, and inside Linux kernel, and then experimented on a real testbed network. The nice thing about this work is that, even not knowing  the network state, the flow-size based IW function works well in various scenarios. 

There are various ideas that can done for computing IW. These can be:

 1. Based on the number of connections that faces in IW loss in the previous RTT, for computing the IW for new connection;
2. Based on the number of previous connections (https://tools.ietf.org/html/draft-touch-tcpm-automatic-iw-03), and IW loss;
3. Based on flow characteristics.

I think this is a nice work to consider further, and I can contribute more on this.

Regards,
 - Runa Barik
   Department of Informatics
  UiO, Oslo, Norway.

________________________________________
From: tcpm <[email-masked]> on behalf of Youjianjie <[email-masked]>
Sent: Monday, October 20, 2014 8:32 AM
To: [email-masked]
Subject: [tcpm] 转发: New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt

Hi all,

Best Regards,
Jianjie

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2014年10月20日 14:26
收件人: Youjianjie; Huangyihong (Rachel); Huangyihong (Rachel); Youjianjie
主题: New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt

Abstract:

The IETF Secretariat

_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Runa Barik <[email-masked]>
Date: Mon, 20 Oct 2014 10:41:09 +0000

Hi all,

 I forgot to mention the publications on this work.
 1. http://link.springer.com/chapter/10.1007%2F978-3-642-30630-3_25
2.  http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6761284&tag=1
3. http://www.network-of-the-future.org

We are about to submit a paper ``Characterizing the effects of TCP Initial Window".

Regards,
- Runa Barik
________________________________________
From: tcpm <[email-masked]> on behalf of Runa Barik <[email-masked]>
Sent: Monday, October 20, 2014 11:41 AM
To: Youjianjie; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt

Hi all,

Regards,
 - Runa Barik

Hi all,

Best Regards,
Jianjie

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2014年10月20日 14:26
收件人: Youjianjie; Huangyihong (Rachel); Huangyihong (Rachel); Youjianjie
主题: New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt

Abstract:

The IETF Secretariat

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 20 Oct 2014 12:52:26 +0000

Jianjie, Runa,

Research results regarding how to (automatically) set the IW are probably better discussed in the ICCRG, at least until ICCRG can give TCPM a good recommendation how to actually engineer a solution.

Furthermore, in the past there has been a certain consensus that IETF working groups only standardize abstract APIs to the network stack. The actual implementation e.g. as a socket option depends on the operating system.

Best regards

Michael

> -----Original Message-----
> From: tcpm [mailto:[email-masked]] On Behalf Of Runa Barik
> Sent: Monday, October 20, 2014 12:41 PM
> Cc: [email-masked]; [email-masked]
> First, I appreciate the authors submitting a draft on this work. In
> this draft, TCP Initial Window (IW) is computed based on the size of
> the resources, say flow-size. However, it is more important to consider
> when the application does not know the size in advance. And the authors
> set the IW using socket options.
> 
> I worked on the problem related to deciding the TCP Initial Window (IW)
> in my Master thesis `` Improving Latency of Mice in the Internet: An
> Approach Based on TCP Initial Window" (problem focus started in 2011)
> under Dr. Dinil Mon Divakaran in IIT Mandi, India. We concluded that a
> constant value of IW is not appropriate both from Simulations, and
> Analytical tech, and understood that IW can be a function of resources
> in sender-side, and network state. For simplicity, we considered IW as
> a function  of flow-size. There are a couple of papers already
> published in WWIC'12, LCN'13, NoF'14 (accepted for publication). We
> also implemented an user library, and inside Linux kernel, and then
> experimented on a real testbed network. The nice thing about this work
> is that, even not knowing  the network state, the flow-size based IW
> function works well in various scenarios.
> 
>  1. Based on the number of connections that faces in IW loss in the
> previous RTT, for computing the IW for new connection;
> 2. Based on the number of previous connections
> (https://tools.ietf.org/html/draft-touch-tcpm-automatic-iw-03), and IW
> loss;
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Mon, 20 Oct 2014 17:35:30 +0200

> Your questions and comments are appreciated.

Hello Youjianjie,

how do I - from a user/programmer perspective - know a save and fair
IW value in advance? And how you make sure that misconfigurations will
never negatively effects _network stability_ (not your local stack
stability)? A great deal of the Linux kernel community will refuse
this effort. Particular because someone will publish a blog post
titled "Make Internet Connection faster" with tips to "setsockopt(fd,
TCP_IW, 200)" and everybody will add this their software (like the
socketbuffer tunning tips to set buffers to thousands of gbyte). IW is
a sensitive parameter with probably huge negative impact if using
wrong - like selecting an unfair congestion control algorithm.

BTW: do you have analysis done in your setup with 50Kbit/s in a MANET
multihop scenario and short lived TCP flows?

Best regards, Hagen

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Oct 2014 11:48:29 -0700

There has been a proposal to automate the IW which was described here:

http://tools.ietf.org/html/draft-touch-tcpm-automatic-iw-03

An API might interact with that mechanism, e.g., changing parameters.

Joe

---

From: Michael Welzl <[email-masked]>
Date: Mon, 20 Oct 2014 21:19:39 +0200

Hi Hagen,

I'm not Youjianjie, still -

what if 10 is used as a default (like now) and an upper limit?

Cheers,
Michael

> On 20. okt. 2014, at 17.35, Hagen Paul Pfeifer <[email-masked]> wrote:
>

---

From: Runa Barik <[email-masked]>
Date: Mon, 20 Oct 2014 20:20:54 +0000

Hi J. Touch,

            The work in http://tools.ietf.org/html/draft-touch-tcpm-automatic-iw-03, proposes an an algorithm for
automating IW-size of TCP connections, based on the statistics of IW-losses of previous connections. It updates the IW-size based on the number of losses observed for the IW segments in the previous  say 1000 connections, such that the IW-size is increased if the fraction of losses is below a threshold, and decreased otherwise. The problem is, it sets a single IW-size for a large number of consecutive connections if these connections observe same number previous IW losses. I think the variation in IW for flows is very small, which means still the concept of a single constant IW for many flows. 

Regards,
- Runa Barik

________________________________________
From: tcpm <[email-masked]> on behalf of Joe Touch <[email-masked]>
Sent: Monday, October 20, 2014 8:48 PM
To: Youjianjie; [email-masked]
Subject: Re: [tcpm] 转发: New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt

Joe

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Tue, 21 Oct 2014 15:19:37 +0200

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

---

From: Runa Barik <[email-masked]>
Date: Tue, 21 Oct 2014 14:12:55 +0000

Hi all,

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

Hi Michael

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

Hagen

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

---

From: Runa Barik <[email-masked]>
Date: Tue, 21 Oct 2014 14:27:19 +0000

Hi all,

  I would suggest to look at the following papers I worked regarding TCP IW.
________________________________________
From: Runa Barik
Sent: Monday, October 20, 2014 12:41 PM
To: Youjianjie; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt

Hi all,

Regards,
- Runa Barik

Hi all,

Regards,
 - Runa Barik

Hi all,

Best Regards,
Jianjie

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2014年10月20日 14:26
收件人: Youjianjie; Huangyihong (Rachel); Huangyihong (Rachel); Youjianjie
主题: New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt

Abstract:

The IETF Secretariat

---

From: Runa Barik <[email-masked]>
Date: Tue, 21 Oct 2014 16:30:28 +0200

Hi all,

     Inline comments,

Hi Michael

The bandwidth is

Hagen

Regards,
- Runa Barik

---

From: Runa Barik <[email-masked]>
Date: Tue, 21 Oct 2014 20:37:08 +0200

Hi all,

     Sorry for duplicate e-mail.

     Inline comments.

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

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

---

From: Michael Welzl <[email-masked]>
Date: Tue, 21 Oct 2014 21:05:47 +0200

Hi all,

In line -

> On 21. okt. 2014, at 16.12, Runa Barik <[email-masked]> wrote:
> 
> Hi all,
> 
>      Inline comments,

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

> and gain.

Up to here, I agree with you.

> Question: what is the right IW for a given application? ->

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.

> 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

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Tue, 21 Oct 2014 21:23:31 +0200

* Runa Barik | 2014-10-21 20:37:08 [+0200]:

>understand the network during the handshaking, we can get better performance.

Constants are always a guess - like the initial RTO. Starting with a sensitive
guess and probe dynamically is always the best what you can do when you know
nothing about network characteristics.

Changing the IW on a per date basis like Mark's I-D propose is not what I
support. Bandwidth *is* and will be different for a given date, compare CERN
network bandwidth to multi-hop sensor networks - there is no right IW answer.
As I already wrote: dynamically probing succeeded by metric caching is the
best way to do. Meaning conservative in the beginning and utilize the pipe in
subsequent connections.

And bye the way: slow starting with IW10 *is* fast. If there is a problem then
probably the application layer is broken. See how HTTP/2 fixed their congestion
window problem.

Hagen

PS the shorted output of the TCP metric cache (sudo ip tcp_metrics show):

2a01:488:66:1000:b01c:b5d:0:1 age 2148.336sec rtt 60500us rttvar 19000us cwnd 10
54.235.102.146 age 28.452sec rtt 126500us rttvar 107000us cwnd 10
176.34.135.100 age 28.544sec rtt 82000us rttvar 82000us cwnd 10
54.244.6.176 age 8.428sec rtt 195000us rttvar 136000us cwnd 10
2a00:1450:4016:804::1014 age 76.572sec
2a00:1450:4016:802::1012 age 770.008sec rtt 39000us rttvar 31000us cwnd 14
2a00:1450:4016:802::1013 age 132.480sec rtt 39500us rttvar 36000us cwnd 14
2a00:1450:4016:803::1012 age 3139.532sec rtt 33000us rttvar 23000us cwnd 9
2a00:1450:4016:805::1014 age 1305.096sec rtt 39500us rttvar 29000us cwnd 14
2a02:26f0:7b:397::eed age 3936.224sec
2a00:1450:4016:805::1017 age 3139.984sec rtt 33000us rttvar 33000us cwnd 10
2a00:1450:4016:802::1010 age 4038.732sec rtt 30500us rttvar 30000us cwnd 12
2a00:1450:4016:804::1017 age 1923.280sec rtt 30500us rttvar 30000us cwnd 10

---

From: Runa Barik <[email-masked]>
Date: Tue, 21 Oct 2014 20:14:35 +0000

Hi Michael,

 In line with tag RB -
________________________________________
From: Michael Welzl <[email-masked]>
Sent: Tuesday, October 21, 2014 9:05 PM
To: Runa Barik
Cc: Hagen Paul Pfeifer; Joe Touch; [email-masked]
Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt

Hi all,

In line -

RB -

   For IW in the Linux Kernel (checked in version 3.7.4), 
     void tcp_init_sock(struct sock *sk)
     {
             ...............
            tp->snd_cwnd = TCP_INIT_CWND;
            .................
     }
   And this is called during TCP initialization.

RB -

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. 

RB -

   I agree with this point. Ensemble Sharing gives some information about the network-state.

RB-

Generally, giving a large IW only to short flows does strike me as reasonable because long flows simply won’t benefit much from it.

RB -

   We observed the same --- large flows do not achieve better benefit from a larger IW.

RB -

RB -

    We also set an upper limit for IW explicitly inside Transport layer.

RB -

Cheers,
Michael

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Tue, 21 Oct 2014 22:57:01 +0200

* Michael Welzl | 2014-10-21 21:05:47 [+0200]:

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

I also see Runa's point and I know that in 95% a user/programmer will
setsockopt() IW to the wrong value - because he simple has no idea about the
link. I don't consider IW50 as an extreme I already saw CDNs with a IW of 20.
So there is room left for more crazy values ;-)

Furthermore, the "get packets quickly out of the pipe" argument will show in a
different light when considered in a sensor network. If we have a valid
information basis (TCP cache) the finish fast approach may work - but we must
make sure that the pipe is in principle capable for the short IWx burst. IWx
results in bursts and some middle boxes are still not equipped for this
(bufferbloat guys: yes, this world exist ;).

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

IW is not cache driven in Linux - I don't wanted to claim this. But there is
absolutely no restriction to design and implement an algorithm to do that!
Joe's I-D may be a starting point (using packet loss indications, use a
timeout after which the cached information is threated as outdated, ...).
Similar to th RTT subsystem.

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

To some degree: yes. On the other the shorter the time difference between
flows the more likely the same path characteristics are still valid. Sure,
cache timeouts should make sure that the information is outdated after a while
- no doubt.

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

Probably - I must think about this.

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

Ok, got it. But then a setsockopt("SHORT_LIVED_FLOW") will be adequate too,
right!? Setting the IW is really complicated from a programmer point of view,
even a network guru may choose the wrong value. I believe that this logic
should be implemented and controlled in the Kernel.

Anyway, I understand the application argument and it may provide - combined
with the cached IW - a better behavior.

Hagen

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Oct 2014 16:59:59 -0700

A few points on this thread:

- 2140 includes both ensemble and temporal sharing
	ensemble happens only when you have a concurrent
	set of connections, at which point you subtract from
	the window of the current ones to give to the new one

	temporal includes going back to the same place - subnet
	or specific IP - and can involve aging the window

- we had a project here to look at whether the window could be predicted
based on past behavior (e.g., time-based patterns, either time-of-day,
day-of-week, etc.):
	http://www.isi.edu/aln/
The conclusion was that such patterns were not evident (at least when we
did the experiment).

- IW cannot be determined at the time of the connection per se
The only way to do so would be to send IW segments into the net and see
if they get there, which isn't so much a probe as just using that value
as the initial window anyway.

I continue to believe that IW can be adapted over loooong periods of
time using information on past connections as network behavior evolves
as per draft-touch-tcpm-automatic-iw-03.txt, but more experience is
definitely needed.

Joe

---

From: Daniel Borkmann <[email-masked]>
Date: Wed, 22 Oct 2014 11:13:23 +0200

> So there is room left for more crazy values ;-)

You probably have seen this article already:

  http://www.cdnplanet.com/blog/initcwnd-settings-major-cdn-providers/

>> thought by default none of this is happening for IW in Linux, all flows just

The default is 10, but you can have individual IWx settings on a per-route
basis. See the implementation in tcp_init_cwnd().

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 22 Oct 2014 09:57:56 +0000

Hi Hagen, Micheal, Runa, Joe, and all,

Thanks for your discussion on this draft. We barely catch up with your guys^^. We're new to the transport area, and very happy to see so many brilliant comments from all of you. They're highly appreciated.

The motivation of this draft is that we think different applications may have their different requirements for IW to achieve best performance. And maybe different flows for one application may have different requirements (e.g., short flows mentioned by Runa). Current global IW parameter may not well satisfy such requirements. So we bring up it for discussion: configure IW dynamically by API. However, we are not suggesting that users implement it with exaggerated values. We think dynamically setting IW in a safe range would be no harm. That is to say there must have a MAX IW to restrict the IW value in an appropriate range, e.g., current IW=10, maybe larger in the future.

The idea Michael mentioned that using flow size instead of IW as input to the API seems good to me. But some algorithms must be figured out in the transport layer to convert applications parameters like flow size to IW. It also may be a very hard work.

Anyway, we're just at the very beginning of this work. And we didn't do a lot of experiments. But we will. 

BR,
Jianjie & Rachel

> From: tcpm [mailto:[email-masked]] On Behalf Of Hagen Paul Pfeifer
> Sent: Wednesday, October 22, 2014 4:57 AM
> To: Michael Welzl
> Cc: [email-masked]; Joe Touch
> Subject: Re: [tcpm] New Version Notification for
> draft-you-tcpm-configuring-tcp-initial-window-00.txt
> 
> >> 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.
> 
> >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?
> 
> Joe's I-D may be a starting point (using packet loss indications, use a timeout
> after which the cached information is threated as outdated, ...).
> >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.
> 
> flows the more likely the same path characteristics are still valid. Sure, cache
> timeouts should make sure that the information is outdated after a while
> - no doubt.
> 
> >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.
>

---

From: Runa Barik <[email-masked]>
Date: Wed, 22 Oct 2014 12:12:47 +0000

Hi all,

> The conclusion was that such patterns were not evident (at least when

I agree with this points.

> as per draft-touch-tcpm-automatic-iw-03.txt, but more experience is

In the draft ``draft-touch-tcpm-automatic-iw-03.txt", All the
connections at
a particular instance start with nearly same IW value --- a single
constant window for all flows.
My point is, why not to take a look on flow characteristics. I played
with a lot of simulations and experiments.
In my simulations in ns2, I considered a combination of flow types
based on sizes --- large flows from Pareto Distribution, and small flows
from Exponential Distribution. And we observed, large flows having a
small IW, and even randomly choosing a large IW for small flows gives
better performance than all the flows with IW10; and we considered my
network conditions --- multiple bottlenecks, underload, overload,
varying base RTT, Large delay path, and etc. I also tested with CAIDA
dataset in my experiments in a testbed network. A constant IW may not be
suitable.
Somewhere it is IW10 (currently set inside the Linux kernel), IW7
(checked by Youjianjie).

- Runa Barik

---

From: Runa Barik <[email-masked]>
Date: Wed, 22 Oct 2014 12:15:14 +0000

Hi all,

On 2014-10-22 11:57, Huangyihong (Rachel) wrote:
> Thanks for your discussion on this draft. We barely catch up with
> your guys^^. We're new to the transport area, and very happy to see so
> many brilliant comments from all of you. They're highly appreciated.
>
> The motivation of this draft is that we think different applications
> may have their different requirements for IW to achieve best
> performance.

That's really a nice idea.

> And maybe different flows for one application may have
> different requirements (e.g., short flows mentioned by Runa).

  This is what I worked during my master thesis. And we came with a
simple function based on flow-sizes --- the larger the flow-size is, the
smaller the IW should be. This function works better than a single constant IW for all flows.

> Current
> global IW parameter may not well satisfy such requirements. So we
> bring up it for discussion: configure IW dynamically by API. However,
> we are not suggesting that users implement it with exaggerated values.
> We think dynamically setting IW in a safe range would be no harm. That
> is to say there must have a MAX IW to restrict the IW value in an
> appropriate range, e.g., current IW=10, maybe larger in the future.

We implemented the IW function we proposed in LCN'13 inside Linux
kernel, version 3.7.4. However, we implemented  in user space. I think it is hard to
implement inside kernel space. We also set a MAX IW.

>
> The idea Michael mentioned that using flow size instead of IW as
> input to the API seems good to me. But some algorithms must be figured
> out in the transport layer to convert applications parameters like
> flow size to IW. It also may be a very hard work.
>

> do a lot of experiments. But we will.

We had lots of simulations, and experiments in real testbed networks.
And they are accepted by WWIC'12, LCN'13, NoF'14, etc.

> Jianjie & Rachel

Regards,
- Runa

---

From: Runa Barik <[email-masked]>
Date: Wed, 22 Oct 2014 12:35:44 +0000

Hi all,

A typo.
________________________________________
From: tcpm <[email-masked]> on behalf of Runa Barik <[email-masked]>
Sent: Wednesday, October 22, 2014 2:15 PM
To: Huangyihong (Rachel)
Cc: [email-masked]; Michael Welzl; Joe Touch
Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt

Hi all,

We implemented the IW function we proposed in LCN'13 inside Linux
kernel, version 3.7.4. However, we implemented  in user space. I think it is *not* hard to
implement inside kernel space. We also set a MAX IW.

Regards,
- Runa

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Wed, 22 Oct 2014 15:59:40 +0200

@runa: your mailer seems to send randomly email ... ;(

> The motivation of this draft is that we think different applications may have their different requirements for IW to achieve best performance. And maybe different flows for one application may have…

Hey all

let me go one step back: what application will benefit from this effort?

- Bulk data applications?
- Interactive, chatty applications?

Not really, only short lived flows with a specific amount of data.
What is specific? Well 10 * MSS (a window) is handled currently. At
RTT 2 we have a window of 20. One iteration later 40.

That boils down to applications with a data amount in the range of 15k
to 30k, mind you. Below 15k IW10 is fine, larger than 30k and slow
start will kick in quickly (or in other words, after some amount of
data it is rather a bulk data application, an elephant).

What application is this? HTTP/1? What else? Don't get me wrong, the
effort is probably worth - but to see a real use case may help.

Hagen

---

From: Runa Barik <[email-masked]>
Date: Wed, 22 Oct 2014 22:32:25 +0000

Hi Hagen,

In line.
Sent: Wednesday, October 22, 2014 3:59 PM

Hey all

RB -
    My view --- benefit not for bulk data applications. 
    Because, the large flows adversely affect the small flows.
    The benefit is for small flows. In some cases, the size is not known in advance; but,
    some heuristics can be applied.
RB -

Hagen

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Thu, 23 Oct 2014 10:41:20 +0000

Hi Hagen,

Please see inline.

BR,
Rachel

> From: Hagen Paul Pfeifer [mailto:[email-masked]]
> Sent: Wednesday, October 22, 2014 10:00 PM
> To: Huangyihong (Rachel)
> Cc: Michael Welzl; [email-masked]; Joe Touch
> > The motivation of this draft is that we think different applications may have
> their different requirements for IW to achieve best performance. And maybe
> different flows for one application may have different requirements (e.g., short
> flows mentioned by Runa). Current global IW parameter may not well satisfy
> such requirements. So we bring up it for discussion: configure IW dynamically
> by API. However, we are not suggesting that users implement it with
> exaggerated values. We think dynamically setting IW in a safe range would be
> no harm. That is to say there must have a MAX IW to restrict the IW value in an

[Rachel]: For short live flows applications like Large websites, social networking applications and online shopping applications.

> What is specific? Well 10 * MSS (a window) is handled currently. At RTT 2 we
> have a window of 20. One iteration later 40.
> 
> That boils down to applications with a data amount in the range of 15k to 30k,
> mind you. Below 15k IW10 is fine, larger than 30k and slow start will kick in
> quickly (or in other words, after some amount of data it is rather a bulk data
> application, an elephant).
> 
> What application is this? HTTP/1? What else? Don't get me wrong, the effort is
> probably worth - but to see a real use case may help.

[Rachel]: Yes. Mostly for HTTP but not limited to. The online shopping website Taobao, produced by Alibaba, is using IW=7 to get best performance. And it will be better that IW of these short flows could be further reduced to avoid congestion when the network becomes busy on "Double-11" shopping festival of Taobao.

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Thu, 23 Oct 2014 10:43:30 +0000

Hi Runa,

Great. We can cooperate on this work^^.

BR,
Rachel

> From: Runa Barik [mailto:[email-masked]]
> Sent: Wednesday, October 22, 2014 8:36 PM
> To: Huangyihong (Rachel)
> Subject: RE: [tcpm] New Version Notification for
> > Thanks for your discussion on this draft. We barely catch up with your
> > guys^^. We're new to the transport area, and very happy to see so many
> > brilliant comments from all of you. They're highly appreciated.
> >
> > And maybe different flows for one application may have different
> > requirements (e.g., short flows mentioned by Runa).
> 
>   This is what I worked during my master thesis. And we came with a simple
> function based on flow-sizes --- the larger the flow-size is, the smaller the IW
> should be. This function works better than a single constant IW for all flows.
> 
> 
> > Current
> We implemented the IW function we proposed in LCN'13 inside Linux kernel,
> version 3.7.4. However, we implemented  in user space. I think it is *not*
> hard to implement inside kernel space. We also set a MAX IW.
> 
> >
> > The idea Michael mentioned that using flow size instead of IW as input
> > to the API seems good to me. But some algorithms must be figured out
> > in the transport layer to convert applications parameters like flow
> > size to IW. It also may be a very hard work.
> >
> 
> 
> >>>> 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.
> >>
> >> setsockopt() IW to the wrong value - because he simple has no idea
> >> about the link. I don't consider IW50 as an extreme I already saw
> >> CDNs with a IW of 20.
> >> Furthermore, the "get packets quickly out of the pipe" argument will
> >> show in a different light when considered in a sensor network. If we
> >> have a valid information basis (TCP cache) the finish fast approach
> >> may work - but we must make sure that the pipe is in principle
> >> capable for the short IWx burst. IWx results in bursts and some
> >> middle boxes are still not equipped for this (bufferbloat guys: yes,
> >> this world exist ;).
> >>
> >>> 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?
> >>
> >> IW is not cache driven in Linux - I don't wanted to claim this. But
> >> there is absolutely no restriction to design and implement an
> >> algorithm to do that!
> >> Joe's I-D may be a starting point (using packet loss indications, use
> >> a timeout after which the cached information is threated as outdated,
> >> ...).
> >>> 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
> >> To some degree: yes. On the other the shorter the time difference
> >> between flows the more likely the same path characteristics are still
> >> valid.
> >> Sure, cache
> >>> 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.
> >>
> >>> 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.
> >>
> >> Ok, got it. But then a setsockopt("SHORT_LIVED_FLOW") will be
> >> adequate too, right!? Setting the IW is really complicated from a
> >> programmer point of view, even a network guru may choose the wrong
> >> value. I believe that this logic should be implemented and controlled
> >> in the Kernel.
> >>
> >> Anyway, I understand the application argument and it may provide -
> >> combined with the cached IW - a better behavior.
> >>
> >> Hagen
> >

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Oct 2014 07:38:34 -0700

> On 2014-10-22 01:59, Joe Touch wrote:
...
> connections at a particular instance start with nearly same IW value
> --- a single constant window for all flows.

I had been assuming 2140-style grouping of information based on network
interface, destination IP address, destination subnet, etc.

> In my simulations in ns2, I considered a combination of flow types based
> on sizes --- large flows from Pareto Distribution, and small flows from
> Exponential Distribution. And we observed, large flows having a small
> IW, and even randomly choosing a large IW for small flows gives better
> performance than all the flows with IW10;

Large flows are not as affected by IW effects because IW applies only
during transients that are presumably rare (startup, restart after idle,
etc.)

The problem with your observation is that it fails to consider the
"tragedy of the commons". Capacity is a common network resource, and
your increase of IW for short flows causes them to consume that resource
before feedback corrects it in ways that are not generally considered
"fair".

I.e., it's been known for a long time that making IW large helps short
flows and has no real impact on long flows. It's also been known that
this is not necessarily how we want the network to behave.

There's a balance between trying to complete a short flow quickly and
having flows that are basically non-responsive to network congestion. We
only recently increased IW to 10 based on the assumption that "a problem
we haven't seen doesn't exist".

...
> A constant IW may not be suitable.

If you have 2140 in place, you might have the information useful to set
an appropriate IW on a per-connection basis. However, setting that value
solely based on the length of the connection is (IMO) inappropriate.

Joe

---

From: Runa Barik <[email-masked]>
Date: Thu, 23 Oct 2014 16:01:43 +0000

Hi J. Touch,

Comments inline.
________________________________________
From: Joe Touch <[email-masked]>
Sent: Thursday, October 23, 2014 4:38 PM
To: Runa Barik
Cc: Hagen Paul Pfeifer; Michael Welzl; [email-masked]
Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt

...

RB -

     I agree with the above  points. But consider the scenarios,
   (1) All flows start with say IW10; (2) The large flows start with
  IW as per rfc 3390, and small flows with IW10. Scenario (2) shows better
  performance than scenario (1) in various network conditions. In scenario (1),
  we observed large flows are affecting small flows more. However, in scenario (2), this negative
  effect on small flow is reduced . This motivates IW as a function. I agree with rfc 2140 
 that a past experience will help predicting a better value.

RB -

RB -
    Consider a grass field and animals: goat and cow. If same amount of grass will
   be given to both cow and goat, then cow will remain hungry later and goat will
  waste the grass. However, if cow and goat will get the amount they need, probably
  no wastage, and no hungriness. That is my point, different applications may need
  different values of IW for their best service requirements.

RB -

...

Joe

Regards,
- Runa

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Oct 2014 09:41:30 -0700

On 10/23/2014 9:01 AM, Runa Barik wrote:
>  consider the scenarios,
>   effect on small flow is reduced . 

Can you clarify what you saw?

In particular, what does "shows better performance" mean?

	a) short flows complete more quickly

	b) all flows complete more quickly

	c) overall network loss is reduced

These are competing goals.

Joe

---

From: Runa Barik <[email-masked]>
Date: Thu, 23 Oct 2014 17:25:33 +0000

Hi J. Touch,

Comments inline.
Sent: Thursday, October 23, 2014 6:41 PM

BR -

    Both small and large flow complete quickly, and also 
   reduced loss (retransmission rate, number of TO).
    
Can you please have a look at the experimental results in this linked paper, 
 https://sites.google.com/site/dinild/papers/tcp-iw-lcn-2013.pdf?attredirects=0, for more detail?

BR -

Joe

Regards,
- Runa

---

From: Michael Welzl <[email-masked]>
Date: Fri, 24 Oct 2014 09:57:55 +0200

Hi Joe,

In line:

> interface, destination IP address, destination subnet, etc.

...which I'm not sure would be a good idea here, see my previous response to Hagen and also further below.

> before feedback corrects it in ways that are not generally considered

So you're arguing that this work creates an incentive for applications to make their flows shorter? Interesting. An application cheating the system by splitting a large flow into small ones would have to weigh the benefits of being able to use a larger IW against the cost of the handshakes for closing and re-opening a connection, at least. Depending on the IW calculation function in use, there can be corner cases where such cheating might work, I think this should be addressed in the draft.

> solely based on the length of the connection is (IMO) inappropriate.

So, I think it's the most appropriate thing that can be done, and RFC 2140 can end up being less appropriate:
1) if you reduce IW on later connections to a host you're already talking to (ensemble sharing) or have talked to before (temporal sharing), ECMP may put you on a different path and you may end up being too conservative.
2) if you ONLY apply 2140-style IW reduction, you may not be conservative enough because all these first connections to various IP addresses start with IW10  (which may not seem to matter if we think about it from the perspective of a single web server, but certain web pages open many *first* connections from many different IP addresses to my browser, so then it's my access link that suffers).

At the same time, using IW10 on large transfers is just useless. So I think incorporating the flow length in the decision to only use a large window when it can make sense is the best we can currently do.

Cheers,
Michael

---

From: [email-masked]
Date: Fri, 24 Oct 2014 09:18:01 +0100

I think this IW is not an appropriate parameter to present to the API,
because the choice of value has a very significant impact on the
robustness of the TCP service.

An app can anyway decide to  send less (defer sending a large volume of
data straight away) - it is not in a place to decide the network path is
safe to send more. Although if this were to be used as a part of  the  TCB
sharing method (i.e. using cached network path state), that may be of
value.

Gorry

>>> based
> So you're arguing that this work creates an incentive for applications to
> make their flows shorter? Interesting. An application cheating the system
> by splitting a large flow into small ones would have to weigh the benefits
> of being able to use a larger IW against the cost of the handshakes for
> closing and re-opening a connection, at least. Depending on the IW
> calculation function in use, there can be corner cases where such cheating
> might work, I think this should be addressed in the draft.
>
>
> 1) if you reduce IW on later connections to a host you're already talking
> to (ensemble sharing) or have talked to before (temporal sharing), ECMP
> may put you on a different path and you may end up being too conservative.
> 2) if you ONLY apply 2140-style IW reduction, you may not be conservative
> enough because all these first connections to various IP addresses start
> with IW10  (which may not seem to matter if we think about it from the
> perspective of a single web server, but certain web pages open many
> *first* connections from many different IP addresses to my browser, so
> then it's my access link that suffers).
>
> At the same time, using IW10 on large transfers is just useless. So I
> think incorporating the flow length in the decision to only use a large
> window when it can make sense is the best we can currently do.
>
> Cheers,
> Michael
>

---

From: Michael Welzl <[email-masked]>
Date: Fri, 24 Oct 2014 11:18:05 +0200

> robustness of the TCP service.

Actually the proposal that some of us agreed on in emails would not expose the IW but let an application provide the length of its transfer. What the OS does with this information is then up to the OS.

> safe to send more.

My interest is not in saying "it's safe to send more" but in saying "let's only use a large IW (capped by whatever the current agreement is - i.e. if folks use IW10, then that number is 10) for flows that can really benefit from it". It just seems so wrong to me to use IW10 on *all* flows irrespective of their length when it's used at all.

> Although if this were to be used as a part of  the  TCB

I don't see how (see my email to Joe). Maybe only when the same 5-tuple is used again?

Cheers,
Michael

---

From: Youjianjie <[email-masked]>
Date: Fri, 24 Oct 2014 09:54:41 +0000

Hi Michael, Joe,

Please see my comments inline...

BR,
Jianjie

> -----邮件原件-----
> 发件人: tcpm [mailto:[email-masked]] 代表 Michael Welzl
> 发送时间: 2014年10月24日 15:58
> 收件人: Joe Touch
> 抄送: [email-masked]
> 主题: Re: [tcpm] New Version Notification for
> >>> - IW cannot be determined at the time of the connection per se The
> >>> only way to do so would be to send IW segments into the net and see
> >>> if they get there, which isn't so much a probe as just using that
> >>> value as the initial window anyway.
> >>>
> >>> time using information on past connections as network behavior
> >>> evolves as per draft-touch-tcpm-automatic-iw-03.txt, but more
> >>> experience is definitely needed.
> >>>
> >>
> > I had been assuming 2140-style grouping of information based on
> > network interface, destination IP address, destination subnet, etc.
> 
> >> based on sizes --- large flows from Pareto Distribution, and small
> >> flows from Exponential Distribution. And we observed, large flows
> >> having a small IW, and even randomly choosing a large IW for small
> >> flows gives better performance than all the flows with IW10;
> >
> > your increase of IW for short flows causes them to consume that
> > resource before feedback corrects it in ways that are not generally
> > considered "fair".
> 
> So you're arguing that this work creates an incentive for applications to make
> their flows shorter? Interesting. An application cheating the system by splitting
> a large flow into small ones would have to weigh the benefits of being able to
> use a larger IW against the cost of the handshakes for closing and re-opening a
> connection, at least. Depending on the IW calculation function in use, there can
> be corner cases where such cheating might work, I think this should be
> addressed in the draft.
> 

If the applications are not trusted, then the system could add some constraints, such as maximum IW. This value could be configured by the system. Meanwhile, the IW of the receiver should also be considered. If the application are trusted, then this is not an issue. Shall we add such descriptions in the draft?

> > having flows that are basically non-responsive to network congestion.
> > We only recently increased IW to 10 based on the assumption that "a
> > problem we haven't seen doesn't exist".
> >
> > ...
> > If you have 2140 in place, you might have the information useful to
> > set an appropriate IW on a per-connection basis. However, setting that
> > value solely based on the length of the connection is (IMO) inappropriate.
> 
> 1) if you reduce IW on later connections to a host you're already talking to
> (ensemble sharing) or have talked to before (temporal sharing), ECMP may put
> you on a different path and you may end up being too conservative.
> enough because all these first connections to various IP addresses start with
> IW10  (which may not seem to matter if we think about it from the
> perspective of a single web server, but certain web pages open many *first*
> connections from many different IP addresses to my browser, so then it's my
> access link that suffers).
> 
> At the same time, using IW10 on large transfers is just useless. So I think
> incorporating the flow length in the decision to only use a large window when it
> can make sense is the best we can currently do.
> 
> Cheers,
> Michael
>

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 24 Oct 2014 11:11:25 +0000

> Actually the proposal that some of us agreed on in emails would not
> expose the IW but let an application provide the length of its
> transfer. What the OS does with this information is then up to the OS.

This idea has been out there for a while. For instance, see in http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Sf_Diss_40112.pdf Section 5.1.1 or specifically Section 5.1.1.3. This reference is probably not the first time this kind of API was proposed, but out of my head I don't recall other references.

Based on my past work, I'd suggest to survey what applications can indeed provide that sort of information. A while back I had a prototype with a Web server for such an API, but it as far as I remember it really depends on the content and the server architecture whether that kind of information can indeed be provided to the TCP stack. Until it is clear that this type of API is indeed doable, this topic seems to me more research than engineering.

Michael (obviously with chair hat off)

---

From: Michael Welzl <[email-masked]>
Date: Fri, 24 Oct 2014 13:25:12 +0200

> Based on my past work, I'd suggest to survey what applications can indeed provide that sort of information. A while back I had a prototype with a Web server for such an API, but it as far as I reme…

I actually don't get that: obviously you'd only apply it *when* an application can specify a file length. For static files, web servers can do that (no doubt that web servers don't provide only static content). By "only apply" I mean: when an application doesn't specify anything, you get the system default IW.

Cheers,
Michael

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Fri, 24 Oct 2014 13:51:52 +0200

> Actually the proposal that some of us agreed on in emails would not expose the IW but let an application provide the length of its transfer. What the OS does with this information is then up to the…

+1, setting IW directly is far from being adequate for the user. The
user can - similar to other kernel parameters - give an *hint* about
application characteristics. It is up the the kernel to follow then or
ignore then completely. This is a good design. Maybe "expected data
length" is a good starting point.

Hagen

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Fri, 24 Oct 2014 14:03:36 +0200

> Based on my past work, I'd suggest to survey what applications can indeed provide that sort of information. A while back I had a prototype with a Web server for such an API, but it as far as I reme…

Absolutely! Until now we identified several risks/inconsistency - on
the other hand it is hard to see real world use-cases where the API
change is beneficial. More research is clearly required.

And bye the way, this API change even exists in a form of a prime-time
ready patch for Linux Kernel 4 years ago! This patch even include a
upper system limit sysctl. Everyone should read this email thread
because the arguments are equally. E.g. IW is not a user thing, the
kernel should handle this automatically, ...

http://thread.gmane.org/gmane.linux.network/162103

Hagen

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 24 Oct 2014 15:01:50 +0000

> > This idea has been out there for a while. For instance, see in
> http://www.ikr.uni-
> stuttgart.de/Content/Publications/Archive/Sf_Diss_40112.pdf Section
> 5.1.1 or specifically Section 5.1.1.3. This reference is probably not
> the first time this kind of API was proposed, but out of my head I
> don't recall other references.
> >
> > Based on my past work, I'd suggest to survey what applications can
> indeed provide that sort of information. A while back I had a prototype
> with a Web server for such an API, but it as far as I remember it
> really depends on the content and the server architecture whether that
> kind of information can indeed be provided to the TCP stack. Until it
> is clear that this type of API is indeed doable, this topic seems to me
> more research than engineering.
> 
> I actually don't get that: obviously you'd only apply it *when* an
> application can specify a file length. For static files, web servers
> can do that (no doubt that web servers don't provide only static
> content). By "only apply" I mean: when an application doesn't specify
> anything, you get the system default IW.

Disclaimer: I haven't looked into that question in the last years.

However, as far as I recall, I used lighttpd in my past experiments in 2008/2009 because in that code I could access the content length directly in the function that contained the actual socket calls. In other Web servers that I checked at that time, there were wrapper functions e.g. by libraries to hide the socket API from the actual server logic. Being able to pass the file length to the socket would have implied a complete change of that library API. This is a less low-hanging fruit than adding just the "setsockopt" call. I haven't looked at Java-based servers.

A research study could have a look which software would actually allow such an API change, and how disruptive that change would be for the overall software architecture.

Michael

---

From: Yuchung Cheng <[email-masked]>
Date: Fri, 24 Oct 2014 23:12:22 +0800

Why has the thread morphed into
1. should app set IW
2. what's the right IW

Michael has already pointed out early that socket API is out of scope
of tcpm. Period.

---

From: Runa Barik <[email-masked]>
Date: Fri, 24 Oct 2014 15:35:01 +0000

Hi,

Comments inline.
________________________________________
From: tcpm <[email-masked]> on behalf of Scharf, Michael (Michael) <[email-masked]>
Sent: Friday, October 24, 2014 5:01 PM
To: Michael Welzl
Cc: [email-masked] Extensions; Joe Touch
Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt

RB
   The idea mentioned above by Michael Welzl is the one I tested by using simulations in ns2, and 
  experiments  in testbed. There are couple of papers already published. 
  The function I used,
    
          if (flow-size <= theta)
                IW = MaxIW
          else
               IW = flow-size/theta * MaxIW + (1-flow-size/theta) * MinIW
 
       where theta is the flow size threshold used to distinguish between
   large flows and the rest, MinIW is the lower bound (four segments
   [RFC3390]), and MaxIW is the maximum IW that any connection can
   have (e.g. 10 [RFC6928]).  The parameters, theta, MinIW and MaxIW are
   in number of TCP segments.  Observe that, while small flows, defined
   by the threshold theta, will have IW as large as MaxIW, flows
   with size greater than theta will have IW closer to MinIW with
   increasing size.

RB

Michael

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 24 Oct 2014 15:59:46 +0000

Runa,

>   experiments  in testbed. There are couple of papers already

For this discussion being relevant to TCPM, please focus how such a solution could be engineered for general use in the global Internet, including the different classes of applications and architectures implementing TCP.

Thanks

Michael

---

From: Michael Welzl <[email-masked]>
Date: Fri, 24 Oct 2014 18:45:08 +0200

> For this discussion being relevant to TCPM, please focus how such a solution could be engineered for general use in the global Internet, including the different classes of applications and architec…

I think that’s well worth looking into. Meanwhile, I sense some annoyance with this discussion continuing in TCPM while it has already been agreed that it should happen in ICCRG. My apologies, even though I want more list traffic in ICCRG, I have been answering to TCPM too without thinking much about that.

All people involved in this discussion, let’s now really move the thread over to [email-masked] <mailto:[email-masked]> and try to make this the last message on the matter that has [email-masked] <mailto:[email-masked]> in the recipient list. All others, sorry for the continued noise.

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Fri, 24 Oct 2014 09:47:39 -0700

+1

> On Oct 24, 2014, at 1:18 AM, [email-masked] wrote:
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 24 Oct 2014 09:48:36 -0700

> On Oct 24, 2014, at 2:18 AM, Michael Welzl <[email-masked]> wrote:
> 
> 

Apps will lie.