[Search] [txt|xml|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
ConEx Working Group                                            D. Wagner
Internet-Draft                                             M. Kuehlewind
Intended status: Informational                   University of Stuttgart
Expires: January 13, 2014                                  July 12, 2013


                      ConEx Crediting and Auditing
                      draft-wagner-conex-credit-00

Abstract

   Congestion Exposure (ConEx) is a mechanism by which senders inform
   the network about the congestion encountered by previous packets on
   the same flow.  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.  To
   avoid state and complex Round-Trip Time estimations 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.  Unfortunately, introducing credit does not provide
   incentives to honestly report congestion.  This document lists
   potential issues regarding the proposed crediting and discusses
   potential solutions approaches to interpret and handle credits at the
   audit.

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 January 13, 2014.









Wagner & Kuehlewind     Expires January 13, 2014                [Page 1]


Internet-Draft                ConEx Credits                    July 2013


Copyright Notice

   Copyright (c) 2013 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
   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.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Open issues . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  No incentives to conceal congestion by sending credits  .   3
     2.2.  Handling Loss of ConEx-marked Packets . . . . . . . . . .   4
     2.3.  Independence from Audit State . . . . . . . . . . . . . .   4
     2.4.  Assumption on Distance between Congestion Events  . . . .   4
   3.  Potential Credit Definition and Auditing Approaches . . . . .   4
     3.1.  Basic Audit Reference Implementation  . . . . . . . . . .   5
     3.2.  Credit As Congestion Substitute . . . . . . . . . . . . .   6
     3.3.  Credit As Congestion Surcharge  . . . . . . . . . . . . .   6
       3.3.1.  BDP-Scaled Surcharge  . . . . . . . . . . . . . . . .   7
     3.4.  Credit As Short-Lived Congestion Risk Compensation  . . .   8
   4.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

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.  To avoid state and
   complex Round-Trip Time (RTT) estimations 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.



Wagner & Kuehlewind     Expires January 13, 2014                [Page 2]


Internet-Draft                ConEx Credits                    July 2013


   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).  The C (credit) signal is used to build up credits at the
   audit in advance of congestion.

   [draft-ietf-conex-abstract-mech] (currently) only states that the
   "transport signals sufficient credit in advance to cover congestion
   expected during its feedback delay".  Unfortunately, introducing
   crediting can also provide incentives to not report congestion but
   send credits instead.  While ConEx feedback should be provided timely
   and reflect the actual congestion on a path, credits should be send
   at any time before the congestion event and need to cover at least
   the congestion 'costs'.  Thus crediting might motivate to send
   credits instead of ConEx congestion marks (L or E).  Besides this
   central issue, the exact meaning of these credits and their handling
   at the audit and therefore their usage at the sender is also left
   open up to now.  This documents presents and discusses potential
   concepts for crediting and auditing.

1.1.  Definitions

   Congestion occurrence
   The occurrence of a signal congestion signal, which today corresponds
   to a packet loss or ECN-CE mark.

   Congestion event
   One or more congestion occurrences that happen within one RTT and
   therefore are perceived as one congestion event by today's congestion
   control algorithms.

2.  Open issues

   A solid concept how to interpret and handle credit needs to address
   the issues listed in the following.

2.1.  No incentives to conceal congestion by sending credits

   The goal of ConEx is to reveal path congestion honestly by sending
   the right amount of L or E marks timely after an congestion
   occurrence.  The use of credit marks should not motivate to endanger
   this goal.  If credits are treated equally by an audit device, there
   is no incentive to send additional ConEx (L or E) marks if already a
   sufficient large number of credits have been sent in advance of the
   congestion event.  This is a major and fundamental issue of the
   credit concept in general.




Wagner & Kuehlewind     Expires January 13, 2014                [Page 3]


Internet-Draft                ConEx Credits                    July 2013


2.2.  Handling Loss of ConEx-marked Packets

   Due to the complexity of detecting loss of ConEx information and the
   time dependency of this information, ConEx marks should not be
   retransmitted.  Thus ConEx marks of lost packets will never be seen
   at an audit.  Generally, two entities could be responsible to care
   for this issue: the sender or the audit.  To keep the audit simple,
   it would be preferable having this task performed by the ConEx
   sender.  As retransmitting is not an option, the sender can only send
   credits as a substitute instead.  It is not clear if false positives
   by the audit due to lost markings can be avoided by this.  As,
   without any knowledge about lost markings and depending on the
   definition of credits, it is hard for the sender to determine the
   current number of valid credits perceived by the audit.  The other
   option is having the audit estimating loss of ConEx marks without
   requiring the sender to replace them by credit.

