Re: [conex] Review of draft-ietf-conex-abstract-mech-06

[Bob Briscoe <[e-mail]>]

Matt,

A few rejoinders inline...

At 07:02 06/06/2013, Matt Mathis wrote:
>Follow up to Mirja's and Bob's comments, 
>inline.   most are "Looks Good to Me".
>
>
>On Tue, Jun 4, 2013 at 12:12 PM, Bob Briscoe 
><<mailto:[e-mail]>[e-mail]> wrote:
>At 15:12 04/06/2013, Mirja Kühlewind wrote:

[snip]

>2) Section 'Overview' is very long (for an overview). Don't know if per-flow
>state, byte vs. packet and partial deployment needs to be discussed here.
>Maybe think about a subsection on discussion points instead (which could also
>include some discussion on attacks against the audit). On the other hand
>potentially introduce briefly the credit concept here.
>
>
>Flow-state:
>I'd be happy to move most of the first half of 
>the para into an introductory paragraph under 
>S.5.4. "Policy Devices" about flow-state. That 
>would leave just a high level sentence about the 
>trade-off in the introduction, with a pointer to S.5.4. Something like:
>
>"  One of the design goals of the ConEx protocol is that the important
>    policy mechanisms can be implemented for heavily aggregated traffic in the
>    core of the Internet per logical link 
> without per flow state (see Section 5.4).
>    However, the price to pay for avoiding flow state for policy is flow state
>    to audit ConEx signals, which is discussed further in Section 5.5.  In
>    summary: i) flow state for auditing does not require route pinning;
>    ii) auditing at the edges, with limited per flow state, enables
>    policy elsewhere, including in the core, without any per flow state.
>
>"
>
>
>I would make the 2nd part even simpler  "A 
>suitable auditing design enables policy 
>elsewhere, including the core, without any per flow state".

[BB]: Not sure where you intend 'the 2nd part' to 
start. I'd like some residual hint left in the 
Intro that we don't need route pinning. How about:

"  One of the design goals of the ConEx protocol is that the important
    policy mechanisms can be implemented for heavily aggregated traffic in the
    core of the Internet per logical link without 
per flow state (see Section 5.4).
    However, the price to pay for avoiding flow state for policy is flow state
    to audit ConEx signals, which is discussed further in Section 5.5.  In
    summary, a suitable edge-based auditing 
design using soft per-flow state enables
    policy elsewhere, including the core, without any per flow state.
"

Also, I forgot to address Mirja's request to move 
most of the byte-pkt text from the Intro into the 
body. I pushed for that before, so I'll leave you 
to argue if you don't agree. While, if you do 
agree, you can suggest what to leave, and what to move.

>  5) Maybe address briefly how to handle 
> ConEx-not-Marked and not ConEx-capable
>packets (not only for partial deployment but also in regular operation). They
>need to be limited somehow as well, otherwise a sender can easily cheat by
>sending ConEx-not-Marked. And this has to be done by the policer (and not the
>audit though).
>
>
>I think you mean solely Not-ConEx.
>(ConEx-Not-Marked means Conex-enabled but not 
>marked - this highlights that we haven't defined 
>that word well; Section 4.5. defines it with the 
>same meaning as before, but it hasn't been defined before.).
>
>There is a para about this in S.6, starting "A 
>network operator can create incentives for 
>senders to voluntarily reveal ConEx information. ..."
>
>Nonetheless, that in a bullet about senders, so 
>I would be happy to write something more 
>specific in the section on policy devices, which 
>is where this is more relevant. Also, a very 
>simple sentence under audit, saying it ignores Not-ConEx.
>
>
>  I want to think about this one more: propose something more specific.
>
>8) Section 5.5 doesn't give any advise how to handle encrypted TCP for loss
>estimation.
>
>
>Today essentially all encryption is above TCP, 
>because IPsec does not play nice with NATs, and 
>I can't see that changing.    Furthermore there 
>is already quite a menagerie of FW class devices 
>that refuse non-TCP and TCP with nonsensical 
>sequence numbers (to thwart various injection 
>attacks).  We already encrypt nearly all of our 
>payload, except some services and some countries.
>
>It feels like this is important from pedantic 
>completeness standpoint but not much of an issue in the real world.

