Subject: [conex] newer intro text: draft-ietf-conex-concepts-uses

From: Bob Briscoe <[email-masked]>
Date: Wed, 06 Jul 2011 11:13:19 +0100

ConEx folks,

Following much debate on the previous attempt, below is the hopefully 
much improved new Intro text intended for draft -02 (deadline Mon 11 July).

After the Fig, you'll see I've used fair queuing as the launch pad 
for the rest of the argument. Rationale for this is at the end of the 
email if you're interested.

My co-editor Rich hasn't seen this (he's just returning from a couple 
of days away, so for speed I have gone straight to the list).

At this stage, please can reviewers suggest changes to specific 
parts. We won't be able to handle complete re-writes by the deadline.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
1.  Introduction

    The power of Internet technology comes from multiplexing shared
    capacity with packets rather than circuits.  Network operators
    usually provide sufficient shared capacity, but whenever too much
    packet load meets too little shared capacity, congestion results.
    Congestion appears as either increased delay, missing packets or
    packets explicitly marked with ECN [RFC3168].  Referring to Figure 1,
    congestion control currently relies on the transport receiver
    detecting these 'Congestion Signals' and informing the transport
    sender in 'Congestion Feedback Signals'.  The sender is then meant to
    reduce its rate in response.

    This document provides the entry point to the set of ConEx
    documentation.  It motivates a new congestion exposure (ConEx) field
    at the IP layer, focusing on the 'why' rather than the 'how'.  A
    companion document about the ConEx protocol mechanism gives the 'how'
    [ConEx-Abstract-Mech].  Briefly, the idea is for the sender to
    continually signal expected congestion in the headers of any data it
    sends.  To a first approximation the sender does this by relaying the
    'Congestion Feedback Signals' back into the IP layer.  They then
    travel unchanged across the network to the receiver (shown as 'IP-
    Layer-ConEx-Signals' in Figure 1).  Certain IP layer devices can then
    use this new information, for example as input to traffic management.

    ,---------.                                               ,---------.
    |Transport|                                               |Transport|
    | Sender  |   .                                           |Receiver |
    |         |  /|___________________________________________|         |
    |     ,-<---------------Congestion-Feedback-Signals--<--------.     |
    |     |   |/                                              |   |     |
    |     |   |\           Transport Layer Feedback Flow      |   |     |
    |     |   | \  ___________________________________________|   |     |
    |     |   |  \|                                           |   |     |
    |     |   |   '         ,-----------.               .     |   |     |
    |     |   |_____________|           |_______________|\    |   |     |
    |     |   |    IP Layer |           |  Data Flow      \   |   |     |
    |     |   |             |(Congested)|                  \  |   |     |
    |     |   |             |  Network  |--Congestion-Signals--->-'     |
    |     |   |             |  Device   |                    \|         |
    |     |   |             |           |                    /|         |
    |     `----------->--(new)-IP-Layer-ConEx-Signals-------->|         |
    |         |             |           |                  /  |         |
    |         |_____________|           |_______________  /   |         |
    |         |             |           |               |/    |         |
    `---------'             `-----------'               '     `---------'

    Figure 1: Where the ConEx Protocol Fits in the Internet Architecture

Briscoe & Woundy         Expires January 5, 2012                [Page 3]

Internet-Draft               ConEx Mechanism                   July 2011

    Current traffic management solutions limit traffic based on either
    bit-rate or volume.  For instance, weighted fair queuing (based on
    [RFC0970]) shares out bit-rate when a link is congested.  However it
    fails to consider how much of the time a consumer keeps the link
    busy, which is the main factor that determines everyone else's bit-
    rate.  To try to address this issue, many network operators have
    introduced volume limits.  However, these tend to be either not
    strict enough during congested periods, or unnecessarily strict when
    traffic is light.

    Because each solution only partially addresses the problem, operators
    keep adding more solutions.  So a data path across the Internet often
    encounters numerous blockages and throttles in each network it
    crosses.  This clutter is actually a symptom of a deeper underlying
    problem: neither bit-rate nor volume is the right metric.

    Traffic management would be so much better (and simpler) if
    congestion were visible in packets.  Then, whenever congestion was
    not present, all restraints could be removed, leaving the full
    capacity available to everyone.  But if some excessive users were
    causing a lot of congestion, the traffic management function would
    know and be able to directly limit their traffic, in order to protect
    the service of other users sharing the same capacity.

    ConEx exposes exactly the right information for this, in the IP
    layer.  It reveals a consumer's overall contribution to congestion,
    which is a direct measure of how much one user affects others.  ConEx
    makes this easy to measure--as easy as counting straight volume,
    except you only count the volume of packets with ConEx markings.
    With the right metric visible, traffic management would only have to
    be done once on a path because it would be done well.

    In the absence of the right metric, some operators have deployed deep
    packet inspection (DPI) equipment; not just in the public Internet
    but also in enterprise and campus networks.  Their main aim has been
    to identify and limit specific types of application that they
    associate with heavy usage.

    With ConEx, a network operator can manage traffic without dipping
    into the higher layers, because ConEx makes the relevant bulk
    congestion information accessible at the IP layer.  This solves two
    problems that have made DPI controversial: traffic management can be
    application-neutral and compatible with IPsec encryption.

    Also, because ConEx information is added explicitly at the IP layer,
    it is visible to provider and consumer alike.  Therefore traffic
    contracts or acceptable use policies can be based on a quantifiable
    metric that is open and transparent to both parties, so that it will

Briscoe & Woundy         Expires January 5, 2012                [Page 4]

Internet-Draft               ConEx Mechanism                   July 2011

    be sufficient to manage traffic without extra non-transparent
    wriggle-room and caveats.

    To summarise so far, ConEx is designed to make it simple to do
    traffic management that is transparent, neutral and free of
    unnecessary restraints.  Although it is not our place to make a
    network provider meet these requirements, ConEx is designed to make
    this the simplest service to provide.

    {ToDo: review this para when done and fill out} This introduction has
    focused on traffic management as the main use for ConEx.  However,
    ConEx is intended as a generative technology, with a wider range of
    potential uses.  The document structure reflects this.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

Rationale for starting from fair queuing:
I was having real trouble with the paras that talked about how volume 
& bit-rate are the wrong metrics. I originally liked the text Michael 
Menth suggested and John Leslie improved. But actually, someone could 
have read them and just said "fair queuing or round-robin scheduling 
solves that problem; these people are just trying to invent something 
new, when a solution already exists".

The original text I wrote was designed to avoid such criticism, by 
careful choice of words, but I assume it was consequently unclear 
given Michael and John both wanted to rewrite it. Therefore, I have 
tried an approach where we explicitly start from fair queuing, but 
still try to keep it fairly high level, given this is the introduction.

Cheers

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design