2.3.  Independence from Audit State

   An audit may be started with zero state information on existing
   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.  The credit definition and the
   respective implications for the audit should also consider handling
   this situation.

   The concept of crediting should consider that existing flows may be
   rerouted, so that a flow may pass through different audits over time.
   If rerouting and thus a change of the audit happens, it is not
   required to have no impact at all, but starvation and finally
   shutting down of the connection should be avoided.

2.4.  Assumption on Distance between Congestion Events

   Today's congestion control algorithms are designed for loss-based
   congestion feedback and therefore aim to get congestion feedback
   rather rarely, i.e. for typical BDPs there are losses only every some
   RTTs.  Thus it could be assumed that ConEx marks will be received at
   the audit before the next congestion event occurs.
   Nevertheless, if the congestion feedback is not based on loss, but
   e.g. on ECN, a more frequent signal could provide more precise
   information on the current congestion level and therefore allow a
   finer reaction of the congestion control.  Since this would be a
   desirable situation, we should not base the definition of ConEx
   credit on assumptions about the distance between congestion events.

3.  Potential Credit Definition and Auditing Approaches




Wagner & Kuehlewind     Expires January 13, 2014                [Page 4]


Internet-Draft                ConEx Credits                    July 2013


3.1.  Basic Audit Reference Implementation

   The objective of an audit is to verify correct usage of ConEx signals
   and to penalize cheaters.  To verify, that the congestion reported
   using the ConEx mechanism matches the congestion actually observed by
   the receiver, it has to monitor incoming and outgoing traffic close
   to the receiver (beyond any point of congestion).  For ConEx-capable
   connections there are 5 types of events of interest:

   o  ECN-CE (ECN codepoint set)

   o  Loss (to be detected by the audit)

   o  Re-Echo-ECN (ConEx signal E)

   o  Re-Echo-Loss (ConEx signal L)

   o  Credit (ConEx signal C)

   A simple implementation could keep one counter per type of event.
   For a well-behaving sender, for each loss or ECN-CE signal the
   respective ConEx signal will follow just one RTT later, balancing
   both counters.  Therefore, often only the balance of the counters for
   loss or ECN and the respective ConEx signal matter, e.g. Re-Echo-Loss
   - Loss.  For a well behaving sender and disregarding loss of ConEx
   marks, at least one balance counter will be negative right after the
   congestion event but will recover to zero (balanced state) after one
   RTT (for connections with typical BDPs and today's congestion
   controls).  Even if congestion occurs more frequently due to a fine
   grained congestion notification scheme, the balance counters would be
   negative (at about the average number of congestion occurrences per
   RTT) but not decline over time.  Nevertheless, since ConEx marked
   packets can get lost and will not be re-sent, these balance counters
   may decline over time.  Thus the balance counters can get negative or
   zero, but should never get positive (even when more ConEx marks are
   received than congestion signals are observed).

   An audit could also target to estimate loss of ConEx marked packets
   based on an estimate of the connection's packet loss rate.  It then
   could decide how negative the balance counters are allowed to get: if
   the audit additionally counts all packets of a connection, it can
   easily estimate the packet loss rate.  It can compare the relations
   Lost_Packets/All_Packets and (Lost_Packets - Re-Echo-Loss)/
   Lost_Packets and (ECN-CE - Re-Echo-ECN)/ECN-CE respectively.  Over
   time, these relations should converge, assuming that ConEx marked
   packets are hit with the same probability as other packets(!).
   Therefore, the audit may decide to penalize a flow if less ConEx
   marks are received than expected on that estimation.



Wagner & Kuehlewind     Expires January 13, 2014                [Page 5]


Internet-Draft                ConEx Credits                    July 2013


   If the audit detects misbehavior or cheating e.g. due to permanent
   negative counters, the audit shall penalize the connection.  The only
   actually possible penalty would be dropping packets (with a certain
   probability).  The actual drop rate should provide a tangible
   disadvantage to the sender but should not render the connection
   unusable.  E.g. it could depend on how negative the counter is.  This
   could motivate the sender to just open a new connection as
   replacement.  Moreover, false positives probably can't be avoided
   completely.  The actual definition of penalties requires further
   research.

   In the following different proposals for crediting are presented and
   the handling in the audit based on this general principle is
   discussed.

