Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70
From: [email-masked] (Scott O. Bradner)
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Thu, 22 Nov 2007 09:28:13 -0500 (EST)
List-Id: Performance Metrics at Other Layers <pmol.ietf.org>

> This draft deals with passive measurements at a higher layer

not all that passive

Scott

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

Date: Mon, 26 Nov 2007 08:50:50 +0900 (JST)
To: [email-masked]
Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70
From: KIKUCHI Yutaka <[email-masked]>
Organization: Kochi Univ. of Tech.
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

Lars-san, good morning from Japn.

> > I think our approach is very different from IPPMs'.
> > Our intention is to maintain all of tunnel flows in operation
> > to check continuously the SLAs of the flows.
> >
> > The measurment method should be very light-weight and scalable.
> > This is the top priority to deploy.
> > The metrics depend on less resource situation.
> > It is not much argurable how the metrics should be.
> >
> > Also, the method must be passive.
> > IPPM seems not to deal with passive measurement.
> 
> This is all well and good, but IPPM is *the* working group that  
> defines metrics for IP paths. Starting work in the same space in  
> another WG is not going to be productive.

I do agree with the last sentence, but I do not agree with
the second last sentence because our proposals should be
discussed in the operational sense.

A typical use case of the drafts is...

0. operators in an xSP or an iDC...
1. after setting up for watching every one of flows to servers,
2. while working with other tasks and listening music with iPod,
3. getting an alarm on a failure of some tunnels, and
4. checking the reason whether equipment fault, route changed or the other.
5. The xSP will refund money according as the SLA and the measured quality.

I think such the scenario is much different from the IPPM color.

> If IPPM isn't currently chartered to work on the kinds of solutions  
> that you require, there is an established process for proposing to  
> recharter working groups. If your proposal fails to see traction in  
> IPPM for other reasons, you'd do well to review the comments you  
> receive in order to improve your proposal.

> > In addition, we already asked the IPPM mailing list about the draft,
> > according to a suggestion from Dan in 68th Czech IETF,
> > and we got a following answer from the IPPM chairs after 69th IETF.
> > http://www1.ietf.org/mail-archive/web/ippm/current/msg01196.html
> 
> That message was sent at a time when the exact scope of PMOL was yet  
> to be defined. Now it has been defined, and focuses on
> 
>     (... the) development of performance metrics for IP-based  
> protocols and
>     applications that operate over UDP, TCP, SCTP, DCCP, Forward Error
>     Correction (FEC) and other robust transport protocols, and that  
> can be
>     used to characterize traffic on live networks.
> 
> A metric to quantify packet sequentiality for tunneled flows doesn't  
> fall into this charter, IMO.

Does "... development of PM for IP-based protolcols ..." include?
I think our draft is in the target range.

Anyway I knew PMOL does not handle new proposals in the current charter.

-- Yu.

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

Date: Fri, 23 Nov 2007 00:22:47 +0900 (JST)
To: [email-masked]
Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70
From: KIKUCHI Yutaka <[email-masked]>
Organization: Kochi Univ. of Tech.
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

> > This draft deals with passive measurements at a higher layer
> 
> not all that passive
> 
> Scott

It is completely passive.

Folks, see also the OPSAWG mailing list now discussing about the issue.

-- Yu.

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

Date: Thu, 22 Nov 2007 14:56:09 +0100
From: Henk Uijterwaal <[email-masked]>
To: Lars Eggert <[email-masked]>
Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

Hi,

> That message was sent at a time when the exact scope of PMOL was yet to 
> be defined. Now it has been defined, [...]
> A metric to quantify packet sequentiality for tunneled flows doesn't 
> fall into this charter, IMO.

So it looks like we have a problem.  Right now, IPPM focusses on
active measurements at the IP layer.  This draft deals with passive
measurements at a higher layer and thus doesn't fit into IPPM.  It
also doesn't fit into PMOL.   I do think that it is a good draft
though, so I think we have to find a place for it.  \

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
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
------------------------------------------------------------------------------

Is one of the choices leaving the office open?
                                       Alan Greenspan on the next elections

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

From: Lars Eggert <[email-masked]>
To: ext KIKUCHI Yutaka <[email-masked]>
Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70
Date: Thu, 22 Nov 2007 11:43:22 +0200
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

Hi,

On 2007-11-22, at 5:55, ext KIKUCHI Yutaka wrote:
> I think our approach is very different from IPPMs'.
> Our intention is to maintain all of tunnel flows in operation
> to check continuously the SLAs of the flows.
>
> The measurment method should be very light-weight and scalable.
> This is the top priority to deploy.
> The metrics depend on less resource situation.
> It is not much argurable how the metrics should be.
>
> Also, the method must be passive.
> IPPM seems not to deal with passive measurement.

This is all well and good, but IPPM is *the* working group that  
defines metrics for IP paths. Starting work in the same space in  
another WG is not going to be productive.

If IPPM isn't currently chartered to work on the kinds of solutions  
that you require, there is an established process for proposing to  
recharter working groups. If your proposal fails to see traction in  
IPPM for other reasons, you'd do well to review the comments you  
receive in order to improve your proposal.

> In addition, we already asked the IPPM mailing list about the draft,
> according to a suggestion from Dan in 68th Czech IETF,
> and we got a following answer from the IPPM chairs after 69th IETF.
> http://www1.ietf.org/mail-archive/web/ippm/current/msg01196.html

That message was sent at a time when the exact scope of PMOL was yet  
to be defined. Now it has been defined, and focuses on

    (... the) development of performance metrics for IP-based  
protocols and
    applications that operate over UDP, TCP, SCTP, DCCP, Forward Error
    Correction (FEC) and other robust transport protocols, and that  
can be
    used to characterize traffic on live networks.

A metric to quantify packet sequentiality for tunneled flows doesn't  
fall into this charter, IMO.

Lars

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

Date: Thu, 22 Nov 2007 12:55:14 +0900 (JST)
To: [email-masked]
Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70
From: KIKUCHI Yutaka <[email-masked]>
Organization: Kochi Univ. of Tech.
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

Lars-san, Dan-san,
Thank you very much for the help to find suitable place.

I think our approach is very different from IPPMs'.
Our intention is to maintain all of tunnel flows in operation
to check continuously the SLAs of the flows.

The measurment method should be very light-weight and scalable.
This is the top priority to deploy.
The metrics depend on less resource situation.
It is not much argurable how the metrics should be.

Also, the method must be passive.
IPPM seems not to deal with passive measurement.

In addition, we already asked the IPPM mailing list about the draft,
according to a suggestion from Dan in 68th Czech IETF,
and we got a following answer from the IPPM chairs after 69th IETF.
http://www1.ietf.org/mail-archive/web/ippm/current/msg01196.html

-- still in a floating boat (*_*), Yu.

> 
> 
> I would agree that IPPM may be a better place to discuss this draft, as
> IPPM metrics apply to a large extend already to what is being proposed.
> The question of using IPPM metrics at the ends of the tunnel was already
> raised I believe in the OPSAWG when this was presented first. 
> 
> Dan
> 
>  
> 
> > -----Original Message-----
> > From: Lars Eggert [mailto:[email-masked]] 
> > Sent: Wednesday, November 21, 2007 11:39 AM
> > To: ext KIKUCHI Yutaka
> > Cc: [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]; [email-masked]; 
> > [email-masked]
> > Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70
> > 
> > On 2007-11-20, at 22:26, ext KIKUCHI Yutaka wrote:
> > > May I have a slot to discuss an I-D for tunnel measurement?
> > >
> > > 4. One-way Passive Measurement of End-to-End Quality (Yutaka) 
> > > 
> > http://www.ietf.org/internet-drafts/draft-kikuchi-passive-measure-01.t
> > > xt
> > >
> > > I had presented the -00 version in OPSAWG at the last IETF, 
> > but it is 
> > > more adapted to discuss in PMOL than in OPSAWG.
> > 
> > Given that tunnels can be a part of an IP path, I'd think 
> > that this draft would be in scope of IPPM, rather than PMOL 
> > or OPSAWG. Even more so, because some of the metrics you 
> > define for a tunnel seem to overlap with metrics IPPM has 
> > already defined for IP paths.
> > 
> > Lars
> > 
> > 
> > _______________________________________________
> > PMOL mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pmol
> > 
> 

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

Content-class: urn:content-classes:message
Subject: RE: [PMOL] Draft Agenda for PMOL at IETF-70
Date: Wed, 21 Nov 2007 11:24:44 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Lars Eggert" <[email-masked]>, "ext KIKUCHI Yutaka" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], "Scott O. Bradner" <[email-masked]>

I would agree that IPPM may be a better place to discuss this draft, as
IPPM metrics apply to a large extend already to what is being proposed.
The question of using IPPM metrics at the ends of the tunnel was already
raised I believe in the OPSAWG when this was presented first.=20

Dan

=20

> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]]=20
> Sent: Wednesday, November 21, 2007 11:39 AM
> To: ext KIKUCHI Yutaka
> Cc: [email-masked]; [email-masked];=20
> [email-masked]; [email-masked]; [email-masked];=20
> [email-masked]
> Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70
>=20
> On 2007-11-20, at 22:26, ext KIKUCHI Yutaka wrote:
> > May I have a slot to discuss an I-D for tunnel measurement?
> >
> > 4. One-way Passive Measurement of End-to-End Quality (Yutaka)=20
> >=20
> http://www.ietf.org/internet-drafts/draft-kikuchi-passive-measure-01.t
> > xt
> >
> > I had presented the -00 version in OPSAWG at the last IETF,=20
> but it is=20
> > more adapted to discuss in PMOL than in OPSAWG.
>=20
> Given that tunnels can be a part of an IP path, I'd think=20
> that this draft would be in scope of IPPM, rather than PMOL=20
> or OPSAWG. Even more so, because some of the metrics you=20
> define for a tunnel seem to overlap with metrics IPPM has=20
> already defined for IP paths.
>=20
> Lars
>=20
>=20
> _______________________________________________
> PMOL mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pmol
>=20

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

From: Lars Eggert <[email-masked]>
To: ext KIKUCHI Yutaka <[email-masked]>
Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70
Date: Wed, 21 Nov 2007 11:39:02 +0200
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

On 2007-11-20, at 22:26, ext KIKUCHI Yutaka wrote:
> May I have a slot to discuss an I-D for tunnel measurement?
>
> 4. One-way Passive Measurement of End-to-End Quality (Yutaka)
> http://www.ietf.org/internet-drafts/draft-kikuchi-passive-measure-01.txt
>
> I had presented the -00 version in OPSAWG at the last IETF,
> but it is more adapted to discuss in PMOL than in OPSAWG.

Given that tunnels can be a part of an IP path, I'd think that this  
draft would be in scope of IPPM, rather than PMOL or OPSAWG. Even more  
so, because some of the metrics you define for a tunnel seem to  
overlap with metrics IPPM has already defined for IP paths.

Lars

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

Date: Wed, 21 Nov 2007 06:51:56 +0900 (JST)
To: [email-masked]
Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70
From: KIKUCHI Yutaka <[email-masked]>
Organization: Kochi Univ. of Tech.
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

Al,

Thanks for the reply.
How about preparing some slides to discuss the framework
according to our experience, not for intending to discuss the metrics?

-- Yu.

> Yu,
> 
> Sorry, but our charter says:
> 
> >Discussion of new work proposals is strongly discouraged under the
> >initial charter of the PMOL WG, except to advise a protocol
> >development WG when they are evaluating a new work proposal for
> >related performance metrics.
> 
> However, if your experience working with the framework memo
> has generated any constructive comments, please send them
> to the list and/or bring them up during discussion at the meeting.
> 
> Al
> pmol co-chair
> 
> At 03:26 PM 11/20/2007, KIKUCHI Yutaka wrote:
> >Al, Alan, and Everyone,
> >
> >May I have a slot to discuss an I-D for tunnel measurement?
> >
> >4. One-way Passive Measurement of End-to-End Quality (Yutaka)
> >http://www.ietf.org/internet-drafts/draft-kikuchi-passive-measure-01.txt
> >
> >I had presented the -00 version in OPSAWG at the last IETF,
> >but it is more adapted to discuss in PMOL than in OPSAWG.
> >The I-D includes a trial of metrics evaluation with
> >draft-morton-perf-metrics-framework-00.txt (sorry for not 01.txt).
> >
> >Please see also the following I-D describing the requirements
> >to measure tunnels.
> >
> >"Quality Measurement Requirements for Tunneling Protocols"
> >http://www.ietf.org/internet-drafts/draft-kikuchi-tunnel-measure-req-02.txt
> >
> >-- Regards, Yu.
> >
> > > Folks,
> > >
> > > The draft agenda for our session in Vancouver is below.
> > >
> > > Future updates may be found here:
> > > http://www3.ietf.org/proceedings/07dec/agenda/pmol.txt
> > >
> > > Al and Alan
> > > co-chairs
> > >
> > >
> > > Performance Metrics for Other Layers WG (pmol)
> > >
> > > THURSDAY, December 6, 2007
> > > 1300-1500 Afternoon Session I
> > > Salon F       OPS
> > >
> > > Co-Chairs:
> > > Al Morton <[email-masked]>
> > > Alan Clark <[email-masked]>
> > >
> > > Please help contribute to a successful meeting by reading the drafts
> > > and references *before* we meet.
> > >
> > > AGENDA:   Draft as of 11/20/2007
> > >
> > > 0. Agenda Bashing
> > >
> > > 1. Brief overview of the PMOL charter (Chairs - Al)
> > > http://www.ietf.org/html.charters/pmol-charter.html
> > >
> > > 2. Metrics Framework Draft            (Alan)
> > > 
> > http://www.ietf.org/internet-drafts/draft-morton-perf-metrics-framework-01.txt
> > >
> > > 3. SIP Performance Metrics Draft      (Daryl)
> > > http://www.ietf.org/internet-drafts/draft-malas-performance-metrics-07.txt
> > >
> > > 4. AOB
> > >
> > >
> > > To offer comments on PMOL work in progress or the agenda itself,
> > > please send email to:
> > >
> > >                <[email-masked]>
> > >
> > >
> > >
> > > _______________________________________________
> > > PMOL mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/pmol
> > >
> 
> 

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

Date: Tue, 20 Nov 2007 15:42:02 -0500
To: KIKUCHI Yutaka <[email-masked]>
From: Al Morton <[email-masked]>
Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

Yu,

Sorry, but our charter says:

>Discussion of new work proposals is strongly discouraged under the
>initial charter of the PMOL WG, except to advise a protocol
>development WG when they are evaluating a new work proposal for
>related performance metrics.

However, if your experience working with the framework memo
has generated any constructive comments, please send them
to the list and/or bring them up during discussion at the meeting.

Al
pmol co-chair

At 03:26 PM 11/20/2007, KIKUCHI Yutaka wrote:
>Al, Alan, and Everyone,
>
>May I have a slot to discuss an I-D for tunnel measurement?
>
>4. One-way Passive Measurement of End-to-End Quality (Yutaka)
>http://www.ietf.org/internet-drafts/draft-kikuchi-passive-measure-01.txt
>
>I had presented the -00 version in OPSAWG at the last IETF,
>but it is more adapted to discuss in PMOL than in OPSAWG.
>The I-D includes a trial of metrics evaluation with
>draft-morton-perf-metrics-framework-00.txt (sorry for not 01.txt).
>
>Please see also the following I-D describing the requirements
>to measure tunnels.
>
>"Quality Measurement Requirements for Tunneling Protocols"
>http://www.ietf.org/internet-drafts/draft-kikuchi-tunnel-measure-req-02.txt
>
>-- Regards, Yu.
>
> > Folks,
> >
> > The draft agenda for our session in Vancouver is below.
> >
> > Future updates may be found here:
> > http://www3.ietf.org/proceedings/07dec/agenda/pmol.txt
> >
> > Al and Alan
> > co-chairs
> >
> >
> > Performance Metrics for Other Layers WG (pmol)
> >
> > THURSDAY, December 6, 2007
> > 1300-1500 Afternoon Session I
> > Salon F       OPS
> >
> > Co-Chairs:
> > Al Morton <[email-masked]>
> > Alan Clark <[email-masked]>
> >
> > Please help contribute to a successful meeting by reading the drafts
> > and references *before* we meet.
> >
> > AGENDA:   Draft as of 11/20/2007
> >
> > 0. Agenda Bashing
> >
> > 1. Brief overview of the PMOL charter (Chairs - Al)
> > http://www.ietf.org/html.charters/pmol-charter.html
> >
> > 2. Metrics Framework Draft            (Alan)
> > 
> http://www.ietf.org/internet-drafts/draft-morton-perf-metrics-framework-01.txt
> >
> > 3. SIP Performance Metrics Draft      (Daryl)
> > http://www.ietf.org/internet-drafts/draft-malas-performance-metrics-07.txt
> >
> > 4. AOB
> >
> >
> > To offer comments on PMOL work in progress or the agenda itself,
> > please send email to:
> >
> >                <[email-masked]>
> >
> >
> >
> > _______________________________________________
> > PMOL mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pmol
> >

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

Date: Wed, 21 Nov 2007 05:26:48 +0900 (JST)
To: [email-masked]
Subject: Re: [PMOL] Draft Agenda for PMOL at IETF-70
From: KIKUCHI Yutaka <[email-masked]>
Organization: Kochi Univ. of Tech.
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

Al, Alan, and Everyone,

May I have a slot to discuss an I-D for tunnel measurement?

4. One-way Passive Measurement of End-to-End Quality (Yutaka)
http://www.ietf.org/internet-drafts/draft-kikuchi-passive-measure-01.txt

I had presented the -00 version in OPSAWG at the last IETF,
but it is more adapted to discuss in PMOL than in OPSAWG.
The I-D includes a trial of metrics evaluation with
draft-morton-perf-metrics-framework-00.txt (sorry for not 01.txt).

