perfsonar development work

[Stephan Kraft <>]

Hi Jeff,

maybe it´s a more or less philosophical question.

Jeff W. Boote schrieb:
> Stephan Kraft wrote:
>> please find my comments in the document.
>
> Hi Stephan,
>
> I wanted to respond to your comments about available vs. achievable
> bandwidth. These terms actually are 'fairly' well accepted and
> defined, and we should use the accepted definitions.
>
> "Achievable bandwidth" defines what you were able to achieve if you
> attempt to use as much as you can. This is the definition of what
> iperf/nuttcp/thrulay and tools like that do.
from
http://nmwg.internet2.edu/nmwg-tools.html

    * available bandwidth:  the capacity minus utilization over a given
      time interval.
    * achievable bandwidth: the throughput between two end points given
      a specific set of conditions, such as transmission protocol (e.g.:
      TCP or UDP),  host hardware (e.g.: processor speed, bus speed, NIC
      speed), operating system, system settings (e.g.: TCP buffer size,
      txqueuelen setting),  and so on.

with the measurements, we try to determine the "available bandwidth" by
measuring the "achievable bandwidth" by optimizing the measurement itself.
So, for my understanding, we are measuring the throughput to calculate
the available bandwidth.
In reality, we have measured the "achieved bandwidth" in a past time
interval.

I don´t think we need a big discussion here, we can use the term
"achievable bandwidth".
But we have to be aware, that we only have measured throughput under
defined conditions.

I think, you are currently working on a rfc draft for definition of
capacity metrics? There is one draft  available (achievable? :-)) at:

http://www.ietf.org/internet-drafts/draft-ietf-ippm-bw-capacity-05.txt

Or defining Bulk transfer capacity

http://www.ietf.org/rfc/rfc3148.txt

showing the complexity of defining this metrics.

Regards

Stephan
>
> "Available bandwidth" is a much more nebulous term... It refers to the
> amount of bandwidth that is available on a link before a flow is
> likely to have problems. In practice, the tools people have written to
> determine this use packet dispersion techniques. Tools like pathload
> attempt to give you this value.
>
> http://www.cc.gatech.edu/fac/Constantinos.Dovrolis/pathload_tutorial.html
>
> jeff
>
>> regards
>>
>> Stephan
>>
>> Loukik Kudarimoti schrieb:
>>> Here is the document which describes the Multi-Domain Monitoring
>>> Service for LHCOPN.
>>>
>>> Loukik.
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> Betreff:
>>> Monitoring Service specification for LHCOPN - Draft
>>> Von:
>>> Loukik Kudarimoti 
>>> <>
>>> Datum:
>>> Thu, 13 Sep 2007 14:33:56 +0100
>>> An:
>>> 
>>>
>>> An:
>>> 
>>>
>>> Return-Path:
>>> <>
>>> Received:
>>> from mail.dante.org.uk (localhost [127.0.0.1]) by mail.dante.org.uk
>>> (Cyrus v2.3.7) with LMTPA; Thu, 13 Sep 2007 14:35:30 +0100
>>> X-Sieve:
>>> CMU Sieve 2.3
>>> Envelope-to:
>>> ,
>>>  
>>> ,
>>> ,
>>>  
>>> ,
>>>  
>>> 
>>> Delivery-date:
>>> Thu, 13 Sep 2007 14:35:30 +0100
>>> Received:
>>> from [127.0.0.1] (helo=localhost) by mail.dante.org.uk with esmtp
>>> (Exim 4.63) (envelope-from 
>>> <>)
>>>  id
>>> 1IVoqv-00068R-ME; Thu, 13 Sep 2007 14:35:30 +0100
>>> X-Virus-Scanned:
>>> amavisd-new at dante.org.uk
>>> Received:
>>> from mail.dante.org.uk ([127.0.0.1]) by localhost (mail.dante.org.uk
>>> [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usvUsqA3YZAR;
>>> Thu, 13 Sep 2007 14:35:28 +0100 (BST)
>>> Received:
>>> from [137.138.166.172] (helo=cernmxlb.cern.ch) by mail.dante.org.uk
>>> with esmtp (Exim 4.63) (envelope-from
>>> <>)
>>>  id 1IVoqr-00068J-MH; Thu, 13 Sep
>>> 2007 14:35:28 +0100
>>> Received:
>>> from cernpf02.cern.ch ([137.138.166.101]) by cernmxlb.cern.ch with
>>> Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 15:35:21 +0200
>>> List-ID:
>>> <project-lcg-gdb-network-wg.cern.ch>
>>> Precedence:
>>> Bulk
>>> Received:
>>> from cernmxlb.cern.ch ([137.138.166.171]) by cernpf02.cern.ch with
>>> Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 15:35:18 +0200
>>> X-External:
>>> man_on_the_moon_ex
>>> DomainKey-Status:
>>> non participant - Generated by CERN IT/IS DomainKeys v1.0
>>> X-Filter:
>>> CERNMX07 CERN MX v2.0 060921.0942 Release
>>> Received:
>>> from mail.dante.org.uk ([193.63.211.19]) by cernmxlb.cern.ch with
>>> Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 15:35:13 +0200
>>> Received:
>>> from [193.63.211.19] (helo=Trend.local) by mail.dante.org.uk with
>>> esmtp (Exim 4.63) (envelope-from 
>>> <>)
>>>  id
>>> 1IVopR-00062h-Ph for 
>>> ;
>>>  Thu, 13 Sep
>>> 2007 14:35:13 +0100
>>> Nachricht-ID:
>>> <>
>>> User-Agent:
>>> Thunderbird 2.0.0.6 (Macintosh/20070728)
>>> MIME-Version:
>>> 1.0
>>> Content-Type:
>>> multipart/mixed; boundary="------------090303020306030606020500"
>>> X-OriginalArrivalTime:
>>> 13 Sep 2007 13:35:13.0557 (UTC) FILETIME=[E9C6BC50:01C7F60A]
>>>
>>>
>>> Dear all,
>>>
>>> You might recall that DANTE had an action item to provide a detailed
>>> spec of the Monitoring service (based on perfSONAR) that we suggested
>>> during the last LHCOPN workshop. In attachment is a word document
>>> which can be treated as an early draft for this specification.
>>>
>>> I am circulating this draft because we would like your feedback at
>>> this stage of the specification being written up. Your feedback will
>>> help us in tailoring some parts of the specification (especially
>>> deployment location, security, site policies, etc) so that the
>>> document can meet your requirements effectively. We would like to hear
>>> your opinions and comments (even if you are happy with the
>>> specification as is).
>>>
>>> Please do note that there are some sections in the document that are
>>> empty and will get filled up with later versions of the draft.
>>>
>>> Thanks.
>>>
>>
>>
>


-- 
Dr. Stephan Kraft, DFN-Labor
Friedrich-Alexander-Universität Erlangen-Nürnberg
Regionales RechenZentrum Erlangen (RRZE)
Martensstraße 1, 91058 Erlangen, Germany
Tel. +49 9131 85-28735 -28800, Fax +49 9131 302941

www.win-labor.dfn.de