Subject: [conex] draft-conex-mechanism-00 comments

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 29 Jun 2010 12:11:31 +0200

-- I think the document is a good first step, but i am a bit hesitant 
with making a single document covering the mechanism and the use cases 
(since our charter explicitly ask us to first wrap up the use cases). I 
do understnad that some basic understnading of the conex concepts are 
needed in order to understand the use cases. Besides, i do believe that 
the current document falls a bit short doing a good job fully describing 
the mechnisms. I would expect that the mechanism document woul enter in 
more details about the plicer, the shaper and other pieces that would 
complete the whole picture. So, my suggestion would be to:
keep the content as it is with a short description of the conex concepts 
(but not grow on the description of the mechinism in this document). 
Start another doucment where the mechanism can be fully descrived and 
refer to that document for further details. Rename the document as CONEX 
concepts and use cases. Change the style to avoid proposing the 
mechanism here, but rather talking about the conex mechanism in a 
descriptive manner. Focus on the use cases.

-- The CONEX WG charter has focused the work on the use case "where the 
end hosts and the network that contains the destination end host are 
CONEX-enabled but other networks need not be." I think the document does 
cover this use case, but it has not explicitly mentioned that. I think 
it would be important to note that in the begining of the doucment. 
Morevoer, i think it is imporntat to explicitly distonguish the cases 
where it applies. In particular in section 7.1 it would be important to 
explain a bit more how is this case considered. Maybe some pcitures 
would help.

The text that under the bullet 7. Conex Use Cases seems to be more 
descriptive of the overall framework rather than the use cases. I would 
suggest to move it to section 6 (maybe as a subsection)

More specific comments

Section 7 reads:

    Distinguishing conex traffic from non-conex traffic:  On one level
       this seems pretty easy -- conex traffic needs to have the
       downstream congestion field in every packet.  However in practise
       it may not be as simple as this.

MB> I don't follow the logic here. Distinguishing the conex traffic from 
the non conex traffi is easy then. The problem is that it is not obvious 
what to do with the non-conex traffic correct? If so, please rephrase 
this to make it clearer.

then it follows:

       implementation of conex.  Here the two congestion fields are
       unary-encoded into a stream of packets by effectively setting or
       clearing a single bit.  Assuming you are able to identify non-
       conex (or legacy) traffic, then you need to decide what to do
       about it.  An ISP may reasonably choose to do nothing different
       with this traffic.  Alternatively they might incentivise the conex
       traffic in order to give it marginally better service.

MB> but later on in this section you state that non-conex traffic is to 
be dropped when the congestion allowance is depleted and the non-conex 
traffic is to be treated as today, so i would suggest to simply remove 
the above paragraph, since it is simply repeating in a mor obscure way 
what is being stated later on.

MB> Later on in section 7.1 congestion volume is defined. I suggest the 
definition is moved to section 2 where definitions are.

MB> Conex is capitalized conex and ConEx, please use a single 
capitalization

MB> section 7.3 talks about "conex plicers" that have not been defined 
before. Plese define the term (maybe in section 2?)

MB>  please change the name to draft-moncaster-conex-use-cases