[dccp] Is TCP broken?

[Eddie Kohler <kohler@icir.org>]

There was a discussion earlier about whether "it is TCP that is broken",
meaning does TCP behave particularly badly when paired with real-time
media.

TCP is, of course, pretty stupid in many ways, but I didn't quite
understand *how* TCP was broken here...?  Was it this? (the most likely
possibility)

* TCP is broken because it probes for available bandwidth during real-time
  media's quiet periods.

  Guilty as charged, but it might not matter.  If the congested link has a
  large level of statistical multiplexing, or if the TCP flow is
  short-lived, it'll all come out in the wash.  On the other hand, if the
  congested link has a small level of statmux, then the congested router or
  media could just punish TCP a bit to get it back in line.

  Without a bandwidth reservation, it's hard to know how to do better.

  Now, if the real-time media flow was using TFRC, it could preserve its
  bandwidth allocation essentially indefinitely by sending probe traffic at
  *half* its full-speed rate during silent periods (NOT twice).

Other possibilities:

* TCP is broken because it probes for available bandwidth, period.

  I don't think TCP's bandwidth probes will punish TFRC unduly.
  Simulations have been done showing that TCP and TFRC achieve pretty fair
  allocations.

* TCP is broken because it reacts so violently to loss, which constrains
  real-time media unduly.

  Guilty.  TCP does halve its rate in response to each congestion event.
  And yes, that should, up to a point, constrain application designers who
  want to run over the best-effort Internet.  But I'm not yet convinced
  that real-time media won't work.  Many of the constraints don't seem that
  onerous.  (A later mail.)

Eddie

_______________________________________________
dccp IETF mailing list: dccp@ietf.org
list info:  https://www1.ietf.org/mailman/listinfo/dccp
wg charter: http://www.ietf.org/html.charters/dccp-charter.html