Subject: [conex] draft-kuehlewind-conex-accurate-ecn-00

From: ken carlberg <[email-masked]>
Date: Thu, 7 Jul 2011 08:27:25 -0400

Hi,

I briefly read over the draft and came up with a few initial impressions (in no particular order)...

1) i think the draft would be improved if there were some explicit subsections that shouted out to the reader "strengths" and "weaknesses" of each approach.  Section 3.1.5 gives a brief hint of what the reader should consider, and each of the first three sections has a "discussion".  But in reading the various approaches, I have to dig around and write on a separate paper what characteristics I need to be aware of in comparing one to the other.  I see that you have a table in 3.1.5 representing a high level comparison of the three, but I don't have a clear idea of what you consider complex, accurate, or timely.  In a future version, you may want to consider presenting the options as: 
	x.1 Description
	x.2 Strength
	x.3 Weakness

And then in a following section, you can make a more detailed discussion of the different approaches -- e.g., expanding on the table of 3.1.5.  In my opinion, by stating up front what the authors/editors perceive is the strength and weakness of each, the reader can add further comment to help refine the decision to a single approach.  Afterwards, when one approach is agreed upon, then perhaps you can either remove the perceived strength/weakness or move it to an appendix.  

2) for a lack of a better description, some of the sections seem to be mis-numbered in terms of a hierarchy and collection of sections.  It seems odd that section 3.4 (Advanced Compatibility Mode) is separated from the other three options of 1-bit, 3-bit, and code-point sections.  All of these options are meant to provide more reliability, and so any comparison that you do in 3.1.5 would also seem to demand a comparison of 3.4

Also, shouldn't the Requirements of 3.1.1 pertain to all of the options of 3.1.2, 3.1.3, 3.1.4, and 3.4?  And so, should the requirements section be at a section level about the different options?

I'll stress that this comment is more of a nit, but it would be helpful to re-organize these sections for a better flow and cleaner presentation of the points you want to make.

3) In the Discussion part of each of the options, you bring up the impact of the potential loss of ACKs to congestion.  I think you should make it clear to the reader that the congestion and loss you speak of concerning the ACKs from the receiver can be expected to be unrelated to the congestion of the downstream data packets forwarded towards the receiver.   This will be obvious to the individuals familiar with ECN, but not so much to the general reader.

4) for section 3.4, if you choose to cite what is observed in ns2, I think its important to solicit and add information about other deployed implementations.  

5) one very small nit.  I'd recommend changing the text "...(ECN) is an IP/TCP mechanism..."  to  "..(ECN) is an mechanism..".  A more generic statement about ECN that doesn't identify a specific transport protocol would reflect the work to add ECN support to DCCP and RTP/RTCP.

cheers,

-ken

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 7 Jul 2011 16:20:15 +0200

Hi Ken,

thanks a lot for your feedback. The points your are mentioning are all very 
valid and we've already been discussing some of them. 

1) The section 3.1.5. needs to be further extended (but we've been running out 
of time). But actually I've hoping that the description of the different 
schemes is good enough for the reader to basically fill an own table with 
pros and cons. Because if one provides a complete discussion, you already 
influence the reader to tend to a certain solution and you might prevent that 
new/different aspects will be regarded in a further discussion. 
Anyway, the goal is to have a full and detailed discussion in one of the next 
version which allows us to decide on the right scheme.

2) We reordered the sections actually several times. But 3.4. is actually not 
another option. It's an alternative, or lets say an hack, if the receiver is 
not supporting the new scheme. This can always be use no matter which coding 
will be chosen at the end. Also it's basically this one possible hack to 
scope with a 'classic' ECN receiver and thus the requirements doesn't apply 
to this mode. 

3) Yes, that's true. We will add a comment here.

4) In this case we are actually only talking about the TCP mechanism. In DCCP 
ECN is already defined in such a way that you have the exact number of CE 
markings. Thus there is not even a problem. I think it's somewhere mentioned 
in the draft but only as a very small side-remark...

Mirja

