Outline

• More Requirements of Networks
• Quiz

Requirements Revisited

• Last day, we began talking about some requirements one might have of an internet if we were to try to build one from the ground up...
• We looked at the requirements that an application programmer, network designers, and network providers might have.
• Today, we will look at requirements related to connectivity, resource sharing, common services, communication patterns, and reliability.

Connectivety

• Networks obviously must provide connectivity among a set of computers
• We want to be able to address issues of privacy and security concerning which computers are connected.
• Nevertheless, we want systems we can grow to arbitrary size as needed. Such systems are said to scale.
• We will now spend the next several slides examining more specific requirements to build networks that can handle these kinds of connectivety issues.

Links, Nodes, and Clouds

To begin we want to define some of the different ways computers might be connected:

• A link is a set of two (point-to-point) or more (multiple-access) computers (nodes)connected by some physical medium such as coaxial cable or optical fiber.
• Multiple-access links tend to be limited both in the numbers of nodes they can have and in the geographic distance between nodes; however, it is cheaper to have one wire to connect many machines than many.
• If we want to connect more computers than what a multiple-access link can support then we need to connect computers indirectly.

Quiz

Which of the following is true?

1. When downloading the page http://www.cs.sjsu.edu/ the first step your browser will do is contact the machine on which this page lives.
2. The main concern of network application programmers is how easy the network is to administer.
3. Delay is more important than the occasional dropped frame in a video-conferencing system.

Switched Networks

A switched network is a network of nodes where nodes connected to two or more links run software to forward data received on one link out on another. The nodes which do this forwarding are collectively called the cloud and individual forwarding nodes are often called switches. Nodes that try to communicate with each other are often called hosts. There is more than one way to set-up a switched network:

• Circuit-Switched -- used by phone systems. A dedicated circuit (path) between to nodes that want to communicate is set-up
• Packet-Switched -- used by most computer networks, we'll talk about this kind of switched network on the next slide.

Packet-Switched Networks

• In this kind of network, data is sent in discrete blocks of bits called packets.
• A store-and-forward strategy is then typically used. Each node in the network first (1) receives a complete packet and stores it in its memory, (2) it then forwards the packet ot the next node. Hopefully, if the software is designed properly the packet eventually arrives at the desired node.

Internetworks

• In larger scale systems, one often has several independent networks (clouds) which are connected to each other through some node called a router or a gateway.
• Such a set-up is called an internetwork.
• One immediate requirement on such network systems is that we need each host to have some kind of identifier, like a phone number, so hosts know how to talk to each other. This identifier is called an address.
• The process of determining which node to forward a packet to is called routing.

Cost-effective Resource Sharing

• Why should we choose packet-switched networks as our way to ensure any two hosts can communicate with each other?
• Give n hosts there are n(n-1)/2 possible choices for pairs that might want to communicate.
• We want to support multiple hosts communicating at the same time. This will often mean we can't dedicate a link in the cloud to a particular pair of hosts communications. i.e., we will need to share cloud links.
• One way to share a link is to do multiplexing of which there are several subtypes:
  • synchronous time-division multiplexing (STDM): divide time into discrete quanta and give each user a quanta they can send over in a round-robin fashion
  • frequency-division multiplexing (FDM): transmit the data of different users over the channel at different frequencies.
• STDM and FDM might not use all of the available resources because a user might not need his quanta when his time slot arrives or use his frequency when he could and so that bandwidth is not used. Also, to use these systems one needs to know the maximum number of users in advance.

Statistical Multiplexing

• This is the most common kind of multiplexing we will consider this semester.
• First, like STDM, statistical multiplexing takes turns in who gets to use the channel, but unlike STDM takes turns among only people who need to send data. Second, in order to say when a turn ends, statistical Multiplexing will have a maximum amount of data that can be sent in a packet. We can break larger messages into packets.
• The decision of which packets to send next over a shared link can be made in a number of different ways: for instance, the switch might service packets in a first-in, first-out manner.
• This decision will influence the quality of service (QoS) of the network.

Support for Common Services

• Another requirement of computer networks is that application programs running on various hosts be able to communicate in a meaningful way.
• One could have application designers build all the complicated network functionality needed for the application into each application program.
• Since many applications make use of common services, it makes more sense to identify these common services implement them once, and then let the application designer build his program using those services.
• A goal of network service would then be to provide a channel between two application-level processes that need to communicate. This leads to questions like: What kinds of properties should this channel have? Different choices might work better for different kinds of applications.