Please see also the following I-D describing the requirements
to measure tunnels.

"Quality Measurement Requirements for Tunneling Protocols"
http://www.ietf.org/internet-drafts/draft-kikuchi-tunnel-measure-req-02.txt

-- Regards, Yu.

> Folks,
> 
> The draft agenda for our session in Vancouver is below.
> 
> Future updates may be found here:
> http://www3.ietf.org/proceedings/07dec/agenda/pmol.txt
> 
> Al and Alan
> co-chairs
> 
> 
> Performance Metrics for Other Layers WG (pmol)
> 
> THURSDAY, December 6, 2007
> 1300-1500 Afternoon Session I
> Salon F    	OPS	
> 
> Co-Chairs:
> Al Morton <[email-masked]>
> Alan Clark <[email-masked]>
> 
> Please help contribute to a successful meeting by reading the drafts
> and references *before* we meet.
> 
> AGENDA:   Draft as of 11/20/2007
> 
> 0. Agenda Bashing
> 
> 1. Brief overview of the PMOL charter (Chairs - Al)
> http://www.ietf.org/html.charters/pmol-charter.html
> 
> 2. Metrics Framework Draft            (Alan)
> http://www.ietf.org/internet-drafts/draft-morton-perf-metrics-framework-01.txt
> 
> 3. SIP Performance Metrics Draft      (Daryl)
> http://www.ietf.org/internet-drafts/draft-malas-performance-metrics-07.txt
> 
> 4. AOB
> 
> 
> To offer comments on PMOL work in progress or the agenda itself,
> please send email to:
> 
>                <[email-masked]>
> 
> 
> 
> _______________________________________________
> PMOL mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pmol
> 

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

Date: Tue, 20 Nov 2007 12:35:47 -0500
To: [email-masked]
From: Al Morton <[email-masked]>
Cc: Ron Bonica <[email-masked]>
Subject: [PMOL] Draft Agenda for PMOL at IETF-70

Folks,

The draft agenda for our session in Vancouver is below.

Future updates may be found here:
http://www3.ietf.org/proceedings/07dec/agenda/pmol.txt

Al and Alan
co-chairs

Performance Metrics for Other Layers WG (pmol)

THURSDAY, December 6, 2007
1300-1500 Afternoon Session I
Salon F    	OPS	

Co-Chairs:
Al Morton <[email-masked]>
Alan Clark <[email-masked]>

Please help contribute to a successful meeting by reading the drafts
and references *before* we meet.

AGENDA:   Draft as of 11/20/2007

0. Agenda Bashing

1. Brief overview of the PMOL charter (Chairs - Al)
http://www.ietf.org/html.charters/pmol-charter.html

2. Metrics Framework Draft            (Alan)
http://www.ietf.org/internet-drafts/draft-morton-perf-metrics-framework-01.txt

3. SIP Performance Metrics Draft      (Daryl)
http://www.ietf.org/internet-drafts/draft-malas-performance-metrics-07.txt

4. AOB

To offer comments on PMOL work in progress or the agenda itself,
please send email to:

               <[email-masked]>

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

Date: Thu, 15 Nov 2007 11:23:20 -0800
From: Joe Touch <[email-masked]>
To: Stephen Kent <[email-masked]>
Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)]
Cc: Leslie Daigle <[email-masked]>, [email-masked], [email-masked], "Steven M. Bellovin" <[email-masked]>, IESG <[email-masked]>, Sam Hartman <[email-masked]>

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1747443889==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig0202F822B24C50C02C204C9F"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig0202F822B24C50C02C204C9F
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Stephen Kent wrote:
> Joe,
>=20
> This discussion  seems to have moved from a discussion of crypto use on=

> home/office computers, to use in routers. There is no good motivation
> for other than edge (CPE?) routers to make use of IPsec for subscriber
> traffic.

BGP...

> use of IPsec to
> protect BGP is a non-starter, because of where in the router the
> processing would be done (given current router designs).

Yes - and that was the punchline that performance does matter.

> In any case,
> use of IPsec by routers is a very different topic that use in
> home/office computers and ought not be brought into this discussion.

They are two different things, agreed.

> As for the original topic, yes, performance hits come in various flavor=
s
> when we discuss crypto protocol use. For example, there was a good pape=
r
> at NDSS a few years ago that showed how "marshalling" of data in  SSL
> implementations was a very big partFrom [email-masked] Thu Nov 15 15:31:50 2007
Date: Thu, 15 Nov 2007 11:23:20 -0800
From: Joe Touch <[email-masked]>
To: Stephen Kent <[email-masked]>
Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics
	atOther Layers (pmol)]
Cc: Leslie Daigle <[email-masked]>, [email-masked], [email-masked],
	"Steven M. Bellovin" <[email-masked]>, IESG <[email-masked]>,
	Sam Hartman <[email-masked]>

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1747443889==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig0202F822B24C50C02C204C9F"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig0202F822B24C50C02C204C9F
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Stephen Kent wrote:
> Joe,
>=20
> This discussion  seems to have moved from a discussion of crypto use on=

> home/office computers, to use in routers. There is no good motivation
> for other than edge (CPE?) routers to make use of IPsec for subscriber
> traffic.

BGP...

> use of IPsec to
> protect BGP is a non-starter, because of where in the router the
> processing would be done (given current router designs).

Yes - and that was the punchline that performance does matter.

> In any case,
> use of IPsec by routers is a very different topic that use in
> home/office computers and ought not be brought into this discussion.

They are two different things, agreed.

> As for the original topic, yes, performance hits come in various flavor=
s
> when we discuss crypto protocol use. For example, there was a good pape=
r
> at NDSS a few years ago that showed how "marshalling" of data in  SSL
> implementations was a very big part of the performance hit. Nonetheless=
,
> the bottom line is that for mainstream users, most of us are not
> convinced that performance is the primary reason for not using crypto.

If "us" means crypto folk, I agree.

If "us" means the rest of us - who don't use crypto - I am not at all
convinced. There are a variety of other communities who want to use
security - high performance (grid, optiputer), enterprise (huge numbers
of short connections), etc. They all have different reasons for not
using crypto more, but writing off performance would be to continue a
mistake.

I've made that point clear; whether it's actually heard or not isn't
something I have much control over, though.

Joe

--------------enig0202F822B24C50C02C204C9F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig0202F822B24C50C02C204C9F--

--===============1747443889==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

--===============1747443889==--

Date: Thu, 15 Nov 2007 10:35:18 -0500
To: Joe Touch <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics  atOther Layers (pmol)]
Cc: Leslie Daigle <[email-masked]>, [email-masked], [email-masked], "Steven M. Bellovin" <[email-masked]>, IESG <[email-masked]>, Sam Hartman <[email-masked]>

Joe,

This discussion  seems to have  of the performance hit. Nonetheless=
,
> the bottom line is that for mainstream users, most of us are not
> convinced that performance is the primary reason for not using crypto.

If "us" means crypto folk, I agree.

If "us" means the rest of us - who don't use crypto - I am not at all
convinced. There are a variety of other communities who want to use
security - high performance (grid, optiputer), enterprise (huge numbers
of short connections), etc. They all have different reasons for not
using crypto more, but writing off performance would be to continue a
mistake.

I've made that point clear; whether it's actually heard or not isn't
something I have much control over, though.

Joe

--------------enig0202F822B24C50C02C204C9F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig0202F822B24C50C02C204C9F--

--===============1747443889==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

--===============1747443889==--

Date: Thu, 15 Nov 2007 10:35:18 -0500
To: Joe Touch <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics  atOther Layers (pmol)]
Cc: Leslie Daigle <[email-masked]>, [email-masked], [email-masked], "Steven M. Bellovin" <[email-masked]>, IESG <[email-masked]>, Sam Hartman <[email-masked]>

Joe,

This discussion  seems to have moved from a discussion of crypto use 
on home/office computers, to use in routers. There is no good 
motivation for other than edge (CPE?) routers to make use of IPsec 
for subscriber traffic.  We know, from discussions with operators, 
that use of IPsec to protect BGP is a non-starter, because of where 
in the router the processing would be done (given current router 
designs).  In any case, use of IPsec by routers is a very different 
topic that use in home/office computers and ought not be brought into 
this discussion.

As for the original topic, yes, performance hits come in various 
flavors when we discuss crypto protocol use. For example, there was a 
good paper at NDSS a few years ago that showed how "marshalling" of 
data in  SSL implementations was a very big part of the performance 
hit. Nonetheless, the bottom line is that for mainstream users, most 
of us are not convinced that performance is the primary reason for 
not using crypto.

Steve

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

moved from a discussion of crypto use 
on home/office computers, to use in routers. There is no good 
motivation for other than edge (CPE?) routers to make use of IPsec 
for subscriber traffic.  We know, from discussions with operators, 
that use of IPsec to protect BGP is a non-starter, because of where 
in the router the processing would be done (given current router 
designs).  In any case, use of IPsec by routers is a very different 
topic that use in home/office computers and ought not be brought into 
this discussion.

