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

Bob Briscoe <bob.briscoe@bt.com> Thu, 13 June 2013 16:19 UTC

Return-Path: <bob.briscoe@bt.com>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF2A21F8904 for <conex@ietfa.amsl.com>; Thu, 13 Jun 2013 09:19:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.901
X-Spam-Level:
X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ne4DQFe0zwOu for <conex@ietfa.amsl.com>; Thu, 13 Jun 2013 09:19:31 -0700 (PDT)
Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id C2C5E21F9A59 for <conex@ietf.org>; Thu, 13 Jun 2013 09:19:30 -0700 (PDT)
Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 13 Jun 2013 17:19:29 +0100
Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 13 Jun 2013 17:19:28 +0100
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.342.3; Thu, 13 Jun 2013 17:19:23 +0100
Received: from BTP075694.jungle.bt.co.uk ([10.111.112.140]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r5DGJLkb016461; Thu, 13 Jun 2013 17:19:21 +0100
Message-ID: <201306131619.r5DGJLkb016461@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 13 Jun 2013 17:19:20 +0100
To: Mirja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <201306091634.19158.mirja.kuehlewind@ikr.uni-stuttgart.de>
References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <CAH56bmA4Vbk_9=71RZL=MJrMt1420pj4fOrXES0pS9nVMcMbhw@mail.gmail.com> <201306062359.r56NxFrm020485@bagheera.jungle.bt.co.uk> <201306091634.19158.mirja.kuehlewind@ikr.uni-stuttgart.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Cc: ConEx IETF list <conex@ietf.org>
Subject: Re: [conex] Review of draft-ietf-conex-abstract-mech-06
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/conex>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jun 2013 16:19:45 -0000

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:bob.briscoe@bt.com>bob.briscoe@bt.com> 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: +49(0)711/685-67973
>email: mirja.kuehlewind@ikr.uni-stuttgart.de
>web: www.ikr.uni-stuttgart.de
>-------------------------------------------------------------------

________________________________________________________________
Bob Briscoe,                                                  BT