Subject: [tcpm] draft on congestion window limiting

From: Mark Allman <[email-masked]>
Date: Wed, 11 Jan 2006 15:09:55 -0500

Folks-

A quick note (chair hat off) to let you know that several of us have put
together a quick i-d on one particular strategy for mitigating
micro-bursts within TCP.  We submitted a very rough cut in November, but
have just cleaned it up quite a bit and it was sent to the I-D archives
this morning.  Until it pops out in the standard places you can slurp it
From the URL below.  The I-D is:

    Janardhan Iyengar, Mark Allman, Ethan Blanton.  TCP Burst Mitigation
    Through Congestion Window Limiting, January 2006. Internet-Draft
    draft-iyengar-burst-mitigation-01.txt (work in progress).
    http://www.icir.org/mallman/papers/draft-iyengar-burst-mitigation-01.txt

It'd be great to get people experimenting and thinking about whether
this is something that TCP needs or not.  There are some data points on
this contained in the references given in the I-D.  In any case, we'd
like to hear folks' thought on this one.

Thanks!

allman

-- 
Mark Allman -- ICIR/ICSI -- http://www.icir.org/mallman/

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

---

From: Pasi Sarolahti <[email-masked]>
Date: Wed, 25 Jan 2006 23:51:01 +0200

Hi,

Some comments on the burst mitigation draft below...

> like to hear folks' thought on this one.

I believe experimenting with burst mitigation algorithms in real
networks could be possible for many of us. At least Linux has
implemented a similar scheme for years, though I don't know what's the
status of TCP in the latest kernel versions.

(Btw, the Linux scheme is shortly outlined on page 6 of
P. Sarolahti and A. Kuznetsov. "Congestion Control in Linux TCP". In
Proceedings of Usenix/Freenix 2002. Monterey, CA, USA, June 2002. 
[http://www.cs.helsinki.fi/u/sarolaht/papers/linuxtcp.pdf])

We did some experimentations with Linux TCP on slow links and a limited
set of network paramaters about five years ago, and from what I
remember (with the experience of an undergraduate student), burst
mitigation didn't seem to cause problems, but not huge benefits,
either.

I think it would be worthwhile to discuss the trade-offs a bit
more. Discussion section says that whether or not mitigation is needed
remains open, but it could give some more baits for further
thinking. For instance, while burst mitigation can reduce the stress
on network queues to some extent, much research has been done on how
to utilize a high-delay path as effectively as possible within the
limits of congestion control principles. People working with
high-delay paths might want to evaluate carefully whether
reductions on congestion window are more harmful than the temporary 
bursts of load on queues.

I was also thinking about the fairness and incentiveness of burst
mitigation as another kind of trade-off. I cannot come up with very good
case that would illustrate this well, but let's assume there was a
receiver with a buggy delayed ack implementation (say, ignoring the
"ack-on-every-second" rule -- I have seen this sometimes), and two
senders on the other side of the network, one implementing burst
mitigation and another not. It would seem that burst mitigation would
give unnecessary advantage to the flow that does not implement it. This
could be a minor effect, but on the other hand, it is not known how
significant the benefit for avoiding micro-bursts is.

But to me the algorithm itself on Section 2 seems straightforward, and
having BLimit to follow initial congestion window equation feels an
appropriate choice. So if there was some consensus that burst
mitigation is generally needed, I could not see what could go
wrong with the algorithm as described in the draft.

Other than that, I'm only able to come up with small nits:

* I was thinking if the beginning of section 2 should emphasize it a bit
more that burst mitigation is in an experimental landscape. Maybe in
addition than just saying "When using CWL, the following steps MUST be
executed", one could also add that CWL is experimental and TCP MAY
implement it, and when using CWL, the following steps MUST be
executed, just to make it clear. Well, I don't know. This is a very
minor thing, and probably a matter of opinon.

* Section 3 begins with:
    CWL makes TCP congestion control more conservative and is therefore
    implicitly allowed by [RFC2581].
Rather than being in the related work section, this note could also be
somewhere in section 2.

Don't know how much these thoughts help, but hopefully they at least
spring up more comments ;-)

- Pasi

---

From: Janardhan Iyengar <[email-masked]>
Date: Mon, 30 Jan 2006 17:16:57 -0500 (EST)

Pasi,

Thank you for your comments, and for spending your time on this document.

> status of TCP in the latest kernel versions.

Thank you for this bit of information. The scheme mentioned in the paper 
looks like the "Use it or Lose it" scheme mentioned in the draft. I did 
probe the Linux community recently about whether a micro-burst mitigation 
scheme was deployed in Linux. The response I got was that there wasn't any 
such scheme currently deployed, but patches were available. I am not sure 
at this time if there is or isn't a scheme in Linux (I haven't looked at 
the code myself yet). I would be happy if someone could confirm for me 
which one is currently the case.

> more.

Agree, and Good point. I did have this in my mind, but I should have put 
it in the draft. Thanks for the tradeoff suggestions.

> significant the benefit for avoiding micro-bursts is.

As far as the buggy receiver is concerned, I'm not sure that we should aim 
to demonstrate trade-offs in such cases. But, IIUC, your core point is 
that under the same conditions, a sender with burst-mitigation might be at 
a disadvantage with respect to a sender without burst-mitigation. There is 
also the possibility that a sender without burst-mitigation loses packets 
in the network due to the burst when a sender with burst-mitigation does 
not. So, I agree that there is a tradeoff. And that we should write it out 
clearly.

> So if there was some consensus that burst mitigation is generally 
> needed,

We are trying to gather data points on this question too. Our goal in this 
draft is to gauge interest in the issue, and to give a starting point for 
experimentation.

> more that burst mitigation is in an experimental landscape. Maybe in

We did try to emphasize exactly that (just before Section 2, in fact). 
Maybe it did not come through clearly enough.. I'll try to make it 
clearer. Section 2 specifies the mechanics of the algorithm itself and I'm 
not sure if that space should be used for making a statement about the 
experimental status of burst-mitigation. But, point taken.

> Rather than being in the related work section, this note could also be

Does Section 4 (Discussion) seem more appropriate?

Thank you for your comments!

regards,
jana

--------------------
Janardhan R. Iyengar
http://www.cis.udel.edu/~iyengar
Protocol Engineering Lab, University of Delaware