This web page allows you to perform some calculations on a packet switched network. For example the delay incurred for a file transfer accross a hypothetical internet. Or compare the performance of two networks for a particular 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).
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).
For any questions, remarks, etc., please send me an email.
There are currently two Applications defined:
Most codecs provide compression (e.g. differential 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 milliseconds of speach. Such a voice sample is sometimes also called a frame (which is also ambiguous in this context). Many codecs or gateways provide silence suppression (Voice Activity Detection; no transmission when there is no speech; the receiving side may generate 'comfort noise').
Sometimes, several voice samples are collected before they are transmitted (so the voice sampling rate is not the packet rate). This allows more efficient transmission (less packets with their overhead), but increases the overall delay a bit. Late packets lead to stuttering (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 acceptabel 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 | |
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 | |
| (0) | medium | Cable (copper/fibre) or ether (radio) | |
From the bottom up:
| 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:
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.
OSI Level 5/6 (user interface 7)
Lower level protocols: TCP
FTP does not use the packet header for protocol information exchange, but uses a separate control connection. FTP provides translation services (e.g. EBCDIC ↔ ASCII).
Note: the control connection is not taken into account for any calculation.
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 calculations (commonly it is only active during set-up).
Also, a potential Header compression construct is not taken into account.
OSI Level 4
Lower level protocols: IP
TCP is intended for reliable transport across an unreliable network. At the transmitting side, voluminous data is broken into chunks acceptable for the network (Maximum Transfer Unit, MTU); each chunk –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 retransmission is requested.
As a consequence, data transfer may experience considerable delays, but the transfer is reliable. Furthermore, at the beginning of the transmission, TCP is trying to optimise the data transfer size ('MTU discovery') and transmission rate; this also takes time (and extra packets).
Note that the initiation and the closing sequence, MTU discovery, reduced transmission rate, and any retransmissions are not taken into account in the calculations.
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 |
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 life streams (audio, video) and multi-casting (broadcasting); the delays involved in retransmissions would be unacceptable for real-time application anyway.
UDP header:
| UDP | bytes | |
|---|---|---|
| Source Port | 2 | |
| Destination Port | 2 | |
| Length | 2 | |
| Checksum | 2 | |
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 interchangeably 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 independently 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 one). And Level 4 services must consider the action for lost datagrams and datagrams arriving out of sequence.
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 |
IPv6 header:
| IPv6 | bytes | |
|---|---|---|
| Vers. + Traffic class + Flow | 4 | |
| Payload length | 2 | |
| Next hdr + Hop cnt | 2 | |
| Source IP addr. | 16 | |
| Destination IP addr. | 16 | |
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 | |
OSI Level 1&2+
Lower level protocols: - (copper/fibe cable or radio)
Ethernet is an OSI Level 1 & 2 protocol, originally intended for Local Area Networks. The limited routing capability through bridges ('Ethernet switches') is not relevant here (routing is done anyway), and therefore ignored. Ethernet comes in may variants –mainly reflecting cable type and distance covered– but here were are only interested in the effective speed. In particular when Ethernet is used on a shared medium (bus or radio) where it was designed for with its Carrier Sense Multiple Access / Collision Detect (CSMA/CD) protocol, the effective speed is impacted.
| Variant | Comment |
|---|---|
| 10BaseX | original Ethernet bus: 10 Mb/s peak, sustained avg 3 Mb/s |
| 100BaseX | Fast Ethernet (FE): 100 Mb/s, usually point-to-point-full duplex |
| 1000BaseX | Gigabit Ethernet (GbE): 1 Gb/s |
| 10GBaseX | 10 Gb/s Ethernet |
| 100GBaseX | 100 Gb/s Ethernet |
Note that for shared medium variants (i.e. the 10BaseX), the line occupancy in the network must be set according to its maximum achievable speed (i.e. at least 70% for the 10 Mb/s, leaving the 3 Mb/s effectively available).
Ethernet frame:
| Ethernet IEEE802.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 | |
OSI Level 2
Lower level protocols: - (SDH/SONET)
GFP is defined in ITU recommendation G.7041 as a generic method to transport Packed 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/flag 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 tributing 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 | |
For simulation purposes, 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, simulating GFP-F sections has no added value (so use Ethernet L2 & L1).
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.
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 is now more accepted.
These values depend on the general use of the network:
The effective line rate (i.e. the speed and occupancy) is the limiting factor for performance. And usually there is somewhere a bottleneck (overloaded and/or low-speed link). High-speed links can be loaded over 95% without causing extraordinary delay.
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) simultaneously (i.e. ignoring packets travelling along another route). The effective speed of all lines (i.e. depending on speed and occupancy) in the network 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 queueing). 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).
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.