The MPLS WG Archive

[Eric Osborne <eosborne@cisco.com>]

On Sun, Dec 08, 2002 at 02:34:11PM -0800, nitin p wrote:
> 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 :)

Yeah, or ask Jim Leu, I think it's his code. :)

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

Aggregate prefix is when you have a router doing aggregation that is
also the tail of an LSP, like so:


10.1.0.0/24
A
 \
  \
   B-----D-----E
  /
 /
C
 10.1.1.0/24

If B sends 10.1.0.0/23 to D, and D sends labeled packets to B that are
destined to something inside 10.1.0.0/23, B has to do an IP lookup on
the packet (first removing the label stack) to figure out whether to
send it to A or C.



eric

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