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

[Bob Briscoe <[e-mail]>]

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]>[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]
>web: www.ikr.uni-stuttgart.de
>-------------------------------------------------------------------

________________________________________________________________
Bob Briscoe,                                                  BT