Subject: [Iccrg] Meeting in Taipei
From: [email-masked] (Michael Welzl)
Date: Tue Sep 27 22:03:15 2011

Hi,

Regarding work done in TMRG and the charter change, I would say that  
this was fully described in Lachlan's previous email:
http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2011-September/000953.html

Cheers,
Michael

On Sep 27, 2011, at 8:57 PM, Mirja Kuehlewind wrote:

> Hi,
>
> I will be in Taipei and I would be intrested in a meeting. Maybe a  
> good time
> to present the work done in the Transport Modeling Research Group  
> and the
> changes to the charter..?
>
> Mirja
>
>
> On Friday 23 September 2011 03:58:15 Murari Sridharan wrote:
>> Folks,
>>
>> We haven't yet proposed to meet at the Taipei IETF. Is there enough
>> interest to meet there or should we meet instead in Paris? I will  
>> be there
>> and we can hold the meeting if there is sufficient interest.
>>
>> Thanks
>> M & M
>
>
>
> -- 
> -------------------------------------------------------------------
> Dipl.-Ing. Mirja K?hlewind
> Institute of Communication Networks and Computer Engineering (IKR)
> University of Stuttgart, Germany
> Pfaffenwaldring 47, D-70569 Stuttgart
>
> tel: +49(0)711/685-67973
> email: [email-masked]
> web: www.ikr.uni-stuttgart.de
> -------------------------------------------------------------------
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Mirja Kuehlewind)
Date: Tue Sep 27 19:55:34 2011
Subject: [Iccrg] Meeting in Taipei
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

I will be in Taipei and I would be intrested in a meeting. Maybe a good time 
to present the work done in the Transport Modeling Research Group and the 
changes to the charter..?

Mirja

On Friday 23 September 2011 03:58:15 Murari Sridharan wrote:
> Folks,
>
> We haven't yet proposed to meet at the Taipei IETF. Is there enough
> interest to meet there or should we meet instead in Paris? I will be there
> and we can hold the meeting if there is sufficient interest.
>
> Thanks
> M & M

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja K?hlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

From: [email-masked] (Lars Eggert)
Date: Mon Sep 26 13:00:56 2011
Subject: [Iccrg] Transport Modeling Research Group (TMRG) is closing down
Message-ID: <[email-masked]>

Hi,

as discussed on the Transport Modeling Research Group (TMRG) list, the TMRG is closing down.

The TMRG's one remaining active work item is being taken over by the Internet Congestion Control Research Group (ICCRG), out of which the TMRG was spun out of in the first place. The ICCRG charter has been amended to reflect this.

The TMRG mailing list will close; discussion related to TMRG topics will in the future happen on the ICCRG mailing list.

I'd like to thank the TMRG participants and especially chairs for their efforts over the years.

Lars Eggert
IRTF Chair
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20110926/8d5e892e/smime.bin
>From [email-masked]  Tue Sep 27 00:42:15 2011
From: [email-masked] (Dino LOPEZ)
Date: Tue Sep 27 00:40:17 2011
Subject: [Iccrg] RE: On the deployment of Explicit Rate 
	Notificationprotocols
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hi Michael,

Thank you for reading our draft. Please find my answer below.

On 09/26/2011 01:40 PM, SCHARF, Michael wrote:
> Hi Dino,
>
> the core idea of this framework is to allow only sending rates slower
> than the one of the end-to-end congestion control, right?
>
> This IMHO raises a couple of questions:
>
> * Is there a significant benefit? If a router wants to slow down a given
> flow, it can use ECN markings right now (or just packet drops).
> Additional feedback from the network may enable a more fine-grained
> control, which may improve fairness and convergence speed. But I am not
> sure whether this improvement e. g. to ECN is really significant, if no
> speedup compared to end-to-end is allowed.

Some studies show that binary signaling can lead to underutilization of 
resources if several sources receive the congestion signal in a short 
period of time. Thus, ECN can have the same problem, while protocols 
with more complex feedbacks (like RCP, just to give an example), will 
not (moreover, it will depend on the performance of the ERN protocol).

Also, when not all sources sharing the bottleneck are ECN capable, ECN 
capable sources may yield resources in benefit of those non supporting 
the protocol. IP-ERN does not suffer from that problem either. Suppose 
that a bottleneck link is shared by E2E and E2E-ERN flows. Then 
cwnd_ern_ will not match the current rate so cwnd_ern_ is bigger than 
cwnd_ (forwarding devices using IP-ERN MUST NOT take into account the 
pure E2E traffic to compute a feedback).

I think there is a real interest of IP-ERN when the bottleneck is known 
(e.g. path with satellite links, or heavily load network access links). 
In that case, we could avoid retransmissions while using all the 
available bandwidth. The benefit will increase as the bandwidth x delay 
increases. Some studies shows also that delay-based congestion control 
mechanisms may have convergence problems (e.g. TCP Vegas). Using a ERN 
protocol by mean of IP-ERN may speedup the convergence. Delay-based LBE 
convergence capabilities can also benefit from IP-ERN.

>
> * I think that the equation "cwnd_ = min (cwnd_, cwnd_ern_)" can be
> understood and implemented in two different ways:
>
>    (1): Use one cwnd only. Then, the minumum is taken probably always
> whenever cwnd is updated. But then some corner cases could be tricky, e.
> g., when cwnd is inflated during fast rtx.
>
>    (2): Use a shadow cwnd, i. e., "cwnd_ = min (cwnd_shadow_,
> cwnd_ern_)", wherein cwnd_shadow is updated by the end-to-end algorithm
> independent of ERN. Then one key question is how to deal with
> connections that are limited by cwnd_ern. One might need a kind of
> congestion window validation to ensure TCP compatibility.

We agree with you and we have to clarify this. For (1), we have to 
signal that this equation is not valid during the execution of window 
inflation. This can be achieved by mean of a flag turned on during the 
execution of FRet / FRec (special considerations may be also needed 
regarding to F-RTO).

