Subject: [conex] about draft-mathis-conex-abstract-mech-00.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 02 Nov 2010 12:13:31 +0100

Hi,

I read this document and i believe is a good starting point for our 
deliverable.

I have some comments though:

Section 1.1. when i read the document, the definitions included in this 
section were not very meaningful to me. In other words, this section 
defines a set of conex signals that without proper context are not very 
meaningful imho. So i believe that this section needs to be moved to 
later on, when the reader has more idea of what is going on.

Moreover, the Credit signal, i don't believe is properly explained 
anywhere in the document, or at least i haven't been able to find it. I 
think this needs to be explained in more detail. In particular, I found 
the text on section 2, point d quite confusing.

Section 3.1, the strawman encoding talks about bit 48 in the IPv4 
header. Since we are expliclty chartered not to work in v4, i find this 
a bit kind of looking for trouble.
I woudl suggest to remove any reference to IPv4 and simply say : "assume 
we have a bit in the IP header that we can use for this" I believe it 
conveys the same idea and imho it will prevent future troubles.

In the same section 3.1 It reads:

    Furthermore this
    encoding, by itself, does not sufficiently support partial deployment

Why not?

Section 3.2 seems to assume that the reader is familiar with reecn or 
will read about reecn. My personal prefernce would be that the doc is 
self contained, at least w.r.t. to congestion notification. I mean, i 
would like to see a document that i can read and i can understand conex, 
without needing to read other congestion exposure protocols. Do you 
think that would be feasible? I mean it is ok to reference reecn, but i 
would prefer if this document contians the main ideas that need to be 
understood to understand conex.
My preference would be to explain mre in detail these idea in this section.

In section 3.2.1

    This last change
    permits the transport protocol to carry multiple congestion signals
    per round trip, and greatly simplifies accurate auditing.

Why is that?

In section 3.3.1 the definition of credit is not clear enough to me.

Regards, marcelo

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 09 Nov 2010 01:30:02 +0800

Marcelo,

Tx for your review - you've pointed out a number of places where we 
have wrongly assumed too much prior knowledge.

A question: altho we don't have a charter item for a security doc, I 
think it would be useful to have a more detailed treatment of audit 
and policing. Perhaps that could be a informational report describing 
experiments with particular designs of security functions, making it 
clear they are not for standardisation. If we know we are going to do 
this, it might save putting too much detail in abstract-mech.

inline...

At 03:13 03/11/2010, marcelo bagnulo braun wrote:
>Section 1.1. when i read the document, the definitions included in 
>this section were not very meaningful to me. In other words, this 
>section defines a set of conex signals that without proper context 
>are not very meaningful imho. So i believe that this section needs 
>to be moved to later on, when the reader has more idea of what is going on.

My fault. I persuaded Matt to have terminology here, but you're 
right; it doesn't work.

There will be one or two other items of terminology that will have to 
go somewhere, e.g. audit function. Perhaps best will be to define 
terminology as we go through, then have a terminology recap section 
at the end, for quick reference from other drafts.

>anywhere in the document, or at least i haven't been able to find 
>it. I think this needs to be explained in more detail. In 
>particular, I found the text on section 2, point d quite confusing.

Next attempt we will consider putting less at bullet 2d.

And, as I've already promised to Mirja/Ingemar, we will add the 
missing explanation of credit when we talk about the audit function later.

>header. Since we are expliclty chartered not to work in v4, i find 
>this a bit kind of looking for trouble.
>I woudl suggest to remove any reference to IPv4 and simply say : 
>"assume we have a bit in the IP header that we can use for this" I 
>believe it conveys the same idea and imho it will prevent future troubles.

I didn't think the strawman encoding added much. So I wanted to 
delete it. But I see Matt's point that it leads the reader in gently.

If we keep it, we'll take out mention of v4, as you suggest.

>    encoding, by itself, does not sufficiently support partial deployment

Yes, this needs explaining better. Partial deployment was bad 
shorthand for 'loss-based' rather than 'ECN-based ConEx' here. It 
then refers back to the earlier sentence about needing a distinct 
codepoint for each. Given you also need a codepoint for neither, you 
can't get 3 codepoints out of 1 bit.

Clearly, we should not have assumed everyone would understand all 
this by oblique reference using a couple of words. We'll fix.

>Section 3.2 seems to assume that the reader is familiar with reecn 
>or will read about reecn.

