[c-nsp] Multilink Overhead

[Rodney Dunn]

May want to review this:


Line wrap may be a bit off..

-=-


Howw much overhead does Multilink add to packets?

Users occasionally wonder how much overhead Multilink adds to packets, especially when their connections are being pushed to capacity (at or above their rated bandwidth), and they want to know how much Multilink impacts the effective bandwidth of their connection.

The short answer is that Multilink encapsulation normally adds 6 bytes to every frame which is generated. However, this is an extremely misleading answer and does little to help you determine how using Multilink really affects the amount of effective bandwidth you have.

One factor is that Multilink may do fragmentation. Thus, network level datagrams are not necessarily 1:1 with the frames which are transmitted over the media. Basic PPP encapsulation adds two bytes to each datagram. After that, the datagram goes through the multilink process, which produces 1 or more multilink encapsulated fragments from that datagram. Each fragment/frame which is transmitted includes a Multilink header, which nominally adds 6 bytes to the frame. Additionally, each frame includes media-specific framing, external to the PPP and Multilink portions of the frame.

Thus, the total overhead added to a datagram (assuming all the individual member links have identical framing characteristics) is:

        E = P + N * (M + L)

where

    * P = Size of PPP Header added to original datagram before it is fragmented. This PPP Header consists of the PPP Protocol field, the length of which is normally 2 bytes. If PPP Protocol Field Compression is in use for the bundle (very rare except when bundle consists of async member links), under some circumstances this may be reduced to 1 byte.
    * N = Number of fragments generated from this datagram.
    * M = Size of PPP and Multilink encapsulation added to each fragment. M = 6 bytes. If PPP Protocol Field Compression is in use on the member link over which the fragment is to be transmitted (rare unless the member link is an async serial link), M may be reduced to 5 bytes.
    * L = Size of media-specific framing added to the fragment. This is any extra framing added by the layers "below" PPP in the transmission path. This value varies with the media type. 

The most common case is PPP over regular serial lines. In this case, the media format is HDLC. Ignoring the possibility of the use of HDLC Address and Control Field Comression (ACFC), the HDLC media-specific framing overhead L is 5 or more bytes:

    * HDLC Header: 2 bytes
    * HDLC Trailer: 2 bytes
    * 1 or more HDLC "Flag" bytes (the interframe delimiter) 

Hence:

        E = P + N * (M + L)

          = 2 + N * (6 + 5)

Additional bits or bytes might also be added at the link level, to maintain transparency of the data (bit stuffing, byte stuffing, character escaping, and similar).

For some types of media, the value for L can be so large as to overwhelm the overhead added by PPP. For example, consider a VDPN tunnel where PPP is embedded in L2TP. L2TP is an IP application layered on top of IP/UDP, and which embeds the PPP packets inside IP/UDP/L2TP packets. More precisely, the L2TP payload is an HDLC packet, which has dummy HDLC header plus embedded PPP frame. Thus, at a bare minimum, the value of L for L2TP works out to be (working from inside out):

    * 2 bytes for fake HDLC header on PPP packet
    * 6 to 32 bytes for LT2P header (and even longer is possible)
    * 8 or more bytes for UDP header
    * 20 or more bytes for IP headers
    * X more bytes of framing overhead, for whatever physical media over which the IP packets are ultimately transmitted. Typically this is an ethernet, which adds another 26 (or more) bytes. 

In practice, this adds up to over 40 bytes per frame even for physical media which have a lightweight encapsulation (and thus a small value for X).

Even if the overhead per frame is relatively lightweight, as with regular PPP-in-HDLC, the overhead can still consume a significant portion of the available bandwidth if a large number of fragments are generated per each datagram.

Example:

Consider a multilink bundle with member links of 64kbps each, where each link is a regular PPP-in-HDLC serial link. If the bundle has been configured with the fragment size set to 10ms, and the average packet size is ~1000 bytes, then there will be 14 fragments per packet on average. Thus, the overhead works out roughly as:

        P +  N * (M + L)
     =  2 + 14 * (6 + 5)
     =  156 bytes per datagram.

which equates to about 16% of the raw bandwidth of the connection being consumed in overhead. 

-=-





I'm copying and pasting from an internal page where someone had
explained this:



On Wed, Mar 21, 2007 at 12:14:30PM +0100, Oliver Boehmer oboehmer" wrote:
> Renuka K <> wrote on Wednesday, March 21, 2007 11:10 AM:
> 
> > Hi,
> > 
> > We have two E1s, configued with a Multilink Interface. But we are
> > observing around 300Kbps of additional traffic in the multilink. Is
> > this due to Multilink overhead?
> 
> no, MLP overhead is quite small (2-4 bytes per frame).. this must be
> something else..
> 
> 	oli
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/