Subject: [ippm] Request for speaking slot:draft-anjali-ippm-avail-band-measurement-00.txt

From: Tricha Anjali <[email-masked]>
Date: Wed, 6 Nov 2002 11:51:31 -0500 (EST)

Hello Merike, Matt,

Recently I submitted a draft draft-anjali-ippm-avail-band-measurement-00.txt.
If you consider this work of interest to the IPPM WG, I would like to
request a speaking slot at the Atlanta meeting.

Thanks,
Tricha

------

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Available Bandwidth Measurement in IP Networks
	Author(s)	: T. Anjali et al.
	Filename	: draft-anjali-ippm-avail-band-measurement-00.txt
	Pages		: 8
	Date		: 2002-10-28

Available bandwidth along a path is an important metric that can be
useful to provide insight into the state and performance of the
network. Some methods have been proposed in literature for
measurement of available bandwidth but they face the problems of
scalability and high intrusiveness.  In this draft, we propose a
method to measure path available bandwidth using an active approach
that probes the path. The probing mechanism used is based on TCP
New Reno. Once the samples for the available bandwidth measurement
are obtained, more accurate results are calculated using a
prediction filter.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-anjali-ippm-avail-band-measurement-00.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

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-anjali-ippm-avail-band-measurement-00.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-anjali-ippm-avail-band-measurement-00.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.

_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: Matthew J Zekauskas <[email-masked]>
Date: Thu, 07 Nov 2002 11:10:34 -0500

Actually, I'd like to see if we could start a discussion
here first.

[chair hat off]

caveat: I've only had time to skim the draft.

It seems to me this draft doesn't have a good definition for
"available bandwidth"; it compares pathchar-like tests with
SNMP measurements (that seems fair) but then to end-to-end
user perceived measurements (doesn't seem fair -- you're
comparing link capacity with TCP throughput).

It seems that what you really are trying to create is a
"improved" 'bulk transfer capacity' measurement -- what
a TCP connection will provide a user. (Although, by the
end I'm confused again... it's not clear to me if you
are looking for the steady state, as BTC is, or some other
mix, or really truly are looking to know the "raw" bandwidth
on the bottleneck link.)

It's also not clear to me that the method is ready to be
standardized; The whole link capacity area is an area of active
research with (in my opinion) no clear "best" technique.

In addition, I see a number of claims made without
proof here (one that caught my eye: "it is accurate as
it obtains measurement from the network using a TCP session").
I have not followed reference [6] to see what is stated
there.

Do other group members have comments?

--Matt

--On Wednesday, November 06, 2002 11:51 AM -0500 Tricha Anjali 
<[email-masked]> wrote:

>
> Hello Merike, Matt,
>
> Recently I submitted a draft
> draft-anjali-ippm-avail-band-measurement-00.txt. If you consider this
> work of interest to the IPPM WG, I would like to request a speaking slot
> at the Atlanta meeting.
>
> Thanks,
> Tricha
>
> ------
>
>
> 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

---

From: Tricha Anjali <[email-masked]>
Date: Fri, 8 Nov 2002 11:31:31 -0500 (EST)

Answers inline.

> comparing link capacity with TCP throughput).

In the first paragraph of Section 1.2 (Available tools) we mention the
pathchar and packetpair based methods for measurement of the total
capacity in the links of a path; while pathload, iperf and our own method
measure the available bandwidth of the path.

The available bandwidth is different from
the capacity in a link. The capacity of a link is the speed at which the
link transfers data. The available bandwidth of a link is the unused
portion of this link capacity. To illustrate, if the link is a
FastEthernet link, it can transfer 100 Mb of data within a second. Thus,
its capacity is 100 Mbps. If in an interval of 1 sec duration, the link is
not transmitting continuously, it implies that there is some "available
capacity" on the link.  Assume that the link was transmitting only for
2/10th of the second. Then, the link available bandwidth is given as
(1 - 2/10)*100 = 80 Mbps.

> mix, or really truly are looking to know the "raw" bandwidth

Our method measures the current "raw" available bandwidth of the path. It
does not measure the steady-state.

> I have not followed reference [6] to see what is stated

Our method for available bandwidth measurement is accurate because it
enhances the TCP measurements with a prediction and estimation filter that
processes the raw TCP measurements into a more accurate, refined value for
the available bandwidth. While this is explained in Section 2.2, maybe
it was not clearly repeated in Section 3 about the accuracy of our
method.

> Do other group members have comments?

Regards,
Tricha

-------------------------------
Tricha Anjali
Broadband & Wireless Networking Lab
School of Electrical and Computer Engineering
Georgia Institute of Technology
http://users.ece.gatech.edu/~tricha/

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Tue, 12 Nov 2002 13:57:10 +0100 (CET)

> I have not followed reference [6] to see what is stated

Is this reference online somewhere?

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                    Email: [email-masked]
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
------------------------------------------------------------------------------

That problem that we weren't having yesterday, is it better? (Big ISP NOC)

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Tue, 12 Nov 2002 13:49:10 +0100 (CET)

> does not measure the steady-state.

I think that you have now used "raw available bandwidth", "link available
bandwidth" and "available bandwidth" in 2 paragraphs, so I second Matt's
request for a clear definition of what you want to measure.

Henk

---

From: Tricha Anjali <[email-masked]>
Date: Tue, 12 Nov 2002 13:32:27 -0500 (EST)

It is on my website: http://www.ece.gatech.edu/~tricha

Regards,
Tricha

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Wed, 13 Nov 2002 10:04:05 +0100 (CET)

> It is on my website: http://www.ece.gatech.edu/~tricha

That just says that it has been accepted, it doesn't give a link to the
pdf.

Henk

---

From: Matthew J Zekauskas <[email-masked]>
Date: Wed, 13 Nov 2002 11:32:07 -0500

I think a perusal of the email archives would be worthwhile,
as would a read of the BTC Framework, RFC 3148.  This group
was originally formed to generate a bandwidth metric, and the
fact that it's the last thing to be standardized shows the
inherent difficulty in defining that metric.  (Caveat: I wasn't
around when the group was formed...)

Using a version of TCP to test the bandwidth available to TCP
is the group's best current thinking; obviously it perturbs
the system, but it is no less fair than firing off a TCP
transfer.

The problems with the definitions below are
 - TCP's are different, and you need to understand the differences
    in order to say what any given TCP might obtain (hence the
    ancillary metrics in RFC 3148).

 - What a TCP might obtain is different than what sampling SNMP
    counters over time might tell you is available, and both of
    those are different than the instantaneous "unused bandwidth"
    along a path.

This is another reason why I ask that what you are attempting
to measure is defined well.  "Available bandwidth" has a nice
intuitive appeal, but when you look in detail you find that
there are many different potential meanings.

--Matt

--On Tuesday, November 12, 2002 1:49 PM +0100 "Henk Uijterwaal (RIPE-NCC)" 
<[email-masked]> wrote:

>> its capacity is 100 Mbps. If in an interval of 1 sec duration, the link
>> is not transmitting continuously, it implies that there is some
>> "available capacity" on the link.  Assume that the link was transmitting
>> only for 2/10th of the second. Then, the link available bandwidth is
>> given as (1 - 2/10)*100 = 80 Mbps.
>>
>> >
> -------------------------------------------------------------------------
> ----- Henk Uijterwaal                    Email: [email-masked]

---

From: Tricha Anjali <[email-masked]>
Date: Wed, 13 Nov 2002 13:04:29 -0500 (EST)

The title of the paper is a link to the pdf.

Regards,
Tricha