The MPLS WG Archive

[nitin p <nitin_panj@yahoo.com>]

Gopal,
Thanks for clearing me on this. What makes me still
wondered is the huge difference between these two
values. Ok I will mention my results:

Ingress: 3.665 milli seconds
Egress: 0.035 milliseconds
core:    0.018 milliseconds

IP: 0.023 milliseconds.

Now at ingress, if I assume both L3 lookup + L2.5
forwarding, it doesn't explain me why this value is so
high. What else can happen at Ingress which is causing
this huge delay ? Probably I should dig into code and
find out :)

Can you please explain, what is aggregation prefix?,
has it to do anything Penultimate Hop Popping(PHP). As
far as I know my code doesn't support PHP.

Your comments on this will be highly appreciated.

Thanks,
Nitin



--- "Gopal@Yahoo" <gnaganab@yahoo.com> wrote:
> Nitin,
> Theoritcal difference btw forwarding operation of
> Ingress LER and Egress LER is:
> Ingress LER: L3 lookup necessary. Depending on the
> implementation, the packet may have to go thru (or
> use) both 'ip forwarding engine/process' and the
> 'tag
> forwarding engine/process'.
> 
> Egress LER: L3 lookup not necessary (exception for
> aggregate prefix). 'tag forwaridng engine' can do
> the
> job with the Label lookup.
> 
> Because of the above difference in some
> implementations overhead on Ingress and egress may
> be
> different.
> rgds,
> gopal
> 
> --- nitin p <nitin_panj@yahoo.com> wrote:
> > Hi,
> > Sorry for interrupting the discussion between Eric
> > and
> > Jing.
> > 
> > Recently I have also measured the hop delay in the
> > mpls-linux implementation of sourceforge.net.
> > 
> > My results shows that delay at core (LSR) is less
> > than
> > that is observed in IP.
> > Delay at egress(LER) delay in MPLS is slightly
> more
> > than that in IP.
> > But, delay at ingress(LER) is  much more than tha
> in
> > IP.
> > 
> > With my results I can infer that in a network of
> > 1000s(may be 100s) hops overall delay in MPLS will
> > be
> > less that that in IP, but for samaller networks
> MPLS
> > results much more delay.I am not claiming that my
> > results are applicable to commercial
> > implementations,
> > which might have good hardware  support unlike my
> > test
> > where I have used PC.
> > It makes sense that LERs will take more time than
> > LSRs,but what I coudn't understand is the
> > performance
> > difference between Ingress and Egress.
> > 
> > Any comments on this are most welcome.
> > Thanks,
> > Nitin
> > 
> >  
> > --- Eric Osborne <eosborne@cisco.com> wrote:
> > > On Sat, Dec 07, 2002 at 09:14:19PM +0800, Jing
> > Shen
> > > wrote:
> > > > Thanks for Eric's comment. And, read my
> comment
> > in
> > > line please.
> > > > 
> > > > 
> > > > > >   1) TCP throughput of MPLS is a little
> > > smaller than IP when path MTU is
> > > > > > the same.
> > > > > >      and difference increases when path
> MTU
> > > decreases.
> > > > > 
> > > > > MPLS packets are 4 bytes (or more) bigger
> than
> > > IP packets.  If you do
> > > > > not allow for this in your link MTU, then
> you
> > > have smaller effective
> > > > > bandwidth inside TCP.  Allow for that in
> your
> > > link MTU (as any
> > > > > reasonable implementation should) and you
> > don't
> > > have this problem.
> > > > 
> > > > Yes. We notice that at the first stage of our
> > > implementation and then we
> > > > modify the engine to allow for such situation.
> > Our
> > > implementation allows
> > > > for a label stack with depth of 8, and we use
> > only
> > > one. But, that do has
> > > > effect on TCP throughput if the same path is
> > taken
> > > by IP and MPLS. 
> > > > 
> > > 
> > > Have you been able to determine what made this
> > > impact?  If your TCP
> > > segments can open up to the same size under both
> > > MPLS and IP, then all
> > > you add is another 4 bytes of transmission
> delay,
> > > which should be so
> > > close to zero it's inconsequential.  And if
> > > everything has this small
> > > additional delay, then that should in no way
> > create
> > > jitter in the
> > > network.
> > > 
> > > > 
> > > > > So this is a test of your forwarding
> > equipment. 
> > > Equipment which takes
> > > > > zero or negligible time to perform this
> > > encap/decap will not have this
> > > > > problem.
> > > > 
> > > > As I know some of manufacturers announce that
> > > their router/switch
> > > > could operate at line speed, and the latency
> in
> > a
> > > switch is
> > > > negeligible. But, what about situation of
> heavy
> > > load?  The ability
> > > > of a linux based forwarding engine is surely
> not
> > > at the same level
> > > > of any hardware based product, but to my
> > personal
> > > opinion any
> > > > comparation should be taken at the same
> > situation
> > > ( hardware,
> > > > software etc).
> > > 
> > > A switch that operates at line rate can still do
> > so
> > > under heavy load.
> > > There are well-known mechanisms (DiffServ) for
> > > controlling performance
> > > under heavy load.  Theoretically, there should
> be
> > no
> > > difference in the
> > > performance of DiffServ whether applied to IP,
> > MPLS,
> > > or for that
> > > matter, Appletalk, IPX, or any other switched
> > packet
> > > technology.  If
> > > you have found a platform-independent issue
> > inherent
> > > to MPLS that
> > > causes jitter, I am very interested in seeing
> it.
> > > 
> > > >  Another reason is that we try to find out how
> > > MPLS compares with IP
> > > > when realtime multimedia content is loaded.
> The
> > > bandwidth
> > > > requirement of realtime distributed virtual
> > > reality system is at the
> > > > level of Gbps, and that value may increase
> when
> > > number of people
> > > > participating increases.  So, we want to
> measure
> > > the situation that
> > > > accumulated dec/enc time is not negligible.
> > > 
> > > OK, that's a fair thing to want to measure.  But
> > > again, you're testing
> > > a specific implementation, and it's not
> reasonable
> > > to extend that
> > > comparison to any broader scope.
> > > 
> > > > 
> > > > Well, if R12000 is as cheap as 2511 that's not
> a
> > > question at all :-)
> > > > 
> > > 
> > > OK, if you want to talk specific router models,
> > let
> > > me speak to the
> > > ones I know best. :) A 12k and a 2500[*] are
> > > different.  They perform
> > > differently, are priced differently, and have
> 
=== message truncated ===


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com