Re: [conex] Fwd: Review: draft-ietf-conex-destopt-06

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Thu, 14 August 2014 16:51 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
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 F01041A08B6 for <conex@ietfa.amsl.com>; Thu, 14 Aug 2014 09:51:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.558
X-Spam-Level:
X-Spam-Status: No, score=-4.558 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, T_TVD_FUZZY_SECURITIES=0.01] 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 m6rDhkK8bSf6 for <conex@ietfa.amsl.com>; Thu, 14 Aug 2014 09:51:44 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 944011A0747 for <conex@ietf.org>; Thu, 14 Aug 2014 09:51:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0D170D9303; Thu, 14 Aug 2014 18:51:37 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3Jqh3B8sbrdu; Thu, 14 Aug 2014 18:51:36 +0200 (MEST)
Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id B5764D9302; Thu, 14 Aug 2014 18:51:36 +0200 (MEST)
Message-ID: <53ECE917.6000803@tik.ee.ethz.ch>
Date: Thu, 14 Aug 2014 18:51:35 +0200
From: =?windows-1252?Q?Mirja_K=FChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Bob Briscoe <bob.briscoe@bt.com>
References: <201408121058.09210.mirja.kuehlewind@ikr.uni-stuttgart.de> <53EA6068.6090100@tik.ee.ethz.ch> <201408131906.s7DJ6V2s029587@bagheera.jungle.bt.co.uk> <53ECE6C9.40300@tik.ee.ethz.ch>
In-Reply-To: <53ECE6C9.40300@tik.ee.ethz.ch>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/conex/_HBG4ExEr1-Gw_FRrGsL2u5LMQA
Cc: Carlos Ucendo <ralli@tid.es>, ConEx IETF list <conex@ietf.org>
Subject: Re: [conex] Fwd: Review: draft-ietf-conex-destopt-06
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: <http://www.ietf.org/mail-archive/web/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, 14 Aug 2014 16:51:47 -0000

Hi again,

sorry; pressed sent without being done... see further below....

On 14.08.2014 18:41, Mirja Kühlewind wrote:
> Hi Bob,
>
> see inline
>
>>>> * Added subsection of intro on experiment goals: criteria for success
>>>> and duration
>>>
>>> I believe most of the text actually should go in the tcp mods draft. I
>>> not sure if there is a common sense in the mean time to have such a
>>> section in very exp document. But if not I would rather not have it in
>>> this document because I'm not sure how to define if an experiment was
>>> successful. If fact the CDO is the only approach at could fulfill our
>>> requirements, so there is no other  option. And if the coding itself
>>> with the four bits is useful or not, is not really a question of this
>>> document, but amybe more of the whole mechanism (incl. auditing and
>>> policing) or maybe the tcp mods document...?
>>
>> The solution to this would be to refer to one doc that has the expt
>> goals. However, I believe each doc can be seen as a separate piece of a
>> bigger expt.
>> * The expt that this doc describes is a choice of encoding (see below -
>> there are other choices).
>> * The main expt that the TCP doc describes is how to set credit.
> So is it okay if I just add one sentence in the intro (instead of having
> an own section):
>
> "This specification is experimental to allow the IETF to assess whether
> the decision to implement the ConEx signal as a destination option
> fulfills the requirements stated in this document, as well as to
> evaluate the proposed encoding of the ConEx signals."
>
> Does this work for you?
>
>>>> ==Requirements==
>>>>
>>>> * Referred to abstract-mech for requirements, explained that it would
>>>> be hard to satisfy them all, and explained which one wasn't satisfied
>>>> (visibility in outer), referring to section on fast-path performance.
>>>
>>> Took over some of your text at the beginning of this section (and also
>>> reused some text we already used to have there).
>>>
>>> Do you really think that the two requirements you've added are needed?
>>> Because both basically say that the ConEx coding should encode the
>>> Conex signal, which is, from my point of view, the whole purpose of
>>> this document.
>>
>> Perhaps you're too close to ConEx. If these reqs hadn't been defined in
>> abstract-mech, you wouldn't know what "the ConEx signal" was. These reqs
>> say what the component parts of the ConEx signal are. It could say you
>> need separate signals for ECN-credit and loss-credit. It could say ConEx
>> nodes must successfully negotiate ECN (then re-ECN would be a solution).
>>
>> The alternative is to refer to abstract-mech for all the requirements
>> and not list them here, or list the reqs in abstract-mech that are
>> relevant to the network layer encoding.
>>
>>> I do have the feeling that the other requirements listed here are on a
>>> slightly different level because they are more related to deployment
>>> issues.
>>
>> You could say that (but you don't). That's why it seemed odd that you
>> listed some requirements, but not the basic ones.
> Okay the intent of these requirements was not to rephrase what is
> already written down in the abstract-mech because I assume that people
> reading this document do not really care why the conex signals look as
> they do but just want to know which conex signals are there (and what
> there meaning is).
> The reason to have the requirement listed is simply to justify the
> potentially awkward choice to encode them in a destination option.
>
> I now have the following text:
>
> "A set of requirement for an ideal concrete ConEx wire protocol is given
> in <xref target="I-D.ietf-ConEx-abstract-mech"/>. In the ConEx working
> group is was recognized that it will be difficult to find an encoding in
> IPv6 that satisfies all requirements. The choice in this document to
> implement the ConEx information in a destination option satisfies most
> of those requirements, briefly summarized below:"
>
> + I added your paragraph on visibility at the end.
>
> Okay?
>
>>> And regarding tunneling: you are right that we need to give more
>>> advise on tunneling. Shouldn't we just say that one MUST copy the
>>> inner ConEx Option to the outer header (to solve the visibility
>>> problem)?
>>
>> You can't say MUST, because IPv6 dest opts are meant to be e2e only, so
>> no IPv6 tunnel currently even understands what a dest opt is, let alone
>> copies any dest opt to the outer. A MUST would ring huge alarm bells in
>> the vendor community.
>>
>> I added it as a MAY, purely because it might be considered a performance
>> optimisation. I'm still worried about the size of the alarm bells that
>> will ring. It could prevent this draft progressing thru the IESG. Suresh
>> will know best how this might be received in the IESG.
> Okay, got it; see further below...
>
>>
>>
>>>> ==CDO==
>>>
>>>> * Specified precisely which IP header is included in the byte count.
>>> So you suggest to not include any options?
>>
>> I didn't say that, did I? If the wording I used is ambiguous, pls fix it.
>>
>>> Why? I'd say you either include all bits because all of them
>>> contribute to congestion, or none of the IP header bits because that's
>>> just the overhead you can't avoid if you what to send anything. Also
>>> of course you can generate a larger percentage of overhead if you send
>>> smaller packets.
>>
>> That's why I think it is reasonable to include the IP header (and its
>> options) that immediately encapsulates the ConEx dest opt.
> Okay I misread your text.
>
> I just though, if you detect a CDO in the header you are currently
> looking at, you will simply look at the playload length and next hop
> fields of this header and than add another 40 bytes for the header
> itself. But in fact that might be wrong if you have another IP header
> encapsulated in the payload... so what is actually the right number of
> bytes here?
>
> I was about to write the following but I'm not sure if that is actually
> write and/or clear:
> "... IP packet (including the IP header that carries the CDO and all
> associated options)..."?
> That just doesn't say if you should look what the next header is and
> subtract all other IP header bytes you can find. Is this needed?
>
>
>>>> * Suggested deleting example of Not-ConEx-capable packets (see
>>>> separate thread to conex-tcp-modifications authors about TCP pure
>>>> ACKs).
>>> I can remove the example but not sure why you are suggesting this. If
>>> you actually imply that the X bit should never be zero that we have to
>>> discuss if the X bit is needed at all.
>>
>> I have never thought the X flag was needed. There's probably some email
>> on the list somewhere in the past from me that says that.
>>
>> As I put in one of the comment bubbles:
>> "The only need I can see for the X-flag is if
>> the Reserved field gets used in future for
>> something in addition to ConEx. Then there
>> would be a need to identify packets that
>> are not ConEx-capable but still carry the
>> CDO option (for the new reason)."
>>
>> Can anyone think of a use for the X flag?
> I thought the X bit unset means: I'm a ConEx aware sender and i want to
> follow the rules but I don't have any feedback for this (control) data
> so I'm unable to give you useful ConEx information and if you use this
> packet for your estimation of the current congestion level, you might
> underestimate it.
>
> Doesn't that make sense...?
>
>
>>>> ==Fast-path==
>>>>
>>>> * CDO as first destination option: changed from MUST to SHOULD (with
>>>> an example of when not to).
>>> I believe this really needs to be a MUST. I know that might restrict
>>> the use of ConEx with potential other options that might have the same
>>> requirement (for different reasons). But if you don't put a MUST here,
>>> you cannot implemented the suggested way in the fast path.
>>
>> A SHOULD still means it will be the first option in all current
>> implementations. However, I suggest a SHOULD, precisely because
>> performance reasons are not absolute, so they don't require a MUST. If
>> another dest opt cannot work at all unless it is first, that would be a
>> valid reason for CDO coming second, because it still works, it's /just/
>> slower.
>>
>> The IESG will (rightly) be very wary of any draft that says an option
>> MUST be the first option.
>>
>> I suggested the following text after this: "(This is not
>> stated as a 'MUST', because some future destination option might need to
>> be placed first for functional rather than just performance reasons.)"
> So our fast path implementation must simply assume that there is no CDO
> in case it cannot find it as the first option. Otherwise all non-ConEx
> packets would need to go to the slow path to make sure there is no ConEx
> option. That means to me that this must be a MUST...?
>
>
>>>> ==IPsec compatibility==
>>>>
>>>> * Suggested ConEx counts the AH header, and the outer tunnel mode
>>>> header, with reasoning.
>>> Yes, need to be more precise. Will add.
>>
>> This one wasn't just clarity. I've actually contradicted what was said,
>> so pls make sure there wasn't a good reason for why it was like it was.
>>
>> I was most concerned about suggesting this change, because it was the
>> only one that caused a technical difference.
> Ohh, I didn't read your comments carefully and was just looking at the
> text changes... this whole accounting is a mess :-(
> Maybe we should only account the IPv6 header itself and the destination
> options...?
>
> Moreover, isn't this here the same case than with tunneling in general.
> Only if the node that does the encapsulation is ConEx-aware it can copy
> the CDO, otherwise it will be not visible anymore.
>
> So this should either be a should, or we have to say something like: if
> the node is ConEx-aware is MUST copy the CDO...?
And then we can the same thing for tunneling in general...?

>>
>>>> * Suggested optional copying of CDO to outer, but also a simpler 'Do
>>>> not copy CDO' alternative.
>>> I don't really get you SHOULD NOT but MAY here...?
>>
>> See earlier. Tunnels don't normally understand dest opts, which is why I
>> said SHOULD NOT. But the MAY is a performance optimisation. Am I helping?
Okay, understood. But why SHOULD NOT? Isn't it sufficient to say MAY...? 
(or even MUST/SHOULD if ConEx-aware...?)

Mirja


>>>> ==Security Considerations==
>>>>
>>>> * Added lots, all pointers to where security issues are discussed in
>>>> other places (which is what security directorate reviewers need).
>>> Okay I can add that if you think it's necessary (I would say it's just
>>> redundant, but you be might right that it just helps the sec dir).
>>
>> It's not always obvious which aspects relate to security. Especially
>> when the security is structural rather than crypto. So I think these
>> sentences are useful to sec dir.
>>
>>
>>>> ==IANA==
>>>>
>>>> * I think the act bits need to be 00 not 10 to avoid ConEx packets
>>>> being dropped by non-ConEx nodes (including by non-ConEx receivers)?
>>>> But I'm willing to be corrected.
>>> I agree; Will ask Suresh why he has put a 10 though.
>>
>> Yes, he's the right guy to check with.
>>
>>
>> Bob
>>
>>
>>> Thanks,
>>> Mirja
>>>
>>>>
>>>>
>>>> Regards
>>>>
>>>>
>>>>
>>>>
>>>> Bob
>>
>> {Note 1}
>> For anyone watching on the list, the tentative idea that Mirja has
>> reminded me of is documented in 11.3.1 of my PhD thesis entitled "Covert
>> Markings as a Policer Signal".
>>
>> The potential problem: A ConEx policer punishes punishment. If a
>> congestion policer starts dropping packets because the user has
>> contributed excessively to congestion, in subsequent rounds the user has
>> to re-echo 'L' markings for the policer drops as well. This can drive
>> the policer further into 'debit'. This might make it difficult for the
>> user to get out of trouble once she's started getting into trouble.
>>
>> The basic idea was that when a congestion policer drops packets (because
>> the user is causing more congestion than her allowance), it will also
>> remove ConEx markings. Then (if there is some way for the receiver to
>> feed this back), the sender knows not to send more ConEx marks because
>> these aren't congestion drops, they are policer drops.
>>
>> We didn't that double punishment made it hard to get out of trouble in
>> any policer experiments so far, so let's not allow for a possible
>> solution to a problem that we probably don't even have. The current crop
>> of ConEx drafts are experimental anyway. If this problem does surface,
>> then we can reconsider.
>>
>>
>>
>>
>>
>> ________________________________________________________________
>> Bob Briscoe,                                                  BT
>>
>

-- 
------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Communication Systems Group
Institute TIK, ETH Zürich
Gloriastrasse 35, 8092 Zürich, Switzerland

Room ETZ G93
phone: +41 44 63 26932
email: mirja.kuehlewind@tik.ee.ethz.ch
------------------------------------------