Subject: Re: [AVT] draft-ietf-avt-ecn-for-rtp-02 T3/ Anti-Cheating

From: Colin Perkins <[email-masked]>
Date: Tue, 19 Oct 2010 15:20:36 +0100

The ECN nonce support is pretty modular. I'm happy to rip it out of this draft, since we can always resurrect it in a separate draft if there's a need later.

Colin

On 26 Aug 2010, at 00:36, Bob Briscoe wrote:
> Ken,
> 
> We're violently agreeing I think, modulo just a little more optimism on my part about ConEx ;)
> 
> Colin already said (in a Maastricht corridor discussion) that he would be happy to defer receiver misbehaviour stuff. But I don't think I had put the specific proposal to him I put in my mail - modularising the possibility of two alternative future approaches. I've cut all that text from the thread now so, Colin, feel free to respond to Ken's request for your view in the previous mail instead.
> 
> One response inline, altho I think that part of the conversation is getting pretty obscure...
> 
> At 21:39 25/08/2010, ken carlberg wrote:
>> Bob,
>> 
>> FYI. its been a while since this email was sent, so I'm not snipping any of it, but my responses are few and scattered throughout.  And in this case, my opinions are not that strong, so I can probably be swayed by my co-authors if they feel differently.  That said...
>> 
>> On Aug 5, 2010, at 6:41 PM, Bob Briscoe wrote:
>> > Magnus, Ingemar, Colin, Piers, Ken,
> 
> [snip]
> 
>> > T3c/ Misbehaving end-points
>> > -------------------
>> > "
>> > 1968                                                      It is far from certain
>> > 1969          that a receiver would be able to get a significant larger share of
>> > 1970          the resources.  That assumes a high enough level of aggregation
>> > 1971          that there are flows to acquire shares from.
>> > "
>> > Don't agree. It's completely certain that an unresponsive receiver (or sender) can get a significantly larger share of the resources, whether or not it uses ECN. Just try it. Send an unresponsive flow along with some responsive flows (e.g TCP) and the TCPs reduce their rates while the unresponsive flow gets whatever rate it chooses to send at.
>> > "
>> 
>> well, it depends on context.  if I have an aggregate of flows that are only periodically and in a bursty manner triggering a  congestive state, as opposed to a sustained level of congestion condition (though not collapse), then there are no guarantees that all the other flows will be marked or even suffer packet loss.  And...
> 
> 
> [BB]: Going back to the para at issue in the I-D that I quoted: could I paraphrase it as, "If there are only two flows sharing a bottleneck, a cheating receiver cannot get more than twice as much as it would under equality, which isn't so bad."? If that's what it means, nah! Capacity sharing problems are surely better measured by how little others get, rather than how much more the cheater gets.
> 
> Moving on to your periodic bursts scenario, I'm not quite sure I understand what you are getting at or how it's relevant to the para in the I-D.
> 
> Whatever, surely fair shares aren't an issue during any period when a link isn't fully utilised. Becasue, if a link isn't fully utilised for some period, however brief, it is impossible to take more than your fair share over that period (for any definition of fairness) and it's impossible to cause others to get less than their fair share, because nothing you are doing stops others taking more than they are taking.
> 
> Then,  during those bursts, it's only relevant that there would have marking or loss if someone else had taken a greater share than they were taking at that time. But while there's no marking or loss, it implies no-one else is wanting more than they are taking. So lack of marking or loss indicates there cannot have been any sharing problem.
> 
> Or am I missing your point?
> 
> 
> Bob
> 
> 
> 
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Colin Perkins
http://csperkins.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 Oct 2010 17:36:14 +0200

Hi Bob,

I definitely see some points about what you write. I also think ECN for
RTP has made all effort it can to enable a future redefining of one of
the ECT values. As one of the ADs that was involved in chartering CONEX
I am pretty well aware of it. However, this is experimental work that
needs to prove its benefit and maybe more than anything else have a
deployment story. Based on this we have take a reasonable approach on
dealing with ECT(1).

