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

From: [email-masked]
Date: Tue, 10 Aug 2010 09:06:22 -0500 (CDT)

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

---

From: Xiangsong Cui <[email-masked]>
Date: Wed, 11 Aug 2010 09:35:12 +0800

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: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
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

  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:

  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

    Hi Phil,

    The router forwards the packets, but the rate exceeds its capacity, so unfortunately bit error happens in 60% packets, and what 
more

    Thanks and regards
    Xiangsong

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

    layer bits that can be transmitted by the source and received by the destination. Lots of things make this capacity smaller than 
the

    Regards,
    Phil Chimento

    Hi folks,

    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?

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

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

    Any thought?

    Regards,
    Xiangsong

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

---

From: Xiangsong Cui <[email-masked]>
Date: Wed, 11 Aug 2010 16:21:52 +0800

Hi Phil, and all,

I found some answer for my quesions now, I think this issue worth some discussion.

And, I have began the update draft, wish your feedback, would anybody like to co-author this document?

The draft (begin part) looks like:

Internet Engineering Task Force                              X. Cui, Ed.
Internet-Draft                                                    Huawei
Updates: 5136 (if approved)                              August 11, 2010
Intended status: Informational
Expires: February 12, 2011

                   Update RFC5136: Path and Capacity
                    draft-cui-ippm-path-capacity-00

Abstract

   RFC5136 defines network capacity and introduces definition of link,
   path, IP-type-P Link Capacity, IP-type-P Path Capacity, and IP-type-P
   Available Path Capacity.  But some notions in this document are not
   fully precise and confusing.  This document provides some
   clarification and update on RFC5136, especially on the definition of
   Path and Path Capacity.  One important modification on RFC5136 is
   that the in-path-nodes are considered in the definition of path and
   path capacity.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 12, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   Network Capacity is an improtant metric for internet and many
   documents have provided many definitions, measurement metholds,
   calculation formulas.  One example is RFC5136, which specifies Link
   Capacity and Path Capacity.  This document is expected to provide
   complementarity for network capacity, especially for path capacity.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Terminology

   This document uses the following terminology:

   o  Node: Same as the definintion of node of RFC2460, an IP node is a
      device that implements IP protocol.  In IP field, a node without
      special statement is IP node, refer to this definition.  There is
      a definition of host in RFC2330, which is equal to the definition
      of node of RFC2460.

   o  Non-IP node: In this document, a non-IP node is a entity that can
      transmit, receive or forward bit flow, but is not belong to the
      scope of IP node.  The examples of non-IP node are ethernet switch
      and hub.

   o  Host: Same as the definition of host of RFC2460, any node that is
      not a router.  Note that in RFC2330 the notion of host includes
      router, in this document, host doesn't include router.

   o  Link: As defined in RFC2330 and RFC2460, a link is a layer2-level
      connection between nodes.

   o  Path: As defined in RFC2330, a path is a sequence of the form
     < N0, L1, N1, ..., Ln, Nn >, where n >= 0, each Ni is a node, each
      Li is a link between Ni-1 and Ni, each N1...Nn-1 is a router.  A
      pair <Li, Ni> is termed a 'hop'.  In an appropriate operational
      configuration, the links and routers in the path facilitate
      network-layer communication of packets from N0 to Nn.  Note that
      path is a unidirectional concept.

   In section 2.1 of RFC5136, node, link and path are defined.  In this
   document, the definition of node, link and path are updated, as
   specified in this section.

3.  Discussion

   [Editor's note: This section may be removed by RFC-editor].

   Based on the definition of link, link is a layer2-level connection
   between IP nodes.  By this definition, neither the connection between
   ethernet switches nor the connection between IP node and ethernet
   switch is a true link, or in other words, those are not IP link.

   In the scenario of local area network, where host A and host B is
   connected by cable and an ethernet switch, it is need more study and
   dicussion whether the ethernet switch is a part of IP link.

   In section 2.1 of RFC5136, path is defined as "a path P of length n
   as a series of links (L1, L2, ..., Ln) connecting a sequence of nodes
   (N1, N2, ..., Nn+1)", which means the path is a set of links.  But if
   we compare this definition with RFC2330, we can find that the
   routers in the path (i.e. between the source node and the destination
   node), are completely removed.

   Accordingly, in section 2.3.3 of RFC5136, the router capacity is not
   considered in the formula of IP-type-P Path Capacity.

   RFC5136 specifies IP-type-P Path Capacity as

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

   which need more discussion.  This document suggests that
   the router capacity should be considered in IP-type-P Path
   Capacity.  The proposed formula is:

   C(P,T,I) = min (C-router, C-link)
   C-router = min {2..n} {C(Nn,T,I)}
   C-link   = min {1..n} {C(Ln,T,I)}

   For this proposal, we should additionally define "IP-type-P Router
   Capacity".  Routers are the core entities in internet, we can not
   define internet's network capacity without mentioning router
   capacity.

4.  IP-type-P Router Capacity

   TBD

5.  IP-type-P Path Capacity

   TBD

What do you think about this draft? Any commets are appreciated!

Regards,
Xiangsong

----- Original Message ----- 
From: "Xiangsong Cui" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 11, 2010 9:35 AM
Subject: Re: [ippm] Question/comment on RFC5136

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

[snip]

---

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

Hi all,

Speaking as a reader of the draft

> 3.  Discussion
[...]
>   C-link   = min {1..n} {C(Ln,T,I)}

I don't quite understand C-router.  In the most extreme case (2 computers
connected by a piece of wire), there is no router and the Path Capacity
is:

  C(P,T,I) = C(L1, T, I)

In the old formula, or in other words, the capacity of the the cable.  In
the new one, this would become:

    C(P,T,I) = min (C-router, C-link)
    C-router = min {0..0} {C(Nn,T,I)}
    C-link   = min {1..1} {C(Ln,T,I)} = C(L0,T,I).

And more general:

   C(P,T,I) = min (C-router, C-link)
   C-router = min {0..n} {C(Nn,T,I)}
   C-link   = min {1..n} {C(Ln,T,I)}

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.