3.2.  Credit As Congestion Substitute

   Credit marks may be understood by the audit function as an equal
   substitute for congestion marks.  This means, that an audit device
   will count and keep credit marks the same way as congestion marks.
   Usually, as credits should cover the risk of causing congestion, a
   large number of credits will be sent during Slow Start phase of TCP
   congestion control (as the sending rate is increased quite
   aggressively), e.g. at the start-up of a new TCP flow.  Later the
   sending rate is adjusted more slowly, thus usually no further credits
   are needed, if the initially send credits remain valid for the
   lifetime of a flow.  During the connection the number of lost or
   ECN-(CE)-marked packets indicating congestion should be balanced by
   ConEx L or E marks.  So at to the end of a flow's lifetime, there is
   an amount of credits "sitting in the network" that is finally
   discarded.

   Audit implementation:

   An audit maintains three counters per flow: one for credit, one for
   loss balance and one for ECN balance (see Section 3.1).  Whenever a
   marked packet is seen, the respective counter is increased.  When a
   loss or ECN-(CE)-marked packet is observed, the respective counter is
   decreased.
   If the sum of the counters is negative, the flow is penalized.

3.3.  Credit As Congestion Surcharge









Wagner & Kuehlewind     Expires January 13, 2014                [Page 6]


Internet-Draft                ConEx Credits                    July 2013


   Another option is to interpret credit as compensation for late
   arrival of congestion marks, or surcharge on (following) congestion
   marks.  This would basically mean that the sender pays twice for
   congestion: first in advance by sending credit marks, and one RTT
   after the congestion event by sending the respective number of ConEx
   L or E marked packets.

   Audit implementation:

   An audit maintains three counters per flow, one for credit, one for
   loss events and one for ECN events.  Whenever a marked packet is
   seen, the respective counter is increased.  When a loss or
   ECN-(CE)-marked packet is observed, the respective counter and also
   the credit counter is decreased.
   If the credit counter is negative, the flow is penalized.

3.3.1.  BDP-Scaled Surcharge

   For the sake of completeness and mainly motivated by the audit
   implementation below we introduce a variation of the Congestion
   Surcharge definition.  In this approach the charge that needs to be
   provided by credits per congestion event scales with the BDP (as the
   maximum congestion risk) and additionally the longest delay between
   two congestion occurrences within the congestion event.  More
   precisely, the proposed auditing scheme requires the sender to react
   on a congestion event by sending credits until there was one RTT
   without congestion events.  This means that the sender pays for a
   single congestion occurrence at least one RTT of credit marks.. If
   several congestion signals occur within one RTT, the sender sends
   credit marks until one RTT after the last signal.  Thus the credit
   cost of two congestion occurrences within one RTT varies from BDP to
   2*BDP-1.

   Audit implementation:

   An audit maintains three counters per flow, one for credit, one
   balance counter for loss events and one for ECN events.  Whenever a
   L- or C-marked packet is seen, the respective balance is increased.
   When a loss or ECN-(CE)-marked packet is observed, the respective
   counter and also the credit counter is decreased.  For any packet
   seen while the balance is negative, the credit counter is decreased.
   If the credit counter is negative, the flow is penalized.









Wagner & Kuehlewind     Expires January 13, 2014                [Page 7]


Internet-Draft                ConEx Credits                    July 2013


3.4.  Credit As Short-Lived Congestion Risk Compensation

   This approach tries to provide an incentive for the sender to send
   correct congestion feedback and not sending credits instead.  One
   basic property of the approaches presented above is the infinite
   validity of credit.  The expiry of credits could depend on the RTT or
   other channel characteristics, but we deem the reasoning in
   [draft-ietf-conex-abstract-mech] valid, so the audit should not need
   to estimate channel characteristics per flow.  However, credits could
   also expire after a fixed time, e.g. 300 seconds.  This expiration
   time must be fixed and known to all senders so that they can replace
   vanishing credit in time.

   This timeout must at least be large enough to cover the length of a
   feedback cycle of TCP congestion control.  A feedback cycle is the
   time between to congestion events.  Today's congestion control
   algorithms result in quite low loss rate and thus feedback rate for
   large BDPs and therefore rather long feedback cycles.  Nevertheless,
   even for NewReno [RFC5681] being used for a single connection on a
   1GBps link with 100ms RTT and 1500Byte segment size, a feedback cycle
   is about ( (RTT * BDP)/2 = ) 41.6 seconds.  Since even occasional
   packet errors also discourage from using congestion controls with
   that low probing frequency, we deem 300 seconds a safe proposal for
   the expiration timeout.

   Audit implementation:

   An audit maintains three counters per flow, one for credit, one for
   loss events and one for ECN events.  Whenever a marked packet is
   seen, the respective counter is increased.  When a loss or CE-event
   is detected, the respective counter is decreased and the credit
   counter is decreased additionally.  Incoming credits set a timer upon
   which's timeout the credit counter is decreased.
   Note: Since credit expiring a little later than expected does not
   harm the overall function of the audit, it might aggregate expiration
   timeouts, e.g. for 10 seconds so for each flow only 31 bin counters
   would be needed.
   If the credit counter is negative, the flow is penalized.

4.  Discussion

   This section shall provide an initial list of arguments as the basis
   for further discussions.

   For all proposals, honest congestion marks can be replaced with
   credit marks without limitation.  Moreover, for the Substitute
   approach the sender has to the end of an connection no motivation to
   provide any ConEx signals because he can assume that the balance at



Wagner & Kuehlewind     Expires January 13, 2014                [Page 8]


Internet-Draft                ConEx Credits                    July 2013


   the audit is far in his favor.  This aspect may concern a significant
   time, depending on which congestion rate the used congestion control
   algorithm implements.
   Introducing a limitation for sending credit could limit the impact of
   this fact but first a good definition of credit limits is not obvious
   and second it would not work for short flows.

   Any sender-based approach to handle loss of ConEx-marked packets
   requires to allow replacing ConEx L and E signals by credit to a some
   extend.  This is basically contradicting to hindering concealing of
   congestion by using credits.  Note: the same calculation as proposed
   for loss handling at the audit (see Section 3.1) can also be
   performed by the sender, allowing him to send compensational credit
   in advance.  Another advantage of sender-based loss handling is that
   the sender may use that mechanism to compensate false positives of
   the audit.  Of course this a drawback at the same time, as it opens
   for abuse.

   A main advantage of handling loss at the audit is that no
   compensation by credit is necessary, so issue#1 can be avoided.  The
   main disadvantage is that the outlined mechanism only works for
   longer flows since the statistical deviation of the observed loss
   rate needs be acceptable small.  It must also be noted, that the loss
   probability changes over time during a flow's life time.  For today's
   congestion control algorithms, ConEx marked packets will be sent one
   RTT after the congestion event when the sender reduced its sending
   rate, thus the loss rate of ConEx marked packets should be smaller
   than the total average loss rate.  So more complex estimators might
   be necessary, further increasing the audit complexity.

   If ConEx loss is handled by the sender, re-routing or restarting
   audits can be expected to be handled in a similar but this definitely
   requires further research.

   The BDP-Scaled Surcharge-approach has several properties which we
   deem undesirable: although the RTT is out of control of the end user,
   for this definition he has to pay more for connections with longer
   RTTs.  Moreover, the distribution of congestion occurrences affects
   the credit cost of one congestion event significantly.

   Approach Section 3.4 with limited life time of credit at least solves
   the issue of large amounts of credits being available at the audit to
   the end of a connection.  Yet the issue of cheating by sending credit
   instead of congestion marks remains unsolved.  Maybe the proposed
   credit definition could be used with a modified audit algorithm
   limiting the decrease of the balance counters.





Wagner & Kuehlewind     Expires January 13, 2014                [Page 9]


Internet-Draft                ConEx Credits                    July 2013


5.  Security Considerations

   This document has no security considerations.

6.  IANA Considerations

   This document has no IANA considerations.

7.  References

7.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-06 (work in progress), October 2012.

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

7.2.  Informative References

   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
              Control", RFC 5681, September 2009.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP", RFC
              3168, September 2001.

Authors' Addresses

   David Wagner
   University of Stuttgart
   Pfaffenwaldring 47
   70569 Stuttgart
   Germany

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











Wagner & Kuehlewind     Expires January 13, 2014               [Page 10]


Internet-Draft                ConEx Credits                    July 2013


   Mirja Kuehlewind
   University of Stuttgart
   Pfaffenwaldring 47
   70569 Stuttgart
   Germany

   Email: mirja.kuehlewind@ikr.uni-stuttgart.de












































Wagner & Kuehlewind     Expires January 13, 2014               [Page 11]