Subject: [conex] draft-ietf-conex-abstract-mech-02

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 17 Jul 2011 15:47:58 +0200

Hi,

Some comments about this draft, speaking as an individual contributor.

I think this draft look very good and most of it is very clear.

Substantial:

In the intro it reads:

  For the avoidance of doubt, there is no expectation that internetwork
    layer devices will do fine-grained congestion control using ConEx
    information.

But the audit function is likely to do per flow processing, so it seems 
a bit confusing.

In section 2 it reads:

   Given that loss-based and ECN-based ConEx might sometimes be best
    audited at different locations, having distinct encodings would widen
    the design space for the auditing function.  Using the same encoding
    for both signals is likely to make one of the auditing techniques
    infeasible, and the others less accurate.

This seems to imply that there will a different encoding when congestion 
is exposed based on ECN info and when it is obtained from losses. Is 
that what this means? This would increase the amount of code points 
needed, correct? This is not considered in the encoding section, in 
particular in 3.3 where the signals are described, there is no 
differentiation when the congestion is ecn or losses, shoudln't this be 
included there as well?

In section 3.1, i believe that the strawmand encoding should be the IPv6 
encoding that conex is defining rather than an encoding that we will not 
use.
Similarly with section 3.2. My suggestion is to move section 3.1 and 
section 3.2 to an appendix where alternative encodings are discussed and 
keep in this section a short description of the v6 encoding we are 
working on.

Later on section 4.3 it reads:
" Ideally, ConEx should be added to a transport like TCP without
    mandatory modifications to the receiver.  But an optional
    modification to the receiver could be recommended for precision."
I don't understand what this means, maybe it would be useful to expand a 
bit?

Later on in section 4.4.1. I still have a hard time to understand the 
credit. I understand the problem it is trying to solve, but i can't 
really understand how the credit soves the problem out of the proposed text.

In the same section, it reads:
"   The one-way nature of packet forwarding probably makes per-flow state
    unavoidable for the audit function.  This was a necessary sacrifice
    to avoid per-flow state elsewhere in the wider ConEx architecture.
    Nonetheless, care was taken to ensure that packets could bring soft-
    state to the audit function, so that it would continue to work if a
    flow shifted to a different audit device, perhaps after a reroute or
    an audit device failure.  Therefore, although the audit function is
    likely to need flow state memory, at least it complies with the
    'fate-sharing' design principle of the Internet [IntDesPrinciples],
    and at least per-flow audit is only required at the outer edges of
    the internetwork, where it is less of a scalability concern.

    Note also that ConEx does not intend to embed rules in the network on
    how individual flows _behave_.  The audit function only does per-flow
    processing to check the integrity of ConEx _information_."

I don't think these 2 paragraphs belong to the credit section (i mean 
there si nothing specific to the credity in them afaict, but they are 
generic to the audit function). I think they belong to section 4.4.2

Editorial

In the abstract:

s/The mechanism to be developed by the ConEx WG/ The ConEx mechanism

Overall the document, capitalize the first letters of acronym expansion.
For example, in the Introduction:

s/explicit congestion notification (ECN)/Explicit Congestion 
Notification (ECN)

s/ip header/IP header

later on, in the same situation are: RNC, BRAS, DSL

As a matter of taste, i personally preffer using the IP layer term 
instead of the intenetwork layer.

In section 2:

I suggest to split requirement a) into multiple requirements. I mean, 
visibility and inmutability are different requirements.

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 17 Jul 2011 20:02:25 +0100

Marcelo,

Thanks for these. In general we'll try to fix the points you raise, 
but one or two responses inline...

At 14:47 17/07/2011, marcelo bagnulo braun wrote:
>But the audit function is likely to do per flow processing, so it 
>seems a bit confusing.

Is this really confusing? Even though audit might be per-flow, we 
said this under Audit:
"  Note also that ConEx does not intend to embed rules in the network on
    how individual flows _behave_.  The audit function only does per-flow
    processing to check the integrity of ConEx _information_.
"

I don't see how we can make it any clearer that the two points are 
not contradictory. We shouldn't say anything in the Intro, because 
the reader doesn't yet know that audit is per-flow anyway. And when 
we get to saying audit probably has to be per-flow, we immediately 
have the above very clear statement that distinguishes audit from 
congestion control (or anything to do with controlling rate).

We are trying to separate out different sorts of per-flow processing, 
and we are trying to dig under the blanket-ban "per-flow is evil" to 
the (four) different underlying reasons why per-flow stuff can be 
harmful, to show we don't contravene the three most critical of them.

See 
<http://www.ietf.org/mail-archive/web/conex/current/msg00661.html>, 
which I suggested to Matt at the time ought to be incorporated into 
the next rev of abstract-mech.

