Re: Real and Non-Real Time Traffic (was [WG-PIC:352] Re: FMM demo notes)

[Guy T Almes <>]

Ben et al.,
 This is a great thread, and I agree with almost all of your comments 
specifically.

 For too long the TCP experts have operated purely in the context of how 
to optimize large bulk transfers.  As a recent example of a success, the 
CERN/Caltech team have succeeded in pushing 5.6 Gb/s end-to-end between 
CERN/Geneve and Caltech/LosAngeles.
 When this is done with Reno-based techniques, they very intentionally 
build up (and after packet loss events, tear down) massive buffers at the 
bottleneck router.  This cannot be good for VoIP etc.
 Since late 2002 we've been working with the FAST TCP folks (Steven Low 
and his colleagues) at Caltech.  Their control algorithms for TCP are 
grounded in control theory and attempt to maintain moderate-sized queues at 
the bottleneck.  Though they were at first focused entirely on throughput 
and TCP fairness, we pointed out to them that both the moderate-size and 
the consistency of size of queues would be good for VoIP etc.

 I'd love to hear more from you and the others in wg-pic and wg-voip about 
the specifics of how amount of queueing delay and stability of queueing 
delay impinge on their work.

 One quibble: I would not want to burden your effort too early, but I 
would argue that congestion control will be needed if/when large-scale 
deployment occurs.  The cute way of saying it is that you only need to do 
it if your application succeeds.

 Regards,
       -- Guy

--On Wednesday, October 22, 2003 22:25:07 -0400 Ben Teitelbaum 
<> wrote:

> Jeremy George 
> <>
>  writes:
>
> >   One of the things we can do is feedback to network engineers the
> > necessity of substantially eliminating congestion (and not buffering)
> > when real time applications are running.  I think this is non-trivial
> > feedback and one I've pushed at yale.  A really good data network is
> > not necessarily automatically good for real time apps.  I think this is
> > a topic worth some exploration, but probably not by this group.
>
> I think this *is* a topic of which both the PIC and VoIP groups should
> be mindful and which we should discuss from time to time.  For now,
> outside of pathological environments where hundreds of people are
> sharing the ether, real-time applications with adaptive, loss-tolerant
> codecs work well.  In the longer term, we need to worry about
> co-existence with non-real-time bulk transfers.
>
> Let us not forget that TCP is *designed* to congest.  With bigger
> MTUs, "tuned" socket buffering, and tricks like zero-copy, TCP Reno
> will fill the pipe and, worse, build a queue at some interface.  That
> interface will have a delay-bandwidth product of memory adding
> something like 150ms of delay to the comingled VoIP traffic.  On top
> of codec delay and propagation delay, this could push a lot of voice
> traffic into uncomfortable territory (>250ms).
>
> Lightweight QoS techniques (e.g. alternative best-effort (ABE)) could
> help isolate real-time traffic.  Well-tuned RED could avoid
> tail-dropping and therefore the consecutive loss patterns that destroy
> even clever voice codecs.  Finally, new transport protocols like FAST
> (from CalTech) or XCP (from MIT) could improve bulk data throughputs,
> while reducing the need to have so much memory in the routers.
>
> All of this is of critical long-term importance to us.
>
> Finally, the concerns raised by Sally Floyd in
> http://www.ietf.org/internet-drafts/draft-iab-congestion-01.txt don't
> worry me much in the Internet2 environment.  Non-adaptive or
> coarsely-adaptive applications like voice should be just fine as long
> as the streams are "small".  A single 128kbps voice stream is tiny in
> comparison to the slowest interface on a "typical Internet2 path"
> (ignoring wireless, lets define this as switched 10Mbps).  It would be
> interesting to do a back-of-the-envelope worst-case analysis assuming
> complete POTS replacement and the current Internet2 topology and see
> if we could estimate the feasibility or improbability of congestion
> collapse due to VoIP.
>
> Does anyone have busy-hour call volume figures from a campus voice
> switch they could share?  With a few datapoints, I'd do this
> back-of-the-envelope analysis.
>
> What worries me in the Internet2 environment are the non-adaptive
> video applications we are seeing that are not at all "small".
>
> -- ben




---------------------------------------------------------------wg-voip-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

   http://archives.internet2.edu/

---------------------------------------------------------------wg-voip--