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

From: Jing Shen <[email-masked]>
Date: Sat, 07 Dec 2002 11:06:02 +0800

Although Eric's idea is taken by many people , our experiements shows
this
is not the truth at least with the situation of our testbed.

In fact we set up a small testbed consisting a Linux based MPLS engine.
In order to focus on difference between forwarding performance
difference
 between MPLS and IP, we use CBR traffic with static routing table.

The testbed is consist of  3 hops of MPLS(IP) forwarder between source
and 
destination. The experiments shows that:

  If the hardware and software system is kept at the same level, then:
  1) TCP throughput of MPLS is a little smaller than IP when path MTU is
the same.
     and difference increases when path MTU decreases.
  2) For UDP traffic,
     a) when best-effort policy is applied, if link along the path is
lightly loaded (below 30%)
        e2e performance difference IP and MPLS is nearly the same while
the IPDV of MPLS is 
        smaller than IP forwarding; if the link along the path is
heavily loaded, QoS of MPLS
        is worse than IP forwarding. the same result is applied to loss
rate.
     b) when resource reservation is applied, both method could
guarantee the e2e delay but
	MPLS shows better IPDV value with a little longer e2e delay.

  We found the reason for this phenomenon is the
encapsulation/decapsulation procedure of MPLS, and
the processing of MPLS forwarding. 

  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. The reason is, 1) a small testbed could
be considered as a 
emulation of tunnel through large network , and some of large network
use LER-to-LER LSP; 2)
we focus on forwarding difference between IP  and MPLS, and we think
technique like CEF and per-port
cache could be applied to both technologies. 3) the same queueing
mechanism is applied to both 
technologies in our experiments. 4) comparison should be taken at the
same level of cost.

The paper on this experiment will be published on Communication Journal
( Chinese) this month. 
any comment will be highly appreciated.

regards

> 
> No, not really.  MPLS lets you apply QoS using EXP bits, just like you
> can with IP Precedence; any mechanisms you can use with IP Precedence
> to reduce jitter (various queing schemes) are equally applicable with
> MPLS.  Using MPLS-TE can make you more likely to avoid congestion and
> therefore less likely to experience delay and jitter, but from a
> queueing perspective it's the same with MPLS and with IP routing.
> 
> eric
> 
> > Please let me know
> >
> > Thanks
> >
> > J.C.Ramesh Babu
> > Technical Specialist.
> > Communications and Products Division
> > Infosys Technologies Limited
> > Electronic City,
> > Hosur Road,
> > Bangalore.
> >
> > Ph #
> > Off : 91-80-4166472
> > Res: 91-80-6592375
> 
> -------
> The MPLS-OPS Mailing List
> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

-- 
Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, Z.J. 310027
P.R.China

Tel: +86-571-87932423
Mobile: (0)13516813753
Email: [email-masked]

**********************************************************************
* The SunShine of life is made up of very little beams which is      *
*  bright all the time                                               *
**********************************************************************

---

From: Eric Osborne <[email-masked]>
Date: Sat, 7 Dec 2002 00:33:12 -0500

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

> the processing of MPLS forwarding. 

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.

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

> The reason is, 1) a small testbed could
> be considered as a 
> use LER-to-LER LSP;

See earlier point about performance hit at the edge only

>  2) we focus on forwarding difference between IP and MPLS, and we
> think technique like CEF and per-port cache could be applied to both
> technologies.

The fact that you're considering different lookup methodologies for IP
and MPLS suggests even further that what you're profiling is your
implementation, and not either 
		a) a purely hypothetical situation (a la OPnet or
		whatever)
		b) a particular router implementation

I have no problem with you testing your own implementation; I have a
major issue if you try to generalize those results to claim that your
specific behavior is in fact an artifact of the protocol itself.

> 3) the same queueing

I don't understand point #4.  What is 'level of cost'?

> any comment will be highly appreciated.

Any chance of getting a version in English?

eric

---

From: Jing Shen <[email-masked]>
Date: Sat, 07 Dec 2002 21:14:19 +0800

Thanks for Eric's comment. And, read my comment in line please.

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

> zero or negligible time to perform this encap/decap will not have this

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

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. 

Well, if R12000 is as cheap as 2511 that's not a question at all :-)

> particular imaginary problem.

I'm sorry I means label stack operation by encap/decap. That is done at 
each hop. As I mentioned above, if the load is light there is no
difference
but when the load is heavy the difference comes up.

>                 b) a particular router implementation

I agree with you that there is difference between lookup method between
IP
routing and MPLS switching, this may introduce some performance
difference.

> specific behavior is in fact an artifact of the protocol itself.

I agree that implementation introduces performance difference. So, we
take
the experiments with the same hardware and software. The conclusion
could  
not be extended to the word like " any implementation of MPLS has
smaller 
jitter than any implementation of IP", and the switching fabric in
commerical product 
is nearly impossible to be congested. But, what about the accumulated
delay along a 
heavy loaded path?

