RE: [AVT] Vorbis RTP issues list for Vienna

I'd like to add to Brian's comment ... but I fear it might start a
long-winded DCCP/PR-SCTP/UDP-congestion-backoff
discussion.

Here goes ...

Michael Ramalho

At 07:25 AM 7/15/2003 -0400, Rosen, Brian wrote:
> > The keys to the data need to be delivered "at least as
> > reliably" as the
> > data but not necessarily "reliably."  Putting keys in the
> > data packet is
> > one such method, but we are not likely to use this method in
> > RTP (poor
> > separation of functions, no third-party key mgt, etc).  But
> > there have been
> > proposals for using RTCP or SRTCP.  Rather than extend RTCP
> > or SRTCP for
> > this purpose, however, a better approach IMHO is to put the
> > key in the SDP
> > and send it "at least as reliably" as the SRTP.  The SDP must
> > of course be
> > authenticated/integrity-checked and encrypted.
>I'm not sure this is a good idea.  At least in SIP, the
>media path is considerably different, and in most cases,
>considerably shorter than the signalling path, because
>the signalling path has intermediaries that the media
>path does not.  Key change is not something I would
>want to see delayed by the intermediaries.  It really
>is a "real time" transport problem, although somewhat
>less real time than the actual media.
>Passing keys may be best done in the media path.
>
>Brian

I agree with Brian here - ideally the keys should be passed
reliably in the media path. But what to do?

The transport people know that we have a protocol that
can do this job ... it just not being used yet because it
new and has not gone through IETF last call.

pr-SCTP has the ability to have "reliable" and "unreliable"
streams present on the same "association". That is, you
can run RTP over a "unreliable stream" whilst sending the
keying material over a "reliable stream" to the same
(potentially set of) IP address(es).

Like DCCP, RTP over an "unreliable pr-sctp stream" has
the desired property of having "TCP-friendly" backoff under
congestion. Unlike DCCP - pr-SCTP has a "reliable
option" (and was the first offering of pr-sctp, via it's
SCTP origin).

On the other side of the same coin, DCCP has a notion
of which packets provided to it were dropped (or not
forwarded) ... so a layer above DCCP could be designed
to add "reliability" to a particular packet. However this
layer wouldn't have the advantage of being integrated
in the transport. This potentially adds more delay for
the keys (Brian's primary comment above).

As a side note, more complex codecs have the notion
of "frame/payload" importance (e.g., base frames of
a video codec having more importance than interpolated
frames). I'm waiting for the discussion of the need of
"mixed reliability/importance/persistence" payloads in
AVT payload formats for particular codecs ... and the
inevitable impact on proposed transport protocols. I
think this must be addressed with a high level of
interaction with the transport WG to get it right
(i.e., anywhere near optimal).

Michael Ramalho

Michael A. Ramalho, Ph.D.
Office email: mramalho@cisco.com
Personal email: mar42@cornell.edu
Office: +1.941.708.4650
Cell: +1.941.544.2844

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt