Q

Best practices for end-to-end testing

We are trying to set up testing guidelines for equipment (card swipe terminals) owned and/or leased to our customers

that will connect to us via dial-up (T1), host-to-host (Frame) and the Internet. Are there any "best" practices that should be looked at? I'm combing through my Cisco material to find their checklist, but so far, I've had no luck. Best practices for end-to-end testing (that scale well) haven't really been well developed yet. That is because there aren't that many viable options - most testing methodologies are either not end-to-end or require remote agents or hardware solutions at both end (and thus don't scale well).

Your constraints appear to be:

  1. no (or low) dependence on or knowledge of specific network path
  2. scalable to many devices/paths
    1. low effort to test
    2. low cost to instrument each end host
    3. rapid testing
  3. no (or low) new requirements for end host

Before continuing, allow me to define a concept since the language in this area is not well defined. The key words are "end-to-end" and "characterization" or "view".

"End-to-end" specifies a network path from one host to another that may include a wide variety of other devices and media. The nature of "end-to-end" doesn't essentially change though if those devices or media change. The idea of end-to-end is established at a particular network Layer such as Layer 3 (IP) or Layer 2 (Frame).

"Characterization" or "view" defines an attribution of the end-to-end path. A simple example is "connectivity" ? we are all familiar with the characterization of "connected", particularly in terms of the "view" that a well-known tool, ping, provides. More complex characterizations are possible in terms of things like

  • maximum achievable bandwidth
  • propagation delay
  • jitter
  • packet loss

    Best practices should be:

  • rely on an end-to-end characterization of network path
  • use consistent minimum characterization profiles across paths to all devices
  • pre- and post-qualify the path (if possible) when making changes or installations
  • establish a minimum number of independent tests that should be performed relative to the requirements of the implementation
  • monitor the paths on a regular, on-going basis from a critical central point (or multiple points as needed)

    So, in a very simple world, that might mean that you use connectivity as your characterization, ping as your tool, and a script to execute it as a cron job. In a more complex world (like the one you live in), you may have more stringent criteria, and require more sophisticated tools (e.g. appareNet or remote SNMP-based systems like MRTG) to monitor the paths for preferred characterizations.

    This is an area where there is much work yet to be done. I hope this helps.

  • This was first published in May 2003

    Dig deeper on Network Performance Management

    Pro+

    Features

    Enjoy the benefits of Pro+ membership, learn more and join.

    Have a question for an expert?

    Please add a title for your question

    Get answers from a TechTarget expert on whatever's puzzling you.

    You will be able to add details on the next page.

    0 comments

    Oldest 

    Forgot Password?

    No problem! Submit your e-mail address below. We'll send you an email containing your password.

    Your password has been sent to:

    SearchSDN

    SearchEnterpriseWAN

    SearchUnifiedCommunications

    SearchMobileComputing

    SearchDataCenter

    SearchITChannel

    Close