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

From: Bob Briscoe <[email-masked]>
Date: Thu, 05 Aug 2010 23:41:42 +0100

Magnus, Ingemar, Colin, Piers, Ken,

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.

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.
"
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

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: ken carlberg <[email-masked]>
Date: Wed, 25 Aug 2010 16:39:50 -0400

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:
> Below are my main technical concerns with draft-ietf-avt-ecn-for-rtp-02 as promised.
> 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.
> "
> 1205       may be reduced due to the nature of peer-to-peer use of RTP.  Still a
> 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.

yes, good catch, and agreed.  I think our intent was to talk about receivers in general, as opposed to one cheating receiver in the midst of other conforming receivers.  We can tighten up the text to fix this.

> Let's return to the infrastructure devices argument, which seems more plausible...
> "
> 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.

well, you bring up points related to reactions of ECN, and environments where one can envision its deployment, and to what degree it would be deployed.  All of which are something to be discussed elsewhere. (perhaps different draft, if its to be discussed at all)....

> 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.

...but yes, you bring up good points.

> 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?

if the investment of the $100 led me to the cheater costing me $1,000 or more, then I'd consider it :-), but I digress.

> 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.
> 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:
> ii) an additional option (in a separate I-D) comitting to either the ECN Nonce or ConEx

well, Conex is pretty darn new, and still a bit of a moving target that is accentuated with its output of experimental milestones.  However, I would feel comfortable in punting on ECN Nonce for the time being (ie, taking it out of our draft) in trying to preclude a potential conflict with the ECT(1) codepoint.  I think Colin put this in, so I can be swayed by whatever arguments he adds to the topic.

> The downside is that this will create additional deployment options. But the RTP-ECN draft already implies that implementation of nonce support is optional.

agreed.

> 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.

let's see what the other authors have to say on the topic.  And if they agree with your suggestion, we won't be proud and will gladly accept the help :-)

> 1968                                                      It is far from certain
> 1969          that a receiver would be able to get a significant larger share of
> 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...

> 1971                                                        The risk of cheating
> 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.

...this depends on the form of the response.  From our private conversation, I brought up the point that the "response" make take several forms, one of which would be a default position of some type of back-off algorithm, of which several types could be in place.
But, As I mentioned above, I understand the points you are making and we can tighten up the text a bit -- either by removing some of it, or adding more context.

> 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."
> 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.

a little strong given this exchange, but we hear the points you are making :-)

> 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.

right.

> "
> 1979       Receivers misbehaving:  A receiver may prevent the usage of ECN in an
> 1981                                             Thus forcing the sender to turn
> 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.

right, I think I/we have covered this above.

> In all these cases, ConEx is intended to solve the problem, particularly when ECN is used, whether with RTP or any other transport.

we'll cross our fingers for luck concerning Conex :-)

cheers,

-ken

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 26 Aug 2010 00:36:44 +0100

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...
>

[snip]

> > 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

---

From: ken carlberg <[email-masked]>
Date: Thu, 26 Aug 2010 06:52:41 -0400

Bob,

FYI, Colin, and my other cohorts, are swamped at the moment with some other stuff, so they will eventually get back to this thread, but it will just be  while.  Stay tuned :-)

As for your other comments below...

On Aug 25, 2010, at 7:36 PM, 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...
> 
> [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.

I mostly agree in the common case with no other caveats.  I need put my thoughts in a separate text outside of this draft and get back to you.

> 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.
> 

your points above are fine, but we're thinking in different perspectives.  what went through my mind was that given an aggregate that has rate adaptive traffic types, sustained full utilization of links for significant periods of time should be rare given flows backing off in some measure.  hence, marking would only be applied to some subset of flows instead of all of them going through the congested link.  But this is going quite off topic, and I really do need to put things in a separate draft/document.

cheers,

-ken

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 31 Aug 2010 08:23:28 +0200

Hi Bob (and others)

Slow response, sorry. 

Personally I see little gain with the nonce as it assumes that the sending endpoint acts on the behalf of network. Still there is a chance that nonce may be useful (for instance streaming media servers). Nonce however as a limited use for peer to peer scenarions IMHO and it is probably weaker for RTP than it is for TCP.
Still I would keep nonce as is in the draft as it may be useful, AFAIK it will not be used in 3GPP specifications.

ConEx is one future concern. For this reason the "ect" parm-value is included in the attribute, moreover ECT(0) is RECOMMENDED in nonce is not used, I recall that the reason behind this was re-ECN/ConEx. 
But perhaps a SHOULD or MUST is more appropriate ?. Is there any specific need to use ECT(1) today. The document will likely need a major update for ConEx later on as it likely needs to specify how a (formatted) version of the RTCP-ECN feedback is inserted into the IP header, and one can then specify that ECT(1) is used for ConEx enabled RTP flows.

There is a risk that a ConEx policer can be confused by a nonce enabled RTP sender but ECT(1) is only set ~50% of the packets, I believe that it will only take a couple of packets to make a reliable detection. The probability of for instance 5 consecutive ECT(1) is 3%. There can of course be a problem with very short lived ConEx enabled flows.... 

We should not make deployment of ConEx tougher than necessary but I guess that the nonce must anyway be handled in some smart way anyway as it already specified as experimental for TCP (even though is allegedly unused), do you agree ?

Some more inline

Regards
/Ingemar

> -----Original Message-----
> From: Bob Briscoe [mailto:[email-masked]] 
> Sent: den 6 augusti 2010 00:42
> To: [email-masked]
> Cc: [email-masked]
> Subject: draft-ietf-avt-ecn-for-rtp-02 T3/ Anti-Cheating
> 
> 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.
> "
> 1208                                                         
> In addition, as
> 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.

[IJ] I would say that in access technologies that employ a queue for each user (e.g LTE) it is to a large extent the case that the user that misbehaves that will suffer the most. It is of course not 100% true as there will be some collatteral damage, how large depends pretty much on factors such as scheduling algorithms and active queue amangement policies.

> 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?
> 

:-)

> 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.
> 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:
> But the RTP-ECN draft already implies that implementation of 
> nonce support is optional.
> 
> 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.
> 
> 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
> 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."
> 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.
> 
> "
> 1980                                                         
> [...]  simple
> ECN-nonce values, the sender will consider it has failed the 
> nonce test and be entitled to stop sending to it.
> 
> "