making psamp export congestion-aware

[Jennifer Rexford <jrex@research.att.com>]

Folks,

We haven't had much discussion of PSAMP export on the list.  There's a
general requirement from the IETF that new protocols be congestion
aware, using RFC 2914 as a guide.  Here are some thoughts on export
requirements for PSAMP, and a proposal for making it congestion-aware
while remaining compatible with PSAMP's goal of ubiquitous support on
network elements.  Comments appreciated...

-- Jen

Export of measurement records in PSAMP: In the PSAMP framework, a
device such as a passive monitor or an interface card applies
selection and sampling rules to a stream of packets and generates
measurement records that include a collection of fields for each
packet.  The device exports these records for further analysis.  For
example, the records generated by the interface card on a router may
be exported to a separate collection server that may reside next to
the router or elsewhere in the network.  When the measurement records
traverse the network, they compete for resources with other Internet
transfers.  Congestion-aware export is important to ensure that the
measurement records do not overwhelm the capacity of the network or
unduly degrade the performance of other applications.

Unreliable transport: The export of measurement records does not
require reliable export.  In fact, retransmission of lost measurement
packets could consume additional network resources and would require
state on the device generating the records.  The device would have to
be addressable, able to receive and process acknowledgments, and to
store unacknowledged data.  These requirements would be a significant
impediment to having uniform support for measurement on high-speed
interface cards in IP routers.  Instead, we propose that PSAMP devices
can support a unreliable export mechanism.  Sequence numbers on the
packets or the measurement records within the packet would indicate
when loss has occurred, and the analysis of the measurement data can
account for this loss.  In some sense, packet loss becomes just
another form of sampling (albeit a less desirable, and less
controlled, form of sampling).

Changing the sending rate: In congestion-aware transport, there can be
a clear separation between the algorithm that computes the sending
rate and the way the sender adapts to the new sending rate.  For
example, a device could conceivably reduce the sending rate by
discarding excess records.  This approach may be an appropriate
reaction to transient congestion.  Or, the device could operate with a
smaller sampling rate.  This may be a more appropriate reaction to
long-term congestion.  Or, the device could include fewer fields in
the measurement records to reduce the volume of data that are exported
to the collection machine.  In some cases, a collection server may
receive measurement records from more than one device, and could
decide to reduce the export rate at one device rather than the other
(or reduce the rate for one of the filter banks at a device rather
than the other), in order to prioritize the measurement data.  This
type of flexibility is valuable for network operators that collect
measurement data from multiple locations to drive multiple applications.

Configuration of the sending rate: The collection server is the
recipient of the traffic from the PSAMP device(s).  This server can
detect congestion along the path from the PSAMP device through lost
packets (which manifest themselves as gaps in the sequence numbers, or
the absence of packets for a period of time).  The server can run an
appropriate congestion-control algorithm to compute a new sending
rate, and can reconfigure the PSAMP device with the new rate.  This is
an attractive alternative to requiring the PSAMP device to receive
acknowledgment packets.  The server can reconfigure the sending rate
using an SNMP MIB or a command-line interface.  It is already
envisaged having an SNMP accessible MIB for easy reconfiguration of
sampling parameters, so this dovetails well. Implementing the
congestion control algorithm in the collection server has the added
advantages of flexibility in adapting the sending rate and the ability
to incorporate new congestion-control algorithms as they become
available. For the PSAMP standard, it would be mandatory to implement
and such export rate control in both the measurement device and the
collector. There's scope here for reusing existing rate control
algorithms with well understood properties.

Notions of fairness: In some cases, it may be reasonable to allow the
collection server to have flexibility in deciding how aggressively to
respond to congestion.  For example, the PSAMP device and the
collection server may have a very small round-trip time relative to
other traffic.  Conventional TCP-friendly congestion control would
allocate a very large share of the bandwidth to this traffic.
Instead, the collection server could apply an algorithm that reacts
more aggressively to congestion to give a larger share of the
bandwidth to other traffic (with larger RTTs).  In other cases, the
measurement records may require a larger share of the bandwidth than
other flows.  For example, consider a link that carries tens of
thousands of flows, including some non TCP-friendly DoS attack
traffic.  Restricting the PSAMP traffic to a "fair share" allocation
may be too restrictive, and might limit the collection of the data
necessary to diagnose the DoS attack.  In this situation, the
collection server could conceivably have a less aggressive reaction to
congestion (say, dividing the sending rate by 1.5 rather than 2 in the
presence of loss) to claim a larger fraction of the link bandwidth.
The collection server could also employ policies that allocate
bandwidth in certain proportions among streams of measurement records
from different PSAMP devices (or filter banks in a single device).





--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>