Subject: Session control protocol instantiation discussion within the IETF

From: "Mike Luby" <[email-masked]>
Date: Thu, 2 Aug 2001 16:03:29 -0700

(This is a resend of a recent message, but with a title and with the link
properly displayed (at least in some email programs)).

In the upcoming RMT working group meeting at the IETF there will be a
discussion about whether or not a session control protocol instantiation is:

(1) within the mandate of the RMT working group

(2) valuable assuming that the answer to (1) is "yes"

The following draft is a description of a possible session control protocol.
Note that this draft is not an official submission to the IETF, and its
content will not be reviewed at the IETF meeting.  This draft is available
at:

http://www.digitalfountain.com/getDocument.htm/technology/library/draft-ietf
-rmt-mgl-pi-rccp-00-7-11-2001.txt

This document describes the Rich Content Control Protocol (RCCP), a session
control protocol for client initiated  content delivery.  The content in
question may be a file, a stream or some other form of content.  The RCCP
protocol  itself, however, is independent of the type of the content.  RCCP
offers support for both multicast and unicast  delivery.

Some of the key properties and goals of RCCP are:

(1) Initiation of the session including communication of the session
description to clients.
(2) Session monitoring to facilitate server side accounting.
(3) Session teardown, facilitating server side accounting and collection of
client statistics.
(4) Initiation and high level control of data packet reception.
(5) Prevention of some types of DoS attacks on servers.
(3) The ability to either directly or after configuration allow delivery of
content through firewalls.

This document is in a high state of flux, will be greatly modified in the
near future, and is not an official  document within the IETF.

Michael Luby
Chief Technical Officer
Digital Fountain, Inc.
39141 Civic Center Drive
Suite 300
Fremont, CA  94538

www.digitalfountain.com
[email-masked]
(510) 284-1420 (phone)
(510) 284-1499 (fax)
(510) 284-1400 (main)

---

From: "Eunsook Kim" <[email-masked]>
Date: Fri, 3 Aug 2001 10:09:55 +0900

I believe such discussion is very crucial and valuable for the further progress of RMT WG.

We note that in the real fields including the multicast-based contents delivery and the related markets,
there has been a urgent need from so many contents providers and CDN service providers
to provide the multicast session control or management 
for realizing provisioining of multicast services.

I think this issue must be progressively discussed in the RMT WG, along with original error/congestion controls.

In addition to Luby's draft, here is another informative material for this discussion:
http://www.ietf.org/internet-drafts/draft-koh-tsm-00.txt
(some parts of those have already been discussed in the last RMT meeting)

Best Regards,

Eunsook Kim

[email-masked]
+82-2-860-6124
Protocol Engineering Center
Electronics and Telecommunications Research Institute (ETRI)

  ----- Original Message ----- 
  From: Mike Luby 
  To: Rmt@Lbl. Gov 
  Cc: Michael Luby ; Lorenzo Vicisano ; Roger Kermode 
  Sent: Friday, August 03, 2001 8:03 AM
  Subject: Session control protocol instantiation discussion within the IETF

  (This is a resend of a recent message, but with a title and with the link properly displayed (at least in some email programs)).

  http://www.digitalfountain.com/getDocument.htm/technology/library/draft-ietf-rmt-mgl-pi-rccp-00-7-11-2001.txt

  Michael Luby
  Chief Technical Officer
  Digital Fountain, Inc.
  39141 Civic Center Drive
  Suite 300
  Fremont, CA  94538

  www.digitalfountain.com
  [email-masked]
  (510) 284-1420 (phone)
  (510) 284-1499 (fax)
  (510) 284-1400 (main)

---

From: Ross Finlayson <[email-masked]>
Date: Sun, 05 Aug 2001 00:25:54 -0700

At 04:03 PM 8/2/01, Mike Luby wrote:
><http://www.digitalfountain.com/getDocument.htm/technology/library/draft-ietf-rmt-mgl-pi-rccp-00-7-11-2001.txt>http://www.digitalfountain.com/getDocument.htm/technology/library/draft-ietf-rmt-mgl-pi-rccp-00-7-11-2001.txt
>

Mike & RMT (cc. MMUSIC),

I think such a protocol is needed, but at this point I'm not convinced that 
it should be a completely new protocol.  Instead, we should consider 
whether such a protocol could be built upon the existing RTSP protocol - 
the IETF standard control protocol for multimedia (AVT) sessions.  RTSP 
already addresses many of the issues that you outline for your control 
protocol.  While RTSP currently uses SDP - which is probably not rich 
enough to describe reliable transport sessions - the 'next generation' of 
SDP (nicknamed "SDPng") will be flexible enough to describe such 
sessions.  Presumably there can also be a "RTSPng" which can make use of 
"SDPng", as well as having sufficient flexiblity to describe reliable 
transport sessions.

Using RTSP (or "RTSPng") as the control protocol for reliable transport 
sessions has several benefits over using a completely new protocol:
- Some multimedia sessions might include both streaming media (audio and/or 
video) and reliable data delivery.  It would be beneficial to use the same 
control protocol for all parts of such a session.
- Some future RTP payload formats may include reliable (or semi-reliable) 
delivery for part of its data.  (E.g., a RTP payload format for Vorbis 
audio will likely need to include a reliable delivery mechanism for 
transporting 'codebooks' to receivers.)  Ideally, all of the 
parameters/attributes for such a session should be described in SDP (or SDPng).
- Some client tools may end up being used to receive/display both A/V 
streams, and reliably-delivered files.  It would simplify the 
implementation of such clients if they could use a single control protocol, 
rather than using one for A/V streams, and another for reliable data transport.
- Ditto for servers - if the same server implementation ends up being used 
to serve both A/V streams and RMT data.

         Ross.

---

From: Rob Lanphier <[email-masked]>
Date: Mon, 6 Aug 2001 15:35:52 -0700 (PDT)

Yeah, what Ross said. It seems like we should be able to sit down this
week and figure out how to reformulate this as a proposal to extend RTSP.
This is roughly equivalent to the "Backchannel Multicast" feature we use
in RealServer (as distinguished from "Scalable Multicast" which doesn't
use the RTSP connection, but just serves an SDP file off of the HTTP port)

I'm here at the London meeting....let's try to catch up and sketch out an
RTSP version that meets your needs.

Rob

---

From: "Michael Luby" <[email-masked]>
Date: Wed, 8 Aug 2001 20:37:44 -0700

All,
I unfortunately was only at the IETF for a couple of days, and am back in
the Bay Area now.  I would first like to talk with the transport area
directorate (Scott and Allison) to get some advice on this, and then
probably followup with a conference call with whoever is interested.  Would
a conference call be ok with you Rob, Ross (and whoever else is
interested?).
Mike

-----Original Message-----
From: Rob Lanphier [mailto:[email-masked]]
Sent: Monday, August 06, 2001 3:36 PM
To: Ross Finlayson
Cc: Mike Luby; Rmt@Lbl. Gov; [email-masked]
Subject: Re: Session control protocol instantiation discussion within
the IETF

Rob

On Sun, 5 Aug 2001, Ross Finlayson wrote:

><http://www.digitalfountain.com/getDocument.htm/technology/library/draft-ie
tf-rmt-mgl-pi-rccp-00-7-11-2001.txt>http://www.digitalfountain.com/getDocume
nt.htm/technology/library/draft-ietf-rmt-mgl-pi-rccp-00-7-11-2001.txt

---

From: Allison Mankin <[email-masked]>
Date: Wed, 08 Aug 2001 23:49:17 -0400

Mike,

We ADs would be happy to talk with you about this sometime (but after 
we all recover from IETF).  

Having had one hallway talk with you while you were in London,
I think there is some value to discussing session work (without
prejudging if it would extend an existing charter or start up in
a new situation of some sort).