Internet DRAFT - draft-wagner-conex-audit

draft-wagner-conex-audit







Network Working Group                                          D. Wagner
Internet-Draft                                   University of Stuttgart
Intended status: Informational                             M. Kuehlewind
Expires: October 10, 2016                                     ETH Zurich
                                                           April 8, 2016


            Auditing of Congestion Exposure (ConEx) signals
                      draft-wagner-conex-audit-02

Abstract

   Congestion Exposure (ConEx) is a mechanism by which senders inform
   the network about the congestion encountered by previous packets on
   the same flow.  Reliable auditing is necessary to provide a strong
   incentive to declare ConEx information honestly.  This document
   defines how the signals are handled by an audit and lists
   requirements for an audit implementation.  This document does not
   mandate a particular design but identifies state and functions that
   any auditor element must provide to fulfill the requirements stated
   in [draft-ietf-conex-abstract-mech].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 10, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Wagner & Kuehlewind     Expires October 10, 2016                [Page 1]

Internet-Draft               ConEx Auditing                   April 2016


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Meaning of the Re-Echo Signals  . . . . . . . . . . . . .   2
     1.2.  Meaning of Credit Signal  . . . . . . . . . . . . . . . .   3
     1.3.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Audit Implementation  . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Placing an Audit Element  . . . . . . . . . . . . . . . .   4
     2.2.  Per Flow State  . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Penalty Criteria  . . . . . . . . . . . . . . . . . . . .   6
     2.4.  Appropriately Penalizing Misbehaving Flows  . . . . . . .   7
     2.5.  Audit start for existing connections  . . . . . . . . . .   7
     2.6.  Handling Loss of ConEx-marked Packets . . . . . . . . . .   8
   3.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   In order to make ConEx information useful, reliable auditing is
   necessary to provide a strong incentive to declare ConEx information
   honestly.  However, there is always a delay between congestion events
   and the respective ConEx signal at the audit.  In
   [draft-ietf-conex-abstract-mech] it is proposed to use credit signals
   sent in advance to cover potential congestion in the next feedback
   delay duration.

   The ConEx signal is based on loss or Explicit Congestion Notification
   (ECN) marks [RFC3168] as a congestion indication.  Following
   [draft-ietf-conex-abstract-mech] (Section 4.4), ConEx signaling has
   to encode ConEx capability, Re-Echo-Loss (L), Re-Echo-ECN (E) and
   credit (C).

1.1.  Meaning of the Re-Echo Signals

   By the Re-Echo-Loss signal a sender exposes to the network that this
   transport has experienced loss very recently.  By the Re-Echo-ECN
   signal a sender exposes to the network that this transport has



Wagner & Kuehlewind     Expires October 10, 2016                [Page 2]

Internet-Draft               ConEx Auditing                   April 2016


   experienced an ECN-CE mark very recently.  For the audit this means,
   that if it detects a loss or an ECN-CE mark for a ConEx-enabled flow,
   for a compliant sender the corresponding Re-Echo-Loss or Re-Echo-ECN
   signals must be observed in the near future.

1.2.  Meaning of Credit Signal

   The Credit signal represents potential for congestion.  A ConEx-
   enabled sender should signal sufficient credit in advance to any
   congestion event.  If a congestion event occurs, a corresponding
   amount of credit is consumed.  If the sender intends to take the same
   risk again, it just must replace this consumed credit as non-consumed
   credit does not expire.

1.3.  Definitions

   Congestion signal
   The occurrence of a packet loss or ECN-CE mark.  We do not consider
   other signs such as increased delay as congestion signals.

   Congestion event
   One or more congestion signals within one RTT.  For today's
   congestion control algorithms all these signals trigger just one
   reaction regardless of their number.

   Connection
   A connection between transport layer endpoints that allows
   bidirectional signalling, e.g. a TCP connection.

   Flow
   The flow of packets of a connection in one direction.  Therefore for
   a flow sender and receiver are well defined.  With regard to ConEx
   auditing, only one flow of any observed connection is audited, see
   Section 2.1.

