Subject: [NSIS] layer split summary? opinions?

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 28 Jan 2003 19:48:06 -0000

dear all,

as christmas fades into the past and the interim meeting looms, i'd like to re-emphasise some of the core questions that need to be considered and resolved to allow us to make progress on the framework, beyond where we are now (and hence are pretty crucial to making protocol progress as well).

the most important of these is: where does the NTLP/NSLP boundary lie - in other words (I think) what functionality do we see as both (a) common to a large proportion of 'signalling' problems, and (b) something that has to be implemented 'low down' in the stack for some reason.

if anyone has any thoughts at all on any aspects of this question, now would be a good time to raise them, especially if you disagree with any of the directions implied in the (rather long) summary below.

personally, i'd like to see the way forward on these questions finalised - at least in broad outline - in enough time to update documents for IETF#56.

cheers,

robert h.
=========================================

here are some of the facets of this question.

there seems to be either agreement or at least no disagreement that
*) the NTLP shouldn't have much more interesting message types than 'send data' (i.e. it shouldn't have a 'reserve' message for example)
*) the NTLP at one node should be able to use information visible at 'its' layer to send a message to the next NTLP node, rather than relying on the upper layer to work out routing
*) the NTLP shouldn't have concepts of sender or receiver 'initiation' e.g. of a signalling transaction; it only needs to discover its peers downstream but may need to be able to send messages upstream as well.
(see also http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02315.html for more details).

as well as these, there is at least in my head a basic assumption that traditional transport-layer like functionality (segmentation, congestion control, all the different aspects of reliability and so on) should be in the NTLP. On the other hand, some people clearly have doubts about whether these properties are needed for NSIS signalling at all.

there are some more difficult questions, where views diverge more strongly:
*) can we assume that NSLP peers are connected by a single NTLP 'hop' or might the connection run over more than one 'hop' concatenated together? (not assuming a connection oriented model here, just couldn't think of a better word.) does this non-end-to-end-ness of the NTLP restrict what functionality we should attempt to give it?
*) should the NTLP provide a state management service to signalling applications (crudely, should it provide a capability like 'create some state over there' or should it just provide the capability 'send some data over there')? some people think 'obviously yes' some think 'obviously no'.
(see http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02389.html)

*) should the NTLP contain some flow identification information similar to the 5-tuple or not (for NAT and policy routing reasons)? the framework currently says yes, but there have been objections.
(see http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02394.html).

In addition, there are things we haven't really discussed at all yet in the context of layer splitting; in particular, the role (or not) of the NTLP in scoping where messages are allowed to go, detecting and handling mobility events, what gets modified to cope with the path-decoupled case, error and failure condition detection and handling.
===================================================================
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 29 Jan 2003 15:46:50 +0100

Hi 

>> First of all I would like to mention that I am in favor 
>> of using (a migrating version of) RSVP as NTLP.
>> Meaning that NTLP should mainly support the transport 
>> layer features that are at the moment supported by RSVP, 
>> while transport layer features that are not supported by 
>> RSVP should not be supported by the NTLP.
> 

>It would be helpful for the discussion if you could state a technical 
>reason for this opinion.

In my opinion we should try to 
reuse as much as possible the existing transport layer 
solutions provided by RSVP.
In this way we could reuse the current RSVP design experience 
and RSVP protocol specification and shorten the time that 
is needed to standardize NTLP.
I think that the flexibility and modularity requirement can be 
fulfilled by the two level architecture concept. New features will 
have to be supported by NSLPs.

Of course we could try to invent a completely new protocol that 
will be able to support many features, and which probably will not be 
deployed on a large scale.

Best Regards,
Georgios

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Wed, 29 Jan 2003 18:01:53 -0500

My 2 cents are in line.

Regards,
Ilya Freytsis

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:[email-masked]]
Sent: Wednesday, January 29, 2003 9:15 AM
To: 'Hancock, Robert'
Cc: [email-masked]
Subject: RE: [NSIS] layer split summary? opinions?

Hi Robert

