On 10/1/15 12:27 PM, Bob Briscoe wrote:
Robert, Mirja,
Responding (eventually) as one of the authors of conex-abstract-mech
First one point I picked up that might be a misconception from Robert:
On 26.08.2015 22:19, Robert Sparks wrote:
Should
there be a statement that this option must not be used unless by a
transport extension that's discussed how to use it? If not, then
shouldn't this document talk about what happens if there's no
transport header below to inform audit function behavior?
ConEx is designed so that audit is agnostic to the particular
transport behaviour. One would not expect the audit function to look
for a transport header and change its audit behaviour accordingly
(ConEx is designed on the assumption the transport header is or at
least could be encrypted). conex-abstract-mech says:
Transport Oblivious: Audit SHOULD NOT be designed around one
particular rate response, such as any particular TCP congestion
control algorithm or one particular resource sharing regime such
as TCP-friendliness [RFC5348 <https://tools.ietf.org/html/rfc5348>]. An
important goal is to give
ingress networks the freedom to unilaterally allow different rate
responses to congestion and different resource sharing regimes
[Evol_cc
<https://tools.ietf.org/html/draft-ietf-conex-abstract-mech-13#ref-Evol_cc>], without having to coordinate with other networks over
details of individual flow behaviour;
I'd be interested to know where in the docs you got a different
impression, because we ought to try to fix that.
I didn't actually think the audit function code would change per
transport. But as you point out, my suggested fix to the disconnect I
think I see implies that, so it is off the mark.
Your suggestions below will address the concern.
Now, responding to the conversation...
On 28/09/15 20:37, Robert Sparks wrote:
On 9/22/15 7:46 AM, Mirja Kühlewind wrote:
Hi,
regarding M1:
I don't think we can say much more in this doc than what is already
said in the abstract mechanism doc as we simply don't know which
protocol will be used on top of it.
So should this document restrict the use of the extension to those
protocols that are used on top of it where the discussion can be
concrete? (That's what I was suggesting when I asked " Should there
be a statement that this option must not be used unless by a
transport extension that's discussed how to use it?")
That /seems/ reasonable. But let's consider a test-case before
adopting this last sentence: e.g. DNS
I could implement ConEx for a sender of DNS datagrams (that receives
no congestion feedback). conex-abstract-mech says:
Alternatively, without sufficiently precise
congestion feedback from the receiver, the source may have to
conservatively send extra ConEx markings in order to avoid
understating congestion.
So, I could modify my DNS sender to add a CDO header to all IPv6
packets and always set the credit flag. Then, if my sender was behind
a ConEx policer, it would consume some degree of congestion allowance,
but it could never be accused of understating congestion by an audit
function.
Would I need a DNS-specific ConEx document to make this modification?
or could I just implement it based on conex-abstract-mech and
conex-dest-opt?
Actually just these two docs would be sufficient. A DNS-conex document
might be able to suggest a better more efficient mechanism, but it
wouldn't be /necessary/ to write that doc to implement ConEx in DNS.
The subtle point here is that the top-level requirement that ConEx
places on a transport protocol is merely not to understate the
congestion you cause. Any doc defining how a transport sets ConEx
information is really just guidance on how not to look like you are
being dishonest if you intend to be honest. The DNS example shows how
you can be sufficiently honest without a document.
I follow that.
It's a minor pedantic point, but I think the above indicates that
-destopt- doesn't define a concrete ConEx protocol by itself.
What we can do is to add one sentence saying that there must be a
way in the higher layer protocol to provide feedback about
congestion (loss and/or ECN) and that the specification for the
higher layer protocol must discuss how an audit function in the
network can access information on congestion on the forward path
(e.g. monitoring seq#).
That makes sense to me.
conex-abstract-mech deliberately does not require transports to use
congestion feedback (as in the DNS example above).
Also, as quoted above, conex-abstract-mech requires audit to be
transport-agnostic, altho optimisations are possible when the
transport is visible.
So please don't contradict conex-abstract-mech by saying either of
these things.
The way the ConEx docs are structured, conex-abstract-mech is the
place to state requirements on transport protocols and on audit, and I
haven't yet seen anything in this conversation to say we've missed one
(altho I have noticed below that we failed to act on one requirement).
I certainly agree that a doc giving examples of good audit functions
would be extremely useful. But I think the requirements on audit in
conex-abstract-mech are sufficient.
I know some people really want the rules to be clearer. But the
requirements for audit in conex-abstract-mech will still carry more
weight than how one particular example audit device works.
Right.
The "must discuss how" above was what was tempting for me.
Further regarding the abstract mechanism doc, it says the following:
"The general goal of an auditor is to make sure that any ConEx-enabled
traffic is sent with sufficient ConEx-Re-Echo and ConEx-Credit
signals. A concrete definition of the ConEx protocol MUST define
what sufficient means."
I'm not sure if this is a correct usage of normative language, but I
will double-check with the author of this document. However, I don't
think we can say more about what sufficient means that it is already
described in the abstract mechanism doc (further down in section 5.5).
It might also be the case that the authors actually meant to say
here something like
"A transport that uses the ConEx protocol MUST define
what sufficient means."
which would probably me more sensical. I'll check with them.
Bear in mind that abstract-mech is /ultra/ abstract (Matt Mathis
suggested this and we all agreed). abstract-mech envisages that
conex-dest-opt might not be the only concrete ConEx protocol. So this
sentence means that conex-dest-opt has to state the basic audit rules.
I.e. the three penalty criteria in
<https://tools.ietf.org/html/draft-wagner-conex-audit-01#section-2.3>
If David Wagner is not available to re-write these for conex-destopt
and the draft authors can't, I could have a go, but I have other stuff
I'm meant to be doing this week.
Sorry, when I reviewed conex-dest-opt for compliance with
abstract-mech, I failed to notice the gap where this important
requirement should have been satisfied - probably because we stuck the
requirement in section "5.5 Audit", whereas we should have added it to
the list in "3.3. Requirements for non-abstract ConEx specifications".
I suspect fixing this will resolve your concern, Robert.
Yes.
I'm grateful you pointed this out - it is a huge omission - we were
all assuming it, but the actual writing has fallen between the cracks
of all the docs.
One more response in the nits below...
However, while writing these documents, we figured that we actually
would need another document on auditing because there are some
assumption that must be taken in the protocol design. The main
purpose of that doc is/was to give guidance how to design an audit
without caring of all the details in the tcp-mods doc. There is an
(expired) draft (draft-wagner-conex-audit-01) which we did not
follow because there was no energy in the wg and it was not in the
original milestone list. We should definitely consider to revisit
this draft if we plan further experimentation on ConEx.
Does this makes sense to you?
Yes.
Mirja
On 26.08.2015 22:19, Robert Sparks wrote:
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: draft-ietf-conex-destopt-09
Reviewer: Robert Sparks
Review Date: 26 Aug 2015
IETF LC End Date: 31 Aug 2015
IESG Telechat date: 1 Oct 2015
Summary: On the right track with open issues
Major issues:
M1) This document claims to specify "the ConEx wire protocol in IPv6".
But it reads more like "this document just defines an option, other
documents will talk about how and when the option is used". The
abstract-mech document requires that concrete ConEx specifications
discuss the audit function explicitly, with several requirements for
detail scattered through that document. In particular, it asks for a
discussion of how the concrete protocol defends against a set of
likely attacks against the audit function. This document is silent,
and I think a side-effect of being processed in parallel with
tcp-modifications, and suspect most of the thinking on meeting the
requirements for discussing the audit function has concentrated there.
However, nothing in _this_ document restricts its use to other
transport extensions that have talked about these things. Should
there be a statement that this option must not be used unless by a
transport extension that's discussed how to use it? If not, then
shouldn't this document talk about what happens if there's no
transport header below to inform audit function behavior?
Minor issues:
m1) Figure 1 isn't right. I think what you want is:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |X|L|E|C| res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
m2) There is confusion in two places in the document where you discuss
where to put the CDO (at the end of page 5 and the end of page 7). The
current text says the option MUST be the first option in whatever
destination options block it appears in. That seems problematic. What
if some other option also declares it MUST be the first option? I
wonder if instead of trying to say "must be the first option in the
block" you are trying only to say "If you use a CDO, use it in the
destination options block that comes before an AH block, not the one
that might come after".
m3) Third paragraph of section 6: Should the last sentence end with
"in a given stream." ?
Nits/editorial comments:
Introduction: Should "Due to space limitation" be "Due to space
limitations in the IPV4 header"?
Section 4: Right after the definition of Reserved, there is a line
that says "foo". What should it say instead?
I noticed just after "foo" it says:
All packets sent over a ConEx-capable TCP connection or belonging to
the same ConEx-capable flow MUST carry the CDO.
I think this was meant to say:
All packets belonging to the same ConEx-capable flow (e.g. sent over
the same ConEx-capable TCP connection) MUST carry the CDO.
Thanks again, particularly for revealing the huge gap we had missed.
Regards
Bob
The last sentence on page 6: I don't think it's the network node that
you are saying must be aware. Perhaps you mean designers of network
nodes?
At the top of page 7, you have "They MAY log". You shouldn't use a
2119 MAY here - it's not part of the protocol. Similarly, in section
6, "MAY compare the two, and MAY log" should not use 2119.
First paragraph of section 6: "natively" is not clear. Perhaps
replacing "will not natively copy" with "will not normally copy"?
Second paragraph of section 6: I suggest replacing "ignore any
CDO" with "ignore any CDO in the outer header".
Consider moving the description of the bits in the option type field,
particularly the chg bit, earlier in the document. Right now, the
first mention is in the security consideration section, and most
of the definition doesn't happen until the IANA considerations.
It would help if it were clear what that bit was going to be before
you ever mention AH.
_______________________________________________
conex mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/conex
--
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
