Subject: Re: [tcpm] Last Call: <draft-ietf-tcpm-initcwnd-06.txt> (Increasing TCP's Initial Window) to Experimental RFC

From: Magnus Westerlund <[email-masked]>
Date: Thu, 6 Dec 2012 11:01:10 +0100

Hi,

I have reviewed draft-ietf-tcpm-initcwnd-06 and have some questions and
comments.

1) First of all the experiments done appear to cover the impact on other
applications, like measuring the RTT variations when using IW10 compared
to IW3. If one is interested in the impact this proposal have on
real-time traffic flows over a shared bottle-neck the variations in
queue time at the bottleneck combined with that flows seen loss rates
are the most important factors. As a sudden delay spike of sufficient
magnitude will most likely result in a real-time media packet being
late, i.e. late loss rather than being lost in the network there might
be significant impact on such traffic from these IW10 packet bursts.
Have I missed any material discussing this aspect?

All the latency figures in the parts I was looking at was discussing
cases when the object transfer takes longer time. But it appear obvious
that even with a 100 ms increased one-way transfer time for a packet is
the end of the initial window the total transfer goes faster compared to
the delay caused by growing the window.

2) If I assume that most users are behind buffer-bloated links the
introduction of IW10 on wide scale will additionally disrupt interactive
applications and cause increased delay and possible late loss depending
on application. Especially in combination with domain sharding. For
example a Swedish newspaper's website front page results in that more
than 40 TCP connections are opened in a current browser. If these all
was using IW10, the amount of packets being sent initially will grow
roughly from 40*3 = 120 to 40*10 = 400. There are some distribution over
time but still this likely results in a larger delay spike.

I don't quite know how I should consider this case. One stand point is
that the interactive application is anyway buggered and IW10 effects are
not making it significantly worse. The only remedy is queue separation
so that what ever happens with the web-downloads doesn't affect the
interactive traffic. Another is that it will make the existing situation
worse and we should try to avoid making it worse.

I think I am more in the first camp, but still the second one is
worrying to me. But I dare to guess that the performance gains might be
worth the issues, but without real progress on mitigation of the buffer
bloat issues for interactive real-time traffic this will add
significantly to the issues real-time has to face.

3) The documents talks in quite loose terms about what can be done to
avoid to continue cause issues for destinations which has issues with
IW10. However I think it is a bit unspecific here. I can see that a
content deliverer can have lists for destination address blocks that
they see issues with which configures the sending server side with a
lower IW value. It also talks about the clients can configure to keep
the window low initially to prevent an IW10 sender to clobber ones link
if that is known. My question here is if the recommendation for auto
detection and configuration can be made more explicit. Fortunately the
issues with misconfiguration in this cases is not that serious. But
otherwise there is commonly need to be quite careful with such auto
configs that affects the behavior.

4) I am also worried that the document is a bit to positive in regards
to that IW10 will reduce the domain sharding practice. I think the only
thing that can do is likely a new HTTP transport strata that shows that
significantly improved performance for multiple objects from the same
domain over fewer transport flows. Maybe SPDY + IW10 can provide such
incentive, but I don't think IW10 alone will do much.

Cheers

Magnus

On 2012-11-26 22:29, The IESG wrote:
> 
> The IESG has received a request from the TCP Maintenance and Minor
> Extensions WG (tcpm) to consider the following document:
> - 'Increasing TCP's Initial Window'
>   <draft-ietf-tcpm-initcwnd-06.txt> as Experimental RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2012-12-10. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>    This document proposes an experiment to increase the permitted TCP
>    initial window (IW) from between 2 and 4 segments, as specified in
>    RFC 3390, to 10 segments, with a fallback to the existing
>    recommendation when performance issues are detected. It discusses the
>    motivation behind the increase, the advantages and disadvantages of
>    the higher initial window, and presents results from several large
>    scale experiments showing that the higher initial window improves the
>    overall performance of many web services without resulting in a
>    congestion collapse. The document closes with a discussion of usage
>    and deployment for further experimental purpose recommended by the
>    IETF TCP Maintenance and Minor Extensions (TCPM) working group.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sat, 15 Dec 2012 19:16:35 -0800

Hi Magnus,

Thanks for the comments.
I think your points are valid. But, it's not very clear to me what you
would like to suggest authors.
IW10 might have an impact on real-time traffic. But, difficult point is we
are not very sure how much it is over the whole Internet. Do we ask authors
to do experiments to address the concerns you pointed out?
There will be situations where IW10 has negative impacts as well as
positive impacts.
But, I'm feeling it might be difficult to discuss this point without large
scale experiments.

Thanks,
--
Yoshifumi

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 Dec 2012 17:27:03 +0100

On 2012-12-16 04:16, Yoshifumi Nishida wrote:
> IW10 might have an impact on real-time traffic. But, difficult point is
> we are not very sure how much it is over the whole Internet. Do we ask
> authors to do experiments to address the concerns you pointed out? 

I agree. But I think the already performed experiments has failed to
look at the aspect of how much e2e delay has been affected by the usage
of IW10 for flow sharing the bottleneck or full path with the TCP flow.

> But, I'm feeling it might be difficult to discuss this point without
> large scale experiments.

That I am not convinced of. I would like to get some indication if they
simply failed to take this into account or that it was to difficult to
measure.

I agree that some of the below are difficult to address. Some will
require additional experimentation and evaluation. Something I think
will be required to answer when this is evaluated. Then some of it is
actually reasonably straightforward to discuss or clarify in the document.

I still expect the authors to answer my feedback.

Cheers

Magnus

> 
> Thanks,
> --
> Yoshifumi
> 
> On Thu, Dec 6, 2012 at 2:01 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>     Hi,
> 
>     > [email-masked] <mailto:[email-masked]> mailing lists by 2012-12-10.
>     Exceptionally, comments may be
>     > sent to [email-masked] <mailto:[email-masked]> instead. In either
>     case, please retain the
>     <mailto:[email-masked]>

-- 

Magnus Westerlund