2.  Audit Implementation

   An audit element shall be a shadow device, i.e. its presence should
   not be detectable for well-behaving senders.  The objective of an
   audit is to verify that senders signal the ConEx information
   correctly and to penalize cheaters.  For this, the audit element has
   to maintain state for any active ConEx-enabled flow.  It may maintain
   appropriate timers to remove flows that have been idle for too long.
   Flows can be audited independently, there are no dependencies.  There
   are two aspects the auditor has to check for each flow:

   o  if the congestion reported using the ConEx mechanism matches the
      congestion actually observed by the receivers and



Wagner & Kuehlewind     Expires October 10, 2016                [Page 3]

Internet-Draft               ConEx Auditing                   April 2016


   o  if sufficient credit marks have been sent to signal the congestion
      risk in advance.

   The audit penalizes a flow if it fails either of these two criteria.

   This document does not mandate a particular design but identifies
   state and functions that any auditor element must provide to fulfill
   the requirements stated in [draft-ietf-conex-abstract-mech].

2.1.  Placing an Audit Element

   An audit element should be placed so that it can observe all
   congestion signals of audited flows.  If both congestion signals, ECN
   and loss, are detected directly, all auditing should take place
   beyond any potential source of congestion, i.e. any potential
   bottleneck, towards the receiver of that flow.  In that case it must
   be placed beyond any potential multi path routing in order to be able
   to identify all packet losses.  For unencrypted TCP and maybe other
   protocols, losses can be easily detected indirectly by monitoring the
   sender's retransmissions, making loss auditing simple and reliable at
   the same time.  Such ConEx-loss audit function must be placed close
   to the sender before any bottleneck where retransmissions might get
   lost.  Therefore it might make sense to have ConEx-loss auditing and
   ConEx-ECN auditing separated.  Nevertheless, this applies for certain
   deployment scenarios only.  Therefore we describe a combined loss and
   ECN ConEx auditor in the following which must be placed close to the
   receiver, beyond any potential bottleneck.

2.2.  Per Flow State

   ConEx auditing must be performed per incoming ConEx-enabled flow, so
   all monitoring, assessment and penalizing is per flow.

   An audit maintains state for each active connection that is updated
   on every packet of that flow.  Such state entry is created when the
   first packet of an unknown flow is observed.  It is deleted when
   either the corresponding connection is closed conforming to its
   transport layer protocol or a timeout expired.  This timeout should
   be chosen to keep false negatives low, i.e. avoiding timing out still
   active flows.  In contrast, false positives, recognizing two flows as
   one, are expected typically being a smaller issue since in most cases
   the sender is the same host and either complies to the protocol or
   not.  We recommend setting this timeout to 60 seconds, a value also
   common e.g. in NAT middle boxes.

   An audit should maintain an RTT_MAX estimation per flow.  This value
   should be as close to the maximum RTT observed by the sender as




Wagner & Kuehlewind     Expires October 10, 2016                [Page 4]

Internet-Draft               ConEx Auditing                   April 2016


   possible.  RTT_MAX must not be chosen smaller than the RTT observed
   by the sender.
   An audit maintains the following variables per flow:

   o  ECN-CE counter (ECN-CE codepoint set)
      When an ECN-CE-marked packet is observed, the counter is increased
      by the number of IP payload bytes.

   o  Loss counter (to be detected by the audit element, see also
      Section 5.5 in [draft-ietf-conex-abstract-mech])
      When a loss is observed, the counter is increased by the number of
      IP payload bytes.

   o  Re-Echo-ECN counter (ConEx signal E)
      When Re-Echo-ECN-marked packet is seen, the counter is increased
      by the number of IP payload bytes.

   o  Re-Echo-Loss counter (ConEx signal L)
      When Re-Echo-Loss-marked packet is seen, the counter is increased
      by the number of IP payload bytes.

   o  Credit state
      Whenever a ConEx-marked packet (Re-Echo-Loss or Re-Echo-ECN) is
      seen and Credit state is greater than zero, the counter is
      decreased by the number of IP payload bytes.  When a Credit-marked
      packet is seen, the counter is increased by the number of IP
      payload bytes.
      Please note that the meaning of the Credit variable differs from
      the other variables: While all other variables are life-time
      counters for the flow and thus grow monotonously, the credit
      buffer just reflects the current signaled credit.  It shrinks and
      grows as congestion is experienced and credit is sent.

   o  RTT_MAX

   o  is_in_penalty_state

   o  p, an EWMA of the congestion rate (loss and/or ECN-CE marks)

   o  x, an EWMA of the rate of Re-Echo-Loss and/or Re-Echo-ECN marks.
      If a packet carries both flags, it must be counted twice.

   o  current drop probability

   If the flow is part of a bidirectional connection, an auditor may use
   information from the return flow in order to define RTT_MAX and to
   detect packet losses.




Wagner & Kuehlewind     Expires October 10, 2016                [Page 5]

Internet-Draft               ConEx Auditing                   April 2016


2.3.  Penalty Criteria

   Generally, a connection is judged on three criteria, one concerning
   exposure of loss, one on exposure of ECN-based congestion signaling
   and one on announcing potential congestion by credit.  A flow is
   considered misbehaving if at least one of the three conditions is
   met.

   A connection is assumed behaving abusive if

   o  the Credit state is zero,

   o  losses observed in the last 2x RTT_MAX period are not exposed by
      Re-Echo-Loss signals, and

   o  ECN-CE signals received in the last 2x RTT_MAX period are not
      exposed by Re-Echo-Loss signals.

   The first criterion should be checked each time a packet of that flow
   towards the destination is observed.  If Credit state is zero,
   is_in_penalty_state is set to true, else set to false.

   The other two criteria shall be checked periodically based on
   timeouts.  The timeout t must be equal or bigger than 2x RTT_MAX.
   There are n timers used and n should be equal or bigger than 2.  To
   do the check, an audit element must store n snapshots of the ECN-CE
   and loss counter.  When the timeout fires, the oldest set of values
   is compared with the current values of Re-echo-Loss and Re-Echo-ECN,
   respectively.  If the saved loss counter is greater than the current
   Re-Echo-Loss counter, or saved ECN-CE counter is greater than the
   current Re-Echo-ECN counter, is_in_penalty_state is set to true, else
   set to false.

   A flow may have not enough data at a time where it needs to send
   ConEx markings and by this fall into misbehaving state
   (is_in_penalty_state is true) during a phase of inactivity.  If the
   sender then restarts sending packets carrying markings for all failed
   criteria, the sender is assumed being well-behaving (in dubio pro
   reo).  Therefore the auditor shall not drop packets which carry all
   required flags, but use the normal penalty on all others.

   For example, if credit is zero and the losses experienced in the
   2xRTT_MAX period are not compensated by sufficient Re-Echo-Loss
   signals, packets carrying both the C and the L flag will not be
   subject of the penalty function.  Nevertheless, packets carrying only
   the C-flag or only the L-flag will.





Wagner & Kuehlewind     Expires October 10, 2016                [Page 6]

Internet-Draft               ConEx Auditing                   April 2016


2.4.  Appropriately Penalizing Misbehaving Flows

   If a flow is detected to misbehave, the audit must start penalizing
   immediately.  The only actually possible penalty is dropping packets
   (with a certain probability).  In order to not incentivize senders to
   simply start new flows when detecting being penalized by an audit
   element, the penalty of a misbehaving flow should be proportional to
   the misbehavior.

   Please note that we require the sender to make sure that any ConEx
   mark will reach the receiver, so it is responsible for timely
   retransmission of any lost ConEx signal.

   The actual drop rate must provide a tangible disadvantage to the
   sender but should not make the connection unusable.  An auditor
   should aim at forwarding not more packets than would have been
   successfully sent with the exposed congestion rate.  Since the
   congestion rate may vary over time, the auditor should use an
   exponentially-weighted moving average (EWMA) for each flow to define
   the congestion rate p.  An auditor should also maintain a EWMA for
   the rate of ConEx-signals (Re-Echo-Loss and Re-Echo-ECN) x.

   TODO: what are appropriate weighting factors alpha in EWMA?

   Assume the packet rate is r and congestion rate is p, but only p-x
   congestion is signaled by the sender using ConEx (c < p).  The audit
   should aim at giving the flow just a rate of r*(x/p).  In other
   words, it should drop (p-x)/p of the traffic, so its drop probability
   should be (p-x)/p.  Therefore the audit just keeps updated x and p,
   and derives the drop probability as (p-x)/p.

