Module 2: Performance in Real-time Networks Flashcards
Where all possible places where failures can happen in a network?
disk errors
incorrect software
hardware issues
solution space for such errors:
- hop by bop reliability
- end to end reliability
*implementing reliability at lower layers is insufficient
which reliability method does IP use?
end to end reliability
not as complex, too expensive to make every hop reliable by checking checksums
checksum
A checksum is a small-sized block of data for the purpose of detecting errors that may be introduced during its transmission. Checksum could be computed using different functions, such as the hash function at one side and then the original data along with the checksum value is transmitted onto the other side. The receiver, with the knowledge of the function over which checksum is computed, can recompute the checksum using the function and the data it receives and check that they match. If they match, there is a very high probability that the data has not been accidentally altered or corrupted during the transmission. Otherwise, there is some corruption.
IP Layer uses system call API for TCP and UDP, which is exposed to the application
end-to-end reliability
When does it make sense to violate end to end principle?
Sometimes solution 1 is better and sometimes solution 2 makes more sense. Let’s consider an example of lossy links. Let’s suppose I want to send data from A to B, and they’re both mobile devices. Let’s suppose between the mobile devices and the access point we have high probability of packet drops. For example, due to multiple mobile devices trying to transmit at the same time locally. In this case, solution 1 is a good approach to use because you can guarantee reliability on a per-hop basis between the mobile host and the access point. Doing so may result in performance penalty between the mobile host and the access point, but you can result in much higher reliability if you do that. And in doing so, reduce the need for you to retransmit the entire packet again and again from the mobile host to another mobile host, somewhere over the internet.
E2E rule of thumb for in network design
if hosts can implement functionality correctly, implement it in a lower layer only as a performance enhancement
but do so only if it does not impose burden on applications that do not require that functionality
metrics for network performance
- link bandwidth capacity: maximum rate (in bps) at which the sender can send data along the link
- propagation delay: time it takes the signal to travel from source to destination
- packet transmission time: time it takes the sender to transmit all bits of the packet
- queuing delay: time the packet needs to wait before being transmitted because the queue was not empty when it arrived
- processing time: time it takes a router/switch to process the packet header, manage memory, etc.
sending one packet timing diagram
some formulas
latency = propagation + transmit + queuing delay
propagation = distance / speed of light
transmit = packet size bandwidth
queuing delay = queue length / bandwidth
bottleneck example
you can only transmit as fast as your slowest link
cut through switching
a packet starts being forwarded (sent) as soon as its header is received
throughput?
throughput of a connection or link = total number of bits successfully transmitted during some period [t, t+ T) divided by T
link utilization = throughput of the link / link capacity
delay related metrics
delay of bit from A to B
- the time required for bit to go from A to B
round-trip time (RTT)
- two way delay from sender to receiver and back
other delay-related metrics
jitter
- variability in delay
bandwidth-delay product
- product of bandwidth and delay = “storage”capacity of network
- for efficient resource usage: keep the pipe full. affects TCP (reliability delivery) buffer size
measuring jitter
naming and addressing
