RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability

"Geib, Ruediger" <Ruediger.Geib@t-systems.com> Tue, 02 May 2006 13:53 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FavJP-0007A6-1V; Tue, 02 May 2006 09:53:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FavJN-0007A1-V7 for ippm@ietf.org; Tue, 02 May 2006 09:53:09 -0400
Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FavJN-0004vC-IA for ippm@ietf.org; Tue, 02 May 2006 09:53:09 -0400
Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Tue, 2 May 2006 15:53:04 +0200
Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id <KBQ8GT0L>; Tue, 2 May 2006 15:53:04 +0200
Message-Id: <6439282641581441A36F7F6F83ED2ED20E631D@S4DE8PSAAFQ.mitte.t-com.de>
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: acmorton@att.com
Subject: RE: [ippm] draft-shalunov-ippm-reporting-00.txt - availability
Date: Tue, 02 May 2006 15:53:00 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Cc: ippm@ietf.org
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=subscribe>
Errors-To: ippm-bounces@ietf.org

Hi Al,

|Users experience network performance in at least two states:
|available or "broken" (unavailable) where typically some
|sort of failure or misconfiguration cannot be restored automatically
|and requires human intervention.
|
|The tricky part is defining the performance levels that
|constitute the transitions between the two states,
|and keep them application-independent for simplicity.

Exactly.

|Despite the difficulties, Availability is probably one of
|the most important network metrics, as far as real users
|are concerned.

Yes, it is part of many product descriptions and SLAs.

Regards, 

Rudiger

|At 08:39 AM 5/2/2006, Geib, Ruediger wrote:
|>Stas,
|>
|>Real time and leased line services are characterised by an 
|>"availability". I think availability is a useful and common 
|>means to characterise these services. Today, there's only a 
|>meausurement principle for IP service availability. There's 
|>no commonly implemented IP service availability measurement 
|>(RFC2678 on connectivity proposes some metrics which may be 
|>useful).
|>
|>The idea is that you define a service availability over time. If the 
|>service is available, the metrics you've listed below are applied to 
|>characterise the service. If the service is not available, 
|>then no further performance characterisation is required.
|>
|>As more real time services start to be migrated to the 
|>Internet, measuring IP transport availability may be of interest.
|>
|>Regards,
|>
|>Rudiger
|>
|>
|>Carsten|> * additionally "availability" could be one metric
|>|>   (probably with param = (list of) server(s) or network)
|>
|>Stas|Why aren't existing metrics enough?  When no packets
|>|come through, you'll see
|>|
|>|delay = +infinity
|>|loss = 100%
|>|jitter = undefined
|>|duplication = 0%
|>|reordering = 0%
|>|
|>|Is that not enough?
|>
|>_______________________________________________
|>ippm mailing list
|>ippm@ietf.org
|>https://www1.ietf.org/mailman/listinfo/ippm
|
|
|_______________________________________________
|ippm mailing list
|ippm@ietf.org 
|https://www1.ietf.org/mailman/listinfo/ippm
|

_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm