The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <28F05913385EAC43AF019413F674A01704CB8733@OCCLUST04EVS1.ugd.att.com>
, "Ash, Gerald R (Jerry), ALABS" writes:
> Curtis,
> 
> >I think the SPs should speak as to whether the bandwidth inefficiency
> >of 30 byte payloads or the potential to lose a packet with a 200 byte
> >is a greater problem.  
> 
> Both are important issues, but if you read the first few sentences of http://
> ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt you'll see 
> that bandwidth efficiency plays a major role in the motivation for the propos
> ed capability.  Further, the packet sizes quoted in the I-D are typical for V
> oIP in SP networks, as Raymond noted.  Also, VoIP header compression (cRTP, f
> or example) is in use in SP networks on a link by link basis to address the b
> andwidth efficiency issue.  


30 byte + voice/RTP/UDP/IP/MPLS = 78 bytes                62% overhead
30 byte + voice/RTP/UDP/IP/MPLS compressed = 38 bytes	  21% overhead
200 bytes + voice/RTP/UDP/IP/MPLS = 248 bytes		  19% overhead
300 bytes + voice/RTP/UDP/IP/MPLS = 348 bytes		  14% overhead

No header compression and larger frames seems to be the winner as far
as efficiency goes even if you could compress the header to 8 bytes.

> The proposal in the I-Ds is to extend VoIP header compression on an end-to-en
> d basis, in an MPLS context.
> 
> Your suggestions for muxing voice calls into larger packets connote a PSTN/TD
> M-like model.  Some people actually think that the TDM model is pretty effici
> ent for voice, however, VoIP is another matter, and has issues for larger pac
> kets, e.g., increased e2e delay, etc.

You don't mux calls, you collect the frames of a single call and
introduce some assembly delay.

Audio compression techniques typcially do a good job of silence
suppression and vary in the amount of data they send.  Even the best
(that produce reasonable quality audio) consume up to 64 kbit/sec when
someone is actively talking and near nothing on silence.  What would
you consider the average transmission rate for compressed audio?
Somewhere around 16-32 kbit/sec?

To assemble a 300 byte packet at 64 kbit/sec you need under 40 msec,
200 msec gets you 25 msec.  If you set a queueing delay point (as
recommended all over the place for RTP) of 50 msec, you'll get packets
over 300 bytes, and probably an average of well over 200 bytes.

> Jerry 

Please correct me if I'm wrong but your drafts seem to require end2end
MPLS where RTP/UDP/IP/MPLS normally requires just end2end IP.  Since
you are providing new RSVP/TE objects the assumption seems to be
RSVP/TE MPLS edge to edge.  If traffic engineering is done within
regions as can be done with current RTP/UDP/IP/MPLS regardless of
whether LDP is also used, that works fine and scales extremely well.
E2E RSVP/TE MPLS all the way to each peice of VOIP gear is unlikely to
scale well in a single provider and is almost certain to become a
severe problem crossing SP boundaries.

Curtis