Subject: Re: I-D ACTION:draft-ietf-ippm-owdp-00.txt

From: Ben Teitelbaum <[email-masked]>
Date: Fri, 01 Dec 2000 17:21:37 -0500

Tamas Varga wrote:
> 
> Dear Ben,
> 
> Ben Teitelbaum wrote:
> > These are both helpful suggestions. With respect to the first comment, it
> > would seem ideal to identify the Type-P explicitly during  session initiation
> > negotiation. However, since the notion of Type-P has not been formalized, I'm
> > not quite sure how to do include a Type-P identifier. Any suggestions?
> 
> As far as I understood Section 13 and 15 of RFC2330, type-P is a generic
> notation for the packet/service type we want to measure. The problem is
> that it can be substituted by different network, transport & application
> layer protocols and the information required to describe them depends
> on the protocol itself. But this is somewhat easier, since OWDP focuses
> on UDP based test packets only. I think three things may be interesting
> in the IP header: Type-of-Service (TOS), Time-to-time (TTL) and Don't
> Fragment (DF) bit. Filling up TOS with an appropriate DSCP would be useful
> to select packet treatment in a DiffServ network. TTL may limit the scope
> of the measurements. (Anyway, what is if a multicast destination address
> is specified? ). DF can be handy to ensure that the packet was transmitted
> in one piece, otherwise we won't know how many of the fragments were lost.
> 
> I think, setting DSCP is an essential feature. It should be included in
> the Ression-Request message. There is a room nearby the port field.
> The other two feautres may be handy, but it does not necesarily follow
> that we should include them.
> 

Tamas,

Although I like the idea of TTL and DF, I don't actually like the idea of
including DSCP explicitly. As the DiffServ working group has defined DSCPs,
they have only local significance. Instead, I think what we want is the 16-bit
RFC 2836 PHB identification code. This way, if you desire a particular PHB for
your session, you need not know what DSCP in the Session-Sender's local
environment is used to indicate it.

> > With respect to your second comment, I am open to including an option to allow
> > periodic sampling. We thought about supporting arbitrary distributions, but
> > decided to keep things simple by including Poisson only. Adding an option for
> > periodic sampling wouldn't add much complication, so I'm inclided to throw it
> > into the next draft.
> 
> Moreover uniform distribution can be useful, if we choose a random
> value from the (0, 1/Inv-Lambda) interval. Other distributions require
> more parameters, which makes the interpretation of the required fields
> complicated. Anyway, periodic sampling is still reasonable, allocation
> of 1 bit for this purpose is quite easy.

Just curious, in what circumstances is a uniform distribution useful?

> 
> Back to multicasting for a while. As I see, this question is not clarified
> yet in the document. I think it is silently assumed, that unicast test flows
> are used by the measurements. However, the architecture may be multicast
> aware if the Server is able to track Session-Receivers.

Yes, unicast was our silent assumption. As the document now stands, I don't
think it would be particularly difficult to extend it to support multicast. 
We would add an additional Receiver field to each record of the
Retrieve-Session response:

{SeqNo, ReceiverAddr, SendTimestamp, RecvTimestamp}

and then punt on exactly how a Server tracked Session-Receivers. 

-- 

                         ,,,

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