Subject: Accommodating link-level compression in BW calculations

From: Stephen Casner <[email-masked]>
Date: Thu, 2 Jul 1998 19:05:59 -0700 (Pacific Daylight Time)

I have a question which I originally considered an RSVP issue, but Bob
Braden rightly suggests it may be more of an int-serv issue.

When making a reservation for a stream that will use RTP, links that
implement IP/UDP/RTP header compression would like to know that RTP
will be used so they can reduce the bandwidth allocation required for
that link according to the compression gain.  This is analogous to the
adjustment that admission control for each link must make to account
for the link header size, only in this case it is a subtraction from
the specified bandwidth rather than an addition.  (That is, the
flowspec should specify the bandwidth required without considering
header compression since some links may compress and others may not;
then the adjustment would be applied only at links that do the
compression.)

What I envision is some way to specify in the flowspec or some other
object carried by RSVP (or other setup protocol) that the stream is
RTP compressible.  Is there a reasonable place for that information to
go?  Perhaps it would be just one bit, or perhaps a parameter would be
needed to say what the expected compression ratio would be (for
example, it's likely to be greater for audio with constant-duration
packets than for video).

If this information is not available, it would be possible, after the
data starts flowing, for the compressor to notify the admission
control that the stream has been observed to use RTP so that the total
allocated bandwidth could be adjusted to compensate.  But that won't
allow the reservation to succeed on a link that can only handle the
stream if the headers are compressed.

Has this notion been discussed anywhere?
							-- Steve

---

From: Carsten Bormann <[email-masked]>
Date: 03 Jul 1998 11:57:46 +0200

Stephen Casner <[email-masked]> writes:

> [...]

Actually, it may be an ISSLL issue.

``Providing integrated services over low-bitrate links'',
(draft-ietf-issll-isslow-03.txt), March 1998, 
Section 2, "Design Considerations":

#    An important component of the integrated services architecture is the
#    provision of reservations for real-time flows.  One of the problems
#    that systems on low-bitrate links (routers or hosts) face when
#    performing admission control for such reservations is that they must
#    translate the bandwidth requested in the reservation to the one
#    actually consumed on the link.  Methods such as data compression
#    and/or header compression can reduce the requirements on the link,
#    but admission control can only make use of the reduced requirements
#    in its calculations if it has enough information about the data
#    stream to know how effective the compression will be.  One goal of
#    the architecture therefore is to provide the integrated services
#    admission control with this information.  A beneficial side effect
#    may be to allow the systems to perform better compression than would
#    be possible without this information.  This may make it worthwhile to
#    provide this information even when it is not intended to make a
#    reservation for a real-time flow.

> Has this notion been discussed anywhere?

We have discussed quite a few alternatives on how to actually do this
in the ISSLOW subgroup of ISSLL.  Although I'm not exactly happy with
this approach, it seems the best way to do this would be to have the
application indicate in the Tspec (or some other data logically
associated with the Tspec) what compression gains it expects to see
for what compression scheme (IP header compression and CRTP are not
the only schemes ever conceivable).  Obviously, all of this would only
become relevant for controlled-load service -- it is hard to guarantee
header compression gains.

> example, it's likely to be greater for audio with constant-duration

I believe that INTSERV should decide what kind of object should carry
this information.  The various ISSLL people should think about how it
affects their service mappings, and whether a common set of
information (e.g., the simple one I just described above) can be
defined.  In ISSLOW, we would have to talk about it in the service
mapping document, currently draft-ietf-issll-isslow-svcmap-01.txt.

Gruesse, Carsten