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

From: Michael Welzl <[email-masked]>
Date: Wed, 22 Oct 2014 14:46:40 +0200

FYI, all,

This has raised a bit of attention in TCPM, and will be presented in ICCRG in Hawaii. We still have slots available, so if you want to present something, tell us.

Cheers,
Michael

Begin forwarded message:

> From: Youjianjie <[email-masked]>
> Subject: [tcpm] 转发: New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt
> Date: 20. oktober 2014 08:32:53 GMT+02:00
> To: "[email-masked]" <[email-masked]>
> 
> 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
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

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

Hi Hagen,
 
 In line. 
________________________________________
From: tcpm <[email-masked]> on behalf of Hagen Paul Pfeifer <[email-masked]>
Sent: Wednesday, October 22, 2014 3:59 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

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

On 22 October 2014 11:57, Huangyihong (Rachel) <[email-masked]> wrote:

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

Hey all

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

- Bulk data applications?
- Interactive, chatty applications?

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 -

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

Regards,
- Runa

---

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

On 24. okt. 2014, at 17.59, Scharf, Michael (Michael) <[email-masked]> wrote:
> 
> Runa,
> 
>>   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.
> 
> 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.

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: Runa Barik <[email-masked]>
Date: Sat, 25 Oct 2014 09:46:34 +0000

Hi J. Touch,

      A new version of the draft has been updated.
     Comments inline,
________________________________________
From: tcpm <[email-masked]> on behalf of Joe Touch <[email-masked]>
Sent: Friday, October 24, 2014 6:48 PM
To: Michael Welzl
Cc: [email-masked] Extensions
Subject: Re: [tcpm] New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt

> On Oct 24, 2014, at 2:18 AM, Michael Welzl <[email-masked]> wrote:
>
>
>> On 24. okt. 2014, at 10:18, <[email-masked]> <[email-masked]> wrote:
>>
>> 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.
>
> 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.

Apps will lie.

RB
    This is also mentioned by Youjianjie.
   The strategy can be, for untrusted app, IW can be set to MinIW (as per RFC3390). However,
   for trusted app, it can be according the IW function mentioned in the draft.
RB

>
>
>> 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.
>
> 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
>> sharing method (i.e. using cached network path state), that may be of
>> value.
>
> I don't see how (see my email to Joe). Maybe only when the same 5-tuple is used again?
>
> Cheers,
> Michael
>

Regards,
Runa Barik

---

From: Youjianjie <[email-masked]>
Date: Mon, 27 Oct 2014 03:03:00 +0000

Hi Joe,
Inline...

> -----邮件原件-----
> 发件人: Joe Touch [mailto:[email-masked]]
> 发送时间: 2014年10月26日 2:22
> 收件人: Runa Barik
> 抄送: Youjianjie; [email-masked]
> 主题: Re: [tcpm] New Version Notification for
> draft-you-tcpm-configuring-tcp-initial-window-00.txt
> 
> 
> >> ...
> >> 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.
> >
> > Apps will lie.
> >
> > RB
> There are no trusted apps in the Internet; there’s no one party to “trust”
> them.
> 
> I.e., I have no reason to trust your apps, nor you to trust mine.
> 
> So, ultimately, everyone needs to use the same rules and assume that
> everyone will try to game the system.

The worst is all the applications use the default maximum IW set by the system. 

> Joe