I am the one that thought we should included the NONCE as a module in
the solution. I kind of agree that in the general case you simply have
to not support it to avoid it. In addition I agree that pushing TCP
flows out of the way is reasonably simple and does provide a benefit for
the app doing it. A lot of todays non-congestion controlled UDP based
real-time applications are based on doing exactly that. As long as you
are running at rates that are almost always supported you simply go grab
the space you need. Well, that work up to a certain limit and a certain
traffic mix. When sufficient many uncontrolled UDP flows share a
bottleneck you end up in heavy congestion. Fortunately most of these
flow are related to an actual human that will terminate that flow if it
is unusable.

I did perceive Nonce as mechanism some infrastructure devices may need.
Especially where there is incentive to lie and the traffic mix is RTP
heavy and have large flows. Take IPTV as an example. In those cases
there is a sender that desires to not over tax the infrastructure
because that brings down the quality of experience for several users.

However, I am fine with moving out the Nonce stuff into a separate
draft. I might come back to particular points later.

Cheers

Magnus

Bob Briscoe skrev 2010-08-06 00:41:
> Below are my main technical concerns with 
> draft-ietf-avt-ecn-for-rtp-02 as promised.
> I have used the line numbering here:
> <http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-avt-ecn-for-rtp-02.txt>
> 
> T1/ Combining pkts
> T2/ ECN-IP-RTCP
> T3/ Anti-Cheating                       <<<---THIS EMAIL
> T4/ Logging Not-ECT fall-back
> T5/ Delivery %age ECT vs Not-ECT
> T6/ Pkt Reordering around session start
> 
> 
> T3a/ Nonce must be non-negotiable for a receiver
> -------------------
> The addition of ECN nonce support to RTP/RTCP adds considerable 
> complexity. In return we get protection against cheating in just one 
> rather contrived scenario - we have to assume the sender wants to 
> altruistically protect the network and other users against a cheating receiver.
> "
> 1204       The assumption about the senders acting on the behalf of the network
> 1205       may be reduced due to the nature of peer-to-peer use of 
> RTP.  Still a
> 1206       significant portion of RTP senders are infrastructure devices (for
> 1207       example, streaming media servers) that do have an interest in
> 1208       protecting both service quality and the network.
> "
> OK, perhaps not so contrived. We'll return to this in a second...
> 
> "
> 1208                                                         In addition, as
> 1209       real-time media is commonly sensitive to increased delay and packet
> 1210       loss, it will be in both media sender and receivers interest to
> 1211       minimise the number and duration of any congestion events as they
> 1212       will affect media quality.
> "
> "
> 1348       behavior.  We note that it appears counter-productive for a receiver
> 1349       to attempt to cheat as it most likely will have negative impact on
> 1350       its media quality.
> "
> Not so. Point to any evidence that cheating makes things worse for 
> yourself. This argument is one of those fallacies that keeps hanging 
> around from the 1990s. If others are responding to congestion, I get 
> higher rate and/or better quality media by not responding to 
> congestion. And on the current Internet most other traffic is 
> responding to congestion (TCP or BitTorrent uTP), so I can take 
> advantage of that.
> 
> Let's return to the infrastructure devices argument, which seems more 
> plausible...
> "
> 619        o  The "nonce" parameter may be used to signal whether the ECN nonce
> 620           is to be used in the session.  This parameter takes two values;
> 621           "nonce=1" for nonce proposed or shall be used, and 
> "nonce=0" for622             no nonce.  If this parameter is not 
> specified, the default is no
> 623           nonce."A receiver that intends to cheat will just claim 
> it does not support the nonce. Therefore, for any sender to have the 
> option to use the nonce, ideally it should have always been mandatory 
> for all receivers to implement nonce support.
> 
> However, many RTP receiver implementations already exist without ECN 
> support, let alone nonce support. Therefore any receiver that wishes 
> to cheat can just hide among the crowd who do not include or 
> recognise an "a=ecn-capable-rtp" attribute at all.
> 
> A sender could punish receivers that do not support the nonce, for 
> instance with a lower rate. But that makes initial deployment hard, 
> as few receivers support it to start with, so you cannot punish 
> nearly everyone who says they don't support ECN just in case they are lying.
> 
> Perhaps instead, a sender could reward receivers that support the 
> nonce. For instance the reward could be a higher rate. But higher 
> than what? Presumably higher than the rate that is 'fair' to everyone 
> else on the network.
> 
> But, let's go back over logic so far. A sender only uses the ECN 
> nonce if it is trying to altruistically protect the interests of 
> others on the network. But in order to create the necessary 
> incentives for receivers to use the nonce, a sender has to first take 
> more rate from others than its 'fair' entitlement, thus negating its 
> intended altruism.
> 
> If a bloke approached you saying, "Lend me $100 so I can reward any 
> thieves who can prove they have not stolen from you," would you give 
> the bloke $100?
> 
> T3b/ Avoid precluding future uses of the experimental ECT(1) codepoint.
> -------------------
> The IETF has just chartered a new working group on Congestion 
> Exposure (ConEx) as a way to more comprehensively handle cheating 
> with respect to congestion: ConEx is a proposed change to IP to give 
> a sender a field in which it can expose expected congestion to the 
> network. Those working on ConEx claim networks can negate any gain a 
> receiver might get from suppressing congestion feedback as well as 
> negating any gain a sender might get from suppressing congestion 
> exposure back to the network. Once truthful congestion is exposed to 
> the network by the sender, the network can encourage and ultimately 
> force senders to respond to congestion.
> 
> The aim is to allow and encourage a whole range of responses to 
> congestion, not to force a particular response (ie. not just TCP). So 
> low bit-rate inelastic sessions will typically be able to be 
> unresponsive to congestion, while high bit-rate inelastic sessions 
> would come under more pressure to be adaptive.
> 
> This 6pp paper describes how ConEx could be used to encourage one 
> site's elastic flows to compensate for its inelastic flows, but 
> ultimately, if high congestion persists, making even the inelastic 
> flows adapt or stop.
>          "Policing Freedom to Use the Internet Resource Pool"
>          <http://www.bobbriscoe.net/projects/refb/#polfree>
> 
> ConEx is currently chartered to produce an experimental protocol, so 
> we cannot yet know whether it will be successful in its goals (I led 
> the research behind ConEx, so I can only say that so far it has been 
> robust to all the attacks the research community has thrown at it).
> 
> The ECN nonce RFC is also experimental. Use of the nonce has been 
> specified in TCP and DCCP, but not implemented as far as anyone knows.
> 
> ConEx might well need to take over the ECT(1) codepoint that is 
> currently assigned to the ECN nonce experiment.
> 
> Therefore, I suggest the RTP-ECN spec suspends judgement between the 
> two approaches. Rather than building use of ECT(1) into RTP-ECN by 
> default, I suggest RTP-ECN is specified in two stages:
> i) without committing to either anti-cheating approach
> ii) an additional option (in a separate I-D) comitting to either the 
> ECN Nonce or ConEx
> 
> The downside is that this will create additional deployment options. 
> But the RTP-ECN draft already implies that implementation of nonce 
> support is optional.
> 
> If an RTP-ECN implementation does not use the ECN nonce for 
> anti-cheating, we need to ensure it will not use the ECT(1) codepoint 
> at all. Otherwise this would unnecessarily preclude using ECT(1) for 
> ConEx, or for some other purpose.
> 
> There is a considerable amount of text woven into the RTP-ECN draft 
> around using ECT(1) and the nonce. If you agree with this suggestion, 
> I can mark up which text needs removing.
> 
> Don't agree. It's completely certain that an unresponsive receiver 
> (or sender) can get a significantly larger share of the resources, 
> whether or not it uses ECN. Just try it. Send an unresponsive flow 
> along with some responsive flows (e.g TCP) and the TCPs reduce their 
> rates while the unresponsive flow gets whatever rate it chooses to send at.
> "
> 1971                                                        The risk 
> of cheating
> 1972          is that failure to react to congestion results in packet loss and
> 1973          increased path delay.
> "
> If a cheating unresponsive flow leaves N times less bandwidth 
> available than it would have done were it responsive, it will force 
> long-running TCP flows to each reduce their bit-rate by N times, 
> making their transfers last N times longer.
> These TCP flows will raise the ECN marking probability by about N^2 
> times (even if the TCP flows are not ECN-capable). So the marking 
> /rate/ will increase by N times. Any competing adaptive real-time 
> flows will reduce their rates in response to the increased 
> loss/marking probability as well.
> 
> If the bottleneck queue is ECN-capable the cheating flow won't care 
> about a higher ECN marking rate, as its own risk of loss will still 
> be extremely low if it is sending ECT packets.
> 
> Considering any short flows competing for the same bottleneck, the 
> amount of congestion they cause by overshooting as each leaves TCP 
> slow start should reduce by about N times. Therefore, by hogging more 
> capacity the unresponsive flow also reduces the risk that it will 
> suffer any losses from other TCPs overshooting slow start.
> If the bottleneck queue is not ECN-capable, delay to the cheating 
> flow should not be significantly increased by its own cheating, 
> whether the queue is drop-tail or AQM."
> 1973                                 To mitigate the risk of cheating receivers
> 1974          the solution include ECN-Nonce that makes it probabilistically
> 1975          unlikely that a receiver can cheat for more than a few packets
> 1976          before being found out.
> "
> See earlier point about the a nonce sender relying on a cheating 
> receiver choosing to volunteer to support the nonce. I really would 
> rather Internet Drafts stopped making unsubstantiated references to 
> the ECN nonce as if it solves the problem of a cheating receiver.
> 
> "
> 1979       Receivers misbehaving:  A receiver may
> 1980                                                         [...]  simple
> 1981          provide invalid ECN-nonce values.
> "
> This is not a workable attack. If a receiver provides invalid 
> ECN-nonce values, the sender will consider it has failed the nonce 
> test and be entitled to stop sending to it.
> 
> "
> 1979       Receivers misbehaving:  A receiver may prevent the usage 
> of ECN in an
> 1980          RTP session by reporting itself as non ECN capable [...]
> 1981                                             Thus forcing the 
> sender to turn
> 1982          off usage of ECN.  In a point-to-point scenario there is little
> 1983          incentive to do this as it will only affect the receiver.  Thus
> 1984          failing to utilise an optimisation.
> "
> Unlikely to be true. ECN provides very little benefit - it is a tiny 
> optimisation compared to the potential benefit to a receiver from not 
> reporting congestion events, which might allow it to receive at the 
> highest codec rate. Having just above normal loss levels might be a 
> little worse than no losses by using ECN. But getting a high codec 
> rate will surely be worth it, while other r-t flows will have to run 
> at the lowest codec, or other TCP flows will have to reduce to 
> whatever bandwidth is left.
> 
> "
> 1965       Receivers cheating
> 1979       Receivers misbehaving:
> 1997       Misbehaving Senders:
> "
> In all these cases, ConEx is intended to solve the problem, 
> particularly when ECN is used, whether with RTP or any other transport.
> 
> Cheers
> 
> Bob
> 
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 21 Oct 2010 09:23:57 +0200

