Subject: [AVT] Details on Real-time ECN and RTP Payload Format for ECN [email-masked]

From: "Corey Alexander" <[email-masked]>
Date: Tue, 02 Aug 2005 16:50:58 -0500

Greetings.

Thank you all who attended the AVT session this afternoon for your
comments and questions.  Most of them dealt with the underlying method
being used, and whether it was appropriate for the intended use.
Unfortunately, most of them were not adequately addressed.  We would
like to do that here.

First, let's cover some terminology.  There are two terms or phrases
that met with contention: admission control, and congestion.

"Admission Control" - when we refer to admission control, it is
painfully obvious that it differs from how others expect it to be used.
   When we say admission control, we are referring a method to verify two
things:
   (1) end-to-end connectivity along the path through the network, and
   (2) available bandwidth end-to-end along the path through the network

The first item is clear enough, but the second needs additional
clarification.  The real-time ECN method defined in
draft-babiarz-tsvwg-rtecn-04.txt defines a method by which an individual
router measures aggregated traffic rate per service class, marking
specific ECN values in the IP header when the aggregated measure exceeds
one of two pre-engineered threshold levels.  When we refer to available
bandwidth along a network path, we refer to a condition where no router
along that path is marking ECN to indicate an aggregate traffic
measurement (per service class) above either of the two threshold levels.

"Congestion" - this one is particularly confusing.  When we refer to
confusion in this context, we are not referring to the scenario where a
queue has overflowed and packets are dropping, for example.  Instead,
what we really mean is the ECN markings on a packet indicate that the
path in the network on which the packet traversed was marked by one or
more routers that were experiencing an aggregate measurement above one
of the two thresholds levels.

We would like to qualify our definition of admission control as
"measured-rate admission control", and our definition of congestion as
"early congestion".

Now on to probing.  The probing for our measured-rate admission control
accomplishes both of the items that we want to verify, end-to-end
connectivity and bandwidth availability.  The end-to-end connectivity is
obvious - if the probe doesn't reach the remote end, there is no
connectivity.  But how it represents bandwidth availability is less
obvious.

The probe packets are sent with as many attributes as the media packets
they aim to represent as possible: source/destination IP/port and DSCP.
The intent is for the network to treat them as if they were the media
packet they are representing.  Additionally, they could also be padded
to represent a synthetic load on the network, but that is not our objective.

Our objective during proving is to determine whether any one (or more)
of the routers along the path through the network taken by the probe
packets is experiencing a measured aggregated traffic rate above either
of the two pre-engineered threshold levels.  If so, then early
congestion has been detected, and depending on policy and which of the
two thresholds was exceeded, the session represented by the probe may or
may not be admitted.

Simply put, if the ECN marking indicates that there is bandwidth
available by virtue of the measured aggregate traffic rate being below
the pre-engineered threshold for measured-rate admission control, then
the session will be admitted (which is a topic for MMUSIC involving
preconditions).  Otherwise, it will not.

There were and are many questions involving whether the system described
functions as intended.  To address this, for now we'd refer you to draft
draft-dudley-rtecn-simulation-00.txt (and
draft-babiarz-rtecn-marking-00.txt) for information on simulation
results (and an analysis of different marking methods).  Past
referencing this draft, we'll not address those questions here, at least
in this summary.

On to the details of the proposed RTP payload format.  Putting aside for
the moment whether this is a proper use of RTP, and whether there are
alternative methods of accomplishing the end result - there always are -
  we'll describe the use of the two fields.

The two fields ECN and IRSN currently defined are used for path
conformance verification and cheater detection.  There was a question as
to what this meant, the answer to which should also be clarified here.
"Path conformance verification" refers to validating that there are no
devices along the path that are marking ECN bits using a different
methodology, specifically that described in RFC 3168.  "Cheater
detection" refers to validating that there are no devices along the path
that are explicitly marking the ECN bits in the packets (whether probe
or real media packets) in such a way as to disrupt or gain service.
Another area to be detected that overlays the two of these categories is
the general case where a device is simply false marking the ECN bits,
whether zero marking or otherwise.

The ECN field is use to carry during probing the ECN bit value used on
the sent packet, such that a receiving device can compare the ECN value
received int the IP header against the ECN field contents in the payload
and make a determination of whether (1) the path is conformant and/or
without cheaters and/or (2) there is no early congestion indicated on
any of the routers along the path through the network.  If the path is
found to be nonconformant or a cheater is detected, the session is not
admitted.  If there is early congestion detected, the session is
admitted or not depending on policy and the threshold exceeded as
indicated by the ECN marking.

The IRSN field is used mainly during the exchange of real media packets.
  It is used to seed a common psuedorandom function on both the sending
and receiving device.  The initial RTP sequence number should have been
selected randomly by the sending device, so it serves as a random seed
value.  Once seeded, the common function is used by each device to
determine the next number in the psuedorandom sequence, modulus 4, to
determine the sequence number of the next packet which will be used for
cheater detection.  This iterative calculation, combined with the fact
the initial RTP sequence number that was used to seed the common
function, allows each endpoint to synchronize on which packets are used
for cheater detection.  If a cheating device is found during the
exchange of real media, policy may dictate, for example, that the
session can be terminated, or that the indicent logged.

It is possible to do this via other methods, and while we like this
approach, we are considering other options in light of the comments
received today.  We would, however, still like to solicit any other
comments anyone might have.

Thanks,
Corey

-- 
Corey W. Alexander

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt