• Forums
    • Public Forums
      • Community Connect
      • Dynatrace
        • Dynatrace Open Q&A
      • Application Monitoring & UEM
        • AppMon & UEM Open Q&A
      • Network Application Monitoring
        • NAM Open Q&A
        • Enterprise Synthetic Monitoring
      • Synthetic Classic
        • Synthetic Classic Open Q&A
      • BSM Open Q&A
  • Home /
  • Public Forums /
  • Network Application Monitoring /
  • NAM Open Q&A /
avatar image
Question by Brett B. · Nov 06, 2015 at 07:38 PM · nam probe

Server Packets Lost - Explanation?

Hello all,

My client has asked me a question of which I don't know how to answer:

"We have a tap between a server and client.

Why would the number between the (Server to AMD) and the (AMD to Client) not be the same?

If anything, Server to Client should be higher?"

I don't understand where the AMD fits in this equation. Can someone help clarify?

Server packets lost (server to AMD)

The number packets sent by a server that were lost - between the server and the AMD - and needed to be retransmitted.

Server packets lost (AMD to client)

The number of packets sent by a server that were lost - between the AMD and the client - and needed to be retransmitted.

serverpacketslost.png (266.7 kB)
Comment

People who like this

0 Show 0
10 |2000 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users

3 Replies

· Add your reply
  • Sort: 
  • Most voted
  • Newest
  • Oldest
avatar image
Best Answer

Answer by Ulf T. · Nov 09, 2015 at 11:46 PM

Hey Brett - Did you digest Matt's excellent description? If not - let me try to put it in terms the customer might understand:

"We have a tap between a server and client. (Very good)

Why would the number between the (Server to AMD) and the (AMD to Client) not be the same?

Simply because it´s different traffic - The packets can be lost before the AMD as well as after. We know the total number of lost packets and we know the number of packets that has past the TAP/AMD - also what packets (ACK and retrans). The difference between those 2 is what is lost between the server and the AMD. The decode keeps track of the sequence numbers and so knows when a packets have gone missing.

If anything, Server to Client should be higher?" Why - packets can be lost in both directions?

BTW - you graph is missing "Client to AMD" to make the picture complete.

