Subject: Re: [MPLS-OPS]: Jitter and MPLS

From: [email-masked]
Date: Mon, 9 Dec 2002 09:01:06 EST

Nitin-

It would be much helpful if you can specify the delay in a quantitative 
manner. This way we can really understand what are you talking about in term 
of delays.  Also, the specific number of Hops or LPS router, how many egress 
and ingress steps involved in the calculation. A general observation would 
not  be very accurate, since the implementation would be very different from 
one application versus the other, and from one type of services versus 
another.

Thanks-

George

---

From: nitin p <[email-masked]>
Date: Mon, 9 Dec 2002 06:24:01 -0800 (PST)

Hi George,
I have posted my results in of the mails, but here
they are again:

Ingress: 3.665 milli seconds
Egress: 0.035 milliseconds
core:    0.018 milliseconds
 
IP: 0.023 milliseconds.

For my measurements I have attached a sniffer at both
incomming and outgoing interface (same sniffer for
both so no clocking issue). I did the same thing for
boths LSR and LERs. Question of number of LSRs should
not affect the results, considering my measuring
technique.
Jing said He is also getting similar results, I am not
sure how he has done his measurement.

Thanks,
Nitin

> one application versus the other, and from one type

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

---

From: "alok" <[email-masked]>
Date: Mon, 9 Dec 2002 20:16:44 +0530

hi Nitin,

just curious...
your IP result says "0.023" end to end..
can u share "IP across what was your ingress LER" 
IP across your Egress LER 
and IP across your core too for a given packet?

-rgds
alok
----- Original Message ----- 
From: nitin p <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, December 09, 2002 7:54 PM
Subject: Re: [MPLS-OPS]: Jitter and MPLS

> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
>

---

From: nitin p <[email-masked]>
Date: Mon, 9 Dec 2002 15:48:07 -0800 (PST)

Alok,
> and IP across your core too for a given packet?
In my measuremnts these delays are at a hop.

  --H--e0[NODE]e1---H--
    |               |
    +---[SNIFFER]---+
H: Hub
Node:LSR/LER/L3 router
I am calculating delays at e0 and e1 and difference
will give the hop delay. Someone please correct me if
there is some problem in my measuring technique.

So end-to-end delay will be : n*(perhop-delay), in
case of IP, assuming link speed is fast enough.

Thanks,
Nitin

> > > manner. This way we can really understand what
> are
> > > you talking about in term 
> > > of delays.  Also, the specific number of Hops or
> LPS
> > > router, how many egress 
> > > one application versus the other, and from one
> type
> > > of services versus 
> > > another.
> > > 
> > > Thanks-
> > > 
> > > George
> > > 
> > > 
> > > 
> > 
> > 
> > Archive:
> http://www.mplsrc.com/mpls-ops_archive.shtml
> > 
>

---

From: "Brijesh Kumar" <[email-masked]>
Date: Mon, 9 Dec 2002 18:02:28 -0800

Nitin:

You need to analyse your packet forwarding code and the system configuration
with regards to:

1. What kind of L3 route look up is implemented? Is there any significant
difference in the routing table size at the ingress and the egress node? In
any case, measure time for route look up at ingress.

2.  Make sure you add a specific route to destination instead of forwarding
using a default route. This is to make sure you get average rather than
worst case performance from whatever loop up algorithm you are running.

3. Also, have you set up any IP packet classification or access control
policies at ingress? Check that the code does not do some default packet
classification or apply any default access control policies when you have
configured none? Both of these activities are very compute intensive and can
substantially impact the performance. If that is the case, add suitable
instrumentation  code to your packet forwarding code.

If you do the above, you are more likely to get the cause of long processing
time at Ingress. It  looks to me that you are unlikely to get similar
results if you were to use some other implementations of the forwarding
code. Try some other systems/implementation and see how it compares with
your current results.

Cheers,

--brijesh