Re: [aqm] Gaming ECN

[KK <[e-mail]>]

I have been reading the discussion related to ECN and the recent draft put
together by Gorry and Michael.
When we wrote RFC 3168, we constructed the protocol in such a way that it
would not provide an incentive for an ECN capable flow to benefit or for a
flow that purports to be an ECN flow would gain by Œgaming¹ the
environment.
There were several people who questioned us at that time with regard to
our conservative choice to treat flows Œsimilarly': mark flows that are
ECN capable and drop flows that are not ECN capable with the same
criterion (probabilistically or whatever other means people might think of
in the future).
We specified that a packet that was ECN capable wouldn¹t be viewed as
receiving any notion of Œpriority¹. Moreover, we stated that when a buffer
is full, packets would be dropped, irrespective of whether it is ECN
capable or not. 

So, let us look at the two adversarial scenarios:
1) A flow that claims to be ECN capable, gets marked by congested
router(s). The end-system (either end) does not honor the protocol and
continues to send packets at a higher rate (not reducing the window or
whatever in accordance with TCP) than a flow that would react properly to
the ECN marks. It would presumably get more packets through on a short
term basis. 
2) A flow that is not ECN capable has packets dropped by congested
router(s). The end-system (either end) does not honor the protocol and
continues to send packets at a higher rate (not reducing the window or
whatever in accordance with TCP) than a flow that would react properly to
the packet drop as an indication of congestion. It would presumably get
more packets through on a short term basis.
 

Would there be any difference in the number of packets that are
successfully delivered to the destination in either of these cases? I
would think that there would not be a significant, consistent difference.
Yes, these non-cooperative flows would be able to deliver more packets
than the ones that cooperate, whether it is through marking or dropping, I
would think.
Ultimately, if the non-cooperative behavior persists, buffers overflow and
it would not make a difference whether the flow (claims to be or is) ECN
capable or not.

We thought we were being careful in  ensuring that we address the
sentiment that David expresses: "when introducing something
new we need to look at ways that it could be abused and what the effects
of someone trying to abuse it would be"

Thanks,  
-- 
K. K. Ramakrishnan
Professor
Dept. of Computer Science and Engineering
University of California, Riverside
Rm. 332, Winston Chung Hall
Tel: [phone]
Web Page: http://www.cs.ucr.edu/~kk/




On 3/21/15, 3:47 PM, "David Lang" <[e-mail]> wrote:

>On Fri, 20 Mar 2015, John Leslie wrote:
>
>>> If you do #2, then flows with ECN effectively get priority over flows
>>> without ECN
>>
>>   It's not "priority". It's an occasional packet which gets through
>> instead of being dropped.
>
>is it? or is it that in order to keep the link from being congeted, flows
>with 
>ECN marked (but not honored) will consistantly get more packets through
>than 
>ones wihtout ECN?
>
>If it' just an occasional packet, it's not a big deal, but if the non-ECN
>flows 
>get slowed more because the ECN-marked flows are getting more packet
>through, 
>that's a priority difference, not just an occasional packet.
>
>I wrote this based on the responses of "how could anyone game ECN" where
>people 
>seemed to be thinking that there is no way to gain an advantage from
>claiming to 
>do ECN but then ignoring the congestion signals.
>
>It may be that nobody ever abuses ECN this way, but when introducing
>something 
>new we need to look at ways that it could be abused and what the effects
>of 
>someone trying to abuse it would be.
>
>David Lang
>
>_______________________________________________
>aqm mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/aqm