The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

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.

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.

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.

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).

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?

> >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).