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

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