[R-C] New Version Notification for draft-alvestrand-rmcat-remb-00.txt

[Harald Alvestrand]

On 01/18/2012 11:37 PM, Colin Perkins wrote:
> Harald,
>
> A couple of suggestions:
>
> - This uses RTCP Payload-specific feedback messages, with the 
> Application Layer feedback (AFB) FMT parameter and a 4 octet unique 
> identifier (REMB) inside the feedback section. The AFB message was 
> intended to be private for a particular application, and not something 
> that should be standard. This would be better registered as a new FMT 
> value within the payload-specific feedback messages. Doing so would 
> also save 4 octets, since you wouldn't need to unique identifier field.
Agreed; we published this for experimentation, in order to get some 
experience with it without breaking any standards; its usage is 
"private" in the sense of being limited to the people participating in 
the experiment.

I think the draft said so, but I may not have been clear enough; will 
try to improve.
Once we have rough consensus that this approach makes sense, I think we 
should give the "real" format as a new FMT value, and document this 
format in an appendix as "for experimentation in advance of FMT 
assignment". Let's hope we can get it done soon.

Advice sought for IANA considerations:

Offhand, I can't find the registry for FMT values; RFC 4585 section 6.3 
seems to specify 5 values (out of 32 possible codes), with RFC 5104 
section 4.3 assigning 4 more. It's a small field, so I really don't want 
to waste codepoints.

Section 9 of RFC 4585 says that the rule for new entries is 
"specification required" according to RFC 2434, which is "an RFC or 
other permanent and readily available reference", which would preclude I-D.

There's also (to my mind) an open question on whether this should be a 
Payload Specific message (206) or a Transport Layer Feedback Message 
(205). Any reason not to go with a Transport Layer feedback message?

>
> - You have an SSRC feedback field but don't use the SSRC of media 
> source. Would it make sense to use the SSRC of media source to hold 
> the first entry of the SSRC feedback field, and put the others in the 
> payload? Again, saves 4 octets, and avoids a wasted field.
If there's no equipment that tries to "generically" parse these 
messages, we can certainly do so! Since RFC 5104 section 4.2.2.2 seemed 
to not take the opportunity to skip this field, we thought we'd follow 
precedent until we felt safe.

>
> Colin
>
>
> On 17 Jan 2012, at 12:55, Harald Alvestrand wrote:
>> This is the broken-out version of the REMB message that was published 
>> in an appendix of the congestion-control draft I posted just before 
>> Taipei.
>>
>> After discussions inside Google, we decided that the timestamp header 
>> extension didn't offer enough value over the RFC 5450 send-time 
>> offset header extension, so we dropped it from the draft.
>>
>>                   Harald
>>
>> -------- Original Message --------
>> Subject: 	New Version Notification for 
>> draft-alvestrand-rmcat-remb-00.txt
>> Date: 	Tue, 17 Jan 2012 04:54:00 -0800
>> From: 	internet-drafts at ietf.org
>> To: 	harald at alvestrand.no
>> CC: 	harald at alvestrand.no
>>
>>
>>
>> A new version of I-D, draft-alvestrand-rmcat-remb-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository.
>>
>> Filename:	 draft-alvestrand-rmcat-remb
>> Revision:	 00
>> Title:		 RTCP message for Receiver Estimated Maximum Bitrate
>> Creation date:	 2012-01-17
>> WG ID:		 Individual Submission
>> Number of pages: 7
>>
>> Abstract:
>>     This document proposes an RTCP message for use in experimentally-
>>     deployed congestion control algorithms for RTP-based media flows.
>>
>>
>>
>>
>>
>> The IETF Secretariat
>>
>> _______________________________________________
>> Rtp-congestion mailing list
>> Rtp-congestion at alvestrand.no <mailto:Rtp-congestion at alvestrand.no>
>> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>
>
>
> -- 
> Colin Perkins
> http://csperkins.org/
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120119/5f34ac46/attachment.html>