[MMUSIC] Details on Real-time ECN and RTP Payload Format for ECN Probing@nortel.com

["Corey Alexander" <coreya at nortel.com>]

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


_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic