Subject: [ippm] Question/comment on RFC5136

From: Xiangsong Cui <[email-masked]>
Date: Mon, 09 Aug 2010 11:58:49 +0800

Hi folks,

I'm reading RFC5136 "Defining Network Capacity", and I have some question/comment on it.

In section 2.1, the definition of link and path, it reads:

   We then define a path P of length n as a series of
   links (L1, L2, ..., Ln) connecting a sequence of nodes (N1, N2, ...,
   Nn+1). A source S and destination D reside at N1 and Nn+1,
   respectively.

I'm a bit confused by this definition,
it seems the middle-boxes (i.e., nodes N2, N3, ..., Nn) are not included (in this definition) in the path between N1 and Nn+1, is 
this right?
it is very strange to me, because I remember we often mentioned "the middle-box in the path", does that means the middle-box should 
be a part of the path?

Well, if the middle-boxes were part of the path, how about the "path capacity"?
In section 2.3.3, it specifies,

C(P,T,I) = min {1..n} {C(Ln,T,I)}

I think this should be updated, as

C(P,T,I) = min ( X, Y)
X = min {2..n} {C(Nn,T,I)}
Y = min {1..n} {C(Ln,T,I)}

Of course, we should additionally define the capacity of node (transmitting/receiving/forwarding aspect), I think that is necessary.
And there are also some other text need modification, such as IP-type-P Available Path Capacity.

For example, in the path between node A and B as follows,

A------link1------Router------link2------B

For some certain packet/traffic, if the capacity of link1 is 5G bps and the capacity of link2 is 3G bps, while the capacity of the 
router is 2G bps, how much is the capacity of the path between A and B? I believe the capacity is 2G bps (the neckbottle is the 
middle-box), but not 3G bps (as definition of RFC5136).

Since this is a very late comment (on a frozen RFC document), if you agree these are serious issues, I would submit a new draft, to 
update this RFC.

Any thought?

Regards,
Xiangsong

---

From: Xiangsong Cui <[email-masked]>
Date: Mon, 09 Aug 2010 13:12:56 +0800

I think the middle-boxes MUST be part of the path now, because if not, the path would lost connectivity.

The links are not jointed each other, they must be connected by the middle-boxes.

Regards,
Xiangsong

----- Original Message ----- 
From: "Xiangsong Cui" <[email-masked]>
To: <[email-masked]>
Sent: Monday, August 09, 2010 11:58 AM
Subject: [ippm] Question/comment on RFC5136

> it is very strange to me, because I remember we often mentioned "the middle-box in the path", does that means the middle-box 
> should be a part of the path?
>
>
> Since this is a very late comment (on a frozen RFC document), if you agree these are serious issues, I would submit a new draft, 
> to update this RFC.
>
> Any thought?
>
>
> Regards,
> Xiangsong
>
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 13 Aug 2010 09:24:32 +0800

Hi Joseph,

Thanks for your response!

We come to link capacity again, I showed my option on this problem in the link:
http://www.ietf.org/mail-archive/web/ippm/current/msg02417.html

As to link and link capacity, I want to make sure:

Is IP node is a part or a IP link?  I guess not, because link is the layer2-level connection, it is the media, the facility, the 
layer2 protocol..., but does Not cover nodes, which is a layer3 concept.

So C(L,T,I) is node-independent, right?

If you insisit link capacity is node-dependent, I give my third example here.

In the following scenario, where link1/link2/link3/link4 physical capacity is 1.x G bps, they all use the same link protocol, and we 
assume their "physical IP capacity" is 1G bps. Same way, the router IP capacity is 1G bps.

host A------link1--------               ----------link2------ host B
                                       \            /
                                         Router
                                       /            \
host C------link3--------               ----------link4------ host D

Phase 1, only host A transmit packets (IP-type-P) to host B, other hosts don't transimit any packet.
Base on RFC5136, the IP capacity of link1 and link2 is 1G bps for the certain time/period, the link usage is same. IP capacity of 
link3 and link4 is 0 bps and link usage is also same (althouth their physical IP capacity is 1G bps). As to IP-type-P Link 
Utilization, base on the definition of RFC5136, Util(L,T,I) = ( Used(L,T,I) / C(L,T,I) ), so we can get: IP-type-P Link Utilization 
of link1 is 100% (1G bps/1G bps), this looks right, but how about link3 and link4? the IP-type-P Link Utilization of link3 is 0/0, 
what does this mean? (in my mind, when a link is idle, the link utilization is 0, but not 0/0)

Well, phase 2, host C begin to transmit packets (IP-type-P) to host D (others keep unchanged, same networks, same nodes, same 
links....), also at the rate 1G bps.
Unfortunately, router over-loads, but it still works fairly. so link1/link2/link3/link4 IP traffic rate is 500M bps. OK, what is the 
metric? Base on RFC5136, the IP capacity of link1 and link2 is 500M bps  for the certain time/period, the link usage is same. IP 
capacity of link3 and link4 is 500M bps  for the certain time/period and link usage is also same. As to IP-type-P Link Utilization, 
base on the definition of RFC5136, Util(L,T,I) = ( Used(L,T,I) / C(L,T,I) ), so we can get: IP-type-P Link Utilization of link1 is 
100% (500M bps/500M bps), this looks very strange, Link Utilization is unchaged, really?  How about link3 and link4? the IP-type-P 
Link Utilization of link3 is 100% (500M / 500M)?

Now, it is phase 3, host A stop transmitting packets, host C still transmitting as before.
Base on RFC5136, the IP capacity of link1 and link2 is 0 G bps, the link usage is same. IP capacity of link3 and link4 is 1G bps and 
link usage is also same.
How to calculate C(L,T,I) and Util(L,T,I) now?

All of these, are more and more confusing.....................................

Regards
Xiangsong

----- Original Message ----- 
From: "Joseph Ishac" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, August 13, 2010 1:30 AM
Subject: Re: [ippm] Question/comment on RFC5136

