Subject: [re-ECN] Abstract specification of ConEx

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 29 Mar 2010 14:36:27 +0200

Hi

In general I believe that here lies some of the stuff that makes ConEx difficult to comprehend and lack of proper graphichs to explain it does not make it simpler. 

If I understand things correctly the GREEN marks (or pre-credits) are only needed in order to satisfy an "incentive dropper" (is it the correct term?) so that flows are not falsely detected as cheating. The pre-credits are not really needed for the congestion-volume policing or ?.

I guess you have turned this whole thing inside-out several times and therefore understand it better than I do, but anyway I wonder why the pre-credits needed from the first place. 
I understand that without the pre-credits the flow will constantly be in debt as it is up too one RTT short of credit marks. But cannot the "incentive dropper" be made tolerant to this offset. After all cheating will manifest it self as a constantly increasing debt that should be fairly easy to distinguish from the non-cheating case. Or is it fear of "gaming the system" that is the driver behind this ?

Regards
Ingemar

> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 29 Mar 2010 08:06:56 +0100
> From: Bob Briscoe <[email-masked]>
> Subject: Re: [re-ECN] Abstract specification of ConEx
> To: Matt Mathis <[email-masked]>
> Cc: "[email-masked] list" <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
> 
> Matt,
> 
> At 01:39 29/03/2010, Matt Mathis wrote:
> >If it supports
> >ConEx, the sender needs to be able to send three different "credit"
> >markings:
> >BLACK_ECN - in exact agreement with the number of ECN marks 
> seen at the 
> >receiver (but implicitly delayed by one RTT).
> >BLACK_Loss - In exact agreement with the number of losses signaled.
> >For reliable protocols should be in exact agreement with 
> >retransmissions.
> >GREEN - Pre-credits to used to assure that even though the 
> BLACK marks 
> >are delayed by one RTT count(RED)<count(BLACK_ECN)+count(GREEN).
> 
> For an unconstrained abstract encoding, I see this 
> differently (as I tried to describe in my earlier posting on 
> this subject):
> 
> The ECN field already shows whether it supports drop 
> (Not-ECT) or ECN (the other three codepoints). So, if an 
> orthoginal re-feedback field supports the following four codepoints:
> - re-feedback not supported
> - re-feedback unmarked
> - re-feedback marked
> - re-feedback pre-credit
> 
> Then, combined with Not-ECT in the ECN field, these can 
> re-echo losses.
> Or, combined with the other ECN codepoints, they can be used 
> to re-echo ECN.
> 
> 
> >Depending on the deployment scenario and other coding 
> constraints the 
> >sender marking might be three separate ternary values 
> (unsupported, not 
> >marked or marked) or one supported indication plus 3 binary
> >values.    Note that as a practical matter it might be reasonable to
> >assume one 5 valued signal, but this representation can not model 
> >situations where transport might carry both loss and ECN 
> information on 
> >the same ACK.
> >
> >The point of the abstract specification is to permit us to 
> list some of 
> >the algorithms that ConEx might support, such that when it 
> comes time 
> >to choose a particular encoding, it is easy to understand 
> what features 
> >we might forfeit when using it.
> >
> >For example, if a flow is observed to violate 
> >count(RED)<count(BLACK_ECN)+count(GREEN), then it can be 
> identified as
> >cheating.   If I have to encode all of the sender marks into 
> 2 bits (4
> >code points) then would be better not to conflate BLACK_Loss with 
> >either BLACK_ECN or GREEN, because doing so will either weaken or
> >break the cheating test.   It looks as though it might be ok to use a
> >single code point for GREEN and BLACK_ECN marks.
> >
> >My notation is not particularly good.  Perhaps somebody can suggest 
> >something better....
> 
> I tried in my first posting of this thread.
> Did you see it and think it was not useful? Or did you miss it?
> 
> 
> 
> Bob
> 
> 
> >Thanks,
> >--MM--
> >-------------------------------------------
> >Matt Mathis      http://staff.psc.edu/mathis
> >Work:412.268.3319   Home/Cell:412.654.7529
> >-------------------------------------------
> >Evil is defined by mortals who think they know "The Truth" and use 
> >force to apply it to others.
> 
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> re-ECN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/re-ecn
> 
> 
> End of re-ECN Digest, Vol 13, Issue 87
> **************************************
>

---

From: <[email-masked]>
Date: Mon, 29 Mar 2010 17:39:08 +0100

i think you have summarised the issue correctly. but the issue is that a cheater can keep creating new identities for itself. then it always gets within the tolerance of the "incenitve dropper" ie its debt doesnt "constantly increase" becuase it looks like a new user.
 
so if you dont have the green marks (pre-credits) then you have to
- decide that identity splitting isn't a threat you will worry about
- deal with the threat though some other mechanism

best wishes
phil
________________________________

From: [email-masked] on behalf of Ingemar Johansson S
Sent: Mon 29/03/2010 13:36
To: [email-masked]
Cc: [email-masked]
Subject: [re-ECN] Abstract specification of ConEx

Hi

Regards
Ingemar

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 29 Mar 2010 18:54:33 +0100

Ingemar,

At 13:36 29/03/2010, Ingemar Johansson S wrote:
>Hi
>
>In general I believe that here lies some of the stuff that makes 
>ConEx difficult to comprehend and lack of proper graphichs to 
>explain it does not make it simpler.
>
>If I understand things correctly the GREEN marks (or pre-credits) 
>are only needed in order to satisfy an "incentive dropper" (is it 
>the correct term?) so that flows are not falsely detected as 
>cheating. The pre-credits are not really needed for the 
>congestion-volume policing or ?.
>
>I guess you have turned this whole thing inside-out several times 
>and therefore understand it better than I do, but anyway I wonder 
>why the pre-credits needed from the first place.

