Subject: [NSIS] 2 slightly more interesting questions about the layer split

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 9 Dec 2002 08:39:11 -0000

Dear all,

Please note: this email is not about process issues! (Not that this will stop responses on process issues, I'm sure.)

Again as a follow up to the Atlanta session, I'd like to pose 2 further questions about where the NTLP/NSLP split should go.

Rather than being about 'what is good basic transport layer functionality?', these questions are much more about 'how should a single transport layer support a diverse set of signalling applications?'. Since being able to do this is a prime motivation behind our work (at least for some of us), this is my justification for calling these questions 'interesting'.

I have no idea where the the centre of gravity of working group thinking is on these issues, so I have deliberately phrased them in a one-sided partisan way to see what the response is.

I. Are NSLP peers always NTLP peers?
====================================

Background: we think of the NTLP as operating over a limited range (a single 'hop' of some description), but on the other hand, there may be signalling applications where the interested peer nodes are far apart. 

[A concrete example could be a path through two QoS-aware nodes (A, C) separated by a QoS-unaware NAT (B). So, the QoS-NSLP peers are A and C, but they are more than one NTLP hop apart. This would be either because the NTLP is split at the NAT to re-write addresses, which participates in NTLP security mechanisms to enable it to do so, or because there is a full Midcom-NSLP at B. (Which of these two is possible depends on which layer carries the relevant addressing information, which is still open, but I don't think it changes the general argument.)]

So, I propose the answer to the question is 'no'. This could have interesting implications (e.g. for the signalling application multiplexing approach). In particular, where the NSLP depends on a service provided by the NTLP, it means it depends on concatenating that service over several NTLP hops. E2E/fate-sharing arguments might then imply it shouldn't be an NTLP service after all.

Are there other ways to model this type of scenario? Do we have to worry about it?

II. Should the NTLP provide a state management service?
=======================================================

Note this is *not* either of the following questions:
*) should state be held in the NTLP and should soft state mechanisms be used to manage it?
*) could state be held in an NSLP and could soft state mechanisms be used to manage it?
These are protocol design questions, distinctly beyond the framework stage.

This is the following choice:
a) Should a signalling application be able to invoke the NTLP saying "please create this opaque state blob in my peer node and manage it", or
b) Should a signalling application just use the NTLP to get opaque data to its peer, with the state management logic built into the signalling application and parametrised in the data
The choice between (a) and (b) obviously has an impact on the NTLP/NSLP divide.

I'd like to propose the answer 'No' to see how loud people shout (I know people disagree). Here are some very brief justifications:
1. Different signalling applications might have very different qualitative state management requirements/semantics - e.g. soft (deleted unless explicitly refreshed), soft (deleted unless implicitly refreshed), explicitly deleted by initiator, deleted by responder if it loses contact with the initiator, hard, etc. Defining these semantics could be subtle (especially the error cases). Which paradigm should the NTLP implement?
1a. Even if the qualitative aspects are the same, the quantitive requirements (lifetimes, number of messages that can be dropped etc) over a specific NTLP hop supporting multiple NSLPs might be different.
2. Why is doing this at the NTLP easier than doing it at the NSLP, i.e. what does the integration with transport layer functions buy you? (NB: we could use some guidance from the analysis work to tell us whether using a single soft state refresh mechanism to handle packet loss/route change *and* signalling application specific state is still felt to be a good idea.) Note that we can still implement generic state management functionality within the signalling application layer if we want (as Bob has pointed out previously).
3. Some quick analysis we've done suggests that including state management functions in the NTLP makes the NTLP API more complex (by a factor or 2 or 3). That strikes me as alarming.
4. If you believe the answer 'no' to question (I) above, then the state management service available to the NSLP will actually be the concatenation of several NTLP state management services. This could be hard to define and analyse, and the e2e/fate sharing arguments might be seen as significant here.

I'm sure the argument isn't this one-sided. Are there better options than (a) or (b) anyway?

Views?

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

---

