The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <5.1.0.14.0.20030216140944.0281f240@delta.info.net>, raymond zhang w
rites:
> Hi Jerry,
> 
> The draft 
> "http://www.ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt
> " 
> and 
> "http://www.ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-00.txt" 
> indeed touch upon a practical requirement for SPs offering VoIP over their 
> networks.  I'd support the suggestion of MPLS WG taking the lead on such 
> efforts as discussed in this draft, perhaps in coordination with other WGs.
> 
> Regards,
> Raymond


Raymond,

Since you spoke in support of this and mention "practical requirement
for SPs offering VoIP", I'd be interested to hear 1) which service
provider is using gear that sends 30 byte payloads, 2) which gear is
sending 30 byte payloads.

I just spoke to someone at another SP yesterday about other things and
asked about packet sizes in the VOIP deployment.  The gear is Sonus
and the packet sizes were said to be "oh I don't know, I think about
200 on average but might depend on content due to silence suppression
and compression".  That is a far cry from 30 byte payloads.

It may be that some voice over ATM gear sends a 30 byte payload in a
55 byte cell.  That's stupid to start with.  Ten cells would get you
480 bytes minus some for LLC/SNAP if used plus AAL trailer for at
least 450 payload.  That's 15 times the payload for 10 times the cells
allowing 50% more capacity on the same network.  A more moderate 224
byte payload could be fit in 5 cells still yielding close to a 50%
gain.  But voice over ATM gear didn't do it that way.

Some voice over ATM product did things in a stupid way.  There is no
point in perpetuating this.  If the problem is migrating from these
then a better way to do the migration might be to put new VOIP gear on
the edges to replace the voice over ATM gear.  Use voice over
RTP/UDP/IP/MPLS/ATM temporarily.  This will still be more efficient
that using 30 byte payloads in ATM or 30 byte payloads in
RTP/UDP/IP/MPLS or RTP/UDP/MPLS with header compression.  Then
gradually get rid of the ATM.

Alternately if the SP needs to keep the voice/ATM gear the SP will
need some sort of gateway to the modern world.  Whether doing this or
not it would be good to get the voice/ATM vendor to change their gear
to use a larger frame rather than voice in individual cells, but that
may be unlikely to happen.  If anyone is going to make a voice/ATM to
voice/*/MPLS gateway (or IWU if you prefer that term), and wants to
improve efficiency, it would make more sense to go RTP/UDP/IP/MPLS and
don't bother leaving out IP and UDP or doing RTP header compression
but collect multiple ATM cells and build a bigger payload.

Curtis


> At 04:05 PM 2/12/2003 -0500, Ash, Gerald R (Jerry), ALABS wrote:
> >All,
> >
> >I'd like to propose that the MPLS WG take on work regarding VoIP over MPLS 
> >header compression.  This work was earlier accepted for consideration by 
> >the MPLS WG (see the background summary below).
> >
> >Two I-D's related to this work are at:
> >http://www.ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt
>  
> >(George is added as co-author in the next rev)
> >
> >http://www.ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-00.txt
> >
> >Please review the documents and raise any issues/comments to the list.
> >
> >The work was presented at the IETF-55 PWE3 WG meeting (slides and meetings 
> >notes at http://ietf.org/proceedings/02nov/index.html).  It was generally 
> >agreed that the work did not fit well in PWE3, and that MPLS might be the 
> >best overall fit.
> >
> >I propose a brief time slot at the IETF-56 MPLS WG meeting to very briefly 
> >review the above proposals and issues, and get a sense of the room.
> >
> >Comments welcome
> >
> >Thanks,
> >Jerry Ash
> >
> >Background:
> >
> >Some service providers (such as AT&T) have plans to migrate large amounts 
> >of legacy voice traffic to VoIP, as well as to provide VPN services 
> >enabling VoIP.  VoIP over MPLS ('VoMPLS') typically uses the encapsulation 
> >voice/RTP/UDP/IP/MPLS.  For an MPLS VPN, the packet header is at least 48 
> >bytes, while the voice payload is typically no more than 30 bytes.  VoIP 
> >over MPLS header compression can significantly reduce the VoIP overhead 
> >through various compression mechanisms.  This is important on access links 
> >where bandwidth is scarce, and can be important on backbone facilities, 
> >especially where costs are high (e.g., some global cross-sections).
> >
> >VoIP over MPLS header compression methods have been proposed earlier 
> >(March, 2000) in the MPLS working group, however the relevant drafts have 
> >expired.  In particular, George Swallow and Lou Berger proposed a 'simple' 
> >end-to-end compression scheme in which all first-order differences in the 
> >RTP/UDP/IP headers were transmitted, and in which the header compression 
> >context was established through RSVP signaling.  The work was accepted 
> >into the MPLS WG pending an addition to the MPLS WG charter.
> >
> >In the I-D's we propose 3 approaches to VoMPLS header compression: a) 
> >re-use the methods in cRTP to determine the context and MPLS to route 
> >packets, b) re-use the methods in Swallow's and Berger's 'simple' approach 
> >to determine the context and MPLS to route packets, and c) re-use the 
> >methods in cRTP to determine the context and the SCID (session context ID) 
> >to route packets.
> >
> >Issues to discuss:
> >
> >1. WG charter -- The VoMPLS header compression work is not within the 
> >current charter of the MPLS WG, so a charter extension is needed.  George 
> >said he 'would have no objection to the work being done in MPLS'... but 
> >suggested that the 'work fits more closely in the Transport Area/PWE3 WG' 
> >(which is why it was brought there first).
> >
> >2. Protocol extensions -- As detailed in the I-Ds, extensions are proposed 
> >to [cRTP] and [cRTP-ENHANCE], which involve a new packet type field to 
> >identify FULL_HEADER, CONTEXT_STATE, etc. packets.  New objects are 
> >defined for [RSVP-TE].  Extensions are also proposed to RFC2547 VPNs, 
> >which create 'SCID routing tables' to allow routing based on the session 
> >context ID (SCID).  These extensions need coordination with other WGs 
> >(MPLS, CCAMP, AVT, ROHC, PPVPN, etc.).
> >
> >3. Resynchronization -- E2E VoMPLS using cRTP header compression might not 
> >perform well with frequent resynchronizations.  The applicability and 
> >performance need to be addressed (the 'simple' header compression approach 
> >would avoid the need for resynchronization, but achieves less efficiency 
> >than cRTP).
> >
> >4. Scalability -- E2E VoMPLS applied between CE-CE would perhaps require a 
> >large number of LSPs to be created.  There is concern for CE ability to do 
> >the necessary processing and the scalability of the architecture.
> >
> >4. LDP application -- It would be desirable to signal the VoMPLS tunnels 
> >with LDP, since many RFC2547 VPN implementations use LDP as the underlying 
> >LSP signaling mechanism.
> 
> 
>