ietf
[Top] [All Lists]

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

2013-02-11 08:45:19
On 2013-01-24 23:35, Matt Mathis wrote:
Magnus,

In behalf of the draft-ietf-tcpm-initcwnd authors I publicly address
the comments in your IETF LC  review of draft-ietf-tcpm-initcwnd-06.

In regards to interactions between IW and real time traffic (your
points 1&2 below and echoed in Robert Spark's DISCUSS):

By design TCP creates queues to measure the bottleneck bandwidth.
Reducing the jitter for real time traffic is not a goal for TCP.
Although there are a number of TCP centric approaches for reducing
jitter, including reducing queue space, deploying AQM and limiting IW,
none are general nor work in all situations.   Furthermore if you
construct a scenario where one of these approaches seems to help, a
slight variation on that scenario will fail.  In the case of IW,
larger transactions will produce equally large queue occupancy later
on during slowstart or during bulk transfers.

This observation is borne out by the work of Ilpo Jarvinen et al.  See
http://www.tschofenig.priv.at/cc-workshop/irtf_iab-ccirtcpaper9.pdf
and the tcpm slides from IETF 84
http://www.ietf.org/proceedings/84/slides/slides-84-tcpm-11.

We have not attempted to measure IW10 impact on real time traffic,
however we have investigated over one year of historical performance
data for our Hangout/Talk application where we track both the startup
delay of an audio/video call as well as a jitter metric. Our data
shows no degradation in either metric as IW10 is deployed at Google
and elsewhere.  In fact, we see a steady improvement in our metrics,
even for the tail end of the users, which we attribute to generally
better connectivity.

As you noted, the only real solution to controlling jitter is to put
real time and throughput maximizing traffic into separate queues.
All other solutions have the property that they force implementers to
make tradeoffs between peak queuing delay and link utilization, and as
such are just workarounds that don't actually solve the root problem.
The real time community has finally come to understand this reality,
as reflected in the RMCAT charter.

These workarounds can be characterized as protecting RT traffic by
deliberately making TCP less aggressive than desired to quickly fill
the network.   Continuing to use these workarounds widens the gap
between actual application performance and raw network capacity.  This
fact is not lost on application developers and users who often observe
only slight application performance improvements after deploying
expensive faster networks, unless they take things under their own
control by opening multiple connections.  As we all know, this
approach undermines TCP's ability to control congestion.

Trying to make TCP compensate for the lack of segregated queueing (a
network problem) prevents correct solutions to problems caused by TCP
itself, namely it being too timid for most of todays networks.   Given
the wide discussion of bufferbloat and the need for traffic
segregation to support important RT applications, it is fairly likely
that the network problems will come to be solved and the solutions
widely deployed in the next few years.  A side benefit of these
changes to better support RT will be to further limit any possible
impact of IW10 on other Internet traffic.

Thanks for providing some more investigation material. Even from a TCP
perspective I think it is important as the experiment continues that one
include measurement data on how the one-way delay is affected as also
TCP flows carries "real-time" data.

To be clear, your answer has resulted in my having the position that not
going forward with IW10 is probably worse for the Internet than to not
do it.

There is clearly work to be done dealing with buffer-bloat but also the
reactions in the growing heterogeneous behavior of Internet paths. This
is an encouragement to people doing active work on this to continue.



In regards to your point 3, about client domains that experience
persistent problems with IW10.   We propose to add a sentence at the
end of section 12 (Usage and Deployment Recommendation): "Resolution
of these experiments and tighter specifications of the suggestions
here might be grounds for a future standards track document on the
same topic."

Ok, so you don't yet have even an experimental algorithm that you are
confident in auto performing this process yet. I think this is a bit
worrying, but consider the relative few that appears having such issues
according to your investigations I am willing to take the chance.


In regards to your point 4, clarify incentives in section 3 by
replacing end of the 2nd paragraph: "A larger initial window will
incentivize applications to use fewer concurrent TCP connections."
With: "If a larger initial window causes harm to any other flows then
local application tuning will reveal that fewer concurrent connections
yields better performance for some users.   Any content provider
deploying IW10 in conjunction with content distributed across multiple
domains is explicitly encouraged to perform measurement experiments to
detect such problems, and to consider reducing the number of
concurrent connections used to retrieve their content."

As this was really a guess for the future which was difficult to act on
I think the above is as well as I can see you do anything about my issues.

From my perspective I think this can be published as an experimental
with the proposed updates.

Cheers

Magnus


Other planned change to the draft as requested by IESG feedback:

Drop "Updates RFC 3390 and 5681" from the metadata.

This change answers the DISCUSSes posted by Brian Haberman and Ralph Droms.

I believe that together these chanes should address all of the IESG
DISCUSS items.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat
privacy and security as matters of life and death, because for some
users, they are.


On Thu, Dec 6, 2012 at 2:01 AM, Magnus Westerlund
<magnus(_dot_)westerlund(_at_)ericsson(_dot_)com> wrote:
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
ietf(_at_)ietf(_dot_)org mailing lists by 2012-12-10. Exceptionally, 
comments may be
sent to iesg(_at_)ietf(_dot_)org 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: 
magnus(_dot_)westerlund(_at_)ericsson(_dot_)com
----------------------------------------------------------------------





-- 

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: 
magnus(_dot_)westerlund(_at_)ericsson(_dot_)com
----------------------------------------------------------------------

<Prev in Thread] Current Thread [Next in Thread>
  • Re: Last Call: <draft-ietf-tcpm-initcwnd-06.txt> (Increasing TCP's Initial Window) to Experimental RFC, Magnus Westerlund <=