Subject: RE: [ippm] test packet size over IP network

From: "STEPHAN Emile FTRD/DAC/LAN" <[email-masked]>
Date: Fri, 26 Jul 2002 09:23:56 +0200

As far as I am concern you have to use packets sizes corresponding to
those send by the application monitored.
regards
emile

> -----Message d'origine-----
> De : raymond zhang [mailto:[email-masked]]
> Envoye : jeudi 25 juillet 2002 19:54
> A : Matthew J Zekauskas
> Cc : [email-masked]
> Objet : Re: [ippm] test packet size over IP network
> 
> 
> At 12:35 PM 7/25/2002 -0400, you wrote:
> >>I wonder if anyone can provide some references or input in 
> selecting test
> >>packet size for measuring one-way-delay.
> >
> >draft-ietf-ippm-owmetric-as-00.txt is a (very) initial 
> attempt to try to
> >address this, among other issues.
> >
> >As always, "it depends on what you are trying to measure".
> >
> >I can tell you what the two systems I know well do.  The 
> Surveyor system
> >used minimal-sized UDP packets, which in our case was 12 
> bytes (so the
> >physical packet size adds the UDP, IP, and any MAC header).  
> The RIPE-TT
> >system used 100 byte UDP packets the last time I looked.
> >
> >The idea behind small packets was to not send significant 
> traffic, and just
> >get a broad overview of the network's health.
> 
> If this is the goal, then the smaller test probe packets 
> seems to be a 
> better choice without putting whole of traffic over the 
> network.   Private 
> IP networks seem to have bigger average packet sizes than ones in the 
> public internet so 64 byte packet may be too small so 100 
> byte (including 
> payload, udp and ip) seems to be the balance.
> 
> 
> >I'd be interested in what other vendors use and why (I know there are
> >a few on the list).
> >'
> 
> 
> I'd also be interested in what other SPs use as well...
> 
> 
> >--Matt
> 
> 
> _______________________________________________
> ippm mailing list
> [email-masked]
> http://mailhost.advanced.org/mailman/listinfo/ippm
> 

_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Fri, 26 Jul 2002 10:06:05 +0200 (CEST)

> those send by the application monitored.

Well, yes and no.

The first question is how the network treats big and small packets.  When
I first started to compare results from Surveyor (40 bytes back then) and
our TTM service (100 bytes), I discovered a difference even when both
systems measured along the same path.  Further investigation showed that
the delay a packet takes scales as (as expected):

  d_0 + B/T

with B the size in bytes, for B smaller than the MTU (at which point
packets are either fragmented or dropped), d_0 the delay that a packet of
0 bytes would take, and T the throughput of the connection.

If this is the case, then there is no reason to vary the packet size for
one-way-delay measurements.  In fact, it only makes it harder to analyze
the data afterwards and/or use it for derived metrics such as IPDV, where
all packets have to be of the same size.

Most applications send packets of variable size.  In case one wants to
know the delay distribution for this application, use packet sampling to
determine the distribution of the packets sent by this application.  Then
take the delay distribution for fixed size packets.  Then convolute the
two.  This is fairly straightforward.  The opposite operation isn't.

However, one of my customers mentioned that in the very recent optical
fiber equipment he is using, it appeared as if small packets get
preferential treatement over big packets (presumably because it helps
overall performance if small ACK packets arrive as fast as possible, while
big chunks of data can wait a bit).

In this case, it does make sense to do measurements with 2 (or more)
sizes, one smaller and one bigger than the threshold for preferential
treatement. I haven't been able to verify this claim myself though.

BTW. For the draft, I'm still interested to hear what people use and why.

Henk

> > I'd also be interested in what other SPs use as well...

------------------------------------------------------------------------------
Henk Uijterwaal                    Email: [email-masked]
RIPE Network Coordination Centre     WWW: http://www.ripe.net/home/henk
Singel 258                         Phone: +31.20.5354414
1016 AB Amsterdam                    Fax: +31.20.5354445
The Netherlands                   Mobile: +31.6.55861746
------------------------------------------------------------------------------

That problem that we weren't having yesterday, is it better? (Big ISP NOC)

NOTE: My email address (and a hole in our mailing list software) is being
      abused by a spammer.  We are working on fixing this hole and tracking
      the spammer down.  If you receive mail from "[email-masked]" that is
      obviously spam, please send me a copy of the mail including ALL headers.
      I'm sorry for any inconvenience caused by this.

---

From: stanislav shalunov <[email-masked]>
Date: 26 Jul 2002 14:59:06 -0400

>   d_0 + B/T

A note: Some line cards designs have buffer pools of different sizes.
This can lead to loss being different for different packet size.

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

All revolutions are bloody.  The October Revolution was bloodless,
but it was only the beginning.               -- Dmitri Volkogonov
_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm