Subject: RE: AW: [NSIS] Transport functionality in the NTLP

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 19 Feb 2003 11:56:39 +0100

hi all, 

if we want to support 
a) applications which demand limited transport layer functionality and 
b) other applications which demand more transport layer functionality 
then we need to use peer-to-peer addressing for signaling message delivery
(instead of end-to-end addressing). peer-to-peer addressing places the least
restrictions on the ability to support different protocols executed between
neighboring peers. 

does this sound reasonable? 

ciao
hannes

> -----Original Message-----
> From: Lars.Westberg [mailto:[email-masked]]
> Sent: Wednesday, February 19, 2003 11:28 AM
> To: Geib, Ruediger
> Cc: [email-masked]; [email-masked]
> Subject: Re: AW: [NSIS] Transport functionality in the NTLP
> 
> 
> 
> The transport protocol may have these function, but I do not 
> see that it is neccessary in all applications. Un-reliable 
> transport is a must in this protocol.
> Make the NTLP as a minimum set of functions.
> 
> Regards Lasse
> 
> "Geib, Ruediger" wrote:
> 
> > Dear all,
> >
> > the transport protocol must ensure that signaling messages 
> aren't lost or corrupted. Further, NTLP is expected to deal 
> with route changes. I don't think that an unreliable 
> transport is best possible solution supporting this task. 
> Congestion avoidance is a benefit to users and operators, 
> that's why it must be present too. To me, a) seems to be 
> reasonable option.
> >
> > Regards, Rüdiger
> >
> > | a) yes the protocol must always guarantee this feature explicitly
> >
> > | 1. Congestion control (NTLP must protect the local network
> > | from signalling overload) - suggest (a)
> > | 2. High probability of delivery to the next NE even in the
> > | face of packet drops - I suggest (a)
> > | 3. Guaranteed delivery to next NSLP node with feedback on
> > | success - I suggest (d)
> > | 4. Bundling of small messages - I suggest (c), doing it has
> > | only local significance
> > | 5. Segmentation to avoid link/path MTU limits - I suggest
> > | (a), or (b) if you know all your links up to the next NE can
> > | be engineered to have a big enough MTU
> > | 6. In order delivery and duplicate detection/removal - I
> > | suggest (a) (maybe (c), if you are prepared to put it back
> > | locally in adjacent hops)
> > | 7. Framing (supporting message boundaries) - I suggest (a)
> > | 8. Flow control - not sure about this one. Maybe (c)
> > | 9. Security (confidentiality, integrity protection) - I
> > | suggest (a) or (b)
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> 
> _______________________________________________
> 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: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 19 Feb 2003 12:00:27 +0100

Hi Robert

Please see my comments:

1. Congestion control (NTLP must protect the local network from signalling overload) 
- I suggest (c) or (d). In some scenarios, congestion control can be 
provided locally, within a domain, and it does not have to be hop-by-hop.

2. High probability of delivery to the next NE even in the face of packet drops 
- I suggest (c) or (d). This could be solved by the NSLP at end-to-end, end-to-edge
  or edge-to-edge level.
 
3. Guaranteed delivery to next NSLP node with feedback on success 
- I suggest (d)

4. Bundling of small messages 
- I suggest (c), agreed with argument from Robert;

5. Segmentation to avoid link/path MTU limits - 
I suggest (d), the NSLP should take care that the MTU is 
not higher than a certain limit.

6. In order delivery and duplicate detection/removal 
- I suggest (c) or (d). The NSLP can detect this at an end-to-end, end-to-edge 
or edge-to-edge level.

7. Framing (supporting message boundaries) What do you mean here?

8. Flow control - not sure about this one. 
- I suggest(c)

9. Security (confidentiality, integrity protection) 
- I suggest (a) or (b) 

Best Regards,
Georgios 

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]]
Sent: woensdag 19 februari 2003 0:42
To: [email-masked]
Subject: [NSIS] Transport functionality in the NTLP

Dear all,

