RE: making psamp export congestion-aware

["Will Eatherton" <will@cisco.com>]

Jen,

A couple questions about the proposal

* In general I think the concept is great of allowing a protocol like UDP to
be used with a higher level congestion aware protocol to handle the backoff.
However, from past conversations (with Randy) on this topic my understanding
is that the goal of IETF's mandate in this area is to push protocols like
TCP/SCTP/etc. since it protects the internet from service providers that
might otherwise blast out UDP.  Proposals within IPFIX context to use rate
limiting were dismissed since it was too easy for service providers to
mis-configure that or to never enable it altogether.  The final comment was
that there might cases where a service provider might desire a stateless
protocol like UDP within their network (maybe it is an internal network for
mgmt data) but that IETF does not standardize protocols for that
environment.
	-- Doesn't this proposal suffer in that it is to easy for service providers
to not enable your mechanism and therefore end up getting to happily use UDP
without any controls forced on them ?

* In the past I have heard many service providers indicate they really don't
want boxes like a collector changing configuration of the router through
MIB/CLI especially if they are designed by 3rd party vendors.  Do you see
this as a concern with this proposal ?

Will

>
> 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/>


--
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/>