Re: reduce jitter in routed network for voip applications

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 28 Mar 2005, Daniele Giordano wrote:

> RTP is transparent at the transport layer. We analyse TCP and UDP:
> TCP is connection oriented and so the communication begins with the
> definition of a virtual circuit.
> A virtual circuit is a temporary connection of sequence nodes with relative
> reservation of bandwidth.
> A connection oriented service gives the certainty that all information units
> use the same nodes with a same medium latency.
> Same latency maintains reduced the jitter.

The variable latency is usually introduced as a result of queuing due to
transient congestion in the path, and to a lesser extent, due to path
variations due to load balancing.  It has (almost) nothing to do with
whether the packets are TCP or UDP.  QOS protocols may alter the queueing
priorities, but QOS should be helping to reduce VOIP latency by pushing
the VOIP packets to the front of the transmission queue.

Extensive testing done at Genuity around 2000 showed that congestion is
mainly a problem in the tail circuit and that low latency queuing (and I
think smaller MTU) allowed good RTP latencies right up to full t1
utilization. Partly, this solution is specific to Genuity, which had (I
think)  larger than typical headroom in the core.

RSVP won't really do much unless you have end-to-end implementation--I
won't go into any criticisms of RSVP, but suffice it to say I think its
still a work in progress (good work, but more needed), and as a practical
matter isn't widely implemented in the general internet and isn't likely
to be widely implemented between carriers, I think. RSVP as it stands is
really only useful to some fortune 500 companies that have their own
large, private, wide area networks.  QOS in the core networks is
impractical for a number of reasons.  Building in excess headroom is a
good idea for a voip network.  A voip-only side-network is also a good
idea.

I don't think TCP is a solution to latency. Indeed, that would possibly
subject voice streams to RED and WRED congestion control.  (these drop tcp
packets randomly to cause windowing reductions to reduce packet rates
which then reduces congestion)

> I think that RTP should use a layer 4 connection oriented protocol (like
> TCP) but without retransmissions of information units with excessive delay
> or errors (like UDP).
> 
> What do you think about this?

What connection oriented features would you add besides retransmission and 
windowing? You said that your'd remove retransmission, and windowing is 
already essentially implmented in the jitter buffer.

One could say that (voip) RTP is already connection-oriented with H323 and
SIP handling the RTP connection setup issues. Usually, this is necessary
because the h323 and SIP functions are intimately tied to call routing and
stream setup.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   




_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]