As for the original topic, yes, performance hits come in various 
flavors when we discuss crypto protocol use. For example, there was a 
good paper at NDSS a few years ago that showed how "marshalling" of 
data in  SSL implementations was a very big part of the performance 
hit. Nonetheless, the bottom line is that for mainstream users, most 
of us are not convinced that performance is the primary reason for 
not using crypto.

Steve

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

Date: Thu, 15 Nov 2007 06:35:33 -0800
From: Joe Touch <[email-masked]>
To: "Steven M. Bellovin" <[email-masked]>
Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)]
Cc: Leslie Daigle <[email-masked]>, Stephen Kent <[email-masked]>, [email-masked], IESG <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0437301914==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enigB68AF3FF37E87CBD2FA97F1E"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB68AF3FF37E87CBD2FA97F1E
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Steven M. Bellovin wrote:
> On Wed, 14 Nov 2007 22:43:01 -0800
> Joe Touch <[email-masked]> wrote:
>=20
>> Sam Hartman wrote:
>> ...
>>> Yes, Steve almost certanily did slow down any heavy CPU use during
>>> the time when he was doing the backup.
>>>
>>> Our point--Steve, Steve and I--is that for a lot of uses and a lot
>>> of users, no one cares.
>> Perhaps that's why everyone is using security. We don't have a
>> problem then.
>>
> I didn't say that; I said that performance generally isn't the issue.
> Often, there's a *perception* of a performance issue, because once
> there was. The bigger problem, in my opinion, is usability.  *Lots* of
> people use SSL, because they don't have to do anything.  SSL as used in=

> https has lots of problems I won't go into here, but it is excellent
> protection against passive eavesdroppers.

While I'm sure your anecdotal laptop measurements are valid, there are
plenty of others who:
	- transfer large files over disks with more than 70Mbps of BW
		e.g., photos are now over 15MB/file, and videos larger
	- do enough with their CPU in the meantime that they would
	  notice when the OS was sharing it - e.g., photoshop

Why don't users turn on security on DSL lines? They do - VPNs, SSL, etc.
Sure, various protocols still have problems, as you note, but security
over low-speed links is largely a success story.

Why don't core Internet routers have security? Note that some router
vendors sell "IPv6" routers even though they don't come with IPsec HW,
and don't put IPsec in SW -- even though it begs the question of what
IPv6-IPsec should be called (IPv5.5?).

Why? They do more than ASCII email when they're trying to send packets,
have a SATA disk (even on laptops), and don't have - or want - CPU power
to burn (or even to share 50/50) to hide a very real performance problem.=

Performance problems come in many flavors:
	- per packet overhead
	- algorithmic overhead
	- keying overhead
	- policy lookup overhead

All of these are real problems, and can cause performance to drop to a
small fraction of what's capable without security.

Hiding the problem with other debilitations hasn't made it go away.

Joe

--------------enigB68AF3FF37E87CBD2FA97F1E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigB68AF3FF37E87CBD2FA97F1E--

--===============0437301914==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

--===============0437301914==--

Content-class: urn:content-classes:message
Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)]
Date: Thu, 15 Nov 2007 06:26:50 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Steven M. Bellovin" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: Leslie Daigle <[email-masked]>, Stephen Kent <[email-masked]>, [email-masked], IESG <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked]

This is a multi-part message in MIME format.

--===============1474084090==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C82793.8FC3454B"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C82793.8FC3454B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I am mostly in agreement with Steve but I find the premise somewhat odd.

Crypto overhead is an issue for some applications but not so much at the =
bulk end as the large number of small transactions end. Think web server =
doing a thousand hits a second. Even that is manageable with crypto =
accelerators and restart and such.=20

At the bulk end I would not see ssl as the ideal protocol for securing =
distribution of online movies. Why would this be suprising? Why would we =
expect one protocol to be optimal for every application?

For a start I would probaby want to have a message layer encryption =
scheme so that I only need to encrypt my file once, I would probably =
want the crypto to support fast index lookup for chapter search and I =
would probably want DRM features.

The reason we use ssl for everything is because it is deployed and it is =
easier to adapt a deployed protocol than build from scratch.

I don't see the backup scenario as relevant either. Batch mode backup is =
a legacy of the tape drive era. With tape drives and tapes costing an =
order of magnitude more per gig than disk that era is over. If the =
backup medium is disk volume shaddowing makes much more sense.

Given  that consumer targetted backup systems offering volume shaddowing =
are available for just over $500 for a 500Gb system the batch mode =
backup scenario is obsolete.

Now if only the providers of that technology had thought about how I am =
to protect my data against the house burning down...

Sent from my GoodLink Wireless Handheld (www.good.com)

 -----Original Message-----
From: 	Steven M. Bellovin [mailto:[email-masked]]
Sent:	Thursday, November 15, 2007 05:53 AM Pacific Standard Time
To:	Joe Touch
Cc:	Leslie Daigle; Stephen Kent; [email-masked]; Romascanu, Dan (Dan); =
IESG; Sam Hartman; [email-masked]
Subject:	Re: [PMOL] Re: A question about [Fwd: WG Review: Performance =
Metrics  atOther Layers (pmol)]

On Wed, 14 Nov 2007 22:43:01 -0800
Joe Touch <[email-masked]> wrote:

> Sam Hartman wrote:
> ...
> > Yes, Steve almost certanily did slow down any heavy CPU use during
> > the time when he was doing the backup.
> >=20
> > Our point--Steve, Steve and I--is that for a lot of uses and a lot
> > of users, no one cares.
>=20
> Perhaps that's why everyone is using security. We don't have a
> problem then.
>=20
I didn't say that; I said that performance generally isn't the issue.
Often, there's a *perception* of a performance issue, because once
there was. The bigger problem, in my opinion, is usability.  *Lots* of
people use SSL, because they don't have to do anything.  SSL as used in
https has lots of problems I won't go into here, but it is excellent
protection against passive eavesdroppers.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

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

------_=_NextPart_001_01C82793.8FC3454B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Re: [PMOL] Re: A question about [Fwd: WG Review: Performance =
Metrics  atOther Layers (pmol)]</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>I am mostly in agreement with Steve but I find the =
premise somewhat odd.<BR>
<BR>
Crypto overhead is an issue for some applications but not so much at the =
bulk end as the large number of small transactions end. Think web server =
doing a thousand hits a second. Even that is manageable with crypto =
accelerators and restart and such.<BR>
<BR>
At the bulk end I would not see ssl as the ideal protocol for securing =
distribution of online movies. Why would this be suprising? Why would we =
expect one protocol to be optimal for every application?<BR>
<BR>
For a start I would probaby want to have a message layer encryption =
scheme so that I only need to encrypt my file once, I would probably =
want the crypto to support fast index lookup for chapter search and I =
would probably want DRM features.<BR>
<BR>
The reason we use ssl for everything is because it is deployed and it is =
easier to adapt a deployed protocol than build from scratch.<BR>
<BR>
I don't see the backup scenario as relevant either. Batch mode backup is =
a legacy of the tape drive era. With tape drives and tapes costing an =
order of magnitude more per gig than disk that era is over. If the =
backup medium is disk volume shaddowing makes much more sense.<BR>
<BR>
Given&nbsp; that consumer targetted backup systems offering volume =
shaddowing are available for just over $500 for a 500Gb system the batch =
mode backup scenario is obsolete.<BR>
<BR>
Now if only the providers of that technology had thought about how I am =
to protect my data against the house burning down...<BR>
<BR>
<BR>
Sent from my GoodLink Wireless Handheld (www.good.com)<BR>
<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; Steven M. Bellovin [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<BR>
Sent:&nbsp;&nbsp; Thursday, November 15, 2007 05:53 AM Pacific Standard =
Time<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; Joe Touch<BR>
Cc:&nbsp;&nbsp;&nbsp;&nbsp; Leslie Daigle; Stephen Kent; [email-masked]; =
Romascanu, Dan (Dan); IESG; Sam Hartman; [email-masked]<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: [PMOL] Re: A =
question about [Fwd: WG Review: Performance Metrics&nbsp; atOther Layers =
(pmol)]<BR>
<BR>
On Wed, 14 Nov 2007 22:43:01 -0800<BR>
Joe Touch &lt;[email-masked]&gt; wrote:<BR>
<BR>
&gt; Sam Hartman wrote:<BR>
&gt; ...<BR>
&gt; &gt; Yes, Steve almost certanily did slow down any heavy CPU use =
during<BR>
&gt; &gt; the time when he was doing the backup.<BR>
&gt; &gt;<BR>
&gt; &gt; Our point--Steve, Steve and I--is that for a lot of uses and a =
lot<BR>
&gt; &gt; of users, no one cares.<BR>
&gt;<BR>
&gt; Perhaps that's why everyone is using security. We don't have a<BR>
&gt; problem then.<BR>
&gt;<BR>
I didn't say that; I said that performance generally isn't the =
issue.<BR>
Often, there's a *perception* of a performance issue, because once<BR>
there was. The bigger problem, in my opinion, is usability.&nbsp; *Lots* =
of<BR>
people use SSL, because they don't have to do anything.&nbsp; SSL as =
used in<BR>
https has lots of problems I won't go into here, but it is excellent<BR>
protection against passive eavesdroppers.<BR>
<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --Steve Bellovin, <A =
HREF=3D"http://www.cs.columbia.edu/~smb">http://www.cs.columbia.edu/~smb<=
/A><BR>
<BR>
_______________________________________________<BR>
Ietf mailing list<BR>
[email-masked]<BR>
<A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/ietf">https://www1.ietf.or=
g/mailman/listinfo/ietf</A><BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C82793.8FC3454B--

--===============1474084090==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

--===============1474084090==--

Date: Thu, 15 Nov 2007 13:53:23 +0000
From: "Steven M. Bellovin" <[email-masked]>
To: Joe Touch <[email-masked]>
Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics  atOther Layers (pmol)]
Organization: Columbia University
Cc: Leslie Daigle <[email-masked]>, Stephen Kent <[email-masked]>, [email-masked], IESG <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked]

