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

[Chris Peabody <>]

Here's some traffic data for you BEN, to try your "back of the envelope" calculations.

I reviewed the traffic at Georgetown's primary PBX last month - here's the stats for the busiest days.

1. We are now down to about 12,000 phones from our peak of 17,000 (sold our hospital). We also get very little traffic from the residence halls, since kids all use cell phones.

2. DOD (outbound) calls:  30,382 calls in one day   Average duration - 2:28 minutes

2. DID (inbound) calls  37,767 calls in one day   Average duration: - 2:02 minutes

I don't have it broken down by hour - but we probably want to study it at it's highest peak.
Hope this is a good start.  I can forward more data if needed.

CBP

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-pic-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

----------------------------------------------------------------wg-pic--