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

From: [email-masked]
Date: Tue, 10 Aug 2010 07:38:30 -0500 (CDT)

Hi Xiangsong:
The rfc  is actually about IP capacity, not about path capacity per se. The whole idea behind the rfc was to explore what
many of the "bandwidth" measurement tools were trying to measure. We settled on IP capacity because that is what a user sees; i.e.
what he can send and have correctly received from point A to point B at layer 3. This includes all the impairments from, say, a wireless link which
has variable capacity and variable quality, or from an intermediate node (router, switch, security device, take your pick) which has its backplane overloaded.
In your example, you are right, the rate is 2Gb/s because that is the rate of the correctly received IP bit stream.

Defining "path capacity" on a lower level is a daunting task because of the very large variety of middleboxes that exist (not just L2/L3 transport elements, but also NATs, load balancers, security devices, etc etc), many of which can have peculiar behaviors, not to mention the wide variety of link types that exist and do not have a fixed capacity. Anyway, I believe that it is out of scope of the IPPM WG (Henk, Matt, correct me if I am wrong).
Regards,
Phil Chimento

Aug 9, 2010 09:27:19 PM, [email-masked] wrote:

Hi Phil,

Thank you for your quick feedback!

I do agree your statement about IP capacity, but I think that is a higher level concept, here I just want to talk about Path
Capacity.
You said "The notion of "middle-box" capacity is, in effect, included in the definition of IP capacity.", my questions are:
Does the notion of "middle-box" capacity is included in the definition of Path Capacity? Should it be or not?

Additionally, I want to clarify my example, I also talked about IP capacity.

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

Node A sends IP packets to B at the rate of 5G bps, and all the packets are transferred by the router.
The router forwards the packets, but the rate exceeds its capacity, so unfortunately bit error happens in 60% packets, and what more
unfortunately is, the error bit is in IP header checksum.
Node B receives packets from the router, it detects the IP header checksum errors, so the accepted IP flow rate is 2G bps (the
capacity of the neckbottle, the router).

How should we say the capacity of the path between A and B?
I guess the capacity of the path is 2G bps, the invalid IP bandwidth is not our expected IP capacity (neither the link nor the
path), right?

Thanks and regards
Xiangsong

----- Original Message -----
From:
To:
Cc:
Sent: Monday, August 09, 2010 8:26 PM
Subject: Re: [ippm] Question/comment on RFC5136

Remember, what we are talking about here is the IP capacity, not raw link capacity. So the definition includes the number of IP
layer bits that can be transmitted by the source and received by the destination. Lots of things make this capacity smaller than the
nominal link capacity measured at the physical layer. Some things that can reduce the IP layer capacity include: node backplane
capcity, NIC implementation, queueing structure, buffer management, etc. etc. The notion of "middle-box" capacity is, in effect,
included in the definition of IP capacity.

Regards,
Phil Chimento

Aug 9, 2010 12:00:47 AM, [email-masked] wrote:

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

_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 10 Aug 2010 21:09:26 +0800

Hi Phil,

I'm more confused now,
You said "Defining "path capacity" on a lower level is a daunting task ......", and "Anyway, I believe that it is out of scope of the IPPM WG". I agree this is a diffucult task, but let's take a look at the table of content of RFC5136, which reads:

       2.3.2.  Definition: IP-type-P Link Capacity  . . . . . . . . .  7
       2.3.3.  Definition: IP-type-P Path Capacity  . . . . . . . . .  7
       2.3.4.  Definition: IP-type-P Link Usage . . . . . . . . . . .  7
       2.3.5.  Definition: IP-type-P Link Utilization . . . . . . . .  8
       2.3.6.  Definition: IP-type-P Available Link Capacity  . . . .  8
       2.3.7.  Definition: IP-type-P Available Path Capacity  . . . .  8

In these sections, many formula are specified, such as 

I think this RFC did specify the link capacity and path capacity (without consideration on the middle-boxes), and my questions come from these sections.

I am sorry I don't know well the history of this RFC, but I noticed you are the author of this document, so could you please tell me more information, e.g. the WG discussion?

Thanks and Best Regards
Xiangsong

Subject: Re: Re: [ippm] Question/comment on RFC5136
From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Tue, 10 Aug 2010 07:38:30 -0500 (CDT)

Hi Xiangsong:

Hi Phil,

Thanks and regards
Xiangsong

----- Original Message -----
From:
To:
Cc:
Sent: Monday, August 09, 2010 8:26 PM
Subject: Re: [ippm] Question/comment on RFC5136

Regards,
Phil Chimento

Hi folks,

C(P,T,I) = min ( X, Y)

Any thought?

Regards,
Xiangsong