RE: Distributed agent implementation

From: Peter Phaal (
Date: 10/01/02

  • Next message: Wanja Jansson: "ifindex in arts++ viewers"


    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

    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.


    > 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