Robert Haas | 5 Jun 16:27 2002
Picon

Comment on ForCES Requirements draft: FEs and off-load of signaling functions

I'd like to have the opinion of the list/design team regarding the issue
below, which might impact the requirements draft to some extent (sorry
for popping up just before the last call extended deadline):

Certain FEs begin to provide functions that go beyond per-packet
processing, such as TCP termination, where part of the signaling is
off-loaded to the FE. The definition of "High-Touch Functions" in the
draft does not seem to include such functions.

Would it be wise to consider an additional category, such as "Off-load
Functions", with an appropriate model ? I believe leaving this up to a
"Vendor-Specific Function" would considerably reduce the
attractivity/interoperability guaranteed by ForCES.

Regards,
--
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha

Jamal Hadi Salim | 7 Jun 12:40 2002

Re: Comment on ForCES Requirements draft: FEs and off-load of signaling functions


Robert,

Maybe i misunderstood: How does "High-touch" not cover what you are 
addressing? Is it the naming that bothers you?

cheers,
jamal

On Wednesday 05 June 2002 10:27, Robert Haas wrote:
> I'd like to have the opinion of the list/design team regarding the issue
> below, which might impact the requirements draft to some extent (sorry
> for popping up just before the last call extended deadline):
>
> Certain FEs begin to provide functions that go beyond per-packet
> processing, such as TCP termination, where part of the signaling is
> off-loaded to the FE. The definition of "High-Touch Functions" in the
> draft does not seem to include such functions.
>
> Would it be wise to consider an additional category, such as "Off-load
> Functions", with an appropriate model ? I believe leaving this up to a
> "Vendor-Specific Function" would considerably reduce the
> attractivity/interoperability guaranteed by ForCES.
>
> Regards,
> --
> Robert Haas
> IBM Zurich Research Laboratory
> Säumerstrasse 4
> CH-8803 Rüschlikon/Switzerland
(Continue reading)

Jamal Hadi Salim | 7 Jun 12:47 2002

new netlink draft


An updated draft posted at:

ftp://openarchitect.znyx.com/pub/jamal/draft-forces-netlink-03.txt

Please provide comments; we are hoping to last call this.

cheers,
jamal
Robert Haas | 10 Jun 11:33 2002
Picon

Re: Comment on ForCES Requirements draft: FEs and off-load ofsignaling functions

Jamal,

Thanks for your response. Let me clarify: the Requirements draft limits the FE
model to express what logical functions can be applied to packets "as they
pass through the FE" (see sect. 6.1). "High-Touch" is defined as a category of
such logical functions.

In my opinion, this model rules out functions such as TCP termination, that
require processing not only as a packet "passes through the FE" (for instance,
handling timers). Functions such as TCP termination are usually performed by
the CE and could be "off-loaded" into the FEs for performance reasons.

Therefore, it seems to me that this issue is not a naming issue, but rather a
design choice defining what the FE model must include or not. Do you agree ?

Thanks,
-Robert

Jamal Hadi Salim wrote:

> Robert,
>
> Maybe i misunderstood: How does "High-touch" not cover what you are
> addressing? Is it the naming that bothers you?
>
> cheers,
> jamal
>
> On Wednesday 05 June 2002 10:27, Robert Haas wrote:
> > I'd like to have the opinion of the list/design team regarding the issue
(Continue reading)

Internet-Drafts | 10 Jun 13:16 2002
Picon

I-D ACTION:draft-ietf-forces-netlink-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF.

        Title           : Netlink as an IP Services Protocol
        Author(s)       : J. Salim et al.
        Filename        : draft-ietf-forces-netlink-03.txt
        Pages           : 34
        Date            : 07-Jun-02

This document describes Linux Netlink, which is used in Linux both
as an intra-kernel messaging system as well as between kernel and
user space.  This document is intended as informational in the con-
text of prior art for the ForCES IETF working group.  The focus of
this document is to describe Netlink from a perspective of a protocol
between a Forwarding Engine Component (FEC) and a Control Plane
Component (CPC), the two components that define an IP service.
The document ignores the ability of Netlink as a intra-kernel mes-
saging system, as an inter-process communication scheme (IPC), or
as a configuration tool for other non-networking or non-IP network
services (such as decnet, etc.).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-forces-netlink-03.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
(Continue reading)

Jamal Hadi Salim | 10 Jun 14:54 2002

Re: Comment on ForCES Requirements draft: FEs and off-load ofsignaling functions

On Mon, 10 Jun 2002, Robert Haas wrote:

> Jamal,
> 
> Thanks for your response. Let me clarify: the Requirements draft limits the FE
> model to express what logical functions can be applied to packets "as they
> pass through the FE" (see sect. 6.1). "High-Touch" is defined as a category of
> such logical functions.
> 
> In my opinion, this model rules out functions such as TCP termination, that
> require processing not only as a packet "passes through the FE" (for instance,
> handling timers). Functions such as TCP termination are usually performed by
> the CE and could be "off-loaded" into the FEs for performance reasons.
> 
> Therefore, it seems to me that this issue is not a naming issue, but rather a
> design choice defining what the FE model must include or not. Do you agree ?
> 

It depends on how you look at it. And it does become a design issue, but
the model doesnt stop you;
lets take TCP termination, for example:
I would think that the setup phase where the splicing is being set up is
a control plane activity. So is the termination. With the current model
you could redirect specific packets to the control plane (eg in this
case, If i understood correctly, would be SYN/FIN packets).
Activity after the connection is "nailed" seems to me belongs to the
FE (such as munging the ACKs and splicing).
On the same token, timers to generate FE events seem to me also to be
control activity.
Did i understand you correctly? 
(Continue reading)

