Subject: Re: [rtcweb] Fwd: New Version Notification for draft-kaufman-rtp-compatible-data-00.txt

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 1 Jul 2011 14:10:23 +0200

Reading the draft I get the impression that the intention is to 
multiplex (multiple) RTP streams with arbitrary datagrams on the same 
5-tuple. In that light the method lacks IMO:

* There is no multiplexing support for different RTP flows - as 
discussed at the Interim meeting session separation should be maintained

* There is no support for rate/congestion control of the datagrams

* There is no support for multiplexing different datagram flows (the 
need for this can be argued though - could be done by the web app)

Stefan
On 2011-06-30 02:50, Matthew Kaufman wrote:
> I wrote up a method for sending unreliable datagrams to the same port as
> is being used for RTP, RTCP and STUN that does not conflict with this
> usage. It also addresses the security issues involved in allowing
> arbitrary datagrams to be sent.
>
> Matthew Kaufman
>
> Begin forwarded message:
>
>> *From: [email-masked] <mailto:[email-masked]>
>> *Date: *June 29, 2011 5:48:52 PM PDT
>> *To: [email-masked] <mailto:[email-masked]>
>> *Cc: [email-masked] <mailto:[email-masked]>
>> *Subject: **New Version Notification for
>> draft-kaufman-rtp-compatible-data-00.txt*
>>
>> A new version of I-D, draft-kaufman-rtp-compatible-data-00.txt has
>> been successfully submitted by Matthew Kaufman and posted to the IETF
>> repository.
>>
>> Filename:draft-kaufman-rtp-compatible-data
>> Revision:00
>> Title:
>> Creation date:2011-06-30
>> WG ID:Individual Submission
>> Number of pages: 5
>>
>> Abstract:
>> This document describes a method for sending unreliable datagrams
>> that are &quot;compatible&quot; with RTP and RTCP, and STUN usage of a
>> shared
>> UDP address and port.
>>
>>
>>
>>
>> The IETF Secretariat
>

---

From: Randell Jesup <[email-masked]>
Date: Tue, 05 Jul 2011 23:17:34 -0400

On 6/29/2011 8:50 PM, Matthew Kaufman wrote:
> I wrote up a method for sending unreliable datagrams to the same port 
> as is being used for RTP, RTCP and STUN that does not conflict with 
> this usage. It also addresses the security issues involved in allowing 
http://www.ietf.org/id/draft-kaufman-rtp-compatible-data-00.txt

|    One alternative considered was to encapsulate the arbitrary datagrams
|    within RTP as an RTP payload type.  However the semantics associated
|    with RTP are not always appropriate, depending on the type of
|    arbitrary data being transmitted.

This needs to be expanded on.  Why are they not appropriate?  (Not 
disagreeing, but state it please.)

If this data traverses various SBC/midboxes/NATs-with-ALGs/etc, will the 
apparent "invalid" nature cause possible breakage?

| 5.  Security Considerations
|
|    The contents of these messages SHOULD be encrypted.  Reuse of the
|    keying used for an associated RTP session that is using the same IP
|    address and port MAY be an acceptable method of key specification and
|    cryptosystem choice.

I'd say "The User Message Data of these messages"... to avoid confusion 
about encryption of the
all-zeros 4-byte header.

Also: should it say anything about authentication?

Congestion control needs to be discussed, even if it's to say that it's 
the job of a higher or application layer to define.  I do want to as 
part of rtcweb design make congestion handling be unified, whether or 
not we use a single port (though we probably should use 1 port).

-- 
Randell Jesup
[email-masked]

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 11 Jul 2011 09:59:34 -0700

On Jul 1, 2011, at 5:10 AM, Stefan Håkansson LK wrote:

> Reading the draft I get the impression that the intention is to multiplex (multiple) RTP streams with arbitrary datagrams on the same 5-tuple. In that light the method lacks IMO:
> 
> * There is no multiplexing support for different RTP flows - as discussed at the Interim meeting session separation should be maintained

This draft doesn't address that.

> * There is no support for rate/congestion control of the datagrams

Correct. This is a tool for getting datagrams sent and received. Congestion control, reliability, etc. are all a high-layer problem than this.

> * There is no support for multiplexing different datagram flows (the need for this can be argued though - could be done by the web app)
> 

I would argue that this is an application problem, or possibly the responsibility of a layer that goes above this.

Matthew Kaufman

---

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 13 Jul 2011 15:11:02 +0200

>Correct. This is a tool for getting datagrams sent and received. Congestion control, reliability, etc. are all a high-layer problem than this.
Could you elaborate a bit on how that is supposed to work? Would there be another protocol layer on top?
>I would argue that this is an application problem, or possibly the responsibility of a layer that goes above this.
As indicated, I tend to agree to that this should be handled by the application.

Stefan