Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-01.txt
The appendix carries the new extensions for signalling that we have discussed. Hope you like them! Harald -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-rtcweb-congestion-01.txt Date: Sat, 29 Oct 2011 14:28:10 -0700 From: internet-drafts@ietf.org To: harald@alvestrand.no CC: harald@alvestrand.no, holmer@google.com A new version of I-D, draft-alvestrand-rtcweb-congestion-01.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-rtcweb-congestion Revision: 01 Title: A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web Creation date: 2011-10-29 WG ID: Individual Submission Number of pages: 19 Abstract: This document describes two methods of congestion control when using real-time communications on the World Wide Web (RTCWEB); one sender- based and one receiver-based. It is published to aid the discussion on mandatory-to-implement flow control for RTCWEB applications; initial discussion is expected in the RTCWEB WG's mailing list. The IETF Secretariat
In Appendix A, minor error in the diagram for the extension. The second 0xBE should be 0xDE. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xBE | 0xBE | length=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | len=2 | send timestamp (t_i) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For the REMB message, what do we expect the "SSRC of packet sender" header field to be set to? Is it just an arbitrary choice of any of the SSRCs used by the sender of the REMB? On Sat, Oct 29, 2011 at 5:29 PM, Harald Alvestrand <harald@alvestrand.no>wrote:
** The appendix carries the new extensions for signalling that we have discussed. Hope you like them!
Harald
-------- Original Message -------- Subject: New Version Notification for draft-alvestrand-rtcweb-congestion-01.txt Date: Sat, 29 Oct 2011 14:28:10 -0700 From: internet-drafts@ietf.org To: harald@alvestrand.no CC: harald@alvestrand.no, holmer@google.com
A new version of I-D, draft-alvestrand-rtcweb-congestion-01.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository.
Filename: draft-alvestrand-rtcweb-congestion Revision: 01 Title: A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web Creation date: 2011-10-29 WG ID: Individual Submission Number of pages: 19
Abstract: This document describes two methods of congestion control when using real-time communications on the World Wide Web (RTCWEB); one sender- based and one receiver-based.
It is published to aid the discussion on mandatory-to-implement flow control for RTCWEB applications; initial discussion is expected in the RTCWEB WG's mailing list.
The IETF Secretariat
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
On 10/30/2011 02:38 PM, Justin Uberti wrote:
In Appendix A, minor error in the diagram for the extension. The second 0xBE should be 0xDE. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xBE | 0xBE | length=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | len=2 | send timestamp (t_i) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For the REMB message, what do we expect the "SSRC of packet sender" header field to be set to? Is it just an arbitrary choice of any of the SSRCs used by the sender of the REMB? Apparently one of Magnus' new drafts goes into that territory. I suspect Colin Perkins will have opinions too.
I think that for efficiency and general sanity, these need to be sent from one of the SSRCs and not from all of the SSRCs. I don't see any reason not to pick one at random.
On Sat, Oct 29, 2011 at 5:29 PM, Harald Alvestrand <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
The appendix carries the new extensions for signalling that we have discussed. Hope you like them!
Harald
-------- Original Message -------- Subject: New Version Notification for draft-alvestrand-rtcweb-congestion-01.txt Date: Sat, 29 Oct 2011 14:28:10 -0700 From: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> To: harald@alvestrand.no <mailto:harald@alvestrand.no> CC: harald@alvestrand.no <mailto:harald@alvestrand.no>, holmer@google.com <mailto:holmer@google.com>
A new version of I-D, draft-alvestrand-rtcweb-congestion-01.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository.
Filename: draft-alvestrand-rtcweb-congestion Revision: 01 Title: A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web Creation date: 2011-10-29 WG ID: Individual Submission Number of pages: 19
Abstract: This document describes two methods of congestion control when using real-time communications on the World Wide Web (RTCWEB); one sender- based and one receiver-based.
It is published to aid the discussion on mandatory-to-implement flow control for RTCWEB applications; initial discussion is expected in the RTCWEB WG's mailing list.
The IETF Secretariat
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no <mailto:Rtp-congestion@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
[catching up] On 31 Oct 2011, at 08:50, Harald Alvestrand wrote:
On 10/30/2011 02:38 PM, Justin Uberti wrote:
In Appendix A, minor error in the diagram for the extension. The second 0xBE should be 0xDE. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xBE | 0xBE | length=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | len=2 | send timestamp (t_i) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For the REMB message, what do we expect the "SSRC of packet sender" header field to be set to? Is it just an arbitrary choice of any of the SSRCs used by the sender of the REMB?
Apparently one of Magnus' new drafts goes into that territory. I suspect Colin Perkins will have opinions too.
I think that for efficiency and general sanity, these need to be sent from one of the SSRCs and not from all of the SSRCs. I don't see any reason not to pick one at random.
I can imagine there are scenarios where you'd want to congestion control each stream individually, and have a receiver partition up its available bandwidth estimate between them. In that case, you'd send per-SSRC. If you want to control a group of streams, then signalling a single SSRC, and making assumptions about which other SSRCs it applies to, doesn't make sense to me. It would be clearer, and more future proof, to define an identifier for the group of streams, signal that in SDP, and report that identifier in the feedback messages. That is, be explicit, rather than implicitly trying to group things based on assumptions about which set of SSRCs should be controlled together. -- Colin Perkins http://csperkins.org/
On 11/16/2011 09:36 AM, Colin Perkins wrote:
[catching up]
On 31 Oct 2011, at 08:50, Harald Alvestrand wrote:
On 10/30/2011 02:38 PM, Justin Uberti wrote:
In Appendix A, minor error in the diagram for the extension. The second 0xBE should be 0xDE. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xBE | 0xBE | length=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | len=2 | send timestamp (t_i) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For the REMB message, what do we expect the "SSRC of packet sender" header field to be set to? Is it just an arbitrary choice of any of the SSRCs used by the sender of the REMB? Apparently one of Magnus' new drafts goes into that territory. I suspect Colin Perkins will have opinions too.
I think that for efficiency and general sanity, these need to be sent from one of the SSRCs and not from all of the SSRCs. I don't see any reason not to pick one at random.
I can imagine there are scenarios where you'd want to congestion control each stream individually, and have a receiver partition up its available bandwidth estimate between them. In that case, you'd send per-SSRC.
If you want to control a group of streams, then signalling a single SSRC, and making assumptions about which other SSRCs it applies to, doesn't make sense to me. It would be clearer, and more future proof, to define an identifier for the group of streams, signal that in SDP, and report that identifier in the feedback messages.
That is, be explicit, rather than implicitly trying to group things based on assumptions about which set of SSRCs should be controlled together. As described, the feedback option explicitly lists the SSRCs it applies to:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| FMT=15 | PT=206 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of media source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unique identifier 'R' 'E' 'M' 'B' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num SSRC | BR Exp | BR Mantissa | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC feedback | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | The discussion has only focused on the "SSSRC of packet sender" field. The timestamp option diagrammed at the beginning of this thread will, of course, only apply to the packet it occurs in.
participants (3)
-
Colin Perkins -
Harald Alvestrand -
Justin Uberti