i have always found this to be a excellent resource, when looking into the operation and format of protocols. In general not much meat but enough in the morsel to help. http://www.protocols.com/pbook/ppp4.htm#MultiPPP
hope this may but as useful for you as it has been for me, and still is. Evan Scott Weeks <[EMAIL PROTECTED]> wrote: --- [EMAIL PROTECTED] wrote:---------------- On Thu, 28 Jun 2007 14:54:44 -0700, "Scott Weeks" 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 juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
