Subject: [ippm] Impact of hosts on network capacity and RFC 5136

From: Joseph Ishac <[email-masked]>
Date: Wed, 30 Mar 2011 16:32:49 -0400

Folks,

There has been some recent debate regarding RFC 5136.  Specifically if the
impact of network hosts are accounted for in the definitions of network
capacity.

Phil and I have been discussing this off-list and by phone. We believe that
the following paragraphs from the RFC clearly highlight our intent to indeed
capture such effects as they all relate to the role of endpoints as only a
portion in determining the capacity of any "link".

End of Section 1:

  Aside from questions of coding efficiency, there are issues of how
>   access to the channel is controlled, which also may affect the
>   capacity.  For example, a multiple-access medium with collision
>   detection, avoidance, and recovery mechanisms has a varying capacity
>   from the point of view of the users.  This varying capacity depends
>   upon the total number of users contending for the medium, how busy
>   the users are, and bounds resulting from the mechanisms themselves.
>   RF channels may also vary in capacity, depending on range,
>   environmental conditions, mobility, shadowing, etc.

  The important points to derive from this discussion are these: First,
>   capacity is only meaningful when defined relative to a given protocol
>   layer in the network.  It is meaningless to speak of "link" capacity
>   without qualifying exactly what is meant.  Second, capacity is not
>   necessarily fixed, and consequently, a single measure of capacity at
>   any layer may in fact provide a skewed picture (either optimistic or
>   pessimistic) of what is actually available.

Section 2.3.1.2

  The definitions in this document refer to "Type P" packets to
>   designate a particular type of flow or sets of flows.  As defined in
>   RFC 2330, Section 13, "Type P" is a placeholder for what may be an
>   explicit specification of the packet flows referenced by the metric,
>   or it may be a very loose specification encompassing aggregates.  We
>   use the "Type P" designation in these definitions in order to
>   emphasize two things: First, that the value of the capacity
>   measurement depends on the types of flows referenced in the
>   definition.  This is because networks may treat packets differently
>   (in terms of queuing and scheduling) based on their markings and
>   classification.  Networks may also arbitrarily decide to flow-balance
>   based on the packet type or flow type and thereby affect capacity
>   measurements.  Second, the measurement of capacity depends not only
>   on the type of the reference packets, but also on the types of the
>   packets in the "population" with which the flows of interest share
>   the links in the path.

Section 2.3.2.  Definition: IP-type-P Link Capacity

  As mentioned earlier, this definition is affected by many factors
>   that may change over time.  *For example, a device's ability to
>   process and forward IP packets for a particular link may have varying
>   effect on capacity*, depending on the amount or type of traffic being
>   processed.

To summarize RFC 5136, we define nodes as hosts, routers, Ethernet switches,
or any other device and a link as a connection between two of these
network devices or nodes.  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.  Furthermore, we define a link L as a special case where
the path length is one.

Meaning:

   - The definition of nodes have been extended from RFC 2330 to include any
   devices which can impact IP datagrams
   - A link is a connection between two network devices or nodes
   - The definition of a Path (P) is a sequence of (n+1) nodes and (n)
   links for which a Source resides at N(1) and a Destination at N(n+1)
   - The definition of a Link (L) is the case where n=1 above.  Thus
   it includes two devices and one link

Thus, the usage of a link L in this document refers to two nodes and
the link between those devices and not simply the link between the
nodes. When we later define the capacity of L, it incorporates the
complexities of both the devices and the link between them and does not
simply mean the "capacity of the physical (virtual) link" that exists
between those two nodes.

Thanks!

-Joseph and Phil

---

From: Steve Baillargeon <[email-masked]>
Date: Thu, 31 Mar 2011 02:49:21 -0400

Hi Joseph
I agree.
In my opinion, the current definitions in RFC5136 are covering all cases.
I don't see the need to breakdown the network entities further.
All operators that I know refers to link and link capacity as you have defined them.

