From test-admin@advanced.org Thu Mar 1 06:52:21 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29772 for ; Thu, 1 Mar 2001 06:52:21 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f21BqKn09831 for ; Thu, 1 Mar 2001 06:52:20 -0500 Date: Thu, 1 Mar 2001 06:52:20 -0500 Message-Id: <200103011152.f21BqKn09831@mailhost.advanced.org> Subject: advanced.org mailing list memberships reminder From: mailman-owner@advanced.org To: ippm-archive@ietf.org X-No-Archive: yes Sender: test-admin@advanced.org Errors-To: test-admin@advanced.org X-BeenThere: test@mailhost.advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: This is a reminder, sent out once a month, about your advanced.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ippm-request@advanced.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@advanced.org. Thanks! Passwords for ippm-archive@lists.ietf.org: List Password // URL ---- -------- ippm@advanced.org jTPE http://mailhost.advanced.org/mailman/options/ippm/ippm-archive@lists.ietf.org From ippm-admin@advanced.org Thu Mar 1 08:41:00 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03309 for ; Thu, 1 Mar 2001 08:40:59 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f21DaMn02688; Thu, 1 Mar 2001 08:36:22 -0500 Received: from bacardi.torrentnet.com (bacardi.torrentnet.com [198.78.51.104]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f21DV6n01986 for ; Thu, 1 Mar 2001 08:31:06 -0500 Received: from torrentnet.com (campari.torrentnet.com [198.78.51.168]) by bacardi.torrentnet.com (8.10.2/8.10.2) with ESMTP id f21DV2k18262; Thu, 1 Mar 2001 08:31:02 -0500 (EST) Message-ID: <3A9E4F16.EAE9AB30@torrentnet.com> Date: Thu, 01 Mar 2001 08:31:02 -0500 From: "P.F. Chimento" Reply-To: chimento@torrentnet.com Organization: Ericsson IP Infrastructure X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: internet-drafts@ietf.org, ippm@advanced.org Content-Type: multipart/mixed; boundary="------------AF1DA5098BAD14AE02CC5AB3" Subject: [ippm] Editorial update to draft-ietf-ippm-ipdv-06.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List This is a multi-part message in MIME format. --------------AF1DA5098BAD14AE02CC5AB3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Attached is an editorial update (version -07) of draft-ietf-ippm Regards, Phil Chimento -- Phil Chimento Ericsson IPI Phone: 240-314-3597 7301 Calhoun Place chimento@torrentnet.com Rockville, Md. 20855 ----------------------------------------------------- --------------AF1DA5098BAD14AE02CC5AB3 Content-Type: text/plain; charset=us-ascii; name="draft-ietf-ippm-ipdv-07.txt" Content-Disposition: inline; filename="draft-ietf-ippm-ipdv-07.txt" Content-Transfer-Encoding: 7bit Network Working Group C. Demichelis INTERNET-DRAFT CSELT Expiration Date: August 2001 P. Chimento Ericsson IPI February 2001 IP Packet Delay Variation Metric for IPPM 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft shadow directories can be accessed at http://www.ietf.org/shadow.html This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Demichelis and Chimento Expires August 2001 [Page 1] INTERNET-DRAFT IP Packet Delay Variation February 2001 2. Abstract This memo refers to a metric for variation in delay of packets across Internet paths. The metric is based on the difference in the One-Way- Delay of selected packets. This difference in delay is called "IP Packet Delay variation." The metric is valid for measurements between two hosts both in the case that they have synchronized clocks and in the case that they are not synchronized. We discuss both in this draft. 3. Introduction This memo is based on "A One-Way-Delay metric for IPPM", RFC 2679 [2]. Part of the text in this memo is taken directly from that document. This memo defines a metric for variation in delay of packets that flow from one host to another one through an IP path. This quantity is sometimes called "jitter". This term, however, causes confusion because it is used in different ways by different groups of people. "Jitter" commonly has two meanings: The first meaning is the variation of a signal with respect to some clock signal, where the arrival time of the signal is expected to coincide with the arrival of the clock signal. The second meaning has to do with the variation of a metric (e.g. delay) with respect to some reference metric (e.g. average delay or minimum delay). The first meaning is used with reference to synchronous signals and might be used to measure the quality of circuit emulation, for example. There is also a metric called "wander" used in this context. The second meaning is frequently used by computer scientists and frequently (but not always) refers to variation in delay. In this document we will avoid the term "jitter" whenever possible and stick to delay variation which is more precise. Demichelis and Chimento Expires August 2001 [Page 2] INTERNET-DRAFT IP Packet Delay Variation February 2001 3.1. Definition A definition of the IP Packet Delay Variation (ipdv) can be given for packets inside a stream of packets. The IP Packet Delay Variation (ipdv) of a pair of packets within a stream of packets is defined for a selected pair of packets in the stream going from measurement point MP1 to measurement point MP2 is the difference between the one-way-delay of the first of the selected packets and the one-way-delay of the second of the selected packets. 3.2. Motivation One important use of delay variation is the sizing of playout buffers for applications requiring the regular delivery of packets (for example, voice or video playout). What is normally important in this case is the maximum delay variation, which is used to size playout buffers for such applications [6]. Other uses of a delay variation metric are, for example, to determine the dynamics of queues within a network (or router) where the changes in delay variation can be linked to changes in the queue length process at a given link or a combination of links. In addition, this type of metric is particularly robust with respect differences and variations of the clocks of the two hosts. This allows the use of the metric even if the two hosts that support the measurement points are not synchronized. In the latter case indications of reciprocal skew of the clocks can be derived from the measurement and corrections are possible. The related precision is often comparable with the one that can be achieved with synchronized clocks, being of the same order of magnitude of synchronization errors. This will be discussed below. The scope of this document is to provide a way to measure the ipdv delivered on a path. Our goal is to provide a metric which can be parameterized so that it can be used for various purposes. Any report of the metric MUST include all the parameters associated with it so that the conditions and meaning of the metric can be determined exactly. We specifically do not specify particular values of the metrics that IP networks must meet. The flexibility of the metric can be viewed as a disadvantage but there are some arguments for making it flexible. First, though there are some uses of ipdv mentioned above, to some degree the uses of ipdv are still a research topic and some room should be left for experimentation. Secondly, there are different views in the community of what precisely the definition should be (e.g. [7],[8],[9]). The Demichelis and Chimento Expires August 2001 [Page 3] INTERNET-DRAFT IP Packet Delay Variation February 2001 idea here is to parameterize the definition, rather than write a different draft for each proposed definition. As long as all the parameters are reported, it will be clear what is meant by a particular use of ipdv. All the remarks in the draft hold, no matter which parameters are chosen. 3.3. General Issues Regarding Time Everything contained in the Section 2.2. of [2] applies also in this case. To summarize: As in [1] we define "skew" as the first derivative of the offset of a clock with respect to "true time" and define "drift" as the second derivative of the offset of a clock with respect to "true time". From there, we can construct "relative skew" and "relative drift" for two clocks C1 and C2 with respect to one another. These are natural extensions of the basic framework definitions of these quantities: + Relative offset = difference in clock times + Relative skew = first derivative of the difference in clock times + Relative drift = second derivative of the difference in clock times NOTE: The drift of a clock, as it is above defined over a long period must have an average value that tends to zero while the period becomes large since the frequency of the clock has a finite (and small) range. In order to underline the order of magnitude of this effect,it is considered that the maximum range of drift for commercial crystals is about 50 part per million (ppm). Since it is mainly connected with variations in operating temperature (from 0 to 70 degrees Celsius), it is expected that a host will have a nearly constant temperature during its operation period, and variations in temperature, even if quick, could be less than one Celsius per second, and range in the order of few degrees. The total range of the drift is usually related to variations from 0 to 70 Celsius. These are important points for evaluation of precision of ipdv measurements, as will be seen below. Demichelis and Chimento Expires August 2001 [Page 4] INTERNET-DRAFT IP Packet Delay Variation February 2001 4. A singleton definition of a One-way ipdv metric The purpose of the singleton metric is to define what a single instance of an ipdv measurement is. Note that it can only be statistically significant in combination with other instances. It is not intended to be meaningful as a singleton, in the sense of being able to draw inferences from it. This definition makes use of the corresponding definition of type-P- One-Way-Delay metric [2]. This section makes use of those parts of the One-Way-Delay Draft that directly apply to the One-Way-ipdv metric, or makes direct references to that Draft. 4.1. Metric name Type-P-One-way-ipdv 4.2. Metric parameters + Src, the IP address of a host + Dst, the IP address of a host + T1, a time + T2, a time + L, a packet length in bits. The packets of a Type P packet stream from which the singleton ipdv metric is taken MUST all be of the same length. + F, a selection function defining unambiguously the two packets from the stream selected for the metric. + I1,I2, times which mark that beginning and ending of the interval in which the packet stream from which the singleton measurement is taken occurs. + P, the specification of the packet type, over and above the source and destination addresses Demichelis and Chimento Expires August 2001 [Page 5] INTERNET-DRAFT IP Packet Delay Variation February 2001 4.3. Metric unit The value of a Type-P-One-way-ipdv is either a real number of seconds (positive, zero or negative) or an undefined number of seconds. 4.4. Definition We are given a Type P packet stream and I1 and I2 such that the first Type P packet to pass measurement point MP2 after I1 is given index 0 and the last Type P packet to pass measurement point MP2 before I2 is given the highest index number. Type-P-One-way-ipdv is defined for two packets from Src to Dst selected by the selection function F, as the difference between the value of the type-P-One-way- delay from Src to Dst at T2 and the value of the type-P-One-Way-Delay from Src to Dst at T1. T1 is the wire-time at which Scr sent the first bit of the first packet, and T2 is the wire-time at which Src sent the first bit of the second packet. This metric is derived from the One-Way-Delay metric. T2 denote the wire times of the packets sent from Src to Dst. Therefore, for a real number ddT "The type-P-one-way-ipdv from Src to Dst at T1, T2 is ddT" means that Src sent two packets, the first at wire-time T1 (first bit), and the second at wire-time T2 (first bit) and the packets were received by Dst at wire-time dT1+T1 (last bit of the first packet), and at wire-time dT2+T2 (last bit of the second packet), and that dT2-dT1=ddT. "The type-P-one-way-ipdv from Src to Dst at T1,T2 is undefined" means that Src sent the first bit of a packet at T1 and the first bit of a second packet at T2 and that Dst did not receive one or both packets. 4.5. Discussion This metric definition depends on a stream of Type-P-One-Way-Delay packets that have been measured. In general this can be a stream of two or more packets, delimited by the interval endpoints I1 and I2. There must be a stream of at least two packets in order for a singleton ipdv measurement to take place. The purpose of the selection function is to specify exactly which two packets from the stream are to be used for the singleton measurement. Note that the selection function may involve observing the one-way-delay of all the Type P packets of the stream in the specified interval. Examples of a selection function are: Demichelis and Chimento Expires August 2001 [Page 6] INTERNET-DRAFT IP Packet Delay Variation February 2001 + Consecutive Type-P packets within the specified interval + Type-P packets with specified indices within the specified interval + Type-P packets with the min and max one-way-delays within the specified interval + Type-P packets with specified indices from the set of all defined (i.e. non-infinite) one-way-delays Type-P packets within the specified interval. The following practical issues have to be considered: + Being a differential measurement, this metric is less sensitive to clock synchronization problems. This issue will be more carefully examined in section 7 of this memo. It is pointed out that, if the relative clock conditions change in time, the accuracy of the measurement will depend on the time interval I2-I1 and the magnitude of possible errors will be discussed below. + A given methodology will have to include a way to determine whether a delay value is infinite or whether it is merely very large (and the packet is yet to arrive at Dst). As noted by Mahdavi and Paxson, simple upper bounds (such as the 255 seconds theoretical upper bound on the lifetimes of IP packets [Postel: RFC 791]) could be used, but good engineering, including an understanding of packet lifetimes, will be needed in practice. Comment: Note that, for many applications of these metrics, the harm in treating a large delay as infinite might be zero or very small. A TCP data packet, for example, that arrives only after several multiples of the RTT may as well have been lost. + As with other 'type-P' metrics, the value of the metric may depend on such properties of the packet as protocol,(UDP or TCP) port number, size, and arrangement for special treatment (as with IP precedence or with RSVP). + If the packet is duplicated along the path (or paths!) so that multiple non-corrupt copies arrive at the destination, then the packet is counted as received, and the first copy to arrive determines the packet's One-Way-Delay. + If the packet is fragmented and if, for whatever reason, reassembly does not occur, then the packet will be deemed lost. Demichelis and Chimento Expires August 2001 [Page 7] INTERNET-DRAFT IP Packet Delay Variation February 2001 It is assumed that the Type-P packet stream is generated according to the Poisson sampling methodology described in [1]. 4.6. Methodologies As with other Type-P-* metrics, the detailed methodology will depend on the Type-P (e.g., protocol number, UDP/TCP port number, size, precedence). The measurement methodology described in this section asssumes the measurement and determination of ipdv in real-time as part of an active measurement. Note that this can equally well be done a posteriori, i.e. after the one-way-delay measurement is completed. Generally, for a given Type-P, the methodology would proceed as follows: + The need of synchronized clocks for Src and Dst will be discussed later. Here a methodology is supposed that is based on synchronized clocks. + After time I1, start. At the Src host, select Src and Dst IP addresses, and form test packets of Type-P with these addresses according to a given technique (e.g. the Poisson sampling technique). Any 'padding' portion of the packet needed only to make the test packet a given size should be filled with randomized bits to avoid a situation in which the measured delay is lower than it would otherwise be due to compression techniques along the path. + At the Dst host, arrange to receive the packets. + At the Src host, place a timestamp in the Type-P packet, and send it towards Dst. + If the packet arrives within a reasonable period of time, take a timestamp as soon as possible upon the receipt of the packet. By subtracting the two timestamps, an estimate of One-Way-Delay can be computed. + If the packet meets the selection function criterion for the first packet, record this first delay value. Otherwise, continue generating the Type-P packet stream as above until the criterion is met or I2, whichever comes first. + At the Src host, packets continue to be generated according to the given methodology. The Src host places a timestamp in the Type-P packet, and send it towards Dst. Demichelis and Chimento Expires August 2001 [Page 8] INTERNET-DRAFT IP Packet Delay Variation February 2001 + If the packet arrives within a reasonable period of time, take a timestamp as soon as possible upon the receipt of the packet. By subtracting the two timestamps, an estimate of One-Way-Delay can be computed. + If the packet meets the criterion for the second packet for the second packet, then by subtracting the second value of One-Way- Delay from the first value the ipdv value of the pair of packets is obtained. Otherwise, packets continue to be generated until the criterion for the second packet is fulfilled or I2, whichever comes first. + If one or both packets fail to arrive within a reasonable period of time, the ipdv is taken to be undefined. 4.7. Errors and Uncertainties In the singleton metric of ipdv, factors that affect the measurement are the same as those affecting the One-Way-Delay measurement, even if, in this case, the influence is different. The Framework document [1] provides general guidance on this point, but we note here the following specifics related to delay metrics: + Errors/uncertainties due to uncertainties in the clocks of the Src and Dst hosts. + Errors/uncertainties due to the difference between 'wire time' and 'host time'. Each of these errors is discussed in more detail in the following paragraphs. 4.7.1. Errors/Uncertainties related to Clocks If, as a first approximation, the error that affects the first measurement of One-Way-Delay were the same as the one affecting the second measurement, they will cancel each other when calculating ipdv. The residual error related to clocks is the difference of the errors that are supposed to change from time T1, at which the first measurement is performed, to time T2 at which the second measurement is performed. Synchronization, skew, accuracy and resolution are here considered with the following notes: + Errors in synchronization between source and destination clocks contribute to errors in both of the delay measurements required for calculating ipdv. Demichelis and Chimento Expires August 2001 [Page 9] INTERNET-DRAFT IP Packet Delay Variation February 2001 + The effect of drift and skew errors on ipdv measurements can be quantified as follows: Suppose that the skew and drift functions are known. Assume first that the skew function is linear in time. Clock offset if then also a function of time and the error evolves as e(t) = K*t + O, where K is a constant and O is the offset at time 0. In this case, the error added to the subtraction two different time stamps (t2 > t1) is e(t2)-e(t1) = K*(t2 - t1) which will be added to the time difference (t2 - t1). If the drift cannot be ignored, but we assume that the drift is a linear function of time, then the skew is given by s(t) = M*(t**2) + N*t + S0, where M and N are constants and S0 is the skew at time 0. The error added by the variable skew/drift process in this case becomes e(t) = O + s(t) and the error added to the difference in time stamps is e(t2)-e(t1) = N*(t2-t1) + M*{(t2-t1)**2}. It is the claim here (see remarks in section 3.3) that the effects of skew are rather small over the time scales that we are discussing here, since temperature variations in a system tend to be slow relative to packet inter-transmission times and the range of drift is so small. + As far as accuracy and resolution are concerned, what is noted in the one-way-delay document [2] in section 3.7.1, applies also in this case, with the further consideration, about resolution, that in this case the uncertainty introduced is two times the one of a single delay measurement. Errors introduced by these effects are often larger than the ones introduced by the drift. 4.7.2. Errors/uncertainties related to Wire-time vs Host-time The content of sec. 3.7.2 of [2] applies also in this case, with the following further consideration: The difference between Host-time and Wire-time can be in general decomposed into two components, of which one is constant and the other is variable. Only the variable components will produce measurement errors, while the constant one will be canceled while calculating ipdv. However, in most cases, the fixed and variable components are not known exactly. Demichelis and Chimento Expires August 2001 [Page 10] INTERNET-DRAFT IP Packet Delay Variation February 2001 5. Definitions for Samples of One-way ipdv The goal of the sample definition is to make it possible to compute the statistics of sequences of ipdv measurements. The singleton definition is applied to a stream of test packets generated according to a pseudo-random Poisson process with average arrival rate lambda. If necessary, the interval in which the stream is generated can be divided into sub-intervals on which the singleton definition of ipdv can be applied. The result of this is a sequence of ipdv measurements that can be analyzed by various statistical procedures. Starting from the definition of the singleton metric of one-way ipdv, we define a sample of such singletons. In the following, the two packets needed for a singleton measurement will be called a "pair". 5.1. Metric name Type-P-One-way-ipdv-Poisson-stream 5.2. Parameters + Src, the IP address of a host + Dst, the IP address of a host + T0, a time + Tf, a time + lambda, a rate in reciprocal seconds + L, a packet length in bits. The packets of a Type P packet stream from which the sample ipdv metric is taken MUST all be of the same length. + F, a selection function defining unambiguously the packets from the stream selected for the metric. + I(i),I(i+1), i >=0, pairs of times which mark the beginning and ending of the intervals in which the packet stream from which the measurement is taken occurs. I(0) >= T0 and assuming that n is the largest index, I(n) <= Tf. + P, the specification of the packet type, over and above the source and destination addresses Demichelis and Chimento Expires August 2001 [Page 11] INTERNET-DRAFT IP Packet Delay Variation February 2001 5.3. Metric Units: A sequence of triples whose elements are: + T1, T2,times + dT a real number or an undefined number of seconds 5.4. Definition A pseudo-random Poisson process is defined such that it begins at or before T0, with average arrival rate lambda, and ends at or after Tf. Those time values T(i) greater than or equal to T0 and less than or equal to Tf are then selected for packet generation times. Each packet falling within one of the sub-intervals I(i), I(i+1) is tested to determine whether it meets the criteria of the selection function F as the first or second of a packet pair needed to compute ipdv. The sub-intervals can be defined such that a sufficient number of singleton samples for valid statistical estimates can be obtained. The triples defined above consist of the transmission times of the first and second packets of each singleton included in the sample, and the ipdv in seconds. 5.5. Discussion Note first that, since a pseudo-random number sequence is employed, the sequence of times, and hence the value of the sample, is not fully specified. Pseudo-random number generators of good quality will be needed to achieve the desired qualities. The sample is defined in terms of a Poisson process both to avoid the effects of self-synchronization and also capture a sample that is statistically as unbiased as possible. There is, of course, no claim that real Internet traffic arrives according to a Poisson arrival process. The sample metric can best be explained with a couple of examples: For the first example, assume that the selection function specifies the "non-infinite" max and min one-way-delays over each sub-interval. We can define contiguous sub-intervals of fixed specifiec length and produce a sequence each of whose elements is the triple which is collected for each sub-interval. A second example is the selection function that specifies packets whose Demichelis and Chimento Expires August 2001 [Page 12] INTERNET-DRAFT IP Packet Delay Variation February 2001 indices (sequence numbers) are just the integers below a certain bound. In this case, the sub-intervals are defined by the transmission times of the generated packets and the sequence produced is just where D(i) denotes the one-way delay of the ith packet of a stream. This definition of the sample metric encompasses both the definition proposed in [8] and the one proposed in [9]. 5.6. Methodology Since packets can be lost or duplicated or can arrive in a different order than the order sent, in order to recognize the pairs of test packets, they should be marked with a sequence number. For duplicated packets only the first received copy should be considered. Otherwise, the methodology is the same as for the singleton measurement, with the exception that the singleton measurement is repeated a number of times. 5.7. Errors and uncertainties The same considerations apply that have been made about the singleton metric. Additional error can be introduced by the pseudo-random Poisson process as discussed in [2]. Further considerations will be given in section 7. 6. Statistics for One-way-ipdv Some statistics are suggested which can provide useful information in analyzing the behavior of the packets flowing from Src to Dst. The statistics are assumed to be computed from an ipdv sample of reasonable size. The purpose is not to define every possible statistic for ipdv, but ones which have been proposed or used. 6.1. Lost Packets and ipdv statistics The treatment of lost packets as having "infinite" or "undefined" delay complicates the derivation of statistics for ipdv. Specifically, when packets in the measurement sequence are lost, simple statistics such as sample mean cannot be computed. One possible approach to handling this problem is to reduce the event space by conditioning. That is, we consider conditional statistics; Demichelis and Chimento Expires August 2001 [Page 13] INTERNET-DRAFT IP Packet Delay Variation February 2001 namely we estimate the mean ipdv (or other derivative statistic) conditioned on the event that selected packet pairs arrive at the destination (within the given timeout). While this itself is not without problems (what happens, for example, when every other packet is lost), it offers a way to make some (valid) statements about ipdv, at the same time avoiding events with undefined outcomes. In practical terms, what this means is throwing out the samples where one or both of the selected packets has an undefined delay. The sample space is reduced (conditioned) and we can compute the usual statistics, understanding that formally they are conditional. 6.2. Distribution of One-way-ipdv values The one-way-ipdv values are limited by virtue of the fact that there are upper and lower bounds on the one-way-delay values. Specifically, one-way-delay is upper bounded by the value chosen as the maximum beyond which a packet is counted as lost. It is lower bounded by propagation, transmission and nodal transit delays assuming that there are no queues or variable nodal delays in the path. Denote the upper bound of one-way-delay by U and the lower bound by L and we see that one-way-ipdv can only take on values in the (open) interval (L- U, U-L). In any finite interval, the one-way-delay can vary monotonically (non-increasing or non-decreasing) or of course it can vary in both directions in the interval, within the limits of the half-open interval [L,U). Accordingly, within that interval, the one-way-ipdv values can be positive, negative, or a mixture (including 0). Since the range of values is limited, the one-way-ipdv cannot increase or decrease indefinitely. Suppose, for example, that the ipdv has a positive 'run' (i.e. a long sequence of positive values). At some point in this 'run', the positive values must approach 0 (or become negative) if the one-way-delay remains finite. Otherwise, the one-way-delay bounds would be violated. If such a run were to continue infinitely long, the sample mean (assuming no packets are lost) would approach 0 (because the one-way-ipdv values must approach 0). Note, however, that this says nothing about the shape of the distribution, or whether it is symmetric. Note further that over significant intervals, depending on the width of the interval [L,U), that the sample mean one-way-ipdv could be positive, negative or 0. There are basically two ways to represent the distribution of values of an ipdv sample: an empirical pdf and an empirical cdf. The empirical pdf is most often represented as a histogram where the range of values of an ipdv sample is divided into bins of a given Demichelis and Chimento Expires August 2001 [Page 14] INTERNET-DRAFT IP Packet Delay Variation February 2001 length and each bin contains the proportion of values falling between the two limits of the bin. (Sometimes instead the number of values falling between the two limits is used). The empirical cdf is simply the proportion of ipdv sample values less than a given value, for a sequence of values selected from the range of ipdv values. 6.3. Type-P-One-way-ipdv-percentile Given a Type-P One-Way-ipdv sample and a percent X between 0% and 100%, the Xth percentile of all ipdv values in the sample. The 50th percentile is the median. 6.4. Type-P-One-way-ipdv-inverse-percentile Given a Type-P-One-way-ipdv sample and a given value Y, the percent of ipdv sample values less than or equal to Y. 6.5. Type-P-One-way-ipdv-jitter Although the use of the term "jitter" is deprecated, we use it here following the authors in [7]. In that document, the selection function specifies that consecutive packets of the Type-P stream are to be selected for the packet pairs used in ipdv computation. They then take the absolute value of the ipdv values in the sample. The authors in [7] use the resulting sample to compare the behavior of two different scheduling algorithms. 6.6. Type-P-One-way-peak-to-peak-ipdv In this case, the selection function used in collecting the Type-P- One-Way-ipdv sample specifies that the first packet of each pair to be the packet with the maximum Type-P-One-Way-Delay in each sub- interval and the second packet of each pair to be the packet with the minimum Type-P-One-Way-Delay in each sub-interval. The resulting sequence of values is the peak-to-peak delay variation in each sub- interval of the measurement interval. Demichelis and Chimento Expires August 2001 [Page 15] INTERNET-DRAFT IP Packet Delay Variation February 2001 7. Discussion of clock synchronization This section gives some considerations about the need of having synchronized clocks at the source and destination. These considerations are given as a basis for discussion and they require further investigation. 7.1. Effects of synchronization errors Clock errors can be generated by two processes: the relative drift and the relative skew of two given clocks. We should note that drift is physically limited and so the total relative skew of two clocks can vary between an upper and a lower bound. Suppose then that we have a measurement between two systems such that the clocks in the source and destination systems have at time 0 a relative skew of s(0) and after a measurement interval T have skew s(T). We assume that the two clocks have an initial offset of O (that is letter O). Now suppose that the packets travel from source to destination in constant time, in which case the ipdv is zero and the difference in the timestamps of the two clocks is actually just the relative offset of the clocks. Suppose further that at the beginning of the measurement interval the ipdv value is calculated from a packet pair and at the end of the measurement interval another ipdv value is calculated from another packet pair. Assume that the time interval covered by the first measurement is t1 and that covered by the second measurement is t2. Then ipdv1 = s(0)*t1 + t1*(s(T)-s(0))/T ipdv2 = s(T)*t2 + t2*(s(T)-s(0))/T assuming that the change is skew is linear in time. In most practical cases, it is claimed that the drift will be close to zero in which case the second (correction) term in the above equations disappears. Note that in the above discussion, other errors, including the differences between host time and wire time, and externally-caused clock discontinuities (e.g. clock corrections) were ignored. Under these assumptions the maximum clock errors will be due to the maximum relative skew acting on the largest interval between packets. Demichelis and Chimento Expires August 2001 [Page 16] INTERNET-DRAFT IP Packet Delay Variation February 2001 7.2. Estimating the skew of unsynchronized clocks If the skew is linear (that is, if s(t) = S * t for constant S), the error in ipdv values will depend on the time between the packets used in calculating the value. If ti is the time between the packet pair, then let Ti denote the sample mean time between packets and the average skew is s(Ti) = S * Ti. In the event that the delays are constant, the skew parameter S can be estimated from the estimate Ti of the time between packets and the sample mean ipdv value. Under these assumptions, the ipdv values can be corrected by subtracting the estimated S * ti. We observe that the displacement due to the skew does not change the shape of the distribution, and, for example the Standard Deviation remains the same. What introduces a distortion is the effect of the drift, also when the mean value of this effect is zero at the end of the measurement. The value of this distortion is limited to the effect of the total skew variation on the emission interval. 8. Security Considerations The one-way-ipdv metric has the same security properties as the one- way-delay metric [2]. The packets contain no user information, and so privacy of user data is not a concern. It is still possible that there could be an attempt at a denial of service attack by sending many measurement packets into the network; there could also be attempts to disrupt measurements by diverting packets or corrupting them. In general, legitimate measurements must have their parameters selected carefully in order to avoid interfering with normal traffic in the network. Such measurements should also be authorized and authenticated in some way so that attacks can be identified and intercepted. 9. Acknowledgements This major revision of the draft resulted from e-mail discussions with and suggestions from Mike Pierce, Ruediger Geib, Glenn Grotefeld, and Al Morton. For previous revisions of this document, discussions with Ruediger Geib, Matt Zekauskas and Andy Scherer were very helpful. Demichelis and Chimento Expires August 2001 [Page 17] INTERNET-DRAFT IP Packet Delay Variation February 2001 10. References [1] V.Paxon, G.Almes, J.Mahdavi, M.Mathis - "Framework for IP Performance Metrics", RFC 2330 Feb. 1998 [2] G.Almes, S.Kalidindi - "A One-Way-Delay Metric for IPPM", RFC 2679, September 1999 [3] ITU-T Recommendation Y.1540 (formerly numbered I.380) "Internet Protocol Data Communication Service - IP Packet Transfer and Availability Performance Parameters", February 1999 [4] Demichelis, Carlo - "Packet Delay Variation Comparison between ITU-T and IETF Draft Definitions" November 2000 (in the IPPM mail archives) [5] ITU-T Recommendation I.356 "B-ISDN ATM Layer Cell Transfer Performance" [6] S. Keshav - "An Engineering Approach to Computer Networking", Addison-Wesley 1997, ISBN 0-201-63442-2 [7] V. Jacobson, K. Nichols, K. Poduri - "An expedited forwarding PHB", RFC 2598, June 1999 [8] ITU-T Draft Recommendation Y.1541 - "Internet Protocol Communication Service - IP Performance and Availability Objectives and Allocations", April 2000 [9] Demichelis, Carlo - "Improvement of the Instantaneous Packet Delay Variation (IPDV) Concept and Applications", World Telecommunications Congress 2000, 7-12 May 2000 11. Authors' Addresses Carlo Demichelis CSELT - Centro Studi E Laboratori Telecomunicazioni S.p.A Via G. Reiss Romoli 274 10148 - TORINO Italy Phone +39 11 228 5057 Fax. +39 11 228 5069 Demichelis and Chimento Expires August 2001 [Page 18] INTERNET-DRAFT IP Packet Delay Variation February 2001 Philip Chimento Ericsson IPI 7301 Calhoun Place Rockville, Maryland 20855 USA Phone +1-240-314-3597 Expiration date: August 2001 Demichelis and Chimento Expires August 2001 [Page 19] --------------AF1DA5098BAD14AE02CC5AB3-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Mar 2 06:57:39 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26610 for ; Fri, 2 Mar 2001 06:57:39 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f22Br3519616; Fri, 2 Mar 2001 06:53:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f22BqL519590 for ; Fri, 2 Mar 2001 06:52:22 -0500 X-Authentication-Warning: mailhost.advanced.org: Host odin.ietf.org [132.151.1.176] claimed to be ietf.org Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25842; Fri, 2 Mar 2001 06:52:20 -0500 (EST) Message-Id: <200103021152.GAA25842@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@advanced.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 02 Mar 2001 06:52:19 -0500 Subject: [ippm] I-D ACTION:draft-ietf-ippm-btc-framework-05.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : A Framework for Defining Empirical Bulk Transfer Capacity Metrics Author(s) : M. Mathis, M. Allman Filename : draft-ietf-ippm-btc-framework-05.txt Pages : 9 Date : 01-Mar-01 Bulk Transport Capacity (BTC) is a measure of a network's ability to transfer significant quantities of data with a single congestion-aware transport connection (e.g., TCP). The intuitive definition of BTC is the expected long term average data rate (bits per second) of a single ideal TCP implementation over the path in question. However, there are many congestion control algorithms (and hence transport implementations) permitted by IETF standards. This diversity in transport algorithms creates a difficulty for standardizing BTC metrics because the allowed diversity is sufficient to lead to situations where different implementations will yield non-comparable measures -- and potentially fail the formal tests for being a metric. This document defines a framework for standardizing multiple BTC metrics that parallel the permitted transport diversity. Two approaches are used. First, each BTC metric must be much more tightly specified than the typical IETF protocol. Pseudo-code or reference implementations are expected to be the norm. Second, each BTC methodology is expected to collect some ancillary metrics which are potentially useful to support analytical models of BTC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-btc-framework-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippm-btc-framework-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-btc-framework-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010301141402.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-btc-framework-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-btc-framework-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010301141402.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Mar 5 06:47:53 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11497 for ; Mon, 5 Mar 2001 06:47:53 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f25Bg3522569; Mon, 5 Mar 2001 06:42:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f25Bfu522543 for ; Mon, 5 Mar 2001 06:41:57 -0500 X-Authentication-Warning: mailhost.advanced.org: Host odin.ietf.org [132.151.1.176] claimed to be ietf.org Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10554; Mon, 5 Mar 2001 06:41:55 -0500 (EST) Message-Id: <200103051141.GAA10554@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@advanced.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 05 Mar 2001 06:41:55 -0500 Subject: [ippm] I-D ACTION:draft-ietf-ippm-ipdv-07.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : IP Packet Delay Variation Metric for IPPM Author(s) : C. Demichelis, P. Chimento Filename : draft-ietf-ippm-ipdv-07.txt Pages : 19 Date : 02-Mar-01 This memo refers to a metric for variation in delay of packets across Internet paths. The metric is based on the difference in the One-Way- Delay of selected packets. This difference in delay is called 'IP Packet Delay variation.' The metric is valid for measurements between two hosts both in the case that they have synchronized clocks and in the case that they are not synchronized. We discuss both in this draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-ipdv-07.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippm-ipdv-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-ipdv-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010302131443.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-ipdv-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-ipdv-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010302131443.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Mar 7 00:44:04 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA12177 for ; Wed, 7 Mar 2001 00:44:03 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f275e7L02237; Wed, 7 Mar 2001 00:40:07 -0500 Received: from mainserver.surfnetusa.com (mail.surfnetusa.com [208.201.152.2]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f275dpL02202 for ; Wed, 7 Mar 2001 00:39:52 -0500 X-Authentication-Warning: mailhost.advanced.org: Host mail.surfnetusa.com [208.201.152.2] claimed to be mainserver.surfnetusa.com Received: from [63.67.14.34] by mainserver.bookholt.com (NTMail 5.06.0016/AX0201.00.06a07d84) with ESMTP id ycorebaa for ippm@advanced.org; Tue, 6 Mar 2001 21:42:52 -0800 Message-Id: <4.2.0.58.20010306181715.00a98440@mail.merike.com> X-Sender: kaeo.merike@mail.merike.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 06 Mar 2001 18:18:42 -0800 To: ippm@advanced.org From: Merike Kaeo Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ippm] Fwd: Re: Standards for IP stats collection? (corrected) Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Thought I'd forward this to the group. Is anyone here following this fairly closely? - merike >Date: Mon, 05 Mar 2001 10:12:27 +0100 >From: Steven Van den Berghe >X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1 i686) >X-Accept-Language: en >To: Vishal Sharma >Cc: "'te-wg@uu.net'" , "'mpls@uu.net'" , > "'ccamp@ops.ietf.org'" >Subject: Re: Standards for IP stats collection? (corrected) >Sender: owner-te-wg@UU.NET > >Hi all, > >As far as i know, there is currently no effort for bringing together the work >being done by various MIB-authors (including the on the list discussed RMON) >and the work done for active measurements by the IPPM-WG, into general >requirements or an architecture for performing measurements for any higher >purpose (including traffic engineering). I've tried to initiate some activity >on this with http://search.ietf.org/internet-drafts/draft-svdberg-temon-00.txt >(unfortunately the server contains a version with quite some errors, so i've >attached the corrected one to this mail). > >Although sub-IP area enhancements will bring quite some additional input for >the measurement issue, i've limited myself to IP-level. My feeling is, that >this might be a starting point for some general measurement architecture and >hooks should be provided to enable extensions using lower-level information. >Furthermore, the IPPM-WG is highly interested in the metrics and measurements >as they are required by other WG, so they might also be interested in this >discussion. > >Best regards, >Steven > >Vishal Sharma wrote: > > > Hello All, > > > > For the TDM world, GR-253 lays out strict standards for > > the length of time that a carrier-class box should collect > > and store statistics on-board, for retrieval later. The > > number is something like 15-min intervals for 3 days. > > The purpose supposedly is that if the connection to the EMS > > dies, the box at least should allow the provider to recover > > statistics data from it. > > > > My question is: what are similar standards (or existing > > best practices) in the IP carrier community today? How much > > statistics-related information do carriers like to have from > > IP boxes? > > What would carriers like to have? > > > > (The only reference I could find on this was Blain Christian's > > draft > > > http://search.ietf.org/internet-drafts/draft-christian-tewg-measurement-00.t > > xt) > > > > Are there others? > > Do people (read carriers) have any thoughts or suggestions or > > pointers? > > > > Thanks, > > > > -Vishal > >-- >Steven Van den Berghe >steven.vandenberghe@intec.rug.ac.be >Workgroup Broadband-Networks >Department Information Technology >Ghent University - Belgium >Phone: +32 (0)9 267 35 86 | Fax : +32 (0)9 267 35 99 >*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* >I feel like a genocidal maniac when emacs asks me if I >want to kill 10789 characters. > > >*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Mar 7 07:18:32 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00356 for ; Wed, 7 Mar 2001 07:18:31 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f27CH3L31778; Wed, 7 Mar 2001 07:17:03 -0500 Received: from rjo04.embratel.net.br (rjo04.embratel.net.br [200.255.253.237]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f27CGWL31666 for ; Wed, 7 Mar 2001 07:16:33 -0500 Received: from rjo02.embratel.net.br (rjo02.embratel.net.br [200.255.253.238]) by rjo04.embratel.net.br (8.8.8/8.8.2) with ESMTP id JAA00038; Wed, 7 Mar 2001 09:16:27 -0300 (EST) Received: (from claus@localhost) by rjo02.embratel.net.br (8.8.8/8.8.2) id JAA17874; Wed, 7 Mar 2001 09:16:26 -0300 (EST) Date: Wed, 7 Mar 2001 09:16:26 -0300 From: Claus Rugani Topke To: ippm@advanced.org Cc: Claus Rugani Topke , jonny@jonny.eng.br, nacao@embratel.com.br Message-ID: <20010307091626.A16994@rjo02.embratel.net.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Subject: [ippm] Retrasmitted packets... Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Hi, I'm not sure what should be considered as "retransmited packet" or "retransmitted data" in a TCP flow... I fould the following flow in tcpdump output: 982027803.529734 222.222.222.194.1094 > 333.333.333.2.80: . 7885497:7885497(0) ack 1439554681 win 32120 (DF) (ttl 122, id 42242) 982027803.542848 222.222.222.194.1094 > 333.333.333.2.80: . 7885497:7885497(0) ack 1439555705 win 32120 (DF) (ttl 122, id 42498) 982027803.556465 222.222.222.194.1094 > 333.333.333.2.80: . 7885497:7885497(0) ack 1439556596 win 32120 (DF) (ttl 122, id 42754) 982027803.647738 222.222.222.194.1094 > 333.333.333.2.80: . 7885497:7885497(0) ack 1439556596 win 32120 (DF) (ttl 122, id 43522) These packets where retransmissions ? Is there any place where I can found a good definition about flow retransmissions ? Thanks in advance, Claus _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Mar 7 11:20:15 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09520 for ; Wed, 7 Mar 2001 11:20:14 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f27GE3L22976; Wed, 7 Mar 2001 11:14:03 -0500 Received: from galatea (localhost [127.0.0.1]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f27GDKL22816; Wed, 7 Mar 2001 11:13:20 -0500 X-Authentication-Warning: mailhost.advanced.org: Host localhost [127.0.0.1] claimed to be galatea From: "Matthew J Zekauskas" To: Cc: "Merike Kaeo" , "Matt Zekauskas" , , , "Allison Mankin" , "Scott Bradner" Date: Wed, 7 Mar 2001 11:27:39 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: [ippm] Working Group last-call for draft-ietf-ippm-btc-framework-05.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit The latest draft of the Bulk Transport Framework has all fixes and changes suggested on this list as well as previous IETF meetings. Since there have been no substantive changes suggested to the framework since the last version, the co-chairs propose a Working Group last-call for this document, draft-ietf-ippm-btc-framework-05.txt. Assuming no major objections or changes, we will submit this document to the IESG for consideration as an Informational RFC. Please submit your comments to the IPPM mailing list or to the chairs or I-D authors as you feel appropriate (although public comments are preferred). Because IETF week lies during the customary two-week last-call period, the Working Group last-call period will be extended, and will end on Friday, March 30, 2001 at noon EST. --Matt Zekauskas and Merike Kaeo _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Mar 13 23:31:25 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04758 for ; Tue, 13 Mar 2001 23:31:25 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2E4S7D03429; Tue, 13 Mar 2001 23:28:07 -0500 Received: from mainserver.surfnetusa.com (mail.surfnetusa.com [208.201.152.2]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2E4RsD03393 for ; Tue, 13 Mar 2001 23:27:54 -0500 X-Authentication-Warning: mailhost.advanced.org: Host mail.surfnetusa.com [208.201.152.2] claimed to be mainserver.surfnetusa.com Received: from [64.24.109.67] by mainserver.bookholt.com (NTMail 5.06.0016/AX0201.00.06a07d84) with ESMTP id ehudfbaa for ippm@advanced.org; Tue, 13 Mar 2001 20:31:16 -0800 Message-Id: <4.2.0.58.20010313200551.00944780@mail.merike.com> X-Sender: kaeo.merike@mail.merike.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 13 Mar 2001 20:15:17 -0800 To: ippm@advanced.org From: Merike Kaeo Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ippm] owdp - requirements Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List This is a heads up that our area directors have pointed out that the charter as it currently stands does not specifically allow for the working group to create protocols. However, if sufficient reasons are shown why this work should belong in IPPM, then it may be possible to modify the charter accordingly. Therefore, we are working on a requirements document, which will state the problem which the OWDP is trying to solve. The first version will be released a few weeks after the IETF in Minneapolis. - merike _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Mar 13 23:32:49 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04857 for ; Tue, 13 Mar 2001 23:32:49 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2E4S3D03414; Tue, 13 Mar 2001 23:28:03 -0500 Received: from mainserver.surfnetusa.com (mail.surfnetusa.com [208.201.152.2]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2E4RYD02894 for ; Tue, 13 Mar 2001 23:27:35 -0500 X-Authentication-Warning: mailhost.advanced.org: Host mail.surfnetusa.com [208.201.152.2] claimed to be mainserver.surfnetusa.com Received: from [64.24.109.67] by mainserver.bookholt.com (NTMail 5.06.0016/AX0201.00.06a07d84) with ESMTP id xgudfbaa for ippm@advanced.org; Tue, 13 Mar 2001 20:30:57 -0800 Message-Id: <4.2.0.58.20010313195316.00a7b900@mail.merike.com> X-Sender: kaeo.merike@mail.merike.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 13 Mar 2001 19:56:56 -0800 To: agenda@ietf.org From: Merike Kaeo Cc: ippm@advanced.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ippm] IPPM agenda Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Proposed agenda for the IP Performance Metrics WG (ippm) Tuesday, 20 March 2001, 14:15 - 15:15 ====================================== Agenda bashing (<= 5 min) Discussion on advancing metrics through the IETF standards process, concentrating on missing holes (25 min) http://www.ietf.org/internet-drafts/draft-bradner-metricstest-00.txt -- Speaker TBD, and Matt Zekauskas Discussion on IPDV Reorganization (10 min) -- Matt Zekauskas http://www.ietf.org/internet-drafts/draft-ietf-ippm-ipdv-07.txt Preliminary results on periodic streams: periodic vs poisson and discussion on npmps implementation (15 min) -- Al Morton http://www.ietf.org/internet-drafts/draft-ietf-ippm-npmps-04.txt Tuesday, 20 March 2001, 15:45 - 16:45 ====================================== Discussion on last call for BTC framework (10 min) -- Mark Allman http://www.ietf.org/internet-drafts/draft-ietf-ippm-btc-framework-05.txt http://www.ietf.org/internet-drafts/draft-ietf-ippm-btc-cap-00.txt One-way delay protocol document discussion; requirements document (15 min) http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-02.txt -- Stanislav Shalunov & Merike Kaeo Implementations for one-way delay protocol (15 min) http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-02.txt -- Joan Cucchiara Charter milestone revisions (10 min) -- Matt Zekauskas & Merike Kaeo _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Sat Mar 17 21:14:27 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11105 for ; Sat, 17 Mar 2001 21:14:27 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2I293D32386; Sat, 17 Mar 2001 21:09:03 -0500 Received: from mainserver.surfnetusa.com (mail.surfnetusa.com [208.201.152.2]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2I284D32137; Sat, 17 Mar 2001 21:08:05 -0500 X-Authentication-Warning: mailhost.advanced.org: Host mail.surfnetusa.com [208.201.152.2] claimed to be mainserver.surfnetusa.com Received: from [208.232.125.91] by mainserver.bookholt.com (NTMail 5.06.0016/AX0201.00.06a07d84) with ESMTP id xsqsfbaa for ippm@advanced.org; Sat, 17 Mar 2001 18:11:36 -0800 Message-Id: <4.2.0.58.20010317172609.00a8d1f0@mail.merike.com> X-Sender: kaeo.merike@mail.merike.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 17 Mar 2001 17:57:11 -0800 To: From: Merike Kaeo Cc: "Merike Kaeo" , "Matt Zekauskas" , rajeev@IPRG.nokia.com, rravikanth@axiowave.com, "Allison Mankin" , "Scott Bradner" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ippm] Working Group last-call for draft-ietf-ippm--05.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List The latest draft of the One-way Loss Pattern Sample Metrics has all the fixes and changes suggested on this list as well as previous IETF meetings. Since there have been no substantive changes suggested to this document since the last version, the co-chairs propose a Working Group last-call for this document, draft-ietf-ippm-loss-pattern-05.txt. Assuming no major objections or changes, we will submit this document to the IESG for consideration as an Informational RFC. Please submit your comments to the IPPM mailing list or to the chairs or I-D authors as you feel appropriate (although public comments are preferred). Because IETF week lies during the customary two-week last-call period, the Working Group last-call period will be extended, and will end on Monday, April 9, 2001 at noon EST. --Merike Kaeo and Matt Zekauskas _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Mar 20 05:01:32 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28793 for ; Tue, 20 Mar 2001 05:01:31 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2K9u3D19292; Tue, 20 Mar 2001 04:56:03 -0500 Received: from jack.see.plym.ac.uk (jack.see.plymouth.ac.uk [141.163.49.98]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2K9twD19271 for ; Tue, 20 Mar 2001 04:55:59 -0500 X-Authentication-Warning: mailhost.advanced.org: Host jack.see.plymouth.ac.uk [141.163.49.98] claimed to be jack.see.plym.ac.uk Received: from jack.see.plym.ac.uk (bogdan@sfres1.see.plym.ac.uk [141.163.49.101]) by jack.see.plym.ac.uk (8.9.3/8.9.3) with ESMTP id JAA01336 for ; Tue, 20 Mar 2001 09:48:13 GMT Message-ID: <3AB729E4.5E4FB757@jack.see.plym.ac.uk> Date: Tue, 20 Mar 2001 09:59:00 +0000 From: Bogdan Ghita X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: ippm@advanced.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [ippm] Real-time-like traffic generation Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Hello everybody, I would like to do some traffic performance measurement of combined real-time traffic (e.g. VoIP) and TCP traffic. I know that there are plenty of applications to produce a VoIP call, but I would prefere, for the sake of simplicity, to use an easy-to-configure application, such as ping (the tests will involve scripting, and it's rather difficult to make 'rat' or 'netmeeting' part of a script ). I know that they are not the same, I know that the remote station would reply to the ICMP packets sent by the sender, but the effect would be the same: constant traffic, with a precise spacing between packets and same packet lenght for each datagram. The problem I have is that ping cannot send packets at intervals < 1s, except for the flood case, which is out of the question, because the program relies on sigalarm() function, which can be triggered only at integer intervals. So, the question is: are there any tools to produce real-time-like traffic (I'm talking, of course, about freely downloadable ones, not commercial products), or are there any ping 'clones' that avoided the sigalarm() problem? Thank you Bogdan Ghita _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Mar 20 05:29:00 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29659 for ; Tue, 20 Mar 2001 05:28:59 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2KAS3D22744; Tue, 20 Mar 2001 05:28:03 -0500 Received: from leeor.math.technion.ac.il (leeor.math.technion.ac.il [132.68.115.2]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2KARLD22580 for ; Tue, 20 Mar 2001 05:27:21 -0500 Received: (from nyh@localhost) by leeor.math.technion.ac.il (8.9.3/8.9.3) id MAA03202; Tue, 20 Mar 2001 12:26:54 +0200 (IST) Date: Tue, 20 Mar 2001 12:26:54 +0200 From: "Nadav Har'El" To: Bogdan Ghita Cc: ippm@advanced.org Subject: Re: [ippm] Real-time-like traffic generation Message-ID: <20010320122654.A1752@leeor.math.technion.ac.il> References: <3AB729E4.5E4FB757@jack.see.plym.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3AB729E4.5E4FB757@jack.see.plym.ac.uk>; from bodhi@jack.see.plym.ac.uk on Tue, Mar 20, 2001 at 09:59:00AM +0000 Hebrew-Date: 25 Adar 5761 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List On Tue, Mar 20, 2001, Bogdan Ghita wrote about "[ippm] Real-time-like traffic generation": > The problem I have is that ping cannot send packets at intervals < 1s, > except for the flood case, which is out of the question, because the > program relies on sigalarm() function, which can be triggered only at > integer intervals. Actually, Linux (Redhat 7, at least) ping is capable of wait intervals of less than one second, e.g., $ ping -i 0.1 remote.machine.net It appears that an interval of 0.02 seconds or less is not permitted unless you're the superuser - this is probably just some self-imposed limit in the code to prevent mischief from regular users. -- Nadav Har'El | Tuesday, Mar 20 2001, 25 Adar 5761 nyh@math.technion.ac.il |----------------------------------------- Phone: +972-53-245868, ICQ 13349191 |Drink varnish and you'll get a lovely http://nadav.harel.org.il |finish. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Mar 20 08:36:04 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05381 for ; Tue, 20 Mar 2001 08:36:04 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2KDZ4D05950; Tue, 20 Mar 2001 08:35:04 -0500 Received: from itc-eml2.lannet.com (at.lannet.com [194.90.94.231]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2KDYfD05832 for ; Tue, 20 Mar 2001 08:34:42 -0500 X-Authentication-Warning: mailhost.advanced.org: Host at.lannet.com [194.90.94.231] claimed to be itc-eml2.lannet.com Received: by itc-eml2.lannet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Mar 2001 15:34:05 +0200 Message-ID: <15F58915DF84D311AC7D0090279AA614234863@itc-eml2.lannet.com> From: Dan Romascanu To: "'Bogdan Ghita'" , ippm@advanced.org Cc: "'cwk@verio.net'" , "'rgcole@att.com'" Subject: RE: [ippm] Real-time-like traffic generation Date: Tue, 20 Mar 2001 15:34:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Hi Bogdan, Related to this subject, note that there is work being proposed to the IETF RMON WG on synthetic sources for performance monitoring. - draft-cole-sppm-02.txt - draft-kalbfleish-sspmmib-01.tx The issue was discussed in the last night WG meeting in Minneapolis. Bob Cole and myself who are two of the authors of the two drafts will be today at the IPPM WG meeting, if you ore other participants are interested in discussing this work. Regards, Dan > I would like to do some traffic performance measurement of combined > real-time traffic (e.g. VoIP) and TCP traffic. I know that there are > plenty of applications to produce a VoIP call, but I would prefere, for > the sake of simplicity, to use an easy-to-configure application, such as > ping (the tests will involve scripting, and it's rather difficult to > make 'rat' or 'netmeeting' part of a script ). I know that they are not > the same, I know that the remote station would reply to the ICMP packets > sent by the sender, but the effect would be the same: constant traffic, > with a precise spacing between packets and same packet lenght for each > datagram. > > The problem I have is that ping cannot send packets at intervals < 1s, > except for the flood case, which is out of the question, because the > program relies on sigalarm() function, which can be triggered only at > integer intervals. > > So, the question is: are there any tools to produce real-time-like > traffic (I'm talking, of course, about freely downloadable ones, not > commercial products), or are there any ping 'clones' that avoided the > sigalarm() problem? > > Thank you > > Bogdan Ghita > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Mar 20 17:48:36 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29607 for ; Tue, 20 Mar 2001 17:48:36 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2KMl2D30358; Tue, 20 Mar 2001 17:47:02 -0500 Received: from NOD.RESTON.MCI.NET (nod.reston.mci.net [166.60.6.38]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2KMkbD30242 for ; Tue, 20 Mar 2001 17:46:37 -0500 Received: from durian ([166.60.2.77]) by shoe.reston.mci.net (PMDF V6.0-24 #47392) with ESMTP id <01K1FFIT9U4G9ZMASX@shoe.reston.mci.net> for ippm@advanced.org; Tue, 20 Mar 2001 17:46:36 -0500 (EST) Date: Tue, 20 Mar 2001 17:40:02 -0500 (EST) From: Jambi Ganbar In-reply-to: <200101251810.f0PIAw197716@bmah-freebsd-0.cisco.com> X-Sender: bigj@durian To: ippm@advanced.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: [ippm] OWD Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7BIT How many network operators are getting requirements from customers to produce one way delay as part of their SLA/SLG? jambi vBNS Engineering (703) 886 1714 _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Mar 20 20:12:09 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05501 for ; Tue, 20 Mar 2001 20:12:09 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2L153D13227; Tue, 20 Mar 2001 20:05:03 -0500 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2L14LD13195 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL) for ; Tue, 20 Mar 2001 20:04:26 -0500 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2L14Hj04429; Tue, 20 Mar 2001 20:04:21 -0500 X-Authentication-Warning: mail.internet2.edu: Host localhost [127.0.0.1] claimed to be cain.internet2.edu Received: by cain.internet2.edu (Postfix, from userid 1000) id 9D67B577; Tue, 20 Mar 2001 20:04:14 -0500 (EST) To: Jambi Ganbar Cc: ippm@advanced.org Subject: Re: [ippm] OWD References: From: stanislav shalunov Date: 20 Mar 2001 20:04:14 -0500 In-Reply-To: Message-ID: <871yrsaq5t.fsf@cain.internet2.edu> Lines: 12 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Jambi Ganbar writes: > How many network operators are getting requirements from customers to > produce one way delay as part of their SLA/SLG? I assume as Premium service becomes widespread, the answer will be "every". -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ A fool's brain digests philosophy into folly, science into superstition, and art into pedantry. Hence University education. -- G. B. Shaw _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Mar 21 10:07:07 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24243 for ; Wed, 21 Mar 2001 10:07:07 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2LF53D13760; Wed, 21 Mar 2001 10:05:03 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2LF4vD13736 for ; Wed, 21 Mar 2001 10:04:58 -0500 Received: from kantoor.ripe.net (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id QAA11091; Wed, 21 Mar 2001 16:04:56 +0100 (CET) Received: from localhost (henk@localhost) by kantoor.ripe.net (8.8.8/8.8.5) with ESMTP id QAA10055; Wed, 21 Mar 2001 16:04:56 +0100 (CET) X-Authentication-Warning: kantoor.ripe.net: henk owned process doing -bs Date: Wed, 21 Mar 2001 16:04:56 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Jambi Ganbar cc: ippm@advanced.org Subject: Re: [ippm] OWD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List On Tue, 20 Mar 2001, Jambi Ganbar wrote: > How many network operators are getting requirements from customers to > produce one way delay as part of their SLA/SLG? Not many, as until recently it was impossible to buy a device to actually measure them. My guess is that this will change rapidly now that there are measurement devices available on the market for everyone against a nominal fee. (See, for example: http://www.ripe.net/test-traffic). Henk > jambi > vBNS Engineering > (703) 886 1714 > > > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm > ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net 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 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Mar 21 12:37:13 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02469 for ; Wed, 21 Mar 2001 12:37:12 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2LHa3D18124; Wed, 21 Mar 2001 12:36:03 -0500 Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2LHZ4D18001 for ; Wed, 21 Mar 2001 12:35:04 -0500 Received: from smarcus.genuity.com ([171.78.157.158]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id MAA28115; Wed, 21 Mar 2001 12:37:41 -0500 (EST) Message-Id: <3.0.5.32.20010321005429.0090edf0@pobox3.genuity.com> X-Sender: smarcus@pobox3.genuity.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 21 Mar 2001 00:54:29 -0600 To: stanislav shalunov From: "J. Scott Marcus" Subject: Re: [ippm] OWD Cc: Jambi Ganbar , ippm@advanced.org In-Reply-To: <871yrsaq5t.fsf@cain.internet2.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List At 20:04 03/20/2001 -0500, stanislav shalunov wrote: >Jambi Ganbar writes: > >> How many network operators are getting requirements from customers to >> produce one way delay as part of their SLA/SLG? > >I assume as Premium service becomes widespread, the answer will be "every". What makes you believe that Premium service will become widespread? _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Mar 21 15:29:12 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12157 for ; Wed, 21 Mar 2001 15:29:12 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2LKS4D11503; Wed, 21 Mar 2001 15:28:04 -0500 Received: from NOD.RESTON.MCI.NET (nod.reston.mci.net [166.60.6.38]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2LKR9D11264 for ; Wed, 21 Mar 2001 15:27:10 -0500 Received: from durian ([166.60.2.77]) by shoe.reston.mci.net (PMDF V6.0-24 #47392) with ESMTP id <01K1GOY5RFYQ9ZMAN1@shoe.reston.mci.net> for ippm@advanced.org; Wed, 21 Mar 2001 15:27:08 -0500 (EST) Date: Wed, 21 Mar 2001 15:20:30 -0500 (EST) From: Jambi Ganbar Subject: Re: [ippm] OWD In-reply-to: <871yrsaq5t.fsf@cain.internet2.edu> X-Sender: bigj@durian Cc: ippm@advanced.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7BIT I would not make such assumptions. There are still enough networks out there that have minimal SLAs that do not mean much when one read the fine print. I am interested in hearing from ISPs that were asked by customers to provide such numbers. Jambi vBNS Engineering (703) 886 1714 On Tue, 20 Mar 2001, stanislav shalunov wrote: > Jambi Ganbar writes: > > > How many network operators are getting requirements from customers to > > produce one way delay as part of their SLA/SLG? > > I assume as Premium service becomes widespread, the answer will be "every". > > -- > Stanislav Shalunov http://www.internet2.edu/~shalunov/ > > A fool's brain digests philosophy into folly, science into superstition, > and art into pedantry. Hence University education. -- G. B. Shaw > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm > _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Mar 22 14:23:12 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18491 for ; Thu, 22 Mar 2001 14:23:12 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2MJK3D15573; Thu, 22 Mar 2001 14:20:03 -0500 Received: from brixcorp2.brixnet.com ([63.122.27.34]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2MJJsD15545 for ; Thu, 22 Mar 2001 14:19:54 -0500 X-Authentication-Warning: mailhost.advanced.org: Host [63.122.27.34] claimed to be brixcorp2.brixnet.com Received: by BRIXCORP2 with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Mar 2001 14:19:54 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB8A343A@BRIXCORP2> From: "Hedayat, Kaynam" To: "'Jambi Ganbar'" Cc: ippm@advanced.org Subject: RE: [ippm] OWD Date: Thu, 22 Mar 2001 14:19:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List For our SLA and Service Verification offerings we are seeing quite a lot of demand and requirement for OWD measurement. We are especially seeing this from providers of VoIP services. That is why we currently offer OWD measurement tests and are planning to implement the OWDP. Kaynam Hedayat Brix Networks > -----Original Message----- > From: Jambi Ganbar [mailto:bigj@mci.net] > Sent: Wednesday, March 21, 2001 3:21 PM > Cc: ippm@advanced.org > Subject: Re: [ippm] OWD > > > I would not make such assumptions. There are still enough > networks out > there that have minimal SLAs that do not mean much when one > read the fine > print. I am interested in hearing from ISPs that were asked > by customers > to provide such numbers. > Jambi > > vBNS Engineering > (703) 886 1714 > > On Tue, 20 Mar 2001, stanislav shalunov wrote: > > > Jambi Ganbar writes: > > > > > How many network operators are getting requirements from > customers to > > > produce one way delay as part of their SLA/SLG? > > > > I assume as Premium service becomes widespread, the answer > will be "every". > > > > -- > > Stanislav Shalunov http://www.internet2.edu/~shalunov/ > > > > A fool's brain digests philosophy into folly, science into > superstition, > > and art into pedantry. Hence University education. > -- G. B. Shaw > > _______________________________________________ > > ippm mailing list > > ippm@advanced.org > > http://mailhost.advanced.org/mailman/listinfo/ippm > > > > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm > _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Sat Mar 24 02:30:24 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27581 for ; Sat, 24 Mar 2001 02:30:23 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2O7P3D24057; Sat, 24 Mar 2001 02:25:03 -0500 Received: from ctsincsisxic.cts-corp.com ([202.54.64.136]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f2O7O8D23906 for ; Sat, 24 Mar 2001 02:24:09 -0500 X-Authentication-Warning: mailhost.advanced.org: Host [202.54.64.136] claimed to be ctsincsisxic.cts-corp.com Received: from 10.236.2.7 by ctsincsisxic.cts-corp.com (InterScan E-Mail VirusWall NT); Sat, 24 Mar 2001 12:56:39 +0530 Received: by CTSINCSISXIC with Internet Mail Service (5.5.2650.21) id ; Sat, 24 Mar 2001 12:56:38 +0530 Message-ID: From: "Bellala, Kasipathi (CTS)" To: ippm@advanced.org Date: Sat, 24 Mar 2001 12:53:03 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [ippm] (no subject) Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B433.43978870" ------_=_NextPart_001_01C0B433.43978870 Content-Type: text/plain; charset="iso-8859-1" _________________________________________ Kasipathi Bellala Telecom Group Cognizant Technology Solutions Ph : 2540555 X: 7026 ***************************************** Keep Trying...to Get....Success Keep Smiling..to Get....Happiness Keep Loving..to Get....Peace _________________________________________ ------_=_NextPart_001_01C0B433.43978870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

