OSI Architecture

ISO (International Organization for Standardization) was one of the first organizations to formally define a common way to connect computers called Open Systems Interconnection (OSI).
It defines a partitioning of network functionality into seven layers.
ISO usually in conjunction with the International Telecommunications Union publishes a series of protocols specifications based on the OSI architecture. This series is sometimes called the "X-dot" series as the protocols have names like: X.25, X.400, X.500.

More on Layers of the OSI Model

Layer 1 (Physical Layer) -- concerned with transmitting 0s and 1s over the network. Design issues deal with mechanical, electrical, and timing interfaces as well as physical transmission medium.
Layer 2 (Data Link) -- transforms a raw transmission facility into a line that appears free from undetected transmission errors and makes this available to the network layer. It breaks up the input data into data frames. If the service is reliable, the receiver acknowledges correct receipt of each frame with an acknowledgment frame.
Layer 3 (Network Layer) -- controls operation of the subnet. It needs to be able to route messages from the source to destination. Routes can be either static or dynamic. It operates in units of packets.
Layer 4 (Transport Layer) -- Unlike like the lower layers which often involved switches, routers and the like, this layer is typically implemented on hosts. It provides a process-to-process channel between hosts where processes on different (or the same) hosts can communicate by sending each other messages. It often adds sequencing information so that the original data can be reassembled at the other end.
Layer 5 (Session Layer) -- provides a name space that is used to tie together potentially different transport streams that are part of a single application. For example, an audio or video stream that being combined into a teleconferencing application
Layer 6 (Presentation Layer) -- used to specify the syntax of the data to be transmitted. You can think of this data as like specifying an XML language.
Layer 7 (Application Layer) -- contains a variety of protocols which are needed by the end user. For example, FTP, HTTP, POP mail, etc

Internet Architecture

OSI serves as a useful reference model.
The actual Internet Architecture is like the four layered picture above.
It is often called Transmission Control Protocol/ Internet Protocol (TCP/IP) architecture.
The transport layer contains two protocols TCP and UDP (User Datagram Protocol).
TCP provides a reliable byte-stream channel; UDP provides an unreliable datagram delivery channel.

Implementing Network Software

One of the keys to the internet's success is that it is relatively easy to write new application programs that make use of it.
Most operating systems provide an interface to the networking sub-system often called the network application programming interface (API).
Most networking APIs these days are based on the socket interface originally by the Berkeley distribution of Unix.
We will next look at this interface as it is exposed in Java...

Sockets in Java

In using sockets we imagine we have two machines on the internet: a client that wants to open a connection to a given application server.
The server typically provides some kind of application service: network time, ftp, etc.
A given machine might have several application services running on it. So in order for a client to connect to a server it needs to provide both the servers address and the port number of the particular service desired. For example port 80 for HTTP.
In setting up a server one needs a mechanism for binding oneself to a particular port.
Threads also need to be used, to handle more than one request at a time.

Server Code Snippets

To use sockets you should import the following packages:
```
import java.io.*;
import java.net.*;
```
To bind your application to a port in a try block you might create a ServerSocket object:
```
ServerSocket server = new ServerSocket(SERVERPORT);
Socket socket;
```
this might throw an exception if someone else is already bound to ServerPort.
In a while loop one could have the line:
```
socket = server.accept();
```
which could be used to set up one connection with a client; typically, one would then spawn a thread.
A Socket has methods getInputStream() and getOutputStream() for actually reading and writing data from the socket.

Client Side Code Snippet

The client also uses Socket objects. To connect to a particular address on a particular port, a client might use a line like:
```
Socket socket = new Socket("www.cs.sjsu.edu", SERVERPORT);
```
Code for Socket instantiation can throw an UnknownHostException, so is typically in a try catch block.
Again, the socket has methods getInputStream() and getOutputStream() which are then used for actually reading and writing data from the socket.
These methods return InputStream and OutputStream objects which are more for byte level transfer of data, so typically they are passed into constructors of DataInputStream or PrintWriter's and DataOutputStream and BufferedReader's to make it easier to write string.
When manipulating these, it is possible to throw an IOException.
When we are done using a socket we first call close() for each of the streams, then close on the socket.

In-Class Exercise

Make a small Java program using Sockets that connects to port 80 of "www.cs.sjsu.edu". It then writes:

GET / HTTP/1.1
Host:www.cs.sjsu.edu

followed by two carriage return, linefeeds.

It listens for and receives and prints to the System.out, the first 100 characters received, before closing the connection.

Please post your solution to the Feb 1 In-Class Exercise Thread.

Process Model

We next look at two design issues related to composing such protocols. By composing protocols, we mean, for example, the application layer using TCP must somehow invoke in which it turn must somehow invoke IP layer protocol.
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 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 responsible for the message 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 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, when 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 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 + TransferSize/Bandwidth

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 applications improve in performance as bandwidth increases, 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, most adjacent frames are only transmitted as the difference from the previous frame, so the amount of 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.

Network Architecture, Bandwidth and Latency

Outline