Subject: [tcpm] (reducing) tcp bursts

From: Yuchung Cheng <[email-masked]>
Date: Tue, 30 Jul 2013 13:20:34 +0200

There are a lot of discussion on bursts across talks.
1. newcwv: idle-restart
2. tlp: how often is tail drops be caused by (higher) initial burst/send
3. burst (loss) after recovery due to snd.una + rwin jump.
4. I can throw in another one: video player application throttle
sender by not reading the socket or clamp the receive buffer. But this
causes TCP to burst when rwin opens up.

I think the working group should work on a general solution to reduce
burst in the window-based, ack-clocked, TCP. I have heard solutions
like
1. BSD/randy's max-burst solution
2. pace cwnd/rtt but in max-burst chunks
3. more ideas in http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt

We all know TCP is very smooth in bulk transfer. Unfortunately modern
Apps are chatty even on video.

Thoughts?

---

From: Michael Welzl <[email-masked]>
Date: Tue, 30 Jul 2013 13:27:44 +0200

Great idea!

Cheers,
Michael

On Jul 30, 2013, at 1:20 PM, Yuchung Cheng <[email-masked]> wrote:

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

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Tue, 30 Jul 2013 11:32:42 +0000

> 3. more ideas in http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt

4. http://www.icir.org/floyd/tcp_small.html#pacing

---

From: Mark Allman <[email-masked]>
Date: Tue, 30 Jul 2013 11:35:49 -0400

> burst in the window-based, ack-clocked, TCP. 

Is this a demonstrated problem?  When Ethan studied this a while back
the high order bit was that bursting wasn't a huge issue, as I recall.
The paper is:

  Ethan Blanton, Mark Allman.  On the Impact of Bursting on TCP
  Performance.  Proceedings of the Workshop for Passive and Active
  Measurement, March 2005.
  http://www.icir.org/mallman/papers/burst-pam05.ps

My current feeling is that I don't necessarily have a problem with a
burst mitigater as long as it mostly stays out of the way and only tries
to go after really egregious bursts.  But, maybe that notion is just
based on out-of-date information.  It'd be cool to see empirical data on
the subject.

allman

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 30 Jul 2013 18:02:09 +0200

> burst mitigater as long as it mostly stays out of the way and only tries
stays out of whose way?

> based on out-of-date information.  It'd be cool to see empirical data on
Absolutely we should proceed with empirical data and scientific experiments.

A indirect measure is the trickle work we did: when we clamp cwnd to
smooth youtube video burst, the loss rate is reduced nearly 40% on
flows that are not bottle-necked by network.
https://www.usenix.org/system/files/conference/atc12/atc12-final236.pdf

I will post more data to show the loss & burst size correlation at
Google servers.

Or data wizard Mark can start processing his latest traces too.

---

From: Mark Allman <[email-masked]>
Date: Tue, 30 Jul 2013 12:07:58 -0400

> > burst mitigater as long as it mostly stays out of the way and only tries

The connection's.  The above paper basically shows that small-ish bursts
cause little-to-no extra loss.  But, once a burst size hits some point
the loss is big (and probably not just for the given connection, as it
has filled a buffer).  So, probably, small-to-modest bursts are not
causing a whole big issue.  But, big bursts do.  So, a burst limiter
could clamp those big bursts, but why bother with the little ones?

> I will post more data to show the loss & burst size correlation at

Cool!

> Or data wizard Mark can start processing his latest traces too.

Heh.  Well, I am no wizard.  But, we are working on something that might
speak to this indirectly.  We'll see.

allman

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Jul 2013 10:19:57 -0700

Seems like time to revive draft-hughes-restart, and include some of the 
more recent suggestions.

Joe

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 31 Jul 2013 17:11:31 +0200

> could clamp those big bursts, but why bother with the little ones?
ack. TCP shouldn't. The research questions are how big is big and the
trade-off of complexity vs performance of different solutions.

AFAIK Randell implements the max-burst in hughes-restart draft in BSD,
so the section on "BSD implementation" definitely needs an update if
we want to revive it.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 31 Jul 2013 19:42:14 -0700

Hi Yuchung,

I think this looks a very interesting and important point, but I have
several questions.
What is the difference between 1 and 4? newcwv draft seems to address
the issue for application throttle.
Also, what is the difference between 2 and 3? It seems to me that both
are the issue for burst after recovery.
In my understanding, the issue for burst after recovery can be
mitigated by PRR. I'm wondering why you don't mention it..

I'm also wondering how much we can have a general solution.
The characteristic of idle-restart/app throttle and burst after
recovery seems to be very different, we might need different
solutions.

Thanks,
--
Yoshifumi