Subject: Re: [conex] WGLC for draft-ietf-conex-abstract-mech-03.txt

From: John Leslie <[email-masked]>
Date: Mon, 5 Dec 2011 06:33:56 -0500

marcelo bagnulo braun <[email-masked]> wrote:
> 
> Please review the document and send comments before the 5th december.

   The overall effect of this document is that of an impenetrable
academic paper. :^( I'd prefer something more approachable. (Alas, I
have been busy the past few weeks, and didn't set aside enough time
to review it: thus I've missed the deadline by local time, though
not necessarily by "any-time-zone" rules. ;)

   This I-D contains a lot of good material. The organization is a
bit confusing, but IMHO would be good if we were more selective in
what we include. For one example, proxies are introduced but not
explained in sufficient detail. They do not strike me as in any way
necessary to the ConEx mechanism -- merely a potential tool to
speed deployment...

   I'd go a lot easier on the part about competing Congesiton-Control
algorithms. Our point is that there are many of them and we expect
more, with ConEx merely signaling the detected loss and/or ECN marks.
Specifically, I'd replace the third bullet in section 1 with something
like, "Some alternate CC algorithms use delay as an input. ConEx does
not treat delay as a measure of congestion, and is concerned only
with ECN marking and packet loss."

   I'd omit the paragraph before Figure 1: it introduces ideas better
introduced elsewhere.

1.1 Terminology

   "Congestion level" is used but not defined.

2 Requirements for the ConEx Signal

   In 2.a I strongly recommend removing mention of IPv4 -- it's outside
our charter.

   In 2.c "auditing" is used in a somewhat non-intuitive manner, to
mean a function which both derives information and acts upon it to
change the flow. I'd much rather introduce "auditing" as gathering
information, not policing. Thus I recommend against "must have a
capability of providing sufficient disincentives". As we gain
experience with ConEx, I expect disincentives will be found, but
it's premature to say here what they may turn out to be.

   In 2.d I fully agree that ConEx should include building "credit"
against congestion expected before the feedback time (likely to be
several RTTs). However (IMHO) it's not good to tie this to the
auditing function.

   We've already seen on-list some substantial confusion from this.
We have folks gravitating towards setting the "credit" bit on
every packet "just in case". This is not useful: a ConEx signal
which is always present is no more useful than a ConEx signal which
is never present.

   My strong opinion is that all nodes along the path should be
able to determine a "congestion-expected" metric which reasonably
tracks the congestion impairment for the flow in question. It's
premature (IMHO) to say just how to do this, but I think it would
be best to treat the "credit" signal as an "expectation" at the
start (or resumption) of a flow, which suggests that different
CC algorithms may choose to set it differently. Such details
shouldn't be nailed down too early.

   A general comment here: in a number of places in this I-D,
the reader trying to imagine how to implement ConEx will boggle
on how to implement the "auditing function". It seems to require
per-flow state at points along the path where this is wildly
impractical.

   I do not believe ConEx needs such a draconian function that
seems to be requiring high estimates for "credit". It's not that
I object to such a function _existing_ -- rather that this is
just _one_ way to use ConEx signals. Even if it is in fact the
best way, requiring it at the outset of Experimental phase scares
me.

   There is perhaps an unstated assumption that we can have
policing near the sender which will satisfy all nodes along the
path about the accuracy of congestion prediction. To an operator
this is laughable.

   My honest suggestion is to separate out any details of an
auditing function which includes policing into a separate document
which we can revise as we gain experience. Abstract-mech will be
stranger if it limits itself to how to signal the interesting
metrics, without tryinng to specify how to make them trustworthy.

   In any case, I recommend cutting back 2.d to something like,
"The ConEx signal SHOULD be timely. There will be a minimum delay
of one RTT, and often it will be longer. In order for nodes along
the path to ignore this delay, ConEx signals SHOULD include a
"credit" signal to cover congestion (not yet measured) during
this delay."

   The information about ECN congestion being best audited near
the receiver, etc., is important, but deserves its own section
later in the document. Personally, I'd leave out all mention of
how to infer loss at an auditing point. It's not IMHO a _ConEx_
mechanism -- it's a research topic during experiments. While
Matt and Bob may be right that this is the best way to do it,
the world is more complicated than we _can_ imagine and I expect
our readers to imagine lots of alternatives.

   The statement about signaling loss separately from ECN is