>This seems to imply that there will a different encoding when 
>congestion is exposed based on ECN info and when it is obtained from 
>losses. Is that what this means? This would increase the amount of 
>code points needed, correct? This is not considered in the encoding 
>section, in particular in 3.3 where the signals are described, there 
>is no differentiation when the congestion is ecn or losses, 
>shoudln't this be included there as well?

I think you've missed it. In both 3.3.1 & 3.3.2 there is both:
- Re-Echo-Loss
- Re-Echo-ECN

>In section 3.1, i believe that the strawmand encoding should be the 
>IPv6 encoding that conex is defining rather than an encoding that we 
>will not use.

It wouldn't be a strawman if we were using it. A strawman is 
deliberately simple and naive so that it is easy to understand, but 
it doesn't stand up to deeper analysis.

And in the strawman text it says it's not going to be used because 
it's IPv4 only and we've been chartered to address v6.

>section 3.2 to an appendix where alternative encodings are discussed 
>and keep in this section a short description of the v6 encoding we 
>are working on.

When Matt first wrote this doc he designed it to state an abstract 
ideal, even if we have to compromise in the actual encoding (this is 
all explained at the start of S.3). I liked that approach. It would 
surely be wrong to reflect back what we have eventually decided to do 
into the statement of ideal requirements.

Having said that, I agree 3.2 doesn't all fit:
a) we don't have to say what re-ECN did (altho sometimes it's useful 
to say how ConEx is different, for people who originally read re-ECN 
and assume ConEx is the same)
b) we do want to describe the implications on transport protocols 
(esp TCP), but this should be in a section about implications on 
transport protocols, not in the IP encoding section. Probably best at 
the end of Section 3.

>I don't understand what this means, maybe it would be useful to expand a bit?

OK. It's obviously not clear that this refers back to the problem 
described in the previous para. (the problem is TCP only responds 
once per RTT to congestion, so the feedback didn't need to be 
designed to indicate more than this, even if there were more 
losses/ECN marks per RTT. However, re-ECN needs to reflect all 
congestion events, not just one per RTT. TCP feedback's accurate 
enough for losses, especially with SACK, but ECN-feedback needs 
changing. This was called for in the charter and is the purpose of 
draft-kuehlewind-conex-accurate-ecn).

>Later on in section 4.4.1. I still have a hard time to understand 
>the credit. I understand the problem it is trying to solve, but i 
>can't really understand how the credit soves the problem out of the 
>proposed text.

OK. It would probably fix this if we give an example of how credit 
would work (similar to the presentation in Beijing that Andrea 
Soppera did on my behalf).

>I don't think these 2 paragraphs belong to the credit section (i 
>mean there si nothing specific to the credity in them afaict, but 
>they are generic to the audit function). I think they belong to section 4.4.2

You're right. We ought to put a new sub-section heading "Audit and 
Per-flow State" before these paras.

Thanks for this - always v useful to have a fresh eye look over a draft.

Cheers

Bob

>I suggest to split requirement a) into multiple requirements. I 
>mean, visibility and inmutability are different requirements.
>
>
>
>_______________________________________________
>conex mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/conex

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: "Toby Moncaster" <[email-masked]>
Date: Sun, 17 Jul 2011 22:09:14 +0100

One comment snipped inline marked {TM} 

As I haven't read the whole draft I can't really comment on more than this
one issue

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bob Briscoe
Sent: 17 July 2011 20:02
To: marcelo bagnulo braun
Cc: 'ConEx IETF list'
Subject: Re: [conex] draft-ietf-conex-abstract-mech-02

<snip>

Substantial:

In the intro it reads:

But the audit function is likely to do per flow processing, so it seems a
bit confusing.

Is this really confusing? 

{TM} Unfortunately this does seem to have been confusing to a lot of people.
And that has made them write off ConEx as they assume we are requiring every
device in the network to be upgraded...

Even though audit might be per-flow, we said this under Audit:
"
  Note also that ConEx does not intend to embed rules in
the network on
   how individual flows _behave_.  The audit function only
does per-flow
   processing to check the integrity of ConEx _information_.
"

{TM} I think the issue is that people have such pre-conceived notions of
ConEx that they are already assuming it requires per-flow or per-packet
processing because that is what things like flow-aware routing required...  

I think you could make it clearer that audit only ever really needs be done
at the edges where intelligent "slow path" things exist. I think there is a
wrong belief that ConEx auditing has to be done every time a ConEx mark is
set...

I don't see how we can make it any clearer that the two points are not
contradictory. We shouldn't say anything in the Intro, because the reader
doesn't yet know that audit is per-flow anyway. And when we get to saying
audit probably has to be per-flow, we immediately have the above very clear
statement that distinguishes audit from congestion control (or anything to
do with controlling rate).

</snip>

{TM} Unfortunately ConEx needs these first two documents to tread a fine
line between being cold standards documents and spoon feeding the people
that are determined to find problems even where they don't exist... In other
words, if there is still room for misunderstanding you need to tweak the
text somehow. If I get a chance I will read the draft and try and give some
actually constructive comments on how to do this, but probably won't have
time before next weekend

