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

[Matt Mathis <[e-mail]>]

I am buried again - I can't do this justice, nor is it fair for me to hold
it up.  You may proceeded.

Please do the reordering last (or at least late) and capture a copy of the
.xml for me just before the reordering so I can easily see the independent
changes without the confusion that chaff that the reordering will introduce.

If something makes me too uncomfortable, I will have to argue the changes
after the fact.

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.


On Thu, Jun 13, 2013 at 9:19 AM, Bob Briscoe <[e-mail]> wrote:

> Mirja,
>
> Sorry this thread got split up. I haven't responded to any of you points
> in the other part, because I would just be repeating what I said - I'd like
> to hear Matt's responses instead.
>
> Responses to this part inline...
>
>
> At 15:34 09/06/2013, Mirja Kuehlewind wrote:
>
>> Hi Bob, hi Matt,
>>
>> see inline....
>>
>> On Friday 07 June 2013 01:57:26 Bob Briscoe wrote:
>> > 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]>b**[e-mail] <[e-mail]>>
>> wrote:
>> > >At 15:12 04/06/2013, Mirja Kühlewind wrote:
>>
>
> [snip]
>
>  > >  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.).
>>
>> No, I meant also ConEx-Not-Marked because even when you support ConEx you
>> could still send all your packets with ConEx-Not-Marked and the policer
>> and
>> the audit will not do anything...
>>
>
> [BB]: ConEx-Not-Marked are ConEx enabled, they just say "there is no
> re-echo". So if, there is congestion but the source only sends
> ConEx-Not-Marked, it is suppressing re-feedback of the congestion, and the
> audit function will squash the flow.
>
> This is the whole point of the audit function. So perhaps I am
> misunderstanding your point?
>
>  > >
>> > >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.
>>
>> [Mirja]: Okay.
>>
>
> [BB]: Matt, no time to write text at the mo (about to take a week off, so
> I'm having to do the week's extra work beforehand). I planned to do this
> when we add the edits.
>
>
>
>  > >
>> > >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).
>>
>> Eventhough encrypted TCP is not very common today, if this is the most
>> simple
>> way to cheat ConEx, more ConEx deployment could incentivize to send more
>> encrypted packet. Thus there has to be a way to handle this. Maybe we can
>> say
>> something like: "If the TCP header information is encrypted and loss-based
>> Conex signaling is used, a policer should threat this traffic like not
>> ConEx-capable as auditing is not possible."
>>
>
> [BB]: Superficially, that seems a good sentence. But it wouldn't apply in
> the cases described where audit can be done against losses. So I would
> append:
>
> ..."unless the operator knows it is using one of the techniques described
> in Section xxx to audit against losses".
>
>
>
>  >
>> > >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."
>>
>> I believe reordering would also help.
>>
>
> [BB]: Matt, have you pondered?
>
> Regards
>
>
>
> Bob
>
>
>  > >
>> > >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.
>> > >
>> That's a good idea. I would support to put this in the draft.
>>
>> > >
>> > >This isn't really audit is it?  What happens if
>> > >a transport says it can do ECN, but just ignores it?
>>
>> It gets more and more ECN markings and will sooner or later get policing
>> drops. That exactly the case were we need ConEx!
>>
>> >
>> > [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.
>>
>> I'll send a new main on crediting...
>>
>> >
>> > >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
>>
>>
>>
>> --
>> ------------------------------**------------------------------**-------
>> Dipl.-Ing. Mirja Kühlewind
>> Institute of Communication Networks and Computer Engineering (IKR)
>> University of Stuttgart, Germany
>> Pfaffenwaldring 47, D-70569 Stuttgart
>>
>> tel: [phone]
>> email: [e-mail]-**stuttgart.de<[e-mail]>
>> web: www.ikr.uni-stuttgart.de
>> ------------------------------**------------------------------**-------
>>
>
> ______________________________**______________________________**____
> Bob Briscoe,                                                  BT
>