This web page allows you to perform some calcu­lations on a packet switched network.  For example the delay incurred for a file transfer accross a hypo­thetical internet.  Or compare the perfor­mance of two networks for a parti­cular application.
For this purpose the protocol stack and the network are configurable.  The protocol stack is split in:

To allow more extensive calculations and comparison of applications, and/or stacks and/or networks, the calculation initially presents the results for application A using stack A over network A, and in parallel the same for (application, stack & network) B.
Then it presents the results for each application (with its own application stack) going over both networks (each with its own network stack).


You can click on any ? to get help on the related subject (in this window frame).

As the protocol stack data and results will be considerable in size, the results will scroll off the screen at the bottom.  Of course you can scroll up and down, but you may also collapse Application stack, Network stack and Network data by clicking in the corresponding header (grey area).


If you want more Applications and/or Networks than the 2 provided now, open the main page in a separate window (…/Network_m.html);  than you get 5 stacks of Applications & Networks (A··E).
Note that the networks now have 5 hops by default (as opposed to 15 in the 2 networks case).

For any questions, remarks, etc., or if you feel that a particular application or protocol is missing, please send me an email.


There are currently two Applications defined:

These two applications are very different for network calcu­lations:  File transfer is about moving large quan­tities of data (maximum size packets, correct transfer is a priority and delay is not), whereas Voice over IP is about moving small packets very quickly accross the network (amount of data is negli­gible, minimal delay is crucial and minor errors can be ignored).

VoIP:  Voice over IP

Here we are concerned with live voice streams (not the transfer of files, and for the calculation no music or video streams).  The method of coding the voice samples at the origi­nating side and the decoding at the desti­nation side is reflected in the 'codec' (coder/decoder).  There are various voice codecs with different bit­rates and different perceived qualities;  the quality is expressed in the MOS:  Mean Opinion Score from 1 (unintelligible) to 5 (very good).

Most codecs provide compression (e.g. diffe­rential coding):  this generates a multi-byte sample (not to be confused with the basic voice sample usually at 8 kHz (125 μs), cut-off at 3.8 kHz) covering several milli­seconds of speach.  Such a voice sample is sometimes also called a frame (also ambi­guous in this context).  Many codecs or gateways provide silence suppression (Voice Activity Detection;  no trans­mission when there is no speech;  the receiving side may generate 'comfort noise').

Sometimes, several voice samples are collected before they are trans­mitted (so the voice sampling rate is not the packet rate).  This allows more efficient trans­mission (less packets with their overhead), but increases the overall delay a bit.  Late packets lead to stut­tering (which quickly makes it unintelligible);  this can be compensated by more buffering, but that leads to poor turn-around response ('satellite conversations').
The recommended one-way overall delay for voice is 150 ms (i.e. including sampling delay);  the maximum accep­tabel delay is 250 ms.

There are a great many voice codecs, the most common ones are:
CodecBitrateFrame size & intervalMOSRemarks
G.7116480104.1 PCM, ISDN
G.723.1a6.324303.9 H.324 videoconferencing
G.726c322053.85international phone, DECT
Except for G.711, codecs do not (reliably) support tones (DTMF, modem/fax).

Web Pages

The transfer of web pages was considered as an Application, but deemed unrealistic.  Except for very simple pages, a web page involves multiple files (frames, style sheets, scripts, images and other objects) with a great variety in size.  A browser may use multiple streams in parallel to obtain these files, and these files may be cached somewhere at your side of the network.  So there are too many unknown parameters to obtain a realistic results.
Probably, a web page transfer can be approximated by a file transfer.

OSI Stack

The layered communication model and protocols as generally accepted:  the Open Systems Interconnection (OSI) defined by the International Standards Organisation (ISO).
7Application Browser, Skype
6PresentationTranslationsHTTP, VoIP
5SessionInitialise, finaliseFTP, RTP
4TransportEnd-to-end transportTCP, UDP
3NetworkRouting & switchingIP
1PhysicalElectrical or optical interfaceEthernet, HDLC
(0)mediumCable (copper/fibre) or ether (radio)

