The MPLS WG Archive

["Jim Hand" <hand17@earthlink.net>]

	In many VoIP services I am working with, the most important place for
bandwidth efficiency is on the access link between the customer premise and
the provider edge.  There is limited opportunity at the customer premise for
connection muxing, because of the limited number of connections.  So I think
it would be necessary to do compression on the access link in many cases
anyway.

	You could then do connection muxing inside the Service Provider's network.
But in order to do the connection muxing, you would likely have to
decompress the packets first (perhaps there might be some way around this).
This would require a place in the network where you would have to do both
compression/decompresion and connection muxing/demuxing.  That's a lot of
load at some aggregation points in the network.  With the end-to-end
compression, we were hoping to push the compression load out toward the
edges, where there are more boxes to apply to the compression load, and
avoid it altogether within the SP transport network.

Thanks,
Jim
> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@fictitious.org]
> Sent: Wednesday, February 19, 2003 6:29 PM
> To: Jim Hand
> Cc: curtis@fictitious.org; Ash, Gerald R (Jerry), ALABS;
> raymond zhang;
> MPLS@UU.net; George Swallow; Loa Andersson; GOODE, B (Bur),
> ALABS; Dave
> Cooper
> Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression -
> End-to-End MPLS
>
>
>
> In message <001901c2d869$8863c200$3a785b87@mt.att.com>, "Jim
> Hand" writes:
> > Also, neither draft requires end-to-end MPLS between VoIP
> endpoints.  One of
> > the drafts
> >
> (http://ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-comp
> ress-00.txt)
> > requires MPLS between the compressor and decompressor.  The other
> >
> (http://ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compre
> ss-00.txt )oes
> > not require MPLS all the way between compressor and
> decompressor.  Neither
> > draft requires that the compressor and decompressor also be
> VoIP endpoints.
> >
> > Thanks,
> > Jim Hand
>
>
> By end to end I meant compression device to compression device.  I did
> say gateway to gateway which might imply VOIP device.
>
> The argument I was making was that if the compression device is very
> far toward the edge of the network, then the number of LSPs explodes.
> If the compression device is moved closer to the core of the network
> such that a full mesh of RSVP/TE LSPs are feasible, then opportunity
> for multiplexing is enormous.
>
> If you are going to burden the CPU at the "compression device" why not
> have it multiplex rather than header compress and get huge improvement
> in encapulation efficiency rather than relatively small improvement in
> encapsulation efficiency.  This also makes it feasible to more the
> compression closer to the edge and maybe into the VOIP gear rather
> than a router concentrating VOIP gear traffic.
>
> Thanks again,
>
> Curtis
>
>
> > > -----Original Message-----
> > > From: Curtis Villamizar [mailto:curtis@fictitious.org]
> > > Sent: Wednesday, February 19, 2003 11:25 AM
> > > To: Ash, Gerald R (Jerry), ALABS
> > > Cc: curtis@fictitious.org; raymond zhang; MPLS@UU.net;
> George Swallow;
> > > Loa Andersson; GOODE, B (Bur), ALABS; Hand, James C, ALABS;
> > > Dave Cooper
> > > Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression
> >
> > >
> > > 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