Subject: Considering LIPE proposal in AVT working group

From: Stephen Casner <[email-masked]>
Date: Fri, 4 Aug 2000 15:36:06 -0700 (Pacific Daylight Time)

To the AVT working group, and the Transport Area Directors:

At this IETF meeting we had a presentation on "A LightWeight IP
Encapsulation (LIPE) Scheme" <draft-chuah-avt-lipe-00.txt> by Mooi
Chuah.  This draft proposes to multiplex multiple streams of low bit
rate audio (or multimedia) packets into a single UDP/IP session or IP
session.  This would be used, for example, over the T1/E1 links in
wireless access networks between base stations and mobile switching
centers.

We have discussed multiplexing in AVT over several past meetings, and
we have selected a scheme that combines RTP header compression + PPP
multiplexing + compressed L2TP.  The LIPE draft contends that this
scheme is too complex and that the services provided by RTP are not
needed for this application.  See the draft for details.

Therefore, this proposal does not fit within the scope of the current
AVT charter which is to advance RTP to draft standard and to complete
a set of payload formats using RTP.  We could decide to expand our
charter to include development of additional protocols for audio/video
transport as alternatives to RTP.  It would also be possible to
charter a new working group to develop a new protocol with a different
set of requirements.

I am sending this message to the working group and to the Area
Directors to seek comment on whether either of these actions would be
justified for this proposal and which would be more appropriate.

Note that this draft essentially proposes the development of a new
transport protocol.  As I said during the recent AVT meeting, getting
an IP protocol number, as would be needed for a new transport protocol
running over IP, is intentionally somewhat difficult.  There is a
threshold for standardizing a new transport protocol because having
multiple choices for similar operations impairs interoperability,
increases network maintenance and management complexity, etc.
That is, a new proposal should provide a significant improvment in
functionality, efficiency or some other dimension to justify its
standardization.

In the LIPE draft there is a comparison of the efficiencies of several
schemes, and a graph was shown during the presentation (which should
be posted soon along with slides from the other presentations).  Does
this draft meet the threshold of significant improvement?

							-- Steve

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Sun, 6 Aug 2000 09:22:20 +0200

> The LIPE draft contends that this

As another data point in this area, see draft-hiller-rohc-gehco-00.txt which
argues that an RTP header compression scheme that preserves timestamps
(possibly not bit-for-bit exact), but not necessarily sequence numbers, is
"good enough".
(For the present discussion about a/v transport protocols, it is probably
not relevant that it also does not preserve UDP checksums and IP IDs.  Also,
I'm not interested in arguments about how it is bad when the network does
something to your packets behind your back -- you may want to assume
"consensual applications", here.)

I would like to see some discussion starting on how important the RTP
services are for "real-world applications".
Timestamp and sequence number, CSRC list, RTCP reports, SDES info etc.
While the members of this list may not be interested in the specific details
of header compression schemes (if you are, please see
www.dmn.tzi.org/ietf/rohc), they may very well be interested that specific
RTP features make it through the network intact, even if bandwidth
efficiency is of utmost importance.  Please speak up...

Gruesse, Carsten

---

From: Michael Thomas <[email-masked]>
Date: Sun, 6 Aug 2000 10:42:41 -0700 (PDT)

> (possibly not bit-for-bit exact), but not necessarily sequence numbers, is

   One consideration to be aware of is that there has
   been work to be able to use stream ciphers for RTP
   payload encryption. Stream ciphers need accuracy of
   the timestamp at the very least, and quite probably
   the sequence number in the general case (the initial
   work was only done for fixed length voice codecs and
   is not generalizable to variable rate video codecs
   in its present form).

   RTP compression and payload encryption go hand in
   glove, so a great deal of care needs to be taken
   to successfully marry the two .

		   Mike