Robert Haas | 10 Jun 21:34 2002
Picon

Re: Comment on ForCES Requirements draft: FEs and off-load ofsignalingfunctions

Jamal Hadi Salim wrote:

> On Mon, 10 Jun 2002, Robert Haas wrote:
>
> > Jamal,
> >
> > Thanks for your response. Let me clarify: the Requirements draft limits the FE
> > model to express what logical functions can be applied to packets "as they
> > pass through the FE" (see sect. 6.1). "High-Touch" is defined as a category of
> > such logical functions.
> >
> > In my opinion, this model rules out functions such as TCP termination, that
> > require processing not only as a packet "passes through the FE" (for instance,
> > handling timers). Functions such as TCP termination are usually performed by
> > the CE and could be "off-loaded" into the FEs for performance reasons.
> >
> > Therefore, it seems to me that this issue is not a naming issue, but rather a
> > design choice defining what the FE model must include or not. Do you agree ?
> >
>
> It depends on how you look at it. And it does become a design issue, but
> the model doesnt stop you;
> lets take TCP termination, for example:
> I would think that the setup phase where the splicing is being set up is
> a control plane activity. So is the termination. With the current model
> you could redirect specific packets to the control plane (eg in this
> case, If i understood correctly, would be SYN/FIN packets).
> Activity after the connection is "nailed" seems to me belongs to the
> FE (such as munging the ACKs and splicing).
> On the same token, timers to generate FE events seem to me also to be
(Continue reading)

Olivier Marce | 11 Jun 13:09 2002
Picon

Re: Requirements Document - Capabilities Model

Hi Joel

"Joel M. Halpern" wrote:

> The DiffServ conceptual model (and MIB / PIB) which have been mentioned as
> starting points for the capabilities model are actually state models, not
> capabilities models.  There is no way to tell from these models how many
> filters a device can handle, or whether it is capable of
> metering.  However, you can tell at any given time exactly what filters it
> has, how they connect to markers, meters, queues, etc.  When you want to
> configure additional processing elements into the processing path, you
> reference the elements of this model.
>

What's about the section 1.2 of RFC3084 ?
"   When a device boots, it opens a COPS connection to its Primary
   PDP.  When the connection is established, the PEP sends information
   about itself to the PDP in the form of a configuration request.
   This information includes client specific information (e.g.,
   hardware type, software release, configuration information)."

Ins't it an sufficient capabilities description step ?

--
Olivier Marce (ARX Project/Active Network WP)
Alcatel R&I Dept                        Tel: +33 (0) 1 69 63 41 67
Route de Nozay                          Fax: +33 (0) 1 69 63 13 59
F-91461 Marcoussis Cedex (France)

(Continue reading)

Olivier Marce | 11 Jun 13:13 2002
Picon

Re: Comment on ForCES Requirements draft: FEs and off-loadofsignalingfunctions

Hi Robert

Am I right when I understand that you expect that the FE could offer some
sort of proxy function to the CE (on request of the CE ) ?
If so, am I right when I say that this is in the scope of item #3 of Lily's
message ?

"The third kind of control and configuration is even more powerful and future
looking. In addition to dynamic configuration, CEs might be even allowed to
download a given functionality onto FEs. I am not sure how we model that
yet. But we probably can get by without too concerned with this."

Regards

Robert Haas wrote:
>
> Let's see:
>
> TCP splicing, after the setup phase, boils down to converting sequence numbers back
> and forth, and this is indeed a function that takes place "as packets pass through
> the FE". An ideal candidate for a "High-Touch Function".
>
> But what if I'd like to have some sort of control activity take place in the FE as
> well, such as TCP setup or timers handling ?  The reason is to avoid overloading the
> CE with TCP processing, if the FEs are smart enough to handle this directly. This
> goes beyond the current FE model.
>
> Do you also think that some sort of control activity should be allowed to be
> "off-loaded" into the FEs ?
>
(Continue reading)

Joel M. Halpern | 11 Jun 16:05 2002

Re: Requirements Document - Capabilities Model

When I last reviewed the COPS PIBs, there was some, but only a little,
capability information in the various PIBs.  In conversation with some of
the COPS folks I have been told that more recently both the framework PIB
and the DiffServ PIB have had significant capabilities information added to
them.  I expect to find time before the IETF meeting to review these two
documents.  If there is a good start on the capabilities model in the PIBs,
then we will definitely use that.

Yours,
Joel M. Halpern

PS: For historical context, at one time the DiffServ PIB was closely
aligned to the DiffServ MIB, and the MIB definitely did not have much
useful capabilities information.  Things change.  Note that the information
described in the section you quote is pretty minimal when one things about
capabilities information.  But more has been added in other documents.

At 01:09 PM 6/11/2002 +0200, Olivier Marce wrote:
>Hi Joel
>
>"Joel M. Halpern" wrote:
>
> > The DiffServ conceptual model (and MIB / PIB) which have been mentioned as
> > starting points for the capabilities model are actually state models, not
> > capabilities models.  There is no way to tell from these models how many
> > filters a device can handle, or whether it is capable of
> > metering.  However, you can tell at any given time exactly what filters it
> > has, how they connect to markers, meters, queues, etc.  When you want to
> > configure additional processing elements into the processing path, you
> > reference the elements of this model.
(Continue reading)


Gmane