> Just getting back from vacation so I'm slowly catching up here.  I've
> not parsed the whole thread, but have some thoughts on the initial
> question and will throw that out here as I catch up.
>
>> For some certain packet/traffic, if the capacity of link1 is 5G bps
>> and the capacity of link2 is 3G bps, while the capacity of the router
>> is 2G bps, how much is the capacity of the path between A and B? I
>> believe the capacity is 2G bps (the neckbottle is the
> Well, the RFC calls out a couple of things.  The 5 Gbit/s and 3 Gbit/s
> links would be "Nominal Physical Link Capacity" such that:
>
> NomCap(link1) = 5 Gbit/s
> NomCap(link2) = 3 Gbit/s
>
> Now, the "IP-type-P Link Capacity" is what can be transmitted on a link
> by link basis.  So if A has no problem saturating the router then for
> some given time, T, and interval, I:
>
> C(link1,T,I) ~= 5 Gbit/s
> C(link2,T,I) ~= 2 Gbit/s
>
> The reason being that the Capacity at link 2 is driven by the ability to
> transmit IP data from "Router" to "B".  If "Router" has a limitation
> here it impacts this value.
>
> The way I read the above is that value for Y is essentially the limit of
> "Nominal Physical Link Capacity".  The value of X is attempting to
> factor in only *one* possible limiting factor to that, particularly a
> node's forwarding and processing ability.
>
> Our original definition of C aims to capture the many factors that can
> inhibit the ability to reach the "Nominal Physical Link Capacity" and as
> such I believe is intended to be more robust than the case outlined
> above.
>
> I will note that in practice, measuring all of this is VERY hard (and we
> note this in the draft).  However this document is not itself intended to
> be a measuring technique, but instead, a conceptual analysis of what
> should be counted.
>
> -Joseph

---

From: Philip Chimento <[email-masked]>
Date: Wed, 25 Aug 2010 20:31:35 -0400

XIangsong: 
I have been busy and have not been able to respond quickly over the past week or so. 

The origin of RFC 5136 was to try to make precise what was being and should be measured by the many tools that attempt to determine the "bandwidth" of a source-to-destination path at a given time. We spoke at the time of having another informational RFC discussing the current state of "bandwidth" measurement tools, but it was decided not to pursue it. This RFC was not intended to be an element-by-element model of the network. The whole point was to capture what was meant by "bandwidth".

I disagree with your statement that C(L,T,I) is node independent (in the context of this RFC). Take the instance of, say, a firewall, in the path between two routers. Suppose that the firewall is only capable of a throughput of  10 Mb/s but is connected to the routers by 100 Mb/s Ethernet links. We can say that the IP Type P Capacity is 10 Mb/s for the "link" (which is really a path) between the two routers. You could include the firewall if you wanted to, in which case the IP Type P Capacity would be 10 Mb/s for both links, but there wouldn't really be any point. 

Going on to your third example below: 

- Phase 1: You are right, in this case, the IP Type P Capacity reaches the Nominal Link Capacity of both Link 1 and Link 2. The IP Type P Capacity of links 3 and 4 is 0. If the IP Type P Capacity is 0, then the utilization also has to be 0. I believe that this is consistent with normal engineering usage. 

- Phase 2: You postulate that the router is able to share its backplane capacity fairly. Then if the router is designed so that it shares exactly fairly among all active links, then the IP Type P Capacity of links 1,2,3 and 4 is 500 Mb/s, because that is the highest rate at which bits can be (correctly) delivered. Suppose that nodes B and D transmit in the reverse direction (to A and C, respectively) and that the backplane capacity of the router is 1 Gb/s total (both directions). Then the IP Type P Capacity is only 250 Mb/s for links 1,2,3,4. 

- Phase 3: This is exactly the same as Phase 1, just exchanging link and node labels. 

The reason that things are defined this way is that this is what you would see if you were to probe this network with a "bandwidth" measurement tool. 

A router with more links and a given backplane design could give you more quirky behavior depending on internal congestion patterns or hot spots in the switching fabric. For the purposes of the RFC, it doesn't matter whether a node's design, or fast fading of a wireless link is limiting the capacity, it only matters that the capacity is limited. That is why we do not separate links and nodes as separate entities. Given real node behavior, you can't assign a single node capacity (especially to routers and switches) because it depends on the design of the node and what other traffic is present at a given time. 

At this point, my opinion is that we do not need a new draft or RFC; I would be happy to add the above explanations (or some variant) as a correction/update to the RFC,  but I defer to Henk, Matt and the opinion of the workgroup.   
 
Regards, 
Phil Chimento 
[email-masked]

On Aug 12, 2010, at 9:24 PM, Xiangsong Cui wrote:

> Is IP node is a part or a IP link?  I guess not, because link is the layer2-level connection, it is the media, the facility, the layer2 protocol..., but does Not cover nodes, which is a layer3 concept.
> 
> In the following scenario, where link1/link2/link3/link4 physical capacity is 1.x G bps, they all use the same link protocol, and we assume their "physical IP capacity" is 1G bps. Same way, the router IP capacity is 1G bps.
> 
> Base on RFC5136, the IP capacity of link1 and link2 is 1G bps for the certain time/period, the link usage is same. IP capacity of link3 and link4 is 0 bps and link usage is also same (althouth their physical IP capacity is 1G bps). As to IP-type-P Link Utilization, base on the definition of RFC5136, Util(L,T,I) = ( Used(L,T,I) / C(L,T,I) ), so we can get: IP-type-P Link Utilization of link1 is 100% (1G bps/1G bps), this looks right, but how about link3 and link4? the IP-type-P Link Utilization of link3 is 0/0, what does this mean? (in my mind, when a link is idle, the link utilization is 0, but not 0/0)
> 
> Well, phase 2, host C begin to transmit packets (IP-type-P) to host D (others keep unchanged, same networks, same nodes, same links....), also at the rate 1G bps.
> Unfortunately, router over-loads, but it still works fairly. so link1/link2/link3/link4 IP traffic rate is 500M bps. OK, what is the metric? Base on RFC5136, the IP capacity of link1 and link2 is 500M bps  for the certain time/period, the link usage is same. IP capacity of link3 and link4 is 500M bps  for the certain time/period and link usage is also same. As to IP-type-P Link Utilization, base on the definition of RFC5136, Util(L,T,I) = ( Used(L,T,I) / C(L,T,I) ), so we can get: IP-type-P Link Utilization of link1 is 100% (500M bps/500M bps), this looks very strange, Link Utilization is unchaged, really?  How about link3 and link4? the IP-type-P Link Utilization of link3 is 100% (500M / 500M)?
> 
> Base on RFC5136, the IP capacity of link1 and link2 is 0 G bps, the link usage is same. IP capacity of link3 and link4 is 1G bps and link usage is also same.
> ----- Original Message ----- From: "Joseph Ishac" <[email-masked]>

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 26 Aug 2010 09:32:54 +0800

Hi Phil,

I believe our discussion becomes more and more focused, please see my
comments inline.

> -----Original Message-----
> From: Philip Chimento [mailto:[email-masked]]
> Sent: Thursday, August 26, 2010 8:32 AM
> To: Xiangsong Cui
> Cc: Joseph Ishac; [email-masked]
> I have been busy and have not been able to respond quickly over the past
week
> or so.
> 
> The origin of RFC 5136 was to try to make precise what was being and
should
> be measured by the many tools that attempt to determine the "bandwidth" of
> a source-to-destination path at a given time.

Agree, we did talk about source-to-destination path.

 We spoke at the time of having
> another informational RFC discussing the current state of "bandwidth"
> measurement tools, but it was decided not to pursue it. This RFC was not
> intended to be an element-by-element model of the network. The whole point
> was to capture what was meant by "bandwidth".

I don't understand what "element-by-element model" means,
The path definition of "a path P of length n as a series of links" is
element-by-element?
The path capacity C(P,T,I) = min {1..n} {C(Ln,T,I)} is element-by-element?

> 
> I disagree with your statement that C(L,T,I) is node independent (in the
context
> of this RFC). Take the instance of, say, a firewall, in the path between
two
> routers. Suppose that the firewall is only capable of a throughput of  10
Mb/s
> but is connected to the routers by 100 Mb/s Ethernet links. We can say
that the
> IP Type P Capacity is 10 Mb/s for the "link" (which is really a path)
between the
> two routers. 

Good instance. Do you mean

Router1--------connection1-----firewall-----connection2-----router2?

My first question, How many links are there in this network?
My answer is TWO, one is between router 1 and firewall (i.e., connection1), 
the other is between firewall and router2 (i.e., connection2).
There is a path between router 1 and router 2, 
but, router1 and router2 IS NOT CONNECTED BY ONE LINK.

PS, imho,
In the internet, there are only IP node and non-IP node, and, IP node
consists of host and router.
All firewall, application-layer-gateway are routers, although they have more
functionalities.

You could include the firewall if you wanted to, in which case the
> IP Type P Capacity would be 10 Mb/s for both links, but there wouldn't
really be
> any point.

No, I would like to say, in this case,
Link1 capacity is 100Mbps, link2 capacity is 100Mbps, path capacity is 10M
bps.

> - Phase 1: You are right, in this case, the IP Type P Capacity reaches the
> Nominal Link Capacity of both Link 1 and Link 2. The IP Type P Capacity of
links 3
> and 4 is 0. If the IP Type P Capacity is 0, then the utilization also has
to be 0. I
> believe that this is consistent with normal engineering usage.

This seems very strange to me,
Link capacity is defined as "the maximum number of IP-layer bits that can be
transmitted"
If the capacity is 0, do you mean the max number of bits can be transmitted
in this link is 0?
If the link can only transmit 0 bit, is it an active link or unavailable
link?

> 
> - Phase 2: You postulate that the router is able to share its backplane
capacity
> fairly. 

Yes, because all the traffic are type P packets.

Then if the router is designed so that it shares exactly fairly among all
> active links, then the IP Type P Capacity of links 1,2,3 and 4 is 500
Mb/s,
> because that is the highest rate at which bits can be (correctly)
delivered.

But my question here is the link utilization, does it change from phase 1?

> Suppose that nodes B and D transmit in the reverse direction (to A and C,
> respectively) and that the backplane capacity of the router is 1 Gb/s
total (both
> directions). Then the IP Type P Capacity is only 250 Mb/s for links
1,2,3,4.
> 
> - Phase 3: This is exactly the same as Phase 1, just exchanging link and
node
> labels.
> 
> The reason that things are defined this way is that this is what you would
see if
> you were to probe this network with a "bandwidth" measurement tool.

No problem here, but when we get a final result, how to say that?
Can we classify the reason to some one factor?
I mean if the result is affected by multiple *parallel* factors, 
can we speak the result is only affected by one factor A, and other factors
are sub-factor of factor A?
This RFC is not about probe, but describes the principle and arithmetic,
imho.

> 
> A router with more links and a given backplane design could give you more
> quirky behavior depending on internal congestion patterns or hot spots in
the
> switching fabric. For the purposes of the RFC, it doesn't matter whether a
> node's design, or fast fading of a wireless link is limiting the capacity,
it only
> matters that the capacity is limited. That is why we do not separate links
and
> nodes as separate entities. Given real node behavior, you can't assign a
single
> node capacity (especially to routers and switches) 

I have to say, we should do right actions firstly, 
if action A is right, but difficult to do, while action B is easy to do, can
we choose B?
we should do the right job, but not the easy job, right?

because it depends on the
> design of the node and what other traffic is present at a given time.

Yes, I agree this, and I think this may also be wrote in RFC documents, if
needed.

> 
> At this point, my opinion is that we do not need a new draft or RFC; I
would be
> happy to add the above explanations (or some variant) as a
correction/update
> to the RFC,  

I think we need a bulk modification.

but I defer to Henk, Matt and the opinion of the workgroup.

Me too.

Best regards
Xiangsong

> > We come to link capacity again, I showed my option on this problem in
the
> link:
> > Is IP node is a part or a IP link?  I guess not, because link is the
layer2-level
> connection, it is the media, the facility, the layer2 protocol..., but
does Not
> cover nodes, which is a layer3 concept.
> >
> > In the following scenario, where link1/link2/link3/link4 physical
capacity is 1.x
> G bps, they all use the same link protocol, and we assume their "physical
IP
> capacity" is 1G bps. Same way, the router IP capacity is 1G bps.
> >
> > Phase 1, only host A transmit packets (IP-type-P) to host B, other hosts
don't
> transimit any packet.
> > Base on RFC5136, the IP capacity of link1 and link2 is 1G bps for the
certain
> time/period, the link usage is same. IP capacity of link3 and link4 is 0
bps and
> link usage is also same (althouth their physical IP capacity is 1G bps).
As to
> IP-type-P Link Utilization, base on the definition of RFC5136, Util(L,T,I)
=
> ( Used(L,T,I) / C(L,T,I) ), so we can get: IP-type-P Link Utilization of
link1 is 100%
> (1G bps/1G bps), this looks right, but how about link3 and link4? the
IP-type-P
> Link Utilization of link3 is 0/0, what does this mean? (in my mind, when a
link is
> idle, the link utilization is 0, but not 0/0)
> >
> > Well, phase 2, host C begin to transmit packets (IP-type-P) to host D
(others
> keep unchanged, same networks, same nodes, same links....), also at the
rate
> 1G bps.
> > Unfortunately, router over-loads, but it still works fairly. so
> link1/link2/link3/link4 IP traffic rate is 500M bps. OK, what is the
metric? Base
> on RFC5136, the IP capacity of link1 and link2 is 500M bps  for the
certain
> time/period, the link usage is same. IP capacity of link3 and link4 is
500M bps
> for the certain time/period and link usage is also same. As to IP-type-P
Link
> Utilization, base on the definition of RFC5136, Util(L,T,I) = (
Used(L,T,I) /
> C(L,T,I) ), so we can get: IP-type-P Link Utilization of link1 is 100%
(500M
> bps/500M bps), this looks very strange, Link Utilization is unchaged,
really?
> How about link3 and link4? the IP-type-P Link Utilization of link3 is 100%
(500M
> / 500M)?
> >
> > Now, it is phase 3, host A stop transmitting packets, host C still
transmitting
> as before.
> > Base on RFC5136, the IP capacity of link1 and link2 is 0 G bps, the link
usage is
> same. IP capacity of link3 and link4 is 1G bps and link usage is also
same.
> > All of these, are more and more
confusing.....................................

---

From: Henk Uijterwaal <[email-masked]>
Date: Fri, 27 Aug 2010 11:13:16 +0200

IPPM group,

You have probably seen the discussion on RFC 5136.  The state of the
discussion is now:

Phil:
>> would be happy to add the above explanations (or some variant) as a
>> correction/update to the RFC,  

> but I defer to Henk, Matt and the opinion of the workgroup.

I'd appreciate it if people who have been following this discussion,
voiced their opinion about this.  A 1 line comment ("note" or "new RFC")
is already helpful.

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.xs4all.nl/~henku
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

I confirm today what I denied yesterday.            Anonymous Politician.

---

From: Al Morton <[email-masked]>
Date: Fri, 27 Aug 2010 09:28:42 -0400

At 05:13 AM 8/27/2010, Henk Uijterwaal wrote:

...I'd appreciate it if people
who have been following this discussion,

voiced their opinion about this.  A 1 line comment ("note"
or "new RFC")

is already helpful.

Henk

I've briefly contributed to this discussion and followed

the exchange since then.  IPPM has spent the overwhelming

majority of its effort on defining metrics that are also measurable.

If Black-Box Nodes were to be measured in isolation, they must be

connected to measurement devices by something - interfaces and

the media between them. A glance at any of BMWG's methodologies

confirms this reality.

http://datatracker.ietf.org/wg/bmwg/

Looking at one of the fundamental journal articles for this
topic:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.2468

"Bandwidth estimation: metrics, measurement techniques, and
tools",

R.Prasad, et al.

Section II immediately sorts through the terminology needed and

sets the definitions for the work that follows:

"In the following discussion we distinguish between

links at the data link layer (“layer-2”) and links at the IP

layer (“layer-3”). We call the former segments and the

latter hops. A segment normally corresponds to a physical

point-to-point link, a virtual circuit, or to a shared

access local area network (e.g., an Ethernet collision

domain, or an FDDI ring). In contrast, a hop may consist

of a sequence of one or more segments, connected

through switches, bridges, or other layer-2 devices. "
IMO, we need a note to capture similar assumptions for RFC 5136
terminology.

Al

---

From: Xiangsong Cui <[email-masked]>
Date: Sat, 28 Aug 2010 08:39:44 +0800

I'm OK to link and link capacity, my concerns are path and path capacity.

links at the data link layer ("layer-2") and links at the IP 

layer ("layer-3"). We call the former segments and the 

all of this describes link, without mention of path.

Xiangsong

From: [email-masked] [mailto:[email-masked]] On Behalf Of Al
Morton
Sent: Friday, August 27, 2010 9:29 PM
To: Henk Uijterwaal; [email-masked]
Subject: Re: [ippm] Question/comment on RFC5136

...I'd appreciate it if people who have been following this discussion,
voiced their opinion about this.  A 1 line comment ("note" or "new RFC")
is already helpful.

Henk

confirms this reality. http://datatracker.ietf.org/wg/bmwg/

Looking at one of the fundamental journal articles for this topic:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.2468
"Bandwidth estimation: metrics, measurement techniques, and tools",
R.Prasad, et al.

links at the data link layer ("layer-2") and links at the IP 

layer ("layer-3"). We call the former segments and the 

IMO, we need a note to capture similar assumptions for RFC 5136 terminology.

Al