critically important IMHO, and very much deserves its own section.
Though we may not want to go into detail about differing AQM
algorithms and parameters, these are an important part of what
should be tried during experiments, and I'd like to hint more
at that.

   (To digress, DCTCP for example uses AQM parameters to signal
queue depth much more aggressively than the ECN standard implies,
and this turns out to be very useful in the limited environment
where DCTCP is used. There is almost certainly an opportunity to
develop somewhat similar AQM signaling in the big-I Internet,
where ECN marking could be common at nodes where packet loss is
quite rare. We cannot make such changes to ECN in this WG as
currently chartered; but I'd like to leave room to develop
experiments in that direction.)

3. Encoding Congestion Exposure

   I'd omit entirely the "Naive Encoding". For academic papers, this
would be helpful, but here we need to get to the point. We're going
to end up with at least 4 independent bits: it can't help implementors
that we dwell on alternatives. (So 3.1 shouldn't be a separate section.)

3.2 ECN Based Encoding

   Talking of sharing ECN codepoints only confuses the reader. It
can't be understood without going into a lot of re-ECN details, and
that's not the path we will take. I'd omit 3.2.

   The ECN changes section mention of a "different state machine"
is particularly confusing, but I don't believe it is needed for
ConEx. (If it is, it needs a lot more explanation.)

   Section 3.3 feels like the right introduction.

   Section 3.3.1 should match the actual naming of the independent
bits, if possible. If we maintain "abstract-mech" as an I-D, we
can change these if needed without needing to revisit the whole
document.

   Section 3.3.2 should be deleted -- we're not going to recommend
this.

4. Congestion Exposure Components

   I dissent on assigning a policing role to the "auditing function".
"Auditing" and "Policing" were kept separate in use-cases while I
was on the editing team, and I strongly recommend keeping the separate
still. Eventually, they may belong in the same box, but auditing with
no policing will remain a useful function.

   I further suggest that mandating the two be combined does not
belong in an "Abstract Mechanism" document. Nor is the policing
function made any easier to understand by forcing this combination.
I'd prefer that any details of auditing and/or policing be in a
separate document, and abstract-mech merely refer to it as an
optional addition to the basic mechanism.

   Arguments that ConEx is useless without policing don't convince me.
If true, ConEx would be just as useless without trustworthy policing,
and to an ISP any policing done by a competitor is by definition
untrustworthy.

   Most of the rest of Section 4 is pretty good. I'm a bit nervous
about seeming to require ECN-feedback changes, but I don't think the
text intends to actually require them. I'd be happier if all of
Section 4.4 (including 4.4.1 and 4.4.2) disappeared into a separate
document.

4.5 Policy Devices

   This is rather good, but I wonder how well it represents an actual
consensus of this WG -- I'd feel more comfortable with a record of
discussion in the archives of this mailing-list. While I don't
disagree with 4.5.2, I'm uncertain how many of us want to try this.

   In 4.5.3, I'm actively uncomfortable with the term "Congestion
Policer". To me, this is describing a particular case of a Policy
Device, and is by no means the only "policing" function a Policy
Device might do. Perhaps we could find another term along the lines
of "Packet Sorter".

   The implication needed is that at any organizational boundary
it's reasonable to limit the "congestion-expected" that you allow
into your network. (Whether you limit by bytes, packet, or some
combination is a local decision hopefully covered by contractual
agreements.) When presented with traffic which exceeds such limits,
reducing the scheduling priority or selectively dropping packets
is reasonable (though of course not _required_ by ConEx protocol).

   (The use of "Not-ConEx-Marked" may or may not be right in this
paragraph: I have not tried to work that out. IMHO any such details
are local, and other sorting algorithms seem allowable.)

5. Support for Incremental Deployment

   There's a lot of good stuff here... perhaps too much. I would,
for example, omit any mention of proxies.

   I could go into a lot more detail, but I think this email is
long enough.

7. Security Considerations

   This section needs actual discussion of some threats. (The less we
promise, the less threats we need to discuss!)

8. Conclusions

   This isn't needed as a section in an Internet-Draft.

11.2. Informative References

   I appreciate the joke, but do we really want to reference RFC3514?

--
John Leslie <[email-masked]>

---

From: Matt Mathis <[email-masked]>
Date: Mon, 5 Dec 2011 10:09:43 -0800

John, most of your comments are right on the money.  I will make the
changes as suggested.    There are a couple which I would rather call and
discuss to see if I can find a way to make the document clearer rather than
changing its intended meaning.

I will send a more extensive response to the list after that conversation.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

On Mon, Dec 5, 2011 at 3:33 AM, John Leslie <[email-masked]> wrote:

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

---

From: <[email-masked]>
Date: Mon, 19 Dec 2011 08:39:22 +0000

Here are some comments, sorry they are late
Best wishes
Phil

Basically seems ready and to do the job. S3.2 and S4.5.3 need a bit of work I think. I don't think you'll get away with the minimalist S7 Security considerations. Otherwise minor comments.

S1
"One of the required functions ..." is it "required"? Simply: "A transport protocol controls congestion in the network."
Para 3 sentence 1 is awkward, "This document proposes..." - suggest splitting the sentence in two and re-phrasing 

1.1	Terminology.
Add "ConEx Signal - a packet sent by a ConEx-capable transport. It has one of the following values...
"aka" should be deleted

S2 Requirements
 I think the section could have a couple of lines of intro. "Network devices read the ConEx Signal, which indicates the end-to-end congestion, and may act based on its measurements. In order to act reasonably, the ConEx Signal needs to be accurate and timely. In order to discourage the sender from sending a false ConEx Signal, it needs to be auditable; the basic audit technique is to count and compare the ConEx Signal and the actual congestion."
 "any of these requirements" -> "a requirement"
p7 bullet 1, "should never" -> SHOULD NOT
the sub-bullets seem too detailed at this point

S3 
I wondered if the intro here should be (also) in S1. 
"most important" - delete
Penultimate para, "experimental conex encoding chosen for IPv6 [i-d] had to make" -> "encoding [i-d] makes" (otherwise this doc will have to wait for the encoding i-d).   Last sentence re-phrase: "If experiments reveal particular issues with the encoding, then this document will still serve as a reference point"

S3.1
You could start with some words how this relates to the ConEx Signal codepoints, ie naive is Conex-marked & conex-not-marked.

S3.3 should be S3.2. the reader expects to read about the abstract encoding immediately after the naive encoding. 
Para 2, bytes vs packets - might be better to deal with is separately, think it would be better than hiding within codepoint discussion

S3.3.2 - could be phrased better

S3.2 - thought this needed improvement. Suggest re-writing this without talking about re-ECN, and then having an Appendix that's re-ecn specific. The first para is almost enough.
You could add some capitals: the encoding SHOULD support ECN, meaning (1) congestion is signalled with ECN, (2) the transport sender and receiver are ECN-enabled.
"re-ecn specification" -> draft. "central theme...", "takes a step back..." not relevant here. "perfectly" is bold.

S4 "natural ultimate" -> "the"

S4.2 insert "for example" before [I-D.conex-tcp-mods] (otherwise you'll have to wait for it to be an rfc]"
"because it known that conex without ecn is harder to audit" - known -> believed. Add a reference. Is it possible to add a hint of the explanation? Does it affect the auditing hardness whether the receiver is modified or not?
Thought S4.2 could end with "harder to audit" - the rest didn't seem relevant here (move to Incremental deployment section?

S4.4 add "for example" in line 2

S4.4.2 "Audit SHOULD quickly detect and sanction dishonest flows, preferably at the first dishonest packet" - preferably -> ideally

S4.5.3. Congestion policers - think this needs some improvement. Perhaps some words could be copied from the use cases doc. Start by saying its purpose, something like
 "A congestion policer limits the congestion. It reads the ConEx Signals in order to measure the amount of congestion that the traffic causes somewhere downstream. If, for example, the congestion-bit-rate exceeds some configured level, then it takes action to limit the amount of conex traffic by dropping, delaying or downgrading traffic. Typically the congestion policer operates separately for each user. It can be implemented by a simple token bucket..."

S5 "in every possible respect" is bold? 
Sources -> senders.
Conex packet markings -> ConEx Signals
P18 middle para "If necessary, endpoints would be able to detect if a network were removing ConEx signals" - would be able to -> SHOULD? were -> is
Next para - does the use cases draft still include discussion of deployment incentives?

S7 - I guess this needs bulking up

Codepoints or code points
ConEx Signal - capitalise consistently

Philip Eardley   
Research and Technology Strategy

This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
Sent: 17 November 2011 01:52
To: 'ConEx IETF list'
Subject: [conex] WGLC for draft-ietf-conex-abstract-mech-03.txt

This note issues the WGLC for draft-ietf-conex-abstract-mech-03.txt.
(http://www.ietf.org/id/draft-ietf-conex-abstract-mech-03.txt)

Thanks, marcelo