Subject: Agenda for IPPM in San Diego

From: "Matthew J Zekauskas" <[email-masked]>
Date: Fri, 1 Dec 2000 11:25:31 -0500

Proposed agenda for the IP Performance Metrics WG (ippm)

Tuesday, 12 December 2000, 17:00-18:00
======================================

Introduction of new co-chair & agenda bashing (<= 5 min)

Discuss the new charter and milestones (15 min)

Update on Bulk Transfer Capacity (10 min)
  --Mark Allman
    http://www.ietf.org/internet-drafts/draft-ietf-ippm-btc-framework-03.txt

Update on Network Performance Measurement for Periodic Streams (10 min)
  --Vilho Raisanen
    http://www.ietf.org/internet-drafts/draft-ietf-ippm-npmps-03.txt
    http://www.ietf.org/internet-drafts/draft-raisanen-ippm-npmps-results-00.txt
    (also http://www-nrc.nokia.com/netperf/results.pdf )

One-way delay protocol document discussion (10 min)
  -- Ben Teitelbaum
     http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-00.txt

Discussion of any issues with IPDV or loss patterns
  -- speakers TBD, at least the chairs & Phil Chimento.
     http://www.ietf.org/internet-drafts/draft-ietf-ippm-ipdv-05.txt
     http://www.ietf.org/internet-drafts/draft-ietf-ippm-loss-pattern-04.txt

--Matt

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Tue, 5 Dec 2000 12:50:55 +0100 (CET)

Ben, Matt,

>      http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-00.txt

I read the draft and have 2 major issues (besides a bunch of smaller
comments, which I'll post to the list as soon as I've decoded my own
handwriting in the margin).

1. The protocol assumes a setup mechanism for sessions.  We've always
   used a different approach: tell the sender that it should send 
   something to a target, tell the target that it should listen, but
   don't care if sender or target aren't ready yet.

   This has a practical advantage (it is much easier to implement) and
   a theoretical advantage: one can also easily measure losses over
   broken links (where a setup protocol will fail).  The disadvantage
   is that it is harder to raise alarms when packets don't arrive.

   Should we try to include this method in the protocol?

2. Padding and such.

   In order to avoid compression along the way, we use a random bit
   pattern  to pad the packets.  (If you have a packet with lots of
   zero's, it may be compressed by some intelligent device, and thus
   get a travel time corresponding to a much shorter packet.)
 
   Besides that, we also include much more info in our packets, such
   as NTP (clock) errors, experimental status words, source and 
   destination address, etc, etc.  In short, each packet contains
   everything we want to know about the packet, without having to
   rely on other data at source/target.  

   So, what we do is:
   * take N byte packet
   * Fill it with a random bit pattern.
   * Take a number between 0 and N-l (with l the number of bytes for
     all data).  
   * Put the data starting somewhere between 0 and N-l.
   * Make the 0th byte a pointer to the data.

   What I think we should put in the draft is a mechanism for this, even
   if implementations decide that they don't want to or need to use it.

(Perhaps we should sit down sometime before/after the meeting, since I
have a feeling that we won't be able to resolve these issues in the 10
minutes allocated for this draft).

Henk

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

A man can take a train and never reach his destination.
                                               (Kerouac, well before RFC2780).

---

From: Ben Teitelbaum <[email-masked]>
Date: Tue, 05 Dec 2000 08:55:37 -0500

Henk,

I'm not sure I understand point 1). With what we have written, a client could
request a session to begin at a future start time; the server can tell the
sender to send and the receiver to listen (the means by which the server tells
them is unspecified); then, if there is 100% packet loss at the time of the
scheduled session, this is captured. Does that work for you?

As for point 2), note that you can always run in Encrypted mode, which
effectively fills the entire packet payload with random bits.

Let's definitely sit down next week. 

Cheers,

-- 

                         ,,,

                        `o-o-  
                          <    Benjamin Teitelbaum
                           -   Advanced Network & Services, Inc.
                           .   Internet2

---

From: stanislav shalunov <[email-masked]>
Date: 05 Dec 2000 09:25:31 -0500

Henk,

The reason for the setup mechanisms is to allow for a wide range of
possible applications of the protocol.  A central notion is to be able
to run "open" servers--have a one-way ping.

> 2. Padding and such.

The reason padding isn't just supposed to be unspecified pseudo-random
is concern about high-bandwidth covert channels.  Depending on how
much of a concern it is for other people we can take different routes:

* Make it unspecified pseudo-random;

* Take pseudo-random bits from the same source as the one used to
  obtain inter-packet times;

* Use some well-defined source of pseudo-random bits, same for all
  flows.

-- 
Stanislav Shalunov <[email-masked]>	Internet Engineer, Internet2

Sex is the mathematics urge sublimated.                 -- M. C. Reed.

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Thu, 7 Dec 2000 22:53:13 +0100 (CET)

> to run "open" servers--have a one-way ping.

We basically have to solve 2 problems here:

a) How to do measurements with 2 different devices.  
   This requires that the packet formats are understandable by both sides.

b) How to set up a measurement relation between source and target.
  
A setup mechanism is one possible method to accomplish (b) but there are
lots of others and I don't think that we should limit ourselves to one
method unless there are convincing technical arguments.  This is something
we should really discuss by voice next week.

> is concern about high-bandwidth covert channels.

Please explain.

>  Depending on how

Isn't user data sent over a link random (when viewed by a machine)?

Henk

---

From: stanislav shalunov <[email-masked]>
Date: 07 Dec 2000 17:25:13 -0500

Henk,

I think nothing in the draft implies that OWDP-Test sessions have to
be set up with OWDP-Control only.  One can imagine situations when it
is convenient to set the sessions up using different means, and
retrieve the results using yet another method.

Of course, connection parameters have to be somehow transferred
anyway.

Should we explicitly mention the possibility of use of OWDP-Test
without OWDP-Control?  (In fact, if you make Server, Retrieve-Client
and Control-Client the same host in logical roles picture on p.3 of
-01, it collapses into set up without OWDP-Control.)

> > is concern about high-bandwidth covert channels.

I had in mind environments where covert channels can be viewed as a
problem (secretive commercial world, the military, etc.).
Low-bandwidth covert channels are of course always available in any
network, but unspecified padding of large packets could be used to
funnel data out of a network at a high rate.

After thinking about your comment and some internal discussion padding
is changed to unspecified pseudo-random with a message to implementers
to make available a switch for zero padding.

Does this address your concern?