Identifying Common Communication Patterns

• An example early internet application is the file transfer protocol (FTP).
• Here we have a server which supports access to its files and a client who wishes to access and manipulate them.
• The server and client communicate over the channel by the client sending messages called requests and the server sending response messages in reply.
• If one had a video service, one might decide on needing two streams one for such request/reply messages, we want for sure to arrive exactly, and another message stream where, video frames could be sent in a timely manner, but allowing for the occasional dropped frame.
• So from the above we see it could be useful for a network designer to build networks which allow for a few fixed number of different kinds of channels. For instance, one in which each packet is guaranteed to arrive and one in which no guarantee is provided.

Reliability

• Reliable message delivery is one function a network can provide. It is useful to consider why we might have reliability problems:
  • Machines crash and need to be rebooted
  • Switches run out of buffer space
  • Software forwards packets incorrectly to oblivion
• A network needs to be designed to recover from certain kinds of failures so that application programs don't have to deal with these issues.

Three Categories of Network Failures

• The transmitted data over the physical link might contain a bit error. i.e., a 0 becomes a 1 or vice-versa. Often, one gets several bit errors in a row. This is called a burst error. These errors might be caused by things like lightning strikes, power surges, interference in general. For copper, 1 in 10^{6 or 7} bits on average will be corrupted. For optical fiber, the error rate is about 1 in 10^{12 or 14}. One can try to use error detecting codes or error correcting codes to mitigate for this.
• A packet might be lost by the network. For instance, this could happen because of an uncorrectable bit error in the packet or because a switch becomes too overloaded and is forced to drop the packet. It might happen because the packet was forwarded out on the wrong link because of a software error.
• A physical link is cut for some reason: Bad weather, errant tractor, computer died, software crashes, etc. One problem in dealing with this kind of error is that it is over hard to distinguish this case from a slow or malfunctioning computer.

Network Architecture

• We have now described how networks need to provide general, cost-effective, fair, robost connectivity among a large number of computers.
• They also must be able to evolve to handle changing technologies.
• To help organize the problem of creating such networks, designers use general blueprints called network architectures to help guide the design and implementation of networks.
• We will now spend a moment to look at some of these architectures in more detail.

Layering Protocols

• To decompose the problem of building a network into manageable components, we split the network into layers, each of which is designed to handle some particular aspect of network communication.
• The abstract objects that make up the layers of a network system are called: protocols.
• Lower layers will provide services to higher layers through a service interface. For example, a request/reply protocol would support operations by which an application can send and receive messages.
• A protocol defines a peer interface on another machine. This is the interface through which the same layer on two different machines communicate.

Protocol Graphs

• Except at the hardware level where peers directly communicate with each other over a link, peer-to-peer communication is indirect -- each protocol communicates with its peer by passing messages to some lower-level protocol, which in turn delivers the message to its peer.
• There might be more that one protocol at a given level. For instance, request/reply protocol, message stream protocol.
• We therefore represent the suites of protocols that make up a network system with a protocol graph. Edges in the graph represent depends on relations.

Encapsulation

• In the protocol graph slide, we assume the RRP protocol does not know anything about the data given to it by a File Application or Digital Library Application.
• So it gets an uninterpreted string of bytes.
• In order to tell its peer RRP process what to do with the message it prepends a few byte data structure called a header in front of the message. Sometimes one also appends a data structure called a trailer.
• The rest of the message excluding headers and trailers, is called the body or payload.
• We say the application's data is encapsulated in the new message created by protocol RRP.
• This kind of header encapsulation might go on at each layer in the protocol stack. So the actual data sent over hardware in our case might look like: HHP header, RRP header, Data.

Multiplexing/Demultiplexing

• Multiplexing/Demultiplexing is used in protocol stacks.
• For instance, two different applications might have their messages multiplexed over the channel provided by the RRP protocol.
• The RRP peer on the remote machine must demultiplex these message and pass them to the corresponding application.
• In order to know which application the RRP peer should send a given message to, a demultiplexing (demux) key is used. So this string must be part of the RRP header.