The MPLS WG Archive

[raymond zhang <zhangr@info.net>]

Hi Curtis,

Sorry for the delayed response...

>I'm just trying to come up with something that will actually work.

Surely, this is indeed the final objective and do very much appreciate your 
initiating a thread of discussions as engaging as this in helping to 
further clarify and bring focus on the nature of the issues/problems...

A bit more comments in lines below.

Regards,
Raymond

At 02:35 PM 2/20/2003 -0500, Curtis Villamizar wrote:

>In message <5.1.0.14.0.20030220084042.02556418@delta.info.net>, raymond 
>zhang w
>rites:
> > Curtis,
> >
> > Thanks for the response and see some further comments in line...   Based
> > upon discussions we have thus far including your response to my 
> comments in
> > response to Uzelac's email, maybe I should make some clarifications first
> > which may help my understanding of your input as well in any further
> > discussions:
> >
> > The environment in which I am referring to is a global IP/MPLS 
> packet-based
> > network spanning all major and sub-continents where it is not always
> > possible to get ample bandwidth (over-provisioning) economically (very
> > expensive in fact)...  The issues of delay or packet loss do not normally
> > present problems at all as you pointed out, in some continental or 
> national
> > networks of ISPs or SPs but to offer similar level of integrated services
> > (voice/data) for customers with world-wide locations, it is in these 
> remote
> > regions and over last mile local loops that we spend a bit more efforts on
> > to optimize.
> >
> > On low speed local-loops (PE-CE links), IP/UDP/RTP compressions is
> > needed.  I think we both agree on that.  As for PE doing the comp/depcomp,
> > I'd like to hear a bit more from the Vendors...  My experience has been
> > that hardware based compression at PE levels on the edge of the network
> > with large # of aggregating diffserve-enabled customer links presents
> > complexity that may become unmanageable to SPs and with amount of edge
> > features already processed through hardware, would adding
> > compression/decompression be even feasible ?  Besides,   the upgrade
> > path  may be very costly for these line cards which maybe deployed in 
> large
> > numbers across the global network as we add new feature sets/hardware
> > capabilities.  So I am not in favor of it as an option for PE level
> > routers.   Therefore the concept of distributing compression/decompression
> > into CE levels, not in the network appeals in a great deal.  If PE is not
> > doing the comp/decomp, then the compressed path needs to be e2e...
> >
> > Further comments in lines ....
> >
> > Regards,
> > Raymond
>
>
>The applicability statement part of this is embedded in the draft
>itself, rather than following a requirement document.

There will be a requirements draft per Loa's suggestion and in fact it is 
already submitted.

>You are citing PE-CE as the primary problem.  Others have cited PE to
>PE within the metro.
>
>If the problem is PE-CE, lets stick with that problem.

The problems exist in both cases...

>If PE-CE is the problem you are trying to solve, then RTP/UDP/IP/PPP
>compression should do wonders.  I agree with you entirely that the
>current practical problem there is that the PE can't handle the
>comp/depcomp at anywhere close to line rate on even relatively slow
>interfaces.  The PPS rate for these tinygrams is enormous.  (Of course
>making them bigger would help reduce the PPS rate in addition to
>improving the encaps efficiency).
>
>At one packet per 30 msec, you have 30 pps.  At 8kbit/s a T1 holds not
>quite 200 of these if the PPP encaps was 4 bytes or less.  Times 200
>calls you have 6000 pps.  Nothing at all for a line card, but not many
>of these will start to swamp a route processor if that is how the
>comp/decomp is implemented.
>
>Putting the compression in the CE might on the onset sound appealing.
>If you think you have problems with the PE handling the comp/decomp,
>wait til you try to bring up a full mesh of LSPs to all the CE for
>this sort of scale of global networks.  No sense trading one practical
>limitation for another of much more enormous magnitude.

