Subject: [tcpm] Automatic IW draft posted

From: Joe Touch <[email-masked]>
Date: Thu, 23 Dec 2010 15:38:10 -0800

Hi, all,

A preliminary draft has been posted:

http://www.ietf.org/id/draft-touch-tcpm-automatic-iw-00.txt

It includes the algorithm and a lot of other details, some fleshed out 
(the intro), others as a list. The goal is to use this as a basis of 
initial discussion.

(I have not determined the author list yet, so it says TBD right now...)

Joe

---

From: Jerry Chu <[email-masked]>
Date: Sun, 26 Dec 2010 12:57:09 -0800

Hi Joe,

Thanks for the writeup. Your proposal seems like a good step toward
finding a permanent solution to the IW problem. The following are my
comments:

1. The long check period (e.g., one month) is necessary to allow
enough samples to avoid false negative/postives and ensure
stability/convergence. But many hosts today won't survive that long
period without a reboot, hence losing all the IW/counter statistics
and have to start over again. This includes not only most of the
client devices but many servers as well.

What this implies is basically the algorithm will never (or rarely)
have enough time to move IW, either up or down. Even it did, upon the
next reboot the latest IW is lost. Does it start from scatch then?

2. To fix the above problem requires either some local persitent
storage or some external (e.g., through the network) storage to save
counters more frequently. This is certainly doable, but will
introduce a lot of complexity, basically ruining the simplicity of
the algorithm you proposed.

For some hosts the above may not even be feasible.

3. The proposed check

"if (IWnotchecked && ((ISN - seqno)/MSS < IW))) {"

under "3. During a retransmission,...", although simple (hence
meeting the KISS requirement), counts against IW even though the
initial burst may be smaller than IW. OTOH, tracking the actual
burst sizes more accurately and counting them against 3..IW buckets
as Mark Allman described earlier adde more complexity. Is it really
necessary?

For a web server the size distribution of the HTTP responses drops
off quickly after certain threshold. Assuming we decide our loss
tolerant level is 5%. When the IW is bumped to certain leve, e.g.,
20, there may be less than 5% of HTTP responses that are greater
than 20*1460 = 30KB. Assuming IW <= 20 is all good but IW > 20 is
all badness, lumping all the counters together under a single IW
may never fail the 95% check, hence allowing IW to grow unbounded
even though those connections with response sizes greater than 16
always suffer. One may argue the small percentage of connections
sort of justifying fudging it out. But if one judges from the
volume (of just the initial bursts) it may not be insignificant.

A good compromise may be to track only connections with burst
sizes = IW, or >= IW minus some threshold, relying on the fact
that the ones below IW minus some threshold have been verified
before so it's not too risky not to continue to validate them.

This does unfortunately require some code, although minimal, to be
added to the fast path to check the initial burst size. In some
implementations it may not even be easy to accurately delineate/
compute the "burst" size, but one can always fudge in that case.

4. The proposal makes an assumption that the choice of IW is to
be blamed if the percentage of connection experiencing pkt loss
during its IW is greater than some threshold. But this may not be
true. A host may experience high loss percentage regardless of IW.
E.g., IW3 performs as bad as IW10.

If the losses are spread across a large percentage of connections,
then one can argue it's moot whether an optimal IW is picked because
performance will suck for most connections anyway (assuming a high
loss threshold of, e.g., 5%). But if the losses concentrate on only
5% of remote peers and these peers suffer real high pkt loss rate,
this false positive will forbid IW to ever grow, and hence deprives
the rest 95% connections of the benefit of a larger IW.

I have no idea how often this false positive case might exist but
if it turns out to be a large percentage then the proposal will be
worthless in terms of addressing the small IW problem.

5. A possible fix may be to use two sets of counters rather than one.
One tracks the loss rate of all the initial burst sizes <= 3. The
other tracks the rest upto IW. Then compare the two, and allow IW to
increase if the loss rate of the second set is within some threshold
(either absolute or some percentage) of the first one.

But one problem with the above is that the number of the base case
(IW3) may have been negatively affected by other hosts moving up to
a higher IW.

6. Regarding te sequence number wrap around problem, one can add a
simple check to reset IWnotchecked when seqno goes beyond IW but
this requres adding a check to the past path. I agree this issue is
tiny that may be ignored and just allow the false positive.

7. [Ch10] - misses N. Dukkipati as a co-author.

Jerry

On Thu, Dec 23, 2010 at 3:38 PM, Joe Touch <[email-masked]> wrote:
> It includes the algorithm and a lot of other details, some fleshed out (the
> intro), others as a list. The goal is to use this as a basis of initial
> discussion.
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>