On Wed, 14 Nov 2007 22:43:01 -0800
Joe Touch <[email-masked]> wrote:

> Sam Hartman wrote:
> ...
> > Yes, Steve almost certanily did slow down any heavy CPU use during
> > the time when he was doing the backup.
> > 
> > Our point--Steve, Steve and I--is that for a lot of uses and a lot
> > of users, no one cares.
> 
> Perhaps that's why everyone is using security. We don't have a
> problem then.
> 
I didn't say that; I said that performance generally isn't the issue.
Often, there's a *perception* of a performance issue, because once
there was. The bigger problem, in my opinion, is usability.  *Lots* of
people use SSL, because they don't have to do anything.  SSL as used in
https has lots of problems I won't go into here, but it is excellent
protection against passive eavesdroppers.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

Date: Wed, 14 Nov 2007 22:43:01 -0800
From: Joe Touch <[email-masked]>
To: Sam Hartman <[email-masked]>
Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)]
Cc: Leslie Daigle <[email-masked]>, Stephen Kent <[email-masked]>, [email-masked], "Steven M. Bellovin" <[email-masked]>, IESG <[email-masked]>, [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0189919871==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enigD0F53F625FE6C7F36FADD001"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD0F53F625FE6C7F36FADD001
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Sam Hartman wrote:
=2E..
> Yes, Steve almost certanily did slow down any heavy CPU use during the =
time when he was doing the backup.
>=20
> Our point--Steve, Steve and I--is that for a lot of uses and a lot of
> users, no one cares.

Perhaps that's why everyone is using security. We don't have a problem th=
en.

Joe

--------------enigD0F53F625FE6C7F36FADD001
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigD0F53F625FE6C7F36FADD001--

--===============0189919871==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

--===============0189919871==--

Date: Wed, 14 Nov 2007 16:25:55 -0800
From: Joe Touch <[email-masked]>
To: "Steven M. Bellovin" <[email-masked]>
Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)]
Cc: Leslie Daigle <[email-masked]>, Stephen Kent <[email-masked]>, [email-masked], IESG <[email-masked]>, Sam Hartman <[email-masked]>, [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1273663859==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig09E0B0730573A9B5F5BDBEE1"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig09E0B0730573A9B5F5BDBEE1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi, Steve,

Steven M. Bellovin wrote:
> On Wed, 14 Nov 2007 15:39:50 -0500
> Stephen Kent <[email-masked]> wrote:
>=20
>> Joe,
>>
>> I disagree with your suggestion "The software performance of security
>> protocols has been the more substantial issue, and is likely to
>> continue to be for the forseeable future."
>>
>> I suspect that most desktop users do not need hardware crypto for
>> performance.  Irarely if ever drive my GiGE interface at its line
>> rate. With fast processors, especially multi-core processors, we have
>> enough cycles to do symmetric crypto at data rates consistent with
>> most application demands for individual users.  Public key operations
>> for key management are usually low duty cycle, so they too can be
>> accommodated.
>>
> Thanks -- I was going to say something similar.  I regularly back up my=

> laptop's disk over a software-encrypted GigE link. The dump file
> occupies about 35G of disk space; it takes about 70 minutes.  Exclusive=

> of protocol overhead, that comes to ~71M bps; given IP, TCP, and ssh,
> I'd guess it's more like 75-80M bps.  I also know that I can run ttcp
> between that pair of machines at about 500M bps.  Am I really suffering=

> from a 7:1 performance hit from the crypto?  Nope.

By essentially shutting your machine down for over an hour.

> I can't do controlled experiments right now, since the laptop and
> server in question are currently about 350 km apart at the moment.
>=20
> Dumping the disk to /dev/null took about 30 minutes.  The maximum hit
> I'm taking from the crypto, then, is about 2.3:1.

The numbers I get are 3:1 for some protocols, worse for others, but the
CPU hit is also substantial, vs. just taking time but not CPU to do the
transfer.

> Using the
> performance numbers from 'openssl speed' for 1024-byte blocks for
> AES-128 and SHA-1, the crypto is 23 minutes of CPU time.  (This is a
> 1.8Ghz, single-core laptop.) The other 17 minutes probably go to data
> copies -- I'm doing 'dump | ssh cat >file' -- so a kernel implementatio=
n
> (say, IPsec) would be better -- and overhead, plus (of course)
> calculation error).  The point, though, is that the crypto isn't the
> limiting factor.  It's not stopping me from doing anything.  It's not
> even the biggest bottleneck in my application.  And *that's* what's
> important -- not *network* speed, but *application* speed.

Your application shut your machine down for over an hour - just dumping
 alone wouldn't). That's substantial - sure, not for you, but you run
crypto. For those who don't, this is a large part of why (the other part
is key management, but that doesn't come into play for things like
backups since it's a single key and two known parties).

---

The point is that you have a GigE interface you don't use. Why? It's
cheap, and when you do use it - to dump at work - it's a lot faster than
100Mbps.

Crypto puts a huge dent into that capability the way it's done right
now, and nobody is selling me 1Gbps crypto chips for a price that makes
it cost-effective to put it into a laptop. And I don't exactly want to
burn 100% of my CPU capacity to saturate my 802.11 link, let alone such
a small fraction of my GigE.

Joe

--------------enig09E0B0730573A9B5F5BDBEE1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig09E0B0730573A9B5F5BDBEE1--

--===============1273663859==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

--===============1273663859==--

Date: Thu, 15 Nov 2007 02:47:18 +0000
From: "Steven M. Bellovin" <[email-masked]>
To: Sam Hartman <[email-masked]>
Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics  atOther Layers (pmol)]
Organization: Columbia University
Cc: Leslie Daigle <[email-masked]>, Stephen Kent <[email-masked]>, Joe Touch <[email-masked]>, [email-masked], IESG <[email-masked]>, [email-masked]

On Wed, 14 Nov 2007 21:22:48 -0500
Sam Hartman <[email-masked]> wrote:

> 
>     Joe> By essentially shutting your machine down for over an hour.

No, not at all; not even close.
> 
> I'm only going to send this one message, but then I'll drop out of the
> thread.  We've drifted far from Leslie's original query.
> 
> Steve did not say his machine was CPU bound.  Also, even if it was CPU
> bound, he's probably running an operating system with reasonable
> multiprogramming characteristics.  So, if he wanted to use the
> machine, his backup would take longer, but he'd get to do whatever he
> wanted.
> 
> Yes, Steve almost certanily did  slow down any heavy CPU use during
> the time when he was doing the backup.
> 
Right. Operating systems are really good at sharing the CPU between
processes.  As long as you're talking about pure CPU load, the
scheduler works *very* well, and has for O(45 years).  Right now, as
I'm typing this, I'm running that dump again in the background, this
type piped to 'cat >/dev/null' to better simulate the pipe overhead,
and I'm running 'openssl speed' in another window.  I do not perceive
any slowdown whatsoever.  I would notice it I tried to view a movie, or
if I tried to do serious picture or video editing, or if I tried
running another command -- say, firing up firefox if it were not
already running -- that did a lot of disk I/O.  I don't know of any OS
-- and that includes every version of Unix I've ever used, going back
more than 30 years, and every version of Windows I've used, going back
about a dozen years, that shares disk bandwidth particularly well.  But
sharing CPU is very easy.

I don't dispute Joe's numbers about how crypto can limit bandwidth.
Again, though, what matters to me is system and application
performance, and there I generally don't feel the hit.

Why do I use GigE?  Well, in one sense it's because that's what came
with my computer, but I did spend the money to convert my house network
to GigE.  There's some unencrypted traffic to the file server.  Just as
important, even with the crypto I'm approaching the limits of what I
can do with 100BaseT.  As I noted, my actual, over the wire, dump
operations are running at 75-80M bps.  There's not a lot of headroom
between that and the 91M bps that is the fastest I've managed with
ttcp.  I just got a new, faster laptop; I'm curious what it will do,
with and without the crypto.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

