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., 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 calculations: File transfer is about moving large quantities 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 negligible, minimal delay is crucial and minor errors can be ignored).
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 (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|
|G.726c||32||20||5||3.85||international phone, DECT|
The layered communication model and protocols as generally accepted: the Open Systems Interconnection (OSI) defined by the International Standards Organisation (ISO).
|5||Session||Initialise, finalise||FTP, RTP|
|4||Transport||End-to-end transport||TCP, UDP|
|3||Network||Routing & switching||IP|
|1||Physical||Electrical or optical interface||Ethernet, HDLC|
|(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: set-up of the connection, and the control connection are 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.
|Version + Flags||2|
|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 to guarantee 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 –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 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 ('window size'); this also takes time (and extra packets).
TCP segment header:
|Offset + Flags||2|
Note that the initiation and the closing sequence, MTU discovery and/or fragmentation, reduced transmission rate, and any retransmissions are not taken into account in the calculations (chances for bit errors are very slim in modern digital networks).
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 retransmissions would be unacceptable for real-time application anyway.
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 a fixed path). And Level 4 services must consider the action for lost datagrams and datagrams arriving out of sequence.
|Version + Header length||1|
|Type Of Service + Prio||1|
|Flags + fragment offset||2|
|Time To Live||1|
|Source IP address||4|
|Destination IP address||4|
|*||Options||n x 4|
'Protocol' indicates the higher level protocol (e.g. TCP=6, UDP=17, IPv4=4, IPv6 has several variants).
|Vers. + Traffic class + Flow||4|
|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.
|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).
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|
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:
|Payload Length Indication||2|
|core Header Error Check||2|
|type Header Error Check||2|
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.
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. 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 extraordinary delays. And usually there is somewhere a bottleneck in the network (overloaded and/or low-speed link). See also the section on Ethernet speed below.
|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|
Ethernet over radio (WLAN, WiFi):
|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)|
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. 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.
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.