-Steve

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joseph Ishac
Sent: March-30-11 4:33 PM
To: IETF IPPM WG
Cc: Chimento, Philip F.
Subject: [ippm] Impact of hosts on network capacity and RFC 5136

Folks,

There has been some recent debate regarding RFC 5136.  Specifically if the impact of network hosts are accounted for in the definitions of network capacity.

Phil and I have been discussing this off-list and by phone. We believe that the following paragraphs from the RFC clearly highlight our intent to indeed capture such effects as they all relate to the role of endpoints as only a portion in determining the capacity of any "link".

End of Section 1:

Section 2.3.1.2

  As mentioned earlier, this definition is affected by many factors
  that may change over time.  For example, a device's ability to
  process and forward IP packets for a particular link may have varying
  effect on capacity, depending on the amount or type of traffic being
  processed.

To summarize RFC 5136, we define nodes as hosts, routers, Ethernet switches, or any other device and a link as a connection between two of these network devices or nodes.  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.  Furthermore, we define a link L as a special case where the path length is one.

Meaning:

 *   The definition of nodes have been extended from RFC 2330 to include any devices which can impact IP datagrams
 *   A link is a connection between two network devices or nodes
 *   The definition of a Path (P) is a sequence of (n+1) nodes and (n) links for which a Source resides at N(1) and a Destination at N(n+1)
 *   The definition of a Link (L) is the case where n=1 above.  Thus it includes two devices and one link

Thus, the usage of a link L in this document refers to two nodes and the link between those devices and not simply the link between the nodes. When we later define the capacity of L, it incorporates the complexities of both the devices and the link between them and does not simply mean the "capacity of the physical (virtual) link" that exists between those two nodes.

Thanks!

-Joseph and Phil

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 31 Mar 2011 15:20:33 +0800

Dear Joseph and Phil,

Thanks for your clarification, and here I would like to have an E-mail dicssion with you.
Please see my comments below.

----- 原邮件 -----
发件人: Joseph Ishac <[email-masked]>
日期: 星期四, 三月 31日, 2011 上午4:33
主题: [ippm] Impact of hosts on network capacity and RFC 5136
收件人: IETF IPPM WG <[email-masked]>
抄送: "Chimento, Philip F." <[email-masked]>

> impact of network hosts are accounted for in the definitions of 
> networkcapacity.
> 
> >   detection, avoidance, and recovery mechanisms has a varying 
> capacity>   from the point of view of the users.  This varying 
> capacity depends
> >   the users are, and bounds resulting from the mechanisms 
> themselves.>   RF channels may also vary in capacity, depending on 
> range,>   environmental conditions, mobility, shadowing, etc.

I do agree this paragraph, there is no problem.

> 
> 
>  The important points to derive from this discussion are these: 
> First,>   capacity is only meaningful when defined relative to a 
> given protocol
> >   layer in the network.  It is meaningless to speak of "link" 
> capacity>   without qualifying exactly what is meant.  Second, 
> capacity is not

I almost agree this paragraph, and I just want to focus on "IP-layer" here.

> >   explicit specification of the packet flows referenced by the 
> metric,>   or it may be a very loose specification encompassing 
> aggregates.  We
> >   definition.  This is because networks may treat packets 
> differently>   (in terms of queuing and scheduling) based on their 
> markings and
> >   classification.  Networks may also arbitrarily decide to flow-
> balance>   based on the packet type or flow type and thereby 
> affect capacity
> >   measurements.  Second, the measurement of capacity depends not 
> only>   on the type of the reference packets, but also on the 
> types of the

I have no problem with "Type-P packet".
What is more, I think above statement has no relation to our debate.

> >   process and forward IP packets for a particular link may have 
> varying>   effect on capacity*, depending on the amount or type of 
> traffic being
> >   processed.
> 

Yes, I get your point here. However, that is exactly my concern.
You mean you combined (or say enbeded) nodes inside link, right?
I just don'think this is appropriate.

> 
> 
> To summarize RFC 5136, we define nodes as hosts, routers, Ethernet 
> switches,or any other device and a link as a connection between 
> two of these

Do you mean the "link" is exactly the connection between nodes?
Or you mean the link is the "combination" of "the connection between nodes" + "the nodes themselves"?

>   links for which a Source resides at N(1) and a Destination at 
> N(n+1)   - The definition of a Link (L) is the case where n=1 
> above.  Thus
> nodes. 

Let me try to understand your words, there are three "link" in this sentence.
"LINK L", yes, I get it.
There are also <and the "link" between those devices> & <not simply the "link" between the nodes>, I'm fully confused now, do you mean "link L" is NOT a link? I don't think people would understand this well.

When we later define the capacity of L, it incorporates the

So you are speaking "the capacity of L" is NOT "the capacity of a link", but capacity of something else, right? Then, what is its meaning for people who are only familiar with normal "link", "node" and "path" concept?

By the way, could you please answer my questions in my presentation slides?
In slide 7,

! Link1 capacity (IP layer), 0.99 M or 990 M?   
! Link1 utilization (IP layer), 0.1% or 100%?   
! Link2 capacity (IP layer), 0.99 M or 99 M?     
! Link2 utilization (IP layer), 1% or 100%?      
! Path (Src to Dst) capacity (IP layer)?        
! Available path capacity (IP layer)?           

Thanks and best regards,
Xiangsong

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 31 Mar 2011 15:22:12 +0800

The presentation slides is http://www.ietf.org/proceedings/80/slides/ippm-4.pdf.

Best Regards
Xiangsong

---

From: Steve Baillargeon <[email-masked]>
Date: Thu, 31 Mar 2011 04:35:23 -0400

In my book, this is a special case. I believe in most cases, the IP-type-P link capacity is the "IP-layer link speed".
The definition of the IP-type-P link capacity in RFC5136 already indicates or implies the link capacity can be smaller than the "link speed". 
It is up to the implementer to choose how to report the link capacity as they see fit based on their implementation or environment (e.g effective link capacity). 
Do we need to add a new definition called IP-Type-P link speed? I don't believe so.

-Steve

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xiangsong Cui
Sent: March-31-11 3:22 AM
To: Joseph Ishac
Cc: Chimento, Philip F.; IETF IPPM WG
Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136

Best Regards
Xiangsong

----- 原邮件 -----
发件人: Joseph Ishac <[email-masked]>
日期: 星期四, 三月 31日, 2011 上午4:33
主题: [ippm] Impact of hosts on network capacity and RFC 5136
收件人: IETF IPPM WG <[email-masked]>
抄送: "Chimento, Philip F." <[email-masked]>

> Phil and I have been discussing this off-list and by phone. We believe 
> that the following paragraphs from the RFC clearly highlight our 
> intent to indeed capture such effects as they all relate to the role 
> of endpoints as only a portion in determining the capacity of any 
> "link".
> 
> End of Section 1:
> 
> switches,or any other device and a link as a connection between two of 
> these network devices or nodes.  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
> complexities of both the devices and the link between them and does 
> not simply mean the "capacity of the physical (virtual) link" that 
> exists between those two nodes.
> 
> Thanks!
> 
> -Joseph and Phil
>

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 31 Mar 2011 16:39:28 +0800

Hi Steve,

> All operators that I know refers to link and link capacity as you 

I'm not sure, but could you please give me some examples?

What I know is, for example, the information theory, http://en.wikipedia.org/wiki/Information_theory,
which takes the reference model of <"Transmitter" + "Channel" + Receiver">.

Do you mean guys usually take transmitter and receiver as part of channel?
Or you mean the maximum performance value of the channel is transmitter-dependent?

Best regards,
Xiangsong

