Objectives

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:

• an Application stack (OSI level 3-7)
  This is determined by the selected appli­cation and some options; and
• a Network stack (OSI level 1-2)
  This is determined by the network operator.

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).

Usage

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).

Expansion

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

Application

There are currently two Applications defined:

• File-transfer
  Specify File size in bytes for the transfer.  You can specify any (fixed point) number and use K, M or G as magni­tude for respectively Kilo-, Mega- or Giga-bytes (bytes of 8 bits).  By default 1K = 1024, but you can change that to 1000 (M & G are adapted accor­dingly).  The resulting file size is indicated (rounded result).
• Voice over IP (VoIP, streaming)
  Select the Codec, which determines sample/­packet rate and size.

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

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:

Codec	Bitrate	Frame size & interval		MOS	Remarks
	Kb/s	bytes	ms
G.711	64	80	10	4.1	PCM, ISDN
G.723.1a	6.3	24	30	3.9	H.324 videoconferencing
G.723.1b	5.3	20	30	3.7
G.726b	24	15	5
G.726c	32	20	5	3.85	international phone, DECT
G.728	16	10	5	3.61
G.729	8	10	10	3.92

Except for G.711, codecs do not (reliably) support tones (DTMF, modem/fax).

Web Pages

OSI Stack

The layered communication model and protocols as generally accepted:  the Open Systems Interconnection (OSI) defined by the International Standards Organisation (ISO).

level	name	comment	examples
7	Application		Browser, Skype
6	Presentation	Translations	HTTP, VoIP
5	Session	Initialise, finalise	FTP, RTP
4	Transport	End-to-end transport	TCP, UDP
3	Network	Routing & switching	IP
2	Link	Point-to-point	Ethernet
1	Physical	Electrical or optical interface	Ethernet, HDLC
(0)	medium	Cable (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 user					end user
7 Application					7 Application
6 Presentation					6 Presentation
5 Session					5 Session
4 Transport					4 Transport
3 Network		3 Network			3 Network
2 Link		2 Link	2 Link		2 Link
1 Physical		1 Physical	1 Physical		1 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:

• Segment:  at level 5 and above (commonly bare data, no overhead);
• Packet or Datagram:  at level 3 (including L3 overhead);
• Frame:  at the transmission level (L0··L2).

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:

RTP		bytes
	Version + Flags	2
	Sequence nr.	2
	Timestamp	4
	Synchr. Src. id	4

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:

TCP		bytes
	Source Port	2
	Destination Port	2
	Sequence number	4
	Acknowlegment number	4
	Offset + Flags	2
	Window size	2
	Checksum	2
	Urgency pointer	2
*	Option Timestamps	12

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:

UDP		bytes
	Source Port	2
	Destination Port	2
	Length	2
	Checksum	2

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

IPv4 header:

IPv4		bytes
	Version + Header length	1
	Type Of Service + Prio	1
	Packet length	2
	identification	2
	Flags + fragment offset	2
	Time To Live	1
	Protocol	1
	Header checksum	2
	Source IP address	4
	Destination IP address	4
*	Options	n 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

IPv6 header:

IPv6		bytes
	Vers. + Traffic class + Flow	4
	Payload length	2
	Next hdr	1
	Hop limit	1
	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:

MPLS		bytes
	Label + Traffic class + Bottom-of-Stack flag	3
	Time To Live	1

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).

Ethernet

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.3		bytes
	Preamble (synchronisation) + Start-of-Frame	8
	Destination MAC Address	6
	Source MAC Address	6
*	optional 802.1Q VLAN header, possibly containing 802.1p Priority (QoS); potentially double header for QinQ	0/4/8
	Lenght or Type	2
	Payload (padding to minimum 46)	46-1500
	FCS / CRC32	4
	Inter-frame Gap	12

VLAN

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.7041		bytes
	Payload Length Indication	2
	core Header Error Check	2
	Type	2
	type Header Error Check	2

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.

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
IP over PPP/HDLC 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:

• Line speed:  e.g. 10G b/s for 10GBaseX Ethernet (here 1K = 1000 by default);
• Average line occupancy or Channel Utilisation:  usually <70% (LAN) ·· >95% (WAN);
• Maximum packet size:  in rare cases, a network may limit the packet size (see notes below);
• Average packet size:  if unknown, use a value close to the maximum packet size (e.g. 96%);
• Hop count:  the number of nodes - 1.  Usually <5 for LAN,  >10 for WAN.

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.

Notes:

• For these calculations it is assumed that the specified applications A & B have no impact on the actual network load.  This is perfectly reasonable as the additional traffic from a single source is negligible in current fast networks.
• The maximum packet size (for transport over Ethernet) is 1500.  Some networks restrict this to improve interactive response.  However, it has consequences for all traffic through that network:  smaller packets imply more segments for File Transfer.
• Some gigabit LAN networks (i.e. not public internet) allow 'jumbo frames' (up to 9000 bytes/packet) to facilitate fast file transfer over Ethernet.  Abundant use has consequences for the average packet size, and thereby for the network transfer delay for all traffic.
• Some networks allow 'baby giant frames' (1600 bytes) to facilitate Ethernet over (IP/)MPLS over Ethernet.
• Use of MPLS will reduce the effective maximum packet size automatically.  If you don't want that, you have to increase the Maximum packet size accordingly.

Ethernet speed

Ethernet over radio (WLAN, WiFi):

variant	throughput	range
802.11a	27-54 Mb/s	15 m indoors to 30 m outdoors
802.11b	5-11 Mb/s	40 m indoors to 90 m outdoors
802.11g	22-54 Mb/s	45 m indoors to 90 m outdoors
802.11n	50-144 Mb/s	90 m indoors to 180 m outdoors (with directional antenna's several kilometers line-of-sight)

Notes:

• When Ethernet is used on a shared medium (bus or radio) as in a LAN environment where it was designed for with its Carrier Sense Multiple Access / Collision Detection (CSMA/CD) protocol, the effective speed is seriously impacted (WAN applications commonly use point-to-point full-duplex links at speeds of 100 Mb/s or faster). 
  Shared medium variants (i.e. the 10BaseX & WiFi variants) have to deal with contention, so the line speed and line occupancy in the calculation network must be set according to its effectively achievable speed.  For 10BaseX a speed of 7 Mb/s and an occupancy above 60% seem agreeable values.
• The speed of WiFi is also influenced by the distance, potential obstacles and interference.  You may have to adapt figures even more.
• WiMAX is not Ethernet but IEEE 802.16.

Results for File transfer

• Effective line speed:  net/payload line speed;  the result of Line speed, Delay caused by the Occupancy, and Overhead, in bits/s;
  and in bytes/second (8 bit bytes);
• Average packet rate:  number of packets (or frames) transmitted on the line per second;
• Average delay per node:  average delay (queueing & transmission) of a file transfer frame, in milliseconds;
• File transfer delay:  the overall delay to transfer the whole file over this network (in milliseconds, seconds or minutes depending on value);
• Transfer speed:  effective overall speed to transfer the file, in Bytes/s.

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

• Effective line speed:  net/payload line speed;  the result of Line speed, Delay caused by the Occupancy, and Overhead, in bits/s;
  and in bytes/second;
• Average packet rate:  number of packets (or frames) transmitted on the line per second;
• Average delay per node:  average delay (queueing & transmission) of a VoIP frame, in milliseconds;
• Average overall delay:  overall delay over the network, including sampling delay, in milliseconds.

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.