The MPLS WG Archive

[nitin p <nitin_panj@yahoo.com>]

Anish,
Here is my topology
[TG]---[Ing]----[LSR1]--- [LSR2]----[Egr]----[Rec]
As you can see destination and Egress are not same.
In my last mail I have posted the mechanism I used to
measure these delays.
Your comments are most welcome.

Thanks,
Nitin

--- Anish Verma <anish_verma2001@yahoo.co.uk> wrote:
> hi nitin,
>     Could you plz show the topology that u r using?
>     I mean whether destination and egress node in ur
> topology r same.
>     if egress node and destination r same, then at
> the egress the IP lookup
> will not be
>     there as packet is destined for the node itself.
>     That make dealy at egress much lesser than the
> ingress.
> 
> correct me if i am wrong
> anish
> 
> 
> ----- Original Message -----
> From: "nitin p" <nitin_panj@yahoo.com>
> To: "Eric Osborne" <eosborne@cisco.com>; "Jing Shen"
> <jshen@cad.zju.edu.cn>
> Cc: "Eric Osborne" <eosborne@cisco.com>; "J.C.Ramesh
> Babu"
> <rameshbabu_j@infosys.com>; <mpls-ops@mplsrc.com>;
> <mpls@UU.NET>
> Sent: Sunday, December 08, 2002 3:25 AM
> Subject: Re: [MPLS-OPS]: Jitter and MPLS
> 
> 
> > 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
> 
=== message truncated ===


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