From: Sam Hartman <[email-masked]>
To: Joe Touch <[email-masked]>
Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)]
Date: Wed, 14 Nov 2007 21:22:48 -0500
Cc: Leslie Daigle <[email-masked]>, Stephen Kent <[email-masked]>, [email-masked], "Steven M. Bellovin" <[email-masked]>, IESG <[email-masked]>, [email-masked]

>>>>> "Joe" == Joe Touch <[email-masked]> writes:

    Joe> Hi, Steve,
    Joe> Steven M. Bellovin wrote:
    >> On Wed, 14 Nov 2007 15:39:50 -0500
    >> Stephen Kent <[email-masked]> wrote:
    >> 
    >>> Joe,
    >>> 
    >>> I disagree with your suggestion "The software performance of
    >>> security protocols has been the more substantial issue, and is
    >>> likely to continue to be for the forseeable future."
    >>> 
    >>> I suspect that most desktop users do not need hardware crypto
    >>> for performance.  Irarely if ever drive my GiGE interface at
    >>> its line rate. With fast processors, especially multi-core
    >>> processors, we have enough cycles to do symmetric crypto at
    >>> data rates consistent with most application demands for
    >>> individual users.  Public key operations for key management
    >>> are usually low duty cycle, so they too can be accommodated.
    >>> 
    >> Thanks -- I was going to say something similar.  I regularly
    >> back up my laptop's disk over a software-encrypted GigE
    >> link. The dump file occupies about 35G of disk space; it takes
    >> about 70 minutes.  Exclusive of protocol overhead, that comes
    >> to ~71M bps; given IP, TCP, and ssh, I'd guess it's more like
    >> 75-80M bps.  I also know that I can run ttcp between that pair
    >> of machines at about 500M bps.  Am I really suffering from a
    >> 7:1 performance hit from the crypto?  Nope.

    Joe> By essentially shutting your machine down for over an hour.

I'm only going to send this one message, but then I'll drop out of the
thread.  We've drifted far from Leslie's original query.

Steve did not say his machine was CPU bound.  Also, even if it was CPU
bound, he's probably running an operating system with reasonable
multiprogramming characteristics.  So, if he wanted to use the
machine, his backup would take longer, but he'd get to do whatever he
wanted.

Yes, Steve almost certanily did  slow down any heavy CPU use during the time when he was doing the backup.

Our point--Steve, Steve and I--is that for a lot of uses and a lot of
users, no one cares.

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

Date: Wed, 14 Nov 2007 22:32:58 +0000
From: "Steven M. Bellovin" <[email-masked]>
To: Stephen Kent <[email-masked]>
Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics  atOther Layers (pmol)]
Organization: Columbia University
Cc: Leslie Daigle <[email-masked]>, [email-masked], Joe Touch <[email-masked]>, [email-masked], IESG <[email-masked]>, Sam Hartman <[email-masked]>

On Wed, 14 Nov 2007 15:39:50 -0500
Stephen Kent <[email-masked]> wrote:

> Joe,
> 
> I disagree with your suggestion "The software performance of security
> protocols has been the more substantial issue, and is likely to
> continue to be for the forseeable future."
> 
> I suspect that most desktop users do not need hardware crypto for
> performance.  Irarely if ever drive my GiGE interface at its line
> rate. With fast processors, especially multi-core processors, we have
> enough cycles to do symmetric crypto at data rates consistent with
> most application demands for individual users.  Public key operations
> for key management are usually low duty cycle, so they too can be
> accommodated.
> 
Thanks -- I was going to say something similar.  I regularly back up my
laptop's disk over a software-encrypted GigE link. The dump file
occupies about 35G of disk space; it takes about 70 minutes.  Exclusive
of protocol overhead, that comes to ~71M bps; given IP, TCP, and ssh,
I'd guess it's more like 75-80M bps.  I also know that I can run ttcp
between that pair of machines at about 500M bps.  Am I really suffering
from a 7:1 performance hit from the crypto?  Nope.

I can't do controlled experiments right now, since the laptop and
server in question are currently about 350 km apart at the moment.

Dumping the disk to /dev/null took about 30 minutes.  The maximum hit
I'm taking from the crypto, then, is about 2.3:1.  Using the
performance numbers from 'openssl speed' for 1024-byte blocks for
AES-128 and SHA-1, the crypto is 23 minutes of CPU time.  (This is a
1.8Ghz, single-core laptop.)  The other 17 minutes probably go to data
copies -- I'm doing 'dump | ssh cat >file' -- so a kernel implementation
(say, IPsec) would be better -- and overhead, plus (of course)
calculation error).  The point, though, is that the crypto isn't the
limiting factor.  It's not stopping me from doing anything.  It's not
even the biggest bottleneck in my application.  And *that's* what's
important -- not *network* speed, but *application* speed.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

Date: Wed, 14 Nov 2007 13:35:53 -0800
From: Joe Touch <[email-masked]>
To: Stephen Kent <[email-masked]>
Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)]
Cc: Leslie Daigle <[email-masked]>, [email-masked], [email-masked], IESG <[email-masked]>, Sam Hartman <[email-masked]>

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0220158455==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig2C4D0D160F14A8B13AE0A0FB"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2C4D0D160F14A8B13AE0A0FB
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi, Steve,

Stephen Kent wrote:
> Joe,
>=20
> I disagree with your suggestion "The software performance of security
> protocols has been the more substantial issue, and is likely to continu=
e
> to be for the forseeable future."
>=20
> I suspect that most desktop users do not need hardware crypto for
> performance.  Irarely if ever drive my GiGE interface at its line rate.=

It's not hard to drive it high enough to see a substantial impact
(300+Mbps); when I turn on S/W crypto, that drops to less than 1/3 at
best. See the paper below.

> With fast processors, especially multi-core processors, we have enough
> cycles to do symmetric crypto at data rates consistent with most
> application demands for individual users.  Public key operations for ke=
y
> management are usually low duty cycle, so they too can be accommodated.=

Public key is less the issue. See the following for recent measurements
using multicore processors - FWIW, this will peg the processing of a
modern CPU just to reach over 100Mbps:

J. Touch, Y. Yang, "Reducing the Impact of DoS Attacks on Endpoint IP
Security,"Proc. NPSec 2006, in conjunction with ICNP 2006, Nov. 2006.
http://www.isi.edu/touch/pubs/npsec2006

Joe

--------------enig2C4D0D160F14A8B13AE0A0FB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig2C4D0D160F14A8B13AE0A0FB--

--===============0220158455==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

--===============0220158455==--

Date: Wed, 14 Nov 2007 15:39:50 -0500
To: Joe Touch <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics  atOther Layers (pmol)]
Cc: Leslie Daigle <[email-masked]>, [email-masked], [email-masked], IESG <[email-masked]>, Sam Hartman <[email-masked]>

Joe,

I disagree with your suggestion "The software performance of security 
protocols has been the more substantial issue, and is likely to 
continue to be for the forseeable future."

I suspect that most desktop users do not need hardware crypto for 
performance.  Irarely if ever drive my GiGE interface at its line 
rate. With fast processors, especially multi-core processors, we have 
enough cycles to do symmetric crypto at data rates consistent with 
most application demands for individual users.  Public key operations 
for key management are usually low duty cycle, so they too can be 
accommodated.

Steve

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

To: [email-masked]
From: IESG Secretary <[email-masked]>
Date: Wed, 14 Nov 2007 12:15:02 -0500
Cc: [email-masked]
Subject: [PMOL] WG Action: Performance Metrics at Other Layers (pmol) 

A new IETF working group has been formed in the Operations and
Management Area. For additional information, please contact the Area
Directors or the WG Chairs.

+++

Performance Metrics at Other Layers (pmol) 
===========================================

Current Status: Active Working Group

WG Chairs: 
Al Morton <[email-masked]> 
Alan Clark <[email-masked]> 

Operations and Management Area: 
Dan Romascanu <[email-masked]> 
Ronald Bonica <[email-masked]> 

Operations and Management Area Advisor: 
Dan Romascanu <[email-masked]> 

Mailing Lists: 
General Discussion: [email-masked] 
To Subscribe: https://www1.ietf.org/mailman/listinfo/pmol 
Archive: http://www.ietf.org/mail-archive/web/pmol/index.html 

Description of Working Group: 

The successful implementation and operation of IP based applications 
often depends on some underlying performance measurement infrastructure 
that helps service operators or network managers to recognize when 
performance is unsatisfactory and identify problems affecting service 
quality. Standardized performance metrics add the desirable features of 
consistent implementation, interpretation, no comparison. 

The IETF has two Working Groups dedicated to the development of 
performance metrics however each has strict limitations in their 
charters: 

