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