From mailnull@www1.ietf.org Mon Jun 2 07:32: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 HAA01881 for ; Mon, 2 Jun 2003 07:32:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52BWRW04028 for nsis-archive@odin.ietf.org; Mon, 2 Jun 2003 07:32:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52BWBB04004; Mon, 2 Jun 2003 07:32:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h52BTFB03820 for ; Mon, 2 Jun 2003 07:29:15 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01721; Mon, 2 Jun 2003 07:29:13 -0400 (EDT) Message-Id: <200306021129.HAA01721@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: Mon, 02 Jun 2003 07:29:13 -0400 Subject: [NSIS] I-D ACTION:draft-tschofenig-rsvp-doi-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 : RSVP Domain of Interpretation for ISAKMP Author(s) : H. Tschofenig, H. Schulzrinne Filename : draft-tschofenig-rsvp-doi-00.txt Pages : 22 Date : 2003-5-30 RSVP does not provide dynamic key management for the RSVP Integrity object. It is difficult to provide security for RSVP based on standard security protocols. This draft proposes the usage of the ISAKMP protocol with a new Domain of Interpretation (DoI) and allows to establish the necessary security parameters for the RSVP Integrity object. The Integrity object protects RSVP signaling messages at the application layer and uses this DoI to dynamically establish the necessary security associations. This document also addresses the NSIS NTLP work and protocol design implications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tschofenig-rsvp-doi-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-rsvp-doi-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-rsvp-doi-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-5-30152129.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-tschofenig-rsvp-doi-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-tschofenig-rsvp-doi-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-30152129.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 Jun 5 06:41: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 GAA14317 for ; Thu, 5 Jun 2003 06:41:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55Aeml22593 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 06:40:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55AeWB22577; Thu, 5 Jun 2003 06:40:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55Ad6B22483 for ; Thu, 5 Jun 2003 06:39:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14259 for ; Thu, 5 Jun 2003 06:39:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ns7J-0004oW-00 for nsis@ietf.org; Thu, 05 Jun 2003 06:37:09 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19Ns7I-0004oJ-00 for nsis@ietf.org; Thu, 05 Jun 2003 06:37:09 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jun 2003 11:38:24 +0100 Message-ID: From: "Hancock, Robert" To: nsis@ietf.org Date: Thu, 5 Jun 2003 11:38:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] framework: proposal on fragmentation 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, Since we all seem agreed that bundling should be in the NTLP (and in fact, it already apparently is), here is the second open issue on 'transport-like functions' and where they should go in the NTLP/NSLP layer model. This is the question of fragmentation, i.e. where to handle the fact that [NSLP message + NTLP encapsulation] may be bigger than the MTU on the path to the next NxLP node. There seem to me to be 3 main options: 1. leave it up to the IP layer. 2. do it in the NTLP. 3. do it (if needed) in the NSLP. My proposal is basically (2). Read no further if you agree... cheers, robert h. =========================================================================== Here is the background: This issue is not handled in 2961 but discussed as a potential problem there; there is also some analysis in draft-pan-nsis-rsvp-transport-01.txt (section 2.3). There has been some discussion of this in the past on this mailing list, but I couldn't really detect an agreed conclusion to it. I have tried to take it into account in this summary. The situation at the moment is that 'most' RSVP messages are 'small', and this only tends not to be so in the case that it is used over links where the MTU can be made large (9k is common for ATM/FR for example). We expect that this will change in the future - i.e. *some* signalling applications will generate big messages (as we add more security credentials for example), and we don't want to restrict the range of link types that can be used. Reasoning about the choices: 1. Doing it in the IP layer is conceivable but probably wouldn't work well for some awkward reasons, for example... a) IP fragmentation doesn't mix well with implicit addressing + the router alert option (Ping pointed this out at the interim). [I can't decide if this is an implementation issue or specification issue, but it certainly seems to be an issue.] b) If NSIS messages use flow source addresses (like RSVP), they would have to make up their own IP-ID/fragmentation headers independently of the real source node. This could lead to (theoretical) misassembly errors. c) We are trying (hard/a bit) to make NSIS NAT-friendly. Relying on IP layer fragmentation probably won't make this easier. (If you demand every NAT is at least NTLP aware, maybe you are OK.) d) IP fragmentation increases the underlying message loss rate (which then has to be recovered from). Maybe none of these are killing issues. 2. Doing it in the NTLP is a challenge for the NTLP designers... a) Only the NTLP knows its encapsulation overhead and so how to split up the NSLP messages. b) The best efficiency would gained from using some sort of PMTU-d, and I suspect only the NTLP can do this, since it controls IP layer addressing and sees the ICMP messages involved. It also knows when routes change and rediscovery is needed. (And PMTU-d would be useful anyway in the NTLP to do bundling best.) c) Fragmentation could be restricted to the particular NTLP hop that needs it rather than doing it everywhere. I think the main objection to doing it in the NTLP is that it's a function that not many applications/scenarios 'really' need, and we are overloading the common component for a minority interest. We can't really evaluate that argument without seeing how difficult it is (currently, I am not convinced by it). Also, doing fragmentation without the ability to retransmit lost fragments strikes me as a bad thing, but since the current NTLP proposal has some form of reliability in it this isn't relevant. 3. You can only do it in the NSLP if the NSLP knows what fragment size to use. As pointed out above, it doesn't, since there may be more than one NTLP hop to the next NSLP-aware node. (In theory, you could write an NSIS signalling application - which used only small messages! - to discover this information over the path and then use that. This strikes me as a interesting theoretical possibility, but unlikely to lead to good results in practice.) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 5 07:57: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 HAA16785 for ; Thu, 5 Jun 2003 07:57:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55BvLh27590 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 07:57:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55BvEB27581; Thu, 5 Jun 2003 07:57:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55BusB27539 for ; Thu, 5 Jun 2003 07:56:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16774 for ; Thu, 5 Jun 2003 07:56:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NtKe-0005G0-00 for nsis@ietf.org; Thu, 05 Jun 2003 07:55:00 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19NtKd-0005Fx-00 for nsis@ietf.org; Thu, 05 Jun 2003 07:55:00 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h55Buk5s001111; Thu, 5 Jun 2003 13:56:48 +0200 (MET DST) Message-ID: <004401c32b59$8c54d780$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" , References: Subject: Re: [NSIS] framework: proposal on fragmentation Date: Thu, 5 Jun 2003 13:56:47 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Robert Regarding your proposal (2) - fragmentation in NTLP. I will agree with your proposal if it will be posiible to also switch this featureoff when needed. For example, suppose that in a scenario the NTLP will have to support only one type of NSLP that uses small message types. In this situation the NTLP fragmentation feature could be switched off, i.e., not applied at all. Best Regards, Georgios ----- Original Message ----- From: "Hancock, Robert" To: Sent: Thursday, June 05, 2003 12:38 PM Subject: [NSIS] framework: proposal on fragmentation > dear all, > > Since we all seem agreed that bundling should be in the NTLP (and in fact, it > already apparently is), here is the second open issue on 'transport-like > functions' and where they should go in the NTLP/NSLP layer model. > > This is the question of fragmentation, i.e. where to handle the fact that > [NSLP message + NTLP encapsulation] may be bigger than the MTU on the path > to the next NxLP node. > > There seem to me to be 3 main options: > 1. leave it up to the IP layer. > 2. do it in the NTLP. > 3. do it (if needed) in the NSLP. > My proposal is basically (2). Read no further if you agree... > > cheers, > > robert h. > > =========================================================================== > Here is the background: > > This issue is not handled in 2961 but discussed as a potential problem there; > there is also some analysis in draft-pan-nsis-rsvp-transport-01.txt (section 2.3). There has been some discussion of this in the past on this mailing list, but I > couldn't really detect an agreed conclusion to it. I have tried to take it into > account in this summary. > > The situation at the moment is that 'most' RSVP messages are 'small', and > this only tends not to be so in the case that it is used over links where > the MTU can be made large (9k is common for ATM/FR for example). We expect that > this will change in the future - i.e. *some* signalling applications will generate > big messages (as we add more security credentials for example), and we don't want > to restrict the range of link types that can be used. > > Reasoning about the choices: > > 1. Doing it in the IP layer is conceivable but probably wouldn't work well for > some awkward reasons, for example... > a) IP fragmentation doesn't mix well with implicit addressing + the router alert > option (Ping pointed this out at the interim). [I can't decide if this is an > implementation issue or specification issue, but it certainly seems to be an > issue.] > b) If NSIS messages use flow source addresses (like RSVP), they would have > to make up their own IP-ID/fragmentation headers independently of the real source > node. This could lead to (theoretical) misassembly errors. > c) We are trying (hard/a bit) to make NSIS NAT-friendly. Relying on IP layer > fragmentation probably won't make this easier. (If you demand every NAT is at least > NTLP aware, maybe you are OK.) > d) IP fragmentation increases the underlying message loss rate (which then has to > be recovered from). > > Maybe none of these are killing issues. > > 2. Doing it in the NTLP is a challenge for the NTLP designers... > a) Only the NTLP knows its encapsulation overhead and so how to split up the > NSLP messages. > b) The best efficiency would gained from using some sort of PMTU-d, and I suspect > only the NTLP can do this, since it controls IP layer addressing and sees the > ICMP messages involved. It also knows when routes change and rediscovery is > needed. (And PMTU-d would be useful anyway in the NTLP to do bundling best.) > c) Fragmentation could be restricted to the particular NTLP hop that needs it > rather than doing it everywhere. > > I think the main objection to doing it in the NTLP is that it's a function that > not many applications/scenarios 'really' need, and we are overloading the common > component for a minority interest. We can't really evaluate that argument without > seeing how difficult it is (currently, I am not convinced by it). Also, doing > fragmentation without the ability to retransmit lost fragments strikes me as a bad > thing, but since the current NTLP proposal has some form of reliability in it > this isn't relevant. > > 3. You can only do it in the NSLP if the NSLP knows what fragment size to use. > As pointed out above, it doesn't, since there may be more than one NTLP hop to > the next NSLP-aware node. (In theory, you could write an NSIS signalling > application - which used only small messages! - to discover this information > over the path and then use that. This strikes me as a interesting theoretical > possibility, but unlikely to lead to good results in practice.) > _______________________________________________ > 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 Jun 5 08:01: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 IAA16966 for ; Thu, 5 Jun 2003 08:01:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55C1AW27896 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 08:01:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55C15B27848; Thu, 5 Jun 2003 08:01:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55C0RB27760 for ; Thu, 5 Jun 2003 08:00:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16876 for ; Thu, 5 Jun 2003 08:00:25 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NtO5-0005Gs-00 for nsis@ietf.org; Thu, 05 Jun 2003 07:58:33 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19NtO4-0005Gp-00 for nsis@ietf.org; Thu, 05 Jun 2003 07:58:32 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h55C0NW18394 for ; Thu, 5 Jun 2003 15:00:23 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 5 Jun 2003 15:00:23 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 5 Jun 2003 15:00:23 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 5 Jun 2003 14:58:44 +0300 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] framework: proposal on fragmentation Date: Thu, 5 Jun 2003 14:58:43 +0300 Message-ID: Thread-Topic: [NSIS] framework: proposal on fragmentation Thread-Index: AcMrTu5RXT92m2OoQMWUhPm3/CyIiAACsmHw To: , X-OriginalArrivalTime: 05 Jun 2003 11:58:44.0659 (UTC) FILETIME=[D07F4030:01C32B59] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h55C0RB27761 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, > This is the question of fragmentation, i.e. where to handle > the fact that > [NSLP message + NTLP encapsulation] may be bigger than the > MTU on the path > to the next NxLP node. > > There seem to me to be 3 main options: > 1. leave it up to the IP layer. > 2. do it in the NTLP. > 3. do it (if needed) in the NSLP. > My proposal is basically (2). Read no further if you agree... If we want NTLP to run over IPv6, I suppose we would like to handle it at the NTLP layer. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 5 08:09: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 IAA17901 for ; Thu, 5 Jun 2003 08:09:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55C9FG29279 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 08:09:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55C9AB29272; Thu, 5 Jun 2003 08:09:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55C8VB29242 for ; Thu, 5 Jun 2003 08:08:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17795 for ; Thu, 5 Jun 2003 08:08:29 -0400 (EDT) From: maarten.buchli@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NtVt-0005TZ-00 for nsis@ietf.org; Thu, 05 Jun 2003 08:06:37 -0400 Received: from alc240.alcatel.be ([195.207.101.240] helo=bt0rjw.god.bel.alcatel.be) by ietf-mx with esmtp (Exim 4.12) id 19NtVs-0005S8-00 for nsis@ietf.org; Thu, 05 Jun 2003 08:06:36 -0400 Received: from bemail05.net.alcatel.be (bemail05.net.alcatel.be [138.203.144.16]) by bt0rjw.god.bel.alcatel.be (8.12.9/8.11.4) with ESMTP id h55C7oBJ006468; Thu, 5 Jun 2003 14:07:50 +0200 (MEST) Subject: Re: [NSIS] framework: proposal on fragmentation To: "Georgios Karagiannis" Cc: "Hancock, Robert" , Date: Thu, 5 Jun 2003 14:07:49 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 06/05/2003 14:07:50 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 Georgios, Robert, I would agree as well on proposal 2, i.e. to locate the fragmentation into the NTLP. I am not sure however why there would be a need to be able to disable that functionality. Do you have a particular scenario in mind that requires this? Furthermore, would that exlude the use of TCP and SCTP as a transport protocol? regards, Maarten "Georgios Karagiannis" @ietf.org on 05/06/2003 13:56:47 Sent by: nsis-admin@ietf.org To: "Hancock, Robert" , cc: Subject: Re: [NSIS] framework: proposal on fragmentation Hi Robert Regarding your proposal (2) - fragmentation in NTLP. I will agree with your proposal if it will be posiible to also switch this featureoff when needed. For example, suppose that in a scenario the NTLP will have to support only one type of NSLP that uses small message types. In this situation the NTLP fragmentation feature could be switched off, i.e., not applied at all. Best Regards, Georgios ----- Original Message ----- From: "Hancock, Robert" To: Sent: Thursday, June 05, 2003 12:38 PM Subject: [NSIS] framework: proposal on fragmentation > dear all, > > Since we all seem agreed that bundling should be in the NTLP (and in fact, it > already apparently is), here is the second open issue on 'transport-like > functions' and where they should go in the NTLP/NSLP layer model. > > This is the question of fragmentation, i.e. where to handle the fact that > [NSLP message + NTLP encapsulation] may be bigger than the MTU on the path > to the next NxLP node. > > There seem to me to be 3 main options: > 1. leave it up to the IP layer. > 2. do it in the NTLP. > 3. do it (if needed) in the NSLP. > My proposal is basically (2). Read no further if you agree... > > cheers, > > robert h. > > =========================================================================== > Here is the background: > > This issue is not handled in 2961 but discussed as a potential problem there; > there is also some analysis in draft-pan-nsis-rsvp-transport-01.txt (section 2.3). There has been some discussion of this in the past on this mailing list, but I > couldn't really detect an agreed conclusion to it. I have tried to take it into > account in this summary. > > The situation at the moment is that 'most' RSVP messages are 'small', and > this only tends not to be so in the case that it is used over links where > the MTU can be made large (9k is common for ATM/FR for example). We expect that > this will change in the future - i.e. *some* signalling applications will generate > big messages (as we add more security credentials for example), and we don't want > to restrict the range of link types that can be used. > > Reasoning about the choices: > > 1. Doing it in the IP layer is conceivable but probably wouldn't work well for > some awkward reasons, for example... > a) IP fragmentation doesn't mix well with implicit addressing + the router alert > option (Ping pointed this out at the interim). [I can't decide if this is an > implementation issue or specification issue, but it certainly seems to be an > issue.] > b) If NSIS messages use flow source addresses (like RSVP), they would have > to make up their own IP-ID/fragmentation headers independently of the real source > node. This could lead to (theoretical) misassembly errors. > c) We are trying (hard/a bit) to make NSIS NAT-friendly. Relying on IP layer > fragmentation probably won't make this easier. (If you demand every NAT is at least > NTLP aware, maybe you are OK.) > d) IP fragmentation increases the underlying message loss rate (which then has to > be recovered from). > > Maybe none of these are killing issues. > > 2. Doing it in the NTLP is a challenge for the NTLP designers... > a) Only the NTLP knows its encapsulation overhead and so how to split up the > NSLP messages. > b) The best efficiency would gained from using some sort of PMTU-d, and I suspect > only the NTLP can do this, since it controls IP layer addressing and sees the > ICMP messages involved. It also knows when routes change and rediscovery is > needed. (And PMTU-d would be useful anyway in the NTLP to do bundling best.) > c) Fragmentation could be restricted to the particular NTLP hop that needs it > rather than doing it everywhere. > > I think the main objection to doing it in the NTLP is that it's a function that > not many applications/scenarios 'really' need, and we are overloading the common > component for a minority interest. We can't really evaluate that argument without > seeing how difficult it is (currently, I am not convinced by it). Also, doing > fragmentation without the ability to retransmit lost fragments strikes me as a bad > thing, but since the current NTLP proposal has some form of reliability in it > this isn't relevant. > > 3. You can only do it in the NSLP if the NSLP knows what fragment size to use. > As pointed out above, it doesn't, since there may be more than one NTLP hop to > the next NSLP-aware node. (In theory, you could write an NSIS signalling > application - which used only small messages! - to discover this information > over the path and then use that. This strikes me as a interesting theoretical > possibility, but unlikely to lead to good results in practice.) > _______________________________________________ > 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 Jun 5 08:13: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 IAA18029 for ; Thu, 5 Jun 2003 08:13:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55CDCQ29489 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 08:13:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55CD5B29480; Thu, 5 Jun 2003 08:13:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55CCQB29415 for ; Thu, 5 Jun 2003 08:12:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17984 for ; Thu, 5 Jun 2003 08:12:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NtZg-0005WV-00 for nsis@ietf.org; Thu, 05 Jun 2003 08:10:32 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19NtZf-0005W9-00 for nsis@ietf.org; Thu, 05 Jun 2003 08:10:31 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jun 2003 13:11:51 +0100 Message-ID: From: "Hancock, Robert" To: "'maarten.buchli@alcatel.be'" , Georgios Karagiannis Cc: nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation Date: Thu, 5 Jun 2003 13:11:46 +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 Maarten, > Hi Georgios, Robert, > > I would agree as well on proposal 2, i.e. to locate > the fragmentation into the NTLP. I am not sure > however why there would be a need to be able to > disable that functionality. Do you have a particular > scenario in mind that requires this? no comment! > > Furthermore, would that exlude the use of TCP and > SCTP as a transport protocol? that was not the intention - really the functionality I am talking about is 'handle big messages' and TCP/SCTP are clearly able to do that. (it might not be called 'fragmentation' in those protocols but the function is there.) in any case, what protocol/fragmentation mechanism is used in the NTLP should be invisible to upper layers. cheers, r. > > regards, > Maarten > > > > > > "Georgios Karagiannis" @ietf.org on 05/06/2003 > 13:56:47 > > Sent by: nsis-admin@ietf.org > > > To: "Hancock, Robert" , > cc: > Subject: Re: [NSIS] framework: proposal on fragmentation > > > Hi Robert > > Regarding your proposal (2) - fragmentation in NTLP. > > I will agree with your proposal if it will be posiible to > also switch this > featureoff when needed. > For example, suppose that in a scenario the NTLP will have to > support only > one type of NSLP > that uses small message types. In this situation the NTLP > fragmentation > feature could be switched off, > i.e., not applied at all. > > Best Regards, > Georgios > > > ----- Original Message ----- > From: "Hancock, Robert" > To: > Sent: Thursday, June 05, 2003 12:38 PM > Subject: [NSIS] framework: proposal on fragmentation > > > > dear all, > > > > Since we all seem agreed that bundling should be in the NTLP (and in > fact, > it > > already apparently is), here is the second open issue on > 'transport-like > > functions' and where they should go in the NTLP/NSLP layer model. > > > > This is the question of fragmentation, i.e. where to handle > the fact that > > [NSLP message + NTLP encapsulation] may be bigger than the > MTU on the > path > > to the next NxLP node. > > > > There seem to me to be 3 main options: > > 1. leave it up to the IP layer. > > 2. do it in the NTLP. > > 3. do it (if needed) in the NSLP. > > My proposal is basically (2). Read no further if you agree... > > > > cheers, > > > > robert h. > > > > > ============================================================== > ============= > > Here is the background: > > > > This issue is not handled in 2961 but discussed as a > potential problem > there; > > there is also some analysis in draft-pan-nsis-rsvp-transport-01.txt > (section 2.3). There has been some discussion of this in the > past on this > mailing list, but I > > couldn't really detect an agreed conclusion to it. I have > tried to take > it > into > > account in this summary. > > > > The situation at the moment is that 'most' RSVP messages > are 'small', and > > this only tends not to be so in the case that it is used > over links where > > the MTU can be made large (9k is common for ATM/FR for example). We > expect > that > > this will change in the future - i.e. *some* signalling > applications will > generate > > big messages (as we add more security credentials for > example), and we > don't want > > to restrict the range of link types that can be used. > > > > Reasoning about the choices: > > > > 1. Doing it in the IP layer is conceivable but probably > wouldn't work > well > for > > some awkward reasons, for example... > > a) IP fragmentation doesn't mix well with implicit addressing + the > router > alert > > option (Ping pointed this out at the interim). [I can't > decide if this is > an > > implementation issue or specification issue, but it > certainly seems to be > an > > issue.] > > b) If NSIS messages use flow source addresses (like RSVP), > they would > have > > to make up their own IP-ID/fragmentation headers > independently of the > real > source > > node. This could lead to (theoretical) misassembly errors. > > c) We are trying (hard/a bit) to make NSIS NAT-friendly. > Relying on IP > layer > > fragmentation probably won't make this easier. (If you > demand every NAT > is > at least > > NTLP aware, maybe you are OK.) > > d) IP fragmentation increases the underlying message loss > rate (which > then > has to > > be recovered from). > > > > Maybe none of these are killing issues. > > > > 2. Doing it in the NTLP is a challenge for the NTLP designers... > > a) Only the NTLP knows its encapsulation overhead and so > how to split up > the > > NSLP messages. > > b) The best efficiency would gained from using some sort of > PMTU-d, and I > suspect > > only the NTLP can do this, since it controls IP layer > addressing and sees > the > > ICMP messages involved. It also knows when routes change > and rediscovery > is > > needed. (And PMTU-d would be useful anyway in the NTLP to > do bundling > best.) > > c) Fragmentation could be restricted to the particular NTLP hop that > needs > it > > rather than doing it everywhere. > > > > I think the main objection to doing it in the NTLP is that it's a > function > that > > not many applications/scenarios 'really' need, and we are > overloading the > common > > component for a minority interest. We can't really evaluate > that argument > without > > seeing how difficult it is (currently, I am not convinced > by it). Also, > doing > > fragmentation without the ability to retransmit lost > fragments strikes me > as a bad > > thing, but since the current NTLP proposal has some form of > reliability > in > it > > this isn't relevant. > > > > 3. You can only do it in the NSLP if the NSLP knows what > fragment size to > use. > > As pointed out above, it doesn't, since there may be more > than one NTLP > hop to > > the next NSLP-aware node. (In theory, you could write an > NSIS signalling > > application - which used only small messages! - to discover this > information > > over the path and then use that. This strikes me as a interesting > theoretical > > possibility, but unlikely to lead to good results in practice.) > > _______________________________________________ > > 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 Jun 5 08:18: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 IAA18366 for ; Thu, 5 Jun 2003 08:18:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55CIM829762 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 08:18:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55CIBB29750; Thu, 5 Jun 2003 08:18:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55CHuB29732 for ; Thu, 5 Jun 2003 08:17:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18206 for ; Thu, 5 Jun 2003 08:17:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ntf0-0005aI-00 for nsis@ietf.org; Thu, 05 Jun 2003 08:16:02 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Ntez-0005a5-00 for nsis@ietf.org; Thu, 05 Jun 2003 08:16:01 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h55CHnT3006847; Thu, 5 Jun 2003 14:17:49 +0200 (MEST) 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 LVY3DWCS; Thu, 5 Jun 2003 14:18:41 +0200 Message-ID: <3EDF34E2.E702BA7E@era.ericsson.se> Date: Thu, 05 Jun 2003 14:17:38 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lars.Westberg" X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Hancock, Robert" CC: nsis@ietf.org Subject: Re: [NSIS] framework: proposal on fragmentation 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 Hi! That may be a good default behaviour. However, I think it is neccessary to support the third method as well. I think that can be controlled by an simple primitive to the NTLP-layer. Regards Lasse "Hancock, Robert" wrote: > dear all, > > Since we all seem agreed that bundling should be in the NTLP (and in fact, it > already apparently is), here is the second open issue on 'transport-like > functions' and where they should go in the NTLP/NSLP layer model. > > This is the question of fragmentation, i.e. where to handle the fact that > [NSLP message + NTLP encapsulation] may be bigger than the MTU on the path > to the next NxLP node. > > There seem to me to be 3 main options: > 1. leave it up to the IP layer. > 2. do it in the NTLP. > 3. do it (if needed) in the NSLP. > My proposal is basically (2). Read no further if you agree... > > cheers, > > robert h. > > =========================================================================== > Here is the background: > > This issue is not handled in 2961 but discussed as a potential problem there; > there is also some analysis in draft-pan-nsis-rsvp-transport-01.txt (section 2.3). There has been some discussion of this in the past on this mailing list, but I > couldn't really detect an agreed conclusion to it. I have tried to take it into > account in this summary. > > The situation at the moment is that 'most' RSVP messages are 'small', and > this only tends not to be so in the case that it is used over links where > the MTU can be made large (9k is common for ATM/FR for example). We expect that > this will change in the future - i.e. *some* signalling applications will generate > big messages (as we add more security credentials for example), and we don't want > to restrict the range of link types that can be used. > > Reasoning about the choices: > > 1. Doing it in the IP layer is conceivable but probably wouldn't work well for > some awkward reasons, for example... > a) IP fragmentation doesn't mix well with implicit addressing + the router alert > option (Ping pointed this out at the interim). [I can't decide if this is an > implementation issue or specification issue, but it certainly seems to be an > issue.] > b) If NSIS messages use flow source addresses (like RSVP), they would have > to make up their own IP-ID/fragmentation headers independently of the real source > node. This could lead to (theoretical) misassembly errors. > c) We are trying (hard/a bit) to make NSIS NAT-friendly. Relying on IP layer > fragmentation probably won't make this easier. (If you demand every NAT is at least > NTLP aware, maybe you are OK.) > d) IP fragmentation increases the underlying message loss rate (which then has to > be recovered from). > > Maybe none of these are killing issues. > > 2. Doing it in the NTLP is a challenge for the NTLP designers... > a) Only the NTLP knows its encapsulation overhead and so how to split up the > NSLP messages. > b) The best efficiency would gained from using some sort of PMTU-d, and I suspect > only the NTLP can do this, since it controls IP layer addressing and sees the > ICMP messages involved. It also knows when routes change and rediscovery is > needed. (And PMTU-d would be useful anyway in the NTLP to do bundling best.) > c) Fragmentation could be restricted to the particular NTLP hop that needs it > rather than doing it everywhere. > > I think the main objection to doing it in the NTLP is that it's a function that > not many applications/scenarios 'really' need, and we are overloading the common > component for a minority interest. We can't really evaluate that argument without > seeing how difficult it is (currently, I am not convinced by it). Also, doing > fragmentation without the ability to retransmit lost fragments strikes me as a bad > thing, but since the current NTLP proposal has some form of reliability in it > this isn't relevant. > > 3. You can only do it in the NSLP if the NSLP knows what fragment size to use. > As pointed out above, it doesn't, since there may be more than one NTLP hop to > the next NSLP-aware node. (In theory, you could write an NSIS signalling > application - which used only small messages! - to discover this information > over the path and then use that. This strikes me as a interesting theoretical > possibility, but unlikely to lead to good results in practice.) > _______________________________________________ > 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 Jun 5 08:37: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 IAA20836 for ; Thu, 5 Jun 2003 08:37:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55CbGX32150 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 08:37:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55CbAB31955; Thu, 5 Jun 2003 08:37:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55CapB31759 for ; Thu, 5 Jun 2003 08:36:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20763 for ; Thu, 5 Jun 2003 08:36:48 -0400 (EDT) From: maarten.buchli@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NtxI-00066M-00 for nsis@ietf.org; Thu, 05 Jun 2003 08:34:56 -0400 Received: from alc240.alcatel.be ([195.207.101.240] helo=bt0rjw.god.bel.alcatel.be) by ietf-mx with esmtp (Exim 4.12) id 19NtxI-00065n-00 for nsis@ietf.org; Thu, 05 Jun 2003 08:34:56 -0400 Received: from bemail05.net.alcatel.be (bemail05.net.alcatel.be [138.203.144.16]) by bt0rjw.god.bel.alcatel.be (8.12.9/8.11.4) with ESMTP id h55CaHBK010137; Thu, 5 Jun 2003 14:36:17 +0200 (MEST) Subject: RE: [NSIS] framework: proposal on fragmentation To: "Hancock, Robert" Cc: Georgios Karagiannis , nsis@ietf.org Date: Thu, 5 Jun 2003 14:36:04 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 06/05/2003 14:36:17 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: , My question was mainly related to the fact whether it should be possible to 'switch off' the fragmentation functionality at the NTLP, which was proposed in the mail of Georgios. I am not sure whether this is really needed. Opinions? regards, Maarten "Hancock, Robert" @ietf.org on 05/06/2003 14:11:46 Sent by: nsis-admin@ietf.org To: Maarten BUCHLI/BE/ALCATEL@ALCATEL, Georgios Karagiannis cc: nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation Hi Maarten, > Hi Georgios, Robert, > > I would agree as well on proposal 2, i.e. to locate > the fragmentation into the NTLP. I am not sure > however why there would be a need to be able to > disable that functionality. Do you have a particular > scenario in mind that requires this? no comment! > > Furthermore, would that exlude the use of TCP and > SCTP as a transport protocol? that was not the intention - really the functionality I am talking about is 'handle big messages' and TCP/SCTP are clearly able to do that. (it might not be called 'fragmentation' in those protocols but the function is there.) in any case, what protocol/fragmentation mechanism is used in the NTLP should be invisible to upper layers. cheers, r. > > regards, > Maarten > > > > > > "Georgios Karagiannis" @ietf.org on 05/06/2003 > 13:56:47 > > Sent by: nsis-admin@ietf.org > > > To: "Hancock, Robert" , > cc: > Subject: Re: [NSIS] framework: proposal on fragmentation > > > Hi Robert > > Regarding your proposal (2) - fragmentation in NTLP. > > I will agree with your proposal if it will be posiible to > also switch this > featureoff when needed. > For example, suppose that in a scenario the NTLP will have to > support only > one type of NSLP > that uses small message types. In this situation the NTLP > fragmentation > feature could be switched off, > i.e., not applied at all. > > Best Regards, > Georgios > > > ----- Original Message ----- > From: "Hancock, Robert" > To: > Sent: Thursday, June 05, 2003 12:38 PM > Subject: [NSIS] framework: proposal on fragmentation > > > > dear all, > > > > Since we all seem agreed that bundling should be in the NTLP (and in > fact, > it > > already apparently is), here is the second open issue on > 'transport-like > > functions' and where they should go in the NTLP/NSLP layer model. > > > > This is the question of fragmentation, i.e. where to handle > the fact that > > [NSLP message + NTLP encapsulation] may be bigger than the > MTU on the > path > > to the next NxLP node. > > > > There seem to me to be 3 main options: > > 1. leave it up to the IP layer. > > 2. do it in the NTLP. > > 3. do it (if needed) in the NSLP. > > My proposal is basically (2). Read no further if you agree... > > > > cheers, > > > > robert h. > > > > > ============================================================== > ============= > > Here is the background: > > > > This issue is not handled in 2961 but discussed as a > potential problem > there; > > there is also some analysis in draft-pan-nsis-rsvp-transport-01.txt > (section 2.3). There has been some discussion of this in the > past on this > mailing list, but I > > couldn't really detect an agreed conclusion to it. I have > tried to take > it > into > > account in this summary. > > > > The situation at the moment is that 'most' RSVP messages > are 'small', and > > this only tends not to be so in the case that it is used > over links where > > the MTU can be made large (9k is common for ATM/FR for example). We > expect > that > > this will change in the future - i.e. *some* signalling > applications will > generate > > big messages (as we add more security credentials for > example), and we > don't want > > to restrict the range of link types that can be used. > > > > Reasoning about the choices: > > > > 1. Doing it in the IP layer is conceivable but probably > wouldn't work > well > for > > some awkward reasons, for example... > > a) IP fragmentation doesn't mix well with implicit addressing + the > router > alert > > option (Ping pointed this out at the interim). [I can't > decide if this is > an > > implementation issue or specification issue, but it > certainly seems to be > an > > issue.] > > b) If NSIS messages use flow source addresses (like RSVP), > they would > have > > to make up their own IP-ID/fragmentation headers > independently of the > real > source > > node. This could lead to (theoretical) misassembly errors. > > c) We are trying (hard/a bit) to make NSIS NAT-friendly. > Relying on IP > layer > > fragmentation probably won't make this easier. (If you > demand every NAT > is > at least > > NTLP aware, maybe you are OK.) > > d) IP fragmentation increases the underlying message loss > rate (which > then > has to > > be recovered from). > > > > Maybe none of these are killing issues. > > > > 2. Doing it in the NTLP is a challenge for the NTLP designers... > > a) Only the NTLP knows its encapsulation overhead and so > how to split up > the > > NSLP messages. > > b) The best efficiency would gained from using some sort of > PMTU-d, and I > suspect > > only the NTLP can do this, since it controls IP layer > addressing and sees > the > > ICMP messages involved. It also knows when routes change > and rediscovery > is > > needed. (And PMTU-d would be useful anyway in the NTLP to > do bundling > best.) > > c) Fragmentation could be restricted to the particular NTLP hop that > needs > it > > rather than doing it everywhere. > > > > I think the main objection to doing it in the NTLP is that it's a > function > that > > not many applications/scenarios 'really' need, and we are > overloading the > common > > component for a minority interest. We can't really evaluate > that argument > without > > seeing how difficult it is (currently, I am not convinced > by it). Also, > doing > > fragmentation without the ability to retransmit lost > fragments strikes me > as a bad > > thing, but since the current NTLP proposal has some form of > reliability > in > it > > this isn't relevant. > > > > 3. You can only do it in the NSLP if the NSLP knows what > fragment size to > use. > > As pointed out above, it doesn't, since there may be more > than one NTLP > hop to > > the next NSLP-aware node. (In theory, you could write an > NSIS signalling > > application - which used only small messages! - to discover this > information > > over the path and then use that. This strikes me as a interesting > theoretical > > possibility, but unlikely to lead to good results in practice.) > > _______________________________________________ > > 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 Thu Jun 5 09:41: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 JAA24803 for ; Thu, 5 Jun 2003 09:41:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55Dele05189 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 09:40:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55DeTB05164; Thu, 5 Jun 2003 09:40:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55DddB05103 for ; Thu, 5 Jun 2003 09:39:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24722 for ; Thu, 5 Jun 2003 09:39:35 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nuw3-0006vL-00 for nsis@ietf.org; Thu, 05 Jun 2003 09:37:43 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19Nuw2-0006vI-00 for nsis@ietf.org; Thu, 05 Jun 2003 09:37:42 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h55DdYW28883 for ; Thu, 5 Jun 2003 16:39:34 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 5 Jun 2003 16:39:30 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 5 Jun 2003 16:39:30 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 5 Jun 2003 16:39:29 +0300 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] framework: proposal on fragmentation Date: Thu, 5 Jun 2003 16:39:29 +0300 Message-ID: Thread-Topic: [NSIS] framework: proposal on fragmentation Thread-Index: AcMrYgNH+aA1WSqJQGGFK0nKKDsxvwABcALA To: , Cc: , X-OriginalArrivalTime: 05 Jun 2003 13:39:29.0785 (UTC) FILETIME=[E3AC4690:01C32B67] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h55DdhB05105 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 Maarten, I don't see the reason for being able to shut-off the fragmentation either. Some examples would be nice. John > -----Original Message----- > From: ext maarten.buchli@alcatel.be [mailto:maarten.buchli@alcatel.be] > Sent: 05 June, 2003 15:36 > To: Hancock, Robert > Cc: Georgios Karagiannis; nsis@ietf.org > Subject: RE: [NSIS] framework: proposal on fragmentation > > > My question was mainly related to the fact whether it should be > possible to 'switch off' the fragmentation functionality at the NTLP, > which was proposed in the mail of Georgios. I am not sure whether > this is really needed. > Opinions? > > regards, > Maarten > > > > > > "Hancock, Robert" @ietf.org on 05/06/2003 > 14:11:46 > > Sent by: nsis-admin@ietf.org > > > To: Maarten BUCHLI/BE/ALCATEL@ALCATEL, Georgios Karagiannis > > cc: nsis@ietf.org > Subject: RE: [NSIS] framework: proposal on fragmentation > > > Hi Maarten, > > > Hi Georgios, Robert, > > > > I would agree as well on proposal 2, i.e. to locate > > the fragmentation into the NTLP. I am not sure > > however why there would be a need to be able to > > disable that functionality. Do you have a particular > > scenario in mind that requires this? > > no comment! > > > > > Furthermore, would that exlude the use of TCP and > > SCTP as a transport protocol? > > that was not the intention - really the functionality I am > talking about > is 'handle big messages' and TCP/SCTP are clearly able to do that. (it > might > not be called 'fragmentation' in those protocols but the function is > there.) > in any case, what protocol/fragmentation mechanism is used in the NTLP > should > be invisible to upper layers. > > cheers, > > r. > > > > > regards, > > Maarten > > > > > > > > > > > > "Georgios Karagiannis" @ietf.org on > 05/06/2003 > > 13:56:47 > > > > Sent by: nsis-admin@ietf.org > > > > > > To: "Hancock, Robert" , > > > cc: > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > Hi Robert > > > > Regarding your proposal (2) - fragmentation in NTLP. > > > > I will agree with your proposal if it will be posiible to > > also switch this > > featureoff when needed. > > For example, suppose that in a scenario the NTLP will have to > > support only > > one type of NSLP > > that uses small message types. In this situation the NTLP > > fragmentation > > feature could be switched off, > > i.e., not applied at all. > > > > Best Regards, > > Georgios > > > > > > ----- Original Message ----- > > From: "Hancock, Robert" > > To: > > Sent: Thursday, June 05, 2003 12:38 PM > > Subject: [NSIS] framework: proposal on fragmentation > > > > > > > dear all, > > > > > > Since we all seem agreed that bundling should be in the > NTLP (and in > > fact, > > it > > > already apparently is), here is the second open issue on > > 'transport-like > > > functions' and where they should go in the NTLP/NSLP layer model. > > > > > > This is the question of fragmentation, i.e. where to handle > > the fact that > > > [NSLP message + NTLP encapsulation] may be bigger than the > > MTU on the > > path > > > to the next NxLP node. > > > > > > There seem to me to be 3 main options: > > > 1. leave it up to the IP layer. > > > 2. do it in the NTLP. > > > 3. do it (if needed) in the NSLP. > > > My proposal is basically (2). Read no further if you agree... > > > > > > cheers, > > > > > > robert h. > > > > > > > > ============================================================== > > ============= > > > Here is the background: > > > > > > This issue is not handled in 2961 but discussed as a > > potential problem > > there; > > > there is also some analysis in > draft-pan-nsis-rsvp-transport-01.txt > > (section 2.3). There has been some discussion of this in the > > past on this > > mailing list, but I > > > couldn't really detect an agreed conclusion to it. I have > > tried to take > > it > > into > > > account in this summary. > > > > > > The situation at the moment is that 'most' RSVP messages > > are 'small', and > > > this only tends not to be so in the case that it is used > > over links where > > > the MTU can be made large (9k is common for ATM/FR for > example). We > > expect > > that > > > this will change in the future - i.e. *some* signalling > > applications will > > generate > > > big messages (as we add more security credentials for > > example), and we > > don't want > > > to restrict the range of link types that can be used. > > > > > > Reasoning about the choices: > > > > > > 1. Doing it in the IP layer is conceivable but probably > > wouldn't work > > well > > for > > > some awkward reasons, for example... > > > a) IP fragmentation doesn't mix well with implicit > addressing + the > > router > > alert > > > option (Ping pointed this out at the interim). [I can't > > decide if this is > > an > > > implementation issue or specification issue, but it > > certainly seems to be > > an > > > issue.] > > > b) If NSIS messages use flow source addresses (like RSVP), > > they would > > have > > > to make up their own IP-ID/fragmentation headers > > independently of the > > real > > source > > > node. This could lead to (theoretical) misassembly errors. > > > c) We are trying (hard/a bit) to make NSIS NAT-friendly. > > Relying on IP > > layer > > > fragmentation probably won't make this easier. (If you > > demand every NAT > > is > > at least > > > NTLP aware, maybe you are OK.) > > > d) IP fragmentation increases the underlying message loss > > rate (which > > then > > has to > > > be recovered from). > > > > > > Maybe none of these are killing issues. > > > > > > 2. Doing it in the NTLP is a challenge for the NTLP designers... > > > a) Only the NTLP knows its encapsulation overhead and so > > how to split up > > the > > > NSLP messages. > > > b) The best efficiency would gained from using some sort of > > PMTU-d, and I > > suspect > > > only the NTLP can do this, since it controls IP layer > > addressing and sees > > the > > > ICMP messages involved. It also knows when routes change > > and rediscovery > > is > > > needed. (And PMTU-d would be useful anyway in the NTLP to > > do bundling > > best.) > > > c) Fragmentation could be restricted to the particular > NTLP hop that > > needs > > it > > > rather than doing it everywhere. > > > > > > I think the main objection to doing it in the NTLP is that it's a > > function > > that > > > not many applications/scenarios 'really' need, and we are > > overloading the > > common > > > component for a minority interest. We can't really evaluate > > that argument > > without > > > seeing how difficult it is (currently, I am not convinced > > by it). Also, > > doing > > > fragmentation without the ability to retransmit lost > > fragments strikes me > > as a bad > > > thing, but since the current NTLP proposal has some form of > > reliability > > in > > it > > > this isn't relevant. > > > > > > 3. You can only do it in the NSLP if the NSLP knows what > > fragment size to > > use. > > > As pointed out above, it doesn't, since there may be more > > than one NTLP > > hop to > > > the next NSLP-aware node. (In theory, you could write an > > NSIS signalling > > > application - which used only small messages! - to discover this > > information > > > over the path and then use that. This strikes me as a interesting > > theoretical > > > possibility, but unlikely to lead to good results in practice.) > > > _______________________________________________ > > > 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 Thu Jun 5 09:43: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 JAA25235 for ; Thu, 5 Jun 2003 09:43:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55DhOS05364 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 09:43:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55Dh6B05330; Thu, 5 Jun 2003 09:43:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55DgKB05257 for ; Thu, 5 Jun 2003 09:42:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24849 for ; Thu, 5 Jun 2003 09:42:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nuye-0006x0-00 for nsis@ietf.org; Thu, 05 Jun 2003 09:40:24 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by ietf-mx with esmtp (Exim 4.12) id 19Nuyd-0006wm-00 for nsis@ietf.org; Thu, 05 Jun 2003 09:40:23 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h55DfdI2014108; Thu, 5 Jun 2003 06:41:39 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIA42523; Thu, 5 Jun 2003 06:41:38 -0700 (PDT) Message-Id: <200306051341.AIA42523@mira-sjc5-c.cisco.com> To: "Hancock, Robert" cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] framework: proposal on fragmentation In-Reply-To: Message from robert.hancock@roke.co.uk of "Thu, 05 Jun 2003 11:38:19 BST." Date: Thu, 05 Jun 2003 09:41:38 -0400 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'd really like to see optional (probably optional-to- use, mandatory-to-implement) support for fragmentation, and I think it's pretty clear that the only reasonable place to put it is in the NTLP. I don't think it's healthy to be inflexible about layer separation but this is a case in which it would be a lot messier to do it anywhere but in the NTLP, because it's the NTLP that "knows" what the actual packet sizes are. (Note also that relying on IP layer fragmentation can cause NAT failures). I'm very much in agreement. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 5 09:58: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 JAA25825 for ; Thu, 5 Jun 2003 09:58:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55DwIh05987 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 09:58:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55DwBB05977; Thu, 5 Jun 2003 09:58:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55DvOB05944 for ; Thu, 5 Jun 2003 09:57:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25785 for ; Thu, 5 Jun 2003 09:57:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NvDE-00078W-00 for nsis@ietf.org; Thu, 05 Jun 2003 09:55:28 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19NvDD-00078T-00 for nsis@ietf.org; Thu, 05 Jun 2003 09:55:27 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h55Dv15s006496; Thu, 5 Jun 2003 15:57:01 +0200 (MET DST) Message-ID: <006601c32b6a$57ae14e0$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: , Cc: References: Subject: Re: [NSIS] framework: proposal on fragmentation Date: Thu, 5 Jun 2003 15:56:55 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 John and Maarten First of all if a message is fragmented has to be reassembled somewhere. The NTLP will have to find out where the fragmentation and the reassembly process has to be accomplished. This will require additional processing, even if this it is not needed. In scenarios where performance in terms of processing delays, number of states per flow, etc., is important, it should be possible that the fragmentation at NTLP layer should be switched off and either assure that the NSLP messages are small enough such that they will not be fragmented or do it in the NSLP if required. Best Regards, Georgios ----- Original Message ----- From: To: ; Cc: ; Sent: Thursday, June 05, 2003 3:39 PM Subject: RE: [NSIS] framework: proposal on fragmentation > Hi Maarten, > > I don't see the reason for being able to shut-off the fragmentation > either. Some examples would be nice. > > John > > > -----Original Message----- > > From: ext maarten.buchli@alcatel.be [mailto:maarten.buchli@alcatel.be] > > Sent: 05 June, 2003 15:36 > > To: Hancock, Robert > > Cc: Georgios Karagiannis; nsis@ietf.org > > Subject: RE: [NSIS] framework: proposal on fragmentation > > > > > > My question was mainly related to the fact whether it should be > > possible to 'switch off' the fragmentation functionality at the NTLP, > > which was proposed in the mail of Georgios. I am not sure whether > > this is really needed. > > Opinions? > > > > regards, > > Maarten > > > > > > > > > > > > "Hancock, Robert" @ietf.org on 05/06/2003 > > 14:11:46 > > > > Sent by: nsis-admin@ietf.org > > > > > > To: Maarten BUCHLI/BE/ALCATEL@ALCATEL, Georgios Karagiannis > > > > cc: nsis@ietf.org > > Subject: RE: [NSIS] framework: proposal on fragmentation > > > > > > Hi Maarten, > > > > > Hi Georgios, Robert, > > > > > > I would agree as well on proposal 2, i.e. to locate > > > the fragmentation into the NTLP. I am not sure > > > however why there would be a need to be able to > > > disable that functionality. Do you have a particular > > > scenario in mind that requires this? > > > > no comment! > > > > > > > > Furthermore, would that exlude the use of TCP and > > > SCTP as a transport protocol? > > > > that was not the intention - really the functionality I am > > talking about > > is 'handle big messages' and TCP/SCTP are clearly able to do that. (it > > might > > not be called 'fragmentation' in those protocols but the function is > > there.) > > in any case, what protocol/fragmentation mechanism is used in the NTLP > > should > > be invisible to upper layers. > > > > cheers, > > > > r. > > > > > > > > regards, > > > Maarten > > > > > > > > > > > > > > > > > > "Georgios Karagiannis" @ietf.org on > > 05/06/2003 > > > 13:56:47 > > > > > > Sent by: nsis-admin@ietf.org > > > > > > > > > To: "Hancock, Robert" , > > > > > cc: > > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > > > > Hi Robert > > > > > > Regarding your proposal (2) - fragmentation in NTLP. > > > > > > I will agree with your proposal if it will be posiible to > > > also switch this > > > featureoff when needed. > > > For example, suppose that in a scenario the NTLP will have to > > > support only > > > one type of NSLP > > > that uses small message types. In this situation the NTLP > > > fragmentation > > > feature could be switched off, > > > i.e., not applied at all. > > > > > > Best Regards, > > > Georgios > > > > > > > > > ----- Original Message ----- > > > From: "Hancock, Robert" > > > To: > > > Sent: Thursday, June 05, 2003 12:38 PM > > > Subject: [NSIS] framework: proposal on fragmentation > > > > > > > > > > dear all, > > > > > > > > Since we all seem agreed that bundling should be in the > > NTLP (and in > > > fact, > > > it > > > > already apparently is), here is the second open issue on > > > 'transport-like > > > > functions' and where they should go in the NTLP/NSLP layer model. > > > > > > > > This is the question of fragmentation, i.e. where to handle > > > the fact that > > > > [NSLP message + NTLP encapsulation] may be bigger than the > > > MTU on the > > > path > > > > to the next NxLP node. > > > > > > > > There seem to me to be 3 main options: > > > > 1. leave it up to the IP layer. > > > > 2. do it in the NTLP. > > > > 3. do it (if needed) in the NSLP. > > > > My proposal is basically (2). Read no further if you agree... > > > > > > > > cheers, > > > > > > > > robert h. > > > > > > > > > > > ============================================================== > > > ============= > > > > Here is the background: > > > > > > > > This issue is not handled in 2961 but discussed as a > > > potential problem > > > there; > > > > there is also some analysis in > > draft-pan-nsis-rsvp-transport-01.txt > > > (section 2.3). There has been some discussion of this in the > > > past on this > > > mailing list, but I > > > > couldn't really detect an agreed conclusion to it. I have > > > tried to take > > > it > > > into > > > > account in this summary. > > > > > > > > The situation at the moment is that 'most' RSVP messages > > > are 'small', and > > > > this only tends not to be so in the case that it is used > > > over links where > > > > the MTU can be made large (9k is common for ATM/FR for > > example). We > > > expect > > > that > > > > this will change in the future - i.e. *some* signalling > > > applications will > > > generate > > > > big messages (as we add more security credentials for > > > example), and we > > > don't want > > > > to restrict the range of link types that can be used. > > > > > > > > Reasoning about the choices: > > > > > > > > 1. Doing it in the IP layer is conceivable but probably > > > wouldn't work > > > well > > > for > > > > some awkward reasons, for example... > > > > a) IP fragmentation doesn't mix well with implicit > > addressing + the > > > router > > > alert > > > > option (Ping pointed this out at the interim). [I can't > > > decide if this is > > > an > > > > implementation issue or specification issue, but it > > > certainly seems to be > > > an > > > > issue.] > > > > b) If NSIS messages use flow source addresses (like RSVP), > > > they would > > > have > > > > to make up their own IP-ID/fragmentation headers > > > independently of the > > > real > > > source > > > > node. This could lead to (theoretical) misassembly errors. > > > > c) We are trying (hard/a bit) to make NSIS NAT-friendly. > > > Relying on IP > > > layer > > > > fragmentation probably won't make this easier. (If you > > > demand every NAT > > > is > > > at least > > > > NTLP aware, maybe you are OK.) > > > > d) IP fragmentation increases the underlying message loss > > > rate (which > > > then > > > has to > > > > be recovered from). > > > > > > > > Maybe none of these are killing issues. > > > > > > > > 2. Doing it in the NTLP is a challenge for the NTLP designers... > > > > a) Only the NTLP knows its encapsulation overhead and so > > > how to split up > > > the > > > > NSLP messages. > > > > b) The best efficiency would gained from using some sort of > > > PMTU-d, and I > > > suspect > > > > only the NTLP can do this, since it controls IP layer > > > addressing and sees > > > the > > > > ICMP messages involved. It also knows when routes change > > > and rediscovery > > > is > > > > needed. (And PMTU-d would be useful anyway in the NTLP to > > > do bundling > > > best.) > > > > c) Fragmentation could be restricted to the particular > > NTLP hop that > > > needs > > > it > > > > rather than doing it everywhere. > > > > > > > > I think the main objection to doing it in the NTLP is that it's a > > > function > > > that > > > > not many applications/scenarios 'really' need, and we are > > > overloading the > > > common > > > > component for a minority interest. We can't really evaluate > > > that argument > > > without > > > > seeing how difficult it is (currently, I am not convinced > > > by it). Also, > > > doing > > > > fragmentation without the ability to retransmit lost > > > fragments strikes me > > > as a bad > > > > thing, but since the current NTLP proposal has some form of > > > reliability > > > in > > > it > > > > this isn't relevant. > > > > > > > > 3. You can only do it in the NSLP if the NSLP knows what > > > fragment size to > > > use. > > > > As pointed out above, it doesn't, since there may be more > > > than one NTLP > > > hop to > > > > the next NSLP-aware node. (In theory, you could write an > > > NSIS signalling > > > > application - which used only small messages! - to discover this > > > information > > > > over the path and then use that. This strikes me as a interesting > > > theoretical > > > > possibility, but unlikely to lead to good results in practice.) > > > > _______________________________________________ > > > > 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 Thu Jun 5 10:08: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 KAA26755 for ; Thu, 5 Jun 2003 10:08:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55E8M707399 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 10:08:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55E8CB07387; Thu, 5 Jun 2003 10:08:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55E7jB07355 for ; Thu, 5 Jun 2003 10:07:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26628 for ; Thu, 5 Jun 2003 10:07:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NvNE-0007EU-00 for nsis@ietf.org; Thu, 05 Jun 2003 10:05:48 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19NvND-0007EN-00 for nsis@ietf.org; Thu, 05 Jun 2003 10:05:48 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jun 2003 15:07:38 +0100 Message-ID: From: "Hancock, Robert" To: "'Georgios Karagiannis'" , john.loughney@nokia.com, maarten.buchli@alcatel.be Cc: nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation Date: Thu, 5 Jun 2003 15:07:35 +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: , Georgios, I don't really follow the argument. if an NSLP generates a small message, it won't need to be fragmented anywhere. what is the cost? if it generates a big message, why is it easier to do it at the upper layer. [In other words, I agree with Dan's email, just received.] I think the only cost here is implementation effort in the NTLP - but it should be possible to implement fragmentation support so if it isn't needed it has (effectively) no performance impact. And in fact, the implementation effort to provide the feature might be less than what's needed to handle the resultant error cases properly... robert h. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 05 June 2003 14:57 > To: john.loughney@nokia.com; maarten.buchli@alcatel.be > Cc: nsis@ietf.org > Subject: Re: [NSIS] framework: proposal on fragmentation > > > Hi John and Maarten > > First of all if a message is fragmented has to be reassembled > somewhere. > The NTLP will have to find out where the fragmentation and > the reassembly > process has to be > accomplished. This will require additional processing, even > if this it is > not needed. > In scenarios where performance in terms of processing delays, > number of > states per flow, etc., > is important, it should be possible that the fragmentation at > NTLP layer > should be switched off and > either assure that the NSLP messages are small enough such > that they will > not be fragmented > or do it in the NSLP if required. > > Best Regards, > Georgios > > > > ----- Original Message ----- > From: > To: ; > Cc: ; > Sent: Thursday, June 05, 2003 3:39 PM > Subject: RE: [NSIS] framework: proposal on fragmentation > > > > Hi Maarten, > > > > I don't see the reason for being able to shut-off the fragmentation > > either. Some examples would be nice. > > > > John > > > > > -----Original Message----- > > > From: ext maarten.buchli@alcatel.be > [mailto:maarten.buchli@alcatel.be] > > > Sent: 05 June, 2003 15:36 > > > To: Hancock, Robert > > > Cc: Georgios Karagiannis; nsis@ietf.org > > > Subject: RE: [NSIS] framework: proposal on fragmentation > > > > > > > > > My question was mainly related to the fact whether it should be > > > possible to 'switch off' the fragmentation functionality > at the NTLP, > > > which was proposed in the mail of Georgios. I am not sure whether > > > this is really needed. > > > Opinions? > > > > > > regards, > > > Maarten > > > > > > > > > > > > > > > > > > "Hancock, Robert" @ietf.org on > 05/06/2003 > > > 14:11:46 > > > > > > Sent by: nsis-admin@ietf.org > > > > > > > > > To: Maarten BUCHLI/BE/ALCATEL@ALCATEL, Georgios Karagiannis > > > > > > cc: nsis@ietf.org > > > Subject: RE: [NSIS] framework: proposal on fragmentation > > > > > > > > > Hi Maarten, > > > > > > > Hi Georgios, Robert, > > > > > > > > I would agree as well on proposal 2, i.e. to locate > > > > the fragmentation into the NTLP. I am not sure > > > > however why there would be a need to be able to > > > > disable that functionality. Do you have a particular > > > > scenario in mind that requires this? > > > > > > no comment! > > > > > > > > > > > Furthermore, would that exlude the use of TCP and > > > > SCTP as a transport protocol? > > > > > > that was not the intention - really the functionality I am > > > talking about > > > is 'handle big messages' and TCP/SCTP are clearly able to > do that. (it > > > might > > > not be called 'fragmentation' in those protocols but the > function is > > > there.) > > > in any case, what protocol/fragmentation mechanism is > used in the NTLP > > > should > > > be invisible to upper layers. > > > > > > cheers, > > > > > > r. > > > > > > > > > > > regards, > > > > Maarten > > > > > > > > > > > > > > > > > > > > > > > > "Georgios Karagiannis" @ietf.org on > > > 05/06/2003 > > > > 13:56:47 > > > > > > > > Sent by: nsis-admin@ietf.org > > > > > > > > > > > > To: "Hancock, Robert" , > > > > > > > cc: > > > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > > > > > > > Hi Robert > > > > > > > > Regarding your proposal (2) - fragmentation in NTLP. > > > > > > > > I will agree with your proposal if it will be posiible to > > > > also switch this > > > > featureoff when needed. > > > > For example, suppose that in a scenario the NTLP will have to > > > > support only > > > > one type of NSLP > > > > that uses small message types. In this situation the NTLP > > > > fragmentation > > > > feature could be switched off, > > > > i.e., not applied at all. > > > > > > > > Best Regards, > > > > Georgios > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Hancock, Robert" > > > > To: > > > > Sent: Thursday, June 05, 2003 12:38 PM > > > > Subject: [NSIS] framework: proposal on fragmentation > > > > > > > > > > > > > dear all, > > > > > > > > > > Since we all seem agreed that bundling should be in the > > > NTLP (and in > > > > fact, > > > > it > > > > > already apparently is), here is the second open issue on > > > > 'transport-like > > > > > functions' and where they should go in the NTLP/NSLP > layer model. > > > > > > > > > > This is the question of fragmentation, i.e. where to handle > > > > the fact that > > > > > [NSLP message + NTLP encapsulation] may be bigger than the > > > > MTU on the > > > > path > > > > > to the next NxLP node. > > > > > > > > > > There seem to me to be 3 main options: > > > > > 1. leave it up to the IP layer. > > > > > 2. do it in the NTLP. > > > > > 3. do it (if needed) in the NSLP. > > > > > My proposal is basically (2). Read no further if you agree... > > > > > > > > > > cheers, > > > > > > > > > > robert h. > > > > > > > > > > > > > > ============================================================== > > > > ============= > > > > > Here is the background: > > > > > > > > > > This issue is not handled in 2961 but discussed as a > > > > potential problem > > > > there; > > > > > there is also some analysis in > > > draft-pan-nsis-rsvp-transport-01.txt > > > > (section 2.3). There has been some discussion of this in the > > > > past on this > > > > mailing list, but I > > > > > couldn't really detect an agreed conclusion to it. I have > > > > tried to take > > > > it > > > > into > > > > > account in this summary. > > > > > > > > > > The situation at the moment is that 'most' RSVP messages > > > > are 'small', and > > > > > this only tends not to be so in the case that it is used > > > > over links where > > > > > the MTU can be made large (9k is common for ATM/FR for > > > example). We > > > > expect > > > > that > > > > > this will change in the future - i.e. *some* signalling > > > > applications will > > > > generate > > > > > big messages (as we add more security credentials for > > > > example), and we > > > > don't want > > > > > to restrict the range of link types that can be used. > > > > > > > > > > Reasoning about the choices: > > > > > > > > > > 1. Doing it in the IP layer is conceivable but probably > > > > wouldn't work > > > > well > > > > for > > > > > some awkward reasons, for example... > > > > > a) IP fragmentation doesn't mix well with implicit > > > addressing + the > > > > router > > > > alert > > > > > option (Ping pointed this out at the interim). [I can't > > > > decide if this is > > > > an > > > > > implementation issue or specification issue, but it > > > > certainly seems to be > > > > an > > > > > issue.] > > > > > b) If NSIS messages use flow source addresses (like RSVP), > > > > they would > > > > have > > > > > to make up their own IP-ID/fragmentation headers > > > > independently of the > > > > real > > > > source > > > > > node. This could lead to (theoretical) misassembly errors. > > > > > c) We are trying (hard/a bit) to make NSIS NAT-friendly. > > > > Relying on IP > > > > layer > > > > > fragmentation probably won't make this easier. (If you > > > > demand every NAT > > > > is > > > > at least > > > > > NTLP aware, maybe you are OK.) > > > > > d) IP fragmentation increases the underlying message loss > > > > rate (which > > > > then > > > > has to > > > > > be recovered from). > > > > > > > > > > Maybe none of these are killing issues. > > > > > > > > > > 2. Doing it in the NTLP is a challenge for the NTLP > designers... > > > > > a) Only the NTLP knows its encapsulation overhead and so > > > > how to split up > > > > the > > > > > NSLP messages. > > > > > b) The best efficiency would gained from using some sort of > > > > PMTU-d, and I > > > > suspect > > > > > only the NTLP can do this, since it controls IP layer > > > > addressing and sees > > > > the > > > > > ICMP messages involved. It also knows when routes change > > > > and rediscovery > > > > is > > > > > needed. (And PMTU-d would be useful anyway in the NTLP to > > > > do bundling > > > > best.) > > > > > c) Fragmentation could be restricted to the particular > > > NTLP hop that > > > > needs > > > > it > > > > > rather than doing it everywhere. > > > > > > > > > > I think the main objection to doing it in the NTLP is > that it's a > > > > function > > > > that > > > > > not many applications/scenarios 'really' need, and we are > > > > overloading the > > > > common > > > > > component for a minority interest. We can't really evaluate > > > > that argument > > > > without > > > > > seeing how difficult it is (currently, I am not convinced > > > > by it). Also, > > > > doing > > > > > fragmentation without the ability to retransmit lost > > > > fragments strikes me > > > > as a bad > > > > > thing, but since the current NTLP proposal has some form of > > > > reliability > > > > in > > > > it > > > > > this isn't relevant. > > > > > > > > > > 3. You can only do it in the NSLP if the NSLP knows what > > > > fragment size to > > > > use. > > > > > As pointed out above, it doesn't, since there may be more > > > > than one NTLP > > > > hop to > > > > > the next NSLP-aware node. (In theory, you could write an > > > > NSIS signalling > > > > > application - which used only small messages! - to > discover this > > > > information > > > > > over the path and then use that. This strikes me as a > interesting > > > > theoretical > > > > > possibility, but unlikely to lead to good results in > practice.) > > > > > _______________________________________________ > > > > > 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 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 5 10:08: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 KAA26772 for ; Thu, 5 Jun 2003 10:08:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55E8N207415 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 10:08:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55E8AB07370; Thu, 5 Jun 2003 10:08:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55E7bB07170 for ; Thu, 5 Jun 2003 10:07:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26610 for ; Thu, 5 Jun 2003 10:07:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NvN6-0007EI-00 for nsis@ietf.org; Thu, 05 Jun 2003 10:05:40 -0400 Received: from h3s128a211n47.user.nortelnetworks.com ([47.211.128.3] helo=znsgs01r.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19NvN5-0007Ds-00 for nsis@ietf.org; Thu, 05 Jun 2003 10:05:39 -0400 Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h55E5Y505842; Thu, 5 Jun 2003 15:05:37 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jun 2003 15:05:20 +0100 Message-ID: From: "Daniel Warren" To: "'maarten.buchli@alcatel.be'" , "Hancock, Robert" Cc: Georgios Karagiannis , nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation Date: Thu, 5 Jun 2003 15:05:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32B6B.7DE87B0E" 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_01C32B6B.7DE87B0E Content-Type: text/plain; charset="iso-8859-1" From Georgios's mail... 'I will agree with your proposal if it will be posiible to also switch this feature off when needed. For example, suppose that in a scenario the NTLP will have to support only one type of NSLP that uses small message types. In this situation the NTLP fragmentation feature could be switched off' Is it just me or is the ability to 'switch fragmentation off' a bit of a spurreous debate? If a NSLP message plus NTLP 'stuff' is smaller than the MTU, then you don't fragment it, if it's bigger you do. Thats not switching it off so much as having it on but not needing to apply it. I guess it all depends how small the 'small message types' are... Dan -----Original Message----- From: maarten.buchli@alcatel.be [mailto:maarten.buchli@alcatel.be] Sent: 05 June 2003 13:36 To: Hancock, Robert Cc: Georgios Karagiannis; nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation My question was mainly related to the fact whether it should be possible to 'switch off' the fragmentation functionality at the NTLP, which was proposed in the mail of Georgios. I am not sure whether this is really needed. Opinions? regards, Maarten "Hancock, Robert" @ietf.org on 05/06/2003 14:11:46 Sent by: nsis-admin@ietf.org To: Maarten BUCHLI/BE/ALCATEL@ALCATEL, Georgios Karagiannis cc: nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation Hi Maarten, > Hi Georgios, Robert, > > I would agree as well on proposal 2, i.e. to locate > the fragmentation into the NTLP. I am not sure > however why there would be a need to be able to > disable that functionality. Do you have a particular > scenario in mind that requires this? no comment! > > Furthermore, would that exlude the use of TCP and > SCTP as a transport protocol? that was not the intention - really the functionality I am talking about is 'handle big messages' and TCP/SCTP are clearly able to do that. (it might not be called 'fragmentation' in those protocols but the function is there.) in any case, what protocol/fragmentation mechanism is used in the NTLP should be invisible to upper layers. cheers, r. > > regards, > Maarten > > > > > > "Georgios Karagiannis" @ietf.org on 05/06/2003 > 13:56:47 > > Sent by: nsis-admin@ietf.org > > > To: "Hancock, Robert" , > cc: > Subject: Re: [NSIS] framework: proposal on fragmentation > > > Hi Robert > > Regarding your proposal (2) - fragmentation in NTLP. > > I will agree with your proposal if it will be posiible to > also switch this > featureoff when needed. > For example, suppose that in a scenario the NTLP will have to > support only > one type of NSLP > that uses small message types. In this situation the NTLP > fragmentation > feature could be switched off, > i.e., not applied at all. > > Best Regards, > Georgios > > > ----- Original Message ----- > From: "Hancock, Robert" > To: > Sent: Thursday, June 05, 2003 12:38 PM > Subject: [NSIS] framework: proposal on fragmentation > > > > dear all, > > > > Since we all seem agreed that bundling should be in the NTLP (and in > fact, > it > > already apparently is), here is the second open issue on > 'transport-like > > functions' and where they should go in the NTLP/NSLP layer model. > > > > This is the question of fragmentation, i.e. where to handle > the fact that > > [NSLP message + NTLP encapsulation] may be bigger than the > MTU on the > path > > to the next NxLP node. > > > > There seem to me to be 3 main options: > > 1. leave it up to the IP layer. > > 2. do it in the NTLP. > > 3. do it (if needed) in the NSLP. > > My proposal is basically (2). Read no further if you agree... > > > > cheers, > > > > robert h. > > > > > ============================================================== > ============= > > Here is the background: > > > > This issue is not handled in 2961 but discussed as a > potential problem > there; > > there is also some analysis in draft-pan-nsis-rsvp-transport-01.txt > (section 2.3). There has been some discussion of this in the > past on this > mailing list, but I > > couldn't really detect an agreed conclusion to it. I have > tried to take > it > into > > account in this summary. > > > > The situation at the moment is that 'most' RSVP messages > are 'small', and > > this only tends not to be so in the case that it is used > over links where > > the MTU can be made large (9k is common for ATM/FR for example). We > expect > that > > this will change in the future - i.e. *some* signalling > applications will > generate > > big messages (as we add more security credentials for > example), and we > don't want > > to restrict the range of link types that can be used. > > > > Reasoning about the choices: > > > > 1. Doing it in the IP layer is conceivable but probably > wouldn't work > well > for > > some awkward reasons, for example... > > a) IP fragmentation doesn't mix well with implicit addressing + the > router > alert > > option (Ping pointed this out at the interim). [I can't > decide if this is > an > > implementation issue or specification issue, but it > certainly seems to be > an > > issue.] > > b) If NSIS messages use flow source addresses (like RSVP), > they would > have > > to make up their own IP-ID/fragmentation headers > independently of the > real > source > > node. This could lead to (theoretical) misassembly errors. > > c) We are trying (hard/a bit) to make NSIS NAT-friendly. > Relying on IP > layer > > fragmentation probably won't make this easier. (If you > demand every NAT > is > at least > > NTLP aware, maybe you are OK.) > > d) IP fragmentation increases the underlying message loss > rate (which > then > has to > > be recovered from). > > > > Maybe none of these are killing issues. > > > > 2. Doing it in the NTLP is a challenge for the NTLP designers... > > a) Only the NTLP knows its encapsulation overhead and so > how to split up > the > > NSLP messages. > > b) The best efficiency would gained from using some sort of > PMTU-d, and I > suspect > > only the NTLP can do this, since it controls IP layer > addressing and sees > the > > ICMP messages involved. It also knows when routes change > and rediscovery > is > > needed. (And PMTU-d would be useful anyway in the NTLP to > do bundling > best.) > > c) Fragmentation could be restricted to the particular NTLP hop that > needs > it > > rather than doing it everywhere. > > > > I think the main objection to doing it in the NTLP is that it's a > function > that > > not many applications/scenarios 'really' need, and we are > overloading the > common > > component for a minority interest. We can't really evaluate > that argument > without > > seeing how difficult it is (currently, I am not convinced > by it). Also, > doing > > fragmentation without the ability to retransmit lost > fragments strikes me > as a bad > > thing, but since the current NTLP proposal has some form of > reliability > in > it > > this isn't relevant. > > > > 3. You can only do it in the NSLP if the NSLP knows what > fragment size to > use. > > As pointed out above, it doesn't, since there may be more > than one NTLP > hop to > > the next NSLP-aware node. (In theory, you could write an > NSIS signalling > > application - which used only small messages! - to discover this > information > > over the path and then use that. This strikes me as a interesting > theoretical > > possibility, but unlikely to lead to good results in practice.) > > _______________________________________________ > > 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 ------_=_NextPart_001_01C32B6B.7DE87B0E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] framework: proposal on fragmentation

From Georgios's mail...

'I will agree with your proposal if it will be = posiible to also switch this feature off when needed.  For = example, suppose that in a scenario the NTLP will have to support only = one type of NSLP that uses small message types. In this situation the = NTLP fragmentation feature could be switched off'

Is it just me or is the ability to 'switch = fragmentation off' a bit of a spurreous debate?  If a NSLP message = plus NTLP 'stuff' is smaller than the MTU, then you don't fragment it, = if it's bigger you do.  Thats not switching it off so much as = having it on but not needing to apply it.   I guess it all = depends how small the 'small message types' are...

Dan

-----Original Message-----
From: maarten.buchli@alcatel.be [mailto:maarten.buchli@alcatel.= be]
Sent: 05 June 2003 13:36
To: Hancock, Robert
Cc: Georgios Karagiannis; nsis@ietf.org
Subject: RE: [NSIS] framework: proposal on = fragmentation


My question was mainly related to the fact whether it = should be
possible to 'switch off' the fragmentation = functionality at the NTLP,
which was proposed in the mail of Georgios. I am not = sure whether
this is really needed.
Opinions?

regards,
Maarten





"Hancock, Robert" = <robert.hancock@roke.co.uk>@ietf.org on 05/06/2003
14:11:46

Sent by:    nsis-admin@ietf.org


To:    Maarten = BUCHLI/BE/ALCATEL@ALCATEL, Georgios Karagiannis
       = <karagian@cs.utwente.nl>
cc:    nsis@ietf.org
Subject:    RE: [NSIS] framework: = proposal on fragmentation


Hi Maarten,

> Hi Georgios, Robert,
>
> I would agree as well on proposal 2, i.e. to = locate
> the fragmentation into the NTLP. I am not = sure
> however why there would be a need to be able = to
> disable that functionality. Do you have a = particular
> scenario in mind that requires this?

no comment!

>
> Furthermore, would that exlude the use of TCP = and
> SCTP as a transport protocol?

that was not the intention - really the functionality = I am talking about
is 'handle big messages' and TCP/SCTP are clearly = able to do that. (it
might
not be called 'fragmentation' in those protocols but = the function is
there.)
in any case, what protocol/fragmentation mechanism = is used in the NTLP
should
be invisible to upper layers.

cheers,

r.

>
> regards,
> Maarten
>
>
>
>
>
> "Georgios Karagiannis" = <karagian@cs.utwente.nl>@ietf.org on 05/06/2003
> 13:56:47
>
> Sent by:    = nsis-admin@ietf.org
>
>
> To:    "Hancock, = Robert" <robert.hancock@roke.co.uk>, = <nsis@ietf.org>
> cc:
> Subject:    Re: [NSIS] = framework: proposal on fragmentation
>
>
> Hi Robert
>
> Regarding your proposal (2) - fragmentation in = NTLP.
>
> I will agree with your proposal if it will be = posiible to
> also switch this
> featureoff when needed.
> For example, suppose that in a scenario the = NTLP will have to
> support only
> one type of NSLP
> that uses small message types. In this = situation the NTLP
> fragmentation
> feature could be switched off,
> i.e., not applied at all.
>
> Best Regards,
> Georgios
>
>
> ----- Original Message -----
> From: "Hancock, Robert" = <robert.hancock@roke.co.uk>
> To: <nsis@ietf.org>
> Sent: Thursday, June 05, 2003 12:38 PM
> Subject: [NSIS] framework: proposal on = fragmentation
>
>
> > dear all,
> >
> > Since we all seem agreed that bundling = should be in the NTLP (and in
> fact,
> it
> > already apparently is), here is the second = open issue on
> 'transport-like
> > functions' and where they should go in the = NTLP/NSLP layer model.
> >
> > This is the question of fragmentation, = i.e. where to handle
> the fact that
> > [NSLP message + NTLP encapsulation] may be = bigger than the
> MTU on the
> path
> > to the next NxLP node.
> >
> > There seem to me to be 3 main = options:
> > 1. leave it up to the IP layer.
> > 2. do it in the NTLP.
> > 3. do it (if needed) in the NSLP.
> > My proposal is basically (2). Read no = further if you agree...
> >
> > cheers,
> >
> > robert h.
> >
> >
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > Here is the background:
> >
> > This issue is not handled in 2961 but = discussed as a
> potential problem
> there;
> > there is also some analysis in = draft-pan-nsis-rsvp-transport-01.txt
> (section 2.3). There has been some discussion = of this in the
> past on this
> mailing list, but I
> > couldn't really detect an agreed = conclusion to it. I have
> tried to take
> it
> into
> > account in this summary.
> >
> > The situation at the moment is that 'most' = RSVP messages
> are 'small', and
> > this only tends not to be so in the case = that it is used
> over links where
> > the MTU can be made large (9k is common = for ATM/FR for example). We
> expect
> that
> > this will change in the future - i.e. = *some* signalling
> applications will
> generate
> > big messages (as we add more security = credentials for
> example), and we
> don't want
> > to restrict the range of link types that = can be used.
> >
> > Reasoning about the choices:
> >
> > 1. Doing it in the IP layer is conceivable = but probably
> wouldn't work
> well
> for
> > some awkward reasons, for = example...
> > a) IP fragmentation doesn't mix well with = implicit addressing + the
> router
> alert
> > option (Ping pointed this out at the = interim). [I can't
> decide if this is
> an
> > implementation issue or specification = issue, but it
> certainly seems to be
> an
> > issue.]
> > b) If NSIS messages use flow source = addresses (like RSVP),
> they would
> have
> > to make up their own IP-ID/fragmentation = headers
> independently of the
> real
> source
> > node. This could lead to (theoretical) = misassembly errors.
> > c) We are trying (hard/a bit) to make NSIS = NAT-friendly.
> Relying on IP
> layer
> > fragmentation probably won't make this = easier. (If you
> demand every NAT
> is
> at least
> > NTLP aware, maybe you are OK.)
> > d) IP fragmentation increases the = underlying message loss
> rate (which
> then
> has to
> > be recovered from).
> >
> > Maybe none of these are killing = issues.
> >
> > 2. Doing it in the NTLP is a challenge for = the NTLP designers...
> > a) Only the NTLP knows its encapsulation = overhead and so
> how to split up
> the
> > NSLP messages.
> > b) The best efficiency would gained from = using some sort of
> PMTU-d, and I
> suspect
> > only the NTLP can do this, since it = controls IP layer
> addressing and sees
> the
> > ICMP messages involved. It also knows when = routes change
> and rediscovery
> is
> > needed. (And PMTU-d would be useful anyway = in the NTLP to
> do bundling
> best.)
> > c) Fragmentation could be restricted to = the particular NTLP hop that
> needs
> it
> > rather than doing it everywhere.
> >
> > I think the main objection to doing it in = the NTLP is that it's a
> function
> that
> > not many applications/scenarios 'really' = need, and we are
> overloading the
> common
> > component for a minority interest. We = can't really evaluate
> that argument
> without
> > seeing how difficult it is (currently, I = am not convinced
> by it). Also,
> doing
> > fragmentation without the ability to = retransmit lost
> fragments strikes me
> as a bad
> > thing, but since the current NTLP proposal = has some form of
> reliability
> in
> it
> > this isn't relevant.
> >
> > 3. You can only do it in the NSLP if the = NSLP knows what
> fragment size to
> use.
> > As pointed out above, it doesn't, since = there may be more
> than one NTLP
> hop to
> > the next NSLP-aware node. (In theory, you = could write an
> NSIS signalling
> > application - which used only small = messages! - to discover this
> information
> > over the path and then use that. This = strikes me as a interesting
> theoretical
> > possibility, but unlikely to lead to good = results in practice.)
> > = _______________________________________________
> > 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=

------_=_NextPart_001_01C32B6B.7DE87B0E-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 5 10:20: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 KAA27866 for ; Thu, 5 Jun 2003 10:20:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55EKMh08133 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 10:20:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55EKCB08124; Thu, 5 Jun 2003 10:20:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55EIuB07925 for ; Thu, 5 Jun 2003 10:18:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27775 for ; Thu, 5 Jun 2003 10:18:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NvY3-0007KF-00 for nsis@ietf.org; Thu, 05 Jun 2003 10:16:59 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19NvY2-0007KC-00 for nsis@ietf.org; Thu, 05 Jun 2003 10:16:58 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h55EIl5s007419; Thu, 5 Jun 2003 16:18:48 +0200 (MET DST) Message-ID: <00a401c32b6d$623a6690$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Daniel Warren" Cc: References: Subject: Re: [NSIS] framework: proposal on fragmentation Date: Thu, 5 Jun 2003 16:18:49 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A1_01C32B7E.259D10F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 is a multi-part message in MIME format. ------=_NextPart_000_00A1_01C32B7E.259D10F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] framework: proposal on fragmentationHi Daniel What I meant is that the fragmentation at NTLP layer should be optional = and not mandatory. Best regards, Georgios ----- Original Message -----=20 From: Daniel Warren=20 To: 'maarten.buchli@alcatel.be' ; Hancock, Robert=20 Cc: Georgios Karagiannis ; nsis@ietf.org=20 Sent: Thursday, June 05, 2003 4:05 PM Subject: RE: [NSIS] framework: proposal on fragmentation From Georgios's mail...=20 'I will agree with your proposal if it will be posiible to also switch = this feature off when needed. For example, suppose that in a scenario = the NTLP will have to support only one type of NSLP that uses small = message types. In this situation the NTLP fragmentation feature could be = switched off' Is it just me or is the ability to 'switch fragmentation off' a bit of = a spurreous debate? If a NSLP message plus NTLP 'stuff' is smaller than = the MTU, then you don't fragment it, if it's bigger you do. Thats not = switching it off so much as having it on but not needing to apply it. = I guess it all depends how small the 'small message types' are... Dan=20 -----Original Message-----=20 From: maarten.buchli@alcatel.be [mailto:maarten.buchli@alcatel.be]=20 Sent: 05 June 2003 13:36=20 To: Hancock, Robert=20 Cc: Georgios Karagiannis; nsis@ietf.org=20 Subject: RE: [NSIS] framework: proposal on fragmentation=20 My question was mainly related to the fact whether it should be=20 possible to 'switch off' the fragmentation functionality at the NTLP,=20 which was proposed in the mail of Georgios. I am not sure whether=20 this is really needed.=20 Opinions?=20 regards,=20 Maarten=20 "Hancock, Robert" @ietf.org on 05/06/2003=20 14:11:46=20 Sent by: nsis-admin@ietf.org=20 To: Maarten BUCHLI/BE/ALCATEL@ALCATEL, Georgios Karagiannis=20 =20 cc: nsis@ietf.org=20 Subject: RE: [NSIS] framework: proposal on fragmentation=20 Hi Maarten,=20 > Hi Georgios, Robert,=20 >=20 > I would agree as well on proposal 2, i.e. to locate=20 > the fragmentation into the NTLP. I am not sure=20 > however why there would be a need to be able to=20 > disable that functionality. Do you have a particular=20 > scenario in mind that requires this?=20 no comment!=20 >=20 > Furthermore, would that exlude the use of TCP and=20 > SCTP as a transport protocol?=20 that was not the intention - really the functionality I am talking = about=20 is 'handle big messages' and TCP/SCTP are clearly able to do that. (it = might=20 not be called 'fragmentation' in those protocols but the function is=20 there.)=20 in any case, what protocol/fragmentation mechanism is used in the NTLP = should=20 be invisible to upper layers.=20 cheers,=20 r.=20 >=20 > regards,=20 > Maarten=20 >=20 >=20 >=20 >=20 >=20 > "Georgios Karagiannis" @ietf.org on = 05/06/2003=20 > 13:56:47=20 >=20 > Sent by: nsis-admin@ietf.org=20 >=20 >=20 > To: "Hancock, Robert" , = =20 > cc:=20 > Subject: Re: [NSIS] framework: proposal on fragmentation=20 >=20 >=20 > Hi Robert=20 >=20 > Regarding your proposal (2) - fragmentation in NTLP.=20 >=20 > I will agree with your proposal if it will be posiible to=20 > also switch this=20 > featureoff when needed.=20 > For example, suppose that in a scenario the NTLP will have to=20 > support only=20 > one type of NSLP=20 > that uses small message types. In this situation the NTLP=20 > fragmentation=20 > feature could be switched off,=20 > i.e., not applied at all.=20 >=20 > Best Regards,=20 > Georgios=20 >=20 >=20 > ----- Original Message -----=20 > From: "Hancock, Robert" =20 > To: =20 > Sent: Thursday, June 05, 2003 12:38 PM=20 > Subject: [NSIS] framework: proposal on fragmentation=20 >=20 >=20 > > dear all,=20 > >=20 > > Since we all seem agreed that bundling should be in the NTLP (and = in=20 > fact,=20 > it=20 > > already apparently is), here is the second open issue on=20 > 'transport-like=20 > > functions' and where they should go in the NTLP/NSLP layer model.=20 > >=20 > > This is the question of fragmentation, i.e. where to handle=20 > the fact that=20 > > [NSLP message + NTLP encapsulation] may be bigger than the=20 > MTU on the=20 > path=20 > > to the next NxLP node.=20 > >=20 > > There seem to me to be 3 main options:=20 > > 1. leave it up to the IP layer.=20 > > 2. do it in the NTLP.=20 > > 3. do it (if needed) in the NSLP.=20 > > My proposal is basically (2). Read no further if you agree...=20 > >=20 > > cheers,=20 > >=20 > > robert h.=20 > >=20 > >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > > Here is the background:=20 > >=20 > > This issue is not handled in 2961 but discussed as a=20 > potential problem=20 > there;=20 > > there is also some analysis in = draft-pan-nsis-rsvp-transport-01.txt=20 > (section 2.3). There has been some discussion of this in the=20 > past on this=20 > mailing list, but I=20 > > couldn't really detect an agreed conclusion to it. I have=20 > tried to take=20 > it=20 > into=20 > > account in this summary.=20 > >=20 > > The situation at the moment is that 'most' RSVP messages=20 > are 'small', and=20 > > this only tends not to be so in the case that it is used=20 > over links where=20 > > the MTU can be made large (9k is common for ATM/FR for example). = We=20 > expect=20 > that=20 > > this will change in the future - i.e. *some* signalling=20 > applications will=20 > generate=20 > > big messages (as we add more security credentials for=20 > example), and we=20 > don't want=20 > > to restrict the range of link types that can be used.=20 > >=20 > > Reasoning about the choices:=20 > >=20 > > 1. Doing it in the IP layer is conceivable but probably=20 > wouldn't work=20 > well=20 > for=20 > > some awkward reasons, for example...=20 > > a) IP fragmentation doesn't mix well with implicit addressing + = the=20 > router=20 > alert=20 > > option (Ping pointed this out at the interim). [I can't=20 > decide if this is=20 > an=20 > > implementation issue or specification issue, but it=20 > certainly seems to be=20 > an=20 > > issue.]=20 > > b) If NSIS messages use flow source addresses (like RSVP),=20 > they would=20 > have=20 > > to make up their own IP-ID/fragmentation headers=20 > independently of the=20 > real=20 > source=20 > > node. This could lead to (theoretical) misassembly errors.=20 > > c) We are trying (hard/a bit) to make NSIS NAT-friendly.=20 > Relying on IP=20 > layer=20 > > fragmentation probably won't make this easier. (If you=20 > demand every NAT=20 > is=20 > at least=20 > > NTLP aware, maybe you are OK.)=20 > > d) IP fragmentation increases the underlying message loss=20 > rate (which=20 > then=20 > has to=20 > > be recovered from).=20 > >=20 > > Maybe none of these are killing issues.=20 > >=20 > > 2. Doing it in the NTLP is a challenge for the NTLP designers...=20 > > a) Only the NTLP knows its encapsulation overhead and so=20 > how to split up=20 > the=20 > > NSLP messages.=20 > > b) The best efficiency would gained from using some sort of=20 > PMTU-d, and I=20 > suspect=20 > > only the NTLP can do this, since it controls IP layer=20 > addressing and sees=20 > the=20 > > ICMP messages involved. It also knows when routes change=20 > and rediscovery=20 > is=20 > > needed. (And PMTU-d would be useful anyway in the NTLP to=20 > do bundling=20 > best.)=20 > > c) Fragmentation could be restricted to the particular NTLP hop = that=20 > needs=20 > it=20 > > rather than doing it everywhere.=20 > >=20 > > I think the main objection to doing it in the NTLP is that it's a=20 > function=20 > that=20 > > not many applications/scenarios 'really' need, and we are=20 > overloading the=20 > common=20 > > component for a minority interest. We can't really evaluate=20 > that argument=20 > without=20 > > seeing how difficult it is (currently, I am not convinced=20 > by it). Also,=20 > doing=20 > > fragmentation without the ability to retransmit lost=20 > fragments strikes me=20 > as a bad=20 > > thing, but since the current NTLP proposal has some form of=20 > reliability=20 > in=20 > it=20 > > this isn't relevant.=20 > >=20 > > 3. You can only do it in the NSLP if the NSLP knows what=20 > fragment size to=20 > use.=20 > > As pointed out above, it doesn't, since there may be more=20 > than one NTLP=20 > hop to=20 > > the next NSLP-aware node. (In theory, you could write an=20 > NSIS signalling=20 > > application - which used only small messages! - to discover this=20 > information=20 > > over the path and then use that. This strikes me as a interesting=20 > theoretical=20 > > possibility, but unlikely to lead to good results in practice.)=20 > > _______________________________________________=20 > > nsis mailing list=20 > > nsis@ietf.org=20 > > https://www1.ietf.org/mailman/listinfo/nsis=20 > >=20 >=20 > _______________________________________________=20 > nsis mailing list=20 > nsis@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/nsis=20 >=20 >=20 >=20 >=20 _______________________________________________=20 nsis mailing list=20 nsis@ietf.org=20 https://www1.ietf.org/mailman/listinfo/nsis=20 _______________________________________________=20 nsis mailing list=20 nsis@ietf.org=20 https://www1.ietf.org/mailman/listinfo/nsis=20 ------=_NextPart_000_00A1_01C32B7E.259D10F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] framework: proposal on = fragmentation
Hi Daniel
 
What I meant is that the fragmentation = at NTLP=20 layer should be optional and not mandatory.
 
Best regards,
Georgios
----- Original Message -----
From:=20 Daniel Warren
To: 'maarten.buchli@alcatel.be' ; Hancock, Robert
Cc: Georgios=20 Karagiannis ; nsis@ietf.org
Sent: Thursday, June 05, 2003 = 4:05=20 PM
Subject: RE: [NSIS] framework: = proposal=20 on fragmentation

From Georgios's mail...

'I will agree with your proposal if it will be = posiible to=20 also switch this feature off when needed.  For example, suppose = that in a=20 scenario the NTLP will have to support only one type of NSLP that uses = small=20 message types. In this situation the NTLP fragmentation feature could = be=20 switched off'

Is it just me or is the ability to 'switch = fragmentation off'=20 a bit of a spurreous debate?  If a NSLP message plus NTLP 'stuff' = is=20 smaller than the MTU, then you don't fragment it, if it's bigger you = do. =20 Thats not switching it off so much as having it on but not needing to = apply=20 it.   I guess it all depends how small the 'small message = types'=20 are...

Dan

-----Original Message-----
From:=20 maarten.buchli@alcatel.be [mailto:maarten.buchli@alcatel.b= e]=20
Sent: 05 June 2003 13:36
To: Hancock,=20 Robert
Cc: Georgios Karagiannis; = nsis@ietf.org=20
Subject: RE: [NSIS] framework: proposal on=20 fragmentation


My question was mainly related to the fact whether = it should=20 be
possible to 'switch off' the = fragmentation=20 functionality at the NTLP,
which was = proposed in the=20 mail of Georgios. I am not sure whether
this = is really=20 needed.
Opinions?

regards,
Maarten=20





"Hancock, Robert" = <robert.hancock@roke.co.uk>@ietf.org=20 on 05/06/2003
14:11:46

Sent by:    = nsis-admin@ietf.org


To:    Maarten = BUCHLI/BE/ALCATEL@ALCATEL,=20 Georgios Karagiannis
      =20 <karagian@cs.utwente.nl>
cc:   =20 nsis@ietf.org
Subject:    RE: = [NSIS]=20 framework: proposal on fragmentation


Hi Maarten,

> Hi Georgios, Robert,
>=20
> I would agree as well on proposal 2, i.e. to=20 locate
> the fragmentation into the NTLP. = I am not=20 sure
> however why there would be a need = to be able=20 to
> disable that functionality. Do you = have a=20 particular
> scenario in mind that = requires=20 this?

no comment!

>
> Furthermore, = would that=20 exlude the use of TCP and
> SCTP as a = transport=20 protocol?

that was not the intention - really the = functionality I am=20 talking about
is 'handle big messages' and = TCP/SCTP=20 are clearly able to do that. (it
might=20
not be called 'fragmentation' in those protocols = but the=20 function is
there.)
in any=20 case, what protocol/fragmentation mechanism is used in the NTLP =
should
be invisible to = upper=20 layers.

cheers,

r.

>
> regards, =
> Maarten
>
>
>
>=20
>
> "Georgios = Karagiannis"=20 <karagian@cs.utwente.nl>@ietf.org on 05/06/2003
> 13:56:47
>
>=20 Sent by:    nsis-admin@ietf.org
>
>
>=20 To:    "Hancock, Robert" = <robert.hancock@roke.co.uk>,=20 <nsis@ietf.org>
> cc: =
> Subject:    Re: [NSIS] framework: = proposal on=20 fragmentation
>
>=20
> Hi Robert
>
> Regarding your proposal (2) - fragmentation in = NTLP.=20
>
> I will agree = with your=20 proposal if it will be posiible to
> also = switch=20 this
> featureoff when needed. =
> For example, suppose that in a scenario the NTLP will = have=20 to
> support only
> one=20 type of NSLP
> that uses small message = types. In=20 this situation the NTLP
> = fragmentation=20
> feature could be switched off, =
> i.e., not applied at all.
>=20
> Best Regards,
>=20 Georgios
>
>=20
> ----- Original Message -----
> From: "Hancock, Robert" = <robert.hancock@roke.co.uk>=20
> To: <nsis@ietf.org>
>=20 Sent: Thursday, June 05, 2003 12:38 PM
> = Subject:=20 [NSIS] framework: proposal on fragmentation
>
>
> >=20 dear all,
> >
> >=20 Since we all seem agreed that bundling should be in the NTLP (and = in=20
> fact,
> it =
> > already apparently is), here is the second open = issue=20 on
> 'transport-like
>=20 > functions' and where they should go in the NTLP/NSLP layer = model.=20
> >
> > This = is the=20 question of fragmentation, i.e. where to handle
>=20 the fact that
> > [NSLP message + NTLP = encapsulation] may be bigger than the
> = MTU on=20 the
> path
> = > to the=20 next NxLP node.
> >
>=20 > There seem to me to be 3 main options:
> >=20 1. leave it up to the IP layer.
> > 2. = do it in=20 the NTLP.
> > 3. do it (if needed) in = the=20 NSLP.
> > My proposal is basically = (2). Read no=20 further if you agree...
> > =
> > cheers,
> > =
> > robert h.
> = >
> >
>=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
> > Here is=20 the background:
> >
>=20 > This issue is not handled in 2961 but discussed as a =
> potential problem
> = there;=20
> > there is also some analysis in=20 draft-pan-nsis-rsvp-transport-01.txt
> = (section=20 2.3). There has been some discussion of this in the
> past on this
> mailing = list, but=20 I
> > couldn't really detect an agreed = conclusion to it. I have
> tried to = take=20
> it
> into =
> > account in this summary.
>=20 >
> > The situation at the moment = is that=20 'most' RSVP messages
> are 'small', = and=20
> > this only tends not to be so in the case = that it is=20 used
> over links where
> > the MTU can be made large (9k is common for ATM/FR = for=20 example). We
> expect
>=20 that
> > this will change in the = future - i.e.=20 *some* signalling
> applications = will=20
> generate
> > = big messages=20 (as we add more security credentials for
>=20 example), and we
> don't want =
> > to restrict the range of link types that can be = used.=20
> >
> > = Reasoning about=20 the choices:
> >
>=20 > 1. Doing it in the IP layer is conceivable but probably =
> wouldn't work
> well =
> for
> > some awkward = reasons, for=20 example...
> > a) IP fragmentation = doesn't mix=20 well with implicit addressing + the
> = router=20
> alert
> > = option (Ping=20 pointed this out at the interim). [I can't
> decide=20 if this is
> an
> >=20 implementation issue or specification issue, but it
> certainly seems to be
> = an=20
> > issue.]
> = > b) If=20 NSIS messages use flow source addresses (like RSVP),
> they would
> have =
> > to make up their own IP-ID/fragmentation = headers=20
> independently of the
>=20 real
> source
> >=20 node. This could lead to (theoretical) misassembly errors. =
> > c) We are trying (hard/a bit) to make NSIS=20 NAT-friendly.
> Relying on IP =
> layer
> > fragmentation = probably=20 won't make this easier. (If you
> demand = every=20 NAT
> is
> = at=20 least
> > NTLP aware, maybe you are = OK.)=20
> > d) IP fragmentation increases the = underlying=20 message loss
> rate (which =
> then
> has to =
> > be recovered from).
> = >=20
> > Maybe none of these are killing = issues.=20
> >
> > 2. = Doing it in=20 the NTLP is a challenge for the NTLP designers...
>=20 > a) Only the NTLP knows its encapsulation overhead and so =
> how to split up
> = the
> > NSLP messages.
> > = b) The best=20 efficiency would gained from using some sort of
>=20 PMTU-d, and I
> suspect
> > only the NTLP can do this, since it controls IP = layer=20
> addressing and sees
>=20 the
> > ICMP messages involved. It = also knows=20 when routes change
> and = rediscovery=20
> is
> > needed. = (And PMTU-d=20 would be useful anyway in the NTLP to
> = do=20 bundling
> best.)
> >=20 c) Fragmentation could be restricted to the particular NTLP hop = that=20
> needs
> it =
> > rather than doing it everywhere.
>=20 >
> > I think the main objection to = doing it=20 in the NTLP is that it's a
> = function=20
> that
> > not = many=20 applications/scenarios 'really' need, and we are
>=20 overloading the
> common
> > component for a minority interest. We can't really=20 evaluate
> that argument
> without
> > seeing how = difficult it=20 is (currently, I am not convinced
> by = it).=20 Also,
> doing
> >=20 fragmentation without the ability to retransmit lost
> fragments strikes me
> as a = bad=20
> > thing, but since the current NTLP = proposal has some=20 form of
> reliability
>=20 in
> it
> = > this=20 isn't relevant.
> >
>=20 > 3. You can only do it in the NSLP if the NSLP knows what =
> fragment size to
> = use.=20
> > As pointed out above, it doesn't, since = there may=20 be more
> than one NTLP
> hop to
> > the next = NSLP-aware node.=20 (In theory, you could write an
> NSIS=20 signalling
> > application - which = used only=20 small messages! - to discover this
>=20 information
> > over the path and then = use that.=20 This strikes me as a interesting
>=20 theoretical
> > possibility, but = unlikely to=20 lead to good results in practice.)
> > = _______________________________________________
>=20 > nsis mailing list
> > = nsis@ietf.org=20
> > https://www1.ietf.org/mailman/listinfo/nsis =
> >
>
>=20 _______________________________________________
>=20 nsis mailing list
> nsis@ietf.org =
>  https://www1.ietf.org/mailman/listinfo/nsis =
>
>
>=20
>
_______________________________________________ =
nsis mailing list
nsis@ietf.org=20
 https://www1.ietf.org/mailman/listinfo/nsis =




_______________________________________________=20
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis =

------=_NextPart_000_00A1_01C32B7E.259D10F0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 5 10: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 KAA28537 for ; Thu, 5 Jun 2003 10:34:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55EYIx08885 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 10:34:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55EYCB08877; Thu, 5 Jun 2003 10:34:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55EXIB08839 for ; Thu, 5 Jun 2003 10:33:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28494 for ; Thu, 5 Jun 2003 10:33:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nvlx-0007SW-00 for nsis@ietf.org; Thu, 05 Jun 2003 10:31:21 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19Nvlw-0007SM-00 for nsis@ietf.org; Thu, 05 Jun 2003 10:31:20 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h55EX45s008038; Thu, 5 Jun 2003 16:33:05 +0200 (MET DST) Message-ID: <00b901c32b6f$610f1b10$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Melinda Shore" Cc: References: <200306051341.AIA42523@mira-sjc5-c.cisco.com> Subject: Re: [NSIS] framework: proposal on fragmentation Date: Thu, 5 Jun 2003 16:33:06 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Melinda I agree with your proposal! Actually this is also what I meant in my previous e-mails, i.e., optional use of fragmentation at the NTLP layer! Best regards, Georgios ----- Original Message ----- From: "Melinda Shore" To: "Hancock, Robert" Cc: Sent: Thursday, June 05, 2003 3:41 PM Subject: Re: [NSIS] framework: proposal on fragmentation > I'd really like to see optional (probably optional-to- use, > mandatory-to-implement) support for fragmentation, and I > think it's pretty clear that the only reasonable place to > put it is in the NTLP. I don't think it's healthy to be > inflexible about layer separation but this is a case in > which it would be a lot messier to do it anywhere but in the > NTLP, because it's the NTLP that "knows" what the actual > packet sizes are. (Note also that relying on IP layer > fragmentation can cause NAT failures). I'm very much in > agreement. > > 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 Jun 5 10:39: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 KAA28663 for ; Thu, 5 Jun 2003 10:39:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55Eco410019 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 10:38:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55EccB10001; Thu, 5 Jun 2003 10:38:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55EbqB09942 for ; Thu, 5 Jun 2003 10:37:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28621 for ; Thu, 5 Jun 2003 10:37:46 -0400 (EDT) From: maarten.buchli@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NvqN-0007TW-00 for nsis@ietf.org; Thu, 05 Jun 2003 10:35:55 -0400 Received: from alc240.alcatel.be ([195.207.101.240] helo=bt0rjw.god.bel.alcatel.be) by ietf-mx with esmtp (Exim 4.12) id 19NvqM-0007TN-00 for nsis@ietf.org; Thu, 05 Jun 2003 10:35:54 -0400 Received: from bemail05.net.alcatel.be (bemail05.net.alcatel.be [138.203.144.16]) by bt0rjw.god.bel.alcatel.be (8.12.9/8.11.4) with ESMTP id h55EbFBJ023900 for ; Thu, 5 Jun 2003 16:37:15 +0200 (MEST) Subject: Re: [NSIS] framework: proposal on fragmentation To: "Georgios Karagiannis" Cc: "Daniel Warren" , Date: Thu, 5 Jun 2003 16:37:13 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 06/05/2003 16:37:15 MIME-Version: 1.0 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 h55EbqB09943 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, If we decide to make the fragentation mandatory for an NTLP implementation why should we make the use of it optional? If it is implemented it will not put a performance burden in case the message does not need fragmentation as mentioned in the previous e-mails of Daniel and Robert. So it seems that both the implementation and the use of fragmentation should be mandatory. regards, Maarten "Georgios Karagiannis" @ietf.org on 05/06/2003 16:18:49 Sent by: nsis-admin@ietf.org To: "Daniel Warren" cc: Subject: Re: [NSIS] framework: proposal on fragmentation Hi Daniel What I meant is that the fragmentation at NTLP layer should be optional and not mandatory. Best regards, Georgios ----- Original Message ----- From: Daniel Warren To: 'maarten.buchli@alcatel.be' ; Hancock, Robert Cc: Georgios Karagiannis ; nsis@ietf.org Sent: Thursday, June 05, 2003 4:05 PM Subject: RE: [NSIS] framework: proposal on fragmentation From Georgios's mail... 'I will agree with your proposal if it will be posiible to also switch this feature off when needed.  For example, suppose that in a scenario the NTLP will have to support only one type of NSLP that uses small message types. In this situation the NTLP fragmentation feature could be switched off' Is it just me or is the ability to 'switch fragmentation off' a bit of a spurreous debate?  If a NSLP message plus NTLP 'stuff' is smaller than the MTU, then you don't fragment it, if it's bigger you do.  Thats not switching it off so much as having it on but not needing to apply it.   I guess it all depends how small the 'small message types' are... Dan -----Original Message----- From: maarten.buchli@alcatel.be [mailto:maarten.buchli@alcatel.be] Sent: 05 June 2003 13:36 To: Hancock, Robert Cc: Georgios Karagiannis; nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation My question was mainly related to the fact whether it should be possible to 'switch off' the fragmentation functionality at the NTLP, which was proposed in the mail of Georgios. I am not sure whether this is really needed. Opinions? regards, Maarten "Hancock, Robert" @ietf.org on 05/06/2003 14:11:46 Sent by:    nsis-admin@ietf.org To:    Maarten BUCHLI/BE/ALCATEL@ALCATEL, Georgios Karagiannis        cc:    nsis@ietf.org Subject:    RE: [NSIS] framework: proposal on fragmentation Hi Maarten, > Hi Georgios, Robert, > > I would agree as well on proposal 2, i.e. to locate > the fragmentation into the NTLP. I am not sure > however why there would be a need to be able to > disable that functionality. Do you have a particular > scenario in mind that requires this? no comment! > > Furthermore, would that exlude the use of TCP and > SCTP as a transport protocol? that was not the intention - really the functionality I am talking about is 'handle big messages' and TCP/SCTP are clearly able to do that. (it might not be called 'fragmentation' in those protocols but the function is there.) in any case, what protocol/fragmentation mechanism is used in the NTLP should be invisible to upper layers. cheers, r. > > regards, > Maarten > > > > > > "Georgios Karagiannis" @ietf.org on 05/06/2003 > 13:56:47 > > Sent by:    nsis-admin@ietf.org > > > To:    "Hancock, Robert" , > cc: > Subject:    Re: [NSIS] framework: proposal on fragmentation > > > Hi Robert > > Regarding your proposal (2) - fragmentation in NTLP. > > I will agree with your proposal if it will be posiible to > also switch this > featureoff when needed. > For example, suppose that in a scenario the NTLP will have to > support only > one type of NSLP > that uses small message types. In this situation the NTLP > fragmentation > feature could be switched off, > i.e., not applied at all. > > Best Regards, > Georgios > > > ----- Original Message ----- > From: "Hancock, Robert" > To: > Sent: Thursday, June 05, 2003 12:38 PM > Subject: [NSIS] framework: proposal on fragmentation > > > > dear all, > > > > Since we all seem agreed that bundling should be in the NTLP (and in > fact, > it > > already apparently is), here is the second open issue on > 'transport-like > > functions' and where they should go in the NTLP/NSLP layer model. > > > > This is the question of fragmentation, i.e. where to handle > the fact that > > [NSLP message + NTLP encapsulation] may be bigger than the > MTU on the > path > > to the next NxLP node. > > > > There seem to me to be 3 main options: > > 1. leave it up to the IP layer. > > 2. do it in the NTLP. > > 3. do it (if needed) in the NSLP. > > My proposal is basically (2). Read no further if you agree... > > > > cheers, > > > > robert h. > > > > > ============================================================== > ============= > > Here is the background: > > > > This issue is not handled in 2961 but discussed as a > potential problem > there; > > there is also some analysis in draft-pan-nsis-rsvp-transport-01.txt > (section 2.3). There has been some discussion of this in the > past on this > mailing list, but > > couldn't really detect an agreed conclusion to it. I have > tried to take > it > into > > account in this summary. > > > > The situation at the moment is that 'most' RSVP messages > are 'small', and > > this only tends not to be so in the case that it is used > over links where > > the MTU can be made large (9k is common for ATM/FR for example). We > expect > that > > this will change in the future - i.e. *some* signalling > applications will > generate > > big messages (as we add more security credentials for > example), and we > don't want > > to restrict the range of link types that can be used. > > > > Reasoning about the choices: > > > > 1. Doing it in the IP layer is conceivable but probably > wouldn't work > well > for > > some awkward reasons, for example... > > a) IP fragmentation doesn't mix well with implicit addressing + the > router > alert > > option (Ping pointed this out at the interim). [I can't > decide if this is > an > > implementation issue or specification issue, but it > certainly seems to be > an > > issue.] > > b) If NSIS messages use flow source addresses (like RSVP), > they would > have > > to make up their own IP-ID/fragmentation headers > independently of the > real > source > > node. This could lead to (theoretical) misassembly errors. > > c) We are trying (hard/a bit) to make NSIS NAT-friendly. > Relying on IP > layer > > fragmentation probably won't make this easier. (If you > demand every NAT > is > at least > > NTLP aware, maybe you are OK.) > > d) IP fragmentation increases the underlying message loss > rate (which > then > has to > > be recovered from). > > > > Maybe none of these are killing issues. > > > > 2. Doing it in the NTLP is a challenge for the NTLP designers... > > a) Only the NTLP knows its encapsulation overhead and so > how to split up > the > > NSLP messages. > > b) The best efficiency would gained from using some sort of > PMTU-d, and I > suspect > > only the NTLP can do this, since it controls IP layer > addressing and sees > the > > ICMP messages involved. It also knows when routes change > and rediscovery > is > > needed. (And PMTU-d would be useful anyway in the NTLP to > do bundling > best.) > > c) Fragmentation could be restricted to the particular NTLP hop that > needs > it > > rather than doing it everywhere. > > > > I think the main objection to doing it in the NTLP is that it's a > function > that > > not many applications/scenarios 'really' need, and we are > overloading the > common > > component for a minority interest. We can't really evaluate > that argument > without > > seeing how difficult it is (currently, I am not convinced > by it). Also, > doing > > fragmentation without the ability to retransmit lost > fragments strikes me > as a bad > > thing, but since the current NTLP proposal has some form of > reliability > in > it > > this isn't relevant. > > > > 3. You can only do it in the NSLP if the NSLP knows what > fragment size to > use. > > As pointed out above, it doesn't, since there may be more > than one NTLP > hop to > > the next NSLP-aware node. (In theory, you could write an > NSIS signalling > > application - which used only small messages! - to discover this > information > > over the path and then use that. This strikes me as a interesting > theoretical > > possibility, but unlikely to lead to good results in practice.) > > _______________________________________________ > > 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 Thu Jun 5 10:51: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 KAA29053 for ; Thu, 5 Jun 2003 10:51:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55Ep6L10553 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 10:51:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55EonB10517; Thu, 5 Jun 2003 10:50:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55EhXB10225 for ; Thu, 5 Jun 2003 10:43:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28822 for ; Thu, 5 Jun 2003 10:43:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nvvs-0007Vx-00 for nsis@ietf.org; Thu, 05 Jun 2003 10:41:36 -0400 Received: from h3s128a211n47.user.nortelnetworks.com ([47.211.128.3] helo=znsgs01r.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19Nvvr-0007Vj-00 for nsis@ietf.org; Thu, 05 Jun 2003 10:41:35 -0400 Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h55Egd511756; Thu, 5 Jun 2003 15:42:40 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jun 2003 15:41:55 +0100 Message-ID: From: "Daniel Warren" To: "'Georgios Karagiannis'" , Melinda Shore Cc: nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation Date: Thu, 5 Jun 2003 15:41:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32B70.99C3B0FA" 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_01C32B70.99C3B0FA Content-Type: text/plain; charset="iso-8859-1" I'm still not entirely getting this. Where exactly is the 'optionality'? If a connection has an MTU size set that is huge, then there may never be a need to segment, but that isn't an option, other than a configuration option on that link. It says nothing about whether segmentation is implemented or not, it just means segmentation is never an issue. If you have an option to implement segmentation in the true sense of an option, then if you don't implement and messages exceed the size that allows them to fit within the MTU, they will get dropped or errored. Surely thats not the option you want to enable...? Dan -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] Sent: 05 June 2003 15:33 To: Melinda Shore Cc: nsis@ietf.org Subject: Re: [NSIS] framework: proposal on fragmentation Hi Melinda I agree with your proposal! Actually this is also what I meant in my previous e-mails, i.e., optional use of fragmentation at the NTLP layer! Best regards, Georgios ----- Original Message ----- From: "Melinda Shore" To: "Hancock, Robert" Cc: Sent: Thursday, June 05, 2003 3:41 PM Subject: Re: [NSIS] framework: proposal on fragmentation > I'd really like to see optional (probably optional-to- use, > mandatory-to-implement) support for fragmentation, and I > think it's pretty clear that the only reasonable place to > put it is in the NTLP. I don't think it's healthy to be > inflexible about layer separation but this is a case in > which it would be a lot messier to do it anywhere but in the > NTLP, because it's the NTLP that "knows" what the actual > packet sizes are. (Note also that relying on IP layer > fragmentation can cause NAT failures). I'm very much in > agreement. > > 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 ------_=_NextPart_001_01C32B70.99C3B0FA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] framework: proposal on fragmentation

I'm still not entirely getting this.  Where = exactly is the 'optionality'?  If a connection has an MTU size set = that is huge, then there may never be a need to segment, but that isn't = an option, other than a configuration option on that link.  It = says nothing about whether segmentation is implemented or not, it just = means segmentation is never an issue.

If you have an option to implement segmentation in = the true sense of an option, then if you don't implement and messages = exceed the size that allows them to fit within the MTU, they will get = dropped or errored.  Surely thats not the option you want to = enable...?

Dan



-----Original Message-----
From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl= ]
Sent: 05 June 2003 15:33
To: Melinda Shore
Cc: nsis@ietf.org
Subject: Re: [NSIS] framework: proposal on = fragmentation


Hi Melinda

I agree with your proposal! Actually this is also = what I meant in my
previous e-mails, i.e.,  optional use of = fragmentation at the NTLP layer!

Best regards,
Georgios

----- Original Message -----
From: "Melinda Shore" = <mshore@cisco.com>
To: "Hancock, Robert" = <robert.hancock@roke.co.uk>
Cc: <nsis@ietf.org>
Sent: Thursday, June 05, 2003 3:41 PM
Subject: Re: [NSIS] framework: proposal on = fragmentation


> I'd really like to see optional (probably = optional-to- use,
> mandatory-to-implement) support for = fragmentation, and I
> think it's pretty clear that the only = reasonable place to
> put it is in the NTLP.  I don't think it's = healthy to be
> inflexible about layer separation but this is a = case in
> which it would be a lot messier to do it = anywhere but in the
> NTLP, because it's the NTLP that = "knows" what the actual
> packet sizes are.  (Note also that relying = on IP layer
> fragmentation can cause NAT failures).  = I'm very much in
> agreement.
>
> 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=

------_=_NextPart_001_01C32B70.99C3B0FA-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 5 11:00: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 LAA29411 for ; Thu, 5 Jun 2003 11:00:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55F0GR11212 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 11:00:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55F0AB11194; Thu, 5 Jun 2003 11:00:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55Et3B10811 for ; Thu, 5 Jun 2003 10:55:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29169 for ; Thu, 5 Jun 2003 10:54:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nw70-0007bF-00 for nsis@ietf.org; Thu, 05 Jun 2003 10:53:06 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19Nw6z-0007b9-00 for nsis@ietf.org; Thu, 05 Jun 2003 10:53:05 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h55EsGwc002900; Thu, 5 Jun 2003 07:54:16 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIA47648; Thu, 5 Jun 2003 07:54:15 -0700 (PDT) Message-Id: <200306051454.AIA47648@mira-sjc5-c.cisco.com> To: "Georgios Karagiannis" cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] framework: proposal on fragmentation In-Reply-To: Message from karagian@cs.utwente.nl of "Thu, 05 Jun 2003 16:33:06 +0200." <00b901c32b6f$610f1b10$4c0d5982@dynamic.cs.utwente.nl> Date: Thu, 05 Jun 2003 10:54:14 -0400 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 agree with your proposal! Actually this is also what I meant in my > previous e-mails, i.e., optional use of fragmentation at the NTLP layer! Not to be fickle, but in reading the recent traffic on the mailing list I now agree that I don't see what's achieved by having fragmentation be optional. We're probably at the point where the argument would benefit from specifics. I can't think of a circumstance in which you'd want to turn it off, myself. At any rate it seems to me that the discussion of what happens when you've got a packet that's too small to require fragmentation is probably less interesting right now than the question of what would happen if you've got a packet that's large and requires fragmentation. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 5 11:00: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 LAA29437 for ; Thu, 5 Jun 2003 11:00:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55F0Pc11254 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 11:00:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55F0IB11241; Thu, 5 Jun 2003 11:00:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55ExGB11075 for ; Thu, 5 Jun 2003 10:59:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29289 for ; Thu, 5 Jun 2003 10:59:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NwB4-0007cm-00 for nsis@ietf.org; Thu, 05 Jun 2003 10:57:18 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19NwAz-0007cj-00 for nsis@ietf.org; Thu, 05 Jun 2003 10:57:14 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h55Ex25s008968; Thu, 5 Jun 2003 16:59:03 +0200 (MET DST) Message-ID: <00d801c32b73$01ae2810$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Daniel Warren" Cc: References: Subject: Re: [NSIS] framework: proposal on fragmentation Date: Thu, 5 Jun 2003 16:58:59 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D5_01C32B83.C2433380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 is a multi-part message in MIME format. ------=_NextPart_000_00D5_01C32B83.C2433380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] framework: proposal on fragmentationHi Daniel There are different ways of applying the NTLP feature as optional, for = example: * some nodes do not implement the NTLP fragmentation at all; * any NSLP should be able to require from the NTLP to fragment its = messages or not. Best regards, Georgios ----- Original Message -----=20 From: Daniel Warren=20 To: 'Georgios Karagiannis' ; Melinda Shore=20 Cc: nsis@ietf.org=20 Sent: Thursday, June 05, 2003 4:41 PM Subject: RE: [NSIS] framework: proposal on fragmentation=20 I'm still not entirely getting this. Where exactly is the = 'optionality'? If a connection has an MTU size set that is huge, then = there may never be a need to segment, but that isn't an option, other = than a configuration option on that link. It says nothing about whether = segmentation is implemented or not, it just means segmentation is never = an issue. If you have an option to implement segmentation in the true sense of = an option, then if you don't implement and messages exceed the size that = allows them to fit within the MTU, they will get dropped or errored. = Surely thats not the option you want to enable...? Dan=20 -----Original Message-----=20 From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: 05 June 2003 15:33=20 To: Melinda Shore=20 Cc: nsis@ietf.org=20 Subject: Re: [NSIS] framework: proposal on fragmentation=20 Hi Melinda=20 I agree with your proposal! Actually this is also what I meant in my=20 previous e-mails, i.e., optional use of fragmentation at the NTLP = layer!=20 Best regards,=20 Georgios=20 ----- Original Message -----=20 From: "Melinda Shore" =20 To: "Hancock, Robert" =20 Cc: =20 Sent: Thursday, June 05, 2003 3:41 PM=20 Subject: Re: [NSIS] framework: proposal on fragmentation=20 > I'd really like to see optional (probably optional-to- use,=20 > mandatory-to-implement) support for fragmentation, and I=20 > think it's pretty clear that the only reasonable place to=20 > put it is in the NTLP. I don't think it's healthy to be=20 > inflexible about layer separation but this is a case in=20 > which it would be a lot messier to do it anywhere but in the=20 > NTLP, because it's the NTLP that "knows" what the actual=20 > packet sizes are. (Note also that relying on IP layer=20 > fragmentation can cause NAT failures). I'm very much in=20 > agreement.=20 >=20 > Melinda=20 > _______________________________________________=20 > nsis mailing list=20 > nsis@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/nsis=20 >=20 _______________________________________________=20 nsis mailing list=20 nsis@ietf.org=20 https://www1.ietf.org/mailman/listinfo/nsis=20 ------=_NextPart_000_00D5_01C32B83.C2433380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] framework: proposal on = fragmentation
Hi Daniel
 
There are different ways of applying = the NTLP=20 feature as optional, for example:
 
* some nodes do not implement the NTLP=20 fragmentation at all;
* any NSLP should be able to require = from the NTLP=20 to fragment its messages or not.
 
Best regards,
Georgios
 
 
 
----- Original Message -----
From:=20 Daniel Warren
To: 'Georgios=20 Karagiannis' ; Melinda Shore
Sent: Thursday, June 05, 2003 = 4:41=20 PM
Subject: RE: [NSIS] framework: = proposal=20 on fragmentation

I'm still not entirely getting this.  Where = exactly is=20 the 'optionality'?  If a connection has an MTU size set that is = huge,=20 then there may never be a need to segment, but that isn't an option, = other=20 than a configuration option on that link.  It says nothing about = whether=20 segmentation is implemented or not, it just means segmentation is = never an=20 issue.

If you have an option to implement segmentation in = the true=20 sense of an option, then if you don't implement and messages exceed = the size=20 that allows them to fit within the MTU, they will get dropped or=20 errored.  Surely thats not the option you want to = enable...?

Dan



-----Original Message-----
From:=20 Georgios Karagiannis [mailto:karagian@cs.utwente.nl]= =20
Sent: 05 June 2003 15:33
To: Melinda=20 Shore
Cc: nsis@ietf.org
Subject: Re: [NSIS] framework: proposal on fragmentation=20


Hi Melinda

I agree with your proposal! Actually this is also = what I meant=20 in my
previous e-mails, i.e.,  optional = use of=20 fragmentation at the NTLP layer!

Best regards,
Georgios

----- Original Message -----
From:=20 "Melinda Shore" <mshore@cisco.com>
To: = "Hancock,=20 Robert" <robert.hancock@roke.co.uk>
Cc:=20 <nsis@ietf.org>
Sent: Thursday, June = 05, 2003=20 3:41 PM
Subject: Re: [NSIS] framework: = proposal on=20 fragmentation


> I'd really like to see optional (probably = optional-to-=20 use,
> mandatory-to-implement) support = for=20 fragmentation, and I
> think it's pretty = clear that=20 the only reasonable place to
> put it is = in the=20 NTLP.  I don't think it's healthy to be
>=20 inflexible about layer separation but this is a case in =
> which it would be a lot messier to do it anywhere but in = the
> NTLP, because it's the NTLP that = "knows" what=20 the actual
> packet sizes are.  = (Note also=20 that relying on IP layer
> fragmentation = can cause=20 NAT failures).  I'm very much in
>=20 agreement.
>
>=20 Melinda
>=20 _______________________________________________
>=20 nsis mailing list
> nsis@ietf.org =
> https://www1.ietf.org/mailman/listinfo/nsis =
>

_______________________________________________=20
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis =

------=_NextPart_000_00D5_01C32B83.C2433380-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 5 11:12: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 LAA00873 for ; Thu, 5 Jun 2003 11:12:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55FC7n13009 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 11:12:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55FC2B12999; Thu, 5 Jun 2003 11:12:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55FBMB12959 for ; Thu, 5 Jun 2003 11:11:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00786 for ; Thu, 5 Jun 2003 11:11:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NwMm-00004Q-00 for nsis@ietf.org; Thu, 05 Jun 2003 11:09:24 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 19NwMl-000040-00 for nsis@ietf.org; Thu, 05 Jun 2003 11:09:23 -0400 Received: from zcard307.ca.nortel.com (americasm03.nt.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h55FA3J09630; Thu, 5 Jun 2003 11:10:03 -0400 (EDT) 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 L9VCQGQY; Thu, 5 Jun 2003 11:10:03 -0400 Received: from nortelnetworks.com (acart1cv.ca.nortel.com [47.129.129.71]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0QQJ; Thu, 5 Jun 2003 11:10:03 -0400 Message-ID: <3EDF5D4A.1000909@nortelnetworks.com> Date: Thu, 05 Jun 2003 11:10:02 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Georgios Karagiannis CC: john.loughney@nokia.com, maarten.buchli@alcatel.be, nsis@ietf.org Subject: Re: [NSIS] framework: proposal on fragmentation References: <006601c32b6a$57ae14e0$4c0d5982@dynamic.cs.utwente.nl> In-Reply-To: <006601c32b6a$57ae14e0$4c0d5982@dynamic.cs.utwente.nl> 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 There are only two possibilities for point of reassembly: after every NTLP hop, or where the message is being delivered to NSLP. The latter is complicated by the possibility that one NTLP message may contain multiple NSLP messages. On the other hand, it seems like a waste to reassemble messages hop by hop, only to break them down again for the next hop. Of course, doing this means that lost fragments can be retrieved on a per hop basis rather than involving more nodes. In any event, I expect Georgios is concerned that the receiving node has to execute logic checking for fragmentation for every packet received, even if fragmentation can't happen in that particular application. If the reason fragmentation won't happen is a big MTU, I can almost follow his argument. If the reason fragmentation won't happen is the particular NSLP, I don't buy the argument, because the other NSLPs may also be bundled in. Georgios Karagiannis wrote: > Hi John and Maarten > > First of all if a message is fragmented has to be reassembled somewhere. > The NTLP will have to find out where the fragmentation and the reassembly > process has to be > accomplished. This will require additional processing, even if this it is > not needed. > In scenarios where performance in terms of processing delays, number of > states per flow, etc., > is important, it should be possible that the fragmentation at NTLP layer > should be switched off and > either assure that the NSLP messages are small enough such that they will > not be fragmented > or do it in the NSLP if required. > > Best Regards, > Georgios > [snip] _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 5 11: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 LAA03820 for ; Thu, 5 Jun 2003 11:40:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55FeHW15578 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 11:40:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55FeBB15535; Thu, 5 Jun 2003 11:40:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55Fd2B15453 for ; Thu, 5 Jun 2003 11:39:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03603 for ; Thu, 5 Jun 2003 11:39:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nwnc-0000TM-00 for nsis@ietf.org; Thu, 05 Jun 2003 11:37:08 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19Nwnc-0000T0-00 for nsis@ietf.org; Thu, 05 Jun 2003 11:37:08 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jun 2003 16:38:28 +0100 Message-ID: From: "Hancock, Robert" To: "'Tom Taylor'" , Georgios Karagiannis Cc: john.loughney@nokia.com, maarten.buchli@alcatel.be, nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation Date: Thu, 5 Jun 2003 16:38:26 +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 all, FWIW I had assumed that reassembly would probably take place at each NSIS-aware node. Apart from anything else, an NSIS-aware node probably couldn't work out what to do with a fragment (either whether to deliver it locally to an application or forward it, and if so even who to forward it to) without doing the reassembly. Of course, that's an NTLP design question, and you could also put enough data in each fragment to make them independently forwardable; that could be a Good Thing. Receiver fragmentation processing should not be a big deal. If an inbound packet isn't fragmented, it should say so. If it is, reassembly was needed anyway. [Reassembly isn't trivial, but there's a long-known body of knowledge in how to do it.] The key point - as several of us have pointed out - is that deciding how to handle the error conditions with a packet that is too big but which you can't fragment could be very difficult indeed. robert h. > -----Original Message----- > From: Tom Taylor [mailto:taylor@nortelnetworks.com] > Sent: 05 June 2003 16:10 > To: Georgios Karagiannis > Cc: john.loughney@nokia.com; maarten.buchli@alcatel.be; nsis@ietf.org > Subject: Re: [NSIS] framework: proposal on fragmentation > > > There are only two possibilities for point of reassembly: > after every NTLP hop, or > where the message is being delivered to NSLP. The latter is > complicated by the > possibility that one NTLP message may contain multiple NSLP > messages. On the other > hand, it seems like a waste to reassemble messages hop by > hop, only to break them > down again for the next hop. Of course, doing this means > that lost fragments can be > retrieved on a per hop basis rather than involving more nodes. > > In any event, I expect Georgios is concerned that the > receiving node has to execute > logic checking for fragmentation for every packet received, > even if fragmentation > can't happen in that particular application. If the reason > fragmentation won't > happen is a big MTU, I can almost follow his argument. If > the reason fragmentation > won't happen is the particular NSLP, I don't buy the > argument, because the other > NSLPs may also be bundled in. > > Georgios Karagiannis wrote: > > > Hi John and Maarten > > > > First of all if a message is fragmented has to be > reassembled somewhere. > > The NTLP will have to find out where the fragmentation and > the reassembly > > process has to be > > accomplished. This will require additional processing, even > if this it is > > not needed. > > In scenarios where performance in terms of processing > delays, number of > > states per flow, etc., > > is important, it should be possible that the fragmentation > at NTLP layer > > should be switched off and > > either assure that the NSLP messages are small enough such > that they will > > not be fragmented > > or do it in the NSLP if required. > > > > Best Regards, > > Georgios > > > [snip] > > _______________________________________________ > 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 Jun 5 11:58: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 LAA04497 for ; Thu, 5 Jun 2003 11:58:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55FwSC16493 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 11:58:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55FwMB16486; Thu, 5 Jun 2003 11:58:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55FvoB16461 for ; Thu, 5 Jun 2003 11:57:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04469 for ; Thu, 5 Jun 2003 11:57:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nx5o-0000cT-00 for nsis@ietf.org; Thu, 05 Jun 2003 11:55:56 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19Nx5n-0000cQ-00 for nsis@ietf.org; Thu, 05 Jun 2003 11:55:55 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h55Fvj5s011353; Thu, 5 Jun 2003 17:57:45 +0200 (MET DST) Message-ID: <016d01c32b7b$352ded80$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" , References: <76C92FBBFB58D411AE760090271ED41806AC11F9@rsys002a.roke.co.uk> Subject: Re: [NSIS] framework: proposal on bundling Date: Thu, 5 Jun 2003 17:57:46 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Robert I think that I have missed the following e-mail, regarding bundling. What you are actually saying here is that bundling at the NTLP layer should be possible, but it is not mandatory. If yes then I agree! Best Regards, Georgios ----- Original Message ----- From: "Hancock, Robert" To: Sent: Friday, May 23, 2003 12:01 PM Subject: [NSIS] framework: proposal on bundling > Dear all, > > We have a set of outanding issues on 'transport-like functions' and where they > should go in the NTLP/NSLP layer model. I'd like to make a sequence of proposals > about how these should be resolved, starting with the easy ones... > > 'Bundling' is 'getting more than one signalling application message into a > single network layer message'. (It was introduced as an RSVP option in 2961, > essentially for performance reasons.) > > My proposal is that the NTLP should support bundling. (A more precise statement: > an NTLP instance is free to decide whether or not to bundle messages together; > however, it should always be prepared to receive them - on the grounds that > implementing de-bundling is simpler than implementing a negotiation procedure. > implementing bundling is somewhat less trivial.) > > Based on past verbal/m.l. discussions i think this is not too controversial, > here is the reasoning: > *) whether or not messages are in a bundle has no semantic significance, and > no significance beyond the NTLP-hop over which they are bundled. > *) if only NSLPs could bundle, this would significantly restrict the scope > for doing this (only messages for the same signalling application could be > bundled). > *) bundling affects addressing - a bundled message has to be explicitly > addressed (not implicitly+router alert addressed), only the NTLP has the > intelligence to work out how/whether this is possible. > *) we don't prevent an NSLP providing an NTLP with a group of messages to send > at once (and recommending that the NTLP deliver them as a group) but this > is mainly an implementation/API issue. The NTLP may have to unbundle them > anyway. > > any objections? > > r. > _______________________________________________ > 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 Jun 5 12:42: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 MAA05805 for ; Thu, 5 Jun 2003 12:42:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55GgKM20702 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 12:42:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55GgDB20684; Thu, 5 Jun 2003 12:42:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55GfAB20651 for ; Thu, 5 Jun 2003 12:41:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05760 for ; Thu, 5 Jun 2003 12:41:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nxlj-0000xb-00 for nsis@ietf.org; Thu, 05 Jun 2003 12:39:15 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19Nxli-0000xX-00 for nsis@ietf.org; Thu, 05 Jun 2003 12:39:14 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h55Gf25s012808; Thu, 5 Jun 2003 18:41:02 +0200 (MET DST) Message-ID: <017701c32b81$41775120$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" Cc: References: Subject: Re: [NSIS] framework: proposal on fragmentation Date: Thu, 5 Jun 2003 18:41:04 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Robert > FWIW I had assumed that reassembly would probably take place at > each NSIS-aware node. Apart from anything else, an NSIS-aware node > probably couldn't work out what to do with a fragment (either whether > to deliver it locally to an application or forward it, and if so even > who to forward it to) without doing the reassembly. Yes, but this is additional fragmentation/reassembly functionality that will require additional processing, thus the performance behaviour of a node could be affected. Now if nodes do not support NTLP bundling and if the NSLP is designed in such a way that NTLP fragmentation is not needed, then the NTLP reassembly functionality, mentioned above, even if it is not needed, will affect negativelly the performance behaviour of the node. What I am actually proposing is that any NSLP should be able to specify if NTLP fragmentation/reassembly must be supported or not! Therefore, I am proposing that the NTLP fragmentation/reassembly feature should be optional. Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 5 13:04: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 NAA06543 for ; Thu, 5 Jun 2003 13:04:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55H4W221858 for nsis-archive@odin.ietf.org; Thu, 5 Jun 2003 13:04:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55H4QB21845; Thu, 5 Jun 2003 13:04:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h55H3xB21798 for ; Thu, 5 Jun 2003 13:03:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06518 for ; Thu, 5 Jun 2003 13:03:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ny7o-00018k-00 for nsis@ietf.org; Thu, 05 Jun 2003 13:02:04 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19Ny7n-00018b-00 for nsis@ietf.org; Thu, 05 Jun 2003 13:02:03 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h55H3Dq12959; Thu, 5 Jun 2003 13:03:14 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRLF0WSS; Thu, 5 Jun 2003 13:03:14 -0400 Received: from nortelnetworks.com (acart1cv.ca.nortel.com [47.129.129.71]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0QRX; Thu, 5 Jun 2003 13:03:14 -0400 Message-ID: <3EDF77C8.6050008@nortelnetworks.com> Date: Thu, 05 Jun 2003 13:03:04 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Georgios Karagiannis CC: "Hancock, Robert" , nsis@ietf.org Subject: Re: [NSIS] framework: proposal on fragmentation References: <017701c32b81$41775120$4c0d5982@dynamic.cs.utwente.nl> In-Reply-To: <017701c32b81$41775120$4c0d5982@dynamic.cs.utwente.nl> 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 Optionality doesn't work unless it is negotiated, which makes the protocol a lot more complicated. I can say my node doesn't support bundling, but what if the upstream node won't cooperate and sends me a bundled message? Georgios Karagiannis wrote: > Hi Robert > > >>FWIW I had assumed that reassembly would probably take place at >>each NSIS-aware node. Apart from anything else, an NSIS-aware node >>probably couldn't work out what to do with a fragment (either whether >>to deliver it locally to an application or forward it, and if so even >>who to forward it to) without doing the reassembly. > > > Yes, but this is additional fragmentation/reassembly functionality that will > require additional > processing, thus the performance behaviour of a node could be affected. > > Now if nodes do not support NTLP bundling and if the NSLP is designed in > such a way that > NTLP fragmentation is not needed, then the NTLP reassembly functionality, > mentioned above, even if it is not needed, will affect negativelly the > performance behaviour of the node. > > What I am actually proposing is that any NSLP should be able to specify if > NTLP fragmentation/reassembly must be > supported or not! > Therefore, I am proposing that the NTLP fragmentation/reassembly feature > should be optional. > > 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 Fri Jun 6 03:34: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 DAA13083 for ; Fri, 6 Jun 2003 03:34:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h567XXY30416 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 03:33:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h567XMB30409; Fri, 6 Jun 2003 03:33:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h567WMB30348 for ; Fri, 6 Jun 2003 03:32:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13061 for ; Fri, 6 Jun 2003 03:32:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OBgC-00077n-00 for nsis@ietf.org; Fri, 06 Jun 2003 03:30:28 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19OBgB-00077j-00 for nsis@ietf.org; Fri, 06 Jun 2003 03:30:27 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h567WI0J007053; Fri, 6 Jun 2003 09:32:18 +0200 (MEST) Received: from era.ericsson.se (E00104B7F41BB.ki.sw.ericsson.se [147.214.181.136]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGG34NC; Fri, 6 Jun 2003 09:33:24 +0200 Message-ID: <3EE04371.B602AB56@era.ericsson.se> Date: Fri, 06 Jun 2003 09:32:02 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lars.Westberg" X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Tom Taylor CC: Georgios Karagiannis , "Hancock, Robert" , nsis@ietf.org Subject: Re: [NSIS] framework: proposal on fragmentation References: <017701c32b81$41775120$4c0d5982@dynamic.cs.utwente.nl> <3EDF77C8.6050008@nortelnetworks.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 Isn't the functionality in NTLP dependent on NSLP. If a certain NSLP do not want to have bundling and fragementation. Should that not be supported by NTLP ? The selection of NTLP-functionality may be coupled to a certain NSLP-type. In that case you I think that you do not need to have negotiation between different NTLP-instances or.. ? regards Lasse Tom Taylor wrote: > Optionality doesn't work unless it is negotiated, which makes the protocol a lot > more complicated. I can say my node doesn't support bundling, but what if the > upstream node won't cooperate and sends me a bundled message? > > Georgios Karagiannis wrote: > > > Hi Robert > > > > > >>FWIW I had assumed that reassembly would probably take place at > >>each NSIS-aware node. Apart from anything else, an NSIS-aware node > >>probably couldn't work out what to do with a fragment (either whether > >>to deliver it locally to an application or forward it, and if so even > >>who to forward it to) without doing the reassembly. > > > > > > Yes, but this is additional fragmentation/reassembly functionality that will > > require additional > > processing, thus the performance behaviour of a node could be affected. > > > > Now if nodes do not support NTLP bundling and if the NSLP is designed in > > such a way that > > NTLP fragmentation is not needed, then the NTLP reassembly functionality, > > mentioned above, even if it is not needed, will affect negativelly the > > performance behaviour of the node. > > > > What I am actually proposing is that any NSLP should be able to specify if > > NTLP fragmentation/reassembly must be > > supported or not! > > Therefore, I am proposing that the NTLP fragmentation/reassembly feature > > should be optional. > > > > 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 03:51: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 DAA13307 for ; Fri, 6 Jun 2003 03:51:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h567oaM31762 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 03:50:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h567oQB31754; Fri, 6 Jun 2003 03:50:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h567n7B31722 for ; Fri, 6 Jun 2003 03:49:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13296 for ; Fri, 6 Jun 2003 03:49:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OBwO-0007B8-00 for nsis@ietf.org; Fri, 06 Jun 2003 03:47:12 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19OBwN-0007B5-00 for nsis@ietf.org; Fri, 06 Jun 2003 03:47:12 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jun 2003 08:49:04 +0100 Message-ID: From: "Hancock, Robert" To: "'Lars.Westberg'" , Tom Taylor Cc: Georgios Karagiannis , nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation Date: Fri, 6 Jun 2003 08:49:01 +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: , dear all, As a general point, I don't think it is practical to fine tune NTLP functionality to NSLP requirements, except by requesting additional treatment at the message level. (This sentence may be clarified below.) The reason is that we have essentially a 'flat' NTLP where an instance has to support all signalling application traffic passing through that node, even if the node doesn't support that application (FW section 3.2.1 if you've forgotten). So an NTLP never knows what NSLPs it is going to have to handle, and an NSLP can't tell downstream NTLP nodes what to support. [An alternative architecture, where there was NSLP-sensitive explicit next-NTLP-peer discovery and a more session-oriented signalling association between NSLP peers, would enable alternative solutions. But we aren't doing that.] In practice, we have to consider how this works function by function, and whether functions can be selectively invoked. In some cases, I think we will have functions which are mandatory to implement in the receiver, and optional to implement in the sender - this is the case for bundling, where the receiver processing is trivial. For fragmentation, what I find conceptually simplest is mandatory at both ends, or else there needs to be a simple answer to the question 'what happens when an interior NTLP node (not colocated with the NSLP) is given a message it can't forward'. cheers, r. > -----Original Message----- > From: Lars.Westberg [mailto:Lars.Westberg@era.ericsson.se] > Sent: 06 June 2003 08:32 > To: Tom Taylor > Cc: Georgios Karagiannis; Hancock, Robert; nsis@ietf.org > Subject: Re: [NSIS] framework: proposal on fragmentation > > > Isn't the functionality in NTLP dependent on NSLP. If a > certain NSLP do not want to > have > bundling and fragementation. Should that not be supported by NTLP ? > > The selection of NTLP-functionality may be coupled to a > certain NSLP-type. > In that case you I think that you do not need to have > negotiation between different > NTLP-instances or.. ? > > > regards Lasse > Tom Taylor wrote: > > > Optionality doesn't work unless it is negotiated, which > makes the protocol a lot > > more complicated. I can say my node doesn't support > bundling, but what if the > > upstream node won't cooperate and sends me a bundled message? > > > > Georgios Karagiannis wrote: > > > > > Hi Robert > > > > > > > > >>FWIW I had assumed that reassembly would probably take place at > > >>each NSIS-aware node. Apart from anything else, an NSIS-aware node > > >>probably couldn't work out what to do with a fragment > (either whether > > >>to deliver it locally to an application or forward it, > and if so even > > >>who to forward it to) without doing the reassembly. > > > > > > > > > Yes, but this is additional fragmentation/reassembly > functionality that will > > > require additional > > > processing, thus the performance behaviour of a node > could be affected. > > > > > > Now if nodes do not support NTLP bundling and if the NSLP > is designed in > > > such a way that > > > NTLP fragmentation is not needed, then the NTLP > reassembly functionality, > > > mentioned above, even if it is not needed, will affect > negativelly the > > > performance behaviour of the node. > > > > > > What I am actually proposing is that any NSLP should be > able to specify if > > > NTLP fragmentation/reassembly must be > > > supported or not! > > > Therefore, I am proposing that the NTLP > fragmentation/reassembly feature > > > should be optional. > > > > > > 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 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 03:54: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 DAA13367 for ; Fri, 6 Jun 2003 03:54:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h567sAD31896 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 03:54:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h567s3B31889; Fri, 6 Jun 2003 03:54:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h567r7B31860 for ; Fri, 6 Jun 2003 03:53:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13334 for ; Fri, 6 Jun 2003 03:53:05 -0400 (EDT) From: maarten.buchli@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OC0G-0007C0-00 for nsis@ietf.org; Fri, 06 Jun 2003 03:51:12 -0400 Received: from alc245.alcatel.be ([195.207.101.245] helo=relay4.alcatel.be) by ietf-mx with esmtp (Exim 4.12) id 19OC0F-0007Bs-00 for nsis@ietf.org; Fri, 06 Jun 2003 03:51:11 -0400 Received: from bemail05.net.alcatel.be (bemail05.net.alcatel.be [138.203.144.16]) by relay4.alcatel.be (8.12.9/8.12.9) with ESMTP id h568374h028585; Fri, 6 Jun 2003 10:03:07 +0200 Subject: Re: [NSIS] framework: proposal on fragmentation To: "Lars.Westberg" Cc: Tom Taylor , Georgios Karagiannis , "Hancock, Robert" , nsis@ietf.org Date: Fri, 6 Jun 2003 09:52:32 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 06/06/2003 09:52:33 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) 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, Functionality and use of e.g. message bundeling should be transparent to the NSLP layer. I do not see any benefit in making the NSLP aware of e.g. bundling. It seems to me that these are local decisions of the NTLP layer. Maarten "Lars.Westberg" @ietf.org on 06/06/2003 09:32:02 Sent by: nsis-admin@ietf.org To: Tom Taylor cc: Georgios Karagiannis , "Hancock, Robert" , nsis@ietf.org Subject: Re: [NSIS] framework: proposal on fragmentation Isn't the functionality in NTLP dependent on NSLP. If a certain NSLP do not want to have bundling and fragementation. Should that not be supported by NTLP ? The selection of NTLP-functionality may be coupled to a certain NSLP-type. In that case you I think that you do not need to have negotiation between different NTLP-instances or.. ? regards Lasse Tom Taylor wrote: > Optionality doesn't work unless it is negotiated, which makes the protocol a lot > more complicated. I can say my node doesn't support bundling, but what if the > upstream node won't cooperate and sends me a bundled message? > > Georgios Karagiannis wrote: > > > Hi Robert > > > > > >>FWIW I had assumed that reassembly would probably take place at > >>each NSIS-aware node. Apart from anything else, an NSIS-aware node > >>probably couldn't work out what to do with a fragment (either whether > >>to deliver it locally to an application or forward it, and if so even > >>who to forward it to) without doing the reassembly. > > > > > > Yes, but this is additional fragmentation/reassembly functionality that will > > require additional > > processing, thus the performance behaviour of a node could be affected. > > > > Now if nodes do not support NTLP bundling and if the NSLP is designed in > > such a way that > > NTLP fragmentation is not needed, then the NTLP reassembly functionality, > > mentioned above, even if it is not needed, will affect negativelly the > > performance behaviour of the node. > > > > What I am actually proposing is that any NSLP should be able to specify if > > NTLP fragmentation/reassembly must be > > supported or not! > > Therefore, I am proposing that the NTLP fragmentation/reassembly feature > > should be optional. > > > > 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 _______________________________________________ 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 Jun 6 03:56: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 DAA13427 for ; Fri, 6 Jun 2003 03:56:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h567uCr32006 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 03:56:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h567u7B31999; Fri, 6 Jun 2003 03:56:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h567tnB31967 for ; Fri, 6 Jun 2003 03:55:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13417 for ; Fri, 6 Jun 2003 03:55:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OC2s-0007DR-00 for nsis@ietf.org; Fri, 06 Jun 2003 03:53:54 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19OC2r-0007DA-00 for nsis@ietf.org; Fri, 06 Jun 2003 03:53:53 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jun 2003 08:55:16 +0100 Message-ID: From: "Hancock, Robert" To: "'Georgios Karagiannis'" Cc: nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation Date: Fri, 6 Jun 2003 08:55:15 +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: , georgios, i think the answer to your question would be provided by adopting the alternative fragmentation strategy in my email, which i'll reproduce here (since you deleted it): "...you could also put enough data in each fragment to make them independently forwardable; that could be a Good Thing." - so in other words, reassembly takes place only where (at whatever node) it is needed by the application, and we are just talking about which layer to do it in. It would probably be sensible in this case to make a (not unreasonable) design decision that an NTLP instance shouldn't fragment a bundled message, it should unbundle it first. But these are all points about designing an efficient NTLP, they don't affect the definition of the layer split. As Maarten has just pointed out, the NSLP shouldn't even be aware that bundling is taking place, and I'd like the same to apply to fragmentation also. cheers, r. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 05 June 2003 17:41 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: [NSIS] framework: proposal on fragmentation > > > Hi Robert > > > FWIW I had assumed that reassembly would probably take place at > > each NSIS-aware node. Apart from anything else, an NSIS-aware node > > probably couldn't work out what to do with a fragment > (either whether > > to deliver it locally to an application or forward it, and > if so even > > who to forward it to) without doing the reassembly. > > Yes, but this is additional fragmentation/reassembly > functionality that will > require additional > processing, thus the performance behaviour of a node could be > affected. > > Now if nodes do not support NTLP bundling and if the NSLP is > designed in > such a way that > NTLP fragmentation is not needed, then the NTLP reassembly > functionality, > mentioned above, even if it is not needed, will affect negativelly the > performance behaviour of the node. > > What I am actually proposing is that any NSLP should be able > to specify if > NTLP fragmentation/reassembly must be > supported or not! > Therefore, I am proposing that the NTLP > fragmentation/reassembly feature > should be optional. > > Best regards, > Georgios > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 04:09: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 EAA13626 for ; Fri, 6 Jun 2003 04:09:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5689De01307 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 04:09:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56897B01292; Fri, 6 Jun 2003 04:09:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5688oB01266 for ; Fri, 6 Jun 2003 04:08:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13616 for ; Fri, 6 Jun 2003 04:08:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OCFT-0007G6-00 for nsis@ietf.org; Fri, 06 Jun 2003 04:06:55 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19OCFS-0007G3-00 for nsis@ietf.org; Fri, 06 Jun 2003 04:06:54 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h5688j5s005545; Fri, 6 Jun 2003 10:08:46 +0200 (MET DST) Message-ID: <002601c32c02$dafa4f60$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" Cc: References: Subject: Re: [NSIS] framework: proposal on fragmentation Date: Fri, 6 Jun 2003 10:08:46 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Robert > For fragmentation, > what I find conceptually simplest is mandatory at both ends, or else > there needs to be a simple answer to the question 'what happens when > an interior NTLP node (not colocated with the NSLP) is given a message > it can't forward'. If an application that uses a NSLP can solve the problem of fragmentation by its own then the situation that you describe will not happen. And if this happens then the application is aware of that. Please note that the mandatory support of a feature in the NTLP can affect the performance unnecessary. If this happens to often then there is a chance that the NSIS protocol will not be deployed on a large scale. Please try to be flexible when there is a tradeoff between protocol perfromance and support of a long list of mandatory features. Best regards, Georgios ----- Original Message ----- From: "Hancock, Robert" To: "'Lars.Westberg'" ; "Tom Taylor" Cc: "Georgios Karagiannis" ; Sent: Friday, June 06, 2003 9:49 AM Subject: RE: [NSIS] framework: proposal on fragmentation > dear all, > > As a general point, I don't think it is practical to fine tune NTLP > functionality to NSLP requirements, except by requesting additional > treatment at the message level. (This sentence may be clarified below.) > > The reason is that we have essentially a 'flat' NTLP where an instance > has to support all signalling application traffic passing through > that node, even if the node doesn't support that application (FW section > 3.2.1 if you've forgotten). So an NTLP never knows what NSLPs it is > going to have to handle, and an NSLP can't tell downstream NTLP nodes > what to support. > > [An alternative architecture, where there was NSLP-sensitive explicit > next-NTLP-peer discovery and a more session-oriented signalling association > between NSLP peers, would enable alternative solutions. But we aren't > doing that.] > > In practice, we have to consider how this works function by function, > and whether functions can be selectively invoked. In some cases, I think > we will have functions which are mandatory to implement in the receiver, > and optional to implement in the sender - this is the case for > bundling, where the receiver processing is trivial. For fragmentation, > what I find conceptually simplest is mandatory at both ends, or else > there needs to be a simple answer to the question 'what happens when > an interior NTLP node (not colocated with the NSLP) is given a message > it can't forward'. > > cheers, > > r. > > > -----Original Message----- > > From: Lars.Westberg [mailto:Lars.Westberg@era.ericsson.se] > > Sent: 06 June 2003 08:32 > > To: Tom Taylor > > Cc: Georgios Karagiannis; Hancock, Robert; nsis@ietf.org > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > Isn't the functionality in NTLP dependent on NSLP. If a > > certain NSLP do not want to > > have > > bundling and fragementation. Should that not be supported by NTLP ? > > > > The selection of NTLP-functionality may be coupled to a > > certain NSLP-type. > > In that case you I think that you do not need to have > > negotiation between different > > NTLP-instances or.. ? > > > > > > regards Lasse > > Tom Taylor wrote: > > > > > Optionality doesn't work unless it is negotiated, which > > makes the protocol a lot > > > more complicated. I can say my node doesn't support > > bundling, but what if the > > > upstream node won't cooperate and sends me a bundled message? > > > > > > Georgios Karagiannis wrote: > > > > > > > Hi Robert > > > > > > > > > > > >>FWIW I had assumed that reassembly would probably take place at > > > >>each NSIS-aware node. Apart from anything else, an NSIS-aware node > > > >>probably couldn't work out what to do with a fragment > > (either whether > > > >>to deliver it locally to an application or forward it, > > and if so even > > > >>who to forward it to) without doing the reassembly. > > > > > > > > > > > > Yes, but this is additional fragmentation/reassembly > > functionality that will > > > > require additional > > > > processing, thus the performance behaviour of a node > > could be affected. > > > > > > > > Now if nodes do not support NTLP bundling and if the NSLP > > is designed in > > > > such a way that > > > > NTLP fragmentation is not needed, then the NTLP > > reassembly functionality, > > > > mentioned above, even if it is not needed, will affect > > negativelly the > > > > performance behaviour of the node. > > > > > > > > What I am actually proposing is that any NSLP should be > > able to specify if > > > > NTLP fragmentation/reassembly must be > > > > supported or not! > > > > Therefore, I am proposing that the NTLP > > fragmentation/reassembly feature > > > > should be optional. > > > > > > > > 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 > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 04:34: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 EAA14044 for ; Fri, 6 Jun 2003 04:34:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h568YTb02442 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 04:34:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h568YJB02419; Fri, 6 Jun 2003 04:34:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h568XnB02400 for ; Fri, 6 Jun 2003 04:33:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14012 for ; Fri, 6 Jun 2003 04:33:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OCdd-0007N9-00 for nsis@ietf.org; Fri, 06 Jun 2003 04:31:53 -0400 Received: from h3s128a211n47.user.nortelnetworks.com ([47.211.128.3] helo=znsgs01r.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19OCdc-0007N5-00 for nsis@ietf.org; Fri, 06 Jun 2003 04:31:52 -0400 Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h568Wtl12041; Fri, 6 Jun 2003 09:32:55 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jun 2003 09:32:08 +0100 Message-ID: From: "Daniel Warren" To: "'Georgios Karagiannis'" , "Hancock, Robert" Cc: nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation Date: Fri, 6 Jun 2003 09:32:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32C06.1D2F669C" 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_01C32C06.1D2F669C Content-Type: text/plain; charset="iso-8859-1" I still think we are missing a couple of points here, which Robert has got close to but hasn't stated explicitly. Optionality of a feature is only really optional on a node initiating the feature. So, ignoring interim nodes for now, even if fragmentation is optional, any node that can receive NSIS messages has to support re-assembly because it does not know what form the information it is going to get will take - it might not be fragmented, but equally it might, and if it is it will need to be able to reassemble. So by making fragmentation optional, all you are actually saying is that you may have nodes where the actually chopping up of the message (which is not a particularly complex task) is not supported. The exception to this rule is a situation where your nodes only use the 'small messages' NSLP type that Georgios mentioned way back in the thread, and even then that makes that NSLP pretty inflexible to future growth. As for if reassembly needs to happen only at the receiver or at every node in between it depends upon what degree of complexity you want to add to your route managament. Consider a path that goes through a number of interim nodes to get to it's destination. That will mean a number of interim links which may have different MTU size per hop. If you don't want to reassemble and segment at each node then the node that is doing the fragmentation will need to know the MTU size for every hop to the destination and fragment to meet the minimum requirement (otherwise there will be a link where the packets being sent exceed the MTU size and the packets will get dumped). One solution to that is to use Roberts proposal of segmenting and reassembling per hop. the other would be to allow interim nodes to segment the segments if it needs to, maybe lower down the stack. Just some thoughts really. Dan -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] Sent: 06 June 2003 09:09 To: Hancock, Robert Cc: nsis@ietf.org Subject: Re: [NSIS] framework: proposal on fragmentation Hi Robert > For fragmentation, > what I find conceptually simplest is mandatory at both ends, or else > there needs to be a simple answer to the question 'what happens when > an interior NTLP node (not colocated with the NSLP) is given a message > it can't forward'. If an application that uses a NSLP can solve the problem of fragmentation by its own then the situation that you describe will not happen. And if this happens then the application is aware of that. Please note that the mandatory support of a feature in the NTLP can affect the performance unnecessary. If this happens to often then there is a chance that the NSIS protocol will not be deployed on a large scale. Please try to be flexible when there is a tradeoff between protocol perfromance and support of a long list of mandatory features. Best regards, Georgios ----- Original Message ----- From: "Hancock, Robert" To: "'Lars.Westberg'" ; "Tom Taylor" Cc: "Georgios Karagiannis" ; Sent: Friday, June 06, 2003 9:49 AM Subject: RE: [NSIS] framework: proposal on fragmentation > dear all, > > As a general point, I don't think it is practical to fine tune NTLP > functionality to NSLP requirements, except by requesting additional > treatment at the message level. (This sentence may be clarified below.) > > The reason is that we have essentially a 'flat' NTLP where an instance > has to support all signalling application traffic passing through > that node, even if the node doesn't support that application (FW section > 3.2.1 if you've forgotten). So an NTLP never knows what NSLPs it is > going to have to handle, and an NSLP can't tell downstream NTLP nodes > what to support. > > [An alternative architecture, where there was NSLP-sensitive explicit > next-NTLP-peer discovery and a more session-oriented signalling association > between NSLP peers, would enable alternative solutions. But we aren't > doing that.] > > In practice, we have to consider how this works function by function, > and whether functions can be selectively invoked. In some cases, I think > we will have functions which are mandatory to implement in the receiver, > and optional to implement in the sender - this is the case for > bundling, where the receiver processing is trivial. For fragmentation, > what I find conceptually simplest is mandatory at both ends, or else > there needs to be a simple answer to the question 'what happens when > an interior NTLP node (not colocated with the NSLP) is given a message > it can't forward'. > > cheers, > > r. > > > -----Original Message----- > > From: Lars.Westberg [mailto:Lars.Westberg@era.ericsson.se] > > Sent: 06 June 2003 08:32 > > To: Tom Taylor > > Cc: Georgios Karagiannis; Hancock, Robert; nsis@ietf.org > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > Isn't the functionality in NTLP dependent on NSLP. If a > > certain NSLP do not want to > > have > > bundling and fragementation. Should that not be supported by NTLP ? > > > > The selection of NTLP-functionality may be coupled to a > > certain NSLP-type. > > In that case you I think that you do not need to have > > negotiation between different > > NTLP-instances or.. ? > > > > > > regards Lasse > > Tom Taylor wrote: > > > > > Optionality doesn't work unless it is negotiated, which > > makes the protocol a lot > > > more complicated. I can say my node doesn't support > > bundling, but what if the > > > upstream node won't cooperate and sends me a bundled message? > > > > > > Georgios Karagiannis wrote: > > > > > > > Hi Robert > > > > > > > > > > > >>FWIW I had assumed that reassembly would probably take place at > > > >>each NSIS-aware node. Apart from anything else, an NSIS-aware node > > > >>probably couldn't work out what to do with a fragment > > (either whether > > > >>to deliver it locally to an application or forward it, > > and if so even > > > >>who to forward it to) without doing the reassembly. > > > > > > > > > > > > Yes, but this is additional fragmentation/reassembly > > functionality that will > > > > require additional > > > > processing, thus the performance behaviour of a node > > could be affected. > > > > > > > > Now if nodes do not support NTLP bundling and if the NSLP > > is designed in > > > > such a way that > > > > NTLP fragmentation is not needed, then the NTLP > > reassembly functionality, > > > > mentioned above, even if it is not needed, will affect > > negativelly the > > > > performance behaviour of the node. > > > > > > > > What I am actually proposing is that any NSLP should be > > able to specify if > > > > NTLP fragmentation/reassembly must be > > > > supported or not! > > > > Therefore, I am proposing that the NTLP > > fragmentation/reassembly feature > > > > should be optional. > > > > > > > > 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 > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_001_01C32C06.1D2F669C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] framework: proposal on fragmentation

I still think we are missing a couple of points here, = which Robert has got close to but hasn't stated explicitly.

Optionality of a feature is only really optional on a = node initiating the feature.  So, ignoring interim nodes for now, = even if fragmentation is optional, any node that can receive NSIS = messages has to support re-assembly because it does not know what form = the information it is going to get will take - it might not be = fragmented, but equally it might, and if it is it will need to be able = to reassemble.

So by making fragmentation optional, all you are = actually saying is that you may have nodes where the actually chopping = up of the message (which is not a particularly complex task) is not = supported.  The exception to this rule is a situation where your = nodes only use the 'small messages' NSLP type that Georgios mentioned = way back in the thread, and even then that makes that NSLP pretty = inflexible to future growth.

As for if reassembly needs to happen only at the = receiver or at every node in between it depends upon what degree of = complexity you want to add to your route managament.  Consider a = path that goes through a number of interim nodes to get to it's = destination.  That will mean a number of interim links which may = have different MTU size per hop.  If you don't want to reassemble = and segment at each node then the node that is doing the fragmentation = will need to know the MTU size for every hop to the destination and = fragment to meet the minimum requirement (otherwise there will be a = link where the packets being sent exceed the MTU size and the packets = will get dumped).  One solution to that is to use Roberts proposal = of segmenting and reassembling per hop.  the other would be to = allow interim nodes to segment the segments if it needs to, maybe lower = down the stack.

Just some thoughts really.

Dan

-----Original Message-----
From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl= ]
Sent: 06 June 2003 09:09
To: Hancock, Robert
Cc: nsis@ietf.org
Subject: Re: [NSIS] framework: proposal on = fragmentation


Hi Robert

> For fragmentation,
> what I find conceptually simplest is mandatory = at both ends, or else
> there needs to be a simple answer to the = question 'what happens when
> an interior NTLP node (not colocated with the = NSLP) is given a message
> it can't forward'.

If an application that uses a NSLP can solve the = problem of fragmentation by
its own
then the situation that you describe will not = happen. And if this happens
then the application is
aware of that.

Please note that the mandatory support of a feature = in the NTLP can affect
the
performance unnecessary.  If this happens to = often then there is a chance
that the
NSIS protocol will not be deployed on a large scale.<= /FONT>

Please try to be flexible when there is a tradeoff = between protocol
perfromance and support
of a long list of mandatory features.

Best regards,
Georgios


----- Original Message -----
From: "Hancock, Robert" = <robert.hancock@roke.co.uk>
To: "'Lars.Westberg'" = <Lars.Westberg@era.ericsson.se>; "Tom Taylor"
<taylor@nortelnetworks.com>
Cc: "Georgios Karagiannis" = <karagian@cs.utwente.nl>; <nsis@ietf.org>
Sent: Friday, June 06, 2003 9:49 AM
Subject: RE: [NSIS] framework: proposal on = fragmentation


> dear all,
>
> As a general point, I don't think it is = practical to fine tune NTLP
> functionality to NSLP requirements, except by = requesting additional
> treatment at the message level. (This sentence = may be clarified below.)
>
> The reason is that we have essentially a 'flat' = NTLP where an instance
> has to support all signalling application = traffic passing through
> that node, even if the node doesn't support = that application (FW section
> 3.2.1 if you've forgotten). So an NTLP never = knows what NSLPs it is
> going to have to handle, and an NSLP can't tell = downstream NTLP nodes
> what to support.
>
> [An alternative architecture, where there was = NSLP-sensitive explicit
> next-NTLP-peer discovery and a more = session-oriented signalling
association
> between NSLP peers, would enable alternative = solutions. But we aren't
> doing that.]
>
> In practice, we have to consider how this works = function by function,
> and whether functions can be selectively = invoked. In some cases, I think
> we will have functions which are mandatory to = implement in the receiver,
> and optional to implement in the sender - this = is the case for
> bundling, where the receiver processing is = trivial. For fragmentation,
> what I find conceptually simplest is mandatory = at both ends, or else
> there needs to be a simple answer to the = question 'what happens when
> an interior NTLP node (not colocated with the = NSLP) is given a message
> it can't forward'.
>
> cheers,
>
> r.
>
> > -----Original Message-----
> > From: Lars.Westberg [mailto:Lars.Westberg@era.e= ricsson.se]
> > Sent: 06 June 2003 08:32
> > To: Tom Taylor
> > Cc: Georgios Karagiannis; Hancock, Robert; = nsis@ietf.org
> > Subject: Re: [NSIS] framework: proposal on = fragmentation
> >
> >
> > Isn't the functionality in NTLP dependent = on NSLP. If a
> > certain NSLP do not want to
> > have
> > bundling and fragementation. Should that = not be supported by NTLP ?
> >
> > The selection of NTLP-functionality may be = coupled to a
> > certain NSLP-type.
> > In that case you I think that you do not = need to have
> > negotiation between different
> > NTLP-instances or.. ?
> >
> >
> > regards Lasse
> > Tom Taylor wrote:
> >
> > > Optionality doesn't work unless it is = negotiated, which
> > makes the protocol a lot
> > > more complicated.  I can say my = node doesn't support
> > bundling, but what if the
> > > upstream node won't cooperate and = sends me a bundled message?
> > >
> > > Georgios Karagiannis wrote:
> > >
> > > > Hi Robert
> > > >
> > > >
> > > >>FWIW I had assumed that = reassembly would probably take place at
> > > >>each NSIS-aware node. Apart = from anything else, an NSIS-aware node
> > > >>probably couldn't work out = what to do with a fragment
> > (either whether
> > > >>to deliver it locally to an = application or forward it,
> > and if so even
> > > >>who to forward it to) without = doing the reassembly.
> > > >
> > > >
> > > > Yes, but this is additional = fragmentation/reassembly
> > functionality that will
> > > > require  additional
> > > > processing, thus the performance = behaviour of a node
> > could be affected.
> > > >
> > > > Now if nodes do not support NTLP = bundling and if the NSLP
> > is designed in
> > > > such a way that
> > > > NTLP fragmentation is not = needed,  then the NTLP
> > reassembly functionality,
> > > > mentioned above, even if it is = not needed, will affect
> > negativelly the
> > > > performance behaviour of the = node.
> > > >
> > > > What I am actually proposing is = that any NSLP should be
> > able to specify if
> > > > NTLP fragmentation/reassembly = must be
> > > > supported or not!
> > > > Therefore, I am proposing that = the NTLP
> > fragmentation/reassembly feature
> > > > should be optional.
> > > >
> > > > 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=
> >
>

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis=

------_=_NextPart_001_01C32C06.1D2F669C-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 04:42: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 EAA14214 for ; Fri, 6 Jun 2003 04:42:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h568gBC03806 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 04:42:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h568g6B03799; Fri, 6 Jun 2003 04:42:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h568fOB03737 for ; Fri, 6 Jun 2003 04:41:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14167 for ; Fri, 6 Jun 2003 04:41:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OCky-0007Pd-00 for nsis@ietf.org; Fri, 06 Jun 2003 04:39:28 -0400 Received: from [62.225.183.202] (helo=mail1.telekom.de) by ietf-mx with esmtp (Exim 4.12) id 19OCkx-0007PH-00 for nsis@ietf.org; Fri, 06 Jun 2003 04:39:27 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Fri, 6 Jun 2003 10:40:49 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jun 2003 10:40:48 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB4BE@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: Lars.Westberg@era.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation Date: Fri, 6 Jun 2003 10:40:47 +0200 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 Lasse, | The selection of NTLP-functionality may be coupled to a | certain NSLP-type. This sounds like NSLP specific NTLPs. We don't need a layer split in that case. Like Robert, I don't support this proposal. | In that case you I think that you do not need to have | negotiation between different | NTLP-instances or.. ? Negotiation of options between NTLP-instances isn't desireable from an operators point of view. I understand that at some level within the protocol stack there must be awareness of the path MTU size. We should be careful not to overengineer our solution. If NSIS uses a transport protocol below NTLP which handles the MTU issue, let's make it the default. This would also simplify bundeling within NTLP, wouldn't it? Regards, Rudiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 05:25: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 FAA15077 for ; Fri, 6 Jun 2003 05:25:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h569PIC06294 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 05:25:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h569P8B06269; Fri, 6 Jun 2003 05:25:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h569OZB06209 for ; Fri, 6 Jun 2003 05:24:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15035 for ; Fri, 6 Jun 2003 05:24:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ODQk-0007gG-00 for nsis@ietf.org; Fri, 06 Jun 2003 05:22:38 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19ODQj-0007gD-00 for nsis@ietf.org; Fri, 06 Jun 2003 05:22:37 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h569OR5s008730; Fri, 6 Jun 2003 11:24:28 +0200 (MET DST) Message-ID: <007201c32c0d$6e5ea800$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Daniel Warren" Cc: References: Subject: Re: [NSIS] framework: proposal on fragmentation Date: Fri, 6 Jun 2003 11:24:28 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006F_01C32C1E.318F45E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 is a multi-part message in MIME format. ------=_NextPart_000_006F_01C32C1E.318F45E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] framework: proposal on fragmentationHi Daniel Sorry, I will repeat this again: If an application that uses a NSLP can solve the problem of = fragmentation by=20 its own then you do not need to activate the fragmentation/reassembly = features. By activate I mean that you initiate these features without really using = them. This can be solved very easily; the sender NSLP, by using the NSLP/NTLP = API,=20 will inform the NTLP protocol to swicth off the fragmenation option. Beste Regards, Georgios ----- Original Message -----=20 From: Daniel Warren=20 To: 'Georgios Karagiannis' ; Hancock, Robert=20 Cc: nsis@ietf.org=20 Sent: Friday, June 06, 2003 10:32 AM Subject: RE: [NSIS] framework: proposal on fragmentation I still think we are missing a couple of points here, which Robert has = got close to but hasn't stated explicitly.=20 Optionality of a feature is only really optional on a node initiating = the feature. So, ignoring interim nodes for now, even if fragmentation = is optional, any node that can receive NSIS messages has to support = re-assembly because it does not know what form the information it is = going to get will take - it might not be fragmented, but equally it = might, and if it is it will need to be able to reassemble. So by making fragmentation optional, all you are actually saying is = that you may have nodes where the actually chopping up of the message = (which is not a particularly complex task) is not supported. The = exception to this rule is a situation where your nodes only use the = 'small messages' NSLP type that Georgios mentioned way back in the = thread, and even then that makes that NSLP pretty inflexible to future = growth. As for if reassembly needs to happen only at the receiver or at every = node in between it depends upon what degree of complexity you want to = add to your route managament. Consider a path that goes through a = number of interim nodes to get to it's destination. That will mean a = number of interim links which may have different MTU size per hop. If = you don't want to reassemble and segment at each node then the node that = is doing the fragmentation will need to know the MTU size for every hop = to the destination and fragment to meet the minimum requirement = (otherwise there will be a link where the packets being sent exceed the = MTU size and the packets will get dumped). One solution to that is to = use Roberts proposal of segmenting and reassembling per hop. the other = would be to allow interim nodes to segment the segments if it needs to, = maybe lower down the stack. Just some thoughts really.=20 Dan=20 -----Original Message-----=20 From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl]=20 Sent: 06 June 2003 09:09=20 To: Hancock, Robert=20 Cc: nsis@ietf.org=20 Subject: Re: [NSIS] framework: proposal on fragmentation=20 Hi Robert=20 > For fragmentation,=20 > what I find conceptually simplest is mandatory at both ends, or else = > there needs to be a simple answer to the question 'what happens when = > an interior NTLP node (not colocated with the NSLP) is given a = message=20 > it can't forward'.=20 If an application that uses a NSLP can solve the problem of = fragmentation by=20 its own=20 then the situation that you describe will not happen. And if this = happens=20 then the application is=20 aware of that.=20 Please note that the mandatory support of a feature in the NTLP can = affect=20 the=20 performance unnecessary. If this happens to often then there is a = chance=20 that the=20 NSIS protocol will not be deployed on a large scale.=20 Please try to be flexible when there is a tradeoff between protocol=20 perfromance and support=20 of a long list of mandatory features.=20 Best regards,=20 Georgios=20 ----- Original Message -----=20 From: "Hancock, Robert" =20 To: "'Lars.Westberg'" ; "Tom Taylor"=20 =20 Cc: "Georgios Karagiannis" ; =20 Sent: Friday, June 06, 2003 9:49 AM=20 Subject: RE: [NSIS] framework: proposal on fragmentation=20 > dear all,=20 >=20 > As a general point, I don't think it is practical to fine tune NTLP=20 > functionality to NSLP requirements, except by requesting additional=20 > treatment at the message level. (This sentence may be clarified = below.)=20 >=20 > The reason is that we have essentially a 'flat' NTLP where an = instance=20 > has to support all signalling application traffic passing through=20 > that node, even if the node doesn't support that application (FW = section=20 > 3.2.1 if you've forgotten). So an NTLP never knows what NSLPs it is=20 > going to have to handle, and an NSLP can't tell downstream NTLP = nodes=20 > what to support.=20 >=20 > [An alternative architecture, where there was NSLP-sensitive = explicit=20 > next-NTLP-peer discovery and a more session-oriented signalling=20 association=20 > between NSLP peers, would enable alternative solutions. But we = aren't=20 > doing that.]=20 >=20 > In practice, we have to consider how this works function by = function,=20 > and whether functions can be selectively invoked. In some cases, I = think=20 > we will have functions which are mandatory to implement in the = receiver,=20 > and optional to implement in the sender - this is the case for=20 > bundling, where the receiver processing is trivial. For = fragmentation,=20 > what I find conceptually simplest is mandatory at both ends, or else = > there needs to be a simple answer to the question 'what happens when = > an interior NTLP node (not colocated with the NSLP) is given a = message=20 > it can't forward'.=20 >=20 > cheers,=20 >=20 > r.=20 >=20 > > -----Original Message-----=20 > > From: Lars.Westberg [mailto:Lars.Westberg@era.ericsson.se]=20 > > Sent: 06 June 2003 08:32=20 > > To: Tom Taylor=20 > > Cc: Georgios Karagiannis; Hancock, Robert; nsis@ietf.org=20 > > Subject: Re: [NSIS] framework: proposal on fragmentation=20 > >=20 > >=20 > > Isn't the functionality in NTLP dependent on NSLP. If a=20 > > certain NSLP do not want to=20 > > have=20 > > bundling and fragementation. Should that not be supported by NTLP = ?=20 > >=20 > > The selection of NTLP-functionality may be coupled to a=20 > > certain NSLP-type.=20 > > In that case you I think that you do not need to have=20 > > negotiation between different=20 > > NTLP-instances or.. ?=20 > >=20 > >=20 > > regards Lasse=20 > > Tom Taylor wrote:=20 > >=20 > > > Optionality doesn't work unless it is negotiated, which=20 > > makes the protocol a lot=20 > > > more complicated. I can say my node doesn't support=20 > > bundling, but what if the=20 > > > upstream node won't cooperate and sends me a bundled message?=20 > > >=20 > > > Georgios Karagiannis wrote:=20 > > >=20 > > > > Hi Robert=20 > > > >=20 > > > >=20 > > > >>FWIW I had assumed that reassembly would probably take place = at=20 > > > >>each NSIS-aware node. Apart from anything else, an NSIS-aware = node=20 > > > >>probably couldn't work out what to do with a fragment=20 > > (either whether=20 > > > >>to deliver it locally to an application or forward it,=20 > > and if so even=20 > > > >>who to forward it to) without doing the reassembly.=20 > > > >=20 > > > >=20 > > > > Yes, but this is additional fragmentation/reassembly=20 > > functionality that will=20 > > > > require additional=20 > > > > processing, thus the performance behaviour of a node=20 > > could be affected.=20 > > > >=20 > > > > Now if nodes do not support NTLP bundling and if the NSLP=20 > > is designed in=20 > > > > such a way that=20 > > > > NTLP fragmentation is not needed, then the NTLP=20 > > reassembly functionality,=20 > > > > mentioned above, even if it is not needed, will affect=20 > > negativelly the=20 > > > > performance behaviour of the node.=20 > > > >=20 > > > > What I am actually proposing is that any NSLP should be=20 > > able to specify if=20 > > > > NTLP fragmentation/reassembly must be=20 > > > > supported or not!=20 > > > > Therefore, I am proposing that the NTLP=20 > > fragmentation/reassembly feature=20 > > > > should be optional.=20 > > > >=20 > > > > Best regards,=20 > > > > Georgios=20 > > > >=20 > > > > _______________________________________________=20 > > > > nsis mailing list=20 > > > > nsis@ietf.org=20 > > > > https://www1.ietf.org/mailman/listinfo/nsis=20 > > > >=20 > > >=20 > > > _______________________________________________=20 > > > nsis mailing list=20 > > > nsis@ietf.org=20 > > > https://www1.ietf.org/mailman/listinfo/nsis=20 > >=20 >=20 _______________________________________________=20 nsis mailing list=20 nsis@ietf.org=20 https://www1.ietf.org/mailman/listinfo/nsis=20 ------=_NextPart_000_006F_01C32C1E.318F45E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] framework: proposal on = fragmentation
Hi Daniel
 
 
Sorry, I will repeat this = again:
 
If an application that uses a NSLP can solve the = problem of=20 fragmentation by
its own  then you do not = need=20 to activate the fragmentation/reassembly features.
By activate I mean that you initiate these features without = really=20 using them.
 
This can be solved very easily; the sender NSLP, by using the = NSLP/NTLP=20 API,
will inform the NTLP protocol to swicth off the fragmenation = option.
 
Beste Regards,
Georgios

 

 
----- Original Message -----
From:=20 Daniel Warren
To: 'Georgios=20 Karagiannis' ; Hancock, Robert
Sent: Friday, June 06, 2003 = 10:32=20 AM
Subject: RE: [NSIS] framework: = proposal=20 on fragmentation

I still think we are missing a couple of points = here, which=20 Robert has got close to but hasn't stated explicitly.

Optionality of a feature is only really optional on = a node=20 initiating the feature.  So, ignoring interim nodes for now, even = if=20 fragmentation is optional, any node that can receive NSIS messages has = to=20 support re-assembly because it does not know what form the information = it is=20 going to get will take - it might not be fragmented, but equally it = might, and=20 if it is it will need to be able to reassemble.

So by making fragmentation optional, all you are = actually=20 saying is that you may have nodes where the actually chopping up of = the=20 message (which is not a particularly complex task) is not = supported.  The=20 exception to this rule is a situation where your nodes only use the = 'small=20 messages' NSLP type that Georgios mentioned way back in the thread, = and even=20 then that makes that NSLP pretty inflexible to future = growth.

As for if reassembly needs to happen only at the = receiver or=20 at every node in between it depends upon what degree of complexity you = want to=20 add to your route managament.  Consider a path that goes through = a number=20 of interim nodes to get to it's destination.  That will mean a = number of=20 interim links which may have different MTU size per hop.  If you = don't=20 want to reassemble and segment at each node then the node that is = doing the=20 fragmentation will need to know the MTU size for every hop to the = destination=20 and fragment to meet the minimum requirement (otherwise there will be = a link=20 where the packets being sent exceed the MTU size and the packets will = get=20 dumped).  One solution to that is to use Roberts proposal of = segmenting=20 and reassembling per hop.  the other would be to allow interim = nodes to=20 segment the segments if it needs to, maybe lower down the = stack.

Just some thoughts really.

Dan

-----Original Message-----
From:=20 Georgios Karagiannis [mailto:karagian@cs.utwente.nl]= =20
Sent: 06 June 2003 09:09
To: Hancock,=20 Robert
Cc: nsis@ietf.org
Subject: Re: [NSIS] framework: proposal on = fragmentation=20


Hi Robert

> For fragmentation,
> what I=20 find conceptually simplest is mandatory at both ends, or else =
> there needs to be a simple answer to the question 'what = happens=20 when
> an interior NTLP node (not = colocated with=20 the NSLP) is given a message
> it can't=20 forward'.

If an application that uses a NSLP can solve the = problem of=20 fragmentation by
its own
then=20 the situation that you describe will not happen. And if this = happens=20
then the application is
aware of=20 that.

Please note that the mandatory support of a feature = in the=20 NTLP can affect
the
performance unnecessary.  If this happens to often then = there is a=20 chance
that the
NSIS protocol=20 will not be deployed on a large scale.

Please try to be flexible when there is a tradeoff = between=20 protocol
perfromance and support =
of a long list of mandatory features.

Best regards,
Georgios


----- Original Message -----
From:=20 "Hancock, Robert" <robert.hancock@roke.co.uk>
To: "'Lars.Westberg'" <Lars.Westberg@era.ericsson.se>; = "Tom=20 Taylor"
<taylor@nortelnetworks.com>=20
Cc: "Georgios Karagiannis" = <karagian@cs.utwente.nl>;=20 <nsis@ietf.org>
Sent: Friday, June 06, = 2003 9:49=20 AM
Subject: RE: [NSIS] framework: proposal = on=20 fragmentation


> dear all,
> =
> As a general point, I don't think it is practical to = fine tune=20 NTLP
> functionality to NSLP = requirements, except=20 by requesting additional
> treatment at = the message=20 level. (This sentence may be clarified below.)
>
> The reason is that we = have=20 essentially a 'flat' NTLP where an instance
> has=20 to support all signalling application traffic passing through =
> that node, even if the node doesn't support that = application (FW=20 section
> 3.2.1 if you've forgotten). So = an NTLP=20 never knows what NSLPs it is
> going to = have to=20 handle, and an NSLP can't tell downstream NTLP nodes
> what to support.
> =
> [An alternative architecture, where there was = NSLP-sensitive=20 explicit
> next-NTLP-peer discovery and a = more=20 session-oriented signalling
association=20
> between NSLP peers, would enable alternative = solutions.=20 But we aren't
> doing that.] =
>
> In practice, we have to = consider how=20 this works function by function,
> and = whether=20 functions can be selectively invoked. In some cases, I think =
> we will have functions which are mandatory to implement = in the=20 receiver,
> and optional to implement in = the sender=20 - this is the case for
> bundling, where = the=20 receiver processing is trivial. For fragmentation,
> what I find conceptually simplest is mandatory at both = ends, or=20 else
> there needs to be a simple answer = to the=20 question 'what happens when
> an interior = NTLP node=20 (not colocated with the NSLP) is given a message
>=20 it can't forward'.
>
>=20 cheers,
>
> = r.=20
>
> > = -----Original=20 Message-----
> > From: Lars.Westberg = [mailto:Lars.Westberg@era.er= icsson.se]=20
> > Sent: 06 June 2003 08:32
> > To: Tom Taylor
> > = Cc: Georgios=20 Karagiannis; Hancock, Robert; nsis@ietf.org
> >=20 Subject: Re: [NSIS] framework: proposal on fragmentation =
> >
> > =
> > Isn't the functionality in NTLP dependent on NSLP. = If=20 a
> > certain NSLP do not want = to=20
> > have
> > = bundling and=20 fragementation. Should that not be supported by NTLP ? =
> >
> > The selection = of=20 NTLP-functionality may be coupled to a
> = >=20 certain NSLP-type.
> > In that case = you I think=20 that you do not need to have
> > = negotiation=20 between different
> > NTLP-instances = or..=20 ?
> >
> = >=20
> > regards Lasse
> > Tom=20 Taylor wrote:
> >
>=20 > > Optionality doesn't work unless it is negotiated, = which=20
> > makes the protocol a lot
> > > more complicated.  I can say my node = doesn't=20 support
> > bundling, but what if = the=20
> > > upstream node won't cooperate and = sends me a=20 bundled message?
> > > =
> > > Georgios Karagiannis wrote:
>=20 > >
> > > > Hi = Robert=20
> > > >
> = > >=20 >
> > > >>FWIW I had = assumed that=20 reassembly would probably take place at
> = > >=20 >>each NSIS-aware node. Apart from anything else, an NSIS-aware=20 node
> > > >>probably = couldn't work out=20 what to do with a fragment
> > (either = whether
> > > >>to deliver it = locally=20 to an application or forward it,
> > = and if so=20 even
> > > >>who to forward = it to)=20 without doing the reassembly.
> > > = >
> > > >
>=20 > > > Yes, but this is additional = fragmentation/reassembly=20
> > functionality that will
> > > > require  additional
> > > > processing, thus the performance = behaviour of a=20 node
> > could be affected. =
> > > >
> > > = > Now if=20 nodes do not support NTLP bundling and if the NSLP
> > is designed in
> > = > >=20 such a way that
> > > > NTLP = fragmentation=20 is not needed,  then the NTLP
> > = reassembly functionality,
> > > = >=20 mentioned above, even if it is not needed, will affect =
> > negativelly the
> > = > >=20 performance behaviour of the node.
> > = >=20 >
> > > > What I am actually = proposing=20 is that any NSLP should be
> > able to = specify=20 if
> > > > NTLP = fragmentation/reassembly=20 must be
> > > > supported or = not!=20
> > > > Therefore, I am proposing that = the=20 NTLP
> > fragmentation/reassembly = feature=20
> > > > should be optional. =
> > > >
> > > = > Best=20 regards,
> > > > Georgios =
> > > >
> > > = >=20 _______________________________________________
>=20 > > > nsis mailing list
> > = > >=20 nsis@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/nsis =
> > > >
> > = >=20
> > >=20 _______________________________________________
>=20 > > nsis mailing list
> > >=20 nsis@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/nsis =
> >
>

_______________________________________________=20
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis =

------=_NextPart_000_006F_01C32C1E.318F45E0-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 05:35: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 FAA15420 for ; Fri, 6 Jun 2003 05:35:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h569YjS06744 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 05:34:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h569YdB06735; Fri, 6 Jun 2003 05:34:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h569XUB06667 for ; Fri, 6 Jun 2003 05:33:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15365 for ; Fri, 6 Jun 2003 05:33:25 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ODZN-0007lz-00 for nsis@ietf.org; Fri, 06 Jun 2003 05:31:33 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19ODZM-0007lv-00 for nsis@ietf.org; Fri, 06 Jun 2003 05:31:32 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h569XOW10122 for ; Fri, 6 Jun 2003 12:33:24 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Jun 2003 12:33:22 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 12:33:22 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 12:33:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32C0E.AB70BECC" Subject: RE: [NSIS] framework: proposal on fragmentation Date: Fri, 6 Jun 2003 12:33:21 +0300 Message-ID: Thread-Topic: [NSIS] framework: proposal on fragmentation Thread-Index: AcMsDZOmp7i4cVr/Ql2GYh79CnSgUgAAOjkg To: , Cc: X-OriginalArrivalTime: 06 Jun 2003 09:33:22.0208 (UTC) FILETIME=[ABEC9A00:01C32C0E] 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 is a multi-part message in MIME format. ------_=_NextPart_001_01C32C0E.AB70BECC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Georgios, If an application that uses a NSLP can solve the problem of = fragmentation by=20 its own then you do not need to activate the fragmentation/reassembly = features. By activate I mean that you initiate these features without really using = them. =20 This can be solved very easily; the sender NSLP, by using the NSLP/NTLP = API,=20 will inform the NTLP protocol to swicth off the fragmenation option. =20 Yes, but how do you know that intermediate notes have not fragmented? = Or even worse, because of some network changes, packets are routed differently through = a link with a very small MTU that causes fragmentation? =20 John ------_=_NextPart_001_01C32C0E.AB70BECC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] framework: proposal on fragmentation
Hi=20 Georgios,
If an application that uses a NSLP = can solve the=20 problem of fragmentation by
its own  then you do not need=20 to activate the fragmentation/reassembly features.
By activate I mean that = you initiate these=20 features without really using them.
 
This can be solved very easily; the = sender NSLP,=20 by using the NSLP/NTLP API,
will inform the NTLP protocol to = swicth off the=20 fragmenation option.
 
Yes,=20 but how do you know that intermediate notes have not fragmented?  = Or even=20 worse,
because of some network changes, packets are routed = differently through=20 a link with a very
small MTU that causes fragmentation?
 
John
------_=_NextPart_001_01C32C0E.AB70BECC-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 05:45: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 FAA15650 for ; Fri, 6 Jun 2003 05:45:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h569jIV08052 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 05:45:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h569jCB08042; Fri, 6 Jun 2003 05:45:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h569isB08016 for ; Fri, 6 Jun 2003 05:44:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15606 for ; Fri, 6 Jun 2003 05:44:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ODkO-00002O-00 for nsis@ietf.org; Fri, 06 Jun 2003 05:42:56 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19ODkN-00002L-00 for nsis@ietf.org; Fri, 06 Jun 2003 05:42:56 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h569il5s009549; Fri, 6 Jun 2003 11:44:47 +0200 (MET DST) Message-ID: <009101c32c10$454b7da0$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: Cc: References: Subject: Re: [NSIS] framework: proposal on fragmentation Date: Fri, 6 Jun 2003 11:44:48 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008E_01C32C21.08A96D10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 is a multi-part message in MIME format. ------=_NextPart_000_008E_01C32C21.08A96D10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] framework: proposal on fragmentationHi John First of all the NTLP protocol has to use some information, e.g., a = fragmentation bit, to specify that=20 fragmentation is allowed or not.=20 Now, if the sender NSLP (NI) informs its NTLP instance to switch off the = fragmentation, then this NTLP instance=20 will switch off the fragmentation bit. In this way all the intermediate = NTLP nodes will know that fragmentation is=20 not allowed. Best regards, Georgios ----- Original Message -----=20 From: john.loughney@nokia.com=20 To: karagian@cs.utwente.nl ; dlwarren@nortelnetworks.com=20 Cc: nsis@ietf.org=20 Sent: Friday, June 06, 2003 11:33 AM Subject: RE: [NSIS] framework: proposal on fragmentation Hi Georgios, If an application that uses a NSLP can solve the problem of = fragmentation by=20 its own then you do not need to activate the = fragmentation/reassembly features. By activate I mean that you initiate these features without really = using them. =20 This can be solved very easily; the sender NSLP, by using the = NSLP/NTLP API,=20 will inform the NTLP protocol to swicth off the fragmenation option. =20 Yes, but how do you know that intermediate notes have not = fragmented? Or even worse, because of some network changes, packets are routed differently = through a link with a very small MTU that causes fragmentation? =20 John ------=_NextPart_000_008E_01C32C21.08A96D10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] framework: proposal on = fragmentation
Hi John
 
First of all the NTLP protocol has to = use some=20 information, e.g., a fragmentation bit, to specify that
fragmentation is allowed or not. =
Now, if the sender NSLP (NI) informs = its NTLP=20 instance to switch off the fragmentation, then this NTLP instance =
will switch off the fragmentation bit. = In this way=20 all the intermediate NTLP nodes will know that fragmentation is =
not allowed.
 
Best regards,
Georgios
----- Original Message -----
From:=20 john.loughney@nokia.com
To: karagian@cs.utwente.nl ; dlwarren@nortelnetworks.com =
Sent: Friday, June 06, 2003 = 11:33=20 AM
Subject: RE: [NSIS] framework: = proposal=20 on fragmentation

Hi=20 Georgios,
If an application that uses a NSLP = can solve=20 the problem of fragmentation by
its own  then you do not need=20 to activate the fragmentation/reassembly features.
By activate I mean that = you initiate these=20 features without really using them.
 
This can be solved very easily; the = sender=20 NSLP, by using the NSLP/NTLP API,
will inform the NTLP protocol to = swicth off the=20 fragmenation option.
 
Yes, but how do you know that intermediate notes have not=20 fragmented?  Or even worse,
because of some network changes, packets are routed = differently=20 through a link with a very
small MTU that causes fragmentation?
 
John
= ------=_NextPart_000_008E_01C32C21.08A96D10-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 10:56: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 KAA27084 for ; Fri, 6 Jun 2003 10:56:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56EtvB30222 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 10:55:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56EtiB30207; Fri, 6 Jun 2003 10:55:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56EpkB29992 for ; Fri, 6 Jun 2003 10:51:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26811 for ; Fri, 6 Jun 2003 10:51:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OIXL-0002jH-00 for nsis@ietf.org; Fri, 06 Jun 2003 10:49:47 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19OIXK-0002jE-00 for nsis@ietf.org; Fri, 06 Jun 2003 10:49:46 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h56EpcT3028990; Fri, 6 Jun 2003 16:51:38 +0200 (MEST) Received: from era.ericsson.se (E00104B7F41BB.ki.sw.ericsson.se [147.214.181.136]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGGRZPM; Fri, 6 Jun 2003 16:52:46 +0200 Message-ID: <3EE0AA77.B9EFC73F@era.ericsson.se> Date: Fri, 06 Jun 2003 16:51:35 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lars.Westberg" X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Hancock, Robert" CC: Tom Taylor , Georgios Karagiannis , nsis@ietf.org Subject: Re: [NSIS] framework: proposal on fragmentation 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 Hi! Some comments below "Hancock, Robert" wrote: > dear all, > > As a general point, I don't think it is practical to fine tune NTLP > functionality to NSLP requirements, except by requesting additional > treatment at the message level. (This sentence may be clarified below.) > > The reason is that we have essentially a 'flat' NTLP where an instance > has to support all signalling application traffic passing through > that node, even if the node doesn't support that application (FW section > 3.2.1 if you've forgotten). So an NTLP never knows what NSLPs it is > going to have to handle, and an NSLP can't tell downstream NTLP nodes > what to support. > NSLP will above the NTLP and between those it will be an interface. Can't this interface include primitves for the NSLP ? I have difficulties to the issues here. Are you also saying that we are going into a direction where the only NTLP-option is RSVPover SCTP ? Because, you can argue in this way for all protocol features bundling. fragmentation, reliabillity..... This will in my opinion limit the usage of NTLP for some applications. Let's try to specify a one simple operational mode of NTLP-operation where NTLP can use UDP-like of operation without all of these features. My proposal is that we trying to develop two modes of NTLP-operation: - RSVPover SCTP - RSVPoverUDP Regards Lasse > > [An alternative architecture, where there was NSLP-sensitive explicit > next-NTLP-peer discovery and a more session-oriented signalling association > between NSLP peers, would enable alternative solutions. But we aren't > doing that.] > > In practice, we have to consider how this works function by function, > and whether functions can be selectively invoked. In some cases, I think > we will have functions which are mandatory to implement in the receiver, > and optional to implement in the sender - this is the case for > bundling, where the receiver processing is trivial. For fragmentation, > what I find conceptually simplest is mandatory at both ends, or else > there needs to be a simple answer to the question 'what happens when > an interior NTLP node (not colocated with the NSLP) is given a message > it can't forward'. > > cheers, > > r. > > > -----Original Message----- > > From: Lars.Westberg [mailto:Lars.Westberg@era.ericsson.se] > > Sent: 06 June 2003 08:32 > > To: Tom Taylor > > Cc: Georgios Karagiannis; Hancock, Robert; nsis@ietf.org > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > Isn't the functionality in NTLP dependent on NSLP. If a > > certain NSLP do not want to > > have > > bundling and fragementation. Should that not be supported by NTLP ? > > > > The selection of NTLP-functionality may be coupled to a > > certain NSLP-type. > > In that case you I think that you do not need to have > > negotiation between different > > NTLP-instances or.. ? > > > > > > regards Lasse > > Tom Taylor wrote: > > > > > Optionality doesn't work unless it is negotiated, which > > makes the protocol a lot > > > more complicated. I can say my node doesn't support > > bundling, but what if the > > > upstream node won't cooperate and sends me a bundled message? > > > > > > Georgios Karagiannis wrote: > > > > > > > Hi Robert > > > > > > > > > > > >>FWIW I had assumed that reassembly would probably take place at > > > >>each NSIS-aware node. Apart from anything else, an NSIS-aware node > > > >>probably couldn't work out what to do with a fragment > > (either whether > > > >>to deliver it locally to an application or forward it, > > and if so even > > > >>who to forward it to) without doing the reassembly. > > > > > > > > > > > > Yes, but this is additional fragmentation/reassembly > > functionality that will > > > > require additional > > > > processing, thus the performance behaviour of a node > > could be affected. > > > > > > > > Now if nodes do not support NTLP bundling and if the NSLP > > is designed in > > > > such a way that > > > > NTLP fragmentation is not needed, then the NTLP > > reassembly functionality, > > > > mentioned above, even if it is not needed, will affect > > negativelly the > > > > performance behaviour of the node. > > > > > > > > What I am actually proposing is that any NSLP should be > > able to specify if > > > > NTLP fragmentation/reassembly must be > > > > supported or not! > > > > Therefore, I am proposing that the NTLP > > fragmentation/reassembly feature > > > > should be optional. > > > > > > > > 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 > > > > ------------------------------------------------------------------------ > Name: RMRL-Disclaimer.txt > RMRL-Disclaimer.txt Type: Plain Text (text/plain) > Encoding: 7bit _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 11:01: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 LAA27395 for ; Fri, 6 Jun 2003 11:01:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56F1IK30692 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 11:01:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56F1CB30669; Fri, 6 Jun 2003 11:01:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56F0RB30530 for ; Fri, 6 Jun 2003 11:00:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27326 for ; Fri, 6 Jun 2003 11:00:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OIfj-0002nn-00 for nsis@ietf.org; Fri, 06 Jun 2003 10:58:27 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19OIfi-0002nk-00 for nsis@ietf.org; Fri, 06 Jun 2003 10:58:27 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h56F10bj014965; Fri, 6 Jun 2003 17:01:00 +0200 Received: from era.ericsson.se (E00104B7F41BB.ki.sw.ericsson.se [147.214.181.136]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGGR6H1; Fri, 6 Jun 2003 17:01:27 +0200 Message-ID: <3EE0AC80.746DB02@era.ericsson.se> Date: Fri, 06 Jun 2003 17:00:16 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lars.Westberg" X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Geib, Ruediger" CC: nsis@ietf.org Subject: Re: [NSIS] framework: proposal on fragmentation References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB4BE@G8PQD.blf01.telekom.de> 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 The generality of NTLP is a difficutl issue. My point is that I can forsee application that is so simple that an UDP-style of operation is good enough. I do not support the single-mode of operation due to my expectation of a complec protocol standard. I forseen that we can discuss protocol feature during long time and use the generality argument for all protocol feature. This will result in a very complex protcol when the standaridzation is finished. I would recommend that we have two modes of operation in mind: RSVPoverSCTP RSVPover UDP I also recommend to partion the effort for NTLP in these "modes of operation" If someone want to use high-level of protocol support in NTLP => use RSVPoverSCTP. If someone want something simple use RSVPoverUDP. regards Lasse "Geib, Ruediger" wrote: > Hi Lasse, > > | The selection of NTLP-functionality may be coupled to a > | certain NSLP-type. > > This sounds like NSLP specific NTLPs. We don't need a > layer split in that case. Like Robert, I don't support > this proposal. > > | In that case you I think that you do not need to have > | negotiation between different > | NTLP-instances or.. ? > > Negotiation of options between NTLP-instances isn't > desireable from an operators point of view. > > I understand that at some level within the protocol stack > there must be awareness of the path MTU size. We should > be careful not to overengineer our solution. If NSIS uses > a transport protocol below NTLP which handles the MTU > issue, let's make it the default. This would also simplify > bundeling within NTLP, wouldn't it? > > 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 Fri Jun 6 11:07: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 LAA27616 for ; Fri, 6 Jun 2003 11:07:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56F7HU31265 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 11:07:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56F7BB31172; Fri, 6 Jun 2003 11:07:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56F64B31058 for ; Fri, 6 Jun 2003 11:06:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27586 for ; Fri, 6 Jun 2003 11:05:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OIlA-0002rS-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:04:04 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19OIl9-0002rP-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:04:04 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jun 2003 16:05:57 +0100 Message-ID: From: "Hancock, Robert" To: "'Lars.Westberg'" , "Geib, Ruediger" Cc: nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation Date: Fri, 6 Jun 2003 16:05:52 +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: , Lasse, My engineering viewpoint is that the number of signalling applications and deployment scenarios for which an approach like RSVPoverUDP is reasonable is so small as to be not worth the layer model and everything else; that's why the WG has adopted a 2205+2961 conceptual starting point for the NTLP work. However, I suspect that this (what you propose) is more of a WG charter issue than an engineering issue. cheers, robert h. > -----Original Message----- > From: Lars.Westberg [mailto:Lars.Westberg@era.ericsson.se] > Sent: 06 June 2003 16:00 > To: Geib, Ruediger > Cc: nsis@ietf.org > Subject: Re: [NSIS] framework: proposal on fragmentation > > > The generality of NTLP is a difficutl issue. My point is that I can > forsee application that is so simple > that an UDP-style of operation is good enough. > > I do not support the single-mode of operation due to my > expectation of a > complec protocol standard. > I forseen that we can discuss protocol feature during long > time and use > the generality argument > for all protocol feature. This will result in a very complex protcol > when the standaridzation is finished. > > I would recommend that we have two modes of operation in mind: > RSVPoverSCTP > RSVPover UDP > > I also recommend to partion the effort for NTLP in these "modes of > operation" > > If someone want to use high-level of protocol support in NTLP => use > RSVPoverSCTP. > If someone want something simple use RSVPoverUDP. > > regards Lasse > "Geib, Ruediger" wrote: > > > Hi Lasse, > > > > | The selection of NTLP-functionality may be coupled to a > > | certain NSLP-type. > > > > This sounds like NSLP specific NTLPs. We don't need a > > layer split in that case. Like Robert, I don't support > > this proposal. > > > > | In that case you I think that you do not need to have > > | negotiation between different > > | NTLP-instances or.. ? > > > > Negotiation of options between NTLP-instances isn't > > desireable from an operators point of view. > > > > I understand that at some level within the protocol stack > > there must be awareness of the path MTU size. We should > > be careful not to overengineer our solution. If NSIS uses > > a transport protocol below NTLP which handles the MTU > > issue, let's make it the default. This would also simplify > > bundeling within NTLP, wouldn't it? > > > > 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 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 11:08: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 LAA27652 for ; Fri, 6 Jun 2003 11:08:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56F85l32067 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 11:08:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56F80B32027; Fri, 6 Jun 2003 11:08:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56F7NB31455 for ; Fri, 6 Jun 2003 11:07:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27604 for ; Fri, 6 Jun 2003 11:07:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OImS-0002ro-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:05:24 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19OImR-0002rl-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:05:23 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jun 2003 16:07:17 +0100 Message-ID: From: "Hancock, Robert" To: "'Lars.Westberg'" Cc: Tom Taylor , Georgios Karagiannis , nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation Date: Fri, 6 Jun 2003 16:07:10 +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 lasse, see comments below: > > The reason is that we have essentially a 'flat' NTLP where an instance > > has to support all signalling application traffic passing through > > that node, even if the node doesn't support that application (FW section > > 3.2.1 if you've forgotten). So an NTLP never knows what NSLPs it is > > going to have to handle, and an NSLP can't tell downstream NTLP nodes > > what to support. > > > > NSLP will above the NTLP and between those it will be an > interface. Can't this > interface include primitves for the NSLP ? > I have difficulties to the issues here. reproduced from the framework: +------+ +------+ +------+ +------+ | NE | | NE | | NE | | NE | |+----+| | | |+----+| |+----+| ||NSLP|| | | ||NSLP|| ||NSLP|| || || | | || || || || || 1 || | | || 2 || || 1 || |+----+| | | |+----+| |+----+| | || | | | | | | || | |+----+| |+----+| |+----+| |+----+| ====||NTLP||====||NTLP||====||NTLP||====||NTLP||==== |+----+| |+----+| |+----+| |+----+| +------+ +------+ +------+ +------+ Figure 5: Signaling with Heterogeneous NSLPs how does the NSLP in the first node agree a mode of operation with the NTLP in the third node (for example)? Without putting a whole load of NTLP mode negotiation stuff in the NTLP itself. (Mode negotiation is almost certain to be stateful and not what you want.) [everything else trimmed away as handled in other mails...] cheers, r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 11:11: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 LAA27883 for ; Fri, 6 Jun 2003 11:11:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56FB9l32241 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 11:11:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FB4B32232; Fri, 6 Jun 2003 11:11:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FARB32212 for ; Fri, 6 Jun 2003 11:10:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27842 for ; Fri, 6 Jun 2003 11:10:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OIpP-0002w0-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:08:27 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19OIpO-0002vs-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:08:26 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h56FAJ0J008780; Fri, 6 Jun 2003 17:10:19 +0200 (MEST) 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 LVY3LTL3; Fri, 6 Jun 2003 17:11:14 +0200 Message-ID: <3EE0AED7.CE399E81@era.ericsson.se> Date: Fri, 06 Jun 2003 17:10:16 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 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: karagian@cs.utwente.nl, dlwarren@nortelnetworks.com, nsis@ietf.org Subject: Re: [NSIS] framework: proposal on fragmentation References: Content-Type: multipart/alternative; boundary="------------AAE8CEB6BCE073BB2322F675" 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: , --------------AAE8CEB6BCE073BB2322F675 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Comments below: john.loughney@nokia.com wrote: > Hi Georgios, > > If an application that uses a NSLP can solve the problem of > fragmentation byits own then you do not need to activate > the fragmentation/reassembly features.By activate I mean > that you initiate these features without really using > them. This can be solved very easily; the sender NSLP, by > using the NSLP/NTLP API,will inform the NTLP protocol to > swicth off the fragmenation option. Yes, but how do you know > that intermediate notes have not fragmented? Or even > worse,because of some network changes, packets are routed > differently through a link with a verysmall MTU that causes > fragmentation?John > If we have an IP-network, the IP-layer may fragment/reassembly the packets. For me, it does not mean that the NTLP must perform fragmentation. If we have an NSLP that want to have an certain transport service from the NTLP. Can't that choose a proper level of operation by the API ? If the knowledge of a NSLP-instance does not exist in the router, the router could probably forward the packet in the same way it has rececied them without performing bundeling, fragmentation..... Regards Lasse --------------AAE8CEB6BCE073BB2322F675 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Comments below:

john.loughney@nokia.com wrote:

Hi Georgios,
If an application that uses a NSLP can solve the problem of fragmentation byits own  then you do not need to activate the fragmentation/reassembly features.By activate I mean that you initiate these features without really using them. This can be solved very easily; the sender NSLP, by using the NSLP/NTLP API,will inform the NTLP protocol to swicth off the fragmenation option. Yes, but how do you know that intermediate notes have not fragmented?  Or even worse,because of some network changes, packets are routed differently through a link with a verysmall MTU that causes fragmentation?John


If we have an IP-network, the IP-layer may fragment/reassembly the packets.  For me, it does not mean that the NTLP must perform fragmentation.

If we have an NSLP that want to have an certain transport service from the NTLP. Can't that choose a proper level of operation by the API ?

If the knowledge of a NSLP-instance does not exist in the router, the router could probably forward the packet in the same way it has rececied them without performing bundeling,  fragmentation.....

Regards Lasse
 
  --------------AAE8CEB6BCE073BB2322F675-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 11: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 LAA28117 for ; Fri, 6 Jun 2003 11:17:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56FHFJ32577 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 11:17:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FH6B32546; Fri, 6 Jun 2003 11:17:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FFuB32470 for ; Fri, 6 Jun 2003 11:15:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28045 for ; Fri, 6 Jun 2003 11:15:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OIun-0002zJ-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:14:01 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19OIum-0002zA-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:14:00 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h56FGYbj017042; Fri, 6 Jun 2003 17:16:34 +0200 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 LVY3L4J1; Fri, 6 Jun 2003 17:16:48 +0200 Message-ID: <3EE0B026.FED999A9@era.ericsson.se> Date: Fri, 06 Jun 2003 17:15:50 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lars.Westberg" X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Hancock, Robert" CC: "Geib, Ruediger" , nsis@ietf.org Subject: Re: [NSIS] framework: proposal on fragmentation 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 Comments below "Hancock, Robert" wrote: > Lasse, > > My engineering viewpoint is that the number of signalling applications > and deployment scenarios for which an approach like RSVPoverUDP is > reasonable is so small as to be not worth the layer model and everything > else; that's why the WG has adopted a 2205+2961 conceptual starting point > for the NTLP work. > The working group have en started to solve a certain engineering problem e.g to make a more general solution than RSVP and makes it simpler. This working group have started the discussion from another approach: Let's include more functionality than RSVP have today. > > However, I suspect that this (what you propose) is more of a WG charter > issue than an engineering issue. > No, it was included in the problem statement from beginning. > > cheers, > > robert h. > > > -----Original Message----- > > From: Lars.Westberg [mailto:Lars.Westberg@era.ericsson.se] > > Sent: 06 June 2003 16:00 > > To: Geib, Ruediger > > Cc: nsis@ietf.org > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > The generality of NTLP is a difficutl issue. My point is that I can > > forsee application that is so simple > > that an UDP-style of operation is good enough. > > > > I do not support the single-mode of operation due to my > > expectation of a > > complec protocol standard. > > I forseen that we can discuss protocol feature during long > > time and use > > the generality argument > > for all protocol feature. This will result in a very complex protcol > > when the standaridzation is finished. > > > > I would recommend that we have two modes of operation in mind: > > RSVPoverSCTP > > RSVPover UDP > > > > I also recommend to partion the effort for NTLP in these "modes of > > operation" > > > > If someone want to use high-level of protocol support in NTLP => use > > RSVPoverSCTP. > > If someone want something simple use RSVPoverUDP. > > > > regards Lasse > > "Geib, Ruediger" wrote: > > > > > Hi Lasse, > > > > > > | The selection of NTLP-functionality may be coupled to a > > > | certain NSLP-type. > > > > > > This sounds like NSLP specific NTLPs. We don't need a > > > layer split in that case. Like Robert, I don't support > > > this proposal. > > > > > > | In that case you I think that you do not need to have > > > | negotiation between different > > > | NTLP-instances or.. ? > > > > > > Negotiation of options between NTLP-instances isn't > > > desireable from an operators point of view. > > > > > > I understand that at some level within the protocol stack > > > there must be awareness of the path MTU size. We should > > > be careful not to overengineer our solution. If NSIS uses > > > a transport protocol below NTLP which handles the MTU > > > issue, let's make it the default. This would also simplify > > > bundeling within NTLP, wouldn't it? > > > > > > 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 > > > > ------------------------------------------------------------------------ > Name: RMRL-Disclaimer.txt > RMRL-Disclaimer.txt Type: Plain Text (text/plain) > Encoding: 7bit _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 11:22: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 LAA28352 for ; Fri, 6 Jun 2003 11:22:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56FMFc00564 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 11:22:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FM8B00552; Fri, 6 Jun 2003 11:22:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FLcB00511 for ; Fri, 6 Jun 2003 11:21:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28291 for ; Fri, 6 Jun 2003 11:21:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJ0J-000326-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:19:43 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19OJ0I-000323-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:19:42 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h56FMFbj017659; Fri, 6 Jun 2003 17:22:15 +0200 Received: from era.ericsson.se (E00104B7F41BB.ki.sw.ericsson.se [147.214.181.136]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGGR92G; Fri, 6 Jun 2003 17:22:42 +0200 Message-ID: <3EE0B17B.45C2EEDD@era.ericsson.se> Date: Fri, 06 Jun 2003 17:21:31 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lars.Westberg" X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Hancock, Robert" CC: Tom Taylor , Georgios Karagiannis , nsis@ietf.org Subject: Re: [NSIS] framework: proposal on fragmentation 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 Se comment below "Hancock, Robert" wrote: > hi lasse, > > see comments below: > > > > The reason is that we have essentially a 'flat' NTLP where an instance > > > has to support all signalling application traffic passing through > > > that node, even if the node doesn't support that application (FW section > > > 3.2.1 if you've forgotten). So an NTLP never knows what NSLPs it is > > > going to have to handle, and an NSLP can't tell downstream NTLP nodes > > > what to support. > > > > > > > NSLP will above the NTLP and between those it will be an > > interface. Can't this > > interface include primitves for the NSLP ? > > I have difficulties to the issues here. > > reproduced from the framework: > > +------+ +------+ +------+ +------+ > | NE | | NE | | NE | | NE | > |+----+| | | |+----+| |+----+| > ||NSLP|| | | ||NSLP|| ||NSLP|| > || || | | || || || || > || 1 || | | || 2 || || 1 || > |+----+| | | |+----+| |+----+| > | || | | | | | | || | > |+----+| |+----+| |+----+| |+----+| > ====||NTLP||====||NTLP||====||NTLP||====||NTLP||==== > |+----+| |+----+| |+----+| |+----+| > +------+ +------+ +------+ +------+ > > Figure 5: Signaling with Heterogeneous NSLPs > > how does the NSLP in the first node agree a mode of operation with > the NTLP in the third node (for example)? Without putting a whole > load of NTLP mode negotiation stuff in the NTLP itself. (Mode > negotiation is almost certain to be stateful and not what you want.) > No, I trying to explain it: If you have a network element without knowledge of the NSLP:s requirment, the default should be to forward it to the next hop without doing anything to the NSLP-messages. regards Lasse > > [everything else trimmed away as handled in other mails...] > > cheers, > > r. > > ------------------------------------------------------------------------ > Name: RMRL-Disclaimer.txt > RMRL-Disclaimer.txt Type: Plain Text (text/plain) > Encoding: 7bit _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 11:25: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 LAA28475 for ; Fri, 6 Jun 2003 11:25:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56FPAj00804 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 11:25:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FP4B00794; Fri, 6 Jun 2003 11:25:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FOvB00758 for ; Fri, 6 Jun 2003 11:24:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28464 for ; Fri, 6 Jun 2003 11:24:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJ3W-00035U-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:23:02 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19OJ3W-00034t-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:23:02 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jun 2003 16:24:25 +0100 Message-ID: From: "Hancock, Robert" To: "'Lars.Westberg'" Cc: Tom Taylor , Georgios Karagiannis , nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation Date: Fri, 6 Jun 2003 16:24:24 +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: , aha! > > No, I trying to explain it: > If you have a network element without knowledge of the NSLP:s > requirment, the > default should be to forward it to the next hop without doing > anything to the > NSLP-messages. *** and what if the message is too big to forward? *** [which is where we started...] > > regards Lasse > r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 11:28: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 LAA28576 for ; Fri, 6 Jun 2003 11:28:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56FSCk00947 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 11:28:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FS6B00925; Fri, 6 Jun 2003 11:28:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FRVB00903 for ; Fri, 6 Jun 2003 11:27:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28537 for ; Fri, 6 Jun 2003 11:27:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJ60-000372-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:25:36 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19OJ5z-00036z-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:25:35 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h56FS8bj018333; Fri, 6 Jun 2003 17:28:09 +0200 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 LVYT20TG; Fri, 6 Jun 2003 17:27:14 +0200 Message-ID: <3EE0B2DD.EA6F910D@era.ericsson.se> Date: Fri, 06 Jun 2003 17:27:25 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lars.Westberg" X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Hancock, Robert" CC: Tom Taylor , Georgios Karagiannis , nsis@ietf.org Subject: Re: [NSIS] framework: proposal on fragmentation 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 Use IP-fragmentation -lasse "Hancock, Robert" wrote: > aha! > > > > > No, I trying to explain it: > > If you have a network element without knowledge of the NSLP:s > > requirment, the > > default should be to forward it to the next hop without doing > > anything to the > > NSLP-messages. > > *** and what if the message is too big to forward? *** > [which is where we started...] > > > > > regards Lasse > > > > r. > > ------------------------------------------------------------------------ > Name: RMRL-Disclaimer.txt > RMRL-Disclaimer.txt Type: Plain Text (text/plain) > Encoding: 7bit _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 11:28: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 LAA28591 for ; Fri, 6 Jun 2003 11:28:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56FSDL00960 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 11:28:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FS8B00940; Fri, 6 Jun 2003 11:28:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FRoB00908 for ; Fri, 6 Jun 2003 11:27:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28549 for ; Fri, 6 Jun 2003 11:27:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJ6J-000379-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:25:55 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19OJ6I-00036v-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:25:54 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h56FRFms010410; Fri, 6 Jun 2003 08:27:15 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIB79381; Fri, 6 Jun 2003 08:27:14 -0700 (PDT) Message-Id: <200306061527.AIB79381@mira-sjc5-c.cisco.com> To: "Lars.Westberg" cc: "Geib, Ruediger" , nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] framework: proposal on fragmentation In-Reply-To: Message from Lars.Westberg@era.ericsson.se of "Fri, 06 Jun 2003 17:00:16 +0200." <3EE0AC80.746DB02@era.ericsson.se> Date: Fri, 06 Jun 2003 11:27:13 -0400 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 would recommend that we have two modes of operation in mind: > RSVPoverSCTP > RSVPover UDP We reached an agreement at the last meeting, confirmed on the mailing list, that we'd run over a connectionless protocol - that we would gut 2205 and 2961 and use that as the basis for an NTLP. If you go back and look at John's slides from the meeting there was no agreement even to make a connection-oriented protocol available as an option (that is to say, no decision was made either way). One of the things that's killing progress in a number of IETF working groups is the unfortunate tendency to want to go back and revisit and revisit and revisit and revisit decisions that we don't agree with. We need to put a stop to that. That said, I think that we can almost certainly put an NTLP over a connection-oriented protocol, but that we do not want to do this in the baseline. Unless there's new information today that wasn't available in March, however, revisiting the decision that was made then seems like an incredibly bad idea. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 11:39: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 LAA28894 for ; Fri, 6 Jun 2003 11:39:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56FdNd02498 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 11:39:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FdFB02484; Fri, 6 Jun 2003 11:39:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FclB02452 for ; Fri, 6 Jun 2003 11:38:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28858 for ; Fri, 6 Jun 2003 11:38:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJGu-0003Ca-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:36:52 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19OJGt-0003CQ-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:36:51 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h56Fc4CL001260; Fri, 6 Jun 2003 08:38:04 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIB80399; Fri, 6 Jun 2003 08:38:03 -0700 (PDT) Message-Id: <200306061538.AIB80399@mira-sjc5-c.cisco.com> To: "Lars.Westberg" cc: "Hancock, Robert" , Tom Taylor , Georgios Karagiannis , nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] framework: proposal on fragmentation In-Reply-To: Message from Lars.Westberg@era.ericsson.se of "Fri, 06 Jun 2003 17:27:25 +0200." <3EE0B2DD.EA6F910D@era.ericsson.se> Date: Fri, 06 Jun 2003 11:38:03 -0400 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: , > Use IP-fragmentation IP fragmentation is a problem for NATs. That's a problem for a discovery (addressed end-to-end) message, which in turn is a problem for us if we wish to support a middlebox application. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 11:42: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 LAA28985 for ; Fri, 6 Jun 2003 11:42:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56FgAo02657 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 11:42:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56Fg2B02648; Fri, 6 Jun 2003 11:42:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56FfkB02630 for ; Fri, 6 Jun 2003 11:41:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28954 for ; Fri, 6 Jun 2003 11:41:43 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJJm-0003EQ-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:39:50 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19OJJl-0003EN-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:39:49 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h56FfgD08624 for ; Fri, 6 Jun 2003 18:41:42 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Jun 2003 18:41:41 +0300 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 18:41:41 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 18:41:41 +0300 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] framework: proposal on fragmentation Date: Fri, 6 Jun 2003 18:41:40 +0300 Message-ID: Thread-Topic: [NSIS] framework: proposal on fragmentation Thread-Index: AcMsQdKUELnYcrulT6S901ILel5oDwAADQyw To: , Cc: , , , X-OriginalArrivalTime: 06 Jun 2003 15:41:41.0278 (UTC) FILETIME=[1FFF13E0:01C32C42] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56FfkB02631 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, > > Use IP-fragmentation > > IP fragmentation is a problem for NATs. That's a problem > for a discovery (addressed end-to-end) message, which in > turn is a problem for us if we wish to support a middlebox > application. Agreed. Also, handling fragmentation does not imply a connection-oriented protocol. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 11:53: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 LAA29464 for ; Fri, 6 Jun 2003 11:53:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56FrCS03158 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 11:53:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56Fr7B03125; Fri, 6 Jun 2003 11:53:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56Fh1B02713 for ; Fri, 6 Jun 2003 11:43:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29008 for ; Fri, 6 Jun 2003 11:42:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJL0-0003FO-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:41:06 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19OJKz-0003FH-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:41:05 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jun 2003 16:42:58 +0100 Message-ID: From: "Hancock, Robert" To: "'Lars.Westberg'" Cc: Tom Taylor , Georgios Karagiannis , nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation Date: Fri, 6 Jun 2003 16:42:49 +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: , OK - this was option 1 in the original email summary. There seemed to be some resistance to it from several places and a preference to the NTLP approach. What I can imagine you suggesting is: try to get the NSLP to create messages which don't require fragmentation at all (by doing the fragmentation itself); in the [hopefully rare] cases where something goes wrong, rely on the IP layer to handle it. That's an approach - I think it's a much more credible approach than relying on the NSLP alone, but given the unpleasantness about doing it at either IP or NSLP, I still prefer the NTLP option. Anyway, people need to make the argument about which is better and why: IP only NTLP only NSLP only IP+NSLP The other point is: since we are arguing about the fragmentation aspect (rather than the reassembly aspect) .... just how difficult is it to chop up a message and put a common header on each part? And how much complexity is it worth putting in the rest of the network architecture to save doing it? cheers, r. > -----Original Message----- > From: Lars.Westberg [mailto:Lars.Westberg@era.ericsson.se] > Sent: 06 June 2003 16:27 > To: Hancock, Robert > Cc: Tom Taylor; Georgios Karagiannis; nsis@ietf.org > Subject: Re: [NSIS] framework: proposal on fragmentation > > > Use IP-fragmentation > > -lasse > > "Hancock, Robert" wrote: > > > aha! > > > > > > > > No, I trying to explain it: > > > If you have a network element without knowledge of the NSLP:s > > > requirment, the > > > default should be to forward it to the next hop without doing > > > anything to the > > > NSLP-messages. > > > > *** and what if the message is too big to forward? *** > > [which is where we started...] > > > > > > > > regards Lasse > > > > > > > r. > > > > > -------------------------------------------------------------- > ---------- > > Name: RMRL-Disclaimer.txt > > RMRL-Disclaimer.txt Type: Plain Text (text/plain) > > Encoding: 7bit > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 12:12: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 MAA00459 for ; Fri, 6 Jun 2003 12:12:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56GBci05940 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 12:11:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GBNB05880; Fri, 6 Jun 2003 12:11:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56G15B03942 for ; Fri, 6 Jun 2003 12:01:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29882 for ; Fri, 6 Jun 2003 12:01:02 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJcU-0003TT-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:59:10 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19OJcT-0003TQ-00 for nsis@ietf.org; Fri, 06 Jun 2003 11:59:09 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h56G12W05506 for ; Fri, 6 Jun 2003 19:01:02 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Jun 2003 19:01:01 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 19:01:01 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 19:01:01 +0300 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] framework: proposal on fragmentation Date: Fri, 6 Jun 2003 19:01:00 +0300 Message-ID: Thread-Topic: [NSIS] framework: proposal on fragmentation Thread-Index: AcMsPH5yMSY5bLE7RoKcbfDzWXmt7wACAawQ To: , Cc: X-OriginalArrivalTime: 06 Jun 2003 16:01:01.0388 (UTC) FILETIME=[D379D0C0:01C32C44] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56G16B03943 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 Lars, > The generality of NTLP is a difficutl issue. My point is that I can > forsee application that is so simple that an UDP-style of operation is good enough. Some aspects of UDP may be sufficient for NTLP, but there are well known problems of UDP-based protocols transiting middleboxes, so we should try to limit such problems. Fragmentation is one well known one. A possible solution could be a NTLP running over UDP, where NTLP did the fragmentation. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 12:13: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 MAA00634 for ; Fri, 6 Jun 2003 12:13:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56GDAd06182 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 12:13:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GD5B06110; Fri, 6 Jun 2003 12:13:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GB0B05810 for ; Fri, 6 Jun 2003 12:11:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00370 for ; Fri, 6 Jun 2003 12:10:56 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJm4-0003aB-00 for nsis@ietf.org; Fri, 06 Jun 2003 12:09:04 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19OJm3-0003a8-00 for nsis@ietf.org; Fri, 06 Jun 2003 12:09:03 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h56GAuD25926 for ; Fri, 6 Jun 2003 19:10:56 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Jun 2003 19:10:56 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 19:10:55 +0300 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 19:10:55 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 6 Jun 2003 19:10:54 +0300 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] framework: proposal on fragmentation Date: Fri, 6 Jun 2003 19:10:53 +0300 Message-ID: Thread-Topic: [NSIS] framework: proposal on fragmentation Thread-Index: AcMsO7q+Pveu15ocQf6ONGqdWNhq1wACmCkg To: , Cc: , , X-OriginalArrivalTime: 06 Jun 2003 16:10:54.0440 (UTC) FILETIME=[34F65E80:01C32C46] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h56GB0B05811 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 Lasse, > My proposal is that we trying to develop two modes of NTLP-operation: > > - RSVPover SCTP > - RSVPoverUDP This is not relevant to the framework, I think. I think the framework should not be specifying the transport protocol, but rather the NTLP document. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 6 12:13: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 MAA00660 for ; Fri, 6 Jun 2003 12:13:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56GDCo06205 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 12:13:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56GD7B06155; Fri, 6 Jun 2003 12:13:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56G5tB04263 for ; Fri, 6 Jun 2003 12:05:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00160 for ; Fri, 6 Jun 2003 12:05:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJh9-0003WE-00 for nsis@ietf.org; Fri, 06 Jun 2003 12:03:59 -0400 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 19OJh8-0003WB-00 for nsis@ietf.org; Fri, 06 Jun 2003 12:03:58 -0400 Received: from cs.uni-goettingen.de (IBZGate.ibz.gwdg.de [::ffff:134.76.38.21]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Fri, 06 Jun 2003 18:05:56 +0200 Message-ID: <3EE0BB94.4030403@cs.uni-goettingen.de> Date: Fri, 06 Jun 2003 18:04:36 +0200 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: Melinda Shore CC: "Hancock, Robert" , nsis@ietf.org Subject: Re: [NSIS] framework: proposal on fragmentation References: <200306061538.AIB80399@mira-sjc5-c.cisco.com> In-Reply-To: <200306061538.AIB80399@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 What about discovering also (max) MTU, in addition to next NTLP node's IP address? Then no intermdiate nodes between two NTLP peers should do fragmentation. Xiaoming Melinda Shore wrote: >>Use IP-fragmentation > > > IP fragmentation is a problem for NATs. That's a problem > for a discovery (addressed end-to-end) message, which in > turn is a problem for us if we wish to support a middlebox > application. > > 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 Fri Jun 6 16:33: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 QAA11550 for ; Fri, 6 Jun 2003 16:33:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56KWpr27140 for nsis-archive@odin.ietf.org; Fri, 6 Jun 2003 16:32:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56KWdB27118; Fri, 6 Jun 2003 16:32:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56KScB26810 for ; Fri, 6 Jun 2003 16:28:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11400 for ; Fri, 6 Jun 2003 16:28:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ONnN-0006Bj-00 for nsis@ietf.org; Fri, 06 Jun 2003 16:26:41 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19ONnM-0006BE-00 for nsis@ietf.org; Fri, 06 Jun 2003 16:26:40 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h56KRnjc020562; Fri, 6 Jun 2003 13:27:50 -0700 (PDT) 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.3.3-GR) with ESMTP id AEV80543; Fri, 6 Jun 2003 13:27:47 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA08411; Fri, 6 Jun 2003 13:27:47 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16096.63811.549365.475225@thomasm-u1.cisco.com> Date: Fri, 6 Jun 2003 13:27:47 -0700 (PDT) To: Melinda Shore Cc: "Lars.Westberg" , "Hancock, Robert" , Tom Taylor , Georgios Karagiannis , nsis@ietf.org Subject: Re: [NSIS] framework: proposal on fragmentation In-Reply-To: <200306061538.AIB80399@mira-sjc5-c.cisco.com> References: <3EE0B2DD.EA6F910D@era.ericsson.se> <200306061538.AIB80399@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 Melinda Shore writes: > > Use IP-fragmentation > > IP fragmentation is a problem for NATs. That's a problem > for a discovery (addressed end-to-end) message, which in > turn is a problem for us if we wish to support a middlebox > application. Worse, it's a problem for the IESG. Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Jun 9 03: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 DAA22925 for ; Mon, 9 Jun 2003 03:04:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5974Qs06298 for nsis-archive@odin.ietf.org; Mon, 9 Jun 2003 03:04:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5973pB06271; Mon, 9 Jun 2003 03:03:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h596U8B04242 for ; Mon, 9 Jun 2003 02:30:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22287 for ; Mon, 9 Jun 2003 02:30:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PG8R-0007l0-00 for nsis@ietf.org; Mon, 09 Jun 2003 02:28:03 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19PG8Q-0007kx-00 for nsis@ietf.org; Mon, 09 Jun 2003 02:28:02 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19PGAC-000Gd7-00; Mon, 09 Jun 2003 06:29:52 +0000 To: brunner@ccrle.nec.de Cc: john.loughney@nokia.com, nsis@ietf.org, mankin@psg.com Reply-To: mankin@psg.com Date: Sun, 08 Jun 2003 23:29:52 -0700 From: Allison Mankin Message-Id: Subject: [NSIS] AD Review comments on draft-ietf-nsis-req-07.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: , Marcus, John and WG, Here are my AD Review comments on the NSIS requirements. Overall it is a good document. I have a few problems on charter, technical or clarity points. Discussion welcome. Allison -------- However, QoS is not the only field where signaling is used in the Internet. Others might be the use for middlebox communication [RFC3234]. It would be helpful to clarify the manner in which signaling would be used for middlebox communication (in one sentence) - this is so terse, that only if a reader has been in the working group would they understand the sentence. Suggestion: "Signaling might also be used as a communication protocol to set up the state in middleboxes." -------- There are several areas related to networking aspects which are incomplete, for example, interaction with host and site multi- homing, use of anycast services, and so on. These issues should be considered in any future analysis work. Incomplete in the sense of requirements analysis? This paragraph suggests a different kind of analysis. Also anycast in particular seems very unlikely to be a significant element in signaling requirements analysis - it seems like it should not be mentioned in the same sentence with a common issue like multihoming. Suggestion: "This document does not cover requirements in relation to some networking areas, in particular, interaction with host and site multihoming. We leave these for future analysis. " -------- NSIS Initiator - needs to say, in parallel with the NSIS Responder, it interacts with applications (Definition does not say so). -------- 3. Something that terminates the signaling path, the NSIS Responder. The NSIS responder might be in an end-system or within other equipment. The distinguishing feature of the NSIS Initiator is that ^^^^^^^^^ it responds to requests at the end of a signaling path. Typo? s/Initiator/Responder/ -------- The host to first router part includes all the layer 2 technologies to access to the Internet. Consider a home network with a wireless router and a DSL router accessing the Internet. The topology definition is less crisp than host to *first* router. I suggest you add a sentence after this one: "This part of the division is especially informal and may incorporate several access segments." -------- 5.2.2 NSIS MUST support path-coupled and SHOULD NOT exclude path- decoupled signaling. SHOULD NOT is very strong, given that the WG is not chartered to work on this technology. The language needs to be "MAY support path-decoupled signaling." -------- 5.3.2 Automatic release of state after failure SHOULD be possible When the NSIS Initiator goes down, the state it requested in the network SHOULD be released, since it will no longer be necessary. An important feature of RSVP was its soft-state character, in part to ensure that critical resources in the net were not fate-shared for too long. Given this is about release after _failure_, these SHOULDs should be MUSTs, if not going so far as to preserve the soft-state architecture. Comments? -------- 5.4.3 State MUST be addressed independent of flow identification Addressing or identifying state MUST be independent of the flow identifier (flow end-points, topological addresses). Various scenarios in the mobility area require this independence because flows resulting from handoff might have changed end-points etc. but still have the same service requirement. Also several proxy-based signaling methods profit from such independence. Add to the last sentence "though these are not chartered work items for NSIS". This is a tough requirement since it has to be globally unique. It may turn out to be best met by the NI's authentication token, requiring an early integration of authentication design into the protocol. No request to change this, but just noting how hard this is - WG is _sure_ the mobility requirements are really so important? -------- 5.4.1 Mutability information on parameters SHOULD be possible It SHOULD be possible for the NSIS initiator to control the mutability of the signaled information. This prevents them from being changed in a non-recoverable way. The NSIS initiator SHOULD be able to control what is requested end to end, without the request being gradually mutated as it passes through a sequence of domains. This implies that in case of changes made on the parameters, the original requested ones must still be available. Note that we do not require anything about particular parameters being changed. Additionally, note that the provider of the particular requested services can still influence the provisioning but in the signaling message the request should stay the same. The requirement is not expressed well. Do you mean "It SHOULD be possible to have nodes modify parameters to interact with the signaling message, while still retaining an intact copy of the original form of the signaling message"? This requirement seems like it would vary a great deal depending on what the signaling application was, and as it is written here it is very close to a protocol design rather than a requirement. Could you omit it from this document? -------- One of the reasons is that the protocol handling should have a minimal impact on interior (core) nodes. Suggest adding that NSIS MAY also have a feature allowing core nodes to ignore it (though I hope it will be more elegant than RSVP's as document in RFC 3175 :) -------- 5.7.5 Hop-by-hop security Hop-by-Hop security SHOULD be supported. It is a well known and proven concept in Quality-of-Service and other signaling protocols that allows intermediate nodes that actively participate in the protocol to modify the messages as it is required by processing rules. Note that this requirement does not exclude end-to-end or network-to-network security of a signaling message. End-to-end security between the initiator and the responder may be used to provide protection of non-mutable data fields. Network-to-network security refers to the protection of messages over various hops but not in an end-to-end manner i.e. protected over a particular network. Without minimum mandatory to implement channel security for the signaling, you can't be sure the other security features will be untampered with - this needs to be a MUST implement (it's not a MUST use). Suggest changing the first sentence to "Channel security between signaling entities MUST be implemented'? -------- 5.9.5 SHOULD interwork with seamless handoff protocols 5.9.6 MAY interwork with non-traditional routing NSIS assumes L3 routing, but networks, which do non-traditional routing, should not break it. NSIS should not be complex and interworked in ways that make it less modular. Both of these requirements are complications. The first one, because it poses a certain environment and particular protocols, would make NSIS less modular. It is probably improved by changing SHOULD to MAY. The second one may sound worse than it is - does it mean NATs? Suggest this might have meant: 5.9.6. MAY operate in varied routing environments NSIS assumes L3 routing, but it MAY be designed to operate in varied routing environments, such as those with L4 switches and NATs. But if not, do explain... -------- Scenarios - 's' as an abbreviation is not explained. -------- 10.2 The 3G Scenario is somewhat too specific to 3GPP and 3GPP2 still - IMS is mentioned without being expanded or explained. All the terms are specific. Try to make it a bit more abstract - say it is an All-IP multimedia system. -------- This part of the wireless network has different characteristics when compared to traditional IP networks: 1. The network supports a high proportion of real-time traffic. The majority of the traffic transported in the wired part of the wireless network is speech, which is very sensitive to delays and delay variation (jitter). Two things about IP networks - they carry whatever they carry, so it's not out of tradition to be a voice IP network. Second, speech in Internet phones is quite a lot less sensitive to delays and jitter than often thought, due to the many good engineering designs in playout and speech cover that are known. So this material places a context of more difference on the environment than most general transport experts view as necessary, seeing more continuum, while not disagreeing that signaling and resource reservation are valuable. So drop sentence 1, but leave the rest alone (I just wanted to make my point :) -------- 10.10 Application request end-to-end QoS path from the network This is actually the easiest case, nevertheless might be most often used in terms of number of users. Few believe that ordinary applications signaling for QoS is an easy matter for the network - RFCs 2961, 2996 and 3175 are all about mitigating the unscalability of edge signaling. Probably this would go better if you substitute the term "conceptually simplest" for "easiest" and note that there are these issues with scaling. Additionally, we assume no mobility and standard devices. Note: the end system application and NSIS do not know about the distinction between 10.10 and the other scenarios :), unless NSIS is not a modular Internet protocol. -------- QoS for Virtual Private Networks - section needs a number IP-Sec -> IPSec The discussion of NSIS in VPNs ignores the whole world of the PPVPN WG. Cite draft-ietf-ppvpn-framework-08.txt early on in the section (it is in the RFC-Editor Queue). Allison _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Jun 9 07:17: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 HAA27934 for ; Mon, 9 Jun 2003 07:17:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59BGYZ24381 for nsis-archive@odin.ietf.org; Mon, 9 Jun 2003 07:16:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59BGTB24370; Mon, 9 Jun 2003 07:16:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59BFwB24343 for ; Mon, 9 Jun 2003 07:15:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27924 for ; Mon, 9 Jun 2003 07:15:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PKb6-0001nF-00 for nsis@ietf.org; Mon, 09 Jun 2003 07:13:56 -0400 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx with esmtp (Exim 4.12) id 19PKb6-0001n3-00 for nsis@ietf.org; Mon, 09 Jun 2003 07:13:56 -0400 Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.9/8.12.2) with ESMTP id h59BF6ra027407 for ; Mon, 9 Jun 2003 07:15:06 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.12.9/8.12.2/Submit) id h59BF6oW027406 for nsis@ietf.org; Mon, 9 Jun 2003 07:15:06 -0400 (EDT) Date: Mon, 9 Jun 2003 07:15:06 -0400 (EDT) From: Scott Bradner Message-Id: <200306091115.h59BF6oW027406@newdev.harvard.edu> To: nsis@ietf.org Subject: Re: [NSIS] AD Review comments on draft-ietf-nsis-req-07.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: , allison suggests: > Suggestion: "Signaling might also be used as a communication protocol > to set up the state in middleboxes." setup and maintain? Scott _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Jun 9 10:42: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 KAA07293 for ; Mon, 9 Jun 2003 10:42:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59EgDO07030 for nsis-archive@odin.ietf.org; Mon, 9 Jun 2003 10:42:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59EfpB07009; Mon, 9 Jun 2003 10:41:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59Ed2B06891 for ; Mon, 9 Jun 2003 10:39:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07047 for ; Mon, 9 Jun 2003 10:38:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PNlY-0003uu-00 for nsis@ietf.org; Mon, 09 Jun 2003 10:36:56 -0400 Received: from mail-gw.carrieraccess.com ([65.221.135.10] helo=[172.1.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19PNlX-0003tq-00 for nsis@ietf.org; Mon, 09 Jun 2003 10:36:55 -0400 Received: from newman.carrieraccess.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 9 Jun 2003 08:38:15 -0600 Received: by newman.carrieraccess.com with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Jun 2003 08:38:10 -0600 Message-ID: From: "Avella, Alejandro" To: "'mankin@psg.com'" , brunner@ccrle.nec.de Cc: john.loughney@nokia.com, nsis@ietf.org Subject: RE: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt Date: Mon, 9 Jun 2003 08:38:05 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative ; boundary="----_=_NextPart_001_01C32E94.BC92F150" 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_01C32E94.BC92F150 Content-Type: text/plain Allison Mankin wrote: >Second, speech in Internet phones is quite a lot less sensitive to delays and jitter than >often thought, due to the many good engineering designs in playout and >speech cover that are known. From draft-ietf-nsis-req-07.txt, Page 27. 1. The network supports a high proportion of real-time traffic. The majority of the traffic transported in the wired part of the wireless network is speech, which is very sensitive to delays and delay variation (jitter). Comment on Requirements document: Consider being more specificic on the sentence above. Voice requirements for toll-quality are: a) One way delay < 150 ms from ITU-T G.114 (Round Trip delay < 300 ms) b) Jitter < 50 ms c) Packet Loss < 10^-5 I obtained the above values from section 3.1 of the following paper. M. Karam, F. Tobagi, "Analysis of Delay and Delay Jitter of Voice Traffic in the Internet", Computer Networks 40 (2002) 711-726 http://www.stanford.edu/class/ee384b/reading/KaramTobagi.pdf Alejandro Avella ************************************************************************* 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_01C32E94.BC92F150 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt

Allison Mankin wrote:
>Second, speech in Internet phones is quite a lot les= s sensitive to delays and jitter than
>often thought, due to the many good engineering desi= gns in playout and
>speech cover that are known. 

From draft-ietf-nsis-req-07.txt, Page 27.

         1. The n= etwork supports a high proportion of real-time
         &n= bsp;  traffic.  The majority of the traffic transported in the
         &n= bsp;  wired part of the wireless network is speech, which is
         &n= bsp;  very sensitive to delays and delay variation (jitter).

Comment on Requirements document:
Consider being more specificic on the sentence above.&nb= sp; Voice requirements for toll-quality are:
a) One way delay < 150 ms from ITU-T G.114 (Round Tri= p delay < 300 ms)
b) Jitter < 50 ms
c) Packet Loss < 10^-5

I obtained the above values from section 3.1 of the follo= wing paper.

M. Karam, F. Tobagi, "Analysis of Delay and Delay Ji= tter of Voice Traffic in the Internet", Computer Networks 40 (2002) 71= 1-726 http://www.stanford.edu/class/ee384b/reading/KaramTob= agi.pdf

Alejandro Avella



************************************************************************* 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_01C32E94.BC92F150-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Jun 9 10:58: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 KAA07744 for ; Mon, 9 Jun 2003 10:58:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59EwTv07737 for nsis-archive@odin.ietf.org; Mon, 9 Jun 2003 10:58:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59EwAB07714; Mon, 9 Jun 2003 10:58:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59EtPB07528 for ; Mon, 9 Jun 2003 10:55:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07571 for ; Mon, 9 Jun 2003 10:55:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PO1P-00042e-00 for nsis@ietf.org; Mon, 09 Jun 2003 10:53:19 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19PO1O-00042b-00 for nsis@ietf.org; Mon, 09 Jun 2003 10:53:18 -0400 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.8p1/8.12.8) with ESMTP id h59EtCrI016263 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 Jun 2003 10:55:13 -0400 (EDT) Message-ID: <3EE49EE1.9010805@cs.columbia.edu> Date: Mon, 09 Jun 2003 10:51:13 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Avella, Alejandro" CC: "'mankin@psg.com'" , brunner@ccrle.nec.de, john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) 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 We've done recent measurements on this topic. See http://edas.info/S.cgi?bibkey=Jian0305:Qos http://edas.info/S.cgi?bibkey=Jian0305:Assessment http://edas.info/S.cgi?bibkey=Jian0208:Comparisons From our experience, jitter itself does not matter, but it effectively translates into additional delay that is at least as large as the jitter range, but typically somewhat larger since playout delay algorithms can't be perfect. The packet loss numbers cited below do not correspond to any recent real measurements. However, MPEG2 video is said to be significantly more loss sensitive than speech. Avella, Alejandro wrote: > Allison Mankin wrote: > >Second, speech in Internet phones is quite a lot less sensitive to > delays and jitter than > >often thought, due to the many good engineering designs in playout and > >speech cover that are known. > > From draft-ietf-nsis-req-07.txt, Page 27. > > 1. The network supports a high proportion of real-time > traffic. The majority of the traffic transported in the > wired part of the wireless network is speech, which is > very sensitive to delays and delay variation (jitter). > > Comment on Requirements document: > Consider being more specificic on the sentence above. Voice > requirements for toll-quality are: > a) One way delay < 150 ms from ITU-T G.114 (Round Trip delay < 300 ms) > b) Jitter < 50 ms > c) Packet Loss < 10^-5 > > I obtained the above values from section 3.1 of the following paper. > > M. Karam, F. Tobagi, "Analysis of Delay and Delay Jitter of Voice > Traffic in the Internet", Computer Networks 40 (2002) 711-726 > http://www.stanford.edu/class/ee384b/reading/KaramTobagi.pdf > > Alejandro Avella > > | > > ************************************************************************* > 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. > ************************************************************************* > | _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Jun 9 11:51: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 LAA09599 for ; Mon, 9 Jun 2003 11:51:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59FpMi12098 for nsis-archive@odin.ietf.org; Mon, 9 Jun 2003 11:51:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59FpGB12087; Mon, 9 Jun 2003 11:51:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59FowB12064 for ; Mon, 9 Jun 2003 11:50:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09579 for ; Mon, 9 Jun 2003 11:50:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19POtD-0004ZT-00 for nsis@ietf.org; Mon, 09 Jun 2003 11:48:55 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19POtC-0004ZP-00 for nsis@ietf.org; Mon, 09 Jun 2003 11:48:54 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 9 Jun 2003 16:50:54 +0100 Message-ID: From: "Hancock, Robert" To: nsis@ietf.org Subject: RE: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt Date: Mon, 9 Jun 2003 16:50:51 +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 all, i have a few comments on some of these: 5.3.2/5.4.3/5.4.1/5.9.5/5.9.6 cheers, robert h. > 5.3.2 Automatic release of state after failure SHOULD be possible > > When the NSIS Initiator goes down, the state it requested in the > network SHOULD be released, since it will no longer be necessary. > > An important feature of RSVP was its soft-state character, in part to > ensure that critical resources in the net were not > fate-shared for too long. > Given this is about release after _failure_, these SHOULDs > should be MUSTs, > if not going so far as to preserve the soft-state > architecture. Comments? [reh] I would have no problems with a 'MUST' here, but I suspect the word 'possible' has to be kept as well. That is, some people were quite concerned that transient failures in NSIS processing shouldn't necessarily have to cause all state to be released (a sort of 'NSIS hitless restart' possibility). Some of this is as much an operational matter as a protocol requirements matter, of course. > > -------- > > > 5.4.3 State MUST be addressed independent of flow identification > > Addressing or identifying state MUST be independent of the flow > identifier (flow end-points, topological addresses). Various > scenarios in the mobility area require this independence because > flows resulting from handoff might have changed end-points > etc. but > still have the same service requirement. Also several proxy-based > signaling methods profit from such independence. > > Add to the last sentence "though these are not chartered work > items for > NSIS". > > This is a tough requirement since it has to be globally > unique. It may > turn out to be best met by the NI's authentication token, requiring an > early integration of authentication design into the protocol. > No request > to change this, but just noting how hard this is - WG is _sure_ > the mobility requirements are really so important? > > -------- [reh] This requirement has a tortured history, and the difficulties in meeting it have been discussed several times (coming up with a sensible way to secure the identification seems even harder); there is an I-D in preparation on that subject. If making MUST->SHOULD would seem less reckless that might be a good idea (it won't stop us looking for good solutions after all). > > > 5.4.1 Mutability information on parameters SHOULD be possible > > It SHOULD be possible for the NSIS initiator to control the > mutability of the signaled information. This prevents them from > being changed in a non-recoverable way. The NSIS initiator > SHOULD be > able to control what is requested end to end, without the request > being gradually mutated as it passes through a sequence of > domains. > This implies that in case of changes made on the parameters, the > original requested ones must still be available. > > Note that we do not require anything about particular parameters > being changed. > > Additionally, note that the provider of the particular requested > services can still influence the provisioning but in the signaling > message the request should stay the same. > > The requirement is not expressed well. Do you mean "It SHOULD be > possible to have nodes modify parameters to interact with the > signaling message, while still retaining an intact copy of the > original form of the signaling message"? > > This requirement seems like it would vary a great deal > depending on what > the signaling application was, and as it is written here it > is very close > to a protocol design rather than a requirement. Could you omit > it from this document? [reh] IIRC the motivation behind this was to recognise that nodes would change messages, but they shouldn't be allowed to have their modified messages masquerade as the originals. So, Allison's reformulation covers most of the point, but there is also the issue of the originator's desire to control the process. The discussion here was very similar to what I later saw in a much more concrete form in draft-rosenberg-sipping-session-policy-00.txt (now expired). I'm not sure if a specific requirement is needed, but I still think the point should be covered somehow. > -------- > > > 5.9.5 SHOULD interwork with seamless handoff protocols > > 5.9.6 MAY interwork with non-traditional routing > > NSIS assumes L3 routing, but networks, which do non-traditional > routing, should not break it. > > NSIS should not be complex and interworked in ways that make > it less modular. > Both of these requirements are complications. The first one, > because it poses > a certain environment and particular protocols, would make > NSIS less modular. > It is probably improved by changing SHOULD to MAY. The > second one may sound > worse than it is - does it mean NATs? Suggest this might have meant: > > 5.9.6. MAY operate in varied routing environments > > NSIS assumes L3 routing, but it MAY be designed to operate in > varied routing environments, such as those with L4 > switches and NATs. > > But if not, do explain... > -------- There are two issues here: a) the handoff protocols requirement is supposedly a sort of reflection of what is (currently) in the charter, i.e. "The work produced in this Working Group should work with existing IETF mobility ... protocols, including ... SeaMoby Context Transfer...". There was a long-ish discussion cross-posted with seamoby on how to draw the boundary between NSIS features which could be used in mobile networks and seamless handover protocols themselves. Given that we have to draw a boundary round NSIS somehow, that sort of analysis seems reasonable, and not likely to decrease modularity/usefulness. Maybe the word 'interwork' is problematic. 'Work with' or 'coexist rationally with' might be better. b) The second requirement is about wanting NSIS protocols that aren't broken by the presence of policy-based forwarding in NSIS-unaware regions of the network. Again, 'interwork' is probably the wrong word. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Jun 10 03:52: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 DAA16305 for ; Tue, 10 Jun 2003 03:52:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5A7qA926013 for nsis-archive@odin.ietf.org; Tue, 10 Jun 2003 03:52:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A7ppB26000; Tue, 10 Jun 2003 03:51:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A7oTB25955 for ; Tue, 10 Jun 2003 03:50:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16285 for ; Tue, 10 Jun 2003 03:50:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pdrl-0002iC-00 for nsis@ietf.org; Tue, 10 Jun 2003 03:48:25 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19Pdrk-0002i9-00 for nsis@ietf.org; Tue, 10 Jun 2003 03:48:24 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h5A7oG5s007249; Tue, 10 Jun 2003 09:50:18 +0200 (MET DST) Message-ID: <009501c32f24$f0490030$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" , "'Lars.Westberg'" Cc: References: Subject: Re: [NSIS] framework: proposal on fragmentation Date: Tue, 10 Jun 2003 09:50:16 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Robert What I actually propose is to enhance the flexibility of the NTLP protocol by giving the ability to a NSLP to request or not to request the NTLP fragmentation feature. A possible method of doing this is as follows: First of all the NTLP protocol has to use some information, e.g., a fragmentation bit, to specify that fragmentation is allowed or not. Now, if the sender NSLP (NI) informs its NTLP instance to switch off the fragmentation, then this NTLP instance will switch off the fragmentation bit. In this way all the intermediate NTLP nodes will know that fragmentation is not allowed. Note that in this case NTLP negotiation is not needed! Best regards, Georgios ----- Original Message ----- From: "Hancock, Robert" To: "'Lars.Westberg'" Cc: "Tom Taylor" ; "Georgios Karagiannis" ; Sent: Friday, June 06, 2003 5:42 PM Subject: RE: [NSIS] framework: proposal on fragmentation > OK - this was option 1 in the original email summary. There seemed to > be some resistance to it from several places and a preference to the > NTLP approach. > > What I can imagine you suggesting is: try to get the NSLP to create messages > which don't require fragmentation at all (by doing the fragmentation > itself); > in the [hopefully rare] cases where something goes wrong, rely on the IP > layer to handle it. > > That's an approach - I think it's a much more credible approach than > relying on the NSLP alone, but given the unpleasantness about doing it > at either IP or NSLP, I still prefer the NTLP option. Anyway, people > need to make the argument about which is better and why: > IP only > NTLP only > NSLP only > IP+NSLP > > The other point is: since we are arguing about the fragmentation aspect > (rather than the reassembly aspect) .... just how difficult is it to > chop up a message and put a common header on each part? And how much > complexity is > it worth putting in the rest of the network architecture to save doing it? > > cheers, > > r. > > > -----Original Message----- > > From: Lars.Westberg [mailto:Lars.Westberg@era.ericsson.se] > > Sent: 06 June 2003 16:27 > > To: Hancock, Robert > > Cc: Tom Taylor; Georgios Karagiannis; nsis@ietf.org > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > Use IP-fragmentation > > > > -lasse > > > > "Hancock, Robert" wrote: > > > > > aha! > > > > > > > > > > > No, I trying to explain it: > > > > If you have a network element without knowledge of the NSLP:s > > > > requirment, the > > > > default should be to forward it to the next hop without doing > > > > anything to the > > > > NSLP-messages. > > > > > > *** and what if the message is too big to forward? *** > > > [which is where we started...] > > > > > > > > > > > regards Lasse > > > > > > > > > > r. > > > > > > > > -------------------------------------------------------------- > > ---------- > > > Name: RMRL-Disclaimer.txt > > > RMRL-Disclaimer.txt Type: Plain Text (text/plain) > > > Encoding: 7bit > > > _______________________________________________ > 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 Jun 10 04:08: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 EAA16621 for ; Tue, 10 Jun 2003 04:07:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5A87W127440 for nsis-archive@odin.ietf.org; Tue, 10 Jun 2003 04:07:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A87NB27288; Tue, 10 Jun 2003 04:07:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A86kB26914 for ; Tue, 10 Jun 2003 04:06:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16580 for ; Tue, 10 Jun 2003 04:06:43 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pe7W-0002mj-00 for nsis@ietf.org; Tue, 10 Jun 2003 04:04:42 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19Pe7V-0002mg-00 for nsis@ietf.org; Tue, 10 Jun 2003 04:04:41 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5A86g908221 for ; Tue, 10 Jun 2003 11:06:42 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 10 Jun 2003 11:06:42 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 10 Jun 2003 11:06:42 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 10 Jun 2003 11:06:41 +0300 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: Tue, 10 Jun 2003 11:06:41 +0300 Message-ID: Thread-Topic: AD Review comments on draft-ietf-nsis-req-07.txt Thread-Index: AcMuUJILM0fXnKX3SnGKfzq8teabAgA1lFSQ To: , Cc: X-OriginalArrivalTime: 10 Jun 2003 08:06:41.0761 (UTC) FILETIME=[39DE5D10:01C32F27] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5A86lB26936 Subject: [NSIS] RE: AD Review comments on draft-ietf-nsis-req-07.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: , Content-Transfer-Encoding: 8bit Hi Allison, Thanks for the comments. I think that the comments below can be adopted in the document. I will discuss with Marcus a plan to make the changes and get the document submitted so that this can be sent to the IESG. As there is already WG consensus on this draft, we should avoid major discussion of the points, unless there is serious disagreement on them. thanks, John > -----Original Message----- > From: ext Allison Mankin [mailto:mankin@psg.com] > Sent: 09 June, 2003 09:30 > To: brunner@ccrle.nec.de > Cc: Loughney John (NRC/Helsinki); nsis@ietf.org; mankin@psg.com > Subject: AD Review comments on draft-ietf-nsis-req-07.txt > > > Marcus, John and WG, > > Here are my AD Review comments on the NSIS requirements. Overall > it is a good document. I have a few problems on charter, technical > or clarity points. Discussion welcome. > > Allison > > -------- > However, QoS is not the only field where signaling > is used in the Internet. Others might be the use for middlebox > communication [RFC3234]. > > It would be helpful to clarify the manner in which signaling would be > used for middlebox communication (in one sentence) - this is > so terse, that > only if a reader has been in the working group would they > understand the > sentence. > > Suggestion: "Signaling might also be used as a communication protocol > to set up the state in middleboxes." > > -------- > > There are several areas related to networking aspects which are > incomplete, for example, interaction with host and site multi- > homing, use of anycast services, and so on. These issues should be > considered in any future analysis work. > > Incomplete in the sense of requirements analysis? This > paragraph suggests > a different kind of analysis. Also anycast in particular > seems very unlikely > to be a significant element in signaling requirements > analysis - it seems > like it should not be mentioned in the same sentence with a > common issue > like multihoming. > > Suggestion: "This document does not cover requirements in > relation to some > networking areas, in particular, interaction with host and > site multihoming. > We leave these for future analysis. " > > -------- > > NSIS Initiator - needs to say, in parallel with the NSIS Responder, > it interacts with applications (Definition does not say so). > > -------- > 3. Something that terminates the signaling path, the NSIS Responder. > > The NSIS responder might be in an end-system or within other > equipment. The distinguishing feature of the NSIS Initiator is that > ^^^^^^^^^ > it responds to requests at the end of a signaling path. > > Typo? s/Initiator/Responder/ > > -------- > The host to first > router part includes all the layer 2 technologies to access to the > Internet. > > Consider a home network with a wireless router and a DSL > router accessing > the Internet. The topology definition is less crisp than > host to *first* > router. I suggest you add a sentence after this one: "This > part of the > division is especially informal and may incorporate several > access segments." > -------- > > 5.2.2 NSIS MUST support path-coupled and SHOULD NOT exclude path- > decoupled signaling. > > SHOULD NOT is very strong, given that the WG is not chartered > to work on > this technology. > > The language needs to be "MAY support path-decoupled signaling." > > -------- > > 5.3.2 Automatic release of state after failure SHOULD be possible > > When the NSIS Initiator goes down, the state it requested in the > network SHOULD be released, since it will no longer be necessary. > > An important feature of RSVP was its soft-state character, in part to > ensure that critical resources in the net were not > fate-shared for too long. > Given this is about release after _failure_, these SHOULDs > should be MUSTs, > if not going so far as to preserve the soft-state > architecture. Comments? > > -------- > > > 5.4.3 State MUST be addressed independent of flow identification > > Addressing or identifying state MUST be independent of the flow > identifier (flow end-points, topological addresses). Various > scenarios in the mobility area require this independence because > flows resulting from handoff might have changed end-points > etc. but > still have the same service requirement. Also several proxy-based > signaling methods profit from such independence. > > Add to the last sentence "though these are not chartered work > items for > NSIS". > > This is a tough requirement since it has to be globally > unique. It may > turn out to be best met by the NI's authentication token, requiring an > early integration of authentication design into the protocol. > No request > to change this, but just noting how hard this is - WG is _sure_ > the mobility requirements are really so important? > > -------- > > > 5.4.1 Mutability information on parameters SHOULD be possible > > It SHOULD be possible for the NSIS initiator to control the > mutability of the signaled information. This prevents them from > being changed in a non-recoverable way. The NSIS initiator > SHOULD be > able to control what is requested end to end, without the request > being gradually mutated as it passes through a sequence of > domains. > This implies that in case of changes made on the parameters, the > original requested ones must still be available. > > Note that we do not require anything about particular parameters > being changed. > > Additionally, note that the provider of the particular requested > services can still influence the provisioning but in the signaling > message the request should stay the same. > > The requirement is not expressed well. Do you mean "It SHOULD be > possible to have nodes modify parameters to interact with the > signaling message, while still retaining an intact copy of the > original form of the signaling message"? > > This requirement seems like it would vary a great deal > depending on what > the signaling application was, and as it is written here it > is very close > to a protocol design rather than a requirement. Could you omit > it from this document? > > -------- > > One of the > reasons is that the protocol handling should have a minimal impact > on interior (core) nodes. > > Suggest adding that NSIS MAY also have a feature allowing core nodes > to ignore it (though I hope it will be more elegant than RSVP's as > document in RFC 3175 :) > > -------- > > 5.7.5 Hop-by-hop security > > Hop-by-Hop security SHOULD be supported. It is a well known and > proven concept in Quality-of-Service and other signaling protocols > that allows intermediate nodes that actively participate in the > protocol to modify the messages as it is required by processing > rules. Note that this requirement does not exclude end-to-end or > network-to-network security of a signaling message. End-to-end > security between the initiator and the responder may be used to > provide protection of non-mutable data fields. Network-to-network > security refers to the protection of messages over various > hops but > not in an end-to-end manner i.e. protected over a > particular network. > > Without minimum mandatory to implement channel security for > the signaling, > you can't be sure the other security features will be > untampered with - > this needs to be a MUST implement (it's not a MUST use). > Suggest changing > the first sentence to "Channel security between signaling entities > MUST be implemented'? > > -------- > > > 5.9.5 SHOULD interwork with seamless handoff protocols > > 5.9.6 MAY interwork with non-traditional routing > > NSIS assumes L3 routing, but networks, which do non-traditional > routing, should not break it. > > NSIS should not be complex and interworked in ways that make > it less modular. > Both of these requirements are complications. The first one, > because it poses > a certain environment and particular protocols, would make > NSIS less modular. > It is probably improved by changing SHOULD to MAY. The > second one may sound > worse than it is - does it mean NATs? Suggest this might have meant: > > 5.9.6. MAY operate in varied routing environments > > NSIS assumes L3 routing, but it MAY be designed to operate in > varied routing environments, such as those with L4 > switches and NATs. > > But if not, do explain... > -------- > > Scenarios - > > 's' as an abbreviation is not explained. > > -------- > 10.2 > > The 3G Scenario is somewhat too specific to 3GPP and 3GPP2 > still - IMS is > mentioned without being expanded or explained. All the terms > are specific. > Try to make it a bit more abstract - say it is an All-IP > multimedia system. > > -------- > This part of the wireless network has different > characteristics when compared to traditional IP networks: > > 1. The network supports a high proportion of real-time > traffic. The majority of the traffic transported in the > wired part of the wireless network is speech, which is > very sensitive to delays and delay variation (jitter). > > Two things about IP networks - they carry whatever they carry, so > it's not out of tradition to be a voice IP network. Second, speech in > Internet phones is quite a lot less sensitive to delays and > jitter than > often thought, due to the many good engineering designs in playout and > speech cover that are known. So this material places a > context of more > difference on the environment than most general transport experts view > as necessary, seeing more continuum, while not disagreeing > that signaling > and resource reservation are valuable. > > So drop sentence 1, but leave the rest alone (I just wanted > to make my point :) > > -------- > > > 10.10 Application request end-to-end QoS path from the network > > This is actually the easiest case, nevertheless might be > most often > used in terms of number of users. > > Few believe that ordinary applications signaling for QoS is > an easy matter for > the network - RFCs 2961, 2996 and 3175 are all about > mitigating the unscalability > of edge signaling. Probably this would go better if you > substitute the term > "conceptually simplest" for "easiest" and note that there are > these issues with > scaling. > > > Additionally, we assume no mobility and standard devices. > > Note: the end system application and NSIS do not know about the > distinction between 10.10 and the other scenarios :), unless > NSIS is not > a modular Internet protocol. > > -------- > > QoS for Virtual Private Networks - section needs a number > > IP-Sec -> IPSec > > The discussion of NSIS in VPNs ignores the whole world of the > PPVPN WG. > Cite draft-ietf-ppvpn-framework-08.txt early on in the > section (it is in the > RFC-Editor Queue). > > > > Allison > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Jun 10 04:09: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 EAA16651 for ; Tue, 10 Jun 2003 04:09:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5A899f27959 for nsis-archive@odin.ietf.org; Tue, 10 Jun 2003 04:09:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A893B27947; Tue, 10 Jun 2003 04:09:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A88sB27920 for ; Tue, 10 Jun 2003 04:08:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16643 for ; Tue, 10 Jun 2003 04:08:51 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pe9Z-0002nH-00 for nsis@ietf.org; Tue, 10 Jun 2003 04:06:49 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19Pe9Y-0002nE-00 for nsis@ietf.org; Tue, 10 Jun 2003 04:06:48 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5A88oa04735 for ; Tue, 10 Jun 2003 11:08:50 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 10 Jun 2003 11:08:49 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 10 Jun 2003 11:08:49 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 10 Jun 2003 11:08:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32F27.85808F82" Subject: RE: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt Date: Tue, 10 Jun 2003 11:08:48 +0300 Message-ID: Thread-Topic: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt Thread-Index: AcMulNECw/uR2nGtSKeZIK61GpuS/wAkpdTw To: , , Cc: X-OriginalArrivalTime: 10 Jun 2003 08:08:49.0161 (UTC) FILETIME=[85CE0F90:01C32F27] 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 is a multi-part message in MIME format. ------_=_NextPart_001_01C32F27.85808F82 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Alejandro, =20 I think that as we've already passed WG last call, there isn't a strong = reason to make the changes you propose. =20 thanks, John -----Original Message----- From: ext Avella, Alejandro [mailto:AAvella@carrieraccess.com] Sent: 09 June, 2003 17:38 To: 'mankin@psg.com'; brunner@ccrle.nec.de Cc: Loughney John (NRC/Helsinki); nsis@ietf.org Subject: RE: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt Allison Mankin wrote:=20 >Second, speech in Internet phones is quite a lot less sensitive to = delays and jitter than=20 >often thought, due to the many good engineering designs in playout and=20 >speech cover that are known. =20 From draft-ietf-nsis-req-07.txt, Page 27.=20 1. The network supports a high proportion of real-time=20 traffic. The majority of the traffic transported in the=20 wired part of the wireless network is speech, which is=20 very sensitive to delays and delay variation (jitter).=20 Comment on Requirements document:=20 Consider being more specificic on the sentence above. Voice = requirements for toll-quality are:=20 a) One way delay < 150 ms from ITU-T G.114 (Round Trip delay < 300 ms)=20 b) Jitter < 50 ms=20 c) Packet Loss < 10^-5=20 I obtained the above values from section 3.1 of the following paper.=20 M. Karam, F. Tobagi, "Analysis of Delay and Delay Jitter of Voice = Traffic in the Internet", Computer Networks 40 (2002) 711-726 = http://www.stanford.edu/class/ee384b/reading/KaramTobagi.pdf Alejandro Avella=20 *************************************************************************= This e-mail transmission, and any documents, files, or previous e-mail messages attached to it may contain information that is=20 confidential or legally privileged. If you are not the intended=20 recipient, or a person responsible for delivering it to the=20 intended recipient, you are hereby notified that you must not=20 read this transmission and that any disclosure, copying, printing, distribution, or use of any of the information contained in or=20 attached to this transmission is strictly prohibited. If you have=20 received this transmission in error, please immediately notify the=20 sender by telephone or return e-mail and delete the original=20 transmission and its attachments without reading or saving them=20 in any manner. Thank you. *************************************************************************= ------_=_NextPart_001_01C32F27.85808F82 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] AD Review comments on = draft-ietf-nsis-req-07.txt
Hi=20 Alejandro,
 
I=20 think that as we've already passed WG last call, there isn't a strong = reason to=20 make the changes you propose.
 
thanks,
John
-----Original Message-----
From: ext Avella, = Alejandro=20 [mailto:AAvella@carrieraccess.com]
Sent: 09 June, 2003=20 17:38
To: 'mankin@psg.com'; = brunner@ccrle.nec.de
Cc:=20 Loughney John (NRC/Helsinki); nsis@ietf.org
Subject: RE: = [NSIS] AD=20 Review comments on draft-ietf-nsis-req-07.txt

Allison Mankin wrote:
>Second,=20 speech in Internet phones is quite a lot less sensitive to delays and = jitter=20 than
>often thought, due to the many good = engineering designs in playout and
>speech cover=20 that are known. 

From draft-ietf-nsis-req-07.txt, Page 27. =

         1. = The=20 network supports a high proportion of real-time
          &nbs= p;=20 traffic.  The majority of the traffic transported in the =
          &nbs= p;=20 wired part of the wireless network is speech, which is =
          &nbs= p; very=20 sensitive to delays and delay variation (jitter).

Comment on Requirements document:
Consider being more specificic on the sentence above.  = Voice=20 requirements for toll-quality are:
a) One = way delay=20 < 150 ms from ITU-T G.114 (Round Trip delay < 300 ms) =
b) Jitter < 50 ms
c) Packet Loss = <=20 10^-5

I obtained the above values from section 3.1 of the = following=20 paper.

M. Karam, F. Tobagi, "Analysis of Delay and Delay = Jitter of=20 Voice Traffic in the Internet", Computer Networks 40 (2002) 711-726 htt= p://www.stanford.edu/class/ee384b/reading/KaramTobagi.pdf

Alejandro Avella



********************************************************= *****************
This=20 e-mail transmission, and any documents, files, or previous
e-mail = messages=20 attached to it may contain information that is
confidential or = legally=20 privileged. If you are not the intended
recipient, or a person = responsible=20 for delivering it to the
intended recipient, you are hereby = notified that=20 you must not
read this transmission and that any disclosure, = copying,=20 printing,
distribution, or use of any of the information contained = in or=20
attached to this transmission is strictly prohibited. If you have=20
received this transmission in error, please immediately notify the =
sender by telephone or return e-mail and delete the original=20
transmission and its attachments without reading or saving them =
in any=20 manner. Thank=20 = you.
*****************************************************************= ********
 ------_=_NextPart_001_01C32F27.85808F82-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Jun 10 04:14: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 EAA16702 for ; Tue, 10 Jun 2003 04:14:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5A8EBn28494 for nsis-archive@odin.ietf.org; Tue, 10 Jun 2003 04:14:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A8E5B28486; Tue, 10 Jun 2003 04:14:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A8DQB28461 for ; Tue, 10 Jun 2003 04:13:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16692 for ; Tue, 10 Jun 2003 04:13:23 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PeDx-0002oW-00 for nsis@ietf.org; Tue, 10 Jun 2003 04:11:21 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19PeDx-0002oT-00 for nsis@ietf.org; Tue, 10 Jun 2003 04:11:21 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5A8DMa09442 for ; Tue, 10 Jun 2003 11:13:22 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 10 Jun 2003 11:12:39 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 10 Jun 2003 11:12:39 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 10 Jun 2003 11:12:33 +0300 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] AD Review comments on draft-ietf-nsis-req-07.txt Date: Tue, 10 Jun 2003 11:12:29 +0300 Message-ID: Thread-Topic: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt Thread-Index: AcMueKSwLYX07VDGRVqLru3ALkko1wAr1wrA To: , X-OriginalArrivalTime: 10 Jun 2003 08:12:33.0240 (UTC) FILETIME=[0B5DCD80:01C32F28] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5A8DQB28462 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 Scott, > allison suggests: > > Suggestion: "Signaling might also be used as a > communication protocol to set up the state in middleboxes." > > setup and maintain? Yes, probably so. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Jun 10 04:23: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 EAA16859 for ; Tue, 10 Jun 2003 04:23:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5A8NH528988 for nsis-archive@odin.ietf.org; Tue, 10 Jun 2003 04:23:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A8N9B28979; Tue, 10 Jun 2003 04:23:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A8MeB28938 for ; Tue, 10 Jun 2003 04:22:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16833 for ; Tue, 10 Jun 2003 04:22:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PeMt-0002rK-00 for nsis@ietf.org; Tue, 10 Jun 2003 04:20:35 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 19PeMs-0002rH-00 for nsis@ietf.org; Tue, 10 Jun 2003 04:20:34 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id h5A8MZo00462; Tue, 10 Jun 2003 10:22:35 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h5A8MZc06577; Tue, 10 Jun 2003 10:22:35 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jun 2003 10:22:34 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F036760AB@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'john.loughney@nokia.com'" , mankin@psg.com, brunner@ccrle.nec.de Cc: nsis@ietf.org Subject: RE: [NSIS] RE: AD Review comments on draft-ietf-nsis-req-07.txt Date: Tue, 10 Jun 2003 10:22:29 +0200 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 allison, thank you for pointing to a security issue in the document. > 5.7.5 Hop-by-hop security > > Hop-by-Hop security SHOULD be supported. It is a well known and > proven concept in Quality-of-Service and other signaling protocols > that allows intermediate nodes that actively participate in the > protocol to modify the messages as it is required by processing > rules. Note that this requirement does not exclude end-to-end or > network-to-network security of a signaling message. End-to-end > security between the initiator and the responder may be used to > provide protection of non-mutable data fields. Network-to-network > security refers to the protection of messages over various > hops but > not in an end-to-end manner i.e. protected over a > particular network. > > Without minimum mandatory to implement channel security for > the signaling, > you can't be sure the other security features will be > untampered with - > this needs to be a MUST implement (it's not a MUST use). > Suggest changing > the first sentence to "Channel security between signaling entities > MUST be implemented'? you are fully right. i have no idea how this modification sneaked into the draft. i looked a previous versions of the document and found that it contained a must. i also suggest to change the first sentence from "Hop-by-Hop security SHOULD be supported." to "Channel security between signaling entities MUST be implemented. " ciao hannes > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Tuesday, June 10, 2003 10:07 AM > To: mankin@psg.com; brunner@ccrle.nec.de > Cc: nsis@ietf.org > Subject: [NSIS] RE: AD Review comments on draft-ietf-nsis-req-07.txt > > > Hi Allison, > > Thanks for the comments. I think that the comments below can > be adopted > in the document. I will discuss with Marcus a plan to make > the changes > and get the document submitted so that this can be sent to the IESG. > > As there is already WG consensus on this draft, we should avoid major > discussion of the points, unless there is serious > disagreement on them. > > thanks, > John > > > -----Original Message----- > > From: ext Allison Mankin [mailto:mankin@psg.com] > > Sent: 09 June, 2003 09:30 > > To: brunner@ccrle.nec.de > > Cc: Loughney John (NRC/Helsinki); nsis@ietf.org; mankin@psg.com > > Subject: AD Review comments on draft-ietf-nsis-req-07.txt > > > > > > Marcus, John and WG, > > > > Here are my AD Review comments on the NSIS requirements. Overall > > it is a good document. I have a few problems on charter, technical > > or clarity points. Discussion welcome. > > > > Allison > > > > -------- > > However, QoS is not the only field where signaling > > is used in the Internet. Others might be the use for middlebox > > communication [RFC3234]. > > > > It would be helpful to clarify the manner in which > signaling would be > > used for middlebox communication (in one sentence) - this is > > so terse, that > > only if a reader has been in the working group would they > > understand the > > sentence. > > > > Suggestion: "Signaling might also be used as a > communication protocol > > to set up the state in middleboxes." > > > > -------- > > > > There are several areas related to networking aspects which are > > incomplete, for example, interaction with host and site multi- > > homing, use of anycast services, and so on. These issues > should be > > considered in any future analysis work. > > > > Incomplete in the sense of requirements analysis? This > > paragraph suggests > > a different kind of analysis. Also anycast in particular > > seems very unlikely > > to be a significant element in signaling requirements > > analysis - it seems > > like it should not be mentioned in the same sentence with a > > common issue > > like multihoming. > > > > Suggestion: "This document does not cover requirements in > > relation to some > > networking areas, in particular, interaction with host and > > site multihoming. > > We leave these for future analysis. " > > > > -------- > > > > NSIS Initiator - needs to say, in parallel with the NSIS Responder, > > it interacts with applications (Definition does not say so). > > > > -------- > > 3. Something that terminates the signaling path, the NSIS Responder. > > > > The NSIS responder might be in an end-system or within other > > equipment. The distinguishing feature of the NSIS > Initiator is that > > ^^^^^^^^^ > > it responds to requests at the end of a signaling path. > > > > Typo? s/Initiator/Responder/ > > > > -------- > > The host to first > > router part includes all the layer 2 technologies to > access to the > > Internet. > > > > Consider a home network with a wireless router and a DSL > > router accessing > > the Internet. The topology definition is less crisp than > > host to *first* > > router. I suggest you add a sentence after this one: "This > > part of the > > division is especially informal and may incorporate several > > access segments." > > -------- > > > > 5.2.2 NSIS MUST support path-coupled and SHOULD NOT exclude path- > > decoupled signaling. > > > > SHOULD NOT is very strong, given that the WG is not chartered > > to work on > > this technology. > > > > The language needs to be "MAY support path-decoupled signaling." > > > > -------- > > > > 5.3.2 Automatic release of state after failure SHOULD be possible > > > > When the NSIS Initiator goes down, the state it requested in the > > network SHOULD be released, since it will no longer be > necessary. > > > > An important feature of RSVP was its soft-state character, > in part to > > ensure that critical resources in the net were not > > fate-shared for too long. > > Given this is about release after _failure_, these SHOULDs > > should be MUSTs, > > if not going so far as to preserve the soft-state > > architecture. Comments? > > > > -------- > > > > > > 5.4.3 State MUST be addressed independent of flow identification > > > > Addressing or identifying state MUST be independent of the flow > > identifier (flow end-points, topological addresses). Various > > scenarios in the mobility area require this independence because > > flows resulting from handoff might have changed end-points > > etc. but > > still have the same service requirement. Also several > proxy-based > > signaling methods profit from such independence. > > > > Add to the last sentence "though these are not chartered work > > items for > > NSIS". > > > > This is a tough requirement since it has to be globally > > unique. It may > > turn out to be best met by the NI's authentication token, > requiring an > > early integration of authentication design into the protocol. > > No request > > to change this, but just noting how hard this is - WG is _sure_ > > the mobility requirements are really so important? > > > > -------- > > > > > > 5.4.1 Mutability information on parameters SHOULD be possible > > > > It SHOULD be possible for the NSIS initiator to control the > > mutability of the signaled information. This prevents them from > > being changed in a non-recoverable way. The NSIS initiator > > SHOULD be > > able to control what is requested end to end, without > the request > > being gradually mutated as it passes through a sequence of > > domains. > > This implies that in case of changes made on the parameters, the > > original requested ones must still be available. > > > > Note that we do not require anything about particular parameters > > being changed. > > > > Additionally, note that the provider of the particular requested > > services can still influence the provisioning but in the > signaling > > message the request should stay the same. > > > > The requirement is not expressed well. Do you mean "It SHOULD be > > possible to have nodes modify parameters to interact with the > > signaling message, while still retaining an intact copy of the > > original form of the signaling message"? > > > > This requirement seems like it would vary a great deal > > depending on what > > the signaling application was, and as it is written here it > > is very close > > to a protocol design rather than a requirement. Could you omit > > it from this document? > > > > -------- > > > > One of the > > reasons is that the protocol handling should have a > minimal impact > > on interior (core) nodes. > > > > Suggest adding that NSIS MAY also have a feature allowing core nodes > > to ignore it (though I hope it will be more elegant than RSVP's as > > document in RFC 3175 :) > > > > -------- > > > > 5.7.5 Hop-by-hop security > > > > Hop-by-Hop security SHOULD be supported. It is a well known and > > proven concept in Quality-of-Service and other signaling > protocols > > that allows intermediate nodes that actively participate in the > > protocol to modify the messages as it is required by processing > > rules. Note that this requirement does not exclude end-to-end or > > network-to-network security of a signaling message. End-to-end > > security between the initiator and the responder may be used to > > provide protection of non-mutable data fields. > Network-to-network > > security refers to the protection of messages over various > > hops but > > not in an end-to-end manner i.e. protected over a > > particular network. > > > > Without minimum mandatory to implement channel security for > > the signaling, > > you can't be sure the other security features will be > > untampered with - > > this needs to be a MUST implement (it's not a MUST use). > > Suggest changing > > the first sentence to "Channel security between signaling entities > > MUST be implemented'? > > > > -------- > > > > > > 5.9.5 SHOULD interwork with seamless handoff protocols > > > > 5.9.6 MAY interwork with non-traditional routing > > > > NSIS assumes L3 routing, but networks, which do non-traditional > > routing, should not break it. > > > > NSIS should not be complex and interworked in ways that make > > it less modular. > > Both of these requirements are complications. The first one, > > because it poses > > a certain environment and particular protocols, would make > > NSIS less modular. > > It is probably improved by changing SHOULD to MAY. The > > second one may sound > > worse than it is - does it mean NATs? Suggest this might > have meant: > > > > 5.9.6. MAY operate in varied routing environments > > > > NSIS assumes L3 routing, but it MAY be designed to operate in > > varied routing environments, such as those with L4 > > switches and NATs. > > > > But if not, do explain... > > -------- > > > > Scenarios - > > > > 's' as an abbreviation is not explained. > > > > -------- > > 10.2 > > > > The 3G Scenario is somewhat too specific to 3GPP and 3GPP2 > > still - IMS is > > mentioned without being expanded or explained. All the terms > > are specific. > > Try to make it a bit more abstract - say it is an All-IP > > multimedia system. > > > > -------- > > This part of the wireless network has different > > characteristics when compared to traditional IP networks: > > > > 1. The network supports a high proportion of real-time > > traffic. The majority of the traffic > transported in the > > wired part of the wireless network is speech, which is > > very sensitive to delays and delay variation (jitter). > > > > Two things about IP networks - they carry whatever they carry, so > > it's not out of tradition to be a voice IP network. > Second, speech in > > Internet phones is quite a lot less sensitive to delays and > > jitter than > > often thought, due to the many good engineering designs in > playout and > > speech cover that are known. So this material places a > > context of more > > difference on the environment than most general transport > experts view > > as necessary, seeing more continuum, while not disagreeing > > that signaling > > and resource reservation are valuable. > > > > So drop sentence 1, but leave the rest alone (I just wanted > > to make my point :) > > > > -------- > > > > > > 10.10 Application request end-to-end QoS path from the network > > > > This is actually the easiest case, nevertheless might be > > most often > > used in terms of number of users. > > > > Few believe that ordinary applications signaling for QoS is > > an easy matter for > > the network - RFCs 2961, 2996 and 3175 are all about > > mitigating the unscalability > > of edge signaling. Probably this would go better if you > > substitute the term > > "conceptually simplest" for "easiest" and note that there are > > these issues with > > scaling. > > > > > > Additionally, we assume no mobility and standard devices. > > > > Note: the end system application and NSIS do not know about the > > distinction between 10.10 and the other scenarios :), unless > > NSIS is not > > a modular Internet protocol. > > > > -------- > > > > QoS for Virtual Private Networks - section needs a number > > > > IP-Sec -> IPSec > > > > The discussion of NSIS in VPNs ignores the whole world of the > > PPVPN WG. > > Cite draft-ietf-ppvpn-framework-08.txt early on in the > > section (it is in the > > RFC-Editor Queue). > > > > > > > > Allison > > > > > > > _______________________________________________ > 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 Jun 10 04:56: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 EAA17690 for ; Tue, 10 Jun 2003 04:56:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5A8tZc31362 for nsis-archive@odin.ietf.org; Tue, 10 Jun 2003 04:55:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A8tSB31355; Tue, 10 Jun 2003 04:55:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A8scB31311 for ; Tue, 10 Jun 2003 04:54:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17682 for ; Tue, 10 Jun 2003 04:54:34 -0400 (EDT) From: maarten.buchli@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Perp-00036E-00 for nsis@ietf.org; Tue, 10 Jun 2003 04:52:33 -0400 Received: from alc245.alcatel.be ([195.207.101.245] helo=relay4.alcatel.be) by ietf-mx with esmtp (Exim 4.12) id 19Pero-000367-00 for nsis@ietf.org; Tue, 10 Jun 2003 04:52:32 -0400 Received: from bemail05.net.alcatel.be (bemail05.net.alcatel.be [138.203.144.16]) by relay4.alcatel.be (8.12.9/8.12.9) with ESMTP id h5A91r1M023566 for ; Tue, 10 Jun 2003 11:01:53 +0200 Subject: Re: [NSIS] framework: proposal on fragmentation To: nsis@ietf.org, Melinda Shore Date: Tue, 10 Jun 2003 10:53:59 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 06/10/2003 10:53:59 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) 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: , During the last meeting it has been decided to use 2205 and 2961 as a starting point for the NTLP work. This allows for raw IP and UDP as transport protocols. However, as you mentioned, about the use of other (connection oriented) transport protocols no decision was taken either way. 2961 adds congestion control and reliable delivery functionality to RSVP. However, the authors have indicated that there is room for improvement. Connection oriented transport protocols can provide the functionality as well. This will allow for reusing existing protocols. Hence, we support to allow for connection oriented transport protocols like TCP. kind regards, Maarten Melinda Shore @ietf.org on 06/06/2003 17:27:13 Sent by: nsis-admin@ietf.org To: "Lars.Westberg" cc: "Geib, Ruediger" , nsis@ietf.org Subject: Re: [NSIS] framework: proposal on fragmentation > I would recommend that we have two modes of operation in mind: > RSVPoverSCTP > RSVPover UDP We reached an agreement at the last meeting, confirmed on the mailing list, that we'd run over a connectionless protocol - that we would gut 2205 and 2961 and use that as the basis for an NTLP. If you go back and look at John's slides from the meeting there was no agreement even to make a connection-oriented protocol available as an option (that is to say, no decision was made either way). One of the things that's killing progress in a number of IETF working groups is the unfortunate tendency to want to go back and revisit and revisit and revisit and revisit decisions that we don't agree with. We need to put a stop to that. That said, I think that we can almost certainly put an NTLP over a connection-oriented protocol, but that we do not want to do this in the baseline. Unless there's new information today that wasn't available in March, however, revisiting the decision that was made then seems like an incredibly bad idea. 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 Jun 10 05:01: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 FAA17804 for ; Tue, 10 Jun 2003 05:01:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5A91A031630 for nsis-archive@odin.ietf.org; Tue, 10 Jun 2003 05:01:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A915B31602; Tue, 10 Jun 2003 05:01:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A90AB31520 for ; Tue, 10 Jun 2003 05:00:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17780 for ; Tue, 10 Jun 2003 05:00:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PexB-00037T-00 for nsis@ietf.org; Tue, 10 Jun 2003 04:58:05 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19PexA-00037Q-00 for nsis@ietf.org; Tue, 10 Jun 2003 04:58:04 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h5A90nbj014280; Tue, 10 Jun 2003 11:00:50 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 10 Jun 2003 11:01:27 +0200 Message-ID: From: "Attila Bader (ETH)" To: "Hancock, Robert" Cc: nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation Date: Tue, 10 Jun 2003 10:59:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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 consider the following: Considering current applications and RFCs 2205 and 2961 as bases, fragmentation is needed for bundling in practice. Since bundling is reasonable to do by NTLP, NTLP should be responsible for fragmentation of bundle messages. If a future NSLP produces large MTUs, it can be defragmented by that NSLP, or by IP. So my proposal for fragmentation is NTLP for Bundle Message NSLP+IP for future NSLP functions Best regards, Attila Bader > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > Hancock, Robert > Sent: Friday, June 06, 2003 5:43 PM > To: 'Lars.Westberg' > Cc: Tom Taylor; Georgios Karagiannis; nsis@ietf.org > Subject: RE: [NSIS] framework: proposal on fragmentation > > > OK - this was option 1 in the original email summary. There seemed to > be some resistance to it from several places and a preference to the > NTLP approach. > > What I can imagine you suggesting is: try to get the NSLP to > create messages > which don't require fragmentation at all (by doing the fragmentation > itself); > in the [hopefully rare] cases where something goes wrong, > rely on the IP > layer to handle it. > > That's an approach - I think it's a much more credible approach than > relying on the NSLP alone, but given the unpleasantness about > doing it > at either IP or NSLP, I still prefer the NTLP option. Anyway, people > need to make the argument about which is better and why: > IP only > NTLP only > NSLP only > IP+NSLP > > The other point is: since we are arguing about the > fragmentation aspect > (rather than the reassembly aspect) .... just how difficult is it to > chop up a message and put a common header on each part? And how much > complexity is > it worth putting in the rest of the network architecture to > save doing it? > > cheers, > > r. > > > -----Original Message----- > > From: Lars.Westberg [mailto:Lars.Westberg@era.ericsson.se] > > Sent: 06 June 2003 16:27 > > To: Hancock, Robert > > Cc: Tom Taylor; Georgios Karagiannis; nsis@ietf.org > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > Use IP-fragmentation > > > > -lasse > > > > "Hancock, Robert" wrote: > > > > > aha! > > > > > > > > > > > No, I trying to explain it: > > > > If you have a network element without knowledge of the NSLP:s > > > > requirment, the > > > > default should be to forward it to the next hop without doing > > > > anything to the > > > > NSLP-messages. > > > > > > *** and what if the message is too big to forward? *** > > > [which is where we started...] > > > > > > > > > > > regards Lasse > > > > > > > > > > r. > > > > > > > > -------------------------------------------------------------- > > ---------- > > > Name: RMRL-Disclaimer.txt > > > RMRL-Disclaimer.txt Type: Plain Text (text/plain) > > > Encoding: 7bit > > > _______________________________________________ > 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 Jun 10 05:01: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 FAA17819 for ; Tue, 10 Jun 2003 05:01:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5A91Br31643 for nsis-archive@odin.ietf.org; Tue, 10 Jun 2003 05:01:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A916B31617; Tue, 10 Jun 2003 05:01:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A90JB31524 for ; Tue, 10 Jun 2003 05:00:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17784 for ; Tue, 10 Jun 2003 05:00:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PexJ-00037Y-00 for nsis@ietf.org; Tue, 10 Jun 2003 04:58:13 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19PexJ-00037J-00 for nsis@ietf.org; Tue, 10 Jun 2003 04:58:13 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jun 2003 09:59:44 +0100 Message-ID: From: "Hancock, Robert" To: "'Georgios Karagiannis'" , "'Lars.Westberg'" Cc: nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation Date: Tue, 10 Jun 2003 09:59:43 +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: , georgios, in your solution, what happens when an NTLP node gets a too-big message with DF set? r. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 10 June 2003 08:50 > To: Hancock, Robert; 'Lars.Westberg' > Cc: nsis@ietf.org > Subject: Re: [NSIS] framework: proposal on fragmentation > > > Hi Robert > > What I actually propose is to enhance the flexibility of > the NTLP protocol by giving the ability to a NSLP to > request or not to request the NTLP fragmentation feature. > A possible method of doing this is as follows: > > First of all the NTLP protocol has to use some information, e.g., a > fragmentation bit, to specify that > fragmentation is allowed or not. > Now, if the sender NSLP (NI) informs its NTLP instance to > switch off the > fragmentation, then this NTLP instance > will switch off the fragmentation bit. In this way all the > intermediate NTLP > nodes will know that fragmentation is > not allowed. > Note that in this case NTLP negotiation is not needed! > > Best regards, > Georgios > > > ----- Original Message ----- > From: "Hancock, Robert" > To: "'Lars.Westberg'" > Cc: "Tom Taylor" ; "Georgios Karagiannis" > ; > Sent: Friday, June 06, 2003 5:42 PM > Subject: RE: [NSIS] framework: proposal on fragmentation > > > > OK - this was option 1 in the original email summary. There > seemed to > > be some resistance to it from several places and a preference to the > > NTLP approach. > > > > What I can imagine you suggesting is: try to get the NSLP to create > messages > > which don't require fragmentation at all (by doing the fragmentation > > itself); > > in the [hopefully rare] cases where something goes wrong, > rely on the IP > > layer to handle it. > > > > That's an approach - I think it's a much more credible approach than > > relying on the NSLP alone, but given the unpleasantness > about doing it > > at either IP or NSLP, I still prefer the NTLP option. Anyway, people > > need to make the argument about which is better and why: > > IP only > > NTLP only > > NSLP only > > IP+NSLP > > > > The other point is: since we are arguing about the > fragmentation aspect > > (rather than the reassembly aspect) .... just how difficult is it to > > chop up a message and put a common header on each part? And how much > > complexity is > > it worth putting in the rest of the network architecture to > save doing it? > > > > cheers, > > > > r. > > > > > -----Original Message----- > > > From: Lars.Westberg [mailto:Lars.Westberg@era.ericsson.se] > > > Sent: 06 June 2003 16:27 > > > To: Hancock, Robert > > > Cc: Tom Taylor; Georgios Karagiannis; nsis@ietf.org > > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > > > > Use IP-fragmentation > > > > > > -lasse > > > > > > "Hancock, Robert" wrote: > > > > > > > aha! > > > > > > > > > > > > > > No, I trying to explain it: > > > > > If you have a network element without knowledge of the NSLP:s > > > > > requirment, the > > > > > default should be to forward it to the next hop without doing > > > > > anything to the > > > > > NSLP-messages. > > > > > > > > *** and what if the message is too big to forward? *** > > > > [which is where we started...] > > > > > > > > > > > > > > regards Lasse > > > > > > > > > > > > > r. > > > > > > > > > > > -------------------------------------------------------------- > > > ---------- > > > > Name: RMRL-Disclaimer.txt > > > > RMRL-Disclaimer.txt Type: Plain Text (text/plain) > > > > Encoding: 7bit > > > > > _______________________________________________ > > 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 Jun 10 05:26: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 FAA18353 for ; Tue, 10 Jun 2003 05:26:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5A9QJ601044 for nsis-archive@odin.ietf.org; Tue, 10 Jun 2003 05:26:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A9QAB01022; Tue, 10 Jun 2003 05:26:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A9Q0B00995 for ; Tue, 10 Jun 2003 05:26:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18322 for ; Tue, 10 Jun 2003 05:25:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PfMA-0003Ei-00 for nsis@ietf.org; Tue, 10 Jun 2003 05:23:54 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19PfM9-0003E5-00 for nsis@ietf.org; Tue, 10 Jun 2003 05:23:54 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jun 2003 10:25:25 +0100 Message-ID: From: "Hancock, Robert" To: "'maarten.buchli@alcatel.be'" , nsis@ietf.org, Melinda Shore Subject: connectionless or connection oriented (RE: [NSIS] framework: prop osal on fragmentation) Date: Tue, 10 Jun 2003 10:25:25 +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 maarten/melinda, i'm only replying to this email to give it a different subject line. the fragmentation support question for the framework is purely about NTLP functionality, that's the question i'm trying to get to an answer on. i think the connectionless/connection-oriented decision - whether or not it has already been made - should be purely invisible outside the NTLP design. (in fact, I think we have already agreed on that, at least.) so it's a different and largely decoupled topic. thanks, robert h. > -----Original Message----- > From: maarten.buchli@alcatel.be [mailto:maarten.buchli@alcatel.be] > Sent: 10 June 2003 09:54 > To: nsis@ietf.org; Melinda Shore > Subject: Re: [NSIS] framework: proposal on fragmentation > > > During the last meeting it has been decided to use 2205 and > 2961 as a starting point for the NTLP work. This allows for > raw IP and UDP as transport protocols. However, as you > mentioned, about the use of other (connection oriented) > transport protocols no decision was taken either way. > > 2961 adds congestion control and reliable delivery functionality > to RSVP. However, the authors have indicated that there > is room for improvement. Connection oriented transport > protocols can provide the functionality as well. This will > allow for reusing existing protocols. > Hence, we support to allow for connection oriented transport > protocols like TCP. > > kind regards, > Maarten > > > > > > Melinda Shore @ietf.org on 06/06/2003 17:27:13 > > Sent by: nsis-admin@ietf.org > > > To: "Lars.Westberg" > cc: "Geib, Ruediger" , nsis@ietf.org > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > I would recommend that we have two modes of operation in mind: > > RSVPoverSCTP > > RSVPover UDP > > We reached an agreement at the last meeting, confirmed on > the mailing list, that we'd run over a connectionless > protocol - that we would gut 2205 and 2961 and use that as > the basis for an NTLP. If you go back and look at John's > slides from the meeting there was no agreement even to make > a connection-oriented protocol available as an option (that > is to say, no decision was made either way). One of the > things that's killing progress in a number of IETF working > groups is the unfortunate tendency to want to go back and > revisit and revisit and revisit and revisit decisions that > we don't agree with. We need to put a stop to that. > > That said, I think that we can almost certainly put an NTLP > over a connection-oriented protocol, but that we do not want > to do this in the baseline. Unless there's new information > today that wasn't available in March, however, revisiting > the decision that was made then seems like an incredibly bad > idea. > > 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 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Jun 10 05:31: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 FAA18475 for ; Tue, 10 Jun 2003 05:31:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5A9VEl01271 for nsis-archive@odin.ietf.org; Tue, 10 Jun 2003 05:31:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A9V3B01256; Tue, 10 Jun 2003 05:31:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A9UGB01197 for ; Tue, 10 Jun 2003 05:30:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18460 for ; Tue, 10 Jun 2003 05:30:11 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PfQI-0003GM-00 for nsis@ietf.org; Tue, 10 Jun 2003 05:28:10 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19PfQH-0003GI-00 for nsis@ietf.org; Tue, 10 Jun 2003 05:28:09 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5A9U9913425 for ; Tue, 10 Jun 2003 12:30:10 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 10 Jun 2003 12:30:09 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 10 Jun 2003 12:30:09 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 10 Jun 2003 12:30:09 +0300 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: connectionless or connection oriented (RE: [NSIS] framework: proposal on fragmentation) Date: Tue, 10 Jun 2003 12:30:08 +0300 Message-ID: Thread-Topic: connectionless or connection oriented (RE: [NSIS] framework: proposal on fragmentation) Thread-Index: AcMvMl0fLW5wXk6iTzCDcVM8isPcegAAFEcQ To: , , , X-OriginalArrivalTime: 10 Jun 2003 09:30:09.0406 (UTC) FILETIME=[E2A859E0:01C32F32] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5A9UGB01198 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, > i think the connectionless/connection-oriented decision - whether or > not it has already been made - should be purely invisible outside the > NTLP design. (in fact, I think we have already agreed on > that, at least.) so it's a different and largely decoupled topic. Yes, we have agreed on it already. NSIS cannot depend upon a transport layer connection to indicate anything about the livelness of a session. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Jun 10 06:45: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 GAA19727 for ; Tue, 10 Jun 2003 06:45:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AAiar07889 for nsis-archive@odin.ietf.org; Tue, 10 Jun 2003 06:44:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AAiLB07874; Tue, 10 Jun 2003 06:44:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AAgAB07786 for ; Tue, 10 Jun 2003 06:42:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19692 for ; Tue, 10 Jun 2003 06:42:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PgXr-0003Zi-00 for nsis@ietf.org; Tue, 10 Jun 2003 06:40:03 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19PgXq-0003ZY-00 for nsis@ietf.org; Tue, 10 Jun 2003 06:40:02 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h5AAfr5s014813; Tue, 10 Jun 2003 12:42:02 +0200 (MET DST) Message-ID: <00b501c32f3c$ee05b300$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" Cc: References: Subject: Re: [NSIS] framework: proposal on fragmentation Date: Tue, 10 Jun 2003 12:41:14 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Robert The NTLP should be able to transport a message with a minimum MTU without fragmenting it. Best Regards, Georgios ----- Original Message ----- From: "Hancock, Robert" To: "'Georgios Karagiannis'" ; "'Lars.Westberg'" Cc: Sent: Tuesday, June 10, 2003 10:59 AM Subject: RE: [NSIS] framework: proposal on fragmentation > georgios, > > in your solution, what happens when an NTLP node gets a too-big message > with DF set? > > r. > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 10 June 2003 08:50 > > To: Hancock, Robert; 'Lars.Westberg' > > Cc: nsis@ietf.org > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > Hi Robert > > > > What I actually propose is to enhance the flexibility of > > the NTLP protocol by giving the ability to a NSLP to > > request or not to request the NTLP fragmentation feature. > > A possible method of doing this is as follows: > > > > First of all the NTLP protocol has to use some information, e.g., a > > fragmentation bit, to specify that > > fragmentation is allowed or not. > > Now, if the sender NSLP (NI) informs its NTLP instance to > > switch off the > > fragmentation, then this NTLP instance > > will switch off the fragmentation bit. In this way all the > > intermediate NTLP > > nodes will know that fragmentation is > > not allowed. > > Note that in this case NTLP negotiation is not needed! > > > > Best regards, > > Georgios > > > > > > ----- Original Message ----- > > From: "Hancock, Robert" > > To: "'Lars.Westberg'" > > Cc: "Tom Taylor" ; "Georgios Karagiannis" > > ; > > Sent: Friday, June 06, 2003 5:42 PM > > Subject: RE: [NSIS] framework: proposal on fragmentation > > > > > > > OK - this was option 1 in the original email summary. There > > seemed to > > > be some resistance to it from several places and a preference to the > > > NTLP approach. > > > > > > What I can imagine you suggesting is: try to get the NSLP to create > > messages > > > which don't require fragmentation at all (by doing the fragmentation > > > itself); > > > in the [hopefully rare] cases where something goes wrong, > > rely on the IP > > > layer to handle it. > > > > > > That's an approach - I think it's a much more credible approach than > > > relying on the NSLP alone, but given the unpleasantness > > about doing it > > > at either IP or NSLP, I still prefer the NTLP option. Anyway, people > > > need to make the argument about which is better and why: > > > IP only > > > NTLP only > > > NSLP only > > > IP+NSLP > > > > > > The other point is: since we are arguing about the > > fragmentation aspect > > > (rather than the reassembly aspect) .... just how difficult is it to > > > chop up a message and put a common header on each part? And how much > > > complexity is > > > it worth putting in the rest of the network architecture to > > save doing it? > > > > > > cheers, > > > > > > r. > > > > > > > -----Original Message----- > > > > From: Lars.Westberg [mailto:Lars.Westberg@era.ericsson.se] > > > > Sent: 06 June 2003 16:27 > > > > To: Hancock, Robert > > > > Cc: Tom Taylor; Georgios Karagiannis; nsis@ietf.org > > > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > > > > > > > Use IP-fragmentation > > > > > > > > -lasse > > > > > > > > "Hancock, Robert" wrote: > > > > > > > > > aha! > > > > > > > > > > > > > > > > > No, I trying to explain it: > > > > > > If you have a network element without knowledge of the NSLP:s > > > > > > requirment, the > > > > > > default should be to forward it to the next hop without doing > > > > > > anything to the > > > > > > NSLP-messages. > > > > > > > > > > *** and what if the message is too big to forward? *** > > > > > [which is where we started...] > > > > > > > > > > > > > > > > > regards Lasse > > > > > > > > > > > > > > > > r. > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > ---------- > > > > > Name: RMRL-Disclaimer.txt > > > > > RMRL-Disclaimer.txt Type: Plain Text (text/plain) > > > > > Encoding: 7bit > > > > > > > _______________________________________________ > > > 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 Jun 10 06:47: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 GAA19761 for ; Tue, 10 Jun 2003 06:47:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AAlFc08023 for nsis-archive@odin.ietf.org; Tue, 10 Jun 2003 06:47:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AAl3B08011; Tue, 10 Jun 2003 06:47:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AAkTB07970 for ; Tue, 10 Jun 2003 06:46:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19748 for ; Tue, 10 Jun 2003 06:46:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pgc1-0003an-00 for nsis@ietf.org; Tue, 10 Jun 2003 06:44:21 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19Pgc1-0003ak-00 for nsis@ietf.org; Tue, 10 Jun 2003 06:44:21 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jun 2003 11:46:21 +0100 Message-ID: From: "Hancock, Robert" To: "'Georgios Karagiannis'" Cc: nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation Date: Tue, 10 Jun 2003 11:46: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: , georgios, ok, so [i think] you propose that there should be an minimum size NSLP message that all NTLP instances should be able to transmit (presumably, regardless of IP version or whatever encapsulation the NTLP itself adds, to avoid the need to discover things dynamically). anything bigger, the NSLP itself must fragment before providing it to the NTLP. would you like to make a suggestion for how big that number should be? r. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 10 June 2003 11:41 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: [NSIS] framework: proposal on fragmentation > > > Hi Robert > > The NTLP should be able to transport a message with a > minimum MTU without fragmenting it. > > Best Regards, > Georgios > > > > > > ----- Original Message ----- > From: "Hancock, Robert" > To: "'Georgios Karagiannis'" ; > "'Lars.Westberg'" > > Cc: > Sent: Tuesday, June 10, 2003 10:59 AM > Subject: RE: [NSIS] framework: proposal on fragmentation > > > > georgios, > > > > in your solution, what happens when an NTLP node gets a > too-big message > > with DF set? > > > > r. > > > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: 10 June 2003 08:50 > > > To: Hancock, Robert; 'Lars.Westberg' > > > Cc: nsis@ietf.org > > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > > > > Hi Robert > > > > > > What I actually propose is to enhance the flexibility of > > > the NTLP protocol by giving the ability to a NSLP to > > > request or not to request the NTLP fragmentation feature. > > > A possible method of doing this is as follows: > > > > > > First of all the NTLP protocol has to use some > information, e.g., a > > > fragmentation bit, to specify that > > > fragmentation is allowed or not. > > > Now, if the sender NSLP (NI) informs its NTLP instance to > > > switch off the > > > fragmentation, then this NTLP instance > > > will switch off the fragmentation bit. In this way all the > > > intermediate NTLP > > > nodes will know that fragmentation is > > > not allowed. > > > Note that in this case NTLP negotiation is not needed! > > > > > > Best regards, > > > Georgios > > > > > > > > > ----- Original Message ----- > > > From: "Hancock, Robert" > > > To: "'Lars.Westberg'" > > > Cc: "Tom Taylor" ; "Georgios > Karagiannis" > > > ; > > > Sent: Friday, June 06, 2003 5:42 PM > > > Subject: RE: [NSIS] framework: proposal on fragmentation > > > > > > > > > > OK - this was option 1 in the original email summary. There > > > seemed to > > > > be some resistance to it from several places and a > preference to the > > > > NTLP approach. > > > > > > > > What I can imagine you suggesting is: try to get the > NSLP to create > > > messages > > > > which don't require fragmentation at all (by doing the > fragmentation > > > > itself); > > > > in the [hopefully rare] cases where something goes wrong, > > > rely on the IP > > > > layer to handle it. > > > > > > > > That's an approach - I think it's a much more credible > approach than > > > > relying on the NSLP alone, but given the unpleasantness > > > about doing it > > > > at either IP or NSLP, I still prefer the NTLP option. > Anyway, people > > > > need to make the argument about which is better and why: > > > > IP only > > > > NTLP only > > > > NSLP only > > > > IP+NSLP > > > > > > > > The other point is: since we are arguing about the > > > fragmentation aspect > > > > (rather than the reassembly aspect) .... just how > difficult is it to > > > > chop up a message and put a common header on each part? > And how much > > > > complexity is > > > > it worth putting in the rest of the network architecture to > > > save doing it? > > > > > > > > cheers, > > > > > > > > r. > > > > > > > > > -----Original Message----- > > > > > From: Lars.Westberg [mailto:Lars.Westberg@era.ericsson.se] > > > > > Sent: 06 June 2003 16:27 > > > > > To: Hancock, Robert > > > > > Cc: Tom Taylor; Georgios Karagiannis; nsis@ietf.org > > > > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > > > > > > > > > > Use IP-fragmentation > > > > > > > > > > -lasse > > > > > > > > > > "Hancock, Robert" wrote: > > > > > > > > > > > aha! > > > > > > > > > > > > > > > > > > > > No, I trying to explain it: > > > > > > > If you have a network element without knowledge > of the NSLP:s > > > > > > > requirment, the > > > > > > > default should be to forward it to the next hop > without doing > > > > > > > anything to the > > > > > > > NSLP-messages. > > > > > > > > > > > > *** and what if the message is too big to forward? *** > > > > > > [which is where we started...] > > > > > > > > > > > > > > > > > > > > regards Lasse > > > > > > > > > > > > > > > > > > > r. > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------- > > > > > > Name: RMRL-Disclaimer.txt > > > > > > RMRL-Disclaimer.txt Type: Plain Text (text/plain) > > > > > > Encoding: 7bit > > > > > > > > > _______________________________________________ > > > > 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 Jun 10 08:30: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 IAA24055 for ; Tue, 10 Jun 2003 08:30:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5ACUQ216085 for nsis-archive@odin.ietf.org; Tue, 10 Jun 2003 08:30:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ACTYB15966; Tue, 10 Jun 2003 08:29:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ACQmB15830 for ; Tue, 10 Jun 2003 08:26:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23649 for ; Tue, 10 Jun 2003 08:26:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PiB9-0004TB-00 for nsis@ietf.org; Tue, 10 Jun 2003 08:24:43 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19PiB7-0004T4-00 for nsis@ietf.org; Tue, 10 Jun 2003 08:24:41 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h5ACPL5s019424; Tue, 10 Jun 2003 14:25:21 +0200 (MET DST) Message-ID: <00e501c32f4b$5d042030$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" Cc: References: Subject: Re: [NSIS] framework: proposal on fragmentation Date: Tue, 10 Jun 2003 14:25:22 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Robert > ok, so [i think] you propose that there should be an minimum size NSLP > message that all NTLP instances should be able to transmit (presumably, > regardless of IP version or whatever encapsulation the NTLP itself adds, to > avoid the need to discover things dynamically). anything bigger, the NSLP > itself must fragment before providing it to the NTLP. > would you like to make a suggestion for how big that number should be? > For example, look into Section 4.2.2.7 of RFC 1812: " A common trick used by some implementations of TCP/IP is to fragment an IP datagram into IP fragments that are no larger than 576 bytes when the IP datagram is to travel through a router. This is intended to allow the resulting IP fragments to pass the rest of the path without further fragmentation. " , from RFC1812. Best regards, Georgios > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 10 June 2003 11:41 > > To: Hancock, Robert > > Cc: nsis@ietf.org > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > Hi Robert > > > > The NTLP should be able to transport a message with a > > minimum MTU without fragmenting it. > > > > Best Regards, > > Georgios > > > > > > > > > > > > ----- Original Message ----- > > From: "Hancock, Robert" > > To: "'Georgios Karagiannis'" ; > > "'Lars.Westberg'" > > > > Cc: > > Sent: Tuesday, June 10, 2003 10:59 AM > > Subject: RE: [NSIS] framework: proposal on fragmentation > > > > > > > georgios, > > > > > > in your solution, what happens when an NTLP node gets a > > too-big message > > > with DF set? > > > > > > r. > > > > > > > -----Original Message----- > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > Sent: 10 June 2003 08:50 > > > > To: Hancock, Robert; 'Lars.Westberg' > > > > Cc: nsis@ietf.org > > > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > > > > > > > Hi Robert > > > > > > > > What I actually propose is to enhance the flexibility of > > > > the NTLP protocol by giving the ability to a NSLP to > > > > request or not to request the NTLP fragmentation feature. > > > > A possible method of doing this is as follows: > > > > > > > > First of all the NTLP protocol has to use some > > information, e.g., a > > > > fragmentation bit, to specify that > > > > fragmentation is allowed or not. > > > > Now, if the sender NSLP (NI) informs its NTLP instance to > > > > switch off the > > > > fragmentation, then this NTLP instance > > > > will switch off the fragmentation bit. In this way all the > > > > intermediate NTLP > > > > nodes will know that fragmentation is > > > > not allowed. > > > > Note that in this case NTLP negotiation is not needed! > > > > > > > > Best regards, > > > > Georgios > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Hancock, Robert" > > > > To: "'Lars.Westberg'" > > > > Cc: "Tom Taylor" ; "Georgios > > Karagiannis" > > > > ; > > > > Sent: Friday, June 06, 2003 5:42 PM > > > > Subject: RE: [NSIS] framework: proposal on fragmentation > > > > > > > > > > > > > OK - this was option 1 in the original email summary. There > > > > seemed to > > > > > be some resistance to it from several places and a > > preference to the > > > > > NTLP approach. > > > > > > > > > > What I can imagine you suggesting is: try to get the > > NSLP to create > > > > messages > > > > > which don't require fragmentation at all (by doing the > > fragmentation > > > > > itself); > > > > > in the [hopefully rare] cases where something goes wrong, > > > > rely on the IP > > > > > layer to handle it. > > > > > > > > > > That's an approach - I think it's a much more credible > > approach than > > > > > relying on the NSLP alone, but given the unpleasantness > > > > about doing it > > > > > at either IP or NSLP, I still prefer the NTLP option. > > Anyway, people > > > > > need to make the argument about which is better and why: > > > > > IP only > > > > > NTLP only > > > > > NSLP only > > > > > IP+NSLP > > > > > > > > > > The other point is: since we are arguing about the > > > > fragmentation aspect > > > > > (rather than the reassembly aspect) .... just how > > difficult is it to > > > > > chop up a message and put a common header on each part? > > And how much > > > > > complexity is > > > > > it worth putting in the rest of the network architecture to > > > > save doing it? > > > > > > > > > > cheers, > > > > > > > > > > r. > > > > > > > > > > > -----Original Message----- > > > > > > From: Lars.Westberg [mailto:Lars.Westberg@era.ericsson.se] > > > > > > Sent: 06 June 2003 16:27 > > > > > > To: Hancock, Robert > > > > > > Cc: Tom Taylor; Georgios Karagiannis; nsis@ietf.org > > > > > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > > > > > > > > > > > > > Use IP-fragmentation > > > > > > > > > > > > -lasse > > > > > > > > > > > > "Hancock, Robert" wrote: > > > > > > > > > > > > > aha! > > > > > > > > > > > > > > > > > > > > > > > No, I trying to explain it: > > > > > > > > If you have a network element without knowledge > > of the NSLP:s > > > > > > > > requirment, the > > > > > > > > default should be to forward it to the next hop > > without doing > > > > > > > > anything to the > > > > > > > > NSLP-messages. > > > > > > > > > > > > > > *** and what if the message is too big to forward? *** > > > > > > > [which is where we started...] > > > > > > > > > > > > > > > > > > > > > > > regards Lasse > > > > > > > > > > > > > > > > > > > > > > r. > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > ---------- > > > > > > > Name: RMRL-Disclaimer.txt > > > > > > > RMRL-Disclaimer.txt Type: Plain Text (text/plain) > > > > > > > Encoding: 7bit > > > > > > > > > > > _______________________________________________ > > > > > 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 Jun 10 09:10: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 JAA27571 for ; Tue, 10 Jun 2003 09:10:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AD9cV20157 for nsis-archive@odin.ietf.org; Tue, 10 Jun 2003 09:09:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AD9HB20103; Tue, 10 Jun 2003 09:09:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AD6bB19114 for ; Tue, 10 Jun 2003 09:06:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27263 for ; Tue, 10 Jun 2003 09:06:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pinf-0005Z6-00 for nsis@ietf.org; Tue, 10 Jun 2003 09:04:31 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx with esmtp (Exim 4.12) id 19Pinf-0005Z3-00 for nsis@ietf.org; Tue, 10 Jun 2003 09:04:31 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx1.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 19Pipc-0002Jh-00 for ; Tue, 10 Jun 2003 15:06:32 +0200 Received: from i72ms0.tm.uni-karlsruhe.de ([141.3.71.10] helo=smtp.ipv6.tm.uni-karlsruhe.de ident=8) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 19Pipc-0005qP-00 for ; Tue, 10 Jun 2003 15:06:32 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de ([3ffe:400:20:1:2e0:29ff:fe3e:c87] ident=mail) by smtp.ipv6.tm.uni-karlsruhe.de with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.12) id 19Pipb-0007Pi-00 for nsis@ietf.org; Tue, 10 Jun 2003 15:06:31 +0200 Received: from localhost ([::1] helo=vorta.ipv6.tm.uni-karlsruhe.de ident=bless) by vorta.ipv6.tm.uni-karlsruhe.de with smtp (Exim 4.05) id 19Pipa-0005Wo-00 for nsis@ietf.org; Tue, 10 Jun 2003 15:06:30 +0200 Date: Tue, 10 Jun 2003 15:06:30 +0200 From: Roland Bless To: nsis@ietf.org Subject: Re: [NSIS] framework: proposal on fragmentation Message-Id: <20030610150630.34175265.bless@tm.uka.de> In-Reply-To: <3EE0AED7.CE399E81@era.ericsson.se> References: <3EE0AED7.CE399E81@era.ericsson.se> Organization: Institute of Telematics, University of Karlsruhe X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) 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 Lasse, I don't think you can rely on IP fragmentation features in this case, as John already mentioned earlier: IPv6 will only fragment/reassemble packets in an end-to-end fashion. In this case reassembly/fragmentation will only work if an NTLP node is the destination/source of the IP packet conveying the signaling message, which is not always true for path-coupled signaling messages. > If we have an IP-network, the IP-layer may fragment/reassembly the > packets. For me, it does not mean that the NTLP must perform > fragmentation. > > If we have an NSLP that want to have an certain transport service from > the NTLP. Can't that choose a proper level of operation by the API ? > > If the knowledge of a NSLP-instance does not exist in the router, the > router could probably forward the packet in the same way it has rececied > them without performing bundeling, fragmentation..... _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Jun 10 09:53: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 JAA00202 for ; Tue, 10 Jun 2003 09:53:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5ADrVq23591 for nsis-archive@odin.ietf.org; Tue, 10 Jun 2003 09:53:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ADrIB23532; Tue, 10 Jun 2003 09:53:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5ADqBB23443 for ; Tue, 10 Jun 2003 09:52:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00073 for ; Tue, 10 Jun 2003 09:52:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PjVl-0006Qp-00 for nsis@ietf.org; Tue, 10 Jun 2003 09:50:05 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19PjVj-0006QY-00 for nsis@ietf.org; Tue, 10 Jun 2003 09:50:04 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jun 2003 14:51:33 +0100 Message-ID: From: "Hancock, Robert" To: "'Georgios Karagiannis'" Cc: nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation Date: Tue, 10 Jun 2003 14:51:33 +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: , indeed. however, even 576 doesn't guarantee that fragmentation won't be needed (for IPv4 the MTU could be as low as 68), and in any case, you also have to take out the NTLP encapsulation overhead. doing unnecessary fragmentation as the NSLP will increase network load, because you have more more messages. i suppose you could allow the NTLP to bundle the fragments back together [i did originally consider this option but discarded it as just too ugly to propose] but the result would still be bigger than the original could have been, especially if the per-fragment overhead is large. i still don't see this as preferable to having the NTLP able to chop up messages. why is that so hard???? cheers, r. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 10 June 2003 13:25 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: [NSIS] framework: proposal on fragmentation > > > Hi Robert > > > > > ok, so [i think] you propose that there should be an > minimum size NSLP > > message that all NTLP instances should be able to transmit > (presumably, > > regardless of IP version or whatever encapsulation the NTLP > itself adds, > to > > avoid the need to discover things dynamically). anything > bigger, the NSLP > > itself must fragment before providing it to the NTLP. > > would you like to make a suggestion for how big that number > should be? > > > > For example, look into Section 4.2.2.7 of RFC 1812: > " A common trick used by some implementations of TCP/IP is to > fragment an IP datagram into IP fragments that are no > larger than > 576 bytes when the IP datagram is to travel through a router. > This is intended to allow the resulting IP fragments to pass the > rest of the path without further fragmentation. " , > from RFC1812. > > Best regards, > Georgios > > > > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: 10 June 2003 11:41 > > > To: Hancock, Robert > > > Cc: nsis@ietf.org > > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > > > > Hi Robert > > > > > > The NTLP should be able to transport a message with a > > > minimum MTU without fragmenting it. > > > > > > Best Regards, > > > Georgios > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > From: "Hancock, Robert" > > > To: "'Georgios Karagiannis'" ; > > > "'Lars.Westberg'" > > > > > > Cc: > > > Sent: Tuesday, June 10, 2003 10:59 AM > > > Subject: RE: [NSIS] framework: proposal on fragmentation > > > > > > > > > > georgios, > > > > > > > > in your solution, what happens when an NTLP node gets a > > > too-big message > > > > with DF set? > > > > > > > > r. > > > > > > > > > -----Original Message----- > > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > > Sent: 10 June 2003 08:50 > > > > > To: Hancock, Robert; 'Lars.Westberg' > > > > > Cc: nsis@ietf.org > > > > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > > > > > > > > > > Hi Robert > > > > > > > > > > What I actually propose is to enhance the flexibility of > > > > > the NTLP protocol by giving the ability to a NSLP to > > > > > request or not to request the NTLP fragmentation feature. > > > > > A possible method of doing this is as follows: > > > > > > > > > > First of all the NTLP protocol has to use some > > > information, e.g., a > > > > > fragmentation bit, to specify that > > > > > fragmentation is allowed or not. > > > > > Now, if the sender NSLP (NI) informs its NTLP instance to > > > > > switch off the > > > > > fragmentation, then this NTLP instance > > > > > will switch off the fragmentation bit. In this way all the > > > > > intermediate NTLP > > > > > nodes will know that fragmentation is > > > > > not allowed. > > > > > Note that in this case NTLP negotiation is not needed! > > > > > > > > > > Best regards, > > > > > Georgios > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Hancock, Robert" > > > > > To: "'Lars.Westberg'" > > > > > Cc: "Tom Taylor" ; "Georgios > > > Karagiannis" > > > > > ; > > > > > Sent: Friday, June 06, 2003 5:42 PM > > > > > Subject: RE: [NSIS] framework: proposal on fragmentation > > > > > > > > > > > > > > > > OK - this was option 1 in the original email summary. There > > > > > seemed to > > > > > > be some resistance to it from several places and a > > > preference to the > > > > > > NTLP approach. > > > > > > > > > > > > What I can imagine you suggesting is: try to get the > > > NSLP to create > > > > > messages > > > > > > which don't require fragmentation at all (by doing the > > > fragmentation > > > > > > itself); > > > > > > in the [hopefully rare] cases where something goes wrong, > > > > > rely on the IP > > > > > > layer to handle it. > > > > > > > > > > > > That's an approach - I think it's a much more credible > > > approach than > > > > > > relying on the NSLP alone, but given the unpleasantness > > > > > about doing it > > > > > > at either IP or NSLP, I still prefer the NTLP option. > > > Anyway, people > > > > > > need to make the argument about which is better and why: > > > > > > IP only > > > > > > NTLP only > > > > > > NSLP only > > > > > > IP+NSLP > > > > > > > > > > > > The other point is: since we are arguing about the > > > > > fragmentation aspect > > > > > > (rather than the reassembly aspect) .... just how > > > difficult is it to > > > > > > chop up a message and put a common header on each part? > > > And how much > > > > > > complexity is > > > > > > it worth putting in the rest of the network architecture to > > > > > save doing it? > > > > > > > > > > > > cheers, > > > > > > > > > > > > r. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Lars.Westberg [mailto:Lars.Westberg@era.ericsson.se] > > > > > > > Sent: 06 June 2003 16:27 > > > > > > > To: Hancock, Robert > > > > > > > Cc: Tom Taylor; Georgios Karagiannis; nsis@ietf.org > > > > > > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > > > > > > > > > > > > > > > > Use IP-fragmentation > > > > > > > > > > > > > > -lasse > > > > > > > > > > > > > > "Hancock, Robert" wrote: > > > > > > > > > > > > > > > aha! > > > > > > > > > > > > > > > > > > > > > > > > > > No, I trying to explain it: > > > > > > > > > If you have a network element without knowledge > > > of the NSLP:s > > > > > > > > > requirment, the > > > > > > > > > default should be to forward it to the next hop > > > without doing > > > > > > > > > anything to the > > > > > > > > > NSLP-messages. > > > > > > > > > > > > > > > > *** and what if the message is too big to forward? *** > > > > > > > > [which is where we started...] > > > > > > > > > > > > > > > > > > > > > > > > > > regards Lasse > > > > > > > > > > > > > > > > > > > > > > > > > r. > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > > ---------- > > > > > > > > Name: RMRL-Disclaimer.txt > > > > > > > > RMRL-Disclaimer.txt Type: Plain Text (text/plain) > > > > > > > > Encoding: 7bit > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 Jun 10 10:37: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 KAA03360 for ; Tue, 10 Jun 2003 10:37:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AEaj527077 for nsis-archive@odin.ietf.org; Tue, 10 Jun 2003 10:36:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AEaYB27050; Tue, 10 Jun 2003 10:36:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AEYxB26853 for ; Tue, 10 Jun 2003 10:34:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03239 for ; Tue, 10 Jun 2003 10:34:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PkB9-0006vw-00 for nsis@ietf.org; Tue, 10 Jun 2003 10:32:51 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19PkB8-0006vt-00 for nsis@ietf.org; Tue, 10 Jun 2003 10:32:51 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h5AEYo5s024867; Tue, 10 Jun 2003 16:34:50 +0200 (MET DST) Message-ID: <011201c32f5d$74022ef0$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" Cc: References: Subject: Re: [NSIS] framework: proposal on fragmentation Date: Tue, 10 Jun 2003 16:34:51 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Robert What I actually propose is that when the NSLP is not in favour of NTLP fragmentation, then the NTLP should not do fragmentation. If the NSLP activates the "Do Fragmentation" bit then the NTLP is allowed to do fragmentation. Otherwise if the NSLP switches off the "Do Fragmentation" bit then the NTLP will not do fragmentation. Please note that in this situation the NSLP is aware of the fragmentation issues and it will either rely on the IP fragmentation or try to solve the fragmentation issues by its own. Best Regards, Georgios ----- Original Message ----- From: "Hancock, Robert" To: "'Georgios Karagiannis'" Cc: Sent: Tuesday, June 10, 2003 3:51 PM Subject: RE: [NSIS] framework: proposal on fragmentation > indeed. > > however, even 576 doesn't guarantee that fragmentation won't be needed > (for IPv4 the MTU could be as low as 68), and in any case, you also have to > take out the NTLP encapsulation overhead. > > doing unnecessary fragmentation as the NSLP will increase network load, > because you have more more messages. i suppose you could allow the NTLP to bundle > the fragments back together [i did originally consider this option but > discarded it as just too ugly to propose] but the result would still be > bigger than the original could have been, especially if the per-fragment overhead > is large. > > i still don't see this as preferable to having the NTLP able to chop up messages. > why is that so hard???? > > cheers, > > r. > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 10 June 2003 13:25 > > To: Hancock, Robert > > Cc: nsis@ietf.org > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > Hi Robert > > > > > > > > > ok, so [i think] you propose that there should be an > > minimum size NSLP > > > message that all NTLP instances should be able to transmit > > (presumably, > > > regardless of IP version or whatever encapsulation the NTLP > > itself adds, > > to > > > avoid the need to discover things dynamically). anything > > bigger, the NSLP > > > itself must fragment before providing it to the NTLP. > > > would you like to make a suggestion for how big that number > > should be? > > > > > > > For example, look into Section 4.2.2.7 of RFC 1812: > > " A common trick used by some implementations of TCP/IP is to > > fragment an IP datagram into IP fragments that are no > > larger than > > 576 bytes when the IP datagram is to travel through a router. > > This is intended to allow the resulting IP fragments to pass the > > rest of the path without further fragmentation. " , > > from RFC1812. > > > > Best regards, > > Georgios > > > > > > > > > -----Original Message----- > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > Sent: 10 June 2003 11:41 > > > > To: Hancock, Robert > > > > Cc: nsis@ietf.org > > > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > > > > > > > Hi Robert > > > > > > > > The NTLP should be able to transport a message with a > > > > minimum MTU without fragmenting it. > > > > > > > > Best Regards, > > > > Georgios > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Hancock, Robert" > > > > To: "'Georgios Karagiannis'" ; > > > > "'Lars.Westberg'" > > > > > > > > Cc: > > > > Sent: Tuesday, June 10, 2003 10:59 AM > > > > Subject: RE: [NSIS] framework: proposal on fragmentation > > > > > > > > > > > > > georgios, > > > > > > > > > > in your solution, what happens when an NTLP node gets a > > > > too-big message > > > > > with DF set? > > > > > > > > > > r. > > > > > > > > > > > -----Original Message----- > > > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > > > Sent: 10 June 2003 08:50 > > > > > > To: Hancock, Robert; 'Lars.Westberg' > > > > > > Cc: nsis@ietf.org > > > > > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > > > > > > > > > > > > > Hi Robert > > > > > > > > > > > > What I actually propose is to enhance the flexibility of > > > > > > the NTLP protocol by giving the ability to a NSLP to > > > > > > request or not to request the NTLP fragmentation feature. > > > > > > A possible method of doing this is as follows: > > > > > > > > > > > > First of all the NTLP protocol has to use some > > > > information, e.g., a > > > > > > fragmentation bit, to specify that > > > > > > fragmentation is allowed or not. > > > > > > Now, if the sender NSLP (NI) informs its NTLP instance to > > > > > > switch off the > > > > > > fragmentation, then this NTLP instance > > > > > > will switch off the fragmentation bit. In this way all the > > > > > > intermediate NTLP > > > > > > nodes will know that fragmentation is > > > > > > not allowed. > > > > > > Note that in this case NTLP negotiation is not needed! > > > > > > > > > > > > Best regards, > > > > > > Georgios > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Hancock, Robert" > > > > > > To: "'Lars.Westberg'" > > > > > > Cc: "Tom Taylor" ; "Georgios > > > > Karagiannis" > > > > > > ; > > > > > > Sent: Friday, June 06, 2003 5:42 PM > > > > > > Subject: RE: [NSIS] framework: proposal on fragmentation > > > > > > > > > > > > > > > > > > > OK - this was option 1 in the original email summary. There > > > > > > seemed to > > > > > > > be some resistance to it from several places and a > > > > preference to the > > > > > > > NTLP approach. > > > > > > > > > > > > > > What I can imagine you suggesting is: try to get the > > > > NSLP to create > > > > > > messages > > > > > > > which don't require fragmentation at all (by doing the > > > > fragmentation > > > > > > > itself); > > > > > > > in the [hopefully rare] cases where something goes wrong, > > > > > > rely on the IP > > > > > > > layer to handle it. > > > > > > > > > > > > > > That's an approach - I think it's a much more credible > > > > approach than > > > > > > > relying on the NSLP alone, but given the unpleasantness > > > > > > about doing it > > > > > > > at either IP or NSLP, I still prefer the NTLP option. > > > > Anyway, people > > > > > > > need to make the argument about which is better and why: > > > > > > > IP only > > > > > > > NTLP only > > > > > > > NSLP only > > > > > > > IP+NSLP > > > > > > > > > > > > > > The other point is: since we are arguing about the > > > > > > fragmentation aspect > > > > > > > (rather than the reassembly aspect) .... just how > > > > difficult is it to > > > > > > > chop up a message and put a common header on each part? > > > > And how much > > > > > > > complexity is > > > > > > > it worth putting in the rest of the network architecture to > > > > > > save doing it? > > > > > > > > > > > > > > cheers, > > > > > > > > > > > > > > r. > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Lars.Westberg [mailto:Lars.Westberg@era.ericsson.se] > > > > > > > > Sent: 06 June 2003 16:27 > > > > > > > > To: Hancock, Robert > > > > > > > > Cc: Tom Taylor; Georgios Karagiannis; nsis@ietf.org > > > > > > > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > > > > > > > > > > > > > > > > > > > Use IP-fragmentation > > > > > > > > > > > > > > > > -lasse > > > > > > > > > > > > > > > > "Hancock, Robert" wrote: > > > > > > > > > > > > > > > > > aha! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > No, I trying to explain it: > > > > > > > > > > If you have a network element without knowledge > > > > of the NSLP:s > > > > > > > > > > requirment, the > > > > > > > > > > default should be to forward it to the next hop > > > > without doing > > > > > > > > > > anything to the > > > > > > > > > > NSLP-messages. > > > > > > > > > > > > > > > > > > *** and what if the message is too big to forward? *** > > > > > > > > > [which is where we started...] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > regards Lasse > > > > > > > > > > > > > > > > > > > > > > > > > > > > r. > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > > > ---------- > > > > > > > > > Name: RMRL-Disclaimer.txt > > > > > > > > > RMRL-Disclaimer.txt Type: Plain Text (text/plain) > > > > > > > > > Encoding: 7bit > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 Jun 10 11:21: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 LAA05199 for ; Tue, 10 Jun 2003 11:21:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AFLKj31121 for nsis-archive@odin.ietf.org; Tue, 10 Jun 2003 11:21:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFL1B31097; Tue, 10 Jun 2003 11:21:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFHMB30910 for ; Tue, 10 Jun 2003 11:17:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05073 for ; Tue, 10 Jun 2003 11:17:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PkqE-0007KO-00 for nsis@ietf.org; Tue, 10 Jun 2003 11:15:18 -0400 Received: from [63.127.199.195] (helo=arb-exchange1.cetaceannetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19PkqD-0007KL-00 for nsis@ietf.org; Tue, 10 Jun 2003 11:15:17 -0400 Received: by mail.cetaceannetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jun 2003 11:18:32 -0400 Message-ID: <6D8664171C38D511B5AD0002B325CE66015722E3@mail.cetaceannetworks.com> From: "Freytsis, Ilya" To: "'Georgios Karagiannis'" , "Hancock, Robert" Cc: nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation Date: Tue, 10 Jun 2003 11:18:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="Windows-1251" 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, I think it is a very reasonable proposal. It means that every NTLP implementation must support fragmentation in the following manner: optional to fragment those messages that do have "Do Fragmentation" flag set but mandatory to re-assembled already fragmented messages. Regards, Ilya -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] Sent: Tuesday, June 10, 2003 10:35 AM To: Hancock, Robert Cc: nsis@ietf.org Subject: Re: [NSIS] framework: proposal on fragmentation Hi Robert What I actually propose is that when the NSLP is not in favour of NTLP fragmentation, then the NTLP should not do fragmentation. If the NSLP activates the "Do Fragmentation" bit then the NTLP is allowed to do fragmentation. Otherwise if the NSLP switches off the "Do Fragmentation" bit then the NTLP will not do fragmentation. Please note that in this situation the NSLP is aware of the fragmentation issues and it will either rely on the IP fragmentation or try to solve the fragmentation issues by its own. Best Regards, Georgios ----- Original Message ----- From: "Hancock, Robert" To: "'Georgios Karagiannis'" Cc: Sent: Tuesday, June 10, 2003 3:51 PM Subject: RE: [NSIS] framework: proposal on fragmentation > indeed. > > however, even 576 doesn't guarantee that fragmentation won't be needed > (for IPv4 the MTU could be as low as 68), and in any case, you also have to > take out the NTLP encapsulation overhead. > > doing unnecessary fragmentation as the NSLP will increase network load, > because you have more more messages. i suppose you could allow the NTLP to bundle > the fragments back together [i did originally consider this option but > discarded it as just too ugly to propose] but the result would still be > bigger than the original could have been, especially if the per-fragment overhead > is large. > > i still don't see this as preferable to having the NTLP able to chop up messages. > why is that so hard???? > > cheers, > > r. > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 10 June 2003 13:25 > > To: Hancock, Robert > > Cc: nsis@ietf.org > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > Hi Robert > > > > > > > > > ok, so [i think] you propose that there should be an > > minimum size NSLP > > > message that all NTLP instances should be able to transmit > > (presumably, > > > regardless of IP version or whatever encapsulation the NTLP > > itself adds, > > to > > > avoid the need to discover things dynamically). anything > > bigger, the NSLP > > > itself must fragment before providing it to the NTLP. > > > would you like to make a suggestion for how big that number > > should be? > > > > > > > For example, look into Section 4.2.2.7 of RFC 1812: > > " A common trick used by some implementations of TCP/IP is to > > fragment an IP datagram into IP fragments that are no > > larger than > > 576 bytes when the IP datagram is to travel through a router. > > This is intended to allow the resulting IP fragments to pass the > > rest of the path without further fragmentation. " , > > from RFC1812. > > > > Best regards, > > Georgios > > > > > > > > > -----Original Message----- > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > Sent: 10 June 2003 11:41 > > > > To: Hancock, Robert > > > > Cc: nsis@ietf.org > > > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > > > > > > > Hi Robert > > > > > > > > The NTLP should be able to transport a message with a > > > > minimum MTU without fragmenting it. > > > > > > > > Best Regards, > > > > Georgios > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Hancock, Robert" > > > > To: "'Georgios Karagiannis'" ; > > > > "'Lars.Westberg'" > > > > > > > > Cc: > > > > Sent: Tuesday, June 10, 2003 10:59 AM > > > > Subject: RE: [NSIS] framework: proposal on fragmentation > > > > > > > > > > > > > georgios, > > > > > > > > > > in your solution, what happens when an NTLP node gets a > > > > too-big message > > > > > with DF set? > > > > > > > > > > r. > > > > > > > > > > > -----Original Message----- > > > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > > > Sent: 10 June 2003 08:50 > > > > > > To: Hancock, Robert; 'Lars.Westberg' > > > > > > Cc: nsis@ietf.org > > > > > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > > > > > > > > > > > > > Hi Robert > > > > > > > > > > > > What I actually propose is to enhance the flexibility of > > > > > > the NTLP protocol by giving the ability to a NSLP to > > > > > > request or not to request the NTLP fragmentation feature. > > > > > > A possible method of doing this is as follows: > > > > > > > > > > > > First of all the NTLP protocol has to use some > > > > information, e.g., a > > > > > > fragmentation bit, to specify that > > > > > > fragmentation is allowed or not. > > > > > > Now, if the sender NSLP (NI) informs its NTLP instance to > > > > > > switch off the > > > > > > fragmentation, then this NTLP instance > > > > > > will switch off the fragmentation bit. In this way all the > > > > > > intermediate NTLP > > > > > > nodes will know that fragmentation is > > > > > > not allowed. > > > > > > Note that in this case NTLP negotiation is not needed! > > > > > > > > > > > > Best regards, > > > > > > Georgios > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Hancock, Robert" > > > > > > To: "'Lars.Westberg'" > > > > > > Cc: "Tom Taylor" ; "Georgios > > > > Karagiannis" > > > > > > ; > > > > > > Sent: Friday, June 06, 2003 5:42 PM > > > > > > Subject: RE: [NSIS] framework: proposal on fragmentation > > > > > > > > > > > > > > > > > > > OK - this was option 1 in the original email summary. There > > > > > > seemed to > > > > > > > be some resistance to it from several places and a > > > > preference to the > > > > > > > NTLP approach. > > > > > > > > > > > > > > What I can imagine you suggesting is: try to get the > > > > NSLP to create > > > > > > messages > > > > > > > which don't require fragmentation at all (by doing the > > > > fragmentation > > > > > > > itself); > > > > > > > in the [hopefully rare] cases where something goes wrong, > > > > > > rely on the IP > > > > > > > layer to handle it. > > > > > > > > > > > > > > That's an approach - I think it's a much more credible > > > > approach than > > > > > > > relying on the NSLP alone, but given the unpleasantness > > > > > > about doing it > > > > > > > at either IP or NSLP, I still prefer the NTLP option. > > > > Anyway, people > > > > > > > need to make the argument about which is better and why: > > > > > > > IP only > > > > > > > NTLP only > > > > > > > NSLP only > > > > > > > IP+NSLP > > > > > > > > > > > > > > The other point is: since we are arguing about the > > > > > > fragmentation aspect > > > > > > > (rather than the reassembly aspect) .... just how > > > > difficult is it to > > > > > > > chop up a message and put a common header on each part? > > > > And how much > > > > > > > complexity is > > > > > > > it worth putting in the rest of the network architecture to > > > > > > save doing it? > > > > > > > > > > > > > > cheers, > > > > > > > > > > > > > > r. > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Lars.Westberg [mailto:Lars.Westberg@era.ericsson.se] > > > > > > > > Sent: 06 June 2003 16:27 > > > > > > > > To: Hancock, Robert > > > > > > > > Cc: Tom Taylor; Georgios Karagiannis; nsis@ietf.org > > > > > > > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > > > > > > > > > > > > > > > > > > > Use IP-fragmentation > > > > > > > > > > > > > > > > -lasse > > > > > > > > > > > > > > > > "Hancock, Robert" wrote: > > > > > > > > > > > > > > > > > aha! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > No, I trying to explain it: > > > > > > > > > > If you have a network element without knowledge > > > > of the NSLP:s > > > > > > > > > > requirment, the > > > > > > > > > > default should be to forward it to the next hop > > > > without doing > > > > > > > > > > anything to the > > > > > > > > > > NSLP-messages. > > > > > > > > > > > > > > > > > > *** and what if the message is too big to forward? *** > > > > > > > > > [which is where we started...] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > regards Lasse > > > > > > > > > > > > > > > > > > > > > > > > > > > > r. > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > > > ---------- > > > > > > > > > Name: RMRL-Disclaimer.txt > > > > > > > > > RMRL-Disclaimer.txt Type: Plain Text (text/plain) > > > > > > > > > Encoding: 7bit > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 Tue Jun 10 16:35: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 QAA16717 for ; Tue, 10 Jun 2003 16:35:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AKYjU24089 for nsis-archive@odin.ietf.org; Tue, 10 Jun 2003 16:34:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AKYcB24050; Tue, 10 Jun 2003 16:34:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AKXcB24016 for ; Tue, 10 Jun 2003 16:33:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16643 for ; Tue, 10 Jun 2003 16:33:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PpmG-0001uT-00 for nsis@ietf.org; Tue, 10 Jun 2003 16:31:32 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19PpmF-0001uM-00 for nsis@ietf.org; Tue, 10 Jun 2003 16:31:32 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5AKWmq03314; Tue, 10 Jun 2003 16:32:48 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KRLGCJ08; Tue, 10 Jun 2003 16:32:48 -0400 Received: from nortelnetworks.com (acart1dn.ca.nortel.com [47.129.129.97]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JQNA0SNC; Tue, 10 Jun 2003 16:32:49 -0400 Message-ID: <3EE6406D.4040506@nortelnetworks.com> Date: Tue, 10 Jun 2003 16:32:45 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Georgios Karagiannis CC: "Hancock, Robert" , nsis@ietf.org Subject: Re: [NSIS] framework: proposal on fragmentation References: <011201c32f5d$74022ef0$4c0d5982@dynamic.cs.utwente.nl> In-Reply-To: <011201c32f5d$74022ef0$4c0d5982@dynamic.cs.utwente.nl> 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 You haven't answered Robert's earlier question: what happens if an intermediate NTLP node receives a "don't fragment" message which is too big to pass on. The obvious treatment is to drop the message. Must the intermediate NTLP node also send a message back indicating that the forward message was dropped. Georgios Karagiannis wrote: > Hi Robert > > What I actually propose is that when the NSLP is not in favour of NTLP > fragmentation, > then the NTLP should not do fragmentation. If the NSLP activates the > "Do Fragmentation" bit then the NTLP is allowed to do fragmentation. > Otherwise if the NSLP switches off the "Do Fragmentation" bit then the > NTLP will not do fragmentation. Please note that in this situation the NSLP > is > aware of the fragmentation issues and it will either rely on the IP > fragmentation > or try to solve the fragmentation issues by its own. > > > Best Regards, > Georgios > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Jun 11 04:10: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 EAA29063 for ; Wed, 11 Jun 2003 04:10:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5B8A4317391 for nsis-archive@odin.ietf.org; Wed, 11 Jun 2003 04:10:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B89pB17343; Wed, 11 Jun 2003 04:09:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B88gB17304 for ; Wed, 11 Jun 2003 04:08:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29019 for ; Wed, 11 Jun 2003 04:08:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q0cu-0005nl-00 for nsis@ietf.org; Wed, 11 Jun 2003 04:06:36 -0400 Received: from infres.enst.fr ([137.194.160.3]) by ietf-mx with esmtp (Exim 4.12) id 19Q0ct-0005nh-00 for nsis@ietf.org; Wed, 11 Jun 2003 04:06:35 -0400 Received: from luu (dhcp7-211.enst.fr [137.194.7.211]) by infres.enst.fr (Postfix) with SMTP id 5163118E1; Wed, 11 Jun 2003 10:08:38 +0200 (MEST) Message-ID: <001501c32ff0$6bd6c680$d307c289@enst.fr> From: "Thanh Tra LUU" To: "Tom Taylor" , "Georgios Karagiannis" Cc: References: <011201c32f5d$74022ef0$4c0d5982@dynamic.cs.utwente.nl> <3EE6406D.4040506@nortelnetworks.com> Subject: Re: [NSIS] framework: proposal on fragmentation Date: Wed, 11 Jun 2003 10:06:54 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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 Tom, I think we can do as you said that a next NTLP uses a notification of error (like ICMP). When a NTLP receives this notification, it notifies NSLP to reduce the NSLP message's length. So NSLP must be able to fragment its messages. Georgios said that NSLP message's length is too small to need fragmenting by NTLP so this function can be switched off, but how NSLP can know its message's length is small enough to not need fragmenting ? I don't think NTLP notifies NSLP about the max length is a good way. Because it looks like PMTU mechanism, so I think we let NTLP does it all. NTLP can set the bit "Don't Fragement" or not (for some useful purposes of NTLP), but it must do it by itself and this is opaque to NSLP. Nary Tra ENST, Paris ----- Original Message ----- From: "Tom Taylor" To: "Georgios Karagiannis" Cc: "Hancock, Robert" ; Sent: Tuesday, June 10, 2003 10:32 PM Subject: Re: [NSIS] framework: proposal on fragmentation > You haven't answered Robert's earlier question: what happens if an intermediate NTLP > node receives a "don't fragment" message which is too big to pass on. The obvious > treatment is to drop the message. Must the intermediate NTLP node also send a > message back indicating that the forward message was dropped. > > Georgios Karagiannis wrote: > > > Hi Robert > > > > What I actually propose is that when the NSLP is not in favour of NTLP > > fragmentation, > > then the NTLP should not do fragmentation. If the NSLP activates the > > "Do Fragmentation" bit then the NTLP is allowed to do fragmentation. > > Otherwise if the NSLP switches off the "Do Fragmentation" bit then the > > NTLP will not do fragmentation. Please note that in this situation the NSLP > > is > > aware of the fragmentation issues and it will either rely on the IP > > fragmentation > > or try to solve the fragmentation issues by its own. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Jun 11 04:39: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 EAA29539 for ; Wed, 11 Jun 2003 04:39:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5B8dN219277 for nsis-archive@odin.ietf.org; Wed, 11 Jun 2003 04:39:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B8d8B19262; Wed, 11 Jun 2003 04:39:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B8cKB19197 for ; Wed, 11 Jun 2003 04:38:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29492 for ; Wed, 11 Jun 2003 04:38:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q15Z-0005t3-00 for nsis@ietf.org; Wed, 11 Jun 2003 04:36:13 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Q15T-0005sz-00 for nsis@ietf.org; Wed, 11 Jun 2003 04:36:07 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h5B8cYbj010002; Wed, 11 Jun 2003 10:38:34 +0200 Received: from era.ericsson.se (E00104B7F41BB.ki.sw.ericsson.se [147.214.181.136]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGH1ZC7; Wed, 11 Jun 2003 10:39:15 +0200 Message-ID: <3EE6EA3B.C764DF82@era.ericsson.se> Date: Wed, 11 Jun 2003 10:37:15 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Lars.Westberg" X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Tom Taylor CC: Georgios Karagiannis , "Hancock, Robert" , nsis@ietf.org Subject: Re: [NSIS] framework: proposal on fragmentation References: <011201c32f5d$74022ef0$4c0d5982@dynamic.cs.utwente.nl> <3EE6406D.4040506@nortelnetworks.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 Comment below Tom Taylor wrote: > You haven't answered Robert's earlier question: what happens if an intermediate NTLP > node receives a "don't fragment" message which is too big to pass on. The obvious > treatment is to drop the message. Must the intermediate NTLP node also send a > message back indicating that the forward message was dropped. if NTLP can not forward the meesage, is'nt that a typical error handling condition ? I forseen that we have to handle many types of errors in a NTLP-protocol. > > > Georgios Karagiannis wrote: > > > Hi Robert > > > > What I actually propose is that when the NSLP is not in favour of NTLP > > fragmentation, > > then the NTLP should not do fragmentation. If the NSLP activates the > > "Do Fragmentation" bit then the NTLP is allowed to do fragmentation. > > Otherwise if the NSLP switches off the "Do Fragmentation" bit then the > > NTLP will not do fragmentation. Please note that in this situation the NSLP > > is > > aware of the fragmentation issues and it will either rely on the IP > > fragmentation > > or try to solve the fragmentation issues by its own. > > > > > > 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 Jun 11 04:43: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 EAA29616 for ; Wed, 11 Jun 2003 04:43:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5B8hBs19458 for nsis-archive@odin.ietf.org; Wed, 11 Jun 2003 04:43:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B8h6B19447; Wed, 11 Jun 2003 04:43:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B8gcB19431 for ; Wed, 11 Jun 2003 04:42:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29597 for ; Wed, 11 Jun 2003 04:42:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q19j-0005uq-00 for nsis@ietf.org; Wed, 11 Jun 2003 04:40:31 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19Q19i-0005un-00 for nsis@ietf.org; Wed, 11 Jun 2003 04:40:30 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Jun 2003 09:42:33 +0100 Message-ID: From: "Hancock, Robert" To: "'Thanh Tra LUU'" , Tom Taylor , Georgios Karagiannis Cc: nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation Date: Wed, 11 Jun 2003 09:42:33 +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: , dear all, what i am missing at the moment is a complete picture of how this 'optional fragmentation scheme' (or schemes?) would really work in practice, including (as Tom says) what really happens to too-big non-fragmentable messages (generate an error and route it back to the originating NSLP? fragment at IP level?) and so on. since this scheme still has the fragmentation functionality in the NTLP, i'm struggling (i'm trying, but i'm really struggling) to see how it is more attractive than just saying 'the NTLP does the fragmentation if it needs to'. my expectation would be that all NSLPs would set 'fragmentation allowed' on their messages, because the NSLP designer can't see any benefit in creating an extra error case to handle and doesn't want to invent his own PMTU-like discovery mechanisms. in that case it reduces in practice to the previous case anyway, while polluting the protocol with more error conditions and optional parts. cheers, r. > -----Original Message----- > From: Thanh Tra LUU [mailto:luu@enst.fr] > Sent: 11 June 2003 09:07 > To: Tom Taylor; Georgios Karagiannis > Cc: nsis@ietf.org > Subject: Re: [NSIS] framework: proposal on fragmentation > > > hi Tom, > > I think we can do as you said that a next NTLP uses a > notification of error > (like ICMP). When a NTLP receives this notification, it > notifies NSLP to > reduce the NSLP message's length. So NSLP must be able to fragment its > messages. > > Georgios said that NSLP message's length is too small to need > fragmenting by > NTLP so this function can be switched off, but how NSLP can know its > message's length is small enough to not need fragmenting ? > > I don't think NTLP notifies NSLP about the max length is a > good way. Because > it looks like PMTU mechanism, so I think we let NTLP does it > all. NTLP can > set the bit "Don't Fragement" or not (for some useful > purposes of NTLP), but > it must do it by itself and this is opaque to NSLP. > > > Nary Tra > ENST, Paris > > > > ----- Original Message ----- > From: "Tom Taylor" > To: "Georgios Karagiannis" > Cc: "Hancock, Robert" ; > Sent: Tuesday, June 10, 2003 10:32 PM > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > You haven't answered Robert's earlier question: what happens if an > intermediate NTLP > > node receives a "don't fragment" message which is too big > to pass on. The > obvious > > treatment is to drop the message. Must the intermediate > NTLP node also > send a > > message back indicating that the forward message was dropped. > > > > Georgios Karagiannis wrote: > > > > > Hi Robert > > > > > > What I actually propose is that when the NSLP is not in > favour of NTLP > > > fragmentation, > > > then the NTLP should not do fragmentation. If the NSLP > activates the > > > "Do Fragmentation" bit then the NTLP is allowed to do > fragmentation. > > > Otherwise if the NSLP switches off the "Do Fragmentation" > bit then the > > > NTLP will not do fragmentation. Please note that in this > situation the > NSLP > > > is > > > aware of the fragmentation issues and it will either rely > on the IP > > > fragmentation > > > or try to solve the fragmentation issues by its own. > > > _______________________________________________ > 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 Jun 11 05:31:54 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 FAA00480 for ; Wed, 11 Jun 2003 05:31:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5B9VTX22261 for nsis-archive@odin.ietf.org; Wed, 11 Jun 2003 05:31:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B9VNB22254; Wed, 11 Jun 2003 05:31:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B9UOB22178 for ; Wed, 11 Jun 2003 05:30:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00428 for ; Wed, 11 Jun 2003 05:30:19 -0400 (EDT) From: maarten.buchli@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q1tw-00065k-00 for nsis@ietf.org; Wed, 11 Jun 2003 05:28:16 -0400 Received: from alc240.alcatel.be ([195.207.101.240] helo=bt0rjw.god.bel.alcatel.be) by ietf-mx with esmtp (Exim 4.12) id 19Q1tv-00065b-00 for nsis@ietf.org; Wed, 11 Jun 2003 05:28:16 -0400 Received: from bemail05.net.alcatel.be (bemail05.net.alcatel.be [138.203.144.16]) by bt0rjw.god.bel.alcatel.be (8.12.9/8.11.4) with ESMTP id h5B9Ti3W020048; Wed, 11 Jun 2003 11:29:49 +0200 (MEST) Subject: RE: [NSIS] framework: proposal on fragmentation To: "Hancock, Robert" Cc: nsis@ietf.org Date: Wed, 11 Jun 2003 11:29:43 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 06/11/2003 11:29:49 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 all, I fully agree with Robert. I cannot see any relevance of a fragmentation bit either. Dropping messages because they are too large and have the 'do not fragment' bit set does not seem a nice approach to me. Indeed, as pointed out by Robert this will lead to unnecessary error conditions, which should be avoided in my opinion. regards, Maarten "Hancock, Robert" @ietf.org on 11/06/2003 10:42:33 Sent by: nsis-admin@ietf.org To: "'Thanh Tra LUU'" , Tom Taylor , Georgios Karagiannis cc: nsis@ietf.org Subject: RE: [NSIS] framework: proposal on fragmentation dear all, what i am missing at the moment is a complete picture of how this 'optional fragmentation scheme' (or schemes?) would really work in practice, including (as Tom says) what really happens to too-big non-fragmentable messages (generate an error and route it back to the originating NSLP? fragment at IP level?) and so on. since this scheme still has the fragmentation functionality in the NTLP, i'm struggling (i'm trying, but i'm really struggling) to see how it is more attractive than just saying 'the NTLP does the fragmentation if it needs to'. my expectation would be that all NSLPs would set 'fragmentation allowed' on their messages, because the NSLP designer can't see any benefit in creating an extra error case to handle and doesn't want to invent his own PMTU-like discovery mechanisms. in that case it reduces in practice to the previous case anyway, while polluting the protocol with more error conditions and optional parts. cheers, r. > -----Original Message----- > From: Thanh Tra LUU [mailto:luu@enst.fr] > Sent: 11 June 2003 09:07 > To: Tom Taylor; Georgios Karagiannis > Cc: nsis@ietf.org > Subject: Re: [NSIS] framework: proposal on fragmentation > > > hi Tom, > > I think we can do as you said that a next NTLP uses a > notification of error > (like ICMP). When a NTLP receives this notification, it > notifies NSLP to > reduce the NSLP message's length. So NSLP must be able to fragment its > messages. > > Georgios said that NSLP message's length is too small to need > fragmenting by > NTLP so this function can be switched off, but how NSLP can know its > message's length is small enough to not need fragmenting ? > > I don't think NTLP notifies NSLP about the max length is a > good way. Because > it looks like PMTU mechanism, so I think we let NTLP does it > all. NTLP can > set the bit "Don't Fragement" or not (for some useful > purposes of NTLP), but > it must do it by itself and this is opaque to NSLP. > > > Nary Tra > ENST, Paris > > > > ----- Original Message ----- > From: "Tom Taylor" > To: "Georgios Karagiannis" > Cc: "Hancock, Robert" ; > Sent: Tuesday, June 10, 2003 10:32 PM > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > You haven't answered Robert's earlier question: what happens if an > intermediate NTLP > > node receives a "don't fragment" message which is too big > to pass on. The > obvious > > treatment is to drop the message. Must the intermediate > NTLP node also > send a > > message back indicating that the forward message was dropped. > > > > Georgios Karagiannis wrote: > > > > > Hi Robert > > > > > > What I actually propose is that when the NSLP is not in > favour of NTLP > > > fragmentation, > > > then the NTLP should not do fragmentation. If the NSLP > activates the > > > "Do Fragmentation" bit then the NTLP is allowed to do > fragmentation. > > > Otherwise if the NSLP switches off the "Do Fragmentation" > bit then the > > > NTLP will not do fragmentation. Please note that in this > situation the > NSLP > > > is > > > aware of the fragmentation issues and it will either rely > on the IP > > > fragmentation > > > or try to solve the fragmentation issues by its own. > > > _______________________________________________ > 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 Jun 11 05:35: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 FAA00550 for ; Wed, 11 Jun 2003 05:35:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5B9ZAY22479 for nsis-archive@odin.ietf.org; Wed, 11 Jun 2003 05:35:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B9Z3B22469; Wed, 11 Jun 2003 05:35:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5B9YHB22415 for ; Wed, 11 Jun 2003 05:34:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00530 for ; Wed, 11 Jun 2003 05:34:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q1xg-00067d-00 for nsis@ietf.org; Wed, 11 Jun 2003 05:32:08 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19Q1xf-00067a-00 for nsis@ietf.org; Wed, 11 Jun 2003 05:32:08 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h5B9YA5s024625; Wed, 11 Jun 2003 11:34:10 +0200 (MET DST) Message-ID: <008001c32ffc$9d542f70$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" Cc: References: Subject: Re: [NSIS] framework: proposal on fragmentation Date: Wed, 11 Jun 2003 11:34:11 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Robert > > what i am missing at the moment is a complete picture of how this 'optional > fragmentation scheme' (or schemes?) would really work in practice, including > (as Tom says) what really happens to too-big non-fragmentable messages > (generate > an error and route it back to the originating NSLP? fragment at IP level?) > and > so on. Well, we can define the detailed operation later on. Now it is important to mention that in the default case fragmentation is accomplished by the NTLP. However, the NSLP instance of NI (NSIS Initiator) is capable of deactivating (switching off) the NTLP fragmentation. > since this scheme still has the fragmentation functionality in the NTLP, i'm > struggling (i'm trying, but i'm really struggling) to see how it is more > attractive > than just saying 'the NTLP does the fragmentation if it needs to'. my > expectation > would be that all NSLPs would set 'fragmentation allowed' on their messages, > > because the NSLP designer can't see any benefit in creating an extra error > case > to handle and doesn't want to invent his own PMTU-like discovery mechanisms. > in > that case it reduces in practice to the previous case anyway, while > polluting the > protocol with more error conditions and optional parts. If the NSLP instance of NI (NSIS Initiator) NI needs to use the NTLP fragmentation then the "Do fragmentation" bit will be activated. Otherwise, this NSLP instance will de-activate (switch off) the "Do Forwarding" bit. Best regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Jun 11 13:48: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 NAA19071 for ; Wed, 11 Jun 2003 13:48:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BHlpf20251 for nsis-archive@odin.ietf.org; Wed, 11 Jun 2003 13:47:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BHlZm20140; Wed, 11 Jun 2003 13:47:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BHSOm18493 for ; Wed, 11 Jun 2003 13:28:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18278 for ; Wed, 11 Jun 2003 13:28:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q9MX-00020F-00 for nsis@ietf.org; Wed, 11 Jun 2003 13:26:17 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19Q9MW-000206-00 for nsis@ietf.org; Wed, 11 Jun 2003 13:26:16 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5BHRljc005689; Wed, 11 Jun 2003 10:27:48 -0700 (PDT) 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.3.3-GR) with ESMTP id AEZ23092; Wed, 11 Jun 2003 10:27:46 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA15356; Wed, 11 Jun 2003 10:27:46 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16103.26258.208692.50722@thomasm-u1.cisco.com> Date: Wed, 11 Jun 2003 10:27:46 -0700 (PDT) To: "Lars.Westberg" Cc: "Geib, Ruediger" , nsis@ietf.org Subject: Re: [NSIS] framework: proposal on fragmentation In-Reply-To: <3EE0AC80.746DB02@era.ericsson.se> References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB4BE@G8PQD.blf01.telekom.de> <3EE0AC80.746DB02@era.ericsson.se> 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 Lars.Westberg writes: > The generality of NTLP is a difficutl issue. My point is that I can > forsee application that is so simple > that an UDP-style of operation is good enough. [] I really think it might be useful to take a more systemic look at things on all of these discussions. That is, what are we trying to use NSIS for, and what are the design constraints in that system. In isolation the notion of UDP-based communication is good since you don't need hard state, blah, blah, blah. My personal acid test is in the realm of mobility and handoffs: could an NSIS be used to gain favorable treatment of packets on a lossy and insecure medium where fast handoffs are necessary to keep connectivity? The two principle things that come to my mind are: 1) Security -- rationing a scarce resource 2) Speed -- completing the allocation in a timely fashion so as to be useful If either of these conditions are not met, then NSIS is likely to not be used, opting instead for the time-honored tradition of brute force and ignorance, or used in a way such that the setup time is not in the critical path. In this particular scenario, connectionless transport doesn't tell the whole story; the desire to have a command/response kind of 2 message protocol (on the first hop, that is) is an obvious win over needing to first need to create a session, but the access control aspect of (1) is a significant consideration as well. In particular, identity credentials have a tendency to be large, and CPU complexity especially for public key operations tends to be high. Both considerations push you in the direction of creating hard state of some kind (cf IKE main mode, TCP). At the very least, it's fairly obvious that any underlying transport which wants to use X.509 type identities is going to have to deal with the message fragmentation problem, and frankly IP-layer fragmentation is just a non-starter, IMO, if that's the norm. So in at least some of the interesting cases we know that we won't be able to have our coveted command/response protocol (assuming the MTU-pixie doesn't wave its wand over the Internet): three or more messages may be necessary. Which leads us to the next questions: 1) how interesting is this case? (ie, how likely) 2) does more than 2 messages in and of itself blow our time budget for (1) above? Neither are especially clear at this point: the deployed base of RSVP -- such as it is -- isn't using RFC 2752 identities that I'm aware of, so that's no help. Or maybe it's instructive... take your pick. And (2) is highly dependent on the air interface and its characteristics. For current 3G cellular just about anything beyond a single command and response for *everything* is likely to blow your time budget, and 802.11 while better isn't dramatically better. Which is to say, that it's not entirely clear that for, oh say, VoIP with current radio technologies intersected with access control requirements that this is going to work well enough during handoffs in the naive break-before-make handoff that's an unfortunate necessity. I'm sure somebody will find this debatable, but that's not really my point here. So, I'm not sure where I'm going with this except to try to ground these discussions into some sort of reality check of what we're trying to accomplish here. In my particular example, depending on how you tweak the parameters, connectionless establishment may be a large win, or it may be a non-starter. Also: if you believe that X.509 or other large byte identities are going to see widespread deployment for access control for wireless, then it's pretty much a given that we're going to need to deal with transport fragmentation in a sensible (read: non-L3) way. That in turn informs the debate whether fragmentation based on a non-threeway handshake protocol (tcp/sctp) is useful (or possible, some might argue). Finally, finesse is required here. It's easy to say that x.509 identities are required therefore fragmentation trumps all. That way lies insanity, IMO. We have to be careful to not overengineer solutions for marginal problems. The track record of PKI deployment is not good, so it's probably wise to consider the case where it is not part of the solution and provide optimization around that design criteria. Which is why I'm muddled about this. Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Jun 11 16:34: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 QAA28685 for ; Wed, 11 Jun 2003 16:34:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BKYTq00763 for nsis-archive@odin.ietf.org; Wed, 11 Jun 2003 16:34:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BKYKm00729; Wed, 11 Jun 2003 16:34:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BKXpm00705 for ; Wed, 11 Jun 2003 16:33:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26880 for ; Wed, 11 Jun 2003 16:33:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QCG0-0003WS-00 for nsis@ietf.org; Wed, 11 Jun 2003 16:31:44 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19QCFz-0003WP-00 for nsis@ietf.org; Wed, 11 Jun 2003 16:31:43 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5BKX9jc028457; Wed, 11 Jun 2003 13:33:10 -0700 (PDT) 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.3.3-GR) with ESMTP id AEZ46549; Wed, 11 Jun 2003 13:33:09 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA15693; Wed, 11 Jun 2003 13:33:09 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16103.37381.277467.475065@thomasm-u1.cisco.com> Date: Wed, 11 Jun 2003 13:33:09 -0700 (PDT) To: mankin@psg.com Cc: brunner@ccrle.nec.de, john.loughney@nokia.com, nsis@ietf.org Subject: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt 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 Allison Mankin writes: > 5.4.3 State MUST be addressed independent of flow identification > > Addressing or identifying state MUST be independent of the flow > identifier (flow end-points, topological addresses). Various > scenarios in the mobility area require this independence because > flows resulting from handoff might have changed end-points etc. but > still have the same service requirement. Also several proxy-based > signaling methods profit from such independence. > > Add to the last sentence "though these are not chartered work items for > NSIS". > > This is a tough requirement since it has to be globally unique. It may > turn out to be best met by the NI's authentication token, requiring an > early integration of authentication design into the protocol. No request > to change this, but just noting how hard this is - WG is _sure_ > the mobility requirements are really so important? Maybe I don't understand what you're concerned about, but why should this be hard? Say I generate a pseudo-random number, we'd only really have to worry about the birthday paradox which is mitigated by adding bits. We're talking about the (NSIS) signaling traffic, right? This seems pretty orthogonal to auth... Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Wed Jun 11 18:02: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 SAA05169 for ; Wed, 11 Jun 2003 18:02:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BM2PT09570 for nsis-archive@odin.ietf.org; Wed, 11 Jun 2003 18:02:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BM2Hm09560; Wed, 11 Jun 2003 18:02:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BM1jm09527 for ; Wed, 11 Jun 2003 18:01:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05138 for ; Wed, 11 Jun 2003 18:01:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QDd3-0004QX-00 for nsis@ietf.org; Wed, 11 Jun 2003 17:59:37 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19QDd2-0004QN-00 for nsis@ietf.org; Wed, 11 Jun 2003 17:59:36 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5BM1BVI040515; Thu, 12 Jun 2003 00:01:11 +0200 (CEST) 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 B3EDDA597B; Wed, 11 Jun 2003 23:47:57 +0200 (CEST) Date: Thu, 12 Jun 2003 00:01:13 +0200 From: Marcus Brunner Reply-To: Marcus Brunner To: mankin@psg.com Cc: john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt Message-ID: <50208495.1055376073@[10.1.1.130]> In-Reply-To: References: X-Mailer: Mulberry/3.0.2 (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 Alison, John, Here my comments and how I have addressed them. I am going to submit the changed version (-08) soon. Marcus > > -------- > However, QoS is not the only field where signaling > is used in the Internet. Others might be the use for middlebox > communication [RFC3234]. > > It would be helpful to clarify the manner in which signaling would be > used for middlebox communication (in one sentence) - this is so terse, > that only if a reader has been in the working group would they understand > the sentence. > > Suggestion: "Signaling might also be used as a communication protocol > to set up the state in middleboxes." > changed into "Signaling might also be used as a communication protocol to setup and maintain the state in middleboxes." > -------- > > There are several areas related to networking aspects which are > incomplete, for example, interaction with host and site multi- > homing, use of anycast services, and so on. These issues should be > considered in any future analysis work. > > Incomplete in the sense of requirements analysis? This paragraph suggests > a different kind of analysis. Also anycast in particular seems very > unlikely to be a significant element in signaling requirements analysis > - it seems like it should not be mentioned in the same sentence with a > common issue like multihoming. > > Suggestion: "This document does not cover requirements in relation to > some networking areas, in particular, interaction with host and site > multihoming. We leave these for future analysis. " > ok, change accepted > -------- > > NSIS Initiator - needs to say, in parallel with the NSIS Responder, > it interacts with applications (Definition does not say so). > > -------- > 3. Something that terminates the signaling path, the NSIS Responder. > > The NSIS responder might be in an end-system or within other > equipment. The distinguishing feature of the NSIS Initiator is that > ^^^^^^^^^ > it responds to requests at the end of a signaling path. > > Typo? s/Initiator/Responder/ > done thanks > -------- > The host to first > router part includes all the layer 2 technologies to access to the > Internet. > > Consider a home network with a wireless router and a DSL router accessing > the Internet. The topology definition is less crisp than host to *first* > router. I suggest you add a sentence after this one: "This part of the > division is especially informal and may incorporate several access > segments." ok, added. > -------- > > 5.2.2 NSIS MUST support path-coupled and SHOULD NOT exclude path- > decoupled signaling. > > SHOULD NOT is very strong, given that the WG is not chartered to work on > this technology. > > The language needs to be "MAY support path-decoupled signaling." > Req changed to 5.2.2 NSIS MUST support path-coupled and MAY support path-decoupled signaling. The path-coupled signaling mode MUST be supported. NSIS signaling messages are routed only through nodes (NEs) that are in the data path. However, there is a set of scenarios, where signaling is not on the data path. Therefore, NSIS MAY support the path-decoupled signaling mode, where signaling messages are routed to nodes (NEs), which are not assumed to be on the data path, but which are aware of it. > -------- > > 5.3.2 Automatic release of state after failure SHOULD be possible > > When the NSIS Initiator goes down, the state it requested in the > network SHOULD be released, since it will no longer be necessary. > > An important feature of RSVP was its soft-state character, in part to > ensure that critical resources in the net were not fate-shared for too > long. Given this is about release after _failure_, these SHOULDs should > be MUSTs, if not going so far as to preserve the soft-state architecture. > Comments? > Changed to 5.3.2 Automatic release of state after failure MUST be possible When the NSIS Initiator goes down, the state it requested in the network SHOULD be released, since it will most likely no longer be necessary. After detection of a failure in the network, any NSIS Forwarder/Initiator MUST be able to release state it is involved in. For example, this may require signaling of the "Release after Failure" message upstream as well as downstream, or soft state timing out. The goal is to prevent stale state within the network and adds robustness to the operation of NSIS. So in other words, an NSIS signaling protocol or mechanisms MUST provide means for an NSIS entity to discover and remove local stale state. Note that this might need to work together with a notification mechanism. Note as well, that transient failures in NSIS processing shouldn't necessarily have to cause all state to be released immediately. > -------- > > > 5.4.3 State MUST be addressed independent of flow identification > > Addressing or identifying state MUST be independent of the flow > identifier (flow end-points, topological addresses). Various > scenarios in the mobility area require this independence because > flows resulting from handoff might have changed end-points etc. but > still have the same service requirement. Also several proxy-based > signaling methods profit from such independence. > > Add to the last sentence "though these are not chartered work items for > NSIS". > > This is a tough requirement since it has to be globally unique. It may > turn out to be best met by the NI's authentication token, requiring an > early integration of authentication design into the protocol. No request > to change this, but just noting how hard this is - WG is _sure_ > the mobility requirements are really so important? > ok added "though these are not chartered work items for NSIS" I think the address of the state might be locally unique only (per node), but this is a design decision. And I think mobility is important but should not be the overruling factor. > -------- > > > 5.4.1 Mutability information on parameters SHOULD be possible > > It SHOULD be possible for the NSIS initiator to control the > mutability of the signaled information. This prevents them from > being changed in a non-recoverable way. The NSIS initiator SHOULD be > able to control what is requested end to end, without the request > being gradually mutated as it passes through a sequence of domains. > This implies that in case of changes made on the parameters, the > original requested ones must still be available. > > Note that we do not require anything about particular parameters > being changed. > > Additionally, note that the provider of the particular requested > services can still influence the provisioning but in the signaling > message the request should stay the same. > > The requirement is not expressed well. Do you mean "It SHOULD be > possible to have nodes modify parameters to interact with the > signaling message, while still retaining an intact copy of the > original form of the signaling message"? > > This requirement seems like it would vary a great deal depending on what > the signaling application was, and as it is written here it is very close > to a protocol design rather than a requirement. Could you omit > it from this document? > You are right the part on keeping a copy is very design-specific, but as Robert pointed out in a different mail, the control of the change process should be under the control of the NSIS initiator. So with this I have change it the following: 5.4.1 Mutability information on parameters SHOULD be possible It is possible that nodes modify parameters of a signaling message. However, it SHOULD be possible for the NSIS Initiator to control the mutability of the signaled information. For example, the NSIS Initiator should be able to control what is requested end to end, without the request being gradually mutated as it passes through a sequence of nodes. > -------- > > One of the > reasons is that the protocol handling should have a minimal impact > on interior (core) nodes. > > Suggest adding that NSIS MAY also have a feature allowing core nodes > to ignore it (though I hope it will be more elegant than RSVP's as > document in RFC 3175 :) > added the point to the paragraph on example methods the req reads now 5.5.4 NSIS SHOULD allow to constrain load on devices The NSIS architecture SHOULD give the ability to constrain the load (CPU load, memory space, signaling bandwidth consumption and signaling intensity) on devices where it is needed. One of the reasons is that the protocol handling should have a minimal impact on interior (core) nodes. This can be achieved by many different methods. Examples include message aggregation, header compression, minimizing functionality, or ignoring signaling in core nodes. The framework may choose any method as long as the requirement is met. > -------- > > 5.7.5 Hop-by-hop security > > Hop-by-Hop security SHOULD be supported. It is a well known and > proven concept in Quality-of-Service and other signaling protocols > that allows intermediate nodes that actively participate in the > protocol to modify the messages as it is required by processing > rules. Note that this requirement does not exclude end-to-end or > network-to-network security of a signaling message. End-to-end > security between the initiator and the responder may be used to > provide protection of non-mutable data fields. Network-to-network > security refers to the protection of messages over various hops but > not in an end-to-end manner i.e. protected over a particular network. > > Without minimum mandatory to implement channel security for the > signaling, you can't be sure the other security features will be > untampered with - this needs to be a MUST implement (it's not a MUST > use). Suggest changing the first sentence to "Channel security between > signaling entities MUST be implemented'? > ok changed > -------- > > > 5.9.5 SHOULD interwork with seamless handoff protocols > > 5.9.6 MAY interwork with non-traditional routing > > NSIS assumes L3 routing, but networks, which do non-traditional > routing, should not break it. > > NSIS should not be complex and interworked in ways that make it less > modular. Both of these requirements are complications. The first one, > because it poses a certain environment and particular protocols, would > make NSIS less modular. It is probably improved by changing SHOULD to > MAY. The second one may sound worse than it is - does it mean NATs? > Suggest this might have meant: > > 5.9.6. MAY operate in varied routing environments > > NSIS assumes L3 routing, but it MAY be designed to operate in > varied routing environments, such as those with L4 switches and NATs. > > But if not, do explain... I don't see why this makes it less modular, nevertheless I followed Roberts proposal to use "work with" instead of "interwork" 5.9.5 SHOULD work with seamless handoff protocols An NSIS protocol SHOULD work with seamless handoff protocols such as context transfer and candidate access router (CAR) discovery. Concerning req 5.9.6 The req is not so much about that it is designed for other routing environments, but that it should not break in "non-traditional" environments. Again I followed Robert and replace "interworking" ith "work with" > -------- > > Scenarios - > > 's' as an abbreviation is not explained. > yes, should be Fast state installation > -------- > 10.2 > > The 3G Scenario is somewhat too specific to 3GPP and 3GPP2 still - IMS is > mentioned without being expanded or explained. All the terms are > specific. Try to make it a bit more abstract - say it is an All-IP > multimedia system. expanded the IMS, but being specific is on purpose it should be the 3GPP scenario. A less specific version has been complained about. > > -------- > This part of the wireless network has different > characteristics when compared to traditional IP networks: > > 1. The network supports a high proportion of real-time > traffic. The majority of the traffic transported in the > wired part of the wireless network is speech, which is > very sensitive to delays and delay variation (jitter). > > Two things about IP networks - they carry whatever they carry, so > it's not out of tradition to be a voice IP network. Second, speech in > Internet phones is quite a lot less sensitive to delays and jitter than > often thought, due to the many good engineering designs in playout and > speech cover that are known. So this material places a context of more > difference on the environment than most general transport experts view > as necessary, seeing more continuum, while not disagreeing that signaling > and resource reservation are valuable. > > So drop sentence 1, but leave the rest alone (I just wanted to make my > point :) > Actually, in this particular scenario it is very jitter sensitive, but this has nothing to do with IP phones and its playout, but with the design of current protocols running on top of IP here. I removed it anyway since it does not really add value. > -------- > > > 10.10 Application request end-to-end QoS path from the network > > This is actually the easiest case, nevertheless might be most often > used in terms of number of users. > > Few believe that ordinary applications signaling for QoS is an easy > matter for the network - RFCs 2961, 2996 and 3175 are all about > mitigating the unscalability of edge signaling. Probably this would go > better if you substitute the term "conceptually simplest" for "easiest" > and note that there are these issues with scaling. > > > Additionally, we assume no mobility and standard devices. > > Note: the end system application and NSIS do not know about the > distinction between 10.10 and the other scenarios :), unless NSIS is not > a modular Internet protocol. > You are right, removed the sentence > -------- > > QoS for Virtual Private Networks - section needs a number > > IP-Sec -> IPSec > ok > The discussion of NSIS in VPNs ignores the whole world of the PPVPN WG. > Cite draft-ietf-ppvpn-framework-08.txt early on in the section (it is in > the RFC-Editor Queue). > Ok added the reference. Marcus _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 12 00:08: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 AAA13826 for ; Thu, 12 Jun 2003 00:08:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5C48Sk02090 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 00:08:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C48Mm02064; Thu, 12 Jun 2003 00:08:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C47Cm01456 for ; Thu, 12 Jun 2003 00:07:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13791 for ; Thu, 12 Jun 2003 00:07:08 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QJKi-0006Ng-00 for nsis@ietf.org; Thu, 12 Jun 2003 00:05:04 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19QJKh-0006Nd-00 for nsis@ietf.org; Thu, 12 Jun 2003 00:05:04 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5C479922390 for ; Thu, 12 Jun 2003 07:07:09 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Jun 2003 07:07:08 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 12 Jun 2003 07:07:07 +0300 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 12 Jun 2003 07:07:07 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 12 Jun 2003 07:07:06 +0300 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] framework: proposal on fragmentation Date: Thu, 12 Jun 2003 07:07:05 +0300 Message-ID: Thread-Topic: [NSIS] framework: proposal on fragmentation Thread-Index: AcMwQ/95D3uzF7QJSZCS581B4r/3YgAU/Ofw To: , Cc: , X-OriginalArrivalTime: 12 Jun 2003 04:07:06.0762 (UTC) FILETIME=[168716A0:01C33098] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5C47Cm01457 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 Michael, This is what should be, in general, captured in the framework, i.e. - the big picture. John > -----Original Message----- > From: ext Michael Thomas [mailto:mat@cisco.com] > Sent: 11 June, 2003 20:28 > To: Lars.Westberg > Cc: Geib, Ruediger; nsis@ietf.org > Subject: Re: [NSIS] framework: proposal on fragmentation > > > Lars.Westberg writes: > > The generality of NTLP is a difficutl issue. My point is that I can > > forsee application that is so simple > > that an UDP-style of operation is good enough. > > [] > > I really think it might be useful to take a more > systemic look at things on all of these > discussions. That is, what are we trying to use > NSIS for, and what are the design constraints in > that system. In isolation the notion of UDP-based > communication is good since you don't need hard > state, blah, blah, blah. My personal acid test is > in the realm of mobility and handoffs: could an > NSIS be used to gain favorable treatment of > packets on a lossy and insecure medium where fast > handoffs are necessary to keep connectivity? > > The two principle things that come to my mind are: > > 1) Security -- rationing a scarce resource > 2) Speed -- completing the allocation in a timely > fashion so as to be useful > > If either of these conditions are not met, then > NSIS is likely to not be used, opting instead for > the time-honored tradition of brute force and > ignorance, or used in a way such that the setup > time is not in the critical path. > > In this particular scenario, connectionless > transport doesn't tell the whole story; the desire > to have a command/response kind of 2 message > protocol (on the first hop, that is) is an obvious > win over needing to first need to create a > session, but the access control aspect of (1) is a > significant consideration as well. In particular, > identity credentials have a tendency to be large, > and CPU complexity especially for public key > operations tends to be high. Both considerations > push you in the direction of creating hard state > of some kind (cf IKE main mode, TCP). At the very > least, it's fairly obvious that any underlying > transport which wants to use X.509 type identities > is going to have to deal with the message > fragmentation problem, and frankly IP-layer > fragmentation is just a non-starter, IMO, if > that's the norm. > > So in at least some of the interesting cases we > know that we won't be able to have our coveted > command/response protocol (assuming the MTU-pixie > doesn't wave its wand over the Internet): three or > more messages may be necessary. > > Which leads us to the next questions: > > 1) how interesting is this case? (ie, how likely) > 2) does more than 2 messages in and of itself blow > our time budget for (1) above? > > Neither are especially clear at this point: the > deployed base of RSVP -- such as it is -- isn't > using RFC 2752 identities that I'm aware of, so > that's no help. Or maybe it's instructive... take > your pick. And (2) is highly dependent on the air > interface and its characteristics. For current 3G > cellular just about anything beyond a single > command and response for *everything* is likely to > blow your time budget, and 802.11 while better > isn't dramatically better. > > Which is to say, that it's not entirely clear that > for, oh say, VoIP with current radio technologies > intersected with access control requirements that > this is going to work well enough during handoffs > in the naive break-before-make handoff that's an > unfortunate necessity. I'm sure somebody will find > this debatable, but that's not really my point > here. > > So, I'm not sure where I'm going with this except > to try to ground these discussions into some sort > of reality check of what we're trying to > accomplish here. In my particular example, > depending on how you tweak the parameters, > connectionless establishment may be a large win, > or it may be a non-starter. Also: if you believe > that X.509 or other large byte identities are > going to see widespread deployment for access > control for wireless, then it's pretty much a > given that we're going to need to deal with > transport fragmentation in a sensible (read: > non-L3) way. That in turn informs the debate > whether fragmentation based on a non-threeway > handshake protocol (tcp/sctp) is useful (or > possible, some might argue). > > Finally, finesse is required here. It's easy to > say that x.509 identities are required therefore > fragmentation trumps all. That way lies insanity, > IMO. We have to be careful to not overengineer > solutions for marginal problems. The track record > of PKI deployment is not good, so it's probably > wise to consider the case where it is not part of > the solution and provide optimization around that > design criteria. > > Which is why I'm muddled about this. > > Mike > > _______________________________________________ > 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 Jun 12 00:26: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 AAA14241 for ; Thu, 12 Jun 2003 00:26:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5C4QIO02889 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 00:26:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C4QCm02862; Thu, 12 Jun 2003 00:26:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C4PPm02781 for ; Thu, 12 Jun 2003 00:25:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14211 for ; Thu, 12 Jun 2003 00:25:21 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QJcM-0006RH-00 for nsis@ietf.org; Thu, 12 Jun 2003 00:23:18 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19QJcL-0006RE-00 for nsis@ietf.org; Thu, 12 Jun 2003 00:23:17 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5C4PLa27068 for ; Thu, 12 Jun 2003 07:25:22 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Jun 2003 07:25:21 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 12 Jun 2003 07:25:21 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 12 Jun 2003 07:25:20 +0300 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] AD Review comments on draft-ietf-nsis-req-07.txt Date: Thu, 12 Jun 2003 07:25:19 +0300 Message-ID: Thread-Topic: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt Thread-Index: AcMwZRCT09FHrEE4QGmSVCTQG/B3IAANGbCw To: , Cc: X-OriginalArrivalTime: 12 Jun 2003 04:25:21.0176 (UTC) FILETIME=[A2D96980:01C3309A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5C4PPm02782 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, In general, all of the comments look good, one concern, however - > > 10.2 > > > > The 3G Scenario is somewhat too specific to 3GPP and 3GPP2 > still - IMS is > > mentioned without being expanded or explained. All the terms are > > specific. Try to make it a bit more abstract - say it is an All-IP > > multimedia system. > > expanded the IMS, but being specific is on purpose it should be the 3GPP > scenario. A less specific version has been complained about. The one problem is that the IETF is not 3GPP, and it may be seen as the IETF imposing its view upon 3GPP. We should be careful not to imply that this is the way that the IETF or the NSIS WG thinks 3GPP should do things. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 12 03: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 DAA29109 for ; Thu, 12 Jun 2003 03:27:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5C7QYa25487 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 03:26:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C7QSm25463; Thu, 12 Jun 2003 03:26:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C7PHm25434 for ; Thu, 12 Jun 2003 03:25:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29057 for ; Thu, 12 Jun 2003 03:25:16 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QMQQ-0007Qf-00 for nsis@ietf.org; Thu, 12 Jun 2003 03:23:10 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19QMQP-0007Qc-00 for nsis@ietf.org; Thu, 12 Jun 2003 03:23:09 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5C7PEa13264 for ; Thu, 12 Jun 2003 10:25:14 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Jun 2003 10:25:14 +0300 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 12 Jun 2003 10:25:14 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 12 Jun 2003 10:25:07 +0300 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, 12 Jun 2003 10:25:07 +0300 Message-ID: Thread-Topic: Security Threats for NSIS & RSVP Security Properties documents Thread-Index: AcMgZFhYdpLzjoxwQ9SmD3nVdEaHcQQT1PIw To: , X-OriginalArrivalTime: 12 Jun 2003 07:25:07.0903 (UTC) FILETIME=[C03D54F0:01C330B3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5C7PIm25435 Subject: [NSIS] Security Threats for NSIS draft 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 Hannes, Any chance you'd get this submitted soon, I'd like to start WG call before Vienna. > Security Threats for NSIS > http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 12 03:41: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 DAA29401 for ; Thu, 12 Jun 2003 03:41:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5C7fEe27072 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 03:41:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C7f9m27063; Thu, 12 Jun 2003 03:41:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C7eqm27036 for ; Thu, 12 Jun 2003 03:40:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29379 for ; Thu, 12 Jun 2003 03:40:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QMfU-0007Wk-00 for nsis@ietf.org; Thu, 12 Jun 2003 03:38:44 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 19QMfT-0007Wh-00 for nsis@ietf.org; Thu, 12 Jun 2003 03:38:44 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id h5C7ent08567; Thu, 12 Jun 2003 09:40:49 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h5C7enC12315; Thu, 12 Jun 2003 09:40:49 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 09:40:48 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F036760E6@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'john.loughney@nokia.com'" , nsis@ietf.org Date: Thu, 12 Jun 2003 09:40:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] RE: Security Threats for NSIS draft 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 have asked a number of nsis members for their comments to this draft and to the rsvp security properties draft to get more feedback. i hope to receive some comments. i will incorporate them immediately. ciao hannes > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Thursday, June 12, 2003 9:25 AM > To: Tschofenig Hannes; nsis@ietf.org > Subject: Security Threats for NSIS draft > > > Hannes, > > Any chance you'd get this submitted soon, I'd like to start > WG call before Vienna. > > > Security Threats for NSIS > > http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt > > thanks, > John > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 12 05:18: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 FAA01481 for ; Thu, 12 Jun 2003 05:18:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5C9IQi02502 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 05:18:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C9IIm02483; Thu, 12 Jun 2003 05:18:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C9HMm02443 for ; Thu, 12 Jun 2003 05:17:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01453 for ; Thu, 12 Jun 2003 05:17:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QOAr-0000IL-00 for nsis@ietf.org; Thu, 12 Jun 2003 05:15:13 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19QOAr-0000Hx-00 for nsis@ietf.org; Thu, 12 Jun 2003 05:15:13 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 10:16:34 +0100 Message-ID: From: "Hancock, Robert" To: nsis@ietf.org Cc: "'john.loughney@nokia.com'" , mat@cisco.com Subject: RE: [NSIS] framework: proposal on fragmentation Date: Thu, 12 Jun 2003 10:16:29 +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 all, anyone who wants to propose f/w text on the big picture regarding mobility issues (or comment on the current text) is ***more*** than welcome. FWIW, my suspicion on the rapid handoff issues that mike mentions is that solutions will have to be based on state (and it doesn't matter if it is hard or soft or set up using a connectionless or connection-oriented protocol) being transferred within the network. This is not really a matter of message sizes, simply that authentication/authorisation actions can't be done at high enough speed within the network anyway. This means interacting somehow with a CT protocol, section 5.2.5. (In fact, there was a more detailed discussion in the previous version.) On the more general process point, my feeling is that at the moment we are not trying to set down the last word on what functionality is needed where, just trying to work out the best direction to set off in as the protocol work starts. I am pretty certain that some of the decisions we are making at the moment are wrong or missing details, we just don't know in what way; however, we need a starting point which isn't too influenced by solving only the immediate problems. Actually, the fragmentation issue doesn't seem like a particularly hard one, in that: *) we know there are good uses for certificates in authentication - and, more importantly authorisation - which are the hardest part of the NSIS problem space at the system level. We should do what we can to make these easy. *) the non-use of 2752 (or indeed 3182) doesn't tell us very much - maybe it isn't used because it makes messages too big... *) fragmentation/reassembly is not rocket science, and fragmentation IMHO is not a likely cause of processing overload *) there seems to be an obvious place to do it i'll try to send a summary of what i perceive as the current state of the argument shortly. cheers, robert h. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 12 June 2003 05:07 > To: mat@cisco.com; Lars.Westberg@era.ericsson.se > Cc: Ruediger.Geib@t-systems.com; nsis@ietf.org > Subject: RE: [NSIS] framework: proposal on fragmentation > > > Hi Michael, > > This is what should be, in general, captured in the > framework, i.e. - the big picture. > > John > > -----Original Message----- > > From: ext Michael Thomas [mailto:mat@cisco.com] > > Sent: 11 June, 2003 20:28 > > To: Lars.Westberg > > Cc: Geib, Ruediger; nsis@ietf.org > > Subject: Re: [NSIS] framework: proposal on fragmentation > > > > > > Lars.Westberg writes: > > > The generality of NTLP is a difficutl issue. My point is > that I can > > > forsee application that is so simple > > > that an UDP-style of operation is good enough. > > > > [] > > > > I really think it might be useful to take a more > > systemic look at things on all of these > > discussions. That is, what are we trying to use > > NSIS for, and what are the design constraints in > > that system. In isolation the notion of UDP-based > > communication is good since you don't need hard > > state, blah, blah, blah. My personal acid test is > > in the realm of mobility and handoffs: could an > > NSIS be used to gain favorable treatment of > > packets on a lossy and insecure medium where fast > > handoffs are necessary to keep connectivity? > > > > The two principle things that come to my mind are: > > > > 1) Security -- rationing a scarce resource > > 2) Speed -- completing the allocation in a timely > > fashion so as to be useful > > > > If either of these conditions are not met, then > > NSIS is likely to not be used, opting instead for > > the time-honored tradition of brute force and > > ignorance, or used in a way such that the setup > > time is not in the critical path. > > > > In this particular scenario, connectionless > > transport doesn't tell the whole story; the desire > > to have a command/response kind of 2 message > > protocol (on the first hop, that is) is an obvious > > win over needing to first need to create a > > session, but the access control aspect of (1) is a > > significant consideration as well. In particular, > > identity credentials have a tendency to be large, > > and CPU complexity especially for public key > > operations tends to be high. Both considerations > > push you in the direction of creating hard state > > of some kind (cf IKE main mode, TCP). At the very > > least, it's fairly obvious that any underlying > > transport which wants to use X.509 type identities > > is going to have to deal with the message > > fragmentation problem, and frankly IP-layer > > fragmentation is just a non-starter, IMO, if > > that's the norm. > > > > So in at least some of the interesting cases we > > know that we won't be able to have our coveted > > command/response protocol (assuming the MTU-pixie > > doesn't wave its wand over the Internet): three or > > more messages may be necessary. > > > > Which leads us to the next questions: > > > > 1) how interesting is this case? (ie, how likely) > > 2) does more than 2 messages in and of itself blow > > our time budget for (1) above? > > > > Neither are especially clear at this point: the > > deployed base of RSVP -- such as it is -- isn't > > using RFC 2752 identities that I'm aware of, so > > that's no help. Or maybe it's instructive... take > > your pick. And (2) is highly dependent on the air > > interface and its characteristics. For current 3G > > cellular just about anything beyond a single > > command and response for *everything* is likely to > > blow your time budget, and 802.11 while better > > isn't dramatically better. > > > > Which is to say, that it's not entirely clear that > > for, oh say, VoIP with current radio technologies > > intersected with access control requirements that > > this is going to work well enough during handoffs > > in the naive break-before-make handoff that's an > > unfortunate necessity. I'm sure somebody will find > > this debatable, but that's not really my point > > here. > > > > So, I'm not sure where I'm going with this except > > to try to ground these discussions into some sort > > of reality check of what we're trying to > > accomplish here. In my particular example, > > depending on how you tweak the parameters, > > connectionless establishment may be a large win, > > or it may be a non-starter. Also: if you believe > > that X.509 or other large byte identities are > > going to see widespread deployment for access > > control for wireless, then it's pretty much a > > given that we're going to need to deal with > > transport fragmentation in a sensible (read: > > non-L3) way. That in turn informs the debate > > whether fragmentation based on a non-threeway > > handshake protocol (tcp/sctp) is useful (or > > possible, some might argue). > > > > Finally, finesse is required here. It's easy to > > say that x.509 identities are required therefore > > fragmentation trumps all. That way lies insanity, > > IMO. We have to be careful to not overengineer > > solutions for marginal problems. The track record > > of PKI deployment is not good, so it's probably > > wise to consider the case where it is not part of > > the solution and provide optimization around that > > design criteria. > > > > Which is why I'm muddled about this. > > > > Mike > > > > _______________________________________________ > > 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 Jun 12 05:22: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 FAA01556 for ; Thu, 12 Jun 2003 05:22:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5C9MCx02736 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 05:22:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C9M2m02719; Thu, 12 Jun 2003 05:22:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C9LUm02695 for ; Thu, 12 Jun 2003 05:21:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01533 for ; Thu, 12 Jun 2003 05:21:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QOEr-0000K5-00 for nsis@ietf.org; Thu, 12 Jun 2003 05:19:21 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19QOEr-0000K2-00 for nsis@ietf.org; Thu, 12 Jun 2003 05:19:21 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 10:21:26 +0100 Message-ID: From: "Hancock, Robert" To: "'nsis@ietf.org'" Date: Thu, 12 Jun 2003 10:21:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] attempted summary of fragmentation discussion 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, in attempting to summarise where we are so far, this is what i think the situation is: 1) no-one really likes relying on IP fragmentation 2) no-one wants to force all responsibility into the NSLPs 3) everyone [almost?] is happy with the NTLP doing fragmentation as a default 4) there is a proposal to make it possible to signal the NTLP not to do fragmentation and have the NSLP do it (in some still-to-be-defined way) personally, i fail to see the benefit of (4) over (3), which may be a symptom of a deeper problem (with me or the proposal). however, i believe it is not ruled out even if we used as an initial position: *) make the NTLP do fragmentation when it is needed; ideally, do it in such a way that reassembly is only needed at the receiving NSLP. in later stages of the protocol work, and after some experience with applications, we could presumably "enhance" the NTLP in the direction of option 4, i.e. give it the ability not to do fragmentation as well. after all, this would appear to be an intrinsically backwards compatible extension. have i missed anything? robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 12 05:58: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 FAA02043 for ; Thu, 12 Jun 2003 05:58:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5C9wEa04682 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 05:58:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C9wAm04672; Thu, 12 Jun 2003 05:58:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5C9v5m04612 for ; Thu, 12 Jun 2003 05:57:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02014 for ; Thu, 12 Jun 2003 05:57:01 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QOnI-0000RD-00 for nsis@ietf.org; Thu, 12 Jun 2003 05:54:56 -0400 Received: from alc240.alcatel.be ([195.207.101.240] helo=bt0rjw.god.bel.alcatel.be) by ietf-mx with esmtp (Exim 4.12) id 19QOnH-0000R7-00 for nsis@ietf.org; Thu, 12 Jun 2003 05:54:55 -0400 Received: from bemail04.net.alcatel.be (bemail04.net.alcatel.be [138.203.144.6]) by bt0rjw.god.bel.alcatel.be (8.12.9/8.11.4) with ESMTP id h5C9uM3W002192; Thu, 12 Jun 2003 11:56:27 +0200 (MEST) Subject: Re: [NSIS] attempted summary of fragmentation discussion To: "Hancock, Robert" Cc: "'nsis@ietf.org'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 12 Jun 2003 11:56:19 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 06/12/2003 11:56:26 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 Robert, all, I have followed this thread from a slight distance so I might have missed something obvious but I am wondering about the following issue: if someone wants to do fragmentation in his or her NSLP instead of in the NTLP, why does it have to be signalled to the NTLP? In order to do a good job, the NSLP would need to know the MTU of the path to the next NSLP-aware entity and would then need to make the message parts it sends small enough. I would say it is completely transparant to the NTLP which, if the NSLP has done its job properly, will not need to fragment anymore. But it doesn't need to be told that. Sven "Hancock, Robert" @ietf.org on 12/06/2003 11:21:26 Sent by: nsis-admin@ietf.org To: "'nsis@ietf.org'" cc: Subject: [NSIS] attempted summary of fragmentation discussion dear all, in attempting to summarise where we are so far, this is what i think the situation is: 1) no-one really likes relying on IP fragmentation 2) no-one wants to force all responsibility into the NSLPs 3) everyone [almost?] is happy with the NTLP doing fragmentation as a default 4) there is a proposal to make it possible to signal the NTLP not to do fragmentation and have the NSLP do it (in some still-to-be-defined way) personally, i fail to see the benefit of (4) over (3), which may be a symptom of a deeper problem (with me or the proposal). however, i believe it is not ruled out even if we used as an initial position: *) make the NTLP do fragmentation when it is needed; ideally, do it in such a way that reassembly is only needed at the receiving NSLP. in later stages of the protocol work, and after some experience with applications, we could presumably "enhance" the NTLP in the direction of option 4, i.e. give it the ability not to do fragmentation as well. after all, this would appear to be an intrinsically backwards compatible extension. have i missed anything? 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 Thu Jun 12 06:07: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 GAA02168 for ; Thu, 12 Jun 2003 06:07:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CA7DH05489 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 06:07:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CA74m05138; Thu, 12 Jun 2003 06:07:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CA6Om04970 for ; Thu, 12 Jun 2003 06:06:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02158 for ; Thu, 12 Jun 2003 06:06:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QOwJ-0000Sy-00 for nsis@ietf.org; Thu, 12 Jun 2003 06:04:15 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19QOwJ-0000Sv-00 for nsis@ietf.org; Thu, 12 Jun 2003 06:04:15 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 11:06:21 +0100 Message-ID: From: "Hancock, Robert" To: "'sven.van_den_bosch@alcatel.be'" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] attempted summary of fragmentation discussion Date: Thu, 12 Jun 2003 11:06: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 sven, i think what you say is correct - if a message doesn't need fragmenting, then the NTLP doesn't need to be told not to do it. this is part of my overall confusion about option 4. the missing part of the picture for option 4 is how the originating NSLP does the MTU discovery, which is a non-trivial question which there seems to be some resistance to addressing. robert h. > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: 12 June 2003 10:56 > To: Hancock, Robert > Cc: 'nsis@ietf.org' > Subject: Re: [NSIS] attempted summary of fragmentation discussion > > > Hi Robert, all, > > I have followed this thread from a slight distance so I might > have missed > something obvious but I am wondering about the following > issue: if someone > wants to do fragmentation in his or her NSLP instead of in > the NTLP, why > does it have to be signalled to the NTLP? In order to do a > good job, the > NSLP would need to know the MTU of the path to the next > NSLP-aware entity > and would then need to make the message parts it sends small enough. I > would say it is completely transparant to the NTLP which, if > the NSLP has > done its job properly, will not need to fragment anymore. But > it doesn't > need to be told that. > > Sven > > > > > > "Hancock, Robert" @ietf.org on 12/06/2003 > 11:21:26 > > Sent by: nsis-admin@ietf.org > > > To: "'nsis@ietf.org'" > cc: > Subject: [NSIS] attempted summary of fragmentation discussion > > > dear all, > > in attempting to summarise where we are so far, this is what > i think the > situation is: > > 1) no-one really likes relying on IP fragmentation > 2) no-one wants to force all responsibility into the NSLPs > 3) everyone [almost?] is happy with the NTLP doing fragmentation as a > default > 4) there is a proposal to make it possible to signal the NTLP > not to do > fragmentation and have the NSLP do it (in some > still-to-be-defined way) > > personally, i fail to see the benefit of (4) over (3), which may be a > symptom of a deeper problem (with me or the proposal). > > however, i believe it is not ruled out even if we used as an initial > position: > *) make the NTLP do fragmentation when it is needed; ideally, > do it in such > a way that reassembly is only needed at the receiving NSLP. > > in later stages of the protocol work, and after some experience with > applications, we could presumably "enhance" the NTLP in the > direction of > option 4, i.e. give it the ability not to do fragmentation as > well. after > all, this would appear to be an intrinsically backwards compatible > extension. > > have i missed anything? > > 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 Thu Jun 12 06: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 GAA02628 for ; Thu, 12 Jun 2003 06:35:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CAYZb06929 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 06:34:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CAYNm06920; Thu, 12 Jun 2003 06:34:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CAXkm06902 for ; Thu, 12 Jun 2003 06:33:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02616 for ; Thu, 12 Jun 2003 06:33:42 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QPMn-0000Xu-00 for nsis@ietf.org; Thu, 12 Jun 2003 06:31:37 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19QPMm-0000Xr-00 for nsis@ietf.org; Thu, 12 Jun 2003 06:31:36 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5CAXga27570 for ; Thu, 12 Jun 2003 13:33:42 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 12 Jun 2003 13:33:41 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 12 Jun 2003 13:33:41 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 12 Jun 2003 13:33:40 +0300 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, 12 Jun 2003 13:33:39 +0300 Message-ID: Thread-Topic: Security Threats for NSIS draft Thread-Index: AcMwtp0IO/wQRtJVSJuIqptTVepFygAF15EQ To: , X-OriginalArrivalTime: 12 Jun 2003 10:33:40.0560 (UTC) FILETIME=[171BCD00:01C330CE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5CAXkm06903 Subject: [NSIS] RE: Security Threats for NSIS draft 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 have asked a number of nsis members for their comments to this draft and > to the rsvp security properties draft to get more feedback. i hope to > receive some comments. i will incorporate them immediately. If you don't hear back from them in a timely manner, it would probably be good to update the document anyway & log their comments in WG last call. thanks, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 12 06:56: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 GAA02969 for ; Thu, 12 Jun 2003 06:56:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CAuIo08571 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 06:56:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CAu5m08547; Thu, 12 Jun 2003 06:56:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CAt3m08498 for ; Thu, 12 Jun 2003 06:55:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02929 for ; Thu, 12 Jun 2003 06:54:58 -0400 (EDT) From: sven.van_den_bosch@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QPhN-0000c4-00 for nsis@ietf.org; Thu, 12 Jun 2003 06:52:53 -0400 Received: from alc240.alcatel.be ([195.207.101.240] helo=bt0rjw.god.bel.alcatel.be) by ietf-mx with esmtp (Exim 4.12) id 19QPhN-0000bj-00 for nsis@ietf.org; Thu, 12 Jun 2003 06:52:53 -0400 Received: from bemail04.net.alcatel.be (bemail04.net.alcatel.be [138.203.144.6]) by bt0rjw.god.bel.alcatel.be (8.12.9/8.11.4) with ESMTP id h5CAsO3W006823 for ; Thu, 12 Jun 2003 12:54:24 +0200 (MEST) Subject: RE: [NSIS] attempted summary of fragmentation discussion To: "Hancock, Robert" Cc: "'nsis@ietf.org'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Thu, 12 Jun 2003 12:54:14 +0200 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 06/12/2003 12:54:23 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 Robert, OK. Then I guess this means three things: - NTLP needs to support fragmentation (for the NSLPs that don't want to do it) - NTLP does not need anything else to support option 4. I guess we could add a sentence saying that NSLP is allowed to do its own fragmentation but that this is transparant to NTLP - NSLPs seeking to do fragmentation themselves need to address the MTU discovery issue. Is this a reasonable position for the framework to take? Sven "Hancock, Robert" on 12/06/2003 12:06:21 To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL cc: "'nsis@ietf.org'" Subject: RE: [NSIS] attempted summary of fragmentation discussion hi sven, i think what you say is correct - if a message doesn't need fragmenting, then the NTLP doesn't need to be told not to do it. this is part of my overall confusion about option 4. the missing part of the picture for option 4 is how the originating NSLP does the MTU discovery, which is a non-trivial question which there seems to be some resistance to addressing. robert h. > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: 12 June 2003 10:56 > To: Hancock, Robert > Cc: 'nsis@ietf.org' > Subject: Re: [NSIS] attempted summary of fragmentation discussion > > > Hi Robert, all, > > I have followed this thread from a slight distance so I might > have missed > something obvious but I am wondering about the following > issue: if someone > wants to do fragmentation in his or her NSLP instead of in > the NTLP, why > does it have to be signalled to the NTLP? In order to do a > good job, the > NSLP would need to know the MTU of the path to the next > NSLP-aware entity > and would then need to make the message parts it sends small enough. I > would say it is completely transparant to the NTLP which, if > the NSLP has > done its job properly, will not need to fragment anymore. But > it doesn't > need to be told that. > > Sven > > > > > > "Hancock, Robert" @ietf.org on 12/06/2003 > 11:21:26 > > Sent by: nsis-admin@ietf.org > > > To: "'nsis@ietf.org'" > cc: > Subject: [NSIS] attempted summary of fragmentation discussion > > > dear all, > > in attempting to summarise where we are so far, this is what > i think the > situation is: > > 1) no-one really likes relying on IP fragmentation > 2) no-one wants to force all responsibility into the NSLPs > 3) everyone [almost?] is happy with the NTLP doing fragmentation as a > default > 4) there is a proposal to make it possible to signal the NTLP > not to do > fragmentation and have the NSLP do it (in some > still-to-be-defined way) > > personally, i fail to see the benefit of (4) over (3), which may be a > symptom of a deeper problem (with me or the proposal). > > however, i believe it is not ruled out even if we used as an initial > position: > *) make the NTLP do fragmentation when it is needed; ideally, > do it in such > a way that reassembly is only needed at the receiving NSLP. > > in later stages of the protocol work, and after some experience with > applications, we could presumably "enhance" the NTLP in the > direction of > option 4, i.e. give it the ability not to do fragmentation as > well. after > all, this would appear to be an intrinsically backwards compatible > extension. > > have i missed anything? > > robert h. > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > > > -- Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, Berkshire. RG12 8FZ The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 12 07: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 HAA03174 for ; Thu, 12 Jun 2003 07:04:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CB4M508949 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 07:04:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CB4Am08935; Thu, 12 Jun 2003 07:04:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CB3im08896 for ; Thu, 12 Jun 2003 07:03:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03152 for ; Thu, 12 Jun 2003 07:03:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QPpn-0000ev-00 for nsis@ietf.org; Thu, 12 Jun 2003 07:01:35 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19QPpm-0000eo-00 for nsis@ietf.org; Thu, 12 Jun 2003 07:01:34 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 12:03:10 +0100 Message-ID: From: "Hancock, Robert" To: "'sven.van_den_bosch@alcatel.be'" Cc: "'nsis@ietf.org'" Subject: RE: [NSIS] attempted summary of fragmentation discussion Date: Thu, 12 Jun 2003 12:03: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 sven, i agree with your first two points. at the moment, i am not sure on the justification for the third and so would prefer to defer it - it sounds like feature-itis to me. r. > -----Original Message----- > From: sven.van_den_bosch@alcatel.be > [mailto:sven.van_den_bosch@alcatel.be] > Sent: 12 June 2003 11:54 > To: Hancock, Robert > Cc: 'nsis@ietf.org' > Subject: RE: [NSIS] attempted summary of fragmentation discussion > > > Hi Robert, > > OK. Then I guess this means three things: > - NTLP needs to support fragmentation (for the NSLPs that > don't want to do > it) > - NTLP does not need anything else to support option 4. I > guess we could > add a sentence saying that NSLP is allowed to do its own > fragmentation but > that this is transparant to NTLP > - NSLPs seeking to do fragmentation themselves need to address the MTU > discovery issue. > > Is this a reasonable position for the framework to take? > Sven > > > > > > "Hancock, Robert" on 12/06/2003 12:06:21 > > To: Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL > cc: "'nsis@ietf.org'" > Subject: RE: [NSIS] attempted summary of fragmentation discussion > > > hi sven, > > i think what you say is correct - if a message doesn't need > fragmenting, > then the NTLP doesn't need to be told not to do it. this is part of my > overall confusion about option 4. > > the missing part of the picture for option 4 is how the > originating NSLP > does the MTU discovery, which is a non-trivial question which > there seems > to be some resistance to addressing. > > robert h. > > > -----Original Message----- > > From: sven.van_den_bosch@alcatel.be > > [mailto:sven.van_den_bosch@alcatel.be] > > Sent: 12 June 2003 10:56 > > To: Hancock, Robert > > Cc: 'nsis@ietf.org' > > Subject: Re: [NSIS] attempted summary of fragmentation discussion > > > > > > Hi Robert, all, > > > > I have followed this thread from a slight distance so I might > > have missed > > something obvious but I am wondering about the following > > issue: if someone > > wants to do fragmentation in his or her NSLP instead of in > > the NTLP, why > > does it have to be signalled to the NTLP? In order to do a > > good job, the > > NSLP would need to know the MTU of the path to the next > > NSLP-aware entity > > and would then need to make the message parts it sends > small enough. I > > would say it is completely transparant to the NTLP which, if > > the NSLP has > > done its job properly, will not need to fragment anymore. But > > it doesn't > > need to be told that. > > > > Sven > > > > > > > > > > > > "Hancock, Robert" @ietf.org on 12/06/2003 > > 11:21:26 > > > > Sent by: nsis-admin@ietf.org > > > > > > To: "'nsis@ietf.org'" > > cc: > > Subject: [NSIS] attempted summary of fragmentation discussion > > > > > > dear all, > > > > in attempting to summarise where we are so far, this is what > > i think the > > situation is: > > > > 1) no-one really likes relying on IP fragmentation > > 2) no-one wants to force all responsibility into the NSLPs > > 3) everyone [almost?] is happy with the NTLP doing > fragmentation as a > > default > > 4) there is a proposal to make it possible to signal the NTLP > > not to do > > fragmentation and have the NSLP do it (in some > > still-to-be-defined way) > > > > personally, i fail to see the benefit of (4) over (3), > which may be a > > symptom of a deeper problem (with me or the proposal). > > > > however, i believe it is not ruled out even if we used as an initial > > position: > > *) make the NTLP do fragmentation when it is needed; ideally, > > do it in such > > a way that reassembly is only needed at the receiving NSLP. > > > > in later stages of the protocol work, and after some experience with > > applications, we could presumably "enhance" the NTLP in the > > direction of > > option 4, i.e. give it the ability not to do fragmentation as > > well. after > > all, this would appear to be an intrinsically backwards compatible > > extension. > > > > have i missed anything? > > > > robert h. > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > > > > -- > Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, > Bracknell, > Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments is > confidential to > Roke Manor Research Ltd and must not be passed to any third > party without > permission. This communication is for information only and > shall not create > or > change any contractual relationship. > > > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 12 07:39: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 HAA04287 for ; Thu, 12 Jun 2003 07:39:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CBcVH12091 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 07:38:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CBcPm12083; Thu, 12 Jun 2003 07:38:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CBb2m11252 for ; Thu, 12 Jun 2003 07:37:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04245 for ; Thu, 12 Jun 2003 07:37:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QQM2-0000py-00 for nsis@ietf.org; Thu, 12 Jun 2003 07:34:54 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19QQM2-0000pt-00 for nsis@ietf.org; Thu, 12 Jun 2003 07:34:54 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h5CBavCf013786; Thu, 12 Jun 2003 13:36:57 +0200 (MET DST) Message-ID: <004d01c330d6$ef4ef690$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" , References: Subject: Re: [NSIS] attempted summary of fragmentation discussion Date: Thu, 12 Jun 2003 13:36:57 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Robert Please combine (3) and (4) in a more strict way! Best regards, Georgios ----- Original Message ----- From: "Hancock, Robert" To: Sent: Thursday, June 12, 2003 11:21 AM Subject: [NSIS] attempted summary of fragmentation discussion > dear all, > > in attempting to summarise where we are so far, this is what i think the > situation is: > > 1) no-one really likes relying on IP fragmentation > 2) no-one wants to force all responsibility into the NSLPs > 3) everyone [almost?] is happy with the NTLP doing fragmentation as a > default > 4) there is a proposal to make it possible to signal the NTLP not to do > fragmentation and have the NSLP do it (in some still-to-be-defined way) > > personally, i fail to see the benefit of (4) over (3), which may be a > symptom of a deeper problem (with me or the proposal). > > however, i believe it is not ruled out even if we used as an initial > position: > *) make the NTLP do fragmentation when it is needed; ideally, do it in such > a way that reassembly is only needed at the receiving NSLP. > > in later stages of the protocol work, and after some experience with > applications, we could presumably "enhance" the NTLP in the direction of > option 4, i.e. give it the ability not to do fragmentation as well. after > all, this would appear to be an intrinsically backwards compatible > extension. > > have i missed anything? > > 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 Thu Jun 12 07:52: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 HAA05008 for ; Thu, 12 Jun 2003 07:52:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CBqFR12748 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 07:52:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CBqAm12740; Thu, 12 Jun 2003 07:52:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CBpJm12702 for ; Thu, 12 Jun 2003 07:51:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04956 for ; Thu, 12 Jun 2003 07:51:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QQZr-00012N-00 for nsis@ietf.org; Thu, 12 Jun 2003 07:49:11 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19QQZr-00012C-00 for nsis@ietf.org; Thu, 12 Jun 2003 07:49:11 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 12:50:47 +0100 Message-ID: From: "Hancock, Robert" To: "'Georgios Karagiannis'" , nsis@ietf.org Subject: RE: [NSIS] attempted summary of fragmentation discussion Date: Thu, 12 Jun 2003 12:50:44 +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, how and why? i.e. it would be helpful (at least to me) if you could a) define (4) in a bit more detail about how the layers and nodes would interact to achieve it, and b) explain why this functionality would justify the additional complexity. cheers, r. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 12 June 2003 12:37 > To: Hancock, Robert; nsis@ietf.org > Subject: Re: [NSIS] attempted summary of fragmentation discussion > > > Hi Robert > > Please combine (3) and (4) in a more strict way! > > Best regards, > Georgios > ----- Original Message ----- > From: "Hancock, Robert" > To: > Sent: Thursday, June 12, 2003 11:21 AM > Subject: [NSIS] attempted summary of fragmentation discussion > > > > dear all, > > > > in attempting to summarise where we are so far, this is > what i think the > > situation is: > > > > 1) no-one really likes relying on IP fragmentation > > 2) no-one wants to force all responsibility into the NSLPs > > 3) everyone [almost?] is happy with the NTLP doing > fragmentation as a > > default > > 4) there is a proposal to make it possible to signal the > NTLP not to do > > fragmentation and have the NSLP do it (in some > still-to-be-defined way) > > > > personally, i fail to see the benefit of (4) over (3), > which may be a > > symptom of a deeper problem (with me or the proposal). > > > > however, i believe it is not ruled out even if we used as an initial > > position: > > *) make the NTLP do fragmentation when it is needed; > ideally, do it in > such > > a way that reassembly is only needed at the receiving NSLP. > > > > in later stages of the protocol work, and after some experience with > > applications, we could presumably "enhance" the NTLP in the > direction of > > option 4, i.e. give it the ability not to do fragmentation > as well. after > > all, this would appear to be an intrinsically backwards compatible > > extension. > > > > have i missed anything? > > > > 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 Thu Jun 12 08:04: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 IAA05440 for ; Thu, 12 Jun 2003 08:04:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CC4Qa13326 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 08:04:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CC4Gm13295; Thu, 12 Jun 2003 08:04:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CC31m13249 for ; Thu, 12 Jun 2003 08:03:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05354 for ; Thu, 12 Jun 2003 08:02:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QQlB-000190-00 for nsis@ietf.org; Thu, 12 Jun 2003 08:00:53 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19QQlA-00018x-00 for nsis@ietf.org; Thu, 12 Jun 2003 08:00:52 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h5CC2uCf015003; Thu, 12 Jun 2003 14:02:56 +0200 (MET DST) Message-ID: <008501c330da$90ce5170$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" , References: Subject: Re: [NSIS] attempted summary of fragmentation discussion Date: Thu, 12 Jun 2003 14:02:58 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Robert I proposed many solutions to this in previous e-mails. The main advantage of having this feature is that the performance of the node in terms of processing delays will be enhanced when the node does not have to perform fragmentation. Best regards, Georgios ----- Original Message ----- From: "Hancock, Robert" To: "'Georgios Karagiannis'" ; Sent: Thursday, June 12, 2003 1:50 PM Subject: RE: [NSIS] attempted summary of fragmentation discussion > hi georgios, > > how and why? > > i.e. it would be helpful (at least to me) if you could > a) define (4) in a bit more detail about how the layers and nodes would > interact to achieve it, and > b) explain why this functionality would justify the additional complexity. > > cheers, > > r. > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 12 June 2003 12:37 > > To: Hancock, Robert; nsis@ietf.org > > Subject: Re: [NSIS] attempted summary of fragmentation discussion > > > > > > Hi Robert > > > > Please combine (3) and (4) in a more strict way! > > > > Best regards, > > Georgios > > ----- Original Message ----- > > From: "Hancock, Robert" > > To: > > Sent: Thursday, June 12, 2003 11:21 AM > > Subject: [NSIS] attempted summary of fragmentation discussion > > > > > > > dear all, > > > > > > in attempting to summarise where we are so far, this is > > what i think the > > > situation is: > > > > > > 1) no-one really likes relying on IP fragmentation > > > 2) no-one wants to force all responsibility into the NSLPs > > > 3) everyone [almost?] is happy with the NTLP doing > > fragmentation as a > > > default > > > 4) there is a proposal to make it possible to signal the > > NTLP not to do > > > fragmentation and have the NSLP do it (in some > > still-to-be-defined way) > > > > > > personally, i fail to see the benefit of (4) over (3), > > which may be a > > > symptom of a deeper problem (with me or the proposal). > > > > > > however, i believe it is not ruled out even if we used as an initial > > > position: > > > *) make the NTLP do fragmentation when it is needed; > > ideally, do it in > > such > > > a way that reassembly is only needed at the receiving NSLP. > > > > > > in later stages of the protocol work, and after some experience with > > > applications, we could presumably "enhance" the NTLP in the > > direction of > > > option 4, i.e. give it the ability not to do fragmentation > > as well. after > > > all, this would appear to be an intrinsically backwards compatible > > > extension. > > > > > > have i missed anything? > > > > > > robert h. > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > -- > Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, > Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments is confidential to > Roke Manor Research Ltd and must not be passed to any third party without > permission. This communication is for information only and shall not create or > change any contractual relationship. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 12 08:18: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 IAA06456 for ; Thu, 12 Jun 2003 08:18:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CCI2C14909 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 08:18:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CCHvm14893; Thu, 12 Jun 2003 08:17:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CCFgm14757 for ; Thu, 12 Jun 2003 08:15:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06334 for ; Thu, 12 Jun 2003 08:15:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QQxR-0001Ru-00 for nsis@ietf.org; Thu, 12 Jun 2003 08:13:33 -0400 Received: from infres.enst.fr ([137.194.160.3]) by ietf-mx with esmtp (Exim 4.12) id 19QQxQ-0001RU-00 for nsis@ietf.org; Thu, 12 Jun 2003 08:13:32 -0400 Received: from luu (dhcp7-211.enst.fr [137.194.7.211]) by infres.enst.fr (Postfix) with SMTP id 5C5B9190E for ; Thu, 12 Jun 2003 14:15:36 +0200 (MEST) Message-ID: <007a01c330dc$95362d80$d307c289@enst.fr> From: "Thanh Tra LUU" To: References: <004d01c330d6$ef4ef690$4c0d5982@dynamic.cs.utwente.nl> Subject: Re: [NSIS] attempted summary of fragmentation discussion Date: Thu, 12 Jun 2003 14:17:24 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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 Georgios, I think NSLP/NTLP must be well-designed because they would be the generic signaling protocols and what we do now will get important consequences in the future. But it does not mean we permit these protocols to do all possibilities. If they're too complicated and too heavy, no one uses it. A day when someone apply these protocols, they know how to use the functions of these protocols for their purposes. Regards. Nary Tra ENST, Paris ----- Original Message ----- From: "Georgios Karagiannis" To: "Hancock, Robert" ; Sent: Thursday, June 12, 2003 1:36 PM Subject: Re: [NSIS] attempted summary of fragmentation discussion > Hi Robert > > Please combine (3) and (4) in a more strict way! > > Best regards, > Georgios > ----- Original Message ----- > From: "Hancock, Robert" > To: > Sent: Thursday, June 12, 2003 11:21 AM > Subject: [NSIS] attempted summary of fragmentation discussion > > > > dear all, > > > > in attempting to summarise where we are so far, this is what i think the > > situation is: > > > > 1) no-one really likes relying on IP fragmentation > > 2) no-one wants to force all responsibility into the NSLPs > > 3) everyone [almost?] is happy with the NTLP doing fragmentation as a > > default > > 4) there is a proposal to make it possible to signal the NTLP not to do > > fragmentation and have the NSLP do it (in some still-to-be-defined way) > > > > personally, i fail to see the benefit of (4) over (3), which may be a > > symptom of a deeper problem (with me or the proposal). > > > > however, i believe it is not ruled out even if we used as an initial > > position: > > *) make the NTLP do fragmentation when it is needed; ideally, do it in > such > > a way that reassembly is only needed at the receiving NSLP. > > > > in later stages of the protocol work, and after some experience with > > applications, we could presumably "enhance" the NTLP in the direction of > > option 4, i.e. give it the ability not to do fragmentation as well. after > > all, this would appear to be an intrinsically backwards compatible > > extension. > > > > have i missed anything? > > > > 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 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 12 08:18: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 IAA06471 for ; Thu, 12 Jun 2003 08:18:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CCI5t14923 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 08:18:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CCHum14878; Thu, 12 Jun 2003 08:17:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CCFem14751 for ; Thu, 12 Jun 2003 08:15:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06327 for ; Thu, 12 Jun 2003 08:15:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QQxP-0001Re-00 for nsis@ietf.org; Thu, 12 Jun 2003 08:13:32 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19QQxO-0001QG-00 for nsis@ietf.org; Thu, 12 Jun 2003 08:13:30 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5CCEvVI082151; Thu, 12 Jun 2003 14:14:57 +0200 (CEST) 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 11698AAA0C; Thu, 12 Jun 2003 14:01:38 +0200 (CEST) Date: Thu, 12 Jun 2003 14:14:59 +0200 From: Marcus Brunner Reply-To: Marcus Brunner To: "Hancock, Robert" , "'Georgios Karagiannis'" Cc: nsis@ietf.org Subject: RE: [NSIS] attempted summary of fragmentation discussion Message-ID: <13363035.1055427299@[10.1.1.130]> In-Reply-To: References: X-Mailer: Mulberry/3.0.2 (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 think a possible way is as in v4 set the Don't fragment bit. If fragmentation occurs get an error back. It would be the task of the NSLP to detect the possible MTU size. What I have not hear so far is the cost of having fragmentation built into NTLP. Georgios and myself are concerned that the NTLP gets too fat for high-speed processing, so we try to avoid to design for the rare cases such as fragmentation. Marcus --On Donnerstag, 12. Juni 2003 12:50 +0100 "Hancock, Robert" wrote: > hi georgios, > > how and why? > > i.e. it would be helpful (at least to me) if you could > a) define (4) in a bit more detail about how the layers and nodes would > interact to achieve it, and > b) explain why this functionality would justify the additional complexity. > > cheers, > > r. > >> -----Original Message----- >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> Sent: 12 June 2003 12:37 >> To: Hancock, Robert; nsis@ietf.org >> Subject: Re: [NSIS] attempted summary of fragmentation discussion >> >> >> Hi Robert >> >> Please combine (3) and (4) in a more strict way! >> >> Best regards, >> Georgios >> ----- Original Message ----- >> From: "Hancock, Robert" >> To: >> Sent: Thursday, June 12, 2003 11:21 AM >> Subject: [NSIS] attempted summary of fragmentation discussion >> >> >> > dear all, >> > >> > in attempting to summarise where we are so far, this is >> what i think the >> > situation is: >> > >> > 1) no-one really likes relying on IP fragmentation >> > 2) no-one wants to force all responsibility into the NSLPs >> > 3) everyone [almost?] is happy with the NTLP doing >> fragmentation as a >> > default >> > 4) there is a proposal to make it possible to signal the >> NTLP not to do >> > fragmentation and have the NSLP do it (in some >> still-to-be-defined way) >> > >> > personally, i fail to see the benefit of (4) over (3), >> which may be a >> > symptom of a deeper problem (with me or the proposal). >> > >> > however, i believe it is not ruled out even if we used as an initial >> > position: >> > *) make the NTLP do fragmentation when it is needed; >> ideally, do it in >> such >> > a way that reassembly is only needed at the receiving NSLP. >> > >> > in later stages of the protocol work, and after some experience with >> > applications, we could presumably "enhance" the NTLP in the >> direction of >> > option 4, i.e. give it the ability not to do fragmentation >> as well. after >> > all, this would appear to be an intrinsically backwards compatible >> > extension. >> > >> > have i missed anything? >> > >> > 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 -------------------------------------- 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 Mobile: +49 (0) 163 275 17 43 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 Thu Jun 12 08:50: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 IAA08625 for ; Thu, 12 Jun 2003 08:50:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CCoNa17696 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 08:50:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CCoIm17657; Thu, 12 Jun 2003 08:50:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CCk4m17341 for ; Thu, 12 Jun 2003 08:46:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08120 for ; Thu, 12 Jun 2003 08:46:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QRQp-0001ws-00 for nsis@ietf.org; Thu, 12 Jun 2003 08:43:55 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19QRQo-0001w5-00 for nsis@ietf.org; Thu, 12 Jun 2003 08:43:54 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5CCiqVI084707; Thu, 12 Jun 2003 14:44:52 +0200 (CEST) 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 1147CA2BBA; Thu, 12 Jun 2003 14:31:33 +0200 (CEST) Date: Thu, 12 Jun 2003 14:44:55 +0200 From: Marcus Brunner Reply-To: Marcus Brunner To: Thanh Tra LUU Cc: nsis@ietf.org Subject: Re: [NSIS] attempted summary of fragmentation discussion Message-ID: <15158416.1055429095@[10.1.1.130]> In-Reply-To: <007a01c330dc$95362d80$d307c289@enst.fr> References: <004d01c330d6$ef4ef690$4c0d5982@dynamic.cs.utwente.nl> <007a01c330dc$95362d80$d307c289@enst.fr> X-Mailer: Mulberry/3.0.2 (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 Georgios is trying to do exactly try to reduce the complexity. Marcus --On Donnerstag, 12. Juni 2003 14:17 +0200 Thanh Tra LUU wrote: > Hi Georgios, > > I think NSLP/NTLP must be well-designed because they would be the generic > signaling protocols and what we do now will get important consequences in > the future. But it does not mean we permit these protocols to do all > possibilities. If they're too complicated and too heavy, no one uses it. A > day when someone apply these protocols, they know how to use the functions > of these protocols for their purposes. > > Regards. > > Nary Tra > ENST, Paris > > > ----- Original Message ----- > From: "Georgios Karagiannis" > To: "Hancock, Robert" ; > Sent: Thursday, June 12, 2003 1:36 PM > Subject: Re: [NSIS] attempted summary of fragmentation discussion > > >> Hi Robert >> >> Please combine (3) and (4) in a more strict way! >> >> Best regards, >> Georgios >> ----- Original Message ----- >> From: "Hancock, Robert" >> To: >> Sent: Thursday, June 12, 2003 11:21 AM >> Subject: [NSIS] attempted summary of fragmentation discussion >> >> >> > dear all, >> > >> > in attempting to summarise where we are so far, this is what i think >> > the situation is: >> > >> > 1) no-one really likes relying on IP fragmentation >> > 2) no-one wants to force all responsibility into the NSLPs >> > 3) everyone [almost?] is happy with the NTLP doing fragmentation as a >> > default >> > 4) there is a proposal to make it possible to signal the NTLP not to do >> > fragmentation and have the NSLP do it (in some still-to-be-defined way) >> > >> > personally, i fail to see the benefit of (4) over (3), which may be a >> > symptom of a deeper problem (with me or the proposal). >> > >> > however, i believe it is not ruled out even if we used as an initial >> > position: >> > *) make the NTLP do fragmentation when it is needed; ideally, do it in >> such >> > a way that reassembly is only needed at the receiving NSLP. >> > >> > in later stages of the protocol work, and after some experience with >> > applications, we could presumably "enhance" the NTLP in the direction >> > of option 4, i.e. give it the ability not to do fragmentation as well. > after >> > all, this would appear to be an intrinsically backwards compatible >> > extension. >> > >> > have i missed anything? >> > >> > 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 >> > > _______________________________________________ > 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 Mobile: +49 (0) 163 275 17 43 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 Thu Jun 12 09: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 JAA09740 for ; Thu, 12 Jun 2003 09:29:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CDTEm20818 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 09:29:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CDTBm20792; Thu, 12 Jun 2003 09:29:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CDSDm20751 for ; Thu, 12 Jun 2003 09:28:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09704 for ; Thu, 12 Jun 2003 09:28:10 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QS5d-0002L7-00 for nsis@ietf.org; Thu, 12 Jun 2003 09:26:05 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19QS5c-0002L3-00 for nsis@ietf.org; Thu, 12 Jun 2003 09:26:04 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5CDSAa19843 for ; Thu, 12 Jun 2003 16:28:10 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 12 Jun 2003 16:28:10 +0300 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 12 Jun 2003 16:28:10 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 12 Jun 2003 16:28:09 +0300 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, 12 Jun 2003 16:28:07 +0300 Message-ID: Thread-Topic: [NSIS] attempted summary of fragmentation discussion Thread-Index: AcMw3LYjh5w7ic9LSYq7dkBkIij/dAABchYA To: X-OriginalArrivalTime: 12 Jun 2003 13:28:09.0856 (UTC) FILETIME=[774B9800:01C330E6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5CDSDm20752 Subject: [NSIS] How to move forward on the Fragmentation issue 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, First off, let's stick to fragmentation. Message bundling is another topic. My feeling is: 1) Fragmentation is handled by the NTLP layer. 2) Fragmentation is implemented at the NTLP layer. I get the feeling that some people are thinking, but not stating, that some applications may not care about fragmentation. They want to be able to turn on a don't fragment bit. If a message has to be fragmented, an error message would be generated. One thing that I do not see is how a NSLP layer would perform PMTU discovery - or at least how an NSLP would learn the PMTU, but maybe someone could tell me. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 12 09:32: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 JAA09843 for ; Thu, 12 Jun 2003 09:32:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CDWKY20993 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 09:32:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CDW4m20954; Thu, 12 Jun 2003 09:32:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CDVrm20927 for ; Thu, 12 Jun 2003 09:31:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09828 for ; Thu, 12 Jun 2003 09:31:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QS9A-0002Mm-00 for nsis@ietf.org; Thu, 12 Jun 2003 09:29:44 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19QS99-0002MM-00 for nsis@ietf.org; Thu, 12 Jun 2003 09:29:43 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5CDV8CL002199; Thu, 12 Jun 2003 06:31:08 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIH46100; Thu, 12 Jun 2003 06:31:06 -0700 (PDT) Message-Id: <200306121331.AIH46100@mira-sjc5-c.cisco.com> To: "Hancock, Robert" cc: "'sven.van_den_bosch@alcatel.be'" , "'nsis@ietf.org'" From: Melinda Shore Subject: Re: [NSIS] attempted summary of fragmentation discussion In-Reply-To: Message from robert.hancock@roke.co.uk of "Thu, 12 Jun 2003 11:06:21 BST." Date: Thu, 12 Jun 2003 09:31:06 -0400 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: , The NSLP doesn't know whether or not it's being bundled, which is a not-so-trivial impediment to having the NSLP making fragmentation decisions. It's conceivable that we could add a bit to an API to tell the NTLP not to bundle a given NSLP, but I think that we're tending towards getting complexer faster than we're getting usefuler. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 12 09:57: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 JAA10565 for ; Thu, 12 Jun 2003 09:57:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CDvUI23405 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 09:57:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CDvQm23336; Thu, 12 Jun 2003 09:57:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CDrkm22981 for ; Thu, 12 Jun 2003 09:53:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10388 for ; Thu, 12 Jun 2003 09:53:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QSUM-0002X1-00 for nsis@ietf.org; Thu, 12 Jun 2003 09:51:38 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19QSUL-0002W8-00 for nsis@ietf.org; Thu, 12 Jun 2003 09:51:37 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5CDqlVI092112; Thu, 12 Jun 2003 15:52:47 +0200 (CEST) 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 34C2CAB926; Thu, 12 Jun 2003 15:39:27 +0200 (CEST) Date: Thu, 12 Jun 2003 15:52:49 +0200 From: Marcus Brunner Reply-To: Marcus Brunner To: Melinda Shore , "Hancock, Robert" Cc: "'sven.van_den_bosch@alcatel.be'" , "'nsis@ietf.org'" Subject: Re: [NSIS] attempted summary of fragmentation discussion Message-ID: <19233366.1055433169@[10.1.1.130]> In-Reply-To: <200306121331.AIH46100@mira-sjc5-c.cisco.com> References: <200306121331.AIH46100@mira-sjc5-c.cisco.com> X-Mailer: Mulberry/3.0.2 (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 Donnerstag, 12. Juni 2003 09:31 -0400 Melinda Shore wrote: > The NSLP doesn't know whether or not it's being bundled, > which is a not-so-trivial impediment to having the NSLP > making fragmentation decisions. > I think this are two different orthogonal issues. The decision on bundling is in the NTLP, I hope that it does not bundle if afterwards fragmentation is needed. > It's conceivable that we could add a bit to an API to tell > the NTLP not to bundle a given NSLP, but I think that we're > tending towards getting complexer faster than we're getting > usefuler. Whether bundling makes anything easier needs to be proved. Marcus > > Melinda > _______________________________________________ > 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 Mobile: +49 (0) 163 275 17 43 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 Thu Jun 12 09:58: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 JAA10580 for ; Thu, 12 Jun 2003 09:58:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CDvbF23427 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 09:57:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CDvTm23386; Thu, 12 Jun 2003 09:57:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CDu8m23135 for ; Thu, 12 Jun 2003 09:56:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10482 for ; Thu, 12 Jun 2003 09:56:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QSWd-0002Yu-00 for nsis@ietf.org; Thu, 12 Jun 2003 09:53:59 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19QSWc-0002YY-00 for nsis@ietf.org; Thu, 12 Jun 2003 09:53:58 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5CDtZVI092364; Thu, 12 Jun 2003 15:55:35 +0200 (CEST) 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 2D8196420A; Thu, 12 Jun 2003 15:42:15 +0200 (CEST) Date: Thu, 12 Jun 2003 15:55:37 +0200 From: Marcus Brunner Reply-To: Marcus Brunner To: john.loughney@nokia.com Cc: nsis@ietf.org Subject: Re: [NSIS] How to move forward on the Fragmentation issue Message-ID: <19401377.1055433337@[10.1.1.130]> In-Reply-To: References: X-Mailer: Mulberry/3.0.2 (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 Donnerstag, 12. Juni 2003 16:28 +0300 john.loughney@nokia.com wrote: > Hi all, > > First off, let's stick to fragmentation. Message bundling is another > topic. > > My feeling is: > > 1) Fragmentation is handled by the NTLP layer. > 2) Fragmentation is implemented at the NTLP layer. > > I get the feeling that some people are thinking, but not stating, > that some applications may not care about fragmentation. They want > to be able to turn on a don't fragment bit. If a message has to > be fragmented, an error message would be generated. Its not that the application does not care, but some are afraid of adding functionality to a common part. But it boiles down to the estimation of cost of the feature. > One thing that I do not see is how a NSLP layer would perform > PMTU discovery - or at least how an NSLP would learn the PMTU, > but maybe someone could tell me. try and error ;-) Marcus -------------------------------------- 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 Mobile: +49 (0) 163 275 17 43 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 Thu Jun 12 10:07: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 KAA11385 for ; Thu, 12 Jun 2003 10:07:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CE7EK24373 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 10:07:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CE7Am24227; Thu, 12 Jun 2003 10:07:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CE6Cm23947 for ; Thu, 12 Jun 2003 10:06:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11204 for ; Thu, 12 Jun 2003 10:06:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QSgM-0002gW-00 for nsis@ietf.org; Thu, 12 Jun 2003 10:04:02 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19QSgM-0002fz-00 for nsis@ietf.org; Thu, 12 Jun 2003 10:04:02 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h5CE5Uwc021369; Thu, 12 Jun 2003 07:05:30 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIH48596; Thu, 12 Jun 2003 07:05:29 -0700 (PDT) Message-Id: <200306121405.AIH48596@mira-sjc5-c.cisco.com> To: Marcus Brunner cc: "'nsis@ietf.org'" From: Melinda Shore Subject: Re: [NSIS] attempted summary of fragmentation discussion In-Reply-To: Message from brunner@ccrle.nec.de of "Thu, 12 Jun 2003 15:52:49 +0200." <19233366.1055433169@[10.1.1.130]> Date: Thu, 12 Jun 2003 10:05:28 -0400 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: , > Whether bundling makes anything easier needs to be proved. Absolutely, and I think it's arguable that it does provide a good cost/benefit tradeoff. However, we agreed that we would start with 2205 + 2961, and bundling is included in 2961. We can excise it later if there's agreement that it adds undue complexity (Saint-Exupery on protocol design: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away"). I hope we can be consistently rigorous about avoiding unnecessary complexity. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Thu Jun 12 10:56: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 KAA14468 for ; Thu, 12 Jun 2003 10:56:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CEuWS29037 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 10:56:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CEuIm29018; Thu, 12 Jun 2003 10:56:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CErqm28848 for ; Thu, 12 Jun 2003 10:53:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14341 for ; Thu, 12 Jun 2003 10:53:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QTQV-0003BA-00 for nsis@ietf.org; Thu, 12 Jun 2003 10:51:43 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19QTQU-0003B1-00 for nsis@ietf.org; Thu, 12 Jun 2003 10:51:42 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5CErDVI097351; Thu, 12 Jun 2003 16:53:14 +0200 (CEST) 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 53FDEACAA4; Thu, 12 Jun 2003 16:39:53 +0200 (CEST) Date: Thu, 12 Jun 2003 16:53:15 +0200 From: Marcus Brunner Reply-To: Marcus Brunner To: john.loughney@nokia.com, hannes.tschofenig@siemens.com Cc: nsis@ietf.org Subject: Re: [NSIS] Security Threats for NSIS draft Message-ID: <22860231.1055436795@[10.1.1.130]> In-Reply-To: References: X-Mailer: Mulberry/3.0.2 (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 Hannes, We find the document very useful, the only thing we are not that happy with is the grouping of the different threats. A proposal could be to group into general security threats, signaling related, and NSIS specific. For people know very well normal security threats it is tiring to go through the document. And the format ID-nits etc. needs to be updated. Marcus & Miquel --On Donnerstag, 12. Juni 2003 10:25 +0300 john.loughney@nokia.com wrote: > Hannes, > > Any chance you'd get this submitted soon, I'd like to start WG call > before Vienna. > >> Security Threats for NSIS >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt > > thanks, > John > _______________________________________________ > 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 Mobile: +49 (0) 163 275 17 43 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 Thu Jun 12 11:24: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 LAA15701 for ; Thu, 12 Jun 2003 11:24:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CFNtJ31689 for nsis-archive@odin.ietf.org; Thu, 12 Jun 2003 11:23:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CFNUm31629; Thu, 12 Jun 2003 11:23:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CFLMm31475 for ; Thu, 12 Jun 2003 11:21:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15621 for ; Thu, 12 Jun 2003 11:21:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QTr8-0003Rb-00 for nsis@ietf.org; Thu, 12 Jun 2003 11:19:14 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 19QTr7-0003RY-00 for nsis@ietf.org; Thu, 12 Jun 2003 11:19:13 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id h5CFLIV07448; Thu, 12 Jun 2003 17:21:19 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h5CFLIp24539; Thu, 12 Jun 2003 17:21:18 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jun 2003 17:21:18 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F036760FD@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Marcus Brunner'" , john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] Security Threats for NSIS draft Date: Thu, 12 Jun 2003 17:21:15 +0200 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, hi miquel, thanks for your comments. would you also be happy if i add a table which maps the list of the threats into the groups - general security threats - signaling transport related - NSIS NSLP specific ? ciao hannes > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: Thursday, June 12, 2003 4:53 PM > To: john.loughney@nokia.com; Tschofenig Hannes > Cc: nsis@ietf.org > Subject: Re: [NSIS] Security Threats for NSIS draft > > > Hannes, > > We find the document very useful, the only thing we are not > that happy with > is the grouping of the different threats. A proposal could be > to group into > general security threats, signaling related, and NSIS > specific. For people > know very well normal security threats it is tiring to go through the > document. > > And the format ID-nits etc. needs to be updated. > > Marcus & Miquel > > --On Donnerstag, 12. Juni 2003 10:25 +0300 > john.loughney@nokia.com wrote: > > > Hannes, > > > > Any chance you'd get this submitted soon, I'd like to start WG call > > before Vienna. > > > >> Security Threats for NSIS > >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt > > > > thanks, > > John > > _______________________________________________ > > 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 > Mobile: +49 (0) 163 275 17 43 > 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 Fri Jun 13 01:48: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 BAA09760 for ; Fri, 13 Jun 2003 01:48:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5D5lr027528 for nsis-archive@odin.ietf.org; Fri, 13 Jun 2003 01:47:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CHmYa11779; Thu, 12 Jun 2003 13:48:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CGGYm03294 for ; Thu, 12 Jun 2003 12:16:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17222 for ; Thu, 12 Jun 2003 12:16:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QUiY-0003qU-00 for nsis@ietf.org; Thu, 12 Jun 2003 12:14:26 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19QUiX-0003qI-00 for nsis@ietf.org; Thu, 12 Jun 2003 12:14:25 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h5CGFiwc016886; Thu, 12 Jun 2003 09:15:44 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIH60873; Thu, 12 Jun 2003 09:15:43 -0700 (PDT) Message-Id: <200306121615.AIH60873@mira-sjc5-c.cisco.com> To: Marcus Brunner cc: "Hancock, Robert" , "'Georgios Karagiannis'" , nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] attempted summary of fragmentation discussion In-Reply-To: Message from brunner@ccrle.nec.de of "Thu, 12 Jun 2003 14:14:59 +0200." <13363035.1055427299@[10.1.1.130]> Date: Thu, 12 Jun 2003 12:15:42 -0400 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: , > What I have not hear so far is the cost of having > fragmentation built into NTLP. Georgios and myself are > concerned that the NTLP gets too fat for high-speed > processing, so we try to avoid to design for the rare > cases such as fragmentation. Obviously we don't want to allow IP to fragment the packets, since this will remove our ability to support middlebox traversal. That means that either we don't allow any fragmentation or we handle fragmentation ourselves. If we handle fragmentation ourselves it's pretty clear that it needs to be handled lower in the stack rather than higher in the stack, primarily because we need to know the entire packet size in order to make correct fragmentation decisions. "Entire packet size" may include bundling but will certainly include authentication-related data, which can be quite large. Additionally there may be other TLVs in the header (for example, related to reliable delivery) that the upper layers will not know about and therefore not be able to factor into a fragmentation decision. Adding support for fragmentation will certainly increase the code load, which may be an issue in memory-constrained devices, but it will not meaningfully lengthen the execution path since it's a quick check to see if you need to fragment (if packet_length > pmtu) on the sender side and a quick check to see if reassembly is required (if (frag_bit_is_set)) on the receiver side. Path MTU will need to be determined regardless of where fragmentation occurs and is a constant cost unless there's a decision not to fragment at all, which brings with it its own costs (and, for that matter, will require PMTU discovery as well). Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 13 02:26: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 CAA22401 for ; Fri, 13 Jun 2003 02:26:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5D6QCS08753 for nsis-archive@odin.ietf.org; Fri, 13 Jun 2003 02:26:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D4gGa23021; Fri, 13 Jun 2003 00:42:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D4fVm22986 for ; Fri, 13 Jun 2003 00:41:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08354 for ; Fri, 13 Jun 2003 00:41:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QgLQ-00010f-00 for nsis@ietf.org; Fri, 13 Jun 2003 00:39:20 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19QgLP-00010c-00 for nsis@ietf.org; Fri, 13 Jun 2003 00:39:19 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19QgNO-000IdP-00; Fri, 13 Jun 2003 04:41:22 +0000 To: Michael Thomas cc: brunner@ccrle.nec.de, john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt In-Reply-To: Message from Michael Thomas of "Wed, 11 Jun 2003 13:33:09 PDT." <16103.37381.277467.475065@thomasm-u1.cisco.com> Date: Thu, 12 Jun 2003 21:41:22 -0700 From: Allison Mankin Message-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: , > > > > This is a tough requirement since it has to be globally unique. It may > > turn out to be best met by the NI's authentication token, requiring an > > early integration of authentication design into the protocol. No request > > to change this, but just noting how hard this is - WG is _sure_ > > the mobility requirements are really so important? > > Maybe I don't understand what you're concerned > about, but why should this be hard? Say I generate > a pseudo-random number, we'd only really have to > worry about the birthday paradox which is > mitigated by adding bits. We're talking about the > (NSIS) signaling traffic, right? This seems pretty > orthogonal to auth... > Globally unique means a reasonably quite pseudo-random number (because it isn't good to have the resources id'd as someone else's) or a value that is sure to be unique. I'm not asking the document to take these ramblings in...just raising thoughts. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 13 03:30: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 DAA23907 for ; Fri, 13 Jun 2003 03:30:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5D7TXS13905 for nsis-archive@odin.ietf.org; Fri, 13 Jun 2003 03:29:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D4YHa21797; Fri, 13 Jun 2003 00:34:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D4XXm21773 for ; Fri, 13 Jun 2003 00:33:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08242 for ; Fri, 13 Jun 2003 00:33:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QgDh-0000yj-00 for nsis@ietf.org; Fri, 13 Jun 2003 00:31:21 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19QgDh-0000yg-00 for nsis@ietf.org; Fri, 13 Jun 2003 00:31:21 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19QgFi-000INn-00; Fri, 13 Jun 2003 04:33:26 +0000 To: "Hancock, Robert" cc: nsis@ietf.org, mankin@psg.com Subject: Re: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt In-Reply-To: Message from "Hancock, Robert" of "Mon, 09 Jun 2003 16:50:51 BST." Date: Thu, 12 Jun 2003 21:33:24 -0700 From: Allison Mankin Message-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: , Robert, Thanks for the explanations and comments. They were helpful. I have one amplification to make: > 5.9.6 MAY interwork with non-traditional routing > > NSIS assumes L3 routing, but networks, which do non-traditional > routing, should not break it. You explain this as follows: > b) The second requirement is about wanting NSIS protocols that aren't broken > > by the presence of policy-based forwarding in NSIS-unaware regions of the > network. Again, 'interwork' is probably the wrong word. So my guess that what the group meant by non-traditional (non-L3) routing was L4 switches/NATs was incorrect. The text is not fixed by changing the word 'interwork', it needs to have a clearer statement of the environment in which you expect NSIS to be robust. Policy-based forwarding would seem to me to be a form of L3 routing, so I'm still not sure. Could you clarify? This part of what you say: NSIS must be function in circumstances where parts of the network are NSIS-aware does not have to be coupled to the network having unusual routing, so this is not coming through clearly. Allison _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 13 06:35: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 GAA27722 for ; Fri, 13 Jun 2003 06:35:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DAYoD28647 for nsis-archive@odin.ietf.org; Fri, 13 Jun 2003 06:34:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D581a25005; Fri, 13 Jun 2003 01:08:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D570m24152 for ; Fri, 13 Jun 2003 01:07:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09041 for ; Fri, 13 Jun 2003 01:06:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qgk7-0001B3-00 for nsis@ietf.org; Fri, 13 Jun 2003 01:04:51 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19Qgk6-0001B0-00 for nsis@ietf.org; Fri, 13 Jun 2003 01:04:50 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19Qgm5-000Ja7-00; Fri, 13 Jun 2003 05:06:53 +0000 To: Marcus Brunner cc: john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt In-Reply-To: Message from Marcus Brunner of "Thu, 12 Jun 2003 00:01:13 +0200." <50208495.1055376073@[10.1.1.130]> Date: Thu, 12 Jun 2003 22:06:53 -0700 From: Allison Mankin Message-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: , Marcus, Thanks for the detailed responses. It's all good, with just two worries left. I asked for better clarification of Requirement 5.9.6 in my reply to Robert Hancock - it still stands out that "non-traditional routing" is vague and what form of robust behavior is required of NSIS in what environment is really not stated by the text. The other worry is the 3G scenario. John Loughney's message expressed a very good reason to make the scenario just a little more abstract, as I suggested, when he wrote: the IETF is not 3GPP, and it may be seen as the IETF imposing its view upon 3GPP. We should be careful not to imply that this is the way that the IETF or the NSIS WG thinks 3GPP should do things. If the WG does not want to decrease the specificity of the details from 3GPP, then the text must make more disclaimers. The opening of the section should say that the scenario inserts NSIS in an environment that resembles 3GPP, but that NSIS is not in 3GPP plans, and that design is hypothetical. The following language is not enough because it comes later, after the reader may have become convinced of NSIS's integral role with the other 3GPP components: 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. Thanks, Allison _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 13 08:11: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 IAA29833 for ; Fri, 13 Jun 2003 08:11:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DCAii03879 for nsis-archive@odin.ietf.org; Fri, 13 Jun 2003 08:10:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D7p3a15828; Fri, 13 Jun 2003 03:51:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D7o3m15780 for ; Fri, 13 Jun 2003 03:50:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24356 for ; Fri, 13 Jun 2003 03:50:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QjHt-0002VP-00 for nsis@ietf.org; Fri, 13 Jun 2003 03:47:53 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19QjHs-0002V0-00 for nsis@ietf.org; Fri, 13 Jun 2003 03:47:53 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5D7mfVI023178; Fri, 13 Jun 2003 09:48:41 +0200 (CEST) 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 8104AACDA9; Fri, 13 Jun 2003 09:35:14 +0200 (CEST) Date: Fri, 13 Jun 2003 09:48:43 +0200 From: Marcus Brunner Reply-To: Marcus Brunner To: Melinda Shore Cc: "Hancock, Robert" , "'Georgios Karagiannis'" , nsis@ietf.org Subject: Re: [NSIS] attempted summary of fragmentation discussion Message-ID: <3445023.1055497723@[10.1.1.130]> In-Reply-To: <200306121615.AIH60873@mira-sjc5-c.cisco.com> References: <200306121615.AIH60873@mira-sjc5-c.cisco.com> X-Mailer: Mulberry/3.0.2 (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 Donnerstag, 12. Juni 2003 12:15 -0400 Melinda Shore wrote: >> What I have not hear so far is the cost of having >> fragmentation built into NTLP. Georgios and myself are >> concerned that the NTLP gets too fat for high-speed >> processing, so we try to avoid to design for the rare >> cases such as fragmentation. > > Obviously we don't want to allow IP to fragment the packets, > since this will remove our ability to support middlebox > traversal. I do not see how NSIS is able to pass through a standard NAT and still work correctly. I think there needs to be an NSIS specific adaption of the NAT anyway. > That means that either we don't allow any > fragmentation or we handle fragmentation ourselves. If we > handle fragmentation ourselves it's pretty clear that it > needs to be handled lower in the stack rather than higher in > the stack, primarily because we need to know the entire > packet size in order to make correct fragmentation > decisions. RFC 2205 proposes for the future the notion of semantic fragmentation, which means that it must be higher in the stack, because the high you are the more you know about the semantic. "The most likely direction will be to perform "semantic fragmentation", i.e., break the path or reservation state being transmitted into multiple self-contained messages, each of an acceptable size." Marcus -------------------------------------- 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 Mobile: +49 (0) 163 275 17 43 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 Fri Jun 13 09:12: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 JAA02412 for ; Fri, 13 Jun 2003 09:12:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DDCCW09352 for nsis-archive@odin.ietf.org; Fri, 13 Jun 2003 09:12:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DBJ2a32196; Fri, 13 Jun 2003 07:19:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DBIBm32167 for ; Fri, 13 Jun 2003 07:18:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28311 for ; Fri, 13 Jun 2003 07:18:10 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QmXJ-0003hB-00 for nsis@ietf.org; Fri, 13 Jun 2003 07:16:02 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19QmXJ-0003h8-00 for nsis@ietf.org; Fri, 13 Jun 2003 07:16:01 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5DBI9904027 for ; Fri, 13 Jun 2003 14:18:09 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 13 Jun 2003 14:18:08 +0300 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 13 Jun 2003 14:18:08 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 13 Jun 2003 14:18:08 +0300 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: Fri, 13 Jun 2003 14:18:08 +0300 Message-ID: Thread-Topic: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt Thread-Index: AcMxlSh4dgwFD6kHS/2OPlLOpWqkFwACCYKg To: X-OriginalArrivalTime: 13 Jun 2003 11:18:08.0210 (UTC) FILETIME=[7790A320:01C3319D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5DBIBm32168 Subject: [NSIS] Info for the upcoming IETF 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 Hi all, Just a small note from your friendly WG Chair. IETF time is soon upon us, here are some suggestions for those attending the meeting. - Newcomers can learn a lot ahead of time by reading the Tao of the IETF at . The newcomer orientation on Sunday (this year, at 1PM) is useful, but it is even more useful if they have read the Tao first. - It is a good idea to at least skim the WG archives for the past four months before the meeting to help prevent rehashing items that have already been decided and to help focus on items that need more review. - Similarly, it is a good idea to re-read the WG's charter before the meeting. Heck, many WG chairs could get value from this... - Many IETF areas have area-wide meetings. People who are interested in more than just one WG can get a feel for what is happening in other areas by going to these meetings. - The "Note Well" notice is serious. It can be found at , and will be given on paper in the registration packets. br, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 13 10:48: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 KAA08559 for ; Fri, 13 Jun 2003 10:48:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DEm0T17218 for nsis-archive@odin.ietf.org; Fri, 13 Jun 2003 10:48:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CNA2a00746; Thu, 12 Jun 2003 19:10:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CN9Im00649 for ; Thu, 12 Jun 2003 19:09:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00889 for ; Thu, 12 Jun 2003 19:09:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qb9w-0006p8-00 for nsis@ietf.org; Thu, 12 Jun 2003 19:07:08 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19Qb9v-0006ou-00 for nsis@ietf.org; Thu, 12 Jun 2003 19:07:07 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jun 2003 00:08:44 +0100 Message-ID: From: "Hancock, Robert" To: Marcus Brunner Cc: nsis@ietf.org Subject: RE: [NSIS] attempted summary of fragmentation discussion Date: Fri, 13 Jun 2003 00:08:36 +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: , marcus, all, i still feel i am missing something in this argument. apologies if this mail is a bit long. 1. georgios' proposal is to have fragmentation functionality in the NTLP anyway, and just the option to not use it. (another option would be to have no fragmentation functionality in the NTLP at all, just 'packet too big' error reporting - but that's not what's been proposed.) ==> therefore it is a pure increase in complexity in the NTLP compared to 'the NTLP does fragmentation' option. 2. if you believe fragmentation is a 'rare case', do it as part of your exception handling software; the code needed for fragmentation is trivial (certainly trivial compared to PMTU discovery logic which is needed in the NTLP wherever fragmentation is done, as Melinda points out below). ==> we don't care either way in terms of NTLP complexity. 3. my more general concern is that the concept of PMTU discovery has a number of non-trivial aspects associated with it - check out the plpmtud bof notes from the last IETF (and rfc2923) for details of how in the real world it doesn't really work as well as one would like. while these problems are fixable (and indeed have to be fixed for the NTLP, whichever approach we take) they appear to me to be pointers that PMTU in the NSLP will architecturally fragile and something to be avoided unless there is a pressing performance reason why it has to be done. in particular, this approach will add an RTT to signalling setup times while the MTU is discovered (unless the initial message in the exchange is small), and messages will be black-holed unless the error reporting (which depends on backwards routing per flow at every intermediate node) works perfectly. ==> IMHO not doing fragmentation is a mechanism for storing up deployment and design problems for the future . 4. so, maybe people are really concerned about performance issues. here is an example: Signalling Messages >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +-----------+ +-----------+ |NSLP Source| +---------\ +------+ Thin Pipe | NSLP Sink | +-----------+ |Fat Pipe > |NTLP 2| -----------> +-----------+ | NTLP 1 | +---------/ +------+ | NTLP 3 | +-----------+ +-----------+ (the pipes are fat and thin in the sense of being able to send big or small messages). This case is I think the *most* favourable to the "don't fragment at NTLP" viewpoint, because *) if the NSLP is present at the intermediate nodes the question of layering is moot *) if the pipes are the other way round, fragmentation won't happen anyway So, let's consider 4 cases for what happens when a big message is sent source->sink. The emphasis of the analysis is on the processing burden at Node 2. a) Fragmentation at NTLP only: Node 1 sends message Node 2 NTLP executes the following - receive incoming message into NTLP code - process incoming message - determine outgoing interface for route - construct header for outgoing packets - while (packet payload is left) { send chunk of packet payload in fragment } b) Fragmentation optionally allowed at NSLP: Because the NSLP designer and implementor don't believe in making their own lives harder, the NSLP sends its message with 'fragmentation allowed' anyway ==> end result is the same as case (a) except with more complex code because of the optional aspects which aren't being used c) Fragmentation happens at the NSLP (either because the designer/implementor are blackmailed into it, or because it is taken out of the NTLP): Nodes 1 & 2 go through PMTU discovery procedure Node 1 NSLP generates a sequence of message fragments Node 1 NTLP bundles them back together into one or two messages (depending on how much overhead is added) Node 2 NTLP executes the following (once or twice) - receive incoming message into NTLP code - process incoming message bundle header - for each message in bundle { - determine outgoing interface for route - construct header for outgoing packet - send outgoing packet } ==> to me, it isn't clear how this makes life easier for NTLP at Node 2 (and the additional burden applies to any other nodes between 1 and 2 as well). d) So, you don't like bundling after all? Take it out altogether (but remember, the experience leading to 2961 was that the step called 'receive' here is actually the dominant element of the processing load): Nodes 1 & 2 go through PMTU discovery procedure Node 1 generates a sequence of message fragments, each sent individually Node 2 NTLP executes the following - for each fragment { - receive incoming message into NTLP code - determine outgoing interface for route - construct header for outgoing packet - send outgoing packet } ==> seems hardest of all (again, the extra load applies everywhere upstream of node 2 as well). why is this wrong? cheers, robert h. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: 12 June 2003 17:16 > To: Marcus Brunner > Cc: Hancock, Robert; 'Georgios Karagiannis'; nsis@ietf.org > Subject: Re: [NSIS] attempted summary of fragmentation discussion > > > > What I have not hear so far is the cost of having > > fragmentation built into NTLP. Georgios and myself are > > concerned that the NTLP gets too fat for high-speed > > processing, so we try to avoid to design for the rare > > cases such as fragmentation. > > Obviously we don't want to allow IP to fragment the packets, > since this will remove our ability to support middlebox > traversal. That means that either we don't allow any > fragmentation or we handle fragmentation ourselves. If we > handle fragmentation ourselves it's pretty clear that it > needs to be handled lower in the stack rather than higher in > the stack, primarily because we need to know the entire > packet size in order to make correct fragmentation > decisions. "Entire packet size" may include bundling but > will certainly include authentication-related data, which > can be quite large. Additionally there may be other TLVs > in the header (for example, related to reliable delivery) > that the upper layers will not know about and therefore not > be able to factor into a fragmentation decision. > > Adding support for fragmentation will certainly increase the > code load, which may be an issue in memory-constrained > devices, but it will not meaningfully lengthen the execution > path since it's a quick check to see if you need to fragment > (if packet_length > pmtu) on the sender side and a quick > check to see if reassembly is required (if (frag_bit_is_set)) > on the receiver side. Path MTU will need to be determined > regardless of where fragmentation occurs and is a constant > cost unless there's a decision not to fragment at all, which > brings with it its own costs (and, for that matter, will > require PMTU discovery as well). > > Melinda > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 13 11:05: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 LAA09094 for ; Fri, 13 Jun 2003 11:05:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DF5Lh18504 for nsis-archive@odin.ietf.org; Fri, 13 Jun 2003 11:05:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D7b2a14282; Fri, 13 Jun 2003 03:37:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D7alm14225 for ; Fri, 13 Jun 2003 03:36:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24021 for ; Fri, 13 Jun 2003 03:36:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qj54-0002P6-00 for nsis@ietf.org; Fri, 13 Jun 2003 03:34:38 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19Qj53-0002Oi-00 for nsis@ietf.org; Fri, 13 Jun 2003 03:34:37 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5D7aEVI021048; Fri, 13 Jun 2003 09:36:15 +0200 (CEST) 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 7A221AC4AE; Fri, 13 Jun 2003 09:22:47 +0200 (CEST) Date: Fri, 13 Jun 2003 09:33:39 +0200 From: Marcus Brunner Reply-To: Marcus Brunner To: Tschofenig Hannes , john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: [NSIS] Security Threats for NSIS draft Message-ID: <2697839.1055496819@[10.1.1.130]> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F036760FD@mchp905a.mch.sbs.de> References: <2A8DB02E3018D411901B009027FD3A3F036760FD@mchp905a.mch.sbs.de> X-Mailer: Mulberry/3.0.2 (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 think the distinction between signaling transport related NSIS NSLP specific is not needed. I think it is difficult to do this because the framework on this issue is not stable (at least to my knowledge) But at least general security and signaling specific threats would make it much clearer. Marcus --On Donnerstag, 12. Juni 2003 17:21 +0200 Tschofenig Hannes wrote: > hi marcus, > hi miquel, > > thanks for your comments. > > would you also be happy if i add a table which maps the list of the > threats into the groups > - general security threats > - signaling transport related > - NSIS NSLP specific > ? > > ciao > hannes > >> -----Original Message----- >> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] >> Sent: Thursday, June 12, 2003 4:53 PM >> To: john.loughney@nokia.com; Tschofenig Hannes >> Cc: nsis@ietf.org >> Subject: Re: [NSIS] Security Threats for NSIS draft >> >> >> Hannes, >> >> We find the document very useful, the only thing we are not >> that happy with >> is the grouping of the different threats. A proposal could be >> to group into >> general security threats, signaling related, and NSIS >> specific. For people >> know very well normal security threats it is tiring to go through the >> document. >> >> And the format ID-nits etc. needs to be updated. >> >> Marcus & Miquel >> >> --On Donnerstag, 12. Juni 2003 10:25 +0300 >> john.loughney@nokia.com wrote: >> >> > Hannes, >> > >> > Any chance you'd get this submitted soon, I'd like to start WG call >> > before Vienna. >> > >> >> Security Threats for NSIS >> >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt >> > >> > thanks, >> > John >> > _______________________________________________ >> > 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 >> Mobile: +49 (0) 163 275 17 43 >> personal home page: http://www.brubers.org/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 Mobile: +49 (0) 163 275 17 43 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 Fri Jun 13 12:26: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 MAA11126 for ; Fri, 13 Jun 2003 12:26:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DGQIZ26775 for nsis-archive@odin.ietf.org; Fri, 13 Jun 2003 12:26:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DEs2a17686; Fri, 13 Jun 2003 10:54:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DErhm17663 for ; Fri, 13 Jun 2003 10:53:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08733 for ; Fri, 13 Jun 2003 10:53:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qpts-0005yw-00 for nsis@ietf.org; Fri, 13 Jun 2003 10:51:32 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19Qptr-0005yP-00 for nsis@ietf.org; Fri, 13 Jun 2003 10:51:31 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5DEr8ms001753; Fri, 13 Jun 2003 07:53:09 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AII80793; Fri, 13 Jun 2003 07:53:07 -0700 (PDT) Message-Id: <200306131453.AII80793@mira-sjc5-c.cisco.com> To: "Hancock, Robert" cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] attempted summary of fragmentation discussion In-Reply-To: Message from robert.hancock@roke.co.uk of "Fri, 13 Jun 2003 00:08:36 BST." Date: Fri, 13 Jun 2003 10:53:06 -0400 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: , Those are good points, but I think what's missing from that analysis is the reassembly costs, which would tend to dominate the process (as opposed to fragmentation costs, which are low). When talking about reassembly you have to consider what happens when packets arrive out-of-order, are dropped, etc., and that means additional buffers (statefulness), additional timers (more statefulness), and additional execution logic. The other problem, I think, is that the problem isn't bundling, it's message size, and that's almost certainly going to be an issue whether application messages are bundled or not. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 13 12:58: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 MAA12307 for ; Fri, 13 Jun 2003 12:58:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DGvpB01245 for nsis-archive@odin.ietf.org; Fri, 13 Jun 2003 12:57:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DF31a18315; Fri, 13 Jun 2003 11:03:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DF2um18304 for ; Fri, 13 Jun 2003 11:02:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09000 for ; Fri, 13 Jun 2003 11:02:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qq2m-00062Y-00 for nsis@ietf.org; Fri, 13 Jun 2003 11:00:44 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19Qq2l-00062V-00 for nsis@ietf.org; Fri, 13 Jun 2003 11:00:44 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jun 2003 16:02:51 +0100 Message-ID: From: "Hancock, Robert" To: "'Melinda Shore'" Cc: nsis@ietf.org Subject: RE: [NSIS] attempted summary of fragmentation discussion Date: Fri, 13 Jun 2003 16:02:49 +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 that the reassembly is the critical part of the overall packet handling problem. looking back over the v6 discussions on this topic, key parts of the argument are much more about reassembly costs and doing fragmentation in a way to minimise them, rather than the costs of fragmentation themselves. however, i think it is possible to implement fragmentation so that reassembly is only required in the NSLP node where the message has to be dealt with. this will be true however we split the layering issues up, and so doesn't affect the decision we are trying to make. (this is not the case with the fragmentation stage, where at least part of the argument is that doing fragmentation in the NTLP may overload a node which doesn't actually care about the corresponding application.) robert h. i didn't want to confuse the argument by including bundling, but in the performance analysis there is a sort of interaction. the analysis considers only a single big message after all. > -----Original Message----- > From: Melinda Shore [mailto:mshore@cisco.com] > Sent: 13 June 2003 15:53 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: [NSIS] attempted summary of fragmentation discussion > > > Those are good points, but I think what's missing from that > analysis is the reassembly costs, which would tend to > dominate the process (as opposed to fragmentation costs, > which are low). When talking about reassembly you have to > consider what happens when packets arrive out-of-order, are > dropped, etc., and that means additional buffers > (statefulness), additional timers (more statefulness), and > additional execution logic. > > The other problem, I think, is that the problem isn't > bundling, it's message size, and that's almost certainly > going to be an issue whether application messages are > bundled or not. > > Melinda > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 13 13:09: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 NAA13289 for ; Fri, 13 Jun 2003 13:09:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DH8nS11363 for nsis-archive@odin.ietf.org; Fri, 13 Jun 2003 13:08:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D8I2a18180; Fri, 13 Jun 2003 04:18:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D8H6m18122 for ; Fri, 13 Jun 2003 04:17:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24842 for ; Fri, 13 Jun 2003 04:17:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qji4-0002fr-00 for nsis@ietf.org; Fri, 13 Jun 2003 04:14:56 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19Qji4-0002fa-00 for nsis@ietf.org; Fri, 13 Jun 2003 04:14:56 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jun 2003 09:16:34 +0100 Message-ID: From: "Hancock, Robert" To: "'Allison Mankin'" Cc: nsis@ietf.org Subject: RE: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt Date: Fri, 13 Jun 2003 09:16: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 allison, i'll try to explain, hopefully in not too much detail. historical background to this requirement (for those needing it): there was a long-ish discussion at the first NSIS interim (just over a year ago) about problems in the path-finding process, i.e. that two packets with the same destination address (e.g. a data packet and a PATH message) might be routed differently. obviously an NSIS processing node can be mandated not to do this, but if the data path crosses an NSIS-unaware cloud, the signalling and data paths may split and be very difficult to recombine. the requirement is basically trying to say: we should not ignore this problem, although a general solution is recognised as hard. Bob provided an excellent summary of the situation in an email to the list (on or around 21/11/02, in my time zone). so, I think there are two parts to stating the requirement. one is, defining the circumstances where the splitting arises. this is a combination of a) NSIS-unaware node, and b) makes a routing decision based on something other that L3 DA. We never found a good name for things that do (b); policy forwarding is part of it (some people call this policy routing which is not the problem); another part is QoS routing (e.g. routing on ToS/DS value); another part is load sharing using a hash of some part of the packet header as a discriminator. These may or may not involve packet fields above L3, including L4 switching and things like interception middleboxes ("transparent" web caches), and may or may not involve L3 fields not usually used in (unicast) routing, like L3 SA. maybe there is *no* good name for the set of circumstances covered by (b), and the requirement should be phrased in terms of 'non-pure-L3-destination- address-routing' (although it's a bit of a mouthful), and accompanied by some more background. the other part of stating the requirement is to say what we should try to achieve in these circumstances. i don't think a concrete target can be set here, because a perfect solution is nearly provably impossible. i think the main approach is that as the signalling packets that have to follow the path look more and more like data packets the problem gets less severe, but that's solution space, not a requirement. do you think that the concerns are reasonable and that a useful requirement covering them can be written? in other words, is this only a terminology/clarity issue? cheers, robert h. > -----Original Message----- > From: Allison Mankin [mailto:mankin@psg.com] > Sent: 13 June 2003 05:33 > To: Hancock, Robert > Cc: nsis@ietf.org; mankin@psg.com > Subject: Re: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt > > > Robert, > > Thanks for the explanations and comments. They were helpful. > > I have one amplification to make: > > > 5.9.6 MAY interwork with non-traditional routing > > > > NSIS assumes L3 routing, but networks, which do non-traditional > > routing, should not break it. > > You explain this as follows: > > > b) The second requirement is about wanting NSIS protocols > that aren't broken > > > > by the presence of policy-based forwarding in NSIS-unaware > regions of the > > network. Again, 'interwork' is probably the wrong word. > > So my guess that what the group meant by non-traditional > (non-L3) routing > was L4 switches/NATs was incorrect. The text is not fixed by > changing the > word 'interwork', it needs to have a clearer statement of the > environment > in which you expect NSIS to be robust. Policy-based > forwarding would seem > to me to be a form of L3 routing, so I'm still not sure. > Could you clarify? > > This part of what you say: > > NSIS must be function in circumstances where parts of the > network are > NSIS-aware > > does not have to be coupled to the network having unusual > routing, so this > is not coming through clearly. > > Allison > _______________________________________________ > 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 Jun 13 14:37: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 OAA17470 for ; Fri, 13 Jun 2003 14:37:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DHNsd06734 for nsis-archive@odin.ietf.org; Fri, 13 Jun 2003 13:23:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D9n2a25583; Fri, 13 Jun 2003 05:49:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D9mpm25568 for ; Fri, 13 Jun 2003 05:48:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26803 for ; Fri, 13 Jun 2003 05:48:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ql8q-0003EH-00 for nsis@ietf.org; Fri, 13 Jun 2003 05:46:40 -0400 Received: from h42s128a211n47.user.nortelnetworks.com ([47.211.128.42] helo=znsgs01r.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19Ql8p-0003ED-00 for nsis@ietf.org; Fri, 13 Jun 2003 05:46:40 -0400 Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5D9m3o19585; Fri, 13 Jun 2003 10:48:03 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jun 2003 10:48:03 +0100 Message-ID: From: "Daniel Warren" To: "'Georgios Karagiannis'" , "Hancock, Robert" , nsis@ietf.org Subject: RE: [NSIS] attempted summary of fragmentation discussion Date: Fri, 13 Jun 2003 10:48:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33190.E090673C" 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_01C33190.E090673C Content-Type: text/plain; charset="iso-8859-1" I'm going to take on more run at this... I can see no usefulness of a 'Do not fragment bit'. The fragmentation of messages is something that only takes place to ensure that a message that would otherwise not make it across a network because of it's unfragmented size, actually does make it from one end to the other. If a message results in the packet being sent being greater than the MTU for one hop of the path the message takes and the message cannot be fragmented it is a guarantee that the message will fail to be communicated and an error will be returned to the sending node. If fragmentation is allowed there is still a possibility that the message will fail (should one of the fragments get lost) but there is also a possibility (and one would hope, a significantly high one) that the messgae will be delivered successfully. So, by setting a 'Do not fragment bit' you are basically increasing the likelihood of messages not being delivered successfully. If the bit is set, and the message arrives at the receiving end unscathed, that has nothing to do with the bit being set, since the message would have to be under the size of the PMTU and so would not have been fragmented anyway! I can understand the concept of the bit if you want to ensure reliable delivery of the message for some reason, but that could just as easily be provisioned for by wetting the MTU size on the hops that are going to have to handle the messages to be big enough not to have to fragment the messages. That puts you back in the situation above where the bit would make no difference. The only other consideration would then be bundling of messages that would result in the NTLP fragmenting a number of messages that are being sent in an amalgous blob. If a message not to be fragmented gets in amongst a bundle of other messages and the bundle results in something larger than PMTU being sent, that *could* justify a 'Do not segment' bit. However, wouldn't a better solution be a 'Do not bundle' bit? Dan -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] Sent: 12 June 2003 13:03 To: Hancock, Robert; nsis@ietf.org Subject: Re: [NSIS] attempted summary of fragmentation discussion Hi Robert I proposed many solutions to this in previous e-mails. The main advantage of having this feature is that the performance of the node in terms of processing delays will be enhanced when the node does not have to perform fragmentation. Best regards, Georgios ----- Original Message ----- From: "Hancock, Robert" To: "'Georgios Karagiannis'" ; Sent: Thursday, June 12, 2003 1:50 PM Subject: RE: [NSIS] attempted summary of fragmentation discussion > hi georgios, > > how and why? > > i.e. it would be helpful (at least to me) if you could > a) define (4) in a bit more detail about how the layers and nodes would > interact to achieve it, and > b) explain why this functionality would justify the additional complexity. > > cheers, > > r. > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 12 June 2003 12:37 > > To: Hancock, Robert; nsis@ietf.org > > Subject: Re: [NSIS] attempted summary of fragmentation discussion > > > > > > Hi Robert > > > > Please combine (3) and (4) in a more strict way! > > > > Best regards, > > Georgios > > ----- Original Message ----- > > From: "Hancock, Robert" > > To: > > Sent: Thursday, June 12, 2003 11:21 AM > > Subject: [NSIS] attempted summary of fragmentation discussion > > > > > > > dear all, > > > > > > in attempting to summarise where we are so far, this is > > what i think the > > > situation is: > > > > > > 1) no-one really likes relying on IP fragmentation > > > 2) no-one wants to force all responsibility into the NSLPs > > > 3) everyone [almost?] is happy with the NTLP doing > > fragmentation as a > > > default > > > 4) there is a proposal to make it possible to signal the > > NTLP not to do > > > fragmentation and have the NSLP do it (in some > > still-to-be-defined way) > > > > > > personally, i fail to see the benefit of (4) over (3), > > which may be a > > > symptom of a deeper problem (with me or the proposal). > > > > > > however, i believe it is not ruled out even if we used as an initial > > > position: > > > *) make the NTLP do fragmentation when it is needed; > > ideally, do it in > > such > > > a way that reassembly is only needed at the receiving NSLP. > > > > > > in later stages of the protocol work, and after some experience with > > > applications, we could presumably "enhance" the NTLP in the > > direction of > > > option 4, i.e. give it the ability not to do fragmentation > > as well. after > > > all, this would appear to be an intrinsically backwards compatible > > > extension. > > > > > > have i missed anything? > > > > > > robert h. > > > _______________________________________________ > > > nsis mailing list > > > nsis@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nsis > > > > > > > -- > Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, > Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments is confidential to > Roke Manor Research Ltd and must not be passed to any third party without > permission. This communication is for information only and shall not create or > change any contractual relationship. > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ------_=_NextPart_001_01C33190.E090673C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] attempted summary of fragmentation discussion

I'm going to take on more run at this...

I can see no usefulness of a 'Do not fragment = bit'.  The fragmentation of messages is something that only takes = place to ensure that a message that would otherwise not make it across = a network because of it's unfragmented size, actually does make it from = one end to the other.  If a message results in the packet being = sent being greater than the MTU for one hop of the path the message = takes and the message cannot be fragmented it is a guarantee that the = message will fail to be communicated and an error will be returned to = the sending node.  If fragmentation is allowed there is still a = possibility that the message will fail (should one of the fragments get = lost) but there is also a possibility (and one would hope, a = significantly high one) that the messgae will be delivered = successfully.

So, by setting a 'Do not fragment bit' you are = basically increasing the likelihood of messages not being delivered = successfully.  If the bit is set, and the message arrives at the = receiving end unscathed, that has nothing to do with the bit being set, = since the message would have to be under the size of the PMTU and so = would not have been fragmented anyway!  I can understand the = concept of the bit if you want to ensure reliable delivery of the = message for some reason, but that could just as easily be provisioned = for by wetting the MTU size on the hops that are going to have to = handle the messages to be big enough not to have to fragment the = messages.  That puts you back in the situation above where the bit = would make no difference.

The only other consideration would then be bundling = of messages that would result in the NTLP fragmenting a number of = messages that are being sent in an amalgous blob.  If a message = not to be fragmented gets in amongst a bundle of other messages and the = bundle results in something larger than PMTU being sent, that *could* = justify a 'Do not segment' bit.  However, wouldn't a better = solution be a 'Do not bundle' bit?

Dan

-----Original Message-----
From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl= ]
Sent: 12 June 2003 13:03
To: Hancock, Robert; nsis@ietf.org
Subject: Re: [NSIS] attempted summary of = fragmentation discussion


Hi Robert

I proposed many solutions to this in previous = e-mails.
The main advantage of having this feature is that = the performance of the
node in terms of processing delays will be = enhanced
when the node does not have to perform = fragmentation.

Best regards,
Georgios




----- Original Message -----
From: "Hancock, Robert" = <robert.hancock@roke.co.uk>
To: "'Georgios Karagiannis'" = <karagian@cs.utwente.nl>; <nsis@ietf.org>
Sent: Thursday, June 12, 2003 1:50 PM
Subject: RE: [NSIS] attempted summary of = fragmentation discussion


> hi georgios,
>
> how and why?
>
> i.e. it would be helpful (at least to me) if = you could
> a) define (4) in a bit more detail about how = the layers and nodes would
> interact to achieve it, and
> b) explain why this functionality would justify = the additional complexity.
>
> cheers,
>
> r.
>
> > -----Original Message-----
> > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl= ]
> > Sent: 12 June 2003 12:37
> > To: Hancock, Robert; nsis@ietf.org
> > Subject: Re: [NSIS] attempted summary of = fragmentation discussion
> >
> >
> > Hi Robert
> >
> > Please combine (3) and (4) in a more = strict way!
> >
> > Best regards,
> > Georgios
> > ----- Original Message -----
> > From: "Hancock, Robert" = <robert.hancock@roke.co.uk>
> > To: <nsis@ietf.org>
> > Sent: Thursday, June 12, 2003 11:21 = AM
> > Subject: [NSIS] attempted summary of = fragmentation discussion
> >
> >
> > > dear all,
> > >
> > > in attempting to summarise where we = are so far, this is
> > what i think the
> > > situation is:
> > >
> > > 1) no-one really likes relying on IP = fragmentation
> > > 2) no-one wants to force all = responsibility into the NSLPs
> > > 3) everyone [almost?] is happy with = the NTLP doing
> > fragmentation as a
> > > default
> > > 4) there is a proposal to make it = possible to signal the
> > NTLP not to do
> > > fragmentation and have the NSLP do it = (in some
> > still-to-be-defined way)
> > >
> > > personally, i fail to see the benefit = of (4) over (3),
> > which may be a
> > > symptom of a deeper problem (with me = or the proposal).
> > >
> > > however, i believe it is not ruled = out even if we used as an initial
> > > position:
> > > *) make the NTLP do fragmentation = when it is needed;
> > ideally, do it in
> > such
> > > a way that reassembly is only needed = at the receiving NSLP.
> > >
> > > in later stages of the protocol work, = and after some experience with
> > > applications, we could presumably = "enhance" the NTLP in the
> > direction of
> > > option 4, i.e. give it the ability = not to do fragmentation
> > as well. after
> > > all, this would appear to be an = intrinsically backwards compatible
> > > extension.
> > >
> > > have i missed anything?
> > >
> > > robert h.
> > > = _______________________________________________
> > > nsis mailing list
> > > nsis@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/nsis=
> > >
> >
>
> --
> Registered Office: Roke Manor Research Ltd, = Siemens House, Oldbury,
Bracknell,
> Berkshire. RG12 8FZ
>
> The information contained in this e-mail and = any attachments is
confidential to
> Roke Manor Research Ltd and must not be passed = to any third party without
> permission. This communication is for = information only and shall not
create or
> change any contractual relationship.
>

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis=

------_=_NextPart_001_01C33190.E090673C-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 13 19:11: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 TAA27848 for ; Fri, 13 Jun 2003 19:11:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DNBXG32307 for nsis-archive@odin.ietf.org; Fri, 13 Jun 2003 19:11:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DLB4a20656; Fri, 13 Jun 2003 17:11:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DLAqm20552 for ; Fri, 13 Jun 2003 17:10:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23221 for ; Fri, 13 Jun 2003 17:10:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qvmr-0001Kh-00 for nsis@ietf.org; Fri, 13 Jun 2003 17:08:41 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19Qvmq-0001I3-00 for nsis@ietf.org; Fri, 13 Jun 2003 17:08:40 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h5DLAIwc006841; Fri, 13 Jun 2003 14:10:18 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIJ28380; Fri, 13 Jun 2003 14:10:13 -0700 (PDT) Message-Id: <200306132110.AIJ28380@mira-sjc5-c.cisco.com> To: Michael Thomas cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] attempted summary of fragmentation discussion In-Reply-To: Message from mat of "Fri, 13 Jun 2003 14:04:50 PDT." <16106.15474.954924.470334@thomasm-u1.cisco.com> Date: Fri, 13 Jun 2003 17:10:12 -0400 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: , > Does PMTU (re)discovery always have to be from > end host to end host? What's an "end host" in this context? Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 13 20:46: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 UAA00141 for ; Fri, 13 Jun 2003 20:46:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5E0jfG06829 for nsis-archive@odin.ietf.org; Fri, 13 Jun 2003 20:45:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DLG2a21047; Fri, 13 Jun 2003 17:16:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DLF4m20986 for ; Fri, 13 Jun 2003 17:15:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23448 for ; Fri, 13 Jun 2003 17:15:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qvqv-0001N2-00 for nsis@ietf.org; Fri, 13 Jun 2003 17:12:53 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19Qvqv-0001Mg-00 for nsis@ietf.org; Fri, 13 Jun 2003 17:12:53 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5DLEUjc008311; Fri, 13 Jun 2003 14:14:30 -0700 (PDT) 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.3.3-GR) with ESMTP id AFB55629; Fri, 13 Jun 2003 14:14:28 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA19364; Fri, 13 Jun 2003 14:14:28 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16106.16052.349992.672754@thomasm-u1.cisco.com> Date: Fri, 13 Jun 2003 14:14:28 -0700 (PDT) To: Melinda Shore Cc: Michael Thomas , nsis@ietf.org Subject: Re: [NSIS] attempted summary of fragmentation discussion In-Reply-To: <200306132110.AIJ28380@mira-sjc5-c.cisco.com> References: <16106.15474.954924.470334@thomasm-u1.cisco.com> <200306132110.AIJ28380@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 Melinda Shore writes: > > Does PMTU (re)discovery always have to be from > > end host to end host? > > What's an "end host" in this context? The host at which the reservation is turned around? Ie, the thing that takes a PATH and generates a RESV. Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 13 21:34: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 VAA01112 for ; Fri, 13 Jun 2003 21:34:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5E1YKM09354 for nsis-archive@odin.ietf.org; Fri, 13 Jun 2003 21:34:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DJ91a30409; Fri, 13 Jun 2003 15:09:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DJ8lm30139 for ; Fri, 13 Jun 2003 15:08:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19464 for ; Fri, 13 Jun 2003 15:08:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qtsh-0000aJ-00 for nsis@ietf.org; Fri, 13 Jun 2003 15:06:35 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx with esmtp (Exim 4.12) id 19Qtsg-0000aG-00 for nsis@ietf.org; Fri, 13 Jun 2003 15:06:34 -0400 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h5DJ8due029385; Fri, 13 Jun 2003 15:08:39 -0400 (EDT) Message-ID: <3EEA2056.5020207@cs.columbia.edu> Date: Fri, 13 Jun 2003 15:04:54 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030603 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Allison Mankin CC: Michael Thomas , brunner@ccrle.nec.de, john.loughney@nokia.com, nsis@ietf.org Subject: Re: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt 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 Allison Mankin wrote: > Globally unique means a reasonably quite pseudo-random number > (because it isn't good to have the resources id'd as someone else's) > or a value that is sure to be unique. > > I'm not asking the document to take these ramblings in...just raising > thoughts. The interim meeting slides have an 'analysis' of the collision probability for different random number lengths, which were significantly lower than any other reasonable failure probabilities and similar to the probability that Earth will be obliterated by a meteor, from my recollection. I also believe that are no reasonable alternatives unless one assumes 1) every originator has a DNS name that is guaranteed to be unique and that it has easy access to (this isn't true without a working inverse mapping) or 2) every originator has a globally unique IP address (clearly iffy) or 3) we posit some global number handout algorithm system (maybe useful, but non-trivial; see multicast address assignment problem) Henning _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Fri Jun 13 22:35: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 WAA02871 for ; Fri, 13 Jun 2003 22:35:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5E2ZBP13087 for nsis-archive@odin.ietf.org; Fri, 13 Jun 2003 22:35:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DL61a18945; Fri, 13 Jun 2003 17:06:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DL5gm18900 for ; Fri, 13 Jun 2003 17:05:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22905 for ; Fri, 13 Jun 2003 17:05:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qvhr-0001CN-00 for nsis@ietf.org; Fri, 13 Jun 2003 17:03:31 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19Qvhq-0001Ba-00 for nsis@ietf.org; Fri, 13 Jun 2003 17:03:30 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h5DL4qwc004227; Fri, 13 Jun 2003 14:04:52 -0700 (PDT) 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.3.3-GR) with ESMTP id AFB54599; Fri, 13 Jun 2003 14:04:51 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA19337; Fri, 13 Jun 2003 14:04:51 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16106.15474.954924.470334@thomasm-u1.cisco.com> Date: Fri, 13 Jun 2003 14:04:50 -0700 (PDT) To: Melinda Shore Cc: Marcus Brunner , "Hancock, Robert" , "'Georgios Karagiannis'" , nsis@ietf.org Subject: Re: [NSIS] attempted summary of fragmentation discussion In-Reply-To: <200306121615.AIH60873@mira-sjc5-c.cisco.com> References: <13363035.1055427299@[10.1.1.130]> <200306121615.AIH60873@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 Melinda Shore writes: > Adding support for fragmentation will certainly increase the > code load, which may be an issue in memory-constrained > devices, but it will not meaningfully lengthen the execution > path since it's a quick check to see if you need to fragment > (if packet_length > pmtu) on the sender side and a quick > check to see if reassembly is required (if (frag_bit_is_set)) > on the receiver side. Path MTU will need to be determined > regardless of where fragmentation occurs and is a constant > cost unless there's a decision not to fragment at all, which > brings with it its own costs (and, for that matter, will > require PMTU discovery as well). Does PMTU (re)discovery always have to be from end host to end host? Mike _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Sun Jun 15 06:50: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 GAA28166 for ; Sun, 15 Jun 2003 06:50:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5FAoI223479 for nsis-archive@odin.ietf.org; Sun, 15 Jun 2003 06:50:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F6Y2a04466; Sun, 15 Jun 2003 02:34:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5F6Wum04445 for ; Sun, 15 Jun 2003 02:32:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24519 for ; Sun, 15 Jun 2003 02:32:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RR2H-0002CR-00 for nsis@ietf.org; Sun, 15 Jun 2003 02:30:41 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19RR2G-0002CO-00 for nsis@ietf.org; Sun, 15 Jun 2003 02:30:40 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19RR4L-0004zl-00; Sun, 15 Jun 2003 06:32:49 +0000 To: "Hancock, Robert" cc: nsis@ietf.org, mankin@psg.com Subject: Re: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt In-Reply-To: Message from "Hancock, Robert" of "Fri, 13 Jun 2003 09:16:27 BST." Date: Sat, 14 Jun 2003 23:32:46 -0700 From: Allison Mankin Message-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: , Robert, Specifics are necessary in the text; the problem was trying to encapsulate everything tersely in the phrase "non-traditional routing." It is an important problem and does deserve notice in the requirements. I recommend that the requirement be written with text such as you've written in this message, saying that NSIS should not break even though it passes through portions of the net in which these types of forwarding (the types enumerated) make it difficult to ensure that the data will follow the same path as the signaling message. Perhaps you can give Marcus a new text for the section. A few more comments inline. Allison > > i'll try to explain, hopefully in not too much detail. > > historical background to this requirement (for those needing it): > there was a long-ish discussion at the first NSIS interim (just > over a year ago) about problems in the path-finding process, i.e. that > two packets with the same destination address (e.g. a data packet > and a PATH message) might be routed differently. obviously an > NSIS processing node can be mandated not to do this, Even an NSIS processing node can't avoid the following problem, which would occur with any routing, even vanilla L3, and I think is not mentioned in the requirements document: the route changes between reservation refreshes and the data stream goes off the links that have reservations.. I can't find the message by Bob that you cite without having a Subject line (there are a number around that date and they don't obviously have this topic), but I think he would speak of this. Perhaps this needs to be added as another part of the same requirement. > but if the > data path crosses an NSIS-unaware cloud, the signalling and data paths > may split and be very difficult to recombine. the requirement > is basically trying to say: we should not ignore this problem, > although a general solution is recognised as hard. Bob provided > an excellent summary of the situation in an email to the list > (on or around 21/11/02, in my time zone). > > so, I think there are two parts to stating the requirement. > > one is, defining the circumstances where the splitting arises. this is > a combination of > a) NSIS-unaware node, and > b) makes a routing decision based on something other that L3 DA. > We never found a good name for things that do (b); policy forwarding > is part of it (some people call this policy routing which is not > the problem); another part is QoS routing (e.g. routing on ToS/DS value); > another part is load sharing using a hash of some part of the packet > header as a discriminator. These may or may not involve packet fields > above L3, including L4 switching and things like interception middleboxes > ("transparent" web caches), and may or may not involve L3 fields not > usually used in (unicast) routing, like L3 SA. > > maybe there is *no* good name for the set of circumstances covered by > (b), and the requirement should be phrased in terms of 'non-pure-L3-destination > - > address-routing' (although it's a bit of a mouthful), and accompanied by > some more background. There is no one name for the different types of routing, so yes, that is the better way to go. > > the other part of stating the requirement is to say what we should > try to achieve in these circumstances. i don't think a concrete target > can be set here, because a perfect solution is nearly provably impossible. > i think the main approach is that as the signalling packets that have to > follow the path look more and more like data packets the problem gets > less severe, but that's solution space, not a requirement. > > do you think that the concerns are reasonable and that a useful > requirement covering them can be written? in other words, is this only > a terminology/clarity issue? > As I said above, yes and yes. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Jun 16 05:05: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 FAA05906 for ; Mon, 16 Jun 2003 05:05:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5G94ZB16978 for nsis-archive@odin.ietf.org; Mon, 16 Jun 2003 05:04:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G7l2a12118; Mon, 16 Jun 2003 03:47:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5G7kpm12105 for ; Mon, 16 Jun 2003 03:46:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04609 for ; Mon, 16 Jun 2003 03:46:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RofL-0000W3-00 for nsis@ietf.org; Mon, 16 Jun 2003 03:44:35 -0400 Received: from mail5.telekom.de ([62.225.183.202] helo=mail1.telekom.de) by ietf-mx with esmtp (Exim 4.12) id 19RofL-0000Vx-00 for nsis@ietf.org; Mon, 16 Jun 2003 03:44:35 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 16 Jun 2003 09:46:13 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Jun 2003 09:46:13 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB4D0@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: mankin@psg.com Cc: nsis@ietf.org Subject: RE: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt Date: Mon, 16 Jun 2003 09:46:08 +0200 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: , Hello Allison, during my design efforts on a new backbone signaling protocol I came to the same conclusion as formulated by the requirement below. I don't think that it is mobility specific. Please note that also RFC 3175 simplifies the state addressing slightly (two IP addresses and a DSCP instead of RSVPs 5 tuple). It's a general requirement and should be kept unchanged. Regards, Rudiger | Allison Mankin writes: |> 5.4.3 State MUST be addressed independent of flow identification | [snip] |> No request |> to change this, but just noting how hard this is - WG is _sure_ |> the mobility requirements are really so important? _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Jun 16 12:19: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 MAA19618 for ; Mon, 16 Jun 2003 12:19:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GGIkS15675 for nsis-archive@odin.ietf.org; Mon, 16 Jun 2003 12:18:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GA92a21774; Mon, 16 Jun 2003 06:09:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GA8bm21754 for ; Mon, 16 Jun 2003 06:08:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07032 for ; Mon, 16 Jun 2003 06:08:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RqsX-00017I-00 for nsis@ietf.org; Mon, 16 Jun 2003 06:06:21 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19RqsW-00017F-00 for nsis@ietf.org; Mon, 16 Jun 2003 06:06:20 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h5GA8BCf001681; Mon, 16 Jun 2003 12:08:11 +0200 (MET DST) Message-ID: <006001c333ef$328652d0$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: , Cc: References: Subject: Re: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt Date: Mon, 16 Jun 2003 12:08:13 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Allison Regarding your comment on Section 5.7.5 about MUST implement and not a MUST use. Do you mean that the channel security between signaling entities MUST be implemented, but this does not mean that it should be used? Best Regards, Georgios ----- Original Message ----- From: "Allison Mankin" To: Cc: ; ; Sent: Monday, June 09, 2003 8:29 AM Subject: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt > Marcus, John and WG, > > Here are my AD Review comments on the NSIS requirements. Overall > it is a good document. I have a few problems on charter, technical > or clarity points. Discussion welcome. > > Allison > > -------- > However, QoS is not the only field where signaling > is used in the Internet. Others might be the use for middlebox > communication [RFC3234]. > > It would be helpful to clarify the manner in which signaling would be > used for middlebox communication (in one sentence) - this is so terse, that > only if a reader has been in the working group would they understand the > sentence. > > Suggestion: "Signaling might also be used as a communication protocol > to set up the state in middleboxes." > > -------- > > There are several areas related to networking aspects which are > incomplete, for example, interaction with host and site multi- > homing, use of anycast services, and so on. These issues should be > considered in any future analysis work. > > Incomplete in the sense of requirements analysis? This paragraph suggests > a different kind of analysis. Also anycast in particular seems very unlikely > to be a significant element in signaling requirements analysis - it seems > like it should not be mentioned in the same sentence with a common issue > like multihoming. > > Suggestion: "This document does not cover requirements in relation to some > networking areas, in particular, interaction with host and site multihoming. > We leave these for future analysis. " > > -------- > > NSIS Initiator - needs to say, in parallel with the NSIS Responder, > it interacts with applications (Definition does not say so). > > -------- > 3. Something that terminates the signaling path, the NSIS Responder. > > The NSIS responder might be in an end-system or within other > equipment. The distinguishing feature of the NSIS Initiator is that > ^^^^^^^^^ > it responds to requests at the end of a signaling path. > > Typo? s/Initiator/Responder/ > > -------- > The host to first > router part includes all the layer 2 technologies to access to the > Internet. > > Consider a home network with a wireless router and a DSL router accessing > the Internet. The topology definition is less crisp than host to *first* > router. I suggest you add a sentence after this one: "This part of the > division is especially informal and may incorporate several access segments." > -------- > > 5.2.2 NSIS MUST support path-coupled and SHOULD NOT exclude path- > decoupled signaling. > > SHOULD NOT is very strong, given that the WG is not chartered to work on > this technology. > > The language needs to be "MAY support path-decoupled signaling." > > -------- > > 5.3.2 Automatic release of state after failure SHOULD be possible > > When the NSIS Initiator goes down, the state it requested in the > network SHOULD be released, since it will no longer be necessary. > > An important feature of RSVP was its soft-state character, in part to > ensure that critical resources in the net were not fate-shared for too long. > Given this is about release after _failure_, these SHOULDs should be MUSTs, > if not going so far as to preserve the soft-state architecture. Comments? > > -------- > > > 5.4.3 State MUST be addressed independent of flow identification > > Addressing or identifying state MUST be independent of the flow > identifier (flow end-points, topological addresses). Various > scenarios in the mobility area require this independence because > flows resulting from handoff might have changed end-points etc. but > still have the same service requirement. Also several proxy-based > signaling methods profit from such independence. > > Add to the last sentence "though these are not chartered work items for > NSIS". > > This is a tough requirement since it has to be globally unique. It may > turn out to be best met by the NI's authentication token, requiring an > early integration of authentication design into the protocol. No request > to change this, but just noting how hard this is - WG is _sure_ > the mobility requirements are really so important? > > -------- > > > 5.4.1 Mutability information on parameters SHOULD be possible > > It SHOULD be possible for the NSIS initiator to control the > mutability of the signaled information. This prevents them from > being changed in a non-recoverable way. The NSIS initiator SHOULD be > able to control what is requested end to end, without the request > being gradually mutated as it passes through a sequence of domains. > This implies that in case of changes made on the parameters, the > original requested ones must still be available. > > Note that we do not require anything about particular parameters > being changed. > > Additionally, note that the provider of the particular requested > services can still influence the provisioning but in the signaling > message the request should stay the same. > > The requirement is not expressed well. Do you mean "It SHOULD be > possible to have nodes modify parameters to interact with the > signaling message, while still retaining an intact copy of the > original form of the signaling message"? > > This requirement seems like it would vary a great deal depending on what > the signaling application was, and as it is written here it is very close > to a protocol design rather than a requirement. Could you omit > it from this document? > > -------- > > One of the > reasons is that the protocol handling should have a minimal impact > on interior (core) nodes. > > Suggest adding that NSIS MAY also have a feature allowing core nodes > to ignore it (though I hope it will be more elegant than RSVP's as > document in RFC 3175 :) > > -------- > > 5.7.5 Hop-by-hop security > > Hop-by-Hop security SHOULD be supported. It is a well known and > proven concept in Quality-of-Service and other signaling protocols > that allows intermediate nodes that actively participate in the > protocol to modify the messages as it is required by processing > rules. Note that this requirement does not exclude end-to-end or > network-to-network security of a signaling message. End-to-end > security between the initiator and the responder may be used to > provide protection of non-mutable data fields. Network-to-network > security refers to the protection of messages over various hops but > not in an end-to-end manner i.e. protected over a particular network. > > Without minimum mandatory to implement channel security for the signaling, > you can't be sure the other security features will be untampered with - > this needs to be a MUST implement (it's not a MUST use). Suggest changing > the first sentence to "Channel security between signaling entities > MUST be implemented'? > > -------- > > > 5.9.5 SHOULD interwork with seamless handoff protocols > > 5.9.6 MAY interwork with non-traditional routing > > NSIS assumes L3 routing, but networks, which do non-traditional > routing, should not break it. > > NSIS should not be complex and interworked in ways that make it less modular. > Both of these requirements are complications. The first one, because it poses > a certain environment and particular protocols, would make NSIS less modular. > It is probably improved by changing SHOULD to MAY. The second one may sound > worse than it is - does it mean NATs? Suggest this might have meant: > > 5.9.6. MAY operate in varied routing environments > > NSIS assumes L3 routing, but it MAY be designed to operate in > varied routing environments, such as those with L4 switches and NATs. > > But if not, do explain... > -------- > > Scenarios - > > 's' as an abbreviation is not explained. > > -------- > 10.2 > > The 3G Scenario is somewhat too specific to 3GPP and 3GPP2 still - IMS is > mentioned without being expanded or explained. All the terms are specific. > Try to make it a bit more abstract - say it is an All-IP multimedia system. > > -------- > This part of the wireless network has different > characteristics when compared to traditional IP networks: > > 1. The network supports a high proportion of real-time > traffic. The majority of the traffic transported in the > wired part of the wireless network is speech, which is > very sensitive to delays and delay variation (jitter). > > Two things about IP networks - they carry whatever they carry, so > it's not out of tradition to be a voice IP network. Second, speech in > Internet phones is quite a lot less sensitive to delays and jitter than > often thought, due to the many good engineering designs in playout and > speech cover that are known. So this material places a context of more > difference on the environment than most general transport experts view > as necessary, seeing more continuum, while not disagreeing that signaling > and resource reservation are valuable. > > So drop sentence 1, but leave the rest alone (I just wanted to make my point :) > > -------- > > > 10.10 Application request end-to-end QoS path from the network > > This is actually the easiest case, nevertheless might be most often > used in terms of number of users. > > Few believe that ordinary applications signaling for QoS is an easy matter for > the network - RFCs 2961, 2996 and 3175 are all about mitigating the unscalability > of edge signaling. Probably this would go better if you substitute the term > "conceptually simplest" for "easiest" and note that there are these issues with > scaling. > > > Additionally, we assume no mobility and standard devices. > > Note: the end system application and NSIS do not know about the > distinction between 10.10 and the other scenarios :), unless NSIS is not > a modular Internet protocol. > > -------- > > QoS for Virtual Private Networks - section needs a number > > IP-Sec -> IPSec > > The discussion of NSIS in VPNs ignores the whole world of the PPVPN WG. > Cite draft-ietf-ppvpn-framework-08.txt early on in the section (it is in the > RFC-Editor Queue). > > > > Allison > > > _______________________________________________ > 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 Jun 16 17:51: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 RAA04318 for ; Mon, 16 Jun 2003 17:51:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GLoYu07834 for nsis-archive@odin.ietf.org; Mon, 16 Jun 2003 17:50:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GEU2a06883; Mon, 16 Jun 2003 10:30:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GETrm06841 for ; Mon, 16 Jun 2003 10:29:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15984 for ; Mon, 16 Jun 2003 10:29:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RuxM-0002xm-00 for nsis@ietf.org; Mon, 16 Jun 2003 10:27:36 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19RuxL-0002xj-00 for nsis@ietf.org; Mon, 16 Jun 2003 10:27:35 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5GETnw2010616; Mon, 16 Jun 2003 16:29:49 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 16 Jun 2003 16:31:34 +0200 Message-ID: From: "Attila Bader (ETH)" To: mankin@psg.com Cc: nsis@ietf.org Subject: RE: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt Date: Mon, 16 Jun 2003 16:27:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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 Allison, I do not completely understand your argument for MUST implementation of hop-by-hop security. 'Must be implemented but not must use' means that there is the possibility to use hop-by-hop security in any NE but it has to be implemented even if it is never used. 'SHOULD be supported' means that it has to be implemented except in particular cases. I think it is strong enough. Best regards, Attila > > 5.7.5 Hop-by-hop security > > Hop-by-Hop security SHOULD be supported. It is a well known and > proven concept in Quality-of-Service and other signaling protocols > that allows intermediate nodes that actively participate in the > protocol to modify the messages as it is required by processing > rules. Note that this requirement does not exclude end-to-end or > network-to-network security of a signaling message. End-to-end > security between the initiator and the responder may be used to > provide protection of non-mutable data fields. Network-to-network > security refers to the protection of messages over various > hops but > not in an end-to-end manner i.e. protected over a > particular network. > > Without minimum mandatory to implement channel security for > the signaling, > you can't be sure the other security features will be > untampered with - > this needs to be a MUST implement (it's not a MUST use). > Suggest changing > the first sentence to "Channel security between signaling entities > MUST be implemented'? > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Mon Jun 16 20:58:11 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 UAA10946 for ; Mon, 16 Jun 2003 20:58:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H0vhQ20735 for nsis-archive@odin.ietf.org; Mon, 16 Jun 2003 20:57:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GLX1a06324; Mon, 16 Jun 2003 17:33:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GLW8m06298 for ; Mon, 16 Jun 2003 17:32:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03607 for ; Mon, 16 Jun 2003 17:32:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S1Xy-000797-00 for nsis@ietf.org; Mon, 16 Jun 2003 17:29:50 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19S1Xy-00078z-00 for nsis@ietf.org; Mon, 16 Jun 2003 17:29:50 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5GLVVpa020024; Mon, 16 Jun 2003 14:31:32 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIL17276; Mon, 16 Jun 2003 14:31:31 -0700 (PDT) Message-Id: <200306162131.AIL17276@mira-sjc5-c.cisco.com> To: "Attila Bader (ETH)" cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt In-Reply-To: Message from Attila.Bader@eth.ericsson.se of "Mon, 16 Jun 2003 16:27:47 +0200." Date: Mon, 16 Jun 2003 17:31:30 -0400 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 do not completely understand your argument for MUST > implementation of hop-by-hop security. 'Must be > implemented but not must use' means that there is the > possibility to use hop-by-hop security in any NE but it > has to be implemented even if it is never used. 'SHOULD be > supported' means that it has to be implemented except in > particular cases. I think it is strong enough. "SHOULD be supported" does not mean what you say it means. For practical purposes, if hop-by-hop security is a must-implement, then failing to do so results in a non-interoperable implementation. If hop-by-hop security is a should-implement, then failing to do so does not result in a non-interoperable implementation. Given the consequences of a successful attack against this protocol, which could range from dinking with QoS signaling (and all that implies) to opening firewall pinholes to installing bogus address maps in a NAT, it seems perfectly reasonable to have mandatory-to-implement security mechanisms. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Jun 17 01:56: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 BAA18019 for ; Tue, 17 Jun 2003 01:56:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H5uBm10102 for nsis-archive@odin.ietf.org; Tue, 17 Jun 2003 01:56:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H41Ga01419; Tue, 17 Jun 2003 00:01:16 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H40mm01352 for ; Tue, 17 Jun 2003 00:00:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15596 for ; Tue, 17 Jun 2003 00:00:44 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S7c5-0002Gs-00 for nsis@ietf.org; Mon, 16 Jun 2003 23:58:29 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19S7c4-0002Gn-00 for nsis@ietf.org; Mon, 16 Jun 2003 23:58:29 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5H40ha04034 for ; Tue, 17 Jun 2003 07:00:43 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 17 Jun 2003 07:00:43 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 17 Jun 2003 07:00:43 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 17 Jun 2003 07:00:43 +0300 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] AD Review comments on draft-ietf-nsis-req-07.txt Date: Tue, 17 Jun 2003 07:00:40 +0300 Message-ID: Thread-Topic: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt Thread-Index: AcM0TTesmPgTSA3ZQA2lIRTcj+fz4QAN4Khw To: , Cc: X-OriginalArrivalTime: 17 Jun 2003 04:00:43.0380 (UTC) FILETIME=[06146340:01C33485] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5H40nm01360 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 Attila, > I do not completely understand your argument for MUST > implementation of hop-by-hop security. 'Must be implemented > but not must use' means that there is the possibility to use > hop-by-hop security in any NE but it has to be implemented > even if it is never used. 'SHOULD be supported' means that it > has to be implemented except in particular cases. I think it > is strong enough. We are designing this for the Internet (see the 'I' in the IETF). This being so, security is extremely important and is needed to ensure a robust protocol that is resistant to DoS attacks; protects infrastructure, etc. In this way: Channel security between signaling entities MUST be implemented. seems perfectly reasonable. Sysadmins, etc., can decide if it needs to be turned on or not. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Jun 17 07:17:11 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 HAA07036 for ; Tue, 17 Jun 2003 07:17:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HBGgx18514 for nsis-archive@odin.ietf.org; Tue, 17 Jun 2003 07:16:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H8J2a04913; Tue, 17 Jun 2003 04:19:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H8Ivm04902 for ; Tue, 17 Jun 2003 04:18:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03538 for ; Tue, 17 Jun 2003 04:18:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SBdw-00042y-00 for nsis@ietf.org; Tue, 17 Jun 2003 04:16:40 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19SBdv-00042v-00 for nsis@ietf.org; Tue, 17 Jun 2003 04:16:39 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h5H8ImCf009806; Tue, 17 Jun 2003 10:18:48 +0200 (MET DST) Message-ID: <002e01c334a9$14c5f1a0$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Melinda Shore" Cc: , "Attila Bader \(ETH\)" References: <200306162131.AIL17276@mira-sjc5-c.cisco.com> Subject: Re: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt Date: Tue, 17 Jun 2003 10:18:49 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Melinda > For practical purposes, if hop-by-hop security is a > must-implement, then failing to do so results in a > non-interoperable implementation. If hop-by-hop security is > a should-implement, then failing to do so does not result in > a non-interoperable implementation. It depends where the hop-by hop security is implemented. For example in one administrative domain (with trust relashionships between NSIS peers) hop-by-hop security must be implemented on the NSIS edge nodes, without requiring that hop-by-hop security is implemented in the NSIS interior nodes. Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Jun 17 07:55: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 HAA08115 for ; Tue, 17 Jun 2003 07:55:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HBt3j20789 for nsis-archive@odin.ietf.org; Tue, 17 Jun 2003 07:55:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H882a04271; Tue, 17 Jun 2003 04:08:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H878m03476 for ; Tue, 17 Jun 2003 04:07:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03105 for ; Tue, 17 Jun 2003 04:07:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SBSV-0003zm-00 for nsis@ietf.org; Tue, 17 Jun 2003 04:04:51 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19SBSU-0003zj-00 for nsis@ietf.org; Tue, 17 Jun 2003 04:04:50 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h5H873Cf009343; Tue, 17 Jun 2003 10:07:03 +0200 (MET DST) Message-ID: <002301c334a7$7079f750$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: , , Cc: References: Subject: Re: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt Date: Tue, 17 Jun 2003 10:07:04 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 > We are designing this for the Internet (see the 'I' in the > IETF). This being so, security is extremely important and > is needed to ensure a robust protocol that is resistant > to DoS attacks; protects infrastructure, etc. In this > way: You are right, but there are situations where security can be provided, without adding additional functionality into the protocol. For example, the security threats within a trusted administrative domain are different then the security threats in a inter-domain communication. Therefore, the security features required in these two situations are different. Best Regards, Georgios _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Jun 17 09:41: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 JAA15449 for ; Tue, 17 Jun 2003 09:41:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HDexw29455 for nsis-archive@odin.ietf.org; Tue, 17 Jun 2003 09:40:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HBf3a20307; Tue, 17 Jun 2003 07:41:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HBeWm20295 for ; Tue, 17 Jun 2003 07:40:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07760 for ; Tue, 17 Jun 2003 07:40:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SEn0-00056J-00 for nsis@ietf.org; Tue, 17 Jun 2003 07:38:14 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19SEmz-000561-00 for nsis@ietf.org; Tue, 17 Jun 2003 07:38:13 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h5HBdU6p029502; Tue, 17 Jun 2003 04:39:31 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIL78197; Tue, 17 Jun 2003 04:39:30 -0700 (PDT) Message-Id: <200306171139.AIL78197@mira-sjc5-c.cisco.com> To: "Georgios Karagiannis" cc: nsis@ietf.org, "Attila Bader \(ETH\)" From: Melinda Shore Subject: Re: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt In-Reply-To: Message from karagian@cs.utwente.nl of "Tue, 17 Jun 2003 10:18:49 +0200." <002e01c334a9$14c5f1a0$4c0d5982@dynamic.cs.utwente.nl> Date: Tue, 17 Jun 2003 07:39:29 -0400 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: , > It depends where the hop-by hop security is implemented. > For example in one administrative domain (with trust > relashionships between NSIS peers) hop-by-hop security > must be implemented on the NSIS edge nodes, without > requiring that hop-by-hop security is implemented in the > NSIS interior nodes. That's optional-to-use, not optional-to-implement. Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Jun 17 10:02:11 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 KAA16361 for ; Tue, 17 Jun 2003 10:02:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HE1h830316 for nsis-archive@odin.ietf.org; Tue, 17 Jun 2003 10:01:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H8N2a05222; Tue, 17 Jun 2003 04:23:02 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H8MYm05211 for ; Tue, 17 Jun 2003 04:22:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03566 for ; Tue, 17 Jun 2003 04:22:32 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SBhR-00043v-00 for nsis@ietf.org; Tue, 17 Jun 2003 04:20:17 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19SBhP-00043m-00 for nsis@ietf.org; Tue, 17 Jun 2003 04:20:15 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5H8Lea13243 for ; Tue, 17 Jun 2003 11:21:40 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 17 Jun 2003 11:20:25 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 17 Jun 2003 11:20:25 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 17 Jun 2003 11:20:25 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 17 Jun 2003 11:20:25 +0300 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] AD Review comments on draft-ietf-nsis-req-07.txt Date: Tue, 17 Jun 2003 11:20:24 +0300 Message-ID: Thread-Topic: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt Thread-Index: AcM0p9aYaKlYfBlETM6iOMj1z9BkugAAN3xw To: Cc: X-OriginalArrivalTime: 17 Jun 2003 08:20:25.0049 (UTC) FILETIME=[4D7A6490:01C334A9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5H8MYm05212 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, > You are right, but there are situations where security can be provided, > without adding additional functionality into the protocol. What we are requiring is not that NSIS develop new mechanism, but support existing ones. > For example, the security threats within a trusted administrative domain are > different then the security threats in a inter-domain communication. Therefore, the > security features required in these two situations are different. Can you give me a pointer to where a 'trusted administrative domain' is defined, especially in IETF literature? As I understand, trusted domains are not accepted in the IETF as proper security mechanisms. We have had this discussion in the SIGTRAN wg, and the IESG told us that trusted networks was not a good model, and asked us to reconsider this. The result can be found here: http://www.ietf.org/internet-drafts/draft-ietf-sigtran-security-02.txt br, John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From mailnull@www1.ietf.org Tue Jun 17 11:28: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 LAA22593 for ; Tue, 17 Jun 2003 11:28:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HFSAP05333 for nsis-archive@odin.ietf.org; Tue, 17 Jun 2003 11:28:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H7o2a01716; Tue, 17 Jun 2003 03:50:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5H7nNm01625 for ; Tue, 17 Jun 2003 03:49:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02256 for ; Tue, 17 Jun 2003 03:49:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SBBJ-0003nl-00 for nsis@ietf.org; Tue, 17 Jun 2003 03:47:05 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19SBBI-0003nh-00 for nsis@ietf.org; Tue, 17 Jun 2003 03:47:05 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h5H7nHCf008564; Tue, 17 Jun 2003 09:49:18 +0200 (MET DST) Message-ID: <001701c334a4$f5ad6bd0$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" Cc: References: Subject: Re: [NSIS] attempted summary of fragmentation discussion Date: Tue, 17 Jun 2003 09:49:19 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Robert > (another option would be to have no fragmentation functionality > in the NTLP at all, just 'packet too big' error reporting - > but that's not what's been proposed.) You are right, this could be also seen as a possible alternative. Best Regards, Georgios ----- Original Message ----- From: "Hancock, Robert" To: "Marcus Brunner" Cc: Sent: Friday, June 13, 2003 1:08 AM Subject: RE: [NSIS] attempted summary of fragmentation discussion > marcus, all, > > i still feel i am missing something in this argument. > apologies if this mail is a bit long. > > 1. georgios' proposal is to have fragmentation functionality > in the NTLP anyway, and just the option to not use it. > (another option would be to have no fragmentation functionality > in the NTLP at all, just 'packet too big' error reporting - > but that's not what's been proposed.) > ==> therefore it is a pure increase in complexity in the NTLP > compared to 'the NTLP does fragmentation' option. > > 2. if you believe fragmentation is a 'rare case', do it as > part of your exception handling software; the code needed for > fragmentation is trivial (certainly trivial compared to PMTU > discovery logic which is needed in the NTLP wherever fragmentation > is done, as Melinda points out below). > ==> we don't care either way in terms of NTLP complexity. > > 3. my more general concern is that the concept of PMTU discovery > has a number of non-trivial aspects associated with it - check out > the plpmtud bof notes from the last IETF (and rfc2923) for details > of how in the real world it doesn't really work as well as one > would like. while these problems are fixable (and indeed have to > be fixed for the NTLP, whichever approach we take) they appear to > me to be pointers that PMTU in the NSLP will architecturally fragile and something to be avoided > unless there is a pressing performance reason why it has to be done. in particular, > this approach will add an RTT to signalling setup times while the MTU is > discovered (unless the initial message in the exchange is small), and messages > will be black-holed unless the error reporting (which depends on backwards routing > per flow at every intermediate node) works perfectly. > ==> IMHO not doing fragmentation is a mechanism for storing up > deployment and design problems for the future . > > 4. so, maybe people are really concerned about performance issues. > here is an example: > > Signalling Messages > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > +-----------+ +-----------+ > |NSLP Source| +---------\ +------+ Thin Pipe | NSLP Sink | > +-----------+ |Fat Pipe > |NTLP 2| -----------> +-----------+ > | NTLP 1 | +---------/ +------+ | NTLP 3 | > +-----------+ +-----------+ > > (the pipes are fat and thin in the sense of being able to send > big or small messages). This case is I think the *most* favourable > to the "don't fragment at NTLP" viewpoint, because > *) if the NSLP is present at the intermediate nodes the question > of layering is moot > *) if the pipes are the other way round, fragmentation won't happen > anyway > > So, let's consider 4 cases for what happens when a big message > is sent source->sink. The emphasis of the analysis is on the > processing burden at Node 2. > a) Fragmentation at NTLP only: > Node 1 sends message > Node 2 NTLP executes the following > - receive incoming message into NTLP code > - process incoming message > - determine outgoing interface for route > - construct header for outgoing packets > - while (packet payload is left) > { send chunk of packet payload in fragment } > > b) Fragmentation optionally allowed at NSLP: > Because the NSLP designer and implementor don't believe in making > their own lives harder, the NSLP sends its message with 'fragmentation > allowed' anyway > ==> end result is the same as case (a) except with more complex > code because of the optional aspects which aren't being used > > c) Fragmentation happens at the NSLP (either because > the designer/implementor are blackmailed into it, or > because it is taken out of the NTLP): > Nodes 1 & 2 go through PMTU discovery procedure > Node 1 NSLP generates a sequence of message fragments > Node 1 NTLP bundles them back together into one or two > messages (depending on how much overhead is added) > Node 2 NTLP executes the following (once or twice) > - receive incoming message into NTLP code > - process incoming message bundle header > - for each message in bundle > { > - determine outgoing interface for route > - construct header for outgoing packet > - send outgoing packet > } > ==> to me, it isn't clear how this makes life easier for > NTLP at Node 2 (and the additional burden applies to any > other nodes between 1 and 2 as well). > > d) So, you don't like bundling after all? Take it out > altogether (but remember, the experience leading to 2961 was > that the step called 'receive' here is actually the dominant > element of the processing load): > Nodes 1 & 2 go through PMTU discovery procedure > Node 1 generates a sequence of message fragments, each sent > individually > Node 2 NTLP executes the following > - for each fragment > { > - receive incoming message into NTLP code > - determine outgoing interface for route > - construct header for outgoing packet > - send outgoing packet > } > ==> seems hardest of all (again, the extra load applies > everywhere upstream of node 2 as well). > > why is this wrong? > > cheers, > > robert h. > > > -----Original Message----- > > From: Melinda Shore [mailto:mshore@cisco.com] > > Sent: 12 June 2003 17:16 > > To: Marcus Brunner > > Cc: Hancock, Robert; 'Georgios Karagiannis'; nsis@ietf.org > > Subject: Re: [NSIS] attempted summary of fragmentation discussion > > > > > > > What I have not hear so far is the cost of having > > > fragmentation built into NTLP. Georgios and myself are > > > concerned that the NTLP gets too fat for high-speed > > > processing, so we try to avoid to design for the rare > > > cases such as fragmentation. > > > > Obviously we don't want to allow IP to fragment the packets, > > since this will remove our ability to support middlebox > > traversal. That means that either we don't allow any > > fragmentation or we handle fragmentation ourselves. If we > > handle fragmentation ourselves it's pretty clear that it > > needs to be handled lower in the stack rather than higher in > > the stack, primarily because we need to know the entire > > packet size in order to make correct fragmentation > > decisions. "Entire packet size" may include bundling but > > will certainly include authentication-related data, which > > can be quite large. Additionally there may be other TLVs > > in the header (for example, related to reliable delivery) > > that the upper layers will not know about and therefore not > > be able to factor into a fragmentation decision. > > > > Adding support for fragmentation will certainly increase the > > code load, which may be an issue in memory-constrained > > devices, but it will not meaningfully lengthen the execution > > path since it's a quick check to see if you need to fragment > > (if packet_length > pmtu) on the sender side and a quick > > check to see if reassembly is required (if (frag_bit_is_set)) > > on the receiver side. Path MTU will need to be determined > > regardless of where fragmentation occurs and is a constant > > cost unless there's a decision not to fragment at all, which > > brings with it its own costs (and, for that matter, will > > require PMTU discovery as well). > > > > 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 Jun 17 13:53: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 NAA28241 for ; Tue, 17 Jun 2003 13:53:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HHrKp05306 for nsis-archive@odin.ietf.org; Tue, 17 Jun 2003 13:53:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HBw8a20968; Tue, 17 Jun 2003 07:58:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HBvvm20915 for ; Tue, 17 Jun 2003 07:57:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08595 for ; Tue, 17 Jun 2003 07:57:56 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SF3s-0005Al-00 for nsis@ietf.org; Tue, 17 Jun 2003 07:55:40 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19SF3r-0005Ai-00 for nsis@ietf.org; Tue, 17 Jun 2003 07:55:39 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5HBvra04993 for ; Tue, 17 Jun 2003 14:57:53 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 17 Jun 2003 14:57:52 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 17 Jun 2003 14:57:51 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 17 Jun 2003 14:57:51 +0300 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] AD Review comments on draft-ietf-nsis-req-07.txt Date: Tue, 17 Jun 2003 14:57:50 +0300 Message-ID: Thread-Topic: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt Thread-Index: AcM0xUAMoWiZNu2KSMWoRlS5nClNvQAAa4DQ To: , , Cc: X-OriginalArrivalTime: 17 Jun 2003 11:57:51.0221 (UTC) FILETIME=[AD9A4250:01C334C7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5HBvvm20917 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, > > We are designing this for the Internet (see the 'I' in the > > IETF). This being so, security is extremely important and > > is needed to ensure a robust protocol that is resistant > > to DoS attacks; protects infrastructure, etc. In this > > way: > > You are right, but there are situations where security can be > provided, without adding additional functionality into the protocol. > > For example, the security threats within a trusted administrative domain are > different then the security threats in a inter-domain communication. Therefore, the > security features required in these two situations are different. Currently, the suggested text is: "Channel security between signaling entities MUST be implemented." As one cannot implement or mandate use in a trusted admin domain, I am not sure how to capture your concern. If there exists certain deployment scenarios where interior nodes don't have security associations, that is life. However, I doubt the security area will let us have a SHOULD for this requirement, as they have not let other working groups do that. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jun 17 14:17: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 OAA00287 for ; Tue, 17 Jun 2003 14:17:04 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HIGae13688 for nsis-archive@odin.ietf.org; Tue, 17 Jun 2003 14:16:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SKxC-00030G-NI; Tue, 17 Jun 2003 14:13:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus with esmtp (Exim 4.20) id 19SJao-0003WF-0e for nsis@optimus.ietf.org; Tue, 17 Jun 2003 12:45:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26000 for ; Tue, 17 Jun 2003 12:45:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SJYZ-0001gH-00 for nsis@ietf.org; Tue, 17 Jun 2003 12:43:39 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19SJYY-0001gE-00 for nsis@ietf.org; Tue, 17 Jun 2003 12:43:38 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h5HGjnCf029636; Tue, 17 Jun 2003 18:45:49 +0200 (MET DST) Message-ID: <00ff01c334ef$e9e71710$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: Cc: , "Marcus Brunner" , References: <22860231.1055436795@[10.1.1.130]> Subject: Re: [NSIS] Security Threats for NSIS draft Date: Tue, 17 Jun 2003 18:45:51 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Hannes I have read the last version of the "Security Threats for NSIS" draft and I think that it is very usefull. I agree with Marcus on the proposal of grouping the threats in: security threats and signaling related threats. Best Regards, Georgios ----- Original Message ----- From: "Marcus Brunner" To: ; Cc: Sent: Thursday, June 12, 2003 4:53 PM Subject: Re: [NSIS] Security Threats for NSIS draft > Hannes, > > We find the document very useful, the only thing we are not that happy with > is the grouping of the different threats. A proposal could be to group into > general security threats, signaling related, and NSIS specific. For people > know very well normal security threats it is tiring to go through the > document. > > And the format ID-nits etc. needs to be updated. > > Marcus & Miquel > > --On Donnerstag, 12. Juni 2003 10:25 +0300 john.loughney@nokia.com wrote: > > > Hannes, > > > > Any chance you'd get this submitted soon, I'd like to start WG call > > before Vienna. > > > >> Security Threats for NSIS > >> http://www.ietf.org/internet-drafts/draft-ietf-nsis-threats-01.txt > > > > thanks, > > John > > _______________________________________________ > > 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 > Mobile: +49 (0) 163 275 17 43 > personal home page: http://www.brubers.org/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 exim@www1.ietf.org Tue Jun 17 18:33: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 SAA14804 for ; Tue, 17 Jun 2003 18:33:27 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HMX1018816 for nsis-archive@odin.ietf.org; Tue, 17 Jun 2003 18:33:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SP0e-0004tN-Nk; Tue, 17 Jun 2003 18:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SP0A-0004tB-Lb for nsis@optimus.ietf.org; Tue, 17 Jun 2003 18:32:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14786 for ; Tue, 17 Jun 2003 18:32:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SOxu-0005ck-00 for nsis@ietf.org; Tue, 17 Jun 2003 18:30:10 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19SOxu-0005ch-00 for nsis@ietf.org; Tue, 17 Jun 2003 18:30:10 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jun 2003 23:32:26 +0100 Message-ID: From: "Hancock, Robert" To: Michael Thomas , Melinda Shore Cc: nsis@ietf.org Subject: RE: [NSIS] attempted summary of fragmentation discussion Date: Tue, 17 Jun 2003 23:32:24 +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: , mike, i think at least one stage of PMTU discovery has to take place between (adjacent) NTLP peers. ICMP 'too big' messages from between the two will be hard for any other type of end system (whatever 'end' means) to interpret, given the manipulations that might be done by the NTLP; if the NTLP is providing channel level security, no-one else will even be able to tell what message it is that is too big. NTLP-level PMTU discovery is a load for the NTLP, but it seems unavoidable to me - especially if NTLP messages themselves need fragmentation. if the NTLP itself does all the fragmentation, that's clearly all that is needed. if fragmentation is to be done at the NSLP, there needs to be a second 'outer' level of PMTU discovery. i would see this only being done between adjacent NSLP peers (of course, they could still be on opposite sides of the network), there doesn't seem to be any point in going further than that, only disadvantages. cheers, robert h. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, June 13, 2003 22:14 > To: Melinda Shore > Cc: Michael Thomas; nsis@ietf.org > Subject: Re: [NSIS] attempted summary of fragmentation discussion > > > Melinda Shore writes: > > > Does PMTU (re)discovery always have to be from > > > end host to end host? > > > > What's an "end host" in this context? > > The host at which the reservation is turned > around? Ie, the thing that takes a PATH and > generates a RESV. > > Mike > _______________________________________________ > 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 exim@www1.ietf.org Tue Jun 17 18:34: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 SAA14906 for ; Tue, 17 Jun 2003 18:34:27 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HMY1J19100 for nsis-archive@odin.ietf.org; Tue, 17 Jun 2003 18:34:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SP1d-0004xy-7Q; Tue, 17 Jun 2003 18:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SP0j-0004vL-3u for nsis@optimus.ietf.org; Tue, 17 Jun 2003 18:33:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14795 for ; Tue, 17 Jun 2003 18:33:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SOyT-0005d2-00 for nsis@ietf.org; Tue, 17 Jun 2003 18:30:45 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19SOyS-0005cn-00 for nsis@ietf.org; Tue, 17 Jun 2003 18:30:44 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jun 2003 23:32:31 +0100 Message-ID: From: "Hancock, Robert" To: nsis@ietf.org Date: Tue, 17 Jun 2003 23:32:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] yet another attempted summary of fragmentation discussion 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, Here is another attempt to summarise the fragmentation issues (for those who are still following). We have basically the same 4 options on the table: 1. Leave it up to the IP layer 2. Do it only in the NTLP 3. Do it only in the NSLP (NTLP provides information about how big fragments are allowed to be) 4. Combination of (2) and (3) - how a message is treated depends on a flag in it (for example). Arguments basically revolve around on concerns about the complexity and processing burden on the NTLP at nodes which wouldn't otherwise have to worry about fragmentation. Some factoids (the most interesting/controversial ones only): A) There are enough trivial/minor/annoying/insuperable concerns about relying on IP level fragmentation to rule out (1). B) For all the others, PMTU discovery has to be done at least at the NTLP level. For (3) and (4) it has to be done at the NSLP level as well (so there is some additional error handling needed in the NTLP). C) It's possible to implement the fragmentation so that reassembly is only needed at the destination NSLP node (whichever layer it actually takes place in). So, the processing cost we are moving around relates only to the fragmentation part. D) I believe that the processing cost tradeoff between (2) and (3) is just as likely to favour (2) as (3) so far as the 'vulnerable' NTLP node is concerned, and favours (2) for the other nodes on the path (see separate emails), especially when interactions with bundling are taken into account. I certainly don't believe the 'fragmentation is obviously expensive' argument. E) (4) is the most algorithmically functionally complex of all the solutions for both layers. F) Fragmentation itself as functionality is not complex (it takes about 5 pages to describe the BSD code for IP in its full glory in Stevens). G) Fragmentation amplifies message loss rates. If you think that message loss is a problem, then fragmentation makes it a bigger problem; however, if you think that message loss is a problem, you probably believe in some kind of recovery (retransmission), which solves the problem anyway. As might come across, I'm still a fan of (2) as a resolution of the argument; I certainly don't see many stones left un-turned in the discussion so far. I'd like to move on to the next open issue (congestion and flow control, IMHO much more tricky and interesting). Any ideas on how to do that sooner rather than later? cheers, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jun 17 18:46: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 SAA15297 for ; Tue, 17 Jun 2003 18:46:26 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HMk0t21471 for nsis-archive@odin.ietf.org; Tue, 17 Jun 2003 18:46:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SPDE-0005aC-Bf; Tue, 17 Jun 2003 18:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SPD2-0005a1-2w for nsis@optimus.ietf.org; Tue, 17 Jun 2003 18:45:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15282 for ; Tue, 17 Jun 2003 18:45:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SPAm-0005ht-00 for nsis@ietf.org; Tue, 17 Jun 2003 18:43:28 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by ietf-mx with esmtp (Exim 4.12) id 19SPAl-0005hn-00 for nsis@ietf.org; Tue, 17 Jun 2003 18:43:27 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5HMjCTr026847; Tue, 17 Jun 2003 15:45:12 -0700 (PDT) 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.3.3-GR) with ESMTP id AFE22289; Tue, 17 Jun 2003 15:45:11 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA05138; Tue, 17 Jun 2003 15:45:10 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16111.39414.786985.966016@thomasm-u1.cisco.com> Date: Tue, 17 Jun 2003 15:45:10 -0700 (PDT) To: "Hancock, Robert" Cc: Michael Thomas , Melinda Shore , nsis@ietf.org Subject: RE: [NSIS] attempted summary of fragmentation discussion 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 I apologize for being so obscure about where I was headed with this. One of the things that would be extremely advantageous with an NSIS is to pay close attention to local convergence issues on moves. That is, we would like to have a protocol which does not require round trips all the way to an end node -- which might be half a world away -- to heal a reservation from a move. It would be much better to only require signaling to the join point between the old and new location and no farther into the network. Thus, if PMTU discovery is required again upon arriving at a new attachment point, it's probably double plus ungood since I think that PMTU discovery is an end to end process. Naively, it would seem to be the case that you'd need to re-run PMTU discovery upon movement if you have MTU-size considerations. Mike Hancock, Robert writes: > mike, > > i think at least one stage of PMTU discovery has to take place between > (adjacent) NTLP peers. ICMP 'too big' messages from between the two will > be hard for any other type of end system (whatever 'end' means) to > interpret, > given the manipulations that might be done by the NTLP; if the NTLP is > providing channel level security, no-one else will even be able to tell > what message it is that is too big. NTLP-level PMTU discovery is a load > for the NTLP, but it seems unavoidable to me - especially if NTLP messages > themselves need fragmentation. > > if the NTLP itself does all the fragmentation, that's clearly all that is > needed. > > if fragmentation is to be done at the NSLP, there needs to be a second > 'outer' > level of PMTU discovery. i would see this only being done between adjacent > NSLP peers (of course, they could still be on opposite sides of the > network), > there doesn't seem to be any point in going further than that, only > disadvantages. > > cheers, > > robert h. > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Friday, June 13, 2003 22:14 > > To: Melinda Shore > > Cc: Michael Thomas; nsis@ietf.org > > Subject: Re: [NSIS] attempted summary of fragmentation discussion > > > > > > Melinda Shore writes: > > > > Does PMTU (re)discovery always have to be from > > > > end host to end host? > > > > > > What's an "end host" in this context? > > > > The host at which the reservation is turned > > around? Ie, the thing that takes a PATH and > > generates a RESV. > > > > Mike > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > > > > -- > Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, > Berkshire. RG12 8FZ > > The information contained in this e-mail and any attachments is confidential to > Roke Manor Research Ltd and must not be passed to any third party without > permission. This communication is for information only and shall not create or > change any contractual relationship. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jun 18 04:04: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 EAA23291 for ; Wed, 18 Jun 2003 04:04:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5I843b19975 for nsis-archive@odin.ietf.org; Wed, 18 Jun 2003 04:04:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SXvG-0005C4-J8; Wed, 18 Jun 2003 04:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SXux-0005Bo-6f for nsis@optimus.ietf.org; Wed, 18 Jun 2003 04:03:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23281 for ; Wed, 18 Jun 2003 04:03:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SXsh-0001Af-00 for nsis@ietf.org; Wed, 18 Jun 2003 04:01:23 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19SXsg-0001Ab-00 for nsis@ietf.org; Wed, 18 Jun 2003 04:01:22 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h5I83bCf021823; Wed, 18 Jun 2003 10:03:38 +0200 (MET DST) Message-ID: <001301c33570$20a4b3e0$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" , References: Subject: Re: [NSIS] yet another attempted summary of fragmentation discussion Date: Wed, 18 Jun 2003 10:03:39 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Robert I do not see how you came to the conclusion in (E) that option (4) is the most algorithmically functionally complex of all the solutions for both layers. If a NSLP chooses to use the NTLP fragmentation then the complexity is the same as (2) and if a NSLP does not need fragmentation then the complexity is actually reduced. I am still in favour of option (4). Best regards, Georgios ----- Original Message ----- From: "Hancock, Robert" To: Sent: Wednesday, June 18, 2003 12:32 AM Subject: [NSIS] yet another attempted summary of fragmentation discussion > Dear all, > > Here is another attempt to summarise the fragmentation issues > (for those who are still following). > > We have basically the same 4 options on the table: > 1. Leave it up to the IP layer > 2. Do it only in the NTLP > 3. Do it only in the NSLP (NTLP provides information about how > big fragments are allowed to be) > 4. Combination of (2) and (3) - how a message is treated depends > on a flag in it (for example). > > Arguments basically revolve around on concerns about the complexity > and processing burden on the NTLP at nodes which wouldn't otherwise > have to worry about fragmentation. > > Some factoids (the most interesting/controversial ones only): > A) There are enough trivial/minor/annoying/insuperable concerns > about relying on IP level fragmentation to rule out (1). > B) For all the others, PMTU discovery has to be done at least > at the NTLP level. For (3) and (4) it has to be done at the > NSLP level as well (so there is some additional error handling > needed in the NTLP). > C) It's possible to implement the fragmentation so that reassembly > is only needed at the destination NSLP node (whichever layer it > actually takes place in). So, the processing cost we are moving around > relates only to the fragmentation part. > D) I believe that the processing cost tradeoff between (2) and (3) > is just as likely to favour (2) as (3) so far as the 'vulnerable' > NTLP node is concerned, and favours (2) for the other nodes on the > path (see separate emails), especially when interactions with bundling > are taken into account. I certainly don't believe the 'fragmentation > is obviously expensive' argument. > E) (4) is the most algorithmically functionally complex of all the > solutions for both layers. > F) Fragmentation itself as functionality is not complex (it takes > about 5 pages to describe the BSD code for IP in its full glory in > Stevens). > G) Fragmentation amplifies message loss rates. If you think that > message loss is a problem, then fragmentation makes it a bigger problem; > however, if you think that message loss is a problem, you probably > believe in some kind of recovery (retransmission), which solves > the problem anyway. > > As might come across, I'm still a fan of (2) as a resolution of the > argument; I certainly don't see many stones left un-turned in the > discussion so far. > > I'd like to move on to the next open issue (congestion and flow control, > IMHO much more tricky and interesting). Any ideas on how to do that > sooner rather than later? > > 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 exim@www1.ietf.org Wed Jun 18 04: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 EAA24217 for ; Wed, 18 Jun 2003 04:40:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5I8e1Z24968 for nsis-archive@odin.ietf.org; Wed, 18 Jun 2003 04:40:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYU5-0006Uc-FL; Wed, 18 Jun 2003 04:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYTD-0006To-2U for nsis@optimus.ietf.org; Wed, 18 Jun 2003 04:39:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24190 for ; Wed, 18 Jun 2003 04:39:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SYQx-0001Pp-00 for nsis@ietf.org; Wed, 18 Jun 2003 04:36:47 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19SYQw-0001PY-00 for nsis@ietf.org; Wed, 18 Jun 2003 04:36:46 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jun 2003 09:38:34 +0100 Message-ID: From: "Hancock, Robert" To: "'Georgios Karagiannis'" , nsis@ietf.org Subject: RE: [NSIS] yet another attempted summary of fragmentation discuss ion Date: Wed, 18 Jun 2003 09:38:33 +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: , georgios, (4) is more complex than (2) because *) both need fragmentation capability in the NTLP *) only (4) needs MTU reporting from the NTLP *) only (4) needs fragmentation capability in the NSLP *) only (4) needs setting/processing of a 'DF' bit (4) is more complex than (3) because *) both need fragmentation capability in the NSLP *) both need MTU reporting from the NTLP *) only (4) needs fragmentation capability in the NTLP *) only (4) needs setting/processing of a 'DF' bit it may be that what I understand by (4) is not the same as what you are proposing; I'm afraid that can only be fixed by you actually defining what you are proposing in a form which other people can understand and evaluate. however, a pre-emptive point: if you are proposing a solution which allows *some* NSLP (i.e. not the one you are interested in, but someone else's) to generate a message that would need NTLP fragmentation, then I believe that the consequence is that *all* NTLP implementations will have to support fragmentation to be compliant with the standard we write. this is a general consequence of the "we don't design protocols for closed environments" attitude (see also the 'I in IETF' comment a few emails back). In other words, you can't just say 'well, the NSLP I care about only produces small messages so I won't bother with fragmentation at all'. Other people might like to comment on whether this assumption is sensible. cheers, r. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: Wednesday, June 18, 2003 09:04 > To: Hancock, Robert; nsis@ietf.org > Subject: Re: [NSIS] yet another attempted summary of fragmentation > discussion > > > Hi Robert > > I do not see how you came to the conclusion in > (E) that option (4) is the most algorithmically functionally > complex of all > the > solutions for both layers. > > If a NSLP chooses to use the NTLP fragmentation then the complexity is > the same as (2) and if a NSLP does not need fragmentation then the > complexity > is actually reduced. > > I am still in favour of option (4). > > Best regards, > Georgios > > ----- Original Message ----- > From: "Hancock, Robert" > To: > Sent: Wednesday, June 18, 2003 12:32 AM > Subject: [NSIS] yet another attempted summary of > fragmentation discussion > > > > Dear all, > > > > Here is another attempt to summarise the fragmentation issues > > (for those who are still following). > > > > We have basically the same 4 options on the table: > > 1. Leave it up to the IP layer > > 2. Do it only in the NTLP > > 3. Do it only in the NSLP (NTLP provides information about how > > big fragments are allowed to be) > > 4. Combination of (2) and (3) - how a message is treated depends > > on a flag in it (for example). > > > > Arguments basically revolve around on concerns about the complexity > > and processing burden on the NTLP at nodes which wouldn't otherwise > > have to worry about fragmentation. > > > > Some factoids (the most interesting/controversial ones only): > > A) There are enough trivial/minor/annoying/insuperable concerns > > about relying on IP level fragmentation to rule out (1). > > B) For all the others, PMTU discovery has to be done at least > > at the NTLP level. For (3) and (4) it has to be done at the > > NSLP level as well (so there is some additional error handling > > needed in the NTLP). > > C) It's possible to implement the fragmentation so that reassembly > > is only needed at the destination NSLP node (whichever layer it > > actually takes place in). So, the processing cost we are > moving around > > relates only to the fragmentation part. > > D) I believe that the processing cost tradeoff between (2) and (3) > > is just as likely to favour (2) as (3) so far as the 'vulnerable' > > NTLP node is concerned, and favours (2) for the other nodes on the > > path (see separate emails), especially when interactions > with bundling > > are taken into account. I certainly don't believe the 'fragmentation > > is obviously expensive' argument. > > E) (4) is the most algorithmically functionally complex of all the > > solutions for both layers. > > F) Fragmentation itself as functionality is not complex (it takes > > about 5 pages to describe the BSD code for IP in its full glory in > > Stevens). > > G) Fragmentation amplifies message loss rates. If you think that > > message loss is a problem, then fragmentation makes it a > bigger problem; > > however, if you think that message loss is a problem, you probably > > believe in some kind of recovery (retransmission), which solves > > the problem anyway. > > > > As might come across, I'm still a fan of (2) as a resolution of the > > argument; I certainly don't see many stones left un-turned in the > > discussion so far. > > > > I'd like to move on to the next open issue (congestion and > flow control, > > IMHO much more tricky and interesting). Any ideas on how to do that > > sooner rather than later? > > > > 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 exim@www1.ietf.org Wed Jun 18 04:50: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 EAA24342 for ; Wed, 18 Jun 2003 04:50:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5I8o1L25833 for nsis-archive@odin.ietf.org; Wed, 18 Jun 2003 04:50:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYdk-0006iA-VQ; Wed, 18 Jun 2003 04:50:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYdU-0006hm-9Z for nsis@optimus.ietf.org; Wed, 18 Jun 2003 04:49:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24324 for ; Wed, 18 Jun 2003 04:49:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SYbE-0001Sh-00 for nsis@ietf.org; Wed, 18 Jun 2003 04:47:24 -0400 Received: from h42s128a211n47.user.nortelnetworks.com ([47.211.128.42] helo=znsgs01r.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19SYbD-0001ST-00 for nsis@ietf.org; Wed, 18 Jun 2003 04:47:23 -0400 Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5I8n3610644; Wed, 18 Jun 2003 09:49:03 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jun 2003 09:49:04 +0100 Message-ID: From: "Daniel Warren" To: "'Hancock, Robert'" , "'Georgios Karagiannis'" , nsis@ietf.org Subject: RE: [NSIS] yet another attempted summary of fragmentation discuss ion Date: Wed, 18 Jun 2003 09:49:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33575.7B203A42" 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_01C33575.7B203A42 Content-Type: text/plain; charset="iso-8859-1" I was midway through drafting an almost identical mail. NTLP is a generic part that spans all NSLP's so just 'turning off' fragmentation for one NSLP, does not mean the functionality required to fragment messages vanishes altogether. It is only functionally less complex for that one NSLP, but makes NTLP algorithmically more complex at least because a 'does this NSLP want fragmentation?' check has to be included (among other things). Then for the case where the response is Yes, all of the fragmentation functionality in the NTLP still has to be present. But for the case where the answer is 'No', then either PMTU reporting is required so that the NSLP canensure that it's message fits in the pipes its going down, or there is a need for a lot more error handling when the PMTU is exceeded. Not surprisingly, I still support option 2, and I'd refer you back to my last mail for my rationale about why the 'flag' would be redundant anyway. Dan -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: 18 June 2003 09:39 To: 'Georgios Karagiannis'; nsis@ietf.org Subject: RE: [NSIS] yet another attempted summary of fragmentation discuss ion georgios, (4) is more complex than (2) because *) both need fragmentation capability in the NTLP *) only (4) needs MTU reporting from the NTLP *) only (4) needs fragmentation capability in the NSLP *) only (4) needs setting/processing of a 'DF' bit (4) is more complex than (3) because *) both need fragmentation capability in the NSLP *) both need MTU reporting from the NTLP *) only (4) needs fragmentation capability in the NTLP *) only (4) needs setting/processing of a 'DF' bit it may be that what I understand by (4) is not the same as what you are proposing; I'm afraid that can only be fixed by you actually defining what you are proposing in a form which other people can understand and evaluate. however, a pre-emptive point: if you are proposing a solution which allows *some* NSLP (i.e. not the one you are interested in, but someone else's) to generate a message that would need NTLP fragmentation, then I believe that the consequence is that *all* NTLP implementations will have to support fragmentation to be compliant with the standard we write. this is a general consequence of the "we don't design protocols for closed environments" attitude (see also the 'I in IETF' comment a few emails back). In other words, you can't just say 'well, the NSLP I care about only produces small messages so I won't bother with fragmentation at all'. Other people might like to comment on whether this assumption is sensible. cheers, r. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: Wednesday, June 18, 2003 09:04 > To: Hancock, Robert; nsis@ietf.org > Subject: Re: [NSIS] yet another attempted summary of fragmentation > discussion > > > Hi Robert > > I do not see how you came to the conclusion in > (E) that option (4) is the most algorithmically functionally > complex of all > the > solutions for both layers. > > If a NSLP chooses to use the NTLP fragmentation then the complexity is > the same as (2) and if a NSLP does not need fragmentation then the > complexity > is actually reduced. > > I am still in favour of option (4). > > Best regards, > Georgios > > ----- Original Message ----- > From: "Hancock, Robert" > To: > Sent: Wednesday, June 18, 2003 12:32 AM > Subject: [NSIS] yet another attempted summary of > fragmentation discussion > > > > Dear all, > > > > Here is another attempt to summarise the fragmentation issues > > (for those who are still following). > > > > We have basically the same 4 options on the table: > > 1. Leave it up to the IP layer > > 2. Do it only in the NTLP > > 3. Do it only in the NSLP (NTLP provides information about how > > big fragments are allowed to be) > > 4. Combination of (2) and (3) - how a message is treated depends > > on a flag in it (for example). > > > > Arguments basically revolve around on concerns about the complexity > > and processing burden on the NTLP at nodes which wouldn't otherwise > > have to worry about fragmentation. > > > > Some factoids (the most interesting/controversial ones only): > > A) There are enough trivial/minor/annoying/insuperable concerns > > about relying on IP level fragmentation to rule out (1). > > B) For all the others, PMTU discovery has to be done at least > > at the NTLP level. For (3) and (4) it has to be done at the > > NSLP level as well (so there is some additional error handling > > needed in the NTLP). > > C) It's possible to implement the fragmentation so that reassembly > > is only needed at the destination NSLP node (whichever layer it > > actually takes place in). So, the processing cost we are > moving around > > relates only to the fragmentation part. > > D) I believe that the processing cost tradeoff between (2) and (3) > > is just as likely to favour (2) as (3) so far as the 'vulnerable' > > NTLP node is concerned, and favours (2) for the other nodes on the > > path (see separate emails), especially when interactions > with bundling > > are taken into account. I certainly don't believe the 'fragmentation > > is obviously expensive' argument. > > E) (4) is the most algorithmically functionally complex of all the > > solutions for both layers. > > F) Fragmentation itself as functionality is not complex (it takes > > about 5 pages to describe the BSD code for IP in its full glory in > > Stevens). > > G) Fragmentation amplifies message loss rates. If you think that > > message loss is a problem, then fragmentation makes it a > bigger problem; > > however, if you think that message loss is a problem, you probably > > believe in some kind of recovery (retransmission), which solves > > the problem anyway. > > > > As might come across, I'm still a fan of (2) as a resolution of the > > argument; I certainly don't see many stones left un-turned in the > > discussion so far. > > > > I'd like to move on to the next open issue (congestion and > flow control, > > IMHO much more tricky and interesting). Any ideas on how to do that > > sooner rather than later? > > > > 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 ------_=_NextPart_001_01C33575.7B203A42 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] yet another attempted summary of fragmentation = discuss ion

I was midway through drafting an almost identical = mail.  NTLP is a generic part that spans all NSLP's so just = 'turning off' fragmentation for one NSLP, does not mean the = functionality required to fragment messages vanishes altogether.  = It is only functionally less complex for that one NSLP, but makes NTLP = algorithmically more complex at least because a 'does this NSLP want = fragmentation?' check has to be included (among other things).  = Then for the case where the response is Yes, all of the fragmentation = functionality in the NTLP still has to be present.  But for the = case where the answer is 'No', then either PMTU reporting is required = so that the NSLP canensure that it's message fits in the pipes its = going down, or there is a need for a lot more error handling when the = PMTU is exceeded.

Not surprisingly, I still support option 2, and I'd = refer you back to my last mail for my rationale about why the 'flag' = would be redundant anyway.

Dan

-----Original Message-----
From: Hancock, Robert [mailto:robert.hancock@roke.co.= uk]
Sent: 18 June 2003 09:39
To: 'Georgios Karagiannis'; nsis@ietf.org
Subject: RE: [NSIS] yet another attempted summary of = fragmentation
discuss ion


georgios,

(4) is more complex than (2) because
*) both need fragmentation capability in the = NTLP
*) only (4) needs MTU reporting from the NTLP
*) only (4) needs fragmentation capability in the = NSLP
*) only (4) needs setting/processing of a 'DF' = bit

(4) is more complex than (3) because
*) both need fragmentation capability in the = NSLP
*) both need MTU reporting from the NTLP
*) only (4) needs fragmentation capability in the = NTLP
*) only (4) needs setting/processing of a 'DF' = bit

it may be that what I understand by (4) is not the = same as what you
are proposing; I'm afraid that can only be fixed by = you actually
defining what you are proposing in a form which = other people
can understand and evaluate. however, a pre-emptive = point:

if you are proposing a solution which allows *some* = NSLP (i.e. not
the one you are interested in, but someone else's) = to generate a
message that would need NTLP fragmentation, then I = believe that the
consequence is that *all* NTLP implementations will = have to support
fragmentation to be compliant with the standard we = write. this is
a general consequence of the "we don't design = protocols for closed
environments" attitude (see also the 'I in = IETF' comment a few emails
back). In other words, you can't just say 'well, the = NSLP I care
about only produces small messages so I won't bother = with fragmentation
at all'.

Other people might like to comment on whether this = assumption is
sensible.

cheers,

r.

> -----Original Message-----
> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl= ]
> Sent: Wednesday, June 18, 2003 09:04
> To: Hancock, Robert; nsis@ietf.org
> Subject: Re: [NSIS] yet another attempted = summary of fragmentation
> discussion
>
>
> Hi Robert
>
> I do not see how you came to the conclusion = in
> (E) that option (4) is the most algorithmically = functionally
> complex of all
> the
> solutions for both layers.
>
> If a NSLP chooses to use the NTLP fragmentation = then the complexity is
> the same as (2) and if a NSLP does not need = fragmentation then the
> complexity
> is actually reduced.
>
> I am still in favour of option (4).
>
> Best regards,
> Georgios
>
> ----- Original Message -----
> From: "Hancock, Robert" = <robert.hancock@roke.co.uk>
> To: <nsis@ietf.org>
> Sent: Wednesday, June 18, 2003 12:32 AM
> Subject: [NSIS] yet another attempted summary = of
> fragmentation discussion
>
>
> > Dear all,
> >
> > Here is another attempt to summarise the = fragmentation issues
> > (for those who are still = following).
> >
> > We have basically the same 4 options on = the table:
> > 1. Leave it up to the IP layer
> > 2. Do it only in the NTLP
> > 3. Do it only in the NSLP (NTLP provides = information about how
> > big fragments are allowed to be)
> > 4. Combination of (2) and (3) - how a = message is treated depends
> > on a flag in it (for example).
> >
> > Arguments basically revolve around on = concerns about the complexity
> > and processing burden on the NTLP at nodes = which wouldn't otherwise
> > have to worry about fragmentation.
> >
> > Some factoids (the most = interesting/controversial ones only):
> > A) There are enough = trivial/minor/annoying/insuperable concerns
> > about relying on IP level fragmentation to = rule out (1).
> > B) For all the others, PMTU discovery has = to be done at least
> > at the NTLP level. For (3) and (4) it has = to be done at the
> > NSLP level as well (so there is some = additional error handling
> > needed in the NTLP).
> > C) It's possible to implement the = fragmentation so that reassembly
> > is only needed at the destination NSLP = node (whichever layer it
> > actually takes place in). So, the = processing cost we are
> moving around
> > relates only to the fragmentation = part.
> > D) I believe that the processing cost = tradeoff between (2) and (3)
> > is just as likely to favour (2) as (3) so = far as the 'vulnerable'
> > NTLP node is concerned, and favours (2) = for the other nodes on the
> > path (see separate emails), especially = when interactions
> with bundling
> > are taken into account. I certainly don't = believe the 'fragmentation
> > is obviously expensive' argument.
> > E) (4) is the most algorithmically = functionally complex of all the
> > solutions for both layers.
> > F) Fragmentation itself as functionality = is not complex (it takes
> > about 5 pages to describe the BSD code for = IP in its full glory in
> > Stevens).
> > G) Fragmentation amplifies message loss = rates. If you think that
> > message loss is a problem, then = fragmentation makes it a
> bigger problem;
> > however, if you think that message loss is = a problem, you probably
> > believe in some kind of recovery = (retransmission), which solves
> > the problem anyway.
> >
> > As might come across, I'm still a fan of = (2) as a resolution of the
> > argument; I certainly don't see many = stones left un-turned in the
> > discussion so far.
> >
> > I'd like to move on to the next open issue = (congestion and
> flow control,
> > IMHO much more tricky and interesting). = Any ideas on how to do that
> > sooner rather than later?
> >
> > 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=

------_=_NextPart_001_01C33575.7B203A42-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jun 18 04:51: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 EAA24359 for ; Wed, 18 Jun 2003 04:51:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5I8p2R26118 for nsis-archive@odin.ietf.org; Wed, 18 Jun 2003 04:51:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYek-0006n9-23; Wed, 18 Jun 2003 04:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYeB-0006ma-3F for nsis@optimus.ietf.org; Wed, 18 Jun 2003 04:50:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24339 for ; Wed, 18 Jun 2003 04:50:24 -0400 (EDT) From: louise.burness@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SYbv-0001T4-00 for nsis@ietf.org; Wed, 18 Jun 2003 04:48:07 -0400 Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt05.hc.bt.com) by ietf-mx with esmtp (Exim 4.12) id 19SYbu-0001Sr-00 for nsis@ietf.org; Wed, 18 Jun 2003 04:48:06 -0400 Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Wed, 18 Jun 2003 09:49:42 +0100 Message-ID: To: nsis@ietf.org Subject: RE: [NSIS] yet another attempted summary of fragmentation discuss ion Date: Wed, 18 Jun 2003 09:49:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message 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: , your assumption seems perfectly sensible to me, otherwise you are not building 2 protocols at all. btw (4) seems the most complex to me Lou -----Original Message----- From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] Sent: 18 June 2003 09:39 To: 'Georgios Karagiannis'; nsis@ietf.org Subject: RE: [NSIS] yet another attempted summary of fragmentation discussion georgios, (4) is more complex than (2) because *) both need fragmentation capability in the NTLP *) only (4) needs MTU reporting from the NTLP *) only (4) needs fragmentation capability in the NSLP *) only (4) needs setting/processing of a 'DF' bit (4) is more complex than (3) because *) both need fragmentation capability in the NSLP *) both need MTU reporting from the NTLP *) only (4) needs fragmentation capability in the NTLP *) only (4) needs setting/processing of a 'DF' bit it may be that what I understand by (4) is not the same as what you are proposing; I'm afraid that can only be fixed by you actually defining what you are proposing in a form which other people can understand and evaluate. however, a pre-emptive point: if you are proposing a solution which allows *some* NSLP (i.e. not the one you are interested in, but someone else's) to generate a message that would need NTLP fragmentation, then I believe that the consequence is that *all* NTLP implementations will have to support fragmentation to be compliant with the standard we write. this is a general consequence of the "we don't design protocols for closed environments" attitude (see also the 'I in IETF' comment a few emails back). In other words, you can't just say 'well, the NSLP I care about only produces small messages so I won't bother with fragmentation at all'. Other people might like to comment on whether this assumption is sensible. cheers, r. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: Wednesday, June 18, 2003 09:04 > To: Hancock, Robert; nsis@ietf.org > Subject: Re: [NSIS] yet another attempted summary of fragmentation > discussion > > > Hi Robert > > I do not see how you came to the conclusion in > (E) that option (4) is the most algorithmically functionally > complex of all > the > solutions for both layers. > > If a NSLP chooses to use the NTLP fragmentation then the complexity is > the same as (2) and if a NSLP does not need fragmentation then the > complexity > is actually reduced. > > I am still in favour of option (4). > > Best regards, > Georgios > > ----- Original Message ----- > From: "Hancock, Robert" > To: > Sent: Wednesday, June 18, 2003 12:32 AM > Subject: [NSIS] yet another attempted summary of > fragmentation discussion > > > > Dear all, > > > > Here is another attempt to summarise the fragmentation issues > > (for those who are still following). > > > > We have basically the same 4 options on the table: > > 1. Leave it up to the IP layer > > 2. Do it only in the NTLP > > 3. Do it only in the NSLP (NTLP provides information about how > > big fragments are allowed to be) > > 4. Combination of (2) and (3) - how a message is treated depends > > on a flag in it (for example). > > > > Arguments basically revolve around on concerns about the complexity > > and processing burden on the NTLP at nodes which wouldn't otherwise > > have to worry about fragmentation. > > > > Some factoids (the most interesting/controversial ones only): > > A) There are enough trivial/minor/annoying/insuperable concerns > > about relying on IP level fragmentation to rule out (1). > > B) For all the others, PMTU discovery has to be done at least > > at the NTLP level. For (3) and (4) it has to be done at the > > NSLP level as well (so there is some additional error handling > > needed in the NTLP). > > C) It's possible to implement the fragmentation so that reassembly > > is only needed at the destination NSLP node (whichever layer it > > actually takes place in). So, the processing cost we are > moving around > > relates only to the fragmentation part. > > D) I believe that the processing cost tradeoff between (2) and (3) > > is just as likely to favour (2) as (3) so far as the 'vulnerable' > > NTLP node is concerned, and favours (2) for the other nodes on the > > path (see separate emails), especially when interactions > with bundling > > are taken into account. I certainly don't believe the 'fragmentation > > is obviously expensive' argument. > > E) (4) is the most algorithmically functionally complex of all the > > solutions for both layers. > > F) Fragmentation itself as functionality is not complex (it takes > > about 5 pages to describe the BSD code for IP in its full glory in > > Stevens). > > G) Fragmentation amplifies message loss rates. If you think that > > message loss is a problem, then fragmentation makes it a > bigger problem; > > however, if you think that message loss is a problem, you probably > > believe in some kind of recovery (retransmission), which solves > > the problem anyway. > > > > As might come across, I'm still a fan of (2) as a resolution of the > > argument; I certainly don't see many stones left un-turned in the > > discussion so far. > > > > I'd like to move on to the next open issue (congestion and > flow control, > > IMHO much more tricky and interesting). Any ideas on how to do that > > sooner rather than later? > > > > 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jun 18 04:54: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 EAA24458 for ; Wed, 18 Jun 2003 04:54:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5I8s2427058 for nsis-archive@odin.ietf.org; Wed, 18 Jun 2003 04:54:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYhd-00072J-R1; Wed, 18 Jun 2003 04:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYgd-0006xu-Ty for nsis@optimus.ietf.org; Wed, 18 Jun 2003 04:52:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24423 for ; Wed, 18 Jun 2003 04:52:57 -0400 (EDT) From: maarten.buchli@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SYeN-0001Um-00 for nsis@ietf.org; Wed, 18 Jun 2003 04:50:39 -0400 Received: from alc245.alcatel.be ([195.207.101.245] helo=relay4.alcatel.be) by ietf-mx with esmtp (Exim 4.12) id 19SYeM-0001UR-00 for nsis@ietf.org; Wed, 18 Jun 2003 04:50:39 -0400 Received: from bemail05.net.alcatel.be (bemail05.net.alcatel.be [138.203.144.16]) by relay4.alcatel.be (8.12.9/8.12.9) with ESMTP id h5I91s1M014892 for ; Wed, 18 Jun 2003 11:01:54 +0200 Subject: RE: [NSIS] yet another attempted summary of fragmentation discuss ion To: "Hancock, Robert" Cc: "'Georgios Karagiannis'" , nsis@ietf.org Date: Wed, 18 Jun 2003 10:52:25 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 06/18/2003 10:52:25 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) 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, Your assumption that the protocols should not be designed for closed environment -or one particular NSLP- seems very sensible to me. Option 2 is my preference as well for reasons already detailed by you in previous mails. regards, Maarten "Hancock, Robert" @ietf.org on 18/06/2003 10:38:33 Sent by: nsis-admin@ietf.org To: "'Georgios Karagiannis'" , nsis@ietf.org cc: Subject: RE: [NSIS] yet another attempted summary of fragmentation discuss ion georgios, (4) is more complex than (2) because *) both need fragmentation capability in the NTLP *) only (4) needs MTU reporting from the NTLP *) only (4) needs fragmentation capability in the NSLP *) only (4) needs setting/processing of a 'DF' bit (4) is more complex than (3) because *) both need fragmentation capability in the NSLP *) both need MTU reporting from the NTLP *) only (4) needs fragmentation capability in the NTLP *) only (4) needs setting/processing of a 'DF' bit it may be that what I understand by (4) is not the same as what you are proposing; I'm afraid that can only be fixed by you actually defining what you are proposing in a form which other people can understand and evaluate. however, a pre-emptive point: if you are proposing a solution which allows *some* NSLP (i.e. not the one you are interested in, but someone else's) to generate a message that would need NTLP fragmentation, then I believe that the consequence is that *all* NTLP implementations will have to support fragmentation to be compliant with the standard we write. this is a general consequence of the "we don't design protocols for closed environments" attitude (see also the 'I in IETF' comment a few emails back). In other words, you can't just say 'well, the NSLP I care about only produces small messages so I won't bother with fragmentation at all'. Other people might like to comment on whether this assumption is sensible. cheers, r. > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: Wednesday, June 18, 2003 09:04 > To: Hancock, Robert; nsis@ietf.org > Subject: Re: [NSIS] yet another attempted summary of fragmentation > discussion > > > Hi Robert > > I do not see how you came to the conclusion in > (E) that option (4) is the most algorithmically functionally > complex of all > the > solutions for both layers. > > If a NSLP chooses to use the NTLP fragmentation then the complexity is > the same as (2) and if a NSLP does not need fragmentation then the > complexity > is actually reduced. > > I am still in favour of option (4). > > Best regards, > Georgios > > ----- Original Message ----- > From: "Hancock, Robert" > To: > Sent: Wednesday, June 18, 2003 12:32 AM > Subject: [NSIS] yet another attempted summary of > fragmentation discussion > > > > Dear all, > > > > Here is another attempt to summarise the fragmentation issues > > (for those who are still following). > > > > We have basically the same 4 options on the table: > > 1. Leave it up to the IP layer > > 2. Do it only in the NTLP > > 3. Do it only in the NSLP (NTLP provides information about how > > big fragments are allowed to be) > > 4. Combination of (2) and (3) - how a message is treated depends > > on a flag in it (for example). > > > > Arguments basically revolve around on concerns about the complexity > > and processing burden on the NTLP at nodes which wouldn't otherwise > > have to worry about fragmentation. > > > > Some factoids (the most interesting/controversial ones only): > > A) There are enough trivial/minor/annoying/insuperable concerns > > about relying on IP level fragmentation to rule out (1). > > B) For all the others, PMTU discovery has to be done at least > > at the NTLP level. For (3) and (4) it has to be done at the > > NSLP level as well (so there is some additional error handling > > needed in the NTLP). > > C) It's possible to implement the fragmentation so that reassembly > > is only needed at the destination NSLP node (whichever layer it > > actually takes place in). So, the processing cost we are > moving around > > relates only to the fragmentation part. > > D) I believe that the processing cost tradeoff between (2) and (3) > > is just as likely to favour (2) as (3) so far as the 'vulnerable' > > NTLP node is concerned, and favours (2) for the other nodes on the > > path (see separate emails), especially when interactions > with bundling > > are taken into account. I certainly don't believe the 'fragmentation > > is obviously expensive' argument. > > E) (4) is the most algorithmically functionally complex of all the > > solutions for both layers. > > F) Fragmentation itself as functionality is not complex (it takes > > about 5 pages to describe the BSD code for IP in its full glory in > > Stevens). > > G) Fragmentation amplifies message loss rates. If you think that > > message loss is a problem, then fragmentation makes it a > bigger problem; > > however, if you think that message loss is a problem, you probably > > believe in some kind of recovery (retransmission), which solves > > the problem anyway. > > > > As might come across, I'm still a fan of (2) as a resolution of the > > argument; I certainly don't see many stones left un-turned in the > > discussion so far. > > > > I'd like to move on to the next open issue (congestion and > flow control, > > IMHO much more tricky and interesting). Any ideas on how to do that > > sooner rather than later? > > > > 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 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jun 18 05:31: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 FAA25172 for ; Wed, 18 Jun 2003 05:31:28 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5I9V1230852 for nsis-archive@odin.ietf.org; Wed, 18 Jun 2003 05:31:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SZHQ-00081U-RJ; Wed, 18 Jun 2003 05:31:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SZGc-00080j-N6 for nsis@optimus.ietf.org; Wed, 18 Jun 2003 05:30:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25147 for ; Wed, 18 Jun 2003 05:30:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SZEM-0001g3-00 for nsis@ietf.org; Wed, 18 Jun 2003 05:27:50 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19SZEL-0001g0-00 for nsis@ietf.org; Wed, 18 Jun 2003 05:27:49 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h5I9U3Cf025554; Wed, 18 Jun 2003 11:30:04 +0200 (MET DST) Message-ID: <00a801c3357c$33d7bfa0$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" , References: Subject: Re: [NSIS] yet another attempted summary of fragmentation discussion Date: Wed, 18 Jun 2003 11:29:03 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Robert First of all I do not know how you could deduce that I am interested in a protocol that can be used for closed environments and not for the Internet!!!!!!. This is not true!!!!!! I am interested in a protocol that can be used for QoS signaling in a RAN used for third generation mobile systems. See section 10.4 in the NSIS requirements draft. This scenario, and are plenty of other scenarios, imposes strict requirements in terms of processing delays and scalability (performance of the network does not deterirates badly when the number of supported users is increased). NSIS can be used in such scenarios only if these strict requirements are met. Now assume that your option (2) is used: * the NTLP will have to find out, thus process even if the NSLP does not need fragmentation, if fragmentation is needed; * the NTLP will have to find out, thus process even if the NSLP does not need fragmentation, if reassembly is needed. Now assume the following option (3bis) is used : The NSLP and NTLP do not do fragmentation at all. In case of an error, e.g., if fragmentation is needed then the NTLP will send an error message back to the sender. When no fragmentation is needed then this option is the fastest and less complicated. I am in favour of combining the above two options (by using a "Do fragmentation" bit) then: * the NSLP's that do not need NTLP fragmentation will use the above option (2) * the NSLP's that do need fragmentation will use the above option (3bis). Best regards, Georgios ----- Original Message ----- From: "Hancock, Robert" To: "'Georgios Karagiannis'" ; Sent: Wednesday, June 18, 2003 10:38 AM Subject: RE: [NSIS] yet another attempted summary of fragmentation discussion > georgios, > > (4) is more complex than (2) because > *) both need fragmentation capability in the NTLP > *) only (4) needs MTU reporting from the NTLP > *) only (4) needs fragmentation capability in the NSLP > *) only (4) needs setting/processing of a 'DF' bit > > (4) is more complex than (3) because > *) both need fragmentation capability in the NSLP > *) both need MTU reporting from the NTLP > *) only (4) needs fragmentation capability in the NTLP > *) only (4) needs setting/processing of a 'DF' bit > > it may be that what I understand by (4) is not the same as what you > are proposing; I'm afraid that can only be fixed by you actually > defining what you are proposing in a form which other people > can understand and evaluate. however, a pre-emptive point: > > if you are proposing a solution which allows *some* NSLP (i.e. not > the one you are interested in, but someone else's) to generate a > message that would need NTLP fragmentation, then I believe that the > consequence is that *all* NTLP implementations will have to support > fragmentation to be compliant with the standard we write. this is > a general consequence of the "we don't design protocols for closed > environments" attitude (see also the 'I in IETF' comment a few emails > back). In other words, you can't just say 'well, the NSLP I care > about only produces small messages so I won't bother with fragmentation > at all'. > > Other people might like to comment on whether this assumption is > sensible. > > cheers, > > r. > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: Wednesday, June 18, 2003 09:04 > > To: Hancock, Robert; nsis@ietf.org > > Subject: Re: [NSIS] yet another attempted summary of fragmentation > > discussion > > > > > > Hi Robert > > > > I do not see how you came to the conclusion in > > (E) that option (4) is the most algorithmically functionally > > complex of all > > the > > solutions for both layers. > > > > If a NSLP chooses to use the NTLP fragmentation then the complexity is > > the same as (2) and if a NSLP does not need fragmentation then the > > complexity > > is actually reduced. > > > > I am still in favour of option (4). > > > > Best regards, > > Georgios > > > > ----- Original Message ----- > > From: "Hancock, Robert" > > To: > > Sent: Wednesday, June 18, 2003 12:32 AM > > Subject: [NSIS] yet another attempted summary of > > fragmentation discussion > > > > > > > Dear all, > > > > > > Here is another attempt to summarise the fragmentation issues > > > (for those who are still following). > > > > > > We have basically the same 4 options on the table: > > > 1. Leave it up to the IP layer > > > 2. Do it only in the NTLP > > > 3. Do it only in the NSLP (NTLP provides information about how > > > big fragments are allowed to be) > > > 4. Combination of (2) and (3) - how a message is treated depends > > > on a flag in it (for example). > > > > > > Arguments basically revolve around on concerns about the complexity > > > and processing burden on the NTLP at nodes which wouldn't otherwise > > > have to worry about fragmentation. > > > > > > Some factoids (the most interesting/controversial ones only): > > > A) There are enough trivial/minor/annoying/insuperable concerns > > > about relying on IP level fragmentation to rule out (1). > > > B) For all the others, PMTU discovery has to be done at least > > > at the NTLP level. For (3) and (4) it has to be done at the > > > NSLP level as well (so there is some additional error handling > > > needed in the NTLP). > > > C) It's possible to implement the fragmentation so that reassembly > > > is only needed at the destination NSLP node (whichever layer it > > > actually takes place in). So, the processing cost we are > > moving around > > > relates only to the fragmentation part. > > > D) I believe that the processing cost tradeoff between (2) and (3) > > > is just as likely to favour (2) as (3) so far as the 'vulnerable' > > > NTLP node is concerned, and favours (2) for the other nodes on the > > > path (see separate emails), especially when interactions > > with bundling > > > are taken into account. I certainly don't believe the 'fragmentation > > > is obviously expensive' argument. > > > E) (4) is the most algorithmically functionally complex of all the > > > solutions for both layers. > > > F) Fragmentation itself as functionality is not complex (it takes > > > about 5 pages to describe the BSD code for IP in its full glory in > > > Stevens). > > > G) Fragmentation amplifies message loss rates. If you think that > > > message loss is a problem, then fragmentation makes it a > > bigger problem; > > > however, if you think that message loss is a problem, you probably > > > believe in some kind of recovery (retransmission), which solves > > > the problem anyway. > > > > > > As might come across, I'm still a fan of (2) as a resolution of the > > > argument; I certainly don't see many stones left un-turned in the > > > discussion so far. > > > > > > I'd like to move on to the next open issue (congestion and > > flow control, > > > IMHO much more tricky and interesting). Any ideas on how to do that > > > sooner rather than later? > > > > > > 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 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jun 18 05:41: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 FAA25277 for ; Wed, 18 Jun 2003 05:41:28 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5I9f1X32592 for nsis-archive@odin.ietf.org; Wed, 18 Jun 2003 05:41:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SZR7-0008TJ-5p; Wed, 18 Jun 2003 05:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SZQK-0008Sr-4g for nsis@optimus.ietf.org; Wed, 18 Jun 2003 05:40:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25254 for ; Wed, 18 Jun 2003 05:40:09 -0400 (EDT) From: louise.burness@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SZO3-0001hb-00 for nsis@ietf.org; Wed, 18 Jun 2003 05:37:51 -0400 Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt08.hc.bt.com) by ietf-mx with esmtp (Exim 4.12) id 19SZO2-0001hR-00 for nsis@ietf.org; Wed, 18 Jun 2003 05:37:51 -0400 Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Wed, 18 Jun 2003 10:39:26 +0100 Message-ID: To: nsis@ietf.org Subject: RE: [NSIS] yet another attempted summary of fragmentation discuss ion Date: Wed, 18 Jun 2003 10:39:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message 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 Could you please explain what exactly are the strict requirements that must be met for 3G systems? Further isn't a 3G RAN is really an extended L2, so your earlier arguments about needing to re-run the fragmentation at each handover event would not really be true? Lou -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] Sent: 18 June 2003 10:29 To: Hancock, Robert; nsis@ietf.org Subject: Re: [NSIS] yet another attempted summary of fragmentation discussion Hi Robert First of all I do not know how you could deduce that I am interested in a protocol that can be used for closed environments and not for the Internet!!!!!!. This is not true!!!!!! I am interested in a protocol that can be used for QoS signaling in a RAN used for third generation mobile systems. See section 10.4 in the NSIS requirements draft. This scenario, and are plenty of other scenarios, imposes strict requirements in terms of processing delays and scalability (performance of the network does not deterirates badly when the number of supported users is increased). NSIS can be used in such scenarios only if these strict requirements are met. Now assume that your option (2) is used: * the NTLP will have to find out, thus process even if the NSLP does not need fragmentation, if fragmentation is needed; * the NTLP will have to find out, thus process even if the NSLP does not need fragmentation, if reassembly is needed. Now assume the following option (3bis) is used : The NSLP and NTLP do not do fragmentation at all. In case of an error, e.g., if fragmentation is needed then the NTLP will send an error message back to the sender. When no fragmentation is needed then this option is the fastest and less complicated. I am in favour of combining the above two options (by using a "Do fragmentation" bit) then: * the NSLP's that do not need NTLP fragmentation will use the above option (2) * the NSLP's that do need fragmentation will use the above option (3bis). Best regards, Georgios ----- Original Message ----- From: "Hancock, Robert" To: "'Georgios Karagiannis'" ; Sent: Wednesday, June 18, 2003 10:38 AM Subject: RE: [NSIS] yet another attempted summary of fragmentation discussion > georgios, > > (4) is more complex than (2) because > *) both need fragmentation capability in the NTLP > *) only (4) needs MTU reporting from the NTLP > *) only (4) needs fragmentation capability in the NSLP > *) only (4) needs setting/processing of a 'DF' bit > > (4) is more complex than (3) because > *) both need fragmentation capability in the NSLP > *) both need MTU reporting from the NTLP > *) only (4) needs fragmentation capability in the NTLP > *) only (4) needs setting/processing of a 'DF' bit > > it may be that what I understand by (4) is not the same as what you > are proposing; I'm afraid that can only be fixed by you actually > defining what you are proposing in a form which other people > can understand and evaluate. however, a pre-emptive point: > > if you are proposing a solution which allows *some* NSLP (i.e. not > the one you are interested in, but someone else's) to generate a > message that would need NTLP fragmentation, then I believe that the > consequence is that *all* NTLP implementations will have to support > fragmentation to be compliant with the standard we write. this is > a general consequence of the "we don't design protocols for closed > environments" attitude (see also the 'I in IETF' comment a few emails > back). In other words, you can't just say 'well, the NSLP I care > about only produces small messages so I won't bother with fragmentation > at all'. > > Other people might like to comment on whether this assumption is > sensible. > > cheers, > > r. > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: Wednesday, June 18, 2003 09:04 > > To: Hancock, Robert; nsis@ietf.org > > Subject: Re: [NSIS] yet another attempted summary of fragmentation > > discussion > > > > > > Hi Robert > > > > I do not see how you came to the conclusion in > > (E) that option (4) is the most algorithmically functionally > > complex of all > > the > > solutions for both layers. > > > > If a NSLP chooses to use the NTLP fragmentation then the complexity is > > the same as (2) and if a NSLP does not need fragmentation then the > > complexity > > is actually reduced. > > > > I am still in favour of option (4). > > > > Best regards, > > Georgios > > > > ----- Original Message ----- > > From: "Hancock, Robert" > > To: > > Sent: Wednesday, June 18, 2003 12:32 AM > > Subject: [NSIS] yet another attempted summary of > > fragmentation discussion > > > > > > > Dear all, > > > > > > Here is another attempt to summarise the fragmentation issues > > > (for those who are still following). > > > > > > We have basically the same 4 options on the table: > > > 1. Leave it up to the IP layer > > > 2. Do it only in the NTLP > > > 3. Do it only in the NSLP (NTLP provides information about how > > > big fragments are allowed to be) > > > 4. Combination of (2) and (3) - how a message is treated depends > > > on a flag in it (for example). > > > > > > Arguments basically revolve around on concerns about the complexity > > > and processing burden on the NTLP at nodes which wouldn't otherwise > > > have to worry about fragmentation. > > > > > > Some factoids (the most interesting/controversial ones only): > > > A) There are enough trivial/minor/annoying/insuperable concerns > > > about relying on IP level fragmentation to rule out (1). > > > B) For all the others, PMTU discovery has to be done at least > > > at the NTLP level. For (3) and (4) it has to be done at the > > > NSLP level as well (so there is some additional error handling > > > needed in the NTLP). > > > C) It's possible to implement the fragmentation so that reassembly > > > is only needed at the destination NSLP node (whichever layer it > > > actually takes place in). So, the processing cost we are > > moving around > > > relates only to the fragmentation part. > > > D) I believe that the processing cost tradeoff between (2) and (3) > > > is just as likely to favour (2) as (3) so far as the 'vulnerable' > > > NTLP node is concerned, and favours (2) for the other nodes on the > > > path (see separate emails), especially when interactions > > with bundling > > > are taken into account. I certainly don't believe the 'fragmentation > > > is obviously expensive' argument. > > > E) (4) is the most algorithmically functionally complex of all the > > > solutions for both layers. > > > F) Fragmentation itself as functionality is not complex (it takes > > > about 5 pages to describe the BSD code for IP in its full glory in > > > Stevens). > > > G) Fragmentation amplifies message loss rates. If you think that > > > message loss is a problem, then fragmentation makes it a > > bigger problem; > > > however, if you think that message loss is a problem, you probably > > > believe in some kind of recovery (retransmission), which solves > > > the problem anyway. > > > > > > As might come across, I'm still a fan of (2) as a resolution of the > > > argument; I certainly don't see many stones left un-turned in the > > > discussion so far. > > > > > > I'd like to move on to the next open issue (congestion and > > flow control, > > > IMHO much more tricky and interesting). Any ideas on how to do that > > > sooner rather than later? > > > > > > 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 > _______________________________________________ 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 exim@www1.ietf.org Wed Jun 18 05:44: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 FAA25318 for ; Wed, 18 Jun 2003 05:44:28 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5I9i1E00721 for nsis-archive@odin.ietf.org; Wed, 18 Jun 2003 05:44:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SZU1-0000BX-JV; Wed, 18 Jun 2003 05:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SZTr-0000BE-Sl for nsis@optimus.ietf.org; Wed, 18 Jun 2003 05:43:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25311 for ; Wed, 18 Jun 2003 05:43:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SZRb-0001ig-00 for nsis@ietf.org; Wed, 18 Jun 2003 05:41:31 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19SZRa-0001ic-00 for nsis@ietf.org; Wed, 18 Jun 2003 05:41:30 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jun 2003 10:43:18 +0100 Message-ID: From: "Hancock, Robert" To: "'Georgios Karagiannis'" , nsis@ietf.org Subject: RE: [NSIS] yet another attempted summary of fragmentation discuss ion Date: Wed, 18 Jun 2003 10:43: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, it's good to see you haven't run out of '!'. [snip] > > Now assume that your option (2) is used: > * the NTLP will have to find out, thus process even if the NSLP does > not need fragmentation, if fragmentation is needed; OK, let's call this 'processing cost A' > * the NTLP will have to find out, thus process even if the > NSLP does not need fragmentation, if reassembly is needed. reassembly can always be deferred to the node where the receiving NSLP is located where reassembly will be needed whichever layer it is done in. so i don't see this as an issue. > > Now assume the following option (3bis) is used : The NSLP > and NTLP do not > do fragmentation at all. > In case of an error, e.g., if fragmentation is needed then > the NTLP will > send an error message back > to the sender. > When no fragmentation is needed then this option is the > fastest and less > complicated. forgive me, but I am baffled by this. isn't the processing you are describing here exactly the same as 'processing cost A' you object to above? you have to do the error processing first, since there is no robust way for an NSLP to determine in advance that fragmentation is not needed. it would also help if you could explain what you are trying to eliminate - the code complexity or processing cost (or both). My conclusion which you originally objected to was about the former (there is a separate conclusion about the latter, which is basically 'not clear either way'.) > > I am in favour of combining the above two options (by using a "Do > fragmentation" bit) then: > * the NSLP's that do not need NTLP fragmentation will use the > above option > (2) > * the NSLP's that do need fragmentation will use the above > option (3bis). > > Best regards, > Georgios cheers, robert h. PS is 3bis != 4? > > > ----- Original Message ----- > From: "Hancock, Robert" > To: "'Georgios Karagiannis'" ; > Sent: Wednesday, June 18, 2003 10:38 AM > Subject: RE: [NSIS] yet another attempted summary of fragmentation > discussion > > > > georgios, > > > > (4) is more complex than (2) because > > *) both need fragmentation capability in the NTLP > > *) only (4) needs MTU reporting from the NTLP > > *) only (4) needs fragmentation capability in the NSLP > > *) only (4) needs setting/processing of a 'DF' bit > > > > (4) is more complex than (3) because > > *) both need fragmentation capability in the NSLP > > *) both need MTU reporting from the NTLP > > *) only (4) needs fragmentation capability in the NTLP > > *) only (4) needs setting/processing of a 'DF' bit > > > > it may be that what I understand by (4) is not the same as what you > > are proposing; I'm afraid that can only be fixed by you actually > > defining what you are proposing in a form which other people > > can understand and evaluate. however, a pre-emptive point: > > > > if you are proposing a solution which allows *some* NSLP (i.e. not > > the one you are interested in, but someone else's) to generate a > > message that would need NTLP fragmentation, then I believe that the > > consequence is that *all* NTLP implementations will have to support > > fragmentation to be compliant with the standard we write. this is > > a general consequence of the "we don't design protocols for closed > > environments" attitude (see also the 'I in IETF' comment a > few emails > > back). In other words, you can't just say 'well, the NSLP I care > > about only produces small messages so I won't bother with > fragmentation > > at all'. > > > > Other people might like to comment on whether this assumption is > > sensible. > > > > cheers, > > > > r. > > > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: Wednesday, June 18, 2003 09:04 > > > To: Hancock, Robert; nsis@ietf.org > > > Subject: Re: [NSIS] yet another attempted summary of fragmentation > > > discussion > > > > > > > > > Hi Robert > > > > > > I do not see how you came to the conclusion in > > > (E) that option (4) is the most algorithmically functionally > > > complex of all > > > the > > > solutions for both layers. > > > > > > If a NSLP chooses to use the NTLP fragmentation then the > complexity is > > > the same as (2) and if a NSLP does not need fragmentation then the > > > complexity > > > is actually reduced. > > > > > > I am still in favour of option (4). > > > > > > Best regards, > > > Georgios > > > > > > ----- Original Message ----- > > > From: "Hancock, Robert" > > > To: > > > Sent: Wednesday, June 18, 2003 12:32 AM > > > Subject: [NSIS] yet another attempted summary of > > > fragmentation discussion > > > > > > > > > > Dear all, > > > > > > > > Here is another attempt to summarise the fragmentation issues > > > > (for those who are still following). > > > > > > > > We have basically the same 4 options on the table: > > > > 1. Leave it up to the IP layer > > > > 2. Do it only in the NTLP > > > > 3. Do it only in the NSLP (NTLP provides information about how > > > > big fragments are allowed to be) > > > > 4. Combination of (2) and (3) - how a message is treated depends > > > > on a flag in it (for example). > > > > > > > > Arguments basically revolve around on concerns about > the complexity > > > > and processing burden on the NTLP at nodes which > wouldn't otherwise > > > > have to worry about fragmentation. > > > > > > > > Some factoids (the most interesting/controversial ones only): > > > > A) There are enough trivial/minor/annoying/insuperable concerns > > > > about relying on IP level fragmentation to rule out (1). > > > > B) For all the others, PMTU discovery has to be done at least > > > > at the NTLP level. For (3) and (4) it has to be done at the > > > > NSLP level as well (so there is some additional error handling > > > > needed in the NTLP). > > > > C) It's possible to implement the fragmentation so that > reassembly > > > > is only needed at the destination NSLP node (whichever layer it > > > > actually takes place in). So, the processing cost we are > > > moving around > > > > relates only to the fragmentation part. > > > > D) I believe that the processing cost tradeoff between > (2) and (3) > > > > is just as likely to favour (2) as (3) so far as the > 'vulnerable' > > > > NTLP node is concerned, and favours (2) for the other > nodes on the > > > > path (see separate emails), especially when interactions > > > with bundling > > > > are taken into account. I certainly don't believe the > 'fragmentation > > > > is obviously expensive' argument. > > > > E) (4) is the most algorithmically functionally complex > of all the > > > > solutions for both layers. > > > > F) Fragmentation itself as functionality is not complex > (it takes > > > > about 5 pages to describe the BSD code for IP in its > full glory in > > > > Stevens). > > > > G) Fragmentation amplifies message loss rates. If you think that > > > > message loss is a problem, then fragmentation makes it a > > > bigger problem; > > > > however, if you think that message loss is a problem, > you probably > > > > believe in some kind of recovery (retransmission), which solves > > > > the problem anyway. > > > > > > > > As might come across, I'm still a fan of (2) as a > resolution of the > > > > argument; I certainly don't see many stones left > un-turned in the > > > > discussion so far. > > > > > > > > I'd like to move on to the next open issue (congestion and > > > flow control, > > > > IMHO much more tricky and interesting). Any ideas on > how to do that > > > > sooner rather than later? > > > > > > > > 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 > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jun 18 06:01: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 GAA25731 for ; Wed, 18 Jun 2003 06:01:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IA12a03251 for nsis-archive@odin.ietf.org; Wed, 18 Jun 2003 06:01:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SZkT-0000qK-UP; Wed, 18 Jun 2003 06:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SZk1-0000pt-PP for nsis@optimus.ietf.org; Wed, 18 Jun 2003 06:00:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25717 for ; Wed, 18 Jun 2003 06:00:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SZhl-0001nk-00 for nsis@ietf.org; Wed, 18 Jun 2003 05:58:13 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19SZhk-0001nh-00 for nsis@ietf.org; Wed, 18 Jun 2003 05:58:12 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h5IA0KCf026889; Wed, 18 Jun 2003 12:00:21 +0200 (MET DST) Message-ID: <00bd01c33580$6eea4a00$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" , References: Subject: Re: [NSIS] yet another attempted summary of fragmentation discussion Date: Wed, 18 Jun 2003 11:29:03 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Robert First of all I do not know how you could deduce that I am interested in a protocol that can be used for closed environments and not for the Internet!!!!!!. This is not true!!!!!! I am interested in a protocol that can be used for QoS signaling in a RAN used for third generation mobile systems. See section 10.4 in the NSIS requirements draft. This scenario, and are plenty of other scenarios, imposes strict requirements in terms of processing delays and scalability (performance of the network does not deterirates badly when the number of supported users is increased). NSIS can be used in such scenarios only if these strict requirements are met. Now assume that your option (2) is used: * the NTLP will have to find out, thus process even if the NSLP does not need fragmentation, if fragmentation is needed; * the NTLP will have to find out, thus process even if the NSLP does not need fragmentation, if reassembly is needed. Now assume the following option (3bis) is used : The NSLP and NTLP do not do fragmentation at all. In case of an error, e.g., if fragmentation is needed then the NTLP will send an error message back to the sender. When no fragmentation is needed then this option is the fastest and less complicated. I am in favour of combining the above two options (by using a "Do fragmentation" bit) then: * the NSLP's that do not need NTLP fragmentation will use the above option (2) * the NSLP's that do need fragmentation will use the above option (3bis). Best regards, Georgios ----- Original Message ----- From: "Hancock, Robert" To: "'Georgios Karagiannis'" ; Sent: Wednesday, June 18, 2003 10:38 AM Subject: RE: [NSIS] yet another attempted summary of fragmentation discussion > georgios, > > (4) is more complex than (2) because > *) both need fragmentation capability in the NTLP > *) only (4) needs MTU reporting from the NTLP > *) only (4) needs fragmentation capability in the NSLP > *) only (4) needs setting/processing of a 'DF' bit > > (4) is more complex than (3) because > *) both need fragmentation capability in the NSLP > *) both need MTU reporting from the NTLP > *) only (4) needs fragmentation capability in the NTLP > *) only (4) needs setting/processing of a 'DF' bit > > it may be that what I understand by (4) is not the same as what you > are proposing; I'm afraid that can only be fixed by you actually > defining what you are proposing in a form which other people > can understand and evaluate. however, a pre-emptive point: > > if you are proposing a solution which allows *some* NSLP (i.e. not > the one you are interested in, but someone else's) to generate a > message that would need NTLP fragmentation, then I believe that the > consequence is that *all* NTLP implementations will have to support > fragmentation to be compliant with the standard we write. this is > a general consequence of the "we don't design protocols for closed > environments" attitude (see also the 'I in IETF' comment a few emails > back). In other words, you can't just say 'well, the NSLP I care > about only produces small messages so I won't bother with fragmentation > at all'. > > Other people might like to comment on whether this assumption is > sensible. > > cheers, > > r. > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: Wednesday, June 18, 2003 09:04 > > To: Hancock, Robert; nsis@ietf.org > > Subject: Re: [NSIS] yet another attempted summary of fragmentation > > discussion > > > > > > Hi Robert > > > > I do not see how you came to the conclusion in > > (E) that option (4) is the most algorithmically functionally > > complex of all > > the > > solutions for both layers. > > > > If a NSLP chooses to use the NTLP fragmentation then the complexity is > > the same as (2) and if a NSLP does not need fragmentation then the > > complexity > > is actually reduced. > > > > I am still in favour of option (4). > > > > Best regards, > > Georgios > > > > ----- Original Message ----- > > From: "Hancock, Robert" > > To: > > Sent: Wednesday, June 18, 2003 12:32 AM > > Subject: [NSIS] yet another attempted summary of > > fragmentation discussion > > > > > > > Dear all, > > > > > > Here is another attempt to summarise the fragmentation issues > > > (for those who are still following). > > > > > > We have basically the same 4 options on the table: > > > 1. Leave it up to the IP layer > > > 2. Do it only in the NTLP > > > 3. Do it only in the NSLP (NTLP provides information about how > > > big fragments are allowed to be) > > > 4. Combination of (2) and (3) - how a message is treated depends > > > on a flag in it (for example). > > > > > > Arguments basically revolve around on concerns about the complexity > > > and processing burden on the NTLP at nodes which wouldn't otherwise > > > have to worry about fragmentation. > > > > > > Some factoids (the most interesting/controversial ones only): > > > A) There are enough trivial/minor/annoying/insuperable concerns > > > about relying on IP level fragmentation to rule out (1). > > > B) For all the others, PMTU discovery has to be done at least > > > at the NTLP level. For (3) and (4) it has to be done at the > > > NSLP level as well (so there is some additional error handling > > > needed in the NTLP). > > > C) It's possible to implement the fragmentation so that reassembly > > > is only needed at the destination NSLP node (whichever layer it > > > actually takes place in). So, the processing cost we are > > moving around > > > relates only to the fragmentation part. > > > D) I believe that the processing cost tradeoff between (2) and (3) > > > is just as likely to favour (2) as (3) so far as the 'vulnerable' > > > NTLP node is concerned, and favours (2) for the other nodes on the > > > path (see separate emails), especially when interactions > > with bundling > > > are taken into account. I certainly don't believe the 'fragmentation > > > is obviously expensive' argument. > > > E) (4) is the most algorithmically functionally complex of all the > > > solutions for both layers. > > > F) Fragmentation itself as functionality is not complex (it takes > > > about 5 pages to describe the BSD code for IP in its full glory in > > > Stevens). > > > G) Fragmentation amplifies message loss rates. If you think that > > > message loss is a problem, then fragmentation makes it a > > bigger problem; > > > however, if you think that message loss is a problem, you probably > > > believe in some kind of recovery (retransmission), which solves > > > the problem anyway. > > > > > > As might come across, I'm still a fan of (2) as a resolution of the > > > argument; I certainly don't see many stones left un-turned in the > > > discussion so far. > > > > > > I'd like to move on to the next open issue (congestion and > > flow control, > > > IMHO much more tricky and interesting). Any ideas on how to do that > > > sooner rather than later? > > > > > > 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 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jun 18 07:40: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 HAA27548 for ; Wed, 18 Jun 2003 07:40:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IBe3O16499 for nsis-archive@odin.ietf.org; Wed, 18 Jun 2003 07:40:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SbIH-0004HT-GY; Wed, 18 Jun 2003 07:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SbHv-0004Gp-Su for nsis@optimus.ietf.org; Wed, 18 Jun 2003 07:39:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27528 for ; Wed, 18 Jun 2003 07:39:38 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SbFg-0002GN-00 for nsis@ietf.org; Wed, 18 Jun 2003 07:37:20 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19SbFf-0002GK-00 for nsis@ietf.org; Wed, 18 Jun 2003 07:37:19 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5IBdba25442 for ; Wed, 18 Jun 2003 14:39:37 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 18 Jun 2003 14:39:36 +0300 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 14:39:35 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 14:39:35 +0300 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] yet another attempted summary of fragmentation discussion Date: Wed, 18 Jun 2003 14:39:34 +0300 Message-ID: Thread-Topic: [NSIS] yet another attempted summary of fragmentation discussion Thread-Index: AcM1geE3WoS+zX/bQWSLuaM4HOdvEAACy6sQ To: , , X-OriginalArrivalTime: 18 Jun 2003 11:39:35.0059 (UTC) FILETIME=[4AA6F630:01C3358E] 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 X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA27548 Hi All, I am in favor of Robert's point 2: 2. Do it only in the NTLP I think it is the cleanest, most general proposal. I believe that there are a number of mechanisms available, and would note that there are a number of mechanisms for doing PMTU discover (for example, see the end of message). As far as Georgios' concern, my feeling that inside a controlled environment (like 3G RAN), a NSLP could use configuration data to ensure that PMTU is not needed and that all NSLP packets are within the PMTU. However, this is to be handled in the NTLP spec. I think that, as a general rule, saying that the NTLP has ultimate responsibility for handling fragmentation is a reasonable thing for the Framework document to say. I also get the feeling that there is consensus on the mailing list to support this position. John ====================================================== A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination as yet. The following description was submitted, ans is provided for informational purposes only: Path Maximum Transmission Unit Discovery (pmutd) ------------------------------------------------ Current Status: Proposed Working Group Chair(s): Matt Mathis TBD Transport Area Directors(s): Allison Mankin Jon Peterson Transport Area Advisor: Allison Mankin Mailing List (temporary): General Discussion: mtu@psc.edu Subscribe: majordomo@psc.edu with "subscribe mtu" in the body Archive: http://www.psc.edu/~mathis/MTU/mbox.txt (This is to be moved to the IETF as soon as chartered). Description of Working Group: The goal of the PMTUD working group is to specify a robust method for determining the IP Maximum Transmission Unit supported over an end-to-end path. This new method is expected to update most uses of RFC1191 and RFC1981, the current standards track protocols for this purpose. Various weakness in the current methods are documented in RFC2923, and have proven to be a chronic impediment to the deployment of new technologies that alter the path MTU, such as tunnels and new types of link layers. The proposed new method does not rely on ICMP or other messages from the network. It finds the proper MTU by starting a connection using relatively small packets (e.g. TCP segments) and searching upwards by probing with progressively larger test packets (containing application data). If a probe packet is successfully delivered, then the path MTU is raised. The isolated loss of a probe packet (with or without an ICMP can't fragment message) is treated as an indication of a MTU limit, and not a congestion indicator. The working group will specify the method for use in TCP, SCTP, and will outline what is necessary to support the method in transports such as DCCP. It will particularly describe the precise conditions under which lost packets are not treated as congestion indications. The work will pay particular attention to details that affect robustness and security. Path MTU discovery has the potential to interact with many other parts of the Internet, including all link, transport, encapsulation and tunnel protocols. Thereforethis working group will particularly encourage input from a wide cross section of the IETF to help to maximize the robustness of path MTU discovery in the presence of pathological behaviors from other components. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jun 18 08:01: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 IAA28911 for ; Wed, 18 Jun 2003 08:01:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IC11J21032 for nsis-archive@odin.ietf.org; Wed, 18 Jun 2003 08:01:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sbcb-0005T7-K0; Wed, 18 Jun 2003 08:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SbcP-0005SP-5P for nsis@optimus.ietf.org; Wed, 18 Jun 2003 08:00:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28895 for ; Wed, 18 Jun 2003 08:00:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sba9-0002Qc-00 for nsis@ietf.org; Wed, 18 Jun 2003 07:58:29 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19Sba8-0002QZ-00 for nsis@ietf.org; Wed, 18 Jun 2003 07:58:28 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h5IC0iCf001679; Wed, 18 Jun 2003 14:00:44 +0200 (MET DST) Message-ID: <00ce01c33591$403e2350$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Hancock, Robert" , References: Subject: Re: [NSIS] yet another attempted summary of fragmentation discussion Date: Wed, 18 Jun 2003 14:00:45 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Robert > it's good to see you haven't run out of '!'. Sorry, couldn't help it :-) > reassembly can always be deferred to the node where the > receiving NSLP is located where reassembly will be needed whichever > layer it is done in. so i don't see this as an issue. > forgive me, but I am baffled by this. isn't the processing you > are describing here exactly the same as 'processing cost A' you > object to above? you have to do the error processing first, since > there is no robust way for an NSLP to determine in advance that > fragmentation is not needed. Maybe the application(s) running above NSLP can determine that. Error processing will be done only when fragmentation is required and the NTLP is not able to do it. Thus "processing cost A" is done only when needed, while in option (2) it is done always. So by optimizing the situation where fragmentation is not needed, you will increase the performance of the NSIS protocol. Note that that the performance of the NSIS protocol will not be affected when a combination of 2 and 3bis is supported by NSIS and during a NSIS session the fragmentation option (2) is used. > > it would also help if you could explain what you are trying to eliminate - > the code complexity or processing cost (or both). My conclusion which you > originally objected to was about the former (there is a separate conclusion > about the latter, which is basically 'not clear either way'.) No, see above > > PS is 3bis != 4? 2 = your 2; 3 bis != your 3; => my 4 != your 4 Best regards, Georgios > > ----- Original Message ----- > > From: "Hancock, Robert" > > To: "'Georgios Karagiannis'" ; > > Sent: Wednesday, June 18, 2003 10:38 AM > > Subject: RE: [NSIS] yet another attempted summary of fragmentation > > discussion > > > > > > > georgios, > > > > > > (4) is more complex than (2) because > > > *) both need fragmentation capability in the NTLP > > > *) only (4) needs MTU reporting from the NTLP > > > *) only (4) needs fragmentation capability in the NSLP > > > *) only (4) needs setting/processing of a 'DF' bit > > > > > > (4) is more complex than (3) because > > > *) both need fragmentation capability in the NSLP > > > *) both need MTU reporting from the NTLP > > > *) only (4) needs fragmentation capability in the NTLP > > > *) only (4) needs setting/processing of a 'DF' bit > > > > > > it may be that what I understand by (4) is not the same as what you > > > are proposing; I'm afraid that can only be fixed by you actually > > > defining what you are proposing in a form which other people > > > can understand and evaluate. however, a pre-emptive point: > > > > > > if you are proposing a solution which allows *some* NSLP (i.e. not > > > the one you are interested in, but someone else's) to generate a > > > message that would need NTLP fragmentation, then I believe that the > > > consequence is that *all* NTLP implementations will have to support > > > fragmentation to be compliant with the standard we write. this is > > > a general consequence of the "we don't design protocols for closed > > > environments" attitude (see also the 'I in IETF' comment a > > few emails > > > back). In other words, you can't just say 'well, the NSLP I care > > > about only produces small messages so I won't bother with > > fragmentation > > > at all'. > > > > > > Other people might like to comment on whether this assumption is > > > sensible. > > > > > > cheers, > > > > > > r. > > > > > > > -----Original Message----- > > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > > Sent: Wednesday, June 18, 2003 09:04 > > > > To: Hancock, Robert; nsis@ietf.org > > > > Subject: Re: [NSIS] yet another attempted summary of fragmentation > > > > discussion > > > > > > > > > > > > Hi Robert > > > > > > > > I do not see how you came to the conclusion in > > > > (E) that option (4) is the most algorithmically functionally > > > > complex of all > > > > the > > > > solutions for both layers. > > > > > > > > If a NSLP chooses to use the NTLP fragmentation then the > > complexity is > > > > the same as (2) and if a NSLP does not need fragmentation then the > > > > complexity > > > > is actually reduced. > > > > > > > > I am still in favour of option (4). > > > > > > > > Best regards, > > > > Georgios > > > > > > > > ----- Original Message ----- > > > > From: "Hancock, Robert" > > > > To: > > > > Sent: Wednesday, June 18, 2003 12:32 AM > > > > Subject: [NSIS] yet another attempted summary of > > > > fragmentation discussion > > > > > > > > > > > > > Dear all, > > > > > > > > > > Here is another attempt to summarise the fragmentation issues > > > > > (for those who are still following). > > > > > > > > > > We have basically the same 4 options on the table: > > > > > 1. Leave it up to the IP layer > > > > > 2. Do it only in the NTLP > > > > > 3. Do it only in the NSLP (NTLP provides information about how > > > > > big fragments are allowed to be) > > > > > 4. Combination of (2) and (3) - how a message is treated depends > > > > > on a flag in it (for example). > > > > > > > > > > Arguments basically revolve around on concerns about > > the complexity > > > > > and processing burden on the NTLP at nodes which > > wouldn't otherwise > > > > > have to worry about fragmentation. > > > > > > > > > > Some factoids (the most interesting/controversial ones only): > > > > > A) There are enough trivial/minor/annoying/insuperable concerns > > > > > about relying on IP level fragmentation to rule out (1). > > > > > B) For all the others, PMTU discovery has to be done at least > > > > > at the NTLP level. For (3) and (4) it has to be done at the > > > > > NSLP level as well (so there is some additional error handling > > > > > needed in the NTLP). > > > > > C) It's possible to implement the fragmentation so that > > reassembly > > > > > is only needed at the destination NSLP node (whichever layer it > > > > > actually takes place in). So, the processing cost we are > > > > moving around > > > > > relates only to the fragmentation part. > > > > > D) I believe that the processing cost tradeoff between > > (2) and (3) > > > > > is just as likely to favour (2) as (3) so far as the > > 'vulnerable' > > > > > NTLP node is concerned, and favours (2) for the other > > nodes on the > > > > > path (see separate emails), especially when interactions > > > > with bundling > > > > > are taken into account. I certainly don't believe the > > 'fragmentation > > > > > is obviously expensive' argument. > > > > > E) (4) is the most algorithmically functionally complex > > of all the > > > > > solutions for both layers. > > > > > F) Fragmentation itself as functionality is not complex > > (it takes > > > > > about 5 pages to describe the BSD code for IP in its > > full glory in > > > > > Stevens). > > > > > G) Fragmentation amplifies message loss rates. If you think that > > > > > message loss is a problem, then fragmentation makes it a > > > > bigger problem; > > > > > however, if you think that message loss is a problem, > > you probably > > > > > believe in some kind of recovery (retransmission), which solves > > > > > the problem anyway. > > > > > > > > > > As might come across, I'm still a fan of (2) as a > > resolution of the > > > > > argument; I certainly don't see many stones left > > un-turned in the > > > > > discussion so far. > > > > > > > > > > I'd like to move on to the next open issue (congestion and > > > > flow control, > > > > > IMHO much more tricky and interesting). Any ideas on > > how to do that > > > > > sooner rather than later? > > > > > > > > > > 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 > > > > > > > _______________________________________________ > 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 exim@www1.ietf.org Wed Jun 18 08:07: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 IAA29036 for ; Wed, 18 Jun 2003 08:07:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IC71L21934 for nsis-archive@odin.ietf.org; Wed, 18 Jun 2003 08:07:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SbiP-0005hB-4O; Wed, 18 Jun 2003 08:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SbiB-0005dh-0v for nsis@optimus.ietf.org; Wed, 18 Jun 2003 08:06:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28999 for ; Wed, 18 Jun 2003 08:06:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sbfv-0002Rq-00 for nsis@ietf.org; Wed, 18 Jun 2003 08:04:27 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19Sbfu-0002Rn-00 for nsis@ietf.org; Wed, 18 Jun 2003 08:04:26 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h5IC6gCf001905; Wed, 18 Jun 2003 14:06:42 +0200 (MET DST) Message-ID: <00e701c33592$15782ac0$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: , References: Subject: Re: [NSIS] yet another attempted summary of fragmentation discussion Date: Wed, 18 Jun 2003 14:06:43 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Lou I was refering to the IP based RAN. Best Regards, Georgios ----- Original Message ----- From: To: Sent: Wednesday, June 18, 2003 11:39 AM Subject: RE: [NSIS] yet another attempted summary of fragmentation discussion > Hi > > Could you please explain what exactly are the strict requirements that must > be met for 3G systems? > Further isn't a 3G RAN is really an extended L2, so your earlier arguments > about needing to re-run the fragmentation at each handover event would not > really be true? > > Lou > > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 18 June 2003 10:29 > To: Hancock, Robert; nsis@ietf.org > Subject: Re: [NSIS] yet another attempted summary of fragmentation > discussion > > > Hi Robert > > First of all I do not know how you could deduce that I am interested in a > protocol that can be used > for closed environments and not for the Internet!!!!!!. This is not > true!!!!!! > I am interested in a protocol that can be used for QoS signaling in a RAN > used for third generation > mobile systems. See section 10.4 in the NSIS requirements draft. > This scenario, and are plenty of other scenarios, imposes strict > requirements in terms of processing delays > and scalability (performance of the network does not deterirates badly when > the number of supported users > is increased). > > NSIS can be used in such scenarios only if these strict requirements are > met. > > Now assume that your option (2) is used: > * the NTLP will have to find out, thus process even if the NSLP does > not need fragmentation, if fragmentation is needed; > * the NTLP will have to find out, thus process even if the NSLP does not > need > fragmentation, if reassembly is needed. > > Now assume the following option (3bis) is used : The NSLP and NTLP do not > do fragmentation at all. > In case of an error, e.g., if fragmentation is needed then the NTLP will > send an error message back > to the sender. > When no fragmentation is needed then this option is the fastest and less > complicated. > > I am in favour of combining the above two options (by using a "Do > fragmentation" bit) then: > * the NSLP's that do not need NTLP fragmentation will use the above option > (2) > * the NSLP's that do need fragmentation will use the above option (3bis). > > Best regards, > Georgios > > > ----- Original Message ----- > From: "Hancock, Robert" > To: "'Georgios Karagiannis'" ; > Sent: Wednesday, June 18, 2003 10:38 AM > Subject: RE: [NSIS] yet another attempted summary of fragmentation > discussion > > > > georgios, > > > > (4) is more complex than (2) because > > *) both need fragmentation capability in the NTLP > > *) only (4) needs MTU reporting from the NTLP > > *) only (4) needs fragmentation capability in the NSLP > > *) only (4) needs setting/processing of a 'DF' bit > > > > (4) is more complex than (3) because > > *) both need fragmentation capability in the NSLP > > *) both need MTU reporting from the NTLP > > *) only (4) needs fragmentation capability in the NTLP > > *) only (4) needs setting/processing of a 'DF' bit > > > > it may be that what I understand by (4) is not the same as what you > > are proposing; I'm afraid that can only be fixed by you actually > > defining what you are proposing in a form which other people > > can understand and evaluate. however, a pre-emptive point: > > > > if you are proposing a solution which allows *some* NSLP (i.e. not > > the one you are interested in, but someone else's) to generate a > > message that would need NTLP fragmentation, then I believe that the > > consequence is that *all* NTLP implementations will have to support > > fragmentation to be compliant with the standard we write. this is > > a general consequence of the "we don't design protocols for closed > > environments" attitude (see also the 'I in IETF' comment a few emails > > back). In other words, you can't just say 'well, the NSLP I care > > about only produces small messages so I won't bother with fragmentation > > at all'. > > > > Other people might like to comment on whether this assumption is > > sensible. > > > > cheers, > > > > r. > > > > > -----Original Message----- > > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > Sent: Wednesday, June 18, 2003 09:04 > > > To: Hancock, Robert; nsis@ietf.org > > > Subject: Re: [NSIS] yet another attempted summary of fragmentation > > > discussion > > > > > > > > > Hi Robert > > > > > > I do not see how you came to the conclusion in > > > (E) that option (4) is the most algorithmically functionally > > > complex of all > > > the > > > solutions for both layers. > > > > > > If a NSLP chooses to use the NTLP fragmentation then the complexity is > > > the same as (2) and if a NSLP does not need fragmentation then the > > > complexity > > > is actually reduced. > > > > > > I am still in favour of option (4). > > > > > > Best regards, > > > Georgios > > > > > > ----- Original Message ----- > > > From: "Hancock, Robert" > > > To: > > > Sent: Wednesday, June 18, 2003 12:32 AM > > > Subject: [NSIS] yet another attempted summary of > > > fragmentation discussion > > > > > > > > > > Dear all, > > > > > > > > Here is another attempt to summarise the fragmentation issues > > > > (for those who are still following). > > > > > > > > We have basically the same 4 options on the table: > > > > 1. Leave it up to the IP layer > > > > 2. Do it only in the NTLP > > > > 3. Do it only in the NSLP (NTLP provides information about how > > > > big fragments are allowed to be) > > > > 4. Combination of (2) and (3) - how a message is treated depends > > > > on a flag in it (for example). > > > > > > > > Arguments basically revolve around on concerns about the complexity > > > > and processing burden on the NTLP at nodes which wouldn't otherwise > > > > have to worry about fragmentation. > > > > > > > > Some factoids (the most interesting/controversial ones only): > > > > A) There are enough trivial/minor/annoying/insuperable concerns > > > > about relying on IP level fragmentation to rule out (1). > > > > B) For all the others, PMTU discovery has to be done at least > > > > at the NTLP level. For (3) and (4) it has to be done at the > > > > NSLP level as well (so there is some additional error handling > > > > needed in the NTLP). > > > > C) It's possible to implement the fragmentation so that reassembly > > > > is only needed at the destination NSLP node (whichever layer it > > > > actually takes place in). So, the processing cost we are > > > moving around > > > > relates only to the fragmentation part. > > > > D) I believe that the processing cost tradeoff between (2) and (3) > > > > is just as likely to favour (2) as (3) so far as the 'vulnerable' > > > > NTLP node is concerned, and favours (2) for the other nodes on the > > > > path (see separate emails), especially when interactions > > > with bundling > > > > are taken into account. I certainly don't believe the 'fragmentation > > > > is obviously expensive' argument. > > > > E) (4) is the most algorithmically functionally complex of all the > > > > solutions for both layers. > > > > F) Fragmentation itself as functionality is not complex (it takes > > > > about 5 pages to describe the BSD code for IP in its full glory in > > > > Stevens). > > > > G) Fragmentation amplifies message loss rates. If you think that > > > > message loss is a problem, then fragmentation makes it a > > > bigger problem; > > > > however, if you think that message loss is a problem, you probably > > > > believe in some kind of recovery (retransmission), which solves > > > > the problem anyway. > > > > > > > > As might come across, I'm still a fan of (2) as a resolution of the > > > > argument; I certainly don't see many stones left un-turned in the > > > > discussion so far. > > > > > > > > I'd like to move on to the next open issue (congestion and > > > flow control, > > > > IMHO much more tricky and interesting). Any ideas on how to do that > > > > sooner rather than later? > > > > > > > > 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 > > > > > _______________________________________________ > 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 exim@www1.ietf.org Wed Jun 18 08:34: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 IAA00197 for ; Wed, 18 Jun 2003 08:34:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5ICY1Y26816 for nsis-archive@odin.ietf.org; Wed, 18 Jun 2003 08:34:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sc8X-0006yP-Ja; Wed, 18 Jun 2003 08:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sc8B-0006y0-KB for nsis@optimus.ietf.org; Wed, 18 Jun 2003 08:33:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00005 for ; Wed, 18 Jun 2003 08:33:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sc5v-0002ju-00 for nsis@ietf.org; Wed, 18 Jun 2003 08:31:19 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 19Sc5u-0002iJ-00 for nsis@ietf.org; Wed, 18 Jun 2003 08:31:18 -0400 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; Wed, 18 Jun 2003 15:33:09 +0300 Date: Wed, 18 Jun 2003 15:33:09 +0300 (EEST) From: Jukka MJ Manner To: Tschofenig Hannes cc: nsis@ietf.org Subject: Re: [NSIS] RE: Security Threats for NSIS draft In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F036760E6@mchp905a.mch.sbs.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 Hi, I just went through the threats doc and have some miscellaneous comments. The basic idea of regrouping the threats sounds like a good thing, I also had some trouble following "the story". Also, a table summarizing the threats and maybe giving a short example of a solution would be good. Some other nits: - A clear intro would be needed, one that says in the first lines of the introduction what this document is about. After that you can tell what is the contents of the doc. - you seem to use should and must somewhat interchangeably? It might be good to be quite strict here, that is, security is a must. I don't mean here that you should use "MUST" or "SHOULD" etc. but just to say that if some attack is possible, "this is exactly how it can be defended". (- page breaks! Aargghh... I hate it when I print a document out and it doesn't have page breaks. On A4 paper, I get more lines than the IETF std number.) - It is not always clear why a certain attack is possible and what can be done about it, e.g. in Sec. 2.3. Could you elaborate a little here and there why a certain attach would be possible? Usually one-two lines is enough. - A few typos: o 1.1 "securing protocols in separated" s/in/is/ o pp. 11, last sentence "Replay attack, which can be..." o pp. 12 "signatures and not security" s/not/no/ o pp. 13 "learn communication patters." s/patters/patterns/ o pp. 15 List of sections? "2.8" mentioned twice? o pp. 16 an extra '>'? o pp. 16 "An adversary with access _to_ an NSIS router..." o pp. 17 "signaling message_s_ on behalf of someone..." o pp. 20 Sec 2.12 "...can be (the) misused by an adversary" o pp. 22 "for the possibility _of_ making a QoS reservation" Regards, Jukka ps. I'll read through the other doc this evening and send comments tomorrow morning. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jun 18 10:48: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 KAA10519 for ; Wed, 18 Jun 2003 10:48:28 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IEm1F19222 for nsis-archive@odin.ietf.org; Wed, 18 Jun 2003 10:48:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdeT-00036S-Th; Wed, 18 Jun 2003 10:11:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdJn-0001bE-UL for nsis@optimus.ietf.org; Wed, 18 Jun 2003 09:49:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06876 for ; Wed, 18 Jun 2003 09:49:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SdGr-0004nf-00 for nsis@ietf.org; Wed, 18 Jun 2003 09:46:41 -0400 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 19SdGR-0004nP-00 for nsis@ietf.org; Wed, 18 Jun 2003 09:46:15 -0400 Received: from luu (dhcp7-211.enst.fr [137.194.7.211]) by infres.enst.fr (Postfix) with SMTP id 70B8218BA; Wed, 18 Jun 2003 15:48:27 +0200 (MEST) Message-ID: <00d101c335a0$681bd5c0$d307c289@enst.fr> From: "Thanh Tra LUU" To: "Georgios Karagiannis" Cc: References: <00ce01c33591$403e2350$4c0d5982@dynamic.cs.utwente.nl> Subject: Re: [NSIS] yet another attempted summary of fragmentation discussion Date: Wed, 18 Jun 2003 15:49:15 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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 Georgois, > > it's good to see you haven't run out of '!'. > > Sorry, couldn't help it :-) Ok, let's go to the end of the road. > Maybe the application(s) running above NSLP can determine that. > Error processing will be done only when fragmentation is required and > the NTLP is not able to do it. > Thus "processing cost A" is done only when needed, while in option (2) > it is done always. ok, I agree. But I don't think A costs too much. If (2) is done: NTLP compare the length of NSLP message with the MTU value which is determined by PMTUd. If NTLP doesn't do the comparaison, NSLP must do it. There is no difference. On the other hand, if NSLP and NTLP support fragmentation, both of them must do PMTUd. If NSLP know its message's length (NSLP message's length) is small, NTLP can know it too. NTLP know exactly the length of the whole message ( header, some complementary objets of NTLP). Of course, two PMTUds are not identical, PTMUd_NSLP is E2E, PTMUd_NTLP is hop by hop (supposing that all node are NSIS aware). BTW, the PTMUd must be done. If NTLP sees that it's not necessary to fragment a message, it sets bit "Don't fragement" by itself and the intermediate NTLPs won't do framgementation anymore and don't need to examine the message's length. But the scope of NTLP is adjacent hops. How can NTLP can know the length of a message is small in the end-to-end scope ? It seems that you're right, Georgios. I thinks ( I take the RSVP as an exemple), NSLP_RSVP send message PATH from A to B, NTLP has the right to fragment the message. When A receive the message RSVP from B, NSLP of A know the MTU of a packet A to B (end to end). If A send a another message to B and the length of message is smaller than MTU, it can set the bit "Don't Fragment" and the NTLP on the intermediate nodes won't do fragmentation anymore. If we do it, there is a problem that if the route changes and the MTU is not correct anymore, we must have some messages for errors. > > PS is 3bis != 4? > > 2 = your 2; > 3 bis != your 3; > => my 4 != your 4 What's your 4bis ? Nary Tra ENST, Paris. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jun 18 10: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 KAA10834 for ; Wed, 18 Jun 2003 10:53:01 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IEqYa21019 for nsis-archive@odin.ietf.org; Wed, 18 Jun 2003 10:52:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdeW-00037M-VU; Wed, 18 Jun 2003 10:11:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdUc-0002Ab-2V for nsis@optimus.ietf.org; Wed, 18 Jun 2003 10:00:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07477 for ; Wed, 18 Jun 2003 10:00:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SdSL-0004uk-00 for nsis@ietf.org; Wed, 18 Jun 2003 09:58:33 -0400 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 19SdSK-0004uh-00 for nsis@ietf.org; Wed, 18 Jun 2003 09:58:32 -0400 Received: from luu (dhcp7-211.enst.fr [137.194.7.211]) by infres.enst.fr (Postfix) with SMTP id 7202F18B1; Wed, 18 Jun 2003 16:00:49 +0200 (MEST) Message-ID: <00e201c335a2$1fc0a9c0$d307c289@enst.fr> From: "Thanh Tra LUU" To: "Georgios Karagiannis" Cc: Subject: Re: [NSIS] yet another attempted summary of fragmentation discussion Date: Wed, 18 Jun 2003 16:01:32 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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 Georgios, Sorry, I did a mistake. I think ( I take RSVP as an exemple), NSLP_RSVP send message PATH from A to B, NTLP has the right to fragment the message. When A receive the message RSVP from B, NSLP of A know the MTU of a packet A to B (end to end). ^^^^^^ RESV If A send a another message to B and the length of message is smaller than MTU, it can set the bit "Don't Fragment" and the NTLP on the intermediate nodes won't do fragmentation anymore. If we do it, there is a problem that if the route changes and the MTU is not correct anymore, we must have some messages for errors. Nary Tra ENST, Paris. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jun 18 11:19: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 LAA12184 for ; Wed, 18 Jun 2003 11:19:40 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IFJCt25638 for nsis-archive@odin.ietf.org; Wed, 18 Jun 2003 11:19:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Se0f-00041A-KY; Wed, 18 Jun 2003 10:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SdXo-0002NJ-C3 for nsis@optimus.ietf.org; Wed, 18 Jun 2003 10:04:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07807 for ; Wed, 18 Jun 2003 10:04:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SdVX-0004yt-00 for nsis@ietf.org; Wed, 18 Jun 2003 10:01:51 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19SdVW-0004yq-00 for nsis@ietf.org; Wed, 18 Jun 2003 10:01:50 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5IE4scv003817; Wed, 18 Jun 2003 16:04:54 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 18 Jun 2003 16:05:54 +0200 Message-ID: From: "Attila Bader (ETH)" To: john.loughney@nokia.com, robert.hancock@roke.co.uk, karagian@cs.utwente.nl, nsis@ietf.org Subject: RE: [NSIS] yet another attempted summary of fragmentation discuss ion Date: Wed, 18 Jun 2003 16:02:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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 All, I agree that NTLP has to have responsibility for fragmentation generally. However, the cost of 'do not fragment' is 1 bit, which makes it possible that an NSLP that do not want fragmentation in underlying layers get an error message and do fragmentation itself or do something else to solve the problem. I would not exclude this option, so I propose to include DF bit. Best regards, Attila > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > john.loughney@nokia.com > Sent: Wednesday, June 18, 2003 1:40 PM > To: robert.hancock@roke.co.uk; karagian@cs.utwente.nl; nsis@ietf.org > Subject: RE: [NSIS] yet another attempted summary of fragmentation > discussion > > > Hi All, > > I am in favor of Robert's point 2: > > 2. Do it only in the NTLP > > I think it is the cleanest, most general proposal. I believe that > there are a number of mechanisms available, and would note that there > are a number of mechanisms for doing PMTU discover (for example, see > the end of message). > > As far as Georgios' concern, my feeling that inside a controlled > environment (like 3G RAN), a NSLP could use configuration data > to ensure that PMTU is not needed and that all NSLP packets are > within the PMTU. However, this is to be handled in the NTLP > spec. I think that, as a general rule, saying that the NTLP > has ultimate responsibility for handling fragmentation is a > reasonable thing for the Framework document to say. > > I also get the feeling that there is consensus on the mailing > list to support this position. > > John > ====================================================== > > A new IETF working group has been proposed in the Transport Area. > The IESG has not made any determination as yet. The following > description > was submitted, ans is provided for informational purposes only: > > Path Maximum Transmission Unit Discovery (pmutd) > ------------------------------------------------ > > Current Status: Proposed Working Group > > Chair(s): > > Matt Mathis > TBD > > Transport Area Directors(s): > > Allison Mankin > Jon Peterson > > Transport Area Advisor: > > Allison Mankin > > Mailing List (temporary): > > General Discussion: mtu@psc.edu > Subscribe: majordomo@psc.edu with "subscribe mtu" in the body > Archive: http://www.psc.edu/~mathis/MTU/mbox.txt > > (This is to be moved to the IETF as soon as chartered). > > Description of Working Group: > > The goal of the PMTUD working group is to specify a robust method for > determining the IP Maximum Transmission Unit supported over an > end-to-end path. This new method is expected to update most uses of > RFC1191 and RFC1981, the current standards track protocols for this > purpose. Various weakness in the current methods are documented in > RFC2923, and have proven to be a chronic impediment to the deployment > of new technologies that alter the path MTU, such as tunnels and new > types of link layers. > > The proposed new method does not rely on ICMP or other messages from > the network. It finds the proper MTU by starting a connection using > relatively small packets (e.g. TCP segments) and searching upwards by > probing with progressively larger test packets (containing > application > data). If a probe packet is successfully delivered, then the path MTU > is raised. The isolated loss of a probe packet (with or without an > ICMP can't fragment message) is treated as an indication of a MTU > limit, and not a congestion indicator. > > The working group will specify the method for use in TCP, SCTP, and > will outline what is necessary to support the method in transports > such as DCCP. It will particularly describe the precise conditions > under which lost packets are not treated as congestion indications. > The work will pay particular attention to details that affect > robustness and security. > > Path MTU discovery has the potential to interact with many > other parts > of the Internet, including all link, transport, encapsulation and > tunnel protocols. Thereforethis working group will particularly > encourage input from a wide cross section of the IETF to help to > maximize the robustness of path MTU discovery in the presence of > pathological behaviors from other components. > > _______________________________________________ > 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 exim@www1.ietf.org Wed Jun 18 12:07: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 MAA14526 for ; Wed, 18 Jun 2003 12:07:14 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IG6ke02449 for nsis-archive@odin.ietf.org; Wed, 18 Jun 2003 12:06:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Seun-0007Ql-Dx; Wed, 18 Jun 2003 11:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SeOv-0005oJ-CU for nsis@optimus.ietf.org; Wed, 18 Jun 2003 10:59:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11010 for ; Wed, 18 Jun 2003 10:59:01 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SeMe-0005Ro-00 for nsis@ietf.org; Wed, 18 Jun 2003 10:56:44 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19SeMd-0005Rl-00 for nsis@ietf.org; Wed, 18 Jun 2003 10:56:43 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5IEx1924913 for ; Wed, 18 Jun 2003 17:59:01 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 18 Jun 2003 17:58:59 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 17:58:59 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 18 Jun 2003 17:58:59 +0300 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] yet another attempted summary of fragmentation discussion Date: Wed, 18 Jun 2003 17:58:59 +0300 Message-ID: Thread-Topic: [NSIS] yet another attempted summary of fragmentation discussion Thread-Index: AcM1on5mbZZ11x8VQdWE3HDUMaXUSAAB3m+g To: , X-OriginalArrivalTime: 18 Jun 2003 14:58:59.0497 (UTC) FILETIME=[26035190:01C335AA] 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 X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA14526 Hi Attila, > I agree that NTLP has to have responsibility for > fragmentation generally. However, the cost of 'do not > fragment' is 1 bit, which makes it possible that an NSLP that > do not want fragmentation in underlying layers get an error > message and do fragmentation itself or do something else to > solve the problem. I would not exclude this option, so I > propose to include DF bit. A short note - I think that the DF bit is out of scope of the Framework draft - it is a solution ... John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jun 18 13:10: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 NAA16621 for ; Wed, 18 Jun 2003 13:10:19 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IH9qP12993 for nsis-archive@odin.ietf.org; Wed, 18 Jun 2003 13:09:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SfdJ-0001G3-NJ; Wed, 18 Jun 2003 12:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Seyd-0007YI-7l for nsis@optimus.ietf.org; Wed, 18 Jun 2003 11:35:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12947 for ; Wed, 18 Jun 2003 11:35:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SewN-0005rL-00 for nsis@ietf.org; Wed, 18 Jun 2003 11:33:39 -0400 Received: from mail-gw.carrieraccess.com ([65.221.135.10] helo=[172.1.1.10]) by ietf-mx with esmtp (Exim 4.12) id 19SewL-0005pk-00 for nsis@ietf.org; Wed, 18 Jun 2003 11:33:38 -0400 Received: from newman.carrieraccess.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 18 Jun 2003 09:35:13 -0600 Received: by newman.carrieraccess.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jun 2003 09:34:47 -0600 Message-ID: From: "Avella, Alejandro" To: "'john.loughney@nokia.com'" , robert.hancock@roke.co.uk, karagian@cs.utwente.nl, nsis@ietf.org Subject: RE: [NSIS] yet another attempted summary of fragmentation discuss ion Date: Wed, 18 Jun 2003 09:34:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative ; boundary="----_=_NextPart_001_01C335AF.26005210" 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_01C335AF.26005210 Content-Type: text/plain; charset="iso-8859-1" Hi John, Not sure if the RFCs below may be of use to this fragmentation discussion... >I believe that >there are a number of mechanisms available, and would note that there >are a number of mechanisms for doing PMTU discover (for example, see >the end of message). McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. http://www.ietf.org/rfc/rfc1981.txt?number=1981 Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990. http://www.ietf.org/rfc/rfc1191.txt?number=1191 Alejandro Avella ====================================================== A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination as yet. The following description was submitted, ans is provided for informational purposes only: Path Maximum Transmission Unit Discovery (pmutd) ------------------------------------------------ Current Status: Proposed Working Group Chair(s): Matt Mathis TBD Transport Area Directors(s): Allison Mankin Jon Peterson Transport Area Advisor: Allison Mankin Mailing List (temporary): General Discussion: mtu@psc.edu Subscribe: majordomo@psc.edu with "subscribe mtu" in the body Archive: http://www.psc.edu/~mathis/MTU/mbox.txt (This is to be moved to the IETF as soon as chartered). Description of Working Group: The goal of the PMTUD working group is to specify a robust method for determining the IP Maximum Transmission Unit supported over an end-to-end path. This new method is expected to update most uses of RFC1191 and RFC1981, the current standards track protocols for this purpose. Various weakness in the current methods are documented in RFC2923, and have proven to be a chronic impediment to the deployment of new technologies that alter the path MTU, such as tunnels and new types of link layers. The proposed new method does not rely on ICMP or other messages from the network. It finds the proper MTU by starting a connection using relatively small packets (e.g. TCP segments) and searching upwards by probing with progressively larger test packets (containing application data). If a probe packet is successfully delivered, then the path MTU is raised. The isolated loss of a probe packet (with or without an ICMP can't fragment message) is treated as an indication of a MTU limit, and not a congestion indicator. The working group will specify the method for use in TCP, SCTP, and will outline what is necessary to support the method in transports such as DCCP. It will particularly describe the precise conditions under which lost packets are not treated as congestion indications. The work will pay particular attention to details that affect robustness and security. Path MTU discovery has the potential to interact with many other parts of the Internet, including all link, transport, encapsulation and tunnel protocols. Thereforethis working group will particularly encourage input from a wide cross section of the IETF to help to maximize the robustness of path MTU discovery in the presence of pathological behaviors from other components. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis ************************************************************************* 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_01C335AF.26005210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [NSIS] yet another attempted summary of fragmentation discussion=

Hi John,

Not sure if the RFCs below may be of use to this fragment= ation discussion...

>I believe that
>there are a number of mechanisms available, and woul= d note that there
>are a number of mechanisms for doing PMTU discover (= for example, see
>the end of message).

McCann, J., Deering, S. and J. Mogul, "Path MTU Disc= overy for IP
version 6", RFC 1981, August 1996.
http://www.ietf.org/rfc/rfc1981.txt?number=3D1981

Mogul, J. and S. Deering, "Path MTU Discovery",= RFC 1191,
November 1990.
http://www.ietf.org/rfc/rfc1191.txt?number=3D1191

Alejandro Avella


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

A new IETF working group has been proposed in the Transpo= rt Area.
The IESG has not made any determination as yet. The foll= owing description
was submitted, ans is provided for informational purpose= s only:

 Path Maximum Transmission Unit Discovery (pmutd)
 ------------------------------------------------

 Current Status: Proposed Working Group

 Chair(s):

 Matt Mathis <mathis@psc.edu>
 TBD

 Transport Area Directors(s):

 Allison Mankin <mankin@psg.com>
 Jon Peterson <jon.peterson@neustar.biz>

 Transport Area Advisor:

 Allison Mankin <mankin@psg.com>

 Mailing List (temporary):

 General Discussion: mtu@psc.edu
 Subscribe: majordomo@psc.edu with "subscribe = mtu" in the body
 Archive: http://www.psc.edu/~mathis/MTU/mbox.txt

 (This is to be moved to the IETF as soon as charter= ed).

 Description of Working Group:

 The goal of the PMTUD working group is to specify a= robust method for
 determining the IP Maximum Transmission Unit suppo= rted over an
 end-to-end path. This new method is expected to up= date most uses of
 RFC1191 and RFC1981, the current standards track p= rotocols for this
 purpose. Various weakness in the current methods a= re documented in
 RFC2923, and have proven to be a chronic impedimen= t to the deployment
 of new technologies that alter the path MTU, such = as tunnels and new
 types of link layers.

 The proposed new method does not rely on ICMP or ot= her messages from
 the network. It finds the proper MTU by starting a= connection using
 relatively small packets (e.g. TCP segments) and s= earching upwards by
 probing with progressively larger test packets (co= ntaining application
 data). If a probe packet is successfully delivered= , then the path MTU
 is raised. The isolated loss of a probe packet (wi= th or without an
 ICMP can't fragment message) is treated as an indi= cation of a MTU
 limit, and not a congestion indicator.
 
 The working group will specify the method for use = in TCP, SCTP, and
 will outline what is necessary to support the meth= od in transports
 such as DCCP. It will particularly describe the pr= ecise conditions
 under which lost packets are not treated as conges= tion indications.
 The work will pay particular attention to details = that affect
 robustness and security.

 Path MTU discovery has the potential to interact wi= th many other parts
 of the Internet, including all link, transport, en= capsulation and
 tunnel protocols. Thereforethis working group will= particularly
 encourage input from a wide cross section of the I= ETF to help to
 maximize the robustness of path MTU discovery in t= he presence of
 pathological behaviors from other components.

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis



************************************************************************* 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_01C335AF.26005210-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jun 18 23:26: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 XAA13077 for ; Wed, 18 Jun 2003 23:26:24 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5J3Pu112774 for nsis-archive@odin.ietf.org; Wed, 18 Jun 2003 23:25:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SpgX-0002YO-By; Wed, 18 Jun 2003 23:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SpXZ-0002Ci-Hz for nsis@optimus.ietf.org; Wed, 18 Jun 2003 22:52:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12263 for ; Wed, 18 Jun 2003 22:52:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SpVH-0005SR-00 for nsis@ietf.org; Wed, 18 Jun 2003 22:50:23 -0400 Received: from mailsrv.psl.com.sg ([202.14.153.3]) by ietf-mx with esmtp (Exim 4.12) id 19SpVF-0005SB-00 for nsis@ietf.org; Wed, 18 Jun 2003 22:50:22 -0400 Received: from netpronote3 ([10.81.113.70]) by mailsrv.psl.com.sg (8.11.1/8.11.1) with SMTP id h5J2jC425040 for ; Thu, 19 Jun 2003 10:45:12 +0800 (SGT) From: "Cheng Hong" To: Subject: RE: [NSIS] yet another attempted summary of fragmentation discussion Date: Thu, 19 Jun 2003 10:54:55 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 In-Reply-To: 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 Attila, If there are NSLPs that really really don't want its messages be fragmented by the lower layer, due to whatever reason, the "do not fragment" flag could be justified. However, this has nothing to do with the performance consideration being discussed in this thread. Probably it should be looked at in the layer split section. BR Cheng > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > Attila Bader (ETH) > Sent: Wednesday, June 18, 2003 10:03 PM > To: john.loughney@nokia.com; robert.hancock@roke.co.uk; > karagian@cs.utwente.nl; nsis@ietf.org > Subject: RE: [NSIS] yet another attempted summary of fragmentation > discussion > > > Hi All, > > I agree that NTLP has to have responsibility for fragmentation > generally. However, the cost of 'do not fragment' is 1 bit, which > makes it possible that an NSLP that do not want fragmentation in > underlying layers get an error message and do fragmentation > itself or do something else to solve the problem. I would not > exclude this option, so I propose to include DF bit. > > Best regards, Attila > > > > > -----Original Message----- > > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > > john.loughney@nokia.com > > Sent: Wednesday, June 18, 2003 1:40 PM > > To: robert.hancock@roke.co.uk; karagian@cs.utwente.nl; nsis@ietf.org > > Subject: RE: [NSIS] yet another attempted summary of fragmentation > > discussion > > > > > > Hi All, > > > > I am in favor of Robert's point 2: > > > > 2. Do it only in the NTLP > > > > I think it is the cleanest, most general proposal. I believe that > > there are a number of mechanisms available, and would note that there > > are a number of mechanisms for doing PMTU discover (for example, see > > the end of message). > > > > As far as Georgios' concern, my feeling that inside a controlled > > environment (like 3G RAN), a NSLP could use configuration data > > to ensure that PMTU is not needed and that all NSLP packets are > > within the PMTU. However, this is to be handled in the NTLP > > spec. I think that, as a general rule, saying that the NTLP > > has ultimate responsibility for handling fragmentation is a > > reasonable thing for the Framework document to say. > > > > I also get the feeling that there is consensus on the mailing > > list to support this position. > > > > John > > ====================================================== > > > > A new IETF working group has been proposed in the Transport Area. > > The IESG has not made any determination as yet. The following > > description > > was submitted, ans is provided for informational purposes only: > > > > Path Maximum Transmission Unit Discovery (pmutd) > > ------------------------------------------------ > > > > Current Status: Proposed Working Group > > > > Chair(s): > > > > Matt Mathis > > TBD > > > > Transport Area Directors(s): > > > > Allison Mankin > > Jon Peterson > > > > Transport Area Advisor: > > > > Allison Mankin > > > > Mailing List (temporary): > > > > General Discussion: mtu@psc.edu > > Subscribe: majordomo@psc.edu with "subscribe mtu" in the body > > Archive: http://www.psc.edu/~mathis/MTU/mbox.txt > > > > (This is to be moved to the IETF as soon as chartered). > > > > Description of Working Group: > > > > The goal of the PMTUD working group is to specify a robust method for > > determining the IP Maximum Transmission Unit supported over an > > end-to-end path. This new method is expected to update most uses of > > RFC1191 and RFC1981, the current standards track protocols for this > > purpose. Various weakness in the current methods are documented in > > RFC2923, and have proven to be a chronic impediment to the deployment > > of new technologies that alter the path MTU, such as tunnels and new > > types of link layers. > > > > The proposed new method does not rely on ICMP or other messages from > > the network. It finds the proper MTU by starting a connection using > > relatively small packets (e.g. TCP segments) and searching upwards by > > probing with progressively larger test packets (containing > > application > > data). If a probe packet is successfully delivered, then the path MTU > > is raised. The isolated loss of a probe packet (with or without an > > ICMP can't fragment message) is treated as an indication of a MTU > > limit, and not a congestion indicator. > > > > The working group will specify the method for use in TCP, SCTP, and > > will outline what is necessary to support the method in transports > > such as DCCP. It will particularly describe the precise conditions > > under which lost packets are not treated as congestion indications. > > The work will pay particular attention to details that affect > > robustness and security. > > > > Path MTU discovery has the potential to interact with many > > other parts > > of the Internet, including all link, transport, encapsulation and > > tunnel protocols. Thereforethis working group will particularly > > encourage input from a wide cross section of the IETF to help to > > maximize the robustness of path MTU discovery in the presence of > > pathological behaviors from other components. > > > > _______________________________________________ > > 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 exim@www1.ietf.org Thu Jun 19 03:32: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 DAA03322 for ; Thu, 19 Jun 2003 03:32:15 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5J7Vk528539 for nsis-archive@odin.ietf.org; Thu, 19 Jun 2003 03:31:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19StgH-00071e-Ln; Thu, 19 Jun 2003 03:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19StSh-0006Oe-QM for nsis@optimus.ietf.org; Thu, 19 Jun 2003 03:03:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02649 for ; Thu, 19 Jun 2003 03:03:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19StQP-0000Er-00 for nsis@ietf.org; Thu, 19 Jun 2003 03:01:37 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx with esmtp (Exim 4.12) id 19StQO-0000Eo-00 for nsis@ietf.org; Thu, 19 Jun 2003 03:01:36 -0400 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, 19 Jun 2003 10:03:55 +0300 Date: Thu, 19 Jun 2003 10:03:55 +0300 (EEST) From: Jukka MJ Manner To: Tschofenig Hannes cc: nsis@ietf.org In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F036760FD@mchp905a.mch.sbs.de> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] Short review of RSVP Security Properties 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 went through the document yesterday evening and this morning. As I am no security expert, I am not able to comment on the contents and whether what you say is true or not. As a real newbie in security issues, I can only comment a little on the presentation. As you mention yourself, the document is pretty long, thus, some summary would be needed. You do have a conclusions-section, true, but you could say a little more there, for example, what are the things RSVP expects to be "there" a priori, e.g. keys and knowing your neighbor (and what is wrong with the way RSVP expects things to be?), and why was it that some issue is a problem, e.g. addressing for signaling messages should be done in a hop-by-hop fashion? Also, the comment in the conclusions about "public key auth and user id confidentiality requires improvements" leaves something to wonder, why was this so and what are these improvements? Thus, you might enhance your existing list in the conclusions by saying a little more (one-two sentences) about the reasons and put pointers to the sections where a particular problem was described - your doc is 43 pages, so it is like a short book, and a reader will surely not remember everything after one read, even after two. There are some types here and there, e.g. you seem to use some weird character as the "'" in "host's" or "user's", it prints out like "M-^R", pp. 5 "of a nodes", pp. 12 "confidentiality, AND confidentiality of the signaling messages", Figure 4 is split up on two pages 20-21, same with Figure 5 (28-29), pp. 21 "In IPSEC is applied in a nested", pp. 34 "It cannot not be interpreted" > "It should not be" (it can, but it shouldn't :), pp. 35 "and key exchange should BE separated from". Hope this helps, Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jun 19 04:48: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 EAA05402 for ; Thu, 19 Jun 2003 04:48:52 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5J8mOX10953 for nsis-archive@odin.ietf.org; Thu, 19 Jun 2003 04:48:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Suov-0001qe-UA; Thu, 19 Jun 2003 04:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SuWB-00011z-3a for nsis@optimus.ietf.org; Thu, 19 Jun 2003 04:11:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04377 for ; Thu, 19 Jun 2003 04:11:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SuTt-0000fT-00 for nsis@ietf.org; Thu, 19 Jun 2003 04:09:17 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19SuTs-0000fF-00 for nsis@ietf.org; Thu, 19 Jun 2003 04:09:16 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h5J8BUCf006321; Thu, 19 Jun 2003 10:11:31 +0200 (MET DST) Message-ID: <006701c3363a$65496de0$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: , , References: Subject: Re: [NSIS] yet another attempted summary of fragmentation discussion Date: Thu, 19 Jun 2003 10:11:21 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 John I agree with you! What about the following proposal that could be introduced in the framework draft: "The NTLP does fragmentation when it is needed. However, there might be situations where the NSLP can request from the NTLP not to do fragmentation. In these situations the NSLP is aware that fragmentation errors can occur and therefore, several solutions could be applied. For example, configuration of the network such that fragmentation will not occur, fragmentation at IP layer or fragmentation at NSLP layer." Best regards, Georgios ----- Original Message ----- From: To: ; Sent: Wednesday, June 18, 2003 4:58 PM Subject: RE: [NSIS] yet another attempted summary of fragmentation discussion > Hi Attila, > > > I agree that NTLP has to have responsibility for > > fragmentation generally. However, the cost of 'do not > > fragment' is 1 bit, which makes it possible that an NSLP that > > do not want fragmentation in underlying layers get an error > > message and do fragmentation itself or do something else to > > solve the problem. I would not exclude this option, so I > > propose to include DF bit. > > A short note - I think that the DF bit is out of scope of the > Framework draft - it is a solution ... > > 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 exim@www1.ietf.org Thu Jun 19 05:04: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 FAA05703 for ; Thu, 19 Jun 2003 05:04:25 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5J93w013719 for nsis-archive@odin.ietf.org; Thu, 19 Jun 2003 05:03:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SvAD-0003BN-Jd; Thu, 19 Jun 2003 04:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sv28-0002Vh-7m for nsis@optimus.ietf.org; Thu, 19 Jun 2003 04:44:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05335 for ; Thu, 19 Jun 2003 04:44:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Suzq-0000vy-00 for nsis@ietf.org; Thu, 19 Jun 2003 04:42:18 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Suzp-0000vv-00 for nsis@ietf.org; Thu, 19 Jun 2003 04:42:17 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5J8iYw2014029; Thu, 19 Jun 2003 10:44:34 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 19 Jun 2003 10:46:29 +0200 Message-ID: From: "Attila Bader (ETH)" To: john.loughney@nokia.com, "Hancock, Robert" , karagian@cs.utwente.nl Cc: nsis@ietf.org Subject: RE: [NSIS] yet another attempted summary of fragmentation discuss ion Date: Thu, 19 Jun 2003 10:43:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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 and Robert, Yes you are right, I was thinking in advance. So I think framework should contain that fragmentation is done in NTLP but NSLP is able to prevent NTLP to do fragmentation. Regards, Attila > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > john.loughney@nokia.com > Sent: Wednesday, June 18, 2003 4:59 PM > To: Attila.Bader@eth.ericsson.se; nsis@ietf.org > Subject: RE: [NSIS] yet another attempted summary of fragmentation > discussion > > > Hi Attila, > > > I agree that NTLP has to have responsibility for > > fragmentation generally. However, the cost of 'do not > > fragment' is 1 bit, which makes it possible that an NSLP that > > do not want fragmentation in underlying layers get an error > > message and do fragmentation itself or do something else to > > solve the problem. I would not exclude this option, so I > > propose to include DF bit. > > A short note - I think that the DF bit is out of scope of the > Framework draft - it is a solution ... > > 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 exim@www1.ietf.org Thu Jun 19 08:24: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 IAA12394 for ; Thu, 19 Jun 2003 08:24:52 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JCONf17341 for nsis-archive@odin.ietf.org; Thu, 19 Jun 2003 08:24:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SxyP-0002sa-Db; Thu, 19 Jun 2003 07:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SxdS-0001jM-6S for nsis@optimus.ietf.org; Thu, 19 Jun 2003 07:31:22 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09336; Thu, 19 Jun 2003 07:31:20 -0400 (EDT) Message-Id: <200306191131.HAA09336@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, 19 Jun 2003 07:31:20 -0400 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-req-08.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 : Requirements for Signaling Protocols Author(s) : M. Brunner Filename : draft-ietf-nsis-req-08.txt Pages : 36 Date : 2003-6-18 This document defines requirements for signaling across different network environments, such as across administrative and/or technology domains. Signaling is mainly considered for Quality of Service such as The Resource Reservation Protocol, however in recent years several other applications of signaling have been defined such as signaling for label distribution in Multiprotocol Label Switching or signaling to middleboxes. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. This document presents the assumptions before listing the requirements. The requirements are grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-req-08.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-req-08.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-req-08.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-6-18122036.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-req-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-req-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-18122036.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jun 19 08:34: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 IAA13661 for ; Thu, 19 Jun 2003 08:34:55 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JCYR719070 for nsis-archive@odin.ietf.org; Thu, 19 Jun 2003 08:34:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SxyR-0002t0-7l; Thu, 19 Jun 2003 07:53:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sxds-0001jn-NA for nsis@optimus.ietf.org; Thu, 19 Jun 2003 07:31:48 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09420; Thu, 19 Jun 2003 07:31:47 -0400 (EDT) Message-Id: <200306191131.HAA09420@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, 19 Jun 2003 07:31:46 -0400 Subject: [NSIS] I-D ACTION:draft-ietf-nsis-qos-requirements-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 : Requirements of a QoS Solution for Mobile IP Author(s) : H. Chaskar Filename : draft-ietf-nsis-qos-requirements-01.txt Pages : 8 Date : 2003-6-18 Mobile IP ensures correct routing of packets to mobile node as the mobile node changes its point of attachment to the Internet. However, it is also required to provide proper QoS forwarding treatment to mobile node's packet stream at the intermediate nodes in the network, so that QoS-sensitive IP services can be supported over Mobile IP. This document describes requirements for an IP QoS mechanism for its satisfactory operation with Mobile IP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-requirements-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-qos-requirements-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-qos-requirements-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-6-18133511.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-qos-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-qos-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-18133511.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jun 19 09:24: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 JAA17104 for ; Thu, 19 Jun 2003 09:24:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JDO2931548 for nsis-archive@odin.ietf.org; Thu, 19 Jun 2003 09:24:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SzOU-0008Ck-20; Thu, 19 Jun 2003 09:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sz2Y-0006ce-7g for nsis@optimus.ietf.org; Thu, 19 Jun 2003 09:01:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16146 for ; Thu, 19 Jun 2003 09:01:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sz0F-0003rU-00 for nsis@ietf.org; Thu, 19 Jun 2003 08:58:59 -0400 Received: from infres.enst.fr ([137.194.192.1]) by ietf-mx with esmtp (Exim 4.12) id 19Sz0F-0003rR-00 for nsis@ietf.org; Thu, 19 Jun 2003 08:58:59 -0400 Received: from luu (dhcp7-211.enst.fr [137.194.7.211]) by infres.enst.fr (Postfix) with SMTP id 0F2DB1929; Thu, 19 Jun 2003 15:01:17 +0200 (MEST) Message-ID: <006601c33663$183514e0$d307c289@enst.fr> From: "Thanh Tra LUU" To: "Hancock, Robert" Cc: References: Subject: Re: [NSIS] yet another attempted summary of fragmentation discussion Date: Thu, 19 Jun 2003 15:02:52 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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 Robert, I still don't see that it is more useful in the case NSLP can do the fragmentation : + Let NSLP do fragmentation is advantageous only in the case NSLP is not installed on NTLP in a node. For another application such as reservation IntServ, it's not useful because the fragmentation is redone by every node on the data path anyway. (if NSLP_applic1 of a node A sets a bit Don't Fragment (DF=1), NSLP_applic1 of a intermediate node C can unset this bit (DF=0) because node C can change the message.) + if NSLP do fragmentation, the implementation may have to be redone for each signaling application (NSLP). + It becomes hard to share PMTU information between different NSLPs. For exemple, a end host A want to implement NSLP for QoS (NSLP_QoS) and NSLP for Middlebox (NSLP_Mid) with the same end host B, NSLP_QoS and NSLP_Mid must do PMTUd. I think it's better if NTLP do fragmentation and it's capable of doing PMTUd end-to-end. Just a proposition. Nary Tra ENST, Paris. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jun 19 11:04: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 LAA23593 for ; Thu, 19 Jun 2003 11:04:28 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JF41r23298 for nsis-archive@odin.ietf.org; Thu, 19 Jun 2003 11:04:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T0xE-00063b-UL; Thu, 19 Jun 2003 11:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T0xA-00063G-GP for nsis@optimus.ietf.org; Thu, 19 Jun 2003 11:03:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23583 for ; Thu, 19 Jun 2003 11:03:52 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T0ur-0005LY-00 for nsis@ietf.org; Thu, 19 Jun 2003 11:01:33 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19T0uq-0005LU-00 for nsis@ietf.org; Thu, 19 Jun 2003 11:01:32 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5JF3q926786 for ; Thu, 19 Jun 2003 18:03:52 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 19 Jun 2003 18:03:49 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 19 Jun 2003 18:03:51 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 19 Jun 2003 18:03:50 +0300 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] yet another attempted summary of fragmentation discussion Date: Thu, 19 Jun 2003 18:03:50 +0300 Message-ID: Thread-Topic: [NSIS] yet another attempted summary of fragmentation discussion Thread-Index: AcM2P3oSb461pxCeSXmwrXeXIcPI6QANEarg To: , , X-OriginalArrivalTime: 19 Jun 2003 15:03:50.0538 (UTC) FILETIME=[FDE666A0:01C33673] 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 X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA23593 Hi Georgios, I think, in general, it is best to keep the framework document simple. Rather than adding text for the sake of text, I propose we keep the text simple. If so, then: The NTLP does fragmentation when it is needed. should be sufficient. If you develop an NSLP that ensures fragmentation doesn't happen, then the NTLP doesn't need to worry about fragmentation. John > -----Original Message----- > From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 19 June, 2003 11:11 > To: Loughney John (NRC/Helsinki); Attila.Bader@eth.ericsson.se; > nsis@ietf.org > Subject: Re: [NSIS] yet another attempted summary of fragmentation > discussion > > > Hi John > > I agree with you! > > What about the following proposal that could be introduced > in the framework > draft: > > "The NTLP does fragmentation when it is needed. However, > there might be > situations > where the NSLP can request from the NTLP not to do fragmentation. > In these situations the NSLP is aware that fragmentation > errors can occur > and therefore, > several solutions could be applied. For example, configuration of the > network such that > fragmentation will not occur, fragmentation at IP layer or > fragmentation at > NSLP layer." > > > Best regards, > Georgios > > > > ----- Original Message ----- > From: > To: ; > Sent: Wednesday, June 18, 2003 4:58 PM > Subject: RE: [NSIS] yet another attempted summary of fragmentation > discussion > > > > Hi Attila, > > > > > I agree that NTLP has to have responsibility for > > > fragmentation generally. However, the cost of 'do not > > > fragment' is 1 bit, which makes it possible that an NSLP that > > > do not want fragmentation in underlying layers get an error > > > message and do fragmentation itself or do something else to > > > solve the problem. I would not exclude this option, so I > > > propose to include DF bit. > > > > A short note - I think that the DF bit is out of scope of the > > Framework draft - it is a solution ... > > > > 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 > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jun 19 12:17: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 MAA28671 for ; Thu, 19 Jun 2003 12:17:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JGH2c12677 for nsis-archive@odin.ietf.org; Thu, 19 Jun 2003 12:17:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T25t-0003Hz-RJ; Thu, 19 Jun 2003 12:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T25r-0003Hf-Sx for nsis@optimus.ietf.org; Thu, 19 Jun 2003 12:16:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28647 for ; Thu, 19 Jun 2003 12:16:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T23Z-0006aE-00 for nsis@ietf.org; Thu, 19 Jun 2003 12:14:37 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19T23Y-0006aB-00 for nsis@ietf.org; Thu, 19 Jun 2003 12:14:36 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h5JGG1Cf025321; Thu, 19 Jun 2003 18:16:01 +0200 (MET DST) Message-ID: <016b01c3367e$14eb9af0$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: , , References: Subject: Re: [NSIS] yet another attempted summary of fragmentation discussion Date: Thu, 19 Jun 2003 18:16:03 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 John Any NSLP should be able to disable the NTLP fragmentation and not only a specific NSLP. Best regards, Georgios ----- Original Message ----- From: To: ; ; Sent: Thursday, June 19, 2003 5:03 PM Subject: RE: [NSIS] yet another attempted summary of fragmentation discussion > Hi Georgios, > > I think, in general, it is best to keep the framework document > simple. Rather than adding text for the sake of text, I > propose we keep the text simple. If so, then: > > The NTLP does fragmentation when it is needed. > > should be sufficient. If you develop an NSLP that ensures > fragmentation doesn't happen, then the NTLP doesn't need to > worry about fragmentation. > > John > > > > -----Original Message----- > > From: ext Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 19 June, 2003 11:11 > > To: Loughney John (NRC/Helsinki); Attila.Bader@eth.ericsson.se; > > nsis@ietf.org > > Subject: Re: [NSIS] yet another attempted summary of fragmentation > > discussion > > > > > > Hi John > > > > I agree with you! > > > > What about the following proposal that could be introduced > > in the framework > > draft: > > > > "The NTLP does fragmentation when it is needed. However, > > there might be > > situations > > where the NSLP can request from the NTLP not to do fragmentation. > > In these situations the NSLP is aware that fragmentation > > errors can occur > > and therefore, > > several solutions could be applied. For example, configuration of the > > network such that > > fragmentation will not occur, fragmentation at IP layer or > > fragmentation at > > NSLP layer." > > > > > > Best regards, > > Georgios > > > > > > > > ----- Original Message ----- > > From: > > To: ; > > Sent: Wednesday, June 18, 2003 4:58 PM > > Subject: RE: [NSIS] yet another attempted summary of fragmentation > > discussion > > > > > > > Hi Attila, > > > > > > > I agree that NTLP has to have responsibility for > > > > fragmentation generally. However, the cost of 'do not > > > > fragment' is 1 bit, which makes it possible that an NSLP that > > > > do not want fragmentation in underlying layers get an error > > > > message and do fragmentation itself or do something else to > > > > solve the problem. I would not exclude this option, so I > > > > propose to include DF bit. > > > > > > A short note - I think that the DF bit is out of scope of the > > > Framework draft - it is a solution ... > > > > > > 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 > > > > _______________________________________________ > 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 exim@www1.ietf.org Thu Jun 19 15: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 PAA13237 for ; Thu, 19 Jun 2003 15:21:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JJL5301148 for nsis-archive@odin.ietf.org; Thu, 19 Jun 2003 15:21:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T4xz-0000Ht-2X; Thu, 19 Jun 2003 15:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T4xp-0000HM-4Q for nsis@optimus.ietf.org; Thu, 19 Jun 2003 15:20:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13170 for ; Thu, 19 Jun 2003 15:20:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T4vX-00026H-00 for nsis@ietf.org; Thu, 19 Jun 2003 15:18:31 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19T4vW-00026A-00 for nsis@ietf.org; Thu, 19 Jun 2003 15:18:30 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Jun 2003 20:20:49 +0100 Message-ID: From: "Hancock, Robert" To: "'nsis@ietf.org'" Date: Thu, 19 Jun 2003 20:20:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [NSIS] framework: proposal on congestion/flow control 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 the fragmentation debate dies away (at least for now), my next f/w open issue is where responsibility for overload handling should go; specifically, what functionality (if any) should the NTLP have in protecting the network from congestion, and assisting the NSLP in detecting and adapting to overload higher up in the protocol stack. the arguments on all sides seem to me to be unclear and complex. once my summary email got beyond 5 pages i decided to put them in an i-d instead, which (while it goes through the editor queue) you can find here: http://sigcomp.srmr.co.uk/~reh/draft-hancock-nsis-overload-00.txt i'll just list the proposed tentative conclusions here: 1. The NTLP needs to prevent network overload in the IP layer between NTLP peers (i.e. should enforce congestion control). 2. However, NSLPs need to detect and adapt to overload within the NSIS protocols themselves (i.e. they can't just 'send blind') 3. Detection may take place by noting messages dropped by the NTLP, as well as any flow control imposed by the NTLP. these conclusions are tentative because they depend on various assumptions (which may be wrong) and tradeoffs (which could be balanced either way), which are all discussed in the draft. so, you might like to read it. on the other hand, you might like to jump in and sound off straight away, which is fine too. i'll try to keep track. happy debating, robert h. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jun 19 15:37: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 PAA14676 for ; Thu, 19 Jun 2003 15:37:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JJb2O07851 for nsis-archive@odin.ietf.org; Thu, 19 Jun 2003 15:37:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T5DR-000220-Lh; Thu, 19 Jun 2003 15:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T5DO-00020p-9L for nsis@optimus.ietf.org; Thu, 19 Jun 2003 15:36:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14633 for ; Thu, 19 Jun 2003 15:36:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T5B6-0002V0-00 for nsis@ietf.org; Thu, 19 Jun 2003 15:34:36 -0400 Received: from tnt.isi.edu ([128.9.128.128]) by ietf-mx with esmtp (Exim 4.12) id 19T5B5-0002Uu-00 for nsis@ietf.org; Thu, 19 Jun 2003 15:34:35 -0400 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6p2/8.11.2) with ESMTP id h5JJatK08366; Thu, 19 Jun 2003 12:36:55 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id MAA16041; Thu, 19 Jun 2003 12:25:28 -0700 (PDT) Date: Thu, 19 Jun 2003 12:25:28 -0700 (PDT) Message-Id: <200306191925.MAA16041@gra.isi.edu> To: john.loughney@nokia.com, karagian@cs.utwente.nl Subject: Re: [NSIS] yet another attempted summary of fragmentation discussion 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: , I don't get why an NSLP should be able to disable NTLP fragmentation. What happens if the NSLP did disable it? A message that exceeds the local MTU must then be black-holed by the NTLP, since it cannot be fragmented (I believe there was a consensus against IP fragmentation.) That does not make sense. If the NSLP want to avoid fragmentation, it must itself make sure it sends messages smaller than the local MTU. But if it does that, then any fragmentation mechanism in the NTLP won't be invoked anyway, so there is no need to explicitly tell the NTLP not to fragment. What am I missing? Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jun 20 02:37: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 CAA19293 for ; Fri, 20 Jun 2003 02:37:06 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5K6ac617112 for nsis-archive@odin.ietf.org; Fri, 20 Jun 2003 02:36:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TFVC-0004O3-1t; Fri, 20 Jun 2003 02:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TFUv-0004Nm-Iu for nsis@optimus.ietf.org; Fri, 20 Jun 2003 02:35:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19250 for ; Fri, 20 Jun 2003 02:35:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TFSb-00008J-00 for nsis@ietf.org; Fri, 20 Jun 2003 02:33:21 -0400 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx with esmtp (Exim 4.12) id 19TFSa-00007r-00 for nsis@ietf.org; Fri, 20 Jun 2003 02:33:20 -0400 Received: from lap10-c703.uibk.ac.at (lap10-c703.uibk.ac.at [138.232.65.57]) by smtp.uibk.ac.at (8.12.9/8.12.9/F1) with ESMTP id h5K6Z5qd013952; Fri, 20 Jun 2003 08:35:06 +0200 Subject: Re: [NSIS] framework: proposal on congestion/flow control From: Michael Welzl To: "Hancock, Robert" Cc: "'nsis@ietf.org'" In-Reply-To: References: Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1056090826.1725.18.camel@lap10-c703> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 20 Jun 2003 08:33:46 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 () IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 X-Scanned-By: MIMEDefang 2.26 at uibk.ac.at (www . roaringpenguin . com / mimedefang) 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 all, I'm (somewhat) new to this group, so please forgive me if I'm talking nonsense. Having said that, I just read this document, and my opinion is: - I agree that, in general, congestion control should be done by the NTLP (after all, doing congestion control on top of congestion control means stacking a control loop on top of another one). - I agree that a NSLP should provide a flow control mechanism to cope with NSLP-layer overload BUT: Some signaling messages may only be of a sporadic nature (e.g. the RETRY or REPAIR messages in the draft) - for such messages, the initial negotiations of protocols such as TCP and DCCP would be unnecessary overhead (if a routing protocol used DCCP to convey its messages, it would introduce additional state in routers!), so UDP would be the protocol of choice. In (_ONLY_) these cases, the NSLP should handle network congestion to some degree at least. A first step in this direction could be to limit the signaling traffic appropriately - e.g., make it a fraction of payload, as would be natural for NORMAL and REFRESH messages. It then automatically scales with payload traffic in a linear manner; I think that this is specified for RTCP. The problem is, of course, that these messages may need to be sent in times of interrupted payload traffic, so the enforcement should perhaps not be strict but use a rate limiter such as a token bucket... which could make things quite complex. Maybe it would suffice to mention that sometimes, NSLPs would probably have to use UDP, and that they should handle congestion in these cases. Best regards, Michael Welzl On Thu, 2003-06-19 at 21:20, Hancock, Robert wrote: > dear all, > > as the fragmentation debate dies away (at least for now), > my next f/w open issue is where responsibility for overload > handling should go; specifically, what functionality (if > any) should the NTLP have in protecting the network from > congestion, and assisting the NSLP in detecting and adapting > to overload higher up in the protocol stack. > > the arguments on all sides seem to me to be unclear and complex. > once my summary email got beyond 5 pages i decided to put them > in an i-d instead, which (while it goes through the editor > queue) you can find here: > http://sigcomp.srmr.co.uk/~reh/draft-hancock-nsis-overload-00.txt > > i'll just list the proposed tentative conclusions here: > 1. The NTLP needs to prevent network overload in the IP layer between > NTLP peers (i.e. should enforce congestion control). > 2. However, NSLPs need to detect and adapt to overload within the > NSIS protocols themselves (i.e. they can't just 'send blind') > 3. Detection may take place by noting messages dropped by the NTLP, > as well as any flow control imposed by the NTLP. > > these conclusions are tentative because they depend on > various assumptions (which may be wrong) and tradeoffs > (which could be balanced either way), which are all discussed > in the draft. so, you might like to read it. on the other hand, > you might like to jump in and sound off straight away, which is > fine too. i'll try to keep track. > > happy debating, > > robert h. > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis -- Michael Welzl University of Innsbruck _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jun 20 07:34: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 HAA26156 for ; Fri, 20 Jun 2003 07:34:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KBY3Z17791 for nsis-archive@odin.ietf.org; Fri, 20 Jun 2003 07:34:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TK9Z-0004c5-Re; Fri, 20 Jun 2003 07:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TK95-0004Yb-I2 for nsis@optimus.ietf.org; Fri, 20 Jun 2003 07:33:31 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25793; Fri, 20 Jun 2003 07:33:30 -0400 (EDT) Message-Id: <200306201133.HAA25793@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: Fri, 20 Jun 2003 07:33:29 -0400 Subject: [NSIS] I-D ACTION:draft-hancock-nsis-overload-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 : Handling Overload Conditions in the NSIS Protocol Suite Author(s) : R. Hancock et al. Filename : draft-hancock-nsis-overload-00.txt Pages : 11 Date : 2003-6-19 The NSIS working group is considering protocols for signaling for resources for a traffic flow along its path in the network. The requirements for such signaling are being developed in [2] and a framework in [3]. The framework describes a 2-layer protocol architecture, with a common lower NSIS 'transport' layer protocol (NTLP) supporting a variety of upper layer NSIS signaling layer protocols (NSLPs). It is an open issue where within this architecture to place the responsibility for handling overload conditions. These conditions relate both to overload of the IP layer itself, as well as overload of buffer/processing resources within the NTLP/NSLPs. This note discusses the requirements and the implications of various approaches, and proposes a way forwards. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hancock-nsis-overload-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-hancock-nsis-overload-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-hancock-nsis-overload-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-6-19154017.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hancock-nsis-overload-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hancock-nsis-overload-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-19154017.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jun 20 08:01: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 IAA29695 for ; Fri, 20 Jun 2003 08:01:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KC11W28656 for nsis-archive@odin.ietf.org; Fri, 20 Jun 2003 08:01:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKZh-0007S5-SQ; Fri, 20 Jun 2003 08:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TKZG-0007Mx-MJ for nsis@optimus.ietf.org; Fri, 20 Jun 2003 08:00:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29634 for ; Fri, 20 Jun 2003 08:00:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TKWu-0002U4-00 for nsis@ietf.org; Fri, 20 Jun 2003 07:58:08 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19TKWt-0002Tl-00 for nsis@ietf.org; Fri, 20 Jun 2003 07:58:08 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5KC0KVI050128 for ; Fri, 20 Jun 2003 14:00:20 +0200 (CEST) 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 E9C24A8EB8 for ; Fri, 20 Jun 2003 13:45:25 +0200 (CEST) Date: Fri, 20 Jun 2003 14:00:00 +0200 From: Marcus Brunner Reply-To: Marcus Brunner To: nsis@ietf.org Message-ID: <15499477.1056117600@[10.1.1.130]> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========15516336==========" Subject: [NSIS] I-D ACTION:draft-brunner-nsis-midcom-ps-00.txt (fwd) 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: , --==========15516336========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit ---------- Forwarded Message ---------- Date: Donnerstag, 19. Juni 2003 07:30 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce Subject: I-D ACTION:draft-brunner-nsis-midcom-ps-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : NSIS NAT/FW NSLP: Problem Statement and Framework > Author(s) : M. Brunner et al. > Filename : draft-brunner-nsis-midcom-ps-00.txt > Pages : 43 > Date : 2003-6-18 > > This memo presents the problems for using the Next Steps in Signaling > base protocol for firewall/NAT traversal commonly refered to > middlebox traversal > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-brunner-nsis-midcom-ps-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-brunner-nsis-midcom-ps-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-brunner-nsis-midcom-ps-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. ---------- End Forwarded Message ---------- -------------------------------------- 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 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus --==========15516336========== Content-Type: multipart/mixed; boundary="==========15505257==========" --==========15505257========== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NSIS NAT/FW NSLP: Problem Statement and Framework Author(s) : M. Brunner et al. Filename : draft-brunner-nsis-midcom-ps-00.txt Pages : 43 Date : 2003-6-18 This memo presents the problems for using the Next Steps in Signaling base protocol for firewall/NAT traversal commonly refered to middlebox traversal A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brunner-nsis-midcom-ps-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-brunner-nsis-midcom-ps-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-brunner-nsis-midcom-ps-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. --==========15505257========== Content-Type: multipart/alternative; boundary="==========15509613==========" --==========15509613========== Content-Type: message/external-body; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-6-18121847.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-brunner-nsis-midcom-ps-00.txt --==========15509613========== Content-Type: message/external-body; name="draft-brunner-nsis-midcom-ps-00.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-6-18121847.I-D@ietf.org> --==========15509613==========-- --==========15505257==========-- --==========15516336==========-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jun 20 09:54: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 JAA06416 for ; Fri, 20 Jun 2003 09:54:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KDs2W26598 for nsis-archive@odin.ietf.org; Fri, 20 Jun 2003 09:54:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TML3-0006ut-8U; Fri, 20 Jun 2003 09:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TMKs-0006sb-VP for nsis@optimus.ietf.org; Fri, 20 Jun 2003 09:53:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06396 for ; Fri, 20 Jun 2003 09:53:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TMKr-000498-00 for nsis@ietf.org; Fri, 20 Jun 2003 09:53:49 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19TMKq-000495-00 for nsis@ietf.org; Fri, 20 Jun 2003 09:53:48 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h5KDriCf001595; Fri, 20 Jun 2003 15:53:44 +0200 (MET DST) Message-ID: <004f01c33733$5ea8b3c0$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: "Bob Braden" Cc: References: <200306191925.MAA16041@gra.isi.edu> Subject: Re: [NSIS] yet another attempted summary of fragmentation discussion Date: Fri, 20 Jun 2003 15:53:46 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 Bob In order to explain why, from my point of view, it is important to have the "Do fragmentation" bit I would like to use the following figure. * NF are NSIS Forwarders * NF2, NF3, NF4 and NF5 are NF nodes belonging to a network that is manged by one administrator. These nodes can be optimally configured by the administrator. * NF2 and NF5 are edge nodes; Moreover they are NTLP statefull and they can also be seen as NSIS Initiators (NI); * NF3 and NF4 are interior nodes. Moreover they are NTLP stateless nodes. For definitions of these terms please see: http://www.ietf.org/internet-drafts/draft-westberg-proposal-for-rsvpv2-nslp- 00.txt |--------| |--------| |--------| |--------| |--------| |-------| |NSLP |<->| NSLP |<->| NSLP |<->| NSLP |<->| NSLP |<->| NSLP| | |<->| |<->| |<->| |<->| |<->| | | | | | | | | | | | | | --------------------------------------------- ------- ------- ------- ----- |NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP| | |<->| |<-> | |<->| |<->| |<->| | |-------| |--------| |--------| |--------| |--------| |-------| NF1 NF2 NF3 NF4 NF5 NF6 edge interior interior edge Suppose that the interior nodes of this core network have to support, in comparison, to the edge nodes, a very large number of sessions (e.g., factor 100), i.e., since they are interior nodes of a big core network. Thus the performance of the interior nodes, has to be optimized as much as possible. Note that the performance is in terms of processing delay and scalability (i.e., performance remains almost the same even if the number of flows is increased). The administrator will try to simplify the algorithms that are running on the interior nodes as much as possible by combinig the functionality that can be provided by edge nodes (could be complex) and the ability to configure optimally its network. Now when this administrator will need to use NSIS in its network will try to minimize the features that must be used by the NTLP interior nodes. This applies to features such as fragmentation/reassembly but also flow control and congestion control. Please note that such features could be supported by the NF edge nodes. Now in case of fragmentation/reassembly, the operator will configure the network such that it could be ensured that the NTLP packets sent by the NF edge nodes will not be fragmeted by the NTLP interior nodes. In this situation the NSLP instance located at NF2 edge node will set the "Do fragmentation" off. In this situation the NF3 and NF4 nodes by only checking this "Do fragmentation" bit will deduce that no fragmentation and reassembly is needed. If this bit would not be there then an additional feature will be needed to decide if fragmentation and/or reassembly is needed. The NSLP instance located at NF5 can set the "Do fragmentation" bit to on. Best Regards, Georgios ----- Original Message ----- From: "Bob Braden" To: ; Cc: Sent: Thursday, June 19, 2003 9:25 PM Subject: Re: [NSIS] yet another attempted summary of fragmentation discussion > > I don't get why an NSLP should be able to disable NTLP fragmentation. > What happens if the NSLP did disable it? A message that exceeds the > local MTU must then be black-holed by the NTLP, since it cannot be > fragmented (I believe there was a consensus against IP fragmentation.) > That does not make sense. If the NSLP want to avoid fragmentation, it > must itself make sure it sends messages smaller than the local MTU. > But if it does that, then any fragmentation mechanism in the NTLP won't > be invoked anyway, so there is no need to explicitly tell the NTLP not > to fragment. > > What am I missing? > > Bob Braden > > > > > _______________________________________________ > 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 exim@www1.ietf.org Fri Jun 20 12:38: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 MAA16675 for ; Fri, 20 Jun 2003 12:38:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KGc2W11903 for nsis-archive@odin.ietf.org; Fri, 20 Jun 2003 12:38:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TOtl-00035Z-Dg; Fri, 20 Jun 2003 12:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TOsn-0002al-Nj for nsis@optimus.ietf.org; Fri, 20 Jun 2003 12:37:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16603 for ; Fri, 20 Jun 2003 12:36:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TOsm-0006XC-00 for nsis@ietf.org; Fri, 20 Jun 2003 12:37:00 -0400 Received: from tnt.isi.edu ([128.9.128.128]) by ietf-mx with esmtp (Exim 4.12) id 19TOsl-0006X6-00 for nsis@ietf.org; Fri, 20 Jun 2003 12:36:59 -0400 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6p2/8.11.2) with ESMTP id h5KGawK09415; Fri, 20 Jun 2003 09:36:58 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id JAA16300; Fri, 20 Jun 2003 09:32:54 -0700 (PDT) Date: Fri, 20 Jun 2003 09:32:54 -0700 (PDT) Message-Id: <200306201632.JAA16300@gra.isi.edu> To: braden@ISI.EDU, karagian@cs.utwente.nl Subject: Re: [NSIS] yet another attempted summary of fragmentation discussion 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: , Georgios, Thank you for the explanation, but unfortunately it does not seem to relate to my question. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Jun 22 15:52: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 PAA17353 for ; Sun, 22 Jun 2003 15:52:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5MJq4406277 for nsis-archive@odin.ietf.org; Sun, 22 Jun 2003 15:52:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UAsb-0001cy-7M; Sun, 22 Jun 2003 15:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UArI-0001aE-T8 for nsis@optimus.ietf.org; Sun, 22 Jun 2003 15:51:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17318 for ; Sun, 22 Jun 2003 15:50:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UArH-0005F1-00 for nsis@ietf.org; Sun, 22 Jun 2003 15:50:39 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 19UAr6-0005Eo-00 for nsis@ietf.org; Sun, 22 Jun 2003 15:50:28 -0400 Received: (from braden@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h5MJn3g04178; Sun, 22 Jun 2003 12:49:03 -0700 (PDT) Date: Sun, 22 Jun 2003 12:49:03 -0700 (PDT) From: Bob Braden Message-Id: <200306221949.h5MJn3g04178@boreas.isi.edu> To: robert.hancock@roke.co.uk, michael.welzl@uibk.ac.at Subject: Re: [NSIS] framework: proposal on congestion/flow control 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: , *> *> Some signaling messages may only be of a sporadic nature *> (e.g. the RETRY or REPAIR messages in the draft) - for *> such messages, the initial negotiations of protocols such *> as TCP and DCCP would be unnecessary overhead (if a *> routing protocol used DCCP to convey its messages, it *> would introduce additional state in routers!), so UDP *> would be the protocol of choice. *> I wonder how you can do congestion control without state at each end, which requires setup. How does it help to use UDP and move the congestion state into the "application", i.e., into NSLP? It would seem that DCCP is what the doctor ordered here. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Jun 22 16:31: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 QAA17868 for ; Sun, 22 Jun 2003 16:31:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5MKV2A09367 for nsis-archive@odin.ietf.org; Sun, 22 Jun 2003 16:31:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UBUM-0002Qy-7N; Sun, 22 Jun 2003 16:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UBTd-0002QR-Gm for nsis@optimus.ietf.org; Sun, 22 Jun 2003 16:30:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17850 for ; Sun, 22 Jun 2003 16:30:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UBTb-0005OO-00 for nsis@ietf.org; Sun, 22 Jun 2003 16:30:15 -0400 Received: from viefep15-int.chello.at ([213.46.255.19]) by ietf-mx with esmtp (Exim 4.12) id 19UBTQ-0005OI-00 for nsis@ietf.org; Sun, 22 Jun 2003 16:30:04 -0400 Received: from work ([80.109.142.58]) by viefep15-int.chello.at (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with SMTP id <20030622202914.QGTY1476.viefep15-int.chello.at@work>; Sun, 22 Jun 2003 22:29:14 +0200 From: "Michael Welzl" To: "Bob Braden" , Cc: Subject: AW: [NSIS] framework: proposal on congestion/flow control Date: Sun, 22 Jun 2003 22:29:19 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <200306221949.h5MJn3g04178@boreas.isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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, > *> > *> Some signaling messages may only be of a sporadic nature > *> (e.g. the RETRY or REPAIR messages in the draft) - for > *> such messages, the initial negotiations of protocols such > *> as TCP and DCCP would be unnecessary overhead (if a > *> routing protocol used DCCP to convey its messages, it > *> would introduce additional state in routers!), so UDP > *> would be the protocol of choice. > *> > > I wonder how you can do congestion control without state at each end, > which requires setup. How does it help to use UDP and move the > congestion state into the "application", i.e., into NSLP? It would > seem that DCCP is what the doctor ordered here. If you think that this is reasonable for each and every type of signaling message (no cynism here - I'm just not sure), then I agree. I only wanted to make a case for some kind of rate limiting function instead of congestion-control-for-some-cases-and-nothing-at-all-otherwise. Best regards, Michael _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Jun 22 18:08: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 SAA20084 for ; Sun, 22 Jun 2003 18:08:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5MM83o19240 for nsis-archive@odin.ietf.org; Sun, 22 Jun 2003 18:08:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UD0E-00050C-VJ; Sun, 22 Jun 2003 18:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UD00-0004zr-9D for nsis@optimus.ietf.org; Sun, 22 Jun 2003 18:07:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20011 for ; Sun, 22 Jun 2003 18:07:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UCzx-0005kl-00 for nsis@ietf.org; Sun, 22 Jun 2003 18:07:45 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 19UCzm-0005kX-00 for nsis@ietf.org; Sun, 22 Jun 2003 18:07:34 -0400 Received: (from braden@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h5MM75g21924; Sun, 22 Jun 2003 15:07:05 -0700 (PDT) Date: Sun, 22 Jun 2003 15:07:05 -0700 (PDT) From: Bob Braden Message-Id: <200306222207.h5MM75g21924@boreas.isi.edu> To: braden@ISI.EDU, orobert.hancock@roke.co.uk, michael.welzl@uibk.ac.at Subject: Re: AW: [NSIS] framework: proposal on congestion/flow control 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: , *> Hi, *> *> > *> *> > *> Some signaling messages may only be of a sporadic nature *> > *> (e.g. the RETRY or REPAIR messages in the draft) - for *> > *> such messages, the initial negotiations of protocols such *> > *> as TCP and DCCP would be unnecessary overhead (if a *> > *> routing protocol used DCCP to convey its messages, it *> > *> would introduce additional state in routers!), so UDP *> > *> would be the protocol of choice. *> > *> *> > *> > I wonder how you can do congestion control without state at each end, *> > which requires setup. How does it help to use UDP and move the *> > congestion state into the "application", i.e., into NSLP? It would *> > seem that DCCP is what the doctor ordered here. *> *> If you think that this is reasonable for each and every type *> of signaling message (no cynism here - I'm just not sure), then *> I agree. I only wanted to make a case for some kind of rate *> limiting function instead of *> congestion-control-for-some-cases-and-nothing-at-all-otherwise. *> *> Best regards, *> Michael Michael, I could be wrong, but it seems to me that to do congestion control you need state. The issue is when that state is established. In the case of ephemeral messages that you want to send using UDP (or better, DCCP), I would think that the state could be set up roughly once, when two neighbor nodes first discover each other. So, it's a question of when, not whether, to establish state. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jun 23 02:13: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 CAA09487 for ; Mon, 23 Jun 2003 02:13:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N6D2u11530 for nsis-archive@odin.ietf.org; Mon, 23 Jun 2003 02:13:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKZZ-0002zr-Cn; Mon, 23 Jun 2003 02:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UKYm-0002tO-Uw for nsis@optimus.ietf.org; Mon, 23 Jun 2003 02:12:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09348 for ; Mon, 23 Jun 2003 02:12:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UKYj-0007Sn-00 for nsis@ietf.org; Mon, 23 Jun 2003 02:12:09 -0400 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx with esmtp (Exim 4.12) id 19UKYY-0007Sa-00 for nsis@ietf.org; Mon, 23 Jun 2003 02:11:58 -0400 Received: from lap10-c703.uibk.ac.at (lap10-c703.uibk.ac.at [138.232.65.57]) by smtp.uibk.ac.at (8.12.9/8.12.9/F1) with ESMTP id h5N6B2qd014055; Mon, 23 Jun 2003 08:11:02 +0200 Subject: Re: AW: [NSIS] framework: proposal on congestion/flow control From: Michael Welzl To: Bob Braden Cc: orobert.hancock@roke.co.uk, nsis@ietf.org In-Reply-To: <200306222207.h5MM75g21924@boreas.isi.edu> References: <200306222207.h5MM75g21924@boreas.isi.edu> Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1056348581.1734.24.camel@lap10-c703> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 23 Jun 2003 08:09:42 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.6 () DEAR_SOMEBODY,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_05_08 X-Scanned-By: MIMEDefang 2.26 at uibk.ac.at (www . roaringpenguin . com / mimedefang) 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 Dear Bob, > Michael, > > I could be wrong, but it seems to me that to do congestion control you > need state. The issue is when that state is established. In the case > of ephemeral messages that you want to send using UDP (or better, > DCCP), I would think that the state could be set up roughly once, when > two neighbor nodes first discover each other. So, it's a question of > when, not whether, to establish state. > > Bob Braden I agree, but It's also a question of how much state you establish, or (more important) how often you need to update it. DCCP requires a lot of state and acks every packet, which is ok for any long-term data transfer, but I thought that there might be sporadic messages in signaling (error messages of some sort ... keepalives ... stuff like that) where this would be unnecessary overhead. For instance, an occasional "source quench"-like message (from the receiver, not an intermediate router!) might suffice in such cases. Rate-based open-loop instead of window-based closed-loop congestion control, perhaps using rather old state (as you mention - it is indeed a question of when!). And even without setting up any kind of state, it is reasonable to limit the rate of signaling traffic: if a node generally keeps its signaling traffic below, say, 5% of the payload it generates, the whole signaling traffic in the whole network will not exceed 5% of the whole payload traffic. This means that signaling traffic scales linearly with payload (which can, in turn, be expected to be limited through congestion control) ... while this is not as good as full-fledged congestion control, it's a start. I think that such a limit was also specified for RTCP, btw. Doing this would be my recommendation for such sporadic messages. Best regards, Michael _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jun 23 05:35: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 FAA13895 for ; Mon, 23 Jun 2003 05:35:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N9Z2e02336 for nsis-archive@odin.ietf.org; Mon, 23 Jun 2003 05:35:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UNj3-0000bZ-Ne; Mon, 23 Jun 2003 05:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UNiW-0000bF-Nb for nsis@optimus.ietf.org; Mon, 23 Jun 2003 05:34:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13863 for ; Mon, 23 Jun 2003 05:34:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UNiE-0000pt-00 for nsis@ietf.org; Mon, 23 Jun 2003 05:34:10 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19UNi3-0000pm-00 for nsis@ietf.org; Mon, 23 Jun 2003 05:33:59 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5N9WWw2001107; Mon, 23 Jun 2003 11:32:32 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 23 Jun 2003 11:34:42 +0200 Message-ID: From: "Attila Bader (ETH)" To: Bob Braden , karagian@cs.utwente.nl, "Hancock, Robert" Cc: nsis@ietf.org Subject: RE: [NSIS] yet another attempted summary of fragmentation discuss ion Date: Mon, 23 Jun 2003 11:31:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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 Bob, Sorry for stretching this thread further, I try to be short: The difference between the two approaches is how to handle error. Let's assume that fragmentation/reassembly (not only in local node) causes false operation for an NSLP (because of timing or other reasons). For this NSLP, to discover that a message was/will be fragmented is complex, or even worse, NSLP may not be aware that fragmentation/reassembly occurred. On the other hand, if NTLP had to send larger message than MTU and it could not be fragmented it is a clear situation. I think, if NSLP wants to avoid fragmentation/reassembly, it should be possible to ask such a service from NTLP. It is another question what to do if this service can not be provided. Best regards, Attila > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Bob > Braden > Sent: Thursday, June 19, 2003 9:25 PM > To: john.loughney@nokia.com; karagian@cs.utwente.nl > Cc: nsis@ietf.org > Subject: Re: [NSIS] yet another attempted summary of fragmentation > discussion > > > > I don't get why an NSLP should be able to disable NTLP fragmentation. > What happens if the NSLP did disable it? A message that exceeds the > local MTU must then be black-holed by the NTLP, since it cannot be > fragmented (I believe there was a consensus against IP fragmentation.) > That does not make sense. If the NSLP want to avoid fragmentation, it > must itself make sure it sends messages smaller than the local MTU. > But if it does that, then any fragmentation mechanism in the > NTLP won't > be invoked anyway, so there is no need to explicitly tell the NTLP not > to fragment. > > What am I missing? > > Bob Braden > > > > > _______________________________________________ > 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 exim@www1.ietf.org Mon Jun 23 08:35: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 IAA18100 for ; Mon, 23 Jun 2003 08:35:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NCZ2e26080 for nsis-archive@odin.ietf.org; Mon, 23 Jun 2003 08:35:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UQXF-0006la-SR; Mon, 23 Jun 2003 08:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UQX3-0006ky-I7 for nsis@optimus.ietf.org; Mon, 23 Jun 2003 08:34:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18075 for ; Mon, 23 Jun 2003 08:34:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UQWn-0001nO-00 for nsis@ietf.org; Mon, 23 Jun 2003 08:34:33 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19UQWc-0001nF-00 for nsis@ietf.org; Mon, 23 Jun 2003 08:34:22 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5NCYGw2003029; Mon, 23 Jun 2003 14:34:16 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 23 Jun 2003 14:36:26 +0200 Message-ID: From: "Attila Bader (ETH)" To: Michael Welzl , Bob Braden Cc: orobert.hancock@roke.co.uk, nsis@ietf.org Subject: RE: AW: [NSIS] framework: proposal on congestion/flow control Date: Mon, 23 Jun 2003 14:32:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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 Michael and Bob, Please note that we have shown an example for an architecture in which internal nodes are stateless. Please see the following draft: http://www.ietf.org/internet-drafts/draft-westberg-proposal-for-rsvpv2-nslp-00.txt Best regards, Attila > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of > Michael Welzl > Sent: Monday, June 23, 2003 8:10 AM > To: Bob Braden > Cc: orobert.hancock@roke.co.uk; nsis@ietf.org > Subject: Re: AW: [NSIS] framework: proposal on congestion/flow control > > > Dear Bob, > > > Michael, > > > > I could be wrong, but it seems to me that to do congestion > control you > > need state. The issue is when that state is established. > In the case > > of ephemeral messages that you want to send using UDP (or better, > > DCCP), I would think that the state could be set up roughly > once, when > > two neighbor nodes first discover each other. So, it's a > question of > > when, not whether, to establish state. > > > > Bob Braden > > I agree, but It's also a question of how much state you > establish, or (more important) how often you need to update it. > DCCP requires a lot of state and acks every packet, which is ok > for any long-term data transfer, but I thought that there might > be sporadic messages in signaling (error messages of some > sort ... keepalives ... stuff like that) where this would be > unnecessary overhead. > > For instance, an occasional "source quench"-like message (from > the receiver, not an intermediate router!) might suffice in > such cases. Rate-based open-loop instead of window-based > closed-loop congestion control, perhaps using rather old > state (as you mention - it is indeed a question of when!). > > And even without setting up any kind of state, it is reasonable > to limit the rate of signaling traffic: if a node generally > keeps its signaling traffic below, say, 5% of the payload it > generates, the whole signaling traffic in the whole network > will not exceed 5% of the whole payload traffic. This means > that signaling traffic scales linearly with payload (which > can, in turn, be expected to be limited through congestion > control) ... while this is not as good as full-fledged > congestion control, it's a start. I think that such a limit > was also specified for RTCP, btw. > > Doing this would be my recommendation for such sporadic > messages. > > Best regards, > Michael > > > _______________________________________________ > 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 exim@www1.ietf.org Mon Jun 23 14:25: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 OAA02627 for ; Mon, 23 Jun 2003 14:25:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NIP2722436 for nsis-archive@odin.ietf.org; Mon, 23 Jun 2003 14:25:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UVzx-0005pm-Vs; Mon, 23 Jun 2003 14:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UVzh-0005oI-8G for nsis@optimus.ietf.org; Mon, 23 Jun 2003 14:24:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02541 for ; Mon, 23 Jun 2003 14:24:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UVlE-0004QD-00 for nsis@ietf.org; Mon, 23 Jun 2003 14:09:48 -0400 Received: from tnt.isi.edu ([128.9.128.128]) by ietf-mx with esmtp (Exim 4.12) id 19UVkz-0004Ol-00 for nsis@ietf.org; Mon, 23 Jun 2003 14:09:33 -0400 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6p2/8.11.2) with ESMTP id h5NI7AK06917; Mon, 23 Jun 2003 11:07:10 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id KAA17322; Mon, 23 Jun 2003 10:56:13 -0700 (PDT) Date: Mon, 23 Jun 2003 10:56:13 -0700 (PDT) Message-Id: <200306231756.KAA17322@gra.isi.edu> To: braden@ISI.EDU, michael.welzl@uibk.ac.at Subject: Re: AW: [NSIS] framework: proposal on congestion/flow control 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: , *> *> > Michael, *> > *> > I could be wrong, but it seems to me that to do congestion control you *> > need state. The issue is when that state is established. In the case *> > of ephemeral messages that you want to send using UDP (or better, *> > DCCP), I would think that the state could be set up roughly once, when *> > two neighbor nodes first discover each other. So, it's a question of *> > when, not whether, to establish state. *> > *> > Bob Braden *> *> I agree, but It's also a question of how much state you *> establish, or (more important) how often you need to update it. *> DCCP requires a lot of state and acks every packet, which is ok *> for any long-term data transfer, but I thought that there might *> be sporadic messages in signaling (error messages of some *> sort ... keepalives ... stuff like that) where this would be *> unnecessary overhead. *> *> For instance, an occasional "source quench"-like message (from *> the receiver, not an intermediate router!) might suffice in *> such cases. Rate-based open-loop instead of window-based *> closed-loop congestion control, perhaps using rather old *> state (as you mention - it is indeed a question of when!). Michael, I believe that you are confusing congestion control with flow control. The "source-quench-like" or windowing mechanisms you describe are hop/hop flow control. Congestion control has to do with the interaction of the signaling traffic with other Internet traffic. We don't want signaling traffic to starve out other traffic, either TCP traffic or realtime traffic. Internet transport is supposed to be "TCP-friendly". I have not looked at DCCP lately, but I assume it has the minimal mechanism required for honest Internet congestion control. *> *> And even without setting up any kind of state, it is reasonable *> to limit the rate of signaling traffic: if a node generally *> keeps its signaling traffic below, say, 5% of the payload it *> generates, the whole signaling traffic in the whole network *> will not exceed 5% of the whole payload traffic. This means *> that signaling traffic scales linearly with payload (which *> can, in turn, be expected to be limited through congestion *> control) ... while this is not as good as full-fledged *> congestion control, it's a start. I think that such a limit *> was also specified for RTCP, btw. As you imply above, the notion of sporadic needs to be made more precise, because there can be bursty behavior even when the steady-state rates are reasonable. Suppose that a route changes, so a lot of reservations have to be signaled at one time. The initiating NSIS node and the recipient NSIS node may be perfectly happy to blast across these reservation packets, but the result could be like a DoS attack on the link! Is your fixed percentage bound good enough? I don't know. 5% FEELS OK, because it seems negligble, and we assume there are not 10 other fixed overheads each taking 5%. There is only one NSIS flow (or is there?) And if the other traffic is low, you might want to let signaling take a higher percentage. And the situation might be different in the core of the network and in the edge. Finally, such rate limiting is NOT congestion control, since it does not react dynamically to congestion. It is like an RTP media stream. It always seemed me reasonable that NSIS (or RSVP) traffic should be given its own scheduling class (e.g., diffserv code point), but nobody seemed to agree. None of this is to say that I know the answer here; it's a hard problem. As a practical matter, the AD (;-)) will decide what congestion control in NSIS is good enough. But then, if NSIS were easy, it would have been done 5 years ago, I guess. Bob Braden *> *> Doing this would be my recommendation for such sporadic *> messages. *> *> Best regards, *> Michael *> _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jun 23 14:25: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 OAA02638 for ; Mon, 23 Jun 2003 14:25:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NIP2X22474 for nsis-archive@odin.ietf.org; Mon, 23 Jun 2003 14:25:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UVzy-0005qO-FF; Mon, 23 Jun 2003 14:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UVzh-0005oN-En for nsis@optimus.ietf.org; Mon, 23 Jun 2003 14:24:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02545 for ; Mon, 23 Jun 2003 14:24:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UVlE-0004QB-00 for nsis@ietf.org; Mon, 23 Jun 2003 14:09:48 -0400 Received: from tnt.isi.edu ([128.9.128.128]) by ietf-mx with esmtp (Exim 4.12) id 19UVkz-0004Ok-00 for nsis@ietf.org; Mon, 23 Jun 2003 14:09:33 -0400 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6p2/8.11.2) with ESMTP id h5NI7AK06911; Mon, 23 Jun 2003 11:07:10 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id LAA17339; Mon, 23 Jun 2003 11:01:35 -0700 (PDT) Date: Mon, 23 Jun 2003 11:01:35 -0700 (PDT) Message-Id: <200306231801.LAA17339@gra.isi.edu> To: Attila.Bader@eth.ericsson.se Subject: RE: [NSIS] yet another attempted summary of fragmentation discuss ion 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: , Attila, Your argument about fragmentation is supported by the analogy of the Don't Fragment (DF) bit in the IP header. The same argument I made for NSIS could be applied to the DF bit [I did, and I was wrong... DF did turn out to be useful in triggering an error signal. I guess we don't always learn from our mistakes.] So I accept that there is an argument for a DF bit in the NSLP <-> NTLP interface. Bob Braden _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jun 23 19:26: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 TAA15112 for ; Mon, 23 Jun 2003 19:26:28 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NNQ1p01181 for nsis-archive@odin.ietf.org; Mon, 23 Jun 2003 19:26:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UahE-0000I4-R5; Mon, 23 Jun 2003 19:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uagj-0000HO-OD for nsis@optimus.ietf.org; Mon, 23 Jun 2003 19:25:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15095 for ; Mon, 23 Jun 2003 19:25:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uagi-0006YX-00 for nsis@ietf.org; Mon, 23 Jun 2003 19:25:28 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19UagX-0006Y7-00 for nsis@ietf.org; Mon, 23 Jun 2003 19:25:17 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 00:24:18 +0100 Message-ID: From: "Hancock, Robert" To: Bob Braden , michael.welzl@uibk.ac.at Cc: nsis@ietf.org Subject: RE: AW: [NSIS] framework: proposal on congestion/flow control Date: Tue, 24 Jun 2003 00:24: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: , dear all, i think my sympathies are with Bob here. if it is worth implementing congestion control at all, we should use it for all the signalling traffic. in my view, the cost of congestion control is not the per-packet processing overhead; it's the architectural constraint that (so far as we all can tell, I think) you can't send messages without knowing what congestion control state to apply, i.e. which peer you are sending to. so, applying congestion control directly to PATH messages (for example) is liable to be non-trivial. some detailed points: *) shouldn't we generally try to avoid 'magic numbers' (like 5%) in the protocol suite architecture? *) i can see that it makes sense for signalling to have resources engineered for it. however, NSIS protocols will have to be deployed incrementally, and will short (and very likely long) term need to operate over network clouds with no QoS support at all. so, I don't think we can depend on this as a general solution. *) we have agreed earlier (I think) that a signalling application isn't forced to use the NTLP to transport all its messages. the question at hand is, should the NTLP guarantee that it will forward messages adaptively (so as not to cause congestion) - then an NSLP which *only* uses the NTLP is pre-guaranteed to be network friendly. [As an aside, we've just finished writing an NSLP definition which optionally sends some messages outside the NTLP like this, to skip processing in network interior nodes - very like rfc3175 in fact. but it's very hard to be convincing that the result is network friendly overall. i'd be much happier with a congestion-controlling NTLP that was able to bypass interior nodes the same way. I suspect that argument is still to come.] cheers, r. > -----Original Message----- > From: Bob Braden [mailto:braden@ISI.EDU] > Sent: Monday, June 23, 2003 18:56 > To: braden@ISI.EDU; michael.welzl@uibk.ac.at > Cc: nsis@ietf.org > Subject: Re: AW: [NSIS] framework: proposal on congestion/flow control > > > *> > *> > Michael, > *> > > *> > I could be wrong, but it seems to me that to do > congestion control you > *> > need state. The issue is when that state is > established. In the case > *> > of ephemeral messages that you want to send using UDP > (or better, > *> > DCCP), I would think that the state could be set up > roughly once, when > *> > two neighbor nodes first discover each other. So, > it's a question of > *> > when, not whether, to establish state. > *> > > *> > Bob Braden > *> > *> I agree, but It's also a question of how much state you > *> establish, or (more important) how often you need to update it. > *> DCCP requires a lot of state and acks every packet, which is ok > *> for any long-term data transfer, but I thought that there might > *> be sporadic messages in signaling (error messages of some > *> sort ... keepalives ... stuff like that) where this would be > *> unnecessary overhead. > *> > *> For instance, an occasional "source quench"-like message (from > *> the receiver, not an intermediate router!) might suffice in > *> such cases. Rate-based open-loop instead of window-based > *> closed-loop congestion control, perhaps using rather old > *> state (as you mention - it is indeed a question of when!). > > Michael, > > I believe that you are confusing congestion control with flow control. > The "source-quench-like" or windowing mechanisms you describe are > hop/hop flow control. Congestion control has to do with the > interaction > of the signaling traffic with other Internet traffic. We don't > want signaling traffic to starve out other traffic, either TCP traffic > or realtime traffic. Internet transport is supposed to be > "TCP-friendly". > I have not looked at DCCP lately, but I assume it has the minimal > mechanism required for honest Internet congestion control. > > *> > *> And even without setting up any kind of state, it is reasonable > *> to limit the rate of signaling traffic: if a node generally > *> keeps its signaling traffic below, say, 5% of the payload it > *> generates, the whole signaling traffic in the whole network > *> will not exceed 5% of the whole payload traffic. This means > *> that signaling traffic scales linearly with payload (which > *> can, in turn, be expected to be limited through congestion > *> control) ... while this is not as good as full-fledged > *> congestion control, it's a start. I think that such a limit > *> was also specified for RTCP, btw. > > As you imply above, the notion of sporadic needs to be made more > precise, because there can be bursty behavior even when the > steady-state rates are reasonable. Suppose that a route changes, so a > lot of reservations have to be signaled at one time. The initiating > NSIS node and the recipient NSIS node may be perfectly happy to blast > across these reservation packets, but the result could be like a DoS > attack on the link! > > Is your fixed percentage bound good enough? I don't know. 5% FEELS > OK, because it seems negligble, and we assume there are not 10 other > fixed overheads each taking 5%. There is only one NSIS flow (or is > there?) And if the other traffic is low, you might want to let > signaling take a higher percentage. And the situation might be > different in the core of the network and in the edge. Finally, > such rate limiting is NOT congestion control, since it does not > react dynamically to congestion. It is like an RTP media stream. > > It always seemed me reasonable that NSIS (or RSVP) traffic should > be given its own scheduling class (e.g., diffserv code point), but > nobody seemed to agree. > > None of this is to say that I know the answer here; it's a hard > problem. As a practical matter, the AD (;-)) will decide what > congestion control in NSIS is good enough. But then, if NSIS > were easy, it would have been done 5 years ago, I guess. > > Bob Braden > > *> > *> Doing this would be my recommendation for such sporadic > *> messages. > *> > *> Best regards, > *> Michael > *> > > _______________________________________________ > 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 exim@www1.ietf.org Mon Jun 23 20:13: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 TAA15111 for ; Mon, 23 Jun 2003 19:26:28 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NNQ1A01180 for nsis-archive@odin.ietf.org; Mon, 23 Jun 2003 19:26:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UahE-0000Hu-FU; Mon, 23 Jun 2003 19:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uag9-0000Gw-Np for nsis@optimus.ietf.org; Mon, 23 Jun 2003 19:25:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15081 for ; Mon, 23 Jun 2003 19:24:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uag8-0006YN-00 for nsis@ietf.org; Mon, 23 Jun 2003 19:24:52 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19Uafx-0006Y8-00 for nsis@ietf.org; Mon, 23 Jun 2003 19:24:41 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 00:24:21 +0100 Message-ID: From: "Hancock, Robert" To: Bob Braden , Attila.Bader@eth.ericsson.se Cc: nsis@ietf.org Subject: RE: [NSIS] yet another attempted summary of fragmentation discuss ion Date: Tue, 24 Jun 2003 00:24:22 +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: , dear all, so, what do others think? one point i would emphasise is that this would be a feature we add to the NTLP for the benefit of signalling applications that might want it; it doesn't do anything to protect NTLP implementations from fragmentation load. at the moment I can't see a signalling application that would want this facility (which is primarily a performance optimisation), but on the other hand we are supposed to be designing for the future. the one circumstance where i could see this facility being useful would be where a signalling application needed to transfer gigantic amounts of data between peers (an authorisation object containing a video clip?) and wanted to discover the best size to which to segment its own data. but then i think we'd be better to define a mandatory-to-implement signalling MTU discovery NSLP which would return the answer in one go, rather than some trial and error mechanism. r. PS. while the IP experience may be relevant, i don't see that the conclusions have to be the same. after all, one of the main points of DF in IP is to allow TCP streams to segment their data optimally, since TCP is far better at reassembly than IP is. if the NTLP is that bad at reassembling fragments - essentially through unreliability - then we should probably change something. why else is DF used? > -----Original Message----- > From: Bob Braden [mailto:braden@ISI.EDU] > Sent: Monday, June 23, 2003 19:02 > To: Attila.Bader@eth.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] yet another attempted summary of fragmentation > discuss ion > > > > Attila, > > Your argument about fragmentation is supported by the analogy of the > Don't Fragment (DF) bit in the IP header. The same argument > I made for > NSIS could be applied to the DF bit [I did, and I was wrong... DF did > turn out to be useful in triggering an error signal. I guess we don't > always learn from our mistakes.] > > So I accept that there is an argument for a DF bit in the > NSLP <-> NTLP > interface. > > Bob Braden > > > > > > _______________________________________________ > 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 exim@www1.ietf.org Mon Jun 23 22:36: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 WAA18948 for ; Mon, 23 Jun 2003 22:36:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5O2a5E19198 for nsis-archive@odin.ietf.org; Mon, 23 Jun 2003 22:36:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Udf8-0004z6-47; Mon, 23 Jun 2003 22:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UdeJ-0004y9-Rf for nsis@optimus.ietf.org; Mon, 23 Jun 2003 22:35:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18930 for ; Mon, 23 Jun 2003 22:34:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ude1-0007XH-00 for nsis@ietf.org; Mon, 23 Jun 2003 22:34:53 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19Uddl-0007XD-00 for nsis@ietf.org; Mon, 23 Jun 2003 22:34:37 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h5O2YCkM005401; Mon, 23 Jun 2003 22:34:12 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h5O2YAN04270; Mon, 23 Jun 2003 22:34:10 -0400 Message-ID: <3EF7B7B9.2020300@cs.columbia.edu> Date: Mon, 23 Jun 2003 22:30:17 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030603 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" CC: nsis@ietf.org Subject: Re: AW: [NSIS] framework: proposal on congestion/flow control 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 Hancock, Robert wrote: > in my view, the cost of congestion control is not the per-packet > processing overhead; it's the architectural constraint that (so far > as we all can tell, I think) you can't send messages without > knowing what congestion control state to apply, i.e. which peer you are > sending to. so, applying congestion control directly to PATH messages > (for example) is liable to be non-trivial. This depends. I just submitted a draft, temporarily at http://www.cs.columbia.edu/~hgs/nsis/gimps/draft-schulzrinne-nsis-ntlp-00.html that tries to find a compromise similar to all existing congestion-controlled transport protocols: the first small message is (congestion-control) free. To be more precise, if you know where you are going, by previous state or some external knowledge (e.g., all your non-local messages go through a border router or you are running a link-state routing protocol that somehow conveys this information or all your routers support NTLP), you use an existing congestion-controlled association. Large messages that could cause congestion themselves are always subject to congestion control. After all, TCP SYN and kin aren't congestion controlled, either, except that their loss causes exponential back-off. I think the best we can hope to do is to mimick this behavior in environments where the first message goes off into the blue yonder. > > some detailed points: > *) shouldn't we generally try to avoid 'magic numbers' (like 5%) in the > protocol suite architecture? I don't see how any magic number can make sense. RTP uses a 5% default for RTCP, but it is in relation to a well-defined 'payload bandwidth', the media stream itself. There is no similar ratio for NTLP, particularly once you stray a bit beyond the well-trod field of QoS signaling. If you ask for a large reservation, are you allowed to send more signaling messages? That seems the wrong incentive. > *) i can see that it makes sense for signalling to have resources > engineered for it. however, NSIS protocols will have to be deployed > incrementally, and will short (and very likely long) term need to operate > over network clouds with no QoS support at all. so, I don't think we can > depend on this as a general solution. I agree that edge-to-edge signaling will be common. I think we want to engineer a 'safe' protocol that operates according to well-established 'good neighbor' principles even if the application differs from what we can currently picture. As a somewhat far-fetched example, consider an application that updates all routers along a path with some active-network code. It's far more efficient to do this with NTLP than having individual transport connections from the origin to each router, but there's no sensible 5% limit (over what time horizon? compared to what bandwidth?) and the messages can be large. > [As an aside, we've just finished writing an NSLP definition which optionally > sends some messages outside the NTLP like this, to skip processing in network > interior nodes - very like rfc3175 in fact. but it's very hard to be convincing > that the result is network friendly overall. i'd be much happier with a > congestion-controlling NTLP that was able to bypass interior nodes the same > way. I suspect that argument is still to come.] Nothing prevents 'short-cut' or 'express' NTLP connections, in general. This is just a matter of trivially tuning the discovery mechanism. Henning _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jun 23 23:10:54 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 XAA19526 for ; Mon, 23 Jun 2003 23:10:54 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5O3A2t23403 for nsis-archive@odin.ietf.org; Mon, 23 Jun 2003 23:10:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UeC1-00065M-Nf; Mon, 23 Jun 2003 23:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UeBR-00064y-1m for nsis@optimus.ietf.org; Mon, 23 Jun 2003 23:09:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19477 for ; Mon, 23 Jun 2003 23:09:20 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UeBN-0007fa-00 for nsis@ietf.org; Mon, 23 Jun 2003 23:09:21 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19UeBC-0007fX-00 for nsis@ietf.org; Mon, 23 Jun 2003 23:09:10 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5O38o927571 for ; Tue, 24 Jun 2003 06:08:50 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 24 Jun 2003 06:08:50 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 24 Jun 2003 06:08:49 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 24 Jun 2003 06:08:48 +0300 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" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] yet another attempted summary of fragmentation discuss ion Date: Tue, 24 Jun 2003 06:08:47 +0300 Message-ID: Thread-Topic: [NSIS] yet another attempted summary of fragmentation discuss ion Thread-Index: AcM53teSPaGWXeDOR72ZAfmYao0qYAAHsQCg To: , , Cc: X-OriginalArrivalTime: 24 Jun 2003 03:08:48.0554 (UTC) FILETIME=[EE63E8A0:01C339FD] Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi all, As I said before, this is protocol stuff, not framework stuff. There is WG consensus that the framework document should say that NTLP handles fragmentation when needed. I don't think we should pile extra text, conditional clauses or text around it, we should keep it simple and in the protocol design phase for NTLP, we cover potential corner cases, etc. Unless there is strong opposition to this position, I think we should move on. John > -----Original Message----- > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > Sent: 24 June, 2003 02:24 > To: Bob Braden; Attila.Bader@eth.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] yet another attempted summary of fragmentation > discuss ion >=20 >=20 > dear all, >=20 > so, what do others think? >=20 > one point i would emphasise is that this would be a feature=20 > we add to the > NTLP > for the benefit of signalling applications that might want=20 > it; it doesn't > do anything to protect NTLP implementations from fragmentation load.=20 >=20 > at the moment I can't see a signalling application that would=20 > want this=20 > facility (which is primarily a performance optimisation), but=20 > on the other > hand we are supposed to be designing for the future. >=20 > the one circumstance where i could see this facility being=20 > useful would be > where a signalling application needed to transfer gigantic=20 > amounts of data > between peers (an authorisation object containing a video=20 > clip?) and wanted > to discover the best size to which to segment its own data.=20 > but then i think > we'd be better to define a mandatory-to-implement signalling=20 > MTU discovery=20 > NSLP which would return the answer in one go, rather than=20 > some trial and=20 > error mechanism. >=20 > r. >=20 > PS. while the IP experience may be relevant, i don't see that the > conclusions > have to be the same. after all, one of the main points of DF=20 > in IP is to > allow TCP streams to segment their data optimally, since TCP=20 > is far better > at > reassembly than IP is. if the NTLP is that bad at=20 > reassembling fragments - > essentially through unreliability - then we should probably change > something. >=20 > why else is DF used? >=20 > > -----Original Message----- > > From: Bob Braden [mailto:braden@ISI.EDU] > > Sent: Monday, June 23, 2003 19:02 > > To: Attila.Bader@eth.ericsson.se > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] yet another attempted summary of fragmentation > > discuss ion > >=20 > >=20 > >=20 > > Attila, > >=20 > > Your argument about fragmentation is supported by the analogy of the > > Don't Fragment (DF) bit in the IP header. The same argument=20 > > I made for > > NSIS could be applied to the DF bit [I did, and I was=20 > wrong... DF did > > turn out to be useful in triggering an error signal. I=20 > guess we don't > > always learn from our mistakes.] > >=20 > > So I accept that there is an argument for a DF bit in the=20 > > NSLP <-> NTLP > > interface. > >=20 > > Bob Braden > >=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jun 23 23:59: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 XAA20308 for ; Mon, 23 Jun 2003 23:59:28 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5O3x1D27332 for nsis-archive@odin.ietf.org; Mon, 23 Jun 2003 23:59:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UexR-00076d-3S; Mon, 23 Jun 2003 23:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uewk-00076I-0g for nsis@optimus.ietf.org; Mon, 23 Jun 2003 23:58:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20283 for ; Mon, 23 Jun 2003 23:58:14 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uewh-00001E-00 for nsis@ietf.org; Mon, 23 Jun 2003 23:58:15 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19UewW-000018-00 for nsis@ietf.org; Mon, 23 Jun 2003 23:58:05 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5O3vja02733 for ; Tue, 24 Jun 2003 06:57:45 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 24 Jun 2003 06:57:44 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 24 Jun 2003 06:57:44 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 24 Jun 2003 06:57:44 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 24 Jun 2003 06:57:43 +0300 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" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [NSIS] framework: proposal on congestion/flow control Date: Tue, 24 Jun 2003 06:57:42 +0300 Message-ID: Thread-Topic: AW: [NSIS] framework: proposal on congestion/flow control Thread-Index: AcM5tNVyFO2LC0o5R7iTpJzDS5jlfwAT7WZw To: , Cc: X-OriginalArrivalTime: 24 Jun 2003 03:57:44.0157 (UTC) FILETIME=[C42560D0:01C33A04] Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi Bob, Quick question for you: > I believe that you are confusing congestion control with flow control. > The "source-quench-like" or windowing mechanisms you describe are > hop/hop flow control. Congestion control has to do with the = interaction > of the signaling traffic with other Internet traffic. We don't > want signaling traffic to starve out other traffic, either TCP traffic > or realtime traffic. Internet transport is supposed to be=20 > "TCP-friendly". Michael seems to be talking about flow-control on a hop-by-hop=20 basis. I've always considered congestion control as a end-to-end mechanism. What are your thoughts about having congestion control on=20 a hop-by-hop basis - to me this sounds sub-optimal. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jun 24 02:50: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 CAA05516 for ; Tue, 24 Jun 2003 02:50:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5O6o4D23542 for nsis-archive@odin.ietf.org; Tue, 24 Jun 2003 02:50:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uhcv-000670-OE; Tue, 24 Jun 2003 02:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uhco-00066R-Qz for nsis@optimus.ietf.org; Tue, 24 Jun 2003 02:49:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05506 for ; Tue, 24 Jun 2003 02:49:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uhcl-000113-00 for nsis@ietf.org; Tue, 24 Jun 2003 02:49:51 -0400 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx with esmtp (Exim 4.12) id 19Uhca-00010Z-00 for nsis@ietf.org; Tue, 24 Jun 2003 02:49:40 -0400 Received: from lap10-c703.uibk.ac.at (lap10-c703.uibk.ac.at [138.232.65.57]) by smtp.uibk.ac.at (8.12.9/8.12.9/F1) with ESMTP id h5O6mgqd024112; Tue, 24 Jun 2003 08:48:42 +0200 Subject: RE: AW: [NSIS] framework: proposal on congestion/flow control From: Michael Welzl To: john.loughney@nokia.com Cc: braden@ISI.EDU, nsis@ietf.org In-Reply-To: References: Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1056437240.1725.27.camel@lap10-c703> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 24 Jun 2003 08:47:20 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.5 () IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03 X-Scanned-By: MIMEDefang 2.26 at uibk.ac.at (www . roaringpenguin . com / mimedefang) 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 all, > Hi Bob, > > Quick question for you: > > > I believe that you are confusing congestion control with flow control. > > The "source-quench-like" or windowing mechanisms you describe are > > hop/hop flow control. Congestion control has to do with the interaction > > of the signaling traffic with other Internet traffic. We don't > > want signaling traffic to starve out other traffic, either TCP traffic > > or realtime traffic. Internet transport is supposed to be > > "TCP-friendly". > > Michael seems to be talking about flow-control on a hop-by-hop > basis. I've always considered congestion control as a end-to-end > mechanism. What are your thoughts about having congestion control on > a hop-by-hop basis - to me this sounds sub-optimal. This is all wrong. Let me quote this sentence from my original message: > For instance, an occasional "source quench"-like message (from > the receiver, not an intermediate router!) might suffice in > such cases. So I was talking about a message that would be semantically similar to source quench but NOT something that would be used on a hop-by-hop basis. Flow control is the idea of protecting a receiver from overload. Congestion control is the idea of protecting the network from overload. Hop-by-hop flow control ... well ... is the idea of protecting intermediate nodes from overload, which clearly relates to congestion control - hop by hop flow control can REALIZE congestion control. Just because TCP does it on a strict end-to-end basis, that doesn't mean that anything happening in between is NOT congestion control - RED and ECN are good examples of network internal (hop by hop, if you will) mechanisms that work nicely. ICMP SQ failed because it doesn't scale. Anyhow, that's not the issue here. This is just to clarify what I meant - I meant rate-based congestion control, where a receiver (not an intermediate hop!) would send an occasional "reduce your rate" message instead of ack clocking. Best regards, Michael _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jun 24 03:30: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 DAA06216 for ; Tue, 24 Jun 2003 03:30:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5O7U2H28094 for nsis-archive@odin.ietf.org; Tue, 24 Jun 2003 03:30:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UiFd-0007J1-QE; Tue, 24 Jun 2003 03:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UiF5-0007IF-TU for nsis@optimus.ietf.org; Tue, 24 Jun 2003 03:29:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06198 for ; Tue, 24 Jun 2003 03:29:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UiF3-0001Bt-00 for nsis@ietf.org; Tue, 24 Jun 2003 03:29:25 -0400 Received: from lmr1.uibk.ac.at ([138.232.1.142] helo=smtp.uibk.ac.at) by ietf-mx with esmtp (Exim 4.12) id 19UiEs-0001Bo-00 for nsis@ietf.org; Tue, 24 Jun 2003 03:29:14 -0400 Received: from lap10-c703.uibk.ac.at (lap10-c703.uibk.ac.at [138.232.65.57]) by smtp.uibk.ac.at (8.12.9/8.12.9/F1) with ESMTP id h5O7Sdqd028676; Tue, 24 Jun 2003 09:28:40 +0200 Subject: RE: AW: [NSIS] framework: proposal on congestion/flow control From: Michael Welzl To: "Hancock, Robert" Cc: Bob Braden , nsis@ietf.org In-Reply-To: References: Content-Type: text/plain Organization: University of Innsbruck Message-Id: <1056439638.1726.62.camel@lap10-c703> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 24 Jun 2003 09:27:18 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 () IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 X-Scanned-By: MIMEDefang 2.26 at uibk.ac.at (www . roaringpenguin . com / mimedefang) 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 all, > i think my sympathies are with Bob here. if it is worth implementing > congestion control at all, we should use it for all the signalling > traffic. My original point was that even signaling traffic that would use UDP anyhow should have SOME kind of congestion control. I wasn't aware that the idea is to use full-fledged TCP or DCCP for each and every type of signaling, but that's fine with me. > in my view, the cost of congestion control is not the per-packet > processing overhead; it's the architectural constraint that (so far > as we all can tell, I think) you can't send messages without > knowing what congestion control state to apply, i.e. which peer you are > sending to. so, applying congestion control directly to PATH messages > (for example) is liable to be non-trivial. Right. > some detailed points: > *) shouldn't we generally try to avoid 'magic numbers' (like 5%) in the > protocol suite architecture? Hmm, I agree. Magic number are a problem indeed. > *) i can see that it makes sense for signalling to have resources > engineered for it. however, NSIS protocols will have to be deployed > incrementally, and will short (and very likely long) term need to operate > over network clouds with no QoS support at all. so, I don't think we can > depend on this as a general solution. Right. > *) we have agreed earlier (I think) that a signalling > application isn't forced to use the NTLP to transport all its messages. the > question at hand is, should the NTLP guarantee that it will forward messages > adaptively (so as not to cause congestion) - then an NSLP which *only* uses > the NTLP is pre-guaranteed to be network friendly. > [As an aside, we've just finished writing an NSLP definition which optionally > sends some messages outside the NTLP like this, to skip processing in network > interior nodes - very like rfc3175 in fact. but it's very hard to be convincing > that the result is network friendly overall. i'd be much happier with a > congestion-controlling NTLP that was able to bypass interior nodes the same > way. I suspect that argument is still to come.] I would also be happier with prescribed congestion control for everything and no means to bypass it. I still claim that, in a perfect world, a congestion control mechanism should be tailored for the specific type of signaling message, but a) we have no solution at hand b) we'd better use SOME than NO congestion control So, I fully agree with everything you say. Best regards, Michael _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jun 24 04:08: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 EAA06766 for ; Tue, 24 Jun 2003 04:08:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5O883Q00869 for nsis-archive@odin.ietf.org; Tue, 24 Jun 2003 04:08:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UiqQ-0000DV-22; Tue, 24 Jun 2003 04:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UiqO-0000DK-2v for nsis@optimus.ietf.org; Tue, 24 Jun 2003 04:08:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06759 for ; Tue, 24 Jun 2003 04:07:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uiq6-0001Kk-00 for nsis@ietf.org; Tue, 24 Jun 2003 04:07:42 -0400 Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by ietf-mx with esmtp (Exim 4.12) id 19Uipv-0001Kg-00 for nsis@ietf.org; Tue, 24 Jun 2003 04:07:31 -0400 Received: from utip105 (utip105.cs.utwente.nl [130.89.13.76]) by utrhcs.cs.utwente.nl (8.12.9/8.12.9) with SMTP id h5O877Cf005717; Tue, 24 Jun 2003 10:07:08 +0200 (MET DST) Message-ID: <002001c33a27$9c0cdc90$4c0d5982@dynamic.cs.utwente.nl> From: "Georgios Karagiannis" To: , , , Cc: References: Subject: Re: [NSIS] yet another attempted summary of fragmentation discuss ion Date: Tue, 24 Jun 2003 10:07:08 +0200 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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 John Are you also saying that the DF bit solution is not excluded and it will be covered during the design phase of NTLP? If yes then I agree with your proposal. Best Regards, Georgios ----- Original Message ----- From: To: ; ; Cc: Sent: Tuesday, June 24, 2003 5:08 AM Subject: RE: [NSIS] yet another attempted summary of fragmentation discuss ion > Hi all, > > As I said before, this is protocol stuff, not framework stuff. > There is WG consensus that the framework document should > say that NTLP handles fragmentation when needed. I don't > think we should pile extra text, conditional clauses or > text around it, we should keep it simple and in the protocol > design phase for NTLP, we cover potential corner cases, > etc. > > Unless there is strong opposition to this position, I think > we should move on. > > John > > > -----Original Message----- > > From: ext Hancock, Robert [mailto:robert.hancock@roke.co.uk] > > Sent: 24 June, 2003 02:24 > > To: Bob Braden; Attila.Bader@eth.ericsson.se > > Cc: nsis@ietf.org > > Subject: RE: [NSIS] yet another attempted summary of fragmentation > > discuss ion > > > > > > dear all, > > > > so, what do others think? > > > > one point i would emphasise is that this would be a feature > > we add to the > > NTLP > > for the benefit of signalling applications that might want > > it; it doesn't > > do anything to protect NTLP implementations from fragmentation load. > > > > at the moment I can't see a signalling application that would > > want this > > facility (which is primarily a performance optimisation), but > > on the other > > hand we are supposed to be designing for the future. > > > > the one circumstance where i could see this facility being > > useful would be > > where a signalling application needed to transfer gigantic > > amounts of data > > between peers (an authorisation object containing a video > > clip?) and wanted > > to discover the best size to which to segment its own data. > > but then i think > > we'd be better to define a mandatory-to-implement signalling > > MTU discovery > > NSLP which would return the answer in one go, rather than > > some trial and > > error mechanism. > > > > r. > > > > PS. while the IP experience may be relevant, i don't see that the > > conclusions > > have to be the same. after all, one of the main points of DF > > in IP is to > > allow TCP streams to segment their data optimally, since TCP > > is far better > > at > > reassembly than IP is. if the NTLP is that bad at > > reassembling fragments - > > essentially through unreliability - then we should probably change > > something. > > > > why else is DF used? > > > > > -----Original Message----- > > > From: Bob Braden [mailto:braden@ISI.EDU] > > > Sent: Monday, June 23, 2003 19:02 > > > To: Attila.Bader@eth.ericsson.se > > > Cc: nsis@ietf.org > > > Subject: RE: [NSIS] yet another attempted summary of fragmentation > > > discuss ion > > > > > > > > > > > > Attila, > > > > > > Your argument about fragmentation is supported by the analogy of the > > > Don't Fragment (DF) bit in the IP header. The same argument > > > I made for > > > NSIS could be applied to the DF bit [I did, and I was > > wrong... DF did > > > turn out to be useful in triggering an error signal. I > > guess we don't > > > always learn from our mistakes.] > > > > > > So I accept that there is an argument for a DF bit in the > > > NSLP <-> NTLP > > > interface. > > > > > > Bob Braden > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 exim@www1.ietf.org Tue Jun 24 04:16: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 EAA06932 for ; Tue, 24 Jun 2003 04:16:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5O8G2d01577 for nsis-archive@odin.ietf.org; Tue, 24 Jun 2003 04:16:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uiy8-0000PK-T8; Tue, 24 Jun 2003 04:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UixB-0000O7-Rz for nsis@optimus.ietf.org; Tue, 24 Jun 2003 04:15:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06902 for ; Tue, 24 Jun 2003 04:14:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uix9-0001Mn-00 for nsis@ietf.org; Tue, 24 Jun 2003 04:14:59 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Uiwy-0001Mg-00 for nsis@ietf.org; Tue, 24 Jun 2003 04:14:48 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5O8Ehw2010288; Tue, 24 Jun 2003 10:14:43 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 24 Jun 2003 10:16:57 +0200 Message-ID: From: "Attila Bader (ETH)" To: Bob Braden Cc: nsis@ietf.org, john.loughney@nokia.com, "Hancock, Robert" Subject: RE: [NSIS] yet another attempted summary of fragmentation discuss ion Date: Tue, 24 Jun 2003 10:13:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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 Bob, I appreciate your experience. In my mind there is a light-weight application which is sensitive to timing, e.g. using sliding window method for better performace, using stateless interior nodes for scalability. It may not allow for an intermediate node to wait for fragments. If the application sends small messages and it may never be fragmented in practice and may never cause problem. I agree with John that this discussion should be continued in design phase. What I would like to achieve is that we should not close the window for this kind of applications. Best regards, Attila > -----Original Message----- > From: nsis-admin@ietf.org [mailto:nsis-admin@ietf.org]On Behalf Of Bob > Braden > Sent: Monday, June 23, 2003 8:02 PM > To: Attila.Bader@eth.ericsson.se > Cc: nsis@ietf.org > Subject: RE: [NSIS] yet another attempted summary of fragmentation > discussion > > > > Attila, > > Your argument about fragmentation is supported by the analogy of the > Don't Fragment (DF) bit in the IP header. The same argument > I made for > NSIS could be applied to the DF bit [I did, and I was wrong... DF did > turn out to be useful in triggering an error signal. I guess we don't > always learn from our mistakes.] > > So I accept that there is an argument for a DF bit in the > NSLP <-> NTLP > interface. > > Bob Braden > > > > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Jun 24 10:19: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 KAA18076 for ; Tue, 24 Jun 2003 10:19:28 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OEJ1d16587 for nsis-archive@odin.ietf.org; Tue, 24 Jun 2003 10:19:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UodR-0004JN-3o; Tue, 24 Jun 2003 10:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uocn-0004Id-FO for nsis@optimus.ietf.org; Tue, 24 Jun 2003 10:18:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18023 for ; Tue, 24 Jun 2003 10:18:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uock-0003E7-00 for nsis@ietf.org; Tue, 24 Jun 2003 10:18:18 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 19UocZ-0003DW-00 for nsis@ietf.org; Tue, 24 Jun 2003 10:18:08 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 19Uoay-0005DH-00; Tue, 24 Jun 2003 16:16:28 +0200 Received: from i72ms0.tm.uni-karlsruhe.de ([141.3.71.10] helo=smtp.ipv6.tm.uni-karlsruhe.de ident=8) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 19Uoay-0003x3-00; Tue, 24 Jun 2003 16:16:28 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de ([3ffe:400:20:1:2e0:29ff:fe3e:c87] ident=mail) by smtp.ipv6.tm.uni-karlsruhe.de with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.12) id 19Uoay-0000Gj-00; Tue, 24 Jun 2003 16:16:28 +0200 Received: from localhost ([::1] helo=vorta.ipv6.tm.uni-karlsruhe.de ident=bless) by vorta.ipv6.tm.uni-karlsruhe.de with smtp (Exim 4.05) id 19Uoax-0002T2-00; Tue, 24 Jun 2003 16:16:27 +0200 Date: Tue, 24 Jun 2003 16:16:27 +0200 From: Roland Bless To: Jukka MJ Manner Cc: nsis@ietf.org Subject: Re: [NSIS] RE: Security Threats for NSIS draft Message-Id: <20030624161627.27d2a2fb.bless@tm.uka.de> In-Reply-To: References: <2A8DB02E3018D411901B009027FD3A3F036760E6@mchp905a.mch.sbs.de> Organization: Institute of Telematics, University of Karlsruhe X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) 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, On Wed, 18 Jun 2003 15:33:09 +0300 (EEST) Jukka MJ Manner wrote: > The basic idea of regrouping the threats sounds like a good thing, I also > had some trouble following "the story". Also, a table summarizing the ^^^^^^^^^ Confirmed, I had the same impression while reading it. > threats and maybe giving a short example of a solution would be good. Some > other nits: > > - A clear intro would be needed, one that says in the first lines of the > introduction what this document is about. After that you can tell what is > the contents of the doc. Yup. > (- page breaks! Aargghh... I hate it when I print a document out and it > doesn't have page breaks. On A4 paper, I get more lines than the IETF std > number.) I hate it too, but as I read on the IETF discussion list, some people don't want to waste their time in generating FFs. I have a perl script "makeFFintoRFC" (actually the one line below) that does the trick. I usually use it in a pipe just before a2ps for pretty printing. perl -pe 's/^(.*\[?Page\s*[0-9]+\]?)/\1\014/i;s/^([:alpha:]+\w+.*\s{4,}[0-9]+\s*)/\1\014/i' $* Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jun 24 12:13: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 MAA22080 for ; Tue, 24 Jun 2003 12:13:27 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OGD0I05138 for nsis-archive@odin.ietf.org; Tue, 24 Jun 2003 12:13:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UqPk-0001Kl-8m; Tue, 24 Jun 2003 12:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UqPG-0001K0-Ac for nsis@optimus.ietf.org; Tue, 24 Jun 2003 12:12:30 -0400 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22040 for ; Tue, 24 Jun 2003 12:12:27 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6p2/8.11.2) with ESMTP id h5OG7DK07072; Tue, 24 Jun 2003 09:07:13 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id IAA17609; Tue, 24 Jun 2003 08:55:39 -0700 (PDT) Date: Tue, 24 Jun 2003 08:55:39 -0700 (PDT) Message-Id: <200306241555.IAA17609@gra.isi.edu> To: braden@ISI.EDU, michael.welzl@uibk.ac.at, john.loughney@nokia.com Subject: RE: AW: [NSIS] framework: proposal on congestion/flow control 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: , *> *> Quick question for you: *> *> > I believe that you are confusing congestion control with flow control. *> > The "source-quench-like" or windowing mechanisms you describe are *> > hop/hop flow control. Congestion control has to do with the interaction *> > of the signaling traffic with other Internet traffic. We don't *> > want signaling traffic to starve out other traffic, either TCP traffic *> > or realtime traffic. Internet transport is supposed to be *> > "TCP-friendly". *> *> Michael seems to be talking about flow-control on a hop-by-hop *> basis. I've always considered congestion control as a end-to-end *> mechanism. What are your thoughts about having congestion control on *> a hop-by-hop basis - to me this sounds sub-optimal. *> *> John *> John, Perhaps I was sloppy... I meant hop/hop in the sense of NSIS hops. For NSIS traffic between NSIS neighbors, there is not distinction between that and E2E; the neighbors ARE the ends. Does this help? Bob _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Tue Jun 24 12:18: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 MAA22345 for ; Tue, 24 Jun 2003 12:18:28 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OGI0N06944 for nsis-archive@odin.ietf.org; Tue, 24 Jun 2003 12:18:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UqUa-0001nu-S6; Tue, 24 Jun 2003 12:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UqTf-0001n9-6e for nsis@optimus.ietf.org; Tue, 24 Jun 2003 12:17:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22298 for ; Tue, 24 Jun 2003 12:16:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UqTO-00042b-00 for nsis@ietf.org; Tue, 24 Jun 2003 12:16:46 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 19UqTD-00042W-00 for nsis@ietf.org; Tue, 24 Jun 2003 12:16:35 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id h5OGGTl11202; Tue, 24 Jun 2003 18:16:29 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h5OGGS416275; Tue, 24 Jun 2003 18:16:29 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 18:16:28 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03676185@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Roland Bless'" , Jukka MJ Manner Cc: nsis@ietf.org Subject: RE: [NSIS] RE: Security Threats for NSIS draft Date: Tue, 24 Jun 2003 18:16:21 +0200 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 all, thanks for your comments. > Hi, > > On Wed, 18 Jun 2003 15:33:09 +0300 (EEST) Jukka MJ Manner > wrote: > > > The basic idea of regrouping the threats sounds like a good > thing, I also > > had some trouble following "the story". Also, a table > summarizing the > ^^^^^^^^^ > Confirmed, I had the same impression while reading it. we are currently i the process of updating the draft based on the received comments. i hope it is then easier to follow the content of the draft. > > > threats and maybe giving a short example of a solution > would be good. solutions? several times i got the comment to keep the draft solution free. > Some > > other nits: > > > > - A clear intro would be needed, one that says in the first > lines of the > > introduction what this document is about. After that you > can tell what is > > the contents of the doc. > > Yup. this is one of modifications. > > > (- page breaks! Aargghh... I hate it when I print a > document out and it > > doesn't have page breaks. On A4 paper, I get more lines > than the IETF std > > number.) fixing this as well. sorry for making you crazy :-) > > I hate it too, but as I read on the IETF discussion list, > some people don't want to > waste their time in generating FFs. I have a perl script > "makeFFintoRFC" (actually > the one line below) that does the trick. I usually use it in > a pipe just before a2ps > for pretty printing. > perl -pe > 's/^(.*\[?Page\s*[0-9]+\]?)/\1\014/i;s/^([:alpha:]+\w+.*\s{4,} > [0-9]+\s*)/\1\014/i' $* > thanks. ciao hannes > Regards, > Roland > > _______________________________________________ > 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 exim@www1.ietf.org Tue Jun 24 12: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 MAA23421 for ; Tue, 24 Jun 2003 12:51:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OGp2c12128 for nsis-archive@odin.ietf.org; Tue, 24 Jun 2003 12:51:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ur0Y-000396-5a; Tue, 24 Jun 2003 12:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uqzq-00036b-Vj for nsis@optimus.ietf.org; Tue, 24 Jun 2003 12:50:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23384 for ; Tue, 24 Jun 2003 12:50:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uqzp-0004EZ-00 for nsis@ietf.org; Tue, 24 Jun 2003 12:50:17 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 19Uqze-0004Dy-00 for nsis@ietf.org; Tue, 24 Jun 2003 12:50:06 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 19Uqyz-0006Zj-00; Tue, 24 Jun 2003 18:49:25 +0200 Received: from i72ms0.tm.uni-karlsruhe.de ([141.3.71.10] helo=smtp.ipv6.tm.uni-karlsruhe.de ident=8) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 19Uqyz-0004r7-00; Tue, 24 Jun 2003 18:49:25 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de ([3ffe:400:20:1:2e0:29ff:fe3e:c87] ident=mail) by smtp.ipv6.tm.uni-karlsruhe.de with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.12) id 19Uqyx-0004CT-00; Tue, 24 Jun 2003 18:49:24 +0200 Received: from localhost ([::1] helo=vorta.ipv6.tm.uni-karlsruhe.de ident=bless) by vorta.ipv6.tm.uni-karlsruhe.de with smtp (Exim 4.05) id 19Uqyx-0005o2-00; Tue, 24 Jun 2003 18:49:23 +0200 Date: Tue, 24 Jun 2003 18:49:23 +0200 From: Roland Bless To: "Georgios Karagiannis" Cc: "Hancock, Robert" , Subject: Re: [NSIS] yet another attempted summary of fragmentation discussion Message-Id: <20030624184923.2329aadf.bless@tm.uka.de> In-Reply-To: <00ce01c33591$403e2350$4c0d5982@dynamic.cs.utwente.nl> References: <00ce01c33591$403e2350$4c0d5982@dynamic.cs.utwente.nl> Organization: Institute of Telematics, University of Karlsruhe X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) 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 Georgios, please see comments inline. On Wed, 18 Jun 2003 14:00:45 +0200 "Georgios Karagiannis" wrote: > Maybe the application(s) running above NSLP can determine that. > Error processing will be done only when fragmentation is required and > the NTLP is not able to do it. > Thus "processing cost A" is done only when needed, while in option (2) > it is done always. Sorry, but with respect to robustness I fully disagree here. Even if you have this "Don't fragment" bit set, an NTLP implementation has to perform the check whether the PDU will fit into an MTU on the outgoing link. If this is however not the case, you have to send an error message back. So you have to check this anyway, like in this incomplete pseudo-code: if ( length(PDU) <= MTU(outgoing_link) ) forward(PDU,outgoing_link) else { // msg too big if (DF_bit_is_set(PDU)) send_errormsg_back(PDU); // msg too big and dont fragment bit set else do_fragmented_forward(PDU,outgoing_link); // fragmentation allowed } [I guess John is right: this is really not related to the framework, but to protocol design...:-)] Avoiding the first if()-check always when the DF-bit is set will be broken (what do you do in case the NSLP did not use the correct size or the link suddenly changes and the PathMTU is no longer valid?). > So by optimizing the situation where fragmentation is not needed, you will > increase the performance of the NSIS protocol. Though I'm not against the DF-bit, I still don't see any performance advantages from it as you state. Your DF-bit assures only that fragmentation will not occur "silently". So the DF-bit is usefull in cases when you want to avoid fragmentation at all (which may have performance implications). In case the NTLP PDU is always small enough the do_fragmented_forward() will never be called anyway. With respect to reassembly: It is fairly easy to check for a "Last Fragment" bit (that is set for non-fragmented PDUs, too) so that you don't have to wait until further fragments arrive. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jun 25 11:10: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 LAA14544 for ; Wed, 25 Jun 2003 11:10:28 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFA2b30200 for nsis-archive@odin.ietf.org; Wed, 25 Jun 2003 11:10:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBuL-0007qy-LF; Wed, 25 Jun 2003 11:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBpB-0006YL-1K for nsis@optimus.ietf.org; Wed, 25 Jun 2003 11:04:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12939; Wed, 25 Jun 2003 10:53:15 -0400 (EDT) Message-Id: <200306251453.KAA12939@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: Wed, 25 Jun 2003 10:53:14 -0400 Subject: [NSIS] I-D ACTION:draft-tschofenig-nsis-sid-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 : Security Implications of the Session Identifier Author(s) : H. Tschofenig Filename : draft-tschofenig-nsis-sid-00.txt Pages : 14 Date : 2003-6-24 As one result of the analysis activities in the NSIS group it was realized that mobility and the ability to change the flow identifier causes problems with existing QoS reservations. To be able to associate a signaling message with existing state an identifier other than the flow identifier had to be used. Such an abstraction is achieved with the session identifier which allows identification of established state independently of the flow characteristics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-sid-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-sid-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-sid-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-6-25103346.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-tschofenig-nsis-sid-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-tschofenig-nsis-sid-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-25103346.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jun 25 11:35: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 LAA15707 for ; Wed, 25 Jun 2003 11:35:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFZ7d03693 for nsis-archive@odin.ietf.org; Wed, 25 Jun 2003 11:35:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIc-0000xQ-Pd; Wed, 25 Jun 2003 11:35:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBpB-0006YL-7N for nsis@optimus.ietf.org; Wed, 25 Jun 2003 11:04:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12991; Wed, 25 Jun 2003 10:53:30 -0400 (EDT) Message-Id: <200306251453.KAA12991@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: Wed, 25 Jun 2003 10:53:30 -0400 Subject: [NSIS] I-D ACTION:draft-shore-ntlp-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 : The NSIS Transport Layer Protocol (NTLP) Author(s) : M. Shore Filename : draft-shore-ntlp-00.txt Pages : 23 Date : 2003-6-24 The RSVP [RFC2205] model for communicating requests to network devices along a datapath has proven useful for a variety of appli- cations beyond what the protocol designers envisioned, and while the architectural model generalizes well the protocol itself has a number of features that limit its applicability to applications other than IntServ [RFC1633]. The NSIS working group is developing a modernized version that, among other things, is based on a 'two- layer' architecture that divides protocol function into transport and application. This document describes the transport protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shore-ntlp-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-shore-ntlp-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-shore-ntlp-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-6-25103417.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shore-ntlp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-shore-ntlp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-25103417.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jun 25 11:35: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 LAA15750 for ; Wed, 25 Jun 2003 11:35:36 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFZ9p04018 for nsis-archive@odin.ietf.org; Wed, 25 Jun 2003 11:35:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIf-00012i-EX; Wed, 25 Jun 2003 11:35:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBpA-0006YL-Rn for nsis@optimus.ietf.org; Wed, 25 Jun 2003 11:04:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12851; Wed, 25 Jun 2003 10:52:43 -0400 (EDT) Message-Id: <200306251452.KAA12851@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: Wed, 25 Jun 2003 10:52:43 -0400 Subject: [NSIS] I-D ACTION:draft-tschofenig-nsis-qos-authz-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 : QoS NSLP Authorization Issues Author(s) : H. Tschofenig Filename : draft-tschofenig-nsis-qos-authz-issues-00.txt Pages : 13 Date : 2003-6-24 Various proposals for NSIS QoS NSLPs have been published recently. The design of a QoS NSLPs has to consider more than only exchanging QoS objects. Authorization has to be handled properly to make this protocol both useful and performant. Authorization in mobile environments, unfortunately, raises additional questions. This document provides an introduction to the topic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-qos-authz-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-qos-authz-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-qos-authz-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-6-25103259.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-tschofenig-nsis-qos-authz-issues-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-tschofenig-nsis-qos-authz-issues-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-25103259.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Wed Jun 25 11:35: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 LAA15850 for ; Wed, 25 Jun 2003 11:35:42 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFZFR04788 for nsis-archive@odin.ietf.org; Wed, 25 Jun 2003 11:35:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCIl-0001F8-1f; Wed, 25 Jun 2003 11:35:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBpi-0006YL-Vz for nsis@optimus.ietf.org; Wed, 25 Jun 2003 11:05:15 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12886; Wed, 25 Jun 2003 10:52:54 -0400 (EDT) Message-Id: <200306251452.KAA12886@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nsis@ietf.org, aaa-wg@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jun 2003 10:52:54 -0400 Subject: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-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 : Requirements for a QoS AAA Protocol Author(s) : F. Alfano et al. Filename : draft-alfano-aaa-qosreq-00.txt Pages : 16 Date : 2003-6-24 This document describes requirements for a protocol that would perform Authentication, Authorization, and Accounting for Quality-of- Service reservations. This protocol would be used by elements along the path of a given application flow to authenticate a reservation request, ensure that the reservation is authorized, and to account for resources used during the life of the application flow. A QoS AAA protocol should also support dynamic authorization of QoS as a function of application and account state. While we assume the existence of some QoS reservation protocol to allow endpoints to request QoS from network elements, complete requirements for such a protocol are outside the scope of this document and a QoS AAA protocol could be used to support more than one kind of reservation protocol. A QoS AAA protocol could be used between any bearer-level network element that lies along the path of an application flow and an application server that lies anywhere in the network, allowing for a wide variety of flexible service deployment models. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosreq-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-alfano-aaa-qosreq-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-alfano-aaa-qosreq-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-6-25103318.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-alfano-aaa-qosreq-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-alfano-aaa-qosreq-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-25103318.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jun 26 04:24: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 EAA11942 for ; Thu, 26 Jun 2003 04:24:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q8O7s21640 for nsis-archive@odin.ietf.org; Thu, 26 Jun 2003 04:24:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VS33-0005cn-Mx; Thu, 26 Jun 2003 04:24:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VR4w-0001fv-1o for nsis@optimus.ietf.org; Thu, 26 Jun 2003 03:22:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10936 for ; Thu, 26 Jun 2003 03:21:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VR0z-0006K5-00 for nsis@ietf.org; Thu, 26 Jun 2003 03:17:53 -0400 Received: from mail5.telekom.de ([62.225.183.202] helo=mail1.telekom.de) by ietf-mx with esmtp (Exim 4.12) id 19VR0o-0006Je-00 for nsis@ietf.org; Thu, 26 Jun 2003 03:17:42 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 26 Jun 2003 09:16:35 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jun 2003 09:16:35 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB4F0@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: robert.hancock@roke.co.uk Cc: nsis@ietf.org Subject: Re: [NSIS] framework: proposal on congestion/flow control Date: Thu, 26 Jun 2003 09:16:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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: quoted-printable Robert, This thread is limited to congestion on the control=20 plane/signaling, isn't it? |what *is* (i think) the case is that the long-term response to=20 |congestion has to be to force the congestion up the protocol |stack and/or out to the network edge - in the end, it ends=20 |up with a user. The statement is that the signaling source must reduce=20 the "signaling rate". I agree. The only problem I see is the case when congestion results=20 from a network failure. In that case, signaling information=20 may be urgently needed on the new path (and also from a user=20 perspective). I'm not sure whether NSIS is able to optimise=20 for both. My preference would be to protect the network=20 and reduce signaling load. |this leaves open the question of whose responsibility it is to=20 |do congestion control between 'interior' nodes |*) the NTLP for its retransmissions, NSLP for everything else |*) NTLP only By retransmissions as part of congestion control you mean control of the sending rate of retransmissions? NTLP is able to ensure=20 reliable transmission of signaling messages, i.e. each message=20 will be ack'ed by the NTLP peer. If this is the case, NTLP=20 should deal with local congestion. The refresh timer values should be large enough to leave space=20 for the NTLP congestion control to add value. Otherwise NSLP=20 controls congestion.=20 Another question coming to my mind is whether there should be=20 a differentiation between network congestion and=20 application/signaling processor congestion. Something similar to ECN might be useful to protect signaling processors from=20 being overloaded. Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jun 26 04:24: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 EAA11984 for ; Thu, 26 Jun 2003 04:24:42 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q8OEc22336 for nsis-archive@odin.ietf.org; Thu, 26 Jun 2003 04:24:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VS3C-0005o6-Hi; Thu, 26 Jun 2003 04:24:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VRkI-0004TR-U2 for nsis@optimus.ietf.org; Thu, 26 Jun 2003 04:04:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11607 for ; Thu, 26 Jun 2003 04:04:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VRk1-0006Up-00 for nsis@ietf.org; Thu, 26 Jun 2003 04:04:25 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19VRjq-0006Ug-00 for nsis@ietf.org; Thu, 26 Jun 2003 04:04:14 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jun 2003 09:03:24 +0100 Message-ID: From: "Hancock, Robert" To: "'Geib, Ruediger'" Cc: nsis@ietf.org Subject: RE: [NSIS] framework: proposal on congestion/flow control Date: Thu, 26 Jun 2003 09:03: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: quoted-printable Content-Transfer-Encoding: quoted-printable 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: quoted-printable hi rudi, > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: Thursday, June 26, 2003 08:17 > To: Hancock, Robert > Cc: nsis@ietf.org > Subject: Re: [NSIS] framework: proposal on congestion/flow control >=20 >=20 > Robert, >=20 > This thread is limited to congestion on the control=20 > plane/signaling, isn't it? well, it's limited to congestion at the IP layer and at NTLP/NSLP layers. the draft discusses all of them together (e.g. because many of the causes are common), but there is some decoupling possible in the solution. >=20 > |what *is* (i think) the case is that the long-term response to=20 > |congestion has to be to force the congestion up the protocol > |stack and/or out to the network edge - in the end, it ends=20 > |up with a user. >=20 > The statement is that the signaling source must reduce=20 > the "signaling rate". I agree. > The only problem I see is the case when congestion results=20 > from a network failure. In that case, signaling information=20 > may be urgently needed on the new path (and also from a user=20 > perspective). I'm not sure whether NSIS is able to optimise=20 > for both. My preference would be to protect the network=20 > and reduce signaling load. i think this is unarguably true; however, the trick is to know whether or not the signalling you are generating is hurting the network; once you know this, a reasonable strategy is to signal as fast as possible without hurting the network. the hard part (or, 50% of the hard part) is detecting congestion reliably in=20 the first place. >=20 > |this leaves open the question of whose responsibility it is to=20 > |do congestion control between 'interior' nodes > |*) the NTLP for its retransmissions, NSLP for everything else > |*) NTLP only >=20 > By retransmissions as part of congestion control you mean control > of the sending rate of retransmissions? NTLP is able to ensure=20 > reliable transmission of signaling messages, i.e. each message=20 > will be ack'ed by the NTLP peer. If this is the case, NTLP=20 > should deal with local congestion. agreed. i don't see any alternative. > The refresh timer values should be large enough to leave space=20 > for the NTLP congestion control to add value. Otherwise NSLP=20 > controls congestion.=20 i don't really see what you mean by this. what about NSLP messages which are not refreshes, for example? >=20 > Another question coming to my mind is whether there should be=20 > a differentiation between network congestion and=20 > application/signaling processor congestion. Something similar > to ECN might be useful to protect signaling processors from=20 > being overloaded. this is the other issue considered in the draft. from a framework perspective, i think the key question is whether the NTLP provides an environment in which NSLPs can signal and detect overload implicitly (which in practice means the NTLP providing something like a=20 flow-controlled delivery service between NSLP peers), or whether the NSLPs have to do this for themselves (in which case ideas like ECN could well be useful, but are then part of the NSLP design debate). my personal view is that it is not possible to solve all the=20 problems with a flow-controlled NTLP, therefore the second approach is what we should be thinking in terms of. >=20 > Regards, R=FCdiger >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jun 26 05:01: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 FAA13076 for ; Thu, 26 Jun 2003 05:01:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5Q912x07203 for nsis-archive@odin.ietf.org; Thu, 26 Jun 2003 05:01:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VSco-0001s5-DF; Thu, 26 Jun 2003 05:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VScD-0001oX-V4 for nsis@optimus.ietf.org; Thu, 26 Jun 2003 05:00:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13060 for ; Thu, 26 Jun 2003 05:00:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VScA-0006ps-00 for nsis@ietf.org; Thu, 26 Jun 2003 05:00:22 -0400 Received: from mail5.telekom.de ([62.225.183.202] helo=mail1.telekom.de) by ietf-mx with esmtp (Exim 4.12) id 19VSbz-0006pb-00 for nsis@ietf.org; Thu, 26 Jun 2003 05:00:12 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Thu, 26 Jun 2003 10:59:17 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jun 2003 10:59:07 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB4F5@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: robert.hancock@roke.co.uk Cc: nsis@ietf.org Subject: RE: [NSIS] framework: proposal on congestion/flow control Date: Thu, 26 Jun 2003 10:59:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hello Robert |> The refresh timer values should be large enough to leave space=20 |> for the NTLP congestion control to add value. Otherwise NSLP=20 |> controls congestion.=20 | |i don't really see what you mean by this. what about NSLP messages |which are not refreshes, for example? What I want to say is that congestion control on different levels=20 should be designed in a way that both aren't active in the same=20 timescale. Usually the upper layer congestion control is slower than=20 the lower layer congestion control. My assumption is that the=20 refresh mechanism is designed to cope with congestion too in order=20 not to eliminate state caused by lost messages. There's no point in=20 retransmitting NTLP messages if there's a high probability that due=20 to a timeout state was removed in the receiving NSLP already.=20 If NSLP was having its own ACK mechanism and starts to retransmit=20 if it doesn't receive an ACK in time, this could add congestion=20 should NTLP still try to retransmit the original NSLP message in=20 the same time.=20 |> Another question coming to my mind is whether there should be=20 |> a differentiation between network congestion and=20 |> application/signaling processor congestion. Something similar |> to ECN might be useful to protect signaling processors from=20 |> being overloaded. | |this is the other issue considered in the draft. from a framework |perspective, i think the key question is whether the NTLP provides |an environment in which NSLPs can signal and detect overload = implicitly |(which in practice means the NTLP providing something like a=20 |flow-controlled delivery service between NSLP peers), or whether the |NSLPs have to do this for themselves (in which case ideas like ECN |could well be useful, but are then part of the NSLP design debate). | |my personal view is that it is not possible to solve all the=20 |problems with a flow-controlled NTLP, therefore the second approach |is what we should be thinking in terms of. Yes, agreed. Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jun 26 09:53: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 JAA25044 for ; Thu, 26 Jun 2003 09:53:28 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QDr1d00642 for nsis-archive@odin.ietf.org; Thu, 26 Jun 2003 09:53:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VXBN-0000AG-C3; Thu, 26 Jun 2003 09:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VXAc-00007h-NX for nsis@optimus.ietf.org; Thu, 26 Jun 2003 09:52:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24926 for ; Thu, 26 Jun 2003 09:51:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VXAL-0001hq-00 for nsis@ietf.org; Thu, 26 Jun 2003 09:51:57 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19VXAB-0001hC-00 for nsis@ietf.org; Thu, 26 Jun 2003 09:51:47 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jun 2003 14:50:58 +0100 Message-ID: From: "Hancock, Robert" To: "'Geib, Ruediger'" Cc: nsis@ietf.org Subject: RE: [NSIS] framework: proposal on congestion/flow control Date: Thu, 26 Jun 2003 14:50:56 +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 rudiger, > Hello Robert > > |> The refresh timer values should be large enough to leave space > |> for the NTLP congestion control to add value. Otherwise NSLP > |> controls congestion. > | > |i don't really see what you mean by this. what about NSLP messages > |which are not refreshes, for example? > > What I want to say is that congestion control on different levels > should be designed in a way that both aren't active in the same > timescale. Usually the upper layer congestion control is slower than > the lower layer congestion control. My assumption is that the > refresh mechanism is designed to cope with congestion too in order > not to eliminate state caused by lost messages. well, for this and many other reasons, but anyway... > There's no point in > retransmitting NTLP messages if there's a high probability that due > to a timeout state was removed in the receiving NSLP already. > If NSLP was having its own ACK mechanism and starts to retransmit > if it doesn't receive an ACK in time, this could add congestion > should NTLP still try to retransmit the original NSLP message in > the same time. quite right. this is one example of a general problem of how to cope when there are natural mechanisms to use in 2 layers, and they end up duplicating rather than complementing each other. but in this case, i think it's more a question of multiple reliability mechanisms (explicitly at the NTLP, via refresh at the NSLP) rather than multiple congestion control mechanisms. cheers, r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jun 26 14:31: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 OAA13573 for ; Thu, 26 Jun 2003 14:31:01 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PFjfW23372 for nsis-archive@odin.ietf.org; Wed, 25 Jun 2003 11:45:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VCSr-00064s-LV; Wed, 25 Jun 2003 11:45:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VBzv-0007wP-9q for nsis@optimus.ietf.org; Wed, 25 Jun 2003 11:16:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01529 for ; Tue, 24 Jun 2003 21:32:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uxpf-0000R3-00 for nsis@ietf.org; Tue, 24 Jun 2003 20:08:15 -0400 Received: from rsys001a.roke.co.uk ([193.118.192.110]) by ietf-mx with esmtp (Exim 4.12) id 19UxpV-0000Q1-00 for nsis@ietf.org; Tue, 24 Jun 2003 20:08:05 -0400 Received: by rsys001a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 23:09:27 +0100 Message-ID: From: "Hancock, Robert" To: Bob Braden , michael.welzl@uibk.ac.at, john.loughney@nokia.com Cc: nsis@ietf.org Subject: RE: AW: [NSIS] framework: proposal on congestion/flow control Date: Tue, 24 Jun 2003 23: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: , dear all, there are at least 4 possible meanings of the word 'end' in the context of NSIS discussions (maybe the WG chair could decide an appropriate penalty for using the word without qualification): a) the data flow endpoints b) the 'furthest apart' signalling application nodes on the path c) any signalling application node on the path d) any NSIS node on the path [everything else is router, still. i wouldn't like to get in an argument about whether a node sending an NSIS message is a host or a router, but maybe that's a discussion that's needed at some point.] the point roughly made in the mini-draft that accompanies this thread is that congestion-generating load can originate with any of (a), (b) or (c), but not [as a consequence of the 'NTLP doesn't manage signalling application state' decision] with (d), unless the NTLP has retransmissions, in which case endpoints (d) can also be guilty. therefore, doing 'end-to-end' (presumably meaning a/b-level) congestion control in NSIS signalling protocols will not be a congestion control solution - in fact, the most likely congestion causes are the 'ends in the middle' (c) because of local repair actions, IMHO. what *is* (i think) the case is that the long-term response to congestion has to be to force the congestion up the protocol stack and/or out to the network edge - in the end, it ends up with a user. this leaves open the question of whose responsibility it is to do congestion control between 'interior' nodes *) the NTLP for its retransmissions, NSLP for everything else *) NTLP only cheers, r. > -----Original Message----- > From: Bob Braden [mailto:braden@ISI.EDU] > Sent: Tuesday, June 24, 2003 17:56 > To: braden@ISI.EDU; michael.welzl@uibk.ac.at; john.loughney@nokia.com > Cc: nsis@ietf.org > Subject: RE: AW: [NSIS] framework: proposal on congestion/flow control > > > > *> > *> Quick question for you: > *> > *> > I believe that you are confusing congestion control > with flow control. > *> > The "source-quench-like" or windowing mechanisms you > describe are > *> > hop/hop flow control. Congestion control has to do > with the interaction > *> > of the signaling traffic with other Internet traffic. We don't > *> > want signaling traffic to starve out other traffic, > either TCP traffic > *> > or realtime traffic. Internet transport is supposed to be > *> > "TCP-friendly". > *> > *> Michael seems to be talking about flow-control on a hop-by-hop > *> basis. I've always considered congestion control as a end-to-end > *> mechanism. What are your thoughts about having > congestion control on > *> a hop-by-hop basis - to me this sounds sub-optimal. > *> > *> John > *> > > John, > > Perhaps I was sloppy... I meant hop/hop in the sense of NSIS hops. > For NSIS traffic between NSIS neighbors, there is not distinction > between that and E2E; the neighbors ARE the ends. > > Does this help? > > 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 exim@www1.ietf.org Thu Jun 26 16:23: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 QAA19992 for ; Thu, 26 Jun 2003 16:23:09 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QKMgC12315 for nsis-archive@odin.ietf.org; Thu, 26 Jun 2003 16:22:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VdFp-0002pc-VJ; Thu, 26 Jun 2003 16:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VdFb-0002ot-Pf for nsis@optimus.ietf.org; Thu, 26 Jun 2003 16:21:47 -0400 Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19866 for ; Thu, 26 Jun 2003 16:21:44 -0400 (EDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5QKJvt25434; Thu, 26 Jun 2003 15:19:57 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h5QKJtY20498; Thu, 26 Jun 2003 15:19:55 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HH3V55-0001N8-00; Thu, 26 Jun 2003 16:19:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16123.21862.945025.92159@gargle.gargle.HOWL> Date: Thu, 26 Jun 2003 15:19:50 -0500 From: Pete McCann To: nsis@ietf.org, aaa-wg@merit.edu Subject: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt In-Reply-To: <200306251452.KAA12886@ietf.org> References: <200306251452.KAA12886@ietf.org> X-Mailer: VM 7.14 under 21.5 (beta13) "cauliflower" XEmacs Lucid 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, We hope everyone who is interested in QoS/AAA has a chance to read the draft we have just submitted. Our work is definitely related to the 2 drafts-tschofenig that have been posted on the NSIS group (apologies for not acknowledging this explicitly in the draft, but we found them only recently and are still reading them). However, our work focuses more on the requirements for a AAA protocol rather than requirements for NSIS. Also, we are trying to set forth in our draft what we think is the proper relationship between NSIS/RSVP, AAA, and call control protocols like SIP. Please read/comment! -Pete Internet-Drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Requirements for a QoS AAA Protocol > Author(s) : F. Alfano et al. > Filename : draft-alfano-aaa-qosreq-00.txt > Pages : 16 > Date : 2003-6-24 > > This document describes requirements for a protocol that would > perform Authentication, Authorization, and Accounting for Quality-of- > Service reservations. This protocol would be used by elements along > the path of a given application flow to authenticate a reservation > request, ensure that the reservation is authorized, and to account > for resources used during the life of the application flow. A QoS > AAA protocol should also support dynamic authorization of QoS as a > function of application and account state. While we assume the > existence of some QoS reservation protocol to allow endpoints to > request QoS from network elements, complete requirements for such a > protocol are outside the scope of this document and a QoS AAA > protocol could be used to support more than one kind of reservation > protocol. A QoS AAA protocol could be used between any bearer-level > network element that lies along the path of an application flow and > an application server that lies anywhere in the network, allowing for > a wide variety of flexible service deployment models. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosreq-00.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Thu Jun 26 21:41: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 VAA00448 for ; Thu, 26 Jun 2003 21:41:08 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5R1efa11414 for nsis-archive@odin.ietf.org; Thu, 26 Jun 2003 21:40:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ViDZ-0002vQ-9I; Thu, 26 Jun 2003 21:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ViCa-0002tu-7S for nsis@optimus.ietf.org; Thu, 26 Jun 2003 21:39:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00405 for ; Thu, 26 Jun 2003 21:38:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ViCX-00006R-00 for nsis@ietf.org; Thu, 26 Jun 2003 21:38:57 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19ViCM-00005s-00 for nsis@ietf.org; Thu, 26 Jun 2003 21:38:47 -0400 Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 4.14) id 19ViBr-000ILd-AV; Fri, 27 Jun 2003 01:38:15 +0000 To: Hemant.Chaskar@nokia.com cc: john.loughney@nokia.com, nsis@ietf.org Date: Thu, 26 Jun 2003 18:38:15 -0700 From: Allison Mankin Message-Id: Subject: [NSIS] IESG Review of draft-ietf-nsis-qos-requirements-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: , The IESG approved draft-ietf-nsis-qos-requirements-01.txt today. It was regarded as rather optimistic about what may be possible, but the requirements were convincing. The Security Considerations section had been missing and its having one now was appreciated. This work started in the mobileip wg, and transferred into nsis. Kudoes to Hemant as editor, and to folks in both working groups. Allison _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jun 27 00:35: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 AAA04770 for ; Fri, 27 Jun 2003 00:35:07 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5R4Yf416181 for nsis-archive@odin.ietf.org; Fri, 27 Jun 2003 00:34:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vkvw-00040q-J0; Fri, 27 Jun 2003 00:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vku3-0003s5-4z for nsis@optimus.ietf.org; Fri, 27 Jun 2003 00:33:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04691 for ; Fri, 27 Jun 2003 00:31:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vku0-000178-00 for nsis@ietf.org; Fri, 27 Jun 2003 00:32:00 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19Vktp-000170-00 for nsis@ietf.org; Fri, 27 Jun 2003 00:31:50 -0400 Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 4.14) id 19Vktk-000Obw-9I; Fri, 27 Jun 2003 04:31:44 +0000 To: brunner@ccrle.nec.de Cc: john.loughney@nokia.com, nsis@ietf.org, harald@alvestrand.no Reply-To: mankin@psg.com Date: Thu, 26 Jun 2003 21:31:44 -0700 From: Allison Mankin Message-Id: Subject: [NSIS] IESG Review of draft-ietf-nsis-req-08.txt - Comments 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: , The IESG reviewed the NSIS Requirements. There was some concern over the readability. In addition, there were a few technical comments that should be addressed. Here are Harald Alvestrand's. Allison ------- Forwarded Message Date: Thu, 26 Jun 2003 08:35:22 -0700 From: Harald Tveit Alvestrand To: iesg@ietf.org Subject: A couple of comments on draft-ietf-nsis-req This section, from the start of section 5, worries me: The parts of the networks we differentiate are the host-to-first router, the access network, and the core network. The host to first router part includes all the layer 2 technologies to access to the Internet. This part of the division is especially informal and may incorporate several access segments. In many cases, there is an application and/or user running on the host initiating signaling. The access network can be characterized by low capacity links, medium speed IP processing capabilities, and it might consist of a complete layer 2 network as well. The core network characteristics include high-speed forwarding capacities and inter-domain issues. These divisions between network types are not strict and do not appear in all networks, but where they do exist they may influence signaling requirements and will be highlighted as necessary. First of all, the grammar is sufficiently convoluted that I have problems parsing it. Second, I have definitional problems. I have problems imagining how an access network can work if it does NOT contain a "complete layer 2 network" - after all, a link is, in its way, a layer 2 network. OTOH, I don't think GSM/GPRS can fairly be called a "layer 2 network" - it's more complex than that - but it's definitely being used as an access network. The sentence "host to first router part includes all the layer 2 technologies to access to the Internet" does not parse, and makes the definition only make sense when the first router is connected to the Internet - I don't think that was intended. Since this paragraph is key to the overall architectural constraints, I think it's rather important to make it crystal clear. Section 5.5.1 on scalability worries me a lot, because it uses "scalable" without referring to a scale; while it may be appropriate to "scale" an end-system-to-first-router protocol to 10.000 users and say "good enough", I think core routers have scalability requirements to millions of active participants (which argues for them not having to see their state....) I would like to see some hand-wringing here like: "The NSIS protocols MUST be scalable up to the level of ubiquity - that is, if every end-user on the network uses NSIS functions, the system MUST NOT be brought to a catastrophic failure, but continue to give service appropriate to the resources available." There might be more than this, but this is at least worrying..... ------- End of Forwarded Message _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Fri Jun 27 00:44: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 AAA05034 for ; Fri, 27 Jun 2003 00:44:07 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5R4hfF20903 for nsis-archive@odin.ietf.org; Fri, 27 Jun 2003 00:43:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vl4f-0005FT-4e; Fri, 27 Jun 2003 00:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vl3x-0005Eo-6J for nsis@optimus.ietf.org; Fri, 27 Jun 2003 00:42:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04933 for ; Fri, 27 Jun 2003 00:42:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vl3u-0001Ay-00 for nsis@ietf.org; Fri, 27 Jun 2003 00:42:14 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19Vl3j-0001Av-00 for nsis@ietf.org; Fri, 27 Jun 2003 00:42:03 -0400 Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 4.14) id 19Vl3d-000Oy2-VM; Fri, 27 Jun 2003 04:41:57 +0000 To: brunner@ccrle.nec.de cc: john.loughney@nokia.com, nsis@ietf.org, smb@research.att.com Date: Thu, 26 Jun 2003 21:41:57 -0700 From: Allison Mankin Message-Id: Subject: [NSIS] More IESG Review of draft-ietf-nsis-req-08.txt - Comments 2 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: , Steve Bellovin also had comments on the NSIS Requirements draft: Section 3 effectively rules out any requirement for security within a domain. I don't think that's right. In 5.7.8, confidentiality SHOULD be supported. The ability to listen to signaling channels is a major guide to what data channels are interesting. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Jun 28 02:36: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 CAA16624 for ; Sat, 28 Jun 2003 02:36:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5S6Z4q02797 for nsis-archive@odin.ietf.org; Sat, 28 Jun 2003 02:35:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W9Ic-0000is-US; Sat, 28 Jun 2003 02:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W9Hr-0000iE-G6 for nsis@optimus.ietf.org; Sat, 28 Jun 2003 02:34:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16544 for ; Sat, 28 Jun 2003 02:34:13 -0400 (EDT) From: john.loughney@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19W9Hn-0001eu-00 for nsis@ietf.org; Sat, 28 Jun 2003 02:34:12 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19W9Hc-0001eY-00 for nsis@ietf.org; Sat, 28 Jun 2003 02:34:01 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h5S6X8917277 for ; Sat, 28 Jun 2003 09:33:08 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sat, 28 Jun 2003 09:33:09 +0300 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 28 Jun 2003 09:33:07 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sat, 28 Jun 2003 09:33:06 +0300 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" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt Date: Sat, 28 Jun 2003 09:33:06 +0300 Message-ID: Thread-Topic: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt Thread-Index: AcM8IKDXdfTnPACfRI2stmw1UCY3pABHhauA To: , , X-OriginalArrivalTime: 28 Jun 2003 06:33:06.0831 (UTC) FILETIME=[228B89F0:01C33D3F] Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi Pete, Question for you - NSIS will obviously need some AAA interaction, not just for QoS, but for middle box traversal (note, new NSIS charter has been announced). It might be interesting to discuss this work in both AAA & NSIS, but my feeling is that the AAA WG already has a lot to do. Perhaps you could work with Hannes to incorporate aspects of the drafts together. =20 thanks, John > -----Original Message----- > From: ext Pete McCann [mailto:mccap@lucent.com] > Sent: 26 June, 2003 23:20 > To: nsis@ietf.org; aaa-wg@merit.edu > Subject: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt >=20 >=20 >=20 > Hi, >=20 > We hope everyone who is interested in QoS/AAA has a chance to read the > draft we have just submitted. >=20 > Our work is definitely related to the 2 drafts-tschofenig that have > been posted on the NSIS group (apologies for not acknowledging this > explicitly in the draft, but we found them only recently and are still > reading them). However, our work focuses more on the requirements for > a AAA protocol rather than requirements for NSIS. Also, we are trying > to set forth in our draft what we think is the proper relationship > between NSIS/RSVP, AAA, and call control protocols like SIP. >=20 > Please read/comment! >=20 > -Pete >=20 > Internet-Drafts@ietf.org writes: > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > >=20 > >=20 > > Title : Requirements for a QoS AAA Protocol > > Author(s) : F. Alfano et al. > > Filename : draft-alfano-aaa-qosreq-00.txt > > Pages : 16 > > Date : 2003-6-24 > > =09 > > This document describes requirements for a protocol that would=20 > > perform Authentication, Authorization, and Accounting for=20 > Quality-of- > > Service reservations. This protocol would be used by=20 > elements along=20 > > the path of a given application flow to authenticate a reservation=20 > > request, ensure that the reservation is authorized, and to account=20 > > for resources used during the life of the application flow. A QoS=20 > > AAA protocol should also support dynamic authorization of QoS as a=20 > > function of application and account state. While we assume the=20 > > existence of some QoS reservation protocol to allow endpoints to=20 > > request QoS from network elements, complete requirements=20 > for such a=20 > > protocol are outside the scope of this document and a QoS AAA=20 > > protocol could be used to support more than one kind of=20 > reservation=20 > > protocol. A QoS AAA protocol could be used between any=20 > bearer-level=20 > > network element that lies along the path of an application=20 > flow and=20 > > an application server that lies anywhere in the network,=20 > allowing for=20 > > a wide variety of flexible service deployment models. > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosreq-00.txt >=20 >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Jun 28 04:48: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 EAA19089 for ; Sat, 28 Jun 2003 04:48:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5S8m3O07179 for nsis-archive@odin.ietf.org; Sat, 28 Jun 2003 04:48:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WBNI-0001rg-NO; Sat, 28 Jun 2003 04:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WBN2-0001rR-1j for nsis@optimus.ietf.org; Sat, 28 Jun 2003 04:47:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19048 for ; Sat, 28 Jun 2003 04:47:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WBMk-0002Hc-00 for nsis@ietf.org; Sat, 28 Jun 2003 04:47:26 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 19WBMZ-0002HY-00 for nsis@ietf.org; Sat, 28 Jun 2003 04:47:15 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id h5S8kte21801; Sat, 28 Jun 2003 10:46:55 +0200 (MEST) Received: from joe (lnxekv1-19.esn.sbs.de [149.246.36.19]) by mail3.siemens.de (8.11.7/8.11.7) with ESMTP id h5S8ksc20285; Sat, 28 Jun 2003 10:46:54 +0200 (MEST) From: "Hannes Tschofenig" To: , , , Subject: RE: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt Date: Sat, 28 Jun 2003 10:44:05 +0200 Message-ID: <000401c33d51$7434ab80$010aa8c0@joe> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable 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: quoted-printable hi john,=20 hi pete,=20 i have also seen your draft on the ietf announcement list and i will = read it as soon as possible. we tried to address various aspects of qos and authorization (and also authorization for nat/firewall signaling) in the past. we noticed the need for interworking between nsis and aaa (and possibly other protocols). however, the working group needs to make some decisions (see "QoS NSLP Authorization Issues" draft) before going into = a more solution oriented discussion.=20 btw, i am only editor of the drafts. a number of nsis wg members have contributed to the documents (see co-authors list). =20 you might also want to take a look at a slide presentation given at the = new york interim meeting: http://www.tschofenig.priv.at/nsis/NSIS_AAA.ppt ciao hannes > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Sent: Samstag, 28. Juni 2003 08:33 > To: mccap@lucent.com; nsis@ietf.org; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: [NSIS] I-D=20 > ACTION:draft-alfano-aaa-qosreq-00.txt >=20 >=20 > Hi Pete, >=20 > Question for you - NSIS will obviously need some AAA=20 > interaction, not just for QoS, but for middle box traversal=20 > (note, new NSIS charter has been announced). >=20 > It might be interesting to discuss this work in both AAA &=20 > NSIS, but my feeling is that the AAA WG already has a lot to=20 > do. Perhaps you could work with Hannes to incorporate=20 > aspects of the drafts together. =20 >=20 > thanks, > John >=20 > > -----Original Message----- > > From: ext Pete McCann [mailto:mccap@lucent.com] > > Sent: 26 June, 2003 23:20 > > To: nsis@ietf.org; aaa-wg@merit.edu > > Subject: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt > >=20 > >=20 > >=20 > > Hi, > >=20 > > We hope everyone who is interested in QoS/AAA has a chance=20 > to read the=20 > > draft we have just submitted. > >=20 > > Our work is definitely related to the 2 drafts-tschofenig that have=20 > > been posted on the NSIS group (apologies for not acknowledging this=20 > > explicitly in the draft, but we found them only recently=20 > and are still=20 > > reading them). However, our work focuses more on the=20 > requirements for=20 > > a AAA protocol rather than requirements for NSIS. Also, we=20 > are trying=20 > > to set forth in our draft what we think is the proper relationship=20 > > between NSIS/RSVP, AAA, and call control protocols like SIP. > >=20 > > Please read/comment! > >=20 > > -Pete > >=20 > > Internet-Drafts@ietf.org writes: > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > >=20 > > >=20 > > > Title : Requirements for a QoS AAA Protocol > > > Author(s) : F. Alfano et al. > > > Filename : draft-alfano-aaa-qosreq-00.txt > > > Pages : 16 > > > Date : 2003-6-24 > > > =09 > > > This document describes requirements for a protocol that would=20 > > > perform Authentication, Authorization, and Accounting for=20 > > Quality-of- > > > Service reservations. This protocol would be used by=20 > > elements along=20 > > > the path of a given application flow to authenticate a=20 > reservation=20 > > > request, ensure that the reservation is authorized, and=20 > to account=20 > > > for resources used during the life of the application=20 > flow. A QoS=20 > > > AAA protocol should also support dynamic authorization=20 > of QoS as a=20 > > > function of application and account state. While we assume the=20 > > > existence of some QoS reservation protocol to allow endpoints to=20 > > > request QoS from network elements, complete requirements=20 > > for such a=20 > > > protocol are outside the scope of this document and a QoS AAA=20 > > > protocol could be used to support more than one kind of=20 > > reservation=20 > > > protocol. A QoS AAA protocol could be used between any=20 > > bearer-level=20 > > > network element that lies along the path of an application=20 > > flow and=20 > > > an application server that lies anywhere in the network,=20 > > allowing for=20 > > > a wide variety of flexible service deployment models. > > >=20 > > > A URL for this Internet-Draft is: > > >=20 > http://www.ietf.org/internet-drafts/draft-> alfano-aaa-qosreq-00.txt > >=20 > >=20 > >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sat Jun 28 17:46: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 RAA03578 for ; Sat, 28 Jun 2003 17:46:13 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5SLjk016020 for nsis-archive@odin.ietf.org; Sat, 28 Jun 2003 17:45:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WNVE-00043w-Vr; Sat, 28 Jun 2003 17:45:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WNUT-00043Y-Uo for nsis@optimus.ietf.org; Sat, 28 Jun 2003 17:44:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03549 for ; Sat, 28 Jun 2003 17:43:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WNUC-0005ja-00 for nsis@ietf.org; Sat, 28 Jun 2003 17:43:56 -0400 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 19WNU1-0005jU-00 for nsis@ietf.org; Sat, 28 Jun 2003 17:43:45 -0400 Received: from cs.uni-goettingen.de (IBZGate.ibz.gwdg.de [::ffff:134.76.38.21]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Sat, 28 Jun 2003 23:43:12 +0200 Message-ID: <3EFE0BED.2050004@cs.uni-goettingen.de> Date: Sat, 28 Jun 2003 23:43:09 +0200 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: nsis@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] Proposed draft "Mobility Support in NSIS" 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 all, Here is a new Internet Draft that we propose as a problem statement and proposed mechanisms to extend NSIS for mobility support: http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-00.txt or http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-00.pdf Following previous work (Michael Thomas, Cedric Westphal/Hemant Chaskar, Charles Shen, and many others), this Draft aims to provide an extensive view on mobility support related issues that will be of broad general use. We welcome your comments. We are also especially interested in other open issues and studying how they may be addressed by future versions of the Draft. Regards, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Jun 29 04:00: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 EAA24296 for ; Sun, 29 Jun 2003 04:00:17 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5T7xlM26046 for nsis-archive@odin.ietf.org; Sun, 29 Jun 2003 03:59:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WX5R-0006iz-6l; Sun, 29 Jun 2003 03:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WX4x-0006hi-LL for nsis@optimus.ietf.org; Sun, 29 Jun 2003 03:58:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24269 for ; Sun, 29 Jun 2003 03:58:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WX4q-0007mk-00 for nsis@ietf.org; Sun, 29 Jun 2003 03:58:24 -0400 Received: from user.informatik.uni-goettingen.de ([134.76.81.16] helo=s2.ifi.informatik.uni-goettingen.de) by ietf-mx with esmtp (Exim 4.12) id 19WX4f-0007mW-00 for nsis@ietf.org; Sun, 29 Jun 2003 03:58:13 -0400 Received: from cs.uni-goettingen.de (IBZGate.ibz.gwdg.de [::ffff:134.76.38.21]) (AUTH: PLAIN fu, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by s2.ifi.informatik.uni-goettingen.de with esmtp; Sun, 29 Jun 2003 09:57:55 +0200 Message-ID: <3EFE9C03.20409@cs.uni-goettingen.de> Date: Sun, 29 Jun 2003 09:57:55 +0200 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: nsis@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [NSIS] yet a possible NSLP 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 all, The following draft presents a potential NSLP, traceroute, which is based on stateless NTLP, namely using "record-route" in the messages, rather than storing routing/messaging info into local states: http://www.ietf.org/internet-drafts/draft-fu-ccamp-traceroute-00.txt, .pdf We tentatively apply CASP as underlying NTLP -- expecting to update it with NSIS WG NTLP, as well as change of the placement of the discovery component -- still, we find some issues would be of interest for NSIS, such as whether a stateless mode for NTLP is needed at all in general, tunnels/middlebox & non-NSIS cloud implications to NTLP for similar NSLPs, and so forth. Any comments and suggestions will be very appreciated. Regards, Xiaoming _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Sun Jun 29 23:01: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 XAA15546 for ; Sun, 29 Jun 2003 23:01:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5U314F08654 for nsis-archive@odin.ietf.org; Sun, 29 Jun 2003 23:01:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Woub-0002F5-8p; Sun, 29 Jun 2003 23:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wotu-0002EI-6X for nsis@optimus.ietf.org; Sun, 29 Jun 2003 23:00:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15502 for ; Sun, 29 Jun 2003 23:00:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Wotq-0002ss-00 for nsis@ietf.org; Sun, 29 Jun 2003 23:00:14 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19Wota-0002rs-00 for nsis@ietf.org; Sun, 29 Jun 2003 22:59:58 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h5U2x9kM007541; Sun, 29 Jun 2003 22:59:09 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h5U2x6N11194; Sun, 29 Jun 2003 22:59:07 -0400 Message-ID: <3EFFA68E.4080902@cs.columbia.edu> Date: Sun, 29 Jun 2003 22:55:10 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Geib, Ruediger" CC: nsis@ietf.org Subject: Re: [NSIS] clarifications on schulzrinne-nsis-ntlp References: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB4FE@G8PQD.blf01.telekom.de> In-Reply-To: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB4FE@G8PQD.blf01.telekom.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cs.columbia.edu id h5U2x9kM007541 Content-Transfer-Encoding: quoted-printable 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: quoted-printable Geib, Ruediger wrote: > I don't understand how GIMPS works if a re-route occurs between > querying node and an already discovered next-hop peer. If you've > provided text I'd appreciate if you explain things more explicit. This clearly needs more elaboration. There are three choices, similar to=20 RSVP: (1) explicit "trigger" if a node finds out that the next hop has=20 changed; this is the RSVP mechanism where some form of notification=20 mechanism from the routing table to the protocol handler is assumed.=20 Clearly, in RSVP and GIMPS, this only works if the routing change is=20 local to the NTLP node, not if the routing change happens somewhere a=20 few hops away. (2) An extended trigger, where the node checks the link-state routing=20 table to discover that the path has changed. This makes certain=20 assumptions on consistency of route computation (but you need to=20 probably make those to avoid routing loops) and only works intra-domain=20 and for OSPF and similar link-state protocols. This would be the best=20 solution, I think, but requires more access to the routing boiler room=20 than typical OS may provide. (3) Probe: periodically, re-do the discovery operation. Again, similar=20 to RSVP, except that there's an extra degree of freedom since not every=20 message needs to redo the discovery, depending on the likely stability=20 of routes. All indications are that leaving mobility aside that routes=20 are stable for hours and days, so this may not be necessary on a=20 30-second interval. (Mobility is not an issue since the message will=20 visit "virgin" territory, rather than nodes with existing sessions.) >=20 > The state table seems to include information on the previous hop and > on "the existing transport and security assosiaction to the next-hop > peer". That's mentioned several times in the text. It may be added in > the paragraph "each node maintains a forwarding state table that > includes...". It's clear to me that several individual state table > entries may refer to the same previous/next peer entries. Indeed; added. >=20 > Two editorials: >=20 > Section 2 mentions a "GTSP". Section 6 doesn't contain a "message > SDU" (or message content), which should at least be optional. Old name; yes, clearly. >=20 > I don't intend to start a detailed discussion. I'm rather asking for > a couple of clarifications by the author. Thanks for the comments. >=20 > Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jun 30 06:37: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 GAA08564 for ; Mon, 30 Jun 2003 06:37:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UAb2X26258 for nsis-archive@odin.ietf.org; Mon, 30 Jun 2003 06:37:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ww1t-0006oN-1x; Mon, 30 Jun 2003 06:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ww1W-0006lU-Hb for nsis@optimus.ietf.org; Mon, 30 Jun 2003 06:36:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08537 for ; Mon, 30 Jun 2003 06:36:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ww1S-0005WE-00 for nsis@ietf.org; Mon, 30 Jun 2003 06:36:34 -0400 Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx with esmtp (Exim 4.12) id 19Ww1H-0005Vo-00 for nsis@ietf.org; Mon, 30 Jun 2003 06:36:23 -0400 Received: from g8pbr.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Mon, 30 Jun 2003 12:34:21 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jun 2003 12:33:53 +0200 Message-Id: <9F8582E37B2EE5498E76392AEDDCD3FE03DBB507@G8PQD.blf01.telekom.de> From: "Geib, Ruediger" To: mshore@cisco.com Cc: nsis@ietf.org Subject: [NSIS] clarifications on shore-ntlp Date: Mon, 30 Jun 2003 12:33:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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: quoted-printable Melinda, I've read your draft and would like to provide a brief feedback: I like the introduction of TLVs in an early stage. The "epoch" and = protection of internal state mechanisms sound useful too. Could you explicitely identify which state-information is maintained by = NTLP? I wasn't able to understand that from your document. =A75.5.1 mentions that "Messages containing the MESSAGE_ID_LIST TLV are = normally sent end-to-end in a forward direction with a destination IP = address equal to the address of the original reservation, or trigger, = request." I thought MESSAGE_IDs were only valid between adjacent NTLP = nodes. Could you clarify? =A75.3, last section, specifies that Nodes receiving a message ... = containing a MESSAGE_ID TLV with the ACK_Desired flag set should = respond with a MESSAGE_ID_ACK TLV. If response to "ACK_Desired" is = optional, how does the sender react if his request is never ACKed = because the receiver doesn't support this option? Further, your draft doesn't seem to define whether or how an originator = of a summary refresh reacts if it doesn't receive ACK/NACK messages = (e.g. due to losses). =A7 5.3 mentions that a "The ACK_Desired flag will typically be set = only in trigger messages". The text doesn't define "trigger messages". =A7 5.5.1 says, "The destination IP address may be set to the NTLP next = hop when the next hop is known to be NTLP-capable." That's the case for = upstream communication only, isn't it? I don't intend to start a detailed discussion. I'm rather asking for a = couple of clarifications by the author.=20 Regards, R=FCdiger _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jun 30 09:21: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 JAA21670 for ; Mon, 30 Jun 2003 09:21:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UDL4926720 for nsis-archive@odin.ietf.org; Mon, 30 Jun 2003 09:21:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wyab-0006wS-JH; Mon, 30 Jun 2003 09:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WyaW-0006wH-S9 for nsis@optimus.ietf.org; Mon, 30 Jun 2003 09:20:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21615 for ; Mon, 30 Jun 2003 09:20:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WyaU-0000I3-00 for nsis@ietf.org; Mon, 30 Jun 2003 09:20:54 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19WyaJ-0000Gc-00 for nsis@ietf.org; Mon, 30 Jun 2003 09:20:43 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jun 2003 14:19:40 +0100 Message-ID: From: "Hancock, Robert" To: nsis@ietf.org Date: Mon, 30 Jun 2003 14:19:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [NSIS] w.g. framework document update 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 have made an update of the framework draft. the main changes are to reflect recent progress (since san francisco) on some of the open issues, mainly allocation of state management and fragmentation responsibility between the layers, as well as some general tidying. don't get frustrated waiting for it to appear in the repositories! get your own copy now at http://sigcomp.srmr.co.uk/~reh/draft-ietf-nsis-fw-03.txt happy reading, robert h. & all the authors _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jun 30 11:54: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 LAA02417 for ; Mon, 30 Jun 2003 11:54:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UFs2N26410 for nsis-archive@odin.ietf.org; Mon, 30 Jun 2003 11:54:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X0yf-0006rZ-Fs; Mon, 30 Jun 2003 11:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X0yJ-0006ql-4V for nsis@optimus.ietf.org; Mon, 30 Jun 2003 11:53:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02183 for ; Mon, 30 Jun 2003 11:53:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X0rm-00021Z-00 for nsis@ietf.org; Mon, 30 Jun 2003 11:46:54 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 19X0rX-00021U-00 for nsis@ietf.org; Mon, 30 Jun 2003 11:46:39 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h5UFkUH05717; Mon, 30 Jun 2003 17:46:30 +0200 (MEST) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id h5UFkT422585; Mon, 30 Jun 2003 17:46:30 +0200 (MEST) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jun 2003 17:46:29 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BBFF52@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'john.loughney@nokia.com'" , mccap@lucent.com, nsis@ietf.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt Date: Mon, 30 Jun 2003 17:46:26 +0200 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 pete, as promised i have read your draft and provided some comments inline. please take a look at: http://www.tschofenig.priv.at/comments/draft-alfano-aaa-qosreq-00-hannes.txt it is good that you join the discussion. ciao hannes > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Saturday, June 28, 2003 8:33 AM > To: mccap@lucent.com; nsis@ietf.org; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: [NSIS] I-D > ACTION:draft-alfano-aaa-qosreq-00.txt > > > Hi Pete, > > Question for you - NSIS will obviously need some AAA interaction, > not just for QoS, but for middle box traversal (note, new NSIS > charter has been announced). > > It might be interesting to discuss this work in both AAA & NSIS, > but my feeling is that the AAA WG already has a lot to do. Perhaps > you could work with Hannes to incorporate aspects of the drafts > together. > > thanks, > John > > > -----Original Message----- > > From: ext Pete McCann [mailto:mccap@lucent.com] > > Sent: 26 June, 2003 23:20 > > To: nsis@ietf.org; aaa-wg@merit.edu > > Subject: [AAA-WG]: [NSIS] I-D ACTION:draft-alfano-aaa-qosreq-00.txt > > > > > > > > Hi, > > > > We hope everyone who is interested in QoS/AAA has a chance > to read the > > draft we have just submitted. > > > > Our work is definitely related to the 2 drafts-tschofenig that have > > been posted on the NSIS group (apologies for not acknowledging this > > explicitly in the draft, but we found them only recently > and are still > > reading them). However, our work focuses more on the > requirements for > > a AAA protocol rather than requirements for NSIS. Also, we > are trying > > to set forth in our draft what we think is the proper relationship > > between NSIS/RSVP, AAA, and call control protocols like SIP. > > > > Please read/comment! > > > > -Pete > > > > Internet-Drafts@ietf.org writes: > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > > > > Title : Requirements for a QoS AAA Protocol > > > Author(s) : F. Alfano et al. > > > Filename : draft-alfano-aaa-qosreq-00.txt > > > Pages : 16 > > > Date : 2003-6-24 > > > > > > This document describes requirements for a protocol that would > > > perform Authentication, Authorization, and Accounting for > > Quality-of- > > > Service reservations. This protocol would be used by > > elements along > > > the path of a given application flow to authenticate a > reservation > > > request, ensure that the reservation is authorized, and > to account > > > for resources used during the life of the application > flow. A QoS > > > AAA protocol should also support dynamic authorization > of QoS as a > > > function of application and account state. While we assume the > > > existence of some QoS reservation protocol to allow endpoints to > > > request QoS from network elements, complete requirements > > for such a > > > protocol are outside the scope of this document and a QoS AAA > > > protocol could be used to support more than one kind of > > reservation > > > protocol. A QoS AAA protocol could be used between any > > bearer-level > > > network element that lies along the path of an application > > flow and > > > an application server that lies anywhere in the network, > > allowing for > > > a wide variety of flexible service deployment models. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosreq-00.txt > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From exim@www1.ietf.org Mon Jun 30 14:28: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 OAA09740 for ; Mon, 30 Jun 2003 14:28:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UIS2d31969 for nsis-archive@odin.ietf.org; Mon, 30 Jun 2003 14:28:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X3Nh-0008It-9k; Mon, 30 Jun 2003 14:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X3NC-0008HB-9f for nsis@optimus.ietf.org; Mon, 30 Jun 2003 14:27:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09671 for ; Mon, 30 Jun 2003 14:27:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X3N9-0003Kp-00 for nsis@ietf.org; Mon, 30 Jun 2003 14:27:27 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 19X3My-0003KW-00 for nsis@ietf.org; Mon, 30 Jun 2003 14:27:16 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5UIQN2K028262; Mon, 30 Jun 2003 11:26:23 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIZ55536; Mon, 30 Jun 2003 11:26:22 -0700 (PDT) Message-Id: <200306301826.AIZ55536@mira-sjc5-c.cisco.com> To: "Geib, Ruediger" cc: nsis@ietf.org From: Melinda Shore Subject: Re: [NSIS] clarifications on shore-ntlp In-Reply-To: Message from Ruediger.Geib@t-systems.com of "Mon, 30 Jun 2003 12:33:46 +0200." <9F8582E37B2EE5498E76392AEDDCD3FE03DBB507@G8PQD.blf01.telekom.de> Date: Mon, 30 Jun 2003 14:26:22 -0400 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: , 1) Right now the only state being maintained by the NTLP is for its own function, which would include timers, per-hop path state, ACK/NACK state, etc. 2) 2961 says that MESSAGE_IDs may only used between adjacent nodes. That there's a conflict in my document is an error on my part, but it isn't obvious to me which is the right answer. In 2961 MESSAGE_ID is used to support reliable messaging, which is hop-by-hop. We've talked a bit on the mailing list about identifiers with global scope and while there's some agreement that it's needed there really hasn't been sufficient discussion of namespace collision avoidance and there hasn't been discussion of how to avoid a proliferation of identifiers, the latter of which is a potential problem. 3) As I mention in the TO DO list the NACK and error processing need to be filled out. "Error" would include packet loss, and you're correct to point that out. 4) a trigger message is the first one to request a particular reservation/data flow. This is another topic that requires discussion by the working group since it touches on the problem of where to place the layer separation and how clean it should be (or how much awareness the layers should have of each other). 5) yes, that's correct, and the text needs to be clearer. Thanks, Melinda _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis