TCP-RTT info of src-dst from sFlow

[anu mercian]

Dear sFlow-RT community,

This might be a naive question, but I wanted to get more clarification on how to get RTT information of src-dst pairs from sflow datagrams. I saw another post where "Host sFlow" is used to enable extended tcp info to the sflow datagram. Host sFlow is installed on servers, if I need to get RTT information of src-dst pairs from sFlow configured on switches, how do I achieve it. 

Also can any sflow-rt API package be used to compute RTT, post processing at the sflow collector?

Thank you very much in advance,

Anu

[Neil McKee]

I don't see any way you could derive RTT from the sFlow you get from switches.  That information is only available from the Linux host-sflow agent because of the way Linux allows efficient access to the TCP connection state that is maintained deep in the kernel. The kernel is maintaining RTT/jitter/retransmissions etc. as part of the normal end-to-end modeling that running TCP requires:

https://blog.sflow.com/2016/10/network-performance-monitoring.html

but to the switch these are just packets to be forwarded.

There are other effects you can possibly detect from the stream of samples that you get from the switch (such as  a contraction of the TCP window,  a reduction in the throughput of a long-running flow, or the appearance of congestion-notification bits),  but if you can run hsflowd on some of your servers (and VMs) then you will get a highly enriched view of the traffic with suprisingly low overhead.

Maintaining a real-time delay-map of the entire network without having to run any active tests is certainly desirable,  but remember that utilization is typically a more useful control-variable for the reasons outlined here:

https://blog.sflow.com/2013/02/delay-vs-utilization-for-adaptive.html

------
Neil McKee
InMon Corp.
http://www.inmon.com

--
You received this message because you are subscribed to the Google Groups "sFlow-RT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sflow-rt+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sflow-rt/7968c467-d4b5-48f9-b1da-ab8adbc395e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[anu mercian]

Thank you very much for the detailed response. With my current work, I am experimenting with sflow on HPE switches and cannot control what can be installed on servers. So I am limited to what we can leverage from switches. I will look more into throughput, congestion-notification and contraction of TCP window for now.

Thank you,

Anu

On Friday, July 12, 2019 at 4:30:58 PM UTC-7, Neil McKee wrote:

I don't see any way you could derive RTT from the sFlow you get from switches.  That information is only available from the Linux host-sflow agent because of the way Linux allows efficient access to the TCP connection state that is maintained deep in the kernel. The kernel is maintaining RTT/jitter/retransmissions etc. as part of the normal end-to-end modeling that running TCP requires:

https://blog.sflow.com/2016/10/network-performance-monitoring.html

but to the switch these are just packets to be forwarded.

There are other effects you can possibly detect from the stream of samples that you get from the switch (such as  a contraction of the TCP window,  a reduction in the throughput of a long-running flow, or the appearance of congestion-notification bits),  but if you can run hsflowd on some of your servers (and VMs) then you will get a highly enriched view of the traffic with suprisingly low overhead.

Maintaining a real-time delay-map of the entire network without having to run any active tests is certainly desirable,  but remember that utilization is typically a more useful control-variable for the reasons outlined here:

https://blog.sflow.com/2013/02/delay-vs-utilization-for-adaptive.html

------
Neil McKee
InMon Corp.
http://www.inmon.com

On Fri, Jul 12, 2019 at 2:47 PM anu mercian <freebi...@gmail.com> wrote:

Dear sFlow-RT community,

This might be a naive question, but I wanted to get more clarification on how to get RTT information of src-dst pairs from sflow datagrams. I saw another post where "Host sFlow" is used to enable extended tcp info to the sflow datagram. Host sFlow is installed on servers, if I need to get RTT information of src-dst pairs from sFlow configured on switches, how do I achieve it. 

Also can any sflow-rt API package be used to compute RTT, post processing at the sflow collector?

Thank you very much in advance,

Anu

--
You received this message because you are subscribed to the Google Groups "sFlow-RT" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sflo...@googlegroups.com.