For (2 hoping I understood your remark). IP-ERN requires cwnd_ be equal 
to cwnd_shadow_. Thus, cwnd_shadow_ must be updated immediately once 
equation 1 is executed.

For (1 & 2). We have to make un update and remark that after the 
execution of eq.1, cwnd_ern_ must be updated (cwnd_ern_ = cwnd_) so the 
feedback from forwarding devices are computed using the right state of 
the sources.

>
> * Apparently, the reseach community failed so far to agree on the header
> information that explicit rate notification would actually need. The
> draft seems to leave that question open. For a framework document, this
> may be OK. But I could imagine that proposals would - at least in theory
> - require also signaling of information in the SYNs. This is not
> foreseen in your architecture, right?
Speaking not as researcher, but as TCPM co-chair: Since you are
proposing at least one new TCP option, please note that TCP option space
in particular in SYNs is somehow scarce.

Absolutely. In this document we didn't want to deal with the header 
construction/position of ERN protocols. Indeed, IP-ERN can be used to 
deploy an ERN protocol like a service and the programmer is free to 
create/place the header as he wants.

Additionally, in this draft we advised (we have to clarify also that 
this is only an advise) to use the TCP option fields to initiate an 
E2E-ERN connection. However, if the cases when IP-ERN can be used is 
strictly defined by a network administrator (e.g. long-lived flows with 
well known receivers), the use of TCP options at SYN packets is not needed.

>
> BTW, I guess that you are aware of the challenges listed in section 3.1
> of RFC 6077.

Yes, I do. We will update the document with references to that RFC.

Best Regards,

Dino

>
> Michael
>
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Murari Sridharan
>> Sent: Monday, September 26, 2011 10:12 AM
>> To: Dino LOPEZ; [email-masked]; [email-masked]
>> Subject: [Iccrg] RE: On the deployment of Explicit Rate
>> Notificationprotocols
>>
>> +iccrg
>>
>> -----Original Message-----
>> From: Dino LOPEZ [mailto:[email-masked]]
>> Sent: Monday, September 26, 2011 1:07 AM
>> To: [email-masked]; Murari Sridharan
>> Subject: On the deployment of Explicit Rate Notification protocols
>>
>> Dear ICCRG chairs,
>>
>> We have submitted a new Internet draft which provides an
>> architecture to allow the deployment of congestion control
>> protocols with explicit rate notification from forwarding
>> devices (Explicit Rate Notification protocols).
>>
>> This draft is currently available at
>> http://www.ietf.org/internet-drafts/draft-lopez-ietf-tsvwg-ipe
>> rn-00.txt
>>
>> We will be grateful if you can relay this information to the
>> ICCRG community and we can receive any feedback from the you
>> all (at http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG
>> it is remarked that one should send an email to the chairs
>> requesting that the ICCRG perform a review of the document)
>>
>> Best Regards,
>>
>> The authors
>> Lochin, Emmanuel ([email-masked]) Lopez Pacheco,
>> Dino ([email-masked]) Sathiaseelan, Arjuna
>> ([email-masked])
>>
>>
>> _______________________________________________
>> Iccrg mailing list
>> [email-masked]
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>

From: [email-masked] (SCHARF, Michael)
Date: Mon Sep 26 12:38:59 2011
Subject: [Iccrg] RE: On the deployment of Explicit Rate  Notificationprotocols
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Dino,

the core idea of this framework is to allow only sending rates slower
than the one of the end-to-end congestion control, right?

This IMHO raises a couple of questions:

* Is there a significant benefit? If a router wants to slow down a given
flow, it can use ECN markings right now (or just packet drops).
Additional feedback from the network may enable a more fine-grained
control, which may improve fairness and convergence speed. But I am not
sure whether this improvement e. g. to ECN is really significant, if no
speedup compared to end-to-end is allowed.

* I think that the equation "cwnd_ = min (cwnd_, cwnd_ern_)" can be
understood and implemented in two different ways: 

  (1): Use one cwnd only. Then, the minumum is taken probably always
whenever cwnd is updated. But then some corner cases could be tricky, e.
g., when cwnd is inflated during fast rtx.

  (2): Use a shadow cwnd, i. e., "cwnd_ = min (cwnd_shadow_,
cwnd_ern_)", wherein cwnd_shadow is updated by the end-to-end algorithm
independent of ERN. Then one key question is how to deal with
connections that are limited by cwnd_ern. One might need a kind of
congestion window validation to ensure TCP compatibility.

* Apparently, the reseach community failed so far to agree on the header
information that explicit rate notification would actually need. The
draft seems to leave that question open. For a framework document, this
may be OK. But I could imagine that proposals would - at least in theory
- require also signaling of information in the SYNs. This is not
foreseen in your architecture, right?

BTW, I guess that you are aware of the challenges listed in section 3.1
of RFC 6077.

Michael

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Murari Sridharan
> Sent: Monday, September 26, 2011 10:12 AM
> To: Dino LOPEZ; [email-masked]; [email-masked]
> Subject: [Iccrg] RE: On the deployment of Explicit Rate 
> Notificationprotocols
> 
> +iccrg
> 
> -----Original Message-----
> From: Dino LOPEZ [mailto:[email-masked]]
> Sent: Monday, September 26, 2011 1:07 AM
> To: [email-masked]; Murari Sridharan
> Subject: On the deployment of Explicit Rate Notification protocols
> 
> Dear ICCRG chairs,
> 
> We have submitted a new Internet draft which provides an 
> architecture to allow the deployment of congestion control 
> protocols with explicit rate notification from forwarding 
> devices (Explicit Rate Notification protocols).
> 
> This draft is currently available at
> http://www.ietf.org/internet-drafts/draft-lopez-ietf-tsvwg-ipe
> rn-00.txt
> 
> We will be grateful if you can relay this information to the 
> ICCRG community and we can receive any feedback from the you 
> all (at http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG 
> it is remarked that one should send an email to the chairs 
> requesting that the ICCRG perform a review of the document)
> 
> Best Regards,
> 
> The authors
> Lochin, Emmanuel ([email-masked]) Lopez Pacheco, 
> Dino ([email-masked]) Sathiaseelan, Arjuna 
> ([email-masked])
> 
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 

From: [email-masked] (Murari Sridharan)
Date: Fri Sep 23 02:56:56 2011
Subject: [Iccrg] Meeting in Taipei
Message-ID: <[email-masked]>

Folks,

We haven't yet proposed to meet at the Taipei IETF. Is there enough interest to meet there or should we meet instead in Paris? I will be there and we can hold the meeting if there is sufficient interest.

Thanks
M & M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20110923/67880faf/attachment.html
>From [email-masked]  Mon Sep 26 09:12:06 2011
From: [email-masked] (Murari Sridharan)
Date: Mon Sep 26 09:10:28 2011
Subject: [Iccrg] RE: On the deployment of Explicit Rate Notification
	protocols
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

+iccrg

-----Original Message-----
From: Dino LOPEZ [mailto:[email-masked]] 
Sent: Monday, September 26, 2011 1:07 AM
To: [email-masked]; Murari Sridharan
Subject: On the deployment of Explicit Rate Notification protocols

Dear ICCRG chairs,

We have submitted a new Internet draft which provides an architecture to allow the deployment of congestion control protocols with explicit rate notification from forwarding devices (Explicit Rate Notification protocols).

This draft is currently available at
http://www.ietf.org/internet-drafts/draft-lopez-ietf-tsvwg-ipern-00.txt

We will be grateful if you can relay this information to the ICCRG community and we can receive any feedback from the you all (at http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG it is remarked that one should send an email to the chairs requesting that the ICCRG perform a review of the document)

Best Regards,

The authors
Lochin, Emmanuel ([email-masked]) Lopez Pacheco, Dino ([email-masked]) Sathiaseelan, Arjuna ([email-masked])

From: [email-masked] (Lars Eggert)
Date: Thu Sep 22 14:47:22 2011
Subject: [Iccrg] Re: [tmrg] Folding TMRG into ICCRG
In-Reply-To: <[email-masked]>
References: <BANLkTi=[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

as discussed, sounds good to me. Please let me know when to make this change to the charter.

Lars

On 2011-9-14, at 5:57, Lachlan Andrew wrote:

> Greetings all,
> 
> To streamline operations, it has been proposed that the Traffic
> Modeling Research Group (TMRG) be absorbed into the Internet
> Congestion Control Research Group (ICCRG).  The goals of the two
> groups are closely aligned, and both groups could do with the extra
> activity.
> 
> The main current activity of the TMRG is the development by David
> Hayes at Swinburne of a TCP test suite, including an  ns2
> implementation.  This will continue unchanged if it is absorbed.
> 
> If anyone has opinions for or against this merger, please discuss it
> on the list.
> 
> 
> If people approve, the remaining task is to modify the ICCRG charter
> <http://irtf.org/iccrg> to include the tasks of the TMRG
> <http://irtf.org/tmrg>.  That is helped by the fact that much of the
> TMRG charter lists what it is *not* chartered to do.  Most of the
> scope of TMRG could be incorporated into ICCRG by changing the ICCRG
> charter to replace
>    "It is difficult therefore to compare like with like."
> by
>    "It is difficult therefore to compare like with like.  One goal of
> the ICCRG is to improve our methods for evaluating transport
> protocols.  To this end, a set of simulation (or other) test suites
> will be developed."
> 
> This makes no mention of the earlier goal of "a survey of models used
> in simulations, analysis, and experiments for the evaluation of
> transport protocols".  I don't think anyone is pushing to write a
> survey, so I don't think that needs to be mentioned.
> 
> Cheers,
> Lachlan (TMRG chair)
> 
> --
> Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
> Swinburne University of Technology, Melbourne, Australia
> <http://caia.swin.edu.au/cv/landrew>
> Ph +61 3 9214 4837
> _______________________________________________
> tmrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/tmrg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20110922/64f4981a/smime.bin
>From [email-masked]  Thu Sep 22 14:54:57 2011
From: [email-masked] (Michael Welzl)
Date: Thu Sep 22 14:53:30 2011
Subject: [Iccrg] Re: [tmrg] Folding TMRG into ICCRG
In-Reply-To: <[email-masked]>
References: <BANLkTi=[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Fine with me (as long as noone's going to hold us liable if the test 
suite work gets stuck again.... I hope it won't  :-)  )

Cheers,
Michael

On 9/22/11 3:48 PM, Lars Eggert wrote:
> Hi,
>
> as discussed, sounds good to me. Please let me know when to make this change to the charter.
>
> Lars
>
>
> On 2011-9-14, at 5:57, Lachlan Andrew wrote:
>
>> Greetings all,
>>
>> To streamline operations, it has been proposed that the Traffic
>> Modeling Research Group (TMRG) be absorbed into the Internet
>> Congestion Control Research Group (ICCRG).  The goals of the two
>> groups are closely aligned, and both groups could do with the extra
>> activity.
>>
>> The main current activity of the TMRG is the development by David
>> Hayes at Swinburne of a TCP test suite, including an  ns2
>> implementation.  This will continue unchanged if it is absorbed.
>>
>> If anyone has opinions for or against this merger, please discuss it
>> on the list.
>>
>>
>> If people approve, the remaining task is to modify the ICCRG charter
>> <http://irtf.org/iccrg>  to include the tasks of the TMRG
>> <http://irtf.org/tmrg>.  That is helped by the fact that much of the
>> TMRG charter lists what it is *not* chartered to do.  Most of the
>> scope of TMRG could be incorporated into ICCRG by changing the ICCRG
>> charter to replace
>>     "It is difficult therefore to compare like with like."
>> by
>>     "It is difficult therefore to compare like with like.  One goal of
>> the ICCRG is to improve our methods for evaluating transport
>> protocols.  To this end, a set of simulation (or other) test suites
>> will be developed."
>>
>> This makes no mention of the earlier goal of "a survey of models used
>> in simulations, analysis, and experiments for the evaluation of
>> transport protocols".  I don't think anyone is pushing to write a
>> survey, so I don't think that needs to be mentioned.
>>
>> Cheers,
>> Lachlan (TMRG chair)
>>
>> --
>> Lachlan Andrew  Centre for Advanced Internet Architectures (CAIA)
>> Swinburne University of Technology, Melbourne, Australia
>> <http://caia.swin.edu.au/cv/landrew>
>> Ph +61 3 9214 4837
>> _______________________________________________
>> tmrg mailing list
>> [email-masked]
>> https://www.irtf.org/mailman/listinfo/tmrg
>
>
> _______________________________________________
> tmrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/tmrg

From: [email-masked] (Michael Welzl)
Date: Thu Sep 22 14:39:10 2011
Subject: [Iccrg] Aggregate congestion control
Message-ID: <[email-masked]>

Hi all!

Ideas for aggregate congestion control tend to pop up every now and then 
- e.g. there's an old paper on doing this as a defense against DoS at:
http://ccr.sigcomm.org/archive/ccr-toc/ccr-toc-2002.html (vol 32 no 3, 
search for "aggregates" on the page)

And there were papers that used TFRC (turned into "CP"):
D. E. Ott, T. Sparks, and K. Mayer-Patel. Aggregate Congestion Control 
for Distributed Multimedia Applications. In IEEE Infocom 2004, Hong Kong.
...and MulTCP (turned into "PA-MulTCP"):
F.-C. Kuo and X. Fu. Probe-Aided MulTCP: an aggregate congestion control 
mechanism. SIGCOMM Comput. Commun. Rev., 38(1):17?28, 2008.

This work focuses on traffic engineering, but is also about controlling 
aggregates in a way:
http://nms.csail.mit.edu/projects/texcp/

And this paper, for instance, introduces an XCP-based PEP for a path 
segment, to improve satellite communications:
http://www.isi.edu/isi-xcp/docs/kapoor-pep-gi2005.final.pdf
..., including the statement: "There is a one-to-one mapping between TCP 
and PEP connections. We did not implement multiplexing of TCP 
connections, mainly for simplicity. It remains a promising direction for 
future work."

There's got to be more that I don't know about (and I'd be thankful for 
pointers). But I'm mostly interested in the general perception - is 
aggregate-based congestion control regarded as a promising direction? 
(why?) As futile? (why?) Is anybody actually deploying an aggregate 
congestion control based solution? I'd just like to hear some thoughts.

Cheers,
Michael

From: [email-masked] (Lachlan Andrew)
Date: Wed Sep 14 03:57:01 2011
Subject: [Iccrg] Folding TMRG into ICCRG
In-Reply-To: <BANLkTi=[email-masked]>
References: <BANLkTi=[email-masked]>
Message-ID: <[email-masked]>

Greetings all,

To streamline operations, it has been proposed that the Traffic
Modeling Research Group (TMRG) be absorbed into the Internet
Congestion Control Research Group (ICCRG).  The goals of the two
groups are closely aligned, and both groups could do with the extra
activity.

The main current activity of the TMRG is the development by David
Hayes at Swinburne of a TCP test suite, including an  ns2
implementation.  This will continue unchanged if it is absorbed.

If anyone has opinions for or against this merger, please discuss it
on the list.

If people approve, the remaining task is to modify the ICCRG charter
<http://irtf.org/iccrg> to include the tasks of the TMRG
<http://irtf.org/tmrg>.  That is helped by the fact that much of the
TMRG charter lists what it is *not* chartered to do. ?Most of the
scope of TMRG could be incorporated into ICCRG by changing the ICCRG
charter to replace
? ?"It is difficult therefore to compare like with like."
by
? ?"It is difficult therefore to compare like with like. ?One goal of
the ICCRG is to improve our methods for evaluating transport
protocols. ?To this end, a set of simulation (or other) test suites
will be developed."

This makes no mention of the earlier goal of "a survey of models used
in simulations, analysis, and experiments for the evaluation of
transport protocols". ?I don't think anyone is pushing to write a
survey, so I don't think that needs to be mentioned.

Cheers,
Lachlan (TMRG chair)

--
Lachlan Andrew? Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew>
Ph +61 3 9214 4837

From: [email-masked] (Mirja Kuehlewind)
Date: Tue Sep 13 16:55:28 2011
Subject: [Iccrg] Can TCP stay in slow start 'for ever'?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <CAK6E8=cwP4TKRMU=[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Bob,

this looks like its implemented in Linux (2.6.26):

/* RFC2861, slow part. Adjust cwnd, after it was not full during one rto.
 * As additional protections, we do not touch cwnd in retransmission phases,
 * and if application hit its sndbuf limit recently.
 */
void tcp_cwnd_application_limited(struct sock *sk)
{
	struct tcp_sock *tp = tcp_sk(sk);

	if (inet_csk(sk)->icsk_ca_state == TCP_CA_Open &&
	    sk->sk_socket && !test_bit(SOCK_NOSPACE, &sk->sk_socket->flags)) {
		/* Limited by application or receiver window. */
		u32 init_win = tcp_init_cwnd(tp, __sk_dst_get(sk));
		u32 win_used = max(tp->snd_cwnd_used, init_win);
		if (win_used < tp->snd_cwnd) {
			tp->snd_ssthresh = tcp_current_ssthresh(sk);
			tp->snd_cwnd = (tp->snd_cwnd + win_used) >> 1;
		}
		tp->snd_cwnd_used = 0;
	}
	tp->snd_cwnd_stamp = tcp_time_stamp;
}

Mirja

On Friday 09 September 2011 21:20:57 Bob Briscoe wrote:
> Yuchung,
>
> Tx for this too.
>
> At 17:44 09/09/2011, Yuchung Cheng wrote:
> >The Linux 2.6 or later fully implements this RFC.
> >
> >For app-limit part, an ACK does not increase cwnd in SS unless the
> >cwnd was fully utilized.
>
> I'll look at the code, but if you have already looked, do you know
> whether it also ages out ssthresh and decays cwnd if it can, as shown
> in the second part of the pseudocode in S.3.2 of RFC2861?
>
> >Interestingly, some systems turning off the cwnd restart after idle
> >feature (in Linux or other OSes). This may generate unpleasant
> >line-rate bursts like Bob's video-download example.
> >http://www.cs.princeton.edu/~jrex/papers/snap10.pdf
>
> OK - I found the part of the paper about burst after idle problems
> (interesting paper BTW), but you'll see I'm more interested in the
> app-limited behaviour part right now.
>
> Cheers
>
>
> Bob
>
>
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja K?hlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

From: [email-masked] (Ingemar Johansson S)
Date: Mon Sep 12 06:54:19 2011
Subject: [Iccrg] RE: [conex] ECN in TCP and CWND
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi

Thanks, and really sorry for my delayed response, seems like my mailbox and mind is bloated these days :-)
Thanks for the reply, I double checked our TCP implementation and it seems then to be in order even though I find it a bit odd.
I will have a look at  
 http://tools.ietf.org/html/draft-mathis-tcpm-proportional-rate-reduction-00
later on, get the feeling that is is related to DCTCP or ?

Again, thanks for the help.
/Ingemar

> -----Original Message-----
> From: Scheffenegger, Richard [mailto:[email-masked]] 
> Sent: den 22 augusti 2011 15:04
> To: Ingemar Johansson S; [email-masked]
> Cc: ConEx IETF list
> Subject: RE: [conex] ECN in TCP and CWND
> 
> Hi Ingemar,
> 
> I believe there was a very similar question recently in TCPM, 
> revolving around TCP-NCR, i.e.
> 
> http://www.ietf.org/mail-archive/web/tcpm/current/msg06528.html
> 
> 
> My summary was that RFC5681 does allow cwnd to increase 
> whenever an ACK acks new data (as would be the case with 
> ECN); however, the consensus back then was that cwnd should 
> not increase during "exceptional" events (reordering, loss 
> recovery, ecn rtt), even though that may hinder tcp from 
> throttling up when that may be safe...
> 
> OTOH, if cwnd is held constant during such events, particular 
> loss recovery may not complete without RTO (and subsequent 
> slow start), or cwnd may reduce to (and kept at) 1 segment 
> for extended periods of time...
> 
> But your observation, that many implementations will actually 
> increase cwnd after the cwnd reduction event, was made then too. 
> 
> Further note, that this particular behavior may get addressed 
> with draft-mathis-tcpm-proportional-rate-reduction-00, as the 
> cwnd reduction will be spaced out over ~1RTT -  basically a 
> new ACK will not necessarily trigger the sending of a new 
> data segment (and not increase cwnd), when PRR is active.
> 
> 
> But you may want to take this question to the tcpm group too...
> 
> Best regards,
> 
> 
> 
> Richard Scheffenegger
> 
> > -----Original Message-----
> > From: Ingemar Johansson S [mailto:[email-masked]]
> > Sent: Montag, 01. August 2011 19:13
> > To: [email-masked]
> > Cc: ConEx IETF list
> > Subject: [conex] ECN in TCP and CWND
> > 
> > Hi
> > 
> > I am digging in an experimental ECN for TCP implemementation. It is 
> > supposed to be implemented according to RFC3168.
> > 
> > As I understand things "TCP should not react to congestion 
> indications 
> > more than once every window of data" (6.1.3 in RFC3168) 
> Sofar so good, 
> > sounds very reasonable.
> > But what about CWND?, should it be allowed to increase during this 
> > time?.
> > 
> > To me it sounds most reasonable to _not_ allow the CWND to increase 
> > during the time that congestion indications are ingored but 
> the code I 
> > am staring at does not behave in this way.
> > 
> > 
> > What is the correct behavior ?
> > 
> > Regards
> > Ingemar
> > =================================
> > INGEMAR JOHANSSON  M.Sc.
> > Senior Researcher
> > 
> > Ericsson AB
> > Wireless Area Networks
> > Labratoriegr?nd 11
> > 971 28, Lule?, Sweden
> > Phone +46-1071 43042
> > SMS/MMS +46-73 078 3289
> > [email-masked]
> > www.ericsson.com
> > Visit http://labs.ericsson.com !
> > =================================
> > _______________________________________________
> > conex mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/conex
> 
>From [email-masked]  Mon Sep 12 12:49:39 2011
From: [email-masked] (Arjuna Sathiaseelan)
Date: Mon Sep 12 12:49:53 2011
Subject: [Iccrg] Re: Can TCP stay in slow start 'for ever'?
Message-ID: <CAPaG1A=[email-masked]>

Dear Bob,
  Apart from Debian 2.6.18-4-686, I am quite sure there are no other
implementations that have RFC 2861. Interestingly, we have a PhD
student who has been looking into the issues related to app-limited
(data-limited) senders and the problems associated with RFC 2861 and
Standard TCP (RFC 2581,RFC5681). We presented a draft to the TCPM
sometime ago ( http://tools.ietf.org/html/draft-fairhurst-tcpm-newcwv-01)
on this.

If you need any info, let me know. I am happy to discuss. thanks

Regards
Arjuna

---------- Forwarded message ----------
From: <[email-masked]>
Date: Sat, Sep 10, 2011 at 12:01 PM
Subject: Iccrg Digest, Vol 68, Issue 1
To: [email-masked]

Send Iccrg mailing list submissions to
? ? ? ?[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
? ? ? ?http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
or, via email, send a message with subject or body 'help' to
? ? ? ?[email-masked]

You can reach the person managing the list at
? ? ? ?[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Iccrg digest..."

Today's Topics:

? 1. Can TCP stay in slow start 'for ever'? (Bob Briscoe)
? 2. Re: Can TCP stay in slow start 'for ever'? (Tim Shepard)
? 3. Re: Can TCP stay in slow start 'for ever'? (Bob Briscoe)
? 4. Re: Can TCP stay in slow start 'for ever'? (Tim Shepard)
? 5. Re: Can TCP stay in slow start 'for ever'? (Yuchung Cheng)
? 6. Re: Can TCP stay in slow start 'for ever'? (Bob Briscoe)
? 7. Re: Can TCP stay in slow start 'for ever'? (Bob Briscoe)

----------------------------------------------------------------------

Message: 1
Date: Fri, 09 Sep 2011 12:07:23 +0100
From: Bob Briscoe <[email-masked]>
Subject: [Iccrg] Can TCP stay in slow start 'for ever'?
To: iccrg IRTF list <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"; format=flowed

Folks,

It seems the specs [RFC2581, RFC5681] allow/encourage the behaviour
described below. Does anyone know whether implementers typically put
in additional checks and balances to stop this?

If the source limits the data feeding into a TCP connection to a
fairly constant low rate,
and if it initially sets ssthresh arbitrarily high [RFC2581, RFC5681]
and if the receiver advertises a huge rwnd
then cwnd will continue to grow exponentially until it hits the
arbitrarily high value of ssthresh, even though the app isn't using
anything like this window.

Then, if the app suddenly gets a burst of data to send, the source
TCP would jump instantily to line rate, which might be a step-change
of many orders of magnitude.

After one or two RTT, the sending TCP would have to do fast
retransmit/fast recovery with a halving of cwnd per RTT. In the mean
time, the source would be continually dumping huge amounts of excess
data into network buffers. This might continue for half a dozen or
more halvings - one per RTT - to get back down to the operating point
of the network path (which might be just above the rate it had
originally been limiting itself to).

Given there is a lot more app-limiting of TCP connections these days
(e.g. for video), this would seem to be a potential issue.

Bob

________________________________________________________________
Bob Briscoe, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?BT Innovate & Design

------------------------------

Message: 2
Date: Fri, 09 Sep 2011 08:25:39 -0400
From: Tim Shepard <[email-masked]>
Subject: Re: [Iccrg] Can TCP stay in slow start 'for ever'?
To: Bob Briscoe <[email-masked]>
Cc: iccrg IRTF list <[email-masked]>
Message-ID: <[email-masked]>

Bob,

I believe RFC 2861 (IETF status "EXPERIMENTAL") is on exactly this topic.

There's also the "Restarting Idle Connections" section in RFC 5681
(IETF status DRAFT STANDARD), but from my quick re-read of that
section just now that does not seem to fully answer your question.

(And there may be more relevant RFCs to point at that I'm not aware of
?at the moment.)

I'm not sure what modern TCP implementations actually do about this.
But I know there has been some awareness of this issue before. ?If you
don't get a complete enough answer on this list, you might also want
to ask on the tcpm mailing list.

? ? ? ? ? ? ? ? ? ? ? ?-Tim Shepard
? ? ? ? ? ? ? ? ? ? ? ? [email-masked]

------------------------------

Message: 3
Date: Fri, 09 Sep 2011 15:56:38 +0100
From: Bob Briscoe <[email-masked]>
Subject: Re: [Iccrg] Can TCP stay in slow start 'for ever'?
To: Tim Shepard <[email-masked]>
Cc: iccrg IRTF list <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"; format=flowed

Tim,

Thank you. That's exactly what I was looking for. I knew of RFC2861,
but only remembered the restart after idle part. I hadn't realised it
also covered non-idle but app-limited periods. The algo looks reasonable.

Yes, I would still be interested in whether anyone knows the
implementation status of RFC2861.

Bob

At 13:25 09/09/2011, Tim Shepard wrote:

>Bob,
>
>I believe RFC 2861 (IETF status "EXPERIMENTAL") is on exactly this topic.
>
>There's also the "Restarting Idle Connections" section in RFC 5681
>(IETF status DRAFT STANDARD), but from my quick re-read of that
>section just now that does not seem to fully answer your question.
>
>(And there may be more relevant RFCs to point at that I'm not aware of
> ?at the moment.)
>
>I'm not sure what modern TCP implementations actually do about this.
>But I know there has been some awareness of this issue before. ?If you
>don't get a complete enough answer on this list, you might also want
>to ask on the tcpm mailing list.
>
> ? ? ? ? ? ? ? ? ? ? ? ? -Tim Shepard
> ? ? ? ? ? ? ? ? ? ? ? ? [email-masked]

________________________________________________________________
Bob Briscoe, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?BT Innovate & Design

------------------------------

Message: 4
Date: Fri, 09 Sep 2011 11:18:42 -0400
From: Tim Shepard <[email-masked]>
Subject: Re: [Iccrg] Can TCP stay in slow start 'for ever'?
To: Bob Briscoe <[email-masked]>
Cc: iccrg IRTF list <[email-masked]>
Message-ID: <[email-masked]>

A thread on the tcpm mailing list from 2007 seems relevent.

Here is a message in the middle of that thread... walk the tree of
followups to see messages which discuss the status (as of 2007) of
this stuff in a couple of widely-used TCP implementations:

? ? http://www.ietf.org/mail-archive/web/tcpm/current/msg02868.html

I don't know if the code that is out there now adequately handles the
particular issue you raisd (connection never goes idle but is not
fully making use of the cwnd it is rapidly growing).

? ? ? ? ? ? ? ? ? ? ? ?-Tim Shepard
? ? ? ? ? ? ? ? ? ? ? ? [email-masked]

------------------------------

Message: 5
Date: Fri, 9 Sep 2011 09:44:28 -0700
From: Yuchung Cheng <[email-masked]>
Subject: Re: [Iccrg] Can TCP stay in slow start 'for ever'?
To: Tim Shepard <[email-masked]>
Cc: iccrg IRTF list <[email-masked]>
Message-ID:
? ? ? ?<CAK6E8=cwP4TKRMU=[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Sep 9, 2011 at 8:18 AM, Tim Shepard <[email-masked]> wrote:
>
>
> A thread on the tcpm mailing list from 2007 seems relevent.
>
> Here is a message in the middle of that thread... walk the tree of
> followups to see messages which discuss the status (as of 2007) of
> this stuff in a couple of widely-used TCP implementations:
>
> ? ? http://www.ietf.org/mail-archive/web/tcpm/current/msg02868.html
>
>
> I don't know if the code that is out there now adequately handles the
> particular issue you raisd (connection never goes idle but is not
> fully making use of the cwnd it is rapidly growing).

The Linux 2.6 or later fully implements this RFC.

For app-limit part, an ACK does not increase cwnd in SS unless the
cwnd was fully utilized.

For idle connection part, Linux halves the cwnd every RTO after last
transmission. But the kernel offers a system knob to disable this.

Interestingly, some systems turning off the cwnd restart after idle
feature (in Linux or other OSes). This may generate unpleasant
line-rate bursts like Bob's video-download example.
http://www.cs.princeton.edu/~jrex/papers/snap10.pdf

------------------------------

Message: 6
Date: Fri, 09 Sep 2011 19:52:22 +0100
From: Bob Briscoe <[email-masked]>
Subject: Re: [Iccrg] Can TCP stay in slow start 'for ever'?
To: Tim Shepard <[email-masked]>
Cc: iccrg IRTF list <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"; format=flowed

Tim,

Thanks for that. Spot on the info I needed.

It's amazing how searching has evolved - I don't even need to search
myself any more! I just send a request to a mailing list and some
other nice person does it for me :)

Cheers

Bob

At 16:18 09/09/2011, Tim Shepard wrote:

>A thread on the tcpm mailing list from 2007 seems relevent.
>
>Here is a message in the middle of that thread... walk the tree of
>followups to see messages which discuss the status (as of 2007) of
>this stuff in a couple of widely-used TCP implementations:
>
> ? ? ?http://www.ietf.org/mail-archive/web/tcpm/current/msg02868.html
>
>
>I don't know if the code that is out there now adequately handles the
>particular issue you raisd (connection never goes idle but is not
>fully making use of the cwnd it is rapidly growing).
>
> ? ? ? ? ? ? ? ? ? ? ? ? -Tim Shepard
> ? ? ? ? ? ? ? ? ? ? ? ? [email-masked]

________________________________________________________________
Bob Briscoe, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?BT Innovate & Design

------------------------------

Message: 7
Date: Fri, 09 Sep 2011 20:20:57 +0100
From: Bob Briscoe <[email-masked]>
Subject: Re: [Iccrg] Can TCP stay in slow start 'for ever'?
To: Yuchung Cheng <[email-masked]>
Cc: iccrg IRTF list <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"; format=flowed

Yuchung,

Tx for this too.

At 17:44 09/09/2011, Yuchung Cheng wrote:
>The Linux 2.6 or later fully implements this RFC.
>
>For app-limit part, an ACK does not increase cwnd in SS unless the
>cwnd was fully utilized.

I'll look at the code, but if you have already looked, do you know
whether it also ages out ssthresh and decays cwnd if it can, as shown
in the second part of the pseudocode in S.3.2 of RFC2861?

>Interestingly, some systems turning off the cwnd restart after idle
>feature (in Linux or other OSes). This may generate unpleasant
>line-rate bursts like Bob's video-download example.
>http://www.cs.princeton.edu/~jrex/papers/snap10.pdf

OK - I found the part of the paper about burst after idle problems
(interesting paper BTW), but you'll see I'm more interested in the
app-limited behaviour part right now.

Cheers

Bob

________________________________________________________________
Bob Briscoe, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?BT Innovate & Design

------------------------------

_______________________________________________
Iccrg mailing list
[email-masked]
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

End of Iccrg Digest, Vol 68, Issue 1
************************************

From: [email-masked] (Bob Briscoe)
Date: Fri Sep  9 20:21:15 2011
Subject: [Iccrg] Can TCP stay in slow start 'for ever'?
In-Reply-To: <CAK6E8=cwP4TKRMU=[email-masked] mail.com>
References: <[email-masked]> <[email-masked]> <CAK6E8=cwP4TKRMU=[email-masked]>
Message-ID: <[email-masked]>

Yuchung,

Tx for this too.

At 17:44 09/09/2011, Yuchung Cheng wrote:
>The Linux 2.6 or later fully implements this RFC.
>
>For app-limit part, an ACK does not increase cwnd in SS unless the
>cwnd was fully utilized.

I'll look at the code, but if you have already looked, do you know 
whether it also ages out ssthresh and decays cwnd if it can, as shown 
in the second part of the pseudocode in S.3.2 of RFC2861?

>Interestingly, some systems turning off the cwnd restart after idle
>feature (in Linux or other OSes). This may generate unpleasant
>line-rate bursts like Bob's video-download example.
>http://www.cs.princeton.edu/~jrex/papers/snap10.pdf

OK - I found the part of the paper about burst after idle problems 
(interesting paper BTW), but you'll see I'm more interested in the 
app-limited behaviour part right now.

Cheers

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design 

From: [email-masked] (Bob Briscoe)
Date: Fri Sep  9 19:53:45 2011
Subject: [Iccrg] Can TCP stay in slow start 'for ever'?
In-Reply-To: <[email-masked]>
References: <Your message of Fri, 09 Sep 2011 15:56:38 +0100. <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Tim,

Thanks for that. Spot on the info I needed.

It's amazing how searching has evolved - I don't even need to search 
myself any more! I just send a request to a mailing list and some 
other nice person does it for me :)

Cheers

Bob

At 16:18 09/09/2011, Tim Shepard wrote:

>A thread on the tcpm mailing list from 2007 seems relevent.
>
>Here is a message in the middle of that thread... walk the tree of
>followups to see messages which discuss the status (as of 2007) of
>this stuff in a couple of widely-used TCP implementations:
>
>      http://www.ietf.org/mail-archive/web/tcpm/current/msg02868.html
>
>
>I don't know if the code that is out there now adequately handles the
>particular issue you raisd (connection never goes idle but is not
>fully making use of the cwnd it is rapidly growing).
>
>                         -Tim Shepard
>                         [email-masked]

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design 

From: [email-masked] (Yuchung Cheng)
Date: Fri Sep  9 17:45:03 2011
Subject: [Iccrg] Can TCP stay in slow start 'for ever'?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <CAK6E8=cwP4TKRMU=[email-masked]>

On Fri, Sep 9, 2011 at 8:18 AM, Tim Shepard <[email-masked]> wrote:
>
>
> A thread on the tcpm mailing list from 2007 seems relevent.
>
> Here is a message in the middle of that thread... walk the tree of
> followups to see messages which discuss the status (as of 2007) of
> this stuff in a couple of widely-used TCP implementations:
>
> ? ? http://www.ietf.org/mail-archive/web/tcpm/current/msg02868.html
>
>
> I don't know if the code that is out there now adequately handles the
> particular issue you raisd (connection never goes idle but is not
> fully making use of the cwnd it is rapidly growing).

The Linux 2.6 or later fully implements this RFC.

For app-limit part, an ACK does not increase cwnd in SS unless the
cwnd was fully utilized.

For idle connection part, Linux halves the cwnd every RTO after last
transmission. But the kernel offers a system knob to disable this.

Interestingly, some systems turning off the cwnd restart after idle
feature (in Linux or other OSes). This may generate unpleasant
line-rate bursts like Bob's video-download example.
http://www.cs.princeton.edu/~jrex/papers/snap10.pdf

From: [email-masked] (Tim Shepard)
Date: Fri Sep  9 16:19:15 2011
Subject: [Iccrg] Can TCP stay in slow start 'for ever'?
In-Reply-To: Your message of Fri, 09 Sep 2011 15:56:38 +0100. <[email-masked]>
Message-ID: <[email-masked]>

A thread on the tcpm mailing list from 2007 seems relevent.

Here is a message in the middle of that thread... walk the tree of
followups to see messages which discuss the status (as of 2007) of
this stuff in a couple of widely-used TCP implementations:

     http://www.ietf.org/mail-archive/web/tcpm/current/msg02868.html

I don't know if the code that is out there now adequately handles the
particular issue you raisd (connection never goes idle but is not
fully making use of the cwnd it is rapidly growing).

			-Tim Shepard
			 [email-masked]

From: [email-masked] (Bob Briscoe)
Date: Fri Sep  9 15:56:57 2011
Subject: [Iccrg] Can TCP stay in slow start 'for ever'?
In-Reply-To: <[email-masked]>
References: <Your message of Fri, 09 Sep 2011 12:07:23 +0100. <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Tim,

Thank you. That's exactly what I was looking for. I knew of RFC2861, 
but only remembered the restart after idle part. I hadn't realised it 
also covered non-idle but app-limited periods. The algo looks reasonable.

Yes, I would still be interested in whether anyone knows the 
implementation status of RFC2861.

Bob

At 13:25 09/09/2011, Tim Shepard wrote:

>Bob,
>
>I believe RFC 2861 (IETF status "EXPERIMENTAL") is on exactly this topic.
>
>There's also the "Restarting Idle Connections" section in RFC 5681
>(IETF status DRAFT STANDARD), but from my quick re-read of that
>section just now that does not seem to fully answer your question.
>
>(And there may be more relevant RFCs to point at that I'm not aware of
>  at the moment.)
>
>I'm not sure what modern TCP implementations actually do about this.
>But I know there has been some awareness of this issue before.  If you
>don't get a complete enough answer on this list, you might also want
>to ask on the tcpm mailing list.
>
>                         -Tim Shepard
>                         [email-masked]

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design 

From: [email-masked] (Tim Shepard)
Date: Fri Sep  9 13:26:25 2011
Subject: [Iccrg] Can TCP stay in slow start 'for ever'?
In-Reply-To: Your message of Fri, 09 Sep 2011 12:07:23 +0100. <[email-masked]>
Message-ID: <[email-masked]>

Bob, 

I believe RFC 2861 (IETF status "EXPERIMENTAL") is on exactly this topic.

There's also the "Restarting Idle Connections" section in RFC 5681
(IETF status DRAFT STANDARD), but from my quick re-read of that
section just now that does not seem to fully answer your question.

(And there may be more relevant RFCs to point at that I'm not aware of
 at the moment.)

I'm not sure what modern TCP implementations actually do about this.
But I know there has been some awareness of this issue before.  If you
don't get a complete enough answer on this list, you might also want
to ask on the tcpm mailing list.

			-Tim Shepard
			 [email-masked]

From: [email-masked] (Bob Briscoe)
Date: Fri Sep  9 12:09:52 2011
Subject: [Iccrg] Can TCP stay in slow start 'for ever'?
Message-ID: <[email-masked]>

Folks,

It seems the specs [RFC2581, RFC5681] allow/encourage the behaviour 
described below. Does anyone know whether implementers typically put 
in additional checks and balances to stop this?

If the source limits the data feeding into a TCP connection to a 
fairly constant low rate,
and if it initially sets ssthresh arbitrarily high [RFC2581, RFC5681]
and if the receiver advertises a huge rwnd
then cwnd will continue to grow exponentially until it hits the 
arbitrarily high value of ssthresh, even though the app isn't using 
anything like this window.

Then, if the app suddenly gets a burst of data to send, the source 
TCP would jump instantily to line rate, which might be a step-change 
of many orders of magnitude.

After one or two RTT, the sending TCP would have to do fast 
retransmit/fast recovery with a halving of cwnd per RTT. In the mean 
time, the source would be continually dumping huge amounts of excess 
data into network buffers. This might continue for half a dozen or 
more halvings - one per RTT - to get back down to the operating point 
of the network path (which might be just above the rate it had 
originally been limiting itself to).

Given there is a lot more app-limiting of TCP connections these days 
(e.g. for video), this would seem to be a potential issue.

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design