Subject: Re: [tcpm] summary of IW thoughts + way forward ? (at least a new subject line to stare at!)

From: Kacheong Poon <[email-masked]>
Date: Fri, 03 Dec 2010 00:31:56 +0800

On 12/ 1/10 01:05 AM, Mark Allman wrote:

> So, off-list I framed this to Joe and Aki.  Its basically Joe's
> idea, but with a few more details.  As such, Joe will no doubt
> correct it. :)  So, do something like this:
>
>    o On Jul/1 set IW=3 [i.e., RFC5681].  Also, start two counters for
>      each possible IW, 1--3: total number of connections using the
>      given IW and number of connections using that IW that
>      experienced loss in the initial window.

Using this proposal, does it mean that a host randomly picks a
value from 1 to IW_cur as the IW every time it starts a new TCP
connection (assuming no cache hit)?  Assuming IW=3 is really good
for every one.  This proposal automatically penalizes 2/3 of all
the connections as they use a sub-optimal IW value comparing to
the current default value.  Does anyone really think that IW < 3
makes sense in today's Internet?

Still assuming IW=3 is good for every one.  Suppose IW_cur is 4
and 5% of all connections are not doing good at IW=4.  Using this
proposal, only 23.75% (24% * 95%) of all connections benefit from
the IW increase and the rest is penalized.  50% of all connections
are worse than the current situation.  And then in the next month,
IW_cur will be decremented to 3.  Again 2/3 of all connections are
penalized comparing to today's Internet.  Then in the following
month, IW_cur is incremented to 4 again.  Story goes on.

I probably misunderstood this proposal.  The above cannot be
right since the goal is to make the overall user experience
better than today's situation, not worse....  Or are people really
thinking that IW=3 is too aggressive even though TCP almost always
send in burst of 3 or more segments?

-- 

					K. Poon.
					[email-masked]

---

From: Mark Allman <[email-masked]>
Date: Thu, 02 Dec 2010 12:30:11 -0500

> connection (assuming no cache hit)?

No.  It means that given that there is a natural variance in the amount
of data that will be available for transmission in the initial cwnd
we'll naturally end up with data at the different points.  (And, maybe
there is some small bit we have to do that says if we have total
connections like this ...

  IW=1 3
  IW=2 5
  IW=3 20K
  IW=4 30K

and things work fine at IW=3 and IW=4 then we can discount IW={1,2}
because there isn't enough data there.

But, you get the idea ... we're not turning the IW into a random
variable. 

allman

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 03 Dec 2010 01:50:10 +0800

> connections like this ...

Then I suppose this proposal probably boils down to only
checking IW_cur (the max) in most, if not all, hosts which
increasing the IW matters.  Otherwise, there is no reason
to increase it in the first place.  With Jerry's data, IW=10
is the correct number for Google since it affects ~5% (don't
remember the exact number) of all connections.

So maybe this WG can just tell folks to use whatever IW
value your site sees fit.  IETF only recommends IW=3 to
be used if your site does not know anything better.  You
know what value of IW to use better than anyone else on this
list.  There is no single good way which fits all sites on
how to determine the correct value of IW.  So use whatever
reasonable method which fits your site to decide on the value.

-- 

					K. Poon.

---

From: Jerry Chu <[email-masked]>
Date: Thu, 2 Dec 2010 11:43:03 -0800

Hey Kacheong, nice to hear from you!

> remember the exact number) of all connections.

That's how I feel too. I.e., you'll need only two counters rather
than IW*2 counters to track those connections that send the maxIW.
In case it eventually goes up to e.g., IW16 but then problem starts
showing up for IW15 due to, e.g., the rest of world switches to IW16,
you'll probably see that in connections using IW16. Yes going
back down a few steps (e.g., back to IW12) may take a while but the
chance of that happening is small.

Jerry

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>