Re: [conex] Gen-art LC review: draft-ietf-conex-destopt-09

Bob Briscoe <ietf@bobbriscoe.net> Thu, 01 October 2015 17:27 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D001B2DFC; Thu, 1 Oct 2015 10:27:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1q4eZSxqqZmQ; Thu, 1 Oct 2015 10:27:23 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BFD71B2E1F; Thu, 1 Oct 2015 10:27:22 -0700 (PDT)
Received: from 1.83.200.146.dyn.plus.net ([146.200.83.1]:47550 helo=[192.168.0.16]) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from <ietf@bobbriscoe.net>) id 1ZhhdX-0005lg-Ld; Thu, 01 Oct 2015 18:27:20 +0100
To: Robert Sparks <rjsparks@nostrum.com>, =?UTF-8?Q?Mirja_K=c3=bchlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>
References: <55DE1F65.5070106@nostrum.com> <56014D94.9070002@tik.ee.ethz.ch> <56099700.6050004@nostrum.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <560D6CF6.4050700@bobbriscoe.net>
Date: Thu, 1 Oct 2015 18:27:18 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <56099700.6050004@nostrum.com>
Content-Type: multipart/alternative; boundary="------------040101010303080407010304"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
Archived-At: <http://mailarchive.ietf.org/arch/msg/conex/NUtU0aOjMUeLgRObFqzFE3X0-es>
Cc: General Area Review Team <gen-art@ietf.org>, conex@ietf.org, draft-ietf-conex-destopt@ietf.org
Subject: Re: [conex] Gen-art LC review: draft-ietf-conex-destopt-09
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/conex/>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2015 17:27:28 -0000

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.

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.

>
>> 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.


>>
>> 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.
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
> conex@ietf.org
> https://www.ietf.org/mailman/listinfo/conex
>
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/