> There has been some recent debate regarding RFC 5136.  
> Specifically if the impact of network hosts are accounted for in 
> the definitions of network capacity.
> 
> Phil and I have been discussing this off-list and by phone. We 
> believe that the following paragraphs from the RFC clearly 
> highlight our intent to indeed capture such effects as they all 
> relate to the role of endpoints as only a portion in determining 
> the capacity of any "link".
> 
> End of Section 1:
> 
> First,  capacity is only meaningful when defined relative to a 
> given protocol
> balance  based on the packet type or flow type and thereby affect 
> capacity  measurements.  Second, the measurement of capacity 
> depends not only
> varying  effect on capacity, depending on the amount or type of 
> traffic being
>  processed.
> 
> 
> switches, or any other device and a link as a connection between 
> two of these network devices or nodes.  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.  Furthermore, we define a 
> link L as a special case where the path length is one.
> 
> Meaning:
> 
> *   The definition of nodes have been extended from RFC 2330 to 
> include any devices which can impact IP datagrams
> *   The definition of a Path (P) is a sequence of (n+1) nodes and 
> (n) links for which a Source resides at N(1) and a Destination at 
> N(n+1) *   The definition of a Link (L) is the case where n=1 
> above.  Thus it includes two devices and one link
> 
> Thus, the usage of a link L in this document refers to two nodes 
> and the link between those devices and not simply the link between 
> the nodes. When we later define the capacity of L, it incorporates 
> the complexities of both the devices and the link between them and 
> does not simply mean the "capacity of the physical (virtual) link" 
> that exists between those two nodes.
> 
> Thanks!
> 
> -Joseph and Phil
>

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 31 Mar 2011 16:50:08 +0800

> In my book, this is a special case. 

could you please explain why this is a special case?
because there is a router in the network?
or because the "capacity of the router" is less than "the capacity of the links"
if it is the latter, then there is a different capacity of the link in your mind, right?

Best regards,
Xiangosng

I believe in most cases, the 
> IP-type-P link capacity is the "IP-layer link speed".
> The definition of the IP-type-P link capacity in RFC5136 already 
> indicates or implies the link capacity can be smaller than the 
> "link speed". 
> It is up to the implementer to choose how to report the link 
> capacity as they see fit based on their implementation or 
> environment (e.g effective link capacity). 
> The presentation slides is 
> http://www.ietf.org/proceedings/80/slides/ippm-4.pdf.
> 
> Best Regards
> Xiangsong
> 
> ----- 原邮件 -----
> > Specifically if the
> believe 
> > >   packets in the "population" with which the flows of interest 
> share> >   the links in the path.
> > 
> > 
> two of 
> and

---

From: Andreas Johnsson A <[email-masked]>
Date: Thu, 31 Mar 2011 11:17:58 +0200

Since I'm one of the authors of the capacity metric parts of Y.1540 that Xiangsong are referring to in his slide set, I think I should stick my head into this debate.

In my view, everything seem to boil down to whether we assume that the definition of a link in RFC5136 encompass the interconnected hosts (or parts of them) or not. Xiangsong believe that the hosts are not inherently part of the link concept while the authors of the RFC do. Right? I think we need to clarify (since it obviously is not clear) this very basic thing on today's meeting. 

Best regards,
Andreas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xiangsong Cui
Sent: den 31 mars 2011 10:50
To: Steve Baillargeon
Cc: Chimento, Philip F.; IETF IPPM WG
Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136

Best regards,
Xiangosng

> indicates or implies the link capacity can be smaller than the "link 
> speed".
> It is up to the implementer to choose how to report the link capacity 
> as they see fit based on their implementation or environment (e.g 
> effective link capacity).

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 31 Mar 2011 17:35:47 +0800

> 
> In my view, everything seem to boil down to whether we assume that 
> the definition of a link in RFC5136 encompass the interconnected 
> hosts (or parts of them) or not. Xiangsong believe that the hosts 
> are not inherently part of the link concept while the authors of 
> the RFC do. Right? 

Exactly! At least on my side.
This is the essential issue, I think.

I think we need to clarify (since it obviously 
> is not clear) this very basic thing on today's meeting. 

And yes, this is a very basic issue, so I propose to re-write this document.

Best regards,
Xiangsong