We've posed questions about what transport-like functionality (reliability and so on) should be present in signalling protocols, and in particular how it should be divided in our 2 layer NTLP/NSLP model.
[On the mailing list, the discussion tends to transmogrify immediately into 'why TCP is/is not the right answer'; in the interim meeting, we made slightly more progress but didn't reach agreement in the room. Hence this mail.]

So here is a list of functionality which you might or might want in the NTLP. Make your views known, if you have any. You could say for example:
a) yes the protocol must always guarantee this feature explicitly
b) this property must be achieved but you could do it by other mechanisms as well (e.g. 'security' could be 'cryptographic protection' or 'network is physically protected')
c) it should be an option (in which case, what are the implications of having parts of the path support it and parts not)
d) no, there is no point in having this in the transport layer (e.g. it provides no benefit, or we can assume an upper NSLP will do it for us)

Here is a list of functions and an initial set of working assumptions (some deliberately provocative, but at least partly influenced by our recent discussions)
1. Congestion control (NTLP must protect the local network from signalling overload) - suggest (a)
2. High probability of delivery to the next NE even in the face of packet drops - I suggest (a)
3. Guaranteed delivery to next NSLP node with feedback on success - I suggest (d)
4. Bundling of small messages - I suggest (c), doing it has only local significance
5. Segmentation to avoid link/path MTU limits - I suggest (a), or (b) if you know all your links up to the next NE can be engineered to have a big enough MTU
6. In order delivery and duplicate detection/removal - I suggest (a) (maybe (c), if you are prepared to put it back locally in adjacent hops)
7. Framing (supporting message boundaries) - I suggest (a)
8. Flow control - not sure about this one. Maybe (c)
9. Security (confidentiality, integrity protection) - I suggest (a) or (b)

cheers,

robert h.

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 19 Feb 2003 13:44:27 +0100

Hi Hannes

This is not about applications that demand limited transport layer 
functionalities, but it is about environments and scenarios.
There are scenarios, for example:
* wireless access scenarios will only need
a part of these features, since these features can be provided by other 
means
* the wired part of a cellular system that does need these features.
regarding end to end addressing, use the same addressing procedures as RSVP,
since they are working fine!

Best Regards,
Georgios

-----Original Message-----
From: Tschofenig Hannes [mailto:[email-masked]]
Sent: woensdag 19 februari 2003 11:57
To: Lars Westberg (EAB); Geib, Ruediger
Cc: [email-masked]; [email-masked]
Subject: RE: AW: [NSIS] Transport functionality in the NTLP

hi all, 

if we want to support 

ciao
hannes

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 19 Feb 2003 13:47:06 +0100

Hi Hannes

Sorry, I meant 
* the wired part of a cellular system that does "NOT" need these features.

Best Regards,
Georgios

-----Original Message-----
From: Georgios Karagiannis (ELN) 
Sent: woensdag 19 februari 2003 13:44
To: 'Tschofenig Hannes'
Cc: [email-masked]
Subject: RE: AW: [NSIS] Transport functionality in the NTLP

Hi Hannes

Best Regards,
Georgios

-----Original Message-----
From: Tschofenig Hannes [mailto:[email-masked]]
Sent: woensdag 19 februari 2003 11:57
To: Lars Westberg (EAB); Geib, Ruediger
Cc: [email-masked]; [email-masked]
Subject: RE: AW: [NSIS] Transport functionality in the NTLP

hi all, 

if we want to support 

ciao
hannes

---

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 19 Feb 2003 14:52:35 +0100

hi georgios

> functionalities, but it is about environments and scenarios.

ok, i reformulate it. how about: applications, environments and scenarios

> a part of these features, since these features can be 

i sometimes have the impression that this is more like a feeling than based
on solid grounds. 

> since they are working fine!

if i got john's comments at the nsis interim meeting correctly then we do
not try to create a protocol which is tailored to a very specific
application, environment or scenario. 

creating a "more lighweight" (whatever that means) protocol for very
specific applications, environments and scenarios with the drawback that the
entire protocol becomes a mess is probably not the right choice (an example:
providing congestion control at the nslp in an end-to-end fashion).

ciao
hannes

---

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 19 Feb 2003 14:55:39 +0100

hi georgios

i have difficulties to see your arguments agains peer-to-peer addressing.
they have nothing todo with the wireless network. 

ciao
hannes

> [mailto:[email-masked]]
> Sent: Wednesday, February 19, 2003 1:47 PM
> To: Georgios Karagiannis (ELN); Tschofenig Hannes
> Cc: [email-masked]

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 19 Feb 2003 15:06:39 +0100