From: [email-masked]
Date: Tue, 10 Dec 2002 14:42:05 +0100

Hi Robert, all,

My views on your questions:
- NSLP/NTLP peers: I agree with your analysis and answer (no)
- state: I am assuming b). In that case, I think that you can come to a
situation where the NTLP can fail and recover without causing a failure in
the NSLP which may be desirable in some cases.

Just my 2cc,
Sven.

"Hancock, Robert" <[email-masked]>@ietf.org on 09/12/2002
09:39:11

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  [NSIS] 2 slightly more interesting questions about the layer
      split

Dear all,

Please note: this email is not about process issues! (Not that this will
stop responses on process issues, I'm sure.)

Again as a follow up to the Atlanta session, I'd like to pose 2 further
questions about where the NTLP/NSLP split should go.

Rather than being about 'what is good basic transport layer
functionality?', these questions are much more about 'how should a single
transport layer support a diverse set of signalling applications?'. Since
being able to do this is a prime motivation behind our work (at least for
some of us), this is my justification for calling these questions
'interesting'.

I have no idea where the the centre of gravity of working group thinking is
on these issues, so I have deliberately phrased them in a one-sided
partisan way to see what the response is.

Background: we think of the NTLP as operating over a limited range (a
single 'hop' of some description), but on the other hand, there may be
signalling applications where the interested peer nodes are far apart.

[A concrete example could be a path through two QoS-aware nodes (A, C)
separated by a QoS-unaware NAT (B). So, the QoS-NSLP peers are A and C, but
they are more than one NTLP hop apart. This would be either because the
NTLP is split at the NAT to re-write addresses, which participates in NTLP
security mechanisms to enable it to do so, or because there is a full
Midcom-NSLP at B. (Which of these two is possible depends on which layer
carries the relevant addressing information, which is still open, but I
don't think it changes the general argument.)]

So, I propose the answer to the question is 'no'. This could have
interesting implications (e.g. for the signalling application multiplexing
approach). In particular, where the NSLP depends on a service provided by
the NTLP, it means it depends on concatenating that service over several
NTLP hops. E2E/fate-sharing arguments might then imply it shouldn't be an
NTLP service after all.

Are there other ways to model this type of scenario? Do we have to worry
about it?

Note this is *not* either of the following questions:
*) should state be held in the NTLP and should soft state mechanisms be
used to manage it?
*) could state be held in an NSLP and could soft state mechanisms be used
to manage it?
These are protocol design questions, distinctly beyond the framework stage.

This is the following choice:
a) Should a signalling application be able to invoke the NTLP saying
"please create this opaque state blob in my peer node and manage it", or
b) Should a signalling application just use the NTLP to get opaque data to
its peer, with the state management logic built into the signalling
application and parametrised in the data
The choice between (a) and (b) obviously has an impact on the NTLP/NSLP
divide.

I'd like to propose the answer 'No' to see how loud people shout (I know
people disagree). Here are some very brief justifications:
1. Different signalling applications might have very different qualitative
state management requirements/semantics - e.g. soft (deleted unless
explicitly refreshed), soft (deleted unless implicitly refreshed),
explicitly deleted by initiator, deleted by responder if it loses contact
with the initiator, hard, etc. Defining these semantics could be subtle
(especially the error cases). Which paradigm should the NTLP implement?
1a. Even if the qualitative aspects are the same, the quantitive
requirements (lifetimes, number of messages that can be dropped etc) over a
specific NTLP hop supporting multiple NSLPs might be different.
2. Why is doing this at the NTLP easier than doing it at the NSLP, i.e.
what does the integration with transport layer functions buy you? (NB: we
could use some guidance from the analysis work to tell us whether using a
single soft state refresh mechanism to handle packet loss/route change
*and* signalling application specific state is still felt to be a good
idea.) Note that we can still implement generic state management
functionality within the signalling application layer if we want (as Bob
has pointed out previously).
3. Some quick analysis we've done suggests that including state management
functions in the NTLP makes the NTLP API more complex (by a factor or 2 or
3). That strikes me as alarming.
4. If you believe the answer 'no' to question (I) above, then the state
management service available to the NSLP will actually be the concatenation
of several NTLP state management services. This could be hard to define and
analyse, and the e2e/fate sharing arguments might be seen as significant
here.

I'm sure the argument isn't this one-sided. Are there better options than
(a) or (b) anyway?

Views?

Robert H.

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Tue, 10 Dec 2002 14:02:40 -0500

Robert,

These are very good questions.

I think the following principles are important for the layer separation:
- The less interdependency between layers the better
- The simpler (but meaningful) service lower layer delivers the better

It seems to me that answer NO (the first question) and choice B (the second
question) are inline with these principles.

Ilya

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]]
Sent: Monday, December 09, 2002 3:39 AM
To: [email-masked]
Subject: [NSIS] 2 slightly more interesting questions about the layer split

Dear all,

Rather than being about 'what is good basic transport layer functionality?',
these questions are much more about 'how should a single transport layer
support a diverse set of signalling applications?'. Since being able to do
this is a prime motivation behind our work (at least for some of us), this
is my justification for calling these questions 'interesting'.

I have no idea where the the centre of gravity of working group thinking is
on these issues, so I have deliberately phrased them in a one-sided partisan
way to see what the response is.

Background: we think of the NTLP as operating over a limited range (a single
'hop' of some description), but on the other hand, there may be signalling
applications where the interested peer nodes are far apart.

[A concrete example could be a path through two QoS-aware nodes (A, C)
separated by a QoS-unaware NAT (B). So, the QoS-NSLP peers are A and C, but
they are more than one NTLP hop apart. This would be either because the NTLP
is split at the NAT to re-write addresses, which participates in NTLP
security mechanisms to enable it to do so, or because there is a full
Midcom-NSLP at B. (Which of these two is possible depends on which layer
carries the relevant addressing information, which is still open, but I
don't think it changes the general argument.)]

Note this is *not* either of the following questions:
*) should state be held in the NTLP and should soft state mechanisms be used
to manage it?
*) could state be held in an NSLP and could soft state mechanisms be used to
manage it?
These are protocol design questions, distinctly beyond the framework stage.

This is the following choice:
a) Should a signalling application be able to invoke the NTLP saying "please
create this opaque state blob in my peer node and manage it", or
b) Should a signalling application just use the NTLP to get opaque data to
its peer, with the state management logic built into the signalling
application and parametrised in the data
The choice between (a) and (b) obviously has an impact on the NTLP/NSLP
divide.

I'd like to propose the answer 'No' to see how loud people shout (I know
people disagree). Here are some very brief justifications:
1. Different signalling applications might have very different qualitative
state management requirements/semantics - e.g. soft (deleted unless
explicitly refreshed), soft (deleted unless implicitly refreshed),
explicitly deleted by initiator, deleted by responder if it loses contact
with the initiator, hard, etc. Defining these semantics could be subtle
(especially the error cases). Which paradigm should the NTLP implement?
1a. Even if the qualitative aspects are the same, the quantitive
requirements (lifetimes, number of messages that can be dropped etc) over a
specific NTLP hop supporting multiple NSLPs might be different.
2. Why is doing this at the NTLP easier than doing it at the NSLP, i.e. what
does the integration with transport layer functions buy you? (NB: we could
use some guidance from the analysis work to tell us whether using a single
soft state refresh mechanism to handle packet loss/route change *and*
signalling application specific state is still felt to be a good idea.) Note
that we can still implement generic state management functionality within
the signalling application layer if we want (as Bob has pointed out
previously).
3. Some quick analysis we've done suggests that including state management
functions in the NTLP makes the NTLP API more complex (by a factor or 2 or
3). That strikes me as alarming.
4. If you believe the answer 'no' to question (I) above, then the state
management service available to the NSLP will actually be the concatenation
of several NTLP state management services. This could be hard to define and
analyse, and the e2e/fate sharing arguments might be seen as significant
here.

Views?

Robert H.