RTCP Packet Types

Last day, we began talking about RTP, the real-time transport protocol, which is often used for things like Voice over IP.
We had started talking about RTCP which is RTP's control protocol.
It is used to provide performance feedback to the applications making use of RTP, used to correlate different streams, and is used to convey the identity of senders for display on the screen.
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):

Which of the following is true of the TCP extension header used to increase the the sequence number range ?

It increases the range of sequence numbers to 128 bits.
It uses system timestamps.
It specifies a multiplier on the units being acknowledged. So rather than acknowledge units as small as single bytes, one might acknowledge blocks of 2^k bytes where k is the multiplier.

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.

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.

The last 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).

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.

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) = (&sum_i x_i)^2/(n×(&sum_i (x_i)^2))
```
This returns a value between 0 and 1 with a value of 1 if each x_i have the same throughputs.