> "link 
> capacity 
> > Do we need to add a new definition called IP-Type-P link speed? 
> I 
> > don't believe so.
> > 
> > -Steve
> > 
> > From: [email-masked] [mailto:[email-masked]] On 
> Behalf 
> > Of Xiangsong Cui
> > > >   capacity.  For example, a multiple-access medium with 
> collision> > >   detection, avoidance, and recovery mechanisms has 
> a varying
> > > themselves.>   RF channels may also vary in capacity, 
> depending 
> > on
> > >   - The definition of nodes have been extended from RFC 2330 
> to 
> > > include any
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>

---

From: Steve Baillargeon <[email-masked]>
Date: Thu, 31 Mar 2011 05:55:17 -0400

It is up for debate.

My point is the basic definitions of a path and link should be consistent.

In my book, a path can be made of multiple links and nodes and a link is simply a subset of that definition.
This is already indicated in section 2.1 of the RFC 5136.

-Steve

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xiangsong Cui
Sent: March-31-11 5:36 AM
To: Andreas Johnsson A
Cc: IETF IPPM WG
Subject: Re: [ippm] Impact of hosts on network capacity and RFC 5136

> 
> In my view, everything seem to boil down to whether we assume that the 
> definition of a link in RFC5136 encompass the interconnected hosts (or 
> parts of them) or not. Xiangsong believe that the hosts are not 
> inherently part of the link concept while the authors of the RFC do. 
> Right?

Best regards,
Xiangsong

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 31 Mar 2011 19:00:42 +0800

> My point is the basic definitions of a path and link should be 

I didn't get your point clearly, do you mean the definitions of path and link should be same or be compatible?

> In my book, a path can be made of multiple links and nodes and a 

Yes, this is the basic definition, also in my book and RFC2330, a path is made of links and nodes, but RFC5136 says path is made of ONLY links, and without explicit nodes. (nodes perhaps hide inside links.)  

> link is simply a subset of that definition.

I guess you are speaking subpath, which is indicated in section 5 of RFC2330.
Otherwise, you are speaking "LINK" is a subset of "link" and "node", I cann't tell the diference between "LINK" and "link".

Best regards,
Xiangsong

> Behalf Of Xiangsong Cui
> > or because the "capacity of the router" is less than "the 
> capacity of 
> > the links"
> > if it is the latter, then there is a different capacity of the 
> link in 
> > your mind, right?
> > 
> > Best regards,
> > Xiangosng
> > 
> > > > First,>   capacity is only meaningful when defined relative 
> to 
> > a
> > > > given protocol
> > > > differently>   (in terms of queuing and scheduling) based on 
> their> > > markings and
> > > >  As mentioned earlier, this definition is affected by many 
> factors> > > >   that may change over time.  *For example, a device's
> > ability to
> > > > >   process and forward IP packets for a particular link may 
> have> > > varying>   effect on capacity*, depending on the amount or
> > type of
> > > > traffic being
> > > > >   processed.
> > > > 
> > > > 
> > > > 
> > > > Nn+1, respectively.  Furthermore, we define a link L as a 
> special> > > case where
> > > > the path length is one.
> > > > 
> > > > Meaning:
> > > > 
> > > > not simply mean the "capacity of the physical (virtual) 
> link" 
> > > that

---

From: "Chimento, Philip F." <[email-masked]>
Date: Thu, 31 Mar 2011 09:44:20 -0400

Xiangsong:

> I almost agree this paragraph, and I just want to focus on "IP-layer" here.
I am not sure what you mean by “almost agree”. What part of it do you disagree with?
> What is more, I think above statement has no relation to our debate.
I think that perhaps you have missed the point of this paragraph: It is not only the
nodal capacity that has to be factored in. The capacity that any flow “sees” is also affected by how the node is configured to treat the packets. In a time of no congestion, where the flow is low priority, say the capacity available to it is X. In a time of congestion, where there are higher priority flows of capacity Z, the capacity available to the low priority flow is X-Z, not X.
> I just don'think this is appropriate.