Please see my further comments in line:
>> *) the NTLP shouldn't have much more interesting message types
>> than 'send data' (i.e. shouldn't have a 'reserve' message for example)

Yes, but a certain message for example could be used for "reserve"
and "refresh" of a NTLP state and another one for "teardown" of the
NTLP state.

>> *) the NTLP at one node should be able to use information visible
>> at 'its' layer to send a message to the next NTLP node, rather
>> than relying on the upper layer to work out routing

If the way of using this information is similar to the way used by
RSVP, i.e., path-coupled signaling, then I agree!

>> *) the NTLP shouldn't have concepts of sender or receiver
>> 'initiation' e.g. of a signaling transaction; it only needs
>> to discover its peers downstream but may need to be able to send messages
upstream as well.
>> (see also
http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02315.html
>> for more details).

Agree!

>> as well as these, there is at least in my head a basic assumption that
>> traditional transport-layer like functionality (segmentation, congestion
>> control, all the different aspects of reliability and so on) should be in
>> the NTLP. On the other hand, some people clearly have doubts about
>> whether these properties are needed for NSIS signalling at all.

I think that such transport-layer like functions should not
be a part of the NTLP!
Such functions should be accomplished as much as possible by NSLPs.
NTLP should mainly support the transport layer features
that are at the moment supported by RSVP, while transport layer features
that are not supported by RSVP should not be supported by
the NTLP.

[Ilya] I would argue that from the strictly layer separation perspective it
is beneficial to put as much common transport functionality into NTLP as
possible and do not duplicate it in various NSLPs. 

>> *) can we assume that NSLP peers are connected by a single NTLP 'hop' or
>> might the connection run over more than one 'hop' concatenated
>> together? (not assuming a connection oriented model here, just couldn't
>> think of a better word.) does this non-end-to-end-ness of the
>> NTLP restrict what functionality we should attempt to give it?

If we want to develop a flexible NTLP that can be used by different NSLPs
I think that we should allow that the connection between two NSLP peers
runs over more than one NTLP "hop".

>> *) should the NTLP provide a state management service to signalling
>> applications (crudely, should it provide a capability like 'create
>> some state over there' or should it just provide the capability 'send
>> some data over there')? some people think 'obviously yes' some think
'obviously no'.
>> (see
http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02389.html)

If we consider that the connection between two NSLP peers
runs over more than one NTLP "hop" then I think that the NTLP should
be able to provide "NTLP" state management.
Now regarding the state management service to signaling
applications, I think that it should be left open.
A signaling application may use either the NTLP state management or
provide its own state management.

>> *) should the NTLP contain some flow identification information
>> similar to the 5-tuple or not (for NAT and policy routing reasons)?
>> the framework currently says yes, but there have been objections.
>> (see
http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02394.html).

If the NTLP will provide "NTLP" soft state management then I think that
flow identification and state identification information will be necessary!
Moreover, you need the flow identification to be able to differentiate
between different signaling applications that are
running on the same node and are supported by the NTLP.
[Ilya] I am not sure that I follow to Georgios' logic here but I share the
rational in Robert's message (referenced above) for having "flow routing
information" in NTLP.

>> In addition, there are things we haven't really discussed at all
>> yet in the context of layer splitting; in particular, the role (or not)
>> of the NTLP in scoping where messages are allowed to go, detecting
>> and handling mobility events, what gets modified to cope with the
>> path-decoupled case, error and failure condition detection and handling.

Again, NTLP should mainly support the transport layer features
that are at the moment supported by RSVP while transport layer features
that are not supported by RSVP should not be supported by
the NTLP.

Best regards,
Georgios

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 30 Jan 2003 14:52:14 +0100

Dear Henning

>> However, your statement does add a requirement to 
>> NTLP: namely, that it  should be able to use either 'raw' IP 
>> or an existing transport 
>> mechanism, such as UDP, TCP or SCTP (or possibly one of the emerging 
>> UDP-like, congestion-controlled protocols being discussed in TSVAREA).

Yes I agree!

Best Regards,
Georgios

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 30 Jan 2003 22:47:53 -0000

dear all,

some points on terminology and trying to clarify exactly what question is being discussed:

1. The framework describes 'the NSIS transport layer' as *everything* below the signalling application layer and above the IP layer (e.g. figs 2/3). What we (or at least, I) am trying to discover is what functionality should be in this layer, *however* it is structured internally.

