Subject: Re: [ippm] Question/comment on RFC5136

From: [email-masked]
Date: Fri, 27 Aug 2010 09:38:02 -0500 (CDT)

A few more comments on Xiangsong's last e-mail:

1) "element-by-element" means that you want to characterize each network element individually. Joseph and I have both explained why we think this does not help the definition of capacity in this case.
2) A router would look at the firewall example as 1 hop (not two links, the firewall is invisible to the router). While you COULD look at it your way, it doesn't bring any additional insight to the achievable capacity between these two nodes, which for whatever reason remains limited to 10 Mb/s.
3) Yes, at that time, the maximum number of IP bits that can be transmitted on that path is 0. When you start sending another stream and the router re-allocates resources, the capacity changes.
4) No, under the conditions postulated, the link utilization does not change. When the router is dividing the entire capacity evenly between two streams and there is no capacity left, then the utilization is 100%.
5) I don't understand your comments about factors.
6) However to reply to the next comment, we were not lazy in not including a node capacity definition, and it wasn't because it was too hard. It was because it didn't make sense to do so.

Regarding Al Morton's proposal, I am fine with that.

Thanks.
Regards,
Phil Chimento

Aug 25, 2010 09:33:13 PM, [email-masked] wrote:

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]
> Subject: Re: [ippm] Question/comment on RFC5136
>
> 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.

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.

>
> 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.

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

>
> Regards,
> Phil Chimento
> [email-masked]
>
>
>
> On Aug 12, 2010, at 9:24 PM, Xiangsong Cui wrote:
>
> > 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"
> > To: "Xiangsong Cui"
> > Cc:
> > 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 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).
> >>
> >> 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.
> >>
> >>> 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)}
> >>
> >> 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
> >
> > _______________________________________________
> > ippm mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ippm

---

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

Just a quick response.

Your statements seems to me that link is an end-to-end concept, but not a hop-by-hop concept, so the firewall is just a hop of the link but does not split the path (i.e., between the source and the destination) to two links. This is really different from my thought.

PS, nobody says routers should be visible to the source, we all know the source transmits packet to the destination but not to the on-way routers.

I would like to wait the decision of working group now.

Thanks and best regards

Xiangsong

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, August 27, 2010 10:38 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: RE: [ippm] Question/comment on RFC5136

Thanks. 
Regards, 
Phil Chimento

Hi Phil,

week
should

context
two
Mb/s
that the
between the

PS, imho,

really be

links 3
to be 0. I

capacity

Mb/s,
delivered.

total (both
1,2,3,4.
node
see if

the
it only
and
single

would be
correction/update

Me too.

Best regards
Xiangsong

the
layer2-level
does Not
here.
capacity is 1.x
IP
don't
certain
bps and
As to
=
link1 is 100%
IP-type-P
link is
(others
rate
metric? Base
certain
500M bps
Link
Used(L,T,I) /
(500M
really?
(500M
transmitting
usage is
same.
to
of
as
we
to