The MPLS WG Archive

["alok" <alok.dube@apara.com>]

Hi,

sorry but im kindof lost on this bit..would appreciate if you could clarify
the same,

inline...

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

so on the ingress LER,

in the fwding table it would be more of "incoming interface---destn-ip(till
here to be matched)---tag label to be put while outgoing -- outgoing
interface"

wouldnt it? so essentially are u saying that this makes it slower?

the 1st part is the indexing part (till to be matched), the other is the
action....


on the P routers

u have FT as:

"incoming interface---label (till here to be matched)---outgoing label and
interface"


> Egress LER: L3 lookup not necessary (exception for
> aggregate prefix). 'tag forwaridng engine' can do the
> job with the Label lookup.

on the egress FT entry to match on looks like :

"incoming interface--label--destn-subnet-1(to be matched)--outgoing
interface"
"incoming interface--label--destn-subnet-2(to be matched)--outgoing
interface"


if your saying i have a supernet advertised via MiBGP to the remote end
hence traffic for both come in with 1 label, i need to do a specific network
route lookup, after i get the packet on egress.....right? if the table looks
like above, why do u say that this would be a problem? (be it hash or trees
or whatever algo)

am i missing something?

i actually dont know how typical ASICs split that functionality (i mean how
do u represent interface--and ip and label part etc" in the FT...but
assuming u even make a simple hash on that combo..i think its close enuf to
assume each entry wud be unique, even if different parameters are
involved...

not too sure abt that bit, wud be great if someone could clarify...

-rgds
Alok


>
> 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
> > > different interfaces and
> > > capabilities.  I would never do forwarding
> > > performance tests on a 2500
> > > and claim the 12k behaves the same way, nor would
> > I
> > > do tests on 12k
> > > forwarding and claim the 2500 performed the same
> > > way.  By the same
> > > token, you can't test a Linux forwarding
> > > implementation (a lot like a
> > > really fast 2500) and claim that its performance
> > is
> > > the same as any
> > > other router maker.
> > >
> > > [*] - sidebar to the viewing audience - a 12k
> > (GSR)
> > > is a Really Big
> > > router, and a 2500 is a Really Small router.
> > >
> > > > > >  Although we have not experimented with
> > > Cisco's express forwarding
> > > > > > and the like, and we do not experiment with
> > > large scale system with
> > > > > > real internet traffic pattern, we concern
> > that
> > > the result could
> > > > > > applied to large scale network.
> > > > >
> > > > > I'm concerned about that too, because it means
> > > that you're building a
> > > > > large-scale network out of Linux-based
> > > software-forwarding devices.
> > > > > But even if you do have a performance hit at
> > > encap/decap, you only do
> > > > > label push/pop at the edges of the network, so
> > > you'd only take this
> > > > > hypothetical hit at the edges, making scale a
> > > nonissue for your
> > > > > particular imaginary problem.
> > > > >
> >
> === message truncated ===
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
>