No. We are not saying that the nodes are embedded in the link. We are saying that the endpoint is part of the link.
> There are also <and the "link" between those devices> & <not simply the "link"
> between the nodes>, I'm fully confused now, do you mean "link L" is NOT a
> link? I don't think people would understand this well.
>
I can see how this sentence can be confusing and I can see how re-wording could clear up the confusion. However, we do not need a new draft to do that.
> So you are speaking "the capacity of L" is NOT "the capacity of a link", but
> capacity of something else, right? Then, what is its meaning for people who
> are only familiar with normal "link", "node" and "path" concept?
>
We already say in the beginning of section 2.1 that we are modifying the definitions of Link and Path from what they were in RFC2330. You may not agree with how we have modified them, but we made it clear that we were changing the definitions.

> ! Link1 capacity (IP layer), 0.99 M or 990 M?
Link 1 IP  Layer capacity is 0.99Mb/s
> ! Link1 utilization (IP layer), 0.1% or 100%?
IP Layer Utilization is 100%
> ! Link2 capacity (IP layer), 0.99 M or 99 M?
Is the router only capable of forwarding 1Mb/s on link 2?
The answer depends on that.
> ! Path (Src to Dst) capacity (IP layer)?
0.99
> ! Available path capacity (IP layer)?
0
It is clear that your view is that what we call Nominal Capacity is the same as IP Layer capacity. We explicitly differentiate these two concepts.

>> simply mean the "capacity of the physical (virtual) link" that exists

Regards,
Phil Chimento

JHU/APL
240-228-1743
443-778-1743
[email-masked]
--

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 31 Mar 2011 22:09:57 +0800

> I am not sure what you mean by “almost agree”. What part of it do 

The reason that I said "almost" is the text from RFC2330, (copied below)

   "Such a metric will be called an 'analytically specified metric' or,
   more simply, an analytical metric.

   {Comment: Examples of such analytical metrics might include:

propagation time of a link
     The time, in seconds, required by a single bit to travel from the
     output port on one Internet host across a single link to another
     Internet host.

bandwidth of a link for packets of size k
     The capacity, in bits/second, where only those bits of the IP
     packet are counted, for packets of size k bytes.

routeThe path, as defined in Section 5, from A to B at a given time.

hop count of a route
     The value 'n' of the route path.
     }"

But your above statement doesn't clearly show that it is an analytical metric to me.

> share>>>   the links in the path.
> >>
> >
> nodal capacity that has to be factored in. The capacity that any 
> flow “sees” is also affected by how the node is configured to 
> treat the packets. In a time of no congestion, where the flow is 
> low priority, say the capacity available to it is X. In a time of 
> congestion, where there are higher priority flows of capacity Z, 
> the capacity available to the low priority flow is X-Z, not X.
> >>
> No. We are not saying that the nodes are embedded in the link. We 
> are saying that the endpoint is part of the link.

Yes, I do make sure you are saying node is part of the link now.
Do you think this is a major change to RFC2330 and RFC2460?
This is also very different from the definition from Y.1540.

And by the way, in my example, which link the router should belong to? Link 1 or Link 2?

Best regards,
Xiangsong

> > Or you mean the link is the "combination" of "the connection 
> between nodes" +
> > "the nodes themselves"?
> >
> I can see how this sentence can be confusing and I can see how re-
> wording could clear up the confusion. However, we do not need a 
> new draft to do that.
> >
> We already say in the beginning of section 2.1 that we are 
> modifying the definitions of Link and Path from what they were in 
> RFC2330. You may not agree with how we have modified them, but we 
> made it clear that we were changing the definitions.
> 
> It is clear that your view is that what we call Nominal Capacity 
> is the same as IP Layer capacity. We explicitly differentiate 
> these two concepts.
> 
> > Thanks and best regards,
> > Xiangsong
> >
> >> simply mean the "capacity of the physical (virtual) link" that 
> exists>> between those two nodes.
> >>
> >> Thanks!
> >>
> >> -Joseph and Phil
> >>
> 
> Regards,
> Phil Chimento
> 
> JHU/APL
> 240-228-1743
> 443-778-1743

