Subject: [bmwg] about measuring the delay by real world disruption

From: "Chao Liu -X (chaliu2 - CIIC at Cisco)" <[email-masked]>
Date: Fri, 19 Nov 2010 08:59:10 +0800

I agree with Gary on the measuring the delay by real world disruption,
and I believe the result should be closer to the feeling of real users.

I used a script to test delay, and it turned out that the delay is
mainly caused by the connect() timeout(SYN timeout), which is 21 seconds
on my PC.

The IPv6 addr of www.python.org is 2002:888:2000:d::a2. If I change the
last number of the address to 5 or 6, i.e. 2002:888:2000:d::a2-->
2001:888:2000:d::a5 or 2001:888:2000:d::a6, the connection is timeout,
so these are both problematic addresses.

Because of the huge IPv6 address space and the time consumption of
discovering an problematic address(21 seconds), it'll take great amount
of time to discover all the real world disruption areas. An efficient
way should be figured out to do this job. 

-chao

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

Date: Thu, 18 Nov 2010 14:29:39 +0800

From: "Gary Yang (gayang)" <[email-masked]>

Subject: [bmwg] Comments on

         draft-baker-bmwg-testing-eyeball-happiness-00

To: <[email-masked]>

Message-ID:

         <[email-masked]>

Content-Type: text/plain; charset="us-ascii"

Fred,

One question: Instead of configuring the disruption, what about

measuring (approaching) the delay by "real word disruption" ? 

The setup time is as worst as 40 second "heard" so far and needs to be

measured to index the real eyeball happiness cost. An experiment of

calling socket.getaddrinfo(www.python.org, 80, 0, 0, socket.SOL_TCP)

returns "2002:888:2000:d::a2" and "82.94.164,162" is played, both are

legitimate interface, so the "socket.connect" immediately returns in

this case.

Instead of using the legitimate address, a "problematic" IPv6 address

used by socket.connect() will generate latency. "Problematic" means

"real world disruption" affecting and producing abnormal delays. Of

course, we don't know the set of "problematic" address, but we can

script socket.connect(xxx) in a loop with parameters "xxx" randomly

selected from the IPv6 address pool, and recording the connect(xxx)

return time in each loop instance. The average and 2nd derivations on

those anomalies will be very close to eyeball cost. Given enough of time

to run the script, it should discover the real world disruption areas,

and reflect the real user happiness during the IPv6 transition.

 

-gary

_______________________________________________

bmwg mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/bmwg

---

From: Andrew Yourtchenko <[email-masked]>
Date: Fri, 19 Nov 2010 02:20:23 +0100 (CET)

Chao, Gary,

I think the main emphasis of the document is to test the *application* as 
opposed to the badly behaving server.

If, as a user, I try to turn to an operator of the siteX, the frequent response 
is "it works for everyone else, check your setup".

Whereas the problem may even be caused by some totally unrelated party inbetwen.

So the focus is to put the finger on what can be controlled in the easiest 
fashion - the application. If the application picks up the "working" address by 
means of magic - the user experience does not suffer, and this is what the 
target is (as opposed to fixing the connectivity per se).

As for testing with the different addresses - that would not be the right test 
in my opinion. Because, when, as a user, I move from "good provider" to "bad 
provider" - the target address does not change when blackholed.

Application behaviour in case the addresses are different *may* vary - so that 
test would not adequately capture that in all the cases, in my opinion.

cheers,
andrew