Fwd: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt
Here's our initial attempt at a "circuit breakers" draft for RTCWeb. Comments welcome - this is very much a straw-man for discussion, rather than a final solution. Colin Begin forwarded message:
From: internet-drafts@ietf.org Subject: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt Date: 5 March 2012 20:17:59 GMT To: i-d-announce@ietf.org Reply-To: internet-drafts@ietf.org
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : RTP Congestion Control: Circuit Breakers for Unicast Sessions Author(s) : Colin Perkins Varun Singh Filename : draft-perkins-avtcore-rtp-circuit-breakers-00.txt Pages : 14 Date : 2012-03-05
The Real-time Transport Protocol (RTP) is widely used for telephony, video conferencing, and telepresence applications. These applications are often used over best-effort UDP/IP networks. If congestion control is not implemented then network congestion will deteriorate the user's multimedia experience. This document does not propose a congestion control algorithm. Instead, it specifies a minimal set of "circuit-breakers". Circuit-breakers are conditions under which an RTP flow should cease to transmit media to protect the network from excessive congestion. It is expected that all RTP applications running on best-effort networks will be able to run without triggering these circuit breakers in normal operation.
A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-breake...
-- Colin Perkins http://csperkins.org/
On 03/06/2012 12:32 AM, Colin Perkins wrote:
Here's our initial attempt at a "circuit breakers" draft for RTCWeb. Comments welcome - this is very much a straw-man for discussion, rather than a final solution.
Colin
Begin forwarded message:
From: internet-drafts@ietf.org Subject: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt Date: 5 March 2012 20:17:59 GMT To: i-d-announce@ietf.org Reply-To: internet-drafts@ietf.org
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : RTP Congestion Control: Circuit Breakers for Unicast Sessions Author(s) : Colin Perkins Varun Singh Filename : draft-perkins-avtcore-rtp-circuit-breakers-00.txt Pages : 14 Date : 2012-03-05
The Real-time Transport Protocol (RTP) is widely used for telephony, video conferencing, and telepresence applications. These applications are often used over best-effort UDP/IP networks. If congestion control is not implemented then network congestion will deteriorate the user's multimedia experience. This document does not propose a congestion control algorithm. Instead, it specifies a minimal set of "circuit-breakers". Circuit-breakers are conditions under which an RTP flow should cease to transmit media to protect the network from excessive congestion. It is expected that all RTP applications running on best-effort networks will be able to run without triggering these circuit breakers in normal operation.
A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-breake... Thanks for this work!
A few questions (to make sure I get them noted down): Section 4.1: Accordingly, if a sender of RTP data packets receives two or more consecutive RTCP RR packets from the same receiver that correspond to its transmission and have a non-increasing extended highest sequence number received field, then that sender SHOULD cease transmission. If I see RTCP packets with 1: highest sequence number = 2 2: highest sequence number = 2 3: highest sequence number = 2 do I cease transmission after packet 3 has arrived, or after packet 2 has arrived? I *think* the logical time is after packet 3 has arrived, but I'm a little unsure that the words are unambiguously saying that; it's not 100% clear to me whether packet 1 is considered included in the set of "non-increasing highest sequence number". Section 4.2: Is it reasonable to replace, for the purposes of this calculation, "an order of magnitude" with "a factor of ten"? (for those who don't have a physics background, putting text somewhere that says that an order of magnitude is "somewhere around a factor of ten" might be appropriate.) We might also want to add the words about doing a dramatically reduced rate if we can from section 4.1 here, factor it out as a general statement, or say that it is not appropriate here if it's not. Security considerations (missing section): For an end node that implements this specification, an active attacker can cut the transmission by faking two RTCP packets that get accepted instead of the recipient's RTCP packets. This may be worthy of a note, and pointer to appropriate defenses. Good stuff! Harald
Hi Harald, comments inline On Tue, Mar 6, 2012 at 09:52, Harald Alvestrand <harald@alvestrand.no> wrote: [snip!]
A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-breake...
Thanks for this work!
A few questions (to make sure I get them noted down):
Section 4.1:
Accordingly, if a sender of RTP data packets receives two or more consecutive RTCP RR packets from the same receiver that correspond to its transmission and have a non-increasing extended highest sequence number received field, then that sender SHOULD cease transmission.
If I see RTCP packets with
1: highest sequence number = 2 2: highest sequence number = 2 3: highest sequence number = 2
do I cease transmission after packet 3 has arrived, or after packet 2 has arrived?
After 3. The idea is for the sender to wait for two RTCP intervals (which corresponds to two additional reports). for the reported HSN to increase. Example: SR | | | X -----------------------------------------------------------------------------------------------------------> time RR | N N N The N are RTCP RRs that carry the same HSN value. X means terminate session. We could clarify this in the next iteration.
I *think* the logical time is after packet 3 has arrived, but I'm a little unsure that the words are unambiguously saying that; it's not 100% clear to me whether packet 1 is considered included in the set of "non-increasing highest sequence number".
Section 4.2: Is it reasonable to replace, for the purposes of this calculation, "an order of magnitude" with "a factor of ten"? (for those who don't have a physics background, putting text somewhere that says that an order of magnitude is "somewhere around a factor of ten" might be appropriate.)
We might also want to add the words about doing a dramatically reduced rate if we can from section 4.1 here, factor it out as a general statement, or say that it is not appropriate here if it's not.
Security considerations (missing section): For an end node that implements this specification, an active attacker can cut the transmission by faking two RTCP packets that get accepted instead of the recipient's RTCP packets. This may be worthy of a note, and pointer to appropriate defenses.
This is a valid attack. However, if we consider no early-feedback (the draft currently only follows RFC3550 timing rules) then the attacker's second fake report may be ignored by the sender because it is too early. Meanwhile, the actual receiver may get to deliver its RTCP RR. Example: SR | | | I -----------------------------------------------------------------------------------------------------------> time RR | F | F | F F | | are valid SR and RR, F are Fake RTCPs (replaying the last valid RTCP report). So, instead of waiting for 3 RTCP reports to arrive the sender MUST wait two RTCP intervals? Cheers, Varun -- http://www.netlab.tkk.fi/~varun/
On 03/06/2012 10:21 AM, Varun Singh wrote:
Hi Harald,
comments inline
On Tue, Mar 6, 2012 at 09:52, Harald Alvestrand<harald@alvestrand.no> wrote:
[snip!] Thanks for the quick response!
[snip]
Security considerations (missing section): For an end node that implements this specification, an active attacker can cut the transmission by faking two RTCP packets that get accepted instead of the recipient's RTCP packets. This may be worthy of a note, and pointer to appropriate defenses. This is a valid attack. However, if we consider no early-feedback (the draft currently only follows RFC3550 timing rules) then the attacker's second fake report may be ignored by the sender because it is too early. Meanwhile, the actual receiver may get to deliver its RTCP RR.
Example: SR | | | I -----------------------------------------------------------------------------------------------------------> time RR | F | F | F F |
| are valid SR and RR, F are Fake RTCPs (replaying the last valid RTCP report). So, instead of waiting for 3 RTCP reports to arrive the sender MUST wait two RTCP intervals? Yes, I think stating that the sender waits two RTCP intervals before drawing a conclusion is a reasonable defense against this version of the attack.
Another interesting version is what happens if the attacker bumps up the "highest sequence number received" - the security considerations may want to say that RRs with a "highest sequence number received" larger than the highest sequence number sent MAY be part of an attack, so SHOULD be disregarded. But of course, using SRTP on the RTCP channel is also an option for the defender; that allows the receiver to detect that the replays are replays, and discard them for that reason.
Hi Harald, Comment inline. On Tue, Mar 6, 2012 at 11:51, Harald Alvestrand <harald@alvestrand.no> wrote:
On 03/06/2012 10:21 AM, Varun Singh wrote:
Security considerations (missing section): For an end node that implements this specification, an active attacker can cut the transmission by faking two RTCP packets that get accepted instead of the recipient's RTCP packets. This may be worthy of a note, and pointer to appropriate defenses.
This is a valid attack. However, if we consider no early-feedback (the draft currently only follows RFC3550 timing rules) then the attacker's second fake report may be ignored by the sender because it is too early. Meanwhile, the actual receiver may get to deliver its RTCP RR.
Example: SR | | | I
-----------------------------------------------------------------------------------------------------------> time RR | F | F | F F |
| are valid SR and RR, F are Fake RTCPs (replaying the last valid RTCP report). So, instead of waiting for 3 RTCP reports to arrive the sender MUST wait two RTCP intervals?
Yes, I think stating that the sender waits two RTCP intervals before drawing a conclusion is a reasonable defense against this version of the attack.
Another interesting version is what happens if the attacker bumps up the "highest sequence number received" - the security considerations may want to say that RRs with a "highest sequence number received" larger than the highest sequence number sent MAY be part of an attack, so SHOULD be disregarded.
I am not sure if an endpoint reporting a HSN_received larger than the HSN_sent trips any circuit breaker, but if the endpoint doesn't ignore the report then the endpoint may reset its timeout counter. A plan for action for the Security considerations can be to list the values in the fake RTCP report that can trip a circuit breakers and then see how the endpoint can detect or protect against that kind of attack.
But of course, using SRTP on the RTCP channel is also an option for the defender; that allows the receiver to detect that the replays are replays, and discard them for that reason.
Yes. -- http://www.netlab.tkk.fi/~varun/
On 03/06/2012 02:26 PM, Varun Singh wrote:
Hi Harald,
Comment inline.
On Tue, Mar 6, 2012 at 11:51, Harald Alvestrand<harald@alvestrand.no> wrote:
On 03/06/2012 10:21 AM, Varun Singh wrote:
Security considerations (missing section): For an end node that implements this specification, an active attacker can cut the transmission by faking two RTCP packets that get accepted instead of the recipient's RTCP packets. This may be worthy of a note, and pointer to appropriate defenses. This is a valid attack. However, if we consider no early-feedback (the draft currently only follows RFC3550 timing rules) then the attacker's second fake report may be ignored by the sender because it is too early. Meanwhile, the actual receiver may get to deliver its RTCP RR.
Example: SR | | | I
-----------------------------------------------------------------------------------------------------------> time RR | F | F | F F |
| are valid SR and RR, F are Fake RTCPs (replaying the last valid RTCP report). So, instead of waiting for 3 RTCP reports to arrive the sender MUST wait two RTCP intervals? Yes, I think stating that the sender waits two RTCP intervals before drawing a conclusion is a reasonable defense against this version of the attack.
Another interesting version is what happens if the attacker bumps up the "highest sequence number received" - the security considerations may want to say that RRs with a "highest sequence number received" larger than the highest sequence number sent MAY be part of an attack, so SHOULD be disregarded. I am not sure if an endpoint reporting a HSN_received larger than the HSN_sent trips any circuit breaker, but if the endpoint doesn't ignore the report then the endpoint may reset its timeout counter. What could happen is this:
Victim receiver:RTCP, HSN(low) Attacker: RTCP, HSN(high) Victim sender: OK, HSN is (high) Victim receiver:RTCP, HSN(low+some) Victim sender: Oops, HSN did not increase Victim receiver:RTCP, HSN(low+some+some) Victim sener: Oops, HSN did not increase for two RTCP intervals. Shut down. One-packet denial of service. If HSN is always verified against last-sent, and the report is discarded as erroneous if it is higher than last-sent, this attack cannot occur.
A plan for action for the Security considerations can be to list the values in the fake RTCP report that can trip a circuit breakers and then see how the endpoint can detect or protect against that kind of attack.
But of course, using SRTP on the RTCP channel is also an option for the defender; that allows the receiver to detect that the replays are replays, and discard them for that reason. Yes.
On 7 Mar 2012, at 09:22, Harald Alvestrand wrote:
On 03/06/2012 02:26 PM, Varun Singh wrote:
Hi Harald,
Comment inline.
On Tue, Mar 6, 2012 at 11:51, Harald Alvestrand<harald@alvestrand.no> wrote:
On 03/06/2012 10:21 AM, Varun Singh wrote:
Security considerations (missing section): For an end node that implements this specification, an active attacker can cut the transmission by faking two RTCP packets that get accepted instead of the recipient's RTCP packets. This may be worthy of a note, and pointer to appropriate defenses. This is a valid attack. However, if we consider no early-feedback (the draft currently only follows RFC3550 timing rules) then the attacker's second fake report may be ignored by the sender because it is too early. Meanwhile, the actual receiver may get to deliver its RTCP RR.
Example: SR | | | I
-----------------------------------------------------------------------------------------------------------> time RR | F | F | F F |
| are valid SR and RR, F are Fake RTCPs (replaying the last valid RTCP report). So, instead of waiting for 3 RTCP reports to arrive the sender MUST wait two RTCP intervals? Yes, I think stating that the sender waits two RTCP intervals before drawing a conclusion is a reasonable defense against this version of the attack.
Another interesting version is what happens if the attacker bumps up the "highest sequence number received" - the security considerations may want to say that RRs with a "highest sequence number received" larger than the highest sequence number sent MAY be part of an attack, so SHOULD be disregarded. I am not sure if an endpoint reporting a HSN_received larger than the HSN_sent trips any circuit breaker, but if the endpoint doesn't ignore the report then the endpoint may reset its timeout counter. What could happen is this:
Victim receiver:RTCP, HSN(low) Attacker: RTCP, HSN(high) Victim sender: OK, HSN is (high) Victim receiver:RTCP, HSN(low+some) Victim sender: Oops, HSN did not increase Victim receiver:RTCP, HSN(low+some+some) Victim sener: Oops, HSN did not increase for two RTCP intervals. Shut down.
One-packet denial of service.
If HSN is always verified against last-sent, and the report is discarded as erroneous if it is higher than last-sent, this attack cannot occur.
Sure - the Extended Highest Sequence Number received needs to be compared with the sequence numbers being sent. This is also why you can get away with only using two RTCP packets to determine if there's persistent loss: you don't just check that the highest sequence numbers in the packets are non-increasing in isolation, you check that they don't increase to match the sequence number you send. Maybe the draft need clarifying on this. -- Colin Perkins http://csperkins.org/
On 03/07/2012 10:43 AM, Colin Perkins wrote:
On 7 Mar 2012, at 09:22, Harald Alvestrand wrote:
On 03/06/2012 02:26 PM, Varun Singh wrote:
Hi Harald,
Comment inline.
On Tue, Mar 6, 2012 at 11:51, Harald Alvestrand<harald@alvestrand.no> wrote:
On 03/06/2012 10:21 AM, Varun Singh wrote:
Security considerations (missing section): For an end node that implements this specification, an active attacker can cut the transmission by faking two RTCP packets that get accepted instead of the recipient's RTCP packets. This may be worthy of a note, and pointer to appropriate defenses. This is a valid attack. However, if we consider no early-feedback (the draft currently only follows RFC3550 timing rules) then the attacker's second fake report may be ignored by the sender because it is too early. Meanwhile, the actual receiver may get to deliver its RTCP RR.
Example: SR | | | I
-----------------------------------------------------------------------------------------------------------> time RR | F | F | F F |
| are valid SR and RR, F are Fake RTCPs (replaying the last valid RTCP report). So, instead of waiting for 3 RTCP reports to arrive the sender MUST wait two RTCP intervals? Yes, I think stating that the sender waits two RTCP intervals before drawing a conclusion is a reasonable defense against this version of the attack.
Another interesting version is what happens if the attacker bumps up the "highest sequence number received" - the security considerations may want to say that RRs with a "highest sequence number received" larger than the highest sequence number sent MAY be part of an attack, so SHOULD be disregarded. I am not sure if an endpoint reporting a HSN_received larger than the HSN_sent trips any circuit breaker, but if the endpoint doesn't ignore the report then the endpoint may reset its timeout counter. What could happen is this:
Victim receiver:RTCP, HSN(low) Attacker: RTCP, HSN(high) Victim sender: OK, HSN is (high) Victim receiver:RTCP, HSN(low+some) Victim sender: Oops, HSN did not increase Victim receiver:RTCP, HSN(low+some+some) Victim sener: Oops, HSN did not increase for two RTCP intervals. Shut down.
One-packet denial of service.
If HSN is always verified against last-sent, and the report is discarded as erroneous if it is higher than last-sent, this attack cannot occur.
Sure - the Extended Highest Sequence Number received needs to be compared with the sequence numbers being sent. This is also why you can get away with only using two RTCP packets to determine if there's persistent loss: you don't just check that the highest sequence numbers in the packets are non-increasing in isolation, you check that they don't increase to match the sequence number you send.
Maybe the draft need clarifying on this. Or just make it explicit that this is obvious sense, but not made explicit elsewhere. It's kind of a clarification to RFC 3550 section A.2 - the checks there seem to have been written at a time when you did not consider the possibility that someone was out to get you...
On 3/6/2012 2:52 AM, Harald Alvestrand wrote:
On 03/06/2012 12:32 AM, Colin Perkins wrote:
Here's our initial attempt at a "circuit breakers" draft for RTCWeb. Comments welcome - this is very much a straw-man for discussion, rather than a final solution.
Colin
Great - people have been doing this forever, but totally ad-hoc (and for different reasons). In the past I've seen (and used) values in the 10-30 second timeframe used to drop calls with lack of connectivity, though for VoIP 30 seconds is *forever*; few people will wait that long before abandoning a phone call (more might wait that long before abandoning an online 'call', at least today). Most uses I've seen relied on the recipient to end the call, not the sender to do so via RTCP, since most failures in mid-call are loss of connectivity in both directions.
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : RTP Congestion Control: Circuit Breakers for Unicast Sessions Author(s) : Colin Perkins Varun Singh Filename : draft-perkins-avtcore-rtp-circuit-breakers-00.txt Pages : 14 Date : 2012-03-05
A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-breake...
Section 4.1:
Accordingly, if a sender of RTP data packets receives two or more consecutive RTCP RR packets from the same receiver that correspond to its transmission and have a non-increasing extended highest sequence number received field, then that sender SHOULD cease transmission.
If I see RTCP packets with
1: highest sequence number = 2 2: highest sequence number = 2 3: highest sequence number = 2
do I cease transmission after packet 3 has arrived, or after packet 2 has arrived?
As was later clarified, the answer was after packet 3. It would be good to point to the RFC 3550 definition of "reporting interval"; perhaps even discuss how it's calculated, and re-emphasize that it's not 3 RTCP packets in the AVPF case. -- Randell Jesup randell-ietf@jesup.org
Hi Randell, Comment inline. On Tue, Mar 6, 2012 at 15:24, Randell Jesup <randell-ietf@jesup.org> wrote:
On 3/6/2012 2:52 AM, Harald Alvestrand wrote:
On 03/06/2012 12:32 AM, Colin Perkins wrote:
Here's our initial attempt at a "circuit breakers" draft for RTCWeb. Comments welcome - this is very much a straw-man for discussion, rather than a final solution.
Colin
Great - people have been doing this forever, but totally ad-hoc (and for different reasons).
In the past I've seen (and used) values in the 10-30 second timeframe used to drop calls with lack of connectivity, though for VoIP 30 seconds is *forever*; few people will wait that long before abandoning a phone call (more might wait that long before abandoning an online 'call', at least today). Most uses I've seen relied on the recipient to end the call, not the sender to do so via RTCP, since most failures in mid-call are loss of connectivity in both directions.
Section 8. "Session Timeouts" is at the moment a stand alone section and has not been integrated into the Timeout Circuit breaker (Sectio 4.2) and broadly suggests 3 options (which are similar to what you pointed out) 1. some one will disconnect the call. 2. longer than 15 seconds because ICE suggests timeout > 15 sec. 3. wait 2 RTCP intervals after sending an SR for an RTCP RR to arrive. Cheers, Varun [snipped] -- http://www.netlab.tkk.fi/~varun/
On 6 Mar 2012, at 13:24, Randell Jesup wrote:
On 3/6/2012 2:52 AM, Harald Alvestrand wrote:
On 03/06/2012 12:32 AM, Colin Perkins wrote:
Here's our initial attempt at a "circuit breakers" draft for RTCWeb. Comments welcome - this is very much a straw-man for discussion, rather than a final solution.
Colin
Great - people have been doing this forever, but totally ad-hoc (and for different reasons).
In the past I've seen (and used) values in the 10-30 second timeframe used to drop calls with lack of connectivity, though for VoIP 30 seconds is *forever*; few people will wait that long before abandoning a phone call (more might wait that long before abandoning an online 'call', at least today). Most uses I've seen relied on the recipient to end the call, not the sender to do so via RTCP, since most failures in mid-call are loss of connectivity in both directions.
A receiver-based circuit-breaker should be added too, I agree. Colin
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : RTP Congestion Control: Circuit Breakers for Unicast Sessions Author(s) : Colin Perkins Varun Singh Filename : draft-perkins-avtcore-rtp-circuit-breakers-00.txt Pages : 14 Date : 2012-03-05
A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-breake...
Section 4.1:
Accordingly, if a sender of RTP data packets receives two or more consecutive RTCP RR packets from the same receiver that correspond to its transmission and have a non-increasing extended highest sequence number received field, then that sender SHOULD cease transmission.
If I see RTCP packets with
1: highest sequence number = 2 2: highest sequence number = 2 3: highest sequence number = 2
do I cease transmission after packet 3 has arrived, or after packet 2 has arrived?
As was later clarified, the answer was after packet 3.
It would be good to point to the RFC 3550 definition of "reporting interval"; perhaps even discuss how it's calculated, and re-emphasize that it's not 3 RTCP packets in the AVPF case.
-- Randell Jesup randell-ietf@jesup.org _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
-- Colin Perkins http://csperkins.org/
Branching the subject line.... On 03/06/2012 11:24 PM, Colin Perkins wrote:
On 6 Mar 2012, at 13:24, Randell Jesup wrote:
On 3/6/2012 2:52 AM, Harald Alvestrand wrote:
On 03/06/2012 12:32 AM, Colin Perkins wrote:
Here's our initial attempt at a "circuit breakers" draft for RTCWeb. Comments welcome - this is very much a straw-man for discussion, rather than a final solution.
Colin Great - people have been doing this forever, but totally ad-hoc (and for different reasons).
In the past I've seen (and used) values in the 10-30 second timeframe used to drop calls with lack of connectivity, though for VoIP 30 seconds is *forever*; few people will wait that long before abandoning a phone call (more might wait that long before abandoning an online 'call', at least today). Most uses I've seen relied on the recipient to end the call, not the sender to do so via RTCP, since most failures in mid-call are loss of connectivity in both directions. A receiver-based circuit-breaker should be added too, I agree. This may be more application dependent, since a receiver that can't get packets through to the sender is not going to be able to stop the flow.
It can take various measures to get the message through to the sender that bad things are happening (RTCP, signalling), but these may be dependent on *something* working.
On 3/7/2012 5:30 AM, Harald Alvestrand wrote:
Branching the subject line....
On 03/06/2012 11:24 PM, Colin Perkins wrote:
On 6 Mar 2012, at 13:24, Randell Jesup wrote:
In the past I've seen (and used) values in the 10-30 second timeframe used to drop calls with lack of connectivity, though for VoIP 30 seconds is *forever*; few people will wait that long before abandoning a phone call (more might wait that long before abandoning an online 'call', at least today). Most uses I've seen relied on the recipient to end the call, not the sender to do so via RTCP, since most failures in mid-call are loss of connectivity in both directions. A receiver-based circuit-breaker should be added too, I agree. This may be more application dependent, since a receiver that can't get packets through to the sender is not going to be able to stop the flow.
Often it can end the call via signaling however even if p2p connectivity is lost. Also, this assumes that the loss is not something that ICE is able to renegotiate around (IP change, router reset, etc) - if the loss isn't total, ICE *should* be able to re-establish communication, even if only via a TURN server. It does imply that on apparent connectivity loss we should restart ICE (IP change we should notice, but router reset we might not). Also, ICE probes probably shouldn't wait until things are at a critical stage (3rd RTCP interval with no reception). a) total connectivity loss Sender and receiver must time out on lack of media and/or RTCP b) one-way loss sender->receiver Sender can use circuit breaker Receiver must time out on lack of media and/or RTCP c) one-way loss receiver->sender Mirror of b When one side decides to give up, it must attempt to signal this to the other side both via RTCP BYE's and by ending the call via signaling if possible.
It can take various measures to get the message through to the sender that bad things are happening (RTCP, signalling), but these may be dependent on *something* working.
Right. Though restarting ICE may make something work (but typically signaling will remain up, though if the loss is near-total in the internet->receiver direction, the receiver may have trouble completing a "end the call" transaction to the server, even if their packets are getting out. The receiver must end the call and stop sending regardless of ability to tell the sender to stop sending. -- Randell Jesup randell-ietf@jesup.org
On 6 Mar 2012, at 07:52, Harald Alvestrand wrote:
On 03/06/2012 12:32 AM, Colin Perkins wrote:
Here's our initial attempt at a "circuit breakers" draft for RTCWeb. Comments welcome - this is very much a straw-man for discussion, rather than a final solution.
Colin
Begin forwarded message:
From: internet-drafts@ietf.org Subject: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt Date: 5 March 2012 20:17:59 GMT To: i-d-announce@ietf.org Reply-To: internet-drafts@ietf.org
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : RTP Congestion Control: Circuit Breakers for Unicast Sessions Author(s) : Colin Perkins Varun Singh Filename : draft-perkins-avtcore-rtp-circuit-breakers-00.txt Pages : 14 Date : 2012-03-05
The Real-time Transport Protocol (RTP) is widely used for telephony, video conferencing, and telepresence applications. These applications are often used over best-effort UDP/IP networks. If congestion control is not implemented then network congestion will deteriorate the user's multimedia experience. This document does not propose a congestion control algorithm. Instead, it specifies a minimal set of "circuit-breakers". Circuit-breakers are conditions under which an RTP flow should cease to transmit media to protect the network from excessive congestion. It is expected that all RTP applications running on best-effort networks will be able to run without triggering these circuit breakers in normal operation.
A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-breake...
Thanks for this work!
A few questions (to make sure I get them noted down):
Section 4.1:
Accordingly, if a sender of RTP data packets receives two or more consecutive RTCP RR packets from the same receiver that correspond to its transmission and have a non-increasing extended highest sequence number received field, then that sender SHOULD cease transmission.
If I see RTCP packets with
1: highest sequence number = 2 2: highest sequence number = 2 3: highest sequence number = 2
do I cease transmission after packet 3 has arrived, or after packet 2 has arrived? I *think* the logical time is after packet 3 has arrived, but I'm a little unsure that the words are unambiguously saying that; it's not 100% clear to me whether packet 1 is considered included in the set of "non-increasing highest sequence number".
We should clarify. My feeling is that either way would work, depending on how aggressive we want the circuit breaker to be.
Section 4.2: Is it reasonable to replace, for the purposes of this calculation, "an order of magnitude" with "a factor of ten"? (for those who don't have a physics background, putting text somewhere that says that an order of magnitude is "somewhere around a factor of ten" might be appropriate.)
Sure, will clarify.
We might also want to add the words about doing a dramatically reduced rate if we can from section 4.1 here, factor it out as a general statement, or say that it is not appropriate here if it's not.
Yes.
Security considerations (missing section): For an end node that implements this specification, an active attacker can cut the transmission by faking two RTCP packets that get accepted instead of the recipient's RTCP packets. This may be worthy of a note, and pointer to appropriate defenses.
Agreed.
Good stuff!
Harald
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
-- Colin Perkins http://csperkins.org/
Colin I'm curious about this RTP extension for the cases in which DiffServ is actually used, but there's more load than capacity to serve the DS node(s)? What happens then? Also, in the fairly rare case that reservations are used, many times RTCP feedback will be used to invoke or cause a source to reduce resolution or to otherwise change audio codecs, which can be planned for *without* the need for this circuit breaker mode of just cease transmitting. Would you be relying on the application at each end to know the difference as to whether that endpoint is within a BE network, a DS network that's congested or a network that uses (say) reservations, but still experiences problems? James At 01:52 AM 3/6/2012, Harald Alvestrand wrote:
On 03/06/2012 12:32 AM, Colin Perkins wrote:
Here's our initial attempt at a "circuit breakers" draft for RTCWeb. Comments welcome - this is very much a straw-man for discussion, rather than a final solution.
Colin
Begin forwarded message:
From: <mailto:internet-drafts@ietf.org>internet-drafts@ietf.org Subject: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt Date: 5 March 2012 20:17:59 GMT To: <mailto:i-d-announce@ietf.org>i-d-announce@ietf.org Reply-To: <mailto:internet-drafts@ietf.org>internet-drafts@ietf.org
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : RTP Congestion Control: Circuit Breakers for Unicast Sessions Author(s) : Colin Perkins Varun Singh Filename : draft-perkins-avtcore-rtp-circuit-breakers-00.txt Pages : 14 Date : 2012-03-05
The Real-time Transport Protocol (RTP) is widely used for telephony, video conferencing, and telepresence applications. These applications are often used over best-effort UDP/IP networks. If congestion control is not implemented then network congestion will deteriorate the user's multimedia experience. This document does not propose a congestion control algorithm. Instead, it specifies a minimal set of "circuit-breakers". Circuit-breakers are conditions under which an RTP flow should cease to transmit media to protect the network from excessive congestion. It is expected that all RTP applications running on best-effort networks will be able to run without triggering these circuit breakers in normal operation.
A URL for this Internet-Draft is: <http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-breakers-00.txt>http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-breakers-00.txt
Thanks for this work!
A few questions (to make sure I get them noted down):
Section 4.1:
Accordingly, if a sender of RTP data packets receives two or more consecutive RTCP RR packets from the same receiver that correspond to its transmission and have a non-increasing extended highest sequence number received field, then that sender SHOULD cease transmission.
If I see RTCP packets with
1: highest sequence number = 2 2: highest sequence number = 2 3: highest sequence number = 2
do I cease transmission after packet 3 has arrived, or after packet 2 has arrived? I *think* the logical time is after packet 3 has arrived, but I'm a little unsure that the words are unambiguously saying that; it's not 100% clear to me whether packet 1 is considered included in the set of "non-increasing highest sequence number".
Section 4.2: Is it reasonable to replace, for the purposes of this calculation, "an order of magnitude" with "a factor of ten"? (for those who don't have a physics background, putting text somewhere that says that an order of magnitude is "somewhere around a factor of ten" might be appropriate.)
We might also want to add the words about doing a dramatically reduced rate if we can from section 4.1 here, factor it out as a general statement, or say that it is not appropriate here if it's not.
Security considerations (missing section): For an end node that implements this specification, an active attacker can cut the transmission by faking two RTCP packets that get accepted instead of the recipient's RTCP packets. This may be worthy of a note, and pointer to appropriate defenses. Good stuff!
Harald
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
Colin, Varun, Can you clarify how the circuit breaker mechanism would work with RFC 4585 extended feedback. To make things concrete, I'm thinking about the following scenario: - Sender is sending 2Mb/s video into a 4Mb/s DSL line. RTT is 100ms. - Receiver is allowed to send up to 2.5% of this as RTCP feedback in ACK mode, so that's 6.5 packets per RTT if I got the maths right. - A TCP flow slowstarts, doubles the window for the last time and collides with the RTP flow in the wonderful way slowstart sometimes does. If you're unlucky, you'll get 33% packet loss for one full RTT before TCP backs off. - The RTCP receiver sends 6 successive RTCP reports over one RTT indicating 33% loss. If doesn't really matter if ACKs or NACKs are sent in this scenario. The calculated TCP rate would be ~18Kb/s for those parameters, so the circuit breaker would kick in if I understood the draft correctly because that's more than two reporting intervals with excessively high loss. This is the main reason for loss event rate in the TFRC specification - you avoid responding to such transients too strongly. Cheers, Mark On 5 March 2012 23:32, Colin Perkins <csp@csperkins.org> wrote:
Here's our initial attempt at a "circuit breakers" draft for RTCWeb. Comments welcome - this is very much a straw-man for discussion, rather than a final solution.
Colin
Begin forwarded message:
From: internet-drafts@ietf.org Subject: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt Date: 5 March 2012 20:17:59 GMT To: i-d-announce@ietf.org Reply-To: internet-drafts@ietf.org
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : RTP Congestion Control: Circuit Breakers for Unicast Sessions Author(s) : Colin Perkins Varun Singh Filename : draft-perkins-avtcore-rtp-circuit-breakers-00.txt Pages : 14 Date : 2012-03-05
The Real-time Transport Protocol (RTP) is widely used for telephony, video conferencing, and telepresence applications. These applications are often used over best-effort UDP/IP networks. If congestion control is not implemented then network congestion will deteriorate the user's multimedia experience. This document does not propose a congestion control algorithm. Instead, it specifies a minimal set of "circuit-breakers". Circuit-breakers are conditions under which an RTP flow should cease to transmit media to protect the network from excessive congestion. It is expected that all RTP applications running on best-effort networks will be able to run without triggering these circuit breakers in normal operation.
A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-breake...
-- Colin Perkins http://csperkins.org/
_______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt
participants (6)
-
Colin Perkins -
Harald Alvestrand -
James M. Polk -
Mark Handley -
Randell Jesup -
Varun Singh