> 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