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

[Bob Briscoe <[e-mail]>]

Mirja,

At 19:43 12/08/2014, Mirja Kühlewind wrote:
>Hi Bob,
>
>thanks for your review. Please see comments inline.
>
>(Please also note my new email address...)
>
>
>
>>----------  Forwarded Message  ----------
>>
>>Subject: Review: draft-ietf-conex-destopt-06
>>Date: Tuesday 12 August 2014, 01:26:01
>>From: Bob Briscoe <[e-mail]>
>>To: Suresh KRISHNAN <[e-mail]>, Mirja KUEHLEWIND
>><[e-mail]>, Carlos Ucendo <[e-mail]>
>>CC: ConEx IETF list <[e-mail]>
>>
>>Suresh, Mirja, Carlos,
>>
>>As promised at the authors mtg in Toronto, I have reviewed
>>draft-ietf-conex-destopt-06.
>>
>>At this late stage, I prefer to suggest text, not just criticise. But
>>pls don't take this to mean I expect you to use my suggested text.
>>
>>I had a lot of nits, so I thought it easiest to deal with these by
>>annotating the draft (using MS Word, but also supplied as PDF output):
>><http://www.bobbriscoe.net/projects/conex/draft-ietf-conex-destopt-06-rvw-bb.doc>
>><http://www.bobbriscoe.net/projects/conex/draft-ietf-conex-destopt-06-rvw-bb.pdf>
>>
>>I have also included all my more substantial concerns in the above
>>annotations - highlighted in yellow.
>>
>>I've listed the major items here, as hooks if mailing list discussion
>>is needed on any of them (but see the annotations for detail before
>>discussing).
>>
>>My most controversial disagreement is around IPsec compatibility,
>>which we ought to spin into a separate thread if you want to discuss/argue.
>>
>>Most of the other additions are because conex-abstract-mech says a
>>concrete protocol spec has to address specific aspects, which weren't
>>addressed.
>>
>>==Intro==
>>* Added scoping in Intro (solely wire protocol; specific transport
>>protocol specs will determine when specifically to set each marking,
>>e.g. conex-tcp-modifications)
>
>k. I added something to the previous paragraph 
>because this was already intended to say that 
>this document is mainly for people that 
>implement a network node and want to do something with ConEx.

Surely this doc is just as important for the 
sender, esp as a generic definition of the ConEx 
protocol for all transport protocols, not just TCP.



>>* Standards Track -> Experimental
>Yes, thanks.
>
>>* 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.


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


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


>>==CDO==
>
>The current version says 'immediate nodes SHOULD 
>only read the CDO field' which you changed to 
>'MUST forward unaltered'. This 'SHOULD' was 
>actually a SHOULD because you (!) came up with 
>the idea that a policer should be able to remove 
>ConEx markings instead of dropping immediately.
>I don't think and never thought that this is a 
>good idea because it changes the ConEx 
>information for other nodes later on the path. 
>If you think that is definitely not needed 
>anymore, I'm happy to have a MUST there.

OK, you got me.
Let's make this a MUST.

I forgot about what my other personality thought 
when I visited you back in 2010;)
My currently dominant personality isn't convinced 
by those rather tentative ideas.{See Note 1}


>>* For any text about ignoring invalid fields, explicitly said that
>>intermediate nodes MUST NOT normalise. Also, specified to treat
>>packets with invalid fields like a non-ConEx-capable packet.
>
>ACK, will add your text here.
>
>>
>>* 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.



>>* 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?




>>==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.)"




>>==Config & Management==
>>
>>* Added section, mainly to say there is no config & mgmt (required by
>>abstract-mech).
>I don't thing that the statement about being 
>able to switch ConEx on and off belongs in this document (but in tcp mods).

Good point.

>I can add one sentence on warnings or error 
>messages if really needed, but I don't think that needs an own section.

Pls do. I was just making sure all the reqs in abstract-mech were satisfied.



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



>>* Suggested the section is restructured because I believe the
>>visibility problem is not related to tunnel mode, but only to ESP in
>>tunnel mode.
>I agree that tunneling was not addressed well.
>
>>
>>* Added a para about the possibility of implementing a ConEx proxy
>>(without breaking e2e authentication).
>ACK will add.
>
>>
>>==Tunnelling==
>>
>>* Section added, to generalise from just IPsec to any IP-in-IP
>>tunnelling (particularly relevant to mobile scenarios).
>If we have a separate section on tunneling. 
>Shouldn't we have tunning first and then IPSec...?

Could do, I guess.



>>* 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?



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