From: Peter Phaal (peter_phaal@inmon.com)
Date: 10/01/02
Marc,
It is very important for scalability that the sFlow sender transmit sFlow
datagrams in sequence number order. Forcing recievers to maintain a queue of
out of order samples per sFlow source would consume significant resources
and introduce additional latency to the measurement system. An sFlow
receiver should be able to make a single determination as to whether or not
to process or discard a received sFlow datagram based on the sequence
number.
Of course packet re-ordering in the network is possible (since sFlow uses
UDP), but re-ordered packets are unusual and a receiver should be free to
choose to discard the out of order packets. An sFlow source generating out
of order packets would force all receivers to perform packet re-ordering
which is unacceptable.
Regards,
Peter
> This looks fine. I agree that there's some extra overhead
> for collectors to
> track multiple sequence number streams, but hopefully, this won't be
> burdensome. Regarding the issue of a distributed agent implementation
> causing an increased number of sFlow datagrams to be sent,
> that would likely
> happen only when data rates are relatively low, such that
> non-full sFlow
> datagrams would be sent as a result of a timer tick. In the
> scenario that
> I'm thinking of, I believe things could be optimized to
> mostly avoid that,
> however, doing so might result in some samples being
> delivered out of order.
> Do you think that collectors should be prepared to deal with
> such cases by
> doing some buffering and reordering of out-of-order samples,
> or do you feel
> that's too much of a burden?
This archive was generated by hypermail 2.1.4 : 10/01/02 PDT