The MPLS WG Archive

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



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

[MPLS-OPS]: Jitter and MPLS

  • From: Eric Osborne <eosborne@cisco.com>
  • Date: Mon, 9 Dec 2002 08:55:16 -0500
  • Cc: alok <alok.dube@apara.com>, mpls-ops@mplsrc.com, mpls@UU.NET
  • User-Agent: Mutt/1.2.5i
  • X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562

On Mon, Dec 09, 2002 at 09:00:17PM +0800, Jing Shen wrote:
> 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.
>

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


> 
> > 
> > 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
> ZheJiang University(YuQuan)
> HangZhou, Z.J. 310027
> P.R.China
> 
> Tel: +86-571-87932423
> Mobile: (0)13516813753
> Email: jshen@cad.zju.edu.cn
> 
> **********************************************************************
> * The SunShine of life is made up of very little beams which is      *
> *  bright all the time                                               *
> **********************************************************************