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

[Mirja Kühlewind <[e-mail]>]

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: [phone]
email: [e-mail]
------------------------------------------