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

From: [email-masked]
Date: Wed, 11 Aug 2010 09:31:36 -0500 (CDT)

Hi Al:
That's fine with me. Who would determine direction on this? Henk and Matt?
Regards,
Phil Chimento

Aug 11, 2010 09:36:22 AM, [email-masked] wrote:

Hi Phil,

Perhaps this issue can be fully addressed with a short note,

essentially your text below submitted as an Errata

to RFC 5136.

I think the concepts below were clearly understood

by the working group when we were working on the draft,

and so a simple clarification should be sufficient now.

Al

At 09:23 AM 8/11/2010, [email-masked] wrote:

Xiangsong:

We did not forget to include the node capacity. As I explained, the node
capacity and characteristics are implicitly included in the link capacity
(that is, any restrictions in the node's performance will impact its
ability to transmit IP packets at a given rate. So, for example, if you
have a node with an outgoing link of 10 Gb/s and the node is only capable
of transmitting 3 Gb/s at a given time on that link, then that is the
capacity of that link at that time (note that we have a time parameter
associated with each metric).

I understand that you would prefer to have this made explicit. It is too
bad that your comments did not come earlier, but I see you have submitted
your own draft.

Regards,

Phil Chimento

Aug 10, 2010 09:35:25 PM, [email-masked] wrote:

Hi Phil,

I know the precondition of IP-type-P, in my initial example, the
first sentence is " For some certain packet/traffic,...", so we
are

both talking about the capacity for IP-type-P and all we are
discussing is about IP-type-P. I'm not discussing Layer 1 or layer 2

either, I'm talking about path and path capacity (in the precondition
of IP-type-P, not physical capacity but IP capacity).

My concerns are:

the middle-box should be included in the definition of path,

the IP-type-P IP capacity of the middle-box should be considered in
IP-type-P Path Capacity.

I believe IP-type-P Path Capacity is a very important metric, I like
it, and just want to make it more accurate although that is a

hard job.

Regards,

Xiangsong

----- Original Message -----

From:

To:

Cc:

Sent: Tuesday, August 10, 2010 10:06 PM

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

Xiangsong:

Please notice that these are "IP-type-P ...Capacity". The
same physical/logical path can have different capacities depending on the

type of IP packets sent, for example, packets with different DSCP
values may see different capacities (because of traffic class

definitions in routers, for example). We were not trying to define
this at Layer 1 or Layer 2. The formulas should all refer to IP

capacity of links and paths, not to the physical capacity per se
(which is an upper bound that in practice is never reached).

Regards,

Phil Chimento

Aug 10, 2010 09:09:43 AM, [email-masked] wrote:

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

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

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

------------------------------------------------------------------------------

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

--------------------------------------------------------------------------------

> _______________________________________________

> ippm mailing list

> [email-masked]

https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________

ippm mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/ippm

---

From: Al Morton <[email-masked]>
Date: Wed, 11 Aug 2010 10:40:58 -0400

At 10:31 AM 8/11/2010, [email-masked] wrote:

Hi Al:

That's fine with me. Who would determine direction on this? Henk and
Matt?

Ultimately, I think an Errata makes sense here whether there's

a new draft or not.

IIRC, the Errata must be approved by some combination

of authors and chairs, but anyone can submit Errata using the
on-line

system. That would get the process rolling.

Al

Regards,

Phil Chimento

Hi Phil,

to RFC 5136.

Al

Xiangsong:

We did not forget to include the node capacity. As I explained, the
node capacity and characteristics are implicitly included in the link
capacity (that is, any restrictions in the node's performance will impact
its ability to transmit IP packets at a given rate. So, for example, if
you have a node with an outgoing link of 10 Gb/s and the node is only
capable of transmitting 3 Gb/s at a given time on that link, then that is
the capacity of that link at that time (note that we have a time
parameter associated with each metric).

I understand that you would prefer to have this made explicit. It is
too bad that your comments did not come earlier, but I see you have
submitted your own draft.

Regards,

Phil Chimento

---

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 25 Aug 2010 11:26:14 +0200

All,

Catching up after 3 weeks of vacation...

> Ultimately, I think an Errata makes sense here whether there's

If I understand the discussion correctly, then I think a note to clarify
this is in order.

> of authors and chairs, but anyone can submit Errata using the on-line

That is correct.  I suggest that the original poster (i.e. Xiangsong)
submits the errate.  The authors and chairs can verify this.  If the
issue can be explained as in section 3 of the draft from Xiangsong,
then I don't think that a new RFC is needed.  If not, the WG can pick
up the draft as a work item, with the goal of replacing 5136.

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.