2. suggesting that a 'simple' basic NTLP sublayer of some sort could be run over TCP (or SCTP) is a very interesting design constraint for that sublayer. (In the purest form, where the sublayer operates entirely over one or more TCP connections, I suspect it is an engineering impossibility, mainly for addressing/peer discovery reasons. This is one reason why the framework document does not draw such a strict layered picture.) But it's a question about designing the NTLP, *not* what functionality it should encapsulate. (Shameless plug: We have tried to list some of the issues about this and other possible approaches in http://www.ietf.org/internet-drafts/draft-mcdonald-nsis-ntlp-considerations-00.txt.)

3. *Whatever* of these approaches is taken, it doesn't affect the apparent consensus that an NSLP should be able to call on some combination of lower layers (whatever you call them) which provide these classic transport-like functions. (What I get from Georgios is that he'd like them to be somehow optional to use. But I'll write a separate mail on that.)

I'd like to proceed on the basis that the assumption in (3) is correct.

Cheers,

Robert H.

> Sent: 30 January 2003 13:52
> To: 'Henning Schulzrinne'
> Cc: [email-masked]

---

From: [email-masked]
Date: Fri, 31 Jan 2003 09:56:58 +0100

Hi Robert, all,

Please see some (Georgios/Ilya/Henning-aware) comments inline.

Sven

"Hancock, Robert" <[email-masked]>@ietf.org on 28/01/2003
20:48:06

Sent by:    [email-masked]

To:    [email-masked]
cc:
Subject:    [NSIS] layer split summary? opinions?

dear all,

as christmas fades into the past and the interim meeting looms, i'd like to
re-emphasise some of the core questions that need to be considered and
resolved to allow us to make progress on the framework, beyond where we are
now (and hence are pretty crucial to making protocol progress as well).

the most important of these is: where does the NTLP/NSLP boundary lie - in
other words (I think) what functionality do we see as both (a) common to a
large proportion of 'signalling' problems, and (b) something that has to be
implemented 'low down' in the stack for some reason.

if anyone has any thoughts at all on any aspects of this question, now
would be a good time to raise them, especially if you disagree with any of
the directions implied in the (rather long) summary below.

personally, i'd like to see the way forward on these questions finalised -
at least in broad outline - in enough time to update documents for IETF#56.

cheers,

robert h.

there seems to be either agreement or at least no disagreement that
*) the NTLP shouldn't have much more interesting message types than 'send
data' (i.e. it shouldn't have a 'reserve' message for example)

[Sven] I agree.

*) the NTLP at one node should be able to use information visible at 'its'
layer to send a message to the next NTLP node, rather than relying on the
upper layer to work out routing

[Sven] I agree. I am just wondering here if whatever processing happens at
the NSLP layer can change the destination address for the NTLP. In other
words, does the interface between NSLP and NTLP allow updating NTLP
objects/fields?

*) the NTLP shouldn't have concepts of sender or receiver 'initiation' e.g.
of a signalling transaction; it only needs to discover its peers downstream
but may need to be able to send messages upstream as well.
(see also
http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02315.html
for more details).

[Sven] I agree with the first sentence. I am not so sure about the second
part. This is obviously used for reverse routing the message over the
forward path but I think this will definitely not be needed for all NSLPs.
Also, does it imply keeping state or could it also mean that NTLP would
support some kind of record/explicit route object

as well as these, there is at least in my head a basic assumption that
traditional transport-layer like functionality (segmentation, congestion
control, all the different aspects of reliability and so on) should be in
the NTLP. On the other hand, some people clearly have doubts about whether
these properties are needed for NSIS signalling at all.

there are some more difficult questions, where views diverge more strongly:
*) can we assume that NSLP peers are connected by a single NTLP 'hop' or
might the connection run over more than one 'hop' concatenated together?
(not assuming a connection oriented model here, just couldn't think of a
better word.) does this non-end-to-end-ness of the NTLP restrict what
functionality we should attempt to give it?

[Sven] Does this mean that we need a kind of transparent way to send
messages through NTLP peers without looking at them in the NSLP layer (like
router alert, or rather the inverse of it). In that case it wouldn't even
matter whether there was an NSLP peer above or not. I find the suggestion
of non-end-to-endness for NTLP interesting. Does it mean NSLP will always
provide the end-to-end aspects? In that case, is it possible that there is
a different src/dst @ in NSLP and NTLP?

*) should the NTLP provide a state management service to signalling
applications (crudely, should it provide a capability like 'create some
state over there' or should it just provide the capability 'send some data
over there')? some people think 'obviously yes' some think 'obviously no'.
(see
http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02389.html)

[Sven] I would be inclined to say no. I would say NTLP just gets a message
from A to B without leaving intermediate state.

*) should the NTLP contain some flow identification information similar to
the 5-tuple or not (for NAT and policy routing reasons)? the framework
currently says yes, but there have been objections.
(see
http://www.ietf.org/mail-archive/working-groups/nsis/current/msg02394.html
).

[Sven] I would say yes for the reasons you point out (NAT, ...) I am
wondering however how potential NSLP objects are treated if this happens.

In addition, there are things we haven't really discussed at all yet in the
context of layer splitting; in particular, the role (or not) of the NTLP in
scoping where messages are allowed to go, detecting and handling mobility
events, what gets modified to cope with the path-decoupled case, error and
failure condition detection and handling.
===================================================================
_______________________________________________
nsis mailing list
[email-masked]
 https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 31 Jan 2003 10:52:56 +0100

Hi Robert

Please see my comment in line!
>> Firstly, I don't know the full story, but my impression of 
>> the 'RSVP[2205] design experience' is that if you don't put 
>> these features in at the start, you have to put them in later 
>> (rfc2961). 

The goal of providing the bundling of messages in RFC 2961 was to
mainly reduce the processing overhead requirements of refresh messages.
In my opinion if the bundling of refresh messages and the exponential 
back-off procedures are needed then they could be provided by the NSLP
that needs them. Not all NSLPs will need such features.

>> [A similar point can be made about security, i.e. 2747.]

Regarding RFC2747, I agree! Anyway RFC2205 refers to the 
RSVP Cryptographic Authentication work that is currently 
included in RFC2747.

>> Secondly, it is frequently stressed that the IETF strives to develop protocols 
>> which function robustly in all possible environments, i.e. open networks 
>> subject to overload, misconfiguration of individual elements, constrained 
>> links, malicious traffic, and so on (see also RFC3426). I don't see this 
>> requirement being relaxed just because we are starting from parts of an 
>> existing protocol.

>> In other words, even if you don't think you need these features in your 
>> protocol today, someone will use it next year in an environment where they 
>> do - by which time it could be too late. This has been the experience for 
>> other network problems in the past (it's happened in interior and exterior 
>> routing protocols, SIP), I don't see why signalling protocols should be immune.

I agree that NSIS (NTLP + NSLP) in combination with other IETF existing protocols
e.g., TCP, SCTP, that can operate below NTLP should function robustly in all possible environments.
This does not mean that NTLP should reinvent all the features that TCP or SCTP
can provide. In my opinion additional features that have be provided by 
NSIS (for some environments) and are not supported by TCP, SCTP or NTLP,
should be provided by NSLP.

Best regards,
Georgios

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Fri, 31 Jan 2003 11:09:02 -0500

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Thursday, January 30, 2003 8:50 AM
To: Georgios Karagiannis (ELN)
Cc: [email-masked]
Subject: Re: [NSIS] layer split summary? opinions?
That's what I've been advocating. Part of the discussion problem seems
to be that some people say "NTLP" and mean "whatever 'transport' layer
NSIS invents including the transport below", others mean "whatever sits
on top of either IP or TCP/SCTP". We should agree on one definition.

A different way of phrasing the confusion is that some people see NTLP
as an interface to the higher layer (NSLP) above - it describes all of
the services that the NSIS-new-stuff adds plus any underlying existing
transport protocol offers.

Other people, possibly guided by the 'P' at the end, see it as a
protocol, i.e., describe only the services that this layer adds on top
of whatever L3/L4 mechanism is below.

[Ilya] It seems to me that both definitions and views (since they are
related) can be useful depending on what is being discussed. When the
NTLP/NSLP split is discussed viewing NTLP as services to NSLP is meaningful.
On the other hand one cannot discuss the details of the NTLP behavior
independent on what it is sitting on top of.
 
Regards,
Ilya Freytsis