Toby

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 18 Jul 2011 09:14:56 +0200

below

i only keep the issues that i don't completelly agree with your replies...

El 17/07/11 21:02, Bob Briscoe escribió:
> deliberately simple and naive so that it is easy to understand, but it 
> doesn't stand up to deeper analysis.
>
i understand that
What i am suggesting is to include a v6 example, not with all the 
details of the encoding but simply saying that we encode the information 
in an ipv6 dest option and that the details are defined later (maybe a 
reference to suresh draft)

I think this would make the document set more coherent.

> all explained at the start of S.3). I liked that approach. 
i agree with this as well

> It would surely be wrong to reflect back what we have eventually 
> decided to do into the statement of ideal requirements.
>
i am not sure i understnad what you mean by this

> and assume ConEx is the same)

i am fine with pointing the difference, but as i said, i think this 
would fit best in an appendix

> b) we do want to describe the implications on transport protocols (esp 
> TCP), but this should be in a section about implications on transport 
> protocols, not in the IP encoding section. Probably best at the end of 
> Section 3.
>

ok

> described in the previous para. (the problem is TCP only responds once 
> per RTT to congestion, so the feedback didn't need to be designed to 
> indicate more than this, even if there were more losses/ECN marks per 
> RTT. However, re-ECN needs to reflect all congestion events, not just 
> one per RTT. TCP feedback's accurate enough for losses, especially 
> with SACK, but ECN-feedback needs changing. This was called for in the 
> charter and is the purpose of
ok, i understand it now.

maybe my problem was with the previous paragraph where it states:

"The sender may require
    more precise feedback from the receiver otherwise it is at risk of
    appearin to be understating its ConEx Signals "

It is not clear to me what it means by appearing to be understanding its conex signals.

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 18 Jul 2011 10:25:34 +0100

Marcelo,

I think we've now converged (assuming Matt also agrees).

Responses inline...

At 08:14 18/07/2011, marcelo bagnulo braun wrote:

>>>In section 3.1, i believe that the strawmand 
>>>encoding should be the IPv6 encoding that 
>>>conex is defining rather than an encoding that we will not use.
>>
>>It wouldn't be a strawman if we were using it. 
>>A strawman is deliberately simple and naive so 
>>that it is easy to understand, but it doesn't stand up to deeper analysis.
>>
>>And in the strawman text it says it's not going 
>>to be used because it's IPv4 only and we've been chartered to address v6.
>i understand that
>What i am suggesting is to include a v6 example, 
>not with all the details of the encoding but 
>simply saying that we encode the information in 
>an ipv6 dest option and that the details are 
>defined later (maybe a reference to suresh draft)
>

Oh certainly (talking for myself, not having 
checked with my co-author here). I would like to 
make sure that we refer to every piece of ConEx 
documentation from somewhere in this doc. Yes, we 
need to update the doc to talk about more recent work.

>>>Similarly with section 3.2. My suggestion is 
>>>to move section 3.1 and section 3.2 to an 
>>>appendix where alternative encodings are 
>>>discussed and keep in this section a short 
>>>description of the v6 encoding we are working on.
>>
>>When Matt first wrote this doc he designed it 
>>to state an abstract ideal, even if we have to 
>>compromise in the actual encoding (this is all 
>>explained at the start of S.3). I liked that approach.
>>It would surely be wrong to reflect back what 
>>we have eventually decided to do into the statement of ideal requirements.

We could point to what we've decided to do, but 
only in the context of comparing it with the 
ideal, but we have to be clear it is not the same 
as the ideal. This doc is about the ideal. I 
would say the v6 encoding is where we should talk 
about the particular set of compromises made relative to the ideal.

>>a) we don't have to say what re-ECN did (altho 
>>sometimes it's useful to say how ConEx is 
>>different, for people who originally read re-ECN and assume ConEx is the same)
>
>i am fine with pointing the difference, but as i 
>said, i think this would fit best in an appendix

Yes, I meant to agree with that.

>>b) we do want to describe the implications on 
>>transport protocols (esp TCP), but this should 
>>be in a section about implications on transport 
>>protocols, not in the IP encoding section. 
>>Probably best at the end of Section 3.
>
>ok
>
>>
>>OK. It's obviously not clear that this refers 
>>back to the problem described in the previous 
>>para. (the problem is TCP only responds once 
>>per RTT to congestion, so the feedback didn't 
>>need to be designed to indicate more than this, 
>>even if there were more losses/ECN marks per 
>>RTT. However, re-ECN needs to reflect all 
>>congestion events, not just one per RTT. TCP 
>>feedback's accurate enough for losses, 
>>especially with SACK, but ECN-feedback needs 

OK, I've noted that better explanatory text is 
needed to describe the problem here.

Bob