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

From: Robert Haas <[email-masked]>
Date: Wed, 5 Jun 2002 16:27:56 +0200

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 7 Jun 2002 06:40:09 -0400

Robert,

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

cheers,
jamal

---

From: Robert Haas <[email-masked]>
Date: Mon, 10 Jun 2002 11:33:23 +0200

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 10 Jun 2002 05:54:47 -0700

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

cheers,
jamal

---

From: Robert Haas <[email-masked]>
Date: Mon, 10 Jun 2002 21:34:14 +0200

> Did i understand you correctly?

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 ?

Thanks

---

From: Olivier Marce <[email-masked]>
Date: Tue, 11 Jun 2002 13:13:11 +0200

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

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

---

From: Robert Haas <[email-masked]>
Date: Thu, 13 Jun 2002 11:53:12 +0200

Olivier,

> sort of proxy function to the CE (on request of the CE ) ?

You're right.

> yet. But we probably can get by without too concerned with this."

Not really: in my view, the ability to download new functionalities into an FE is
orthogonal to the type of functionality the FE can execute.

In other words, you could think of an FE that provides a static proxy-function: that could
be the case for an FE that has been built to execute TCP termination in particular, but no
other proxy-function.

Therefore, by generalization, such proxy-functions (or "Off-load Functions") could be
found in any of  the 3 "flexibility" classes:  #1 (static capabilities), #2
(reconfigurable capabilities), or #3 (downloadable capabilities).

Do you agree with this interpretation of the 3 "flexibility" classes suggested by Lily and
how proxy-functions can belong to any of them ?

Regards,
-Robert

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 13 Jun 2002 06:39:02 -0400

On Monday 10 June 2002 15:34, Robert Haas wrote:
> > > 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 ?
> >
> 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 ?
>

Robert,
I think it would be wrong to limit what functionality goes onto the FE. I 
worked on the requirements team and tried hard to make sure this is clear;
If you find that this is not reflected properly, i think it should be 
clarified. 
I cant remember who came up with the term "high-touch" and it may already be 
used by some organizations as marketing cliche and so may already be polluted 
to mean something else than intended focus.
The caveat to note is that while Forces MUST not restrict what functionality 
goes into the FE vs CE, the charter says the immediate focus (in my opinion 
it is just an example) is Forwarding + QoS. This may be confusing the other 
side of the coin where people seem to think the protocol is based on Diffserv 
configuration. 

cheers,
jamal

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

---

From: Robert Haas <[email-masked]>
Date: Tue, 18 Jun 2002 18:07:10 +0200

Jamal,
My concern is the limitation of the scope of FEs capabilities to whatever can be
done to "the packet as it passes through the FE", as the draft mentions it
repeatedly.
If there are other capabilities planned for ForCES besides Forwarding+QoS, then
the requirements draft should avoid being so restrictive, IMHO. The TCP
termination being just one example out of today's FEs capabilities that go beyond
the current scope, as I understand now.

If you think it's acceptable, then I'll try to come up with a concrete suggestion
how to formulate this, that you could then consider including in the draft.

Cheers,
-Robert

Jamal Hadi Salim wrote:

> worked on the requirements team and tried hard to make sure this is clear.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 19 Jun 2002 21:10:01 -0400

Robert,
Please come up with the appropriate text.

cheers,
jamal

On Tuesday 18 June 2002 12:07, Robert Haas wrote:
> Jamal,
> My concern is the limitation of the scope of FEs capabilities to whatever
> can be done to "the packet as it passes through the FE", as the draft
> mentions it repeatedly.
> If there are other capabilities planned for ForCES besides Forwarding+QoS,
> then the requirements draft should avoid being so restrictive, IMHO. The
> TCP termination being just one example out of today's FEs capabilities that
> go beyond the current scope, as I understand now.
>
> If you think it's acceptable, then I'll try to come up with a concrete
> suggestion how to formulate this, that you could then consider including in
> the draft.
>
> Cheers,
> -Robert
>
> Jamal Hadi Salim wrote:
> > > > > 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;
> > > > 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).
> > > 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 ?
> >
> > Robert,
> > I cant remember who came up with the term "high-touch" and it may already
> > be used by some organizations as marketing cliche and so may already be
> > polluted to mean something else than intended focus.
> > The caveat to note is that while Forces MUST not restrict what
> > functionality goes into the FE vs CE, the charter says the immediate
> > focus (in my opinion it is just an example) is Forwarding + QoS. This may
> > be confusing the other side of the coin where people seem to think the
> > protocol is based on Diffserv configuration.
> >
> > cheers,
> > jamal
> >
> > > Thanks
> > >
> > > > cheers,
> > > > jamal
> > > >
> > > > > 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
> > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > > "Off-load Functions", with an appropriate model ? I believe
> > > > > > > leaving this up to a "Vendor-Specific Function" would
> > > > > > > considerably reduce the

---

From: Robert Haas <[email-masked]>
Date: Tue, 25 Jun 2002 14:10:16 +0200

Jamal, Hormuzd,
Here is a suggestion that could fit into section 6.5 "Minimal Set of Logical
Functions". The idea is to ensure that the FE model remains flexible and it does
not imply that FEs must support such functionalities.

8) Off-loaded Functions
Per-packet processing can leave state in the FE, so that logical
functions executed during packet processing can perform in a consistent
manner (for instance, each packet may update the state of the token
bucket occupancy of a given policer). In addition, FEs MUST allow
logical functions to execute asynchronously from packet processing,
according to a certain finite-state machine, in order to perform
functions that are, for instance, off-loaded from the CE to the FE.
The FE model MUST be capable of expressing these asynchronous
functions.
Examples of such functions include the finite-state machine execution
required by TCP termination or OSPF Hello processing, triggered not
only by packet events, but timer events as well.

Regards,
-Robert