- The Benchmarking Methodology WG has addressed a range of networking 
technologies and protocols in their long history (such as IEEE 802.3, 
ATM, Frame Relay, and Routing Protocols), but the charter strictly 
limits their Performance characterizations to the laboratory 
environment. 

- The IP Performance Metrics WG has the mandate to develop metrics 
applicable to the performance of Internet data delivery, but it is 
specifically prohibited from developing metrics that characterize 
traffic (such as a VoIP stream). 

The IETF also has current and completed activities related to the 
reporting of application performance metrics (e.g. RAQMON and RTCP XR) 
and is also actively involved in the development of reliable transport 
protocols which would affect the relationship between IP performance and 
application performance. 

Thus there is a gap in the currently chartered coverage of IETF WGs: 
development of performance metrics for IP-based protocols and 
applications that operate over UDP, TCP, SCTP, DCCP, Forward Error 
Correction (FEC) and other robust transport protocols, and that can be 
used to characterize traffic on live networks. 

The working group will focus on the completion of two RFCs: 

1. A PMOL framework and guidelines memo that will describe the necessary
elements of performance metrics of protocols and applications 
transported over IETF-specified protocols (such as the formal 
definition, purpose, and units of measure) and the various types of 
metrics that characterize traffic on live networks (such as metrics 
derived from other metrics, possibly on lower layers). The framework 
will also address the need to specify the intended audience and the 
motivation for the performance metrics. There will also be guidelines 
for a performance metric development process that includes entry 
criteria for new proposals (how a proposal might be evaluated for 
possible endorsement by a protocol development working group), and how 
an successful proposal will be developed. Also, it is recognized that
there are applications and protocols that do not need to use this
framework and can make use of simpler specific methods for determining
performance. 

2. A proof-of-concept RFC defining performance metrics for SIP, based on
draft-malas-performance-metrics. This memo would serve as an example of 
the framework and the PMOL development process in the IETF. 

Discussion of new work proposals is strongly discouraged under the 
initial charter of the PMOL WG, except to advise a protocol development 
WG when they are evaluating a new work proposal for related performance 
metrics. 

The Working Group will work closely with the RAI and APPS areas,
performing early review of the documents with the two areas and inviting
their particpation in the WGLC. 

The PMOL WG will also be guided by a document describing how memos 
defining performance metrics are intended to advance along the IETF 
Standards track (draft-bradner-metricstest). 

PMOL WG will take advantage of expertise and seek to avoid overlap with 
other standards development organizations, such as ETSI STQ, ITU-T SG 
12, ATIS IIF, ATIS PRQC, and others. 

Milestones 

June 08 SIP Performance Metrics Draft to IESG Review for consideration 
as Proposed Standard 

Sept 08 PMOL Framework and Guidelines Draft to IESG Review for 
consideration as BCP 

Nov 08 - Discuss rechartering of the WG for new PMOL metrics work or shut
down

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

Date: Wed, 14 Nov 2007 06:51:42 -0800
From: Joe Touch <[email-masked]>
To: Sam Hartman <[email-masked]>
Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance	Metrics atOther Layers (pmol)]
Cc: IESG <[email-masked]>, [email-masked], [email-masked], Leslie Daigle <[email-masked]>

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1357077894==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig9387D3286DFF979632C54BAB"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9387D3286DFF979632C54BAB
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Sam Hartman wrote:
>>>>>> "Romascanu," =3D=3D Romascanu, Dan (Dan) <[email-masked]> writ=
es:
>=20
>     >> -----Original Message----- From: Sam Hartman
>     >> [mailto:[email-masked]] Sent: Monday, October 29, 2007 10:24
>     >> PM To: Leslie Daigle Cc: IESG; [email-masked]; [email-masked]
>     >> Subject: [PMOL] Re: A question about [Fwd: WG Review:
>     >> Performance Metrics atOther Layers (pmol)]
>     >>=20
>     >> >>>>> "Leslie" =3D=3D Leslie Daigle <[email-masked]>
>     >> writes:
>     >>=20
>     >> I doubt I'll use the output in security protocols.
>     >>=20
>=20
>     Romascanu,> Isn't it true that best security protocol designs
>     Romascanu,> always take performance aspects into account, because
>     Romascanu,> users will turn off the security features if they deem
>     Romascanu,> their performance reduction too great?=20
>=20
> In many cases the performance of security protocols is not a huge issue=
 at all with modern hardware.
> There are a few important exceptions.

A significant one is the lack of hardware to support security protocols.
GigE interfaces have been common on both desktops and laptops for 5
years, but no corresponding security hardware has been similarly deployed=
=2E

The software performance of security protocols has been the more
substantial issue, and is likely to continue to be for the forseeable
future.

Joe

--------------enig9387D3286DFF979632C54BAB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig9387D3286DFF979632C54BAB--

--===============1357077894==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

--===============1357077894==--

From: "Randy Presuhn" <[email-masked]>
Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: PerformanceMetrics atOther Layers (pmol)]
Date: Fri, 2 Nov 2007 10:52:01 -0800
Cc: [email-masked], [email-masked]

Hi -

> From: "Bill Sommerfeld" <[email-masked]>
> To: "Sam Hartman" <[email-masked]>
> Cc: "IESG" <[email-masked]>; "Romascanu, Dan (Dan)" <[email-masked]>; <[email-masked]>; <[email-masked]>; "Leslie Daigle"
<[email-masked]>
> Sent: Friday, November 02, 2007 8:30 AM
> Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: PerformanceMetrics atOther Layers (pmol)]
...
> Depending on the scope of this effort I see a bunch of things that might
> be worth modelling:
...

What's the relationship of all this to RFC 2564 and RFC 3729?
(For the phone case, the question would extend to RFC 4711.)

Randy

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)]
From: Bill Sommerfeld <[email-masked]>
To: Sam Hartman <[email-masked]>
Date: Fri, 02 Nov 2007 12:30:43 -0400
Cc: IESG <[email-masked]>, [email-masked], [email-masked], Leslie Daigle <[email-masked]>

On Thu, 2007-11-01 at 11:09 -0400, Sam Hartman wrote:
> In many cases the performance of security protocols is not a huge
> issue at all with modern hardware.

Depending on the scope of this effort I see a bunch of things that might
be worth modelling:

 - additional compute resources (cpu, memory, crypto hardware, battery
energy, etc.)
 - additional round trips (that pesky speed of light thing)
 - increases in message sizes/reduced effective MTU
 - availability (if your security protocol depends on a KDC/OCSP
server/CRL distribution point/other service, if it's not available,
you're not available)

The first is not a factor on typical client computers, but the same is
not necessarily true for the mobile phone/pda class of widget or even
for servers -- in the latter case customers say they want high enough
utilization that the overhead of security protocols is going to be
significant for server sizing.

> It has not been my experience that it is important to a level where
> metrics are requested or used.  

it's very common for customers to ask "how big a server/server farm do
we need to support this expected workload?".  The impact of security
protocols on that workload can be significant.  

					- Bill

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

From: David R Oran <[email-masked]>
To: Brian E Carpenter <[email-masked]>
Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance	Metrics atOther Layers (pmol)]
Date: Thu, 1 Nov 2007 17:25:41 -0400
Cc: [email-masked], Sam Hartman <[email-masked]>, IESG <[email-masked]>, Leslie Daigle <[email-masked]>, [email-masked]

On Nov 1, 2007, at 4:40 PM, Brian E Carpenter wrote:

>
>> Leslie asked for comments from uninvolved parties and I'm giving my
>> personal opinion that I would not find this work useful.  If others
>> do, we should go charter it.
>
> I think it will be useful, if it succeeds in rigorously defining
> metrics for upper layer protocols, given their dependencies on
> the metrics for lower layer protocols. The context is how to
> write meaningful service level agreements for application level
> services, which require well-defined and reproducible metrics.
>
For the services I work on in my day job (e.g. multicast/unicast real- 
time video streaming) the metrics I am concerned with are either:

a) RTP/RTCP transport metrics, for which AVT has done a very good job  
with and hence PMOL is redundant, or
b) session protocol setup metrics (e.g. RTSP), which are mostly useful  
for debugging as opposed to service measurement
c) application-level SLA metrics, which are pretty abstract and not  
amenable to direct computation (e.g. visible artifacts per hour), or
d) encoding/perceptual metrics, such as PSNR, R-factor, etc. which are  
in generally defined on bodies other than the IETF and which have been  
the subject of much controversy both in the industry and in the IETF  
when people have tried to get them blessed.

As such, PMOL would be valuable to me if:
1. it succeeded in developing useful algorithms/methods for  
correlating these metrics to lower level metrics like route  
convergence time or congestive loss rates, or
2. it succeeded in developing application metrics which are less  
susceptible to industry controversy, vendor wars, service-provider  
"count everything that moves" behavior, and found wide adoption.

My personal assessment is:

a) the likelihood of PMOL succeeding at either of these is quite low,  
but I'm willing to be pleasantly surprised, and
b) if PMOL starts encroaching on the work in AVT I will be unhappy as  
I think AVT does a very good job without needing a new venue for  
developing useful transport level metrics, at least for real time flows