Hi

I am working on the draft, removing the nonce stuff. As I understand it, section 5.3 can be removed entirely, but I guess some text is needed to indicated that RFC3611 (4.1) can be used to indicate packets that are lost or ECN-CE marked. 
ECN-CE is not mentioned in RFC3611, do you believe that it is valid to use RFC3611 for indication on ECN-CE. I guess it is if one stick to the principle that ECN-CE should be reacted on in the same way as a packet loss. What is your opinion.

/Ingemar

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]] 
> Sent: den 19 oktober 2010 16:21
> To: Bob Briscoe
> Cc: ken carlberg; [email-masked]; 
> [email-masked]
> Subject: Re: [AVT] draft-ietf-avt-ecn-for-rtp-02 T3/ Anti-Cheating
> 
> The ECN nonce support is pretty modular. I'm happy to rip it 
> out of this draft, since we can always resurrect it in a 
> separate draft if there's a need later.
> 
> Colin
> 
> 
> > We're violently agreeing I think, modulo just a little more 
> optimism 
> > on my part about ConEx ;)
> > 
> > Colin already said (in a Maastricht corridor discussion) 
> that he would be happy to defer receiver misbehaviour stuff. 
> But I don't think I had put the specific proposal to him I 
> put in my mail - modularising the possibility of two 
> alternative future approaches. I've cut all that text from 
> the thread now so, Colin, feel free to respond to Ken's 
> request for your view in the previous mail instead.
> > 
> > One response inline, altho I think that part of the 
> conversation is getting pretty obscure...
> > 
> >> FYI. its been a while since this email was sent, so I'm 
> not snipping any of it, but my responses are few and 
> scattered throughout.  And in this case, my opinions are not 
> that strong, so I can probably be swayed by my co-authors if 
> they feel differently.  That said...
> >> 
> >> > Don't agree. It's completely certain that an 
> unresponsive receiver (or sender) can get a significantly 
> larger share of the resources, whether or not it uses ECN. 
> Just try it. Send an unresponsive flow along with some 
> responsive flows (e.g TCP) and the TCPs reduce their rates 
> while the unresponsive flow gets whatever rate it chooses to send at.
> >> > "
> >> 
> >> well, it depends on context.  if I have an aggregate of 
> flows that are only periodically and in a bursty manner 
> triggering a  congestive state, as opposed to a sustained 
> level of congestion condition (though not collapse), then 
> there are no guarantees that all the other flows will be 
> marked or even suffer packet loss.  And...
> > 
> > 
> > [BB]: Going back to the para at issue in the I-D that I 
> quoted: could I paraphrase it as, "If there are only two 
> flows sharing a bottleneck, a cheating receiver cannot get 
> more than twice as much as it would under equality, which 
> isn't so bad."? If that's what it means, nah! Capacity 
> sharing problems are surely better measured by how little 
> others get, rather than how much more the cheater gets.
> > 
> > Moving on to your periodic bursts scenario, I'm not quite 
> sure I understand what you are getting at or how it's 
> relevant to the para in the I-D.
> > 
> > Whatever, surely fair shares aren't an issue during any 
> period when a link isn't fully utilised. Becasue, if a link 
> isn't fully utilised for some period, however brief, it is 
> impossible to take more than your fair share over that period 
> (for any definition of fairness) and it's impossible to cause 
> others to get less than their fair share, because nothing you 
> are doing stops others taking more than they are taking.
> > 
> > Then,  during those bursts, it's only relevant that there 
> would have marking or loss if someone else had taken a 
> greater share than they were taking at that time. But while 
> there's no marking or loss, it implies no-one else is wanting 
> more than they are taking. So lack of marking or loss 
> indicates there cannot have been any sharing problem.
> >

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 Oct 2010 09:31:47 +0200

> ECN-CE is not mentioned in RFC3611, do you believe that it is valid to use RFC3611 for indication on ECN-CE. I guess it is if one stick to the principle that ECN-CE should be reacted on in the same…

I at least are of the opinion that if a packet arrived with a CE mark,
it is still delivered. It shall not be marked as lost in the RTCP XR
packet loss vector. If we want/need to know exactly which packets where
CE marked, then we should define a CE marking XR vector for that.
Overloading of this would reduce the utility of the packet loss vector.

Did you have any specific need for explicit CE markings?

Cheers

Magnus Westerlund

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 21 Oct 2010 09:51:14 +0200

Hi 

Sounds like we should define a CE report block similar to 4.1 in RFC3611 then. If both CE and loss occur during a report interval one will of course get both Loss and CE report blocks. A solution is of course a combined Loss/CE report block to reduce some of the overhead (I believe I can live with separate Loss and CE blocks and the extra overhead)

I can imagine that one can consider a more relaxed behavior to CE than Loss although I have not seen much evidence of it sofar a least in wireless access scenarios, one is there likely to see CE shortly before a loss or excessive delay. Wireline may be a different story though..

/Ingemar 

> From: Magnus Westerlund 
> Sent: den 21 oktober 2010 09:32
> To: Ingemar Johansson S
> Cc: Colin Perkins; Bob Briscoe; 
> [email-masked]; [email-masked]
> Subject: Re: [AVT] Removing nonce (WAS RE: 
> draft-ietf-avt-ecn-for-rtp-02 T3/ Anti-Cheating)
> 
> > I am working on the draft, removing the nonce stuff. As I 
> understand it, section 5.3 can be removed entirely, but I 
> guess some text is needed to indicated that RFC3611 (4.1) can 
> be used to indicate packets that are lost or ECN-CE marked. 
> > ECN-CE is not mentioned in RFC3611, do you believe that it 
> is valid to use RFC3611 for indication on ECN-CE. I guess it 
> is if one stick to the principle that ECN-CE should be 
> reacted on in the same way as a packet loss. What is your opinion.
> 
> I at least are of the opinion that if a packet arrived with a 
> CE mark, it is still delivered. It shall not be marked as 
> lost in the RTCP XR packet loss vector. If we want/need to 
> know exactly which packets where CE marked, then we should 
> define a CE marking XR vector for that.

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 21 Oct 2010 11:19:27 +0200

