RTCP timers are randomized to avoid burst of RTCP packets in the network in case of synchronization among participants. For example, if all the participants are automatically invited into a conference at the same time, and if the RTCP interval timers are not randomized, then many participants may calculate the same interval timer and send the packets at the same time causing unwanted burst in the network. (You don't have to explain why burst is undesirable.)1b. We have seen leaky buckets in a variety of applications. Name three actions that a leaky bucket can take. Where would each of these actions be appropriate?
1c. Assume the MPEG frame sequence IBBPBBIBBP[B]BIBBPBB... If the frame enclosed in  is lost, what other frames are affected? (Mark the affected frames in the sequence).
mark packets diff-serv three-color marker delay packets edge shaping (within host) drop packets protection in network
1d. Why can DVRMP not just use the regular routing tables in making forwarding decisions?
It will not affect any other frame. This is because none of the other frame types (I, B, P) depend on B frame: I (intra) is independent; P depends on I or P; B depends on I or P.
1e. "Normal conversation is about 60 dB." What does this mean? How much louder (as a multiple) than the softest audible sound is this?
In DVMRP, multicast forwarding is made more efficient when a router sends the first packet only to those routers whose routes back to the source are through it. To implement this when a router Q receives an advertisement for a route to some network N with metric M from router R, and this metric is the smallest Q has received so far for getting to M, then Q sends a route back to R for the same network with metric M+(infinity). (In practice a number larger than any allowed metrics is used instead of infinity, e.g., 32). So, if a router receives a route for a network with a metric greater than infinity, it knows that this router should receive multicast packets from a host on that network. So, it can alter its forwarding decision based on this.
Since this requires additional information that is not present in the regular routing table, DVMRP has its own routing table.
In short, normal routing computes the "forward" path and outgoing interface, from a point to an IP address, while DVMRP computes the "backward" path, i.e., the interface a packet should be arriving on if it has taken the shortest path to the point. Since paths in the Internet are not symmetric, the two interfaces may not be the same.
Just discussing RPF and pruning will fetch partial credit only. DVMRP table has network (+mask) and metrics.
This means that the conversation is 60 dB louder than the softest audible sound, which is, as air pressure, 1060/20 = 103 = 1,000 times as much. details1f. Why would UDP be advantageous as a means for carrying signaling messages (as opposed to TCP)?
Signaling refers to protocols such as RSVP, SIP and (under a wider definition) RTCP.1g. Name two advantages and two disadvantages of proxying (vs. redirecting) SIP requests.
- TCP requires setting up and tearing down a connection, with a three-way handshake, thus increasing the delay and message count overhead.
- One cannot build a stateless SIP proxy using TCP.
Reasons that are of marginal significance:
Thus, these items would need to be qualified by the signaling protocol being used.
- multicast - not commonly used for signaling (except RTCP);
- signaling does need reliability, either by periodic retransmission or application-layer reliability;
- packet header overhead - signaling is infrequent, so 12 more bytes per packet are not likely to make a difference;
- congestion control - signaling rate is low (typically, << 1 packet/roundtrip time), so congestion control is not likely to be invoked even for TCP.
1h. How do you label a queue that has Poisson arrivals, fixed (deterministic) service times, one server and an infinite buffer?
proxy redirect advantage hide callee address; may hide caller address; lower delay caller gets choice as to whether to go to forwarded address disadvantage proxy is more complicated than redirect server delay, exposure of addresses
Using the Kendall notation, this is a M/D/1/infinity queue.1i. Describe the role of the PATH message in RSVP.
1j. Reverse path forwarding: Consider the topology and link costs below and suppose that node E is the multicast source. Using arrows to indicate flows, with "-->|" indicating a packet that is not forwarded beyond the receiving router, indicate links over which packets will be forwarded using RPF, and links over which packets will not be forwarded, given that node E is the source.
The PATH message is sent from the data source to the data destinations.
(Two of these were required.)
- It establishes state in each RSVP router, so that the RESV messages can travel back to the source on the same path that the actual user data will take.
- The PATH message carries the Tspec, which describes the traffic characteristics of the source.
- The PATH message can also be used to advertise the capacity of the nodes to the receiver (OPWA).
2. Essay: What are the advantages and disadvantages of RSVP being receiver-oriented? (Also describe briefly what it means.) What parts of RSVP could one remove if multicast was not important? Describe a simplified version of RSVP without multicast support, but that would be backwards-compatible.
3. Design task: Design a voicemail system for an Internet telephony service provider. Justify your protocol choices and show what kind of servers are needed. The voicemail service needs to play announcements to users, allow users to retrieve their voicemail via phone and web page and deliver an instant messages whenever they receive a new phone call. How much storage space would you need if each user receives ten calls a day, lasting two minutes each? Users are allowed to keep their messages for one week.
Receiver-oriented means that the data receivers initiate the actual reservation, sending requests towards the data sender.
Advantages of receiver-oriented protocols:
- Some branches of the multicast tree can decide that they do not need resource reservations, without affecting anything else.
- Receivers could subscribe to different levels of service.
Disadvantages of receiver orientation:
- Separate PATH and RESV messages are needed to establish state and reservations, each with their own reliability mechanism.
- Merging RESV requests is complicated.
- Killer reservations, where a higher-level reservation merges and this reservation then fails.
- Since routers can't adequately filter reservations, receivers may still experience random packet loss if their reservation is too small.
Non-issues (i.e., not valid answers):
- Scaling - receiver- and sender-oriented have the same scaling properties for multicast;
- multicast - both can support multicast;
- latency - one round-trip time in each case;
- merging for one sender - also possible with sender-oriented protocols.
If multicast was not needed, one could remove or greatly simplify the following components:
- reservation styles (FF, WF, etc.);
- PATH/RESV two-pass signaling;
- RESV state and NHOP (next hop)/PHOP (previous hop)/LIH (logical interface handle);
- error handling (simplified, e.g., killer reservation problem due to merging of reservations);
- non-RSVP region handling (simplified).
A simplified version would still use the PATH and RESV messages, but dispense with the items listed above.
Architecture: There are several possible architectures, depending on how voice mail messages are retrieved. The basic design includes a SIP proxy and a SIP user agent (UA). As usual, the SIP user agent has to register with the registrar. The SIP user agent accepts the call if the actual callee does not pick up the call. This can be accomplished by parallel forking, where the SIP UA waits the desired number of seconds before picking up. If the human user picks up first, the branch to the voice mail UA is cancelled. The voice mail server sends the announcement using RTP packets and records the RTP packets.
Naturally, the system can be connected via an IP telephony gateway to the circuit-switched telephone system.
The control of recording and playback can be done using either RTSP or SIP. For RTSP, the SIP UA acting as the voice mail server instructs an RTSP server to record the RTP stream and makes sure that the IP address of that server is contained in the SIP/SDP response. For SIP, the UA records the message itself and then is reachable via a special URI (say, firstname.lastname@example.org) for Alice to retrieve her messages. Using RTSP allows finer-grained control, e.g., fast forwarding through the email message. SIP, on the other hand, is likely to simplify the use of DTMF ("touch tones") to control the voicemail server from a regular telephone.
The voicemail server can also use a web interface to allow users to retrieve their messages as files, via HTTP, or deliver them as MIME email attachments to the user's email inbox via SMTP.
Storage space: Each user generates 20 minutes of voice a day or 140 minutes for one week. Under the pessimistic assumption that users keep all messages that long and the typical assumption of using G.729 as the codec (8 kb/s or 1 kB/s), one would need 140 * 60s * 1 kB/s = 8400 kB or 8.4 MB per user. (As an aside, an 80 GB disk could support the storage for about 9500 users, but one would likely have to stripe data across multiple disks to provide enough bandwidth for recording and playback.)