Subject: Re: [bmwg] draft-baker-bmwg-testing-eyeball-happiness-01.txt

From: Al Morton <[email-masked]>
Date: Tue, 07 Dec 2010 23:05:49 -0500

At 03:30 PM 12/3/2010, [email-masked] wrote:
>...
>         Title           : Testing Eyeball Happiness
>         Author(s)       : F. Baker
>         Filename        : draft-baker-bmwg-testing-eyeball-happiness-01.txt
>         Pages           : 9
>...
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-baker-bmwg-testing-eyeball-happiness-01.txt

Hi Fred,
I have a few comments on your draft,
Al
(as a participant)

---------------------------------------------------------------------
Despite preparing Informational RFCs since the early days,
BMWG has always used the RFC 2119 terms, even before there was
a 2119 to refer to. I suggest to use the usual requirements language
paragraph:
1.1.  Requirements Language

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in RFC 2119 [RFC2119].

and incorporate these terms in the metric definitions where it makes
sense. I'll take a shot at this later...
-------------------------------------------------------------------------

As it stands, I think the metrics you've defined could be measured
in either Lab or Real-world networks. So, I'd like to suggest Scope
section text that makes this clear:

X.X  Scope

(first paragraph is a slightly re-worded para 2 of Intro)
This note describes a test to determine how quickly an
application can reliably open sessions in a complex
environment, such as dual stack (IPv4+IPv6) deployment or IPv6
deployment with multiple prefixes and upstream ingress filtering.
This is not a test of a specific algorithm, but a measurement of the
external behavior of the application and its host system as a black box.
The "happy eyeballs" question is this:
how long does it take an application to open a
session with a server or peer, under best case and worst case
conditions?

The methods defined here make the assumption that the initial
communication set-up of many applications can be summarized by
the measuring the DNS query/response and transport layer handshaking,
because no application-layer communication takes place without
these steps.

The methods and metrics defined in this note are ideally suited for
Laboratory operation, as this affords the greatest degree of control
to modify configurations quickly and produce consistent results.

However, if the device under test is operated as a single user
with limited query and stream generation, then there's no concern about
overloading production network devices with a single "set of eyeballs".
Therefore, these procedures and metrics MAY be applicable to
production network application, as long as the injected traffic
represents a single user's typical traffic load, and the
testers adhere to the precautions of the relevant network with
respect to re-configuration of devices in production.
-----------------------------------------------------------------------------

I suggest adding a phrase to the end of Section 2, paragraph 1:

     ...The amount of time necessary to establish
    communication between two entities should be approximately the same
    regardless of the type of address chosen or the viability of routing
    in the specific network, and users will expect this time to be
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    consistent with their current experience (else, happiness is at risk).
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

---------------------------------------------------------------------------
slightly more exact wording suggestion for in section 2.2:
OLD:
    The measurement plays with an access list or null route in Router 1
    that would prevent traffic Alice->Bob using each of Bob's addresses.
Suggest:
    Different measurement trials revise an access list or null route 
in Router 1
    that would prevent traffic Alice->Bob using each of Bob's addresses.

---------------------------------------------------------------------------

Figure 3 could add the same identification of the transport handshake:

           DNS Server                   Alice                    Bob
               |                          |                       |
           1.  |<--www.example.com A------|                       |
           2.  |<--www.example.com AAAA---|                       |
           3.  |---192.0.2.1------------->|                       |
           4.  |---2001:dba::1----------->|                       |
           5.  |                          |                       |
           6.  |                          |--UDP Request, IPv6-->X|<---------
           7.  |                          |--UDP Request, IPv6-->X|  first
           8.  |                          |--UDP Request, IPv6-->X|  request/
           9.  |                          |                       |  response
          10.  |                          |--UDP Request, IPv4--->|  success
          11.  |                          |<-UDP Response, IPv4---|<---------

                      Figure 3: Message flow using UDP

-----------------------------------------------------------------------------

Suggest to add this point in section 2.3, just before the
metric definition in 2.3.1:

    ALL measurement events on the sending and receiving of messages
    SHALL be observed at the "Alice" attachment point and time stamps
    SHOULD be applied upon reception of the last bit of the IP
    information field. Use of a alternate timing reference SHALL
    be noted.

 >>>> If tcpdump uses a different reference point, we should use that.
---------------------------------------------------------------------------

Suggest that, before getting into the minimum and maximum,
we formalize the single-trial definition of Session setup time,
as discussed above:

2.3.x.  Metric: Session Setup Interval

    Name:  Session Setup Interval

    Description:  The session setup interval MUST be the time beginning
    with the first DNS query sent (observed at Alice's attachment), and
    ending with successful transport connection establishment (as indicated
    in line 12 of Figure 2, and line 11 of Figure 3). This interval is
    defined as the session setup interval.

    Methodology:  In the LAN analyzer trace, note the times of the
       initial DNS request and the confirmation that the session is open
       as described in Section 2.2.  Several instances of the test will
       be run, in at least one of which an attempt is seen to exactly one
       of Bob's addresses.

    Units:  Session setup time is measured in milliseconds.

    Measurement Point(s):  The measurement point is at Alice's LAN
       interface, both sending and receiving, observed using a program
       such as tcpdump running on Alice or an external analyzer.

    Timing:  Continuous.

a lot of redundant info can now be removed from the Maximum and Minimum
Setup time definitions.

-------------------------------------------------------------------------

"minimized" Minimum Session Setup Interval

2.3.2.  Metric: Minimum Session Setup Interval

    Name:  Minimum Session Setup Interval

    Description:  The minimum session setup interval is the shortest
       period of time observed for the opening a session, over all
       trials.

    Methodology:  see Session Setup Interval

    Units:  Session setup time is measured in milliseconds.

    Measurement Point(s): see Session Setup Interval.

    Timing:  Continuous.

---------------------------------------------------------------------------

Reporting Results:

There could be a table configuration parameters and results
to help testers include all the relevant context info in
a report.

Application information:
TCP/UDP, timeouts, etc.

DNS information:

Failed attempt response:
Destination Unreachable/etc.

Session Setup Interval:
(results for each different trial, minimum, maximum, etc.

-----------------------------------------------------------------------