Hi

After some consideration I believe that it is better to skip the RLE XR block altogether. I don't see a clear need now to explicitly see if specific packets are CE marked. But should such a need occur later on, then we can add perhaps add this, this addition is also quite simple.

BTW.. It was not my intention to flood the AVT list with this thread, sorry for the extra noise...

/Ingemar

> From: Ingemar Johansson S [mailto:[email-masked]] 
> Sent: den 21 oktober 2010 09:51
> To: Magnus Westerlund
> Subject: RE: [AVT] Removing nonce (WAS RE: 
> Sounds like we should define a CE report block similar to 4.1 
> in RFC3611 then. If both CE and loss occur during a report 
> interval one will of course get both Loss and CE report 
> blocks. A solution is of course a combined Loss/CE report 
> block to reduce some of the overhead (I believe I can live 
> with separate Loss and CE blocks and the extra overhead)
> 
> I can imagine that one can consider a more relaxed behavior 
> to CE than Loss although I have not seen much evidence of it 
> sofar a least in wireless access scenarios, one is there 
> likely to see CE shortly before a loss or excessive delay. 
> Wireline may be a different story though..
> 
> /Ingemar 
> 
> guess some 
> > text is needed to indicated that RFC3611 (4.1) can be used 
> to indicate 
> > packets that are lost or ECN-CE marked.
> > is valid to use RFC3611 for indication on ECN-CE. I guess 
> it is if one 
> > stick to the principle that ECN-CE should be reacted on in the same 
> > way as a packet loss. What is your opinion.
> > 
> > packet loss vector. If we want/need to know exactly which packets 
> > where CE marked, then we should define a CE marking XR vector for 
> > that.

---

From: Colin Perkins <[email-masked]>
Date: Mon, 25 Oct 2010 12:02:23 +0100

> Overloading of this would reduce the utility of the packet loss vector.

Agreed. The congestion response should be the same for a packet that's lost or CE marked, but the effect on the user experience will be quite different, so they should be reported differently. 

-- 
Colin Perkins
http://csperkins.org/

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 25 Oct 2010 15:51:44 +0100

Folks,

May not get time to respond to all these responses on ECN-for-RTP. 
Too many of my own drafts in process for today's deadlines.

Bob

At 12:02 25/10/2010, Colin Perkins wrote:
> understand it, section 5.3 can be removed entirely, but I guess 
> some text is needed to indicated that RFC3611 (4.1) can be used to 
> indicate packets that are lost or ECN-CE marked.
> >> ECN-CE is not mentioned in RFC3611, do you believe that it is 
> valid to use RFC3611 for indication on ECN-CE. I guess it is if one 
>Agreed. The congestion response should be the same for a packet 
>that's lost or CE marked, but the effect on the user experience will 
>be quite different, so they should be reported differently.
>
>--
>Colin Perkins
>http://csperkins.org/