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

Mirja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de> Sun, 09 June 2013 14:34 UTC

Return-Path: <mirja.kuehlewind@ikr.uni-stuttgart.de>
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 49E6821F8CDD for <conex@ietfa.amsl.com>; Sun, 9 Jun 2013 07:34:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 IuvjyeM89KwF for <conex@ietfa.amsl.com>; Sun, 9 Jun 2013 07:34:23 -0700 (PDT)
Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id D584D21F8B04 for <conex@ietf.org>; Sun, 9 Jun 2013 07:34:22 -0700 (PDT)
Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id D5DD860280; Sun, 9 Jun 2013 16:34:19 +0200 (CEST)
Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id A466C6027E; Sun, 9 Jun 2013 16:34:19 +0200 (CEST)
From: Mirja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de>
Organization: University of Stuttgart (Germany), IKR
To: Bob Briscoe <bob.briscoe@bt.com>
Date: Sun, 09 Jun 2013 16:34:19 +0200
User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316)
References: <201306041612.25493.mkuehle@ikr.uni-stuttgart.de> <CAH56bmA4Vbk_9=71RZL=MJrMt1420pj4fOrXES0pS9nVMcMbhw@mail.gmail.com> <201306062359.r56NxFrm020485@bagheera.jungle.bt.co.uk>
In-Reply-To: <201306062359.r56NxFrm020485@bagheera.jungle.bt.co.uk>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <201306091634.19158.mirja.kuehlewind@ikr.uni-stuttgart.de>
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: Sun, 09 Jun 2013 14:34:27 -0000

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

Fine with me!

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

Maybe we can have the same approach here. Just leave one sentence saying that 
it is defined in this to count congestion byte-wise and give a reference for 
a later section for the reasoning.

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

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

Okay.

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

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

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