cs398 Lecture Notes
Spring 2000
Week 13, Thursday

For today you should have read the handout about RED,
and you should write answers to questions 1, 2, 11.

And you should send me spoofed email before Friday.


SNMP
----

This is a pretty general recipe for a distributed database:

Transport: GET, SET

Format: names of variables, format of results

Names of variables defined by MIB (management information base)

Format of results defined by ASN.1 (Chapter 7)

Abstract Syntax Notation

   <tag, length, value>

Solves the big-endian, little-endian problem.

Floating-point formats?

Marshalling of structures?


Multimedia Applications
-----------------------

Way back in Chapter 1, we talked about the semantic gap
between the basic service provided by the network and
the set of services commonly needed by applications.

UDP provides a pretty bare-bones process-to-process TP.

TCP adds many of the functions most applications need.


Multimedia applications fall in between.  They need more
than UDP, but TCP contains some things that are
unnecessary, some that are implemented inappropriately
and some that are undesireable.

    (Name one of each)


One solution to this problem is for multimedia applications
to build their own protocols on top of UDP (the same way
HTTP and SMTP are built on TCP).

Quickly it becomes clear that there are common features
needed by all MA.

These features can be factored out and implemented once
and for all as an intermediate layer between the application
and UDP.

RTP
---

Real time transport protocol

Common requirements

1) sender and receiver agree on (maybe negotiate) data format
   and encoding scheme

2) timestamping data: when should this bit get played?

   if everything were delivered exactly on time, we could
   play it as soon as it arrives

   since there is variation in delay (jitter) we send
   everything a little early

   in other words, we maintain a playback buffer

   if it gets there late, it will still be in time

   if it gets there promptly, there is a delay between
   when it arrives and when it plays

   if it gets there super late, then everything subsequent
   will be delayed, although we can sometimes catch up by
   shortening silences

3) facilitate synchronization: sound with image, or multiple
   image or multiple sound

4) monitor packet loss so that applications can respond
   appropriately

   (as opposed to TCP, where this functionality resides lower
   in the protocol stack)

   (What might different applications do?)

5) indicate frame boundaries

   useful for shortening (or lengthening) silences, as
   mentioned above

6) indentify stream sources


   (Why do headers have to be small?)

   (Why do packets tend to be small?)

Padding scheme is an interesting example of how RTP really
chisels on header bits.

One bit indicates that there is padding.

   (How do we figure out how much?)


RTCP
----

Real-time transport control protocol

RTCP is to RTP as ICMP is to IP


A few highlights
----------------

The idea of a mixer is very cool.

Think of an audio stream as a sequence of talkbursts.

If they don't overlap, then the mixer just intersperses
them, using the timestamps for synchronization.

   (Wait, I thought the timestamps measured arbitrary
   ticks, and different streams might use different
   granularities).

What if they do overlap?  Multiple talkbursts can be
merged at the application level.  Not clear that this
can happen at RTP level.

Even so, the book implies that the merged stream is smaller
than the sum of the two streams.  Hmm.


Clock sync
----------

RTCP packets map time-of-day timestamps to tick timestamps.

      (How do you deal with clock error, skew, drift, etc.?)

Distributed clock sync algorithms (maybe).


Summary
-------

So, what have we learned?

1) some details about the more common networks and protocols
   out there

2) some understanding of _why_ things are the way they are

3) some recurring themes that are broadly applicable

   a) protocol design
   b) multi-level interfaces and the semantic gap
   c) hierarchical aggregation
   d) distributed algorithms and anarchic design
   e) new kinds of modularity, like separation of policy
      and mechanism, and autonomy between administrative domains

4) reading skills, ways of extracting answers from technical
   documents

5) a tiny bit of network programming, and the tools to
   go figure out the rest