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

From: Steve Baillargeon <[email-masked]>
Date: Fri, 1 Apr 2011 03:43:11 -0400

This is my last email on this exchange.
The IETF MIBs have defined separate MIBs for each layer.
Therefore stats should be produced at each layer as well.
The standards have allowed for a GE link utilization to be at 10% while the IP link utilization is at 100%.

-Steve

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

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

> 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
> 
> 2011/3/31 Xiangsong Cui <[email-masked]>:
> > 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]>
> >
> >> 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
> >> _______________________________________________
> >> 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: Xiangsong Cui <[email-masked]>
Date: Fri, 01 Apr 2011 16:07:29 +0800

Hi Steve,

> The IETF MIBs have defined separate MIBs for each layer.

Which RFC or draft?

> The standards have allowed for a GE link utilization to be at 10% 
> while the IP link utilization is at 100%.

Imho, you did bring a new terminology of "IP link" to IPPM ...

Xiangsong

> 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.
> 
> 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
> 
> ----- 原邮件 -----
> > the means of gathering the metrics was out of scope for the 
> document.>

---

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 06 Apr 2011 10:56:07 +0200

IPPM group,

We have had both email and voice discussions on this RFC over the last
week.  The mail that summarizes the issue, is, IMHO, this one:

   http://www.ietf.org/mail-archive/web/ippm/current/msg02585.html

(with some follow-ups).

I'd like to close this issue.  If you were involved in this discussion,
please indicate if there is anything to be said on the topic that hasn't
been brought up before.   If no new issues are raised, we'll make sure
that the above gets documented somehow and the issue is solved.  If there
is more to discuss, we can do so.  Deadline for responding is April 13,
i.e. next week.

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk(at)uijterwaal.nl
RIPE NCC                                  http://www.xs4all.nl/~henku
                                          Phone: +31.6.55861746
------------------------------------------------------------------------------

There appears to have been a collective retreat from reality that day.
                                 (John Glanfield, on an engineering project)

---

From: Steve Baillargeon <[email-masked]>
Date: Wed, 6 Apr 2011 08:44:15 -0400

Hi Henk
I have nothing new to add except to repeat my last question highlighted in the enclosed email.

I think Philip and Joseph are willing to look into the possibility to create a standard track document.

-Steve

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henk Uijterwaal
Sent: April-06-11 4:56 AM
To: [email-masked]
Subject: [ippm] RFC 5136

IPPM group,

We have had both email and voice discussions on this RFC over the last week.  The mail that summarizes the issue, is, IMHO, this one:

(with some follow-ups).

I'd like to close this issue.  If you were involved in this discussion, please indicate if there is anything to be said on the topic that hasn't
been brought up before.   If no new issues are raised, we'll make sure
that the above gets documented somehow and the issue is solved.  If there is more to discuss, we can do so.  Deadline for responding is April 13, i.e. next week.

Henk

There appears to have been a collective retreat from reality that day.
                                 (John Glanfield, on an engineering project) _______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

Subject: Standard Track for Capacity
From: Steve Baillargeon <[email-masked]>
To: Joseph Ishac <[email-masked]>, "Chimento, Philip F." <[email-masked]>
Cc: Henk Uijterwaal <[email-masked]>, Matthew J Zekauskas <[email-masked]>, IETF IPPM WG <[email-masked]>
Date: Fri, 1 Apr 2011 04:05:34 -0400

Hi Joseph, Hi Philip
I noticed that RFC 5136 is informational.
Is it possible to discuss the possibility to move it to a standard track (with the required additions)?
Or create a separate document that will become an Internet standard entitled "Capacity Metrics"?
What do you think?

-Steve

---

From: Al Morton <[email-masked]>
Date: Wed, 06 Apr 2011 08:57:48 -0400

To capture (and expand on) what I suggested at the meeting,
the last 3 paragraphs would make a good Eratta for the RFC,
beginning with a new sentence and an edit in the next,
as shown below:

There is a term ("Link") in RFC 5136 that is used differently from
the same term in RFC 2330, and this has caused some confusion.

To summarize the network framework of RFC 5136, we define nodes as hosts,
              ^^^^^^^^^^^^^^^^^^^^^^^^
...<remainder of the message follows for complete Errata text>

hope this helps,
Al