Subject: ntlp terminology confusions (was: RE: [NSIS] layer split summary? opinions?)

From: "Hancock, Robert" <[email-masked]>
Date: Sun, 2 Feb 2003 16:53:18 -0000

dear all,

as (partly) responsible for some of the confusion that henning refers to below, allow me to try to restate (again) the two questions which i think we are trying to address.

1. the layer split question: what overall functionality should be below the signalling applications; and in particular, whether that functionality should include things like local reliable delivery, sequencing, etc.

2. the design question: ***if*** the answer to (1) is 'yes', should that functionality be provided in a sort of pure 2205-like way, or as an integrated new-ish special purpose transport protocol (like CSTP/IP), or using an existing protocol as a component (like CASP does), or some other way.

i feel we should try to answer (1) without getting immediately hung up on (2), which is why i have phrased the question abstractly as NTLP/NSLP layer split. But maybe the 'P' in NTLP confuses the issue because we can't stop thinking about (2), and the options clearly show that the NTLP could be a single P, or 2 Ps (or even more).

if it makes life easier, we could phrase (1) (and indeed the rest of the framework) entirely in terms of Ls rather than Ps, so (1) would be a question of the split between the signalling and transport layers (NSL/NTL), and (2) would be a question of whether the NTL should be implemented as one or several protocols.

your friendly framework editor,

robert h.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 02 February 2003 13:51
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] layer split summary? opinions?
> 
> 
> Hi Henning & Georgios,
> 
> > > No, if an application needs TCP or SCTP features, then 
> these applications 
> > > should probably use the TCP or SCTP protocols, e.g., below NTLP.
> > 
> > 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.
> 
> Well, I think we need to determine if, for example, reliable transport
> is needed.  If so, then I suggest that we use TCP/SCTP; if not, then
> UDP will probably be enough. 
> 
> > 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.
> 
> Ultimately, this is what we will need to do.
>  
> > The re-use of the word transport can't help but add to 
> > misunderstandings, but we probably lack the language supply 
> to fix that 
> > particular problem. (We have used the term messaging layer in one 
> > context, but that term has its own set of problems.)
> 
> Agreed.
> 
> > 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).
> 
> I agree.
> 
> John
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 03 Feb 2003 15:43:04 -0500

Even the word layer will be taken to mean just the NSIS addition itself, 
without the lower layer support. I think it would be most helpful to 
spell out that this can indeed be done in multiple ways.

Another possibility is to call it 'service', which has some notion of 
encapsulating lower layer hand-me-up services.