From the bottom up:

  1. The Physical layer defines the physical formats to transport the bitstreams to and from an adjacent node;
  2. The Link layer defines the formats and handling (synchro­nisation, signalling, start of a byte or frames) between two adjacent nodes;
  3. The Network layer takes care of routing through the whole network;
  4. The Transport layer takes care of the end-to-end transport:  the order and correctness of packets (requests retrans­mission if required);
  5. The Session layer takes care for the init­ia­li­sation and comple­tion of the relation with the other side;
  6. The Presentation layer handles the right presentation, e.g. the trans­lation of (special) characters;
  7. The Application layer contains the final application (e.g. mail- or browser-program).

end userend user
7 Application7 Application
6 Presentation6 Presentation
5 Session5 Session
4 Transport4 Transport
3 Network3 Network3 Network
2 Link2 Link2 Link2 Link
1 Physical1 Physical1 Physical1 Physical
(0) medium(0) medium

Data is the payload in a packet.  As most protocol layers add control information to a packet, the packet gets larger at each level (and the term 'packet' becomes ill-defined).  To indicate the data-plus-control-information, different terms are used at different levels in the protocol stack:

7 Application
6 Presentation
5 Sessiondatadatadata Segment
4 Transporth4data
3 Networkh3dataPacket/datagram
2 Linkh2data
1 Physical   h1dataFCS Frame

As the maximum frame size is commonly limited, the maximum datagram size and the maximum segment size are limited as a consequence.  How much smaller the datagram and the segment are, depends the the protocol stack (and the options) used.  So indirectly determined by the application.
As most files are larger than the maximum segment size, this maximum is used to partition the file.
In contrast, VoIP uses small segments, and the packet- & frame size are correspondingly smaller.

FTP:  File Transfer Protocol

OSI Level 5/6 (user interface 7)
Lower level protocols:  TCP

FTP does not use the packet header for protocol infor­mation exchange, but uses a separate control connection.  FTP provides trans­lation services (e.g. EBCDIC ⇔ ASCII).

Note:  set-up of the connection, and the control connection are not taken into account for any calculation.

RTP:  Real-time Transport Protocol

OSI Level 5
Lower level protocols:  UDP

RTP carries media streams (e.g. audio and/or video);  it is used in conjunction with the RTP Control Protocol (RTCP), which carries control information (like signalling) out-of-band.

RTP header:
Version + Flags2
Sequence nr.2
Synchr. Src. id4

Note:  the Control protocol (RTPC) is not taken into account in calcu­lations (commonly it is only active during set-up).
Also, a potential Header compression construct is not taken into account.

TCP:  Transmission Control Protocol

OSI Level 4
Lower level protocols:  IP

TCP is to guarantee reliable transport across an unreliable network.  At the trans­mitting side, volu­minous data is broken into chunks acceptable for the network (Maximum Transfer Unit, MTU);  each chunk –at TCP-level called segment– gets a sequence number and a checksum (among other data items), and is then handed over to IP for transmission.  At the receiving side, packets are accepted from IP, the checksum is verified, the segments are ordered, and a copy of the original data is reconstructed.  For incorrect segments and missing segments a retrans­mission is requested.
As a consequence, data transfer may experience considerable delays, but the transfer is reliable.  Furthermore, at the beginning of the trans­mission, TCP is trying to optimise the data transfer size ('MTU discovery') and trans­mission rate ('window size');  this also takes time (and extra packets).

TCP segment header:
Source Port2
Destination Port2
Sequence number4
Acknowlegment number4
Offset + Flags2
Window size2
Urgency pointer2
 * Option Timestamps12
The option Timestamps is commonly used;  this results in total 32 bytes overhead.

Note that the initiation and the closing sequence, MTU discovery and/or fragmentation, reduced transmission rate, and any retrans­missions are not taken into account in the calculations (chances for bit errors are very slim in modern digital networks).

UDP:  User Datagram Protocol

OSI Level 4
Lower level protocols:  IP

UDP uses very little overhead, but provides no reliability (packets may get damaged or lost).  It is suitable for live streams (audio, video) and multi-casting (broadcasting);  the delays involved in retrans­missions would be unacceptable for real-time application anyway.

UDP header:
Source Port2
Destination Port2

IP:  Internet Protocol

OSI Level 3
Lower level protocols:  MPLS, Ethernet

IP is the heart of internet (originally intended to interconnect networks, hence inter-net):  it carries the datagram through the network (the terms datagram and packet are used inter­changeably in practice:  it is the level 3 transfer unit, but then what is level 3 ?).  The wide-spread version is IPv4, but as IPv4 address space is now exhausted, networks will (have to) switch to IPv6.

Note that IP may support payloads up to 64 Kbytes (IPv6 even more), but most networks go nowhere near that value.  A size of 450 bytes is considered a minimum (MTU), 1500 bytes for the packet is a common maximum (Ethernet).

Note:  IP is connectionless (does not require a call/session set-up;  every datagram travels inde­pen­dently across the network, so needs to contain full network addresses), and unreliable (datagrams may get damaged, or –more likely– may get lost).  As a consequence, a packet may use a different route than the previous one (and so it is virtually impossible to guarantee any Quality of Service along the path as there isn't a fixed path).  And Level 4 services must consider the action for lost datagrams and datagrams arriving out of sequence.


IPv4 header:
Version + Header length1
Type Of Service + Prio1
Packet length2
Flags + fragment offset2
Time To Live1
Header checksum2
Source IP address4
Destination IP address4
 * Optionsn x 4
Options require a multiple of 4 bytes, but options are commonly not used for normal applications/­operations.

'Protocol' indicates the higher level protocol (e.g. TCP=6, UDP=17, IPv4=4, IPv6 has several variants).


IPv6 header:
Vers. + Traffic class + Flow4
Payload length2
Next hdr1
Hop limit1
Source IP addr.16
Destination IP addr.16
The 'next header' corresponds to the IPv4 'protocol' field.

MPLS:  Multi-Protocol Label Switching

OSI Level 3-
Lower level protocols:  Ethernet, FR

MPLS is a level 3 protocol which is often used to tunnel IP-packets along a fixed path (allowing traffic management) in the core network (i.e. the MPLS-network forms a subnetwork).  3 labels seems a reasonable average.

MPLS header:
Label + Traffic class + Bottom-of-Stack flag3
Time To Live1

Note that MPLS decreases the maximum packet size, and with that the maximum segment size for all file transfers accross that network:  an MPLS subnetwork will slow down all file transfers along the way (but only for about 0.27% per label).


OSI Level 1&2+
Lower level protocols:  - (copper/fibe cable or radio)

Ethernet (IEEE 802.3) is an OSI Level 1 & 2 protocol, originally intended for Local Area Networks.  Ethernet comes in may variants (mostly regarding physical aspects) but all use the same basic frame format:
Ethernet IEEE 802.3bytes
Preamble (synchronisation) + Start-of-Frame8
Destination MAC Address6
Source MAC Address6
 *optional 802.1Q VLAN header, possibly containing 802.1p Priority (QoS); potentially double header for QinQ0/4/8
Lenght or Type2
Payload (padding to minimum 46)46-1500
FCS / CRC324
Inter-frame Gap12


 802.1Q:  This Ethernet option extends the header (keeps the payload at the same size).

Generic Framing Procedure

OSI Level 2
Lower level protocols:  - (SDH/SONET)

GFP is defined in ITU recommendation G.7041 as a generic method to transport Protocol Data Units over synchronous path (typically SDH or SONET).
There are 2 variants in application:  the transparent (GFP-T) and the framed (GFP-F) variant;  our interest is with the latter.  It encapsulates a client frame (e.g. Ethernet or PPP) without preamble/start-of-frame and interframe gap in GFP, and transports it through one or more SDH paths (i.e. virtual concatenation using reverse multiplexing).  Typically 10 Mb/s through VC12-5v (i.e. 5 VC12 channels @ 2.048 Mb/s), 100 Mb/s in VC3-2v, and 1 Gb/s in VC4-7v.  Commonly, Link Capacity Adjustment Scheme (LCAS) is used to manage the tributary channels.

GFP frame (GFP-F) for Ethernet:
GFP G.7041bytes
Payload Length Indication2
core Header Error Check2
type Header Error Check2
Above 8 bytes replace the 20 bytes Ethernet preamble/start-of-frame & interframe gap.

GFP exhibits the same behaviour as point-to-point Ethernet:  it emulates a channel with the same speed as Ethernet, with slightly less overhead, and potentially over much longer distances.  Consequently, for our purposes, simulating GFP-F sections has no added value (use Ethernet L2 & L1 instead).
It is unclear how common GFP is used to aggregate IP traffic over SDH/SONET, and which channel speeds are then used.  Obviously, in such cases a routing/­bridging capability is required at the GFP nodes.  And for low traffic aggregation, there is no need to match the specific external Ethernet interface speed in the SDH/SONET paths.

[Under consideration:]

PPP:  Point-to-Point Protocol

OSI Level 1/2 (typically over serial lines, or GFP), or 3+ (over IP)
Lower level protocols:  0 or 3

Multilink Point-to-Point Protocol (MP)
Frame Relay Forum (FRF).
Unclear what status and popularity this has, and what frame sizes.

PoS:  Packet over SDH/SONET
Apparently Ethernet over SDH/SONET (e.g. GFP) is now more accepted.

Network Parameters

These values depend on the general use of the network:

Invalid values are flagged in red.

The effective line rate (i.e. the speed and occupancy) is the limiting factor for performance.  The speed of a link to service an incoming packet is effectively the 'idle bandwidth' (100%-occupancy x line speed; M/M/1 calculation), so gigabit links can be loaded to 99% without causing extra­ordinary delays.  And usually there is somewhere a bottle­neck in the network (overloaded and/or low-speed link).  See also the section on Ethernet speed below.


Ethernet speed

The limited routing capability of Ethernet through repeaters, bridges and 'Ethernet switches' is not relevant for our purposes, and therefore ignored (routing is done anyway, though an Ethernet switch adds 1 hop). Ethernet comes in may variants –mainly reflecting cable type and distance covered– but here were are only interested in the effective speed. 
10BaseXoriginal Ethernet bus: 10 Mb/s peak, sustained avg 3 Mb/s
100BaseXFast Ethernet (FE): 100 Mb/s, usually point-to-point-full duplex
1000BaseXGigabit Ethernet (GbE): 1 Gb/s
10GBaseX10 Gb/s Ethernet
100GBaseX100 Gb/s Ethernet

Ethernet over radio (WLAN, WiFi):
802.11a27-54 Mb/s15 m indoors to 30 m outdoors
802.11b5-11 Mb/s40 m indoors to 90 m outdoors
802.11g22-54 Mb/s45 m indoors to 90 m outdoors
802.11n50-144 Mb/s90 m indoors to 180 m outdoors (with directional antenna's several kilometers line-of-sight)


Results for File transfer

For this calculation it is assumed that there is only a single packet from this transfer at a node at any time (except of course at the source node).  This seems a realistic assumption:  packets from the same source go in the same direction, so it is unlikely that multiple packets from a single transfer arrive (nearly) simul­ta­neously (i.e. a negligible fraction of the packets may travel along another route).  The effective speed of all lines (i.e. depending on speed and occupancy) on any node are assumed to be at the same level, so the rate of incoming packets is about the same as the rate of outgoing packets (no local accumulation except queuing).  But as this transfer has to compete with other uses of the network, its packets will have to queue for transmission along with the rest.

The results seem slightly better than achievable in the 'real' world, especially with small files, probably because the ignored initiation and closing sequence, MTU discovery and retransmissions (or link load is even higher).
As with any model calculation, results are indicative only.

Results for Voice over IP

This calculation does not assume that the IP packets have the Type Of Service flag Delay set (many nodes haven't implemented this feature anyway), so these packets do not 'jump the queue'.  These packets will have to queue like any other packet.  But the packets –and therefore the frames– are short.
As with any model calculation, results are indicative only.