Well, thus far in our discussion, we have established that we need at least 
comp/dcomp over PE-CE link.  Then we discussed the infeasibility of having 
PE to do comp/dcomp, upon which I come to that the other option would 
carrie compressed VoIP packets over the entire path across the network and 
do comp/decomp outside of the network, for example, at the CE or a large 
aggregation box ( in a voice access only environment and not part of the 
IGP plane of SP's network).

But we would in this case be dealing with comp/decomp distributed 
throughout the network instead of being at the aggregating PEs.  Namely, 
the amount of meshing may be much smaller at the CE level since they are 
customer specific.  This would be further reduced since not every call 
occupies its unique virtual connection.  Calls between the same pair of 
gateways may be aggregated onto the same e2e LSP if LSP is used as an e2e 
path.

Then the meshing on the PE could be limited to a set of aggregating or 
hierarchical LSPs among much smaller # of PEs (comparing to # of connected 
CEs to all PEs) (also since not every customer has locations in every PoP 
around the world which may ease the aggregation load on the PE level 
LSPs)... So this is not a trade at the same scale.  Nonetheless, as you 
pointed out, the scaling issues will worsen (may still be manageable 
depending the degree of the mesh) from provisioning to tunnel maintenance 
(setup/teardown due to link/interface events, e.g.) as number of customer 
sites increase.  I wonder what your thoughts are on the other Ash 
draft 
(file:///D:/onnet-data/out/IPbackbone/ietf/avt/draft-ash-e2e-crtp-hdr-compress-00.txt) 
where LSP does not get extended down to the CE, instead RSVP-TE tunnels are 
built between PEs, yet PE may only spend the first cycle just to establish 
the context state and then do not spend cycles to do comp/decomp for 
subsequent ip/udp/rtp compressed packets ?

>If there is a huge number of CE then at some point you'll have to
>partition the network to make this continue to work.  If so you might
>get CE to some voice/VOIP aggregation box/gateway and have these
>terminate the LSPs and do comp/decomp, then communicate among
>themselves.  This is likely to be a huge comp/decomp load.  You can
>concentrate the comp/decomp at some specialized processor or try to do
>the processing on the line cards (which may mean new line cards).

Could be an option but preferably not on the direct diffserve path into the 
network, in other words, placed behind the CEs, for example...

>If a CE is supporting on the order of at least 100 (to 200 if encaps
>efficiency can be improved), then muxing might be easier on the PE
>router.  For example, separating 300 pps of 600 byte packets is likely
>to be a lot easier (even if 6000 pps are sent out) than compressing
>and decompressing 6000pps and would add zero delay.  Either way,
>moving processing to the PE line card seems essential.
>I'm just trying to come up with something that will actually work.
>
>Regards,
>
>Curtis
>
>ps - wrt queueing and serialization delay.  30bytes into a T1 incurs a
>serialization delay of 240bits/1.5mbits or 0.16 msec.  200 bytes is 1
>msec serialization.  If CE means customer handset then we're e2e MPLS
>becomes completely absurd so I think it should be safe so assume at
>least T1 and it not you get delay.  With serialization times on the
>order of 1 msec edge and these days under a microsecond in cores, the
>queueing argument has never held water for priority queued traffic
>that is not congested.
>
>That's a moot point for a single flow if you have to hold the playout
>time for 200 msec to get 200 bytes packets because that is already an
>excessive delay.  For multiplexing, the argument against large packets
>based on serialization and queueing simply doesn't hold up.
>
>We're not talking IP over barbed wire in the third world, right?  Its
>at least T1?

Well, sub-T1/E1 are quite common as well...

> > >Tiny payload is needed for queue efficiency is a myth left over from
> > >the ATM days.  It is simply not true.
> >
> > I think there are two aspects in this...  Firstly traffic flows with
> > constant packet size would improve queue efficiency (M/D/1) and smaller
> > packet payload would reduce delay across low speed links (not an issue 
> once
> > again in areas of network with large pipes since no or little qeueuing)
> > which is required as part of the budge delay planning.  The voice quality
> > is provided on a per path basis not just over segments of the path inside
> > SP's major portion of the backbone.   ( I don't mean to spur another 
> around
> > of discussions on ATM vs. IP at all ! I thought issues are well understood
> > by now).