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

[Chris Peabody <>]

The info I gave to Ben was all off campus traffic.   CBP

Enyeart, Mike wrote:

Ben,

I think it would be more meaningful to model the trunk traffic, since
all the other traffic remains on campus.

-Mike

-----Original Message-----
From:  []
On Behalf Of Ben Teitelbaum
Sent: Wednesday, October 22, 2003 9:25 PM
To: ; VoIP Working Group
Subject: Real and Non-Real Time Traffic (was [WG-PIC:352] Re: FMM demo
notes)

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