> I don't understand point #4.  What is 'level of cost'?

I mean that the forwarding engine show has the same building cost.

> Any chance of getting a version in English?

I'm sorry we have not done a english version.
If you like I'd send you the experimental result. 

Thanks again. 

-- 
Jing Shen

State Key Lab of CAD&CG

Tel: +86-571-87932423
Mobile: (0)13516813753

---

From: Eric Osborne <[email-masked]>
Date: Sat, 7 Dec 2002 10:20:48 -0500

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

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

> but when the load is heavy the difference comes up.

Then what you're testing is the per-hop performance hit taken by label
swapping.  This is, again, very implementation-dependent.  In MPLS
forwarding you have to do a label lookup and label swap, in IP you
have to do a FIB lookup.  Whether these two are the same speed,
insignificantly different, or significantly different is a
platform-specific thing.  

> I agree with you that there is difference between lookup method
> between IP routing and MPLS switching, this may introduce some
> performance difference.

Right, but like I said above, the switching mechanism is not a
function inherent to the protocol.  

> I agree that implementation introduces performance difference. So,
> we take the experiments with the same hardware and software. The
> conclusion could not be extended to the word like " any
> implementation of MPLS has smaller jitter than any implementation of
> IP", and the switching fabric in commerical product is nearly
> impossible to be congested. But, what about the accumulated delay
> along a heavy loaded path?

If the per-hop delay due to implementation differences in MPLS
processing vs. IP processing is 0, then the accumulated delay is also
0.  If the per-hop delay due to different protocols is non-zero but
insignificant (let's say 1us per hop), then the total accumulated
delay is going to be so small that it's not noticeable by any
application using the network, and it will pale in comparison to other
sources of delay that must exist in this network.  If the per-hop
delay is significant, then yes, the total end-to-end delay will also
be significant.

> I mean that the forwarding engine show has the same building cost.

Cost level has little to do with it.  Nothing about either IP or MPLS
forwarding inherently takes more money to do.  The waaaaay-back,
long-ago argument that MPLS is faster at switching because it's a
20-bit lookup rather than 32-bit is obsolete.  There's also nothing
inherent to the cost of building a forwarding device that induces any
jitter, nor is there anything inherent that introduces different
jitter per protocol.
 
> If you like I'd send you the experimental result. 

Sure, I'd be interested to see whether there's more to this than I
think.

eric

---

From: Eric Osborne <[email-masked]>
Date: Sun, 8 Dec 2002 23:24:46 -0500

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" <[email-masked]> 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 <[email-masked]> 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 <[email-masked]> 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.
> > > > > 
> > > > > 
> > > > > > >      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.
> > > > > 
> > > > > 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. 
> > > > > 
> > > > 
> > > > you add is another 4 bytes of transmission
> > delay,
> > > > which should be so
> > > > 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
> > > > > 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.
> > > > 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
> > > > > when realtime multimedia content is loaded.
> > The
> > > > bandwidth
> > > > > level of Gbps, and that value may increase
> > when
> > > > number of people
> > > > > participating increases.  So, we want to
> > measure
> > > > the situation that
> > > > a specific implementation, and it's not
> > reasonable
> > > > to extend that
> > > > > 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
> > > > differently, are priced differently, and have
> > 
> === message truncated ===
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com

---

From: Jing Shen <[email-masked]>
Date: Mon, 09 Dec 2002 19:50:46 +0800

nitin,

I suggest you to dig into the code or contact Leu.
Our implementation generates nearly the same delay 
when acting as either Ingree or Egress. 

Is there any on-demand switching enabled?

-- 
Jing Shen

State Key Lab of CAD&CG

Tel: +86-571-87932423
Mobile: (0)13516813753

---

From: Jing Shen <[email-masked]>
Date: Mon, 09 Dec 2002 21:00:17 +0800

alok,

> 
> I cant figure this point
> 
> are you comparing ethernet--MPLS--IP--TCP frame with ethernet--IP--TCP
> frame? well then your frame size is larger....thats about the only
> difference i see.

That's the reason. The reason why we take that is, we do not consider 
MPLS as mechanism carrying TCP packet, and MPLS is to add new mechanism 
to IP networks, so the overhead is considered to be the one affecting 
throughput. If we want o compare payload of MPLS with payload of IP,
I can't find any acceptable parameters to be compared.

> 
> yes, but lets assume that u had a scenario where the MPLS+payload(be it IP
> of anything) was compared with IP+(payload) ...where payload is of equal
> size, then what is the result? do realise your switching on a smaller
> "label" than an whole IP address....and I also assume your switching table
> is not optimized for "aggregates etc"..it depends on your switching
> mechanism.
> 

We don't want to compare aggregation situation, but want to focus on
e2e performance difference.

> 
> well, we put L2 headers in each hop too and in cases of ethernet/Multiaccess
> media, the L2 header depends on the next-hop... you would have ASICs doing
> it on the interface/FT.
> 
> according to your logic, FR interfaces should give the same
> problem.....specially on MultiAccess topologies...
> 
> >
[snip]

-- 
Jing Shen

State Key Lab of CAD&CG

Tel: +86-571-87932423
Mobile: (0)13516813753

---

From: Eric Osborne <[email-masked]>
Date: Mon, 9 Dec 2002 08:55:16 -0500

> I can't find any acceptable parameters to be compared.

If you add 4 bytes to a packet, you've made the packet 4 bytes bigger,
and increased delay because there are 4 more bytes to transmit.  No
argument there.  Arguing that this has an impact on jitter is
something I don't get (a given flow should always have the same
additional label imposition delay, so 0 jitter), nor do I think it's
reasonable to state that label imposition in the general case has any
impact on delay other than the trans/prop delay of 4 extra bytes.  As
I've said again and again, if your implementation takes extra time to
add labels to a packet, it's perfectly fair to profile _your
implementation_, but there are ways to do label imposition such that
the act of imposition itself take no extra time.  Other than increased
packet size, delay (and most certainly jitter!) are artifacts of an
implementation.  Do you agree?

