Outline

• Process Model
• Message Buffers
• Performance
• Bandwidth and Latency
• Delay X Bandwidth Product
• High-Speed Networks
• Application Performance Needs

Protocol Implementation Issues

• On Monday, we discussed how to write application layer programs in Java through the socket interface.
• This is similar to the way a high-level protocol might interact with a low-level protocol. For example, TCP needs an interface to send outgoing messages to IP and IP needs to be able to deliver incoming messages to TCP.
• In the protocol stack: we would have interfaces like application to TCP, TCP to IP, etc.
• We next look at two design issues related to composing such protocols. By composing protocols we mean for example, application layer using TCP must somehow invoke in which it turn must somehow invoke IP layer protocol.

Process Model

• Most operating systems provide an abstraction called a process.
• Each process runs largely independently of other processes, and the OS is responsible for making sure resources, such as address space and CPU cycles are allocated to all the current processes.
• The process abstractions allows one to have a lot of things executing concurrently on the same machine.
• At the application level we have even mentioned that we might have an smtp daemon process, an http daemon process etc.
• The change that occurs when the OS stops one process from executing on the CPU and starts up another one is called a context-switch. It can be an order-of-magnitude slower than a function call.

Process Per Protocol versus Per Message

• One way to implement the protocol stack is to have each protocol in the stack have its own process -- after all, many application protocols have their own process.
• This would be called a process-per-protocol strategy. So the protocol at level i sends messages to the process responsible for the protocol it needs at level i-1, and so on.
• The alternative is process-per-message. Each protocol is a static piece of code and the OS associates the processes with the messages.
• That is, when the message arrives from the network the OS dispatches a process that is makes responsible for the messages as it moves up the protocol graph. At each level, the procedure that implements that protocol is invoked, which eventually results in the procedure for the next protocol being invoked, and so on.
• This magic might go on in our Monday's code, when server.accept(), or a inStream.readInt() is called: We recursively call functions down the protocol stack till we actually get data (we might block for a bit), then we pop our way back through the function calls each returning the data with the appropriate headers stripped off.
• The reverse happens when we do a write.
• process-per-message is typically used over process-per-protocol because context switching is so much slower than function calls.

Message Buffers

• Consider again how we send data at the application layer: we might have an int which is stored in some application layer memory, and we call our output stream's writeInt, this data would be copied to some buffer of the transport layer.
• If we pursued this idea to each layer of the protocol stack, then layer i would copy data to layer i-1's buffer and so on.
• This kind of layered copying of the same data is slow. Most network subsystems define an abstract data type for messages that is shared by all protocols in the protocol graph.
• This structure varies from OS to OS but is often some kind of linked-list: layer i-1 gets a list from layer i and appends on to the front of the list its header, etc.

Performance

• So far we have been looking mainly at design requirements that influence the functional aspects of networks.
• Over the next several slides we look at requirements of networks related to performance, and the terminology associated with these requirements.

Bandwidth and Latency

• The two main ways of measuring network performance are: its bandwidth (throughput) and its latency (delay).
• The bandwidth of a network is the number of bits that can be transmitted over the network in a certain period of time.
  • For example, a network might have a bandwidth of 10 million bits/second (Mbps).
  • Sometimes we will also consider the time its takes the network to transmit each bit of data. So for a 10 Mbps network this would be .1 microseconds (μs).
  • We might also talk of the bandwidth of a single link in a network. We might say we have a 1Mbps link.
• The latency of a network corresponds to how long it takes a message to travel from one end of the network to the other.
  • Again, sometimes we will be interested in this information for a single link or an end-to-end channel.
  • Latency is measured in time. For example it might take 24 milliseconds (ms) for a message to go across North America
  • Often, we will be interested in the round-trip time (RTT) -- the time to get to a destination and back.

Three Components of Latency

• There is a latency associated with the speed of light. The speed of light travels: 3.0 × 10⁸m/s in a vacuum, 2.3 × 10⁸m/s in a cable, 2.0 × 10⁸m/s in a fiber. So in a vacuum to send anything 1 m take at least 1/(3.0 × 10⁸) seconds. We will use the term propagation delay to mean the time it takes to propagate a signal through the system (this might be longer than the speed of light delay).
• Another component of latency is the time to transmit a unit of data. This is a function of the network bandwidth and the size of the packet that needs to be sent.
• There is also a latency associated with queuing delays within the network.

So we could define total latency as:

Latency = Propagation + Transmit + Queue
Propagation = Distance/SpeedOfLight 
    (will be different if looking at general propagation delay)
Transmit = Size/Bandwidth

Perceived Latency

• The relative importance of bandwidth versus latency depends on the application.
• Suppose one had a 1 byte message that we want to transmit across the country and get a 1-byte reply (without much computation at the other end).
  • This situation would be latency bound.
  • The transmit component of the total latency on a 1Mbps versus 100Mbps channel is 8μs versus .08μs; whereas, the propagation delay of any data might by 100ms.
• On the other hand, if one was downloading a 25 megabyte image from a digital library.
  • It might take 20 seconds to transmit over a 10Mbps channel.
  • So a difference in the propagation delay is 1ms versus 100ms won't make much difference.

Delay × Bandwidth Product

• The product Delay × Bandwidth is another useful metric.
• You can think of a channel between two hosts as a pipe: the bandwidth measures the size of a cross-section of the pipe and the delay its length.
• So Delay × Bandwidth gives the volume of the pipe -- the maximum number of bits that could be in transit through the pipe at any instant.
• For example, a transcontinental channel with a one way latency of 50ms and a bandwidth of 45 Mbps is able to hold:

  50 × 10^-3 × 45 × 10^6 bits/sec
  = 2.25 × 10^6 bits ≈ 280KB.
  

• Notice if the receiver of data needs to send a message back saying that they are receiving, then up to 2 × Delay × Bandwidth many bits might have been sent before the first bit of data can be acknowledged.
• Often as the RTT case is the case of interest, Delay × Bandwidth actually is given with the factor of two already incorporated.

High-Speed Networks

• The bandwidth on today's networks are increasing at a dramatic rate.
• The speed of light though has not been changing (at least in the standard model). So the transcontinental RTT of a 1 Gbps link is the same 100ms as it is for a 1Mbps link.
• To send a 1MB file over a 1Mbps network with an RTT of 100ms takes 80 RTTs to send the file. Each RTT 1.25% of the file is sent.
• In contrast, a 1MB file doesn't even come close to the 12.5MB that can be sent in one RTT on a 1Gbps network.
• So for larger bandwidth networks latency starts to play a larger role in the throughput in network design.
• Here:

  Throughput = TransferSize/TransferTime
  TransferTime = RTT + 1/(Bandwidth × TransferSize)
  

• To transmit a 1MB file across a 1Gbps network with a 100ms latency, the transfer time would be 108ms. That means, the effective throughput will be 1MB/108ms = 74.1Mbps.
• Transferring more data, helps throughput, having to retransmit things and wait another RTT hurts it.

Application Performance Needs

• Different applications have different needs for bandwidth: some application will improve performance as bandwidth increase, others can have explicitly stated upper bounds on the bandwidth they need.
• A video stream might send an image of resolution 352 × 240 pixels, each pixel might have 24 bits of color information, so the size of each frame is (352 × 240 × 24)/8 = 247.5 KB. At 30 frames a second, we can put an upper bound on the throughput needed at 75Mbps.
• In the real would, ost adjacent frames are only transmitted as the difference from the previous frame, so the data per frame is actually much lower. The data per frame also varies as some sequences of frames have bigger delta's (differences) than others.
• To accommodate the real world, one often talks about the "average bandwidth requirements" of an application as well as the "peak rate" of bandwidth needed.
• In addition to bandwidth requirements, applications might also have delay requirements. For instance, we might need a video frame every 33 ms. The networks might have variations in its latency called jitter, and so this can affect our app and we might need to do things like buffering to smooth out the latency.