Hi Hannes

What do you mean?
Regarding peer to peer addressing, have I given such arguments?

Best Regards,
Georgios 

-----Original Message-----
From: Tschofenig Hannes [mailto:[email-masked]]
Sent: woensdag 19 februari 2003 14:56
To: Georgios Karagiannis (ELN)
Cc: [email-masked]
Subject: RE: AW: [NSIS] Transport functionality in the NTLP

hi georgios

ciao
hannes

---

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 19 Feb 2003 15:29:27 +0100

hi georgios

please see my comments inline:

> >> i sometimes have the impression that this is more like 
> >> a feeling than based on solid grounds.
> 
> What do you mean?
> In wireless networks link layers provide such features!!!!!
> Please, do not impose performance degradations when it is not 
> needed!!!

i didn't want to make you angry. i know that you are very enthusiastic about
wireless networks.  

however, if you have end-to-end qos signaling then you might also carry the
signaling messages over a non-wireless link. this is again a reason for
peer-to-peer signaling since you can (possibly) switch your ntlp at some
parts in the network (which would help you).

> 
> > * the wired part of a cellular system that does not need 
> these features.
> [hannes] if i got john's comments at the nsis interim meeting 
> [hannes] correctly then we do not try to create a protocol which 
> [hannes] is tailored to a very specific application, 
> environment or scenario. 
> 
> [hannes] creating a "more lighweight" (whatever that means) 
> protocol for very
> [hannes] specific applications, environments and scenarios 
> with the drawback that the
> [hannes] entire protocol becomes a mess is probably not the 
> right choice (an example:
> [hannes] providing congestion control at the nslp in an 
> end-to-end fashion).
> 
> Wireless scenarios are not specific applications!!!!

i know that. that's why i said specific applications, environments and
scenarios. 

> Actually the goal of starting NSIS was to solve QoS issues in 
> wireless scenarios. Please do not forget this!!!!

as you know: the charter changed some time ago - nsis now tries to be more
generic. 

> Other types of scenarios could also use NSIS, but in my opinion 
> NSIS should at least satisfy the requirements imposed by 
> wireless scenarios!!!

i guess that i am not the right person to give you an answer for this
(forward to john). 

ciao
hannes

---

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 19 Feb 2003 15:36:31 +0100

hi georgios! 

in your previous mail you said: 
> > regarding end to end addressing, use the same addressing procedures as
RSVP, since they are working fine!

from the various presentations given at the nsis interim meeting i thought
that we concluded that the combination of signaling message delivery and
discovery is not the best thing and that some extensions already already
assume a logical peer-to-peer addressing. furthermore end-to-end addressing
prevents the usage of existing protocols and places unnecessary restrictions
on nsis as a generic signaling protocol. 

i guess that also you remember scott bradner saying that you cannot assume
that the next nsis peer will also be known. 

ciao
hannes

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 19 Feb 2003 17:07:45 +0100

Hi Hannes

> parts in the network (which would help you).

As I already mentioned, first we have to agree on the definition 
of the term peer to peer signaling protocol!
Second, it should not be mandated to use the mentioned features!
Allow scenarios to not use these features!

>> as you know: the charter changed some time ago - nsis now tries to be more

The WG charter changed some times, but anyway 
it was agreed to follow the NSIS requirements!
Thus also the requirements imposed by wireless scenarios!

Best regards,
Georgios

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 19 Feb 2003 17:22:19 +0100

Hi Hannes

>> that the next nsis peer will also be known. 

Well what we actually concluded on this issue is:
* the typically solution for path discovery will be the path 
  forwarding routing solution (as in RSVP). When this solution cannot 
  be applied then other type of discovery procedure could be applied;

Best Regards,
Georgios

---

From: Tschofenig Hannes <[email-masked]>
Date: Fri, 21 Feb 2003 19:08:19 +0100

hi georgios

>   be applied then other type of discovery procedure could be applied;

there are different issues: 

- discovery
- signaling message delivery

in-path discovery is certainly similar to the path message used in rsvp. you
would include the address of the data destination in the discovery message
(and attach a router alert option to it).

i tried to point to the problem of end-to-end addressing for signaling
message delivery. 

ciao
hannes

---

