\section{Integrated Services}

% -----------------------------------------------------------------
\begin{slide}{}

   \begin{sitem}
      \item High-speed networks have enabled new applications
      \begin{sitem}
         \item they also need ``deliver on time'' assurances from the network
      \end{sitem}
      \item Applications that are sensitive to the timeliness of data are
            called {\em real-time} applications
      \begin{sitem}
         \item voice
         \item video
         \item industrial control
      \end{sitem}
      \item Timeliness guarantees must come from {\it inside} the network
      \begin{sitem}
         \item end-hosts cannot correct late packets like they can correct 
               for lost packets
      \end{sitem}
      \item Need more than best-effort
      \begin{sitem}
         \item IETF is standardizing extensions to best-effort model
      \end{sitem}
   \end{sitem}
\end{slide}
% -----------------------------------------------------------------
\begin{slide}{}

   \subsection{Service Model}

   \begin{sitem}
      \item Two types of applications
      \begin{sitem}
         \item real-time
         \item elastic
      \end{sitem}
      \item Example real-time application (audio)
      \pichere{audio.eps,height=1.5in}
      \begin{sitem}
         \item sample voice once every 125$\mu$s
         \item each sample has a {\it playback time}
         \item packets experience variable delay in network
         \item add constant factor to playback time: {\it playback point}
      \end{sitem}
   \end{sitem}
\end{slide}
% -----------------------------------------------------------------
\begin{slide}{}  

   \begin{sitem}
      \item Playback buffer
      \pichere{playback.eps,height=3in}
      \item Example distribution of delays     
      \pichere{jitter.eps,height=3in}    
   \end{sitem}
\end{slide}
% -----------------------------------------------------------------
\begin{slide}{}  

   \begin{sitem}
      \item Taxonomy of real-time applications
      \pichere{taxonomy.eps,height=2in}
      \item Service classes
      \begin{sitem}
         \item guaranteed
         \item predictive
         \item controlled-delay
      \end{sitem}
   \end{sitem}
\end{slide}
% -----------------------------------------------------------------
\begin{slide}{}  

   \subsection{Mechanisms}

   \begin{sitem}
      \item Flowspecs
      \begin{sitem}
         \item {\it Rspec}: describes service requested from network
         \begin{sitem}
            \item controlled-delay: level of delay required
            \item guaranteed/predictive: delay target
         \end{sitem}
         \bigskip
         \item {\it Tspec}: describes flow's traffic characteristics
         \begin{sitem}
            \item average bandwidth + burstiness: {\em token bucket} filter
            \item token rate $r$
            \item bucket depth $B$
            \item must have a token to send a byte
            \item must have $n$ tokens to send $n$ bytes
            \item start with no tokens
            \item accumulate tokens at rate of $r$ per second
            \item can accumulate no more than $B$ tokens
         \end{sitem}
      \end{sitem}
   \end{sitem}
\end{slide}
% -----------------------------------------------------------------
\begin{slide}{}  

   \begin{sitem}
      \item Admission Control
      \begin{sitem}
         \item decide if a new flow can be supported
         \item answer depends on service class
         \item not the same as {\it policing}
      \end{sitem}
      \item Reservation Protocol
      \begin{sitem}
         \item called signalling in ATM
         \item proposed Internet standard: RSVP
         \item consistent with robustness of today's connectionless model
         \item uses soft state (refresh periodically)
         \item designed to support multicast
         \item is receiver oriented
         \item two messages: PATH and RESV
         \item source transmits PATH messages sent every 30 seconds
         \item destination responds with RESV message
         \item merge requirements in case of multicast
         \item can specify number of speakers
      \end{sitem}
   \end{sitem}
\end{slide}
% -----------------------------------------------------------------
\begin{slide}{}  

   \pichere{pathmsg.eps,height=4in}

\end{slide}
% -----------------------------------------------------------------
\begin{slide}{}  

   \begin{sitem} 
      \item Packet Classifying and Scheduling
      \begin{sitem}
         \item associate each packet with the appropriate reservation so 
               that it can be handled correctly, a process known as 
               {\em classifying} packets
         \item manage the packets in the queues so that they receive the
               service that has been requested, a process known as packet 
               {\it scheduling}
      \end{sitem}

      \item RSVP versus ATM (Q.2931)
      \begin{sitem}
         \item RSVP
         \begin{sitem}
            \item receiver generates reservation 
            \item soft state (refresh/timeout)
            \item separate from route establishment
            \item QoS can change dynamically
            \item receiver heterogeneity 
         \end{sitem}
         \item ATM
         \begin{sitem}
            \item sender generates connection request
            \item hard state (explicit delete)
            \item concurrent with route establishment
            \item QoS is  static for life of connection
            \item uniform QoS to all receivers
         \end{sitem}
      \end{sitem}
   \end{sitem}
\end{slide}