2.5.  Audit start for existing connections

   An audit may be started with zero state information on existing
   flows, e.g. due to (re-)started audit or re-routing of flows.  As
   credits will have been sent in advance of congestion events, it is
   possible that no valid credit state is available at the audit when a
   congestion event occurs.  An audit implementation should take this
   into account by ignoring the first criterion for some time.  We
   recommend starting to take credit into account after one minute.

   TODO: is this the right way? this should be enough for the first
   congestion epoch, but disregards credit build up in slow start.  Or
   give some credit on Credit for the start? how much?







Wagner & Kuehlewind     Expires October 10, 2016                [Page 7]

Internet-Draft               ConEx Auditing                   April 2016


2.6.  Handling Loss of ConEx-marked Packets

   ConEx-marked packets will be sent just after the sender noticed a
   congestion signal, so often this sender will just have reduced its
   sending rate.  Thus the loss probability for ConEx-marked packets is
   expected to be lower than for the average flow.  Nevertheless, ConEx-
   marked packets can be lost.  The sender should re-send the ConEx-
   signal.  This induces additional delay for that ConEx-signal but this
   is taken into account by using 2xRTT_MAX as threshold for penalties.
   By that false positives of the auditor misbehavior detection are
   avoided.  Only if two ConEx-marked packets are lost in subsequent
   RTTs, the auditor will penalize a flow of a well-behaving sender.  To
   avoid even these rare cases at least for long-lasting connections,
   the audit may use the fraction of lost packets of that connection to
   allow for the same fraction of loss for each ConEx-mark (E, L and C)
   for a time longer than 2xRTT_MAX.  Nevertheless, the rare event of
   loss of ConEx-marked packets will often cause the audit to penalize
   the flow for one RTT.  We deem this price being acceptable for the
   clean and robust auditor design made possible by making the sender
   responsible for successful delivery of ConEx signals.

3.  Acknowledgements

   We would like to thank Bob Briscoe for his input (based on research
   work of his PhD thesis).

4.  Security Considerations

   Here known / identified attacks will be discussed.  Bob Briscoe's
   dissertation provides good material here. big TODO.

5.  IANA Considerations

   This document has no IANA considerations.

6.  References

6.1.  Normative References

   [draft-ietf-conex-abstract-mech]
              Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
              Concepts and Abstract Mechanism", draft-ietf-conex-
              abstract-mech-08 (work in progress), October 2013.

   [draft-ietf-conex-destopt]
              Krishnan, S., Kuehlewind, M., and C. Ucendo, "IPv6
              Destination Option for ConEx", draft-ietf-conex-destopt-05
              (work in progress), March 2013.



Wagner & Kuehlewind     Expires October 10, 2016                [Page 8]

Internet-Draft               ConEx Auditing                   April 2016


   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, DOI 10.17487/RFC3168, September 2001,
              <http://www.rfc-editor.org/info/rfc3168>.

6.2.  Informative References

   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
              Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
              <http://www.rfc-editor.org/info/rfc5681>.

Authors' Addresses

   David Wagner
   University of Stuttgart
   Pfaffenwaldring 47
   70569 Stuttgart
   Germany

   Email: david.wagner@ikr.uni-stuttgart.de


   Mirja Kuehlewind
   ETH Zurich
   Gloriastrasse 35
   8092 Zurich
   Switzerland

   Email: mirja.kuehlewind@tik.ee.ethz.ch






















Wagner & Kuehlewind     Expires October 10, 2016                [Page 9]