I've re-read 3.2, and I don't think it assumes or needs re-ECN 
familiarity. Admittedly 3.2 doesn't describe the re-ECN protocol, but 
I don't think it leaves the reader wanting or needing to know that. 
The intention was merely to say re-ECN exists and to give the 
features of re-ECN we want to avoid, particularly to improve 
incremental deployability.

>My personal prefernce would be that the doc is self contained, at 
>least w.r.t. to congestion notification. I mean, i would like to see 
>a document that i can read and i can understand conex, without 
>needing to read other congestion exposure protocols. Do you think 
>that would be feasible? I mean it is ok to reference reecn, but i 
>would prefer if this document contians the main ideas that need to 
>be understood to understand conex.

Self-contained is our intent too. I didn't feel this section 
compromised that. Perhaps we're too close to re-ECN to be good judges 
of that tho.

I'll see what Matt thinks about the following order instead, which 
allows the reader to understand a full encoding, before talking about 
re-ECN. This should help clarify we're only talking about re-ECN to 
highlight the information it chose to remove (as a compromise to fit 
the available space):
3.1) Strawman Encoding
3.2) Abstract Encoding
3.3) Re-ECN Encoding
3.4) Encoding Discussion [bring end of S.2 here, from "It is 
important to note..."]

Rationale: Rather than taking them in historical order, it:
- starts with the naive idea as a gentle ramp for the tired reader,
- then it states the max information the protocol could expose,
- then it discusses compromises drawing back from max exposure:
   - first the compromises re-ECN made (for space reasons),
   - then ones we might make in the w-g.

>    per round trip, and greatly simplifies accurate auditing.

We need to spell this out.

It's because today's TCP feedback state machine (and derivatives of 
it) suppresses all but one nack per RTT (Reno's cumulative acks for 
drop, and the ECE/CWR mechanism for ECN). So if there was >1 
congestion indication in an RTT, today's TCP sender could not know, 
and would re-echo just one.

Therefore, without a modified feedback state machine, a TCP sender 
with the best intentions would not be able to help sometimes showing 
a shortfall between ConEx and actual congestion, which would be 
punished by the audit function.

>In section 3.3.1 the definition of credit is not clear enough to me.

Yup - got that.

Altho the most complex part of this doc will be the explanation of 
credit, I'm happy we should be able to keep the whole doc not much 
longer than it is now.

Thanks again.

Bob

>Regards, marcelo
>
>
>
>_______________________________________________
>conex mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/conex

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 9 Nov 2010 03:42:47 +0100

Hi

Just a comment on the mention of re-ECN and bit 48 in IPv4. I agree that it may be asking for trouble. Still it does well as an educational example so I have nothing against keeping it in the abstract mechanism draft for instance as a appendix. You may add a proper disclaimer in the appendix to be on the safe side. For many people (such as yours truly) a "real example" makes it a lot easier to understand the more abstract part, bits are sometimes easier to comprehend than abstact codepoints. 

Most of the conex stuff is fairly easy to understand, but there are things such as the initial credit marking that may benefit from a real example.
I am not that convinced about the need for a strawman encoding section. I would belive that it should be sufficient with the abstract encoding and in an appendix a description of how the abstract mechanism is conflated to Re-ECN. I guess the final ConEx solution is described in a separate document ?

my 5 RMB

/Ingemar

> -----Original Message-----
> From: Bob Briscoe [mailto:[email-masked]] 
> Sent: den 9 november 2010 01:30
> To: marcelo bagnulo braun
> Cc: [email-masked]
> Subject: Re: [conex] about draft-mathis-conex-abstract-mech-00.txt
> 
> Marcelo,
> 
> Tx for your review - you've pointed out a number of places 
> where we have wrongly assumed too much prior knowledge.
> 
> A question: altho we don't have a charter item for a security 
> doc, I think it would be useful to have a more detailed 
> treatment of audit and policing. Perhaps that could be a 
> informational report describing experiments with particular 
> designs of security functions, making it clear they are not 
> for standardisation. If we know we are going to do this, it 
> might save putting too much detail in abstract-mech.
> 
> inline...
> 
> My fault. I persuaded Matt to have terminology here, but 
> you're right; it doesn't work.
> 
> There will be one or two other items of terminology that will 
> have to go somewhere, e.g. audit function. Perhaps best will 
> be to define terminology as we go through, then have a 
> terminology recap section at the end, for quick reference 
> from other drafts.
> 
> 
> And, as I've already promised to Mirja/Ingemar, we will add 
> the missing explanation of credit when we talk about the 
> audit function later.
> 
> 
>