_________________________________________
Kasipathi = Bellala         &= nbsp;           &= nbsp; 
Telecom = Group           &= nbsp;           &= nbsp;           &= nbsp;
Cognizant = Technology Solutions     
Ph : 2540555 X: = 7026           &n= bsp;       
*****************************************
Keep Trying...to = Get....Success         &nbs= p;  
Keep Smiling..to = Get....Happiness       
Keep Loving..to = Get....Peace
_________________________________________

------_=_NextPart_001_01C0B433.43978870-- --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com --------------InterScan_NT_MIME_Boundary-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Sun Mar 25 03:11:56 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01031 for ; Sun, 25 Mar 2001 03:11:55 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2P883D11591; Sun, 25 Mar 2001 03:08:03 -0500 Received: from sm10.texas.rr.com ([24.93.35.222]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2P876D11421 for ; Sun, 25 Mar 2001 03:07:07 -0500 X-Authentication-Warning: mailhost.advanced.org: Host [24.93.35.222] claimed to be sm10.texas.rr.com Received: from localhost (cs2773-200.houston.rr.com [24.27.73.200]) by sm10.texas.rr.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f2P81Bi5013083 for ; Sun, 25 Mar 2001 02:05:14 -0600 Message-Id: <200103250805.f2P81Bi5013083@sm10.texas.rr.com> X-Sender: hermag@excite.com From: "hermag@excite.com" To: ippm@advanced.org Date: Sun, 25 Mar 2001 02:01:57 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__18672566_7317.06" Subject: [ippm] Would you like to recieve information on how to register your pet online for free? Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List This is a Multipart MIME message. ------=_NextPart_000_001__18672566_7317.06 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_000_001__18672566_7317.06 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5VbnRpdGxlZCBEb2N1bWVudDwvdGl0bGU+DQo8bWV0 YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl dD1pc28tODg1OS0xIj4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4 dD0iIzAwMDAwMCI+DQo8cD5IZWxsbyE8L3A+DQo8cD5Xb3VsZCB5b3UgbGlrZSB0byBrbm93 IGhvdyB0byByZWdpc3RlciB5b3VyIHBldCBvbmxpbmUgZm9yIGZyZWU/PC9wPg0KPHA+SWYg eW91IHdvdWxkIGxpa2UgdG8gYmUgcmVtb3ZlZCBmcm9tIGV2ZXIgcmVjZWl2aW5nIGFub3Ro ZXIgZW1haWwgcGxlYXNlIHR5cGUgDQogIFJFTU9WRSBvbmx5IGluIHRoZSByZXR1cm4gc3Vi amVjdCBoZWFkZXIuIFdlIHJlc3BlY3QgeW91ciByaWdodCB0byBwcml2YWN5LjwvcD4NCjxw PklmIHlvdSB3b3VsZCBsaWtlIHRvIHJlY2VpdmUgbW9yZSBpbmZvcm1hdGlvbiBvbiBob3cg dG8gcmVnaXN0ZXIgeW91ciBwZXQgZm9yIA0KICBmcmVlIGp1c3QgcmVwbHkgdG8gdGhpcyBl bWFpbCBtZXNzYWdlIHdpdGggUExFQVNFIFNFTkQgSU5GTyBvbmx5IGluIHRoZSBzdWJqZWN0 IA0KICBoZWFkZXIuPC9wPg0KPHA+PC9wPg0KPHA+VGhhbmsgWW91PGJyPg0KPC9wPg0KPC9i b2R5Pg0KPC9odG1sPg0K ------=_NextPart_000_001__18672566_7317.06-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Mar 26 16:19:37 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16747 for ; Mon, 26 Mar 2001 16:19:37 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2QL53j04700; Mon, 26 Mar 2001 16:05:03 -0500 Received: from galatea (localhost [127.0.0.1]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f2QL4oj04580; Mon, 26 Mar 2001 16:04:52 -0500 X-Authentication-Warning: mailhost.advanced.org: Host localhost [127.0.0.1] claimed to be galatea From: "Matthew J Zekauskas" To: Cc: "Merike Kaeo" , "Matt Zekauskas" Date: Mon, 26 Mar 2001 16:21:15 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [ippm] ietf50 - Minneapolis - draft meeting minutes & presentations Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit Draft meeting minutes, and the presentations, from IETF 50 are available at http://www.advanced.org/IPPM/Meetings/ietf50/ Let Merike or I know if you have any comments on the minutes. --Matt _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Mar 27 04:32:03 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA15803 for ; Tue, 27 Mar 2001 04:32:02 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2R9P4j18464; Tue, 27 Mar 2001 04:25:04 -0500 Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2R9OEj18434 for ; Tue, 27 Mar 2001 04:24:14 -0500 Received: from oleane (dyn-1-2-159.Vin.dialup.oleane.fr [194.2.4.159]) by smtp1.cluster.oleane.net with SMTP id f2R9OCV55011 for ; Tue, 27 Mar 2001 11:24:12 +0200 (CEST) Message-ID: <005d01c0b69f$e1da2880$8001a8c0@oleane.com> From: "Peter Lewis" To: Date: Tue, 27 Mar 2001 11:25:36 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005A_01C0B6B0.A4F51B80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [ippm] IP.Net Convention Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List This is a multi-part message in MIME format. ------=_NextPart_000_005A_01C0B6B0.A4F51B80 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable What does the IP standard protocol really afford today in terms of = security, quality of service, mobility and billing?=20 What types of virtual networks can be set up? Can a private network use = VoIP technologies to convey voice? Can a mobile network be included in that equation? What tools are = available and are they interoperable?=20 What services do operators propose today? The IP.Net Convention, to be held in Paris, June 19 to 22, will provide = technical and commercial answers to these questions, illustrated by = concrete implementation cases.=20 http://www.upperside.fr/ipnetworks/ipnet.htm ------=_NextPart_000_005A_01C0B6B0.A4F51B80 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
What does the IP standard protocol really afford = today in=20 terms of security, quality of service, mobility and billing?
What = types of=20 virtual networks can be set up? Can a private network use VoIP = technologies to=20 convey voice?
Can a mobile network be included in that equation? What = tools=20 are available and are they interoperable?
What services do operators = propose=20 today?

The IP.Net Convention, to be held in = Paris, June=20 19 to 22, will provide technical and commercial answers to these = questions,=20 illustrated by concrete implementation cases.
http://www.uppersid= e.fr/ipnetworks/ipnet.htm
 
------=_NextPart_000_005A_01C0B6B0.A4F51B80-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Mar 28 23:37:32 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27590 for ; Wed, 28 Mar 2001 23:37:32 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2T4a6j29627; Wed, 28 Mar 2001 23:36:06 -0500 Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f2T4Zvj29606 for ; Wed, 28 Mar 2001 23:35:58 -0500 X-Authentication-Warning: mailhost.advanced.org: Host p-mail1.rd.francetelecom.fr [193.49.124.31] claimed to be p-mail1.cnet.fr Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Mar 2001 17:49:59 +0200 Message-ID: From: ADAM Yann FTRD/DAC/LAN To: "'Henk Uijterwaal (RIPE-NCC)'" , Jambi Ganbar Cc: ippm@advanced.org Subject: RE: [ippm] OWD Date: Tue, 27 Mar 2001 14:38:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id f2T4Zvj29606 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.advanced.org id f2T4a6j29627 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA27590 As Henk said, technical offers are not widespread. I'd also say so for service offers: VoIP or video streaming services are not standard offers in operator's today catalog. Thus, I would say the measurement is ahead of one's time. Infonet SLA has a delay specification, but I don't know if it's a OWD measurement. The solutions I know for OWD measurement are: Ipanema Technologies (www.ipanematech.com), Imedia Technology (www.imedia-tech.com), Brix Networks (www.brixnetworks.com), RIPE test-traffic project (see below), and the Surveyor project (www.advanced.org). Do you know others ? Yann Adam -----Message d'origine----- De : Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net] Envoyé : mercredi 21 mars 2001 16:05 À : Jambi Ganbar Cc : ippm@advanced.org Objet : Re: [ippm] OWD On Tue, 20 Mar 2001, Jambi Ganbar wrote: > How many network operators are getting requirements from customers to > produce one way delay as part of their SLA/SLG? Not many, as until recently it was impossible to buy a device to actually measure them. My guess is that this will change rapidly now that there are measurement devices available on the market for everyone against a nominal fee. (See, for example: http://www.ripe.net/test-traffic). Henk > jambi > vBNS Engineering > (703) 886 1714 > > > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm > ---------------------------------------------------------------------------- -- Henk Uijterwaal Email: henk.uijterwaal@ripe.net 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 ---------------------------------------------------------------------------- -- As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Mar 29 15:20:25 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08566 for ; Thu, 29 Mar 2001 15:20:24 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2TKJ3j14059; Thu, 29 Mar 2001 15:19:03 -0500 Received: from galatea (localhost [127.0.0.1]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f2TKISj13907; Thu, 29 Mar 2001 15:18:28 -0500 X-Authentication-Warning: mailhost.advanced.org: Host localhost [127.0.0.1] claimed to be galatea From: "Matthew J Zekauskas" To: Cc: "Merike Kaeo" , "Matthew J Zekauskas" , , , "Allison Mankin" , "Scott Bradner" Subject: RE: [ippm] Working Group last-call for draft-ietf-ippm-btc-framework-05.txt Date: Thu, 29 Mar 2001 15:18:40 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Content-Transfer-Encoding: 7bit I intended to give tsvwg a pointer to this last call, but it fell off my stack. I will do so momentarily. To give folks that subscribe to tsvwg but not ippm a chance to comment, the last-call period will be extended to noon EDT Monday, 2-April-2001. Finally, if anyone else has a comment they just haven't sent off yet, please do! --Matt > -----Original Message----- > From: Matthew J Zekauskas > Sent: Wednesday, March 07, 2001 11:28 AM > To: ippm@advanced.org > Cc: Merike Kaeo; Matt Zekauskas; mallman@grc.nasa.gov; mathis@psc.edu; > Allison Mankin; Scott Bradner > Subject: [ippm] Working Group last-call for > draft-ietf-ippm-btc-framework-05.txt > > > The latest draft of the Bulk Transport Framework has all fixes > and changes suggested on this list as well as previous IETF meetings. > Since there have been no substantive changes suggested to the > framework since the last version, the co-chairs propose a > Working Group last-call for this document, > draft-ietf-ippm-btc-framework-05.txt. > Assuming no major objections or changes, we will submit this > document to the IESG for consideration as an Informational RFC. > > Please submit your comments to the IPPM mailing list or to the > chairs or I-D authors as you feel appropriate (although public > comments are preferred). Because IETF week lies during the > customary two-week last-call period, the Working Group last-call > period will be extended, and will end on Friday, March 30, 2001 at > noon EST. > > --Matt Zekauskas and Merike Kaeo > > > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm > _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Mar 30 02:02:23 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04673 for ; Fri, 30 Mar 2001 02:02:23 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2U6v4j19940; Fri, 30 Mar 2001 01:57:04 -0500 Received: from fw1a.telekom.de (gw1.telekom.de [194.25.15.11]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id f2U6uuj19919 for ; Fri, 30 Mar 2001 01:57:01 -0500 X-Authentication-Warning: mailhost.advanced.org: Host gw1.telekom.de [194.25.15.11] claimed to be fw1a.telekom.de Received: by fw1a.telekom.de; (5.65v4.0/1.3/10May95) id AA22181; Fri, 30 Mar 2001 08:56:55 +0200 Received: from Q9J99.mgb01.telekom.de by U9JWN.mgb01.telekom.de with ESMTP for ippm@advanced.org; Fri, 30 Mar 2001 08:56:45 +0200 Received: from g8pbr.blf01.telekom.de by Q9J99.mgb01.telekom.de with ESMTP for ippm@advanced.org; Fri, 30 Mar 2001 07:56:32 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Mar 2001 08:56:14 +0200 Message-Id: From: "Geib, Ruediger" To: ippm@advanced.org Subject: RE: [ippm] OWD Date: Fri, 30 Mar 2001 08:56:28 +0200 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id f2U6uuj19919 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.advanced.org id f2U6v4j19940 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA04673 > As Henk said, technical offers are not widespread. I'd also say so for > service offers: VoIP or video streaming services are not standard > offers in operator's today catalog. > Thus, I would say the measurement is ahead of one's time. > > Infonet SLA has a delay specification, but I don't know if it's a OWD > measurement. > > The solutions I know for OWD measurement are: > Ipanema Technologies (www.ipanematech.com), Imedia Technology > (www.imedia-tech.com), Brix Networks (www.brixnetworks.com), RIPE > test-traffic project (see below), and the Surveyor project > (www.advanced.org). > > Do you know others ? Deutsche Telekom T-Nova developed its own solution. It is not yet deployed in the production network. Regards, Rüdiger _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Mar 30 02:10:12 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA10587 for ; Fri, 30 Mar 2001 02:10:11 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2U794j21334; Fri, 30 Mar 2001 02:09:04 -0500 Received: from mx1.sita.int (mx1.sita.int [57.250.224.237]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2U78Yj21310 for ; Fri, 30 Mar 2001 02:08:34 -0500 Received: from geneva1.gva.sita.int (geneva1.gva.sita.int [57.5.138.2]) by mx1.sita.int with SMTP id f2U77PT29292 for ; Fri, 30 Mar 2001 07:07:25 GMT Received: by geneva1.gva.sita.int(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 41256A1F.002D06F6 ; Fri, 30 Mar 2001 09:11:48 +0100 X-Lotus-FromDomain: SITA From: Pierre.Benain@sita.int To: ippm@advanced.org Message-ID: <41256A1F.002D0673.00@geneva1.gva.sita.int> Date: Fri, 30 Mar 2001 09:11:47 +0100 Subject: Re: RE: [ippm] OWD Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id f2U78Yj21310 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.advanced.org id f2U794j21334 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA10587 Did you look at CQOS??? They developped a solution as well Rgds/ PY Benain ________________________________________________________________________________________ >From "Geib, Ruediger" on 30 March 2001 8:56:28 AM To : ippm@advanced.org Subject : RE: [ippm] OWD > As Henk said, technical offers are not widespread. I'd also say so for > service offers: VoIP or video streaming services are not standard > offers in operator's today catalog. > Thus, I would say the measurement is ahead of one's time. > > Infonet SLA has a delay specification, but I don't know if it's a OWD > measurement. > > The solutions I know for OWD measurement are: > Ipanema Technologies (www.ipanematech.com), Imedia Technology > (www.imedia-tech.com), Brix Networks (www.brixnetworks.com), RIPE > test-traffic project (see below), and the Surveyor project > (www.advanced.org). > > Do you know others ? Deutsche Telekom T-Nova developed its own solution. It is not yet deployed in the production network. Regards, Rüdiger _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm Pierre-Yves Benain SITA Network Solutions Marketing 26, chemin de Joinville - P.O. Box 31 1216 Cointrin Geneva Switzerland Tel +41 22 747 6577 (CVS 228-6577) Fax +41 22 747 6530 (CVS 228-6530) Cell +41 79 615 58 43 mailto pierre.benain@sita.int _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Mar 30 11:01:35 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22447 for ; Fri, 30 Mar 2001 11:01:35 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2UG07j17650; Fri, 30 Mar 2001 11:00:07 -0500 Received: from nscolmar.uha.fr (nscolmar.uha.fr [194.167.108.34]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2UA7dj01220 for ; Fri, 30 Mar 2001 05:07:40 -0500 Received: from [194.167.108.50] (admpcsrv1.uha.fr [194.167.108.50]) by nscolmar.uha.fr (8.11.0/jtpda-5.3.3) with SMTP id f2U9CKX29665 ; Fri, 30 Mar 2001 11:12:20 +0200 Received: from admpcsrv1.uha.fr by [194.167.108.50] via smtpd (for nscolmar.uha.fr [194.167.108.34]) with SMTP; 30 Mar 2001 09:23:09 UT Received: from gtrpc31 ([192.168.12.82]) by admpcsrv1.uha.fr (Lotus Domino Release 5.0.3 (Intl)) with SMTP id 2001033011092191:6615 ; Fri, 30 Mar 2001 11:09:21 +0200 Message-Id: <3.0.1.32.20010330112213.008f6520@uha.fr> X-Sender: conf@uha.fr (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Fri, 30 Mar 2001 11:22:13 +0200 To: conf@uha.fr From: conf@uha.fr Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on ADMPCSRV1/SRV/COLMAR(Release 5.0.3 (Intl)|21 March 2000) at 30/03/2001 11:09:22, Serialize by Router on ADMPCSRV1/SRV/COLMAR(Release 5.0.3 (Intl)|21 March 2000) at 30/03/2001 11:16:50, Serialize complete at 30/03/2001 11:16:50 Content-Type: text/plain; charset="us-ascii" Subject: [ippm] Call for participation for ICN01 and Call for Papers for ECUMN'02 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List Dear All, Please feel free to circulate to interested colleagues: 1. The preliminary program of ICN01 (International Conference on Networking) (see http://iutsun1.colmar.uha.fr/ICN01.html ) which will be held at Colmar, France, from Monday July 9, 2001 to Friday July 13, 2001. If you would like to Chair a session during ICN01, please contact lorenz@ieee.org 2. The call for papers of ECUMN'02 (see http://iutsun1.colmar.uha.fr/ECUMN02.html ) scheduled from April 8 to April 10, 2002. The deadline for this CfP is September 1, 2001. Accept our sincere apologies if you receive multiple copies. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Mar 30 14:05:49 2001 Received: from mailhost.advanced.org (root@mail.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05686 for ; Fri, 30 Mar 2001 14:05:48 -0500 (EST) Received: from mailhost.advanced.org (mailhost.advanced.org [209.211.239.227]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2UJ13j14822; Fri, 30 Mar 2001 14:01:03 -0500 Received: from Thor.Adtech-Inc.COM ([63.165.80.10]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f2UJ0Bj14772 for ; Fri, 30 Mar 2001 14:00:12 -0500 X-Authentication-Warning: mailhost.advanced.org: Host [63.165.80.10] claimed to be Thor.Adtech-Inc.COM Received: from apollo.adtech-inc.com (Apollo.Adtech-Inc.COM [10.12.0.17]) by Thor.Adtech-Inc.COM (8.10.2/8.10.2) with ESMTP id f2UIxv529217; Fri, 30 Mar 2001 08:59:57 -1000 (HST) Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Mar 2001 09:04:42 -1000 Message-ID: <8AC36D3167EED41184C800508BD95405152026@apollo.adtech-inc.com> From: "Uyeshiro, Robin" To: "'Pierre.Benain@sita.int'" Cc: "'ippm@advanced.org'" Subject: RE: RE: [ippm] OWD Date: Fri, 30 Mar 2001 09:04:41 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id f2UJ0Bj14772 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: IETF IP Performance Metrics Working Group List X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.advanced.org id f2UJ13j14822 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA05686 Commercial test equipment vendors have been offering one-way delay measurements for some time, with GPS for measuring across geographically dispersed networks. One-way delay measurements have been important to commercial networks for some time now. -----Original Message----- From: Pierre.Benain@sita.int [mailto:Pierre.Benain@sita.int] Sent: Thursday, March 29, 2001 10:12 PM To: ippm@advanced.org Subject: Re: RE: [ippm] OWD Did you look at CQOS??? They developped a solution as well Rgds/ PY Benain ____________________________________________________________________________ ____________ >From "Geib, Ruediger" on 30 March 2001 8:56:28 AM To : ippm@advanced.org Subject : RE: [ippm] OWD > As Henk said, technical offers are not widespread. I'd also say so for > service offers: VoIP or video streaming services are not standard > offers in operator's today catalog. > Thus, I would say the measurement is ahead of one's time. > > Infonet SLA has a delay specification, but I don't know if it's a OWD > measurement. > > The solutions I know for OWD measurement are: > Ipanema Technologies (www.ipanematech.com), Imedia Technology > (www.imedia-tech.com), Brix Networks (www.brixnetworks.com), RIPE > test-traffic project (see below), and the Surveyor project > (www.advanced.org). > > Do you know others ? Deutsche Telekom T-Nova developed its own solution. It is not yet deployed in the production network. Regards, Rüdiger _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm Pierre-Yves Benain SITA Network Solutions Marketing 26, chemin de Joinville - P.O. Box 31 1216 Cointrin Geneva Switzerland Tel +41 22 747 6577 (CVS 228-6577) Fax +41 22 747 6530 (CVS 228-6530) Cell +41 79 615 58 43 mailto pierre.benain@sita.int _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm