Subject: RE: [AVT] Is TCP broken?

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Dec 2003 09:10:17 -0500

Eddie

> * 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.
I don't think there exists mechanisms to do this, because you
need immediate response when the stream starts, and nothing
in TCP does immediate - it's designed to react slowly.
> 
>   Without a bandwidth reservation, it's hard to know how to do better.
I don't believe this.  I think it's possible to do some relatively
simple things to TCP that would help media streams quite a bit.
> 
>   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).
This is not tenable.  No application would do this; they would
simply turn off the Voice Activity Detection.  It's also wrong.
It illustrates that indeed TCP is broken.  TCP needs a mechanism
to determine it's "fair" share and use extra bandwidth opportunistically,
returning to "fair" immediately when asked.

> 
> 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.
TRFC, as I understand it, does not work for media flows,
which are on/off constant rate.  It is not interesting to look
at steady state; you have to include startup/shutdown. 
All the simulations I've seen either show that TRFC won't start
cleanly for CBR-like flows, or don't show how start/stop works
at all.

The problem here is "rate control"; media streams don't rate control,
except as we have discussed, rather crudely, and only downward.

> 
> * 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.)
Well, I'd say this was an example where TCP is broken in that
it does not use available bandwidth appropriately, but in this case,
it is TCP that loses.  I don't want to promote solutions that
break TCP, or, as in this case, not use available bandwidth efficiently.

Brian

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Eddie Kohler <[email-masked]>
Date: Wed, 03 Dec 2003 08:35:40 -0800

> >   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.

? TCP is designed to react *quickly*.  It halves its rate after a single
dropped packet (after an RTT of course).

> simple things to TCP that would help media streams quite a bit.

Such as?  (1) I don't think the situation is that bad; (2) it seems like
any modification to TCP to cause it to probe slower for excess bandwidth
would cut to TCP's heart.

> >   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).

I disagree with each of these points.  Would 'no' application really do
this?  If an application was given the choice of (1) not sending over the
best-effort internet or (2) sending traffic during silence periods, why
wouldn't the application choose (2)?  And why wouldn't an application that
sent at a reduced rate during silence periods have a competitive advantage
(assuming people cared about bandwidth)?

TCP has a mechanism to determine its fair share, namely bandwidth probing.
It has a mechanism to adjust to the introduction of new flows, namely
halving its rate after single loss periods.  TFRC is robust against
bandwidth probing.

You want your media flow to start up from nothing, after a silent period of
seconds or minutes, with no loss.  That is not best effort.  That is a
bandwidth reservation.

I don't understand how this would work even in an environment with only
media streams.  If the sum of the streams' non-silent bandwidth is greater
than the link bandwidth, then you may end up with loss when all the streams
aren't silent.  What should the streams do then?  Suicide?  Live with high
loss rates?  Rely on the users to go away?  If the network has been
engineered so that this situation cannot happen, then it's a QoS network.

> >   Simulations have been done showing that TCP and TFRC achieve pretty
> >   fair allocations.

Not all media streams are on/off constant rate as people have brought up,
but yes, slow-start exists and could be problematic for CBR users.  But I
don't understand why this is the complete killer it's being painted to be.
Not for all media flows anyway.

Is delivering media over the current Internet important enough that users
could afford to wait < 1 second for slow start?  (Which, incidentally, is
entirely within the range application startup delay times.)  If the answer
is no, fine; use QoS.

Eddie