--- [EMAIL PROTECTED] wrote:---------------- On Thu, 28 Jun 2007 14:54:44 -0700, "Scott Weeks" <[EMAIL PROTECTED]> wrote:
>I'm searching the web for data on the overhead of using MLPPP and > not having too much success. If I'm gluing two T1s together do I > still get 1.536 times two or is there impact on this from the MLPPP? Enabling MLPPP will not change the clock-rate of the constituent-links. But the PPP frame overhead will be increased by either 4 or 2 bytes, per multilink fragment. This depends on whether long or short sequence number fragment format is negotiated for the bundle. See RFC 1990, section 3. ---------------------------------------------------- I knew it wouldn't "change the clock-rate of the constituent-links", but I was unaware of the "PPP frame overhead will be increased by either 4 or 2 bytes" part. I had found things on old NANOG posts like "...PPP framing overhead is close to negligible...", done some stoopid math and I wondered what the extra impact would be caused by what I now understand is called the MP header. I read the part of the RFC you mentioned to get that name. So, the 30000 foot level is that impact is probably even less than "close to negligible"... :-) Thanks, scott _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