[BB]: Mirja's point was we don't say what can (or 
cannot) be done with encrypted TCP. I don't think 
she's looking for an evasive answer like "There 
probably isn't much encrypted TCP". I don't 
believe we should base protocol design on 
predictions of the future traffic mix. We should 
make the admission clear that we can't do 
anything with encrypted TCP (and similarly multipath is tough).


>Let me think about this before you reorganize the section.
>
>Perhaps this would be solved by moving Generic 
>loss auditing before the more specific loss 
>auditing bullets, because it basically says 
>generic isn't possible. Then ending generic loss 
>auditing with a linking sentence saying 
>"Nonetheless, loss auditing is possible in the following specific scenarios."
>
>In hindsight, we now have another way of doing 
>generic loss auditing, which I'd like to add. A 
>network can tunnel traffic and turn on ECN in 
>the outer, just for the length of the tunnel. 
>Then, by RFC6040, the tunnel egress will drop 
>any ECN-marked packets with an the inner showing 
>that the e2e transport is Not-ECN-capable.
>
>So, an auditor at the tunnel egress will see all 
>the congestion signals from within the network 
>as ECN, then the tunnel egress will transform 
>ECN into drop for those transports that don't support ECN.
>
>
>This isn't really audit is it?  What happens if 
>a transport says it can do ECN, but just ignores it?

[BB]: Audit checks whether the transport receiver 
and/or sender expose the congestion they see 
(then policy devices can rely on this exposed 
info to police anyone ignoring congestion - if that's the policy).

The tunnel turns on ECN support in the outer to 
ensure any congestion at intermediate nodes can 
all be exposed to the auditor as ECN marks not 
losses. It works for all packets (even DNS), 
whatever the e2e transport says about ECN support (in the inner).

Nonetheless, for those transports that say they 
don't support ECN, the tunnel egress converts all 
congestion signals into drops (after the auditor 
has read the ECN signals). This 'just works' if 
the tunnel complies with RFC6040.

>
>9) Section 5.5.1 introdues the credit concept. Not sure if the meaning of
>credits is well enough specified here. My personal option is that credits
>should somehow get invalid (at some point in time). This is left open in the
>current text.
>
>
>I think we need to agree before we can talk 
>about writing down what we agree...
>
>
>I think that abstract-mech needs to embrace 
>*both*, explicitly if not implicitly.  I need to 
>think about this some more, but I suspect that 
>it means we have unnecessarily over constrained audit here.

[BB]: We need to allow multiple experiments at 
this experimental stage. But ultimately, sources 
will need to unambiuously know what Credit means, 
so they know how much to introduce and when.



>Rather than thinking of Credit expiring after a 
>time, one can think of the combination of recent 
>Re-Echo signals and earlier Credit signals 
>keeping the Credit state fresh within a flow. As 
>long as you've sent Credit before a round of 
>congestion, then if you send Re-Echo afterwards 
>the Auditor can switch it round as if you sent 
>the Re-Echo before and the Credit after.
>
>So, when the Auditor holds Credit, it allows up 
>to that amount of Re-Echo to be considered as 
>having been sent before the congestion, rather 
>than after. Then, as it switches the Re-Echoes 
>back in time, it switches the Credits forward, so they always stay recent.
>
>Credit is primarily a mechanism to ensure the 
>sender has to suffer some cost before it is 
>trusted to pay back some cost. Credit doesn't 
>need to degrade over time if the cost to the 
>sender of introducing credit doesn't degrade over time.
>
>Does this move us forward, or do you still 
>disagree? If so, I suggest a new thread would be useful.
>
>
>This is probably correct, but I really don't think it belongs in A-M.

[BB]: I don't think it should either. This is a 
discussion with Mirja, rather than a proposal for text.

>
>Except for the couple of items for more thought, dig in!

Looking forward to the rest.

CHeers


Bob


>Thanks,
>--MM--
>The best way to predict the future is to create it.  - Alan Kay
>
>Privacy matters!  We know from recent events 
>that people are using our services to speak in 
>defiance of unjust governments.   We treat 
>privacy and security as matters of life and 
>death, because for some users, they are.

________________________________________________________________
Bob Briscoe,                                                  BT