From mailnull@www1.ietf.org Sun Feb 2 08:49:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05552 for ; Sun, 2 Feb 2003 08:49:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h12DrxN32280 for nsis-archive@odin.ietf.org; Sun, 2 Feb 2003 08:53:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h12DrnJ32269; Sun, 2 Feb 2003 08:53:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h12DqvJ32216 for ; Sun, 2 Feb 2003 08:52:57 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05523 for ; Sun, 2 Feb 2003 08:47:55 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h12Ds4e13809 for ; Sun, 2 Feb 2003 15:54:04 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 2 Feb 2003 15:51:28 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 2 Feb 2003 15:51:28 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 2 Feb 2003 15:51:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] layer split summary? opinions? Date: Sun, 2 Feb 2003 15:51:27 +0200 Message-ID: Thread-Topic: [NSIS] layer split summary? opinions? Thread-Index: AcLJNa7tVnFRB5SZTC+YAU9HcBeOdQBjCvfA To: , Cc: X-OriginalArrivalTime: 02 Feb 2003 13:51:27.0846 (UTC) FILETIME=[2EDC7060:01C2CAC2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h12DqvJ32217 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit 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 nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Feb 2 08:49:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05568 for ; Sun, 2 Feb 2003 08:49:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h12Ds8J32314 for nsis-archive@odin.ietf.org; Sun, 2 Feb 2003 08:54:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h12Ds2J32303; Sun, 2 Feb 2003 08:54:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h12DrUJ32256 for ; Sun, 2 Feb 2003 08:53:30 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05547 for ; Sun, 2 Feb 2003 08:48:26 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h12Dovk26704 for ; Sun, 2 Feb 2003 15:50:57 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 2 Feb 2003 15:52:01 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 2 Feb 2003 15:52:01 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 2 Feb 2003 15:52:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Date: Sun, 2 Feb 2003 15:52:00 +0200 Message-ID: Thread-Topic: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt Thread-Index: AcLH5JsP1xtD+HtqQY2I9bf9zP3xMgC3Z3AA To: , X-OriginalArrivalTime: 02 Feb 2003 13:52:01.0094 (UTC) FILETIME=[42ADAE60:01C2CAC2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h12DrUJ32257 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, This text looks good. Shall we adopt it? John > -----Original Message----- > From: ext Kuntal Chowdhury [mailto:kuntal@iqmail.net] > Sent: 30 January, 2003 00:12 > To: nsis@ietf.org > Subject: Re: [NSIS] WG Last Call on draft-ietf-nsis-req-06.txt > > > Hi all, > Here is the updated text for issue# 7. I incorporated the > comments from Maarten > and Brian. > > -------------------------------------------------------------- > ---------------- > > 10.2 3G Wireless Networks > > In this scenario, the user is using the packet services of a 3rd > generation wireless system (e.g. 3GPP/UMTS, 3GPP2/cdma2000). The > region between the End Host and the Edge Node (Edge Router) > connecting the wireless network to another QoS domain is > considered > to be a single QoS domain. > > The issues in such an environment regarding QoS include: > > 1) 3G wireless networks provide their own QoS technology with > specialized parameters to co-ordinate the QoS provided by both the > radio access and wired access networks. Provisioning of QoS > technologies within a 3G wireless network can be described mainly > in terms of calling bearer classes, service options and service > instances. These QoS technologies need to be invoked with suitable > parameters when higher layers trigger a request for QoS. Therefore > these involve mapping of the requested higher layer QoS parameters > onto specific bearer classes or service instances. The request for > allocation of resources might be triggered by signaling at the IP > level that passes across the wireless system, and possibly other > QoS domains. Typically, wireless network specific messages are > invoked to setup the underlying bearer classes or service > instances > in parallel with the IP layer QoS negotiation, to > allocate resources > within the radio access network. > > 2) The IP signaling messages are initiated by the NSIS > initiator and > interpreted by the NSIS Forwarder. The most efficient placement of > the NSIS Initiator and NSIS Forwarder has not been > determined in 3G > wireless networks, but a few potential scenarios can be > envisioned. > The NSIS Initiator could be located at the End Host e.g. UE or MS > (triggered by applications), the Access Gateway or at a > node that is > not directly on the data path, such as a Policy Decision Function. > The Access Gateway could act as a proxy NSIS Initiator on > behalf of > the UE/MS or an End Host. The Policy Decision Function > that controls > per-flow/aggregate resources with respect to the session > within its > QoS domain (e.g. the 3G wireless network) may act as a proxy NSIS > Initiator for the UE/MS or the Access Gateway. Depending on the > placement of the NSIS Initiator, the NSIS Forwarder may > be located at > an appropriate point in the 3G wireless network. > > 3) The need for re-negotiation of resources in a new 3G wireless > domain due to UE/MS mobility. In this case the NSIS > Initiator and the > NSIS Forwarder should detect mobility events and > autonomously trigger > re-negotiation of resources. > > > > 10.3 An example scenario for 3G wireless networks > > The 3G wireless access scenario is shown in Figure 1. > The Proxy-Call > State Control Function (P-CSCF) is the outbound SIP > proxy (only used > in IMS). The Access Gateway is the egress router of the > 3G wireless > domain and it connects the radio access network to the > Edge Router > (ER) of the backbone IP network. The Policy Decision > Function (PDF)is > an entity responsible for controlling bearer level > resource allocations/ > de-allocations in relation to session level services > e.g. SIP. The > Policy Decision Function may also control the Access > Gateway to open > and close the gates and to configure per-flow policies, i.e. to > authorize or forbid user traffic. The P-CSCF (only used > in IMS) and > the Access Gateway communicate with the Policy Decision > Function, for > network resource allocation/de-allocation decisions. The > User Equipment > (UE) or the Mobile Station (MS) consists of a Mobile > Terminal (MT) and > Terminal Equipment (TE), e.g. a laptop. > > > +--------+ > +--------->| P-CSCF |---------> SIP signaling > / +--------+ > / SIP | > | | > | +-----+ +----------------+ > | | PDF |<---------->| NSIS > Forwarder |<---> > | +-----+ +----------------+ > | | ^ > | | | > | | | > | |COPS | > | | | > +------+ +---------+ | > | UE/MS|----------| Access |<-----------+ +----+ > +------+ | Gateway |------------------| ER | > +---------+ +----+ > > Figure 1: 3G wireless access scenario > > The PDF has all the required QoS information for per-flow > or aggregate > admission control in 3G wireless networks. It receives resource > allocation/de-allocation requests from the P-CSCF and/or > Access Gateway etc. and responds with policy decisions. > Hence the PDF > may be a candidate entity to host the functionality of the NSIS > Initiator, initiating the "NSIS" QoS signaling towards > the backbone IP > network. On the other hand, the UE/MS may act as the NSIS > Initiator or > the Access Gateway may act as a Proxy NSIS Initiator on > behalf of the > UE/MS. In the former case, the P-CSCF/PDF has to do the > mapping from > codec types and media descriptors (derived from SIP/SDP > signaling) to > IP traffic descriptor. In the latter case, the UE/MS may use any > appropriate QoS signaling mechanism as the NSIS > Initiator. If the Access > Gateway is acting as the Proxy NSIS initiator on behalf > of the UE/MS, > then it may have to do the mapping of parameters from radio access > specific QoS to IP QoS traffic parameters before > forwarding the request > to the NSIS Forwarder. > > The NSIS Forwarder is currently not part of the standard > 3G wireless > architecture. However, to achieve end-to-end QoS a NSIS > Forwarder is > needed such that the NSIS Initiators can request a QoS > connection to > the IP network. As in the previous example, the NSIS Forwarder > could manage a set of pre-provisioned resources in the IP network, > i.e. bandwidth pipes, and the NSIS Forwarder performs > per-flow admission > control into these pipes. In this way, a connection can > be made between > two 3G wireless access networks, and hence, end-to-end QoS can be > achieved. In this case the NSIS Initiator and NSIS Forwarder are > clearly two separate logical entities. The Access Gateway > or/and the > Edge Router in Fig.1 may contain the NSIS Forwarder functionality, > depending upon the placement of the NSIS Initiator as discussed in > scenario 2 in section 10.2. This use case clearly > illustrates the need > for an "NSIS" QoS signaling protocol between NSIS > Initiator and NSIS > Forwarder. An important application of such a protocol > may be its use > in the end-to-end establishment of a connection with specific QoS > characteristics between a mobile host and another party > (e.g. end host > or content server). > > > > -------------------------------------------------------------- > ------------------- > > -Kuntal > > > Brian Williams wrote: > > Hi Kuntal. > > I would suggest some small tweaking in the wording as follows (the > > changes are in the parts between the <>): > > > > 2) The IP signaling messages are initiated by the NSIS > initiator and > > interpreted by the NSIS Forwarder. The most efficient > placement of the > > NSIS Initiator and NSIS Forwarder has not been determined > in 3G wireless > > networks, but a few potential scenarios can be envisioned. The NSIS > > Initiator could be located at the End Host e.g. UE or MS > (triggered by > > applications), the Access Gateway or at a node that is not > directly on > > the data path, such as a policy server. The Access Gateway > could act as > > a proxy NSIS Initiator on behalf of the UE/MS or an End > Host. The Policy > > per-flow/aggregate > resources > respect to the session> within its QoS domain (e.g. the 3G wireless > > network) may act as a proxy NSIS Initiator for the UE/MS or > the Access > > Gateway. Depending on the placement of the NSIS Initiator, the NSIS > > Forwarder may be located at an appropriate point in the 3G wireless > > network. > > > > 10.3 An example scenario for a 3G wireless network > > > > The 3G wireless access scenario is shown in Figure 1. The > Proxy-Call > > State Control Function (P-CSCF) is the outbound SIP proxy > (only used in > > IMS). The Access Gateway is the egress router of the 3G > wireless domain > > and it connects the radio access network to the Edge Router > (ER) of the > > backbone IP network. > responsible for controlling bearer level resource > > allocations/de-allocations in relation to session level > services eg SIP. > > The Policy Decision Function may also control the Access > Gateway to open > > and close the gates and to configure per-flow policies, i.e. to > > authorize or forbid user traffic.> > > /brian > > > > Kuntal Chowdhury wrote: > > > >> Hi all, > >> Here is an attempt to generalize the scope of NSIS in 3G wireless > >> networks. The following is the suggested update/re-write > of section > >> 10.2 and 10.3. > >> > >> Issue Name: 7 > >> Submitter name: Louis-Nicolas Hamer and Kuntal Chowdhury > >> Submitter email address: nhamer@nortelnetworks.com > >> Date first submitted: 22/01/2003 > >> Reference: none > >> Document: draft-ietf-nsis-req-06.txt > >> Comment type: T > >> Priority: 2 > >> Section: 10.2 & 10.3 > >> > >> Proposed text: > >> > >> 10.2 3G Wireless Networks > >> > >> In this scenario, the user is using the packet services of a 3rd > >> generation wireless system (e.g. 3GPP/UMTS, 3GPP2/cdma2000). The > >> region between the End Host and the Edge Node (Edge Router) > >> connecting the wireless network to another QoS domain > is considered > >> to be a single QoS domain. > >> > >> The issues in such an environment regarding QoS include: > >> > >> 1) 3G wireless networks provide their own QoS technology with > >> specialized parameters to co-ordinate the QoS provided > by both the > >> radio access and wired access networks. Provisioning of QoS > >> technologies within a 3G wireless network can be > described mainly > >> in terms of calling bearer classes, service options and service > >> instances. These QoS technologies need to be invoked > with suitable > >> parameters when higher layers trigger a request for > QoS. Therefore > >> these involve mapping of the requested higher layer QoS > parameters > >> onto specific bearer classes or service instances. The > request for > >> allocation of resources might be triggered by signaling > at the IP > >> level that passes across the wireless system, and possibly other > >> QoS domains. Typically, wireless network specific messages are > >> invoked to setup the underlying bearer classes or > service instances > >> in parallel with the IP layer QoS negotiation, to > allocate resources > >> within the radio access network. > >> > >> 2) The IP signaling messages are initiated by the NSIS > initiator and > >> interpreted by the NSIS Forwarder. The most efficient > placement of the > >> NSIS Initiator and NSIS Forwarder has not been determined in 3G > >> wireless > >> networks, but a few potential scenarios can be > envisioned. The NSIS > >> Initiator could be located at the End Host e.g. UE or > MS (triggered by > >> applications), the Access Gateway or at a node that is > not directly on > >> the data path, such as a policy server. The Access > Gateway could > >> act as > >> a proxy NSIS Initiator on behalf of the UE/MS or an End > Host. The > >> Policy > >> Server that manages per-flow/aggregate resources within > its QoS domain > >> (e.g. the 3G wireless network) may act as a proxy NSIS > Initiator > >> for the > >> UE/MS or the Access Gateway. Depending on the placement > of the NSIS > >> Initiator, the NSIS Forwarder may be located at an appropriate > >> point in the 3G wireless network. > >> > >> 3) The need for re-negotation of the resource needs in a new 3G > >> wireless > >> domain due to UE/MS mobility. In this case the NSIS > Initiators and the > >> NSIS Forwarders will have to detect mobility events and trigger > >> re-negotiation of resources autonomously. > >> > >> > >> 10.3 An example scenario for a 3G wireless network > >> > >> The 3G wireless access scenario is shown in Figure 1. > The Proxy-Call > >> State Control Function (P-CSCF) is the outbound SIP > proxy (only used > >> in IMS). The Access Gateway is the egress router of the > 3G wireless > >> domain and it connects the radio access network to the > Edge Router > >> (ER) of the backbone IP network. The Policy Server is the entity > >> responsible for managing the resource > allocations/de-allocations in > >> the 3G wireless domain. It is also responsible for the > policy-based > >> control of the end-user service. The Policy Server also > controls the > >> Access Gateway to open and close the gates and to > configure per-flow > >> policies, i.e. to authorize or forbid user traffic. The > P-CSCF (only > >> used in IMS) and the Access Gateway communicate with the Policy > >> Server, > >> for network resource allocation/de-allocation > decisions. The User > >> Equipment (UE) or the Mobile Station (MS) consists of a Mobile > >> Terminal > >> (MT) and Terminal Equipment (TE), e.g. a laptop. > >> > >> > >> +--------+ > >> +--------->| P-CSCF |-------> SIP signaling > >> / +--------+ > >> / SIP | > >> | +--------+ > >> | | Policy | +----------------+ > >> | | Server |<------->| NSIS > Forwarder |<---> > >> | +--------+ +----------------+ > >> | | ^ > >> | |COPS | > >> | | | > >> +------+ +---------+ | > >> | UE/MS|----------| Access |<-----------+ +----+ > >> +------+ | Gateway |----------------------| ER | > >> +---------+ +----+ > >> > >> Figure 1: 3G wireless access scenario > >> > >> The Policy Server has all the required QoS information > for per-flow > >> or aggregate admission control in 3G wireless networks. > It receives > >> resource allocation/de-allocation requests from the > P-CSCF and/or > >> Access Gateway etc. and responds with policy decisions. > Hence the > >> Policy Server may be a candidate entity to host the > functionality > >> of the NSIS Initiator, initiating the "NSIS" QoS > signaling towards the > >> core IP network. On the other hand, the UE/MS may act > as the NSIS > >> Initiator or the Access Gateway may act as a Proxy NSIS > Initiator > >> on behalf of the UE/MS. In the former case, the > P-CSCF/Policy Server > >> has to do the mapping from codec types and media > descriptors (derived > >> from SIP/SDP signaling) to IP traffic descriptor. In the latter > >> case, the UE/MS may use any appropriate QoS signaling > mechanism as the > >> NSIS Initiator. If the Access Gateway is acting as the Proxy > >> NSIS initiator on behalf of the UE/MS, then it may have > to do the > >> mapping of parameters from radio access specific QoS to IP QoS > >> traffic parameters before forwarding the request to the NSIS > >> Forwarder. > >> > >> The NSIS Forwarder is currently not part of the > standard 3G wireless > >> architecture. However, to achieve end-to-end QoS a NSIS > Forwarder is > >> needed such that the NSIS Initiators can request a QoS > connection to > >> the IP network. As in the previous example, the NSIS Forwarder > >> could manage a set of pre-provisioned resources in the > IP network, > >> i.e. bandwidth pipes, and the NSIS Forwarder performs per-flow > >> admission > >> control into these pipes. In this way, a connection can be made > >> between > >> two 3G wireless access networks, and hence, end-to-end > QoS can be > >> achieved. In this case the NSIS Initiator and NSIS Forwarder are > >> clearly two separate logical entities. The Access > Gateway or/and the > >> Edge Router in Fig.1 may contain the NSIS Forwarder > functionality, > >> depending upon the placement of the NSIS Initiator as > discussed in > >> scenario 2 in section 10.2. This use case clearly > illustrates the need > >> for an "NSIS" QoS signaling protocol between NSIS > Initiator and NSIS > >> Forwarder. An important application of such a protocol > may be its use > >> in the end-to-end establishment of a connection with > specific QoS > >> characteristics between a mobile host and another party > (e.g. end host > >> or content server). > >> > >> > >> > >> > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >> > > > > > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Feb 2 08:58:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05711 for ; Sun, 2 Feb 2003 08:58:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h12E37032559 for nsis-archive@odin.ietf.org; Sun, 2 Feb 2003 09:03:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h12E34J32551; Sun, 2 Feb 2003 09:03:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h12E2dJ32522 for ; Sun, 2 Feb 2003 09:02:39 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05699 for ; Sun, 2 Feb 2003 08:57:37 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h12E08k27927 for ; Sun, 2 Feb 2003 16:00:09 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 2 Feb 2003 16:01:12 +0200 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 2 Feb 2003 16:01:12 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 2 Feb 2003 16:01:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] layer split summary? opinions? Date: Sun, 2 Feb 2003 16:01:11 +0200 Message-ID: Thread-Topic: [NSIS] layer split summary? opinions? Thread-Index: AcLJNa8ApxhgN3eBRmWIEj3pCtNNGABjcPgw To: , Cc: , X-OriginalArrivalTime: 02 Feb 2003 14:01:12.0235 (UTC) FILETIME=[8B2F1FB0:01C2CAC3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h12E2dJ32523 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, > > Features such as segmentation, congestion > > control, non duplication of signaling messages, etc. > > are specific and needed for some NSLP type, > > but not for all NSLP types. > > Can you identify the types that need it and the types that don't? > > Are you advocating that NSLP become a full-fledged transport protocol > for 'some' NSLP types, essentially an application-layer TCP or SCTP? It is out of scope to develop a full-fledged transport protocol here. br, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Feb 2 09:27:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06203 for ; Sun, 2 Feb 2003 09:27:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h12EWKW01798 for nsis-archive@odin.ietf.org; Sun, 2 Feb 2003 09:32:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h12EWHJ01778; Sun, 2 Feb 2003 09:32:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h12ENPJ01448 for ; Sun, 2 Feb 2003 09:23:25 -0500 Received: from mtiwmhc11.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06011 for ; Sun, 2 Feb 2003 09:18:22 -0500 (EST) Received: from cs.columbia.edu (80.indianapolis-19rh16rt.in.dial-access.att.net[12.85.5.80]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003020214215811100k0tsve>; Sun, 2 Feb 2003 14:21:58 +0000 Message-ID: <3E3D28E7.9010101@cs.columbia.edu> Date: Sun, 02 Feb 2003 09:19:19 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: nsis@ietf.org Subject: Re: [NSIS] layer split summary? opinions? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > 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. I believe the RSVP effort already came to that conclusion, albeit in a kludge added later. (I feel free to label it as such since I'm the co-author of the original paper suggesting the fix :-)). I don't see how you can have a signaling protocol that does not offer reliability, and on short timescales. As far as I can tell, there are no deployed examples of 'unreliable' signaling protocols in other domains (SS7, ATM). Now, it is possible to rely purely on end-to-end reliability, but this has serious design problems, in terms of efficiency. (Among other issues, the RTT estimate is likely going to be much better among NSIS peers than among some random pair of endpoints that haven't met each other before.) Let me turn this question around: Where would you consider a system sufficient that purely relies on soft-state timeout and retransmision? Henning _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Feb 2 11:50:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08462 for ; Sun, 2 Feb 2003 11:50:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h12GtTP09875 for nsis-archive@odin.ietf.org; Sun, 2 Feb 2003 11:55:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h12GtOJ09868; Sun, 2 Feb 2003 11:55:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h12GsnJ09837 for ; Sun, 2 Feb 2003 11:54:49 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08440 for ; Sun, 2 Feb 2003 11:49:44 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Sun, 2 Feb 2003 16:53:18 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF6745@rsys002a.roke.co.uk> From: "Hancock, Robert" To: john.loughney@nokia.com, hgs@cs.columbia.edu, Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org Subject: ntlp terminology confusions (was: RE: [NSIS] layer split summary? opinions?) Date: Sun, 2 Feb 2003 16:53:18 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , 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: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 02 February 2003 13:51 > To: hgs@cs.columbia.edu; Georgios.Karagiannis@eln.ericsson.se > Cc: nsis@ietf.org > 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 > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Feb 3 03:05:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00581 for ; Mon, 3 Feb 2003 03:05:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h138Ap400677 for nsis-archive@odin.ietf.org; Mon, 3 Feb 2003 03:10:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h138AlJ00669; Mon, 3 Feb 2003 03:10:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1389sJ00634 for ; Mon, 3 Feb 2003 03:09:54 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00575 for ; Mon, 3 Feb 2003 03:04:30 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 3 Feb 2003 09:07:55 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <1GF15TP8>; Mon, 3 Feb 2003 09:07:53 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE23B306@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: nsis@ietf.org Subject: AW: [NSIS] layer split summary? opinions? Date: Mon, 3 Feb 2003 09:07:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , John, as a provider representative I fully support Henning's view. Regards, Rudiger | I don't see how you can have a signaling protocol that does not offer | reliability, and on short timescales. As far as I can tell, | there are no deployed examples of 'unreliable' signaling protocols in | other domains (SS7, ATM). | | Now, it is possible to rely purely on end-to-end reliability, | but this has serious design problems, in terms of efficiency. | (Among other issues, the RTT estimate is likely going to be | much better among NSIS peers than among some random pair of | endpoints that haven't met each other before.) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Feb 3 03:47:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01009 for ; Mon, 3 Feb 2003 03:47:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h138qE302956 for nsis-archive@odin.ietf.org; Mon, 3 Feb 2003 03:52:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h138qAJ02949; Mon, 3 Feb 2003 03:52:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h138pGJ02908 for ; Mon, 3 Feb 2003 03:51:16 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00985 for ; Mon, 3 Feb 2003 03:45:51 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h138nRAv029241; Mon, 3 Feb 2003 09:49:27 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DY5SZXGR; Mon, 3 Feb 2003 09:49:27 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Feb 2003 09:40:05 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB89D@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 42e09cf4 9ffcebbb 908facde 00000138 From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" Cc: nsis@ietf.org Subject: RE: [NSIS] layer split summary? opinions? Date: Mon, 3 Feb 2003 09:50:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi John I agree with your view! Best Regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: zondag 2 februari 2003 14:51 To: hgs@cs.columbia.edu; Georgios.Karagiannis@eln.ericsson.se Cc: nsis@ietf.org 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 nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Feb 3 15:40:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20926 for ; Mon, 3 Feb 2003 15:40:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h13Kjbw24199 for nsis-archive@odin.ietf.org; Mon, 3 Feb 2003 15:45:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KjXJ24192; Mon, 3 Feb 2003 15:45:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KipJ24094 for ; Mon, 3 Feb 2003 15:44:51 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20862 for ; Mon, 3 Feb 2003 15:39:12 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h13KgcY0011348 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 3 Feb 2003 15:42:43 -0500 (EST) Message-ID: <3E3ED458.8070609@cs.columbia.edu> Date: Mon, 03 Feb 2003 15:43:04 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: john.loughney@nokia.com, Georgios.Karagiannis@eln.ericsson.se, nsis@ietf.org Subject: Re: ntlp terminology confusions (was: RE: [NSIS] layer split summary? opinions?) References: <76C92FBBFB58D411AE760090271ED41805DF6745@rsys002a.roke.co.uk> In-Reply-To: <76C92FBBFB58D411AE760090271ED41805DF6745@rsys002a.roke.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit 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. Hancock, Robert wrote: > 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. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Feb 3 23:20:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29618 for ; Mon, 3 Feb 2003 23:20:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h144Pe016135 for nsis-archive@odin.ietf.org; Mon, 3 Feb 2003 23:25:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h144PZJ16128; Mon, 3 Feb 2003 23:25:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13JE0J17211 for ; Mon, 3 Feb 2003 14:14:00 -0500 Received: from c000.snv.cp.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17765 for ; Mon, 3 Feb 2003 14:08:21 -0500 (EST) Received: (cpmta 16383 invoked from network); 3 Feb 2003 11:11:56 -0800 Received: from 192.150.187.41 (HELO icsi.berkeley.edu) by smtp.wehrle.com (209.228.32.64) with SMTP; 3 Feb 2003 11:11:56 -0800 X-Sent: 3 Feb 2003 19:11:56 GMT Message-ID: <3E3EBEFA.6080408@icsi.berkeley.edu> Date: Mon, 03 Feb 2003 11:11:54 -0800 From: Klaus Wehrle Organization: International Computer Science Institute User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021223 X-Accept-Language: de-de, en-us, en MIME-Version: 1.0 To: Ion Stoica , Kevin Jeffay Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] CFP: IWQoS 2003 - Dealine approaching - Feb. 14, 2003 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit *CALL FOR PAPERS* ELEVENTH INTERNATIONAL WORKSHOP on QUALITY of SERVICE (IWQoS) http://iwqos03.cs.berkeley.edu/ June 2-4, 2003 Doubletree Hotel Monterey, California Supported by technical co-sponsorship by/in-cooperation with IEEE Communications Society, ACM SIGCOMM and ACM SIGMOBILE (approval pending). Important dates: ---------------- Paper deadline: *February 14, 2003* Notification of acceptance: March 24, 2003 Final paper due: April 8, 2003 IWQoS is a successful series of workshops providing an international forum for the presentation and discussion of new research and ideas on quality of service (QoS). The goal of the workshop is to bring together researchers, developers, and practitioners working in this area to discuss recent and innovative results, and identify future directions and challenges, in developing practical systems where predictable and controlled performance is a central requirement. Papers are solicited on all aspects of architecture, algorithm, and protocol design for systems in which QoS requirements are important. In addition to traditional IWQoS topics such as service guarantees and admission control, papers offering research contributions related to robustness, resilience, security, and predictability in networking and distributed systems are particularly solicited. Topics of interest include, but are not limited to: * Scalable QoS architectures * Analytical and simulation models for QoS * QoS control for middleware * QoS-aware programming models and languages * QoS issues in overlay and peer-to-peer networks * QoS issues in ad-hoc networks * Robust and resilient systems * Content delivery networks with service guarantees * Service assurances in wireless and mobile environments * QoS support for information appliances * Modeling user and application QoS requirements * Charging, accounting, and pricing for QoS * Experiences with QoS (measurements, tests, evaluations) IWQoS aims to allow rapid dissemination of research results and to provide fast turnaround. The deadline for papers is therefore as close to the conference as the publishers allow. In the past the workshop has been cross-disciplinary, well focused, with the emphasis on innovation. As a result, a considerable amount of time is devoted to informal discussion. Submission instructions are available at: http://iwqos03.cs.berkeley.edu/ Co-Chairs: ---------- Kevin Jeffay, University of North Carolina Ion Stoica, University of California at Berkeley Publicity Chair: --------------- Klaus Wehrle, ICSI/ICIR Berkeley IWQoS Steering Committee: ------------------------- Thomas Gross, ETH Zurich Jorg Liebeherr, University of Virginia David Hutchison, Lancaster University Peter Steenkiste, CMU Ralf Steinmetz, Darmstadt University of Technology Lars Wolf, University of Braunschweig Hui Zhang, CMU and Turin Networks Program committee: --------------------------------- Nina Bhatti, University of Arizona Andrew T.Campbell, Columbia University Anna Charny, Cisco Systems John Chuang, University of California, Berkeley Rene Cruz, University of California, San Diego Constantinos Dovrolis, Georgia Tech Anja Feldmann, Technical University Munich Victor Firoiu, Nortel Networks Thomas Gross, ETH Zurich David Hutchison, Lancaster University Shiv Kalyanaraman, Rensselaer Polytech Institute, NY Dina Katabi, MIT Jasleen Kaur, University of North Carolina Srinivasan Keshav, Ensim Edward Knightly, Rice University Jorg Liebeherr, University of Virginia Jane Liu, Microsoft Nick McKeown, Stanford University Marco Mellia, Politecnico di Torino Klara Nahrstedt, University of Illinois Abhay Parekh, ICSI/ICIR Berkeley Balaji Prabhakar, Stanford University Raj Rajkumar, CMU Peter Steenkiste, CMU Harrick Vin, University of Texas Klaus Wehrle, ICSI/ICIR Berkeley John Wroclawski, MIT Hui Zhang, CMU Zhi-Li Zhang, University of Minnesota Further General Information =========================== http://iwqos03.cs.berkeley.edu/ -- Klaus Wehrle International Computer Science Institute (ICSI) 1947 Center Street, Berkeley, CA, 94704-1198, USA http://www.icsi.berkeley.edu/~wehrle _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 01:06:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01645 for ; Tue, 4 Feb 2003 01:06:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h146C1r22206 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 01:12:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h146BwJ22192; Tue, 4 Feb 2003 01:11:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1468oJ22088 for ; Tue, 4 Feb 2003 01:08:50 -0500 Received: from rly-ip03.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01592 for ; Tue, 4 Feb 2003 01:03:00 -0500 (EST) Received: from logs-mtc-ta.proxy.aol.com (logs-mtc-ta.proxy.aol.com [64.12.105.5]) by rly-ip03.mx.aol.com (v89.10) with ESMTP id RELAYIN2-0204010548; Tue, 04 Feb 2003 01:05:48 1900 Received: from cs.columbia.edu (ACAAE05A.ipt.aol.com [172.170.224.90]) by logs-mtc-ta.proxy.aol.com (8.12.6/8.12.6) with ESMTP id h1464DmC329784; Tue, 4 Feb 2003 01:04:14 -0500 (EST) Message-ID: <3E3F57E1.1050703@cs.columbia.edu> Date: Mon, 03 Feb 2003 22:04:17 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] layer split summary? opinions? References: <3E3D28E7.9010101@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Apparently-From: Pingpan999@aol.com Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: >> 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. > > > I believe the RSVP effort already came to that conclusion, albeit in a > kludge added later. (I feel free to label it as such since I'm the > co-author of the original paper suggesting the fix :-)). > Henning, As the other co-author of the original paper to suggest the kludge, and the developer of getting it deployed, you are right - RSVP transport layer needs a lot of help. And it is more than a reliability problem. Come to think of it, we should have suggested to use TCP. :-) - Ping > I don't see how you can have a signaling protocol that does not offer > reliability, and on short timescales. As far as I can tell, there are no > deployed examples of 'unreliable' signaling protocols in other domains > (SS7, ATM). > > Now, it is possible to rely purely on end-to-end reliability, but this > has serious design problems, in terms of efficiency. (Among other > issues, the RTT estimate is likely going to be much better among NSIS > peers than among some random pair of endpoints that haven't met each > other before.) > > Let me turn this question around: Where would you consider a system > sufficient that purely relies on soft-state timeout and retransmision? > > Henning > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 01:34:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02174 for ; Tue, 4 Feb 2003 01:34:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h146dPn23722 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 01:39:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h146dMJ23715; Tue, 4 Feb 2003 01:39:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h146aqJ22972 for ; Tue, 4 Feb 2003 01:36:52 -0500 Received: from hawk.cs.ucla.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02130 for ; Tue, 4 Feb 2003 01:31:01 -0500 (EST) Received: from [192.168.0.103] (user-1121cqk.dsl.mindspring.com [66.32.179.84]) by hawk.cs.ucla.edu (8.11.6+Sun/8.11.6/UCLACS-5.2) with ESMTP id h146YBj23570; Mon, 3 Feb 2003 22:34:11 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 03 Feb 2003 22:34:09 -0800 Subject: Re: [NSIS] layer split summary? opinions? From: Lixia Zhang To: Ping Pan , Henning Schulzrinne CC: , Message-ID: In-Reply-To: <3E3F57E1.1050703@cs.columbia.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Henning Schulzrinne wrote: >>> 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. >> >> >> I believe the RSVP effort already came to that conclusion, albeit in a >> kludge added later. (I feel free to label it as such since I'm the >> co-author of the original paper suggesting the fix :-)). >> > > Henning, > > As the other co-author of the original paper to suggest the kludge, and > the developer of getting it deployed, you are right - RSVP transport > layer needs a lot of help. And it is more than a reliability problem. > Come to think of it, we should have suggested to use TCP. :-) > > - Ping No. Pls consider separating two different concepts: - a soft-state protocol with ACK for each message; and - a reliable transport protocol underneath RSVP. They are very different. In a later paper (in ICNP'99 I believe) we stated that it is a good enhancement to add ACK to RSVP. But I personally consider it INfeasible to put TCP underneath. Lixia (if someone here runs BGP: how well has that been working) >> I don't see how you can have a signaling protocol that does not offer >> reliability, and on short timescales. As far as I can tell, there are no >> deployed examples of 'unreliable' signaling protocols in other domains >> (SS7, ATM). >> >> Now, it is possible to rely purely on end-to-end reliability, but this >> has serious design problems, in terms of efficiency. (Among other >> issues, the RTT estimate is likely going to be much better among NSIS >> peers than among some random pair of endpoints that haven't met each >> other before.) >> >> Let me turn this question around: Where would you consider a system >> sufficient that purely relies on soft-state timeout and retransmision? >> >> Henning >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 01:55:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02517 for ; Tue, 4 Feb 2003 01:55:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1471Gb24590 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 02:01:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1471CJ24579; Tue, 4 Feb 2003 02:01:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h146w9J24431 for ; Tue, 4 Feb 2003 01:58:09 -0500 Received: from fig.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02500 for ; Tue, 4 Feb 2003 01:52:18 -0500 (EST) Received: from fig.isi.edu (localhost.localdomain [127.0.0.1]) by fig.isi.edu (8.12.5/8.12.5) with ESMTP id h146v8eO020794; Mon, 3 Feb 2003 22:57:08 -0800 Received: from localhost (berson@localhost) by fig.isi.edu (8.12.5/8.12.5/Submit) with ESMTP id h146v8RO020790; Mon, 3 Feb 2003 22:57:08 -0800 X-Authentication-Warning: fig.isi.edu: berson owned process doing -bs Date: Mon, 3 Feb 2003 22:57:08 -0800 (PST) From: Steven Berson To: Ping Pan cc: Henning Schulzrinne , , Subject: Re: [NSIS] layer split summary? opinions? In-Reply-To: <3E3F57E1.1050703@cs.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Ping, et al, Before we make any hasty decisions, let's reconsider why TCP (etc) was not used in RSVP. First of all, TCP has a lot of overhead (reliable delivery, in-order delivery, congestion control) not all of which is really needed in RSVP. Second, TCP does not support multicast which was a feature in RSVP. Third, you don't necessarily know who your RSVP neighbor is, so it is not clear who to open the TCP connection to. I think that having some form of reliable transport as (at least) an option is reasonable. But I think we need to be clear about exactly what features are desired and what the tradeoffs are. Then we can make a good decision about mechanisms. Regards, Steve On Mon, 3 Feb 2003, Ping Pan wrote: > Henning Schulzrinne wrote: > >> 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. > > > > > > I believe the RSVP effort already came to that conclusion, albeit in a > > kludge added later. (I feel free to label it as such since I'm the > > co-author of the original paper suggesting the fix :-)). > > > > Henning, > > As the other co-author of the original paper to suggest the kludge, and > the developer of getting it deployed, you are right - RSVP transport > layer needs a lot of help. And it is more than a reliability problem. > Come to think of it, we should have suggested to use TCP. :-) > > - Ping > > > I don't see how you can have a signaling protocol that does not offer > > reliability, and on short timescales. As far as I can tell, there are no > > deployed examples of 'unreliable' signaling protocols in other domains > > (SS7, ATM). > > > > Now, it is possible to rely purely on end-to-end reliability, but this > > has serious design problems, in terms of efficiency. (Among other > > issues, the RTT estimate is likely going to be much better among NSIS > > peers than among some random pair of endpoints that haven't met each > > other before.) > > > > Let me turn this question around: Where would you consider a system > > sufficient that purely relies on soft-state timeout and retransmision? > > > > Henning > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 02:55:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13269 for ; Tue, 4 Feb 2003 02:55:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1480SB05985 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 03:00:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1480PJ05978; Tue, 4 Feb 2003 03:00:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h147wAJ05870 for ; Tue, 4 Feb 2003 02:58:10 -0500 Received: from ns.sait.samsung.co.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13238 for ; Tue, 4 Feb 2003 02:52:16 -0500 (EST) Received: from sait1gc9bc522b (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.1/8.12.1) with SMTP id h147srHS025422; Tue, 4 Feb 2003 16:54:59 +0900 (KST) From: "Sung Hycuk Lee" To: "Steven Berson" , "Ping Pan" Cc: "Henning Schulzrinne" , , Subject: RE: [NSIS] layer split summary? opinions? Date: Tue, 4 Feb 2003 16:55:17 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h147wAJ05871 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Dear all, ***************************************************************************************** Ping, et al, Before we make any hasty decisions, let's reconsider why TCP (etc) was not used in RSVP. First of all, TCP has a lot of overhead (reliable delivery, in-order delivery, congestion control) not all of which is really needed in RSVP. Second, TCP does not support multicast which was a feature in RSVP. Third, you don't necessarily know who your RSVP neighbor is, so it is not clear who to open the TCP connection to. I think that having some form of reliable transport as (at least) an option is reasonable. But I think we need to be clear about exactly what features are desired and what the tradeoffs are. Then we can make a good decision about mechanisms. Regards, Steve ************************************************************************************** I agree with your opions (Steve). The goal of NSIS WG is to make a lightweight signaling (xRSVP), so there are a lot of overhead if xRSVP using TCP is used in mobile (access) envrionments. Regards, Sung Hyuck Lee -************************************************************************************* On Mon, 3 Feb 2003, Ping Pan wrote: > Henning Schulzrinne wrote: > >> 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. > > > > > > I believe the RSVP effort already came to that conclusion, albeit in a > > kludge added later. (I feel free to label it as such since I'm the > > co-author of the original paper suggesting the fix :-)). > > > > Henning, > > As the other co-author of the original paper to suggest the kludge, and > the developer of getting it deployed, you are right - RSVP transport > layer needs a lot of help. And it is more than a reliability problem. > Come to think of it, we should have suggested to use TCP. :-) > > - Ping > > > I don't see how you can have a signaling protocol that does not offer > > reliability, and on short timescales. As far as I can tell, there are no > > deployed examples of 'unreliable' signaling protocols in other domains > > (SS7, ATM). > > > > Now, it is possible to rely purely on end-to-end reliability, but this > > has serious design problems, in terms of efficiency. (Among other > > issues, the RTT estimate is likely going to be much better among NSIS > > peers than among some random pair of endpoints that haven't met each > > other before.) > > > > Let me turn this question around: Where would you consider a system > > sufficient that purely relies on soft-state timeout and retransmision? > > > > Henning > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 06:09:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15965 for ; Tue, 4 Feb 2003 06:09:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14BFMK17006 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 06:15:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BFHJ16998; Tue, 4 Feb 2003 06:15:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BEjJ16975 for ; Tue, 4 Feb 2003 06:14:45 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15947 for ; Tue, 4 Feb 2003 06:08:47 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h14BBI203901 for ; Tue, 4 Feb 2003 13:11:19 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 4 Feb 2003 13:12:24 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Feb 2003 13:12:24 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Feb 2003 13:12:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] layer split summary? opinions? Date: Tue, 4 Feb 2003 13:12:22 +0200 Message-ID: Thread-Topic: [NSIS] layer split summary? opinions? Thread-Index: AcLIsk3s42JKkGiNTD+HdLsIh90lywDi7aNQ To: , , Cc: X-OriginalArrivalTime: 04 Feb 2003 11:12:23.0632 (UTC) FILETIME=[4AE47500:01C2CC3E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h14BEjJ16976 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Robert, > 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 support this. However, regarding Lixia's mail earlier, we still need discussion what form of reliability is needed, for example TCP-style reliablity or soft-state refresh reliability. br, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 06:13:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16032 for ; Tue, 4 Feb 2003 06:13:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14BJ9t17189 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 06:19:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BJ6J17182; Tue, 4 Feb 2003 06:19:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BInJ17154 for ; Tue, 4 Feb 2003 06:18:49 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16024 for ; Tue, 4 Feb 2003 06:12:51 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h14BJ6m08169 for ; Tue, 4 Feb 2003 13:19:06 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 4 Feb 2003 13:16:28 +0200 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Feb 2003 13:16:27 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Feb 2003 13:16:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] layer split summary? opinions? Date: Tue, 4 Feb 2003 13:16:26 +0200 Message-ID: Thread-Topic: [NSIS] layer split summary? opinions? Thread-Index: AcLMF31cM68SeYDMQsqxlmUUsqnI3QAJwHGg To: , , Cc: X-OriginalArrivalTime: 04 Feb 2003 11:16:27.0046 (UTC) FILETIME=[DBFA7C60:01C2CC3E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h14BIoJ17155 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Lixia, A question to you: > Pls consider separating two different concepts: > - a soft-state protocol with ACK for each message; and > - a reliable transport protocol underneath RSVP. > > They are very different. > In a later paper (in ICNP'99 I believe) we stated that it is a good > enhancement to add ACK to RSVP. > But I personally consider it INfeasible to put TCP underneath. > > Lixia > > (if someone here runs BGP: how well has that been working) What is the feasibility of running an NSIS transport over TCP to certain entities, like edge routers / gateways, while supporting soft-state for routers & boxes between these edge routers / gateways? If needed, I could supply a diagram. I think that this is a model that some people are suggesting. However, I think we need to sort out the implications of this. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 06:15:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16083 for ; Tue, 4 Feb 2003 06:15:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14BL9R17294 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 06:21:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BL6J17287; Tue, 4 Feb 2003 06:21:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BK8J17253 for ; Tue, 4 Feb 2003 06:20:08 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16062 for ; Tue, 4 Feb 2003 06:14:10 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h14BGf207381 for ; Tue, 4 Feb 2003 13:16:41 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 4 Feb 2003 13:17:47 +0200 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Feb 2003 13:17:47 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Feb 2003 13:17:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] layer split summary? opinions? Date: Tue, 4 Feb 2003 13:17:46 +0200 Message-ID: Thread-Topic: [NSIS] layer split summary? opinions? Thread-Index: AcLMGn4OkUAiJ84AQ6qBP0ASlvTs3gAJGQiQ To: , Cc: , X-OriginalArrivalTime: 04 Feb 2003 11:17:46.0732 (UTC) FILETIME=[0B799AC0:01C2CC3F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h14BK8J17254 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Steve & Ping, > Ping, et al, > > Before we make any hasty decisions, let's reconsider why TCP (etc) was > not used in RSVP. First of all, TCP has a lot of overhead (reliable > delivery, in-order delivery, congestion control) not all of which is > really needed in RSVP. Second, TCP does not support multicast which > was a feature in RSVP. Third, you don't necessarily know who your > RSVP neighbor is, so it is not clear who to open the TCP connection > to. > > I think that having some form of reliable transport as (at least) an > option is reasonable. But I think we need to be clear about exactly > what features are desired and what the tradeoffs are. Then we can > make a good decision about mechanisms. It would be great to capture some of this material in the Analysis document. Would either one of you want to submit some text? I'm hoping that the Analysis doc could capture this so that it is useful when doing the protocol work. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 06:17:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16111 for ; Tue, 4 Feb 2003 06:17:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14BNAu17355 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 06:23:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BN6J17348; Tue, 4 Feb 2003 06:23:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BMaJ17319 for ; Tue, 4 Feb 2003 06:22:36 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16097 for ; Tue, 4 Feb 2003 06:16:38 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h14BMqm11893 for ; Tue, 4 Feb 2003 13:22:53 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 4 Feb 2003 13:20:13 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Feb 2003 13:20:13 +0200 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Feb 2003 13:20:12 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Feb 2003 13:20:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] layer split summary? opinions? Date: Tue, 4 Feb 2003 13:20:12 +0200 Message-ID: Thread-Topic: [NSIS] layer split summary? opinions? Thread-Index: AcLHpb1A8pP8BBHAT+e97597NO7ZuwEmXnvg To: , Cc: X-OriginalArrivalTime: 04 Feb 2003 11:20:12.0392 (UTC) FILETIME=[624B8E80:01C2CC3F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h14BMaJ17320 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Georgios, > 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. Perhaps some comments on why NTLP would not need other transport layer features not supported by RSVP would be helpful for us to understand. Have you made a determination on why others are not needed? John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 06:23:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16219 for ; Tue, 4 Feb 2003 06:23:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14BTFj17637 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 06:29:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BTCJ17628; Tue, 4 Feb 2003 06:29:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BSKJ17594 for ; Tue, 4 Feb 2003 06:28:20 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16198 for ; Tue, 4 Feb 2003 06:22:22 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h14BOs213129 for ; Tue, 4 Feb 2003 13:24:54 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 4 Feb 2003 13:25:59 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Feb 2003 13:25:58 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Feb 2003 13:25:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] layer split summary? opinions? Date: Tue, 4 Feb 2003 13:25:57 +0200 Message-ID: Thread-Topic: [NSIS] layer split summary? opinions? Thread-Index: AcLJDrj/NM5CxGNJQlG6HIUCL7KN8gDMPx/g To: , Cc: X-OriginalArrivalTime: 04 Feb 2003 11:25:58.0264 (UTC) FILETIME=[30736F80:01C2CC40] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h14BSKJ17595 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Georgios, > 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. So, let me just make sure I understand you. If NTLP could run over TCP, SCTP, UDP, DCCP or IP directly, it should not duplicate features found in those protocols, correct? If so, I agree 100%. Do you think it is OK if we define how NTLP could run over a well known transport protocol, or do you have any reservations (no pun intended) about which transport protocols could be supported? br, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 06:27:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16451 for ; Tue, 4 Feb 2003 06:27:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14BWXZ17858 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 06:32:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BWUJ17848; Tue, 4 Feb 2003 06:32:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BVdJ17776 for ; Tue, 4 Feb 2003 06:31:40 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16289 for ; Tue, 4 Feb 2003 06:25:41 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h14BSD215643 for ; Tue, 4 Feb 2003 13:28:13 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 4 Feb 2003 13:29:18 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Feb 2003 13:29:18 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Feb 2003 13:29:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] layer split summary? opinions? Date: Tue, 4 Feb 2003 13:29:17 +0200 Message-ID: Thread-Topic: [NSIS] layer split summary? opinions? Thread-Index: AcLJNazAx4ge9rr4QHqjHZE2ILShOQDCtOdw To: , Cc: , X-OriginalArrivalTime: 04 Feb 2003 11:29:18.0406 (UTC) FILETIME=[A7BEAE60:01C2CC40] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h14BVeJ17777 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Henning, > While SIP is not a network-layer reservation protocol, I think some of > the lessons learned there apply here as well. (While UDP will likely > remain part of the protocol, its sphere of use has been shrinking > continuously.) > > - MTU discovery and fragmentation is a pain. Even if you think that the > message is small enough to fit 'near' where you are, it might get bigger > along the way, as error indications, signatures and other things are > added. This makes it very different from a run-of-the-mill IP packet > that just gets its TTL bumped. Even if you can estimate the size of the > message you send, you don't always know how big the response > is going to be. > > - Even if you can reasonably assume that normal (QOS) signaling traffic > is low volume, with retries after failures, this is no longer > the case. > > - Wherever some notion of trust is involved, most systems talk to > relatively few other systems in practice, so that the setup overhead for > TCP is modest, removing one of the major TCP/SCTP problems that > motivated UDP in the case of application-layer signaling. > > - People like TLS. Yes, you can use IPsec, but once you talk to > implementors, nobody wants to rely on it being available and > configurable, given a choice. > > I'm sure there are other lessons and not all apply here, but we should, > I believe, look around more recent design efforts in the IETF as well. These are all good points, Jukka, do you think you could add this kind of text into the Analysis document? Henning, if you have any references to these kinds of experiences, I think that they'd be valuable to capture. cheers, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 06:57:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17871 for ; Tue, 4 Feb 2003 06:57:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14C3DO20419 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 07:03:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14C39J20411; Tue, 4 Feb 2003 07:03:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14BovJ19658 for ; Tue, 4 Feb 2003 06:50:57 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17267; Tue, 4 Feb 2003 06:44:59 -0500 (EST) Message-Id: <200302041144.GAA17267@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 04 Feb 2003 06:44:59 -0500 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-signalling-analysis-01.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Analysis of Existing Quality of Service Signaling Protocols Author(s) : J. Manner, X. Fu Filename : draft-ietf-nsis-signalling-analysis-01.txt Pages : 26 Date : 2003-2-3 This document presents a review of existing protocols for signalling the Quality of Service requirements of flows to nodes in an IP network. Protocols are reviewed independently and not compared against the NSIS requirements document nor to RSVP itself. The purpose is to learn from existing work and to avoid common misconceptions about the protocols. A further goal is to avoid to redesign ideas already implemented in another protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-signalling-analysis-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-signalling-analysis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-signalling-analysis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-3125527.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-signalling-analysis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-signalling-analysis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-3125527.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 08:35:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22008 for ; Tue, 4 Feb 2003 08:35:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14DeTf27803 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 08:40:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14DePJ27796; Tue, 4 Feb 2003 08:40:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14DdZJ27740 for ; Tue, 4 Feb 2003 08:39:35 -0500 Received: from brazilnut.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21973 for ; Tue, 4 Feb 2003 08:33:35 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h14DbBC4006314 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Feb 2003 08:37:12 -0500 (EST) Message-ID: <3E3FC21D.7070108@cs.columbia.edu> Date: Tue, 04 Feb 2003 08:37:33 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steven Berson CC: Ping Pan , john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] layer split summary? opinions? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Before we make any hasty decisions, let's reconsider why TCP (etc) was > not used in RSVP. First of all, TCP has a lot of overhead (reliable > delivery, in-order delivery, congestion control) not all of which is > really needed in RSVP. Second, TCP does not support multicast which A lot is being said about 'overhead'. Can somebody quantify this beyond just statements of opinion? My perception, based on measurements in other, related contexts, is that it has no impact whatsoever on signaling performance, compared to other operations. After all, we routinely build web servers that can handle thousands of operations a second. > was a feature in RSVP. Third, you don't necessarily know who your > RSVP neighbor is, so it is not clear who to open the TCP connection > to. The latter is a solvable problem. > > I think that having some form of reliable transport as (at least) an > option is reasonable. But I think we need to be clear about exactly > what features are desired and what the tradeoffs are. Then we can > make a good decision about mechanisms. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 08:39:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22318 for ; Tue, 4 Feb 2003 08:39:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14DjA127993 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 08:45:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14Dj4J27965; Tue, 4 Feb 2003 08:45:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14DiXJ27934 for ; Tue, 4 Feb 2003 08:44:33 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22227 for ; Tue, 4 Feb 2003 08:38:34 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h14Dg7kx008147 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Feb 2003 08:42:09 -0500 (EST) Message-ID: <3E3FC346.70500@cs.columbia.edu> Date: Tue, 04 Feb 2003 08:42:30 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sung Hycuk Lee CC: Steven Berson , Ping Pan , john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] layer split summary? opinions? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > The goal of NSIS WG is to make a lightweight signaling (xRSVP), > so there are a lot of overhead if xRSVP using TCP is used in mobile (access) envrionments. > I'm guessing that your mobile device has a web browser (HTTP), an email client (POP, IMAP, SMTP) and maybe even a SIP UA. How many queries a second does your web browser do? Compared to a signaling protocol? Which do you think will do better in your mobile environment: your already-tuned-for-mobility TCP stack that you need for HTTP, IMAP, SMTP and possibly SIP or RTSP or a let's-develop-a-new-transport protocol that we'll develop for this special purpose? Henning _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 09:11:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22944 for ; Tue, 4 Feb 2003 09:11:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14EHLb29512 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 09:17:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14EHGJ29505; Tue, 4 Feb 2003 09:17:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14EG8J29446 for ; Tue, 4 Feb 2003 09:16:08 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22898 for ; Tue, 4 Feb 2003 09:10:08 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h14EDhKV006732; Tue, 4 Feb 2003 15:13:44 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DY5JNSP0; Tue, 4 Feb 2003 15:13:12 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Feb 2003 15:06:26 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB8A5@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 00e43c2d 9ffcebbb a5ee123c 00000138 From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" Cc: nsis@ietf.org Subject: RE: [NSIS] layer split summary? opinions? Date: Tue, 4 Feb 2003 15:07:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi John >> So, let me just make sure I understand you. If NTLP could run over >> TCP, SCTP, UDP, DCCP or IP directly, it should not duplicate features >> found in those protocols, correct? Yes! >> If so, I agree 100%. >> Do you think it is OK if we define how NTLP could run over >> a well known transport protocol, >> or do you have any reservations (no pun intended) about which >> transport protocols could be supported? I am not in favor of mandating that NTLP will have to run over one well known transport protocol! It will, however, be interesting to describe (and not standardize) how NTLP could run over TCP, SCTP, UDP, DCCP or IP directly. Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 09:28:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23615 for ; Tue, 4 Feb 2003 09:28:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14EYFL30245 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 09:34:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14EYCJ30230; Tue, 4 Feb 2003 09:34:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14EXMJ30211 for ; Tue, 4 Feb 2003 09:33:22 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23576 for ; Tue, 4 Feb 2003 09:27:21 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h14EXYm24917 for ; Tue, 4 Feb 2003 16:33:35 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 4 Feb 2003 16:30:57 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Feb 2003 16:30:57 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Feb 2003 16:30:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] layer split summary? opinions? Date: Tue, 4 Feb 2003 16:30:56 +0200 Message-ID: Thread-Topic: [NSIS] layer split summary? opinions? Thread-Index: AcLMU01rusg4Q8YDSBWztAGtJYjHYwABmYMA To: , Cc: , , X-OriginalArrivalTime: 04 Feb 2003 14:30:57.0180 (UTC) FILETIME=[07EB9DC0:01C2CC5A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h14EXNJ30212 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, > > The goal of NSIS WG is to make a lightweight signaling (xRSVP), > > so there are a lot of overhead if xRSVP using TCP is used > in mobile (access) envrionments. > > > > I'm guessing that your mobile device has a web browser (HTTP), an email > client (POP, IMAP, SMTP) and maybe even a SIP UA. How many queries a > second does your web browser do? Compared to a signaling protocol? > > Which do you think will do better in your mobile environment: your > already-tuned-for-mobility TCP stack that you need for HTTP, IMAP, SMTP > and possibly SIP or RTSP or a let's-develop-a-new-transport protocol > that we'll develop for this special purpose? Just playing the devil's advocate, the problem with TCP on mobile phones isn't the stack, the resource usage or power - it is about the latency. GPRS and CDMAx1 both have very high RTTs. If a new TCP connection needs to be opened, then this will put a significant delay. However, this would be mitigated by multiplexing over a single TCP connection. In practice, we should see (in NSIS) how this could be done for a signaling protocol. br, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 09:30:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23667 for ; Tue, 4 Feb 2003 09:30:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14Ea7330379 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 09:36:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14Ea4J30374; Tue, 4 Feb 2003 09:36:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14EZmJ30331 for ; Tue, 4 Feb 2003 09:35:48 -0500 Received: from hawk.cs.ucla.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23648 for ; Tue, 4 Feb 2003 09:29:47 -0500 (EST) Received: from [192.168.0.103] (user-105nd9q.dialup.mindspring.com [64.91.181.58]) by hawk.cs.ucla.edu (8.11.6+Sun/8.11.6/UCLACS-5.2) with ESMTP id h14EXCj28191; Tue, 4 Feb 2003 06:33:13 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 04 Feb 2003 06:33:09 -0800 Subject: Re: [NSIS] layer split summary? opinions? From: Lixia Zhang To: CC: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Lixia, > > A question to you: > >> Pls consider separating two different concepts: >> - a soft-state protocol with ACK for each message; and >> - a reliable transport protocol underneath RSVP. >> >> They are very different. >> In a later paper (in ICNP'99 I believe) we stated that it is a good >> enhancement to add ACK to RSVP. >> But I personally consider it INfeasible to put TCP underneath. >> >> Lixia >> >> (if someone here runs BGP: how well has that been working) > > What is the feasibility of running an NSIS transport over TCP to > certain entities, like edge routers / gateways, while supporting > soft-state for routers & boxes between these edge routers / gateways? That'll need more time to explain than what I have in hand at this time (heading to airport in an hour) But briefly: the fundamental problem is mismatch of semantics/data framing in providing reliability. One simple example: - TCP offers reliable byte stream. - That's not what you need. A later signaling msg may replace an earlier one, yet you cannot take back the bytes that you have already passed to TCP. Another example: - TCP has this notion of connection - when TCP connection broke, what assumption would you make regarding the state at the other signalling party? currently BGP assumes all states were gone, and it ships another copy of that huge routing table of 118000 entries over again (bar the recent graceful restart, that does not handle all the cases anyway) And don't assume that TCP sessions between two signalling ends never break--if experience with BGP serves an example, it shows they do, and a lot more frequent than one would think > If needed, I could supply a diagram. I think that this is a model > that some people are suggesting. However, I think we need to > sort out the implications of this. > > John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 15:01:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02916 for ; Tue, 4 Feb 2003 15:01:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14K6gt19633 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 15:06:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14K6ZJ19626; Tue, 4 Feb 2003 15:06:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14K53J19582 for ; Tue, 4 Feb 2003 15:05:03 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02875 for ; Tue, 4 Feb 2003 14:58:56 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h14K2Wb27828; Tue, 4 Feb 2003 12:02:32 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id UAA07351; Tue, 4 Feb 2003 20:02:32 GMT Date: Tue, 4 Feb 2003 20:02:32 GMT Message-Id: <200302042002.UAA07351@gra.isi.edu> To: hgs@cs.columbia.edu Subject: Re: [NSIS] layer split summary? opinions? Cc: john.loughney@nokia.com, nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> A lot is being said about 'overhead'. Can somebody quantify this beyond *> just statements of opinion? My perception, based on measurements in *> other, related contexts, is that it has no impact whatsoever on *> signaling performance, compared to other operations. After all, we *> routinely build web servers that can handle thousands of operations a *> second. *> *> Henning, In support of your comment/question: Consider QoS signaling for one flow, and assume no packet loss. * A trigger message is sent from node A to neighbor node B, either in one NTLP message/TCP segment in one IP datagram, or in one NTLP message in one IP datagram. * Node B returns some sort of ACK message, either in as a TCP ACK segment in one IP datagram, or as one NTLP message in one IP datagram. Whether or not TCP is used, this elementary signaling action creates one IP datagram in each direction. Am I missing something here? If TCP is not used, the NTLP header can probably be smaller; it is not clear, but probably there is not much difference in header overhead. In any case, this overhead is probably trivial compared to the TLV encoding overhead in the NSLP layer. Of course, there is more to the story... maybe refresh messages don't need the reliable delivery that TCP would force on you (OTOH, maybe they do need it.) In case of packet losses, you have to retransmit with/without TCP, although TCP's retransmission mechanism probably works better. TCP gives you congestion control when you need it -- which you may well, when a route change forces a flood of signaling updates. OTOH, maybe what you REALLY want for signaling is not TCP but XCP (see Kitabi paper at SIGCOMM 2002). A major point of the 2-layer model is to modularize functionality so you can adapt to later developments in the transport area. After all, the NSIS protocol needs to be able to handle signaling applications that you have not thought of yet, as well as today's signaling applications. Finally, in an environment where TCP is "too high overhead", I suspect that any general-purpose Internet signaling protocol like NSIS is also too high overhead. We do not have to use a back-hoe for spading our gardens. I think that the NSIS task is to design the Internet signaling back-hoe. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 15:09:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03066 for ; Tue, 4 Feb 2003 15:09:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14KFAL20544 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 15:15:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14KF6J20537; Tue, 4 Feb 2003 15:15:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14KEXJ20512 for ; Tue, 4 Feb 2003 15:14:33 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03060 for ; Tue, 4 Feb 2003 15:08:25 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h14KC2b02738; Tue, 4 Feb 2003 12:12:02 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id UAA07360; Tue, 4 Feb 2003 20:12:02 GMT Date: Tue, 4 Feb 2003 20:12:02 GMT Message-Id: <200302042012.UAA07360@gra.isi.edu> To: john.loughney@nokia.com, lixia@cs.ucla.edu Subject: Re: [NSIS] layer split summary? opinions? Cc: nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> Another example: *> - TCP has this notion of connection *> - when TCP connection broke, what assumption would you make regarding *> the state at the other signalling party? *> currently BGP assumes all states were gone, and it ships another *> copy of that huge routing table of 118000 entries over again *> (bar the recent graceful restart, that does not handle all *> the cases anyway) *> Lixia, State recovery is indeed a serious design problem. In RSVP we simply assumed that the normal refrseshes would restore state in a neigbhbor node that had crashed with loss of state and then restarted. So, after an average of 15 seconds, all reservations would be restored. Is this fast enough? Perhaps not. RFC 2961 (I think) added a handshake mechanism so a node would know that its neighbor had crashed and recovered -- an epoch number. When the epoch number changes, a node can then flood (and flood is probably the right word) all its state to the newly recovered node. [The TCP connection implies equivalent synchronization.] But this is exactly the 118000 entry case of BGP, and I don't see any logical alternative. Bob _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 15:27:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03430 for ; Tue, 4 Feb 2003 15:27:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14KXGs21208 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 15:33:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14KXDJ21186; Tue, 4 Feb 2003 15:33:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14KWcJ21149 for ; Tue, 4 Feb 2003 15:32:38 -0500 Received: from hawk.cs.ucla.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03403 for ; Tue, 4 Feb 2003 15:26:30 -0500 (EST) Received: from [131.179.33.142] (Cs-33-142.CS.UCLA.EDU [131.179.33.142]) by hawk.cs.ucla.edu (8.11.6+Sun/8.11.6/UCLACS-5.2) with ESMTP id h14KU4j02125; Tue, 4 Feb 2003 12:30:04 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 04 Feb 2003 12:28:15 -0800 Subject: Re: [NSIS] layer split summary? opinions? From: Lixia Zhang To: CC: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >> A question to you: >> >>> Pls consider separating two different concepts: >>> - a soft-state protocol with ACK for each message; and >>> - a reliable transport protocol underneath RSVP. >>> >>> They are very different. >>> In a later paper (in ICNP'99 I believe) we stated that it is a good >>> enhancement to add ACK to RSVP. >>> But I personally consider it INfeasible to put TCP underneath. >>> >>> Lixia >>> >>> (if someone here runs BGP: how well has that been working) >> >> What is the feasibility of running an NSIS transport over TCP to >> certain entities, like edge routers / gateways, while supporting >> soft-state for routers & boxes between these edge routers / gateways? > > That'll need more time to explain than what I have in hand at this time > (heading to airport in an hour) > > But briefly: the fundamental problem is mismatch of semantics/data framing > in providing reliability. > > One simple example: > - TCP offers reliable byte stream. > - That's not what you need. A later signaling msg may replace an > earlier one, yet you cannot take back the bytes that you have > already passed to TCP. > > Another example: > - TCP has this notion of connection > - when TCP connection broke, what assumption would you make regarding > the state at the other signalling party? > currently BGP assumes all states were gone, and it ships another > copy of that huge routing table of 118000 entries over again > (bar the recent graceful restart, that does not handle all > the cases anyway) If I may add a 3rd example: consider route changes (at least BGP doesn't have that problem) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 15:27:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03443 for ; Tue, 4 Feb 2003 15:27:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14KXIg21221 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 15:33:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14KXEJ21201; Tue, 4 Feb 2003 15:33:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14KWgJ21153 for ; Tue, 4 Feb 2003 15:32:42 -0500 Received: from hawk.cs.ucla.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03406 for ; Tue, 4 Feb 2003 15:26:34 -0500 (EST) Received: from [131.179.33.142] (Cs-33-142.CS.UCLA.EDU [131.179.33.142]) by hawk.cs.ucla.edu (8.11.6+Sun/8.11.6/UCLACS-5.2) with ESMTP id h14KU2j02121; Tue, 4 Feb 2003 12:30:02 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 04 Feb 2003 12:30:01 -0800 Subject: Re: [NSIS] layer split summary? opinions? From: Lixia Zhang To: Bob Braden , CC: Message-ID: In-Reply-To: <200302042012.UAA07360@gra.isi.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > *> > *> Another example: > *> - TCP has this notion of connection > *> - when TCP connection broke, what assumption would you make regarding > *> the state at the other signalling party? > *> currently BGP assumes all states were gone, and it ships another > *> copy of that huge routing table of 118000 entries over again > *> (bar the recent graceful restart, that does not handle all > *> the cases anyway) > *> > > Lixia, > > State recovery is indeed a serious design problem. I believe the step before worrying about recovery is how one defines failure. (e.g. If the TCP connection gone, has the RSVP failed?) Lixia _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 15:40:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03808 for ; Tue, 4 Feb 2003 15:40:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14KkJq22356 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 15:46:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14KkFJ22349; Tue, 4 Feb 2003 15:46:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14KjWJ22311 for ; Tue, 4 Feb 2003 15:45:32 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03776 for ; Tue, 4 Feb 2003 15:39:24 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h14Kh1b18029; Tue, 4 Feb 2003 12:43:01 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id UAA07392; Tue, 4 Feb 2003 20:43:01 GMT Date: Tue, 4 Feb 2003 20:43:01 GMT Message-Id: <200302042043.UAA07392@gra.isi.edu> To: braden@ISI.EDU, ujohn.loughney@nokia.com, lixia@CS.UCLA.EDU Subject: Re: [NSIS] layer split summary? opinions? Cc: nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> > Lixia, *> > *> > State recovery is indeed a serious design problem. *> *> I believe the step before worrying about recovery is how one defines *> failure. *> *> (e.g. If the TCP connection gone, has the RSVP failed?) *> *> Lixia *> Lixia, If this is an exam question, it does not seem hard. If the connection is gone, you reestablish it and exchange epoch numbers. If the epoch numbers are unchanged, you are all done. If they have changed, you know something bad has happened. Yes? Bob _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 15:45:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03918 for ; Tue, 4 Feb 2003 15:45:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14Kp9W22484 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 15:51:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14Kp5J22474; Tue, 4 Feb 2003 15:51:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14KosJ22459 for ; Tue, 4 Feb 2003 15:50:54 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03912 for ; Tue, 4 Feb 2003 15:44:46 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h14KmMb20452; Tue, 4 Feb 2003 12:48:23 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id UAA07411; Tue, 4 Feb 2003 20:48:22 GMT Date: Tue, 4 Feb 2003 20:48:22 GMT Message-Id: <200302042048.UAA07411@gra.isi.edu> To: john.loughney@nokia.com, lixia@cs.ucla.edu Subject: Re: [NSIS] layer split summary? opinions? Cc: nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> If I may add a 3rd example: consider route changes *> (at least BGP doesn't have that problem) *> Ah, you're shifting the ground! Route changes are a subset of the problem of neighbor discovery. Henning says, "There are ways". If Henning is right (and my own work on CSTP leads me to believe that he is), then this is not an obstacle. If Henning is wrong, then indeed using TCP would be a loser. Bob *> _______________________________________________ *> nsis mailing list *> nsis@ietf.org *> https://www1.ietf.org/mailman/listinfo/nsis *> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 15:54:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04081 for ; Tue, 4 Feb 2003 15:54:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14L0ED22892 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 16:00:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14L0AJ22885; Tue, 4 Feb 2003 16:00:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14KxoJ22818 for ; Tue, 4 Feb 2003 15:59:50 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04075 for ; Tue, 4 Feb 2003 15:53:41 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h14KvIb24994; Tue, 4 Feb 2003 12:57:18 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id UAA07419; Tue, 4 Feb 2003 20:57:18 GMT Date: Tue, 4 Feb 2003 20:57:18 GMT Message-Id: <200302042057.UAA07419@gra.isi.edu> To: john.loughney@nokia.com, lixia@cs.ucla.edu, braden@ISI.EDU Subject: Re: [NSIS] layer split summary? opinions? Cc: nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Lixia, PS: When BGP was being developed some 15 years ago, I and several other IAB members fought against Yakov's decision to use TCP. I don't really remember the details, but I think we probably introduced all the arguments you are now using against signaling over TCP. Besides all the technical arguments, using TCP was just plain IMMORAL! From your description of BGP's problems, it appears that the BGP designers were somewhat short-sighted, shall we say, about the details, if they automatically assume that loss of the TCP connection implies loss of all state. However, the success of BGP using TCP over the intervening 15 years has tended to persuade me that I was wrong and Yakov was right. In any case, we need to re-examine the question very carefully. Bob _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 16:18:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04631 for ; Tue, 4 Feb 2003 16:18:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14LOKr24348 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 16:24:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14LOFJ24341; Tue, 4 Feb 2003 16:24:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14LNoJ24290 for ; Tue, 4 Feb 2003 16:23:50 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04611 for ; Tue, 4 Feb 2003 16:17:41 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h14LLIY0029156 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Feb 2003 16:21:18 -0500 (EST) Message-ID: <3E402EE2.7050406@cs.columbia.edu> Date: Tue, 04 Feb 2003 16:21:38 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Braden CC: nsis@ietf.org Subject: Re: [NSIS] layer split summary? opinions? References: <200302042057.UAA07419@gra.isi.edu> In-Reply-To: <200302042057.UAA07419@gra.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Interesting design point. I'm curious if there is the opposite regret: "I only wish we had used UDP (or raw IP) instead of TCP (or some other suitable reliable transport)". Btw, RADIUS and DIAMETER may well offer additional lessons, given that they also made the transition from UDP (RADIUS) to TCP/SCTP (DIAMETER). I haven't followed that debate closely enough to distill the lessons. DNS may offer another lesson. It's obviously the most important user of UDP today, but aren't there discussions about stronger TCP support once secure DNS becomes more prevalent? Bob Braden wrote: > Lixia, > > PS: When BGP was being developed some 15 years ago, I and several other > IAB members fought against Yakov's decision to use TCP. I don't really > remember the details, but I think we probably introduced all the > arguments you are now using against signaling over TCP. Besides all > the technical arguments, using TCP was just plain IMMORAL! > >>From your description of BGP's problems, it appears that the BGP > designers were somewhat short-sighted, shall we say, about the details, > if they automatically assume that loss of the TCP connection implies > loss of all state. However, the success of BGP using TCP over the > intervening 15 years has tended to persuade me that I was wrong and > Yakov was right. In any case, we need to re-examine the question very > carefully. > > Bob > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 16:28:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04796 for ; Tue, 4 Feb 2003 16:28:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14LYUN24753 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 16:34:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14LYQJ24740; Tue, 4 Feb 2003 16:34:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14LTWJ24526 for ; Tue, 4 Feb 2003 16:29:32 -0500 Received: from tnt.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04706 for ; Tue, 4 Feb 2003 16:23:22 -0500 (EST) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id h14LQxb10308; Tue, 4 Feb 2003 13:26:59 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id VAA07443; Tue, 4 Feb 2003 21:26:59 GMT Date: Tue, 4 Feb 2003 21:26:59 GMT Message-Id: <200302042126.VAA07443@gra.isi.edu> To: braden@ISI.EDU, hgs@cs.columbia.edu Subject: Re: [NSIS] layer split summary? opinions? Cc: nsis@ietf.org X-Sun-Charset: US-ASCII Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , *> *> DNS may offer another lesson. It's obviously the most important user of *> UDP today, but aren't there discussions about stronger TCP support once *> secure DNS becomes more prevalent? *> Henning, I would claim that DNS really is a different design point. Any DNS server may have to contact any other DNS server; there is nothing corresponding to "neighbors", long-lived associations that talk only to each other. Datagrams really DO make sense in the DNS case. Bob _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 16:36:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05023 for ; Tue, 4 Feb 2003 16:36:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14LgC025818 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 16:42:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14Lg8J25799; Tue, 4 Feb 2003 16:42:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14LcgJ25594 for ; Tue, 4 Feb 2003 16:38:42 -0500 Received: from hawk.cs.ucla.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04883 for ; Tue, 4 Feb 2003 16:32:33 -0500 (EST) Received: from [131.179.33.142] (Cs-33-142.CS.UCLA.EDU [131.179.33.142]) by hawk.cs.ucla.edu (8.11.6+Sun/8.11.6/UCLACS-5.2) with ESMTP id h14La1j02898; Tue, 4 Feb 2003 13:36:02 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 04 Feb 2003 13:36:01 -0800 Subject: Re: [NSIS] layer split summary? opinions? From: Lixia Zhang To: Bob Braden , CC: Message-ID: In-Reply-To: <200302042057.UAA07419@gra.isi.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > However, the success of BGP using TCP over the > intervening 15 years has tended to persuade me that I was wrong and > Yakov was right. In any case, we need to re-examine the question very > carefully. > > Bob (I told John that I had to get my day job done and stop here, but one more msg) Just to clarify: We have witnessed the success of the Internet over the last 15 years. I agree completely with very careful re-examination. Lixia _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 16:39:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05094 for ; Tue, 4 Feb 2003 16:39:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14LjA925998 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 16:45:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14Lj7J25976; Tue, 4 Feb 2003 16:45:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14LibJ25916 for ; Tue, 4 Feb 2003 16:44:37 -0500 Received: from hawk.cs.ucla.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05074 for ; Tue, 4 Feb 2003 16:38:27 -0500 (EST) Received: from [131.179.33.142] (Cs-33-142.CS.UCLA.EDU [131.179.33.142]) by hawk.cs.ucla.edu (8.11.6+Sun/8.11.6/UCLACS-5.2) with ESMTP id h14Lftj02974; Tue, 4 Feb 2003 13:41:56 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 04 Feb 2003 13:41:55 -0800 Subject: Re: [NSIS] layer split summary? opinions? From: Lixia Zhang To: Bob Braden , CC: Message-ID: In-Reply-To: <200302042048.UAA07411@gra.isi.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > *> If I may add a 3rd example: consider route changes > *> (at least BGP doesn't have that problem) > *> > > Ah, you're shifting the ground! I do not think so. One of the fundamental (unstated) assumption of soft state approach is the potential (just potential) that the world may be changing beneath you at any given time. Lixia _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 17:22:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06436 for ; Tue, 4 Feb 2003 17:22:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h14MSIe29394 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 17:28:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14MSFJ29374; Tue, 4 Feb 2003 17:28:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14MPfJ29261 for ; Tue, 4 Feb 2003 17:25:41 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06380 for ; Tue, 4 Feb 2003 17:19:30 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h14MN5Y0003048 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Feb 2003 17:23:06 -0500 (EST) Message-ID: <3E403D5E.4090103@cs.columbia.edu> Date: Tue, 04 Feb 2003 17:23:26 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lixia Zhang CC: john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] layer split summary? opinions? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > One simple example: > - TCP offers reliable byte stream. > - That's not what you need. A later signaling msg may replace an > earlier one, yet you cannot take back the bytes that you have > already passed to TCP. This is only a problem if there is a long delay in the pipe. Otherwise, UDP or TCP, the message will be delivered after the same time. (If you believe head-of-line blocking matters, SCTP would presumably address that problem.) > > Another example: > - TCP has this notion of connection > - when TCP connection broke, what assumption would you make regarding > the state at the other signalling party? > currently BGP assumes all states were gone, and it ships another > copy of that huge routing table of 118000 entries over again > (bar the recent graceful restart, that does not handle all > the cases anyway) > > And don't assume that TCP sessions between two signalling ends never > break--if experience with BGP serves an example, it shows they do, and a lot > more frequent than one would think At least in our model, the existence of a TCP connection has no relationship to the existence of an NSIS session. A single NSIS session could use multiple TCP connections over time and multiple NSIS sessions can share a single TCP connection, either sequentially or in parallel. The decision when to drop a TCP connection is purely an optimization. If you expect a new signaling message between two entities soon, it makes sense to keep a TCP connection around. (Aside: Early H.323 made the mistake of tying session lifetime to TCP lifetime; there was a related, transaction-level tie for SIP. Both have since seen the error of their ways and decoupled transport session lifetime from higher-layer sessions.) Henning _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 4 23:33:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15207 for ; Tue, 4 Feb 2003 23:33:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h154dXS16513 for nsis-archive@odin.ietf.org; Tue, 4 Feb 2003 23:39:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h154dUJ16506; Tue, 4 Feb 2003 23:39:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h154cqJ16489 for ; Tue, 4 Feb 2003 23:38:52 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15191 for ; Tue, 4 Feb 2003 23:32:33 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h154Z6218043 for ; Wed, 5 Feb 2003 06:35:06 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Feb 2003 06:36:10 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Feb 2003 06:36:10 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Feb 2003 06:36:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] layer split summary? opinions? Date: Wed, 5 Feb 2003 06:36:09 +0200 Message-ID: Thread-Topic: [NSIS] layer split summary? opinions? Thread-Index: AcLMk3cRCo+oc4aaQOqgXhwunaeIpAAO1PhQ To: , Cc: X-OriginalArrivalTime: 05 Feb 2003 04:36:10.0201 (UTC) FILETIME=[1B3C8490:01C2CCD0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h154cqJ16490 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Henning, > Btw, RADIUS and DIAMETER may well offer additional lessons, given that > they also made the transition from UDP (RADIUS) to TCP/SCTP (DIAMETER). > I haven't followed that debate closely enough to distill the lessons. Well, there are some very practical reasons, especially for accounting, not to use UDP. From 2975 Since RADIUS accounting is based on UDP and timeout and retry parameters are not specified, implementations vary widely in their approach to reliability, with some implementations retrying until delivery or buffer exhaustion, and others losing accounting data after a few retries. Since RADIUS accounting does not provide for application-layer acknowledgments or error messages, a RADIUS Accounting-Response is equivalent to a transport-layer acknowledgment and provides no protection against application layer malfunctions. Due to the lack of reliability, it is not possible to do simultaneous usage control based on RADIUS accounting alone. But, yes, in general, the transport area seems to want to move protocols away from UDP to TCP whereever possible. br, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 5 02:27:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12856 for ; Wed, 5 Feb 2003 02:27:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h157XYR02462 for nsis-archive@odin.ietf.org; Wed, 5 Feb 2003 02:33:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h157XSJ02447; Wed, 5 Feb 2003 02:33:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h157WxJ02426 for ; Wed, 5 Feb 2003 02:32:59 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11817 for ; Wed, 5 Feb 2003 02:26:38 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h157Wrm12300 for ; Wed, 5 Feb 2003 09:32:53 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Feb 2003 09:30:13 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Feb 2003 09:30:13 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Feb 2003 09:30:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] layer split summary? opinions? Date: Wed, 5 Feb 2003 09:30:12 +0200 Message-ID: Thread-Topic: [NSIS] layer split summary? opinions? Thread-Index: AcLMWmvoBhEplUKLSXCmnY+7AlOx1AAjbyCw To: Cc: X-OriginalArrivalTime: 05 Feb 2003 07:30:13.0048 (UTC) FILETIME=[6BA88380:01C2CCE8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h157WxJ02427 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Lixia, > One simple example: > - TCP offers reliable byte stream. > - That's not what you need. A later signaling msg may replace an > earlier one, yet you cannot take back the bytes that you have > already passed to TCP. You seem to be suggesting that TCP might be more than what is needed, due to reliable byte stream. SCTP differs slightly, as it offers reliable message transfer, but the difference is not so big. > Another example: > - TCP has this notion of connection > - when TCP connection broke, what assumption would you make regarding > the state at the other signalling party? > currently BGP assumes all states were gone, and it ships another > copy of that huge routing table of 118000 entries over again > (bar the recent graceful restart, that does not handle all > the cases anyway) > > And don't assume that TCP sessions between two signalling ends never > break--if experience with BGP serves an example, it shows > they do, and a lot more frequent than one would think So, what you are suggesting is that the NTLP (NSIS transport layer protcol) should not equate a TCP connection with a NTLP session, if TCP is used. I think that is a very good point. br, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 5 02:38:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13274 for ; Wed, 5 Feb 2003 02:38:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h157iDQ03858 for nsis-archive@odin.ietf.org; Wed, 5 Feb 2003 02:44:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h157iAJ03851; Wed, 5 Feb 2003 02:44:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h157hRJ03826 for ; Wed, 5 Feb 2003 02:43:27 -0500 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13251 for ; Wed, 5 Feb 2003 02:37:06 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by mail.alcatel.be (8.10.1/8.11.4) with ESMTP id h157eba27110; Wed, 5 Feb 2003 08:40:37 +0100 (MET) Subject: Re: [NSIS] layer split summary? opinions? To: Lixia Zhang Cc: , X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 5 Feb 2003 08:40:34 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/05/2003 08:40:36 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Lixia, John, all, Assuming that we are talking about reservations for QoS resources, won't a BGP route change cause a problem as well? It will cause packets to be sent over a new (unreserved) path while leaving an unused reservation on the old path. There is absolutely no guarantee that a reservation will be possible on the new path. The reason for this is explained in RFC 2990: you cannot assume that BE-routing context will always allow you to set up QoS reservations. Would you agree that this can be a problem? Best regards, Sven Lixia Zhang @ietf.org on 04/02/2003 21:28:15 Sent by: nsis-admin@ietf.org To: cc: Subject: Re: [NSIS] layer split summary? opinions? >> A question to you: >> >>> Pls consider separating two different concepts: >>> - a soft-state protocol with ACK for each message; and >>> - a reliable transport protocol underneath RSVP. >>> >>> They are very different. >>> In a later paper (in ICNP'99 I believe) we stated that it is a good >>> enhancement to add ACK to RSVP. >>> But I personally consider it INfeasible to put TCP underneath. >>> >>> Lixia >>> >>> (if someone here runs BGP: how well has that been working) >> >> What is the feasibility of running an NSIS transport over TCP to >> certain entities, like edge routers / gateways, while supporting >> soft-state for routers & boxes between these edge routers / gateways? > > That'll need more time to explain than what I have in hand at this time > (heading to airport in an hour) > > But briefly: the fundamental problem is mismatch of semantics/data framing > in providing reliability. > > One simple example: > - TCP offers reliable byte stream. > - That's not what you need. A later signaling msg may replace an > earlier one, yet you cannot take back the bytes that you have > already passed to TCP. > > Another example: > - TCP has this notion of connection > - when TCP connection broke, what assumption would you make regarding > the state at the other signalling party? > currently BGP assumes all states were gone, and it ships another > copy of that huge routing table of 118000 entries over again > (bar the recent graceful restart, that does not handle all > the cases anyway) If I may add a 3rd example: consider route changes (at least BGP doesn't have that problem) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 5 02:51:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13505 for ; Wed, 5 Feb 2003 02:51:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h157vBx04234 for nsis-archive@odin.ietf.org; Wed, 5 Feb 2003 02:57:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h157v7J04227; Wed, 5 Feb 2003 02:57:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h157utJ04201 for ; Wed, 5 Feb 2003 02:56:55 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13490 for ; Wed, 5 Feb 2003 02:50:33 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h157r5201276 for ; Wed, 5 Feb 2003 09:53:05 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Feb 2003 09:54:10 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Feb 2003 09:54:09 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Feb 2003 09:54:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] layer split summary? opinions? Date: Wed, 5 Feb 2003 09:54:07 +0200 Message-ID: Thread-Topic: [NSIS] layer split summary? opinions? Thread-Index: AcLM6eOP6Q2W4/m8QfqQKikUqik0LgAAZIcQ To: , Cc: X-OriginalArrivalTime: 05 Feb 2003 07:54:08.0494 (UTC) FILETIME=[C34030E0:01C2CCEB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h157utJ04202 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Sven, > Assuming that we are talking about reservations for QoS resources, won't a > BGP route change cause a problem as well? It will cause packets to be sent > over a new (unreserved) path while leaving an unused reservation on the old > path. There is absolutely no guarantee that a reservation will be possible > on the new path. The reason for this is explained in RFC 2990: you cannot > assume that BE-routing context will always allow you to set up QoS > reservations. Would you agree that this can be a problem? I agree, this is a problem, and always has been a problem. If you use 'normal' IP routing, you are not setting up static pipes, so there is always some chance that something changes. Of course, I think of this as a 2nd order problem, meaning that we will probably need to tackle this, but my strategy has always been to work on the general purpose solution and then seen about applying it to some of these corner cases. br, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 5 02:55:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13569 for ; Wed, 5 Feb 2003 02:55:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15817e04424 for nsis-archive@odin.ietf.org; Wed, 5 Feb 2003 03:01:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15814J04417; Wed, 5 Feb 2003 03:01:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15811J04392 for ; Wed, 5 Feb 2003 03:01:01 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13552 for ; Wed, 5 Feb 2003 02:54:39 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h157vB204448 for ; Wed, 5 Feb 2003 09:57:11 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Feb 2003 09:58:15 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Feb 2003 09:58:15 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Feb 2003 09:58:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] layer split summary? opinions? Date: Wed, 5 Feb 2003 09:57:32 +0200 Message-ID: Thread-Topic: [NSIS] layer split summary? opinions? Thread-Index: AcLMnAIjiGzzQqfTSI25YO3LdG46FgAT852w To: , Cc: X-OriginalArrivalTime: 05 Feb 2003 07:58:14.0354 (UTC) FILETIME=[55CB7320:01C2CCEC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h15811J04393 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello all, > This is only a problem if there is a long delay in the pipe. Otherwise, > UDP or TCP, the message will be delivered after the same time. (If you > believe head-of-line blocking matters, SCTP would presumably address > that problem.) A somewhat crazy idea popped into my head, based upon Henning's text. As most of you know, SCTP supports multihoming, allowing support for multiple data paths between SCTP endpoints. Could SCTP, when used as an NSIS transport (below NTLP) provide more path robustness? The question is, however, can we engineer something using SCTP that intermediate nodes 'sniff' the NTLP/SCTP packets to see if they are concerned about the contents? br, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 5 06:09:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17498 for ; Wed, 5 Feb 2003 06:09:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h15BFYc15222 for nsis-archive@odin.ietf.org; Wed, 5 Feb 2003 06:15:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15BFUJ15210; Wed, 5 Feb 2003 06:15:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15BEWJ15086 for ; Wed, 5 Feb 2003 06:14:32 -0500 Received: from s2.ifi.informatik.uni-goettingen.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17381 for ; Wed, 5 Feb 2003 06:08:05 -0500 (EST) Received: from cs.uni-goettingen.de (ap26.ifi.informatik.uni-goettingen.de [::ffff:134.76.81.58]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Wed, 05 Feb 2003 12:11:43 +0100 Message-ID: <3E40F13D.4040601@cs.uni-goettingen.de> Date: Wed, 05 Feb 2003 12:10:53 +0100 From: Xiaoming Fu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: hgs@cs.columbia.edu, lixia@cs.ucla.edu, nsis@ietf.org Subject: Re: [NSIS] layer split summary? opinions? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit John, all, Interesting suggestion. SCTP association has assumed be one candidate for transporting NSLP (e.g., CASP client as in CASP proposal) data for each pair of neigboring NTLP nodes. Following recent investigations on SCTP for mobility, add-ip (as well as delete-ip) operation with SCTP may make it also possible to deal with route change (of which mobility is a special case) while maintaining a same association for the neighboring NTLPs using SCTP. This association can also be used for dealing with route change, where a SCTP/NTLP API should be able to trigger such a local repair and therefore an NTLP/NSLP API triggers further repairs for NSLPs states. I think this assumption/requirement is valid with a two-layer architecture. On the other hand, using SCTP may implicates that session/flow identifiers may be hiden (of course we can break the normal hierarchy and look into lower layers as well), which are potentially useful in some signaling applications. Best regards, Xiaoming john.loughney@nokia.com wrote: > Hello all, > > >>This is only a problem if there is a long delay in the pipe. Otherwise, >>UDP or TCP, the message will be delivered after the same time. (If you >>believe head-of-line blocking matters, SCTP would presumably address >>that problem.) > > > A somewhat crazy idea popped into my head, based upon Henning's text. > As most of you know, SCTP supports multihoming, allowing support for > multiple data paths between SCTP endpoints. Could SCTP, when used > as an NSIS transport (below NTLP) provide more path robustness? > The question is, however, can we engineer something using SCTP that > intermediate nodes 'sniff' the NTLP/SCTP packets to see if they are > concerned about the contents? > > br, > John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 5 18:55:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15826 for ; Wed, 5 Feb 2003 18:55:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1601qP07227 for nsis-archive@odin.ietf.org; Wed, 5 Feb 2003 19:01:52 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1601jp07204; Wed, 5 Feb 2003 19:01:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1600Lp07147 for ; Wed, 5 Feb 2003 19:00:21 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15792 for ; Wed, 5 Feb 2003 18:53:38 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5RLQZ>; Wed, 5 Feb 2003 23:57:16 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF67E9@rsys002a.roke.co.uk> From: "Hancock, Robert" To: john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] layer split summary? opinions? Date: Wed, 5 Feb 2003 23:57:16 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , John, since you raise this in the context specifically of SCTP's multi-address support, it would be a lot clearer if you said what the multiple addresses were that you had in mind, and what sort of conditions you were looking for robustness against. Obviously, sctp can be used to build a pretty robust connection between two NTLP peers (but that isn't really a "crazy idea".) If you're referring to robustness against endpoint address changes but where the peers are the same pair of nodes, I think I agree with Xiaoming's mail (but that scenario doesn't really relate to intermediate nodes sniffing the contents). This doesn't seem like a crazy idea, but I wouldn't know how to validate the 'same peer' assumption either. Or, a genuinely crazy idea would be to [somehow] use SCTP's addressing flexibility to re-instate e2e addressing (getting robustness in the form of automatic reaction to re-routing) while still having the advantages [add caveat here that some people think they are disadvantages] of there being a transport protocol running between peers. Unfortunately, I believe you can show that most of the advantageous features of a transport protocol are intrinsically incompatible with e2e addressing (unless maybe you are prepared to develop a basically new transport protocol). Let's discuss it on tuesday. robert h. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 05 February 2003 07:58 > To: hgs@cs.columbia.edu; lixia@cs.ucla.edu > Cc: nsis@ietf.org > Subject: RE: [NSIS] layer split summary? opinions? > > > Hello all, > > > This is only a problem if there is a long delay in the > pipe. Otherwise, > > UDP or TCP, the message will be delivered after the same > time. (If you > > believe head-of-line blocking matters, SCTP would > presumably address > > that problem.) > > A somewhat crazy idea popped into my head, based upon Henning's text. > As most of you know, SCTP supports multihoming, allowing support for > multiple data paths between SCTP endpoints. Could SCTP, when used > as an NSIS transport (below NTLP) provide more path robustness? > The question is, however, can we engineer something using SCTP that > intermediate nodes 'sniff' the NTLP/SCTP packets to see if they are > concerned about the contents? > > br, > John > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 5 18:55:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15828 for ; Wed, 5 Feb 2003 18:55:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1601sb07240 for nsis-archive@odin.ietf.org; Wed, 5 Feb 2003 19:01:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1601op07220; Wed, 5 Feb 2003 19:01:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1600Np07151 for ; Wed, 5 Feb 2003 19:00:23 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15795 for ; Wed, 5 Feb 2003 18:53:41 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5RLQ5>; Wed, 5 Feb 2003 23:57:19 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41805DF67EA@rsys002a.roke.co.uk> From: "Hancock, Robert" To: john.loughney@nokia.com, lixia@CS.UCLA.EDU Cc: nsis@ietf.org Subject: RE: [NSIS] layer split summary? opinions? Date: Wed, 5 Feb 2003 23:57:18 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Dear all, On the question of whether signalling application behaviour should be tied to TCP connection semantics/operation: Back at the start of this thread, it was argued that the NSIS transport service (however you name what sits below it) should provide only a stateless message delivery capability (not a state management capability). I'd still be interested in comments on that point. In any case, I believe that exactly the same arguments say that tying signalling application behaviour to TCP (or any other transport protocol) connection state machine would be a massively bad idea (if indeed we haven't already said that somewhere). The transport service should get messages from A to B; what's in question is how well it should do it, and whether the costs of depending on something TCP-like are worth the benefits. Or, to use Bob's analogy: a spade and a backhoe both dig conceptually similar things in gardens (i.e. holes). The fact that the backhoe is internally connection-oriented doesn't matter to the gardener. Cheers, RobertH. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 05 February 2003 07:30 > To: lixia@CS.UCLA.EDU > Cc: nsis@ietf.org > Subject: RE: [NSIS] layer split summary? opinions? > > > Hi Lixia, > > > One simple example: > > - TCP offers reliable byte stream. > > - That's not what you need. A later signaling msg may replace an > > earlier one, yet you cannot take back the bytes that you have > > already passed to TCP. > > You seem to be suggesting that TCP might be more than what is needed, > due to reliable byte stream. SCTP differs slightly, as it offers > reliable message transfer, but the difference is not so big. > > > Another example: > > - TCP has this notion of connection > > - when TCP connection broke, what assumption would you make > regarding > > the state at the other signalling party? > > currently BGP assumes all states were gone, and it ships another > > copy of that huge routing table of 118000 entries over again > > (bar the recent graceful restart, that does not handle all > > the cases anyway) > > > > And don't assume that TCP sessions between two signalling ends never > > break--if experience with BGP serves an example, it shows > > they do, and a lot more frequent than one would think > > So, what you are suggesting is that the NTLP (NSIS transport > layer protcol) > should not equate a TCP connection with a NTLP session, if > TCP is used. > I think that is a very good point. > > br, > John > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 6 01:34:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25168 for ; Thu, 6 Feb 2003 01:34:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h166eRA27001 for nsis-archive@odin.ietf.org; Thu, 6 Feb 2003 01:40:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h166eOp26994; Thu, 6 Feb 2003 01:40:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h166d3p26933 for ; Thu, 6 Feb 2003 01:39:03 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25107 for ; Thu, 6 Feb 2003 01:32:12 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h166cUm17160 for ; Thu, 6 Feb 2003 08:38:30 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Feb 2003 08:35:50 +0200 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 08:35:50 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 08:35:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] layer split summary? opinions? Date: Thu, 6 Feb 2003 08:35:48 +0200 Message-ID: Thread-Topic: [NSIS] layer split summary? opinions? Thread-Index: AcLNclK8iQNG0PM6SPOT0XWyiqZvhgAN5Ivw To: , Cc: X-OriginalArrivalTime: 06 Feb 2003 06:35:49.0453 (UTC) FILETIME=[FCD12FD0:01C2CDA9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h166d4p26934 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Robert, > On the question of whether signalling application behaviour > should be tied to TCP connection semantics/operation: > > Back at the start of this thread, it was argued that the NSIS > transport service (however you name what sits below it) > should provide only a stateless message delivery capability > (not a state management capability). I'd still be interested > in comments on that point. Anyone have opinions on this? > In any case, I believe that exactly the same arguments say > that tying signalling application behaviour to TCP (or any > other transport protocol) connection state machine would be a > massively bad idea (if indeed we haven't already said that > somewhere). The transport service should get messages from A > to B; what's in question is how well it should do it, and > whether the costs of depending on something TCP-like are > worth the benefits. > > Or, to use Bob's analogy: a spade and a backhoe both dig > conceptually similar things in gardens (i.e. holes). The fact > that the backhoe is internally connection-oriented doesn't > matter to the gardener. Agreed. br, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 6 01:58:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25764 for ; Thu, 6 Feb 2003 01:58:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1674n830244 for nsis-archive@odin.ietf.org; Thu, 6 Feb 2003 02:04:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1674kp30178; Thu, 6 Feb 2003 02:04:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1673Mp28088 for ; Thu, 6 Feb 2003 02:03:22 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25717 for ; Thu, 6 Feb 2003 01:56:31 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h166x4204838 for ; Thu, 6 Feb 2003 08:59:04 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Feb 2003 09:00:09 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 09:00:09 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 09:00:09 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 09:00:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 6 Feb 2003 09:00:09 +0200 Message-ID: Thread-Topic: [NSIS] layer split summary? opinions? Thread-Index: AcLNclK8iQNG0PM6SPOT0XWyiqZvhgAN5IvwAACyUkA= To: X-OriginalArrivalTime: 06 Feb 2003 07:00:09.0327 (UTC) FILETIME=[62F847F0:01C2CDAD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1673Np28089 Subject: [NSIS] NSIS Interim Meeting Agenda Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, The current agena is as follows: NSIS Interim Meeting The meeting will take place between February 10th - 12th at Columbia University, 500 W 120th Street, NY, NY. Monday Open the meeting at 8 AM Meeting starts at 9 AM Intro WG update Charter update Requirements update http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-06.txt Framework update http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-01.txt Security threats update http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt NSIS Authentication, Authorization and Accounting Issues Implications of trust relationships for NSIS signaling Layer Split document (Ping Pan) Meeting closes 4:30 PM Tuesday Open the meeting at 8 AM Meeting starts at 9 AM Starting Protocol Work Layer split issues Transport issues application issues. related documents: NSIS Transport Layer Protocol (NTLP) Functionality http://www.ietf.org/internet-drafts/draft-brunner-nsis-ntlp-func-00.txt Design Considerations for an NSIS Transport Layer Protocol http://www.ietf.org/internet-drafts/draft-mcdonald-nsis-ntlp-considerations-00.txt Using RSVPv1 as NTLP (NSIS Transport Layer Protocol): suggestions for modifications on RFC2205 http://www.ietf.org/internet-drafts/draft-westberg-nsis-rsvp-as-ntlp-00.txt Meeting closes 4:30 PM Wednesday Open the meeting at 8 AM Meeting starts at 9 AM overflow Mobility issues other topics? Meeting closes 12:00 PM Folks indicated they are coming (if your name is not on this list and you are coming, let me know). thanks, John Aoun, Cedric Bang, Jong Ho Bradner, Scott Brunner, Marcus Chan, Kwok Ho Elwalid, Anwar Freytsis, Ilya Geib, Rüdiger Hancock, Robert Hillebrand, Joachim Karagiannis, Georgios Lee, Sung Hyuck Lippitsch, Hans Loughney, John Mankin, Allison Pan, Ping Phelan, Tom Rinne, Janne Roy, Radhika Schulzrinne, Henning van den Bosch, Sven Zhao, Weibin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 6 02:04:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02157 for ; Thu, 6 Feb 2003 02:04:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h167B7005603 for nsis-archive@odin.ietf.org; Thu, 6 Feb 2003 02:11:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h167B4p05596; Thu, 6 Feb 2003 02:11:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h167Afp05187 for ; Thu, 6 Feb 2003 02:10:41 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00952 for ; Thu, 6 Feb 2003 02:03:49 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1676M210261 for ; Thu, 6 Feb 2003 09:06:22 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Feb 2003 09:07:27 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 09:07:27 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 09:07:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 6 Feb 2003 09:07:27 +0200 Message-ID: Thread-Topic: [NSIS] layer split summary? opinions? Thread-Index: AcLNclK8iQNG0PM6SPOT0XWyiqZvhgAN5IvwAACyUkAAAFpK0A== To: X-OriginalArrivalTime: 06 Feb 2003 07:07:27.0381 (UTC) FILETIME=[68120450:01C2CDAE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h167Afp05188 Subject: [NSIS] Updated NSIS Interim Meeting Agenda Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, A small update to the current agenda is as follows: NSIS Interim Meeting The meeting will take place between February 10th - 12th at Columbia University, 500 W 120th Street, NY, NY. Monday Open the meeting at 8 AM Meeting starts at 9 AM Intro WG update Charter update Requirements update http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-06.txt Framework update http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-01.txt Security threats update http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt NSIS Authentication, Authorization and Accounting Issues Implications of trust relationships for NSIS signaling Layer Split document (Ping Pan) Meeting closes 4:30 PM Tuesday Open the meeting at 8 AM Meeting starts at 9 AM Starting Protocol Work Layer split issues Transport issues application issues. related documents: Two-Level Architecture for Internet Signaling http://www.ietf.org/internet-drafts/draft-braden-2level-signal-arch-01.txt NSIS Transport Layer Protocol (NTLP) Functionality http://www.ietf.org/internet-drafts/draft-brunner-nsis-ntlp-func-00.txt Design Considerations for an NSIS Transport Layer Protocol http://www.ietf.org/internet-drafts/draft-mcdonald-nsis-ntlp-considerations-00.txt Using RSVPv1 as NTLP (NSIS Transport Layer Protocol): suggestions for modifications on RFC2205 http://www.ietf.org/internet-drafts/draft-westberg-nsis-rsvp-as-ntlp-00.txt Meeting closes 4:30 PM Wednesday Open the meeting at 8 AM Meeting starts at 9 AM overflow Mobility issues other topics? Meeting closes 12:00 PM Folks indicated they are coming (if your name is not on this list and you are coming, let me know). thanks, John Aoun, Cedric Bang, Jong Ho Bradner, Scott Brunner, Marcus Chan, Kwok Ho Elwalid, Anwar Freytsis, Ilya Geib, Rüdiger Hancock, Robert Hillebrand, Joachim Karagiannis, Georgios Lee, Sung Hyuck Lippitsch, Hans Loughney, John Mankin, Allison Pan, Ping Phelan, Tom Rinne, Janne Roy, Radhika Schulzrinne, Henning van den Bosch, Sven Zhao, Weibin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 6 05:08:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10981 for ; Thu, 6 Feb 2003 05:08:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16AFGW18695 for nsis-archive@odin.ietf.org; Thu, 6 Feb 2003 05:15:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16AFDp18675; Thu, 6 Feb 2003 05:15:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16AE4p18634 for ; Thu, 6 Feb 2003 05:14:04 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10948 for ; Thu, 6 Feb 2003 05:07:10 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id h16AAm818906 for ; Thu, 6 Feb 2003 11:10:48 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id h16AAlK27358 for ; Thu, 6 Feb 2003 11:10:47 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Feb 2003 11:10:47 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F034C882A@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: nsis@ietf.org Date: Thu, 6 Feb 2003 11:10:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] New draft "NSIS Authentication, Authorization and Accounting Issu es" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi all we have submitted an internet draft relevant for the nsis group. as indicated in the agenda we would like to have a discussion on this topic on monday. Title : NSIS Authentication, Authorization and Accounting Issues Author(s) : H. Tschofenig, M. Buechli, S. Van den Bosch, H. Schulzrinne Filename : draft-tschofenig-nsis-aaa-issues-00.txt Pages : 25 Date : 2003-02-05 Abstract This document describes the implications of authentication, authorization and accounting for an NSIS QoS signaling protocol. We try to show that authorization and charging are very important for the internal machinery of a signaling protocol and for the security and trust model behind it. This document only addresses charging aspects for unicast data traffic. http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-aaa-issues-00.txt ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 6 09:32:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19229 for ; Thu, 6 Feb 2003 09:32:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16Eck004096 for nsis-archive@odin.ietf.org; Thu, 6 Feb 2003 09:38:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Ecfp04088; Thu, 6 Feb 2003 09:38:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16EZxp03307 for ; Thu, 6 Feb 2003 09:35:59 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18921; Thu, 6 Feb 2003 09:28:57 -0500 (EST) Message-Id: <200302061428.JAA18921@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nsis@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 06 Feb 2003 09:28:57 -0500 Subject: [NSIS] I-D ACTION:draft-tschofenig-nsis-aaa-issues-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NSIS Authentication, Authorization and Accounting Issues Author(s) : H. Tschofenig Filename : draft-tschofenig-nsis-aaa-issues-00.txt Pages : 25 Date : 2003-2-5 This document describes the implications of authentication, authorization and accounting for an NSIS QoS signaling protocol. We try to show that authorization and charging are very important for the internal machinery of a signaling protocol and for the security and trust model behind it. This document only addresses charging aspects for unicast data traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-aaa-issues-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-tschofenig-nsis-aaa-issues-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-tschofenig-nsis-aaa-issues-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-5140059.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-tschofenig-nsis-aaa-issues-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-tschofenig-nsis-aaa-issues-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-5140059.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 6 12:34:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27227 for ; Thu, 6 Feb 2003 12:34:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h16HfGs18557 for nsis-archive@odin.ietf.org; Thu, 6 Feb 2003 12:41:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16HfCp18549; Thu, 6 Feb 2003 12:41:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16He5p18512 for ; Thu, 6 Feb 2003 12:40:05 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27184 for ; Thu, 6 Feb 2003 12:33:01 -0500 (EST) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h16HdKm09202 for ; Thu, 6 Feb 2003 19:39:20 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Feb 2003 19:36:39 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 19:36:39 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Feb 2003 19:36:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 6 Feb 2003 19:36:38 +0200 Message-ID: Thread-Topic: [NSIS] layer split summary? opinions? Thread-Index: AcLNclK8iQNG0PM6SPOT0XWyiqZvhgAN5IvwAACyUkAAFmU/AA== To: X-OriginalArrivalTime: 06 Feb 2003 17:36:38.0831 (UTC) FILETIME=[4DB023F0:01C2CE06] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h16He5p18513 Subject: [NSIS] NSIS Interim Meeting Agenda version 3 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit NSIS Interim Meeting The meeting will take place between February 10th - 12th at Columbia University, Room 414 Schapiro CEPSR (entrance level on main campus level), 500 W 120th Street, NY, NY Directions can be found here: http://www.columbia.edu/cu/aboutcolumbia/maps/index.html http://www.columbia.edu/cu/aboutcolumbia/maps/sectionD.html http://www.columbia.edu/cu/aboutcolumbia/maps/images/columbiamap.jpg (the IRT symbol indicates the subway stop and the main campus entrance) Monday Open the meeting at 8 AM Meeting starts at 9 AM Intro WG update Charter update Requirements update http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-06.txt Framework update http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-01.txt Lunch 12:30 Security threats update http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt NSIS Authentication, Authorization and Accounting Issues Implications of trust relationships for NSIS signaling Layer Split document (Ping Pan) Meeting closes 4:30 PM Tuesday Open the meeting at 8 AM Meeting starts at 9 AM Starting Protocol Work "The Design Space for NSIS Signaling Protocols" - Henning Schulzrinne Layer split issues Transport issues Design Considerations for an NSIS Transport Layer Protocol http://www.ietf.org/internet-drafts/draft-mcdonald-nsis-ntlp-considerations-00.txt Using RSVPv1 as NTLP (NSIS Transport Layer Protocol): suggestions for modifications on RFC2205 http://www.ietf.org/internet-drafts/draft-westberg-nsis-rsvp-as-ntlp-00.txt application issues related documents: Two-Level Architecture for Internet Signaling http://www.ietf.org/internet-drafts/draft-braden-2level-signal-arch-01.txt NSIS Transport Layer Protocol (NTLP) Functionality http://www.ietf.org/internet-drafts/draft-brunner-nsis-ntlp-func-00.txt Meeting closes 4:30 PM Wednesday Open the meeting at 8 AM Meeting starts at 9 AM overflow Mobility issues other topics? Meeting closes 12:00 PM Folks indicated they are coming (if your name is not on this list and you are coming, let me know). thanks, John Aoun, Cedric Bang, Jong Ho Bradner, Scott Brunner, Marcus Chan, Kwok Ho Elwalid, Anwar Freytsis, Ilya Geib, Rüdiger Hancock, Robert Hillebrand, Joachim Karagiannis, Georgios Lee, Sung Hyuck Lippitsch, Hans Loughney, John Mankin, Allison Pan, Ping Phelan, Tom Rinne, Janne Roy, Radhika Schulzrinne, Henning Tschofenig Hannes van den Bosch, Sven Zhao, Weibin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 6 20:10:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11195 for ; Thu, 6 Feb 2003 20:10:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h171Gtv14140 for nsis-archive@odin.ietf.org; Thu, 6 Feb 2003 20:16:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h171Ghp14127; Thu, 6 Feb 2003 20:16:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h171EWp14001 for ; Thu, 6 Feb 2003 20:14:32 -0500 Received: from mtiwmhc13.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11115 for ; Thu, 6 Feb 2003 20:07:20 -0500 (EST) Received: from cs.columbia.edu (170.indianapolis-18rh16rt.in.dial-access.att.net[12.85.3.170]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <20030207011058113005jtg2e>; Fri, 7 Feb 2003 01:10:59 +0000 Message-ID: <3E430748.8020901@cs.columbia.edu> Date: Thu, 06 Feb 2003 20:09:28 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org CC: Xiaotao Wu Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] Remote participation in NSIS interim meeting Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit We will be trying to set up remote A/V access (listening and talking) to the NSIS Interim Meeting at Columbia University next week, using SIP tools. This will only work if you have a reasonably liberal firewall that allows port 5060 and at least two UDP port pairs through (for audio and video). Please contact Xiaotao Wu, cc'ed, if you are interested, so that he can run tests ahead of time. Henning _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Feb 7 09:08:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11857 for ; Fri, 7 Feb 2003 09:08:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h17EFUF06338 for nsis-archive@odin.ietf.org; Fri, 7 Feb 2003 09:15:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17EFMp06330; Fri, 7 Feb 2003 09:15:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h17EE0p06261 for ; Fri, 7 Feb 2003 09:14:00 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11803 for ; Fri, 7 Feb 2003 09:06:31 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h17EABaB002824 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 7 Feb 2003 09:10:11 -0500 (EST) Message-ID: <3E43BE48.7010408@cs.columbia.edu> Date: Fri, 07 Feb 2003 09:10:16 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] Internet access at NSIS interim meeting Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Columbia University has a campus-wide open wireless network: http://www.columbia.edu/acis/access/oncampus/wireless/ It should also cover the meeting rooms for the NSIS meeting. No special registration or login is required. There are no firewalls or NATs. IPv6 is available in most places. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sat Feb 8 16:41:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01199 for ; Sat, 8 Feb 2003 16:41:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h18LmwF11863 for nsis-archive@odin.ietf.org; Sat, 8 Feb 2003 16:48:58 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h18Lmsp11856; Sat, 8 Feb 2003 16:48:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h18LjVp11813 for ; Sat, 8 Feb 2003 16:45:31 -0500 Received: from rly-ip04.mx.aol.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01139 for ; Sat, 8 Feb 2003 16:37:23 -0500 (EST) Received: from logs-wo.proxy.aol.com (logs-wo.proxy.aol.com [205.188.200.6]) by rly-ip04.mx.aol.com (v89.10) with ESMTP id RELAYIN7-0208163727; Sat, 08 Feb 2003 16:37:27 -0500 Received: from cs.columbia.edu (AC856871.ipt.aol.com [172.133.104.113]) by logs-wo.proxy.aol.com (8.12.6/8.12.6) with ESMTP id h18LdGDI342379; Sat, 8 Feb 2003 16:39:17 -0500 (EST) Message-ID: <3E457906.5070103@cs.columbia.edu> Date: Sat, 08 Feb 2003 16:39:18 -0500 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: nsis@ietf.org, Henning Schulzrinne Subject: Re: [NSIS] NSIS Interim Meeting Agenda References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Apparently-From: Pingpan999@aol.com Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Here is the draft that we are submitting, and will present on Monday. http://www.cs.columbia.edu/~pingpan/papers/draft-pan-nsis-rsvp-transport-00.txt Thanks! - Ping john.loughney@nokia.com wrote: > Hi all, > > The current agena is as follows: > > NSIS Interim Meeting > > The meeting will take place between February 10th - 12th at Columbia > University, 500 W 120th Street, NY, NY. > > Monday > ... > Layer Split document (Ping Pan) > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Feb 10 03:14:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29593 for ; Mon, 10 Feb 2003 03:14:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1A8NEl30390 for nsis-archive@odin.ietf.org; Mon, 10 Feb 2003 03:23:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A8N5p30383; Mon, 10 Feb 2003 03:23:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1A8JWp30172 for ; Mon, 10 Feb 2003 03:19:32 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29397 for ; Mon, 10 Feb 2003 03:10:43 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1A8EKAv010841; Mon, 10 Feb 2003 09:14:20 +0100 (MET) Received: from era.ericsson.se (E00104B7F41BB.ki.sw.ericsson.se [147.214.181.136]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id DY5KQ9QB; Mon, 10 Feb 2003 09:14:20 +0100 Message-ID: <3E475F5B.A5E6CA61@era.ericsson.se> Date: Mon, 10 Feb 2003 09:14:19 +0100 X-Sybari-Trust: 82838e8c 9ffcebbb a5ee123c 00000138 From: "Lars.Westberg" X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com CC: hgs@cs.columbia.edu, starsu@sait.samsung.co.kr, berson@isi.edu, pingpan@cs.columbia.edu, nsis@ietf.org Subject: Re: [NSIS] layer split summary? opinions? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Comment to the RTT: One problem with TCP/SCTP over air-interace is the response time to establish a session e.g. the time to get the reservation done over the air-interface and the infrastructure. This is not only due to long RTT but also that the radio-channel has a very low-bitrate. The combination of low-bitrate channel, RTT and tight response time requirements may be difficult to fulfill with TCP. The response time problems have ben previously discussed in the ROCH working group for large SIP-payloads. I think that we have to allow different transport protocol and I propose a lightweigth RSVP as one of the solution. - Lasse john.loughney@nokia.com wrote: > Hi, > > > > The goal of NSIS WG is to make a lightweight signaling (xRSVP), > > > so there are a lot of overhead if xRSVP using TCP is used > > in mobile (access) envrionments. > > > > > > > I'm guessing that your mobile device has a web browser (HTTP), an email > > client (POP, IMAP, SMTP) and maybe even a SIP UA. How many queries a > > second does your web browser do? Compared to a signaling protocol? > > > > Which do you think will do better in your mobile environment: your > > already-tuned-for-mobility TCP stack that you need for HTTP, IMAP, SMTP > > and possibly SIP or RTSP or a let's-develop-a-new-transport protocol > > that we'll develop for this special purpose? > > Just playing the devil's advocate, the problem with TCP on mobile phones > isn't the stack, the resource usage or power - it is about the latency. > GPRS and CDMAx1 both have very high RTTs. If a new TCP connection needs > to be opened, then this will put a significant delay. However, this > would be mitigated by multiplexing over a single TCP connection. In > practice, we should see (in NSIS) how this could be done for a signaling > protocol. > > br, > John > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 13 09:43:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13144 for ; Thu, 13 Feb 2003 09:43:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DEreZ25122 for nsis-archive@odin.ietf.org; Thu, 13 Feb 2003 09:53:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DErZp25089; Thu, 13 Feb 2003 09:53:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DEqjp25048 for ; Thu, 13 Feb 2003 09:52:45 -0500 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13135 for ; Thu, 13 Feb 2003 09:42:19 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id h1DEk0U09605 for ; Thu, 13 Feb 2003 15:46:00 +0100 To: nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 13 Feb 2003 15:45:58 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/13/2003 15:46:00 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [NSIS] session ID Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi all, Upon reflection after the NSIS interim meeting, I have a few concerns regarding the session ID (intended to be able to differentiate existing session state from new state state, e.g. after a reroute or mobility event): 1. We must realize that the session ID does not come for free. With only the flowspec present in the message, one would still have the option of keeping only (forward/backward) routing state in the NEs and this can be done per peer. With the session ID (which is necessarily per session), we are obliged to keep state on a much finer granularity. We may have been assuming that per-flow state was going to be kept anyway, but other solutions have already been described. 2. A question that comes to mind is whether the session ID would belong in the NTLP or in the NSLP. From discussion one might have inferred that it would be the NTLP. I am not sure about this. I would say that the session ID refers to state linked to the NSLP (reservation state, ...) and it is not obvious that it should be in the NTLP. A reason to put it in the NTLP would be to allow state refresh without going up to the NSLP. If this is the case we should make that explicit. personally, I don't think it is such a great idea. How for instance, would one differentiate between a refresh that requires new AAA (to check credit e.g.) and one that doesn't? just my 2cc, Sven _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 13 09:58:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14144 for ; Thu, 13 Feb 2003 09:58:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DF8NK26592 for nsis-archive@odin.ietf.org; Thu, 13 Feb 2003 10:08:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DF8Ap26565; Thu, 13 Feb 2003 10:08:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DF7fp26514 for ; Thu, 13 Feb 2003 10:07:41 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14078 for ; Thu, 13 Feb 2003 09:57:14 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h1DF0Xsv015624; Thu, 13 Feb 2003 07:00:33 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADG89174; Thu, 13 Feb 2003 07:00:44 -0800 (PST) Message-Id: <200302131500.ADG89174@mira-sjc5-c.cisco.com> To: sven.van_den_bosch@alcatel.be cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] session ID In-Reply-To: Message from sven.van_den_bosch@alcatel.be of "Thu, 13 Feb 2003 15:45:58 +0100." Date: Thu, 13 Feb 2003 10:00:44 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > 2. A question that comes to mind is whether the session ID would belong in > the NTLP or in the NSLP. It seems clear to me that it's not an either/or question. There's a question about whether or not the NTLP needs a session identifier for its own purposes, and that question is independent of the question of what an NSLP would need. Aside from that, in general I'm not overly fond of overloaded functionality in protocols. I believe there's a good case to be made for a session/flow/what-have-you identifier in the NTLP to simplify state management (imagine a case where you've got two different NSIS applications, say QoS and firewall, manipulating state for one data flow). It may also simplify message processing in cases where an NSIS-capable device doesn't support a particular NSIS application. Additionally, there may be differences in semantics. I would not like to see an NSLP session identifier constrained in its semantics by the NTLP layer. There may be issues around grouping, etc. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 13 10:15:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15361 for ; Thu, 13 Feb 2003 10:15:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DFPMs27505 for nsis-archive@odin.ietf.org; Thu, 13 Feb 2003 10:25:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DFPEp27484; Thu, 13 Feb 2003 10:25:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DFOKp27438 for ; Thu, 13 Feb 2003 10:24:20 -0500 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15191 for ; Thu, 13 Feb 2003 10:13:53 -0500 (EST) From: sven.van_den_bosch@alcatel.be Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id h1DFGsf16268; Thu, 13 Feb 2003 16:16:54 +0100 Subject: Re: [NSIS] session ID To: Melinda Shore Cc: nsis@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 13 Feb 2003 16:16:52 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/13/2003 16:16:54 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Melinda, Thanks for your reply. Please see my comments inline. Sven Melinda Shore @ietf.org on 13/02/2003 16:00:44 Sent by: nsis-admin@ietf.org To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: nsis@ietf.org Subject: Re: [NSIS] session ID > 2. A question that comes to mind is whether the session ID would belong in > the NTLP or in the NSLP. It seems clear to me that it's not an either/or question. There's a question about whether or not the NTLP needs a session identifier for its own purposes, and that question is independent of the question of what an NSLP would need. [Sven] OK. The question in that case should be rephrased as: does the NTLP need a session ID in addition to the NSLP's session ID and if yes what for. I have the impression the session ID is always tied to NSLP state. Aside from that, in general I'm not overly fond of overloaded functionality in protocols. I believe there's a good case to be made for a session/flow/what-have-you identifier in the NTLP to simplify state management (imagine a case where you've got two different NSIS applications, say QoS and firewall, manipulating state for one data flow). [Sven] At the interim meeting we discussed about lower/upper layer correlation and agreed we would limit any awareness of the coupling to the end (edge) nodes (at least for now) It may also simplify message processing in cases where an NSIS-capable device doesn't support a particular NSIS application. [Sven] Can you elaborate? The session ID is meant to identify existing session state in order to avoid e.g. double reservation. If the intermediate node has no NSLP (for that application) it does not maintain its application state and hence doesn't need the session ID. Additionally, there may be differences in semantics. I would not like to see an NSLP session identifier constrained in its semantics by the NTLP layer. There may be issues around grouping, etc. [Sven] Browsing through my interim meeting notes I found that of the three options we discussed - randomly generated session ID (globally unique enough to prevent random collisions) - cryptographically random (first + known only to participating nodes) - purpose-built keys (or similar asymmetric cryptography) the middle one was prefered because the incremental cost was minimal for a relevant additional benefit. In the case of (near) global uniqueness, would you be able to easily aggregate session IDs? Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 13 10:36:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15905 for ; Thu, 13 Feb 2003 10:36:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DFkFW29195 for nsis-archive@odin.ietf.org; Thu, 13 Feb 2003 10:46:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DFkBp29188; Thu, 13 Feb 2003 10:46:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DFjBp29153 for ; Thu, 13 Feb 2003 10:45:11 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15860 for ; Thu, 13 Feb 2003 10:34:44 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1DFcOSQ007364; Thu, 13 Feb 2003 07:38:24 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADG91531; Thu, 13 Feb 2003 07:38:23 -0800 (PST) Message-Id: <200302131538.ADG91531@mira-sjc5-c.cisco.com> To: sven.van_den_bosch@alcatel.be cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] session ID In-Reply-To: Message from sven.van_den_bosch@alcatel.be of "Thu, 13 Feb 2003 16:16:52 +0100." Date: Thu, 13 Feb 2003 10:38:22 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Well, obviously I'm missing a lot of context because I was not at the meeting and minutes have not been published. I haven't seen any decisions about layer split on the mailing list, which is where decisions are made. Clearly much will depend on the general approach to state management. There's still the question of whether an RSVP-like soft state approach to state management will be used or whether there will be persistent "connections" between nodes. I would not ask if the NTLP needs a session ID in addition to the NSLP's, but rather if the NTLP needs a session ID. There may, in fact, be NSIS applications which on their own don't require a session ID. I think it's very important, when talking about what to put where and how to manage state, to remember that we're talking about a fairly large number of potential applications with potentially very different semantics, whether it's something like tunnel endpoint discovery (query/response, no persistent state), NAT (persistent state, you need to find the outermost device), QoS (persistent state, topology information is a generally less important feature of the protocol), monitoring/testing (query/response, topology is interesting but not the primary concern), and so on, and that these applications may be running across the same nodes at the same time and may be trying to control policy on the same stream. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 13 10:50:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16117 for ; Thu, 13 Feb 2003 10:50:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DG0Ni29803 for nsis-archive@odin.ietf.org; Thu, 13 Feb 2003 11:00:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DG0Jp29795; Thu, 13 Feb 2003 11:00:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DFxPp29709 for ; Thu, 13 Feb 2003 10:59:25 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16080 for ; Thu, 13 Feb 2003 10:48:57 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h1DFpYiA019937 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 13 Feb 2003 10:51:35 -0500 (EST) Message-ID: <3E4BBF11.8000800@cs.columbia.edu> Date: Thu, 13 Feb 2003 10:51:45 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Melinda Shore CC: sven.van_den_bosch@alcatel.be, nsis@ietf.org Subject: Re: [NSIS] session ID References: <200302131538.ADG91531@mira-sjc5-c.cisco.com> In-Reply-To: <200302131538.ADG91531@mira-sjc5-c.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Clearly much will depend on the general approach to state > management. There's still the question of whether an > RSVP-like soft state approach to state management will be > used or whether there will be persistent "connections" > between nodes. I would not ask if the NTLP needs a session I think there is general agreement that this is not an "or", but an "and". As was discussed at the meeting, the use of persistent peer-to-peer connections does not at all contradict a soft-state model. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 13 16:20:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01958 for ; Thu, 13 Feb 2003 16:20:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1DLNPd21269 for nsis-archive@odin.ietf.org; Thu, 13 Feb 2003 16:23:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DLNJp21258; Thu, 13 Feb 2003 16:23:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1DLMop21198 for ; Thu, 13 Feb 2003 16:22:50 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01710 for ; Thu, 13 Feb 2003 16:18:59 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h1DLMK3U012026 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 13 Feb 2003 16:22:21 -0500 (EST) Message-ID: <3E4C0C96.5080605@cs.columbia.edu> Date: Thu, 13 Feb 2003 16:22:30 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sven.van_den_bosch@alcatel.be CC: nsis@ietf.org Subject: Re: [NSIS] session ID References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit sven.van_den_bosch@alcatel.be wrote: > Hi all, > > Upon reflection after the NSIS interim meeting, I have a few concerns > regarding the session ID (intended to be able to differentiate existing > session state from new state state, e.g. after a reroute or mobility > event): The main purpose, in my view, is to identify the state, so that one can easily distinguish one session from another session (that may well have the same NI/NR pair). If we want to allow multiple sessions between such NI/NR pairs, such an identifier is needed, even if we ignore the mobility issues. > > 1. We must realize that the session ID does not come for free. With only How much does it cost, in Euros? :-) > the flowspec present in the message, one would still have the option of > keeping only (forward/backward) routing state in the NEs and this can be > done per peer. With the session ID (which is necessarily per session), we No, this doesn't work as soon as you have multiple sessions between two NI/NR pairs. > are obliged to keep state on a much finer granularity. We may have been > assuming that per-flow state was going to be kept anyway, but other > solutions have already been described. You cannot just keep state per peer. For details, I suggest reading our BGRP work or the discussion on aggregation in the RNAP papers. If you have no other information and only the next hop (either forward or backward), how do you know where the hop-before-that or hop-after-that is? Example: A ---> B --- > C |-----> D If A sends a message to B that contains no information other than that, how does B know whether this should go to C or D? The state information is exactly the same in A for both C and D, so you have no chance to distinguish the state. Aggregation requires a funnel or sink-tree model, as far as we've been able to determine. I suspect that merging requests requires identification at a higher layer since it is probably application-specific. > > 2. A question that comes to mind is whether the session ID would belong in > the NTLP or in the NSLP. From discussion one might have inferred that it > would be the NTLP. I am not sure about this. I would say that the session It needs to be in NTLP, since it is required, as discussed above, to simply get the message from NI to NR along the chain of NEs. This has nothing to do with reservation state. NFs need it to maintain (and delete, after timeout) state. How would they know what state to delete without this? > ID refers to state linked to the NSLP (reservation state, ...) and it is > not obvious that it should be in the NTLP. A reason to put it in the NTLP > would be to allow state refresh without going up to the NSLP. If this is > the case we should make that explicit. personally, I don't think it is such > a great idea. How for instance, would one differentiate between a refresh > that requires new AAA (to check credit e.g.) and one that doesn't? The decision on re-authorization properly belongs to the NSLP. In my view of things, the NTLP hands up the NSLP object to the appropriate handler. The handler does its job and tells the NTLP one of two things: forward or error-stop here-return eror message, with a new blob of NSLP information. > > just my 2cc, My two cents (which are worth less than 2cc, unfortunately...). > Sven > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Feb 14 07:03:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18470 for ; Fri, 14 Feb 2003 07:03:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EC7av20468 for nsis-archive@odin.ietf.org; Fri, 14 Feb 2003 07:07:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EC7Rp20450; Fri, 14 Feb 2003 07:07:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EC6bp19792 for ; Fri, 14 Feb 2003 07:06:37 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18281 for ; Fri, 14 Feb 2003 07:02:29 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 14 Feb 2003 13:05:24 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id <14SSVL94>; Fri, 14 Feb 2003 13:05:16 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE23B338@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: sven.van_den_bosch@alcatel.be Cc: nsis@ietf.org Subject: AW: [NSIS] session ID Date: Fri, 14 Feb 2003 13:05:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Sven, if the NTLP handles the refresh, the refresh message simply carries the session ID. It doesn't repeat flow information nor does it carry any other service related information. Once further information is present, NTLP must forward it to NSLP, which will perform the necessary actions. So we have to refresh cases: - absolutely no change in state: NTLP resets soft state timer autonomuosly. - any change in state: NSLP triggers NTLP activity. Regards, Rudiger | How for instance, would one differentiate | between a refresh that requires new AAA | (to check credit e.g.) and one that doesn't? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Feb 14 12:03:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27371 for ; Fri, 14 Feb 2003 12:03:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1EH7XM08216 for nsis-archive@odin.ietf.org; Fri, 14 Feb 2003 12:07:33 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EH7Op08037; Fri, 14 Feb 2003 12:07:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EH5Mp07327 for ; Fri, 14 Feb 2003 12:05:22 -0500 Received: from [172.1.1.10] (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27219 for ; Fri, 14 Feb 2003 12:00:37 -0500 (EST) Received: from mail.carrieraccess.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 14 Feb 2003 10:04:22 -0700 Received: by newman.carrieraccess.com with Internet Mail Service (5.5.2653.19) id <148YS4XN>; Fri, 14 Feb 2003 10:04:15 -0700 Message-ID: From: "Avella, Alejandro" To: nsis@ietf.org Date: Fri, 14 Feb 2003 10:04:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative ; boundary="----_=_NextPart_001_01C2D44B.19B8EAA0" Subject: [NSIS] LAN QoS Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D44B.19B8EAA0 Content-Type: text/plain; charset="iso-8859-1" 1.- Is LAN QoS in NSIS scope? 2.- For example, is IEEE 802.1p/q considered by this working group for a end-to-end QoS solution? Alejandro ************************************************************************* This e-mail transmission, and any documents, files, or previous e-mail messages attached to it may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution, or use of any of the information contained in or attached to this transmission is strictly prohibited. If you have received this transmission in error, please immediately notify the sender by telephone or return e-mail and delete the original transmission and its attachments without reading or saving them in any manner. Thank you. ************************************************************************* ------_=_NextPart_001_01C2D44B.19B8EAA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LAN QoS

1.- Is LAN QoS in NSIS scope?   =
2.- For example, is IEEE 802.1p/q conside= red by this working group for a end-to-end QoS solution?   &= nbsp;  
Alejandro



************************************************************************* This e-mail transmission, and any documents, files, or previous
e-mail messages attached to it may contain information that is
confidential or legally privileged. If you are not the intended
recipient, or a person responsible for delivering it to the
intended recipient, you are hereby notified that you must not
read this transmission and that any disclosure, copying, printing,
distribution, or use of any of the information contained in or
attached to this transmission is strictly prohibited. If you have
received this transmission in error, please immediately notify the
sender by telephone or return e-mail and delete the original
transmission and its attachments without reading or saving them
in any manner. Thank you.
************************************************************************* ------_=_NextPart_001_01C2D44B.19B8EAA0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 18 18:39:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11625 for ; Tue, 18 Feb 2003 18:39:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1INjfJ04477 for nsis-archive@odin.ietf.org; Tue, 18 Feb 2003 18:45:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1INjap04455; Tue, 18 Feb 2003 18:45:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1INirp04393 for ; Tue, 18 Feb 2003 18:44:53 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11589 for ; Tue, 18 Feb 2003 18:38:34 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5R9ZC>; Tue, 18 Feb 2003 23:42:22 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41806AC073A@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Date: Tue, 18 Feb 2003 23:42:21 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] Transport functionality in the NTLP Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , 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. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 18 18:39:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11641 for ; Tue, 18 Feb 2003 18:39:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1INjhs04490 for nsis-archive@odin.ietf.org; Tue, 18 Feb 2003 18:45:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1INjcp04470; Tue, 18 Feb 2003 18:45:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1INiup04398 for ; Tue, 18 Feb 2003 18:44:56 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11592 for ; Tue, 18 Feb 2003 18:38:37 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5R9ZD>; Tue, 18 Feb 2003 23:42:25 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41806AC073B@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Date: Tue, 18 Feb 2003 23:42:24 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] consensus probe on one aspect of NTLP operation Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Dear all, It's clear that the signalling exchanges considered by NSIS can go a long way across a network, visiting a sequence of NSIS entities (NEs). The protocol stack carrying the signalling is divided into a common layer (the NTLP) and signalling application specific layer (an NSLP). I believe we have a roughly agreed working assumption (NB no claim of an official WG consensus) that the NTLP operates only between adjacent NEs ('hop-by-hop'), whereas any larger scope issues (including e2e aspects) are left to the NSLP. Note: the practical content of the 'hop-by-hop' statement is something like: When a signalling message is ready to be sent from one NE, it is given to the NTLP along with information about what flow it is for; it is then up to the NTLP to get it to the next NE along the path, where it is received and the responsibility of the NTLP ends. (The receiving NE may decide to forward the message directly, invoking the NTLP again; or, it may give the message to a signalling application for further processing which then generates another message to be sent via the NTLP.) In particular, the NTLP at a given NE does not use any knowledge about addresses/capabilities/status/etc. of any NEs other than its direct peers. If people have desires for NTLP functionality which are not covered by the previous paragraph, I'd very much appreciate it if they would say (a) specifically how it should be extended, and (b) why it is necessary. [So, I'd obviously be happy to get no relevant replies to this message. However, if people have better words for a definition, I'd be happy to see them.] Cheers, Robert H. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 18 22:32:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16727 for ; Tue, 18 Feb 2003 22:32:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1J3cBg20217 for nsis-archive@odin.ietf.org; Tue, 18 Feb 2003 22:38:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J3c0p20176; Tue, 18 Feb 2003 22:38:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J3aSp19320 for ; Tue, 18 Feb 2003 22:36:28 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16491 for ; Tue, 18 Feb 2003 22:30:02 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1J3XaB6015708; Tue, 18 Feb 2003 19:33:36 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADN42281; Tue, 18 Feb 2003 19:33:45 -0800 (PST) Message-Id: <200302190333.ADN42281@mira-sjc5-c.cisco.com> To: "Hancock, Robert" cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation In-Reply-To: Message from robert.hancock@roke.co.uk of "Tue, 18 Feb 2003 23:42:24 GMT." <76C92FBBFB58D411AE760090271ED41806AC073B@rsys002a.roke.co.uk> Date: Tue, 18 Feb 2003 22:33:44 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Robert, it's the chair's job to call consensus. I still don't know what the technical arguments are for departing from RSVP on this, and since the minutes from the interim meeting have not been posted those of us who were not there don't know what was discussed or presented. I'm happy with accumulating path state in the application, but I'm still highly not comfortable with accumulating routing state in the transport layer. This seems like a big step backwards to me. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 18 22:38:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16832 for ; Tue, 18 Feb 2003 22:38:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1J3iSk20513 for nsis-archive@odin.ietf.org; Tue, 18 Feb 2003 22:44:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J3iEp20504; Tue, 18 Feb 2003 22:44:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J3hFp20481 for ; Tue, 18 Feb 2003 22:43:15 -0500 Received: from mtiwmhc11.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16824 for ; Tue, 18 Feb 2003 22:36:50 -0500 (EST) Received: from cs.columbia.edu (72.indianapolis-13rh15rt.in.dial-access.att.net[12.84.248.72]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003021903403811100kcsm0e>; Wed, 19 Feb 2003 03:40:39 +0000 Message-ID: <3E52FC0F.5070208@cs.columbia.edu> Date: Tue, 18 Feb 2003 22:37:51 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Melinda Shore CC: "Hancock, Robert" , nsis@ietf.org Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation References: <200302190333.ADN42281@mira-sjc5-c.cisco.com> In-Reply-To: <200302190333.ADN42281@mira-sjc5-c.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Melinda, I suspect you have a somewhat different picture in mind. I'm not precisely sure what you mean by "routing state in the transport layer". At least in the discussions I recall, the state in the NTLP isn't all that different from what's in RSVP. Even with a non-raw-IP transport layer (below NTLP in my view of the world, within NTLP in the current fw; the term is overloaded, but I've said my piece on that...), the NTLP would keep the equivalent of next-hop/previous-hop state, except that this state might reference a TCP, SCTP or similar socket rather than an IP address. This does not imply any additional knowledge, at best, one (local) level of indirection (since the socket state would reference the next/previous hop by address). Henning Melinda Shore wrote: > Robert, it's the chair's job to call consensus. I still > don't know what the technical arguments are for departing > from RSVP on this, and since the minutes from the interim > meeting have not been posted those of us who were not there > don't know what was discussed or presented. I'm happy with > accumulating path state in the application, but I'm still > highly not comfortable with accumulating routing state in > the transport layer. This seems like a big step backwards > to me. > > Melinda > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 18 22:56:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17450 for ; Tue, 18 Feb 2003 22:56:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1J42Jb21692 for nsis-archive@odin.ietf.org; Tue, 18 Feb 2003 23:02:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J42Fp21680; Tue, 18 Feb 2003 23:02:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J41dp21576 for ; Tue, 18 Feb 2003 23:01:39 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17409 for ; Tue, 18 Feb 2003 22:55:13 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h1J3wvap008492; Tue, 18 Feb 2003 19:58:57 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADN44002; Tue, 18 Feb 2003 19:58:56 -0800 (PST) Message-Id: <200302190358.ADN44002@mira-sjc5-c.cisco.com> To: Henning Schulzrinne cc: "Hancock, Robert" , nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation In-Reply-To: Message from hgs@cs.columbia.edu of "Tue, 18 Feb 2003 22:37:51 EST." <3E52FC0F.5070208@cs.columbia.edu> Date: Tue, 18 Feb 2003 22:58:56 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Sockets don't come free. Depending on which OS you're running they don't even come cheaply. That's less of a consideration for QoS applications, perhaps, but it's something to keep in mind when thinking about applications in which per-flow information is not aggregatable and there are a lot of flows. Enterprise NAT is a good example because you've got to treat every flow that crosses the device and you've got potentially very wide fan-out to the next-hop devices participating in the application. At any rate it would be a help if the minutes from the interim meeting were posted to the mailing list. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 03:11:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15794 for ; Wed, 19 Feb 2003 03:11:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1J8HcQ17051 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 03:17:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J8HXp17043; Wed, 19 Feb 2003 03:17:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J8Gup17006 for ; Wed, 19 Feb 2003 03:16:56 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15783 for ; Wed, 19 Feb 2003 03:10:25 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Wed, 19 Feb 2003 09:14:04 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Feb 2003 09:14:00 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE23B355@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: robert.hancock@roke.co.uk Cc: nsis@ietf.org Subject: AW: [NSIS] Transport functionality in the NTLP Date: Wed, 19 Feb 2003 09:13:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1J8Gup17007 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit 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 nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 03:59:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16376 for ; Wed, 19 Feb 2003 03:59:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1J959F20402 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 04:05:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J956p20395; Wed, 19 Feb 2003 04:05:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1J94Yp20361 for ; Wed, 19 Feb 2003 04:04:34 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16367 for ; Wed, 19 Feb 2003 03:58:02 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1J91pKV003673; Wed, 19 Feb 2003 10:01:51 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVMF700; Wed, 19 Feb 2003 10:01:51 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Feb 2003 10:01:44 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB8E7@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: ddd1d4e3 9ffcebbb 7a95d2f4 00000138 From: "Georgios Karagiannis (ELN)" To: "'Melinda Shore'" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] consensus probe on one aspect of NTLP operation Date: Wed, 19 Feb 2003 10:01:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Melinda I agree with you! In my opinion, the only strong consensus and decisions that have been taken during the NSIS interim meeting, related to design considerations were: * in addition to the flow ID an additional globally unique ID is needed which has to be used by NTLP. This can be the session ID; * 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; * TCP/SCTP below NTLP can be a mode of operation. Other types of operation should be allowed. This depends on the used environment/scenario and also on the decission of if and where to implement features such as reliability, congestion control, flow control, non-duplication fragmentation of signaling messages, in the NSLP or below. * peer to peer security is needed; However, in secure autonomous domains this has not to be the case. The peer to peer security relation could be between edges and not between interior nodes. Best Regards, Georgios -----Original Message----- From: Melinda Shore [mailto:mshore@cisco.com] Sent: woensdag 19 februari 2003 4:59 To: Henning Schulzrinne Cc: Hancock, Robert; nsis@ietf.org Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation Sockets don't come free. Depending on which OS you're running they don't even come cheaply. That's less of a consideration for QoS applications, perhaps, but it's something to keep in mind when thinking about applications in which per-flow information is not aggregatable and there are a lot of flows. Enterprise NAT is a good example because you've got to treat every flow that crosses the device and you've got potentially very wide fan-out to the next-hop devices participating in the application. At any rate it would be a help if the minutes from the interim meeting were posted to the mailing list. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 04:58:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17473 for ; Wed, 19 Feb 2003 04:58:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JA4ah25286 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 05:04:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JA4Wp25277; Wed, 19 Feb 2003 05:04:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JA3fp25233 for ; Wed, 19 Feb 2003 05:03:41 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17437 for ; Wed, 19 Feb 2003 04:57:07 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h1JA0uR53237; Wed, 19 Feb 2003 11:00:57 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 94E4344A24; Wed, 19 Feb 2003 10:59:36 +0100 (CET) Date: Wed, 19 Feb 2003 11:02:03 +0100 From: Marcus Brunner Reply-To: marcus@brubers.org To: "Hancock, Robert" , nsis@ietf.org Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation Message-ID: <5501731.1045652523@[10.1.1.130]> In-Reply-To: <76C92FBBFB58D411AE760090271ED41806AC073B@rsys002a.roke.co.uk> References: <76C92FBBFB58D411AE760090271ED41806AC073B@rsys002a.roke.co.uk> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I believe we have a roughly agreed working assumption (NB no claim of an > official WG consensus) that the NTLP operates only between adjacent NEs > ('hop-by-hop'), whereas any larger scope issues (including e2e aspects) > are left to the NSLP. > I wonder what this assumption implies. E.g., does it mean that an acknowledgment of successful state setup always has to travel back the reverse path? IMHO it must NOT be excluded that an acknowledgement directly gets back to the NSIS Initiator along a potential different path. (And I am aware of the security problems, and reliability problems of that, but I would like to see this solved end-to-end as much as possible.) In general I like to see the end-to-end argument applied for signaling as much as possible. See more on the issue of transport functionality. Marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 05:21:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17988 for ; Wed, 19 Feb 2003 05:21:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JARIp27219 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 05:27:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JAREp27212; Wed, 19 Feb 2003 05:27:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JAQ3p27166 for ; Wed, 19 Feb 2003 05:26:03 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17958 for ; Wed, 19 Feb 2003 05:19:29 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1JANIAv020831; Wed, 19 Feb 2003 11:23:18 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVG0LCX; Wed, 19 Feb 2003 11:23:16 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Feb 2003 11:22:41 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB8EC@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: faecd941 9ffcebbb 7a95d2f4 00000138 From: "Georgios Karagiannis (ELN)" To: "'Hancock, Robert'" , nsis@ietf.org Subject: RE: [NSIS] consensus probe on one aspect of NTLP operation Date: Wed, 19 Feb 2003 11:22:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Robert >>I believe we have a roughly agreed working assumption >>(NB no claim of an official WG consensus) that the NTLP >> operates only between adjacent NEs ('hop-by-hop'), whereas >> any larger scope issues (including e2e aspects) are left to the NSLP. >> Note: the practical content of the 'hop-by-hop' statement is >> something like: When a signalling message is ready to be sent >> from one NE, it is given to the NTLP along with information about >> what flow it is for; it is then up to the NTLP to get it to the next >> NE along the path, where it is received and the responsibility of >> the NTLP ends. (The receiving NE may decide to forward the >> message directly, invoking the NTLP again; or, it may give the message >> to a signalling application for further processing which then generates >> another message to be sent via the NTLP.) In particular, the NTLP at a >> given NE does not use any knowledge about >> addresses/capabilities/status/etc. of any NEs other than its direct peers. In my opinion the main problem that we have at the moment, but also during the NSIS interim meeting is that we do not know what we want to mean by hop-by-hop protocol. I consider a protocol that uses an end-to-end, end-to-edge, edge-to-edge type of addressing not a hop-by-hop protocol. RSVP is in my opinion not a hop-by-hop protocol. Or am I missing something? Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 05:25:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18022 for ; Wed, 19 Feb 2003 05:25:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JAV9O27406 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 05:31:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JAV5p27399; Wed, 19 Feb 2003 05:31:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JAUtp27372 for ; Wed, 19 Feb 2003 05:30:55 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18018 for ; Wed, 19 Feb 2003 05:24:21 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1JASBKV001550; Wed, 19 Feb 2003 11:28:11 +0100 (MET) Received: from era.ericsson.se (E00104B7F41BB.ki.sw.ericsson.se [147.214.181.136]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVMHDKV; Wed, 19 Feb 2003 11:28:11 +0100 Message-ID: <3E535C39.B2A64362@era.ericsson.se> Date: Wed, 19 Feb 2003 11:28:09 +0100 X-Sybari-Trust: 8c994559 9ffcebbb 7a95d2f4 00000138 From: "Lars.Westberg" X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Geib, Ruediger" CC: robert.hancock@roke.co.uk, nsis@ietf.org Subject: Re: AW: [NSIS] Transport functionality in the NTLP References: <9F8582E37B2EE5498E76392AEDDCD3FE23B355@G8PQD.blf01.telekom.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit 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 > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 05:55:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18381 for ; Wed, 19 Feb 2003 05:55:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JB1OD29455 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 06:01:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JB1Jp29444; Wed, 19 Feb 2003 06:01:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JB0ap29401 for ; Wed, 19 Feb 2003 06:00:36 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18355 for ; Wed, 19 Feb 2003 05:54:03 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id h1JAvoR27397; Wed, 19 Feb 2003 11:57:50 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id h1JAvow02874; Wed, 19 Feb 2003 11:57:50 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id <1N879YZF>; Wed, 19 Feb 2003 11:57:49 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F034C88B8@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Lars.Westberg'" , "Geib, Ruediger" Cc: robert.hancock@roke.co.uk, nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP Date: Wed, 19 Feb 2003 11:56:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1JB0ap29402 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit 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:Lars.Westberg@era.ericsson.se] > Sent: Wednesday, February 19, 2003 11:28 AM > To: Geib, Ruediger > Cc: robert.hancock@roke.co.uk; nsis@ietf.org > 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 > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 05:58:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18455 for ; Wed, 19 Feb 2003 05:58:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JB46929562 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 06:04:06 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JB42p29540; Wed, 19 Feb 2003 06:04:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JB3Ep29515 for ; Wed, 19 Feb 2003 06:03:14 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18425 for ; Wed, 19 Feb 2003 05:56:41 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h1JB0TR54033; Wed, 19 Feb 2003 12:00:29 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 5382D2C9DF; Wed, 19 Feb 2003 11:59:09 +0100 (CET) Date: Wed, 19 Feb 2003 12:01:37 +0100 From: Marcus Brunner Reply-To: marcus@brubers.org To: "Hancock, Robert" , nsis@ietf.org Subject: Re: [NSIS] Transport functionality in the NTLP Message-ID: <9075179.1045656097@[10.1.1.130]> In-Reply-To: <76C92FBBFB58D411AE760090271ED41806AC073A@rsys002a.roke.co.uk> References: <76C92FBBFB58D411AE760090271ED41806AC073A@rsys002a.roke.co.uk> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On Dienstag, 18. Februar 2003 23:42 +0000 "Hancock, Robert" wrote: > 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) Here I would opt for d. I assume that the probability is already high without any mechnism in or below NTLP. Detect and handle the any drop end-to-end. > 3. Guaranteed delivery to next NSLP node with feedback on success - I > suggest (d) aggreed can be done in NSLP if needed. > 4. Bundling of small messages - I suggest (c), doing it has > only local significance This might be an optimization in certain cases. I would even say d) deal with it later if needed. > 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 I would asume that for environment, where security is not requiered this is not an issue. > 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) IMHO this depends again on whether NTLP is hop-by-hop only. If hop-by-hop only then d) should be done end-to-end. > 9. Security (confidentiality, integrity protection) - I suggest (a) or (b) > b) optional Marcus > > cheers, > > robert h. > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 05:58:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18468 for ; Wed, 19 Feb 2003 05:58:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JB47G29575 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 06:04:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JB43p29555; Wed, 19 Feb 2003 06:04:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JB3ip29522 for ; Wed, 19 Feb 2003 06:03:44 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18440 for ; Wed, 19 Feb 2003 05:57:11 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1JB0xAv001382; Wed, 19 Feb 2003 12:00:59 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVG0XF4; Wed, 19 Feb 2003 12:00:58 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Feb 2003 12:00:52 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB8ED@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 76e5fac4 9ffcebbb 7a95d2f4 00000138 From: "Georgios Karagiannis (ELN)" To: "'Hancock, Robert'" , nsis@ietf.org Subject: RE: [NSIS] Transport functionality in the NTLP Date: Wed, 19 Feb 2003 12:00:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , 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:robert.hancock@roke.co.uk] Sent: woensdag 19 februari 2003 0:42 To: nsis@ietf.org 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. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 06:06:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18608 for ; Wed, 19 Feb 2003 06:06:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JBCHq30671 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 06:12:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JBCEp30659; Wed, 19 Feb 2003 06:12:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JBBLp30621 for ; Wed, 19 Feb 2003 06:11:22 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18564 for ; Wed, 19 Feb 2003 06:04:48 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id h1JB8ZR05721; Wed, 19 Feb 2003 12:08:36 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id h1JB8Zw15810; Wed, 19 Feb 2003 12:08:35 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id <1N879Y86>; Wed, 19 Feb 2003 12:08:35 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F034C88BA@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'marcus@brubers.org'" , "Hancock, Robert" , nsis@ietf.org Subject: RE: [NSIS] consensus probe on one aspect of NTLP operation Date: Wed, 19 Feb 2003 12:08:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi marcus! please see my comment inline: > > > I believe we have a roughly agreed working assumption (NB > no claim of an > > official WG consensus) that the NTLP operates only between > adjacent NEs > > ('hop-by-hop'), whereas any larger scope issues (including > e2e aspects) > > are left to the NSLP. > > > > I wonder what this assumption implies. > E.g., does it mean that an acknowledgment of successful state > setup always > has to travel back the reverse path? that is not necessarily implied. from a practical point of view it is, however, highly suggest. if you transmit messages from intermediate nodes along the path to the initiator directly then they have to experience some sort of security protection. this prevents that someone on the internet floods you with bogus messages which trigger some action from your side. please take a look at "Generalized MPLS Signaling - RSVP-TE Extensions" document. there they define a notify message which is transmitted from an intermediate node to the end host. as described in the security section (by steve bellovin) this requires a different security protection (ipsec is suggested there). hence in practice you only have two options: a) you transmit notifies on a regular basis between the nodes which justifies the ipsec establishment (which is not cheap) b) you only transmit notifies which do not require protection (i.e. they are unimportant - no action caused). ciao hannes IMHO it must NOT be > excluded that an > acknowledgement directly gets back to the NSIS Initiator > along a potential > different path. (And I am aware of the security problems, and > reliability > problems of that, but I would like to see this solved > end-to-end as much as > possible.) > > In general I like to see the end-to-end argument applied for > signaling as > much as possible. See more on the issue of transport functionality. > > Marcus > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 06:26:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19033 for ; Wed, 19 Feb 2003 06:26:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JBWOb31786 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 06:32:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JBWKp31779; Wed, 19 Feb 2003 06:32:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JBVJp31691 for ; Wed, 19 Feb 2003 06:31:19 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19009 for ; Wed, 19 Feb 2003 06:24:46 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h1JBSYR54389; Wed, 19 Feb 2003 12:28:34 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id D421C43D09; Wed, 19 Feb 2003 12:27:13 +0100 (CET) Date: Wed, 19 Feb 2003 12:29:38 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: Tschofenig Hannes , "Hancock, Robert" , nsis@ietf.org Subject: RE: [NSIS] consensus probe on one aspect of NTLP operation Message-ID: <10759982.1045657778@[10.1.1.130]> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F034C88BA@mchp905a.mch.sbs.de> References: <2A8DB02E3018D411901B009027FD3A3F034C88BA@mchp905a.mch.sbs.de> X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >> I wonder what this assumption implies. >> E.g., does it mean that an acknowledgment of successful state >> setup always >> has to travel back the reverse path? > > that is not necessarily implied. > > from a practical point of view it is, however, highly suggest. if you > transmit messages from intermediate nodes along the path to the initiator > directly then they have to experience some sort of security protection. > this prevents that someone on the internet floods you with bogus messages > which trigger some action from your side. The example I have been using is not from intermediate nodes but from the other end (typically the NSIS responder). > > please take a look at "Generalized MPLS Signaling - RSVP-TE Extensions" > document. there they define a notify message which is transmitted from an > intermediate node to the end host. as described in the security section > (by steve bellovin) this requires a different security protection (ipsec > is suggested there). > > hence in practice you only have two options: > > a) you transmit notifies on a regular basis between the nodes which > justifies the ipsec establishment (which is not cheap) > b) you only transmit notifies which do not require protection (i.e. they > are unimportant - no action caused). And some of us want to run the protocol in narrow scoped environments. And typically you might already have a security association between the endpoints, which could be used again here. Marcus > ciao > hannes > > > IMHO it must NOT be >> excluded that an >> acknowledgement directly gets back to the NSIS Initiator >> along a potential >> different path. (And I am aware of the security problems, and >> reliability >> problems of that, but I would like to see this solved >> end-to-end as much as >> possible.) >> >> In general I like to see the end-to-end argument applied for >> signaling as >> much as possible. See more on the issue of transport functionality. >> >> Marcus >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 personal home page: http://www.brubers.org/marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 07:03:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19888 for ; Wed, 19 Feb 2003 07:03:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JC9YM02822 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 07:09:34 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JC9Lp02801; Wed, 19 Feb 2003 07:09:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JC8Bp02724 for ; Wed, 19 Feb 2003 07:08:11 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19859 for ; Wed, 19 Feb 2003 07:01:36 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id h1JC5OH28528; Wed, 19 Feb 2003 13:05:24 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id h1JC5Nw21823; Wed, 19 Feb 2003 13:05:23 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id <1N879ZZF>; Wed, 19 Feb 2003 13:05:22 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F034C88BB@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'brunner@ccrle.nec.de'" , "Hancock, Robert" , nsis@ietf.org Subject: RE: [NSIS] consensus probe on one aspect of NTLP operation Date: Wed, 19 Feb 2003 13:05:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi marcus! > > The example I have been using is not from intermediate nodes > but from the > other end (typically the NSIS responder). if it is only end-to-end - without addressing intermediate nodes at all then it should not be part of an nsis protocol. > > > > > please take a look at "Generalized MPLS Signaling - RSVP-TE > Extensions" > > document. there they define a notify message which is > transmitted from an > > intermediate node to the end host. as described in the > security section > > (by steve bellovin) this requires a different security > protection (ipsec > > is suggested there). > > > > hence in practice you only have two options: > > > > a) you transmit notifies on a regular basis between the nodes which > > justifies the ipsec establishment (which is not cheap) > > b) you only transmit notifies which do not require > protection (i.e. they > > are unimportant - no action caused). > > And some of us want to run the protocol in narrow scoped environments. in certain environment it might be possible to have a more simplified version of security. but you have to design the protocol in such a way that the more difficult usage scenarios are also addressed. simply ignoring message protection would be the wrong choice. > > And typically you might already have a security association > between the > endpoints, which could be used again here. mobile ip people also thought this in the beginning. but then...... ciao hannes > > Marcus > > > ciao > > hannes > > > > > > IMHO it must NOT be > >> excluded that an > >> acknowledgement directly gets back to the NSIS Initiator > >> along a potential > >> different path. (And I am aware of the security problems, and > >> reliability > >> problems of that, but I would like to see this solved > >> end-to-end as much as > >> possible.) > >> > >> In general I like to see the end-to-end argument applied for > >> signaling as > >> much as possible. See more on the issue of transport functionality. > >> > >> Marcus > >> > >> > >> _______________________________________________ > >> nsis mailing list > >> nsis@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nsis > >> > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > Phone: +49 (0) 6221 905 11 29 > personal home page: http://www.brubers.org/marcus > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 07:42:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22595 for ; Wed, 19 Feb 2003 07:42:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JCmJO06010 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 07:48:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JCmFp05995; Wed, 19 Feb 2003 07:48:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JCljp05974 for ; Wed, 19 Feb 2003 07:47:45 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22525 for ; Wed, 19 Feb 2003 07:41:09 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1JCiwKV013465; Wed, 19 Feb 2003 13:44:58 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVM2GCC; Wed, 19 Feb 2003 13:44:58 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Feb 2003 13:44:23 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB8EE@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 2d3a0941 9ffcebbb 7a95d2f4 00000138 From: "Georgios Karagiannis (ELN)" To: "'Tschofenig Hannes'" Cc: nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP Date: Wed, 19 Feb 2003 13:44:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1JCljp05975 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit 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:Hannes.Tschofenig@mchp.siemens.de] Sent: woensdag 19 februari 2003 11:57 To: Lars Westberg (EAB); Geib, Ruediger Cc: robert.hancock@roke.co.uk; nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP 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:Lars.Westberg@era.ericsson.se] > Sent: Wednesday, February 19, 2003 11:28 AM > To: Geib, Ruediger > Cc: robert.hancock@roke.co.uk; nsis@ietf.org > 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 > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 07:45:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22785 for ; Wed, 19 Feb 2003 07:45:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JCp8f06216 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 07:51:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JCp4p06201; Wed, 19 Feb 2003 07:51:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JCoNp06146 for ; Wed, 19 Feb 2003 07:50:23 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22646 for ; Wed, 19 Feb 2003 07:43:47 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1JClaAv029783; Wed, 19 Feb 2003 13:47:36 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVJAD6L; Wed, 19 Feb 2003 13:47:36 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Feb 2003 13:47:01 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB8EF@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 8d469406 9ffcebbb a5ee123c 00000138 From: "Georgios Karagiannis (ELN)" To: "Georgios Karagiannis (ELN)" , "'Tschofenig Hannes'" Cc: nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP Date: Wed, 19 Feb 2003 13:47:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1JCoOp06147 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit 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: nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP 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:Hannes.Tschofenig@mchp.siemens.de] Sent: woensdag 19 februari 2003 11:57 To: Lars Westberg (EAB); Geib, Ruediger Cc: robert.hancock@roke.co.uk; nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP 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:Lars.Westberg@era.ericsson.se] > Sent: Wednesday, February 19, 2003 11:28 AM > To: Geib, Ruediger > Cc: robert.hancock@roke.co.uk; nsis@ietf.org > 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 > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 08:50:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24905 for ; Wed, 19 Feb 2003 08:50:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JDuMt10922 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 08:56:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JDuIp10915; Wed, 19 Feb 2003 08:56:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JDtXp10885 for ; Wed, 19 Feb 2003 08:55:33 -0500 Received: from thoth.sbs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24891 for ; Wed, 19 Feb 2003 08:48:55 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id h1JDqiP19532; Wed, 19 Feb 2003 14:52:44 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id h1JDqhw11218; Wed, 19 Feb 2003 14:52:43 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id <1N8798JH>; Wed, 19 Feb 2003 14:52:42 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F034C88C1@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Georgios Karagiannis (ELN)'" Cc: nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP Date: Wed, 19 Feb 2003 14:52:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1JDtXp10886 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi georgios > Hi Hannes > > This is not about applications that demand limited transport layer > functionalities, but it is about environments and scenarios. ok, i reformulate it. how about: applications, 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 i sometimes have the impression that this is more like a feeling than based on solid grounds. > * 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! 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 > > > Best Regards, > Georgios > > > -----Original Message----- > From: Tschofenig Hannes [mailto:Hannes.Tschofenig@mchp.siemens.de] > Sent: woensdag 19 februari 2003 11:57 > To: Lars Westberg (EAB); Geib, Ruediger > Cc: robert.hancock@roke.co.uk; nsis@ietf.org > Subject: RE: AW: [NSIS] Transport functionality in the NTLP > > > 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:Lars.Westberg@era.ericsson.se] > > Sent: Wednesday, February 19, 2003 11:28 AM > > To: Geib, Ruediger > > Cc: robert.hancock@roke.co.uk; nsis@ietf.org > > 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 > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 08:53:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24967 for ; Wed, 19 Feb 2003 08:53:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JDx7b11070 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 08:59:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JDx3p11059; Wed, 19 Feb 2003 08:59:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JDwXp11015 for ; Wed, 19 Feb 2003 08:58:33 -0500 Received: from thoth.sbs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24946 for ; Wed, 19 Feb 2003 08:51:55 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id h1JDtiP22140; Wed, 19 Feb 2003 14:55:44 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id h1JDthw15489; Wed, 19 Feb 2003 14:55:43 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id <1N8798KY>; Wed, 19 Feb 2003 14:55:42 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F034C88C2@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Georgios Karagiannis (ELN)'" Cc: nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP Date: Wed, 19 Feb 2003 14:55:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1JDwXp11016 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit hi georgios i have difficulties to see your arguments agains peer-to-peer addressing. they have nothing todo with the wireless network. ciao hannes > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: Wednesday, February 19, 2003 1:47 PM > To: Georgios Karagiannis (ELN); Tschofenig Hannes > Cc: nsis@ietf.org > Subject: RE: AW: [NSIS] Transport functionality in the NTLP > > > 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: nsis@ietf.org > Subject: RE: AW: [NSIS] Transport functionality in the NTLP > > > 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:Hannes.Tschofenig@mchp.siemens.de] > Sent: woensdag 19 februari 2003 11:57 > To: Lars Westberg (EAB); Geib, Ruediger > Cc: robert.hancock@roke.co.uk; nsis@ietf.org > Subject: RE: AW: [NSIS] Transport functionality in the NTLP > > > 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:Lars.Westberg@era.ericsson.se] > > Sent: Wednesday, February 19, 2003 11:28 AM > > To: Geib, Ruediger > > Cc: robert.hancock@roke.co.uk; nsis@ietf.org > > 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 > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 09:01:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25171 for ; Wed, 19 Feb 2003 09:01:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JE7N612139 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 09:07:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JE7Ap11850; Wed, 19 Feb 2003 09:07:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JE6pp11476 for ; Wed, 19 Feb 2003 09:06:51 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25155 for ; Wed, 19 Feb 2003 09:00:13 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1JE41KV007928; Wed, 19 Feb 2003 15:04:01 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVM28NV; Wed, 19 Feb 2003 15:04:01 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Feb 2003 15:03:54 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB8F1@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: be642ebb 9ffcebbb 7a95d2f4 00000138 From: "Georgios Karagiannis (ELN)" To: "'Tschofenig Hannes'" Cc: nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP Date: Wed, 19 Feb 2003 15:03:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1JE6pp11477 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Hannes > 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 >> 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!!! > * the wired part of a cellular system that does not need these features. > regarding end to end addressing, use the same addressing > procedures as RSVP, > since they are working fine! [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!!!! Actually the goal of starting NSIS was to solve QoS issues in wireless scenarios. Please do not forget this!!!! Other types of scenarios could also use NSIS, but in my opinion NSIS should at least satisfy the requirements imposed by wireless scenarios!!! Best Regards, Georgios > > Best Regards, > Georgios > > > -----Original Message----- > From: Tschofenig Hannes [mailto:Hannes.Tschofenig@mchp.siemens.de] > Sent: woensdag 19 februari 2003 11:57 > To: Lars Westberg (EAB); Geib, Ruediger > Cc: robert.hancock@roke.co.uk; nsis@ietf.org > Subject: RE: AW: [NSIS] Transport functionality in the NTLP > > > 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:Lars.Westberg@era.ericsson.se] > > Sent: Wednesday, February 19, 2003 11:28 AM > > To: Geib, Ruediger > > Cc: robert.hancock@roke.co.uk; nsis@ietf.org > > 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 > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 09:05:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25246 for ; Wed, 19 Feb 2003 09:05:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JEBJL12480 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 09:11:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JEBFp12468; Wed, 19 Feb 2003 09:11:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JEA0p12414 for ; Wed, 19 Feb 2003 09:10:01 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25207 for ; Wed, 19 Feb 2003 09:03:22 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1JE7BKV008765; Wed, 19 Feb 2003 15:07:11 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVM293H; Wed, 19 Feb 2003 15:07:11 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Feb 2003 15:07:04 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB8F2@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: ec58fc37 9ffcebbb 7a95d2f4 00000138 From: "Georgios Karagiannis (ELN)" To: "'Tschofenig Hannes'" Cc: nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP Date: Wed, 19 Feb 2003 15:06:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1JEA1p12418 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit 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:Hannes.Tschofenig@mchp.siemens.de] Sent: woensdag 19 februari 2003 14:56 To: Georgios Karagiannis (ELN) Cc: nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP hi georgios i have difficulties to see your arguments agains peer-to-peer addressing. they have nothing todo with the wireless network. ciao hannes > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: Wednesday, February 19, 2003 1:47 PM > To: Georgios Karagiannis (ELN); Tschofenig Hannes > Cc: nsis@ietf.org > Subject: RE: AW: [NSIS] Transport functionality in the NTLP > > > 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: nsis@ietf.org > Subject: RE: AW: [NSIS] Transport functionality in the NTLP > > > 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:Hannes.Tschofenig@mchp.siemens.de] > Sent: woensdag 19 februari 2003 11:57 > To: Lars Westberg (EAB); Geib, Ruediger > Cc: robert.hancock@roke.co.uk; nsis@ietf.org > Subject: RE: AW: [NSIS] Transport functionality in the NTLP > > > 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:Lars.Westberg@era.ericsson.se] > > Sent: Wednesday, February 19, 2003 11:28 AM > > To: Geib, Ruediger > > Cc: robert.hancock@roke.co.uk; nsis@ietf.org > > 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 > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 09:18:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25516 for ; Wed, 19 Feb 2003 09:18:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JEOMj13226 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 09:24:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JEOFp13132; Wed, 19 Feb 2003 09:24:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JENEp13053 for ; Wed, 19 Feb 2003 09:23:14 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25459 for ; Wed, 19 Feb 2003 09:16:36 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1JEJD219863 for ; Wed, 19 Feb 2003 16:19:13 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 19 Feb 2003 16:20:24 +0200 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Feb 2003 16:20:22 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Feb 2003 16:20:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 19 Feb 2003 16:20:22 +0200 Message-ID: Thread-Topic: [NSIS] Remote participation in NSIS interim meeting Thread-Index: AcLORiBzwWEgydFZSPKNC8wtlNct/gJ12RHw To: X-OriginalArrivalTime: 19 Feb 2003 14:20:22.0718 (UTC) FILETIME=[09F2A5E0:01C2D822] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1JENEp13054 Subject: [NSIS] raw interim meeting minutes Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, I apologize for the delay, I've been out with the flu. I'm sending the raw minutes so that folks who weren't at the meeting can follow what was discussed. I will edit them and send them out. Also, I'll post a link for the presentations, probably by Friday. Thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 09:18:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25530 for ; Wed, 19 Feb 2003 09:18:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JEOSh13240 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 09:24:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JEOKp13214; Wed, 19 Feb 2003 09:24:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JENQp13078 for ; Wed, 19 Feb 2003 09:23:26 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25490 for ; Wed, 19 Feb 2003 09:16:48 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1JEJQ220027 for ; Wed, 19 Feb 2003 16:19:26 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 19 Feb 2003 16:20:37 +0200 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Feb 2003 16:20:36 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Feb 2003 16:20:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 19 Feb 2003 16:20:33 +0200 Message-ID: Thread-Topic: Slides Thread-Index: AcLSHQrXtXcdF7IRR7iwH2SpfBVJ8wGATqng To: X-OriginalArrivalTime: 19 Feb 2003 14:20:33.0687 (UTC) FILETIME=[107C6270:01C2D822] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1JENQp13079 Subject: [NSIS] Some slides from the Interim meeting Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit can be found here: http://www.cs.columbia.edu/~hgs/nsis/ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 09:18:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25543 for ; Wed, 19 Feb 2003 09:18:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JEOTg13253 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 09:24:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JEOHp13157; Wed, 19 Feb 2003 09:24:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JENHp13059 for ; Wed, 19 Feb 2003 09:23:17 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25464 for ; Wed, 19 Feb 2003 09:16:37 -0500 (EST) From: john.loughney@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1JEJF219891 for ; Wed, 19 Feb 2003 16:19:15 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 19 Feb 2003 16:20:26 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Feb 2003 16:20:26 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Feb 2003 16:20:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 19 Feb 2003 16:20:25 +0200 Message-ID: Thread-Topic: [NSIS] Internet access at NSIS interim meeting Thread-Index: AcLOst3w7Bs+PGxYSRKH8h5EGOeaXAJaxl2w To: X-OriginalArrivalTime: 19 Feb 2003 14:20:25.0826 (UTC) FILETIME=[0BCCE420:01C2D822] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1JENHp13060 Subject: [NSIS] Minutes from Monday Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit NSIS interim meeting (Monday February 10) Attendants: Marcus Brunner, Ruediger Geib, Hans Lippitsch, Hannes Tschofenig, Henning Schulzrinne, Robert Hancock, Kwok Ho Chan, Ping Pan, Joachim Hillbrandt, Janne Rinne, and others Minute Taker: Hannes Tschofenig; Sven van den Bosch Agenda: WG update skipped Agenda Bashing skipped Introduction of the participants see participants list Markus Brunner: Requirements update John create an open issues list for NSIS: http://www-nrc.nokia.com/sua/nsis/nsis-issues.htm Markus went through that list and addresses each open item Markus: Requirements draft is intentionally kept abstract. Issue 1: ACTION: Remove text 5.1.5 and check exclusion section REASON: out-of-scope Issue 2: DISCUSSION: Henning: The requirements and the framework document should not be conflicting. Referring to the framework is possible. Term is never mentioned in the document. DISCUSSION: There are no requirements about sender- or receiver initiated signaling. 5.6.2 (Flexibility in the placement of the NSIS Initiator) is related to this. Two issues: - Directionality - Placement Henning: State maintenance and setup Signaling protocol does - control protocol which visits the path along the data path (or follows it roughly) ~ where is goes - establishes/modify/remove state at some nodes (in most cases - it could also only query) * state necessary for the layer split (route messages from a to b) * state for the application state (e.g. midcom, QoS, etc.) state definition: sticks around after the packet is gone active networking is such an example (no resource in the traditional sense) should there be a generic protocol requirements robert: how far do we want the requirements draft to go? making the requirements document independently of any type of application is a very hard job. proposal: requirements draft is generic (introduction) but the examples are qos driven ACTION: remove sender / receiver initiated signaling definitions / reference 5.6.2 what is intended. It should be tried to a definition of state. Issue 3: 5.2.2 DISCUSSION: Henning: It is only a matter of how closely on the data path (not on-path / off-path) Testable definition: a) same "virtual" interfaces b) same ASes (these are the only terms defined for the internet routing architecture) we could use framework definition in section 3.1.1 / path couples - path decoupled RSVP-TE uses RSVP in the reverse order (signaling establishes routing) Robert: Look into the framework draft and use definition there. must support path-coupled, should not exclude path-decoupled. there is no term on-path (only path-coupled)! ACTION: The agreement is to use the framework terminology and definitions of 'path-coupled' and 'path-decoupled'. The requirement then becomes. 'The protocol MUST support path-coupled and SHOULD NOT exclude path-decoupled signaling'. Issue 4: 5.3.4 DISCUSSION: Henning: What is a request for service? More an application issue? This requirement is very QoS biased. Message returned has two objects: a) Confirms the establishment of resource reservation b) Reliability requirement : NSIS message has been transmitted somewhere (and we got a return message back) There is no clear understanding of the requirement. Henning: Confirmation of service execution / Configuration of reliability Hence this requirement can be split into two separate requirements. Robert: This requirement cannot be seen in isolation (5.10.1). Reliability does not need to be addressed. It should be possible to obtain indication of success/failure. Requirement for a specific service layer (since there it only means something). It should be possible to request a response message. Who has to answer the question. ACTION: Shuffle things around. There are two aspects to the proposed text: a. confirmation of delivery b. confirmation of service-related action (e.g. installing state) The first one is covered by 5.10.1. It is proposed to delete the text proposed for this issue (5.3.4) but insert a requirement covering the second aspects after 5.10.2. Ruediger will provide text. Issues 5: Meaning is somewhat vague. Marcus: - RSVP bundling type of requirement - Not about aggregation. Paragraph is QoS reservation centric. Make it more generic? change reservation to flow? ACTION: replace "MUST NOT know" with "need not to know" Remove second half of the last sentence. Issue 6: ACTION: no conclusion - skipped Issue 7: UMTS access session ACTION: already done - agreed in the 3gpp. Issue 8: Definition of RMF ACTION: agreed Issue 9: Provisioning text ACTION: remove text about provisioning Issue 10: QoS technology ACTION: remove Issue 11: Clarification on NSIS usage ACTION: send email to requestor of item and ask where to place the text add middlebox communication as an example of a further NSIS signaling application Issue 12: Requirement on routing NSIS does not interfere with routing. Henning: determination of next data node selection is not done by NSIS (forwarding is done by someone else) (next hop of the data packet) Background: NSIS is not a QoS routing protocol; relationship to load balancing Relationship to 5.9.6 (non-traditional routing) ACTION: Replace text with "NSIS assumes layer 3 routing and the determination of next data node selection is not done by NSIS". Issue 13: Clarification ACTION: accept Issue 14: 5.2.2 ACTION: nothing. the text has changed already. some minor editorial issues Issue 16: ACTION: accepted Issues 17: ACTION: Remove paragraph Issues 18: ACTION: remove Issue 19: ACTION: remove point 7 of protection of non-signaling messages A requirement for encapsulation is covered with the flow identification requirement (5.9.1) Issue 20: 5.1.1 ACTION: remove Issue 21: 5.3.3 (NSIS SHOULD allow for sending notifications upstream) ACTION: don't change Issue 22: ACTION: change accepted Issue 23: ACTION: editorial changes Issue 24: 5.1.7 DISCUSSION: Problem caused through terminology of two-layer split in the framework document. framework: a) signaling application (qos midcom) b) user application (for user application triggering something). Henning: meaning is confusing. Opaque application information MAY get transported in the signaling message, without being handled in the network. Two issues: a) only end-to-end object (why is it carried in NSIS?) b) only interpreted by some entities (the nsis protocol should be able to pass around objects which are interpreted only by some nodes) ACTION: remove 5.1.7 add paragraph from above (see b): something like: "NSIS should be able to carry opaque objects. These are objects that are only interpreted at some NSIS-capable nodes." Issue 25: DISCUSSION: Should the requirements document reference the framework document./ Henning: Informative reference is not going to block. ACTION: add the reference as an informative reference Generic Requirements Discussion Henning: comment the requirements draft. Indicate that some sections are generic whereas others are specific to an application Add a separate section to cover specific issues of midcom, qos, etc. The terminology "reservation" used in the requirements document has a QoS bias. The requirement should talk about state information. Henning: Question: Identify requirements that are application signaling specific Robert: For an outsider the document is not too easy to understand. There should be a uniform label which is assigned to each section. People fear that this activity stalls the progress of the document./ Henning: Possible options: a) labeling (applicability statement) b) grouping it to sections What is the requirements document: - working document to capture discussion (people might argue with it as a design decision) - outsiders to understand Possible outcomes of a labeling process: - for some things it might be very clear - some things we don't understand (so vage to be useless) Problems: - Vague document -> danger of wrong interpretation - if we are not able as a working group then the req. needs to be dropped or re-defined. Henning: => Homework exercise: go through the document and label different sections. 2. Security threats for NSIS - update (Hannes) Hannes goes through his presentation. Issues: Agreement on the minimum security requirements (authentication, integrity and replay protection) on a peer-to-peer basis Should key management be addressed by NSIS protocols? -> yes Discussion on whether there should be the assumption that the next NSIS peer is known. It cannot be assumed in all circumstances. There are some NSIS application (e.g. middlebox communication) and some environments where such an assumption cannot be made. Discussion on end-to-end security -> End-to-end security is an NSLP concept. It has to be used only if the semantic of the object requires it. In general NSIS should not be used to solely exchange information end-to-end. As a criteria one could imagine that the protected objects is not visible to the intermediate nodes. If this object is not relevant for NSIS intermediate nodes then it should be exchanged with an end-to-end protocol only (such as SIP, http, etc.) Discussion on mobility: it was agreed that mobility is an open issue that needs to be tackled in the framework context first. Two questions need to be addressed: a. is the session identifier useful as mechanism (for security, ...) b. if security-relevant, what do we need to do to protect it (ill-defined for now: who sets it, ...) Implications of Trust Relationships for NSIS Signaling (Hannes) Presentation addresses middlebox signaling (firewall; NAT) Goal: figure out difference between QoS and middlebox signaling (related to TIST) Hannes goes through the presentation What happens next? Hannes: we talked about extending the document (with Cedric Aoun) and making it more generic Is the goal to come up with requirements specific to for a middlebox communication NSLP application? Cedric: we already have requirements and framework in midcom. The proposal is to have an NSLP for midcom, and look at NTLP issues from a midcom point-of-view. Is the CASP document contradicting/duplicating/different from work done in the midcom working group? -> It is a good start but need to be more generic and add some things to it. Remark: The midcom wg tries to solve the problem with a different focus and different working assumptions (path decoupled vs. path decoupled signaling) Henning: Since the work in the midcom group is different we should not use the term midcom but rather 'middlebox configuration' to avoid confusion Remark: Would like to capture specificity of firewall/NAT to reduce scope. We are going to look around for other applications on wednesday morning NSIS AAA issues (Hannes) Hannes goes through the presentation Q: Do you assume per-flow accounting between domains? That will certainly not be the case. Remark: Parkway is logically not that different from roaming user where all nodes can be visited networks. Remark: Transit providers do not have the AAA infrastructure (per-flow, roaming, ...) required for the Parkway model Q: Why is Parkway model even considered? A: Because VoIP uses clearing house and because at least it allows for fixed local prices Q: On which layer does it apply? A: The upper layer Remark: The impact on NTLP is the addition of another dimension to data sender/receiver, signaling initiator/responder, now another one is added (initiator/receiver charged) Q: Have you looked at DoS attacks for security? A: This is part of the threat analysis Remark: The AAA consideration are important from trust relations point of view Framework presentation (Robert) Request for mobility and signaling application space (i.e. other non-qos applications) release for next ietf (sfo) Key Issue 1: - We don't have to put all generic protocols in the ntlp. - Capturing the split with an api? Key Issues 2: - not much discussion on the mobility issues (no conclusions - what and how todo) interaction with seamoby activities is unclear Key Issues 3: Shift toward multi-application protocol. What needs to be done to prevent chaos? Issue 1: Sender-/Receiver definition is unclear NI/NF/NR become NSLP concepts Issue 2: Who is allowed what todo for a reservation? Can the network change something? Is only the initiator allowed to change something? It is about authorization! Proxy: Node along the path that "return" signaling message (case b) or node which acts on behalf of the sender (case a). a) Proxy b) Proxy Sender NI NF NF NF NR Receiver The requirements/framework document already allows (a). Case (b) raises more discussion. The term of proxy is somewhat a confusion attractor. The term proxy is also (by some people) used as a synonym for a bandwidth broker. Issue 3: Should entities only related to their neighboring peers? Should the security go over more than a single hop (notification handling - though various hops or to the remote end, Properties of the session identifier: - constant over the lifetime of a session - selected "magically" by the initiator Functionality of the NTLP is a layer split discussion. Issue 4: Addressing (peer-to-peer or end-to-end) Certain messages are end-to-end (e.g. discovery messages) Issue 5: Flow Identification What parameters to use? Current assumption: something minimal is at the NTLP HoA for MIP support is currently ruled out. Problems with policy based forwarding will be explained. Flow Identification at the NLSP requires that routing is done at the application layer (also NAT handling) Relationship with session identifier pointed out. Issue 6: Mobility issues: many things unclear (micro-/macro-mobility), which optimizations are possible/useful? Henning: Minimal requirement (if a flow identifier is changed then existing state needs to be recognized). Relationship between the flow identifier and the mobility handling Issue 7: see slides Issue 8: Path-decoupledness Can be discussed in the two-layer discussion RSVP Transport Issues (Ping Pan) Ping reports about implementation experiences with RSVP Reliable Message -> soft-state is not useful here -> reliability problem -> staged refresh timer (exponential backoff) -> at the end - very tcp like Message Packing -> one session per session -> size does not matter - but the number of messages do (bundling) (for the cpu) (extensions allowed juniper routers to support 4x the number of states) RSVP: -> cannot handle fragments -> policy objects go to the limits -> not an issue for rsvp-te RSVP does not allow you to transmit the message back from the middle to the initiator. Two MTU issues: a) do you get delivery at all (routers/firewalls) b) loss fragmentation problem (one fragmentation lost) ad b) efficiency issue what does a router in the middle of the path do if a RSVP message is fragmented and the fragments do not have the router alert option set? MPLS -> for the traffic engineered network there are rarely "route" changes. hence only refresh messages RFC 2961 is only for refresh messages does not help with bursts of messages advantages of using a tcp transport layer: - only one tcp connection between two nodes - bundling is better - mtu discovery - fragmentation - ... MPLS label distribution is no application for NSIS. RSVP-TE and RSVP is not compatible. Support for multiple transport layers - in certain environments you would like to use raw IP, SCTP, TCP or UDP. Implication of security: - Using existing security mechanism (Channel security - Packet size - policy type of objects/pk-based stuff _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 09:18:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25545 for ; Wed, 19 Feb 2003 09:18:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JEOTQ13268 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 09:24:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JEOIp13178; Wed, 19 Feb 2003 09:24:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JENMp13069 for ; Wed, 19 Feb 2003 09:23:22 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25471 for ; Wed, 19 Feb 2003 09:16:42 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1JENTm25849 for ; Wed, 19 Feb 2003 16:23:29 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 19 Feb 2003 16:20:30 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Feb 2003 16:20:30 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Feb 2003 16:20:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 19 Feb 2003 16:20:29 +0200 Message-ID: Thread-Topic: [NSIS] Internet access at NSIS interim meeting Thread-Index: AcLOst3w7Bs+PGxYSRKH8h5EGOeaXAJayLrg To: X-OriginalArrivalTime: 19 Feb 2003 14:20:29.0951 (UTC) FILETIME=[0E4250F0:01C2D822] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1JENMp13070 Subject: [NSIS] Minutes from Tuesday Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit NSIS interim meeting (Tuesday February 11) Attendants: Scott Bradner, John Loughney Marcus Brunner, Ruediger Geib, Hans Lippitsch, Hannes Tschofenig, Henning Schulzrinne, Robert Hancock, Kwok Ho Chan, Ping Pan, Joachim Hillbrandt, Janne Rinne, and others Minute Taker: Hannes Tschofenig; Sven van den Bosch Agenda: The Design Space for NSIS signaling protocols (Henning) My NSIS model NSIS assumptions: - we want to support more than a single application - operating definition of nsis: path associated state management - possible applications: * traceroute * active networking * network property management/middlebox communication - functionality which should be supported: * bi-directional signaling support * signaling must be done possible between only some nodes (for repair, etc.) / supported in RSVP but only to some extends - no generic mechanism Finding NSIS peers we do not want to find all nsis peers along the path goal : find next node along the path scott: rsvp makes the assumption that every node along the path supports rsvp robert: another category is not only to find an nsis node but also to find a node which supports a specific functionality henning: do we want to provide short-cuts or not? marcus: explit route object is a externally configured mechanism to avoid discovery (external path knowledge) scott: the addresses could be any cast addresses When to discover peers Who triggers a discovery procedure? (NI, NF) a) Discovery triggered by NI (requested) b) Discovery independently at nodes along the network (more traffic but faster reaction time) e.g. when a route change in the middle is detected. scott: soft state is important agreement by everyone - transport connection does not violate this principle henning: refresh reduction extension allows you to extend the refresh interval by separating the overloaded functionality of the path message should the soft state time be configurable? scott: cbr type of exclusive reservation disallows other nodes to use data traffic henning: also regular reservation disallows other nodes to make a reservation henning: automatic discovery is not always what we want. (example: remove state) / this, however, requires further thoughs. triggered updates in rsvp are only partial useful three types of route changes a) observable and meaningful (next nf node is different) b) observable and not meaningful (possible in an edge model) - not useful to track it c) non-observable (not immediately) Next-node discovery this is the most significant difference between path coupled and path decoupled the only useful notion for path-decoupled procedure is about the notion of ASes discovery is an approximation problems might be caused by load balancing, policy routing, layer 4 load balancing, etc. there are problems for any type of policy based forwarding and implicit/explicit discovery procedures (path-coupled) scott: load balancing is even worse since it makes a hash over a fixed portion of the header (including protocol type) conclusion: let's use the destination address inside the ntlp - load balancing problems always causes problems (i.e. use a simple solution) Transport Requirements possible large data volume and large number of messages henning: minimal nsis application requirements - path -associated state management scott: "traceroute++" would be an application which is at least required by some people henning + john: we should not close too many doors to prevent some solution. john: we should make it very generic scott: as a summary: there are things that are larger than mtu henning: see sip as an example henning: there are two issues - large objects / high bursts scott: congestion control is very important Upper/Lower Layers do all nodes process the messages? depends what information is located where scott: extensibility should be provided (see something which i do not know - i should not fail) scott: see ipv6. some bits which tell what you do when the message is received but not understood there has been some confusion what the term NTLP means. henning's definition: ntlp is on top of udp, tcp or some other reliable transport mechanism Reliability fast and reliable setup because human factor is involved. (some issues are only relevant for the initial signaling messages) Options: a) end-to-end * roundtrip estimate is fairly poor * node processing adds unpredictable variability (e.g. aaa processing). (for end-to-end processing you don't have only transmission delay) b) peer-to-peer * better rtt *re-use transport optimizations (sack) * mandates explicit discovery Other transport issues the signaling message can get bigger along the path (add / modify / delete) designing a new transport protocol is very difficult Options for transport protocols: - raw ip - tcp - sctp (see ieee network hol/ sctp) john: multiplexing capability is the big advantage of sctp not the hol scott: multiplexing was the reason to create sctp (not hol) john: sctp has the same order of performance characteristics as tcp scott: the best things learned from tcp have been added to sctp further protocols: - ddp (udp+congestion control) - dccp transport protocol issues have no relationship to soft-state principle optimization issue: state maintenance / state establishment (local optimization issue whether to keep a transport layer session alive or to close it) multicast: even in rsvp nearly all messages are unicast (except for path) end-to-end principle: not clear what "end" in this context means henning: nsis is not just message forwarding protocol (like beep) / it is about adding/modifying/deleting objects along the path scott: it is not modifying the data stream georgos: is ntlp and nslp always co-located? State overhead you are keeping the same information with and without transport layer protocol transport protocol implementation: mostly a non-issue transport header overhead: more with transport protocol overhead Identifiers should be.... (a summary of henning's thoughs) - we need something - do not overload identifiers - should be globally unique (hard todo; an approximation could be sufficient) - not dependent on host addresses - should not depend on mac - constant length - cryptographically random scott: an identifier which can be determined / looked up is a bad thing scott: global identifier requirements are hard to accomplish henning: there might be more than one identifier Packet Format Henning: XML/ASN.1 out of scope (no candidate) Variations of TLV: External described: RSVP: Type has two components (meaning and data type) Internal described: Diameter for example Working Group Update (John) An application on middlebox communication should be added to the working group (will be added to the charter) Requirements: good comments have been submitted / incorporate them and resubmit them to the mailing list Henning: the requirements do not reflex midcom specific issues John: My understanding of the requirements draft is help the working group to develop a common language. do not require every possible use. get the requirements draft done - not useful to discuss them too long. henning is requested to review them. scott: should be real requirements and not desire (less is more) john: example aaa - many of the required features might not be deployed in future if a requirement is not in the draft then it does not mean that a solution is not fullfilling nsis threats should go to last call soon framework is fairly stable henning: framework - requirements document inter-relationship (cross-referencing) robert: framework document 3 critical issues: - layer split - mobility issues - off-path issues 3-6 month a possible target to make final comments analysis document: - what have we learned from the past. - humm at the next ietf meeting to see if the analysis document is useful. - john thinks there is a need to capture knowledge of what works and what not. - every working group has to re-investigate security issues (it would be good to have some documents to for example describe current cipher-recommondations) henning: there are design tradeoff where you never get consensus on. hence it would be better to publish them as a technical report NSIS Framework Issues (Robert) Clarification about what the term ntlp means. inter-layer api? try to include functions which immediately interact with lower layers NTLP issues is there agreement that the ntlp only carries something between two nsis peers? ntlp has - to provide discovery - to interact with routing upstream/downstream direction: - ntlp to decide where go - nslp to trigger it (semantics) henning: option - ntlp as a forwarder - bypass functionality henning: it is hard to detect a route change in a non-nsis node a route change is detected downstream -> the upstream can be detected downstream and a message can be transmitted upstream. to provide this functionality nslp functionality can be used. is reverse routing required by all nslps? - ni does not care that the operation succeeded/ no message back - message from the other end could be transmitted back to the ni. henning: a number problems with that! (security, transport) assumption: the infrastructure for reverse routing has to be established if only discovers downstream peers, but must be capable of forwarding message upstream two basic options for ntlp functionality: Single-hop vs. multi-hop Single-hop: this would allow an nsis message only be transmitted between two nsis peers Multi-hop: should it be possible to transmit an empty nslp message over multiple nsis nodes? if so then the ntlp must have more functionality relationship between middlebox and qos state (for a single session identifier): keep them separate: no strongly coupling between qos and firewall/nat state - but it should be further discussed on the mailing list. john: learning from sip is a good thing. a tcp based sip stack is much nicer to work with/implement henning: state machine got complex due to additional support of udp and because * semantics of message reception * message reception two state machines required this is only about performance and not about semantics of various messages scott: multi-stream / hol scott: congestion control (hop-by-hop or end-to-end) van jacobson: link-per-link congestion control is not a good thing henning: congestion control: has to be hop-by-hop end-to-end is not as possible in the nsis case henning: flow control at each node and loss less buffering flow control is the most important property keeping the edge under network overload conditions in a save state if we want to have these options (or ever use an existing transport protocol) then we cannot go with end-to-end addressing john: we cannot decide now which are mandatory/optional flow identifiers which information should be included at the ntlp? the flow identifiers can be arbitrary complex (just enough to get it through nats) should wildcarding be allowed. would nats allow this? there was some discussion at the midcom list. ruediger: an ntlp protocol to itself use a midcom protocol to request a nat binding to subsequently allow the qos signaling protocol go through henning: holding type of nat state information. hence some solution might not work everywhere. robert: how much an we do for nats. what is the simplest way to provide this functionality. henning: can we do anything? we need at least the 5 tuple. the nat box might not be able to keep the binding to long. it is not only about the address re-writing. it is also about requesting a binding lifetime to adjust the binding lifetime henning: do you allow more than on? wildcarding issue: - efficiency (you could transmit more than one message) - transactional semantics (all or none of them) acit semantics can nslps update objects in ntlp? scott: we cannot put any constraints to it. state management should the ntlp provide a managment service? scott: lower latter would create the state installation and management henning: there is two kind of state - not transport management type of state - signaling state information henning: it does not to be part of the protocol specification. where to locate state is part of the implementation henning: some state identifier + timer + nslp state which gets logically removed timer value can be a configured value (specification) or as part of the signaling application it would be good to describe advantages / disadvantages john: connection & soft-state is a fuzzy concept a tcp connection does not need to be related to an NSIS session (one tcp connection might be associated to more than one nsis session instance) should the ntlp the upper layer nslp that a transport layer connection broke done (might be - api or performance issue) agreement: ntlp failure does not delete nslp state john: keep things separate / let the end systems decide / do not combine two different example: nat and qos signaling first signaling nat and later signal qos signaling cedric: this might be expensive some favor to keep the state information at the nslp robert: request to provide input on a state management service Scoping scott: it cannot be done. there is an endless discussion about this issue on the ipv6 mailing list if people have well-defined chunks then it should be provided at the nslp. local objects are also a scoping issues Rerouting / Mobility events - how to detect it - how to handle them (who can handle merging/deletion to avoid double booking) - is this signaling application specific? Will be discussed tomorrow Security issues should security between non-adjacent nodes be provided? NSLP NSLP NSLP NTLP NTLP NTLP NTLP scott: if the NSIS protocol chooses tcp then it must provide some protection we don't want add new dos attacks dos attacks come in various flavors types of dos attacks and the issues with it should be addressed within the nsis threats document scott: there are some environments where tcp/sctp might not be the right answer (wireless links) heavy discussion about transport protocols henning: we need to decide which properties we would like achieve robert: would the end-to-end nsis protocol break if a protocol is used between two peers which does not provide a certain property? robert: mandate requirement at the transport layer henning: what do you achieve if one hop does not provide reliability in the middle in the network? henning: the danger is then that people add some functionality for end-to-end layer georgios: even bob braden specified a raw ip and a tcp type of transport henning: there are two issues (i am concerned about (b)) a) we do not need certain properties b) we want to implement at the nslp scott: dealing with the single link as a special case - hence in a certain environment it might be ok to provide restricted functionality ACTION: from john to robert: send a mail (what is the current thinking what is needed). anyone should reply with a reason. scott: is also concerned with tcp in a hop-by-hop environment Using RSVPv1 as NTLP suggestions for modifications on RFC2205 (Georgios) ntlp functionality: - any node should be able to asynchronously generate a signaling message - load sharing capability - softstate - local object - support for non nsis aware routers along the path some ntlp should be stateless (skipping the intermediate nodes) - optional / performance enhancement (only used within the admin domain) henning: do you worry about reliability? georgios: no - not discussed robert: couldn't you simply say that you support udp? scott: we shouldn't rule out a proposals john: provide additional motivations why it is a good way forward scott: why isn't it a good way forward NTLP Design Considerations (Robert) How does an NTLP entity detect that it is the last one before data receiver? this issue is caused by the following two reasons: - new application support (midcom) - one of the endpoints does not support NSIS Capability discovery: introduced by providing more generality A couple of re-route detection mechanisms. robert: should nsis depend on stun to do the nat business? scott: let us not do that! do we optimize for low setup latency? sven: it is more important to react on changes than a low setup latency re-routing might be important for some applications (e.g. firewall/nat) - whereas for other applications such as QoS it does not matter too much in RSVP a refresh is not handled with the same priority as the regular messages failure management: timers conclusion: there are new problems introduced - these need to be addressed somehow _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 09:18:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25569 for ; Wed, 19 Feb 2003 09:18:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JEOW813300 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 09:24:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JEOJp13198; Wed, 19 Feb 2003 09:24:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JENNp13073 for ; Wed, 19 Feb 2003 09:23:23 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25473 for ; Wed, 19 Feb 2003 09:16:44 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1JEJL219986 for ; Wed, 19 Feb 2003 16:19:21 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 19 Feb 2003 16:20:32 +0200 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Feb 2003 16:20:32 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Feb 2003 16:20:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 19 Feb 2003 16:20:32 +0200 Message-ID: Thread-Topic: [NSIS] Internet access at NSIS interim meeting Thread-Index: AcLOst3w7Bs+PGxYSRKH8h5EGOeaXAJazabw To: X-OriginalArrivalTime: 19 Feb 2003 14:20:32.0627 (UTC) FILETIME=[0FDAA430:01C2D822] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1JENNp13074 Subject: [NSIS] Minutes from Wednesday Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit NSIS interim meeting (Wednesday February 12) Attendants: Scott Bradner, John Loughney Marcus Brunner, Ruediger Geib, Hans Lippitsch, Hannes Tschofenig, Henning Schulzrinne, Robert Hancock, Kwok Ho Chan, Ping Pan, Joachim Hillbrandt, Janne Rinne, and others Minute Taker: Hannes Tschofenig; Sven van den Bosch Agenda: Mobility Interaction (Hannes) Short presentation on the generic limitations of mobility due to the selection of a flow identifier (if the flow identifier is a 5-tuple including the source ip address then a full packet classifier/flow identifier update along the entire path is required). The session identifier provides some advantages to mobility. Interaction (api, triggers) from the mobility signaling protocol provides performance improvements and is comparable to route detection mechanisms. Henning: from a protocol design perspective we should support something but an implementation should have the choice to delete something. there are some subtle race condition issues which could cause problems to the entire path John: a teardown message for the old path might cause some problems - it is a performance improvement Scott: no symmetric paths can be assumed (if there is more than a single isp along the path then it is very likely that there is no symmetric path anymore). henning: mobility is likely to introduce significant difficulties. john: mobility is left for further optimization (not target for the first work) [marcus] what is the expected time range for a detected path change? [hannes] depends on: refresh interval, route detection mechanism, interaction with mobility protocol, internal nsis protocol mechanisms (e.g. initiator triggered path detection mechanisms) etc. [gk] 802.11 (100 feet), doesn't take long to drive 100 feet [jl] is it 'need to remove state'? [geib] have to link both reservations [hannes] one of the observations of rsvp mobileip interaction is the importance of separation of flow identification and session identification [hs] not only efficiency but mid-session failure for no reason (if you fail to release resources) - downlink reservation * protocol interaction is similar to a route change [gk] main point: nsis should not discover cross-over router or MAP [hannes] the discovery of the cross-over router is automatically provided due to existing of the session identifier [reh] other work suggest you can do it by having a good implementation of mobility protocol and nsis protocol. could benefit from analysis what type of messages you send when. but don't think it covers all the cases. [geib] do all potential anchor points have to be nsis-aware? [hannes] no. [marcus] but completely different timing issue: route change is longer timeframe [hs] don't care how frequently it happens but rather rapid transition from old one to new one. cleanup is probably more important for mobility. [jl] implementation issue? [hs] issue of old/new path: danger to tear down everything, because determining the cross-over point is difficult because of race conditions. [jl] prefer to have it informative. some may want to let the state time out. [hs] thought agreement this was an optimization. need to provide it but not mandate the use of it. [jl] may be some situation where resource reservation is not as 'reserved' (more advisory than contractual) [kwok] interdependence between upstream/downstream [reh] seem to be different, may be dangerous to let one depend on the other. [kwok] but what about correlation [sob] will be difficult in the middle of the network [hs] having coupling between both directions in the network is left for future work Wireless and mobility support issues (Georgios) Generic handover performance requirements georgios: handover requests could be treated by higher priority henning: by what? you only need to detect what is new and what is already existing - a policy issue. minimize number of bits transmitted Implications using TCP over 2.5 and 3G wireless networks characteristics of 2..5 and 3g wireless networks john: this topic is outside the scope of nsis henning: it effects all transport protocols john: slow start is a problem scott: an rfc which addresses this problem will pop-up soon henning: wireless links affect the performance of protocols using retransmission (it is not a tcp specific problem) if one can do better than tcp then we should present it. john: large number of small tcp session might cause problems. we should try to make sure that we avoid robert: reusing a transport layer connection for a number of message is an option henning: re-implementing a tcp mechanism within ntlp does not solve the problem. markus: what of the functions do we need? john: what are the transport things we need? georgios should provide some of the issues ietf pilc have studied the impacts and suggest: - sacks - tcp timestampe - roc Anticipated Handovers (Joachim Hillebrand) reserving resources in advance relationship to seamoby scott: requires movement prediction john: what in nsis can be done to enable this? robert: there is a framework issue on this - dependencies are not know john: joachim should investigate to determine what are the requirements for nsis henning: a generic mechanism would be good john: it is currently premature to be done scott: it is premature to add it to the charter. john: our work should be mobility be friendly scott: but it does not require anticipation of the future scott: there are surely a number of tricky things if there are more than one possible move NSIS and Mobility - Layer Split & Framework Issues (Robert) Some issues are open from the framework issues Is mobility different to re-routing? reservation theft: - now system assumes some sort of "return-routability" home address packet classifier is not feasible reservation theft is easier you have to have end-to-end signaling to update the packet classifier repair is local - there is no option to localize a possible saving: for the unchanged path you should avoid aaa/policy control you have to execute the signaling message exchange again partial nslp execution? I -> -> -> -> -> -> -> -> R \-> \-> -> R What about the reverse direction? What about a change in the middle of the middle network? I -> -> -> -> -> -> -> -> R \-> -/ \-> - ->/ What about a tear-down? There are some dependencies with aaa/charging and mobility? Should we support this? G: for a small change we should Sven: delegation might be an option unchanged path requires a packet classifier update Should we support se-like reservations? selective wildcard - comes with the possibility of multicast sven: - se can only be used between the same points / used in conference type of applications - combining different packet classifiers -> merge classifiers and qos henning: merging on prefixes (this already needs to be done for routing anyway); are routers more flexibility? detecting crossover routers - previous / next peer has changed - are there other issues? henning: - session identifier is necessary - this identifier is sufficient to associate the existing state with an incoming message - move forward henning: properties: - constant over session - globally unique ACTION: session identifier was agreed was is used for? - detect crossover router - session ownership problem? henning: options - session identifier no security relevant (identity of the owner independent from the id) - session identifier is security relevant - session identity (pk-based id) - globally unique, random collision probably is small, not protected - nobody can snoop is id (only participating nodes) - source authentication (authentication, pbk) markus: decouple security and identifier henning: done combine too many things with the same mechanism john: decouple ownership issue + write it down robert: we have a clear need for it. henning: move forward - no one came up with a john: state in the document - it cannot be used as a ownership proposal john: overloading the id is a bad idea as henning used ACTION: currently cryptographically random id (not protected - no ownership) CT/CARD issues ACTION: john - keep it open action item for john to look at 5.3.5 of the framework and to comment on it. cedric: session id for group of flows and different nslp henning: no; separate issues (a) flows (b) nslp ad (b) we haven't made this decision yet. what is the semantically tying the two nslp instances (foo/bar) - what means the combination of foo and bar -> foo fails but bar is allowed etc. this gets very complicated and we don' t want to do it. john: this sounds like an optimization which should not be considered yet; this is not an ntlp discussion ACTION: ad (a) it should not be done henning: there are many things would like to add / keep the core spec small enough - otherwise it will never get implemented. we don't have to get them into the *-00 version. john: we should not try to do 110 % - instead we do 90 % and then we have look at deployment/implementations. extensions can be added later. robert: the capability should be simple cedric: Capability negotiation required? henning: you have to provide something for the discovery. there are different type of issues: there are some things that have mandatory, discoverable and optional parts. the optional parts can cause an error if not understood or blindly forwarded. every good protocol has this type of functionality. henning: there is a danger: if there are two modes and you have a full fletched tp and you have a tp which provides nothing for specific links. bad: functionality implemented in two places (interactions get complicated) if you do what rsvp refresh reduction did then every transport person would laugh us out of the room. it is not a solution - it is a hack. ruediger: there has to be something mandated - otherwise the interoperability is in danger! john: what are the options? NSIS Meeting Summary(John) henning: milestones? john: have been updated henning: next due date? john: requirements to IESG nsis threats quite ready meta-question for analysis doc john: mobility stuff should be captured. possible rolled into the analysis document. henning: lessions are always in the eye of the beholder. john: we don't want to spend more time on the analysis document sven: off-path signaling bof next time (1 hour session) john: describe why it is needed for a restricted environment. henning: a) people have a different notion of what off-path is? how you scope the problem. b) can be quite complicated john: restricted to intra-domain signaling (inter-domain can always get very complicated) sven: it might not only be a qos application john: one or two good use-cases might be a good thing _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 09:26:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25777 for ; Wed, 19 Feb 2003 09:26:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JEWBE13882 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 09:32:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JEW7p13874; Wed, 19 Feb 2003 09:32:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JEVnp13846 for ; Wed, 19 Feb 2003 09:31:49 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25766 for ; Wed, 19 Feb 2003 09:25:11 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h1JESwP5010084 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Feb 2003 09:28:59 -0500 (EST) Message-ID: <3E5394BB.5000803@cs.columbia.edu> Date: Wed, 19 Feb 2003 09:29:15 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcus@brubers.org CC: nsis@ietf.org Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation References: <76C92FBBFB58D411AE760090271ED41806AC073B@rsys002a.roke.co.uk> <5501731.1045652523@[10.1.1.130]> In-Reply-To: <5501731.1045652523@[10.1.1.130]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I wonder what this assumption implies. > E.g., does it mean that an acknowledgment of successful state setup > always has to travel back the reverse path? IMHO it must NOT be > excluded that an acknowledgement directly gets back to the NSIS > Initiator along a potential different path. (And I am aware of the > security problems, and reliability problems of that, but I would like to > see this solved end-to-end as much as possible.) I don't see the value of this extra complexity. You now need to maintain transport state (whether as a TCP connection or your own homebrew protocol) from each node back to the originator. The security problem gets much harder, as you mention. Plus, in many cases the confirmation message is needed by the intermediate nodes anyway. For example, in the resource reservation case, you might want to commit the resources when the reservation has succeeded end-to-end. The only "cost" is the slight increase in processing in each node. Given the processing capability of modern CPUs, this is largely a non-issue. > > In general I like to see the end-to-end argument applied for signaling > as much as possible. See more on the issue of transport functionality. The end-to-end argument doesn't apply here. The NEs *are* the end since they are participants in the protocol at hand. > > Marcus > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 09:27:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25824 for ; Wed, 19 Feb 2003 09:27:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JEX9Z13940 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 09:33:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JEX2p13932; Wed, 19 Feb 2003 09:33:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JEWap13909 for ; Wed, 19 Feb 2003 09:32:36 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25772 for ; Wed, 19 Feb 2003 09:25:58 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id h1JETkR09821; Wed, 19 Feb 2003 15:29:46 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id h1JETjw24306; Wed, 19 Feb 2003 15:29:46 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id <1N87987S>; Wed, 19 Feb 2003 15:29:44 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F034C88C7@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Georgios Karagiannis (ELN)'" Cc: nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP Date: Wed, 19 Feb 2003 15:29:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi georgios please see my comments inline: > Hi Hannes > > > 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 > > >> 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. > > regarding end to end addressing, use the same addressing > > procedures as RSVP, > > since they are working fine! > > [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 > > Best Regards, > Georgios > > > > > > > > Best Regards, > > Georgios > > > > > > -----Original Message----- > > From: Tschofenig Hannes [mailto:Hannes.Tschofenig@mchp.siemens.de] > > Sent: woensdag 19 februari 2003 11:57 > > To: Lars Westberg (EAB); Geib, Ruediger > > Cc: robert.hancock@roke.co.uk; nsis@ietf.org > > Subject: RE: AW: [NSIS] Transport functionality in the NTLP > > > > > > 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:Lars.Westberg@era.ericsson.se] > > > Sent: Wednesday, February 19, 2003 11:28 AM > > > To: Geib, Ruediger > > > Cc: robert.hancock@roke.co.uk; nsis@ietf.org > > > 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 > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 09:35:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26022 for ; Wed, 19 Feb 2003 09:35:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JEfKJ15132 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 09:41:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JEfGp15119; Wed, 19 Feb 2003 09:41:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JEeMp15072 for ; Wed, 19 Feb 2003 09:40:22 -0500 Received: from thoth.sbs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25971 for ; Wed, 19 Feb 2003 09:33:42 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id h1JEbVP24668; Wed, 19 Feb 2003 15:37:32 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id h1JEbVw02713; Wed, 19 Feb 2003 15:37:31 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id <1N8799BH>; Wed, 19 Feb 2003 15:37:30 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F034C88C8@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Georgios Karagiannis (ELN)'" Cc: nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP Date: Wed, 19 Feb 2003 15:36:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi georgios! > > Hi Hannes > > What do you mean? > Regarding peer to peer addressing, have I given such arguments? 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. > > Best Regards, > Georgios ciao hannes > > -----Original Message----- > From: Tschofenig Hannes [mailto:Hannes.Tschofenig@mchp.siemens.de] > Sent: woensdag 19 februari 2003 14:56 > To: Georgios Karagiannis (ELN) > Cc: nsis@ietf.org > Subject: RE: AW: [NSIS] Transport functionality in the NTLP > > > hi georgios > > i have difficulties to see your arguments agains peer-to-peer > addressing. > they have nothing todo with the wireless network. > > ciao > hannes > > > > -----Original Message----- > > From: Georgios Karagiannis (ELN) > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > Sent: Wednesday, February 19, 2003 1:47 PM > > To: Georgios Karagiannis (ELN); Tschofenig Hannes > > Cc: nsis@ietf.org > > Subject: RE: AW: [NSIS] Transport functionality in the NTLP > > > > > > 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: nsis@ietf.org > > Subject: RE: AW: [NSIS] Transport functionality in the NTLP > > > > > > 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:Hannes.Tschofenig@mchp.siemens.de] > > Sent: woensdag 19 februari 2003 11:57 > > To: Lars Westberg (EAB); Geib, Ruediger > > Cc: robert.hancock@roke.co.uk; nsis@ietf.org > > Subject: RE: AW: [NSIS] Transport functionality in the NTLP > > > > > > 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:Lars.Westberg@era.ericsson.se] > > > Sent: Wednesday, February 19, 2003 11:28 AM > > > To: Geib, Ruediger > > > Cc: robert.hancock@roke.co.uk; nsis@ietf.org > > > 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 > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 09:46:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26297 for ; Wed, 19 Feb 2003 09:46:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JEqDa15679 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 09:52:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JEq9p15639; Wed, 19 Feb 2003 09:52:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JEp9p15581 for ; Wed, 19 Feb 2003 09:51:09 -0500 Received: from brazilnut.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26248 for ; Wed, 19 Feb 2003 09:44:30 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h1JEmE8k010688 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Feb 2003 09:48:15 -0500 (EST) Message-ID: <3E539936.2090704@cs.columbia.edu> Date: Wed, 19 Feb 2003 09:48:22 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Georgios Karagiannis (ELN)" CC: "'Tschofenig Hannes'" , nsis@ietf.org Subject: Re: AW: [NSIS] Transport functionality in the NTLP References: <2B06CD3FC17AF64587BC7A7617B230C0CBB8F1@enleent103.nl.eu.ericsson.se> In-Reply-To: <2B06CD3FC17AF64587BC7A7617B230C0CBB8F1@enleent103.nl.eu.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > What do you mean? > In wireless networks link layers provide such features!!!!! > Please, do not impose performance degradations when it is not needed!!! Since this is an engineering working group, maybe we can agree that anybody who claims that "X causes a performance degradation" should at least be kind enough to cite some verifiable evidence, not just hearsay, and then also show that the replacement mechanism is free of those defects. As was pointed out during the interim meeting, nobody has proposed mechanisms at the NSLP layer or (above-L4-transport) NTLP layer that differ fundamentally from what we have at TCP or SCTP layer. It eludes my understanding why the same mechanism implemented at higher layers should be more efficient than implemented at lower layers. As was also discussed repeatedly, RFC 2961 shows what happens if you try to do this at the "NSLP" layer: you get a mess and a transport mechanism that reflects transport knowledge ca. 1975. If there is no congestion or loss, TCP (or SCTP) are essentially free, except for the ACK (which you'll need in any event). > Wireless scenarios are not specific applications!!!! > Actually the goal of starting NSIS was to solve QoS issues in > wireless scenarios. Please do not forget this!!!! > Other types of scenarios could also use NSIS, but in my opinion > NSIS should at least satisfy the requirements imposed by > wireless scenarios!!! You have unfortunately not made an engineering case, besides adding !!!, that implementing reliability or other functionality below NTLP harms wireless deployability. The debate would be furthered and be less circular if you could do so by arguments other than assertions. Things like TCP header compression are available for wireless links; if you replicate this at higher layers, you don't get the benefit of any of those developments. That said, the design choice I presented explicitly allowed for hop-by-hop unreliable forwarding, with only end-to-end reliability. Once you actually measure the performance in high-loss links, you won't like it, but it doesn't add substantial cost to the design. > > Best Regards, > Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 10:05:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27172 for ; Wed, 19 Feb 2003 10:05:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JFBQo17609 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 10:11:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JFBLp17567; Wed, 19 Feb 2003 10:11:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JF97p17409 for ; Wed, 19 Feb 2003 10:09:07 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26886 for ; Wed, 19 Feb 2003 10:02:27 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h1JF6CDc000311 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Feb 2003 10:06:13 -0500 (EST) Message-ID: <3E539D74.7080307@cs.columbia.edu> Date: Wed, 19 Feb 2003 10:06:28 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcus@brubers.org CC: "Hancock, Robert" , nsis@ietf.org Subject: Re: [NSIS] Transport functionality in the NTLP References: <76C92FBBFB58D411AE760090271ED41806AC073A@rsys002a.roke.co.uk> <9075179.1045656097@[10.1.1.130]> In-Reply-To: <9075179.1045656097@[10.1.1.130]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Here I would opt for d. I assume that the probability is already high > without any mechnism in or below NTLP. Detect and handle the any drop > end-to-end. As mentioned during the interim, end-to-end is not a viable option by itself since the RTT estimate is likely to be extremely poor and variable. Do you disagree with that assertion? Indeed, the RSVP design experience bears this out - 2205 by itself is not sufficient and thus 2961 adds a bare-bones hop-by-hop reliability. Similarly, e2e congestion control is going to be extremely challenging given that you'll have poor RTT estimates, node-packet-dropping (due to lack of flow control) and link packet dropping. NEs are not just routers - with AAA, some nodes can hang onto an NSIS message for hundreds of milliseconds or longer. Clearly, flow control cannot be performed end-to-end since the nodes to be protected are in the middle. MTU discovery cannot be done end-to-end since the message size can change along the way. Thus, rather than handwaving, we would need a concrete proposal as to how you would effectively address these issues end-to-end. Also, as I said, it would be really helpful if somebody could cite verifiable engineering evidence that indicate that hop-by-hop solutions won't work. Simply restating this again and again or claiming that "it's not needed" is not very satisfying. One could argue that TCP isn't needed for accessing my local-LAN IMAP or HTTP server either. Are you suggesting that we should run IMAP or HTTP over UDP or that the performance would be significantly better if we did? Or are you suggesting that wireless web browsers should use UDP or raw IP? (If you look at NFS, you'll find a similar evolution of thought, btw.) > I would asume that for environment, where security is not requiered this > is not an issue. It's always easier to not turn on security than to have to back-engineer it later on. Again, RSVP is a good example of what happens if you try. I don't think designing a protocol that doesn't support it as a general rule is going to fly. > IMHO this depends again on whether NTLP is hop-by-hop only. If > hop-by-hop only then d) should be done end-to-end. Flow control simply cannot be done end-to-end. Please show how you can protect an NSIS node in the middle by an end-to-end mechanism. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 10:24:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28542 for ; Wed, 19 Feb 2003 10:24:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JFUPi18941 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 10:30:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JFUGp18934; Wed, 19 Feb 2003 10:30:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JFT9p18889 for ; Wed, 19 Feb 2003 10:29:09 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28430 for ; Wed, 19 Feb 2003 10:22:29 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h1JFPJDc019977 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Feb 2003 10:25:23 -0500 (EST) Message-ID: <3E53A1F0.9070806@cs.columbia.edu> Date: Wed, 19 Feb 2003 10:25:36 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Melinda Shore CC: "Hancock, Robert" , nsis@ietf.org Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation References: <200302190358.ADN44002@mira-sjc5-c.cisco.com> In-Reply-To: <200302190358.ADN44002@mira-sjc5-c.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Melinda, would you happen to have quantitative evidence of the cost relative to doing raw IP sockets plus storing roughly the same information at the application layer? At least from our initial experiments, Linux can handle several ten thousand sockets. Thanks. Henning Melinda Shore wrote: > Sockets don't come free. Depending on which OS you're > running they don't even come cheaply. That's less of a > consideration for QoS applications, perhaps, but it's > something to keep in mind when thinking about applications > in which per-flow information is not aggregatable and there > are a lot of flows. Enterprise NAT is a good example > because you've got to treat every flow that crosses the > device and you've got potentially very wide fan-out to the > next-hop devices participating in the application. > > At any rate it would be a help if the minutes from the > interim meeting were posted to the mailing list. > > Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 10:45:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29323 for ; Wed, 19 Feb 2003 10:45:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JFplZ20646 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 10:51:47 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JFpXp20615; Wed, 19 Feb 2003 10:51:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JFlSp20480 for ; Wed, 19 Feb 2003 10:47:28 -0500 Received: from mailhost.chi1.ameritech.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29255 for ; Wed, 19 Feb 2003 10:40:48 -0500 (EST) Received: from repligate ([67.36.179.41]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20030219154437.IEJJ3860.mailhost.chi1.ameritech.net@repligate> for ; Wed, 19 Feb 2003 09:44:37 -0600 Message-ID: <0d2d01c2d82d$d8c8c740$8500a8c0@repligate> From: "Jim Fleming" To: References: <2B06CD3FC17AF64587BC7A7617B230C0CBB8F1@enleent103.nl.eu.ericsson.se> <3E539936.2090704@cs.columbia.edu> Date: Wed, 19 Feb 2003 09:44:53 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [NSIS] "cite some verifiable evidence, not just hearsay" ? Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "cite some verifiable evidence, not just hearsay" ? ==== Have people considered working code ? Jim Fleming http://IPv8.isfun.net ----- Original Message ----- From: "Henning Schulzrinne" To: "Georgios Karagiannis (ELN)" Cc: "'Tschofenig Hannes'" ; Sent: Wednesday, February 19, 2003 8:48 AM Subject: Re: AW: [NSIS] Transport functionality in the NTLP > > What do you mean? > > In wireless networks link layers provide such features!!!!! > > Please, do not impose performance degradations when it is not needed!!! > > Since this is an engineering working group, maybe we can agree that > anybody who claims that "X causes a performance degradation" should at > least be kind enough to cite some verifiable evidence, not just hearsay, > and then also show that the replacement mechanism is free of those defects. > > As was pointed out during the interim meeting, nobody has proposed > mechanisms at the NSLP layer or (above-L4-transport) NTLP layer that > differ fundamentally from what we have at TCP or SCTP layer. It eludes > my understanding why the same mechanism implemented at higher layers > should be more efficient than implemented at lower layers. > > As was also discussed repeatedly, RFC 2961 shows what happens if you try > to do this at the "NSLP" layer: you get a mess and a transport mechanism > that reflects transport knowledge ca. 1975. > > If there is no congestion or loss, TCP (or SCTP) are essentially free, > except for the ACK (which you'll need in any event). > > > > > Wireless scenarios are not specific applications!!!! > > Actually the goal of starting NSIS was to solve QoS issues in > > wireless scenarios. Please do not forget this!!!! > > Other types of scenarios could also use NSIS, but in my opinion > > NSIS should at least satisfy the requirements imposed by > > wireless scenarios!!! > > You have unfortunately not made an engineering case, besides adding !!!, > that implementing reliability or other functionality below NTLP harms > wireless deployability. The debate would be furthered and be less > circular if you could do so by arguments other than assertions. > > Things like TCP header compression are available for wireless links; if > you replicate this at higher layers, you don't get the benefit of any of > those developments. > > That said, the design choice I presented explicitly allowed for > hop-by-hop unreliable forwarding, with only end-to-end reliability. Once > you actually measure the performance in high-loss links, you won't like > it, but it doesn't add substantial cost to the design. > > > > > > Best Regards, > > Georgios > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 10:45:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29339 for ; Wed, 19 Feb 2003 10:45:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JFpsm20707 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 10:51:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JFpZp20630; Wed, 19 Feb 2003 10:51:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JFm5p20509 for ; Wed, 19 Feb 2003 10:48:05 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29266 for ; Wed, 19 Feb 2003 10:41:24 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h1JFimsv013575; Wed, 19 Feb 2003 07:44:48 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADN81344; Wed, 19 Feb 2003 07:45:00 -0800 (PST) Message-Id: <200302191545.ADN81344@mira-sjc5-c.cisco.com> To: Henning Schulzrinne cc: "Hancock, Robert" , nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation In-Reply-To: Message from hgs@cs.columbia.edu of "Wed, 19 Feb 2003 10:25:36 EST." <3E53A1F0.9070806@cs.columbia.edu> Date: Wed, 19 Feb 2003 10:45:00 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > would you happen to have quantitative evidence of the cost relative to > doing raw IP sockets plus storing roughly the same information at the > application layer? At least from our initial experiments, Linux can > handle several ten thousand sockets. I can get a lot more sockets that that from a BSD system. Nevertheless, while I don't have actual numbers I think you'd clearly be quite hard-pressed to argue that the data and buffers associated with, say, a TCP socket don't substantially outweigh the amount of state associated with an RSVP reservation. Where you can get a win is in circumstances where you can aggregate diverse messages between NSIS nodes, which you can't currently do with RSVP, but I think we need to consider applications in which there's substantial fan-out and persistent connections. If we're willing to make that compromise let's make it explicit, but I do think it's worthwhile to point out that you may end up limiting the extent to which the NTLP is useful as a generalized transport for inband signaling applications. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 11:05:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29873 for ; Wed, 19 Feb 2003 11:05:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JGBS322265 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 11:11:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JGBIp22227; Wed, 19 Feb 2003 11:11:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JGAcp22172 for ; Wed, 19 Feb 2003 11:10:38 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29835 for ; Wed, 19 Feb 2003 11:03:57 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1JG7kAv020005; Wed, 19 Feb 2003 17:07:46 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVMJ5HW; Wed, 19 Feb 2003 17:07:45 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Feb 2003 17:07:45 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB8F3@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 43b21c59 9ffcebbb 7a95d2f4 00000138 From: "Georgios Karagiannis (ELN)" To: "'Tschofenig Hannes'" Cc: nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP Date: Wed, 19 Feb 2003 17:07:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Hannes > 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). 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 >> generic. 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 11:14:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00077 for ; Wed, 19 Feb 2003 11:14:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JGKDa22885 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 11:20:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JGK7p22846; Wed, 19 Feb 2003 11:20:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JGHRp22717 for ; Wed, 19 Feb 2003 11:17:27 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00008 for ; Wed, 19 Feb 2003 11:10:46 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h1JGBdNd011375 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Feb 2003 11:11:40 -0500 (EST) Message-ID: <3E53ACCB.1060206@cs.columbia.edu> Date: Wed, 19 Feb 2003 11:11:55 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Melinda Shore CC: "Hancock, Robert" , nsis@ietf.org Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation References: <200302191545.ADN81344@mira-sjc5-c.cisco.com> In-Reply-To: <200302191545.ADN81344@mira-sjc5-c.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit If I understand you correctly, you are saying that this is primarily a memory issue, where an RSVP state is substantially smaller than TCP state. I'm curious if somebody has measured this; I wasn't able to find any current reference. I think RSVP state is around 500 bytes/session. Maybe we should also set a target connection count we definitely want to support on current hardware, so that we can mock up a system to see if this would work. Melinda Shore wrote: >>would you happen to have quantitative evidence of the cost relative to >>doing raw IP sockets plus storing roughly the same information at the >>application layer? At least from our initial experiments, Linux can >>handle several ten thousand sockets. > > > I can get a lot more sockets that that from a BSD system. > Nevertheless, while I don't have actual numbers I think > you'd clearly be quite hard-pressed to argue that the data > and buffers associated with, say, a TCP socket don't > substantially outweigh the amount of state associated with > an RSVP reservation. Where you can get a win is in > circumstances where you can aggregate diverse messages > between NSIS nodes, which you can't currently do with RSVP, > but I think we need to consider applications in which > there's substantial fan-out and persistent connections. If > we're willing to make that compromise let's make it > explicit, but I do think it's worthwhile to point out that > you may end up limiting the extent to which the NTLP is > useful as a generalized transport for inband signaling > applications. > > Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 11:14:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00152 for ; Wed, 19 Feb 2003 11:14:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JGL7E22987 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 11:21:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JGL2p22978; Wed, 19 Feb 2003 11:21:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JGKip22933 for ; Wed, 19 Feb 2003 11:20:44 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00075 for ; Wed, 19 Feb 2003 11:14:03 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1JGHlKV014110; Wed, 19 Feb 2003 17:17:47 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVHCRKS; Wed, 19 Feb 2003 17:17:47 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Feb 2003 17:17:46 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB8F4@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: c347e48d 9ffcebbb 7a95d2f4 00000138 From: "Georgios Karagiannis (ELN)" To: "'Henning Schulzrinne'" Cc: "'Tschofenig Hannes'" , nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP Date: Wed, 19 Feb 2003 17:17:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Henning My main argument is as follows. If a feature is not needed you should be able to not use it! If TCP is placed below NTLP, mandatory, you will have to support this feature that you do not need! Now the performance degradation that is imposed by using TCP is related to: * increased packet length (there are still open issues related to header compression of the SACK and TCP time stamp options); * TCP is using a three-way handshake mechanism to establish a connection, Regarding setup delay, the above two issues cause a performance degradation, in links that do not need to use these features. Best Regards, Georgios -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: woensdag 19 februari 2003 15:48 To: Georgios Karagiannis (ELN) Cc: 'Tschofenig Hannes'; nsis@ietf.org Subject: Re: AW: [NSIS] Transport functionality in the NTLP > What do you mean? > In wireless networks link layers provide such features!!!!! > Please, do not impose performance degradations when it is not needed!!! Since this is an engineering working group, maybe we can agree that anybody who claims that "X causes a performance degradation" should at least be kind enough to cite some verifiable evidence, not just hearsay, and then also show that the replacement mechanism is free of those defects. As was pointed out during the interim meeting, nobody has proposed mechanisms at the NSLP layer or (above-L4-transport) NTLP layer that differ fundamentally from what we have at TCP or SCTP layer. It eludes my understanding why the same mechanism implemented at higher layers should be more efficient than implemented at lower layers. As was also discussed repeatedly, RFC 2961 shows what happens if you try to do this at the "NSLP" layer: you get a mess and a transport mechanism that reflects transport knowledge ca. 1975. If there is no congestion or loss, TCP (or SCTP) are essentially free, except for the ACK (which you'll need in any event). > Wireless scenarios are not specific applications!!!! > Actually the goal of starting NSIS was to solve QoS issues in > wireless scenarios. Please do not forget this!!!! > Other types of scenarios could also use NSIS, but in my opinion > NSIS should at least satisfy the requirements imposed by > wireless scenarios!!! You have unfortunately not made an engineering case, besides adding !!!, that implementing reliability or other functionality below NTLP harms wireless deployability. The debate would be furthered and be less circular if you could do so by arguments other than assertions. Things like TCP header compression are available for wireless links; if you replicate this at higher layers, you don't get the benefit of any of those developments. That said, the design choice I presented explicitly allowed for hop-by-hop unreliable forwarding, with only end-to-end reliability. Once you actually measure the performance in high-loss links, you won't like it, but it doesn't add substantial cost to the design. > > Best Regards, > Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 11:20:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00324 for ; Wed, 19 Feb 2003 11:20:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JGQQK23299 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 11:26:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JGQKp23270; Wed, 19 Feb 2003 11:26:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JGPEp23207 for ; Wed, 19 Feb 2003 11:25:14 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00260 for ; Wed, 19 Feb 2003 11:18:32 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1JGMKKV015200; Wed, 19 Feb 2003 17:22:20 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVMJ78F; Wed, 19 Feb 2003 17:22:20 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Feb 2003 17:19:01 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB8F5@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 50b89477 9ffcebbb 7a95d2f4 00000138 From: "Georgios Karagiannis (ELN)" To: "'Tschofenig Hannes'" Cc: nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP Date: Wed, 19 Feb 2003 17:22:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Hannes >> 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. 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 > > -----Original Message----- > From: Tschofenig Hannes [mailto:Hannes.Tschofenig@mchp.siemens.de] > Sent: woensdag 19 februari 2003 14:56 > To: Georgios Karagiannis (ELN) > Cc: nsis@ietf.org > Subject: RE: AW: [NSIS] Transport functionality in the NTLP > > > hi georgios > > i have difficulties to see your arguments agains peer-to-peer > addressing. > they have nothing todo with the wireless network. > > ciao > hannes > > > > -----Original Message----- > > From: Georgios Karagiannis (ELN) > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > Sent: Wednesday, February 19, 2003 1:47 PM > > To: Georgios Karagiannis (ELN); Tschofenig Hannes > > Cc: nsis@ietf.org > > Subject: RE: AW: [NSIS] Transport functionality in the NTLP > > > > > > 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: nsis@ietf.org > > Subject: RE: AW: [NSIS] Transport functionality in the NTLP > > > > > > 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:Hannes.Tschofenig@mchp.siemens.de] > > Sent: woensdag 19 februari 2003 11:57 > > To: Lars Westberg (EAB); Geib, Ruediger > > Cc: robert.hancock@roke.co.uk; nsis@ietf.org > > Subject: RE: AW: [NSIS] Transport functionality in the NTLP > > > > > > 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:Lars.Westberg@era.ericsson.se] > > > Sent: Wednesday, February 19, 2003 11:28 AM > > > To: Geib, Ruediger > > > Cc: robert.hancock@roke.co.uk; nsis@ietf.org > > > 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 > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 16:48:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09895 for ; Wed, 19 Feb 2003 16:48:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1JLskc12588 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 16:54:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JLsdp12581; Wed, 19 Feb 2003 16:54:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JLrUp12553 for ; Wed, 19 Feb 2003 16:53:30 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09824 for ; Wed, 19 Feb 2003 16:46:38 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1JLoLSQ012358; Wed, 19 Feb 2003 13:50:21 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABO94882; Wed, 19 Feb 2003 13:50:19 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA07625; Wed, 19 Feb 2003 13:50:19 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15955.64539.648084.828585@thomasm-u1.cisco.com> Date: Wed, 19 Feb 2003 13:50:19 -0800 (PST) To: Henning Schulzrinne Cc: Melinda Shore , "Hancock, Robert" , nsis@ietf.org Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation In-Reply-To: <3E53ACCB.1060206@cs.columbia.edu> References: <200302191545.ADN81344@mira-sjc5-c.cisco.com> <3E53ACCB.1060206@cs.columbia.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Henning Schulzrinne writes: > If I understand you correctly, you are saying that this is primarily a > memory issue, where an RSVP state is substantially smaller than TCP > state. I'm curious if somebody has measured this; I wasn't able to find > any current reference. I think RSVP state is around 500 bytes/session. > > Maybe we should also set a target connection count we definitely want to > support on current hardware, so that we can mock up a system to see if > this would work. If you're going to do this, you'd need to compare apples to apples. As in, what part of RSVP's per session state is being used to maintain the transport part of the session. My guess is that that's substantially less than the 500 bytes you cite. Indeed, since the two are tangled in RSVP, a direct comparision might be rather tricky. Mike > > Melinda Shore wrote: > >>would you happen to have quantitative evidence of the cost relative to > >>doing raw IP sockets plus storing roughly the same information at the > >>application layer? At least from our initial experiments, Linux can > >>handle several ten thousand sockets. > > > > > > I can get a lot more sockets that that from a BSD system. > > Nevertheless, while I don't have actual numbers I think > > you'd clearly be quite hard-pressed to argue that the data > > and buffers associated with, say, a TCP socket don't > > substantially outweigh the amount of state associated with > > an RSVP reservation. Where you can get a win is in > > circumstances where you can aggregate diverse messages > > between NSIS nodes, which you can't currently do with RSVP, > > but I think we need to consider applications in which > > there's substantial fan-out and persistent connections. If > > we're willing to make that compromise let's make it > > explicit, but I do think it's worthwhile to point out that > > you may end up limiting the extent to which the NTLP is > > useful as a generalized transport for inband signaling > > applications. > > > > Melinda > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 19 19:32:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13941 for ; Wed, 19 Feb 2003 19:32:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1K0coY22596 for nsis-archive@odin.ietf.org; Wed, 19 Feb 2003 19:38:50 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K0clp22589; Wed, 19 Feb 2003 19:38:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K0bMp22438 for ; Wed, 19 Feb 2003 19:37:22 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13891 for ; Wed, 19 Feb 2003 19:30:33 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5SBAN>; Thu, 20 Feb 2003 00:34:21 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41806AC0772@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Melinda Shore Cc: nsis@ietf.org Subject: RE: [NSIS] consensus probe on one aspect of NTLP operation Date: Thu, 20 Feb 2003 00:34:19 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi Melinda, > Robert, it's the chair's job to call consensus. I entirely agree with you (as indeed the phrase "no claim of an official WG consensus" in the 3rd sentence of the original mail might have been taken to imply). Actually, there is a serious point here: an assumption of some form about hop-by-hop-ness of the NTLP has been floating around for about 6 months now, with not much comment against it. However, some comments at/around the interim implied that some people weren't happy with it, for reasons which were unclear. Other than writing something in the next framework draft and seeing if people notice it, it wasn't clear to me how else as editor of it to progress the issue other than writing in something suspected to be confusing. Alternative process suggestions are of course welcome. [I haven't really analysed the resulting mail storm yet. But there seems to be *) 1 problem of terminology (I think I would see RSVP's notional 'lower layer' as hop/hop, the same way Bob sees CSTP as hop/hop, but maybe the hop/hop term is unhelpful) *) 1 problem of substance (the non-local notification problem) - which is certainly an issue, which I wanted to think of as orthogonal but probably isn't. It has fallen down my list of worries since making the assumption - also in the minutes of the interim - that reverse routing must be made possible, in which case the non-local notification ability seems not very useful. Obviously, if that goes in the next framework, people will be welcome to complain about that too.] > I still > don't know what the technical arguments are for departing > from RSVP on this, what do you identify as the departure? > and since the minutes from the interim > meeting have not been posted those of us who were not there > don't know what was discussed or presented. I'm happy with > accumulating path state in the application, but I'm still > highly not comfortable with accumulating routing state in > the transport layer. This seems like a big step backwards > to me. which bit of the definition text makes you think this is what is proposed? would you like to propose an alternative definition? > > Melinda > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 04:18:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05013 for ; Thu, 20 Feb 2003 04:18:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1K9PRj29638 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 04:25:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K9PNp29627; Thu, 20 Feb 2003 04:25:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1K9OTp29590 for ; Thu, 20 Feb 2003 04:24:29 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05006 for ; Thu, 20 Feb 2003 04:17:28 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1K9LGAv011785; Thu, 20 Feb 2003 10:21:16 +0100 (MET) Received: from era.ericsson.se (E00104B7F41BB.ki.sw.ericsson.se [147.214.181.136]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVM32QF; Thu, 20 Feb 2003 10:21:16 +0100 Message-ID: <3E549E03.5B73662F@era.ericsson.se> Date: Thu, 20 Feb 2003 10:21:07 +0100 X-Sybari-Trust: 9ea926ee 9ffcebbb 7a95d2f4 00000138 From: "Lars.Westberg" X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Melinda Shore CC: Henning Schulzrinne , "Hancock, Robert" , nsis@ietf.org Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation References: <200302191545.ADN81344@mira-sjc5-c.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi! I am also worried about applications with high "fanout" for NTLP. Do you have any experience about the performance difference between a TCP-solution and a RSVP solution with substantial fanout ? regards Lasse Melinda Shore wrote: > > would you happen to have quantitative evidence of the cost relative to > > doing raw IP sockets plus storing roughly the same information at the > > application layer? At least from our initial experiments, Linux can > > handle several ten thousand sockets. > > I can get a lot more sockets that that from a BSD system. > Nevertheless, while I don't have actual numbers I think > you'd clearly be quite hard-pressed to argue that the data > and buffers associated with, say, a TCP socket don't > substantially outweigh the amount of state associated with > an RSVP reservation. Where you can get a win is in > circumstances where you can aggregate diverse messages > between NSIS nodes, which you can't currently do with RSVP, > but I think we need to consider applications in which > there's substantial fan-out and persistent connections. If > we're willing to make that compromise let's make it > explicit, but I do think it's worthwhile to point out that > you may end up limiting the extent to which the NTLP is > useful as a generalized transport for inband signaling > applications. > > Melinda > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 05:46:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06791 for ; Thu, 20 Feb 2003 05:46:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KAqu202230 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 05:52:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KAqpp02217; Thu, 20 Feb 2003 05:52:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KAmFp02117 for ; Thu, 20 Feb 2003 05:48:15 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06724 for ; Thu, 20 Feb 2003 05:41:11 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1KAj1Av006323; Thu, 20 Feb 2003 11:45:01 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVJG0NN; Thu, 20 Feb 2003 11:45:01 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Feb 2003 11:41:42 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB8F6@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 62da0872 9ffcebbb a5ee123c 00000138 From: "Georgios Karagiannis (ELN)" To: "'Hancock, Robert'" Cc: nsis@ietf.org Subject: RE: [NSIS] consensus probe on one aspect of NTLP operation Date: Thu, 20 Feb 2003 11:43:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Robert Regarding the non-local notification issue that you addressed! In an autonomous administrative domain, the local notification procedure, between edges is useful. Please note that this will be a NSLP procedure. Therefore, I think that we should not exclude the local notification feature. However, it should be an optional feature. Best Regards, Georgios -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: donderdag 20 februari 2003 1:34 To: Melinda Shore Cc: nsis@ietf.org Subject: RE: [NSIS] consensus probe on one aspect of NTLP operation hi Melinda, > Robert, it's the chair's job to call consensus. I entirely agree with you (as indeed the phrase "no claim of an official WG consensus" in the 3rd sentence of the original mail might have been taken to imply). Actually, there is a serious point here: an assumption of some form about hop-by-hop-ness of the NTLP has been floating around for about 6 months now, with not much comment against it. However, some comments at/around the interim implied that some people weren't happy with it, for reasons which were unclear. Other than writing something in the next framework draft and seeing if people notice it, it wasn't clear to me how else as editor of it to progress the issue other than writing in something suspected to be confusing. Alternative process suggestions are of course welcome. [I haven't really analysed the resulting mail storm yet. But there seems to be *) 1 problem of terminology (I think I would see RSVP's notional 'lower layer' as hop/hop, the same way Bob sees CSTP as hop/hop, but maybe the hop/hop term is unhelpful) *) 1 problem of substance (the non-local notification problem) - which is certainly an issue, which I wanted to think of as orthogonal but probably isn't. It has fallen down my list of worries since making the assumption - also in the minutes of the interim - that reverse routing must be made possible, in which case the non-local notification ability seems not very useful. Obviously, if that goes in the next framework, people will be welcome to complain about that too.] > I still > don't know what the technical arguments are for departing > from RSVP on this, what do you identify as the departure? > and since the minutes from the interim > meeting have not been posted those of us who were not there > don't know what was discussed or presented. I'm happy with > accumulating path state in the application, but I'm still > highly not comfortable with accumulating routing state in > the transport layer. This seems like a big step backwards > to me. which bit of the definition text makes you think this is what is proposed? would you like to propose an alternative definition? > > Melinda > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 08:55:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14480 for ; Thu, 20 Feb 2003 08:55:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KE2I114188 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 09:02:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KE2Dp14178; Thu, 20 Feb 2003 09:02:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KDx5p14045 for ; Thu, 20 Feb 2003 08:59:05 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14241 for ; Thu, 20 Feb 2003 08:51:58 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1KDwmm15688 for ; Thu, 20 Feb 2003 15:58:48 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Feb 2003 15:55:46 +0200 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Feb 2003 15:55:46 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Feb 2003 15:55:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] consensus probe on one aspect of NTLP operation Date: Thu, 20 Feb 2003 15:55:44 +0200 Message-ID: Thread-Topic: [NSIS] consensus probe on one aspect of NTLP operation Thread-Index: AcLXyALAkOD6IbWFTeue+RwIzDfFnQAXcHaQ To: , Cc: X-OriginalArrivalTime: 20 Feb 2003 13:55:45.0206 (UTC) FILETIME=[C3B1F560:01C2D8E7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1KDx5p14046 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Melinda, > Robert, it's the chair's job to call consensus. I still > don't know what the technical arguments are for departing > from RSVP on this, and since the minutes from the interim > meeting have not been posted those of us who were not there > don't know what was discussed or presented. I'm happy with > accumulating path state in the application, but I'm still > highly not comfortable with accumulating routing state in > the transport layer. This seems like a big step backwards > to me. Its perfectly legal for WG members to ask for consensus on an issue, which I think is what Robert was doing. However, it is the chair job to call the consensus when consensus is reached. Determining the transport functionality is probably the big issue to determine, so I'd be happy if the WG discussed the needs for transport. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 09:00:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14724 for ; Thu, 20 Feb 2003 09:00:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KE73h14560 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 09:07:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KE6up14436; Thu, 20 Feb 2003 09:06:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1JJ3Mp01660 for ; Wed, 19 Feb 2003 14:03:22 -0500 Received: from w2ksjexg01.ciena.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04965 for ; Wed, 19 Feb 2003 13:56:39 -0500 (EST) Received: from ciena.com (ppan [10.34.77.170]) by w2ksjexg01.ciena.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FG7XGCGA; Wed, 19 Feb 2003 11:00:08 -0800 Message-ID: <3E53D443.6000900@ciena.com> Date: Wed, 19 Feb 2003 11:00:19 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en, zh MIME-Version: 1.0 To: "Georgios Karagiannis (ELN)" CC: "'Henning Schulzrinne'" , "'Tschofenig Hannes'" , nsis@ietf.org Subject: Re: AW: [NSIS] Transport functionality in the NTLP References: <2B06CD3FC17AF64587BC7A7617B230C0CBB8F4@enleent103.nl.eu.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Geoegios and Henning, I have a feeling that there is a misunderstanding here. Argument 1: if we have so many issues in the existing RSVP transport, and BGP/LDP are two operational protocols running over TCP between routers, then why not run RSVP payload over TCP between routers? (The overhead for a TCP socket is very small, at least in the latest FreeBSD and Linux.) This is a valid point. Argument 2: reliable message transport is a good thing, but it can be accomplished at different layers. In case of radio access network, there is a underlying reliable transport layer, and the wireless bandwidth is very expensive, so running RSVP raw-mode is just fine. Why TCP at all? This is also valid. After talking to Georgios during the interim meeting, I had made an effort to emphasis the importance of swapping transport layer protocols during my presentation. I suggest the following: in case of transporting RSVP payload (call it NTLP, if you wish), we could have three different methods: 1. RSVP raw-mode: as defined in the RFC, we can just run it over the reliable wireless access link. 2. RSVP-over-UDP: see the RFC. 3. RSVP-over-TCP: One TCP session is established between RSVP neighbors. (Check RSVP-TE to see how to discover and create RSVP neighbors.) For all RSVP messages, just send them through the TCP socket. Unless you want to support RSVP soft-state time-out, there would be no need to send refresh messages at all. I argue that we will save more link bandwidth, process less messages, and have less bugs to discover. There is one problem wrt the Path messages, since they are delivered e2e and use IP router alert option. Well... RSVP Path messages can be delivered hop-by-hop based on the destination address in the session object. There is no need to have this IP Router Alert option hack in the first place. In any regard, I think this would be work. If you want to feel secure, run your SCTP between routers. I have thought TCP/MD5 (free code BTW) would solve a lot of problems already. 2 cents, - Ping Georgios Karagiannis (ELN) wrote: > Hi Henning > > My main argument is as follows. > If a feature is not needed you should be able to > not use it! > If TCP is placed below NTLP, mandatory, you will have to support this feature > that you do not need! > Now the performance degradation that is imposed by using TCP > is related to: > * increased packet length (there are still open issues > related to header compression > of the SACK and TCP time stamp options); > * TCP is using a three-way handshake mechanism to establish a connection, > > Regarding setup delay, the above two issues cause a performance degradation, in > links that do not need to use these features. > > Best Regards, > Georgios > > > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: woensdag 19 februari 2003 15:48 > To: Georgios Karagiannis (ELN) > Cc: 'Tschofenig Hannes'; nsis@ietf.org > Subject: Re: AW: [NSIS] Transport functionality in the NTLP > > > >>What do you mean? >>In wireless networks link layers provide such features!!!!! >>Please, do not impose performance degradations when it is not needed!!! > > > Since this is an engineering working group, maybe we can agree that > anybody who claims that "X causes a performance degradation" should at > least be kind enough to cite some verifiable evidence, not just hearsay, > and then also show that the replacement mechanism is free of those defects. > > As was pointed out during the interim meeting, nobody has proposed > mechanisms at the NSLP layer or (above-L4-transport) NTLP layer that > differ fundamentally from what we have at TCP or SCTP layer. It eludes > my understanding why the same mechanism implemented at higher layers > should be more efficient than implemented at lower layers. > > As was also discussed repeatedly, RFC 2961 shows what happens if you try > to do this at the "NSLP" layer: you get a mess and a transport mechanism > that reflects transport knowledge ca. 1975. > > If there is no congestion or loss, TCP (or SCTP) are essentially free, > except for the ACK (which you'll need in any event). > > > > >>Wireless scenarios are not specific applications!!!! >>Actually the goal of starting NSIS was to solve QoS issues in >>wireless scenarios. Please do not forget this!!!! >>Other types of scenarios could also use NSIS, but in my opinion >>NSIS should at least satisfy the requirements imposed by >>wireless scenarios!!! > > > You have unfortunately not made an engineering case, besides adding !!!, > that implementing reliability or other functionality below NTLP harms > wireless deployability. The debate would be furthered and be less > circular if you could do so by arguments other than assertions. > > Things like TCP header compression are available for wireless links; if > you replicate this at higher layers, you don't get the benefit of any of > those developments. > > That said, the design choice I presented explicitly allowed for > hop-by-hop unreliable forwarding, with only end-to-end reliability. Once > you actually measure the performance in high-loss links, you won't like > it, but it doesn't add substantial cost to the design. > > > >>Best Regards, >>Georgios > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 10:29:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17901 for ; Thu, 20 Feb 2003 10:29:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KFaC120958 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 10:36:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KFa9p20947; Thu, 20 Feb 2003 10:36:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KFZNp20927 for ; Thu, 20 Feb 2003 10:35:23 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17831 for ; Thu, 20 Feb 2003 10:28:15 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1KFW5SQ002701; Thu, 20 Feb 2003 07:32:05 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADP15969; Thu, 20 Feb 2003 07:32:04 -0800 (PST) Message-Id: <200302201532.ADP15969@mira-sjc5-c.cisco.com> To: john.loughney@nokia.com cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation In-Reply-To: Message from john.loughney@nokia.com of "Thu, 20 Feb 2003 15:55:44 +0200." Date: Thu, 20 Feb 2003 10:32:03 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > Determining the transport functionality is probably the big > issue to determine, so I'd be happy if the WG discussed > the needs for transport. As you know I'm somewhat concerned that a particular protocol is being promoted here and that's what's driving some of the framework and requirements. I'm trying to understand what the problems with existing protocols are perceived to be, and whether they're sufficient to drive a substantial change in the way signaling messages are carried between devices. Unfortunately Ping Pan's draft on transport issues hasn't been discussed here at all. The issues that have been identified are: 1) reliable transport 2) message packing 3) MTU issues 4) short-lived streams result in high signaling traffic volume relative to data traffic I could use further explanation of why the fourth is a problem peculiar to RSVP, since the signaling messages are going to be sent regardless of underlying transport. Also, it seems to me that the second and third are actually the same issue. With changes to RSVP message formats the only real issue with message packing is packet expansion. This is also likely to be a problem as stronger security mechanisms are added, and is potentially a big problem. Packet reassembly would increase the amount of transport-related state in RSVP. The one I'm really not sold on is reliable transport. Has this really proven to be a problem in practice? I can see it being a problem under congestion, but we're going to need to ensure that there are mechanisms for prioritizing signaling traffic anyway - we need to to care, at least, that teardown messages get through regardless of network load. Many applications going to need timers for whatever ends up being the analog of PATH/RESV anyway, in order to be able to provide affirmative success/failure responses in cases where that matters (telephony, for example - post-dial delay can be an issue and if the call is going fail you don't want to wait minutes for it to do so). I see the issues that are being raised here and don't agree with them completely. The question for me, ultimately, comes down to whether the functionality that's lost (the very neat way that RSVP handles routing, specifically) can be regained in another way that's nearly as lightweight and robust, and, if not, whether the gain in other functionality is worth the tradeoff. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 11:12:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19691 for ; Thu, 20 Feb 2003 11:12:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KGJRn24949 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 11:19:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGJHp24941; Thu, 20 Feb 2003 11:19:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGGPp24680 for ; Thu, 20 Feb 2003 11:16:25 -0500 Received: from mail.cs.helsinki.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19417 for ; Thu, 20 Feb 2003 11:09:15 -0500 (EST) Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 20 Feb 2003 18:13:05 +0200 Date: Thu, 20 Feb 2003 18:13:05 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation In-Reply-To: <200302201532.ADP15969@mira-sjc5-c.cisco.com> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, why couldn't we adopt the general approach what Ping Pan just proposed in his earlier email, that, let each individual choose the transport protocol that best suits a certain situation? The debate on "this is better than that in my scenario" will most probably not lead to a result anytime this year. Let's keep the choice as open as possible - wouldn't harm anyone, I guess. Cheers, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 11:25:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20065 for ; Thu, 20 Feb 2003 11:25:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KGWB225623 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 11:32:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGW8p25610; Thu, 20 Feb 2003 11:32:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGVSp25552 for ; Thu, 20 Feb 2003 11:31:28 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20015 for ; Thu, 20 Feb 2003 11:24:18 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h1KGRJsv003901; Thu, 20 Feb 2003 08:27:20 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABP61875; Thu, 20 Feb 2003 08:27:33 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA07815; Thu, 20 Feb 2003 08:27:33 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15957.501.317537.440156@thomasm-u1.cisco.com> Date: Thu, 20 Feb 2003 08:27:33 -0800 (PST) To: Jukka MJ Manner Cc: nsis@ietf.org Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation In-Reply-To: References: <200302201532.ADP15969@mira-sjc5-c.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit One word: complexity. Having a single mechanism for almost any protocol is preferable to a multiplicity unless there are *compelling* reasons to allow flexibility. By way of example, both English and Metric units both equally well solve problems in measurement. Their co-existence, however, at the very least has lead to a new crater on Mars. Closer to home, the SIP experience has taught that having multiple transports leads to some combinatorial explosion, not to mention unexpected problems with security, etc. Mike Jukka MJ Manner writes: > > Hi, > > why couldn't we adopt the general approach what Ping Pan just proposed in > his earlier email, that, let each individual choose the transport protocol > that best suits a certain situation? The debate on "this is better than > that in my scenario" will most probably not lead to a result anytime this > year. Let's keep the choice as open as possible - wouldn't harm anyone, I > guess. > > Cheers, > Jukka > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 11:32:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20284 for ; Thu, 20 Feb 2003 11:32:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KGdEe26798 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 11:39:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGd7p26784; Thu, 20 Feb 2003 11:39:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGcjp26755 for ; Thu, 20 Feb 2003 11:38:45 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20250 for ; Thu, 20 Feb 2003 11:31:34 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1KGcPm11194 for ; Thu, 20 Feb 2003 18:38:25 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Feb 2003 18:35:24 +0200 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Feb 2003 18:35:24 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Feb 2003 18:35:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] consensus probe on one aspect of NTLP operation Date: Thu, 20 Feb 2003 18:35:23 +0200 Message-ID: Thread-Topic: [NSIS] consensus probe on one aspect of NTLP operation Thread-Index: AcLY/TA8spDf/dmeRW6XxmUWF6zd9wAAMDeg To: , Cc: X-OriginalArrivalTime: 20 Feb 2003 16:35:24.0307 (UTC) FILETIME=[1148C630:01C2D8FE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1KGcjp26756 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Mike, > One word: complexity. Having a single mechanism > for almost any protocol is preferable to a > multiplicity unless there are *compelling* reasons > to allow flexibility. By way of example, both > English and Metric units both equally well solve > problems in measurement. Their co-existence, > however, at the very least has lead to a new > crater on Mars. Closer to home, the SIP experience > has taught that having multiple transports leads > to some combinatorial explosion, not to mention > unexpected problems with security, etc. Exactly - that was discussed at the interim meeting. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 11:38:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20491 for ; Thu, 20 Feb 2003 11:38:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KGjCh27240 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 11:45:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGj8p27233; Thu, 20 Feb 2003 11:45:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGimp27205 for ; Thu, 20 Feb 2003 11:44:48 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20480 for ; Thu, 20 Feb 2003 11:37:38 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h1KGeL5e029724 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Feb 2003 11:40:23 -0500 (EST) Message-ID: <3E5504FF.4030109@cs.columbia.edu> Date: Thu, 20 Feb 2003 11:40:31 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Thomas CC: Jukka MJ Manner , nsis@ietf.org Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation References: <200302201532.ADP15969@mira-sjc5-c.cisco.com> <15957.501.317537.440156@thomasm-u1.cisco.com> In-Reply-To: <15957.501.317537.440156@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit To amplify: I think the complexity arises if you need to support the functionality that one underlying mechanism offers at the higher layer elsewhere. If SIP, say, were to only support unreliable delivery using UDP, this would be fairly harmless. The problem arises once you try to replicate all the functionality at a higher layer. Not only do you get complexity, you get interactions between layers, timer collisions, issues with hybrid transports, etc. Thus, I have no problem with saying "support UDP (or raw IP) as an NSIS transport" as long as it is understood that this only offers whatever the network below offers, i.e., there is no attempt to "fix" the problem in RFC 2961 style. Or, put differently: if you want real transport functionality, use a real transport protocol (and if you think you don't need it and you can convince the keepers of the Internet architecture that you will never, ever cause congestion, you don't have to use one). Michael Thomas wrote: > One word: complexity. Having a single mechanism > for almost any protocol is preferable to a > multiplicity unless there are *compelling* reasons > to allow flexibility. By way of example, both > English and Metric units both equally well solve > problems in measurement. Their co-existence, > however, at the very least has lead to a new > crater on Mars. Closer to home, the SIP experience > has taught that having multiple transports leads > to some combinatorial explosion, not to mention > unexpected problems with security, etc. > > Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 11:59:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21356 for ; Thu, 20 Feb 2003 11:59:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KH6Hf29296 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 12:06:17 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KH6Dp29280; Thu, 20 Feb 2003 12:06:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KH1Up28606 for ; Thu, 20 Feb 2003 12:01:30 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21171 for ; Thu, 20 Feb 2003 11:54:19 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h1KGvFap024935; Thu, 20 Feb 2003 08:57:24 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABP64346; Thu, 20 Feb 2003 08:57:15 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA07825; Thu, 20 Feb 2003 08:57:14 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15957.2282.706249.930897@thomasm-u1.cisco.com> Date: Thu, 20 Feb 2003 08:57:14 -0800 (PST) To: Henning Schulzrinne Cc: Michael Thomas , Jukka MJ Manner , nsis@ietf.org Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation In-Reply-To: <3E5504FF.4030109@cs.columbia.edu> References: <200302201532.ADP15969@mira-sjc5-c.cisco.com> <15957.501.317537.440156@thomasm-u1.cisco.com> <3E5504FF.4030109@cs.columbia.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Here I depart company. There is no magical bright-line distinction between a "real" Transport Protocol, and application layer framing (ALF). On the plus side, using a "real" transport layer protocol, you inherit all of the years of experience and predictability of that protocol. On the minus side, you inherit all of the limitations as well. For TCP, that means head of line blocking and single-homing. For RSVP in particular, I don't really understand how "router alert" functionality and TCP/SCTP would get along. My guess: poorly. So, there's nothing wrong with considering ALF as Van pointed out during MEGACO. Good design can also borrow from the 20+ years of experience with the net as well, so it's not like rocket science to design a customized yet net-friendly transport these days. And if you end up with semantic overloading, etc, all you're pointing out is that the protocol wasn't designed in a modular way, not the inherent futility of the approach. As with most engineering, it's very contextual and depends a whole lot on the engineering tradeoffs; sweeping generalizations are rarely useful. Mike Henning Schulzrinne writes: > To amplify: I think the complexity arises if you need to support the > functionality that one underlying mechanism offers at the higher layer > elsewhere. If SIP, say, were to only support unreliable delivery using > UDP, this would be fairly harmless. The problem arises once you try to > replicate all the functionality at a higher layer. Not only do you get > complexity, you get interactions between layers, timer collisions, > issues with hybrid transports, etc. > > Thus, I have no problem with saying "support UDP (or raw IP) as an NSIS > transport" as long as it is understood that this only offers whatever > the network below offers, i.e., there is no attempt to "fix" the problem > in RFC 2961 style. > > Or, put differently: if you want real transport functionality, use a > real transport protocol (and if you think you don't need it and you can > convince the keepers of the Internet architecture that you will never, > ever cause congestion, you don't have to use one). > > Michael Thomas wrote: > > One word: complexity. Having a single mechanism > > for almost any protocol is preferable to a > > multiplicity unless there are *compelling* reasons > > to allow flexibility. By way of example, both > > English and Metric units both equally well solve > > problems in measurement. Their co-existence, > > however, at the very least has lead to a new > > crater on Mars. Closer to home, the SIP experience > > has taught that having multiple transports leads > > to some combinatorial explosion, not to mention > > unexpected problems with security, etc. > > > > Mike > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 12:44:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22712 for ; Thu, 20 Feb 2003 12:44:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KHpTg00512 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 12:51:29 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KHpGp00469; Thu, 20 Feb 2003 12:51:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KHmjp00358 for ; Thu, 20 Feb 2003 12:48:45 -0500 Received: from mailhost.chi1.ameritech.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22525 for ; Thu, 20 Feb 2003 12:41:33 -0500 (EST) Received: from repligate ([67.36.179.41]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20030220164803.GFFA3860.mailhost.chi1.ameritech.net@repligate>; Thu, 20 Feb 2003 10:48:03 -0600 Message-ID: <1be101c2d8ff$e467e770$8500a8c0@repligate> From: "Jim Fleming" To: "Henning Schulzrinne" , "Michael Thomas" Cc: "Jukka MJ Manner" , References: <200302201532.ADP15969@mira-sjc5-c.cisco.com> <15957.501.317537.440156@thomasm-u1.cisco.com> <3E5504FF.4030109@cs.columbia.edu> Date: Thu, 20 Feb 2003 10:48:26 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit Subject: [NSIS] "...real transport functionality..." ? Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit ----- Original Message ----- From: "Henning Schulzrinne" > > Or, put differently: if you want real transport functionality, use a > real transport protocol (and if you think you don't need it and you can > convince the keepers of the Internet architecture that you will never, > ever cause congestion, you don't have to use one). > Can you provide a picture of "the Internet architecture" ? Who are "the keepers of the Internet architecture" ? Jim Fleming Inter.C@T.Inter.NAT Consultant http://www.Unir.NET http://www.Unir.com http://www.Uni%ae.com http://www.Uni®.com _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 12:53:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22990 for ; Thu, 20 Feb 2003 12:53:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KI0UC01195 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 13:00:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KI0Lp01185; Thu, 20 Feb 2003 13:00:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KHxUp01081 for ; Thu, 20 Feb 2003 12:59:30 -0500 Received: from w2ksjexg01.ciena.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22966 for ; Thu, 20 Feb 2003 12:52:18 -0500 (EST) Received: from cs.columbia.edu (ppan [10.34.77.170]) by w2ksjexg01.ciena.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F2XT9YNS; Thu, 20 Feb 2003 09:55:52 -0800 Message-ID: <3E5516AE.9030506@cs.columbia.edu> Date: Thu, 20 Feb 2003 09:55:58 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en, zh MIME-Version: 1.0 To: nsis@ietf.org Subject: [Fwd: Re: AW: [NSIS] Transport functionality in the NTLP] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit send it again with the correct email address -------- Original Message -------- Subject: Re: AW: [NSIS] Transport functionality in the NTLP Date: Wed, 19 Feb 2003 11:00:19 -0800 From: Ping Pan To: "Georgios Karagiannis (ELN)" CC: 'Henning Schulzrinne' , 'Tschofenig Hannes' , nsis@ietf.org References: <2B06CD3FC17AF64587BC7A7617B230C0CBB8F4@enleent103.nl.eu.ericsson.se> Geoegios and Henning, I have a feeling that there is a misunderstanding here. Argument 1: if we have so many issues in the existing RSVP transport, and BGP/LDP are two operational protocols running over TCP between routers, then why not run RSVP payload over TCP between routers? (The overhead for a TCP socket is very small, at least in the latest FreeBSD and Linux.) This is a valid point. Argument 2: reliable message transport is a good thing, but it can be accomplished at different layers. In case of radio access network, there is a underlying reliable transport layer, and the wireless bandwidth is very expensive, so running RSVP raw-mode is just fine. Why TCP at all? This is also valid. After talking to Georgios during the interim meeting, I had made an effort to emphasis the importance of swapping transport layer protocols during my presentation. I suggest the following: in case of transporting RSVP payload (call it NTLP, if you wish), we could have three different methods: 1. RSVP raw-mode: as defined in the RFC, we can just run it over the reliable wireless access link. 2. RSVP-over-UDP: see the RFC. 3. RSVP-over-TCP: One TCP session is established between RSVP neighbors. (Check RSVP-TE to see how to discover and create RSVP neighbors.) For all RSVP messages, just send them through the TCP socket. Unless you want to support RSVP soft-state time-out, there would be no need to send refresh messages at all. I argue that we will save more link bandwidth, process less messages, and have less bugs to discover. There is one problem wrt the Path messages, since they are delivered e2e and use IP router alert option. Well... RSVP Path messages can be delivered hop-by-hop based on the destination address in the session object. There is no need to have this IP Router Alert option hack in the first place. In any regard, I think this would be work. If you want to feel secure, run your SCTP between routers. I have thought TCP/MD5 (free code BTW) would solve a lot of problems already. 2 cents, - Ping Georgios Karagiannis (ELN) wrote: > Hi Henning > > My main argument is as follows. > If a feature is not needed you should be able to > not use it! > If TCP is placed below NTLP, mandatory, you will have to support this feature > that you do not need! > Now the performance degradation that is imposed by using TCP > is related to: > * increased packet length (there are still open issues > related to header compression > of the SACK and TCP time stamp options); > * TCP is using a three-way handshake mechanism to establish a connection, > > Regarding setup delay, the above two issues cause a performance degradation, in > links that do not need to use these features. > > Best Regards, > Georgios > > > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: woensdag 19 februari 2003 15:48 > To: Georgios Karagiannis (ELN) > Cc: 'Tschofenig Hannes'; nsis@ietf.org > Subject: Re: AW: [NSIS] Transport functionality in the NTLP > > > >>What do you mean? >>In wireless networks link layers provide such features!!!!! >>Please, do not impose performance degradations when it is not needed!!! > > > Since this is an engineering working group, maybe we can agree that > anybody who claims that "X causes a performance degradation" should at > least be kind enough to cite some verifiable evidence, not just hearsay, > and then also show that the replacement mechanism is free of those defects. > > As was pointed out during the interim meeting, nobody has proposed > mechanisms at the NSLP layer or (above-L4-transport) NTLP layer that > differ fundamentally from what we have at TCP or SCTP layer. It eludes > my understanding why the same mechanism implemented at higher layers > should be more efficient than implemented at lower layers. > > As was also discussed repeatedly, RFC 2961 shows what happens if you try > to do this at the "NSLP" layer: you get a mess and a transport mechanism > that reflects transport knowledge ca. 1975. > > If there is no congestion or loss, TCP (or SCTP) are essentially free, > except for the ACK (which you'll need in any event). > > > > >>Wireless scenarios are not specific applications!!!! >>Actually the goal of starting NSIS was to solve QoS issues in >>wireless scenarios. Please do not forget this!!!! >>Other types of scenarios could also use NSIS, but in my opinion >>NSIS should at least satisfy the requirements imposed by >>wireless scenarios!!! > > > You have unfortunately not made an engineering case, besides adding !!!, > that implementing reliability or other functionality below NTLP harms > wireless deployability. The debate would be furthered and be less > circular if you could do so by arguments other than assertions. > > Things like TCP header compression are available for wireless links; if > you replicate this at higher layers, you don't get the benefit of any of > those developments. > > That said, the design choice I presented explicitly allowed for > hop-by-hop unreliable forwarding, with only end-to-end reliability. Once > you actually measure the performance in high-loss links, you won't like > it, but it doesn't add substantial cost to the design. > > > >>Best Regards, >>Georgios > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 13:07:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23472 for ; Thu, 20 Feb 2003 13:07:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KIE9g02670 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 13:14:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KIE5p02651; Thu, 20 Feb 2003 13:14:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KIDAp02595 for ; Thu, 20 Feb 2003 13:13:10 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23437 for ; Thu, 20 Feb 2003 13:05:57 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1KI5eB6007511; Thu, 20 Feb 2003 10:05:40 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABP71493; Thu, 20 Feb 2003 10:05:50 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA07834; Thu, 20 Feb 2003 10:05:49 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15957.6397.829116.554052@thomasm-u1.cisco.com> Date: Thu, 20 Feb 2003 10:05:49 -0800 (PST) To: Ping Pan Cc: "Georgios Karagiannis (ELN)" , "'Henning Schulzrinne'" , "'Tschofenig Hannes'" , nsis@ietf.org Subject: Re: AW: [NSIS] Transport functionality in the NTLP In-Reply-To: <3E53D443.6000900@ciena.com> References: <2B06CD3FC17AF64587BC7A7617B230C0CBB8F4@enleent103.nl.eu.ericsson.se> <3E53D443.6000900@ciena.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ping Pan writes: > One TCP session is established between RSVP neighbors. (Check RSVP-TE to > see how to discover and create RSVP neighbors.) For all RSVP messages, > just send them through the TCP socket. Unless you want to support RSVP > soft-state time-out, there would be no need to send refresh messages at > all. I argue that we will save more link bandwidth, process less > messages, and have less bugs to discover. Uh, how else would you reap dead routes/reservations? Which is really to say that the underlying transport is not exactly suited to the actual transport requirements, therefore those requirements must be hacked in at the appliation layer. This is why I think that Henning's "use a real transport layer" is a gloss and deserves a detailed look at *all* of the transport requirements. I suspect that in the end, a lot of this is six of one, half dozen of the other and that living with the devil you know (RSVP's transport) is at least proven to work, and that we don't want to be lured into the best being the enemy of the good. > There is one problem wrt the Path messages, since they are delivered e2e > and use IP router alert option. Well... RSVP Path messages can be > delivered hop-by-hop based on the destination address in the session > object. There is no need to have this IP Router Alert option hack in the > first place. This presupposes that there a 1:1 mapping of access to next hop and signaling. Router alert makes that requirement explicit. Something else would need to make the same requirement. It also possibly opens a can of worms of not making that a requirement. Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 13:14:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23885 for ; Thu, 20 Feb 2003 13:14:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KILG103085 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 13:21:16 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KILCp03074; Thu, 20 Feb 2003 13:21:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KIKap02988 for ; Thu, 20 Feb 2003 13:20:36 -0500 Received: from w2ksjexg01.ciena.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23840 for ; Thu, 20 Feb 2003 13:13:24 -0500 (EST) Received: from cs.columbia.edu (ppan [10.34.77.170]) by w2ksjexg01.ciena.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F2XT9ZZ4; Thu, 20 Feb 2003 10:16:46 -0800 Message-ID: <3E551B8F.7080405@cs.columbia.edu> Date: Thu, 20 Feb 2003 10:16:47 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en, zh MIME-Version: 1.0 To: Michael Thomas CC: Jukka MJ Manner , nsis@ietf.org Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation References: <200302201532.ADP15969@mira-sjc5-c.cisco.com> <15957.501.317537.440156@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The messages are sent between routers. Hop-by-hop. When delivering messages between hops, using a different transport mechanism based on the interface should be a common practice in development. Where is the complexity? Many protocols are processed independent from their transport layer protocol. In case of RSVP, based on the transmit interface, instead of writing to a raw socket, just send through a TCP socket. Don't see the complexity there. The interesting issue is how to maintain per-neighbor transport protocol type. Well, RFC2961 uses RSVP common header. RSVP-TE graceful restart uses the Hello messages. Take your pick, both are pretty simple to do. - Ping Michael Thomas wrote: > One word: complexity. Having a single mechanism > for almost any protocol is preferable to a > multiplicity unless there are *compelling* reasons > to allow flexibility. By way of example, both > English and Metric units both equally well solve > problems in measurement. Their co-existence, > however, at the very least has lead to a new > crater on Mars. Closer to home, the SIP experience > has taught that having multiple transports leads > to some combinatorial explosion, not to mention > unexpected problems with security, etc. > > Mike > > Jukka MJ Manner writes: > > > > Hi, > > > > why couldn't we adopt the general approach what Ping Pan just proposed in > > his earlier email, that, let each individual choose the transport protocol > > that best suits a certain situation? The debate on "this is better than > > that in my scenario" will most probably not lead to a result anytime this > > year. Let's keep the choice as open as possible - wouldn't harm anyone, I > > guess. > > > > Cheers, > > Jukka > > > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 13:23:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24251 for ; Thu, 20 Feb 2003 13:23:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KIU9u03678 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 13:30:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KIU5p03639; Thu, 20 Feb 2003 13:30:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KITIp03583 for ; Thu, 20 Feb 2003 13:29:18 -0500 Received: from w2ksjexg01.ciena.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24164 for ; Thu, 20 Feb 2003 13:22:07 -0500 (EST) Received: from cs.columbia.edu (ppan [10.34.77.170]) by w2ksjexg01.ciena.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F2XT95PH; Thu, 20 Feb 2003 10:25:40 -0800 Message-ID: <3E551DAA.7010909@cs.columbia.edu> Date: Thu, 20 Feb 2003 10:25:46 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en, zh MIME-Version: 1.0 To: Michael Thomas CC: Henning Schulzrinne , Jukka MJ Manner , nsis@ietf.org Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation References: <200302201532.ADP15969@mira-sjc5-c.cisco.com> <15957.501.317537.440156@thomasm-u1.cisco.com> <3E5504FF.4030109@cs.columbia.edu> <15957.2282.706249.930897@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Michael Thomas wrote: > Here I depart company. There is no magical > bright-line distinction between a "real" Transport > Protocol, and application layer framing (ALF). On > the plus side, using a "real" transport layer > protocol, you inherit all of the years of > experience and predictability of that protocol. On > the minus side, you inherit all of the limitations > as well. For TCP, that means head of line blocking > and single-homing. For RSVP in particular, I don't > really understand how "router alert" functionality > and TCP/SCTP would get along. My guess: poorly. > :-) yeap! > So, there's nothing wrong with considering ALF as > Van pointed out during MEGACO. Good design can > also borrow from the 20+ years of experience with > the net as well, so it's not like rocket science > to design a customized yet net-friendly transport > these days. And if you end up with semantic > overloading, etc, all you're pointing out is that > the protocol wasn't designed in a modular way, not > the inherent futility of the approach. As with > most engineering, it's very contextual and depends > a whole lot on the engineering tradeoffs; sweeping > generalizations are rarely useful. > Another issue is: why do we want to figure out all the transport layer stuff that has nothing to do with signaling protocol itself? For example, after looking at how OSPF doing its reliability delivery stuff, arn't you glad to see TCP is used in BGP? :-) - Ping _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 13:28:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24402 for ; Thu, 20 Feb 2003 13:28:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KIZBq03903 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 13:35:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KIZ8p03896; Thu, 20 Feb 2003 13:35:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KIYnp03850 for ; Thu, 20 Feb 2003 13:34:49 -0500 Received: from w2ksjexg01.ciena.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24352 for ; Thu, 20 Feb 2003 13:27:37 -0500 (EST) Received: from cs.columbia.edu (ppan [10.34.77.170]) by w2ksjexg01.ciena.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F2XT95XS; Thu, 20 Feb 2003 10:31:05 -0800 Message-ID: <3E551EF0.9070908@cs.columbia.edu> Date: Thu, 20 Feb 2003 10:31:12 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en, zh MIME-Version: 1.0 To: Michael Thomas CC: Ping Pan , "Georgios Karagiannis (ELN)" , "'Henning Schulzrinne'" , "'Tschofenig Hannes'" , nsis@ietf.org Subject: Re: AW: [NSIS] Transport functionality in the NTLP References: <2B06CD3FC17AF64587BC7A7617B230C0CBB8F4@enleent103.nl.eu.ericsson.se> <3E53D443.6000900@ciena.com> <15957.6397.829116.554052@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Michael Thomas wrote: > Ping Pan writes: > > One TCP session is established between RSVP neighbors. (Check RSVP-TE to > > see how to discover and create RSVP neighbors.) For all RSVP messages, > > just send them through the TCP socket. Unless you want to support RSVP > > soft-state time-out, there would be no need to send refresh messages at > > all. I argue that we will save more link bandwidth, process less > > messages, and have less bugs to discover. > > Uh, how else would you reap dead > routes/reservations? Easy. If the TCP session is gone, withdraw all associated stuff. LDP and BGP are working this way. Again, if explicit withdraw is too tough to deal with (not sure why), send periodic refresh as what has been defined in RSVP and RFC2961. - Ping > Which is really to say that > the underlying transport is not exactly suited to > the actual transport requirements, therefore those > requirements must be hacked in at the appliation > layer. This is why I think that Henning's "use a > real transport layer" is a gloss and deserves a > detailed look at *all* of the transport > requirements. I suspect that in the end, a lot of > this is six of one, half dozen of the other and > that living with the devil you know (RSVP's > transport) is at least proven to work, and that we > don't want to be lured into the best being the > enemy of the good. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 15:32:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28627 for ; Thu, 20 Feb 2003 15:32:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KKdQM13818 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 15:39:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KKdMp13810; Thu, 20 Feb 2003 15:39:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KKbOp13596 for ; Thu, 20 Feb 2003 15:37:24 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28553 for ; Thu, 20 Feb 2003 15:30:10 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA22627; Thu, 20 Feb 2003 15:33:58 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA29855; Thu, 20 Feb 2003 15:33:59 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Feb 2003 15:33:59 -0500 Message-ID: <39469E08BD83D411A3D900204840EC557634CD@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Ping Pan'" , nsis@ietf.org Subject: RE: [Fwd: Re: AW: [NSIS] Transport functionality in the NTLP] Date: Thu, 20 Feb 2003 15:33:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Ping, -> Argument 1: if we have so many issues in the existing RSVP transport, -> and BGP/LDP are two operational protocols running over TCP between -> routers, then why not run RSVP payload over TCP between routers? (The -> overhead for a TCP socket is very small, at least in the -> latest FreeBSD and Linux.) This is a valid point. I am interestingly following the thread. What I am wondering is, why are you not considering P2MP signaling for NTLP? If you restrict RSVP over TCP then aren't you making signaling only for P2P cases?!? Don't you want to benefit from IP multicasting when you really want to signal a call from one calling party to multiple called parties (etc etc)? Your paper reads... RSVP [RFC2205] was originally designed to support real-time applications over the Internet. Over the past several years, the demand for multicast-capable real-time teleconferencing, which many people had envisioned to be one of the key Internet applications that could benefit from network-wide deployment of RSVP, has never materialized. IMHO, making RSVP over TCP we are restricting the protocol too much. If you want reliability and the other benefits of TCP then fine but, I prefer, we should not jeopardize the envisioned future applications. Venkata. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 15:40:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28941 for ; Thu, 20 Feb 2003 15:40:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KKlSx14366 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 15:47:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KKlKp14342; Thu, 20 Feb 2003 15:47:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KKl0p14289 for ; Thu, 20 Feb 2003 15:47:00 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28928 for ; Thu, 20 Feb 2003 15:39:45 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h1KKhXxw018952 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Feb 2003 15:43:35 -0500 (EST) Message-ID: <3E553DFF.9090206@cs.columbia.edu> Date: Thu, 20 Feb 2003 15:43:43 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Naidu, Venkata" CC: "'Ping Pan'" , nsis@ietf.org Subject: Re: [Fwd: Re: AW: [NSIS] Transport functionality in the NTLP] References: <39469E08BD83D411A3D900204840EC557634CD@vie-msgusr-01.dc.fore.com> In-Reply-To: <39469E08BD83D411A3D900204840EC557634CD@vie-msgusr-01.dc.fore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit To avoid any non-issue discussions: The use of a reliable transport protocol, as envisioned, does not interfere at all with multicast use. Recall that RSVP forwards Resv messages hop-by-hop (unicast) as well. Naidu, Venkata wrote: > Ping, > > -> Argument 1: if we have so many issues in the existing RSVP transport, > -> and BGP/LDP are two operational protocols running over TCP between > -> routers, then why not run RSVP payload over TCP between routers? (The > -> overhead for a TCP socket is very small, at least in the > -> latest FreeBSD and Linux.) This is a valid point. > > I am interestingly following the thread. What I am wondering > is, why are you not considering P2MP signaling for NTLP? > If you restrict RSVP over TCP then aren't you making signaling > only for P2P cases?!? Don't you want to benefit from > IP multicasting when you really want to signal a call from > one calling party to multiple called parties (etc etc)? > > Your paper reads... > RSVP [RFC2205] was originally designed to support real-time > applications over the Internet. Over the past several years, the > demand for multicast-capable real-time teleconferencing, which many > people had envisioned to be one of the key Internet applications that > could benefit from network-wide deployment of RSVP, has never > materialized. > > IMHO, making RSVP over TCP we are restricting the protocol > too much. If you want reliability and the other benefits of TCP > then fine but, I prefer, we should not jeopardize the envisioned > future applications. > > Venkata. > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 16:21:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29946 for ; Thu, 20 Feb 2003 16:21:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KLSE816891 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 16:28:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KLSAp16872; Thu, 20 Feb 2003 16:28:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KLR1p16830 for ; Thu, 20 Feb 2003 16:27:01 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29918 for ; Thu, 20 Feb 2003 16:19:46 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA24773; Thu, 20 Feb 2003 16:23:35 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA06248; Thu, 20 Feb 2003 16:23:36 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Feb 2003 16:23:35 -0500 Message-ID: <39469E08BD83D411A3D900204840EC557634CE@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Ping Pan'" , "Georgios Karagiannis (ELN)" Cc: "'Henning Schulzrinne'" , "'Tschofenig Hannes'" , nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP Date: Thu, 20 Feb 2003 16:23:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Ping, -> I suggest the following: in case of transporting RSVP -> payload (call it NTLP, if you wish), we could have three -> different methods: -> -> 1. RSVP raw-mode: as defined in the RFC, we can just run it over the -> reliable wireless access link. -> -> 2. RSVP-over-UDP: see the RFC. -> -> 3. RSVP-over-TCP: -> -> If you want to feel secure, run your SCTP between routers. The other option is to split out the protocol into: - Transport independent part and - Transport dependent part, stub layer for each of the "accepted" (agreed upon) transport protocols Some of the recent protocols (MEGACO, look at section 9 in RFC2885 and AAL2 signaling etc) are following this tradition of giving flexibility of running a higher level protocols suited to different network environments. Venkata. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 16:51:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01042 for ; Thu, 20 Feb 2003 16:51:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KLwKU18994 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 16:58:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KLwGp18971; Thu, 20 Feb 2003 16:58:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KLvWp18925 for ; Thu, 20 Feb 2003 16:57:32 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01015 for ; Thu, 20 Feb 2003 16:50:16 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA26285; Thu, 20 Feb 2003 16:54:04 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA10512; Thu, 20 Feb 2003 16:54:06 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Feb 2003 16:54:05 -0500 Message-ID: <39469E08BD83D411A3D900204840EC557634CF@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Ping Pan'" , Michael Thomas Cc: "Georgios Karagiannis (ELN)" , "'Henning Schulzrinne'" , "'Tschofenig Hannes'" , nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP Date: Thu, 20 Feb 2003 16:53:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Ping, -> Ping Pan writes: -> One TCP session is established between RSVP neighbors. I can see some practical implications with my previous experience. Consider a scenario where multiple parallel links are between neighbors. The RSVP requirement as of today (with QoS restrictions) is that, some messages Path, Resv etc must follow the exact interface on which the Resource Reservation has to happen. AFAIK, with TCP we can't open a socket bound to an interface. We can force a packet out an interface with SO_DONTROUTE (ie IP_ROUTETOIF) socket option, but that option sets TTL to 1 which is not desired for RSVP. For example take LDP with per interface label space, then we should have multiple TCP sessions to the neighbor (one per each link - label space - connected to the neighbor). There are some such small implementation nits we have to consider when moving a protocol transport mechanism from one to the other. It is very hard to imagine all such hidden low level details, but some are definitely tied to the protocols (here, RSVP) core design. Thanks! Venkata. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 16:51:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01055 for ; Thu, 20 Feb 2003 16:51:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KLwKi19007 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 16:58:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KLwHp18986; Thu, 20 Feb 2003 16:58:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KLvXp18929 for ; Thu, 20 Feb 2003 16:57:33 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01017 for ; Thu, 20 Feb 2003 16:50:16 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1KT5SCY7>; Thu, 20 Feb 2003 21:54:06 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41806AC078D@rsys002a.roke.co.uk> From: "Hancock, Robert" To: nsis@ietf.org Subject: RE: [NSIS] consensus probe on one aspect of NTLP operation Date: Thu, 20 Feb 2003 21:53:59 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="x-user-defined" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , dear colleagues, It's precisely this 'you could do it N ways' possibility that led me to attempt to pose the question as a set of choices in my original email (actually on the other 'transport functionality' thread, but they seem pretty well entangled now). To make a more detailed example of the 'should we demand a high likelihood of delivery between adjacent NSIS entities' (which seems to be one of the most contentious issues), I see 4 basic cases: a) require the NTLP to do this b) require an analysis that the combination (NTLP+underlying network) does this c) make it optional, we leave it up to a local decision d) say it's a higher layer function to recover from this All of a/b/c/d are technically reasonable. If we say (a) we accept the cost of doing this hop-by-hop (complexity, constraints on protocol design, etc); on the other hand, we get the benefit that losing an e2e refresh in the NSLP will presumably be a very rare occurrence and so can be treated more crudely than something you expect to happen often. If we say (d), obviously the opposite applies (in each case). Ideally, for this case I'd like to imagine we can get to either (a) or (d). The other options seem less attractive. In particular: (c) means that an NSLP designer can never have any confidence that e2e packet drop won't be common. So any NSLP would have to be designed and coded with robust e2e refresh mechanisms, and the benefit of any local recovery will be largely lost. (c) is pretty well equivalent to (d) for this function. (b) is a more subtle issue, and I take the case of the 'reliable L2 wireless link' as a reasonable example: some link layers deliver reliably. But how easy is it to rely on this analysis in real life? Consider even almost the simplest possible example of a wired Ethernet link between two nodes. If the link lies in a single collision domain, you don't need a 'proper' transport layer to make delivery very likely; on the other hand, if there is bridging into a congested segment, loss is likely and there is no way for the sending node to know which is the case. So here, I would say (b) is only a reasonable alternative to (a) if you really guarantee (e.g. by manual deployment inspection or link quality monitoring) that it holds. That doesn't seem practical to me; maybe I'm just a pessimist. So, I would say we need to trade off (a) and (d) for this particular function. I don't know if it's possible to calculate that trade-off except by the 'mailing list clap-ometer' method, but there are at least concrete engineering arguments that can be made on each side. (Would anyone care to offer a summary?) Cheers, Robert H. PS. same process, maybe different conclusions, needed for the other transport-related functions, especially the contentious ones. so far, seem to be disagreements mainly about congestion/flow control and maybe MTU handling (fragmentation). > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 20 February 2003 17:35 > To: mat@cisco.com; jmanner@cs.helsinki.fi > Cc: nsis@ietf.org > Subject: RE: [NSIS] consensus probe on one aspect of NTLP operation > > > Hi Mike, > > > One word: complexity. Having a single mechanism > > for almost any protocol is preferable to a > > multiplicity unless there are *compelling* reasons > > to allow flexibility. By way of example, both > > English and Metric units both equally well solve > > problems in measurement. Their co-existence, > > however, at the very least has lead to a new > > crater on Mars. Closer to home, the SIP experience > > has taught that having multiple transports leads > > to some combinatorial explosion, not to mention > > unexpected problems with security, etc. > > Exactly - that was discussed at the interim meeting. > > John > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 17:20:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01834 for ; Thu, 20 Feb 2003 17:20:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KMRDf21469 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 17:27:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KMR9p21453; Thu, 20 Feb 2003 17:27:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KMPbp21374 for ; Thu, 20 Feb 2003 17:25:37 -0500 Received: from w2ksjexg01.ciena.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01733 for ; Thu, 20 Feb 2003 17:18:20 -0500 (EST) Received: from cs.columbia.edu (ppan [10.34.77.170]) by w2ksjexg01.ciena.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F2XT010M; Thu, 20 Feb 2003 14:21:54 -0800 Message-ID: <3E555507.70300@cs.columbia.edu> Date: Thu, 20 Feb 2003 14:21:59 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en, zh MIME-Version: 1.0 To: "Naidu, Venkata" CC: Michael Thomas , "Georgios Karagiannis (ELN)" , "'Henning Schulzrinne'" , "'Tschofenig Hannes'" , nsis@ietf.org Subject: Re: AW: [NSIS] Transport functionality in the NTLP References: <39469E08BD83D411A3D900204840EC557634CF@vie-msgusr-01.dc.fore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Naidu, Venkata wrote: > Ping, > > -> Ping Pan writes: > -> One TCP session is established between RSVP neighbors. > > I can see some practical implications with my previous > experience. Consider a scenario where multiple parallel > links are between neighbors. Not a problem. By definition, each RSVP neighbor is associated with the interface IP address. If there are multiple links in between, first, not sure the network should be config'ed that way. If it is, GMPLS has this unnumber-interface support. :-) > The RSVP requirement as of today > (with QoS restrictions) is that, some messages Path, Resv etc > must follow the exact interface on which the Resource > Reservation has to happen. > Yes. > AFAIK, with TCP we can't open a socket bound to an interface. > We can force a packet out an interface with SO_DONTROUTE > (ie IP_ROUTETOIF) socket option, but that option sets > TTL to 1 which is not desired for RSVP. > > For example take LDP with per interface label space, then > we should have multiple TCP sessions to the neighbor (one > per each link - label space - connected to the neighbor). > :-) Glad you bring this up. In LDP, there could be multiple TCP sessions. But there is only one is used for peering. Once the peering is established (with all that client-service figured out), cannot two nodes start to exchanged reservation information directly? You are right, we need to deal with the interface-binding more carefully. > There are some such small implementation nits we have to > consider when moving a protocol transport mechanism from one > to the other. It is very hard to imagine all such hidden > low level details, but some are definitely tied to the > protocols (here, RSVP) core design. Thanks! > Or start to read LDP. LDP's label merging stuff gives me stomachache, but its transport layer is pretty clean, IMHO. :-) - Ping > Venkata. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 20 17:24:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01953 for ; Thu, 20 Feb 2003 17:24:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1KMVbe21649 for nsis-archive@odin.ietf.org; Thu, 20 Feb 2003 17:31:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KMVWp21640; Thu, 20 Feb 2003 17:31:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KMRap21494 for ; Thu, 20 Feb 2003 17:27:36 -0500 Received: from w2ksjexg01.ciena.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01832 for ; Thu, 20 Feb 2003 17:20:19 -0500 (EST) Received: from cs.columbia.edu (ppan [10.34.77.170]) by w2ksjexg01.ciena.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F2XT0FCJ; Thu, 20 Feb 2003 14:23:53 -0800 Message-ID: <3E55557E.2000103@cs.columbia.edu> Date: Thu, 20 Feb 2003 14:23:58 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en, zh MIME-Version: 1.0 To: "Naidu, Venkata" CC: "'Ping Pan'" , "Georgios Karagiannis (ELN)" , "'Henning Schulzrinne'" , "'Tschofenig Hannes'" , nsis@ietf.org Subject: Re: AW: [NSIS] Transport functionality in the NTLP References: <39469E08BD83D411A3D900204840EC557634CE@vie-msgusr-01.dc.fore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Now you are killing me: multicast and AAL2. :-) Let's not go there please. :-) Naidu, Venkata wrote: > Ping, > > -> I suggest the following: in case of transporting RSVP > -> payload (call it NTLP, if you wish), we could have three > -> different methods: > -> > -> 1. RSVP raw-mode: as defined in the RFC, we can just run it over the > -> reliable wireless access link. > -> > -> 2. RSVP-over-UDP: see the RFC. > -> > -> 3. RSVP-over-TCP: > -> > -> If you want to feel secure, run your SCTP between routers. > > The other option is to split out the protocol into: > - Transport independent part and > - Transport dependent part, stub layer for each of > the "accepted" (agreed upon) transport protocols > > Some of the recent protocols (MEGACO, look at section 9 > in RFC2885 and AAL2 signaling etc) are following this > tradition of giving flexibility of running a higher level > protocols suited to different network environments. > > Venkata. > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Feb 21 03:29:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22831 for ; Fri, 21 Feb 2003 03:29:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1L8acN02871 for nsis-archive@odin.ietf.org; Fri, 21 Feb 2003 03:36:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L8aWp02864; Fri, 21 Feb 2003 03:36:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L8Z3p02824 for ; Fri, 21 Feb 2003 03:35:03 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22817 for ; Fri, 21 Feb 2003 03:27:34 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 21 Feb 2003 09:31:06 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Feb 2003 09:31:04 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE23B35F@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: robert.hancock@roke.co.uk Cc: nsis@ietf.org Subject: AW: [NSIS] consensus probe on one aspect of NTLP operation Date: Fri, 21 Feb 2003 09:30:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="x-user-defined" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1L8Z3p02825 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit dear colleagues, From a carrier point of view, reliability in signaling transport is a must. If packets get lost during phases of congestion, the added load on systems having to cope with these losses must be minimised. Congestion frienliness may be helpful. I guess, the lower the layer dealing with the issue, the better. a) therefore is the preferred choice. I didn't say "transport must be TCP". I just listed some requirements. It may be helpful if we first discuss requirements and continue with solutions later. Regards, Rüdiger | To make a more detailed example of the 'should we demand a | high likelihood of delivery between adjacent NSIS entities' | (which seems to be one of the most contentious issues), I see | 4 basic cases: | a) require the NTLP to do this _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Feb 21 03:43:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23169 for ; Fri, 21 Feb 2003 03:43:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1L8oDj04071 for nsis-archive@odin.ietf.org; Fri, 21 Feb 2003 03:50:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L8o9p04052; Fri, 21 Feb 2003 03:50:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L8jap03897 for ; Fri, 21 Feb 2003 03:45:36 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23088 for ; Fri, 21 Feb 2003 03:38:07 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 21 Feb 2003 09:41:44 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Feb 2003 09:41:42 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE23B360@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: jmanner@cs.Helsinki.FI Cc: nsis@ietf.org Subject: AW: [NSIS] consensus probe on one aspect of NTLP operation Date: Fri, 21 Feb 2003 09:41:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Jukka, If there isn't at least one and only one default transport protocol which must be supported by each box, I doubt that the resulting NSIS protocol suite will work in a heterogeneous environment. Regards, Rudiger | why couldn't we adopt the general approach what Ping Pan just | proposed in his earlier email, that, let each individual | choose the transport protocol that best suits a certain | situation? The debate on "this is better than that in my | scenario" will most probably not lead to a result anytime | this year. Let's keep the choice as open as possible - | wouldn't harm anyone, I guess. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Feb 21 04:24:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24061 for ; Fri, 21 Feb 2003 04:24:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1L9VED06776 for nsis-archive@odin.ietf.org; Fri, 21 Feb 2003 04:31:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L9V9p06766; Fri, 21 Feb 2003 04:31:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L9UFp06731 for ; Fri, 21 Feb 2003 04:30:15 -0500 Received: from mail.cs.helsinki.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24045 for ; Fri, 21 Feb 2003 04:22:45 -0500 (EST) Received: from mannersaari.cs.Helsinki.FI (mannersaari.cs.helsinki.fi [::ffff:128.214.11.173]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 21 Feb 2003 11:26:35 +0200 Date: Fri, 21 Feb 2003 11:26:35 +0200 (EET) From: Jukka MJ Manner To: nsis@ietf.org Subject: Re: AW: [NSIS] consensus probe on one aspect of NTLP operation In-Reply-To: <9F8582E37B2EE5498E76392AEDDCD3FE23B360@G8PQD.blf01.telekom.de> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Well, you can always define that an implementation MUST support transport protocol X and MAY support other transport protocols, too. "Transport protocol X" could be something (very) simple and probably unreliable. Jukka On Fri, 21 Feb 2003, Geib, Ruediger wrote: > Jukka, > > If there isn't at least one and only one default transport > protocol which must be supported by each box, I doubt that > the resulting NSIS protocol suite will work in a > heterogeneous environment. > > Regards, Rudiger > > | why couldn't we adopt the general approach what Ping Pan just > | proposed in his earlier email, that, let each individual > | choose the transport protocol that best suits a certain > | situation? The debate on "this is better than that in my > | scenario" will most probably not lead to a result anytime > | this year. Let's keep the choice as open as possible - > | wouldn't harm anyone, I guess. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Feb 21 04:51:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24487 for ; Fri, 21 Feb 2003 04:51:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1L9wSL08367 for nsis-archive@odin.ietf.org; Fri, 21 Feb 2003 04:58:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L9wOp08358; Fri, 21 Feb 2003 04:58:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1L9vBp08329 for ; Fri, 21 Feb 2003 04:57:11 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24464 for ; Fri, 21 Feb 2003 04:49:40 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1L9qH214591 for ; Fri, 21 Feb 2003 11:52:17 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 21 Feb 2003 11:53:29 +0200 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 21 Feb 2003 11:53:28 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 21 Feb 2003 11:53:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="x-user-defined" Subject: RE: [NSIS] consensus probe on one aspect of NTLP operation Date: Fri, 21 Feb 2003 11:53:27 +0200 Message-ID: Thread-Topic: [NSIS] consensus probe on one aspect of NTLP operation Thread-Index: AcLZg94RZFJ6mO/MQPOiqJch9nYr/AACx+Uw To: , Cc: X-OriginalArrivalTime: 21 Feb 2003 09:53:28.0598 (UTC) FILETIME=[159D5B60:01C2D98F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1L9vBp08330 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Rudiger, > From a carrier point of view, reliability in signaling > transport is a must. If packets get lost during phases of > congestion, the added load on systems having to cope with > these losses must be minimised. Congestion frienliness may be > helpful. I guess, the lower the layer dealing with the issue, > the better. a) therefore is the preferred choice. > > I didn't say "transport must be TCP". I just listed some > requirements. It may be helpful if we first discuss > requirements and continue with solutions later. Is a soft-state refresh sufficient for reliability, or do you think guarenteed delivery to be important? thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Feb 21 04:54:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24541 for ; Fri, 21 Feb 2003 04:54:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LA18H08578 for nsis-archive@odin.ietf.org; Fri, 21 Feb 2003 05:01:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LA15p08563; Fri, 21 Feb 2003 05:01:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LA0mp08505 for ; Fri, 21 Feb 2003 05:00:48 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24528 for ; Fri, 21 Feb 2003 04:53:17 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1L9v7Av001558; Fri, 21 Feb 2003 10:57:07 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVJ3KF5; Fri, 21 Feb 2003 10:57:07 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Feb 2003 10:47:57 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB904@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: e2128bac 9ffcebbb a5ee123c 00000138 From: "Georgios Karagiannis (ELN)" To: "'john.loughney@nokia.com'" , Ruediger.Geib@t-systems.com Cc: nsis@ietf.org Subject: RE: [NSIS] consensus probe on one aspect of NTLP operation Date: Fri, 21 Feb 2003 10:53:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="x-user-defined" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi John and Ruediger I think soft state refresh should be a must, the rest is optimization, thus optional! Best Regards, Georgios -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: vrijdag 21 februari 2003 10:53 To: Ruediger.Geib@t-systems.com; robert.hancock@roke.co.uk Cc: nsis@ietf.org Subject: RE: [NSIS] consensus probe on one aspect of NTLP operation Rudiger, > From a carrier point of view, reliability in signaling > transport is a must. If packets get lost during phases of > congestion, the added load on systems having to cope with > these losses must be minimised. Congestion frienliness may be > helpful. I guess, the lower the layer dealing with the issue, > the better. a) therefore is the preferred choice. > > I didn't say "transport must be TCP". I just listed some > requirements. It may be helpful if we first discuss > requirements and continue with solutions later. Is a soft-state refresh sufficient for reliability, or do you think guarenteed delivery to be important? thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Feb 21 04:55:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24576 for ; Fri, 21 Feb 2003 04:55:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LA28508627 for nsis-archive@odin.ietf.org; Fri, 21 Feb 2003 05:02:08 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LA24p08615; Fri, 21 Feb 2003 05:02:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LA1Ep08593 for ; Fri, 21 Feb 2003 05:01:14 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24538 for ; Fri, 21 Feb 2003 04:53:43 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 21 Feb 2003 10:55:29 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Feb 2003 10:55:17 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE23B361@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: jmanner@cs.Helsinki.FI Cc: nsis@ietf.org Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation Date: Fri, 21 Feb 2003 10:55:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , | Well, you can always define that an implementation MUST | support transport protocol X and MAY support other | transport protocols, too. Agreed. | "Transport protocol X" could be something (very) simple | and probably unreliable. Simplicity is always welcome. But unreliable signaling transport causes me a headache. Is there any experience with other signaling protocols indicating that unreliable signaling transport is the best way of conveying this type of information? Regards, Rudiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Feb 21 05:07:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24829 for ; Fri, 21 Feb 2003 05:07:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LAEJA09883 for nsis-archive@odin.ietf.org; Fri, 21 Feb 2003 05:14:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LAE5p09846; Fri, 21 Feb 2003 05:14:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LADFp09805 for ; Fri, 21 Feb 2003 05:13:15 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24812 for ; Fri, 21 Feb 2003 05:05:44 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1LA9YKV004462 for ; Fri, 21 Feb 2003 11:09:34 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVMWQSM; Fri, 21 Feb 2003 11:09:34 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Feb 2003 11:00:24 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB906@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 4430d478 9ffcebbb 7a95d2f4 00000138 From: "Georgios Karagiannis (ELN)" To: nsis@ietf.org Date: Fri, 21 Feb 2003 11:06:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] motivation of using RSVPv1 as NTLP Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi all Below I try to give a motivation of why is good to use RSVPv1 (RFC2205) as NTLP! A great deal of effort was put into the specification and design of the RSVPv1 (RFC2205) protocol. RSVPv1 is well-designed for the applications for which it was intended and worked hard to provide a modular protocol within the constraints of its intended use. The NSIS WG uses the two-level architecture for Internet Signaling proposed in (in Bob's two-level architecture draft): (1) a common lower level that performs transport-layer functions. This common lower level is denoted in (NSIS framework draft) as NSIS Transport Layer Protocol (NTLP) that is a placeholder name for the NSIS protocol component that will support lower layer (signaling application independent) functions. (2) a set of upper-level signaling functions that are specific to particular signaling applications. These upper-level signaling tasks and functions are accomplished by a set of signaling layer protocols denoted in (NSIS framework draft) as NSIS Signaling Layer Protocol (NSLP). The main transport-layer features supported by RSVPv1 (RFC2205), such as support of unicast path-coupled signaling and soft state support have been proven in practice of being lightweight and robust. However, the multicast support introduces a level of complexity into the RSVPv1 protocol that is not needed in support of unicast applications. For example, RSVPv1's state maintenance is complex as it needs to support dynamic membership changes in the multicast groups, such as reservation state merging and maintenance. Our working assumption is that RSVPv1 should be optimized for unicast rather than multicast and that relaxing this design constraint will in turn greatly simplify the protocol. Using RSVPv1 as NTLP will eliminate the need of reinventing solutions for transport-layer features. Furthermore, this will shorten the time needed to standardize NTLP by reusing the current RSVP design experience and RSVP protocol specification. Moreover, after minor modifications, existing RSVPv1 (RFC2205) implementations can be reused and used as NTLP, decreasing the deployment costs. Additional transport-layer features can be introduced in a modular way, either by adding them one by one as optional features into the NTLP specifications and implementations or using an existing protocol below NTLP that could provide these additional features. Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Feb 21 05:15:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25033 for ; Fri, 21 Feb 2003 05:15:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LAM9D10275 for nsis-archive@odin.ietf.org; Fri, 21 Feb 2003 05:22:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LAM6p10267; Fri, 21 Feb 2003 05:22:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LALAp10233 for ; Fri, 21 Feb 2003 05:21:10 -0500 Received: from fw9.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25001 for ; Fri, 21 Feb 2003 05:13:38 -0500 (EST) Received: by fw9.telekom.de; (5.65v4.0/1.3/10May95) id AA02159; Fri, 21 Feb 2003 11:01:56 +0100 Received: from g8pbr.blf01.telekom.de by G8PXB.blf01.telekom.de with ESMTP; Fri, 21 Feb 2003 11:14:53 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Feb 2003 11:14:46 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE23B362@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: john.loughney@nokia.com Cc: nsis@ietf.org Subject: AW: [NSIS] consensus probe on one aspect of NTLP operation Date: Fri, 21 Feb 2003 11:14:44 +0100 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="x-user-defined" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1LALAp10236 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit John, I think that all reliable transport protocols reqiure some kind of refresh mechanism. I'd guess that the further up the protocol stack you allocate it, the more processing is required and the slower the response to congestion. I agree with Henning, that providing evidence based on simulations or implementations would be nice. But yes, apples must be compared with apples... I don't want to say, let's take TCP. However I recognise that I can't offer a reasonable alternative - and I certainly don't want to specify a new transport protocol. For backbone systems involved into signaling, network congestion must not result in increased signaling traffic, amplifying the stress of a router having to cope with congestion already. A good way of doing so seems to be to leave handling of congestion and reliable transport out of the signaling layer. Regards, Rüdiger | -----Ursprüngliche Nachricht----- | Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com] | Gesendet: Freitag, 21. Februar 2003 10:53 | An: Geib, Rüdiger; robert.hancock@roke.co.uk | Cc: nsis@ietf.org | Betreff: RE: [NSIS] consensus probe on one aspect of NTLP operation | | | Rudiger, | | | > From a carrier point of view, reliability in signaling | > transport is a must. If packets get lost during phases of | > congestion, the added load on systems having to cope with | > these losses must be minimised. Congestion frienliness may be | > helpful. I guess, the lower the layer dealing with the issue, | > the better. a) therefore is the preferred choice. | > | > I didn't say "transport must be TCP". I just listed some | > requirements. It may be helpful if we first discuss | > requirements and continue with solutions later. | | Is a soft-state refresh sufficient for reliability, or do you | think guarenteed delivery to be important? | | thanks, | John | _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Feb 21 09:22:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01120 for ; Fri, 21 Feb 2003 09:22:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LETE826155 for nsis-archive@odin.ietf.org; Fri, 21 Feb 2003 09:29:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LETBp26148; Fri, 21 Feb 2003 09:29:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LESJp26108 for ; Fri, 21 Feb 2003 09:28:19 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01066 for ; Fri, 21 Feb 2003 09:20:43 -0500 (EST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1LEOLB6007914; Fri, 21 Feb 2003 06:24:21 -0800 (PST) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADQ44201; Fri, 21 Feb 2003 06:24:31 -0800 (PST) Message-Id: <200302211424.ADQ44201@mira-sjc5-c.cisco.com> To: "Georgios Karagiannis (ELN)" cc: "'john.loughney@nokia.com'" , Ruediger.Geib@t-systems.com, nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation In-Reply-To: Message from Georgios.Karagiannis@eln.ericsson.se of "Fri, 21 Feb 2003 10:53:40 +0100." <2B06CD3FC17AF64587BC7A7617B230C0CBB904@enleent103.nl.eu.ericsson.se> Date: Fri, 21 Feb 2003 09:24:31 -0500 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , > I think soft state refresh should be a must, > the rest is optimization, thus optional! I think that's a good way to put it. In some cases the optimizations may belong in the application that's invoking the signaling (real-time applications that need affirmative failure responses for call admission/call completion decisions), in some cases it may belong in the NSLP (which might provide an API to the higher-layer application), etc. I tend to think of the problem in the context of real-time applications, which puts the reliability question into a slightly different light. There's a point at which delivery of the signaling request has no value (extreme example - it takes 90 seconds to request a reservation and get a response), and reliable delivery is a disadvantage in those cases. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Feb 21 13:08:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09469 for ; Fri, 21 Feb 2003 13:08:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LIFSu09901 for nsis-archive@odin.ietf.org; Fri, 21 Feb 2003 13:15:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LIFLp09881; Fri, 21 Feb 2003 13:15:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LICDp09781 for ; Fri, 21 Feb 2003 13:12:13 -0500 Received: from thoth.sbs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09359 for ; Fri, 21 Feb 2003 13:04:30 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id h1LI8MN13050; Fri, 21 Feb 2003 19:08:22 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id h1LI8Lu19871; Fri, 21 Feb 2003 19:08:21 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Feb 2003 19:08:21 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F034C88EF@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Georgios Karagiannis (ELN)'" Cc: nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP Date: Fri, 21 Feb 2003 19:08:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi georgios please see my comments inline: > > > >> 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. > > 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; 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 > > > Best Regards, > Georgios > > > > > > -----Original Message----- > > From: Tschofenig Hannes [mailto:Hannes.Tschofenig@mchp.siemens.de] > > Sent: woensdag 19 februari 2003 14:56 > > To: Georgios Karagiannis (ELN) > > Cc: nsis@ietf.org > > Subject: RE: AW: [NSIS] Transport functionality in the NTLP > > > > > > hi georgios > > > > i have difficulties to see your arguments agains peer-to-peer > > addressing. > > they have nothing todo with the wireless network. > > > > ciao > > hannes > > > > > > > -----Original Message----- > > > From: Georgios Karagiannis (ELN) > > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > > Sent: Wednesday, February 19, 2003 1:47 PM > > > To: Georgios Karagiannis (ELN); Tschofenig Hannes > > > Cc: nsis@ietf.org > > > Subject: RE: AW: [NSIS] Transport functionality in the NTLP > > > > > > > > > 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: nsis@ietf.org > > > Subject: RE: AW: [NSIS] Transport functionality in the NTLP > > > > > > > > > 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:Hannes.Tschofenig@mchp.siemens.de] > > > Sent: woensdag 19 februari 2003 11:57 > > > To: Lars Westberg (EAB); Geib, Ruediger > > > Cc: robert.hancock@roke.co.uk; nsis@ietf.org > > > Subject: RE: AW: [NSIS] Transport functionality in the NTLP > > > > > > > > > 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:Lars.Westberg@era.ericsson.se] > > > > Sent: Wednesday, February 19, 2003 11:28 AM > > > > To: Geib, Ruediger > > > > Cc: robert.hancock@roke.co.uk; nsis@ietf.org > > > > 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 > > > > > nsis@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Feb 21 13:10:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09530 for ; Fri, 21 Feb 2003 13:10:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LIHsC10022 for nsis-archive@odin.ietf.org; Fri, 21 Feb 2003 13:17:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LIHop10015; Fri, 21 Feb 2003 13:17:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LIEtp09860 for ; Fri, 21 Feb 2003 13:14:55 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09426 for ; Fri, 21 Feb 2003 13:07:13 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id h1LIB5218596; Fri, 21 Feb 2003 19:11:05 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id h1LIB4u20591; Fri, 21 Feb 2003 19:11:04 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Feb 2003 19:11:04 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F034C88F0@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Georgios Karagiannis (ELN)'" Cc: nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP Date: Fri, 21 Feb 2003 19:11:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi georgios please see my comments inline: > Hi Hannes > > > 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). > > As I already mentioned, first we have to agree on the definition > 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. > > > >> as you know: the charter changed some time ago - nsis now > tries to be more > >> generic. > > The WG charter changed some times, but anyway > 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 > > Best regards, > Georgios > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Feb 21 15:13:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13320 for ; Fri, 21 Feb 2003 15:13:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1LKL9G18068 for nsis-archive@odin.ietf.org; Fri, 21 Feb 2003 15:21:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LKL6p18052; Fri, 21 Feb 2003 15:21:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1LKIRp17964 for ; Fri, 21 Feb 2003 15:18:27 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13199 for ; Fri, 21 Feb 2003 15:10:44 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h1LKEIsv008442 for ; Fri, 21 Feb 2003 12:14:18 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABQ86492; Fri, 21 Feb 2003 12:14:32 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA08069; Fri, 21 Feb 2003 12:14:32 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15958.34984.550692.416449@thomasm-u1.cisco.com> Date: Fri, 21 Feb 2003 12:14:32 -0800 (PST) To: In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Subject: [NSIS] fast mobility concerns w/ NLTP Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Something that I think has gotten a bit of the short-shrift in the discussions from what I can tell is the inherent problems with messaging and mobility. The current cellular/pstn infrastructure is highly optimized not only for bandwidth which is often trotted out as a forcing function, but more importantly IMO for handoffs. The march of progress, IMO, will address the former, but I'm not as convinced that latencies will advance at nearly the pace. Part of the problem here is a somewhat systemic problem within IETF which stovepipes problems and doesn't do "architectures". While I have a great deal of respect for that approach, I suspect that the physics of fast mobility is going to be harder to ignore: the PSTN, after all, only does a barely adequate job of handoffs, and it's a customized network for a customized application... unlike the internet which is neither. For NSIS in particular, I don't recall anybody asking what the cost of establishing and reestablishing connection state is in the face of the longer term goal of wanting to provide real time mobility for, oh say, VoIP. RSVP is essentially a command/response kind of protocol whereas TCP/SCTP requires a *prior* threeway handshake before anything useful gets done. For things that aren't moving, maybe that doesn't make much difference. For things that are... I suspect that the total message count -- and how localized those messages are -- will make a tremendous difference. This problem is certainly not NSIS's alone, but every bit counts. Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Feb 21 19:48:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19921 for ; Fri, 21 Feb 2003 19:48:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1M0u9s02010 for nsis-archive@odin.ietf.org; Fri, 21 Feb 2003 19:56:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1M0u5p01991; Fri, 21 Feb 2003 19:56:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1M0rBp01911 for ; Fri, 21 Feb 2003 19:53:12 -0500 Received: from w2ksjexg01.ciena.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19859 for ; Fri, 21 Feb 2003 19:45:22 -0500 (EST) Received: from cs.columbia.edu (ppan [10.34.77.170]) by w2ksjexg01.ciena.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FMVZVQYN; Fri, 21 Feb 2003 16:48:48 -0800 Message-ID: <3E56C8F6.3080601@cs.columbia.edu> Date: Fri, 21 Feb 2003 16:48:54 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en, zh MIME-Version: 1.0 To: "Geib, Ruediger" CC: jmanner@cs.Helsinki.FI, nsis@ietf.org Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation References: <9F8582E37B2EE5498E76392AEDDCD3FE23B361@G8PQD.blf01.telekom.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Geib, Ruediger wrote: > Simplicity is always welcome. But unreliable signaling > transport causes me a headache. Is there any experience > with other signaling protocols indicating that > unreliable signaling transport is the best way of > conveying this type of information? > > Regards, Rudiger I think when people want to design a protocol initially, they don't want to be too bothered with message reliability issue. In many cases, they can get away with it, such as RTP/RTCP. Sometimes, what they have defined would eventually work, e.g., SNMP, OSPF etc. Sometimes, people just regret it. I wonder if SIP is a such example. :-) As a developer, I certainly have not been happy with RSVP refreshes. We attempted to fix it once, and got it working. Then, one day, Henning challenged me about our work 5 years ago. At the end of the day, we thought if we had to do it all over again, TCP would be a better alternative. The point here is that if we already know some design decisions are problematic, should we continue to follow the same design later on? 2 cents, - Ping _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Feb 21 19:55:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20025 for ; Fri, 21 Feb 2003 19:55:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1M12s402235 for nsis-archive@odin.ietf.org; Fri, 21 Feb 2003 20:02:54 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1M12np02227; Fri, 21 Feb 2003 20:02:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1M10ap02169 for ; Fri, 21 Feb 2003 20:00:36 -0500 Received: from w2ksjexg01.ciena.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19999 for ; Fri, 21 Feb 2003 19:52:45 -0500 (EST) Received: from cs.columbia.edu (ppan [10.34.77.170]) by w2ksjexg01.ciena.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FMVZVR2B; Fri, 21 Feb 2003 16:56:21 -0800 Message-ID: <3E56CAC2.6000309@cs.columbia.edu> Date: Fri, 21 Feb 2003 16:56:34 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en, zh MIME-Version: 1.0 To: "Georgios Karagiannis (ELN)" CC: nsis@ietf.org Subject: Re: [NSIS] motivation of using RSVPv1 as NTLP References: <2B06CD3FC17AF64587BC7A7617B230C0CBB906@enleent103.nl.eu.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Georgios, Your argument below simply says since RSVPv1 has been designed, let's continue to use it (though it has some flaws). Unfortunately, in this logic, we should simply use GRE as NTLP. At least GRE has more deployment than RSVP. :-) - Ping Georgios Karagiannis (ELN) wrote: > Hi all > > Below I try to give a motivation of why is good > to use RSVPv1 (RFC2205) as NTLP! > > > A great deal of effort was put into the specification and design > of the RSVPv1 (RFC2205) protocol. RSVPv1 is well-designed for > the applications for which it was intended and worked hard to provide > a modular protocol within the constraints of its intended use. > The NSIS WG uses the two-level architecture for Internet Signaling > proposed in (in Bob's two-level architecture draft): > > (1) a common lower level that performs transport-layer functions. > This common lower level is denoted in (NSIS framework draft) > as NSIS Transport Layer Protocol (NTLP) that is a placeholder > name for the NSIS protocol component that will support lower > layer (signaling application independent) functions. > (2) a set of upper-level signaling functions that are specific > to particular signaling applications. These upper-level > signaling tasks and functions are accomplished by a set of > signaling layer protocols denoted in (NSIS framework draft) > as NSIS Signaling Layer Protocol (NSLP). > > The main transport-layer features supported by RSVPv1 (RFC2205), such > as support of unicast path-coupled signaling and soft state support > have been proven in practice of being lightweight and robust. However, > the multicast support introduces a level of complexity into the RSVPv1 > protocol that is not needed in support of unicast applications. For > example, RSVPv1's state maintenance is complex as it needs to support > dynamic membership changes in the multicast groups, such as reservation > state merging and maintenance. > > Our working assumption is that RSVPv1 should be optimized for unicast > rather than multicast and that relaxing this design constraint will > in turn greatly simplify the protocol. > > Using RSVPv1 as NTLP will eliminate the need of reinventing solutions > for transport-layer features. Furthermore, this will shorten the time > needed to standardize NTLP by reusing the current RSVP design > experience and RSVP protocol specification. Moreover, after minor > modifications, existing RSVPv1 (RFC2205) implementations can be reused > and used as NTLP, decreasing the deployment costs. > > Additional transport-layer features can be introduced in a modular way, > either by adding them one by one as optional features into the NTLP > specifications and implementations or using an existing protocol below > NTLP that could provide these additional features. > > Best regards, > Georgios > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Feb 23 02:20:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03596 for ; Sun, 23 Feb 2003 02:20:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1N7Sp614645 for nsis-archive@odin.ietf.org; Sun, 23 Feb 2003 02:28:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N7Shp14633; Sun, 23 Feb 2003 02:28:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1N7Ncp14334 for ; Sun, 23 Feb 2003 02:23:38 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03510 for ; Sun, 23 Feb 2003 02:15:11 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1N7M8m11025 for ; Sun, 23 Feb 2003 09:22:08 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 23 Feb 2003 09:19:02 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 23 Feb 2003 09:19:03 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 23 Feb 2003 09:19:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] fast mobility concerns w/ NLTP Date: Sun, 23 Feb 2003 09:19:02 +0200 Message-ID: Thread-Topic: [NSIS] fast mobility concerns w/ NLTP Thread-Index: AcLZ5kSFNsQ3ja9dQWaHO33pnl1WqgBJUM1A To: , X-OriginalArrivalTime: 23 Feb 2003 07:19:03.0472 (UTC) FILETIME=[D7FED300:01C2DB0B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1N7Ncp14335 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Micheal, > For NSIS in particular, I don't recall anybody > asking what the cost of establishing and > reestablishing connection state is in the face of > the longer term goal of wanting to provide real > time mobility for, oh say, VoIP. RSVP is > essentially a command/response kind of protocol > whereas TCP/SCTP requires a *prior* threeway > handshake before anything useful gets done. For > things that aren't moving, maybe that doesn't make > much difference. For things that are... I suspect > that the total message count -- and how localized > those messages are -- will make a tremendous > difference. This problem is certainly not NSIS's > alone, but every bit counts. One suggestion has been that the TCP/SCTP connections be already setup; this may help with response times. This kind of solution looks very 3G RAN-ish to me, requiring a lot of extra state/connections to exist, a-priori. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Feb 24 03:46:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04873 for ; Mon, 24 Feb 2003 03:46:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1O8sxN07778 for nsis-archive@odin.ietf.org; Mon, 24 Feb 2003 03:54:59 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O8sqp07763; Mon, 24 Feb 2003 03:54:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O8ppp07665 for ; Mon, 24 Feb 2003 03:51:52 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04850 for ; Mon, 24 Feb 2003 03:42:53 -0500 (EST) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h1O8kUR59409; Mon, 24 Feb 2003 09:46:30 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 160E088061; Mon, 24 Feb 2003 09:44:23 +0100 (CET) Date: Mon, 24 Feb 2003 09:44:28 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: john.loughney@nokia.com, mat@cisco.com, nsis@ietf.org Subject: RE: [NSIS] fast mobility concerns w/ NLTP Message-ID: <2012083.1046079868@[10.1.1.130]> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On Sonntag, 23. Februar 2003 09:19 +0200 john.loughney@nokia.com wrote: > Hi Micheal, > >> For NSIS in particular, I don't recall anybody >> asking what the cost of establishing and >> reestablishing connection state is in the face of >> the longer term goal of wanting to provide real >> time mobility for, oh say, VoIP. RSVP is >> essentially a command/response kind of protocol >> whereas TCP/SCTP requires a *prior* threeway >> handshake before anything useful gets done. For >> things that aren't moving, maybe that doesn't make >> much difference. For things that are... I suspect >> that the total message count -- and how localized >> those messages are -- will make a tremendous >> difference. This problem is certainly not NSIS's >> alone, but every bit counts. > > One suggestion has been that the TCP/SCTP connections > be already setup; this may help with response times. > This kind of solution looks very 3G RAN-ish to me, > requiring a lot of extra state/connections to exist, > a-priori. > But don't forget that TCP from the mobile to the first fixed router (access router) must be set up for each handover. Marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Feb 24 04:47:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06184 for ; Mon, 24 Feb 2003 04:47:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1O9uDc12046 for nsis-archive@odin.ietf.org; Mon, 24 Feb 2003 04:56:13 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O9u7p12038; Mon, 24 Feb 2003 04:56:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O9rUp11973 for ; Mon, 24 Feb 2003 04:53:30 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06084 for ; Mon, 24 Feb 2003 04:44:30 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1O9mMAv014543; Mon, 24 Feb 2003 10:48:22 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVH0HD2; Mon, 24 Feb 2003 10:48:22 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Feb 2003 10:38:39 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB913@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 05539855 9ffcebbb 7a95d2f4 00000138 From: "Georgios Karagiannis (ELN)" To: "'Ping Pan'" Cc: nsis@ietf.org Subject: RE: [NSIS] motivation of using RSVPv1 as NTLP Date: Mon, 24 Feb 2003 10:48:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Ping Well what is says is, Use as NTLP mandatory transport features the mandatory RSVPv1 transport features! Your motivation would be: Why should you use simple solutions, when you can invent complex ones :-) Best Regards, Georgios -----Original Message----- From: Ping Pan [mailto:pingpan@cs.columbia.edu] Sent: zaterdag 22 februari 2003 1:57 To: Georgios Karagiannis (ELN) Cc: nsis@ietf.org Subject: Re: [NSIS] motivation of using RSVPv1 as NTLP Georgios, Your argument below simply says since RSVPv1 has been designed, let's continue to use it (though it has some flaws). Unfortunately, in this logic, we should simply use GRE as NTLP. At least GRE has more deployment than RSVP. :-) - Ping Georgios Karagiannis (ELN) wrote: > Hi all > > Below I try to give a motivation of why is good > to use RSVPv1 (RFC2205) as NTLP! > > > A great deal of effort was put into the specification and design > of the RSVPv1 (RFC2205) protocol. RSVPv1 is well-designed for > the applications for which it was intended and worked hard to provide > a modular protocol within the constraints of its intended use. > The NSIS WG uses the two-level architecture for Internet Signaling > proposed in (in Bob's two-level architecture draft): > > (1) a common lower level that performs transport-layer functions. > This common lower level is denoted in (NSIS framework draft) > as NSIS Transport Layer Protocol (NTLP) that is a placeholder > name for the NSIS protocol component that will support lower > layer (signaling application independent) functions. > (2) a set of upper-level signaling functions that are specific > to particular signaling applications. These upper-level > signaling tasks and functions are accomplished by a set of > signaling layer protocols denoted in (NSIS framework draft) > as NSIS Signaling Layer Protocol (NSLP). > > The main transport-layer features supported by RSVPv1 (RFC2205), such > as support of unicast path-coupled signaling and soft state support > have been proven in practice of being lightweight and robust. However, > the multicast support introduces a level of complexity into the RSVPv1 > protocol that is not needed in support of unicast applications. For > example, RSVPv1's state maintenance is complex as it needs to support > dynamic membership changes in the multicast groups, such as reservation > state merging and maintenance. > > Our working assumption is that RSVPv1 should be optimized for unicast > rather than multicast and that relaxing this design constraint will > in turn greatly simplify the protocol. > > Using RSVPv1 as NTLP will eliminate the need of reinventing solutions > for transport-layer features. Furthermore, this will shorten the time > needed to standardize NTLP by reusing the current RSVP design > experience and RSVP protocol specification. Moreover, after minor > modifications, existing RSVPv1 (RFC2205) implementations can be reused > and used as NTLP, decreasing the deployment costs. > > Additional transport-layer features can be introduced in a modular way, > either by adding them one by one as optional features into the NTLP > specifications and implementations or using an existing protocol below > NTLP that could provide these additional features. > > Best regards, > Georgios > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Feb 24 05:27:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07100 for ; Mon, 24 Feb 2003 05:27:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OAaBV14222 for nsis-archive@odin.ietf.org; Mon, 24 Feb 2003 05:36:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OAWxp14116; Mon, 24 Feb 2003 05:32:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OAUJp14014 for ; Mon, 24 Feb 2003 05:30:19 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06950 for ; Mon, 24 Feb 2003 05:21:19 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1OAPDAv025909; Mon, 24 Feb 2003 11:25:13 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVJ7RVF; Mon, 24 Feb 2003 11:25:12 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Feb 2003 11:15:29 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB915@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: bcab67db 9ffcebbb a5ee123c 00000138 From: "Georgios Karagiannis (ELN)" To: "'Tschofenig Hannes'" Cc: nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP Date: Mon, 24 Feb 2003 11:25:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Feb 24 12:49:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20471 for ; Mon, 24 Feb 2003 12:49:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OHvcE10171 for nsis-archive@odin.ietf.org; Mon, 24 Feb 2003 12:57:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OHvNp10132; Mon, 24 Feb 2003 12:57:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OHu8p10089 for ; Mon, 24 Feb 2003 12:56:08 -0500 Received: from thoth.sbs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20394 for ; Mon, 24 Feb 2003 12:47:00 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id h1OHors00888; Mon, 24 Feb 2003 18:50:53 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id h1OHnWJ12896; Mon, 24 Feb 2003 18:50:02 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Feb 2003 18:49:32 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675DA7@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Georgios Karagiannis (ELN)'" Cc: nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP Date: Mon, 24 Feb 2003 18:49:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi georgios! please see my comments inline: > 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! this might be true for some of the features. for the addressing model this is unfortunately not so simple. > > > [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! 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 > > Best Regards, > Georgios > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Feb 24 13:21:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21474 for ; Mon, 24 Feb 2003 13:21:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1OIUCk12309 for nsis-archive@odin.ietf.org; Mon, 24 Feb 2003 13:30:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OIU8p12295; Mon, 24 Feb 2003 13:30:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OITjp12267 for ; Mon, 24 Feb 2003 13:29:45 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21461 for ; Mon, 24 Feb 2003 13:20:37 -0500 (EST) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h1OIOCsv011747; Mon, 24 Feb 2003 10:24:12 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABS18743; Mon, 24 Feb 2003 10:24:28 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA08662; Mon, 24 Feb 2003 10:24:28 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15962.25436.663481.813436@thomasm-u1.cisco.com> Date: Mon, 24 Feb 2003 10:24:28 -0800 (PST) To: Cc: , Subject: RE: [NSIS] fast mobility concerns w/ NLTP In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit john.loughney@nokia.com writes: > Hi Micheal, > > > For NSIS in particular, I don't recall anybody > > asking what the cost of establishing and > > reestablishing connection state is in the face of > > the longer term goal of wanting to provide real > > time mobility for, oh say, VoIP. RSVP is > > essentially a command/response kind of protocol > > whereas TCP/SCTP requires a *prior* threeway > > handshake before anything useful gets done. For > > things that aren't moving, maybe that doesn't make > > much difference. For things that are... I suspect > > that the total message count -- and how localized > > those messages are -- will make a tremendous > > difference. This problem is certainly not NSIS's > > alone, but every bit counts. > > One suggestion has been that the TCP/SCTP connections > be already setup; this may help with response times. > This kind of solution looks very 3G RAN-ish to me, > requiring a lot of extra state/connections to exist, > a-priori. How does one do that when the destination of the handoff isn't known a priori? Also: does establishing sessions for contingencies scale well? Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 25 00:52:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07418 for ; Tue, 25 Feb 2003 00:52:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1P61jH20890 for nsis-archive@odin.ietf.org; Tue, 25 Feb 2003 01:01:45 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P61ep20880; Tue, 25 Feb 2003 01:01:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P60Gp20831 for ; Tue, 25 Feb 2003 01:00:16 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07362 for ; Tue, 25 Feb 2003 00:50:53 -0500 (EST) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1P5vqm28160 for ; Tue, 25 Feb 2003 07:57:52 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Feb 2003 07:54:45 +0200 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 07:54:44 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Feb 2003 07:54:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [NSIS] fast mobility concerns w/ NLTP Date: Tue, 25 Feb 2003 07:54:43 +0200 Message-ID: Thread-Topic: [NSIS] fast mobility concerns w/ NLTP Thread-Index: AcLcMf3QhIaaU8X7QP2WaoMsO/beCwAYFYUQ To: Cc: X-OriginalArrivalTime: 25 Feb 2003 05:54:44.0650 (UTC) FILETIME=[658758A0:01C2DC92] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1P60Gp20832 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Mike, You are correct, I was not thinking of the first hop ... John > -----Original Message----- > From: ext Michael Thomas [mailto:mat@cisco.com] > Sent: 24 February, 2003 20:24 > To: Loughney John (NRC/Helsinki) > Cc: mat@cisco.com; nsis@ietf.org > Subject: RE: [NSIS] fast mobility concerns w/ NLTP > > > john.loughney@nokia.com writes: > > Hi Micheal, > > > > > For NSIS in particular, I don't recall anybody > > > asking what the cost of establishing and > > > reestablishing connection state is in the face of > > > the longer term goal of wanting to provide real > > > time mobility for, oh say, VoIP. RSVP is > > > essentially a command/response kind of protocol > > > whereas TCP/SCTP requires a *prior* threeway > > > handshake before anything useful gets done. For > > > things that aren't moving, maybe that doesn't make > > > much difference. For things that are... I suspect > > > that the total message count -- and how localized > > > those messages are -- will make a tremendous > > > difference. This problem is certainly not NSIS's > > > alone, but every bit counts. > > > > One suggestion has been that the TCP/SCTP connections > > be already setup; this may help with response times. > > This kind of solution looks very 3G RAN-ish to me, > > requiring a lot of extra state/connections to exist, > > a-priori. > > How does one do that when the destination of > the handoff isn't known a priori? Also: does > establishing sessions for contingencies scale > well? > > Mike > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 25 03:13:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19893 for ; Tue, 25 Feb 2003 03:13:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1P8Ltp07341 for nsis-archive@odin.ietf.org; Tue, 25 Feb 2003 03:21:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P8Lop07331; Tue, 25 Feb 2003 03:21:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P8Flp07165 for ; Tue, 25 Feb 2003 03:15:47 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19779 for ; Tue, 25 Feb 2003 03:06:21 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 25 Feb 2003 09:10:08 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 09:10:08 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE23B368@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: acmorton@att.com Cc: nsis@ietf.org Date: Tue, 25 Feb 2003 09:10:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [NSIS] Re: I-D ACTION:draft-geib-sig-guarandif-00.txt Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Al | A quick question or two on your interesting draft: | In the first page header, you mention the "PADS BOF". | What is PADS? PADS = "PAth-Decoupled Signaling". It's the name of the "Off Path Sinaling" BoF. Chaired by Sven van den Bosch and Marcus Brunner. Currently scheduled for Thursday, 20.3., 1530-1730: pads & plpmtud Path-Decoupled Signaling BOF & Packetization Layer Path MTU Discovery BOF. | Will your draft be discussed on the NSIS list, or | somewhere else? It is forwarded to NSIS herewith to reach people interested in off path signaling. I'm aware that this document is not fitting to any of NSIS's current discussions and it is currently NOT intended as a contribution to NSIS. I'm not interested in a discussion on the draft's service architecture right now. If others feel the idea to be relevant we may start the discussion later on. When time has come, I will repeat the service related part as a draft in its own (to NSIS and PADS, should it be established). If anyone thinks, this draft could be relevant to other WGs, feel free to forward it there. Regards, Rudiger >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : On demand services with throughput guarantees over > DiffServ networks > Author(s) : R. Geib > Filename : draft-geib-sig-guarandif-00.txt > Pages : 7 > Date : 2003-2-21 > >On demand Internet services with guaranteed throughput are the major >driver behind QoS signaling architectures. Guaranteeing throughput >between two defined points of a DiffServ network requires a >combination of flow information and Per Hop Behaviour. Handling >aggregates instead of flows as specified by the DiffServ >architecture is the most reasonable attempt to do so. This document >describes an architecture using DiffServ mechanisms to provide >on demand throughput guarantees between two points of a DiffServ >network. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-geib-sig-guarandif-00.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 25 04:20:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21526 for ; Tue, 25 Feb 2003 04:20:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1P9TQ811583 for nsis-archive@odin.ietf.org; Tue, 25 Feb 2003 04:29:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P9THp11571; Tue, 25 Feb 2003 04:29:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P9O4p11420 for ; Tue, 25 Feb 2003 04:24:04 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21425 for ; Tue, 25 Feb 2003 04:14:35 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1P9ISYe025723; Tue, 25 Feb 2003 10:18:28 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVK12FG; Tue, 25 Feb 2003 10:18:28 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 10:18:28 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB92B@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: e761688d 9ffcebbb a5ee123c 00000138 From: "Georgios Karagiannis (ELN)" To: "'Tschofenig Hannes'" Cc: nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP Date: Tue, 25 Feb 2003 10:17:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , 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:Hannes.Tschofenig@mchp.siemens.de] Sent: maandag 24 februari 2003 18:50 To: Georgios Karagiannis (ELN) Cc: nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP hi georgios! please see my comments inline: > 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! this might be true for some of the features. for the addressing model this is unfortunately not so simple. > > > [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! 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 > > Best Regards, > Georgios > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 25 04:29:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21622 for ; Tue, 25 Feb 2003 04:29:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1P9cei12612 for nsis-archive@odin.ietf.org; Tue, 25 Feb 2003 04:38:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P9cZp12604; Tue, 25 Feb 2003 04:38:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P9Yrp11761 for ; Tue, 25 Feb 2003 04:34:53 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21573 for ; Tue, 25 Feb 2003 04:25:25 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 09:29:18 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA83D@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'nsis@ietf.org'" Date: Tue, 25 Feb 2003 09:29:18 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] another attempt on NTLP peer-peer definition Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , dear all, Having read the mails on the 'consensus probe' thread, and absorbed the ones relevant to the original question, here is a revised attempt on the same subject: It's clear that the signalling exchanges considered by NSIS can go a long way across a network, visiting a sequence of NSIS entities (NEs). The protocol stack carrying the signalling is divided into a common layer (the NTLP) and signalling application specific layer (an NSLP). ============================================================================================ It is a working assumption that the protocol mechanisms of the NTLP operate only between adjacent NEs (informally, the NTLP is a 'hop-by-hop' protocol), whereas any larger scope issues (including e2e aspects) are left to the upper layers. When a signalling message is ready to be sent from one NE, it is given to the NTLP along with information about what flow it is for; it is then up to the NTLP to get it to the next NE along the path (up- or down-stream), where it is received and the responsibility of the NTLP ends. Note that there is no constraint on whether the message is sent directly addressed to the next NE, or addressed to the flow endpoint and intercepted along the path; both addressing models are possible and necessary in some circumstances, and the details are left to the protocol design stage. The key point is that the NTLP at a given NE does not use any knowledge about addresses/capabilities/status/etc. of any NEs other than its direct peers. The receiving NE may decide to forward the message directly, invoking the NTLP again; or, it may give the message to a signalling application for further processing which then generates another message to be sent via the NTLP. In this way, larger scope (including end-to-end) message delivery can be automatically achieved. This definition relates to NTLP operation. It is not intended to restrict the abiliity of an NSLP to send messages by other means. For example, an NE in the middle or end of the signalling path could send a message directly to the other end as a notification of or acknowledgement for some signalling application event. However, it appears that the issues in sending such messages (endpoint discovery, security, NAT traversal and so on) are so different from the direct peer-peer case that there is no benefit in extending the scope of the NTLP to include such non-local functionality; instead, an NSLP which requires such messages and wants to avoid traversing the path of NEs should use some other existing transport protocol - for example, UDP would be a good match for many of the scenarios that have been proposed. ============================================================================================= OK, there hasn't been much discussion on the proposal in the final paragraph. However, my impression is that the people who want to use such notifications don't want to use any interesting functionality in the NTLP anyway, so something simple like plain UDP would be 'good enough' for them. In any case, splitting this from the rest of NTLP requirements seems reasonable to me - any other views? (One motivation for looking only at the hop-by-hop functionality as a single protocol is that if there are any options or variants in design approach - or, worse, in basic functionality - it is easier to manage the resulting complexity if it only impacts direct peers rather than potentially the whole network. It also makes it easier to deploy new versions. Obviously we'd rather get it right first time and with no options, but I'm somehow sceptical that that's possible...) Cheers, Robert H. PS this seems to be a simple concept, so why does the definition have to be so long? Better words possible? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 25 04:39:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21761 for ; Tue, 25 Feb 2003 04:39:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1P9mgE12923 for nsis-archive@odin.ietf.org; Tue, 25 Feb 2003 04:48:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P9mcp12916; Tue, 25 Feb 2003 04:48:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P9ihp12796 for ; Tue, 25 Feb 2003 04:44:43 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21687 for ; Tue, 25 Feb 2003 04:35:14 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1P9d8Ye002807; Tue, 25 Feb 2003 10:39:08 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVK1QLT; Tue, 25 Feb 2003 10:39:08 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 10:39:08 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB92C@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: dd506271 9ffcebbb a5ee123c 00000138 From: "Georgios Karagiannis (ELN)" To: "'Hancock, Robert'" , "'nsis@ietf.org'" Subject: RE: [NSIS] another attempt on NTLP peer-peer definition Date: Tue, 25 Feb 2003 10:39:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Robert Regarding the following paragraph: "Note that there is no constraint on whether the message is sent directly addressed to the next NE, or addressed to the flow endpoint and intercepted along the path; both addressing models are possible and necessary in some circumstances, and the details are left to the protocol design stage." Are you denoting the addressing model where the message is sent directly addressed to the next NE as peer-to-peer addressing and the addressing model where is addressed to the flow endpoint and intercepted along the path as end-to-end addressing? Best Regards, Georgios -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: dinsdag 25 februari 2003 10:29 To: 'nsis@ietf.org' Subject: [NSIS] another attempt on NTLP peer-peer definition dear all, Having read the mails on the 'consensus probe' thread, and absorbed the ones relevant to the original question, here is a revised attempt on the same subject: It's clear that the signalling exchanges considered by NSIS can go a long way across a network, visiting a sequence of NSIS entities (NEs). The protocol stack carrying the signalling is divided into a common layer (the NTLP) and signalling application specific layer (an NSLP). ============================================================================================ It is a working assumption that the protocol mechanisms of the NTLP operate only between adjacent NEs (informally, the NTLP is a 'hop-by-hop' protocol), whereas any larger scope issues (including e2e aspects) are left to the upper layers. When a signalling message is ready to be sent from one NE, it is given to the NTLP along with information about what flow it is for; it is then up to the NTLP to get it to the next NE along the path (up- or down-stream), where it is received and the responsibility of the NTLP ends. Note that there is no constraint on whether the message is sent directly addressed to the next NE, or addressed to the flow endpoint and intercepted along the path; both addressing models are possible and necessary in some circumstances, and the details are left to the protocol design stage. The key point is that the NTLP at a given NE does not use any knowledge about addresses/capabilities/status/etc. of any NEs other than its direct peers. The receiving NE may decide to forward the message directly, invoking the NTLP again; or, it may give the message to a signalling application for further processing which then generates another message to be sent via the NTLP. In this way, larger scope (including end-to-end) message delivery can be automatically achieved. This definition relates to NTLP operation. It is not intended to restrict the abiliity of an NSLP to send messages by other means. For example, an NE in the middle or end of the signalling path could send a message directly to the other end as a notification of or acknowledgement for some signalling application event. However, it appears that the issues in sending such messages (endpoint discovery, security, NAT traversal and so on) are so different from the direct peer-peer case that there is no benefit in extending the scope of the NTLP to include such non-local functionality; instead, an NSLP which requires such messages and wants to avoid traversing the path of NEs should use some other existing transport protocol - for example, UDP would be a good match for many of the scenarios that have been proposed. ============================================================================================= OK, there hasn't been much discussion on the proposal in the final paragraph. However, my impression is that the people who want to use such notifications don't want to use any interesting functionality in the NTLP anyway, so something simple like plain UDP would be 'good enough' for them. In any case, splitting this from the rest of NTLP requirements seems reasonable to me - any other views? (One motivation for looking only at the hop-by-hop functionality as a single protocol is that if there are any options or variants in design approach - or, worse, in basic functionality - it is easier to manage the resulting complexity if it only impacts direct peers rather than potentially the whole network. It also makes it easier to deploy new versions. Obviously we'd rather get it right first time and with no options, but I'm somehow sceptical that that's possible...) Cheers, Robert H. PS this seems to be a simple concept, so why does the definition have to be so long? Better words possible? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 25 04:46:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21819 for ; Tue, 25 Feb 2003 04:46:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1P9tdT13125 for nsis-archive@odin.ietf.org; Tue, 25 Feb 2003 04:55:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P9tYp13114; Tue, 25 Feb 2003 04:55:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P9pVp13016 for ; Tue, 25 Feb 2003 04:51:31 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21787 for ; Tue, 25 Feb 2003 04:42:02 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 09:45:56 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA83F@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Georgios Karagiannis (ELN)'" , "'nsis@ietf.org'" Subject: RE: [NSIS] another attempt on NTLP peer-peer definition Date: Tue, 25 Feb 2003 09:45:55 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , georgios, indeed this is the terminology that the framework uses (in the -01 version in section 3.3.4, although we know that numbering will change soon...) i tried to write the email so it was a bit more self-explanatory. r. > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 25 February 2003 09:39 > To: Hancock, Robert; 'nsis@ietf.org' > Subject: RE: [NSIS] another attempt on NTLP peer-peer definition > > > Hi Robert > > Regarding the following paragraph: > "Note that there is no constraint on whether the message is sent > directly addressed to the next NE, or addressed to the flow > endpoint and intercepted along the path; both addressing models > are possible and necessary in some circumstances, and the > details are left to the protocol design stage." > > Are you denoting the addressing model where the message is sent > directly addressed to the next NE as peer-to-peer addressing > and the addressing model where is addressed to the flow > endpoint and intercepted along the path as end-to-end > addressing? > > Best Regards, > Georgios > > > > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: dinsdag 25 februari 2003 10:29 > To: 'nsis@ietf.org' > Subject: [NSIS] another attempt on NTLP peer-peer definition > > > dear all, > > Having read the mails on the 'consensus probe' thread, and > absorbed the ones relevant to the original question, here is > a revised attempt on the same subject: > > It's clear that the signalling exchanges considered by NSIS > can go a long way across a network, visiting a sequence of > NSIS entities (NEs). The protocol stack carrying the > signalling is divided into a common layer (the NTLP) and > signalling application specific layer (an NSLP). > > ============================================================== > ============================== > > It is a working assumption that the protocol mechanisms of > the NTLP operate only between adjacent NEs (informally, the > NTLP is a 'hop-by-hop' protocol), whereas any larger scope > issues (including e2e aspects) are left to the upper layers. > > When a signalling message is ready to be sent from one NE, it > is given to the NTLP along with information about what flow > it is for; it is then up to the NTLP to get it to the next NE > along the path (up- or down-stream), where it is received and > the responsibility of the NTLP ends. Note that there is no > constraint on whether the message is sent directly addressed > to the next NE, or addressed to the flow endpoint and > intercepted along the path; both addressing models are > possible and necessary in some circumstances, and the details > are left to the protocol design stage. The key point is that > the NTLP at a given NE does not use any knowledge about > addresses/capabilities/status/etc. of any NEs other than its > direct peers. > > The receiving NE may decide to forward the message directly, > invoking the NTLP again; or, it may give the message to a > signalling application for further processing which then > generates another message to be sent via the NTLP. In this > way, larger scope (including end-to-end) message delivery can > be automatically achieved. > > This definition relates to NTLP operation. It is not intended > to restrict the abiliity of an NSLP to send messages by other > means. For example, an NE in the middle or end of the > signalling path could send a message directly to the other > end as a notification of or acknowledgement for some > signalling application event. However, it appears that the > issues in sending such messages (endpoint discovery, > security, NAT traversal and so on) are so different from the > direct peer-peer case that there is no benefit in extending > the scope of the NTLP to include such non-local > functionality; instead, an NSLP which requires such messages > and wants to avoid traversing the path of NEs should use some > other existing transport protocol - for example, UDP would be > a good match for many of the scenarios that have been proposed. > > ============================================================== > =============================== > > OK, there hasn't been much discussion on the proposal in the > final paragraph. However, my impression is that the people > who want to use such notifications don't want to use any > interesting functionality in the NTLP anyway, so something > simple like plain UDP would be 'good enough' for them. In any > case, splitting this from the rest of NTLP requirements seems > reasonable to me - any other views? > > (One motivation for looking only at the hop-by-hop > functionality as a single protocol is that if there are any > options or variants in design approach - or, worse, in basic > functionality - it is easier to manage the resulting > complexity if it only impacts direct peers rather than > potentially the whole network. It also makes it easier to > deploy new versions. Obviously we'd rather get it right first > time and with no options, but I'm somehow sceptical that > that's possible...) > > Cheers, > > Robert H. > > PS this seems to be a simple concept, so why does the > definition have to be so long? Better words possible? > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 25 04:59:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22071 for ; Tue, 25 Feb 2003 04:59:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PA8Ar14493 for nsis-archive@odin.ietf.org; Tue, 25 Feb 2003 05:08:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PA86p14485; Tue, 25 Feb 2003 05:08:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PA3rp13522 for ; Tue, 25 Feb 2003 05:03:53 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21972 for ; Tue, 25 Feb 2003 04:54:23 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1P9wHYe008929; Tue, 25 Feb 2003 10:58:17 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVK1WLN; Tue, 25 Feb 2003 10:58:17 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 10:58:17 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB92D@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 4fb6ab46 9ffcebbb a5ee123c 00000138 From: "Georgios Karagiannis (ELN)" To: "'Hancock, Robert'" , "'nsis@ietf.org'" Subject: RE: [NSIS] another attempt on NTLP peer-peer definition Date: Tue, 25 Feb 2003 10:58:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Robert Okay, I think that we are using then the same definitions. Now regarding NTLP. Suppose that the NTLP is a hop-by-hop protocol. Are you then assuming that both types of addressing peer-to-peer addressing and end-to-end addressing can be applied in such a NTLP hop-by-hop protocol? When peer-to-peer addressing is used, are you considering that the NTLP protocol will have to be terminated and re-initiated at each hop by the NSLP? When end-to-end addressing is used, are you also considering that the NTLP protocol will have to be terminated and re-initiated at each hop by the NSLP? Best Regards, Georgios -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: dinsdag 25 februari 2003 10:46 To: Georgios Karagiannis (ELN); 'nsis@ietf.org' Subject: RE: [NSIS] another attempt on NTLP peer-peer definition georgios, indeed this is the terminology that the framework uses (in the -01 version in section 3.3.4, although we know that numbering will change soon...) i tried to write the email so it was a bit more self-explanatory. r. > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 25 February 2003 09:39 > To: Hancock, Robert; 'nsis@ietf.org' > Subject: RE: [NSIS] another attempt on NTLP peer-peer definition > > > Hi Robert > > Regarding the following paragraph: > "Note that there is no constraint on whether the message is sent > directly addressed to the next NE, or addressed to the flow > endpoint and intercepted along the path; both addressing models > are possible and necessary in some circumstances, and the > details are left to the protocol design stage." > > Are you denoting the addressing model where the message is sent > directly addressed to the next NE as peer-to-peer addressing > and the addressing model where is addressed to the flow > endpoint and intercepted along the path as end-to-end > addressing? > > Best Regards, > Georgios > > > > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: dinsdag 25 februari 2003 10:29 > To: 'nsis@ietf.org' > Subject: [NSIS] another attempt on NTLP peer-peer definition > > > dear all, > > Having read the mails on the 'consensus probe' thread, and > absorbed the ones relevant to the original question, here is > a revised attempt on the same subject: > > It's clear that the signalling exchanges considered by NSIS > can go a long way across a network, visiting a sequence of > NSIS entities (NEs). The protocol stack carrying the > signalling is divided into a common layer (the NTLP) and > signalling application specific layer (an NSLP). > > ============================================================== > ============================== > > It is a working assumption that the protocol mechanisms of > the NTLP operate only between adjacent NEs (informally, the > NTLP is a 'hop-by-hop' protocol), whereas any larger scope > issues (including e2e aspects) are left to the upper layers. > > When a signalling message is ready to be sent from one NE, it > is given to the NTLP along with information about what flow > it is for; it is then up to the NTLP to get it to the next NE > along the path (up- or down-stream), where it is received and > the responsibility of the NTLP ends. Note that there is no > constraint on whether the message is sent directly addressed > to the next NE, or addressed to the flow endpoint and > intercepted along the path; both addressing models are > possible and necessary in some circumstances, and the details > are left to the protocol design stage. The key point is that > the NTLP at a given NE does not use any knowledge about > addresses/capabilities/status/etc. of any NEs other than its > direct peers. > > The receiving NE may decide to forward the message directly, > invoking the NTLP again; or, it may give the message to a > signalling application for further processing which then > generates another message to be sent via the NTLP. In this > way, larger scope (including end-to-end) message delivery can > be automatically achieved. > > This definition relates to NTLP operation. It is not intended > to restrict the abiliity of an NSLP to send messages by other > means. For example, an NE in the middle or end of the > signalling path could send a message directly to the other > end as a notification of or acknowledgement for some > signalling application event. However, it appears that the > issues in sending such messages (endpoint discovery, > security, NAT traversal and so on) are so different from the > direct peer-peer case that there is no benefit in extending > the scope of the NTLP to include such non-local > functionality; instead, an NSLP which requires such messages > and wants to avoid traversing the path of NEs should use some > other existing transport protocol - for example, UDP would be > a good match for many of the scenarios that have been proposed. > > ============================================================== > =============================== > > OK, there hasn't been much discussion on the proposal in the > final paragraph. However, my impression is that the people > who want to use such notifications don't want to use any > interesting functionality in the NTLP anyway, so something > simple like plain UDP would be 'good enough' for them. In any > case, splitting this from the rest of NTLP requirements seems > reasonable to me - any other views? > > (One motivation for looking only at the hop-by-hop > functionality as a single protocol is that if there are any > options or variants in design approach - or, worse, in basic > functionality - it is easier to manage the resulting > complexity if it only impacts direct peers rather than > potentially the whole network. It also makes it easier to > deploy new versions. Obviously we'd rather get it right first > time and with no options, but I'm somehow sceptical that > that's possible...) > > Cheers, > > Robert H. > > PS this seems to be a simple concept, so why does the > definition have to be so long? Better words possible? > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 25 05:14:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22449 for ; Tue, 25 Feb 2003 05:14:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PANnc15328 for nsis-archive@odin.ietf.org; Tue, 25 Feb 2003 05:23:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PANep15318; Tue, 25 Feb 2003 05:23:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PAJZp15154 for ; Tue, 25 Feb 2003 05:19:35 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22404 for ; Tue, 25 Feb 2003 05:10:05 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1PADxYe013088; Tue, 25 Feb 2003 11:13:59 +0100 (MET) Received: from ESEALNT747.al.sw.ericsson.se ([153.88.251.7]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDVNMYCN; Tue, 25 Feb 2003 11:13:59 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 11:11:41 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB92E@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: b33604e8 9ffcebbb 7a95d2f4 00000138 From: "Georgios Karagiannis (ELN)" To: "'Marcus Brunner'" Cc: nsis@ietf.org Date: Tue, 25 Feb 2003 11:13:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] Labeling NSIS requirements Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Marcus According to some discussions that took place during the NSIS interim meeting, there was a need of assigning "generic" and "QoS specific" labels to the NSIS requirements. Please receive an attempt proposal of assigning "generic" or QoS specific" labels to the NSIS requirements. Best Regards, Georgios 5.1 Architecture and Design Goals 5.1.1 MUST be applicable for different technologies. [Georgios] Generic, but will probably be removed! 5.1.2 SHOULD provide resource availability information on request [Georgios] QoS specific 5.1.3 NSIS MUST be designed modularly [Georgios] Generic 5.1.4 NSIS MUST decouple protocol and information [Georgios] Generic 5.1.5 NSIS MUST reuse existing provisioning [Georgios] QoS specific, but it will probably be removed 5.1.6 NSIS MUST support independence of signaling and provisioning paradigm [Georgios] QoS specific, but it will probably be removed 5.1.7 NSIS MUST be application independent [Georgios] Generic 5.2 Signaling Flows 5.2.1 The placement of NSIS Initiator, Forwarder, Responder MUST be free [Georgios] Generic, probably will be modified ?? 5.2.2 No constraint MUST be posed the signaling and NSIS Forwarders to be in the data path. [Georgios] Generic, but probably will be somehow modified 5.2.3 Concealment of topology and technology information SHOULD be possible [Georgios] Generic 5.2.4 Transparent signaling through networks SHOULD be possible [Georgios] Generic 5.3 Messaging 5.3.1 Explicit release of resources MUST be possible [Georgios] Generic if resources are replaced by transport state; QoS specific if the release refers to reservations 5.3.2 Automatic release of resources after failure SHOULD be possible [Georgios] Generic if resources are replaced by transport state; QoS specific if the release refers to reservations 5.3.3 NSIS SHOULD allow for sending notifications upstream [Georgios] Generic 5.3.4 Feedback about success of service request MUST be provided [Georgios] Generic 5.3.5 NSIS MUST allow for local information exchange [Georgios] Generic 5.4 Control Information 5.4.1 Mutability information on parameters SHOULD be possible [Georgios] Generic 5.4.2 SHOULD possible to add and remove local domain information [georgios] Generic 5.4.3 State MUST be addressed independent of flow identification [Georgios] Generic 5.4.4 Modification of already reserved resources SHOULD be seamless [Georgios] QoS specific 5.4.5 Grouping of signaling for several micro-flows MAY be provided [Georgios] QoS specific 5.5 Performance [Georgios] I consider the performance requirements as Generic, since they are applicable to all types of signaling 5.5.1 Scalability [Georgios] Generic 5.5.2 NSIS SHOULD allow for low latency in setup [Georgios] Generic 5.5.3 NSIS MUST allow for low bandwidth consumption for signaling protocol [Georgios] Generic 5.5.4 NSIS SHOULD allow to constrain load on devices [Georgios] Generic 5.5.5 NSIS SHOULD target highest possible network utilization [Georgios] Generic 5.6 Flexibility 5.6.1 Flow aggregation [Georgios] QoS specific 5.6.2 Flexibility in the placement of the NSIS Initiator [Georgios] Generic 5.6.3 Flexibility in the initiation of re-negotiation [Georgios] QoS specific 5.6.4 SOULD support network-initiated re-negotiation [Georgios] QoS specific 5.6.5 Uni / bi-directional reservation [Georgios] QoS specific 5.7 Security [Georgios] I consider the security requirements as Generic, since they are applicable to all types of signaling 5.7.1 Authentication of signaling requests [Georgios] Generic 5.7.2 Resource Authorization [Georgios] Generic 5.7.3 Integrity protection [Georgios] Generic 5.7.4 Replay protection [Georgios] Generic 5.7.5 Hop-by-hop security [Georgios] Generic 5.7.6 Identity confidentiality and location privacy [Georgios] Generic 5.7.7 Denial-of-service attacks [Georgios] Generic 5.7.8 Confidentiality of signaling messages [Georgios] Generic 5.7.9 Ownership of a reservation [Georgios] Generic 5.8 Mobility 5.8.1 Allow efficient service re-establishment after handover [Georgios] Generic 5.9 Interworking with other protocols and techniques [Georgios] Generic 5.9.1 MUST interwork with IP tunneling [Georgios] Generic 5.9.2 The solution MUST NOT constrain either to IPv4 or IPv6 [Georgios] Generic 5.9.3 MUST be independent from charging model [Georgios] Generic 5.9.4 SHOULD provide hooks for AAA protocols [Georgios] Generic 5.9.5 SHOULD interwork with seamless handoff protocols [Georgios] Generic 5.9.6 MAY interwork with non-traditional routing [Georgios] Generic 5.10 Operational 5.10.1 Ability to assign transport quality to signaling messages. [Georgios] Generic 5.10.2 Graceful fail over [Georgios] Generic 5.10.3 Graceful handling of NSIS entity problems [Georgios] Generic _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 25 06:02:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23177 for ; Tue, 25 Feb 2003 06:02:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PBBgm18530 for nsis-archive@odin.ietf.org; Tue, 25 Feb 2003 06:11:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PBBap18506; Tue, 25 Feb 2003 06:11:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PB3Tp17456 for ; Tue, 25 Feb 2003 06:03:29 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22999 for ; Tue, 25 Feb 2003 05:53:58 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 10:57:52 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA840@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Georgios Karagiannis (ELN)'" , "'nsis@ietf.org'" Subject: RE: [NSIS] another attempt on NTLP peer-peer definition Date: Tue, 25 Feb 2003 10:57:50 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi georgios, see inline: > > Suppose that the NTLP is a hop-by-hop protocol. > > Are you then assuming that both types of addressing > peer-to-peer addressing and end-to-end addressing > can be applied in such a NTLP hop-by-hop protocol? as i say, it's a design choice (i.e. for later). rsvp uses both (p2p always for resv, p2p or e2e for path). i think it's hard to rule out either. > > When peer-to-peer addressing is used, are you considering > that the NTLP protocol will have to be terminated and re-initiated > at each hop by the NSLP? > > When end-to-end addressing is used, are you also considering > that the NTLP protocol will have to be terminated and re-initiated > at each hop by the NSLP? i don't know what these questions mean in practice. can you phrase them as comments on the text below? cheers, r. > > > Best Regards, > Georgios > > > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: dinsdag 25 februari 2003 10:46 > To: Georgios Karagiannis (ELN); 'nsis@ietf.org' > Subject: RE: [NSIS] another attempt on NTLP peer-peer definition > > > georgios, > > indeed this is the terminology that the framework uses (in > the -01 version in section 3.3.4, although we know that > numbering will change soon...) > > i tried to write the email so it was a bit more self-explanatory. > > r. > > > -----Original Message----- > > From: Georgios Karagiannis (ELN) > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > Sent: 25 February 2003 09:39 > > To: Hancock, Robert; 'nsis@ietf.org' > > Subject: RE: [NSIS] another attempt on NTLP peer-peer definition > > > > > > Hi Robert > > > > Regarding the following paragraph: > > "Note that there is no constraint on whether the message is sent > > directly addressed to the next NE, or addressed to the flow > > endpoint and intercepted along the path; both addressing models > > are possible and necessary in some circumstances, and the > > details are left to the protocol design stage." > > > > Are you denoting the addressing model where the message is sent > > directly addressed to the next NE as peer-to-peer addressing > > and the addressing model where is addressed to the flow > > endpoint and intercepted along the path as end-to-end > > addressing? > > > > Best Regards, > > Georgios > > > > > > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: dinsdag 25 februari 2003 10:29 > > To: 'nsis@ietf.org' > > Subject: [NSIS] another attempt on NTLP peer-peer definition > > > > > > dear all, > > > > Having read the mails on the 'consensus probe' thread, and > > absorbed the ones relevant to the original question, here is > > a revised attempt on the same subject: > > > > It's clear that the signalling exchanges considered by NSIS > > can go a long way across a network, visiting a sequence of > > NSIS entities (NEs). The protocol stack carrying the > > signalling is divided into a common layer (the NTLP) and > > signalling application specific layer (an NSLP). > > > > ============================================================== > > ============================== > > > > It is a working assumption that the protocol mechanisms of > > the NTLP operate only between adjacent NEs (informally, the > > NTLP is a 'hop-by-hop' protocol), whereas any larger scope > > issues (including e2e aspects) are left to the upper layers. > > > > When a signalling message is ready to be sent from one NE, it > > is given to the NTLP along with information about what flow > > it is for; it is then up to the NTLP to get it to the next NE > > along the path (up- or down-stream), where it is received and > > the responsibility of the NTLP ends. Note that there is no > > constraint on whether the message is sent directly addressed > > to the next NE, or addressed to the flow endpoint and > > intercepted along the path; both addressing models are > > possible and necessary in some circumstances, and the details > > are left to the protocol design stage. The key point is that > > the NTLP at a given NE does not use any knowledge about > > addresses/capabilities/status/etc. of any NEs other than its > > direct peers. > > > > The receiving NE may decide to forward the message directly, > > invoking the NTLP again; or, it may give the message to a > > signalling application for further processing which then > > generates another message to be sent via the NTLP. In this > > way, larger scope (including end-to-end) message delivery can > > be automatically achieved. > > > > This definition relates to NTLP operation. It is not intended > > to restrict the abiliity of an NSLP to send messages by other > > means. For example, an NE in the middle or end of the > > signalling path could send a message directly to the other > > end as a notification of or acknowledgement for some > > signalling application event. However, it appears that the > > issues in sending such messages (endpoint discovery, > > security, NAT traversal and so on) are so different from the > > direct peer-peer case that there is no benefit in extending > > the scope of the NTLP to include such non-local > > functionality; instead, an NSLP which requires such messages > > and wants to avoid traversing the path of NEs should use some > > other existing transport protocol - for example, UDP would be > > a good match for many of the scenarios that have been proposed. > > > > ============================================================== > > =============================== > > > > OK, there hasn't been much discussion on the proposal in the > > final paragraph. However, my impression is that the people > > who want to use such notifications don't want to use any > > interesting functionality in the NTLP anyway, so something > > simple like plain UDP would be 'good enough' for them. In any > > case, splitting this from the rest of NTLP requirements seems > > reasonable to me - any other views? > > > > (One motivation for looking only at the hop-by-hop > > functionality as a single protocol is that if there are any > > options or variants in design approach - or, worse, in basic > > functionality - it is easier to manage the resulting > > complexity if it only impacts direct peers rather than > > potentially the whole network. It also makes it easier to > > deploy new versions. Obviously we'd rather get it right first > > time and with no options, but I'm somehow sceptical that > > that's possible...) > > > > Cheers, > > > > Robert H. > > > > PS this seems to be a simple concept, so why does the > > definition have to be so long? Better words possible? > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 25 06:10:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23284 for ; Tue, 25 Feb 2003 06:10:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PBJir18829 for nsis-archive@odin.ietf.org; Tue, 25 Feb 2003 06:19:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PBJep18820; Tue, 25 Feb 2003 06:19:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PB5Np17508 for ; Tue, 25 Feb 2003 06:05:23 -0500 Received: from thoth.sbs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23011 for ; Tue, 25 Feb 2003 05:55:53 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id h1PAxlm22350; Tue, 25 Feb 2003 11:59:47 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id h1PAxkN18290; Tue, 25 Feb 2003 11:59:46 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 11:59:45 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675DC0@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Georgios Karagiannis (ELN)'" Cc: nsis@ietf.org Subject: RE: AW: [NSIS] Transport functionality in the NTLP Date: Tue, 25 Feb 2003 11:59:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi georgios! please see my comments inline: > 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? 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 > > In your opinion, what type of addressing is being used > 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 > > Best Regards, > Georgios > > -----Original Message----- > From: Tschofenig Hannes [mailto:Hannes.Tschofenig@mchp.siemens.de] > Sent: maandag 24 februari 2003 18:50 > To: Georgios Karagiannis (ELN) > Cc: nsis@ietf.org > Subject: RE: AW: [NSIS] Transport functionality in the NTLP > > > hi georgios! > > please see my comments inline: > > > 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! > > this might be true for some of the features. for the > addressing model this > is unfortunately not so simple. > > > > > > > [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! > > 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 > > > > > Best Regards, > > Georgios > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 25 06:14:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23455 for ; Tue, 25 Feb 2003 06:14:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PBNp019043 for nsis-archive@odin.ietf.org; Tue, 25 Feb 2003 06:23:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PBNhp19031; Tue, 25 Feb 2003 06:23:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PBEvp18650 for ; Tue, 25 Feb 2003 06:14:57 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23237 for ; Tue, 25 Feb 2003 06:05:26 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1PB9KnS000775; Tue, 25 Feb 2003 12:09:20 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4HDHWR; Tue, 25 Feb 2003 12:09:20 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 12:09:20 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB931@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: a1537b3f 9ffcebbb 7a95d2f4 00000138 From: "Georgios Karagiannis (ELN)" To: "'Hancock, Robert'" , "'nsis@ietf.org'" Subject: RE: [NSIS] another attempt on NTLP peer-peer definition Date: Tue, 25 Feb 2003 12:09:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Robert Okay, I have a comment regarding the following text: "it is then up to the NTLP to get it to the next NE along the path (up- or down-stream), where it is received and the responsibility of the NTLP ends." When end-to-end addressing is used, are you assuming that the responsibility of the NTLP will end at each hop? Best Regards, Georgios -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: dinsdag 25 februari 2003 11:58 To: Georgios Karagiannis (ELN); 'nsis@ietf.org' Subject: RE: [NSIS] another attempt on NTLP peer-peer definition hi georgios, see inline: > > Suppose that the NTLP is a hop-by-hop protocol. > > Are you then assuming that both types of addressing > peer-to-peer addressing and end-to-end addressing > can be applied in such a NTLP hop-by-hop protocol? as i say, it's a design choice (i.e. for later). rsvp uses both (p2p always for resv, p2p or e2e for path). i think it's hard to rule out either. > > When peer-to-peer addressing is used, are you considering > that the NTLP protocol will have to be terminated and re-initiated > at each hop by the NSLP? > > When end-to-end addressing is used, are you also considering > that the NTLP protocol will have to be terminated and re-initiated > at each hop by the NSLP? i don't know what these questions mean in practice. can you phrase them as comments on the text below? cheers, r. > > > Best Regards, > Georgios > > > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: dinsdag 25 februari 2003 10:46 > To: Georgios Karagiannis (ELN); 'nsis@ietf.org' > Subject: RE: [NSIS] another attempt on NTLP peer-peer definition > > > georgios, > > indeed this is the terminology that the framework uses (in > the -01 version in section 3.3.4, although we know that > numbering will change soon...) > > i tried to write the email so it was a bit more self-explanatory. > > r. > > > -----Original Message----- > > From: Georgios Karagiannis (ELN) > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > Sent: 25 February 2003 09:39 > > To: Hancock, Robert; 'nsis@ietf.org' > > Subject: RE: [NSIS] another attempt on NTLP peer-peer definition > > > > > > Hi Robert > > > > Regarding the following paragraph: > > "Note that there is no constraint on whether the message is sent > > directly addressed to the next NE, or addressed to the flow > > endpoint and intercepted along the path; both addressing models > > are possible and necessary in some circumstances, and the > > details are left to the protocol design stage." > > > > Are you denoting the addressing model where the message is sent > > directly addressed to the next NE as peer-to-peer addressing > > and the addressing model where is addressed to the flow > > endpoint and intercepted along the path as end-to-end > > addressing? > > > > Best Regards, > > Georgios > > > > > > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: dinsdag 25 februari 2003 10:29 > > To: 'nsis@ietf.org' > > Subject: [NSIS] another attempt on NTLP peer-peer definition > > > > > > dear all, > > > > Having read the mails on the 'consensus probe' thread, and > > absorbed the ones relevant to the original question, here is > > a revised attempt on the same subject: > > > > It's clear that the signalling exchanges considered by NSIS > > can go a long way across a network, visiting a sequence of > > NSIS entities (NEs). The protocol stack carrying the > > signalling is divided into a common layer (the NTLP) and > > signalling application specific layer (an NSLP). > > > > ============================================================== > > ============================== > > > > It is a working assumption that the protocol mechanisms of > > the NTLP operate only between adjacent NEs (informally, the > > NTLP is a 'hop-by-hop' protocol), whereas any larger scope > > issues (including e2e aspects) are left to the upper layers. > > > > When a signalling message is ready to be sent from one NE, it > > is given to the NTLP along with information about what flow > > it is for; it is then up to the NTLP to get it to the next NE > > along the path (up- or down-stream), where it is received and > > the responsibility of the NTLP ends. Note that there is no > > constraint on whether the message is sent directly addressed > > to the next NE, or addressed to the flow endpoint and > > intercepted along the path; both addressing models are > > possible and necessary in some circumstances, and the details > > are left to the protocol design stage. The key point is that > > the NTLP at a given NE does not use any knowledge about > > addresses/capabilities/status/etc. of any NEs other than its > > direct peers. > > > > The receiving NE may decide to forward the message directly, > > invoking the NTLP again; or, it may give the message to a > > signalling application for further processing which then > > generates another message to be sent via the NTLP. In this > > way, larger scope (including end-to-end) message delivery can > > be automatically achieved. > > > > This definition relates to NTLP operation. It is not intended > > to restrict the abiliity of an NSLP to send messages by other > > means. For example, an NE in the middle or end of the > > signalling path could send a message directly to the other > > end as a notification of or acknowledgement for some > > signalling application event. However, it appears that the > > issues in sending such messages (endpoint discovery, > > security, NAT traversal and so on) are so different from the > > direct peer-peer case that there is no benefit in extending > > the scope of the NTLP to include such non-local > > functionality; instead, an NSLP which requires such messages > > and wants to avoid traversing the path of NEs should use some > > other existing transport protocol - for example, UDP would be > > a good match for many of the scenarios that have been proposed. > > > > ============================================================== > > =============================== > > > > OK, there hasn't been much discussion on the proposal in the > > final paragraph. However, my impression is that the people > > who want to use such notifications don't want to use any > > interesting functionality in the NTLP anyway, so something > > simple like plain UDP would be 'good enough' for them. In any > > case, splitting this from the rest of NTLP requirements seems > > reasonable to me - any other views? > > > > (One motivation for looking only at the hop-by-hop > > functionality as a single protocol is that if there are any > > options or variants in design approach - or, worse, in basic > > functionality - it is easier to manage the resulting > > complexity if it only impacts direct peers rather than > > potentially the whole network. It also makes it easier to > > deploy new versions. Obviously we'd rather get it right first > > time and with no options, but I'm somehow sceptical that > > that's possible...) > > > > Cheers, > > > > Robert H. > > > > PS this seems to be a simple concept, so why does the > > definition have to be so long? Better words possible? > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 25 06:18:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23544 for ; Tue, 25 Feb 2003 06:18:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PBRkV19234 for nsis-archive@odin.ietf.org; Tue, 25 Feb 2003 06:27:46 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PBRfp19219; Tue, 25 Feb 2003 06:27:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PBMOp18995 for ; Tue, 25 Feb 2003 06:22:24 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23382 for ; Tue, 25 Feb 2003 06:12:52 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 11:16:47 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA842@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Georgios Karagiannis (ELN)'" , "'nsis@ietf.org'" Subject: RE: [NSIS] another attempt on NTLP peer-peer definition Date: Tue, 25 Feb 2003 11:16:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi georgios, > Okay, I have a comment regarding the following text: > > "it is then up to the NTLP to get it to the next NE > along the path (up- or down-stream), where it is received and > the responsibility of the NTLP ends." > > When end-to-end addressing is used, are you assuming that > the responsibility of the NTLP will end at each hop? i don't see the addressing model makes any difference here. the possible behaviour is described in the paragraph following the one with the sentence you quote. do you think that description is incorrect? (i think it's basically the same behaviour as rsvp with the necessary changes to support non-end-to-end operation and the fact that not all nodes will support all signalling applications.) > > Best Regards, > Georgios > > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: dinsdag 25 februari 2003 11:58 > To: Georgios Karagiannis (ELN); 'nsis@ietf.org' > Subject: RE: [NSIS] another attempt on NTLP peer-peer definition > > > hi georgios, > > see inline: > > > > Suppose that the NTLP is a hop-by-hop protocol. > > > > Are you then assuming that both types of addressing > > peer-to-peer addressing and end-to-end addressing > > can be applied in such a NTLP hop-by-hop protocol? > > as i say, it's a design choice (i.e. for later). rsvp uses > both (p2p always for resv, p2p or e2e for path). i think it's > hard to rule out either. > > > > > When peer-to-peer addressing is used, are you considering > > that the NTLP protocol will have to be terminated and re-initiated > > at each hop by the NSLP? > > > > When end-to-end addressing is used, are you also considering > > that the NTLP protocol will have to be terminated and re-initiated > > at each hop by the NSLP? > > i don't know what these questions mean in practice. can you > phrase them as comments on the text below? > > cheers, > > r. > > > > > > > Best Regards, > > Georgios > > > > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: dinsdag 25 februari 2003 10:46 > > To: Georgios Karagiannis (ELN); 'nsis@ietf.org' > > Subject: RE: [NSIS] another attempt on NTLP peer-peer definition > > > > > > georgios, > > > > indeed this is the terminology that the framework uses (in > > the -01 version in section 3.3.4, although we know that > > numbering will change soon...) > > > > i tried to write the email so it was a bit more self-explanatory. > > > > r. > > > > > -----Original Message----- > > > From: Georgios Karagiannis (ELN) > > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > > Sent: 25 February 2003 09:39 > > > To: Hancock, Robert; 'nsis@ietf.org' > > > Subject: RE: [NSIS] another attempt on NTLP peer-peer definition > > > > > > > > > Hi Robert > > > > > > Regarding the following paragraph: > > > "Note that there is no constraint on whether the message is sent > > > directly addressed to the next NE, or addressed to the flow > > > endpoint and intercepted along the path; both addressing models > > > are possible and necessary in some circumstances, and the > > > details are left to the protocol design stage." > > > > > > Are you denoting the addressing model where the message is sent > > > directly addressed to the next NE as peer-to-peer addressing > > > and the addressing model where is addressed to the flow > > > endpoint and intercepted along the path as end-to-end > > > addressing? > > > > > > Best Regards, > > > Georgios > > > > > > > > > > > > -----Original Message----- > > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > Sent: dinsdag 25 februari 2003 10:29 > > > To: 'nsis@ietf.org' > > > Subject: [NSIS] another attempt on NTLP peer-peer definition > > > > > > > > > dear all, > > > > > > Having read the mails on the 'consensus probe' thread, and > > > absorbed the ones relevant to the original question, here is > > > a revised attempt on the same subject: > > > > > > It's clear that the signalling exchanges considered by NSIS > > > can go a long way across a network, visiting a sequence of > > > NSIS entities (NEs). The protocol stack carrying the > > > signalling is divided into a common layer (the NTLP) and > > > signalling application specific layer (an NSLP). > > > > > > ============================================================== > > > ============================== > > > > > > It is a working assumption that the protocol mechanisms of > > > the NTLP operate only between adjacent NEs (informally, the > > > NTLP is a 'hop-by-hop' protocol), whereas any larger scope > > > issues (including e2e aspects) are left to the upper layers. > > > > > > When a signalling message is ready to be sent from one NE, it > > > is given to the NTLP along with information about what flow > > > it is for; it is then up to the NTLP to get it to the next NE > > > along the path (up- or down-stream), where it is received and > > > the responsibility of the NTLP ends. Note that there is no > > > constraint on whether the message is sent directly addressed > > > to the next NE, or addressed to the flow endpoint and > > > intercepted along the path; both addressing models are > > > possible and necessary in some circumstances, and the details > > > are left to the protocol design stage. The key point is that > > > the NTLP at a given NE does not use any knowledge about > > > addresses/capabilities/status/etc. of any NEs other than its > > > direct peers. > > > > > > The receiving NE may decide to forward the message directly, > > > invoking the NTLP again; or, it may give the message to a > > > signalling application for further processing which then > > > generates another message to be sent via the NTLP. In this > > > way, larger scope (including end-to-end) message delivery can > > > be automatically achieved. > > > > > > This definition relates to NTLP operation. It is not intended > > > to restrict the abiliity of an NSLP to send messages by other > > > means. For example, an NE in the middle or end of the > > > signalling path could send a message directly to the other > > > end as a notification of or acknowledgement for some > > > signalling application event. However, it appears that the > > > issues in sending such messages (endpoint discovery, > > > security, NAT traversal and so on) are so different from the > > > direct peer-peer case that there is no benefit in extending > > > the scope of the NTLP to include such non-local > > > functionality; instead, an NSLP which requires such messages > > > and wants to avoid traversing the path of NEs should use some > > > other existing transport protocol - for example, UDP would be > > > a good match for many of the scenarios that have been proposed. > > > > > > ============================================================== > > > =============================== > > > > > > OK, there hasn't been much discussion on the proposal in the > > > final paragraph. However, my impression is that the people > > > who want to use such notifications don't want to use any > > > interesting functionality in the NTLP anyway, so something > > > simple like plain UDP would be 'good enough' for them. In any > > > case, splitting this from the rest of NTLP requirements seems > > > reasonable to me - any other views? > > > > > > (One motivation for looking only at the hop-by-hop > > > functionality as a single protocol is that if there are any > > > options or variants in design approach - or, worse, in basic > > > functionality - it is easier to manage the resulting > > > complexity if it only impacts direct peers rather than > > > potentially the whole network. It also makes it easier to > > > deploy new versions. Obviously we'd rather get it right first > > > time and with no options, but I'm somehow sceptical that > > > that's possible...) > > > > > > Cheers, > > > > > > Robert H. > > > > > > PS this seems to be a simple concept, so why does the > > > definition have to be so long? Better words possible? > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 25 07:43:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28259 for ; Tue, 25 Feb 2003 07:43:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PCq5K25886 for nsis-archive@odin.ietf.org; Tue, 25 Feb 2003 07:52:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PCq0p25875; Tue, 25 Feb 2003 07:52:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PCnjp25736 for ; Tue, 25 Feb 2003 07:49:45 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28018 for ; Tue, 25 Feb 2003 07:40:13 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h1PCi6nS000985; Tue, 25 Feb 2003 13:44:06 +0100 (MET) Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FD4H12M4; Tue, 25 Feb 2003 13:44:06 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 13:44:06 +0100 Message-ID: <2B06CD3FC17AF64587BC7A7617B230C0CBB934@enleent103.nl.eu.ericsson.se> X-Sybari-Trust: 6e305dd8 9ffcebbb 7a95d2f4 00000138 From: "Georgios Karagiannis (ELN)" To: "'Hancock, Robert'" , "'nsis@ietf.org'" Subject: RE: [NSIS] another attempt on NTLP peer-peer definition Date: Tue, 25 Feb 2003 13:44:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Robert Do you mean that you will agree with the following text: "The NTLP in the receiving NE may decide to forward the message directly, or, it may give the message to a signalling application for further processing which then generates another message to be sent via the NTLP." Best regards, Georgios -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: dinsdag 25 februari 2003 12:17 To: Georgios Karagiannis (ELN); 'nsis@ietf.org' Subject: RE: [NSIS] another attempt on NTLP peer-peer definition hi georgios, > Okay, I have a comment regarding the following text: > > "it is then up to the NTLP to get it to the next NE > along the path (up- or down-stream), where it is received and > the responsibility of the NTLP ends." > > When end-to-end addressing is used, are you assuming that > the responsibility of the NTLP will end at each hop? i don't see the addressing model makes any difference here. the possible behaviour is described in the paragraph following the one with the sentence you quote. do you think that description is incorrect? (i think it's basically the same behaviour as rsvp with the necessary changes to support non-end-to-end operation and the fact that not all nodes will support all signalling applications.) > > Best Regards, > Georgios > > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: dinsdag 25 februari 2003 11:58 > To: Georgios Karagiannis (ELN); 'nsis@ietf.org' > Subject: RE: [NSIS] another attempt on NTLP peer-peer definition > > > hi georgios, > > see inline: > > > > Suppose that the NTLP is a hop-by-hop protocol. > > > > Are you then assuming that both types of addressing > > peer-to-peer addressing and end-to-end addressing > > can be applied in such a NTLP hop-by-hop protocol? > > as i say, it's a design choice (i.e. for later). rsvp uses > both (p2p always for resv, p2p or e2e for path). i think it's > hard to rule out either. > > > > > When peer-to-peer addressing is used, are you considering > > that the NTLP protocol will have to be terminated and re-initiated > > at each hop by the NSLP? > > > > When end-to-end addressing is used, are you also considering > > that the NTLP protocol will have to be terminated and re-initiated > > at each hop by the NSLP? > > i don't know what these questions mean in practice. can you > phrase them as comments on the text below? > > cheers, > > r. > > > > > > > Best Regards, > > Georgios > > > > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: dinsdag 25 februari 2003 10:46 > > To: Georgios Karagiannis (ELN); 'nsis@ietf.org' > > Subject: RE: [NSIS] another attempt on NTLP peer-peer definition > > > > > > georgios, > > > > indeed this is the terminology that the framework uses (in > > the -01 version in section 3.3.4, although we know that > > numbering will change soon...) > > > > i tried to write the email so it was a bit more self-explanatory. > > > > r. > > > > > -----Original Message----- > > > From: Georgios Karagiannis (ELN) > > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > > Sent: 25 February 2003 09:39 > > > To: Hancock, Robert; 'nsis@ietf.org' > > > Subject: RE: [NSIS] another attempt on NTLP peer-peer definition > > > > > > > > > Hi Robert > > > > > > Regarding the following paragraph: > > > "Note that there is no constraint on whether the message is sent > > > directly addressed to the next NE, or addressed to the flow > > > endpoint and intercepted along the path; both addressing models > > > are possible and necessary in some circumstances, and the > > > details are left to the protocol design stage." > > > > > > Are you denoting the addressing model where the message is sent > > > directly addressed to the next NE as peer-to-peer addressing > > > and the addressing model where is addressed to the flow > > > endpoint and intercepted along the path as end-to-end > > > addressing? > > > > > > Best Regards, > > > Georgios > > > > > > > > > > > > -----Original Message----- > > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > Sent: dinsdag 25 februari 2003 10:29 > > > To: 'nsis@ietf.org' > > > Subject: [NSIS] another attempt on NTLP peer-peer definition > > > > > > > > > dear all, > > > > > > Having read the mails on the 'consensus probe' thread, and > > > absorbed the ones relevant to the original question, here is > > > a revised attempt on the same subject: > > > > > > It's clear that the signalling exchanges considered by NSIS > > > can go a long way across a network, visiting a sequence of > > > NSIS entities (NEs). The protocol stack carrying the > > > signalling is divided into a common layer (the NTLP) and > > > signalling application specific layer (an NSLP). > > > > > > ============================================================== > > > ============================== > > > > > > It is a working assumption that the protocol mechanisms of > > > the NTLP operate only between adjacent NEs (informally, the > > > NTLP is a 'hop-by-hop' protocol), whereas any larger scope > > > issues (including e2e aspects) are left to the upper layers. > > > > > > When a signalling message is ready to be sent from one NE, it > > > is given to the NTLP along with information about what flow > > > it is for; it is then up to the NTLP to get it to the next NE > > > along the path (up- or down-stream), where it is received and > > > the responsibility of the NTLP ends. Note that there is no > > > constraint on whether the message is sent directly addressed > > > to the next NE, or addressed to the flow endpoint and > > > intercepted along the path; both addressing models are > > > possible and necessary in some circumstances, and the details > > > are left to the protocol design stage. The key point is that > > > the NTLP at a given NE does not use any knowledge about > > > addresses/capabilities/status/etc. of any NEs other than its > > > direct peers. > > > > > > The receiving NE may decide to forward the message directly, > > > invoking the NTLP again; or, it may give the message to a > > > signalling application for further processing which then > > > generates another message to be sent via the NTLP. In this > > > way, larger scope (including end-to-end) message delivery can > > > be automatically achieved. > > > > > > This definition relates to NTLP operation. It is not intended > > > to restrict the abiliity of an NSLP to send messages by other > > > means. For example, an NE in the middle or end of the > > > signalling path could send a message directly to the other > > > end as a notification of or acknowledgement for some > > > signalling application event. However, it appears that the > > > issues in sending such messages (endpoint discovery, > > > security, NAT traversal and so on) are so different from the > > > direct peer-peer case that there is no benefit in extending > > > the scope of the NTLP to include such non-local > > > functionality; instead, an NSLP which requires such messages > > > and wants to avoid traversing the path of NEs should use some > > > other existing transport protocol - for example, UDP would be > > > a good match for many of the scenarios that have been proposed. > > > > > > ============================================================== > > > =============================== > > > > > > OK, there hasn't been much discussion on the proposal in the > > > final paragraph. However, my impression is that the people > > > who want to use such notifications don't want to use any > > > interesting functionality in the NTLP anyway, so something > > > simple like plain UDP would be 'good enough' for them. In any > > > case, splitting this from the rest of NTLP requirements seems > > > reasonable to me - any other views? > > > > > > (One motivation for looking only at the hop-by-hop > > > functionality as a single protocol is that if there are any > > > options or variants in design approach - or, worse, in basic > > > functionality - it is easier to manage the resulting > > > complexity if it only impacts direct peers rather than > > > potentially the whole network. It also makes it easier to > > > deploy new versions. Obviously we'd rather get it right first > > > time and with no options, but I'm somehow sceptical that > > > that's possible...) > > > > > > Cheers, > > > > > > Robert H. > > > > > > PS this seems to be a simple concept, so why does the > > > definition have to be so long? Better words possible? > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 25 07:49:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28618 for ; Tue, 25 Feb 2003 07:49:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PCw2l26214 for nsis-archive@odin.ietf.org; Tue, 25 Feb 2003 07:58:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PCvvp26191; Tue, 25 Feb 2003 07:57:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PCtmp26076 for ; Tue, 25 Feb 2003 07:55:48 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28431 for ; Tue, 25 Feb 2003 07:46:13 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 12:50:06 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED4181EA849@rsys002a.roke.co.uk> From: "Hancock, Robert" To: "'Georgios Karagiannis (ELN)'" , "'nsis@ietf.org'" Subject: RE: [NSIS] another attempt on NTLP peer-peer definition Date: Tue, 25 Feb 2003 12:50:05 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , georgios, the difference between the two versions seems to me to be sub-microscopic in the level of precision involved; it wouldn't affect the protocol definition at all, but only the terminology you used to configure an entity that implemented it. i have no trouble living with it if others are happy. r. > -----Original Message----- > From: Georgios Karagiannis (ELN) > [mailto:Georgios.Karagiannis@eln.ericsson.se] > Sent: 25 February 2003 12:44 > To: Hancock, Robert; 'nsis@ietf.org' > Subject: RE: [NSIS] another attempt on NTLP peer-peer definition > > > Hi Robert > > Do you mean that you will agree with the following text: > > "The NTLP in the receiving NE may decide to forward the message > directly, or, it may give the message to a > signalling application for further processing which then > generates another message to be sent via the NTLP." > > Best regards, > Georgios > > > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: dinsdag 25 februari 2003 12:17 > To: Georgios Karagiannis (ELN); 'nsis@ietf.org' > Subject: RE: [NSIS] another attempt on NTLP peer-peer definition > > > hi georgios, > > > Okay, I have a comment regarding the following text: > > > > "it is then up to the NTLP to get it to the next NE > > along the path (up- or down-stream), where it is received and > > the responsibility of the NTLP ends." > > > > When end-to-end addressing is used, are you assuming that > > the responsibility of the NTLP will end at each hop? > > i don't see the addressing model makes any difference here. > the possible behaviour is described in the paragraph > following the one with the sentence you quote. do you think > that description is incorrect? (i think it's basically the > same behaviour as rsvp with the necessary changes to support > non-end-to-end operation and the fact that not all nodes will > support all signalling applications.) > > > > > Best Regards, > > Georgios > > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: dinsdag 25 februari 2003 11:58 > > To: Georgios Karagiannis (ELN); 'nsis@ietf.org' > > Subject: RE: [NSIS] another attempt on NTLP peer-peer definition > > > > > > hi georgios, > > > > see inline: > > > > > > Suppose that the NTLP is a hop-by-hop protocol. > > > > > > Are you then assuming that both types of addressing > > > peer-to-peer addressing and end-to-end addressing > > > can be applied in such a NTLP hop-by-hop protocol? > > > > as i say, it's a design choice (i.e. for later). rsvp uses > > both (p2p always for resv, p2p or e2e for path). i think it's > > hard to rule out either. > > > > > > > > When peer-to-peer addressing is used, are you considering > > > that the NTLP protocol will have to be terminated and > re-initiated > > > at each hop by the NSLP? > > > > > > When end-to-end addressing is used, are you also considering > > > that the NTLP protocol will have to be terminated and > re-initiated > > > at each hop by the NSLP? > > > > i don't know what these questions mean in practice. can you > > phrase them as comments on the text below? > > > > cheers, > > > > r. > > > > > > > > > > > Best Regards, > > > Georgios > > > > > > > > > -----Original Message----- > > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > Sent: dinsdag 25 februari 2003 10:46 > > > To: Georgios Karagiannis (ELN); 'nsis@ietf.org' > > > Subject: RE: [NSIS] another attempt on NTLP peer-peer definition > > > > > > > > > georgios, > > > > > > indeed this is the terminology that the framework uses (in > > > the -01 version in section 3.3.4, although we know that > > > numbering will change soon...) > > > > > > i tried to write the email so it was a bit more self-explanatory. > > > > > > r. > > > > > > > -----Original Message----- > > > > From: Georgios Karagiannis (ELN) > > > > [mailto:Georgios.Karagiannis@eln.ericsson.se] > > > > Sent: 25 February 2003 09:39 > > > > To: Hancock, Robert; 'nsis@ietf.org' > > > > Subject: RE: [NSIS] another attempt on NTLP peer-peer definition > > > > > > > > > > > > Hi Robert > > > > > > > > Regarding the following paragraph: > > > > "Note that there is no constraint on whether the > message is sent > > > > directly addressed to the next NE, or addressed to the flow > > > > endpoint and intercepted along the path; both addressing models > > > > are possible and necessary in some circumstances, and the > > > > details are left to the protocol design stage." > > > > > > > > Are you denoting the addressing model where the message is sent > > > > directly addressed to the next NE as peer-to-peer addressing > > > > and the addressing model where is addressed to the flow > > > > endpoint and intercepted along the path as end-to-end > > > > addressing? > > > > > > > > Best Regards, > > > > Georgios > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > > > Sent: dinsdag 25 februari 2003 10:29 > > > > To: 'nsis@ietf.org' > > > > Subject: [NSIS] another attempt on NTLP peer-peer definition > > > > > > > > > > > > dear all, > > > > > > > > Having read the mails on the 'consensus probe' thread, and > > > > absorbed the ones relevant to the original question, here is > > > > a revised attempt on the same subject: > > > > > > > > It's clear that the signalling exchanges considered by NSIS > > > > can go a long way across a network, visiting a sequence of > > > > NSIS entities (NEs). The protocol stack carrying the > > > > signalling is divided into a common layer (the NTLP) and > > > > signalling application specific layer (an NSLP). > > > > > > > > ============================================================== > > > > ============================== > > > > > > > > It is a working assumption that the protocol mechanisms of > > > > the NTLP operate only between adjacent NEs (informally, the > > > > NTLP is a 'hop-by-hop' protocol), whereas any larger scope > > > > issues (including e2e aspects) are left to the upper layers. > > > > > > > > When a signalling message is ready to be sent from one NE, it > > > > is given to the NTLP along with information about what flow > > > > it is for; it is then up to the NTLP to get it to the next NE > > > > along the path (up- or down-stream), where it is received and > > > > the responsibility of the NTLP ends. Note that there is no > > > > constraint on whether the message is sent directly addressed > > > > to the next NE, or addressed to the flow endpoint and > > > > intercepted along the path; both addressing models are > > > > possible and necessary in some circumstances, and the details > > > > are left to the protocol design stage. The key point is that > > > > the NTLP at a given NE does not use any knowledge about > > > > addresses/capabilities/status/etc. of any NEs other than its > > > > direct peers. > > > > > > > > The receiving NE may decide to forward the message directly, > > > > invoking the NTLP again; or, it may give the message to a > > > > signalling application for further processing which then > > > > generates another message to be sent via the NTLP. In this > > > > way, larger scope (including end-to-end) message delivery can > > > > be automatically achieved. > > > > > > > > This definition relates to NTLP operation. It is not intended > > > > to restrict the abiliity of an NSLP to send messages by other > > > > means. For example, an NE in the middle or end of the > > > > signalling path could send a message directly to the other > > > > end as a notification of or acknowledgement for some > > > > signalling application event. However, it appears that the > > > > issues in sending such messages (endpoint discovery, > > > > security, NAT traversal and so on) are so different from the > > > > direct peer-peer case that there is no benefit in extending > > > > the scope of the NTLP to include such non-local > > > > functionality; instead, an NSLP which requires such messages > > > > and wants to avoid traversing the path of NEs should use some > > > > other existing transport protocol - for example, UDP would be > > > > a good match for many of the scenarios that have been proposed. > > > > > > > > ============================================================== > > > > =============================== > > > > > > > > OK, there hasn't been much discussion on the proposal in the > > > > final paragraph. However, my impression is that the people > > > > who want to use such notifications don't want to use any > > > > interesting functionality in the NTLP anyway, so something > > > > simple like plain UDP would be 'good enough' for them. In any > > > > case, splitting this from the rest of NTLP requirements seems > > > > reasonable to me - any other views? > > > > > > > > (One motivation for looking only at the hop-by-hop > > > > functionality as a single protocol is that if there are any > > > > options or variants in design approach - or, worse, in basic > > > > functionality - it is easier to manage the resulting > > > > complexity if it only impacts direct peers rather than > > > > potentially the whole network. It also makes it easier to > > > > deploy new versions. Obviously we'd rather get it right first > > > > time and with no options, but I'm somehow sceptical that > > > > that's possible...) > > > > > > > > Cheers, > > > > > > > > Robert H. > > > > > > > > PS this seems to be a simple concept, so why does the > > > > definition have to be so long? Better words possible? > > > > _______________________________________________ > > > > nsis mailing list > > > > nsis@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 25 08:19:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00340 for ; Tue, 25 Feb 2003 08:19:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PDSRF28424 for nsis-archive@odin.ietf.org; Tue, 25 Feb 2003 08:28:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PDRrp28359; Tue, 25 Feb 2003 08:27:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PDLYp28110 for ; Tue, 25 Feb 2003 08:21:34 -0500 Received: from goliath.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00051 for ; Tue, 25 Feb 2003 08:12:02 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id h1PDFuR12267 for ; Tue, 25 Feb 2003 14:15:56 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id h1PDFt625364 for ; Tue, 25 Feb 2003 14:15:56 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 14:15:54 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675DCE@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'nsis@ietf.org'" Date: Tue, 25 Feb 2003 14:15:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] addressing / discovery Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi all the terminology used in our previous discussion lead to some confusion. hence i will try it again: a) avoid the combination of signaling message delivery and discovery messages if it is a true discovery message then it is very difficult to secure the content of the signaling messages. the purpose of discovery is to find the next NSIS node. if you do not know this next peer then you cannot provide iron-clad security protection for it. existing security protocols such as IPsec, TLS, Kerberos, etc. cannot be used. b) end-to-end addressing of signaling messages if signaling messages are addressed end-to-end (although the next peer is known) the usage of existing security mechanism is prevented to a large extend (e.g. IPsec). in context of ipsec handling i described the reason some time ago. for tls usage the reason is obvious. conclusion: - separate signaling message delivery from discovery - allow existing security protocols to be used (i.e. peer-to-peer addressing of signaling messages) ciao hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 25 13:04:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08819 for ; Tue, 25 Feb 2003 13:04:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PIDuo18534 for nsis-archive@odin.ietf.org; Tue, 25 Feb 2003 13:13:56 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PIDlp18516; Tue, 25 Feb 2003 13:13:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PI9ip18320 for ; Tue, 25 Feb 2003 13:09:44 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08685 for ; Tue, 25 Feb 2003 13:00:06 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h1PI3rI16864; Tue, 25 Feb 2003 13:03:54 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FGRXTXHA; Tue, 25 Feb 2003 13:03:54 -0500 Received: from nortelnetworks.com (acart1dr.ca.nortel.com [47.129.129.100]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FSMZD3RK; Tue, 25 Feb 2003 13:03:54 -0500 Message-ID: <3E5BB006.4070107@nortelnetworks.com> Date: Tue, 25 Feb 2003 13:03:50 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030131 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: "Georgios Karagiannis (ELN)" CC: "'Hancock, Robert'" , "'nsis@ietf.org'" Subject: Re: [NSIS] another attempt on NTLP peer-peer definition References: <2B06CD3FC17AF64587BC7A7617B230C0CBB934@enleent103.nl.eu.ericsson.se> In-Reply-To: <2B06CD3FC17AF64587BC7A7617B230C0CBB934@enleent103.nl.eu.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit That's saying that some entities are just relay points at the NTLP level. Is this necessary, or can the NTLP use routing capabilities already in place to deliver to the target peers? Georgios Karagiannis (ELN) wrote: > Hi Robert > > Do you mean that you will agree with the following text: > > "The NTLP in the receiving NE may decide to forward the message > directly, or, it may give the message to a > signalling application for further processing which then > generates another message to be sent via the NTLP." > > Best regards, > Georgios > > > -----Original Message----- > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: dinsdag 25 februari 2003 12:17 > To: Georgios Karagiannis (ELN); 'nsis@ietf.org' > Subject: RE: [NSIS] another attempt on NTLP peer-peer definition > > > hi georgios, > > >>Okay, I have a comment regarding the following text: >> >>"it is then up to the NTLP to get it to the next NE >>along the path (up- or down-stream), where it is received and >>the responsibility of the NTLP ends." >> >>When end-to-end addressing is used, are you assuming that >>the responsibility of the NTLP will end at each hop? > > > i don't see the addressing model makes any difference here. the possible behaviour is described in the paragraph following the one with the sentence you quote. do you think that description is incorrect? (i think it's basically the same behaviour as rsvp with the necessary changes to support non-end-to-end operation and the fact that not all nodes will support all signalling applications.) > > >>Best Regards, >>Georgios >> >>-----Original Message----- >>From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] >>Sent: dinsdag 25 februari 2003 11:58 >>To: Georgios Karagiannis (ELN); 'nsis@ietf.org' >>Subject: RE: [NSIS] another attempt on NTLP peer-peer definition >> >> >>hi georgios, >> >>see inline: >> >>>Suppose that the NTLP is a hop-by-hop protocol. >>> >>>Are you then assuming that both types of addressing >>>peer-to-peer addressing and end-to-end addressing >>>can be applied in such a NTLP hop-by-hop protocol? >> >>as i say, it's a design choice (i.e. for later). rsvp uses >>both (p2p always for resv, p2p or e2e for path). i think it's >>hard to rule out either. >> >> >>>When peer-to-peer addressing is used, are you considering >>>that the NTLP protocol will have to be terminated and re-initiated >>>at each hop by the NSLP? >>> >>>When end-to-end addressing is used, are you also considering >>>that the NTLP protocol will have to be terminated and re-initiated >>>at each hop by the NSLP? >> >>i don't know what these questions mean in practice. can you >>phrase them as comments on the text below? >> >>cheers, >> >>r. >> >> >>> >>>Best Regards, >>>Georgios >>> >>> >>>-----Original Message----- >>>From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] >>>Sent: dinsdag 25 februari 2003 10:46 >>>To: Georgios Karagiannis (ELN); 'nsis@ietf.org' >>>Subject: RE: [NSIS] another attempt on NTLP peer-peer definition >>> >>> >>>georgios, >>> >>>indeed this is the terminology that the framework uses (in >>>the -01 version in section 3.3.4, although we know that >>>numbering will change soon...) >>> >>>i tried to write the email so it was a bit more self-explanatory. >>> >>>r. >>> >>> >>>>-----Original Message----- >>>>From: Georgios Karagiannis (ELN) >>>>[mailto:Georgios.Karagiannis@eln.ericsson.se] >>>>Sent: 25 February 2003 09:39 >>>>To: Hancock, Robert; 'nsis@ietf.org' >>>>Subject: RE: [NSIS] another attempt on NTLP peer-peer definition >>>> >>>> >>>>Hi Robert >>>> >>>>Regarding the following paragraph: >>>>"Note that there is no constraint on whether the message is sent >>>>directly addressed to the next NE, or addressed to the flow >>>>endpoint and intercepted along the path; both addressing models >>>>are possible and necessary in some circumstances, and the >>>>details are left to the protocol design stage." >>>> >>>>Are you denoting the addressing model where the message is sent >>>>directly addressed to the next NE as peer-to-peer addressing >>>>and the addressing model where is addressed to the flow >>>>endpoint and intercepted along the path as end-to-end >>>>addressing? >>>> >>>>Best Regards, >>>>Georgios >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] >>>>Sent: dinsdag 25 februari 2003 10:29 >>>>To: 'nsis@ietf.org' >>>>Subject: [NSIS] another attempt on NTLP peer-peer definition >>>> >>>> >>>>dear all, >>>> >>>>Having read the mails on the 'consensus probe' thread, and >>>>absorbed the ones relevant to the original question, here is >>>>a revised attempt on the same subject: >>>> >>>>It's clear that the signalling exchanges considered by NSIS >>>>can go a long way across a network, visiting a sequence of >>>>NSIS entities (NEs). The protocol stack carrying the >>>>signalling is divided into a common layer (the NTLP) and >>>>signalling application specific layer (an NSLP). >>>> >>>>============================================================== >>>>============================== >>>> >>>>It is a working assumption that the protocol mechanisms of >>>>the NTLP operate only between adjacent NEs (informally, the >>>>NTLP is a 'hop-by-hop' protocol), whereas any larger scope >>>>issues (including e2e aspects) are left to the upper layers. >>>> >>>>When a signalling message is ready to be sent from one NE, it >>>>is given to the NTLP along with information about what flow >>>>it is for; it is then up to the NTLP to get it to the next NE >>>>along the path (up- or down-stream), where it is received and >>>>the responsibility of the NTLP ends. Note that there is no >>>>constraint on whether the message is sent directly addressed >>>>to the next NE, or addressed to the flow endpoint and >>>>intercepted along the path; both addressing models are >>>>possible and necessary in some circumstances, and the details >>>>are left to the protocol design stage. The key point is that >>>>the NTLP at a given NE does not use any knowledge about >>>>addresses/capabilities/status/etc. of any NEs other than its >>>>direct peers. >>>> >>>>The receiving NE may decide to forward the message directly, >>>>invoking the NTLP again; or, it may give the message to a >>>>signalling application for further processing which then >>>>generates another message to be sent via the NTLP. In this >>>>way, larger scope (including end-to-end) message delivery can >>>>be automatically achieved. >>>> >>>>This definition relates to NTLP operation. It is not intended >>>>to restrict the abiliity of an NSLP to send messages by other >>>>means. For example, an NE in the middle or end of the >>>>signalling path could send a message directly to the other >>>>end as a notification of or acknowledgement for some >>>>signalling application event. However, it appears that the >>>>issues in sending such messages (endpoint discovery, >>>>security, NAT traversal and so on) are so different from the >>>>direct peer-peer case that there is no benefit in extending >>>>the scope of the NTLP to include such non-local >>>>functionality; instead, an NSLP which requires such messages >>>>and wants to avoid traversing the path of NEs should use some >>>>other existing transport protocol - for example, UDP would be >>>>a good match for many of the scenarios that have been proposed. >>>> >>>>============================================================== >>>>=============================== >>>> >>>>OK, there hasn't been much discussion on the proposal in the >>>>final paragraph. However, my impression is that the people >>>>who want to use such notifications don't want to use any >>>>interesting functionality in the NTLP anyway, so something >>>>simple like plain UDP would be 'good enough' for them. In any >>>>case, splitting this from the rest of NTLP requirements seems >>>>reasonable to me - any other views? >>>> >>>>(One motivation for looking only at the hop-by-hop >>>>functionality as a single protocol is that if there are any >>>>options or variants in design approach - or, worse, in basic >>>>functionality - it is easier to manage the resulting >>>>complexity if it only impacts direct peers rather than >>>>potentially the whole network. It also makes it easier to >>>>deploy new versions. Obviously we'd rather get it right first >>>>time and with no options, but I'm somehow sceptical that >>>>that's possible...) >>>> >>>>Cheers, >>>> >>>>Robert H. >>>> >>>>PS this seems to be a simple concept, so why does the >>>>definition have to be so long? Better words possible? >>>>_______________________________________________ >>>>nsis mailing list >>>>nsis@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/nsis >>>> >>> > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Feb 25 17:33:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20355 for ; Tue, 25 Feb 2003 17:33:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PMgSw05508 for nsis-archive@odin.ietf.org; Tue, 25 Feb 2003 17:42:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PMgOp05500; Tue, 25 Feb 2003 17:42:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PMfup05458 for ; Tue, 25 Feb 2003 17:41:56 -0500 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20329 for ; Tue, 25 Feb 2003 17:32:10 -0500 (EST) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Feb 2003 22:36:05 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED41806AC07EA@rsys002a.roke.co.uk> From: "Hancock, Robert" To: Tom Taylor , "Georgios Karagiannis (ELN)" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] another attempt on NTLP peer-peer definition Date: Tue, 25 Feb 2003 22:35:55 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi tom, > That's saying that some entities are just relay points at the > NTLP level. Indeed. > Is this necessary, or can the NTLP use routing capabilities already > in place to deliver to the target peers? The NTLP does use standard IP routing to do this; if a packet with an NSIS message inside hits an NSIS-unaware node (a plain old router) it just gets forwarded like any other IP traffic. The issue you raise is that there may be nodes which are NSIS-aware but which still aren't interested in this particular message. (Half-plausible example: an RSVP PATH-like message with the router alert option carrying a firewall pinhole request is intercepted by a node which only understands QoS.) The message then has to be relayed at the NTLP level. Hope this helps, Robert H. PS Actually it is possible to design signalling frameworks which avoid this problem. But you need a very connection-oriented approach for most of the signalling and a separate sophisticated capability-aware peer-discovery mechanism. I find the picture attractive, but I doubt it will be our first step. > > Georgios Karagiannis (ELN) wrote: > > Hi Robert > > > > Do you mean that you will agree with the following text: > > > > "The NTLP in the receiving NE may decide to forward the message > > directly, or, it may give the message to a > > signalling application for further processing which then > > generates another message to be sent via the NTLP." > > > > Best regards, > > Georgios > > > > > > -----Original Message----- > > From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: dinsdag 25 februari 2003 12:17 > > To: Georgios Karagiannis (ELN); 'nsis@ietf.org' > > Subject: RE: [NSIS] another attempt on NTLP peer-peer definition > > > > > > hi georgios, > > > > > >>Okay, I have a comment regarding the following text: > >> > >>"it is then up to the NTLP to get it to the next NE > >>along the path (up- or down-stream), where it is received and > >>the responsibility of the NTLP ends." > >> > >>When end-to-end addressing is used, are you assuming that > >>the responsibility of the NTLP will end at each hop? > > > > > > i don't see the addressing model makes any difference here. > the possible behaviour is described in the paragraph > following the one with the sentence you quote. do you think > that description is incorrect? (i think it's basically the > same behaviour as rsvp with the necessary changes to support > non-end-to-end operation and the fact that not all nodes will > support all signalling applications.) > > > > > >>Best Regards, > >>Georgios > >> > >>-----Original Message----- > >>From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > >>Sent: dinsdag 25 februari 2003 11:58 > >>To: Georgios Karagiannis (ELN); 'nsis@ietf.org' > >>Subject: RE: [NSIS] another attempt on NTLP peer-peer definition > >> > >> > >>hi georgios, > >> > >>see inline: > >> > >>>Suppose that the NTLP is a hop-by-hop protocol. > >>> > >>>Are you then assuming that both types of addressing > >>>peer-to-peer addressing and end-to-end addressing > >>>can be applied in such a NTLP hop-by-hop protocol? > >> > >>as i say, it's a design choice (i.e. for later). rsvp uses > >>both (p2p always for resv, p2p or e2e for path). i think it's > >>hard to rule out either. > >> > >> > >>>When peer-to-peer addressing is used, are you considering > >>>that the NTLP protocol will have to be terminated and re-initiated > >>>at each hop by the NSLP? > >>> > >>>When end-to-end addressing is used, are you also considering > >>>that the NTLP protocol will have to be terminated and re-initiated > >>>at each hop by the NSLP? > >> > >>i don't know what these questions mean in practice. can you > >>phrase them as comments on the text below? > >> > >>cheers, > >> > >>r. > >> > >> > >>> > >>>Best Regards, > >>>Georgios > >>> > >>> > >>>-----Original Message----- > >>>From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > >>>Sent: dinsdag 25 februari 2003 10:46 > >>>To: Georgios Karagiannis (ELN); 'nsis@ietf.org' > >>>Subject: RE: [NSIS] another attempt on NTLP peer-peer definition > >>> > >>> > >>>georgios, > >>> > >>>indeed this is the terminology that the framework uses (in > >>>the -01 version in section 3.3.4, although we know that > >>>numbering will change soon...) > >>> > >>>i tried to write the email so it was a bit more self-explanatory. > >>> > >>>r. > >>> > >>> > >>>>-----Original Message----- > >>>>From: Georgios Karagiannis (ELN) > >>>>[mailto:Georgios.Karagiannis@eln.ericsson.se] > >>>>Sent: 25 February 2003 09:39 > >>>>To: Hancock, Robert; 'nsis@ietf.org' > >>>>Subject: RE: [NSIS] another attempt on NTLP peer-peer definition > >>>> > >>>> > >>>>Hi Robert > >>>> > >>>>Regarding the following paragraph: > >>>>"Note that there is no constraint on whether the message is sent > >>>>directly addressed to the next NE, or addressed to the flow > >>>>endpoint and intercepted along the path; both addressing models > >>>>are possible and necessary in some circumstances, and the > >>>>details are left to the protocol design stage." > >>>> > >>>>Are you denoting the addressing model where the message is sent > >>>>directly addressed to the next NE as peer-to-peer addressing > >>>>and the addressing model where is addressed to the flow > >>>>endpoint and intercepted along the path as end-to-end > >>>>addressing? > >>>> > >>>>Best Regards, > >>>>Georgios > >>>> > >>>> > >>>> > >>>>-----Original Message----- > >>>>From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] > >>>>Sent: dinsdag 25 februari 2003 10:29 > >>>>To: 'nsis@ietf.org' > >>>>Subject: [NSIS] another attempt on NTLP peer-peer definition > >>>> > >>>> > >>>>dear all, > >>>> > >>>>Having read the mails on the 'consensus probe' thread, and > >>>>absorbed the ones relevant to the original question, here is > >>>>a revised attempt on the same subject: > >>>> > >>>>It's clear that the signalling exchanges considered by NSIS > >>>>can go a long way across a network, visiting a sequence of > >>>>NSIS entities (NEs). The protocol stack carrying the > >>>>signalling is divided into a common layer (the NTLP) and > >>>>signalling application specific layer (an NSLP). > >>>> > >>>>============================================================== > >>>>============================== > >>>> > >>>>It is a working assumption that the protocol mechanisms of > >>>>the NTLP operate only between adjacent NEs (informally, the > >>>>NTLP is a 'hop-by-hop' protocol), whereas any larger scope > >>>>issues (including e2e aspects) are left to the upper layers. > >>>> > >>>>When a signalling message is ready to be sent from one NE, it > >>>>is given to the NTLP along with information about what flow > >>>>it is for; it is then up to the NTLP to get it to the next NE > >>>>along the path (up- or down-stream), where it is received and > >>>>the responsibility of the NTLP ends. Note that there is no > >>>>constraint on whether the message is sent directly addressed > >>>>to the next NE, or addressed to the flow endpoint and > >>>>intercepted along the path; both addressing models are > >>>>possible and necessary in some circumstances, and the details > >>>>are left to the protocol design stage. The key point is that > >>>>the NTLP at a given NE does not use any knowledge about > >>>>addresses/capabilities/status/etc. of any NEs other than its > >>>>direct peers. > >>>> > >>>>The receiving NE may decide to forward the message directly, > >>>>invoking the NTLP again; or, it may give the message to a > >>>>signalling application for further processing which then > >>>>generates another message to be sent via the NTLP. In this > >>>>way, larger scope (including end-to-end) message delivery can > >>>>be automatically achieved. > >>>> > >>>>This definition relates to NTLP operation. It is not intended > >>>>to restrict the abiliity of an NSLP to send messages by other > >>>>means. For example, an NE in the middle or end of the > >>>>signalling path could send a message directly to the other > >>>>end as a notification of or acknowledgement for some > >>>>signalling application event. However, it appears that the > >>>>issues in sending such messages (endpoint discovery, > >>>>security, NAT traversal and so on) are so different from the > >>>>direct peer-peer case that there is no benefit in extending > >>>>the scope of the NTLP to include such non-local > >>>>functionality; instead, an NSLP which requires such messages > >>>>and wants to avoid traversing the path of NEs should use some > >>>>other existing transport protocol - for example, UDP would be > >>>>a good match for many of the scenarios that have been proposed. > >>>> > >>>>============================================================== > >>>>=============================== > >>>> > >>>>OK, there hasn't been much discussion on the proposal in the > >>>>final paragraph. However, my impression is that the people > >>>>who want to use such notifications don't want to use any > >>>>interesting functionality in the NTLP anyway, so something > >>>>simple like plain UDP would be 'good enough' for them. In any > >>>>case, splitting this from the rest of NTLP requirements seems > >>>>reasonable to me - any other views? > >>>> > >>>>(One motivation for looking only at the hop-by-hop > >>>>functionality as a single protocol is that if there are any > >>>>options or variants in design approach - or, worse, in basic > >>>>functionality - it is easier to manage the resulting > >>>>complexity if it only impacts direct peers rather than > >>>>potentially the whole network. It also makes it easier to > >>>>deploy new versions. Obviously we'd rather get it right first > >>>>time and with no options, but I'm somehow sceptical that > >>>>that's possible...) > >>>> > >>>>Cheers, > >>>> > >>>>Robert H. > >>>> > >>>>PS this seems to be a simple concept, so why does the > >>>>definition have to be so long? Better words possible? > >>>>_______________________________________________ > >>>>nsis mailing list > >>>>nsis@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/nsis > >>>> > >>> > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 26 00:49:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29693 for ; Wed, 26 Feb 2003 00:49:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1Q5xIH32239 for nsis-archive@odin.ietf.org; Wed, 26 Feb 2003 00:59:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q5xDp32231; Wed, 26 Feb 2003 00:59:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1Q5uJp32175 for ; Wed, 26 Feb 2003 00:56:19 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29671 for ; Wed, 26 Feb 2003 00:46:26 -0500 (EST) From: john.loughney@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1Q5n6213274 for ; Wed, 26 Feb 2003 07:49:06 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 26 Feb 2003 07:50:21 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Feb 2003 07:50:20 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Feb 2003 07:50:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 26 Feb 2003 07:50:19 +0200 Message-ID: Thread-Topic: AW: [NSIS] Transport functionality in the NTLP Thread-Index: AcLcsBUrINfVrLB7SzCjTzBgAxOgnAAqiYVQ To: X-OriginalArrivalTime: 26 Feb 2003 05:50:20.0322 (UTC) FILETIME=[F263D820:01C2DD5A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1Q5uJp32176 Subject: [NSIS] Agenda Items for IETF 56 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi all, Please send in requests for time at the NSIS meeting in IETF 56. A link with the relevant draft is much appreciated. Main topics are: NSIS Requirements doc NSIS Framework doc NSIS Security Threats RSVP Security Properties NSIS Analysis doc discussion of NTLP properties I would like to avoid discussions on solutions. Remember, that IETF meeting time is limited, so presentations are frowned-upon, but discussion on open and active issues is encouraged. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Feb 26 23:48:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07984 for ; Wed, 26 Feb 2003 23:48:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1R4wme07166 for nsis-archive@odin.ietf.org; Wed, 26 Feb 2003 23:58:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R4wgp07157; Wed, 26 Feb 2003 23:58:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QI6ap30040 for ; Wed, 26 Feb 2003 13:06:36 -0500 Received: from titan.tele.pw.edu.pl (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18074 for ; Wed, 26 Feb 2003 12:56:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by titan.tele.pw.edu.pl (Postfix) with ESMTP id C1A5D3B6DD for ; Wed, 26 Feb 2003 19:00:21 +0100 (CET) Received: from aquila (zttstaff-dhcp121.tele.pw.edu.pl [194.29.169.121]) by titan.tele.pw.edu.pl (Postfix) with ESMTP id 2782D3B6C7 for ; Wed, 26 Feb 2003 18:58:55 +0100 (CET) Message-ID: <410-22003232618142143@aquila> From: "Art-QoS" To: nsis@ietf.org Date: Wed, 26 Feb 2003 19:01:42 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 titan Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1QI6ap30042 Subject: [NSIS] Call for Participation Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit We apologize if you recieve multiple copies of this message. CALL FOR PARTICIPATION Art-QoS 2003 Workshop on ARCHITECTURES FOR QUALITY OF SERVICE IN THE INTERNET jointly held with THE FINAL AQUILA IST SEMINAR Warsaw, Poland, March 24-25, 2003 Organised by: Institute of Telecommunications Warsaw University of Technology, Poland WORKSHOP PURPOSE The Workshop is organised for bringing together the researchers working on providing Quality of Service (QoS) into IP-based networks. The intention is to discuss architectural and traffic control mechanisms aspects supporting end-to-end QoS. The Workshop is organised jointly with the Final Seminar of the AQUILA IST project. The AQUILA (Adaptive Resource Control for QoS Using an IP-based Layered Architecture) project started in December 1999 with 12 partners from 6 countries (Austria, Finland, Germany, Greece, Italy and Poland). The project has defined a comprehensive framework for the support of QoS in IP-based networks. The proposed solutions were implemented in the form of prototypes and tested in the AQUILA trial sites, in Helsinki, Vienna and Warsaw. During the Workshop there are planned two special sessions devoted to AQUILA. More information about the project one can find at www.ist-aquila.org . WORKSHOP VENUE The Workshop will be held in the Sheraton Warsaw Hotel situated near the centre of Warsaw: www.sheraton.pl PROCEEDINGS EDITION All accepted papers will be published in the form of a book, in the Lecture Notes in Computer Science (LNCS) series by Springer-Verlag. Remark that the paper publication is conditioned by paper presentation at the Workshop. CONFERENCE PROGRAMME The detailed Conference Programme is available at: www.tele.pw.edu.pl/art-qos March 24th, 2003 (Monday) 8:00 - 18:00 Reception desk 9:00 - 9:10 Opening 9:10 - 10:45 Session 1: Architectures for Next Generation Networks Keynote: Martin Potts, Evolving Telecommunication Network 10:45 - 11:15 Refreshment break 11:15 - 12:45 Session 2 : Routing 12:45 - 14:15 Lunch 14:15 - 16:00 Session 3 : Signalling 16:00 - 16:30 Refreshment break 16:30 - 18:00 Session 4 : Admission Control 20:00 Dinner March 25th, 2003 (Tuesday) 8:00 - 18:00 Reception desk 9:00 - 10:45 Session 5 : AQUILA Architecture (1) Keynote: Berthold F. Koch & Heinrich Hussmann, Overview of the project AQUILA (IST-1999-10077) 10:45 - 11:15 Refreshment break 11:15 - 12:55 Session 6 : AQUILA Architecture (2) 12:55 - 14:15 Lunch 14:15 - 15:45 Session 7 : Architectures and Services 15:45 - 16:15 Refreshment break 16:15 - 17:45 Session 8 : Traffic Control Mechanisms 17:45 - 18.00 Closing ACCOMMODATION For the conference participants the organisers booked the rooms in the Sheraton Warsaw Hotel with special price (125 EUR + 7% VAT for single room). The hotel registration form one can find at www.tele.pw.edu.pl/art-qos The special rates are guaranteed for the reser-vations not later than March 3rd. WORKSHOP REGISTRATION The Workshop fee is: 250 EUR, registration before March 3rd, 2003 300 EUR, registration after March 3rd, 2003 The Workshop fee includes: pre conference proceedings, post conference proceedings edition (in the form of book) in the Lecture Notes in Computer Science (LNCS) series by Springer-Verlag, lunches and coffee breaks during the Workshop. Conference book will be distributed via mail after the Workshop. Payment should be made by bank transfer or by credit card at the Workshop reception desk. Detailed payment instructions are included in the registration form. The registration form you can download from Conference web page: www.tele.pw.edu.pl/art-qos Please, send the filled registration form by fax: +48 22 660 75 64 or by e-mail: art-qos@tele.pw.edu.pl SPONSORS NASK, Research and Academic Computer Network ATM S.A. DGT Sp. z o.o. IEEE Chapter 19, Warsaw, Poland CORRESPONDENCE ADDRESS Halina Tarasiuk Institute of Telecommunications Warsaw University of Technology Ul. Nowowiejska 15/19 00-665 Warsaw, Poland Phone: (+48 22) 660 73 96 Fax: (+48 22) 660 75 64 E-mail: art-qos@tele.pw.edu.pl PROGRAM COMMITTEE Co-chairs Wojciech Burakowski, Warsaw University of Technology, Poland Berthold Koch, Siemens AG, Germany Members Jose Brazio, Telecommunications Institute Lisbon, Portugal Andrzej Dabrowski, Warsaw University of Technology, Poland Franco Davoli, University of Genua, Italy Gerald Eichler, T-Systems Nova, Germany Hermann Granzer, Siemens AG, Germany Ulrich Hofmann, Salzburg Research, Austria Heinrich Hussmann, Dresden University of Technology, Germany Laszlo Jereb, Budapest University of Technology and Economics, Hungary Yannis Karadimas, Q-Systems, Greece Ilkka Norros, VTT Information Technology, Finland James Roberts, France Telecom R&D, France Stefano Salsano, University of Roma "Tor Vergata", Italy Paulo de Sousa ,European Commission Phuoc Tran-Gia, University of Wuerzburg, Germany Iakovos S. Venieris, National Technical University of Athens, Greece Manuel Villen Altamirano, Telefonica I+D, Spain Jozef Wozniak, Technical University of Gdansk, Poland LOCAL ORGANISING COMMITTEE Andrzej Bak, Andrzej Beben, Marek Dabrowski, Monika Fudala, Halina Tarasiuk (chair), Elzbieta Tarwacka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 27 03:14:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22407 for ; Thu, 27 Feb 2003 03:14:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1R8OJ029852 for nsis-archive@odin.ietf.org; Thu, 27 Feb 2003 03:24:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R8OCp29838; Thu, 27 Feb 2003 03:24:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R8LEp29724 for ; Thu, 27 Feb 2003 03:21:14 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22273 for ; Thu, 27 Feb 2003 03:10:50 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 27 Feb 2003 09:14:32 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 09:14:31 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE23B37F@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: Hannes.Tschofenig@mchp.siemens.de Cc: nsis@ietf.org Subject: [NSIS] Security threats Date: Thu, 27 Feb 2003 09:14:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1R8LFp29725 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello Hannes, I appreciate the work you've done with the "Security Threats for NSIS" draft and agree with most of the assumptions and conclusions you draw. However there's one point where I'd like to have some clarification: Section 1.2, End-to-End Communication concluding that end to end signaling is hard to secure and therefore not required, peer to peer protection will do. First of all, I'm not sure whether this paragraph says that end to end signaling is not required or whether it is just end to end security which is not required. If this paragraphs conclusion is limited to the e2e security, which isn't required, it may be an acceptable conclusion. Could you make that more explicit? What is important to me is, that end to end signaling is a requirement. It seems acceptable to process e2e signaling messages by all NTLP units along a path. As long as intermediate NSLPs aren't required to process them. As a consequence, NTLP must be able to construct the downstream and upstream signaling path between NI and NR on its own. Otherwise your above assumption on peer to peer protection securing e2e signaling is broken. Do you assume that? Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 27 03:31:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22806 for ; Thu, 27 Feb 2003 03:31:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1R8fCU31273 for nsis-archive@odin.ietf.org; Thu, 27 Feb 2003 03:41:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R8f4p31264; Thu, 27 Feb 2003 03:41:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R8cwp31129 for ; Thu, 27 Feb 2003 03:38:58 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22741 for ; Thu, 27 Feb 2003 03:28:34 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 27 Feb 2003 09:32:12 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 09:31:47 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE23B380@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: acmorton@att.com Cc: nsis@ietf.org Subject: [NSIS] Requirements: text proposal 5.3.4 Date: Thu, 27 Feb 2003 09:31:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Dear Marcus, as agreed during the interim meeting, I propose some replacement text for "5.3.4 Feedback about success of service request": 5.3.4 Establishment, change to and refusal to set up state MUST be acknowledged An NR MUST acknowledge establishment of state on behalf of the NI requesting establishment of that state. With the exception of the NI, any NE initiating a change of state MUST signal this along the upstream and downstream signaling path so that other possibly involved NEs and finally NI and NR may adjust their state maintenance. A refusal to set up state MUST be replied with a negative acknowledgement by the NE refusing to set up state. It MUST be sent to the NI. Information on the reason of the refusal to set up state SHOULD be made available. Depending on the NSLP, the (negative) acknowledement may have to pass further NEs (an example would be QoS related signaling). Comments and improvements are welcome. Regards, Rudiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 27 08:30:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01269 for ; Thu, 27 Feb 2003 08:30:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RDeWk19205 for nsis-archive@odin.ietf.org; Thu, 27 Feb 2003 08:40:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RDePp19195; Thu, 27 Feb 2003 08:40:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RDd2p19079 for ; Thu, 27 Feb 2003 08:39:02 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01217 for ; Thu, 27 Feb 2003 08:28:29 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id h1RDWPI08367; Thu, 27 Feb 2003 14:32:25 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id h1RDWPs05430; Thu, 27 Feb 2003 14:32:25 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 14:32:24 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675E07@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Geib, Ruediger'" Cc: nsis@ietf.org Subject: RE: [NSIS] Security threats Date: Thu, 27 Feb 2003 14:32:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi ruediger! thank you for reading the draft and for submitting your comments. > > Hello Hannes, > > I appreciate the work you've done with the "Security Threats > for NSIS" draft and agree with most of the assumptions and > conclusions you draw. However there's one point where I'd > like to have some clarification: > > Section 1.2, End-to-End Communication > concluding that end to end signaling is hard to secure and > therefore not required, peer to peer protection will do. > > First of all, I'm not sure whether this paragraph says that > end to end signaling is not required or whether it is just > end to end security which is not required. If this paragraphs > conclusion is limited to the e2e security, which isn't > required, it may be an acceptable conclusion. Could you make > that more explicit? there are several issues which go with your question: (the term end-to-end refers to the communication between an NI and an NR. in many cases the NI and the NR are the two end hosts.) a) why is pure end-to-end communication an nsis issue? b) is end-to-end communication relevant for certain objects or for the entire messages? c) and finally: how are these objects or messages transmitted (see (1) and (2) below)? end-to-end signaling for (c) can mean two things: 1) a signaling message is sent between the NI and the NR without addressing the intermediate nodes (NF) at all. the nsis message simply skips all intermediate nodes and is processed only by the the end hosts. 2) a signaling message is sent between the NI and the NR addressing the intermediate nodes (NFs) in a peer-to-peer session style (regular nsis message forwarding). in the interim meeting i thought that we came to the conclusion that (1) is a bad thing since the message processing does not seem to make use of the state established at intermediate nodes. hence a protocol like http, sip, etc. could also provide the required functionality to ship messages between two nodes. this issue also refers to point (a) for a more abstract discussion. if the entire message is transmitted with (1) then for (b) only the entire message is meant. it might, from a performance point of view, provide some advantages to add objects which only have a meaning for the end hosts (b) into the nsis signaling protocol. i, however, guess that this is not a discussion right now. note that the end-to-end issue is particularly relevant if the communication is between the two end hosts. there are scenarios where nsis is, for example, used in an intra-domain environement only between the ingress and the egress. in these cases end-to-end security might not cause major difficulties for authentication and key exchange for an end-to-end security association. however, to support such a functionality as part of the main protocol it would be necessary to address end-to-end security for the more complex cases. this might turn out to make the protocol more difficult or complex. > > What is important to me is, that end to end signaling is a > requirement. It seems acceptable to process e2e signaling > messages by all NTLP units along a path. As long as > intermediate NSLPs aren't required to process them. As a > consequence, NTLP must be able to construct the downstream > and upstream signaling path between NI and NR on its own. > Otherwise your above assumption on peer to peer protection > securing e2e signaling is broken. Do you assume that? there seems to be an additional issue namely the "we skip some NF nodes along the path". this seems to be an issue of discovery. an example: a number of nsis nodes along the path support a ntlp. however, for firewall signaling only some of them need to be involved in the protocol processing since the remaining nodes are, for example, qos aware nodes (qos nslps). the question is now: would we like to skip the qos nodes when we do firewall signaling and address only those nodes which are able to process the firewall signaling messages? my preference: we should skip nodes which do not support a particular nslp implementation. this simplifies security handling, refresh message handling and reliability handling and provides improvements for message processing. the drawback is that the discovery procedure needs to include some capability functionality (i.e. the discovery message says: "i would like to discover the next firewall along the path."). conclusion for your draft question: i can make the issue described in the nsis threats document more complete once i know what some other people think about it. the issue, as it is described in the draft today, only raises concerns about the additional complexity when end-to-end signaling (and also end-to-end security) is added as a main protocol feature. it might be true that in some scenarios security is not an issue but for all other scenarios it has to be addressed (including issues like delegation etc.). ciao hannes > > Regards, Rüdiger > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 27 09:12:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03828 for ; Thu, 27 Feb 2003 09:12:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1REMUW22364 for nsis-archive@odin.ietf.org; Thu, 27 Feb 2003 09:22:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1REMPp22357; Thu, 27 Feb 2003 09:22:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RELcp22243 for ; Thu, 27 Feb 2003 09:21:38 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03764 for ; Thu, 27 Feb 2003 09:11:07 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 27 Feb 2003 15:15:01 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 15:15:01 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE23B386@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: Hannes.Tschofenig@mchp.siemens.de Cc: nsis@ietf.org Subject: [NSIS] Security threats - NTLP awareness of upstream path Date: Thu, 27 Feb 2003 15:14:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Hi Hannes, instead of answering my question you seem to have raised a different issue. I'll reply to it with another mail. Still I'd like to know whether you (or others) expect NTLP to be aware of the upstream route to the next NTLP router. RG> What is important to me is, that end to end signaling is a | > requirement. It seems acceptable to process e2e signaling | > messages by all NTLP units along a path. As long as | > intermediate NSLPs aren't required to process them. As a | > consequence, NTLP must be able to construct the downstream | > and upstream signaling path between NI and NR on its own. | > Otherwise your above assumption on peer to peer protection | > securing e2e signaling is broken. Do you assume that? | | there seems to be an additional issue namely the "we skip | some NF nodes along the path". this seems to be an issue | of discovery. an example: [skipped] _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 27 09:17:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04294 for ; Thu, 27 Feb 2003 09:17:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RERAH22698 for nsis-archive@odin.ietf.org; Thu, 27 Feb 2003 09:27:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RER4p22687; Thu, 27 Feb 2003 09:27:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1REQtp22652 for ; Thu, 27 Feb 2003 09:26:55 -0500 Received: from tokyo.ccrle.nec.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04239 for ; Thu, 27 Feb 2003 09:16:23 -0500 (EST) From: brunner@ccrle.nec.de Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id h1REKGR23792; Thu, 27 Feb 2003 15:20:16 +0100 (CET) (envelope-from brunner@ccrle.nec.de) Received: from ccrle.nec.de (fortytwo.office [10.1.1.42]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with SMTP id CD0C0793BB; Thu, 27 Feb 2003 15:17:37 +0100 (CET) Received: from 10.1.1.83 (SquirrelMail authenticated user brunner) by fortytwo.office with HTTP; Thu, 27 Feb 2003 16:19:06 +0100 (CET) Message-ID: <4436.10.1.1.83.1046359146.squirrel@fortytwo.office> Date: Thu, 27 Feb 2003 16:19:06 +0100 (CET) Subject: Re: [NSIS] Requirements: text proposal 5.3.4 To: X-XheaderVersion: 1.1 X-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 In-Reply-To: <9F8582E37B2EE5498E76392AEDDCD3FE23B380@G8PQD.blf01.telekom.de> References: <9F8582E37B2EE5498E76392AEDDCD3FE23B380@G8PQD.blf01.telekom.de> X-Priority: 3 Importance: Normal Cc: , X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit The change of state notification issue is IMHO covered by Req 5.3.3. Therefore, the following change. Additionally, I think refusal of state setup can only be notified not acknowledged. And I would like to keep the example from the current text. So here my proposed changed paragraph. The adding of reason was a MAY in version -06. Kept the MAY there. The concept of NSLP is not known to the requirement draft is more a conclusion out of the requirements. 5.3.4 Establishment and refusal to set up state MUST be notified. An NR MUST acknowledge establishment of state on behalf of the NI requesting establishment of that state. A refusal to set up state MUST be replied with a negative acknowledgement by the NE refusing to set up state. It MUST be sent to the NI. Depending on the signaling application the (positive or negative) notifications may have to pass through further NEs upstream. Information on the reason of the refusal to set up state MAY be made available. E.g., in the resource reservation example, together with a negative answer also return the amount of resources available. Does this changes still capture the essence? Marcus > Dear Marcus, > > as agreed during the interim meeting, I propose some replacement text > for "5.3.4 Feedback about success of service request": > > 5.3.4 Establishment, change to and refusal to set up state MUST be > acknowledged An NR MUST acknowledge establishment of state on behalf of > the NI requesting establishment of that state. With the exception of the > NI, any NE initiating a change of state MUST signal this along the > upstream and downstream signaling path so that other possibly involved > NEs and finally NI and NR may adjust their state maintenance. A refusal > to set up state MUST be replied with a negative acknowledgement by the > NE refusing to set up state. It MUST be sent to the NI. Information on > the reason of the refusal to set up state SHOULD be made available. > Depending on the NSLP, the (negative) acknowledement may have to pass > further NEs (an example would be QoS related signaling). > > Comments and improvements are welcome. > > Regards, Rudiger > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 27 09:45:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05943 for ; Thu, 27 Feb 2003 09:45:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1REtED24892 for nsis-archive@odin.ietf.org; Thu, 27 Feb 2003 09:55:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1REtBp24885; Thu, 27 Feb 2003 09:55:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1REs5p24824 for ; Thu, 27 Feb 2003 09:54:05 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05900 for ; Thu, 27 Feb 2003 09:43:33 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 27 Feb 2003 15:47:27 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 15:47:27 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE23B387@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: Hannes.Tschofenig@mchp.siemens.de Cc: nsis@ietf.org Subject: Re: [NSIS] Security threats Date: Thu, 27 Feb 2003 15:47:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1REs5p24825 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Hannes, I'm having a less complex scenario in mind and add an example below, clarifying what I'd like get. Additional remarks in line. Regards, Rüdiger Here you mean NSLP, I guess. H|a number of nsis nodes along the path support a ntlp. | however, for firewall signaling only some of them | need to be involved in the protocol processing | since the remaining nodes are, for example, qos aware nodes | (qos nslps). | | the question is now: | would we like to skip the qos nodes when we do firewall | signaling and address only those nodes which are able | to process the firewall signaling messages? | | my preference: | we should skip nodes which do not support a particular nslp | implementation. If I remember right, we agreed on the Interim that NTLP is processing all NTLP messages regardless of local NSLP support. H|this simplifies security handling, refresh message handling | and reliability handling and provides improvements for | message processing. the drawback is that the discovery | procedure needs to include some capability functionality | (i.e. the discovery message says: "i would like to discover | the next firewall along the path."). I'm not sure whether that holds. A domain gateway router may support QoS-NSLP but no firewall-NSLP. The carrier may be interested in keeping unauthenticated signaling messages out of his domain in general. That isn't possible with your proposal (unless the gateway supports all NSLPs - which I don't feel to be useful). Finally, my example. Lets assume a customer network with two sites, making a QoS reservation to be used for VoIP calls accross a carrier network. To limit his backbone signaling processing requirements the carrier may prefer to stay out of per VoIP call signaling. So aggregation is applied between his edge nodes. Let's ignore how that is done with regard to QoS. With regard to signaling it means that the carrier routers only maintain state for a single reservation between the two customer sites. Per VoIP call NSIS state maintenance is restricted to the customer domain. Still, all related NSIS signaling messages traverse the carrier network. Path coupled, meaning NSIS path coupled (i.e. downstream and especially upstream). If only hop by hop security is available, the carriers NTLP still must process all per VoIP call signaling messages. Correct? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 27 09:48:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06033 for ; Thu, 27 Feb 2003 09:48:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1REw9w25022 for nsis-archive@odin.ietf.org; Thu, 27 Feb 2003 09:58:09 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1REw6p25015; Thu, 27 Feb 2003 09:58:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1REvpp24993 for ; Thu, 27 Feb 2003 09:57:51 -0500 Received: from david.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06018 for ; Thu, 27 Feb 2003 09:47:19 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id h1REpEo08422; Thu, 27 Feb 2003 15:51:14 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id h1REpEt17322; Thu, 27 Feb 2003 15:51:14 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 15:51:13 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03675E0E@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Geib, Ruediger'" Cc: nsis@ietf.org Subject: RE: [NSIS] Security threats - NTLP awareness of upstream path Date: Thu, 27 Feb 2003 15:51:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , hi guediger. sorry for introducing some confusion. my very short conclusion: if you want to have end-to-end signaling then you also need to provide end-to-end security. (it is important to see this in the context of the description i included my previous mail.) since this issues is, however, more complex i tried to illustrate my thoughts. your previous mail gave me the impression that we have a different understanding of end-to-end. hence i cannot give you a clear answer to your question in the last paragraph: " What is important to me is, that end to end signaling is a requirement. It seems acceptable to process e2e signaling messages by all NTLP units along a path. As long as intermediate NSLPs aren't required to process them. As a consequence, NTLP must be able to construct the downstream and upstream signaling path between NI and NR on its own. Otherwise your above assumption on peer to peer protection securing e2e signaling is broken. Do you assume that? " ciao hannes > Hi Hannes, > > instead of answering my question you seem to have raised > a different issue. I'll reply to it with another mail. > Still I'd like to know whether you (or others) expect > NTLP to be aware of the upstream route to the next > NTLP router. > > RG> What is important to me is, that end to end signaling is a > | > requirement. It seems acceptable to process e2e signaling > | > messages by all NTLP units along a path. As long as > | > intermediate NSLPs aren't required to process them. As a > | > consequence, NTLP must be able to construct the downstream > | > and upstream signaling path between NI and NR on its own. > | > Otherwise your above assumption on peer to peer protection > | > securing e2e signaling is broken. Do you assume that? > | > | there seems to be an additional issue namely the "we skip > | some NF nodes along the path". this seems to be an issue > | of discovery. an example: > > [skipped] > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 27 09:52:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06196 for ; Thu, 27 Feb 2003 09:52:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RF2Fm25321 for nsis-archive@odin.ietf.org; Thu, 27 Feb 2003 10:02:15 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RF2Cp25313; Thu, 27 Feb 2003 10:02:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RF1pp25283 for ; Thu, 27 Feb 2003 10:01:51 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06146 for ; Thu, 27 Feb 2003 09:51:18 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 27 Feb 2003 15:55:11 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 15:55:10 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE23B388@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: AW: [NSIS] Requirements: text proposal 5.3.4 Date: Thu, 27 Feb 2003 15:55:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1RF1pp25284 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Marcus, sounds acceptable to me, though I'd prefer to limit the example's indication to "network busy" (without resource information). Regards, Rüdiger Marcus suggested: | 5.3.4 Establishment and refusal to set up state MUST be notified. | | An NR MUST acknowledge establishment of state on behalf of the NI | requesting establishment of that state. A refusal to set up | state MUST be replied with a negative acknowledgement by the | NE refusing to set up state. It MUST be sent to the NI. Depending | on the signaling application the (positive or negative) | notifications may have to pass through further NEs upstream. | Information on the reason of the refusal to set up state MAY | be made available. E.g., in the resource reservation | example, together with a negative answer also return the amount | of resources available. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Feb 27 10:03:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06566 for ; Thu, 27 Feb 2003 10:03:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1RFDEY26594 for nsis-archive@odin.ietf.org; Thu, 27 Feb 2003 10:13:14 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RFDAp26587; Thu, 27 Feb 2003 10:13:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RFD0p26569 for ; Thu, 27 Feb 2003 10:13:00 -0500 Received: from mail1.telekom.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06515 for ; Thu, 27 Feb 2003 10:02:27 -0500 (EST) Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 27 Feb 2003 16:06:21 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Feb 2003 16:06:21 +0100 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE23B389@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: Hannes.Tschofenig@mchp.siemens.de Cc: nsis@ietf.org Subject: Re: [NSIS] Security threats - NTLP awareness of upstream path Date: Thu, 27 Feb 2003 16:06:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1RFD0p26570 Sender: nsis-admin@ietf.org Errors-To: nsis-admin@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Next Steps in Signaling List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Hannes | if you want to have end-to-end signaling then you also need to provide | end-to-end security. Allright. That coincides with the conclusions the last signaling design team drew I was working with. I've illustrated my end to end signaling scenario with an example in an earlier reply, but I'm happy to repeat it: Lets assume a customer network with two sites, making a QoS reservation to be used for VoIP calls accross a carrier network. To limit his backbone signaling processing requirements the carrier may prefer to stay out of per VoIP call signaling. So signaling aggregation is applied between his edge nodes. Let's ignore how that is done with regard to QoS. With regard to signaling it means that the carrier routers only maintain state for a single reservation between the two customer sites. Per VoIP call NSIS state maintenance is restricted to the customer domain. Still, all related NSIS signaling messages traverse the carrier network. Path coupled, meaning NSIS path coupled (i.e. downstream and especially upstream). The best solution to this would be one where neither the carrier routers NSLP nor the NTLP must process the per VoIP call NSIS signaling. Regards, Rüdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis