The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Dec> msg00148



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[MPLS-OPS]: Jitter and MPLS

  • From: "alok" <alok.dube@apara.com>
  • Date: Mon, 9 Dec 2002 18:47:29 +0530

Hi,

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