As far as comparing TCP/IP/MPLS/linklayer throughput
vs. TCP/IP/linklayer throughput, I'm surprised you can't find any good
mechanisms to measure there.  Surely you can simply look at the size
of the TCP windows, time to open up fully, and other such impacts on
"goodput" that exist in the T/I/M/LL case and not the T/I/LL case?
This seems to be a lot like comparing TCP/IP/PPP vs. TCP/IP/HDLC - you
have the same underlying clock rate and the frames are different sizes
- how does that affect TCP performance?

eric

---

From: nitin p <[email-masked]>
Date: Sat, 7 Dec 2002 13:55:00 -0800 (PST)

Hi,
Sorry for interrupting the discussion between Eric and
Jing.

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.

--- Eric Osborne <[email-masked]> wrote:
> different interfaces and

---

From: nitin p <[email-masked]>
Date: Sun, 8 Dec 2002 14:34:11 -0800 (PST)

Gopal,

IP: 0.023 milliseconds.

Thanks,
Nitin

---

From: "alok" <[email-masked]>
Date: Mon, 9 Dec 2002 17:04:05 +0530

Hi,

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

inline...

> use) both 'ip forwarding engine/process' and the 'tag

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"

> aggregate prefix). 'tag forwaridng engine' can do the

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

> implementations overhead on Ingress and egress may be
> different.
> rgds,
> gopal
>
> > > > Thanks for Eric's comment. And, read my comment
> > in
> > > line please.
> > > >
> > > >
> > > > could operate at line speed, and the latency in
> > a
> > > switch is
> > > under heavy load.  Theoretically, there should be
> > no
> > > difference in the
> > > and claim the 12k behaves the same way, nor would
> > I
> > > do tests on 12k
> > > 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
> > > > > > real internet traffic pattern, we concern
> > that
> > > the result could

---

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

Jing,

> Is there any on-demand switching enabled?
I couldn' get what you mean by on-demand switching
NItin

> *  bright all the time                              
>                 *

---

From: "Gopal@Yahoo" <[email-masked]>
Date: Sun, 8 Dec 2002 12:53:59 -0800 (PST)

Nitin,

---

From: "Anish Verma" <[email-masked]>
Date: Mon, 9 Dec 2002 21:21:28 +0530

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" <[email-masked]>
To: "Eric Osborne" <[email-masked]>; "Jing Shen" <[email-masked]>
Cc: "Eric Osborne" <[email-masked]>; "J.C.Ramesh Babu"
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Sunday, December 08, 2002 3:25 AM
Subject: Re: [MPLS-OPS]: Jitter and MPLS

---

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

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 <[email-masked]> wrote:
> comment in
> in a
> be no
> > > ones I know best. :) A 12k and a 2500[*] are
>

---

From: "alok" <[email-masked]>
Date: Mon, 9 Dec 2002 18:47:29 +0530

Hi,

> I can't find any acceptable parameters to be compared.

yes, but that way you can still come to a "final value" of MTU and make sure
the core always has that MTU..which fits the maximum payload size "as of
date".
...which i guess would be IPSEC in a way....(commericially most
common)..just a guess...

changing the MTU size is not going to be a big problem in the core as long
as you can freeze on the "final value" that doesnt mess up the TCP/RWIN
stuff and doesnt cause SAR...

 thats what i feels, im sure gurus on the list will give u better
perspectives... (unless u have no end to number of
encapsulations/labels/label in label and so on we are gonna get stuck i
guess.....)

so in you experimental network, simply increase average MTU to present +1
label size and the results will reflect more of what the final scenario will
be.... i think.

-rgds
Alok