<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7638.1">
<TITLE>RE: [Tmrg] Proposal to increase TCP initial CWND</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Well, the factor of increasing loss rate of "high-cwnd" single flow and in the same time suppressing the competing traffic for sqrt(increase_to_percent(in this case 5.79%)/increase_from_percent(in this case 3.94%)) will always be linearly dependent on the variable increase_to_percent. Anyway, if we introduce multiple flows with the increase start cwnd size, then they will become competing traffic for themselves, aside the flows which have low cwnd. Therefore, the mathematical model could become pretty complex because of the complex situation of multiple dependencies between the influences of each "high-cwnd" flow to all other flows. Maybe the "cheaper" solution is to get link characteristics from the actual data center, and simulate them to obtain some results.<BR>
<BR>
Greetings,<BR>
Milenkoski A.<BR>
<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: tmrg-interest-bounces@ICSI.Berkeley.EDU on behalf of Lachlan Andrew<BR>
Sent: Sun 7/18/2010 8:27 AM<BR>
To: tmrg; Nandita Dukkipati; Matt Mathis; Jerry Chu; Yuchung Cheng<BR>
Subject: [Tmrg] Proposal to increase TCP initial CWND<BR>
<BR>
Greetings TMRG folk,<BR>
<BR>
At the last IETF meeting, some folk from Google proposed increasing<BR>
the initial TCP CWND from the current value (2-4 depending on MSS) to<BR>
10. The current draft is at<BR>
<<A HREF="http://tools.ietf.org/html/draft-hkchu-tcpm-initcwnd-01">http://tools.ietf.org/html/draft-hkchu-tcpm-initcwnd-01</A>>.<BR>
<BR>
The discussion at the ICCRG meeting raised some modelling/evaluation<BR>
issues which fit well with the expertise at TMRG. Since TMRG is<BR>
chartered as a mailing-list-only RG, let's discuss this now in lieu of<BR>
a meeting at IETF 78 in Maastricht.<BR>
<BR>
The basic TMRG-related issue was: If a data centre changes a TCP<BR>
parameter for *its* flows, how can it estimate the degradation caused<BR>
to *other* flows sharing resources with these flows? Google is awash<BR>
with data, but it all shares the bias of coming from their data<BR>
centres. What models are appropriate to infer the impact on the<BR>
unmeasured flows?<BR>
<BR>
Sections 10.2 and 11 are the most relevant to TMRG.<BR>
<BR>
To start things off, here is one observation:<BR>
- An increase in retransmissions from 3.94% to 5.79% seems very<BR>
significant, if that rate reflects the loss rate. Although described<BR>
as a 1.85% increase, it seems likely to cause competing traffic to<BR>
slow down by a factor of sqrt(5.79/3.94). Moreover, that is the<BR>
increase in loss when (presumably) a *single* flow on that bottleneck<BR>
increases its initial window. How can we estimate the impact of *all*<BR>
flows increasing their initial windows?<BR>
<BR>
I hope this leads to a lively discussion.<BR>
<BR>
Cheers,<BR>
Lachlan<BR>
<BR>
--<BR>
Lachlan Andrew Centre for Advanced Internet Architectures (CAIA)<BR>
Swinburne University of Technology, Melbourne, Australia<BR>
<<A HREF="http://caia.swin.edu.au/cv/landrew">http://caia.swin.edu.au/cv/landrew</A>><BR>
Ph +61 3 9214 4837<BR>
<BR>
_______________________________________________<BR>
Tmrg-interest mailing list<BR>
Tmrg-interest@ICSI.Berkeley.EDU<BR>
<A HREF="http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest">http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest</A><BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>