In summary, my general level of interest in PMOL is low, but that's a  
moot point since the WG has been chartered and I wish the group the  
best of luck!

Dave Oran (IAB hat off).

>   Brian
>
>
> _______________________________________________
> PMOL mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pmol

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

Date: Fri, 02 Nov 2007 09:40:38 +1300
From: Brian E Carpenter <[email-masked]>
Organization: University of Auckland
To: Sam Hartman <[email-masked]>
Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance	Metrics atOther Layers (pmol)]
Cc: IESG <[email-masked]>, [email-masked], [email-masked], Leslie Daigle <[email-masked]>

> Leslie asked for comments from uninvolved parties and I'm giving my
> personal opinion that I would not find this work useful.  If others
> do, we should go charter it.

I think it will be useful, if it succeeds in rigorously defining
metrics for upper layer protocols, given their dependencies on
the metrics for lower layer protocols. The context is how to
write meaningful service level agreements for application level
services, which require well-defined and reproducible metrics.

    Brian

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

Content-class: urn:content-classes:message
Date: Thu, 1 Nov 2007 19:47:05 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Subject: [PMOL] PMOL Working Group was approved!

The IESG approved in the telechat today the formation of the PMOL
Working Group.

Congratulations and good luck!

Please see below the charter that was approved by the IESG.

Regards,

Dan

Performance Metrics at Other Layers (pmol)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Last Modified: 2007-10-22

Current Status: Proposed Working Group

WG Chairs:
TBD

Operations and Management Area:
Dan Romascanu <[email-masked]>
Ronald Bonica <[email-masked]>

Description:

The successful implementation and operation of IP based applications
often depends on some underlying performance measurement infrastructure
that helps service operators or network managers to recognize when
performance is unsatisfactory and identify problems affecting service
quality. Standardized performance metrics add the desirable features of
consistent implementation, interpretation, no comparison.

The IETF has two Working Groups dedicated to the development of
performance metrics however each has strict limitations in their
charters:

- The Benchmarking Methodology WG has addressed a range of networking
technologies and protocols in their long history (such as IEEE 802.3,
ATM, Frame Relay, and Routing Protocols), but the charter strictly
limits their Performance characterizations to the laboratory
environment.

- The IP Performance Metrics WG has the mandate to develop metrics
applicable to the performance of Internet data delivery, but it is
specifically prohibited from developing metrics that characterize
traffic (such as a VoIP stream).

The IETF also has current and completed activities related to the
reporting of application performance metrics (e.g. RAQMON and RTCP XR)
and is also actively involved in the development of reliable transport
protocols which would affect the relationship between IP performance and
application performance.

Thus there is a gap in the currently chartered coverage of IETF WGs:
development of performance metrics for IP-based protocols and
applications that operate over UDP, TCP, SCTP, DCCP, Forward Error
Correction (FEC) and other robust transport protocols, and that can be
used to characterize traffic on live networks.

The working group will focus on the completion of two RFCs:

1. A PMOL framework and guidelines memo that will describe the necessary
elements of performance metrics of protocols and applications
transported over IETF-specified protocols (such as the formal
definition, purpose, and units of measure) and the various types of
metrics that characterize traffic on live networks (such as metrics
derived from other metrics, possibly on lower layers). The framework
will also address the need to specify the intended audience and the
motivation for the performance metrics. There will also be guidelines
for a performance metric development process that includes entry
criteria for new proposals (how a proposal might be evaluated for
possible endorsement by a protocol development working group), and how
an successful proposal will be developed. Also, it is recognized that
there are applications and protocols that do not need to use this
framework and can make use of simpler specific methods for determining
performance.=20

2. A proof-of-concept RFC defining performance metrics for SIP, based on
draft-malas-performance-metrics. This memo would serve as an example of
the framework and the PMOL development process in the IETF.

Discussion of new work proposals is strongly discouraged under the
initial charter of the PMOL WG, except to advise a protocol development
WG when they are evaluating a new work proposal for related performance
metrics.

The Working Group will work closely with the RAI and APPS areas,
performing early review of the documents with the two areas and inviting
their particpation in the WGLC.=20

The PMOL WG will also be guided by a document describing how memos
defining performance metrics are intended to advance along the IETF
Standards track (draft-bradner-metricstest).

PMOL WG will take advantage of expertise and seek to avoid overlap with
other standards development organizations, such as ETSI STQ, ITU-T SG
12, ATIS IIF, ATIS PRQC, and others.

Milestones

June 08 SIP Performance Metrics Draft to IESG Review for consideration
as Proposed Standard

Sept 08 PMOL Framework and Guidelines Draft to IESG Review for
consideration as BCP

Nov 08 - Discuss rechartering of the WG for new PMOL metrics work or
shut down

=20

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

From: Sam Hartman <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Subject: Re: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)]
Date: Thu, 01 Nov 2007 11:09:58 -0400
Cc: [email-masked], Leslie Daigle <[email-masked]>, IESG <[email-masked]>, [email-masked]

>>>>> "Romascanu," == Romascanu, Dan (Dan) <[email-masked]> writes:

    >> -----Original Message----- From: Sam Hartman
    >> [mailto:[email-masked]] Sent: Monday, October 29, 2007 10:24
    >> PM To: Leslie Daigle Cc: IESG; [email-masked]; [email-masked]
    >> Subject: [PMOL] Re: A question about [Fwd: WG Review:
    >> Performance Metrics atOther Layers (pmol)]
    >> 
    >> >>>>> "Leslie" == Leslie Daigle <[email-masked]>
    >> writes:
    >> 
    >> I doubt I'll use the output in security protocols.
    >> 

    Romascanu,> Isn't it true that best security protocol designs
    Romascanu,> always take performance aspects into account, because
    Romascanu,> users will turn off the security features if they deem
    Romascanu,> their performance reduction too great? 

In many cases the performance of security protocols is not a huge issue at all with modern hardware.
There are a few important exceptions.

So measuring
    Romascanu,> the performance of security protocols and the impact
    Romascanu,> of activating security on other protocols and
    Romascanu,> applications seems to be important.

It has not been my experience that it is important to a level where
metrics are requested or used.  Certainly performance is something we
think about, and it is something that does get measured from time to
time and there are certain people who care about security performance
a lot.

Leslie asked for comments from uninvolved parties and I'm giving my
personal opinion that I would not find this work useful.  If others
do, we should go charter it.

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

From: "Dan Schutzer" <[email-masked]>
To: "'Romascanu, Dan \(Dan\)'" <[email-masked]>, "'Sam Hartman'" <[email-masked]>, "'Leslie Daigle'" <[email-masked]>
Subject: RE: [PMOL] Re: A question about [Fwd: WG Review: PerformanceMetrics atOther Layers (pmol)]
Date: Thu, 1 Nov 2007 09:22:54 -0400
Cc: [email-masked], [email-masked], 'IESG' <[email-masked]>

agreed

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Thursday, November 01, 2007 8:48 AM
To: Sam Hartman; Leslie Daigle
Cc: [email-masked]; IESG; [email-masked]
Subject: RE: [PMOL] Re: A question about [Fwd: WG Review: PerformanceMetrics
atOther Layers (pmol)]

 

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Monday, October 29, 2007 10:24 PM
> To: Leslie Daigle
> Cc: IESG; [email-masked]; [email-masked]
> Subject: [PMOL] Re: A question about [Fwd: WG Review: 
> Performance Metrics atOther Layers (pmol)]
> 
> >>>>> "Leslie" == Leslie Daigle <[email-masked]> writes:
> 
> I doubt I'll use the output in security protocols.
> 

Isn't it true that best security protocol designs always take
performance aspects into account, because users will turn off the
security features if they deem their performance reduction too great? So
measuring the performance of security protocols and the impact of
activating security on other protocols and applications seems to be
important. 

Dan

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

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol

Content-class: urn:content-classes:message
Subject: RE: [PMOL] Re: A question about [Fwd: WG Review: Performance Metrics atOther Layers (pmol)]
Date: Thu, 1 Nov 2007 13:48:22 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Sam Hartman" <[email-masked]>, "Leslie Daigle" <[email-masked]>
Cc: [email-masked], IESG <[email-masked]>, [email-masked]

=20
=20

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]=20
> Sent: Monday, October 29, 2007 10:24 PM
> To: Leslie Daigle
> Cc: IESG; [email-masked]; [email-masked]
> Subject: [PMOL] Re: A question about [Fwd: WG Review:=20
> Performance Metrics atOther Layers (pmol)]
>=20
> >>>>> "Leslie" =3D=3D Leslie Daigle <[email-masked]> writes:
>=20
> I doubt I'll use the output in security protocols.
>=20

Isn't it true that best security protocol designs always take
performance aspects into account, because users will turn off the
security features if they deem their performance reduction too great? So
measuring the performance of security protocols and the impact of
activating security on other protocols and applications seems to be
important.=20

Dan

_______________________________________________
PMOL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmol