Skip to main content

You're viewing an archived page. It is no longer being updated.

RIPE 47

RIPE Meeting:

47

Working Group:

Test Traffic

Status:

Final

Revision Number:

1


Test Traffic WG - RIPE47 - Amsterdam - 28/29 January 2004
---------------------------------------------------------

Chair: Alex Tudor (Agilent)
Scribes: Mark Santcroos & Ruben van Staveren (RIPE NCC)
Attendees: Slot 1: about 40,
Slot 2: about 30.

Slot 1, Wednesday January 28, 14:00-16:00

Agenda:
-------
1. Intro / Administrative Matters

* Scribe
* List of attendees
* Minutes
* Agenda Bashing

2. TTM developments at the RIPE NCC, Henk Uijterwaal, RIPE NCC

3. Delay Tomography: calculating estimations for network internal delays from
end-to-end TTM measurements, Jan-Pascal Best, TU Delft, NL

4. Traceroute quality improvements, Marnix Kaart, Delft, NL

5. SCoLE: Scalable Cooperative Latency Estimation, Michal Szymaniak, VU
Amsterdam

1. Intro / Administrative Matters
---------------------------------
Alex opens the meeting at 14:00 and welcomes all attendees. Mark
Santcroos & Ruben van Staveren volunteer to be scribes for both sessions.

The chair asks how attendees have read the minutes of the previous
session. A handful of people did read them. There were no comments on
the minutes on the mailing list or at the meeting and the chair proposes
to declare the minutes final. The attendees agree.

The chair points out that the usefulness of the meeting strongly depends
on the attendees. He asks for feedback on the program, either by private
conversation, in public or on the mailing list. Please don't be shy, the
success of the WG depends on you.

2. TTM developments at the RIPE NCC, Henk Uijterwaal, RIPE NCC
--------------------------------------------------------------

Slides will be available soon at:

http://www.ripe.net/ripe/meetings/ripe-47/presentations/index.html#tt

Henk presented the usual status update of TTM effort at the RIPE NCC.
The most important point is that effective 1/1/2004, the service fee rates
have been dropped to 1000 euro's/year for the first test box, 500 for any
further boxes. Also, the data disclosure policy has been changed, the new
version is available as RIPE document 300.

Q: What is the time lag in making the data available:
A: Immediately for the owner of the box, everyone else the following day.

Henk also presented the RISwhois tool.

Q: Can the riswhois tool be used to view in the past ?
A: The tool doesn't do that, but one can download RIS data for that

Finally, a long standing work item was finished, the so-called 2NIC
project, was finished. This allows a user to give a test box a second IPv4
address and measure along different paths.

Q: Regarding 2NIC, does the 2nd address in a testbox require a 2nd NIC ?
A: Yes. However, the 1u test-box has 2 NIC's in the standard
configuration, in the 4u model one has to add a card.

There where no further questions at the end of the talk.

Alex emphasizes the use of TTM in your business when the AUP opens up: think
about applications.


3. Delay Tomography: calculating estimations for network internal delays
from end-to-end TTM measurements, Jan-Pascal Best, TU Delft, NL
-------------------------------------------------------------------------

Slides at:
http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-tt-tudelt.pdf

The first results on their We present the first results of our work on
network delay tomography, mathematical methods to derive internal delays
from the Test Traffic end-to-end delay measurements were presented. This
analysis method could be employed to generate more detailed automated
warning notofications.

Q: How much of the data do you use?
A: It's a lot of data, we are dropping a lot of non-useful data, like failed
traceroutes

Q: How long does it take to process?
A: A few hours currently. depends on memory and such

Q: Would it help to calibrate if people could supply you with numbers of
known links
A: A little

There was some discussion about the Distribution of error from synthesized
delay graph.

4. Traceroute quality improvements, Marnix Kaart, Delft, NL
-----------------------------------------------------------
This talk had to be cancelled as the speaker was ill.

5. SCoLE: Scalable Cooperative Latency Estimation,
Michal Szymaniak, VU Amsterdam
--------------------------------------------------

