Firewalls

On the homework, you are asked to look at the performance of TCP over a small network.
Another important issue in configuring a network is setting up and maintaining a firewall.
A firewall is an network appliance or application that controls access to a network, or a host on a network, based on inspecting the network traffic flowing through it.
There are two common styles of firewall, those that look at the packet headers and determine if the packet should be allowed; and those that look at the target application of the packet and determine if it should be allowed.
The firewalls built-in to Windows and Mac OSX are mainly of the latter type and usually have a relatively easy to use GUI interface. The Windows firewall seems to be more configurable.
We will look at the packet-based firewalls which tend to be a little more sophisticated and are often run from the command line. (Although there are GUI front-ends such as Water-roof).
Mac OSX come with one such tool called ipfw; Linux has iptables which is based off of the earlier ipchains.
Both of these support both static and dynamic rules. They also support the ability to do traffic shaping.

Running a Firewall

To use ipfw and iptables, you usually need to run commands as either root or use sudo.
To see all of the rules that are currently being used by your firewall you can do a command like:
```
ipfw list
```
or
```
iptables --list
```

To add a basic rule in ipfw you might do:

ipfw add 1000 allow ip from 10.0.0.0/8 to any

or for iptables like:

iptables -A INPUT -s 192.168.0.0/24 -p tcp -m tcp --dport 80 -j ACCEPT

The command to delete a rule for ipfw is delete followed by the number or delete followed by the whole rule; similarly, for iptables you can use the option -D or --delete.
Notice for both we specify the protocol. In the ipfw example, it was ip, and in the iptables example it was tcp. You could also say udp.
For IPFW, we could have said deny rather than allow; similarly we could say DROP rather than accept for iptables.
-s is for source -d is for destination address in iptables.
For ipfw you can use the keywords in or out at the end of the rule. You can add a list of ports after the the addresses.
Typically, one keeps ones rules in a file like /etc/rc.firewall or /etc/firewallrules so they are read at start-up.

Transport Protocols for Real-Time Applications

An application is called real-time if it has a strong requirement for the timely delivery of information.
For example, Voice over IP, video, audio conferencing, etc. are real-time applications.
Streaming applications such as internet radio or YouTube, lack human-to-human interaction, and so often place less stringent requirements on the underlying protocols.
Nevertheless, they share enough commonalities with real-time applications to warrant common protocols for both types of applications.
One protocol for doing this is called RTP which derived many of its features from the vat application (a videoconferencing tool).
RTP can run over many lower-layer protocols but commonly runs over UDP.

Requirements of Real-Time Applications

The most basic requirement for a general-purpose multimedia protocol is to allow similar applications to interoperate with each other.
For example, two independently implemented audio-conferencing tools should be able to interoperate.
To handle this the protocol should provide a means to negotiate the kind of compression, encoding, etc of the audio data being sent. (Similarly, the codec if video conferencing was being done).
Another important requirement for RTP is to enable the recipient of stream data to determine the timing relationship among the received data.
The received data needs to be placed into a playback buffer to smooth things out like jitter.
If a conference is being done, then synchronization of several streams needs to be done. Also, for video one needs to probably synchronize separate audio and video streams.
The application must also be able to handle packet loss in a reasonable manner.
RTP needs to be able to handle framing. For instance, know when data that has arrived constitutes a displayable unit.
Finally, RTP needs to have some way of naming senders and receivers that is more friendly than IP addresses.

RTP Details

RTP was developed at the IETF and was first published in 1996.
It is commonly used to do VoIP and Video-teleconferencing.
It is actually a pair of protocols: RTP and the Real-time Transport Control Protocol (RTCP)
For each application (audio, video, etc) which makes use of RTP, a profile and one or more formats are defined.
The profile provides a range of information used to ensure a common understanding of the fields in the RTP header for that application class.
The format specification explains how the data that follows the RTP header is to be interpreted.
For instance, for audio the format might say that each byte that follows is a sequence of sound samples.
This use of profiles and formats is an example of application level framing.

Header Format

V=2 | P | X | CC | M | PT | Sequence Number

Timestamp

Synchronization source (SSRC) identifier

Contributing source (CSRC) identifiers
...

Extension Header

RTP Payload

The first 12 bytes of the header are always present, CSRCs and extensions may or may not be present
The first two bits are a version identifier which is currently version 2.
P is a "padding" bit which is set if the RTP payload needed to be padded to some size, for instance, because of the requirements of an encryption algorithm.
The extension bit X is used to indicate the presence of an extension header; the 4 bit CC field is used to indicate the number of CSRCs.
M is used for framing.
PT is a 7 bit field that indicates the payload type. Using it an application could switch from one kind of coding scheme to a different one.
The sequence number is used to detect missing or mis-ordered packets. RTP does not do anything when it detects a packet loss (the app decides what to do).
The timestamp is used to enable playback from different portions of the stream and to synchronize tracks if more than one stream is in use (say audio and video).
Timestamps represent the time at which the first sample in the packet was generated.
The synchronizing source (SSRC) is a 32-bit number that uniquely identifies a single source of an RTP stream. In a multimedia conference each sender picks a random SSRC and is expected to resolve conflicts in case of a collision.
The contributing source (CSRC) is only used when the RTP streams pass through a "mixer" of serveral other sources. In which case the mixer will be the SSRC and the other contributers are listed in the CSRC.

Control Protocol

RTCP provides three main functions
- Feedback on the performance of the application and the network
- A way to correlate and synchronize different media streams that have come from the same sender.
- A way to convey the identify of a sender for display on a user interface.
The first function may be useful for rate-adaptive applications.
The second function entails both being able to follow the name of a stream if its SSRC has to change because of a collision (using CNAMEs), and also synchronizing the clocks of different media that may be involved in the communication.

RTCP Packet Types

RTCP supports four kinds of packets:
1. Sender reports, which enable active senders to a session to report transmission and reception statistics.
2. Receiver reports, which receivers who are not senders use to report reception statistics.
3. Source descriptions, which carry CNAMEs and other sender description information
4. Application-specific control packets.
These packets are typically sent over UDP.
RTCP also has a mechanism to scale back the reporting frequency of participants as the number of participant increases. The intent here is to reduce the fraction of the total bandwidth consumed by reporting.
Sender and receiver reports are similar. However, a typical sender report also has in it: a time of day of when the report was generated; an RTP timestamp of when the report was generated; and a cumulative count of the packets and bytes sent by this sender since it began transmission.

Sender/Receiver Reports

These contain (it should be noted that a sender might send to some other sender a report concerning the data received from it):

One block of source data that has been heard since the last report.
Its SSRC.
Fraction of lost packets since last report.
Total number of packets lost from this source since it was first heard from.
Highest sequence number received.
Estimated interarrival jitter for the source.
Last actual timestamp received via RTCP for this source
Delay since last sender report received via RTCP for this source.

Performance

We have now looked at a few different transport layer protocols.
To evaluate these protocols we use the two quantitative metrics we have looked at this semester: latency and throughput (bandwidth).
What is interesting in analysing things at the transport layer is typically we have both hardware and software issues involved.
Measurement of a given protocol is useful to understand the performance a particular application can expect to see.

How to Conduct Performance Experiments

Any report of experimental results should begin by describing the experimental method. This consists of:
- The experimental apparatus: What kind of machines, networks, etc. the experiment was conducted on, what OS and version was used, what was the test program used.
- A description of each trial of the experiment.
- The total number of trials.
The report should then give the data in a meaningful format such as a graph, and discuss this data.
For example, the book describes an experiment conducted between a pair of 733-Mhz Pentium workstations, connected by a 100Mbps Ethernet cable that was only a room long. The machines were running Linux (2.4 kernel), and the test program involved ping-ponged messages between the two machines.
A trial consisted of ping-ponging a message between the two machines 10,000 times, and calculating the RTT by dividing the total time by 10,000.
Three trials were done at each message size and averaged.
Message sizes from 1 byte to 1000 bytes using both the UDP and TCP protocols were used.
A graph of message throughput versus message size was then plotted and discussed.

Congestion Control and Resource Allocation

The next problem we will consider this semester is how to effectively and fairly allocate the resources of the Internet among a collection of competing users.
We basically have time to define the problem and we defer its solutions to CS158B.
The shared resources we are worried about are the bandwidth of links and the lengths of the buffers and queues on the routers or switches where packets are awaiting transmission.
When one has two much traffic/demand on such a resource it is said to become congested.
Most networks provide some kind of congestion-control mechanism to mitigate against congestion.
Resource allocation is the process by which network elements try to meet the competing demands that applications have for their network resources.
There are three important features of the network architecture connected to resource allocation.
- A given source may have more than enough outbound capacity; however, between the source and destination there may be a low capacity link or router that causes a bottleneck. This bottleneck may affect more than one route.
- The sequence of packets sent between a source/destination pair following the same route is called a flow. Flows can be viewed at different granularities such as host-to-host; process-to-process.
- Different networks might have different service models: such as best-effort to one in which individual flows get certain guarantees of quality of service (QoS).

Taxonomy of Resource Allocation Methods

We next look at three dimensions on which resource allocation mechanism may be classified:
- Router Centric versus Host Centric -- whether it is up to routers to decide which packets to be dropped; or whether it is the end hosts that make these kind of decisions
- Reservation-Based versus Feedback-Based -- in the first of these, resources are allocated when the flow is established; in the second way, the resources are dynamically allocated based on network conditions
- Window-Based versus Rate-Based -- allocation might be controlled by saying how big a window the hosts can have or it might be controlled by saying how many bits/second they can send.

Evaluation Criteria

In order to say how good a resource allocation mechanism is , we need to say how effectively and fairly it allocates resources.
So we need some way to define what these mean.
To describe the relationship between the throughput and delay of a network is the so-called power of the network:
```
Power = Throughput/Delay.
```
To effectively allocate resources we want to maximize this ratio.
One measurement of the fairness of a metric was given by Jain. Given flows 1,..., n with throughputs (x₁,...x_n), the fairness is defined as:
```
f(x₁,...x_n) = (∑_i x_i)²/(n×(∑_i (x_i)²))
```
This returns a value between 0 and 1 with a value of 1 if each x_i have the same throughputs.

Firewalls, RTP, Resource Allocation

Outline