Two parts to this question:
- is pre-credit needed?
- could pre-credit be the same codepoint as post-credit?

>I understand that without the pre-credits the flow will constantly 
>be in debt as it is up too one RTT short of credit marks. But cannot 
>the "incentive dropper" be made tolerant to this offset. After all 
>cheating will manifest it self as a constantly increasing debt that 
>should be fairly easy to distinguish from the non-cheating case. Or 
>is it fear of "gaming the system" that is the driver behind this ?

You're exactly hitting the nub of the problem: the network layer is 
about stateless packets. Given policing has to work across multiple 
networks, it cannot depend on a network holding some sort of 
reputation per source address (let alone port numbers too).

If the network were to allow for an RTT delay, flows could just 
continue until they experienced congestion then start a new 
whitewashed flow ID rather than balance the debit marks of the 
congestion with credit marks.

So instead, I took the approach of using the source address (and 
optionally port no) purely as a meaningless label that associates a 
set of packets. The network holds the balance between credit and 
debit as state. But it only stores state about a set of packets when 
pre-credit has been sent. Any packets without any matching state in 
the network (because they haven't sent credit), but that claim to 
support ConEx, all get treated as one bulk set of misbehaving packets.

Requiring pre-credit also has the nice property that it shifts the 
risk of hurting others onto transports, making them care about things 
like overshoot at flow start.

This arrangement has the important property that network state 
doesn't tie a flow to a fixed path (fate sharing). If a flow 
re-routes so it no longer goes through the same anti-cheating device, 
after 1RTT black or green packets will just recreate state in the new 
box, and the old one will timeout. IOW, it uses automatic in-band soft-state.

I thought it would be best if state were not guaranteed to be held 
longer than a min idle period (1 sec say), after which it can 
timeout. If the same ID re-appears later it is taken to imply an 
unrelated set of packets (even if it is actually the same flow) and 
must supply renewed pre-credit. This accords with the transport's 
information about the path going stale if it is idle. It also 
protects against memory exhaustion attacks.

HTH

Bob

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 30 Mar 2010 13:40:41 +0200

Thanks Bob and Phil for the explanation. 
Can't say that I get all the details around the pre-credits but if this WG flies I am confident that I will get to understand this piece as well.

/Ingemar

> -----Original Message-----
> From: Bob Briscoe [mailto:[email-masked]] 
> Sent: den 29 mars 2010 19:55
> To: Ingemar Johansson S
> Cc: [email-masked]; [email-masked]
> >In general I believe that here lies some of the stuff that 
> makes ConEx 
> >difficult to comprehend and lack of proper graphichs to 
> explain it does 
> >not make it simpler.
> >
> >If I understand things correctly the GREEN marks (or 
> pre-credits) are 
> >only needed in order to satisfy an "incentive dropper" (is it the 
> >correct term?) so that flows are not falsely detected as 
> cheating. The 
> >pre-credits are not really needed for the congestion-volume 
> policing or 
> >?.
> >
> >I guess you have turned this whole thing inside-out several 
> times and 
> >therefore understand it better than I do, but anyway I 
> wonder why the 
> >pre-credits needed from the first place.
> 
> >I understand that without the pre-credits the flow will 
> constantly be 
> >in debt as it is up too one RTT short of credit marks. But 
> cannot the 
> >"incentive dropper" be made tolerant to this offset. After 
> all cheating 
> >will manifest it self as a constantly increasing debt that should be 
> >fairly easy to distinguish from the non-cheating case. Or is 
> it fear of 
> >"gaming the system" that is the driver behind this ?
> 
> You're exactly hitting the nub of the problem: the network 
> layer is about stateless packets. Given policing has to work 
> across multiple networks, it cannot depend on a network 
> holding some sort of reputation per source address (let alone 
> port numbers too).
> 
> If the network were to allow for an RTT delay, flows could 
> just continue until they experienced congestion then start a 
> new whitewashed flow ID rather than balance the debit marks 
> of the congestion with credit marks.
> 
> So instead, I took the approach of using the source address 
> (and optionally port no) purely as a meaningless label that 
> associates a set of packets. The network holds the balance 
> between credit and debit as state. But it only stores state 
> about a set of packets when pre-credit has been sent. Any 
> packets without any matching state in the network (because 
> they haven't sent credit), but that claim to support ConEx, 
> all get treated as one bulk set of misbehaving packets.
> 
> Requiring pre-credit also has the nice property that it 
> shifts the risk of hurting others onto transports, making 
> them care about things like overshoot at flow start.
> 
> This arrangement has the important property that network 
> state doesn't tie a flow to a fixed path (fate sharing). If a 
> flow re-routes so it no longer goes through the same 
> anti-cheating device, after 1RTT black or green packets will 
> just recreate state in the new box, and the old one will 
> timeout. IOW, it uses automatic in-band soft-state.
> 
> I thought it would be best if state were not guaranteed to be 
> held longer than a min idle period (1 sec say), after which 
> it can timeout. If the same ID re-appears later it is taken 
> to imply an unrelated set of packets (even if it is actually 
> the same flow) and must supply renewed pre-credit. This 
> accords with the transport's information about the path going 
> stale if it is idle. It also protects against memory 
> exhaustion attacks.
> 
> HTH
> 
> 
> 
> Bob
> 
> 
> >Regards
> >Ingemar
> >
> > > 
> differently (as I 
> > > tried to describe in my earlier posting on this subject):
> > >
> orthoginal 
> > > re-feedback field supports the following four codepoints:
> > > Then, combined with Not-ECT in the ECN field, these can re-echo 
> > > losses.
> > > Or, combined with the other ECN codepoints, they can be used to 
> > > re-echo ECN.
> > >
> > >