---

From: "Chimento, Philip F." <[email-masked]>
Date: Thu, 31 Mar 2011 10:21:04 -0400

> This is also very different from the definition from Y.1540.

As just pointed out, I don't think that there is a fundamental different
between our definition of capacity (IP Layer) for links and Y.1540's
definition of capacity (IP Layer) for network section.
> And by the way, in my example, which link the router should belong to? Link 1
Both.

Regards, 
Phil Chimento

---

From: Joseph Ishac <[email-masked]>
Date: Thu, 31 Mar 2011 14:16:02 -0400

Passing on by request a nice concise example I was sent by Donald
McLachlan of crc.ca:

> I think what you are saying (for instance) is that:
> - Even if the path between the Src and Dst hosts (cabling, switches etc) can support (eg. 10 Gbps)
> - If the Sending host can only transmit at 10 Mbps
> - then the effective Link Capacity (as seen by Src and Dst) is at most 10 Mbps.

I'd like to add a few more examples that are covered by the current
wording in RFC 5136:

1) Employing encoding on a link, several of our links use Reed–Solomon
or rate 1/2 convolution encoding.
2) Passing through an underrated patch panel (say a Cat3 patch panel
when your trying to do 1000GbE) [incidentally don't ask if I've
experienced this first hand ...]

The wording in the RFC is meant to cover such limitations with both
the links and nodes.

-Joseph

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 01 Apr 2011 04:58:33 +0800

I'm wondering in what scenario, the link utilization is not equal to 100%?
Who can tell me what type the link utilization is, it's bool type or float type number?

Thanks for your teaching!

Best Regards
Xiangsong

----- 原邮件 -----
发件人: Joseph Ishac <[email-masked]>
日期: 星期五, 四月 1日, 2011 上午2:16
主题: Re: [ippm] Impact of hosts on network capacity and RFC 5136
收件人: IETF IPPM WG <[email-masked]>
抄送: "Chimento, Philip F." <[email-masked]>

> 1) Employing encoding on a link, several of our links use Reed?Solomon

---

From: Joseph Ishac <[email-masked]>
Date: Thu, 31 Mar 2011 17:51:57 -0400

Well, for a given packet type, Used(L,T,I) measures the *actual* usage
in a given time span.  C(L,T,I) is the maximum you *could* obtain in
that same time span.  So if the link is not actually saturated with
traffic, the link utilization will not be 100%.

If you try to think of actually trying to measure C() and Used() at
the same time, you're bound to get a headache.  That's why developing
the means of gathering the metrics was out of scope for the document.

Does that help answer your question?

-Joseph

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 01 Apr 2011 14:32:33 +0800

Joseph, 

thanks for your answer, but I think I still don't undersand that.

I don't understand what "link is saturated" means, for the example of my slides, in the Gb ethernet, 1M bit flow is saturated for the ethernet link? My answer is no, because link is a layer 2 notion, we have to judge its status in layer 2 viewpoint.

It comes back to the basic question, should the node is part of link?

What I want to say is, if we say node is part of link, perhaps we have to say the Internet is the set of "links", there is no host, no router, no NAT, no firewall, no ALG ..., is that strange? Aha, because all these nodes are inside the links.

Best Regards
Xiangsong

----- 原邮件 -----
发件人: Joseph Ishac <[email-masked]>
日期: 星期五, 四月 1日, 2011 上午5:52
主题: Re: [ippm] Impact of hosts on network capacity and RFC 5136
收件人: Xiangsong Cui <[email-masked]>
抄送: "Chimento, Philip F." <[email-masked]>, IETF IPPM WG <[email-masked]>

> >> 1) Employing encoding on a link, several of our links use 
> Reed?Solomon>> or rate 1/2 convolution encoding.
> >> 2) Passing through an underrated patch panel (say a Cat3 patch 
> panel>> when your trying to do 1000GbE) [incidentally don't ask if 
> I've>> experienced this first hand ...]
> >>