So from the top of my head - there should be 6 packet loss metrics

  • Client to AMD
  • AMD to Client
  • Server to AMD
  • AMD to server
  • Server loss Rate (I Think this is te same as Loss rate Out)
  • Client loss Rate )which then would be Loss rate In)

    The nice thing with a (cleverly) placed tap is that you get an instant Fault Domain Isolation so you know whether its in the DC or out there on the Net that the packets are lost.

    Comment
    Brett B.
    Raffaele T.
    Matt L.
    Chris V.
    Albert Y.

    People who like this

    5 Show 1 · Share
    10 |2000 characters needed characters left characters exceeded
    ▼
    • Viewable by all users
    • Viewable by moderators
    • Viewable by moderators and the original poster
    • Advanced visibility
    Viewable by all users
    avatar image Brett B. · Nov 10, 2015 at 02:31 PM 0
    Share

    Thank you for your detailed response. Yes, those 6 perspectives all make sense and do paint a great picture of where the loss is happening. These metrics are much more useful than I imagined :)

    avatar image
    Best Answer

    Answer by Matt L. · Nov 09, 2015 at 08:08 PM

    Hey Brett,

    My assumption (need validation from someone else please, @Chris Vidler, @Mike Hicks) for these metrics is that the Server Loss Rate (Server to AMD) is due to packets lost between the server transmission, and the AMD sniffing point, and that the Server Loss Rate (AMD to Client) is due to packets lost between the AMD sniffing point and the Client receiving. Then the Total Server Loss Rate is simply the sum of these two metrics:

    This is possible, as the AMD is in the middle, so it can see what packets got to it's sniffing point in the first transmission, vs what the client ends up requesting as retransmissions. then it can take the differences to figure out the two values.

    Simplified ie: AMD sees 7 packets go past it from the server. It then sees ack from Client saying it received 5 packets of the original 10 the server says it sent. In this example, Server Loss Rate (Server - AMD) is 3pkts (10 - 7), the Server Loss Rate (AMD-Client) is 2pkts (7 - 5), and Total Server Loss Rate is 5pkts (3 + 2, or the retransmission request from Client).

    This is useful, as it now tells us where the majority of the loss rate is taking place. Assuming we know the position of the AMD sniffing point on the network, using your datapoint, we can safely assume that the majority (14.3k Pkts) of the total Server-side loss rate (14.3k + 9.8k = 24.1k Pkts) is due to something on the network between the Server and the AMD sniffing point.

    IT's just another way for us to break down the communication between server and client a bit more, due to the positioning of our AMD.

    Thanks,

    Matt Lewis


    serverlossrate.png (108.1 kB)
    Comment
    Brett B.
    Raffaele T.
    Chris V.
    Shiv S.

    People who like this

    4 Show 2 · Share
    10 |2000 characters needed characters left characters exceeded
    ▼
    • Viewable by all users
    • Viewable by moderators
    • Viewable by moderators and the original poster
    • Advanced visibility
    Viewable by all users
    avatar image Matt L. · Nov 09, 2015 at 08:36 PM 0
    Share

    Just verified this by adding the three Server Loss Rate metrics in a DMI report:

    serverlossrateverification.png (4.6 kB)
    avatar image Brett B. · Nov 10, 2015 at 02:30 PM 1
    Share

    Thank you for the great explanation, that makes perfect sense! I wasn't thinking about the AMD seeing the AMD seeing the retransmissions and inferring where the loss happened.

    avatar image

    Answer by Jeroen H. · Dec 21, 2015 at 09:36 PM

    Hi,

    I have some sample capture files available from a customer who has multiple capture points and AMDs in their environment. Some application flows happen to pass more than 1 of these capturing points, so I had the chance to capture traffic simultaneaously on both ends of the network loss. The actual loss is happening on a switch in between the 2 capture points.

    There's 1 trace file where a server packet is lost, and in the other file (capture point closest to the server) this packet is still there.

    These two samples can help you interpret how a tool like wireshark reacts to both situations, as it uses different colorings for the retransmitted packets.

    packet-loss.zip


    packet-loss.zip (8.2 kB)
    Comment
    Matt L.

    People who like this

    1 Show 0 · Share
    10 |2000 characters needed characters left characters exceeded
    ▼
    • Viewable by all users
    • Viewable by moderators
    • Viewable by moderators and the original poster
    • Advanced visibility
    Viewable by all users

    Your answer

    Hint: You can notify a user about this post by typing @username

    Up to 10 attachments (including images) can be used with a maximum of 52.4 MB each and 262.1 MB total.

    Welcome to the
    Dynatrace Community Forums

    Check out the Forum User Guide and Forum Guidelines to learn how to get started.

    Community Member of the Month
    February 2019

    Announcing Dynatrace's Community Member of the Month for February 2019, Larry R.! Click here to read more!

    Employee Member of the Month
    February 2019

    Announcing Dynatrace's Employee Member of the Month for February 2019, Dave M.! Click here to read more!

    Live webinar: AIOps done right through enhanced Dynatrace AI root cause detection

    Learn the enhanced capabilities of the next generation Dynatrace AI root cause analysis and how to feed it with your own data sources.
    Wednesday, February 20, 2019
    Register today!

    Live webinar: AIOps done right through enhanced Dynatrace AI root cause detection

    Learn the enhanced capabilities of the next generation Dynatrace AI root cause analysis and how to feed it with your own data sources.
    Wednesday, February 20, 2019
    Register today!

    NAM 2019 Beta is available

    Would you like to have an early taste of what we have cooked up for 2019? We would love to hear your feedback and improve some of the new features. Check NAM 2019 Beta release notes.
    Sign up today!

    Follow this Question

    Answers Answers and Comments

    17 People are following this question.

    avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image avatar image

    Related Questions

    AMD monitoring with cisco FEX and vPC 1 Answer

    Exclude Exception Class 2 Answers

    Miscellaneous Parameters 2 Answers

    Several Report Questions 5 Answers

    Using "OR" Logic in DMI Metrics 1 Answer

    Forum Tags

    nam server scripting nam upgrade universal decode esm wan nam console mobileapp dashboard sequence transactions citrix mq siebel dna reports rum ads rest api configuration nam probe license security sap alerting css
    • Forums
    • Public Forums
      • Community Connect
      • Dynatrace
        • Dynatrace Open Q&A
      • Application Monitoring & UEM
        • AppMon & UEM Open Q&A
      • Network Application Monitoring
        • NAM Open Q&A
        • Enterprise Synthetic Monitoring
      • Synthetic Classic
        • Synthetic Classic Open Q&A
      • BSM Open Q&A