RE: [nsp] Multiple T1s versus MLPPP

From: Martin, Christian (cmartin@gnilink.net)
Date: Wed Feb 14 2001 - 00:20:25 EST


> i was thinking about the case for interleaving for voice (which is the
> most common reason to do mlppp fragmentation). at speeds above 768k,
> latency is low enough, that you don't need to enable fragmentation.
> you can still enable it, but the benefits it gets you is minimal.

I see. But MLPPP fragmentation was not designed to mitigate the affect of
serialization delay for low-latency traffic. Fragmentation needs to be
performed here anyway, MLPPP or not. As far as common reasons for MLPPP
fragmentation, I was under the impression that this was put in here to 1)
Help balance link utilization and 2) to allow for differing link speeds to
live in the same bundle. I guess that now, mlppp fragmentation has a new
use!

thanks,
chris
  

>
> regards
> .siva
>
>
> >
> > > however the difference becomes less important with links
> > > faster then 768k,
> > > as there is no reason to do multilink fragmentation, and
> multilink
> > > fragmentation should be disabled in this case.
> > >
> > > regards
> > > .siva
> > >
> >
> > Siva,
> >
> > How did you arrive at this assertion? Fragmentation
> _should_ be orthogonal
> > to link speed. There is nothing in RFC 1990 to indicate
> that fragmentation
> > functionality be dependent on link speed. Are you
> suggesting that at higher
> > bit rates (assuming a standard Internet packet size
> distribution) the MLPPP
> > engine has difficulty sending and receiving fragments?
> >
> > regards,
> > ./chris
> >
>



This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:29 EDT