Slides at:
http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-tt-scole.pdf

This paper discusses SCoLE, a scalable system to estimate Internet
latencies. SCoLE is based on GNP, which models Internet latencies in an
N-dimensional Euclidean space. In contrast to GNP and other GNP-based
systems, however, SCoLE does not employ any global space whose parameters
must typically be negotiated by the participating hosts. Instead, it
allows each host to construct its ``private'' space and model inter-host
latencies in that space. The private space parameters as well as the
modeling algorithm can be adjusted on a per-host basis, which improves
system flexibility. More importantly, the mutual independence of private
spaces results in higher SCoLE scalability, which is bound neither by the
global negotiation of space parameters nor by global knowledge of any
kind. We show that latency estimates performed in different private spaces
are highly correlated. This allows SCoLE to be used in large-scale
applications where consistent latency estimates need to be performed
simultaneously by many independent hosts.

Q: About the error margin ... 50 precent seems a bit high.
Do you have plans about getting that down?
A: It's estimation, but the answer is that it all depends on the landmarks.
4 papers discussing the possible location of the landmarks, this is
still research

A remark was made that this technology could be an alternative to the Akamai
technology

Q: How do you calculate the RTT from a webserver
A: We use the TCP connection setup to measure it?

Q: As an example, when the HTTP application is used on TTM boxes, how many
traffic would it generate ?
A: depends


The Test Traffic session for Wednesday was concluded by a demo from
Jan-Pascal


Slot 2, Thursday 29 January 2004, 11:00-12:30

Agenda:
-------

6. Inline measurements: Exploiting IPv6 programmability,
Francisco Garcia, Agilent Labs, UK

7. Reordering of IP Packets in Internet, Xiaoming Zhou, TU Delft

8. AOB

Chair asks how many people currently present here owns a testbox, about
4 or 5 reactions.



6. Inline measurements: Exploiting IPv6 programmability,
Francisco Garcia, Agilent Labs, UK
--------------------------------------------------------

Slides at:
http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-tt-mpower.pdf


Discussion on timestamping issues:

Q: How do you handle the tail in the delay distribution?
A: Default ways, it still is a "problem" for us, as it is for others.

On the use of extension headers:

Q: Have you studied extension headers making the packets to big?
A: Lower the MTU, so we can handle TCP size.

Q: Have you considered using application level added headers.
A: Yes, but we want to use something mainstream.


7. Reordering of IP Packets in Internet, Xiaoming Zhou, TU Delft
----------------------------------------------------------------

Slides at:
http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-reordering-tt.pdf

The authors have analyzed the measurements of the end-to-end packet
reordering by tracing UDP packets between 12 testboxes of RIPE NCC. We
showed that reordering quite often happens in Internet. For bursts of 50
100-byte UDP packets, there were about 56% of all the streams arrived at
the destinations out-of-order. We studied the extent of the reordering in
these streams, and observed most reordered streams have a relative small
number of reordered packets: about 14% of all the streams have more than 2
reordered packets in a bursts of 50 UDP packets. In addition, we showed
that packet reordering has a significant impact on UDP performance since
the reordering add a high cost of recovering from the reordering on the
end host. On the other hand, packet reordering does not have a significant
impact on the UDP delay. We also compared the reordered stream ratios in
the different directions of Internet paths, and observed that reordered
stream ratios are asymmetric, but they vary largely from
testbox-to-testbox.

A comment was made that for for VOIP reordering is not important, as long
as your within the limits of your receiving buffer. There was no real
conclusion about this.

8. AOB
------

Henk asked the WG if some of the topics discussed here should be taken up
by the WG.

- OWAMP, should this be added to the TTM service. Implementing it is
a considerable amount of work but it would improve the usefulness of
the service as well.
- SCoLe, Delay Tomography: should the NCC make these tools available or
play any other role there?

He invited comments, either by private mail or on the mailing list.

The chair suggested to do a session on "how I use my test-box" with short
presentations from a number of TB owners. There were a few volunteers
during the meeting. Alex will discuss details with him offline.