On Thursday 07 July 2011 14:27:25 ken carlberg wrote:
> 1) i think the draft would be improved if there were some explicit
> subsections that shouted out to the reader "strengths" and "weaknesses" of
> each approach.  Section 3.1.5 gives a brief hint of what the reader should
> consider, and each of the first three sections has a "discussion".  But in
> reading the various approaches, I have to dig around and write on a
> separate paper what characteristics I need to be aware of in comparing one
> to the other.  I see that you have a table in 3.1.5 representing a high
> level comparison of the three, but I don't have a clear idea of what you
> consider complex, accurate, or timely.  In a future version, you may want
> to consider presenting the options as: x.1 Description
> 	x.2 Strength
> 	x.3 Weakness
>
> And then in a following section, you can make a more detailed discussion of
> the different approaches -- e.g., expanding on the table of 3.1.5.  In my
> opinion, by stating up front what the authors/editors perceive is the
> strength and weakness of each, the reader can add further comment to help
> refine the decision to a single approach.  Afterwards, when one approach is
> agreed upon, then perhaps you can either remove the perceived
> strength/weakness or move it to an appendix.
>
> 2) for a lack of a better description, some of the sections seem to be
> mis-numbered in terms of a hierarchy and collection of sections.  It seems
> odd that section 3.4 (Advanced Compatibility Mode) is separated from the
> other three options of 1-bit, 3-bit, and code-point sections.  All of these
> options are meant to provide more reliability, and so any comparison that
> you do in 3.1.5 would also seem to demand a comparison of 3.4
>
> Also, shouldn't the Requirements of 3.1.1 pertain to all of the options of
> 3.1.2, 3.1.3, 3.1.4, and 3.4?  And so, should the requirements section be
> at a section level about the different options?
>
> I'll stress that this comment is more of a nit, but it would be helpful to
> re-organize these sections for a better flow and cleaner presentation of
> the points you want to make.
>
> 3) In the Discussion part of each of the options, you bring up the impact
> of the potential loss of ACKs to congestion.  I think you should make it
> clear to the reader that the congestion and loss you speak of concerning
> the ACKs from the receiver can be expected to be unrelated to the
> congestion of the downstream data packets forwarded towards the receiver.  
> This will be obvious to the individuals familiar with ECN, but not so much
> to the general reader.
>
> 4) for section 3.4, if you choose to cite what is observed in ns2, I think
> its important to solicit and add information about other deployed
> implementations.
>
> 5) one very small nit.  I'd recommend changing the text "...(ECN) is an
> IP/TCP mechanism..."  to  "..(ECN) is an mechanism..".  A more generic
> statement about ECN that doesn't identify a specific transport protocol
> would reflect the work to add ECN support to DCCP and RTP/RTCP.
>
> cheers,
>
> -ken

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 07 Jul 2011 19:20:45 +0100

Mirja, Ken,

Mirja = Ken's objection #5) (your 4) was because 
you described ECN as an IP/TCP mechanism, not 
because you described your draft as only about TCP. I support Ken's point.

Ken = Bear in mind that the 3 options in this 
draft are intended to support a process whereby 
one day we choose one and demote the others. So I 
would doc suggest the structure is designed for 
when this becomes a protocol spec, rather than a 
discussion of options for one of the functions.

Bob

At 15:20 07/07/2011, Mirja Kühlewind wrote:
>_______________________________________________
>conex mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/conex

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: ken carlberg <[email-masked]>
Date: Thu, 7 Jul 2011 14:31:28 -0400

On Jul 7, 2011, at 2:20 PM, Bob Briscoe wrote:

> Ken = Bear in mind that the 3 options in this draft are intended to support a process whereby one day we choose one and demote the others. So I would doc suggest the structure is designed for when this becomes a protocol spec, rather than a discussion of options for one of the functions.

ok, then I was a bit confused.  I was under the impression that one of the options would be chosen *during* the progression of the draft.  If all options (and possibly others that some may recommend) will remain, then I think this needs to be made more clear in the draft.  (And now I can more easily understand Mirja's desire not to influence an option before its been "experimented" with.)

but this also puts more importance in articulating the characteristics by which each is examined -- ie, what constitutes complexity, what determines efficiency, what measure of fault tolerance exists, blah, blah, blah.

-ken

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 07 Jul 2011 19:38:57 +0100

Ken,

SOrry. I meant the same as what you thought. Demote = kick out.

Except I was trying to allow for the possibility we leave some 
vestige of text in an appendix to exaplin what we didn't do and why not.

Bob

At 19:31 07/07/2011, ken carlberg wrote:

> > Ken = Bear in mind that the 3 options in this draft are intended 
> to support a process whereby one day we choose one and demote the 
> others. So I would doc suggest the structure is designed for when 
> this becomes a protocol spec, rather than a discussion of options 
> for one of the functions.
>
>
>ok, then I was a bit confused.  I was under the impression that one 
>of the options would be chosen *during* the progression of the 
>draft.  If all options (and possibly others that some may recommend) 
>will remain, then I think this needs to be made more clear in the 
>draft.  (And now I can more easily understand Mirja's desire not to 
>influence an option before its been "experimented" with.)
>
>but this also puts more importance in articulating the 
>characteristics by which each is examined -- ie, what constitutes 
>complexity, what determines efficiency, what measure of fault 
>tolerance exists, blah, blah, blah.
>
>-ken

---

From: ken carlberg <[email-masked]>
Date: Thu, 7 Jul 2011 14:42:02 -0400

ah, ok.  Works for me.

cheers,

-ken

On Jul 7, 2011, at 2:38 PM, Bob Briscoe wrote:

> Except I was trying to allow for the possibility we leave some vestige of text in an appendix to exaplin what we didn't do and why not.
> 
> 
> Bob
>