Subject: Re: [re-ECN] re-ECN Digest, Vol 13, Issue 106

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 31 Mar 2010 11:40:26 +0200

Hi

I believe I agree with Matt. There is a an educational angle to this. I find the red/black/green things somewhat difficult to grasp. For this reason I believe that it is Ok to "waste codepoints" in the abstract specification, it will (I believe) make it easier for others to follow the discussion. Compressing the codepoints for the real protocol spec is the next step IMHO.

/Ingemar

> 
> Message: 1
> Date: Tue, 30 Mar 2010 23:55:05 -0400
> From: Matt Mathis <[email-masked]>
> Subject: Re: [re-ECN] Abstract specification of ConEx
> To: Bob Briscoe <[email-masked]>
> Cc: "[email-masked] list" <[email-masked]>
> Message-ID:
> 	<[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> I don't think your encoding works for hybrid encoding for both loss
> based and ECN based RE-Feedback.   The problem is that if a flow is
> getting both losses and ECN marks (different bottlenecks) you need to
> used different techniques to enforce each.   ECN cheating can be
> detected by counting the red, black and green marks near to the
> receiver, as mentioned before.   Loss cheating requires reconstructing
> the TCP state from the sequence numbers, which is hard a high 
> rate and most robust when you are close to the sender.
> 
> Furthermore these are orthogonal signals in the transport 
> ACKs: a single TCP ACK might carry both SACK blocks 
> indicating losses and ECT marks.  Choosing four code points 
> rather than three independent bits obscures a lot of 
> information and the concurrency in other parts of the system.
> 
> In order to make sure that the abstract model isn't coloring 
> our thinking, we really want to preserve all of this 
> information in the model even though we think it is clear 
> which credit marks we want to
> conflate.    That means the abstract model will not be the same as the
> IPv6 encoding....
> 
> Thanks,
> --MM--
> 
> 
> On Mon, Mar 29, 2010 at 3:06 AM, Bob Briscoe 
> <[email-masked]> wrote:
> > 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 106
> ***************************************
>