<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 01/18/2012 11:37 PM, Colin Perkins wrote:
<blockquote
cite="mid:6F1F09D8-B472-4348-BA39-354DCBA77E0A@csperkins.org"
type="cite">Harald,
<div><br>
</div>
<div>A couple of suggestions:</div>
<div><br>
</div>
<div>- 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.</div>
</blockquote>
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.<br>
<br>
I think the draft said so, but I may not have been clear enough;
will try to improve.<br>
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.<br>
<br>
Advice sought for IANA considerations:<br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
<blockquote
cite="mid:6F1F09D8-B472-4348-BA39-354DCBA77E0A@csperkins.org"
type="cite">
<div><br>
</div>
<div>- 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.</div>
</blockquote>
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.<br>
<br>
<blockquote
cite="mid:6F1F09D8-B472-4348-BA39-354DCBA77E0A@csperkins.org"
type="cite">
<div><br>
</div>
<div>Colin</div>
<div>
<div><br>
</div>
</div>
<div><br>
<div>
<div>On 17 Jan 2012, at 12:55, Harald Alvestrand wrote:</div>
<blockquote type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<div bgcolor="#ffffff" text="#000000"> 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.<br>
<br>
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.<br>
<br>
Harald<br>
<br>
-------- Original Message --------
<table class="moz-email-headers-table" border="0"
cellpadding="0" cellspacing="0">
<tbody>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject:
</th>
<td>New Version Notification for
draft-alvestrand-rmcat-remb-00.txt</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date:
</th>
<td>Tue, 17 Jan 2012 04:54:00 -0800</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">From:
</th>
<td><a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">To:
</th>
<td><a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:harald@alvestrand.no">harald@alvestrand.no</a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">CC:
</th>
<td><a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:harald@alvestrand.no">harald@alvestrand.no</a></td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>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
</pre>
</div>
_______________________________________________<br>
Rtp-congestion mailing list<br>
<a moz-do-not-send="true"
href="mailto:Rtp-congestion@alvestrand.no">Rtp-congestion@alvestrand.no</a><br>
<a class="moz-txt-link-freetext" href="http://www.alvestrand.no/mailman/listinfo/rtp-congestion">http://www.alvestrand.no/mailman/listinfo/rtp-congestion</a><br>
</blockquote>
</div>
<br>
<div apple-content-edited="true">
<span class="Apple-style-span" style="font-size: 9px; "><span
class="Apple-style-span" style="border-collapse: separate;
-webkit-border-horizontal-spacing: 0px;
-webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0);
font-family: 'Lucida Sans Typewriter'; font-size: 9px;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
-webkit-text-decorations-in-effect: none; text-indent:
0px; -webkit-text-size-adjust: auto; text-transform: none;
orphans: 2; white-space: normal; widows: 2; word-spacing:
0px; "><span class="Apple-style-span"
style="border-collapse: separate;
-webkit-border-horizontal-spacing: 0px;
-webkit-border-vertical-spacing: 0px; color: rgb(0, 0,
0); font-family: 'Lucida Sans Typewriter'; font-size:
9px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal; -webkit-text-decorations-in-effect:
none; text-indent: 0px; -webkit-text-size-adjust: auto;
text-transform: none; orphans: 2; white-space: normal;
widows: 2; word-spacing: 0px; "><span
class="Apple-style-span" style="border-collapse:
separate; -webkit-border-horizontal-spacing: 0px;
-webkit-border-vertical-spacing: 0px; color: rgb(0, 0,
0); font-family: 'Lucida Sans Typewriter'; font-size:
9px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal;
line-height: normal;
-webkit-text-decorations-in-effect: none; text-indent:
0px; -webkit-text-size-adjust: auto; text-transform:
none; orphans: 2; white-space: normal; widows: 2;
word-spacing: 0px; ">
<div><br class="Apple-interchange-newline">
<br class="khtml-block-placeholder">
</div>
<div>-- </div>
<div>Colin Perkins</div>
<div><a moz-do-not-send="true"
href="http://csperkins.org/">http://csperkins.org/</a></div>
</span></span></span><br
class="Apple-interchange-newline">
</span><br class="Apple-interchange-newline">
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>