From: Tschofenig Hannes <[email-masked]>
Date: Fri, 21 Feb 2003 19:11:02 +0100

hi georgios

> of the term peer to peer signaling protocol!

i am surprised to see that there is some uncertainty about it. 

> Second, it should not be mandated to use the mentioned features!

sooner or later we have to decide something. with regard to addressing i
tend to favor an approach which is less restrictive (namely peer-to-peer
addressing). 

> Allow scenarios to not use these features!
i clearly see your point. i could argue in a similar way: enable protocol
features which do not prevent certain applications, scenarios etc. 

> it was agreed to follow the NSIS requirements!

the requirement document was an important work - also for getting a common
understanding and for team building. 

> Thus also the requirements imposed by wireless scenarios!

i guess you know that the protocol issues discussed are not orthogonal.
hence if your design focus is restricted to a particular scenario only then
there is a high risk that you actually prevent protocol usage in other
scenarios, applications etc. 

with recent work activities we tried to point to some issues (some objects
e.g. firewall/nat communication, some interaction with aaa/charging,
interworking with non-standard trust relationships, etc.) which demand
protocol properties for a more general deployment scenario. 

ciao
hannes

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 24 Feb 2003 11:25:12 +0100

Hi Hannes

[georgios] Allow scenarios to not use these features!
[hannes] i clearly see your point. i could argue in a similar 
[hannes] way: enable protocol features which do not prevent 
[hannes] certain applications, scenarios etc. 

Yes, but these features can then be used as optional features.
Scenarios that do not require them will not use them!

[hannes] i guess you know that the protocol issues discussed are 
[hannes] not orthogonal.
[hannes] hence if your design focus is restricted to a particular 
[hannes] scenario only then there is a high risk that you actually 
[hannes] prevent protocol usage in other scenarios, applications etc. 

In my opinion wireless scenarios should be seen as general deployment 
scenarios.
The usage of the protocol is only restricted when unnecessary features 
are mandated. Thus making the protocol useless in certain 
wireless scenarios.

NTLP should be able to support optional features that will be used 
by scenarios that need them, and not by scenarios that do not need these 
optional features!

Best Regards,
Georgios

---

From: Tschofenig Hannes <[email-masked]>
Date: Mon, 24 Feb 2003 18:49:31 +0100

hi georgios!

> Scenarios that do not require them will not use them!

this might be true for some of the features. for the addressing model this
is unfortunately not so simple. 

> by scenarios that need them, and not by scenarios that do not 

i fully agree with you when it comes to some nice-to-have features. hence
the only question remains what you call a "feature". 

our previous discussion was centered around addressing which i personally
think is probably one of the most important issues. i would not call
peer-to-peer addressing a feature which you might add later when desired. 

if you would like to see a protocol which is less restrictive then you might
want to argue for a peer-to-peer addressing scheme instead of a end-to-end
addressing. this means that i see peer-to-peer addressing as less
restrictive. 

how does that sound?

ciao
hannes

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Tue, 25 Feb 2003 10:17:34 +0100

Hi Hannes

Thank you for your e-mail.
Regarding the peer-to-peer addressing versus 
end-to-end addressing, could you please 
answer the following questions.
The reason of this is that I would like to 
know if we agree on the definitions of  peer-to-peer 
and end-to-end addressing.

When you consider peer-to-peer addressing are you
assuming that the NTLP protocol terminates and if possible 
is re-initiated at each hop?

In your opinion, what type of addressing is being used 
by the RSVP protocol, end-to end or peer to peer?

Best Regards,
Georgios

-----Original Message-----
From: Tschofenig Hannes [mailto:[email-masked]]
Sent: maandag 24 februari 2003 18:50
To: Georgios Karagiannis (ELN)
Cc: [email-masked]
Subject: RE: AW: [NSIS] Transport functionality in the NTLP

hi georgios!

how does that sound?

ciao
hannes

---

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 25 Feb 2003 11:59:45 +0100

hi georgios!

> is re-initiated at each hop?

what do you mean by terminate? 
a) addressed to a next peer, processed and forwarded to the next peer
b) stopping without sending the signaling message to further peers 

> by the RSVP protocol, end-to end or peer to peer?
rsvp uses a mixture of both - some messages use end-to-end addressing
whereas others use peer-to-peer addressing. 

ciao
hannes