From list-admin Thu Jun 2 12:29:04 1994 Received: from ucdavis.ucdavis.edu (ucdavis.ucdavis.edu [128.120.250.250]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id MAA04645 for ; Thu, 2 Jun 1994 12:29:03 -0400 Received: from fennel.acc.com by ucdavis.ucdavis.edu (8.6.8/UCD2.50) id JAA08681; Thu, 2 Jun 1994 09:29:00 -0700 Received: from by fennel.acc.com (4.1/SMI-4.1) id AB17540; Thu, 2 Jun 94 09:28:58 PDT Message-Id: <9406021628.AB17540@fennel.acc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 2 Jun 1994 09:28:58 -0800 To: ietf-ppp@ucdavis.edu From: fbaker@acc.com (Fred Baker) Subject: Re: PPPEXT scheduling Folks, we have two slots scheduled on Thursday at the IETF. Anyone who wants time in one of those slots, please drop me a note. At 1:59 PM 6/1/94 -0400, Megan Davies Walnut wrote: >Hi Fred, > >I have scheduled two sessions of pppext as follows. > >Thu. July 28: 0930-1200 > 1330-1530 > >Megan ============================================================================= "In sound wisdom there are two sides" Zophar, Job 11:6 - - - - - - - - - - - - - - - - - From list-admin Tue Jun 7 10:46:42 1994 Received: from Shiva.COM (Shiva.COM [192.80.57.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA00748 for ; Tue, 7 Jun 1994 10:46:41 -0400 Received: by Shiva.COM (1.34b) Tue, 7 Jun 94 10:46:39 EDT Date: Tue, 7 Jun 94 10:46:39 EDT From: John Gregg Message-Id: <9406071446.AA06294@Shiva.COM> To: ietf-ppp@merit.edu Subject: suspend/resume; virtual connections A while ago I seem to remember someone posting a suggestion for new LCP packet types to enable virtual connections, i.e. the ability to make a connection suspend (and hang up the phone) in the absense of any real user data traffic, then resume when there was traffic to send. That way you could save phone carrier charges without actually bringing the PPP link down as far as the protocol engine was concerned. Is anybody working on this? Are there any drafts out? -John Gregg - - - - - - - - - - - - - - - - - From list-admin Tue Jun 7 13:51:41 1994 Received: from ftp.com (ftp.com [128.127.2.122]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA15930 for ; Tue, 7 Jun 1994 13:51:39 -0400 Received: by ftp.com ; Tue, 7 Jun 1994 13:51:34 -0400 Received: by ftp.com ; Tue, 7 Jun 1994 13:51:34 -0400 From: wilson@ftp.com (Brad Wilson) Message-Id: <9406071751.AA06109@ftp.com> Subject: Re: suspend/resume; virtual connections To: jgregg@shiva.com (John Gregg) Date: Tue, 7 Jun 1994 13:51:34 -0400 (EDT) Cc: ietf-ppp@merit.edu In-Reply-To: <9406071446.AA06294@Shiva.COM> from "John Gregg" at Jun 7, 94 10:46:39 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1003 >> A while ago I seem to remember someone posting a suggestion for >> new LCP packet types to enable virtual connections, i.e. the ability to >> make a connection suspend (and hang up the phone) in the absense of any >> real user data traffic, then resume when there was traffic to send. That >> way you could save phone carrier charges without actually bringing the PPP >> link down as far as the protocol engine was concerned. Is anybody working on >> this? Are there any drafts out? Why is this necessary? I thought PPP was an unreliable delivery service. What would be the advantage of such a system, besides (possibly) saving you from renegotiating again? Just curious... ;-) Brad -- Brad Wilson | Internet: wilson@ftp.com | #include FTP Software, Inc. | Voice: +1 800 282 4387 | #include 2 High Street | Facsimile: +1 508 659 6297 | #include N. Andover, MA 01845 | Support: support@ftp.com | msg++; smiley++; - - - - - - - - - - - - - - - - - From list-admin Tue Jun 7 13:44:22 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id NAA15284 for ; Tue, 7 Jun 1994 13:44:21 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id NAA10316; Tue, 7 Jun 1994 13:44:12 -0400 Date: Tue, 7 Jun 1994 13:44:12 -0400 From: Patrick Klos Message-Id: <199406071744.NAA10316@mv.mv.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections Cc: jgregg@shiva.com >From list-admin@merit.edu Tue Jun 7 12:32:48 1994 >Date: Tue, 7 Jun 94 10:46:39 EDT >From: John Gregg >To: ietf-ppp@merit.edu >Subject: suspend/resume; virtual connections > > > A while ago I seem to remember someone posting a suggestion for >new LCP packet types to enable virtual connections, i.e. the ability to >make a connection suspend (and hang up the phone) in the absense of any >real user data traffic, then resume when there was traffic to send. That >way you could save phone carrier charges without actually bringing the PPP >link down as far as the protocol engine was concerned. Is anybody working on >this? Are there any drafts out? > > > -John Gregg > > I endorsed this idea at the time, but it was shot down by others as unnecessary. I'm still not convinced it's unnecessary, and think it would be a useful enhancement. Any other folks who think along the same lines might want to speak up now, before we're urged not to try to bring it up for discussion again. (you guys at Gordian were interested in this, weren't you?) Patrick ============================================================================ Patrick Klos Internet: klos@mv.mv.com Klos Technologies, Inc. Voice: (603) 424-8300 604 Daniel Webster Highway FAX: (603) 424-9300 Merrimack, New Hampshire 03054 BBS: (603) 429-0032 ============================================================================ - - - - - - - - - - - - - - - - - From list-admin Tue Jun 7 13:43:04 1994 Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA15224 for ; Tue, 7 Jun 1994 13:43:04 -0400 Received: by ftp.com ; Tue, 7 Jun 1994 13:43:02 -0400 Received: by ftp.com ; Tue, 7 Jun 1994 13:43:02 -0400 From: wilson@ftp.com (Brad Wilson) Message-Id: <9406071743.AA05715@ftp.com> Subject: MD5 export restrictions? To: ietf-ppp@merit.edu (IETF PPP working group) Date: Tue, 7 Jun 1994 13:43:02 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 519 Does MD5 have any export restrictions? (I thought I remembered the answer this question being no). Does anybody have any official oducmentation one way or another on the issue? As always, thanks... Brad -- Brad Wilson | Internet: wilson@ftp.com | #include FTP Software, Inc. | Voice: +1 800 282 4387 | #include 2 High Street | Facsimile: +1 508 659 6297 | #include N. Andover, MA 01845 | Support: support@ftp.com | msg++; smiley++; - - - - - - - - - - - - - - - - - From list-admin Tue Jun 7 16:19:10 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id QAA29945 for ; Tue, 7 Jun 1994 16:19:09 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id QAA05106; Tue, 7 Jun 1994 16:19:02 -0400 Date: Tue, 7 Jun 1994 16:19:02 -0400 From: Patrick Klos Message-Id: <199406072019.QAA05106@mv.mv.com> To: jgregg@shiva.com, wilson@ftp.com Subject: Re: suspend/resume; virtual connections Cc: ietf-ppp@merit.edu >>> A while ago I seem to remember someone posting a suggestion for >>> new LCP packet types to enable virtual connections, i.e. the ability to >>> make a connection suspend (and hang up the phone) in the absense of any >>> real user data traffic, then resume when there was traffic to send. That >>> way you could save phone carrier charges without actually bringing the PPP >>> link down as far as the protocol engine was concerned. Is anybody working on >>> this? Are there any drafts out? > >Why is this necessary? I thought PPP was an unreliable delivery service. >What would be the advantage of such a system, besides (possibly) saving >you from renegotiating again? > This has nothing to do with reliability. These options are (correct me if I'm wrong) primarily to support "ON DEMAND" features of async PPP implementations. The options would provide a way to inform the "server" that a connection was being "suspended" due to lack of activity between the 2 peers. In some instances, suspending rather than terminating provides the "server" some additional information about the connection (i.e. I'll be calling back, so don't release any resources I'm using [like a dynamic IP address]). Actually, I think some people want to use this mechanism to better support ON DEMAND IPX (with all the magic spoofing that must go on). Would someone else like to explain how they think these options would be useful?? Patrick ============================================================================ Patrick Klos Internet: klos@mv.mv.com Klos Technologies, Inc. Voice: (603) 424-8300 604 Daniel Webster Highway FAX: (603) 424-9300 Merrimack, New Hampshire 03054 BBS: (603) 429-0032 ============================================================================ - - - - - - - - - - - - - - - - - From list-admin Tue Jun 7 16:58:10 1994 Received: from gordius.gordian.com (gordius.gordian.com [192.73.220.81]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id QAA03218 for ; Tue, 7 Jun 1994 16:58:06 -0400 Received: from hermes (hermes.gordian.com [192.73.220.111]) by gordius.gordian.com (8.6.5/8.6.5) with SMTP id NAA13554 for <@gordius.gordian.com:ietf-ppp@merit.edu>; Tue, 7 Jun 1994 13:57:28 -0700 Received: by hermes (920330.SGI/920502.SGI) for @gordius.gordian.com:ietf-ppp@merit.edu id AA17137; Tue, 7 Jun 94 13:57:03 -0700 Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.hermes.sgi.4d via MS.5.6.hermes.sgi_4d; Tue, 7 Jun 1994 13:57:03 -0700 (PDT) Message-Id: <0hxBwT30GRljIx6XEu@hermes> Date: Tue, 7 Jun 1994 13:57:03 -0700 (PDT) From: Jay Laefer To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections In-Reply-To: <199406071744.NAA10316@mv.mv.com> References: <199406071744.NAA10316@mv.mv.com> > I endorsed this idea at the time, but it was shot down by others as > unnecessary. I'm still not convinced it's unnecessary, and think it > would be a useful enhancement. Any other folks who think along the > same lines might want to speak up now, before we're urged not to try to > bring it up for discussion again. > (you guys at Gordian were interested in this, weren't you?) Actually, while the idea has some appeal, I believe (a) that it doesn't belong in PPP, and (b) it's mostly unnecessary. (a) because it potentially involves very protocol-specific issues like spoofing NBP (for AppleTalk) or workstation-server keepalives (for IPX). These issues are very unrelated to the link-layer. PPP is about the right size for my taste, and I'd hate to overload it too heavily (although I am in favor of expanding the authentication protocols). (b) because the time you spend negotiating for options would instead be spent validating who you were for a previous connection. I just don't feel that PPP, when properly configured, takes that long to come up. Also, better routing protocols tend to obviate the need for spoofing. Using static routes, IP can be made to route over an on-demand link, and in AppleTalk, AURP appears at first glance to provide a better alternative to RTMP. (I do confess to having only skimmed the AURP documents.) -Jay jay@gordian.com - - - - - - - - - - - - - - - - - From list-admin Tue Jun 7 17:26:55 1994 Received: from ucdavis.ucdavis.edu (ucdavis.edu [128.120.250.250]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id RAA05349 for ; Tue, 7 Jun 1994 17:26:54 -0400 Received: from relay2.UU.NET by ucdavis.ucdavis.edu (8.6.8/UCD2.50) id OAA29936; Tue, 7 Jun 1994 14:26:51 -0700 Received: from cixgate.3com.com by relay2.UU.NET with SMTP (rama) id QQwtht01685; Tue, 7 Jun 1994 17:26:44 -0400 Received: from gw.3Com.COM ([139.87.180.10]) by cixgate.3com.com (4.1/SMI-4.1/3com-cixgate-GCA-931027-01) id AA01875; Tue, 7 Jun 94 11:29:18 PDT Received: from notes.DEV.3Com.COM by gw.3Com.COM with SMTP id AA14970 (5.65c/IDA-1.4.4 for ); Tue, 7 Jun 1994 11:27:33 -0700 Received: by notes.dev.3com.com (IBM OS/2 SENDMAIL VERSION 1.3.0)/1.0) id AA0168; Tue, 07 Jun 94 11:36:49 -0700 Message-Id: <9406071836.AA0168@notes.dev.3com.com> Received: from 3Com with "Lotus Notes Mail Gateway for SMTP" id E143E15B07BBE6218825606600701EC9; Tue, 7 Jun 94 11:36:49 To: ietf-ppp From: Daniel Tai/HQ/3Com Date: 6 Jun 94 13:28:21 PS Subject: Add new E-mail address Mime-Version: 1.0 Content-Type: Text/Plain Please add daniel_tai@3mail.3com.com to the mail list, and delete my old E-mail address taid@centrum.com. Thanks, Daniel Tai - - - - - - - - - - - - - - - - - From list-admin Tue Jun 7 18:08:47 1994 Received: from ucdavis.ucdavis.edu (ucdavis.edu [128.120.250.250]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id SAA07969 for ; Tue, 7 Jun 1994 18:08:46 -0400 Received: from cs.utah.edu by ucdavis.ucdavis.edu (8.6.8/UCD2.50) id PAA06224; Tue, 7 Jun 1994 15:08:42 -0700 Received: from ee.utah.edu by cs.utah.edu (5.65/utah-2.21-cs) id AA08879; Tue, 7 Jun 94 16:08:39 -0600 Received: from [192.206.100.133] by ee.utah.edu with SMTP (1.37.109.4/15.6) id AA25110; Tue, 7 Jun 94 16:08:48 -0600 Date: Tue, 7 Jun 94 16:08:48 -0600 Message-Id: <9406072208.AA25110@ee.utah.edu> X-Sender: paulsen@ee.utah.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ppp@ucdavis.edu From: paulsen@ee.utah.edu (Keith Paulsen) Subject: Add new Email address X-Mailer: Please add ietf-ppp@dayna.com to this mailing list. Thank you! Keith - - - - - - - - - - - - - - - - - From list-admin Tue Jun 7 18:52:47 1994 Received: from digibd.com (digibd.digibd.com [192.83.159.205]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id SAA10454 for ; Tue, 7 Jun 1994 18:52:46 -0400 Received: by digibd.com (5.65/DBI-1.19) id AA21391; Tue, 7 Jun 94 17:51:14 -0500 From: tomc@digibd.com (Tom Coradetti) Message-Id: <9406072251.AA21391@digibd.com> Subject: PPP multilink initial sequence num To: ietf-ppp@merit.edu, sklower@vangogh.cs.berkeley.edu (Keith Sklower) Date: Tue, 7 Jun 1994 17:51:13 -0500 (CDT) X-Mailer: ELM [version 2.4 PL16] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1137 I believe that the PPP Multilink specification should require that the first sequence number used by the transmitter after opening the first link of a bundle should be 0. It does not seem to say this anywhere. If the first thing the receiver sees after the first link is opened is a train of fragments which comprise a complete packet with, say, sequence numbers 8,9, and 10, there is no currently specified reason why it would not pass the received packet to higher protocols. If the transmitter really started with 6, and now fragments 6 and 7 arrive and form a complete packet, the packet can not be passed upward without violating sequentiality. On the other hand, with a prior agreement as to the first sequence number to be expected at the receiver, the receiver has the right initial context. There is no need to negotiate the initial value, just specify a constant for the first link in a bundle. Zero is as good a constant as any. -- Tom Coradetti email: tomc@digibd.com DigiBoard, Inc. Phone: (612) 947-1118 6400 Flying Cloud Dr. FAX: (612) 947-1129 Eden Praire, MN 55344 - - - - - - - - - - - - - - - - - From list-admin Tue Jun 7 19:26:05 1994 Received: from netcomsv.netcom.com (uucp2-b.netcom.com [163.179.3.2]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id TAA11980 for ; Tue, 7 Jun 1994 19:26:05 -0400 Received: from localhost by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id QAA05622; Tue, 7 Jun 1994 16:22:08 -0700 Received: from localhost (vjs@localhost) by calcite.rhyolite.com (8.6.5/8.6.5) id RAA11590 for ietf-ppp@merit.edu; Tue, 7 Jun 1994 17:06:40 -0600 Date: Tue, 7 Jun 1994 17:06:40 -0600 From: Vernon Schryver Message-Id: <199406072306.RAA11590@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections > From: Patrick Klos > To: jgregg@shiva.com, wilson@ftp.com > Subject: Re: suspend/resume; virtual connections > Cc: ietf-ppp@merit.edu > > >>> A while ago I seem to remember someone posting a suggestion for > >>> new LCP packet types to enable virtual connections, i.e. the ability to > >>> make a connection suspend (and hang up the phone) in the absense of any > >>> real user data traffic, then resume when there was traffic to send. That > >>> way you could save phone carrier charges without actually bringing the PPP > >>> link down as far as the protocol engine was concerned. Is anybody working on > >>> this? Are there any drafts out? > > > >Why is this necessary? I thought PPP was an unreliable delivery service. > >What would be the advantage of such a system, besides (possibly) saving > >you from renegotiating again? > > > This has nothing to do with reliability. These options are (correct me if > I'm wrong) primarily to support "ON DEMAND" features of async PPP > implementations. The options would provide a way to inform the "server" > that a connection was being "suspended" due to lack of activity between the > 2 peers. In some instances, suspending rather than terminating provides the > "server" some additional information about the connection (i.e. I'll be > calling back, so don't release any resources I'm using [like a dynamic > IP address]). Actually, I think some people want to use this mechanism to > better support ON DEMAND IPX (with all the magic spoofing that must go on). > > Would someone else like to explain how they think these options would be > useful?? At least for IP, normal on-demand PPP implementations do just fine today without such facilities. At least I have no need for such a facility in my code. At least for me, monitorying TCP SYN's and FIN's, couting packets, and so on works just fine. I don't see how you could use such a option for hanging onto an IP address. What happens if the guy does not call back? What if the link does go down because of telco help?--should you release the IP address or not? As far as I can tell, the presense or absense of such an option cannot be used to keep or release an IP address. Maybe it's need for IPX or Appletalk. Not for IP. Vernon Schryver vjs@rhyolite.com - - - - - - - - - - - - - - - - - From list-admin Tue Jun 7 20:37:20 1994 Received: from lloyd.com (harry.lloyd.com [158.222.1.6]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id UAA15642 for ; Tue, 7 Jun 1994 20:37:19 -0400 Received: from [158.222.1.3] by lloyd.com with smtp (Smail3.1.28.1 #3) id m0qBBcR-000ESEC; Tue, 7 Jun 94 17:35 PDT Message-Id: Date: Tue, 7 Jun 94 17:35 PDT X-Sender: brian@harry.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: tomc@digibd.com (Tom Coradetti), ietf-ppp@merit.edu, sklower@vangogh.cs.berkeley.edu (Keith Sklower) From: brian@lloyd.com (Brian Lloyd) Subject: Re: PPP multilink initial sequence num At 17:51 6/7/94 -0500, Tom Coradetti wrote: >I believe that the PPP Multilink specification should require that >the first sequence number used by the transmitter after opening the >first link of a bundle should be 0. Makes sense to me. Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 - - - - - - - - - - - - - - - - - From list-admin Tue Jun 7 22:30:23 1994 Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id WAA21867 for ; Tue, 7 Jun 1994 22:30:21 -0400 Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (5.65a/94040804) id AA19992; Tue, 7 Jun 94 22:29:48 -0400 From: Karl Fox Received: by gefilte.MorningStar.Com (5.65a/94012401) id AA00557; Tue, 7 Jun 94 22:29:48 -0400 Date: Tue, 7 Jun 94 22:29:48 -0400 Message-Id: <9406080229.AA00557@gefilte.MorningStar.Com> To: wilson@ftp.com (Brad Wilson) Cc: ietf-ppp@merit.edu (IETF PPP working group) Subject: MD5 export restrictions? In-Reply-To: <9406071743.AA05715@ftp.com> References: <9406071743.AA05715@ftp.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Brad Wilson writes: > Does MD5 have any export restrictions? (I thought I remembered the answer > this question being no). Does anybody have any official oducmentation one > way or another on the issue? Our PPP with CHAP is approved for export to all countries except Libya, North Korea, and about half a dozen others. MD5 is not cryptography. - - - - - - - - - - - - - - - - - From list-admin Tue Jun 7 22:28:07 1994 Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id WAA21634 for ; Tue, 7 Jun 1994 22:28:05 -0400 Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (5.65a/94040804) id AA19988; Tue, 7 Jun 94 22:27:33 -0400 From: Karl Fox Received: by gefilte.MorningStar.Com (5.65a/94012401) id AA00554; Tue, 7 Jun 94 22:27:32 -0400 Date: Tue, 7 Jun 94 22:27:32 -0400 Message-Id: <9406080227.AA00554@gefilte.MorningStar.Com> To: John Gregg Cc: ietf-ppp@merit.edu Subject: suspend/resume; virtual connections In-Reply-To: <9406071446.AA06294@Shiva.COM> References: <9406071446.AA06294@Shiva.COM> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. John Gregg writes: > > A while ago I seem to remember someone posting a suggestion for > new LCP packet types to enable virtual connections, i.e. the ability to > make a connection suspend (and hang up the phone) in the absense of any > real user data traffic, then resume when there was traffic to send. That > way you could save phone carrier charges without actually bringing the PPP > link down as far as the protocol engine was concerned. Is anybody working on > this? Are there any drafts out? No. The idea didn't turn out to be useful after all, partly due to authentication problems. - - - - - - - - - - - - - - - - - From list-admin Wed Jun 8 10:02:15 1994 Received: from netcom.com (netcom8.netcom.com [192.100.81.117]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id KAA01353 for ; Wed, 8 Jun 1994 10:02:13 -0400 Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom) id HAA08995; Wed, 8 Jun 1994 07:02:25 -0700 From: thenrion@netcom.com (Tim Henrion) Message-Id: <199406081402.HAA08995@netcom.com> Subject: suspend/resume; virtual connections (fwd) To: ietf-ppp@merit.edu Date: Wed, 8 Jun 1994 07:02:25 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1187 Karl Fox writes: > > John Gregg writes: > > > > A while ago I seem to remember someone posting a suggestion for > > new LCP packet types to enable virtual connections, i.e. the ability to > > make a connection suspend (and hang up the phone) in the absense of any > > real user data traffic, then resume when there was traffic to send. That > > way you could save phone carrier charges without actually bringing the PPP > > link down as far as the protocol engine was concerned. Is anybody working on > > this? Are there any drafts out? > > No. The idea didn't turn out to be useful after all, partly due to > authentication problems. > Karl, Could you elaborate on your statement a little more? My company makes ISDN hardware which makes excellent "use" of the ability to suspend/resume ISDN connections on the fly. PPP not having the ability to do this is a big thorn in the side for us, particularly because the NIUF has specified PPP as the protocol for ISDN router interoperability. What's wrong with having to re-authenticate whenever you bring the connection back up but have the connection state saved at the time it was dropped? Thanks, Tim Henrion thenrion@netcom.com - - - - - - - - - - - - - - - - - From list-admin Wed Jun 8 11:23:39 1994 Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA08284 for ; Wed, 8 Jun 1994 11:23:37 -0400 Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (5.65a/94040804) id AA24176; Wed, 8 Jun 94 11:23:05 -0400 From: Karl Fox Received: by gefilte.MorningStar.Com (5.65a/94012401) id AA00771; Wed, 8 Jun 94 11:23:03 -0400 Date: Wed, 8 Jun 94 11:23:03 -0400 Message-Id: <9406081523.AA00771@gefilte.MorningStar.Com> To: thenrion@netcom.com (Tim Henrion) Cc: ietf-ppp@merit.edu Subject: suspend/resume; virtual connections (fwd) In-Reply-To: <199406081402.HAA08995@netcom.com> References: <199406081402.HAA08995@netcom.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Tim Henrion writes: > Karl Fox writes: > > John Gregg writes: ... > > > i.e. the ability to make a connection suspend (and hang up the > > > phone) in the absense of any real user data traffic, then resume > > > when there was traffic to send. ... > > No. The idea didn't turn out to be useful after all, partly due to > > authentication problems. > Could you elaborate on your statement a little more? My > company makes ISDN hardware which makes excellent "use" > of the ability to suspend/resume ISDN connections on the fly. > PPP not having the ability to do this is a big thorn in > the side for us, particularly because the NIUF has specified > PPP as the protocol for ISDN router interoperability. The original suggestion was to `suspend' and `resume' PPP `sessions' rather than terminating them and renegotiating them as normal. I thought that this wouldn't be useful since the authentication phase must still be traversed, and therefore LCP as well. I got the impression that the request was due to a misunderstanding of the functions of the link layer and the upper layers. Our product `suspends' and `resumes' `connections' by terminating them and then calling back and starting a new PPP session, including renegotiating LCP and reauthenticating. What the upper layer does is its business. My intent as a provider of a dial-on-demand link-layer product is to fool the upper layers into thinking it has a dedicated, permanent connection, not by telling them when the link comes up or goes down. My intent is to transport every single packet sent down by the upper layers, not to keep them informed of my state. > What's wrong with having to re-authenticate whenever you bring the > connection back up but have the connection state saved at the time > it was dropped? What connection state? If you mean the PPP connection state, then it was up, then it went down, then it came back up. If you mean the state of the upper layers, why would that state need to be saved? Isn't it already saved in the data structures associated with the upper layers? What would destroy it? Looking at it from another point of view, remember that the link layer went down because the upper layers were idle. If they're not doing anything, what would be the value of telling them that a link that they aren't using isn't available, but will become available again as soon as they try to use it? Am I perhaps completely misunderstanding your question? > Thanks, > Tim Henrion > thenrion@netcom.com - - - - - - - - - - - - - - - - - From list-admin Wed Jun 8 12:56:11 1994 Received: from csisdn.com (THELMA.CSISDN.COM [192.135.47.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA14775 for ; Wed, 8 Jun 1994 12:56:07 -0400 Received: by csisdn.com (4.1/4.2) id AA14881; Wed, 8 Jun 94 09:55:46 PDT Date: Wed, 8 Jun 94 09:55:46 PDT From: rimola@csisdn.com (Carlos Rimola-Sarti) Message-Id: <9406081655.AA14881@csisdn.com> To: ietf-ppp@merit.edu, vjs@calcite.rhyolite.com Subject: Re: suspend/resume; virtual connections Vernon Schryver writes: > > > At least for IP, normal on-demand PPP implementations do just fine today > without such facilities. At least I have no need for such a facility > in my code. At least for me, monitorying TCP SYN's and FIN's, > couting packets, and so on works just fine. > > I don't see how you could use such a option for hanging onto an IP > address. What happens if the guy does not call back? What if > the link does go down because of telco help?--should you release > the IP address or not? As far as I can tell, the presense or absense > of such an option cannot be used to keep or release an IP address. > We call it "keep-alive" in our implementation of inactivity timeout. The idea is that suspended connections are required to ocassionally reconnect to alert the server that the user is still there and, for example, has not turned off his workstation, experienced a line problem, reset, etc. If the keep-alive does not arrive, the IP address and other resources are released. > Maybe it's need for IPX or Appletalk. Not for IP. > > > Vernon Schryver vjs@rhyolite.com > It's needed for IP. I don't know about IPX. +---------------------------------------+-----------------------------------+ | Carlos Rimola-Sarti | email: rimola@csisdn.com | | Connective Strategies, Inc. | car@btr.com | | ISDN PRI Development, Proj. Mgr | phone: 415-903-2585 | +---------------------------------------+-----------------------------------+ - - - - - - - - - - - - - - - - - From list-admin Wed Jun 8 13:52:05 1994 Received: from pm002-11.dialip.mich.net (pm002-11.dialip.mich.net [35.1.48.92]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA19804 for ; Wed, 8 Jun 1994 13:52:02 -0400 Date: Wed, 8 Jun 94 16:30:21 GMT From: "William Allen Simpson" Message-ID: <2575.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: suspend/resume; virtual connections (fwd) > From: thenrion@netcom.com (Tim Henrion) > Could you elaborate on your statement a little more? My > company makes ISDN hardware which makes excellent "use" > of the ability to suspend/resume ISDN connections on the fly. > PPP not having the ability to do this is a big thorn in > the side for us, particularly because the NIUF has specified > PPP as the protocol for ISDN router interoperability. > > What's wrong with having to re-authenticate whenever > you bring the connection back up but have the connection > state saved at the time it was dropped? > We discussed this last year, too, with respect to ISDN. Folks in Europe needed to suspend/resume ISDN at intervals of less than a second. Hard to do with negotiation. If you haven't told PPP the link is down, it can go up and down rapidly. This is perfectly legal, since control signals are NOT required by PPP. Just drop the call without telling PPP. Set a timer. If the call doesn't come back up within perhaps 60 seconds, tell PPP that the link is Down. Just skipping LCP negotiation and doing only authentication will probably take just as long, because the secret lookup time is often disk based, or requires contact with another system, such as RADIUS. Using a periodic authentication like CHAP is better. If you are paranoid about security, don't use this technique. As a result of the discussion, I added the following to the HDLC-like draft, now in "Last Call". Please read. ---- 2. Physical Layer Requirements Control Signals Because signalling is not required, the physical layer MAY be decoupled from the data link layer, hiding the transient details of the physical transport. This has implications for mobility in cellular radio networks, and other rapidly switching links. Due to the bursty nature of data traffic, some implementations have choosen to disconnect the physical layer during periods of inactivity, and reconnect when traffic resumes, without informing the data link layer. Robust implementations should avoid using this trick over-zealously, since the price for decreased setup latency is decreased security. Implementations SHOULD signal the Down event whenever "significant time" has elapsed since the link was disconnected. The value for "significant time" is a matter of considerable debate, and is based on the tariffs, call setup times, and security concerns of the installation. Security Considerations As noted in the Physical Layer Requirements section, the link layer might not be informed when the connected state of the physical layer has changed. This results in possible security lapses due to over- reliance on the integrity and security of switching systems and administrations. An insertion attack might be undetected. An attacker which is able to spoof the same calling identity might be able to avoid link authentication. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Wed Jun 8 14:31:27 1994 Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA23258 for ; Wed, 8 Jun 1994 14:31:27 -0400 Received: by ftp.com ; Wed, 8 Jun 1994 14:31:18 -0400 Received: by ftp.com ; Wed, 8 Jun 1994 14:31:18 -0400 From: wilson@ftp.com (Brad Wilson) Message-Id: <9406081831.AA20231@ftp.com> Subject: Re: suspend/resume; virtual connections To: rimola@csisdn.com (Carlos Rimola-Sarti) Date: Wed, 8 Jun 1994 14:31:18 -0400 (EDT) Cc: ietf-ppp@merit.edu, vjs@calcite.rhyolite.com In-Reply-To: <9406081655.AA14881@csisdn.com> from "Carlos Rimola-Sarti" at Jun 8, 94 09:55:46 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1218 >> > Maybe it's need for IPX or Appletalk. Not for IP. >> >> It's needed for IP. I don't know about IPX. Nobody's given any reason why it's an LCP option and not an IPCP / IPXCP option (at best), or a stack option. There are just too many things that can go wrong with the idea of presuming that one end of the connection knows what the other end is up to, even though there is no communication. I wouldn't feel comfortable necessarily making such assumptions. Dial on demand is not perfect, but adding this option to the LCP doesn't seem to add anything but an advisory message of, "maybe I'll come back, maybe I won't". It certainly could never be looked at as a "I will be back definitely" message, because you could never know that for sure. -- Brad Wilson | Internet: wilson@ftp.com | #include FTP Software, Inc. | Voice: +1 800 282 4387 | #include 2 High Street | Facsimile: +1 508 659 6297 | #include N. Andover, MA 01845 | Support: support@ftp.com | msg++; smiley++; "If friends impose on you to babysit, it is within your rights to convert the child to a new religion." -- Dogbert, "Clues for the Clueless" - - - - - - - - - - - - - - - - - From list-admin Wed Jun 8 15:11:13 1994 Received: from csisdn.com (THELMA.CSISDN.COM [192.135.47.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id PAA26798 for ; Wed, 8 Jun 1994 15:11:10 -0400 Received: by csisdn.com (4.1/4.2) id AA15218; Wed, 8 Jun 94 12:10:50 PDT Date: Wed, 8 Jun 94 12:10:50 PDT From: rimola@csisdn.com (Carlos Rimola-Sarti) Message-Id: <9406081910.AA15218@csisdn.com> To: rimola@csisdn.com, wilson@ftp.com Subject: Re: suspend/resume; virtual connections Cc: ietf-ppp@merit.edu, vjs@calcite.rhyolite.com wilson@ftp.com (Brad Wilson) writes: > Subject: Re: suspend/resume; virtual connections > > >> > Maybe it's need for IPX or Appletalk. Not for IP. > >> > >> It's needed for IP. I don't know about IPX. > > Nobody's given any reason why it's an LCP option and not an IPCP / IPXCP > option (at best), or a stack option. There are just too many things that > can go wrong with the idea of presuming that one end of the connection > knows what the other end is up to, even though there is no communication. > I wouldn't feel comfortable necessarily making such assumptions. > > Dial on demand is not perfect, but adding this option to the LCP doesn't > seem to add anything but an advisory message of, "maybe I'll come back, > maybe I won't". It certainly could never be looked at as a "I will > be back definitely" message, because you could never know that for sure. > > -- > Brad Wilson | Internet: wilson@ftp.com | #include > FTP Software, Inc. | Voice: +1 800 282 4387 | #include > 2 High Street | Facsimile: +1 508 659 6297 | #include > N. Andover, MA 01845 | Support: support@ftp.com | msg++; smiley++; > > "If friends impose on you to babysit, it is within your rights to convert > the child to a new religion." -- Dogbert, "Clues for the Clueless" > I just want to point out that my comments were in reference to the issue of "hanging on" to the IP address and needing to know when to release it. I have no opinion at this time on *where* the negotiation of such suspend/resume options should take place (LCP, IPCP, stack, etc). +---------------------------------------+-----------------------------------+ | Carlos Rimola-Sarti | email: rimola@csisdn.com | | Connective Strategies, Inc. | car@btr.com | | ISDN PRI Development, Proj. Mgr | phone: 415-903-2585 | +---------------------------------------+-----------------------------------+ - - - - - - - - - - - - - - - - - From list-admin Wed Jun 8 15:20:20 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id PAA27246 for ; Wed, 8 Jun 1994 15:20:17 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id PAA18907; Wed, 8 Jun 1994 15:20:14 -0400 Date: Wed, 8 Jun 1994 15:20:14 -0400 From: Patrick Klos Message-Id: <199406081920.PAA18907@mv.mv.com> To: ietf-ppp@merit.edu, thenrion@netcom.com Subject: Re: suspend/resume; virtual connections (fwd) >Karl, >Could you elaborate on your statement a little more? My >company makes ISDN hardware which makes excellent "use" >of the ability to suspend/resume ISDN connections on the fly. >PPP not having the ability to do this is a big thorn in >the side for us, particularly because the NIUF has specified >PPP as the protocol for ISDN router interoperability. > >What's wrong with having to re-authenticate whenever >you bring the connection back up but have the connection >state saved at the time it was dropped? > >Thanks, >Tim Henrion >thenrion@netcom.com It's obvious that some people feel such a capability is useful, where others feel there's no place for it in PPP. Before we pass final judgement, let's make sure we keep our minds open to the idea that some people will be using PPP differently than others. There are definate advantages to a suspend/ resume capability, whether it be at an LCP level, it's own NCP, or specific options for those NCPs that could take advantage of it. We don't want each vendor to have to violate the spirit and come up with thier own method to accomplish this if we can all agree on some standard way to do the same thing! Just my opinion. Patrick P.S. I don't ever recall any authentication issues in previous discussions of this topic. The debate never lasted long enough to get that far. - - - - - - - - - - - - - - - - - From list-admin Wed Jun 8 15:47:38 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id PAA29422 for ; Wed, 8 Jun 1994 15:47:35 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id PAA23180; Wed, 8 Jun 1994 15:47:31 -0400 Date: Wed, 8 Jun 1994 15:47:31 -0400 From: Patrick Klos Message-Id: <199406081947.PAA23180@mv.mv.com> To: ietf-ppp@merit.edu, karl@morningstar.com Subject: Re: suspend/resume; virtual connections (fwd) Cc: thenrion@netcom.com >Our product `suspends' and `resumes' `connections' by terminating them >and then calling back and starting a new PPP session, including >renegotiating LCP and reauthenticating. What the upper layer does is >its business. My intent as a provider of a dial-on-demand link-layer >product is to fool the upper layers into thinking it has a dedicated, >permanent connection, not by telling them when the link comes up or >goes down. My intent is to transport every single packet sent down by >the upper layers, not to keep them informed of my state. Granted. >> What's wrong with having to re-authenticate whenever you bring the >> connection back up but have the connection state saved at the time >> it was dropped? > >What connection state? If you mean the PPP connection state, then it >was up, then it went down, then it came back up. If you mean the >state of the upper layers, why would that state need to be saved? >Isn't it already saved in the data structures associated with the >upper layers? What would destroy it? I think there is a possibility of a single port (or group of ports) handling more than one connection (although not at the same time). For each connection that is suspended, some information may be saved for re-use when the connection is resumed, whether on that port or another port of the same machine. There does not always have to be a one-to-one correlation between ports and connections. >Looking at it from another point of view, remember that the link layer >went down because the upper layers were idle. If they're not doing >anything, what would be the value of telling them that a link that >they aren't using isn't available, but will become available again as >soon as they try to use it? When one side decides that the link should go down due to inactivity, wouldn't it be nice to let the other side know that's the reason for shutting down the link?? Otherwise the other side wouldn't know if the first side that initiated the shutdown was DONE with the connection, or simply going into an IDLE state. Also, if the peer was DONE, the upper layer protocols might want to know that, whereas the upper layers wouldn't (shouldn't) be affected by an IDLE shutdown. >Am I perhaps completely misunderstanding your question? Unless you understand how and why someone is doing something, it's not always easy to know how to answer them. Maybe if people explain thier questions a little better, others will be able to help with thier answers a little better. Patrick - - - - - - - - - - - - - - - - - From list-admin Wed Jun 8 16:12:24 1994 Received: from netcomsv.netcom.com (netcomsv.netcom.com [192.100.81.101]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id QAA01907 for ; Wed, 8 Jun 1994 16:12:22 -0400 Received: from localhost by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id MAA17265; Wed, 8 Jun 1994 12:53:04 -0700 Received: from localhost (vjs@localhost) by calcite.rhyolite.com (8.6.5/8.6.5) id MAA16223 for ietf-ppp@merit.edu; Wed, 8 Jun 1994 12:37:25 -0600 Date: Wed, 8 Jun 1994 12:37:25 -0600 From: Vernon Schryver Message-Id: <199406081837.MAA16223@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections > From: rimola@csisdn.com (Carlos Rimola-Sarti) > > Vernon Schryver writes: > > > > At least for IP, normal on-demand PPP implementations do just fine today > > without such facilities. At least I have no need for such a facility > > in my code. At least for me, monitorying TCP SYN's and FIN's, > > couting packets, and so on works just fine. > > > > I don't see how you could use such a option for hanging onto an IP > > address. What happens if the guy does not call back? What if > > the link does go down because of telco help?--should you release > > the IP address or not? As far as I can tell, the presense or absense > > of such an option cannot be used to keep or release an IP address. > > > > We call it "keep-alive" in our implementation of inactivity timeout. > > The idea is that suspended connections are required to ocassionally > reconnect to alert the server that the user is still there and, > for example, has not turned off his workstation, experienced a line > problem, reset, etc. If the keep-alive does not arrive, the IP address > and other resources are released. > > > Maybe it's need for IPX or Appletalk. Not for IP. > It's needed for IP. I don't know about IPX. I am not convinced. I do not see that a special PPP packet or option is need needed for nailing down an IP address assignment. Consider cases: 1. the PPP link is in "Opened" state and you have IP packets flowing Obviously you "keep-alive" the IP address assignment regardless of whether you get any specical PPP packets 2. the PPP link is dead 2a. before the link went down, you got a special packet from the peer promising to call back before the IP address is reassigned. 2b. you didn't In cases 2a and 2b, I see no reason to do anything different. For a host of good reasons, you cannot reassign an IP address that was used in the last twice a TCP MSL. (Othereise you'll sometimes fill the PPP link with port unreachables--I speak from experience) You don't want to reassign an address that was last used with the last 16*30 seconds for the familiar routing stability hassles. Maybe the "keep-alive" message would reserve the IP address for many hours but in that case, I still don't see a reason to distinguish between 2a and 2b. I don't see why you might lock up the assignment longer in case 2b than case 2a. Vernon Schryver vjs@rhyolite.com - - - - - - - - - - - - - - - - - From list-admin Wed Jun 8 16:10:12 1994 Received: from localhost (ljb@localhost) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA01522; Wed, 8 Jun 1994 16:10:09 -0400 Message-Id: <199406082010.QAA01522@merit.edu> To: Patrick Klos cc: jgregg@shiva.com, wilson@ftp.com, ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections In-reply-to: Your message of "Tue, 07 Jun 1994 16:19:02 EDT." <199406072019.QAA05106@mv.mv.com> Date: Wed, 08 Jun 1994 16:10:03 -0400 From: "Larry J. Blunk" > >>> A while ago I seem to remember someone posting a suggestion for > >>> new LCP packet types to enable virtual connections, i.e. the ability to > >>> make a connection suspend (and hang up the phone) in the absense of any > >>> real user data traffic, then resume when there was traffic to send. That > >>> way you could save phone carrier charges without actually bringing the PP >P > >>> link down as far as the protocol engine was concerned. Is anybody working > on > >>> this? Are there any drafts out? > > > >Why is this necessary? I thought PPP was an unreliable delivery service. > >What would be the advantage of such a system, besides (possibly) saving > >you from renegotiating again? > > > This has nothing to do with reliability. These options are (correct me if > I'm wrong) primarily to support "ON DEMAND" features of async PPP > implementations. The options would provide a way to inform the "server" > that a connection was being "suspended" due to lack of activity between the > 2 peers. In some instances, suspending rather than terminating provides the > "server" some additional information about the connection (i.e. I'll be > calling back, so don't release any resources I'm using [like a dynamic > IP address]). Actually, I think some people want to use this mechanism to > better support ON DEMAND IPX (with all the magic spoofing that must go on). > > Would someone else like to explain how they think these options would be > useful?? > Some vendors allocate dynamic IP addresses in an LRU fashion and allow the peer to request any address in the IP address pool. This is useful for the case where you take a line hit and want to re-establish your PPP session with the same IP address. There's a pretty good chance that the last IP address you had will still be available. Your PPP implementation just has to have the ability of requesting the previous IP address. By making you IP address pool sufficiently large, you would increase the time the user had to re-establish the session with the same IP address. -Larry Blunk Merit Network, Inc. - - - - - - - - - - - - - - - - - From list-admin Wed Jun 8 19:16:24 1994 Received: from digibd.com (digibd.digibd.com [192.83.159.205]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id TAA15934 for ; Wed, 8 Jun 1994 19:16:23 -0400 Received: by digibd.com (5.65/DBI-1.19) id AA05678; Wed, 8 Jun 94 18:14:51 -0500 From: tomc@digibd.com (Tom Coradetti) Message-Id: <9406082314.AA05678@digibd.com> Subject: PPP Multilink testing on ISDN To: ietf-ppp@merit.edu Date: Wed, 8 Jun 1994 18:14:51 -0500 (CDT) X-Mailer: ELM [version 2.4 PL16] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 311 If anyone would like to arrange a simple test of PPP Multilink over 2 ISDN B channels, please send me some email. -- Tom Coradetti email: tomc@digibd.com DigiBoard, Inc. Phone: (612) 947-1118 6400 Flying Cloud Dr. FAX: (612) 947-1129 Eden Praire, MN 55344 - - - - - - - - - - - - - - - - - From list-admin Wed Jun 8 21:02:40 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id VAA22833 for ; Wed, 8 Jun 1994 21:02:38 -0400 Received: from [129.192.64.5] (coal.acc.com) by fennel.acc.com (4.1/SMI-4.1) id AA02389; Wed, 8 Jun 94 17:36:07 PDT Message-Id: <9406090036.AA02389@fennel.acc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Jun 1994 17:36:13 -0800 To: stev@ftp.com, topolcic@bbn.com From: fbaker@acc.com (Fred Baker) Subject: Multilink Draft Cc: sklower@vangogh.cs.berkeley.edu, ietf-ppp@merit.edu AD-types: I would like the IESG to issue its last call and start the discussion of the PPP Multilink Procedure in draft-ietf-pppext-multilink-09.txt. We have one outstanding comment on the draft: the sequence number on a multilink session needs to have a firm first value, for which zero is nominated. This is a one-liner and doesn't materially change anything else in the draft. Other comments have pretty well died down. Any comments which come in during the IESG last call, and any IESG comments, will be updated at the same time as this one. ============================================================================= "In sound wisdom there are two sides" Zophar, Job 11:6 - - - - - - - - - - - - - - - - - From list-admin Wed Jun 8 21:16:56 1994 Received: from pm012-09.dialip.mich.net (pm012-09.dialip.mich.net [35.1.48.210]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id VAA23591 for ; Wed, 8 Jun 1994 21:16:55 -0400 Date: Wed, 8 Jun 94 23:04:57 GMT From: "William Allen Simpson" Message-ID: <2578.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: suspend/resume; virtual connections > From: "Larry J. Blunk" > Some vendors allocate dynamic IP addresses in an LRU fashion and allow > the peer to request any address in the IP address pool. This is useful > for the case where you take a line hit and want to re-establish your PPP > session with the same IP address. There's a pretty good chance that the > last IP address you had will still be available. Your PPP implementation > just has to have the ability of requesting the previous IP address. > By making you IP address pool sufficiently large, you would increase > the time the user had to re-establish the session with the same IP > address. > This is definitely the right thing to do. Every PPP implementation I've written does this. Should be an implementation note in IPCP. Note it doesn't require any new options, either. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Wed Jun 8 21:44:22 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id VAA25356 for ; Wed, 8 Jun 1994 21:44:21 -0400 Received: from by fennel.acc.com (4.1/SMI-4.1) id AB03459; Wed, 8 Jun 94 18:44:14 PDT Message-Id: <9406090144.AB03459@fennel.acc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Jun 1994 18:44:17 -0800 To: ietf-ppp@merit.edu From: fbaker@acc.com (Fred Baker) Subject: The PPP OSI Network Layer Control Protocol (OSINLCP) I have a question re: RFC 1377. The author, Dave Katz, advises me that several interoperable implementations exist and that there are no known reasons it could not be advanced to Draft Standard without modification. If there is any reason NOT to do so, plase comment to the list by 17 June 1994, failing which I shall advise the AD that this RFC is available for advancement in situ. ============================================================================= "In sound wisdom there are two sides" Zophar, Job 11:6 - - - - - - - - - - - - - - - - - From list-admin Wed Jun 8 21:36:55 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id VAA24882 for ; Wed, 8 Jun 1994 21:36:54 -0400 Received: from [129.192.64.5] (coal.acc.com) by fennel.acc.com (4.1/SMI-4.1) id AA03459; Wed, 8 Jun 94 18:36:47 PDT Message-Id: <9406090136.AA03459@fennel.acc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Jun 1994 18:36:50 -0800 To: ietf-ppp@merit.edu From: fbaker@acc.com (Fred Baker) Subject: draft-ietf-pppext-callback-cp-00.txt We discussed at the last IETF some additional uses for call-back, which the current LCP extension allegedly didn't adequately address. Thomas wrote it up, but I have heard no comment. A penny for your thoughts? ============================================================================= "In sound wisdom there are two sides" Zophar, Job 11:6 - - - - - - - - - - - - - - - - - From list-admin Wed Jun 8 21:44:13 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id VAA25348 for ; Wed, 8 Jun 1994 21:44:12 -0400 Received: from by fennel.acc.com (4.1/SMI-4.1) id AB03459; Wed, 8 Jun 94 18:44:05 PDT Message-Id: <9406090144.AB03459@fennel.acc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Jun 1994 18:44:07 -0800 To: ietf-ppp@merit.edu From: fbaker@acc.com (Fred Baker) Subject: The PPP DECnet Phase IV Control Protocol (DNCP) I have a question re: RFC 1376. The author, Steve Senum, advises me that several interoperable implementations exist and that there are no known reasons it could not be advanced to Draft Standard without modification. If there is any reason NOT to do so, plase comment to the list by 17 June 1994, failing which I shall advise the AD that this RFC is available for advancement in situ. ============================================================================= "In sound wisdom there are two sides" Zophar, Job 11:6 - - - - - - - - - - - - - - - - - From list-admin Wed Jun 8 21:54:29 1994 Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id VAA25957 for ; Wed, 8 Jun 1994 21:54:28 -0400 Received: from cixgate.3com.com by relay2.UU.NET with SMTP (rama) id QQwtmd20703; Wed, 8 Jun 1994 21:54:26 -0400 Received: from gw.3Com.COM by cixgate.3com.com (4.1/SMI-4.1/3com-cixgate-GCA-931027-01) id AA07242; Wed, 8 Jun 94 18:56:01 PDT Received: from notes.DEV.3Com.COM by gw.3Com.COM with SMTP id AA29550 (5.65c/IDA-1.4.4 for ); Wed, 8 Jun 1994 18:54:23 -0700 Received: by notes.dev.3com.com (IBM OS/2 SENDMAIL VERSION 1.3.0)/1.0) id AA1783; Wed, 08 Jun 94 19:03:44 -0700 Message-Id: <9406090203.AA1783@notes.dev.3com.com> Received: from 3Com with "Lotus Notes Mail Gateway for SMTP" id 956AC44BE19DC6B68825606900062F99; Wed, 8 Jun 94 19:03:44 To: ietf-ppp Cc: Allen Rochkind/HQ/3Com From: Allen Rochkind/HQ/3Com Date: 8 Jun 94 18:54:32 PS Subject: suspend/resume; virtual connections (fwd) Mime-Version: 1.0 Content-Type: Text/Plain I second Karl Fox's suggestion that there should be PPP support for implementations to provide a dial on demand link layer, which fools the upper layers into thinking it has a permanent connection and does not have to concern itself with the transient state of the link. After all if dialing were not metered by time, for the benefit of the upper layers, we would leave up our connection indefinitely like a leased line. So dial on demand provides a transparent service to the upper layers to thinking it has a permanent connection, but really economizes on the (real-world time metered) telecommunications charges by dropping the line when the line is not in use. The main issue for me relevant to PPP interoperability between vendor equipment is the relationship between the NCP negotiations and the LCP negotiations. I view NCP negotiations as an upper layer issue. The LCP negotiation is a link issue. I would like to leave up the NCP connection in the dial on demand situation irrespective of the state of the line going up or down. This is part of the transparent virtual "permanent connection" service offered by dial on demand. As the line goes up and down the LCP connection would go up or down (i.e. suspended or as Karl suggests could actually terminate it). If I do dial on demand this way, then how can I be assured that everyone does dial on demand similarly for interoperability? Also how can I tell whether the line is going up or down for dial on demand or the link is either broken or is to be permanently terminated? If we had a suspend/resume option in PPP, which everyone agreed upon, then we could distinguish between a temporary suspension (dial on demand) versus a permanent line termination. We could use suspend/resume to suspend/resume the LCP without causing any disruption in the state of the various NCP connections. If we agree on "suspend/resume" in concept, then more detailed work could iron out the issues as to whether the LCP is suspended or actually terminated. One reason we might want to terminate LCP with this option is that we could bring down lines of one characteristic and bring up another line (when there is traffic in dial on demand) of other characteristics. In this case the LCP parameters negotiated might change. The key idea here is that the "suspend" terminates the LCP without affecting the state of the NCP connections. The upper layers are not notified of the link termination. If the LCP is actually terminated by the normal terminate-request, then this represents a permanent termination, which the upper layers can then be made aware of to terminate their sessions. Date: 06/08/94 11:23:03 AM To: thenrion @ netcom.com (Tim Henrion) @ UGATE cc: ietf-ppp @ merit.edu @ UGATE (bcc: Allen Rochkind/HQ/3Com) From: karl @ MorningStar.Com (Karl Fox) @ UGATE Subject: suspend/resume; virtual connections (fwd) >The original suggestion was to `suspend' and `resume' PPP `sessions' >rather than terminating them and renegotiating them as normal. I >thought that this wouldn't be useful since the authentication phase >must still be traversed, and therefore LCP as well. I got the >impression that the request was due to a misunderstanding of the >functions of the link layer and the upper layers. >Our product `suspends' and `resumes' `connections' by terminating them >and then calling back and starting a new PPP session, including >renegotiating LCP and reauthenticating. What the upper layer does is >its business. My intent as a provider of a dial-on-demand link-layer >product is to fool the upper layers into thinking it has a dedicated, >permanent connection, not by telling them when the link comes up or >goes down. My intent is to transport every single packet sent down by >the upper layers, not to keep them informed of my state. >What connection state? If you mean the PPP connection state, then it >was up, then it went down, then it came back up. If you mean the >state of the upper layers, why would that state need to be saved? >Isn't it already saved in the data structures associated with the >upper layers? What would destroy it? >Looking at it from another point of view, remember that the link layer >went down because the upper layers were idle. If they're not doing >anything, what would be the value of telling them that a link that >they aren't using isn't available, but will become available again as >soon as they try to use it? >Am I perhaps completely misunderstanding your question? - - - - - - - - - - - - - - - - - From list-admin Wed Jun 8 21:58:11 1994 Received: from netcomsv.netcom.com (netcomsv.netcom.com [192.100.81.101]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id VAA26438 for ; Wed, 8 Jun 1994 21:58:10 -0400 Received: from localhost by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id SAA08562; Wed, 8 Jun 1994 18:53:05 -0700 Received: from localhost (vjs@localhost) by calcite.rhyolite.com (8.6.5/8.6.5) id SAA17423 for ietf-ppp@merit.edu; Wed, 8 Jun 1994 18:34:03 -0600 Date: Wed, 8 Jun 1994 18:34:03 -0600 From: Vernon Schryver Message-Id: <199406090034.SAA17423@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections (fwd) > From: Patrick Klos > ... > >What connection state? If you mean the PPP connection state, then it > >was up, then it went down, then it came back up. If you mean the > >state of the upper layers, why would that state need to be saved? > >Isn't it already saved in the data structures associated with the > >upper layers? What would destroy it? > > I think there is a possibility of a single port (or group of ports) handling > more than one connection (although not at the same time). For each connection > that is suspended, some information may be saved for re-use when the > connection is resumed, whether on that port or another port of the same > machine. There does not always have to be a one-to-one correlation between > ports and connections. Fine, but you haven't answered the questions "what connnection state"? If that state vector is empty, then what's the point? > >Looking at it from another point of view, remember that the link layer > >went down because the upper layers were idle. If they're not doing > >anything, what would be the value of telling them that a link that > >they aren't using isn't available, but will become available again as > >soon as they try to use it? > > When one side decides that the link should go down due to inactivity, > wouldn't it be nice to let the other side know that's the reason for shutting > down the link?? No, it would not be nice. My demand-dialing code doesn't care why the link went down, whether the peer decided the line was idle or if some other, higher priority stuff needed the port, or the phone guy was messing around. When the line goes down, I just switch to the wait-for-traffic-after- hysterisis-and-restart mode. I can't see what you would do differently depending on why the line went down. > Otherwise the other side wouldn't know if the first side that > initiated the shutdown was DONE with the connection, or simply going into > an IDLE state. Except in a trivial, toy implementation, I think there is no definition of "DONE with the connection" that makes sense. Nor is "IDLE state" definable. I am connnected only by a demand-dialed PPP link. None of the following is theoretical. My code snoops on TCP packets to infer the number of active TCP connections and to adjust the idle timers appropriately. Still, my computers often guess wrong about whether I'm "DONE". Just because I've stopped typing does not mean I'm done talking over the link--I may be pausing to answer a phone call after ending my remote sessions to one set of machines and before starting new sessions on others. On the other hand, I often forget to close my remote sessions when I leave the keyboard for an hour or two, when I am done. Then there is NFS/UDP. Just because my NFS source maint. tool has not hit the source servers for a few seconds and I don't happen to have a remote session active does not mean I'm done. On the other hand, just because my automounted NFS mounts have not timed out (30 minutes) does not mean I'm not done. > Also, if the peer was DONE, the upper layer protocols might > want to know that, whereas the upper layers wouldn't (shouldn't) be > affected by an IDLE shutdown. What if the upper layers are on some other machine? Sometimes one of the two ends of the PPP link I use is the TCP source or distination. Other times, the ends of the TCP connection are far away and neither PPP peer has any upper layers to inform. Of course, in a internet-in-a-box product, you might be able to talk to the application. You might even be able to define "DONE". I think that's too restricted a situation to bend the PPP protocol to. Vernon Schryver vjs@rhyolite.com - - - - - - - - - - - - - - - - - From list-admin Thu Jun 9 08:27:11 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id IAA01354 for ; Thu, 9 Jun 1994 08:27:09 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id IAA03793; Thu, 9 Jun 1994 08:27:08 -0400 Date: Thu, 9 Jun 1994 08:27:08 -0400 From: Patrick Klos Message-Id: <199406091227.IAA03793@mv.mv.com> To: ietf-ppp@merit.edu, vjs@calcite.rhyolite.com Subject: Re: suspend/resume; virtual connections (fwd) >Fine, but you haven't answered the questions "what connnection state"? > >If that state vector is empty, then what's the point? O.K., I guess a REAL example would be useful. Using IPX and a dial-in router, the connection state would include the IPX network number assigned to link when first established. This would allow the router to prevent reassignment of the IPX network number to another connection. The connection state might also contain a list (one or more) of IPX addresses that should be "spoofed" when "NCP Watchdog" packets are sent to those addresses. This way, the router knows which packets should be watched for and responded to when the link is in it's suspended state. >> When one side decides that the link should go down due to inactivity, >> wouldn't it be nice to let the other side know that's the reason for shutting >> down the link?? > >No, it would not be nice. > >My demand-dialing code doesn't care why the link went down, whether the >peer decided the line was idle or if some other, higher priority stuff >needed the port, or the phone guy was messing around. > >When the line goes down, I just switch to the wait-for-traffic-after- >hysterisis-and-restart mode. > >I can't see what you would do differently depending on why the line >went down. Again, with the IPX example, if the peer was DONE, we could release the IPX network number assigned. We would also know that no "NCP Watchdog" spoofing was necessary. If the peer was just IDLE, then the information saved in the connection state (described above) could be used to maintain the apperance of a connection until some REAL traffic had to cross the link again. >> Otherwise the other side wouldn't know if the first side that >> initiated the shutdown was DONE with the connection, or simply going into >> an IDLE state. > >Except in a trivial, toy implementation, I think there is no definition >of "DONE with the connection" that makes sense. Nor is "IDLE state" >definable. How about a REAL, NON-TOY implementation, where the definition of DONE is "I'm unloading the PPP driver in DOS now; I'm DONE!", and the definition of IDLE is "I'm in Windows or DOS, I'm logged into a file server, but I haven't tried to access the file server for a while [maybe I went to lunch]; I'm IDLE". There are a lot of remote access users (ask Shiva) who would like to start thier DOS machine, log in, and go into Windows, never to have to come out again just to log out and disconnect the phone line. I think these users could benefit GREATLY from on-demand dialing. >I am connnected only by a demand-dialed PPP link. None of the following >is theoretical. > >My code snoops on TCP packets to infer the number of active TCP connections >and to adjust the idle timers appropriately. > >Still, my computers often guess wrong about whether I'm "DONE". >Just because I've stopped typing does not mean I'm done talking over >the link--I may be pausing to answer a phone call after ending my >remote sessions to one set of machines and before starting new sessions >on others. On the other hand, I often forget to close my remote >sessions when I leave the keyboard for an hour or two, when I am done. > >Then there is NFS/UDP. Just because my NFS source maint. tool has not >hit the source servers for a few seconds and I don't happen to have a >remote session active does not mean I'm done. On the other hand, just >because my automounted NFS mounts have not timed out (30 minutes) does >not mean I'm not done. I think it's easier for the user to indicate when they're DONE, and the software to define what IDLE means. That's all detail, anyway. Without a suspend/resume capability, it doesn't matter. With a suspend/resume capability, at least there may be a standard definition of how to address DONE and IDLE once they're defined. >> Also, if the peer was DONE, the upper layer protocols might >> want to know that, whereas the upper layers wouldn't (shouldn't) be >> affected by an IDLE shutdown. > >What if the upper layers are on some other machine? Sometimes one of >the two ends of the PPP link I use is the TCP source or distination. >Other times, the ends of the TCP connection are far away and neither >PPP peer has any upper layers to inform. When I refer to upper layers, I'm referring to the DATALINK layer. IP would need to know NOT to send IP packets through a disconnected port. Maybe IP would know to try to "resume" the connection when it has a packet to send. IPX would like to know if it needs to indicate that a certain route (and any services accessible over that route) went down and to propagate that information. If the link was IDLE, IPX needs to know it should still advertise those routes and services associated with the connection even when the link was down. >Of course, in a internet-in-a-box product, you might be able to talk to >the application. You might even be able to define "DONE". I think >that's too restricted a situation to bend the PPP protocol to. PPP is an extensible protocol for a reason. It has the ability to grow as it finds itself in more and more implementations and uses. I don't think it has to "bend". >Vernon Schryver vjs@rhyolite.com You keep going back to IP and how it could or could not benefit from something like suspend/resume. There are several other protocols that are using PPP more and more, and some of these protocols could benefit from extensions to PPP. Just because IP doesn't benefit from something doesn't mean that something is useless!?! Patrick - - - - - - - - - - - - - - - - - From list-admin Thu Jun 9 08:39:18 1994 Received: from sgw.xyplex.com (sgw.xyplex.com [140.179.224.7]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id IAA02202 for ; Thu, 9 Jun 1994 08:39:16 -0400 Received: by sgw.xyplex.com (4.1/SMI-4.1) id AA20193; Thu, 9 Jun 94 08:39:32 EDT From: sgw@sgw.xyplex.com (sgw) Message-Id: <9406091239.AA20193@sgw.xyplex.com> Subject: Re: suspend/resume; virtual connections (fwd) To: bsimpson@morningstar.com Date: Thu, 9 Jun 94 8:39:31 EDT Cc: ietf-ppp@merit.edu In-Reply-To: <2575.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Jun 8, 94 4:30 pm X-Mailer: ELM [version 2.3 PL8] > We discussed this last year, too, with respect to ISDN. Folks in Europe > needed to suspend/resume ISDN at intervals of less than a second. Hard > to do with negotiation. > > If you haven't told PPP the link is down, it can go up and down rapidly. > This is perfectly legal, since control signals are NOT required by PPP. > > Just drop the call without telling PPP. Set a timer. If the call > doesn't come back up within perhaps 60 seconds, tell PPP that the link > is Down. > > Just skipping LCP negotiation and doing only authentication will > probably take just as long, because the secret lookup time is often disk > based, or requires contact with another system, such as RADIUS. > > Using a periodic authentication like CHAP is better. > > If you are paranoid about security, don't use this technique. > Most PPP implementations use periodic echo-request/echo-reply packets to sanity-check the connection. The simple approach is to close LCP if you don't see N replies in a row. Therefore just blindly dropping the link without informing PPP isn't enough to solve the problem. LQM would notice that conditions have taken a turn for the worse, as well. After the link drops without informing PPP, The link driver could buffer transmitted PPP control packets and send them when the connection resumes. This approach works only when the suspend/resume interval is fairly short. For longer intervals, PPP would need to have some idea of the actual state of the link so as to avoid sending echo and LQR packets. +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | Scott G. Wasson sgwasson@eng.xyplex.com | | Xyplex, Internetworking & Media Voice: (508) 952-4746 | | 295 Foster St. Littleton, MA 01460 Fax: (508) 952-4887 | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ - - - - - - - - - - - - - - - - - From list-admin Thu Jun 9 09:57:54 1994 Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id JAA08856 for ; Thu, 9 Jun 1994 09:57:51 -0400 Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (5.65a/94040804) id AA07800; Thu, 9 Jun 94 09:57:15 -0400 From: Karl Fox Received: by gefilte.MorningStar.Com (5.65a/94012401) id AA01795; Thu, 9 Jun 94 09:57:13 -0400 Date: Thu, 9 Jun 94 09:57:13 -0400 Message-Id: <9406091357.AA01795@gefilte.MorningStar.Com> To: Allen Rochkind/HQ/3Com Cc: Allen Rochkind/HQ/3Com , ietf-ppp Subject: suspend/resume; virtual connections (fwd) In-Reply-To: <9406090203.AA1783@notes.dev.3com.com> References: <9406090203.AA1783@notes.dev.3com.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Allen Rochkind/HQ/3Com writes: > I second Karl Fox's suggestion that there should be PPP support for > implementations to provide a dial on demand link layer, which fools > the upper layers into thinking it has a permanent connection and > does not have to concern itself with the transient state of the > link. I did not suggest that there should be such support; there already is such support. If no packets are traversing a PPP link for a long enough time that a PPP implementation's idle timers shut the link down, then NO PACKETS ARE TRAVERSING THE LINK. If no packets are traversing the link, then the upper layers are not doing anything. If the upper layers are idle, then you can't make them `more idle' or somehow better informed by telling them that the lower layers are down. The beauty of a demand-dialed link layer is that no communication is necessary at all with the upper layers. If it's transparent to the upper layers, then you can't somehow make it more transparent by making it more complex. As Vernon Schryver pointed out, you might not even be able to talk to the upper layers at all. In the vast majority of PPP installations, at least one of the ends of the upper layer sessions is not in the same place as either of the ends of the PPP link, so no communication is even possible. PPP carries packets, not just sessions. You can sometimes determine when sessions are finished, but not always. How do you know when a UDP `session' is finished? Vernon's example of NFS is an excellent illustration of this. The point of all this is that when a PPP session ends, you can't tell if it is finished or not. Even if you think you do, you don't -- the other end might not be able to get back in, or it may encounter busy phone lines. It may be a laptop that is just now being unplugged and folded up, or the link may have gone down because of equipment failure. I have heard only one argument as to why it might be desirable to inform the upper layers that a session had, in fact, `ended' -- and that is so that existing TCP sessions could be shut down. However, the only way to determine from the link layer that a PPP session is `ended' as opposed to `paused' or `temporarily idle' is by watching the TCP sessions and shutting down when they are all closed! So, the only time this could be useful is exactly when it can't! If, after reading this frothing diatribe, you still see a need for `suspend/resume', then please help me understand why by answering these questions: 1) How would suspend/resume differ from standard PPP startup/shutdown? 2) When would each (suspend/resume versus startup/shutdown) be used? 3) What `state' would suspend/resume record between PPP sessions? I apologize for the ferocity and verbose nature of this message. I'm frustrated by the broad base of acceptance of this suggested feature and by the lack of technical reasons for that support. - - - - - - - - - - - - - - - - - From list-admin Thu Jun 9 11:05:19 1994 Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA14461 for ; Thu, 9 Jun 1994 11:05:17 -0400 Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (5.65a/94040804) id AA08461; Thu, 9 Jun 94 11:04:44 -0400 From: Karl Fox Received: by gefilte.MorningStar.Com (5.65a/94012401) id AA01833; Thu, 9 Jun 94 11:04:43 -0400 Date: Thu, 9 Jun 94 11:04:43 -0400 Message-Id: <9406091504.AA01833@gefilte.MorningStar.Com> To: Patrick Klos Cc: ietf-ppp@merit.edu, vjs@calcite.rhyolite.com Subject: Re: suspend/resume; virtual connections (fwd) In-Reply-To: <199406091227.IAA03793@mv.mv.com> References: <199406091227.IAA03793@mv.mv.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Patrick Klos writes: > >Fine, but you haven't answered the questions "what connnection state"? > > > >If that state vector is empty, then what's the point? > > O.K., I guess a REAL example would be useful. Using IPX and a dial-in > router, the connection state would include the IPX network number assigned > to link when first established. This would allow the router to prevent > reassignment of the IPX network number to another connection. The connection > state might also contain a list (one or more) of IPX addresses that should be > "spoofed" when "NCP Watchdog" packets are sent to those addresses. This way, > the router knows which packets should be watched for and responded to when > the link is in it's suspended state. ... > Again, with the IPX example, if the peer was DONE, we could release the IPX > network number assigned. We would also know that no "NCP Watchdog" spoofing > was necessary. If the peer was just IDLE, then the information saved in the > connection state (described above) could be used to maintain the apperance > of a connection until some REAL traffic had to cross the link again. Ah, thank you -- a real reason! I still have a question, though: What happens if the `PC' suspends and hangs up the phone and then gets powered off? Won't the server end have to eventually time out the connection anyway so that it doesn't gradually use up memory until it crashes? If so, then what's the difference between suspend and disconnect? > When I refer to upper layers, I'm referring to the DATALINK layer. Maybe we're just using different terminology, but I've always considered PPP to be at the link layer or datalink layer. Which protocols do you include in the datalink layer? > IP would need to know NOT to send IP packets through a disconnected > port. Maybe IP would know to try to "resume" the connection when it > has a packet to send. The server end of our PPP implementation will try to call back (`resume') the connection if a return packet is sent down by IP if it is set up to do so. If not, then it has neither an interface nor a route, so the packet would never be sent down to PPP. - - - - - - - - - - - - - - - - - From list-admin Thu Jun 9 12:06:52 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id MAA21058 for ; Thu, 9 Jun 1994 12:06:51 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id MAA08568; Thu, 9 Jun 1994 12:06:42 -0400 Date: Thu, 9 Jun 1994 12:06:42 -0400 From: Patrick Klos Message-Id: <199406091606.MAA08568@mv.mv.com> To: ietf-ppp@merit.edu, karl@morningstar.com Subject: Re: suspend/resume; virtual connections (fwd) >Ah, thank you -- a real reason! I still have a question, though: What >happens if the `PC' suspends and hangs up the phone and then gets >powered off? Won't the server end have to eventually time out the >connection anyway so that it doesn't gradually use up memory until it >crashes? If so, then what's the difference between suspend and >disconnect? Sure, the server could time out suspended connections if so desired. The biggest difference between suspend and disconnect is that disconnect can free any associated resources IMMEDIATELY, whereas suspend can maintain those resources for some predefined amount of time (or forever if one so chooses). Granted, you must be careful when no timeout is provided for a suspend. >> When I refer to upper layers, I'm referring to the DATALINK layer. > >Maybe we're just using different terminology, but I've always >considered PPP to be at the link layer or datalink layer. Which >protocols do you include in the datalink layer? Sorry, I should have said NETWORK layer. I goofed up there. I include protocols like IP or IPX in this, not TCP/UDP or SPX/NCP. >> IP would need to know NOT to send IP packets through a disconnected >> port. Maybe IP would know to try to "resume" the connection when it >> has a packet to send. > >The server end of our PPP implementation will try to call back >(`resume') the connection if a return packet is sent down by IP if it >is set up to do so. If not, then it has neither an interface nor a >route, so the packet would never be sent down to PPP. How the NETWORK layer handles deciding when to resume a connection is fairly dependant on the protocol, but in general, when a connection is suspended, trying to send a packet to that connection would invoke the DIAL-AND-CONNECT function to reestablish the link. - - - - - - - - - - - - - - - - - From list-admin Thu Jun 9 15:02:20 1994 Received: from ucdavis.ucdavis.edu (ucdavis.edu [128.120.250.250]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id OAA04424 for ; Thu, 9 Jun 1994 14:59:09 -0400 Received: from ctron.com by ucdavis.ucdavis.edu (8.6.8/UCD2.50) id LAA22230; Thu, 9 Jun 1994 11:51:01 -0700 From: steffen@terrapin.ctron.com Received: from stealth.ctron.com by ctron.com (4.1/SMI-4.1) id AA20045; Thu, 9 Jun 94 14:51:00 EDT Received: from terrapin.ctron by stealth.ctron.com (4.1/SMI-4.1) id AA07261; Thu, 9 Jun 94 14:50:51 EDT Received: by terrapin.ctron (4.1/SMI-4.1) id AA05335; Thu, 9 Jun 94 14:51:06 EDT Message-Id: <9406091851.AA05335@terrapin.ctron> To: ietf-ppp@ucdavis.edu Subject: Third Party Code Reply-To: steffen@ctron.com Date: Thu, 09 Jun 94 14:44:48 -0400 Hello I am searching for any third party vendor that provides PPP implementations with source code that could be purchased by our company. This would include such things as PAP, CHAP, LQM, and any of the various protocol implementations. Thanks in advance Steffen Hermanns Cabletron Systems Inc. P.O. Box 5005 Rochester, NH 03867 --- ( Steffen M. Hermanns [ steffen@ctron.com] [ (603)332-9400 x1319 ] ) - - - - - - - - - - - - - - - - - From list-admin Thu Jun 9 15:14:07 1994 Received: from netcom.com (netcom4.netcom.com [192.100.81.107]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id PAA06330 for ; Thu, 9 Jun 1994 15:14:06 -0400 Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom) id MAA19561; Thu, 9 Jun 1994 12:14:06 -0700 Date: Thu, 9 Jun 1994 12:14:06 -0700 From: thenrion@netcom.com (Tim Henrion) Message-Id: <199406091914.MAA19561@netcom.com> To: wilson@ftp.com Subject: Re: suspend/resume; virtual connections Cc: ietf-ppp@merit.edu > > >> > Maybe it's need for IPX or Appletalk. Not for IP. > >> > >> It's needed for IP. I don't know about IPX. > > Nobody's given any reason why it's an LCP option and not an IPCP / IPXCP > option (at best), or a stack option. There are just too many things that > can go wrong with the idea of presuming that one end of the connection > knows what the other end is up to, even though there is no communication. > I wouldn't feel comfortable necessarily making such assumptions. > It would be an LCP option because it has to do with the physical state/capabilities of the link and nothing to do with the individual protocols. If you don't feel comfortable making such assumptions, then don't. Suspend/resume would/should be negotiable as an LCP option. If you can't handle it or aren't comfortable with it, reject it. > Dial on demand is not perfect, but adding this option to the LCP doesn't > seem to add anything but an advisory message of, "maybe I'll come back, > maybe I won't". It certainly could never be looked at as a "I will > be back definitely" message, because you could never know that for sure. > It enables "resume" capability with minimal delay. Granted this isn't very useful in the async modem world because reconnect times are *significantly* longer than re-nogotiation times. This is not necessarily true for digital telephony (ISDN). Tim Henrion Principal Software Engineer Extension Technology Corporation 30 Hollis Street Framingham, MA 01701 Phone: (508) 872-7748 FAX: (509) 872-7533 Internet: thenrion@netcom.com - - - - - - - - - - - - - - - - - From list-admin Thu Jun 9 15:13:52 1994 Received: from netcom.com (netcom4.netcom.com [192.100.81.107]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id PAA06318 for ; Thu, 9 Jun 1994 15:13:51 -0400 Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom) id MAA19531; Thu, 9 Jun 1994 12:13:54 -0700 Date: Thu, 9 Jun 1994 12:13:54 -0700 From: thenrion@netcom.com (Tim Henrion) Message-Id: <199406091913.MAA19531@netcom.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections (fwd) > If, after reading this frothing diatribe, you still see a need for > `suspend/resume', then please help me understand why by answering > these questions: > > 1) How would suspend/resume differ from standard PPP startup/shutdown? > They're *quicker* and don't require unnecessary renegotiation of configuration options which aren't going to change. > 2) When would each (suspend/resume versus startup/shutdown) be used? > In a LAN emulator scenario, suspend/resume would be used whenever activity between two peers on the "LAN" ceased. Startup/shutdown would be used when you were connecting to a new "node" on the "LAN" or disconnecting your self from the "LAN". > 3) What `state' would suspend/resume record between PPP sessions? > The state of all currently configured LCP/NCP options Tim Henrion Principal Software Engineer Extension Technology Corporation 30 Hollis Street Framingham, MA 01701 Phone: (508) 872-7748 FAX: (509) 872-7533 Internet: thenrion@netcom.com Tim Henrion thenrion@netcom.com - - - - - - - - - - - - - - - - - From list-admin Thu Jun 9 15:30:53 1994 Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id PAA08451 for ; Thu, 9 Jun 1994 15:30:50 -0400 Received: from cixgate.3com.com by relay2.UU.NET with SMTP (rama) id QQwtow05701; Thu, 9 Jun 1994 15:30:48 -0400 Received: from gw.3Com.COM by cixgate.3com.com (4.1/SMI-4.1/3com-cixgate-GCA-931027-01) id AA08977; Thu, 9 Jun 94 12:32:23 PDT Received: from notes.DEV.3Com.COM by gw.3Com.COM with SMTP id AA19849 (5.65c/IDA-1.4.4 for ); Thu, 9 Jun 1994 12:30:45 -0700 Received: by notes.dev.3com.com (IBM OS/2 SENDMAIL VERSION 1.3.0)/1.0) id AA7003; Thu, 09 Jun 94 12:40:06 -0700 Message-Id: <9406091940.AA7003@notes.dev.3com.com> Received: from 3Com with "Lotus Notes Mail Gateway for SMTP" id F84E0A1E1D5BB5B2882560690069C132; Thu, 9 Jun 94 12:40:00 To: Karl Fox Cc: Allen Rochkind/HQ/3Com , ietf-ppp From: Allen Rochkind/HQ/3Com Date: 9 Jun 94 12:30:56 PS Subject: Re: suspend/resume; virtual connections (fwd) Mime-Version: 1.0 Content-Type: Text/Plain I apologize for misrepresenting your point of view. I wanted to say that I agree with your philosophy of dial on demand providing a transparent virtual "permanent connection" to upper layers. I see now you do not incorporate any special PPP mechanism to achieve this. However, I was wondering whether you made the assumption that the NCPs that you had previously negotiated will stay up when you transparently disconnect the LCP after the line idles. My concern was that some other vendors implementing dial on demand may assume that if the LCP is disconnected then all NCPs should be disconnected also. In this case we may have lack of interoperability because when the line comes up again, the NCPs will be in inconsistent states. I wanted a mechanism to make sure all vendor implementations are kept in synch on their NCP connections during dial on demand operation. If PPP has a current method to assure this NCP synchronization with the LCP going up and down, then I agree we don't need a new "suspend" operation. However, my understanding is that PPP is somewhat ambiguous about what happens to the NCPs when the LCPs go up and down. That ambiguity (if I am correct) is the crux of the problem and the "suspend" is only a proposed means to clarify this ambiguity so all implementations stay in synch. I believe Tim Henrion has stated what I wanted to say the best below: >The "connection state" is the state of all currently negotiated NCP >options so that no renegotiation has to take place when the link resumes. >The idea is to be able to resume the connection is as little time as >possible. When the line is brought up, the originator should be able to >tell the other side that he is resuming a suspended connection (by >passing some type of identifier) and re-authenticating himself. >The connection should then resume in the OPEN state with all NCP >options being set to what they were when the connection suspended. I was concerned about loss of interoperability between vendor dial on demand implementations precisely because I feared one vendor would disconnect all NCPs when the LCP went down for idle lines, but the other vendor would leave the NCPs up. The "suspension" mechanism is a standard way to tell both vendors that the LCP went down, but the NCPs should not be affected. - - - - - - - - - - - - - - - - - From list-admin Thu Jun 9 16:49:07 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA16027 for ; Thu, 9 Jun 1994 16:49:06 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09106; 9 Jun 94 15:52 EDT To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@merit.edu Cc: The Internet Engineering Steering Group From: IESG Secretary Subject: Protocol Action: PPP Reliable Transmission to Proposed Standard Date: Thu, 09 Jun 1994 15:52:51 -0400 Sender: jstewart@IETF.CNRI.Reston.VA.US Message-ID: <9406091552.aa09106@IETF.CNRI.Reston.VA.US> The IESG has approved the Internet-Draft "PPP Reliable Transmission" as a Proposed Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact is Stev Knowles. Technical Summary This document defines a method for negotiating and using Numbered- Mode, as defined by ISO 7776, to provide a reliable serial link. Working Group Summary This document, as an output of the PPPEXT Working Group, was the subject of considerable attention. There do not seem to be any open concerns from the group. Protocol Quality This protocol generated no traffic during it's Last Call. As specified, it seems like a reasonable approach to the problems it intends to solve, and there appear to be no missing pieces. The document follows existing PPPEXT RFC formats, so it is easy for a reader with previous experience with PPPEXT documents to follow. This review was done by Stev Knowles, one of the Internet Area Directors, for the IESG. Note to the RFC Editor Upon publication, please change the title of the document to "PPP on Numbered-Mode HDLC Links." - - - - - - - - - - - - - - - - - From list-admin Thu Jun 9 18:06:24 1994 Received: from pm002-23.dialip.mich.net (pm002-23.dialip.mich.net [35.1.48.104]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA29006 for ; Thu, 9 Jun 1994 13:51:44 -0400 Date: Thu, 9 Jun 94 15:32:36 GMT From: "William Allen Simpson" Message-ID: <2588.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: suspend/resume; virtual connections (fwd) > This approach works only when the suspend/resume interval is fairly short. > For longer intervals, PPP would need to have some idea of the actual state > of the link so as to avoid sending echo and LQR packets. > That is correct. The time issue is already mentioned in the RFC. The actual state is either Opened for traffic, or not Opened for traffic. There is no "Suspended" state. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Thu Jun 9 18:36:13 1994 Received: from rodan.UU.NET (389@rodan.UU.NET [153.39.128.10]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA26005 for ; Thu, 9 Jun 1994 13:11:30 -0400 Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA27064; Thu, 9 Jun 94 13:11:28 -0400 Message-Id: <9406091711.AA27064@rodan.UU.NET> To: ietf-ppp From: "Louis A. Mamakos" Subject: Re: suspend/resume; virtual connections (fwd) In-Reply-To: Your message of "08 Jun 1994 18:54:32 +0600." <9406090203.AA1783@notes.dev.3com.com> Date: Thu, 09 Jun 1994 13:11:27 -0400 Sender: louie@uunet.uu.net So some people believe that we need a meta-control protocol to control the Link Control Protocol? I still don't understand what problem I might have that would be better solved with all this additional complexity. > If we agree on "suspend/resume" in concept, then more detailed work could iron > out the issues as to whether the LCP is suspended or actually terminated. One > reason we might want to terminate LCP with this option is that we could bring > down lines of one characteristic and bring up another line (when there is > traffic in dial on demand) of other characteristics. In this case the LCP > parameters negotiated might change. The key idea here is that the "suspend" > terminates the LCP without affecting the state of the NCP connections. The > upper layers are not notified of the link termination. If the LCP is actually > terminated by the normal terminate-request, then this represents a permanent > termination, which the upper layers can then be made aware of to terminate > their sessions. - - - - - - - - - - - - - - - - - From list-admin Thu Jun 9 17:25:21 1994 Received: from pm002-23.dialip.mich.net (pm002-23.dialip.mich.net [35.1.48.104]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA29071 for ; Thu, 9 Jun 1994 13:52:07 -0400 Date: Thu, 9 Jun 94 17:35:46 GMT From: "William Allen Simpson" Message-ID: <2598.bill.simpson@um.cc.umich.edu> To: IESG Cc: ietf-ppp@merit.edu Reply-to: bsimpson@MorningStar.Com Subject: Re: Last Call2: PPP in HDLC-like Framing to Standard I have received one message that indicates there may be a missing or incorrect quote mark. I am unable to find this, and have asked for clarification. I believe we are ready to go forward without delay. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Thu Jun 9 19:07:22 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA23500 for ; Thu, 9 Jun 1994 12:39:11 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for ietf-ppp@merit.edu id AA04804; Thu, 9 Jun 94 09:39:07 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA25619; Thu, 9 Jun 94 10:39:24 -0600 Date: Thu, 9 Jun 94 10:39:24 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406091639.AA25619@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections (fwd) > From: klos@mv.MV.COM (Patrick Klos) > ... > >What connection state? If you mean the PPP connection state, then it > >was up, then it went down, then it came back up. If you mean the > >state of the upper layers, why would that state need to be saved? > >Isn't it already saved in the data structures associated with the > >upper layers? What would destroy it? > > I think there is a possibility of a single port (or group of ports) handling > more than one connection (although not at the same time). For each connection > that is suspended, some information may be saved for re-use when the > connection is resumed, whether on that port or another port of the same > machine. There does not always have to be a one-to-one correlation between > ports and connections. That demand-dialing code that I keep going on about maintains more than one UNIX PPP "network interface" alive per physical port, but I have no need for a PPP pause or resume facility. I fire up PPP state machinery when there is traffic. I do the obvious for IP number negotiation. (A UNIX BSD-style network "interface" is commonly associated with an LAN MAC. It has lots of state, including IP addresses, counts, and queues.) vjs - - - - - - - - - - - - - - - - - From list-admin Thu Jun 9 18:47:11 1994 Received: from nbkanata.newbridge.com (nbkanata.Newbridge.COM [192.75.23.5]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA02819 for ; Thu, 9 Jun 1994 14:34:10 -0400 Received: from Newbridge.COM (thor.Newbridge.COM) by nbkanata.newbridge.com (4.1/SMI-4.1) id AA11011; Thu, 9 Jun 94 14:29:39 EDT Received: from mako.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA19629; Thu, 9 Jun 94 14:29:35 EDT Received: from urchin.newbridge by mako.newbridge (4.1/SMI-4.1) id AA01935; Thu, 9 Jun 94 14:29:35 EDT Received: by urchin.newbridge (5.0/SMI-SVR4) id AA01384; Thu, 9 Jun 1994 14:32:00 +0500 Date: Thu, 9 Jun 1994 14:32:00 +0500 From: jhalpern@mako.Newbridge.COM (Joel Halpern) Message-Id: <9406091832.AA01384@urchin.newbridge> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections (fwd) X-Sun-Charset: US-ASCII Content-Length: 1152 While a mechanism to communicte that one is taking a link down transiently is apparently useful, I believe there are several significant failure modes that reduce its utility. 1) The message can get lost. Therefore, I will think I am in a pending state, but the other end will not. This is important if I expect him to retain state for me. A) This means that servers must retain state for hung up lines B) And even if one did a "suspend", one must be prepared for a full negotiation when the link starts back up. 2) After doing a suspend, one end or the other may go away. They may go away in a fashion which precludes notification. Even if not, it seems very odd to have to make a call just to say good-bye. It seems to me that based on these failure modes, there is very little advantage to having an indiciation over quietly closing the link and restricting how much PPP knows about the closure for a little while. (I could almost imagine creating an option for the LCP to negotiate that one wanted to do such a thing. Seems distinctly awkward.) Thank you, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. - - - - - - - - - - - - - - - - - From list-admin Thu Jun 9 19:16:49 1994 Received: from netcom.com (netcom11.netcom.com [192.100.81.121]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id MAA23373 for ; Thu, 9 Jun 1994 12:35:40 -0400 Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom) id JAA09075; Thu, 9 Jun 1994 09:35:52 -0700 Date: Thu, 9 Jun 1994 09:35:52 -0700 From: thenrion@netcom.com (Tim Henrion) Message-Id: <199406091635.JAA09075@netcom.com> To: vjs@calcite.rhyolite.com Subject: Re: suspend/resume; virtual connections Cc: ietf-ppp@merit.edu > > > From: Patrick Klos > > > ... > > >What connection state? If you mean the PPP connection state, then it > > >was up, then it went down, then it came back up. If you mean the > > >state of the upper layers, why would that state need to be saved? > > >Isn't it already saved in the data structures associated with the > > >upper layers? What would destroy it? > > > > I think there is a possibility of a single port (or group of ports) handling > > more than one connection (although not at the same time). For each connectio > > that is suspended, some information may be saved for re-use when the > > connection is resumed, whether on that port or another port of the same > > machine. There does not always have to be a one-to-one correlation between > > ports and connections. > > Fine, but you haven't answered the questions "what connnection state"? > The "connection state" is the state of all currently negotiated NCP options so that no renegotiation has to take place when the link resumes. The idea is to be able to resume the connection is as little time as possible. When the line is brought up, the originator should be able to tell the other side that he is resuming a suspended connection (by passing some type of identifier) and re-authenticating himself. The connection should then resume in the OPEN state with all NCP options being set to what they were when the connection suspended. > > > >Looking at it from another point of view, remember that the link layer > > >went down because the upper layers were idle. If they're not doing > > >anything, what would be the value of telling them that a link that > > >they aren't using isn't available, but will become available again as > > >soon as they try to use it? > > > > When one side decides that the link should go down due to inactivity, > > wouldn't it be nice to let the other side know that's the reason for shuttin > > down the link?? > > No, it would not be nice. > Oh, yes it would. For PPP implementations that run as standard point-to-point links there is not much point. Keep in mind, however, that not all PPP implementations will be serial lines running over modems which interface to protocol stacks as point-to-point devices. LAN emulators running PPP over digital phone lines would benefit greatly from the ability to suspend/resume PPP connections on the fly. In these situations, it's actually a necessity. > My demand-dialing code doesn't care why the link went down, whether the > peer decided the line was idle or if some other, higher priority stuff > needed the port, or the phone guy was messing around. > > When the line goes down, I just switch to the wait-for-traffic-after- > hysterisis-and-restart mode. > > I can't see what you would do differently depending on why the line > went down. > What about routing? If you're on a connection which the other guy drops unexpectedly, wouldn't that cause you to mark your interface as down and have the routing layer invalidate all the routes through you? The idea is to not inform the upper layers that the connection has gone away so that routes will not get invalidated. In order to do this, you *need* to know why the connection was terminated and that it could be resumed at any time as necessary. > > I am connnected only by a demand-dialed PPP link. None of the following > is theoretical. > > My code snoops on TCP packets to infer the number of active TCP connections > and to adjust the idle timers appropriately. > > Still, my computers often guess wrong about whether I'm "DONE". > Just because I've stopped typing does not mean I'm done talking over > the link--I may be pausing to answer a phone call after ending my > remote sessions to one set of machines and before starting new sessions > on others. On the other hand, I often forget to close my remote > sessions when I leave the keyboard for an hour or two, when I am done. > You're assuming that a "resume" is a long operation, presumably because you're in the async world. In digital telephony, this is not the case. The reason for saving connection state and avoiding renegotiation of all of the NCPs make resuming even faster. It's irrelevant to system administrators whether you're really "DONE" or not, anyway. You're allocating a network media that has a $$ cost associated with it and you're not using it. Network administrators should be able to specify that if you do that for longer than a configurable period of time, the connection should be dropped to save toll charges and resumed when you're actually using it again. > Then there is NFS/UDP. Just because my NFS source maint. tool has not > hit the source servers for a few seconds and I don't happen to have a > remote session active does not mean I'm done. On the other hand, just > because my automounted NFS mounts have not timed out (30 minutes) does > not mean I'm not done. > See above. Tim Henrion Principal Software Engineer Extension Technology Corporation 30 Hollis Street Framingham, MA 01701 Phone: (508) 872-7748 FAX: (509) 872-7533 Internet: thenrion@netcom.com - - - - - - - - - - - - - - - - - From list-admin Thu Jun 9 18:27:38 1994 Received: from pm002-23.dialip.mich.net (pm002-23.dialip.mich.net [35.1.48.104]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA29062 for ; Thu, 9 Jun 1994 13:52:03 -0400 Date: Thu, 9 Jun 94 17:20:21 GMT From: "William Allen Simpson" Message-ID: <2596.bill.simpson@um.cc.umich.edu> To: IESG Cc: ietf-ppp@merit.edu Reply-to: bsimpson@MorningStar.Com Subject: Re: Last Call2: The Point-to-Point Protocol (PPP) to Standard I have received one question this pass, from a new implementor as to how to handle Configuration Options which are longer than the default MRU, and what happens to the other correct options. This is already handled in the wording of the Packet Formats section: When a packet is received with an invalid Length field, the packet is silently discarded without affecting the automaton. Based on the question, however, I have duplicated the text explicitly in the Configuration Options section: When the Data field is indicated by the Length to extend beyond the end of the Information field, the entire packet is silently discarded without affecting the automaton. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Thu Jun 9 19:14:29 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA00447 for ; Thu, 9 Jun 1994 14:08:54 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for ietf-ppp@merit.edu id AA16208; Thu, 9 Jun 94 11:08:48 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA25833; Thu, 9 Jun 94 12:08:38 -0600 Date: Thu, 9 Jun 94 12:08:38 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406091808.AA25833@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections (fwd) > From: klos@mv.MV.COM (Patrick Klos) > ... > >If that state vector is empty, then what's the point? > > O.K., I guess a REAL example would be useful. Using IPX and a dial-in > router, the connection state would include the IPX network number assigned > to link when first established. This would allow the router to prevent > reassignment of the IPX network number to another connection. The connection > state might also contain a list (one or more) of IPX addresses that should be > "spoofed" when "NCP Watchdog" packets are sent to those addresses. This way, > the router knows which packets should be watched for and responded to when > the link is in it's suspended state. I do not see the difference between what IPX is said above to need and what my uses of IP requires, but that I achieve without any such PPP pause/resume facility. My link would be useless if I had not arranged for sufficient RIP packets to be advertised even while the PPP link is "paused". > ... > Again, with the IPX example, if the peer was DONE, we could release the IPX > network number assigned. We would also know that no "NCP Watchdog" spoofing > was necessary. If the peer was just IDLE, then the information saved in the > connection state (described above) could be used to maintain the apperance > of a connection until some REAL traffic had to cross the link again. How is that different from what IP needs? How is it that IP demand dialed implementaitons work without puase/resume? > ... > How about a REAL, NON-TOY implementation, where the definition of DONE is > "I'm unloading the PPP driver in DOS now; I'm DONE!", and the definition > of IDLE is "I'm in Windows or DOS, I'm logged into a file server, but I > haven't tried to access the file server for a while [maybe I went to > lunch]; I'm IDLE". There are a lot of remote access users (ask Shiva) > who would like to start thier DOS machine, log in, and go into Windows, > never to have to come out again just to log out and disconnect the phone > line. I think these users could benefit GREATLY from on-demand dialing. > ... > I think it's easier for the user to indicate when they're DONE, and the > software to define what IDLE means. That's all detail, anyway. Without > a suspend/resume capability, it doesn't matter. With a suspend/resume > capability, at least there may be a standard definition of how to address > DONE and IDLE once they're defined. How can "the user to indicate when they're DONE" when the user is not using, and is not permitted to indicate anything to either PPP peer? What about my personal, real-life example of having a workstation act as a router? The "DONE" indication is possible only in the restricted case of a DOS (not NT or UNIX) box that has no other network connections. Right now, as I type this, I am about >1200 miles from my computers. I have logged into my home computer over a series of wide area, LAN and PPP links. How and why would I indicate to anything that I'm done? Even in your DOS scheme, neither your customers nor the INternet Service Provider would want a "DONE" indication. Consdier some typical scenarios: 1. DOS user logs in via demand-dialed PPP, does stuff, powers off machine (i.e. "DONE" is missed) 2. DOS user logs in via demand-dialed PPP, does stuff, DOS hangs, user reboots, logs in again, and expects to go on, at iwth old IP address if nothing eelse 3. DOS user logs in via demand-dialed PPP, does stuff, says "DONE", shuts down, and 5-minutes later decides to log in again The DONE indication is inevitiably missing or wrong in those scenarios. In all cases the Internet Service Provider will have retained the address assignment for the same duration regardless of whether the user said "DONE". > ... > PPP is an extensible protocol for a reason. It has the ability to grow as > it finds itself in more and more implementations and uses. I don't think > it has to "bend". Bloat is as bad as bending. The biggest complaint people have with PPP is that it is too big and complicated. THey say SLIP is far better because it is simpler. (Read comp.protocols.ppp) > You keep going back to IP and how it could or could not benefit from > something like suspend/resume. There are several other protocols that > are using PPP more and more, and some of these protocols could benefit > from extensions to PPP. Just because IP doesn't benefit from something > doesn't mean that something is useless!?! I keep going back to IP because it has been asserted that IP needs such a facility. I have said that as far as I know, manybe IPX or Appletalk need pause/resume, although so far, I do not see why. Please think of PPP as more than a dumb terminal emulation package for PC's running DOS. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Thu Jun 9 18:46:31 1994 Received: from adtrn722.adtran.com ([198.51.35.247]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id SAA25109 for ; Thu, 9 Jun 1994 18:46:26 -0400 Message-Id: <199406092246.SAA25109@merit.edu> Received: by adtrn722.adtran.com (1.37.109.4/16.2) id AA03749; Thu, 9 Jun 94 17:38:27 -0500 From: Stuart Venters Subject: Re: suspend/resume on ISDN To: ietf-ppp@merit.edu Date: Thu, 9 Jun 94 17:38:26 CDT Mailer: Elm [revision: 70.85] ??? suspend/resume != hangup/redial ??? In an earlier life I worked on ISDN. I remember a feature called call suspend/resume whereby a call could be put on hold and then resumed. While the call was on hold, the Bearer channel circuit was disconnected and the metering of charges for the call was stopped. The D channel and the call, however were still very much alive and therefore you were sure that your peer at the far end of the call was also alive. Does anybody know if this feature is actually available in the telephone network? If it is then it seems that it would be useful for PPP to support it for spoofed IPX cases where the user is logged on but out to lunch. - - - - - - - - - - - - - - - - - From list-admin Thu Jun 9 19:14:24 1994 Received: from pm002-23.dialip.mich.net (pm002-23.dialip.mich.net [35.1.48.104]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA29013 for ; Thu, 9 Jun 1994 13:51:46 -0400 Date: Thu, 9 Jun 94 15:38:15 GMT From: "William Allen Simpson" Message-ID: <2589.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: suspend/resume; virtual connections (fwd) > From: Patrick Klos > Again, with the IPX example, if the peer was DONE, we could release the IPX > network number assigned. We would also know that no "NCP Watchdog" spoofing > was necessary. If the peer was just IDLE, then the information saved in the > connection state (described above) could be used to maintain the apperance > of a connection until some REAL traffic had to cross the link again. > > How about a REAL, NON-TOY implementation, where the definition of DONE is > "I'm unloading the PPP driver in DOS now; I'm DONE!", and the definition > of IDLE is "I'm in Windows or DOS, I'm logged into a file server, but I > haven't tried to access the file server for a while [maybe I went to > lunch]; I'm IDLE". There are a lot of remote access users (ask Shiva) > who would like to start thier DOS machine, log in, and go into Windows, > never to have to come out again just to log out and disconnect the phone > line. I think these users could benefit GREATLY from on-demand dialing. > Looking at your example, it would seem to me to be a bad IPXCP implementation. RFC-1552 clearly states that, by default, there is no network number assigned to a link that is not between two routers. As to demand dialing, there is no reason why the link cannot do a soft drop until more traffic is ready (on either end). The IPXCP should continue to spoof, since it should be unaware of the soft drop. Soft drop works just fine in MacPPP. The other problem you state (getting out of Windows to unload a driver) is a problem with Windows, not a problem with PPP. > I think it's easier for the user to indicate when they're DONE, and the > software to define what IDLE means. That's all detail, anyway. Without > a suspend/resume capability, it doesn't matter. With a suspend/resume > capability, at least there may be a standard definition of how to address > DONE and IDLE once they're defined. > Look, I don't understand the problem. Why aren't you sending Terminate-Requests to indicate you are "DONE"? That's how it is already defined! Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Thu Jun 9 21:37:49 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id VAA04729 for ; Thu, 9 Jun 1994 21:37:48 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for ietf-ppp@merit.edu id AA11151; Thu, 9 Jun 94 18:37:41 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA26790; Thu, 9 Jun 94 19:34:00 -0600 Date: Thu, 9 Jun 94 19:34:00 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406100134.AA26790@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections > From: thenrion@netcom.com (Tim Henrion) > ... > > Fine, but you haven't answered the questions "what connnection state"? > > > > The "connection state" is the state of all currently negotiated NCP > options so that no renegotiation has to take place when the link resumes. > The idea is to be able to resume the connection is as little time as > possible. When the line is brought up, the originator should be able to > tell the other side that he is resuming a suspended connection (by > passing some type of identifier) and re-authenticating himself. > The connection should then resume in the OPEN state with all NCP > options being set to what they were when the connection suspended. How long would it take to exchange those authenticating identifiers? How much faster would it be than just exchanging NCP configure-requests and Acks? The second time around, an NCP negotiation should involve absolutely no rejects or Naks. You should be able to send a single burst consisting of your LCP configure reuest followed by your NCP requests. You would receive the same for the other side. You would respond with a burst consisting of configure-Acks. Given a line at least as fast as a v.32bis modem, how would anything involving pause/resume be faster? As far as I can see, pause/resume might recquire fewer bytes, but it would take just as long to restore the connection. > > No, it would not be nice. > > Oh, yes it would. For PPP implementations that run as standard > point-to-point links there is not much point. Keep in mind, however, > that not all PPP implementations will be serial lines running over > modems which interface to protocol stacks as point-to-point devices. > LAN emulators running PPP over digital phone lines would benefit > greatly from the ability to suspend/resume PPP connections on > the fly. In these situations, it's actually a necessity. What PPP implementations are not "point-to-point links"? I don't see any different between "LAN emulators" and any other PPP application. Could you enlighten me? > > My demand-dialing code doesn't care why the link went down, whether the > > peer decided the line was idle or if some other, higher priority stuff > > needed the port, or the phone guy was messing around. > > > > When the line goes down, I just switch to the wait-for-traffic-after- > > hysterisis-and-restart mode. > > > > I can't see what you would do differently depending on why the line > > went down. > > What about routing? If you're on a connection which the other guy drops > unexpectedly, wouldn't that cause you to mark your interface as down > and have the routing layer invalidate all the routes through you? No. If I did that, then I could not use this PPP likn that I'm using at this very instant. As far as the upper layers (starting with IP) are concerned, my PPP links stay up all of the time. The fact that sometimes the PPP stuff is turned off and not just the PPP state but a lot more (SV STREAMS) state is gone is hidden from IP. > The idea is to not inform the upper layers that the connection has > gone away so that routes will not get invalidated. In order to do > this, you *need* to know why the connection was terminated and > that it could be resumed at any time as necessary. That is not true. Again, if that were true, then I could not use this PPP link. > ... > You're assuming that a "resume" is a long operation, presumably > because you're in the async world. In digital telephony, this is > not the case. The reason for saving connection state and avoiding > renegotiation of all of the NCPs make resuming even faster. How am I assuming such a thing? If I am (I don't think I am), how is it relevant? My code also runs over ISDN. Is that included in what you mean by "digital telephony"? > It's irrelevant to system administrators whether you're really "DONE" > or not, anyway. You're allocating a network media that has a $$ cost > associated with it and you're not using it. Network administrators > should be able to specify that if you do that for longer than a > configurable period of time, the connection should be dropped > to save toll charges and resumed when you're actually using it again. We agree about that. My PPP code (like MorningStar's and everyone else's demand dialing code) has knobs for controlling how much idle time under various circumstance causes the PPP link(s) (BF&I multilink) to be dropped. > > Then there is NFS/UDP. Just because my NFS source maint. tool has not > > hit the source servers for a few seconds and I don't happen to have a > > remote session active does not mean I'm done. On the other hand, just > > because my automounted NFS mounts have not timed out (30 minutes) does > > not mean I'm not done. > > See above. I do understand what you mean. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Thu Jun 9 22:07:20 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id WAA06869 for ; Thu, 9 Jun 1994 22:07:20 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for ietf-ppp@merit.edu id AA13695; Thu, 9 Jun 94 19:07:14 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA26869; Thu, 9 Jun 94 20:07:03 -0600 Date: Thu, 9 Jun 94 20:07:03 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406100207.AA26869@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections (fwd) > From: Allen_Rochkind/HQ/3Com@3mail.3Com.COM (Allen Rochkind/HQ/3Com) > ... > My concern was that some other vendors implementing dial on demand > may assume that if the LCP is disconnected then all NCPs should be > disconnected also. How could anyone read the current PPP RFC's and not assume that all NCPs "MUST" be cleared when LCP is disconnected? Where is the ambiguity in the current standard? Does any current PPP dial on demand implementation not assume that it must re-negotiate all NCPs? ] From: thenrion@netcom.com (Tim Henrion) ] ... ] > Dial on demand is not perfect, but adding this option to the LCP doesn't ] > seem to add anything but an advisory message of, "maybe I'll come back, ] > maybe I won't". It certainly could never be looked at as a "I will ] > be back definitely" message, because you could never know that for sure. ] ] It enables "resume" capability with minimal delay. Granted this ] isn't very useful in the async modem world because reconnect times ] are *significantly* longer than re-nogotiation times. This is ] not necessarily true for digital telephony (ISDN). It seems a "resume" capability could get a link running again with minimal delay, but I do not see why that delay is any less than the delay with the old fashioned style negotiation in an implementation that cares about minimum delay. I understand why fewer bytes might be involved, but I do not see why the exchange of packets would go faster. I presume the delay in coming up is entirely the result of waiting between sending the configure-requests and getting the acks, and not of the transmission time of the bits. Please say why a "reseme" capability would be faster. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 02:24:30 1994 Received: from lloyd.com (harry.lloyd.com [158.222.1.6]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id CAA22940 for ; Fri, 10 Jun 1994 02:24:27 -0400 Received: from [158.222.1.3] by lloyd.com with smtp (Smail3.1.28.1 #3) id m0qBzza-000756C; Thu, 9 Jun 94 23:23 PDT Message-Id: Date: Thu, 9 Jun 94 23:23 PDT X-Sender: brian@harry.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ppp@merit.edu From: brian@lloyd.com (Brian Lloyd) Subject: Re: suspend/resume; virtual connections (fwd) You know, this is actually the, "if a tree falls in the forest and there is nobody around to hear it, does it make a sound," question. I spent a lot of time thinking about this some years ago and finally came to the following conclusion: it doesn't matter. I don't really care if the far end is there or not; I just assume that it is. For the purposes of my routing and service advertising protocols I can connect and "learn" the peer's environment. From then on I can safely assume that it hasn't changed. The only time I really care is if I have actual traffic that has to pass to/through the peer. At that time I become interested in the real state of things at the peer's end. Several things can occur: 1. nothing has changed and all is well; 2. the peer is dead/catatonic and I use that info to clean up my routing and service advertisements; 3. things have changed and I need to relearn things and advertise new info. So even if I am running IPX and am "spoofing" the SAP broadcasts and other cruft, it doesn't matter what is happening at the other end unless someone really needs to get there and then the probe will teach me what I need to learn. Bottom line: it doesn't matter. Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 04:48:28 1994 Received: from relay1.pipex.net (relay1.pipex.net [158.43.128.4]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id EAA02356 for ; Fri, 10 Jun 1994 04:48:27 -0400 Received: from widow.spider.co.uk by relay1.pipex.net with SMTP (PP) id <04498-0@relay1.pipex.net>; Fri, 10 Jun 1994 09:47:49 +0100 Received: by widow.spider.co.uk; Fri, 10 Jun 94 09:46:10 +0100 From: Gerry Meyer Date: Fri, 10 Jun 94 09:44:42 +0100 Message-Id: <2759.9406100844@orbweb.spider.co.uk> Received: by orbweb.spider.co.uk; Fri, 10 Jun 94 09:44:42 +0100 To: thenrion@netcom.com Subject: Re: suspend/resume; virtual connections Cc: ietf-ppp@merit.edu >It enables "resume" capability with minimal delay. Granted this >isn't very useful in the async modem world because reconnect times >are *significantly* longer than re-nogotiation times. This is >not necessarily true for digital telephony (ISDN). National ISDN connections in the UK take ~ 1 sec. International connections can take 3 - 10 seconds. How long does your PPP negotiation to bring an ISDN link up take ? Gerry - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 08:47:35 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id IAA17504 for ; Fri, 10 Jun 1994 08:47:34 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id IAA21278; Fri, 10 Jun 1994 08:47:32 -0400 Date: Fri, 10 Jun 1994 08:47:32 -0400 From: Patrick Klos Message-Id: <199406101247.IAA21278@mv.mv.com> To: ietf-ppp@merit.edu, vjs@rhyolite.wpd.sgi.com Subject: Re: suspend/resume; virtual connections (fwd) >That demand-dialing code that I keep going on about maintains more than >one UNIX PPP "network interface" alive per physical port, but I have no need >for a PPP pause or resume facility. I fire up PPP state machinery >when there is traffic. I do the obvious for IP number negotiation. Vern, I'm glad you have no need for a PPP pause or resume facility. You seem to miss the point! There are other protocols that could benefit from them. Even IP (it has been suggested) could benefit from them. If you don't need them, DON'T USE THEM! As others have pointed out, it would be advantageous if there were a standard way to handle demand-dialing, and this mechanism would help. Why are you so against this??? I've pointed out several of the positive aspects of suspend/resume. If you want to help, maybe you can share with us what's so negative about having these features?? You DON'T have to implement them if you don't want to! So how does it hurt?!? The PPP world has nothing to lose by defining something like "suspend/resume". And some parts of the PPP world may benefit! So, where's the harm?!? >(A UNIX BSD-style network "interface" is commonly associated with an >LAN MAC. It has lots of state, including IP addresses, counts, and >queues.) > > >vjs Patrick - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 09:25:38 1994 Received: from rodan.UU.NET (389@rodan.UU.NET [153.39.128.10]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id JAA20718 for ; Fri, 10 Jun 1994 09:25:37 -0400 Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA02746; Fri, 10 Jun 94 09:25:06 -0400 Message-Id: <9406101325.AA02746@rodan.UU.NET> To: Patrick Klos Cc: ietf-ppp@merit.edu, vjs@rhyolite.wpd.sgi.com From: "Louis A. Mamakos" Subject: Re: suspend/resume; virtual connections (fwd) In-Reply-To: Your message of "Fri, 10 Jun 1994 08:47:32 EDT." <199406101247.IAA21278@mv.mv.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <2732.771254701.1@rodan.UU.NET> Date: Fri, 10 Jun 1994 09:25:03 -0400 Sender: louie@uunet.uu.net > I'm glad you have no need for a PPP pause or resume facility. You seem to > miss the point! There are other protocols that could benefit from them. > Even IP (it has been suggested) could benefit from them. If you don't > need them, DON'T USE THEM! As others have pointed out, it would be > advantageous if there were a standard way to handle demand-dialing, and > this mechanism would help. Don't we already have a standard way to do dial-on-demand? I seem to see it working just fine with all of our dial-up PPP customers. Many of us are arguing that its not NECESSARY to have another mechanism when there are existing mechanisms which seem to work just fine. Are the existing mechanism optimal for *every* situation - of course not. O the other hand they work in a wide variety of environments very well. > Why are you so against this??? I've pointed out several of the positive > aspects of suspend/resume. If you want to help, maybe you can share with > us what's so negative about having these features?? You DON'T have to > implement them if you don't want to! So how does it hurt?!? The PPP world > has nothing to lose by defining something like "suspend/resume". And some > parts of the PPP world may benefit! So, where's the harm?!? Vernon is attempting to maintain some sort of "purity" in the protocol in the sense of not allowing to to grow unsightly hair in places which would make PPP impossible to reasonably implement. Simply put, the "harm" is that there is unneccary complexity in a protocol (PPP) which some would argue is a few orders of magnitude too complex already. Heck, lets just throw the kitchen sink in there, and add reliable transport of frames, negotiaion of accounting and billing options and many other things that properly don't belong in a link-level protocol specification. Fram a practical standpoint, all this unnecsssary complexity is not going to be widely implemented, and the folks that do will probably get it wrong and break other stuff. Unsuspecting users will see "suspend/resume" and assume that they have Yet Another option they have to buy to get a function that already works today. There are enough buggy PPP implementions that crawl out of the woodwork from time to time, that we needn't make the protocol even more difficult to implement and unreliable for a feature which already works today. Just my personal opinion, of course. Louis A. Mamakos louie@uunet.uu.net UUNET Technologies, Inc. uunet!louie 3110 Fairview Park Dr., Suite 570 Voice +1 703 204 8023 Falls Church, Va 22042 Fax +1 703 204 8001 - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 09:35:41 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id JAA21787 for ; Fri, 10 Jun 1994 09:35:36 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id JAA08674; Fri, 10 Jun 1994 09:35:35 -0400 Date: Fri, 10 Jun 1994 09:35:35 -0400 From: Patrick Klos Message-Id: <199406101335.JAA08674@mv.mv.com> To: ietf-ppp@merit.edu, vjs@rhyolite.wpd.sgi.com Subject: Re: suspend/resume; virtual connections (fwd) >I do not see the difference between what IPX is said above to need >and what my uses of IP requires, but that I achieve without any >such PPP pause/resume facility. My link would be useless if I had >not arranged for sufficient RIP packets to be advertised even >while the PPP link is "paused". I'm sure your code is perfect; you keep telling us how well it works! The fact is, others would like to support demand-dialing as well, and there is no standard definition of how it should be done. Everyone can guess, but PPP is great because of it's interoperability! Instead of contantly telling us what's so bad or useless about suspend/resume, maybe you should write up a proposal for demand-dialing and how it should be implemented?? People are looking for standard ways of doing things. Why not make your demand-dialing algorithms a standard so we can all interoperate?? >How is that different from what IP needs? How is it that IP demand >dialed implementaitons work without puase/resume? The needs of IPX are not that much different from the needs of IP. But we don't have a definition of how to support an idle link! Apparently, you knew all along that some "connection state" information needed to be saved when a link went IDLE. You just have your own way of defining and identifying what IDLE means. Just because you have your own flavor of suspend/resume and it works, doesn't mean others shouldn't strive for a standard definition! >How can "the user to indicate when they're DONE" when the user >is not using, and is not permitted to indicate anything to either >PPP peer? What about my personal, real-life example of having >a workstation act as a router? The "DONE" indication is possible >only in the restricted case of a DOS (not NT or UNIX) box that has >no other network connections. As I'm sure you are aware, the DOS case is becoming less and less "the restricted case" (as you put it). More and more people are using DOS and Windows as their PPP platforms, and I'm sure that number will continue to grow. Even so, there's enough benefit for those DOS folks that would justify such considerations! UNIX (and NT) are NOT the only REAL PPP users! Besides, for all practical reasons, DONE means any connection that closes without the negotiation of a SUSPEND function. A link is only IDLE once a SUSPEND has been requested and acknowledged. If the phone gets disconnected or the machine gets turned off, the connection should be assumed DONE. >Right now, as I type this, I am about >1200 miles from my computers. >I have logged into my home computer over a series of wide area, >LAN and PPP links. How and why would I indicate to anything that >I'm done? The only machine you'd need (or want) to indicate if you're DONE or IDLE to would be the machine you're directly connected to (on the other end of the phone line; routing your packets onto the Internet). That's the connection that (could) cost money, so that's the connection that would be suspended during IDLE time. >Even in your DOS scheme, neither your customers nor the INternet >Service Provider would want a "DONE" indication. Consdier some >typical scenarios: Remember, DONE is assumed; IDLE (SUSPENDED) must be negotiated! > 1. DOS user logs in via demand-dialed PPP, does stuff, powers off > machine (i.e. "DONE" is missed) DONE is assumed; disconnect due to power off results in DONE. > 2. DOS user logs in via demand-dialed PPP, does stuff, DOS hangs, > user reboots, logs in again, and expects to go on, at > iwth old IP address if nothing eelse DONE is assumed; disconnect due to reboot results in DONE. > 3. DOS user logs in via demand-dialed PPP, does stuff, says > "DONE", shuts down, and 5-minutes later decides to > log in again Nothing wrong or questionable here. Humans are in control of when they want to log in again. >The DONE indication is inevitiably missing or wrong in those scenarios. >In all cases the Internet Service Provider will have retained >the address assignment for the same duration regardless of >whether the user said "DONE". NO! The Internet Service Provider need NOT have retained the address assignement for the client (unless they're using YOUR demand-dial, in which case the client *might* call back [within a predetermined period of time]). Only if the Internet Service Provider had received a SUSPEND request, and had acknowledged it, should they retain the address assignment for some time. >> ... >> PPP is an extensible protocol for a reason. It has the ability to grow as >> it finds itself in more and more implementations and uses. I don't think >> it has to "bend". > >Bloat is as bad as bending. The biggest complaint people have with >PPP is that it is too big and complicated. THey say SLIP is far >better because it is simpler. (Read comp.protocols.ppp) PPP is not that big or complicated! Some end users have problems understanding PPP, sure! That's why it's up to us engineers to write the code to make it work right. Why are we adding CCP? Why are we adding LCP extensions? Why is there an option that says how much time you have left on a connection?? That's not BLOAT?? The only thing BLOATED around here are all these unnecessary postings debating how good your demand-dial implementation is and how useless adding suspend and resume would be!! >> You keep going back to IP and how it could or could not benefit from >> something like suspend/resume. There are several other protocols that >> are using PPP more and more, and some of these protocols could benefit >> from extensions to PPP. Just because IP doesn't benefit from something >> doesn't mean that something is useless!?! > >I keep going back to IP because it has been asserted that IP needs such >a facility. I have said that as far as I know, manybe IPX or Appletalk >need pause/resume, although so far, I do not see why. It has been asserted that IP could benefit from such a facility. It's obvious that IP doesn't NEED such a facility - IP's working right now without it! And if you don't know that IPX, AppleTalk or some other protocol may need or benefit from this, then don't keep telling us how useless it is! >Please think of PPP as more than a dumb terminal emulation package >for PC's running DOS. I wish you'd realize that PPP on DOS is REAL! It's used for alot more than "dumb terminal emulation". I don't know where you get off telling people where they should and shouldn't use PPP anyway! >Vernon Schryver, vjs@sgi.com Vern, Until this suspend/resume debate started, I had respected you and your comments in this and other groups. I sincerely hope you might open your mind to this idea just a bit to see that it has value. There's no need for bickering in a technical forum such as this, and I'd like to think we can get past this. Sincerely, Patrick - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 10:17:47 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id KAA25849 for ; Fri, 10 Jun 1994 10:17:46 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id KAA18463; Fri, 10 Jun 1994 10:17:41 -0400 Date: Fri, 10 Jun 1994 10:17:41 -0400 From: Patrick Klos Message-Id: <199406101417.KAA18463@mv.mv.com> To: brian@lloyd.com, ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections (fwd) >You know, this is actually the, "if a tree falls in the forest and there is >nobody around to hear it, does it make a sound," question. I spent a lot >of time thinking about this some years ago and finally came to the >following conclusion: it doesn't matter. I don't really care if the far >end is there or not; I just assume that it is. It does matter and I do care if the far end is still there! >For the purposes of my >routing and service advertising protocols I can connect and "learn" the >peer's environment. From then on I can safely assume that it hasn't >changed. The only time I really care is if I have actual traffic that has >to pass to/through the peer. At that time I become interested in the real >state of things at the peer's end. Assuming the other end is ther and hasn't changed is not always good! >Several things can occur: > >1. nothing has changed and all is well; Fine. >2. the peer is dead/catatonic and I use that info to clean up my routing >and service advertisements; It could take you a long time to determine that the peer is dead/catatonic. All that time, you're carrying around alot of useless baggage. You're also letting the rest of the network believe that certain routes or services are still alive when they are not! It wastes RAM remembering that stuff, and it's cleaner to be up to date. >3. things have changed and I need to relearn things and advertise new info. Fine. >So even if I am running IPX and am "spoofing" the SAP broadcasts and other >cruft, it doesn't matter what is happening at the other end unless someone >really needs to get there and then the probe will teach me what I need to >learn. I'd rather have a router that know when to spoof and when to let the rest of the network know something has gone away! Besides, this feature is not just to support the router; it's there to cleanly support a remote client's reconnection. Furthermore, we're still lacking a spec to help insure interoperability of demand-dialed implementations. >Bottom line: it doesn't matter. It DOES matter! And it certainly doesn't hurt to add an option you won't be forced to use, but others could clearly benefit from. >Brian Lloyd, President Lloyd Internetworking >brian@lloyd.com 3031 Alhambra Drive >(916) 676-1147 - voice Suite 102 >(916) 676-3442 - fax Cameron Park, CA 95682 Patrick - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 10:24:47 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA26728 for ; Fri, 10 Jun 1994 10:24:45 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for ietf-ppp@merit.edu id AA00546; Fri, 10 Jun 94 07:24:39 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA28631; Fri, 10 Jun 94 08:24:56 -0600 Date: Fri, 10 Jun 94 08:24:56 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406101424.AA28631@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections (fwd) > From: Patrick Klos > To: ietf-ppp@merit.edu, vjs > Subject: Re: suspend/resume; virtual connections (fwd) > > >That demand-dialing code that I keep going on about maintains more than > >one UNIX PPP "network interface" alive per physical port, but I have no need > >for a PPP pause or resume facility. I fire up PPP state machinery > >when there is traffic. I do the obvious for IP number negotiation. > > Vern, > > I'm glad you have no need for a PPP pause or resume facility. You seem to > miss the point! There are other protocols that could benefit from them. > Even IP (it has been suggested) could benefit from them. If you don't > need them, DON'T USE THEM! As others have pointed out, it would be > advantageous if there were a standard way to handle demand-dialing, and > this mechanism would help. > > Why are you so against this??? I've pointed out several of the positive > aspects of suspend/resume. If you want to help, maybe you can share with > us what's so negative about having these features?? You DON'T have to > implement them if you don't want to! So how does it hurt?!? The PPP world > has nothing to lose by defining something like "suspend/resume". And some > parts of the PPP world may benefit! So, where's the harm?!? > > Patrick If only 10% of all PPP implementations would implement pause/resume, then no implementaton could rely upon it. All implemenations that want to be fast would have to use that burst technique, and so would not need pause/resume, and so no one would implement it, and so the LCP standard would be forever burdened with yet another extra wart. People who push for vanity features don't realize that they do win lasting fame, but of the wrong kind, that people grumble forever that "X added this feature Y to this standard." Simply saying that pause/resume would be fast is not enough. You must show that pause/resume is necessarily faster than alternatives. Do you understand my point about sending all of the PPP LCP and NCP packets in a burst? Would that be any slower than pause/resume? No one has shown any reason why IP needs a PPP pause/resume facility. As I have written, perhaps other protocols need such a facility, but so far, all arguments for those other protocols have been based on ignorance (I'm sorry, but that's the right word) of how PPP is and can be implemented and used. Please don't be offended when I repeat one of my favorite slogans. "Anyone can always find a feature to add to anything, but it takes hardwork, a thick skin, experience, skill, and perhaps even talent to leave the right things out." Only in bad committees do features get added because they might be useful. Good designs, even committee designs do not have unnecessary features. Good design practices require that any feature that only "might be used" be immediately and permanently be removed from consideration. Simply saying that someone might use pause/resume is not enough. You must show that someone would be complelled to use it for techical reasons. Over the years, in more than one committee I've seen people push for what I call "vanity features." These are features that exist because one or a few people wanted them, but that are not and will not be used. PPP already has plenty of them. I call them "vanity features" because the reasons people push them are the same as the reasons people publish books through that part of the publishing industry known as the "vanity press" and the reasons people get what I call "vanity (software) patents." Vanity features are not harmless. Absolutely every "extra" feature costs development time, test time, money, bugs, CPU time, and space. Even implmentations that do not implement pause/resume must be prepared to ignore them. Good implementations that do not have pause/resume will still have to decode them in order to log them in order to help users know what's going on, why their other box is not pausing or resuming. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 10:22:45 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id KAA26540 for ; Fri, 10 Jun 1994 10:22:44 -0400 Received: by mv (8.6.9/mem-931109) id JAA15874; Fri, 10 Jun 1994 09:59:19 -0400 Date: Fri, 10 Jun 1994 09:59:19 -0400 From: Patrick Klos Message-Id: <199406101359.JAA15874@mv> To: bsimpson@morningstar.com, ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections (fwd) >> From: Patrick Klos >> Again, with the IPX example, if the peer was DONE, we could release the IPX >> network number assigned. We would also know that no "NCP Watchdog" spoofing >> was necessary. If the peer was just IDLE, then the information saved in the >> connection state (described above) could be used to maintain the apperance >> of a connection until some REAL traffic had to cross the link again. >> >> How about a REAL, NON-TOY implementation, where the definition of DONE is >> "I'm unloading the PPP driver in DOS now; I'm DONE!", and the definition >> of IDLE is "I'm in Windows or DOS, I'm logged into a file server, but I >> haven't tried to access the file server for a while [maybe I went to >> lunch]; I'm IDLE". There are a lot of remote access users (ask Shiva) >> who would like to start thier DOS machine, log in, and go into Windows, >> never to have to come out again just to log out and disconnect the phone >> line. I think these users could benefit GREATLY from on-demand dialing. >> >Looking at your example, it would seem to me to be a bad IPXCP >implementation. RFC-1552 clearly states that, by default, there is >no network number assigned to a link that is not between two routers. By default, there is no network number assigned. That's why we negotiate one! How else is a node on a local LAN supposed to address the node (or nodes) on the PPP port! I guess EVERYONE with IPXCP has a BAD IMPLEMENTATION! I don't even know what you're trying to say here! >As to demand dialing, there is no reason why the link cannot do a soft >drop until more traffic is ready (on either end). The IPXCP should >continue to spoof, since it should be unaware of the soft drop. > >Soft drop works just fine in MacPPP. A "soft drop"?? Could you tell me what RFC defines a "soft drop"?? I rest my case! There is NONE! That's what we're trying to define. Why all the opposition?!? >The other problem you state (getting out of Windows to unload a driver) >is a problem with Windows, not a problem with PPP. Did we not solve SLIP's problem of only supporting IP by coming up with something new called PPP?? When PAP was not deemed secure enough, did someone come up with CHAP? So are you saying we shouldn't enchance PPP to make it work better in more environments?? Besides, no one is saying there is a "problem with PPP". We just want to enhance it! If you think it's as good as it needs to be, then we don't need "ietf-ppp@merit.edu" anymore! >> I think it's easier for the user to indicate when they're DONE, and the >> software to define what IDLE means. That's all detail, anyway. Without >> a suspend/resume capability, it doesn't matter. With a suspend/resume >> capability, at least there may be a standard definition of how to address >> DONE and IDLE once they're defined. >> >Look, I don't understand the problem. Why aren't you sending >Terminate-Requests to indicate you are "DONE"? That's how it is already >defined! That is how DONE would work! Only IDLE would be handled differently. Is that so hard to figure out?? >Bill.Simpson@um.cc.umich.edu Patrick - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 10:59:04 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id KAA29323 for ; Fri, 10 Jun 1994 10:59:02 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id KAA25801; Fri, 10 Jun 1994 10:58:41 -0400 Date: Fri, 10 Jun 1994 10:58:41 -0400 From: Patrick Klos Message-Id: <199406101458.KAA25801@mv.mv.com> To: klos@mv.MV.COM, louie@alter.net Subject: Re: suspend/resume; virtual connections (fwd) Cc: ietf-ppp@merit.edu, vjs@rhyolite.wpd.sgi.com >Don't we already have a standard way to do dial-on-demand? If there is a standard, I want to know what RFC it's in?? >Simply put, the "harm" is that there is unneccary complexity in a >protocol (PPP) which some would argue is a few orders of magnitude too >complex already. How necessary is the "Time-Remaining" LCP option?? Personally, I appreciate the (relatively) clean design of PPP and do not find it that complex. >we needn't make the protocol even more difficult to >implement and unreliable for a feature which already works today. Optional features are not REQUIRED to be implemented. And who says this feature affects reliability at all? >Just my personal opinion, of course. > >Louis A. Mamakos louie@uunet.uu.net >UUNET Technologies, Inc. uunet!louie >3110 Fairview Park Dr., Suite 570 Voice +1 703 204 8023 >Falls Church, Va 22042 Fax +1 703 204 8001 Patrick - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 11:26:49 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id LAA01925 for ; Fri, 10 Jun 1994 11:26:48 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id LAA29632; Fri, 10 Jun 1994 11:26:45 -0400 Date: Fri, 10 Jun 1994 11:26:45 -0400 From: Patrick Klos Message-Id: <199406101526.LAA29632@mv.mv.com> To: klos@mv.MV.COM, louie@alter.net Subject: Re: suspend/resume; virtual connections (fwd) Cc: ietf-ppp@merit.edu, vjs@rhyolite.wpd.sgi.com Guys, This is not just an IP thing. Other protocols can benefit from this also. You keep saying how this is not necessary, that demand-dialing implementations (all independant) solve all the issues. Great, so hangups keep the connection state for a little while anyway. Noone says suspend/resume can't do that too! Have you guys all standardized on demand-dialing so you all are interoperable?? Patrick - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 11:06:56 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA00285 for ; Fri, 10 Jun 1994 11:06:54 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for ietf-ppp@merit.edu id AA03823; Fri, 10 Jun 94 08:06:44 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA28802; Fri, 10 Jun 94 09:06:58 -0600 Date: Fri, 10 Jun 94 09:06:58 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406101506.AA28802@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections (fwd) > From: Patrick Klos > To: ietf-ppp@merit.edu, vjs > Subject: Re: suspend/resume; virtual connections (fwd) > > >I do not see the difference between what IPX is said above to need > >and what my uses of IP requires, but that I achieve without any > >such PPP pause/resume facility. My link would be useless if I had > >not arranged for sufficient RIP packets to be advertised even > >while the PPP link is "paused". > > I'm sure your code is perfect; you keep telling us how well it works! The > fact is, others would like to support demand-dialing as well, and there is > no standard definition of how it should be done. Everyone can guess, but > PPP is great because of it's interoperability! Instead of contantly > telling us what's so bad or useless about suspend/resume, maybe you should > write up a proposal for demand-dialing and how it should be implemented?? > People are looking for standard ways of doing things. Why not make your > demand-dialing algorithms a standard so we can all interoperate?? My code is not perfect. However, the fact that it works fine wihtout pause/resume shows pause/resueme is unnecessary and therefor bad for IP. Other people have demand-dialed PPP code that also works. I think some of the public domain versions do it. I think some of the public domain SLIP code does it. If you must have a public standard, then you're welcome to my 'man page', but I think you'd be better off reading MorningStar's. MorningStar does things a little differently than I do, but MorningStar's code works on (seemingly) everything and is the de facto standard of comparison. > >How is that different from what IP needs? How is it that IP demand > >dialed implementaitons work without puase/resume? > > The needs of IPX are not that much different from the needs of IP. But we > don't have a definition of how to support an idle link! Apparently, you > knew all along that some "connection state" information needed to be saved > when a link went IDLE. You just have your own way of defining and identifying > what IDLE means. Just because you have your own flavor of suspend/resume > and it works, doesn't mean others shouldn't strive for a standard definition! Ok. But you didn't answer my question. HOw is what IPX needs different from what IP needs? What is your definition of an idle link? How is your defintion of idle different from that used by the many current implementations of demand-dialed PPP? Your definition may be much better. Please describe it. It can't be "the user said DONE or pause" because there are too many cases where the user cannot talk to either end of the PPP link. > >How can "the user to indicate when they're DONE" when the user > >is not using, and is not permitted to indicate anything to either > >PPP peer? What about my personal, real-life example of having > >a workstation act as a router? The "DONE" indication is possible > >only in the restricted case of a DOS (not NT or UNIX) box that has > >no other network connections. > > As I'm sure you are aware, the DOS case is becoming less and less "the > restricted case" (as you put it). More and more people are using DOS > and Windows as their PPP platforms, and I'm sure that number will continue > to grow. Even so, there's enough benefit for those DOS folks that would > justify such considerations! UNIX (and NT) are NOT the only REAL PPP > users! Besides, for all practical reasons, DONE means any connection > that closes without the negotiation of a SUSPEND function. A link is > only IDLE once a SUSPEND has been requested and acknowledged. If the > phone gets disconnected or the machine gets turned off, the connection > should be assumed DONE. Are you aware of the Terminate-Request LCP packets? > >Right now, as I type this, I am about >1200 miles from my computers. > >I have logged into my home computer over a series of wide area, > >LAN and PPP links. How and why would I indicate to anything that > >I'm done? > > The only machine you'd need (or want) to indicate if you're DONE or IDLE > to would be the machine you're directly connected to (on the other end > of the phone line; routing your packets onto the Internet). That's the > connection that (could) cost money, so that's the connection that would > be suspended during IDLE time. That makes no makes no sense. I'm typing this at a keyboard on a machine connected to an Ethernet connected to an FDDI ring connected to an Ethernet and so on to a FR link to an Ethernet to a PPP router (actually a workstation with my code) and on the other side of that last phone line is my home machine. I'm rlogin'ed to it. When I finish with the morning's SGI mail, I'll rlogin to another machine on my home Ethernet and deal with personal stuff. From here in Calif. to which machine in Colo would I say "DONE" and how would I say it? Why would I say it? > >Even in your DOS scheme, neither your customers nor the INternet > >Service Provider would want a "DONE" indication. Consdier some > >typical scenarios: > > Remember, DONE is assumed; IDLE (SUSPENDED) must be negotiated! > > > 1. DOS user logs in via demand-dialed PPP, does stuff, powers off > > machine (i.e. "DONE" is missed) > > DONE is assumed; disconnect due to power off results in DONE. > > > 2. DOS user logs in via demand-dialed PPP, does stuff, DOS hangs, > > user reboots, logs in again, and expects to go on, at > > iwth old IP address if nothing eelse > > DONE is assumed; disconnect due to reboot results in DONE. > > > 3. DOS user logs in via demand-dialed PPP, does stuff, says > > "DONE", shuts down, and 5-minutes later decides to > > log in again > > Nothing wrong or questionable here. Humans are in control of when they > want to log in again. > > >The DONE indication is inevitiably missing or wrong in those scenarios. > >In all cases the Internet Service Provider will have retained > >the address assignment for the same duration regardless of > >whether the user said "DONE". > > NO! The Internet Service Provider need NOT have retained the address > assignement for the client (unless they're using YOUR demand-dial, in > which case the client *might* call back [within a predetermined period > of time]). Only if the Internet Service Provider had received a SUSPEND > request, and had acknowledged it, should they retain the address > assignment for some time. What about case 4 4. Telephone guy pulls the plug. That happens, even with ISDN. It seems you would have the Internet Service Provider release the IP address when that happens. Wouldn't most DOS users quickly find other Internet Service Providers who don't release their IP address on transient disconnections? So that when their good PPP code redials their modem without dropping their FTP or Mosaic session, they can continue with no worse than a hiccup? Instead of having to restart from scractch? I rely on not having a phone hiccup kill my TCP connections with an inferred "DONE". I occassionally move 100MByte pre-compressed files over a v.32bis link. It takes literally days, and the telco frequently zaps the line, but my `rcp` command keeps chugging along. (alpha copies release CDROMs) Instead, when you cool down, I bet you'll decide that the hub must assume "pause" except when it gets a terminate request preceded by a "DONE" request. That doesn't work either, but it's harder to see. > It has been asserted that IP could benefit from such a facility. It's obvious > that IP doesn't NEED such a facility - IP's working right now without it! > And if you don't know that IPX, AppleTalk or some other protocol may need > or benefit from this, then don't keep telling us how useless it is! I have never said pause/resume is useless for IPX or Appletalk, but I do say it is useless for IP and that someone must provide concrete reasons why it is required for IPX or AppleTalk. Please recall that I'm the person in this thread to first wrote "maybe IPX or Appletalk need it." > >Please think of PPP as more than a dumb terminal emulation package > >for PC's running DOS. > > I wish you'd realize that PPP on DOS is REAL! It's used for alot more than > "dumb terminal emulation". I don't know where you get off telling people > where they should and shouldn't use PPP anyway! I have never written that people should not use PPP. I believe PPP on DOS is real. That does not imply pause/resume is needed. > Until this suspend/resume debate started, I had respected you and your > comments in this and other groups. I sincerely hope you might open your > mind to this idea just a bit to see that it has value. There's no need > for bickering in a technical forum such as this, and I'd like to think > we can get past this. So you consider my perisitant technical questions bickering? Ok. I still would like to know what technical problem pause/resume solves. You say IP does not need it. Ok. How do IPX or Appletalk need it? What state do they have that IP does not? Do not baldly assert that state exists. Please describe it. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 11:43:32 1994 Received: from pluto.eecs.uic.edu (pluto.eecs.uic.edu [128.248.167.30]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id LAA03503 for ; Fri, 10 Jun 1994 11:43:31 -0400 Received: from bert.eecs.uic.edu (bert.eecs.uic.edu [128.248.167.23]) by pluto.eecs.uic.edu (8.6.4/8.6.4) with ESMTP id KAA04504 for ; Fri, 10 Jun 1994 10:40:54 -0500 Received: from mana.eecs.uic.edu (mana.eecs.uic.edu [128.248.247.200]) by bert.eecs.uic.edu (8.6.5/8.6.5) with SMTP id KAA02233 for ; Fri, 10 Jun 1994 10:44:11 -0500 Received: from advance.eecs.uic.edu by mana.eecs.uic.edu (4.1/SMI-4.1) id AA06967; Fri, 10 Jun 94 10:43:24 CDT Date: Fri, 10 Jun 94 10:43:24 CDT From: rorem@mana.eecs.uic.edu (Doug Rorem) Message-Id: <9406101543.AA06967@mana.eecs.uic.edu> To: ietf-ppp@merit.edu Subject: Re: suspend/resume >> National ISDN connections in the UK take ~ 1 sec. >> International connections can take 3 - 10 seconds. >> >> How long does your PPP negotiation to bring an ISDN link up take ? I don't know about ISDN, but on a 57.6k serial (direct link, not through a modem) we can be up in *well* under a second ... on an optimally configured system, we can be up in about 2/ or 3/10ths I believe. -- Brad Wilson | Internet: wilson@ftp.com | #include FTP Software, Inc. | Voice: +1 800 282 4387 | #include 2 High Street | Facsimile: +1 508 659 6297 | #include N. Andover, MA 01845 | Support: support@ftp.com | msg++; smiley++; ********************** Why would you tear down a connection on a dedicated 57.6 K line? Tearing down an ISDN (or analog modem) connection is done because of cost savings. For these cases, one incurs call setup times which are longer than .2 to .3 seconds. Doug Rorem University of Illinois at Chicago - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 11:39:33 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA03022 for ; Fri, 10 Jun 1994 11:39:32 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for ietf-ppp@merit.edu id AA07067; Fri, 10 Jun 94 08:39:24 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA28951; Fri, 10 Jun 94 09:39:36 -0600 Date: Fri, 10 Jun 94 09:39:36 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406101539.AA28951@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections (fwd) > From: Patrick Klos > > Guys, > > This is not just an IP thing. Other protocols can benefit from this also. Ok. Please say how. Explicitly. Including showning how other protocols differ from IP and so cannot use the obvious solution for IP. I consider it obvious because it was implemented so many times indpendently, and because it is obvious. You "invent" it simply by 1. doing the obvious when the link goes down unexpectedly (i.e. re-dialing) 2. then being lazy and redialing only when when there is traffic. 3. then knocking down the link if no traffic has been seen lately. > You keep saying how this is not necessary, that demand-dialing implementations > (all independant) solve all the issues. Great, so hangups keep the > connection state for a little while anyway. Noone says suspend/resume can't > do that too! Have you guys all standardized on demand-dialing so you all > are interoperable?? Yes. We are all interoperable (at least on this feature). Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 10:47:27 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id KAA28569 for ; Fri, 10 Jun 1994 10:47:26 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id KAA22998; Fri, 10 Jun 1994 10:47:24 -0400 Date: Fri, 10 Jun 1994 10:47:24 -0400 From: Patrick Klos Message-Id: <199406101447.KAA22998@mv.mv.com> To: ietf-ppp@merit.edu, karl@morningstar.com Subject: Re: suspend/resume; virtual connections (fwd) >> I second Karl Fox's suggestion that there should be PPP support for >> implementations to provide a dial on demand link layer, which fools >> the upper layers into thinking it has a permanent connection and >> does not have to concern itself with the transient state of the >> link. > >I did not suggest that there should be such support; there already is >such support. There is?!? Where is it defined?? What RFC? >If no packets are traversing a PPP link for a long enough time that a >PPP implementation's idle timers shut the link down, then NO PACKETS >ARE TRAVERSING THE LINK. If no packets are traversing the link, then >the upper layers are not doing anything. If the upper layers are >idle, then you can't make them `more idle' or somehow better informed >by telling them that the lower layers are down. In routers, the upper layers (IP and IPX are upper layers to PPP) are always busy making sure thier routing information is up to date. By telling them the lower layer is down (with a REASON), they can either spoof as necessary, or invalidate some of thier routing entries. >The beauty of a demand-dialed link layer is that no communication is >necessary at all with the upper layers. If it's transparent to the >upper layers, then you can't somehow make it more transparent by >making it more complex. See above. >As Vernon Schryver pointed out, you might not even be able to talk to >the upper layers at all. In the vast majority of PPP installations, >at least one of the ends of the upper layer sessions is not in the >same place as either of the ends of the PPP link, so no communication >is even possible. The suspend/resume capability would only be concerned with the two PPP peers. >I have heard only one argument as to why it might be desirable to >inform the upper layers that a session had, in fact, `ended' -- and >that is so that existing TCP sessions could be shut down. However, >the only way to determine from the link layer that a PPP session is >`ended' as opposed to `paused' or `temporarily idle' is by watching >the TCP sessions and shutting down when they are all closed! Not if we define this suspend/resume capability. I've spelled this out several times already in other postings. >So, the >only time this could be useful is exactly when it can't! Huh? >If, after reading this frothing diatribe, you still see a need for >`suspend/resume', then please help me understand why by answering >these questions: > > 1) How would suspend/resume differ from standard PPP startup/shutdown? To shutdown a connection (DONE), send a Terminate Request, wait for Terminate Ack. To suspend a connection (IDLE), send a Suspend Request, wait for a Suspend Ack or Suspend Nak. If Suspend Nak, keep the link up. If Suspend Ack, shut down link, but keep NCPs up (by some as yet undefined mechanism) and wait for the link to come up and a Resume to be requested. > 2) When would each (suspend/resume versus startup/shutdown) be used? Shutdown (DONE) would be the default (loss of phone line, reboot, other misc loss of connection. Suspend (IDLE) would be used when a peer decides the link is IDLE long enough, but doesn't want to relinquish the resources allocated to it. > 3) What `state' would suspend/resume record between PPP sessions? IPX Network Number assigned to the connection. IP Address assigned to the connection. Spoofing requirements. Etc. >I apologize for the ferocity and verbose nature of this message. I'm >frustrated by the broad base of acceptance of this suggested feature >and by the lack of technical reasons for that support. I don't see any "broad base of acceptance"; just the contrary! I see a broad base of negative remarks without any credible reasons why this would NOT be useful! I've given plenty of technical reasons why it would be a good thing. Why does everyone seem to implement "demand dialing" support if they feel this capability is useless?!? This is the same thing! We just want a spec so we can all interoperate. Patrick - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 12:01:06 1994 Received: from netcom.com (netcom4.netcom.com [192.100.81.107]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id MAA04958 for ; Fri, 10 Jun 1994 12:01:05 -0400 Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom) id JAA16307; Fri, 10 Jun 1994 09:01:18 -0700 Date: Fri, 10 Jun 1994 09:01:18 -0700 From: thenrion@netcom.com (Tim Henrion) Message-Id: <199406101601.JAA16307@netcom.com> To: vjs@rhyolite.wpd.sgi.com Subject: Re: suspend/resume; virtual connections Cc: ietf-ppp@merit.edu > > > From: thenrion@netcom.com (Tim Henrion) > > > ... > > > Fine, but you haven't answered the questions "what connnection state"? > > > > > > > The "connection state" is the state of all currently negotiated NCP > > options so that no renegotiation has to take place when the link resumes. > > The idea is to be able to resume the connection is as little time as > > possible. When the line is brought up, the originator should be able to > > tell the other side that he is resuming a suspended connection (by > > passing some type of identifier) and re-authenticating himself. > > The connection should then resume in the OPEN state with all NCP > > options being set to what they were when the connection suspended. > > How long would it take to exchange those authenticating identifiers? > How much faster would it be than just exchanging NCP configure-requests > and Acks? The second time around, an NCP negotiation should involve > absolutely no rejects or Naks. You should be able to send a single > burst consisting of your LCP configure reuest followed by your NCP > requests. You would receive the same for the other side. You would > respond with a burst consisting of configure-Acks. > > Given a line at least as fast as a v.32bis modem, how would > anything involving pause/resume be faster? > > As far as I can see, pause/resume might recquire fewer bytes, but > it would take just as long to restore the connection. > > > > > No, it would not be nice. > > > > Oh, yes it would. For PPP implementations that run as standard > > point-to-point links there is not much point. Keep in mind, however, > > that not all PPP implementations will be serial lines running over > > modems which interface to protocol stacks as point-to-point devices. > > LAN emulators running PPP over digital phone lines would benefit > > greatly from the ability to suspend/resume PPP connections on > > the fly. In these situations, it's actually a necessity. > > What PPP implementations are not "point-to-point links"? > > I don't see any different between "LAN emulators" and > any other PPP application. Could you enlighten me? > LAN Emulation was a bad example for me to use for justifying PPP suspend/resume because it is a proprietary and patented technology. I withdraw my argument on that basis but still believe that the ability to "suspend" and "resume" connections, specifically on digital media which support such operations (ISDN) is benefitial in making PPP attractive as a sophisticated point-to-point link level protocol. Whether Patrick and I can convince you of that is another matter, however. > > > > My demand-dialing code doesn't care why the link went down, whether the > > > peer decided the line was idle or if some other, higher priority stuff > > > needed the port, or the phone guy was messing around. > > > > > > When the line goes down, I just switch to the wait-for-traffic-after- > > > hysterisis-and-restart mode. > > > > > > I can't see what you would do differently depending on why the line > > > went down. > > > > What about routing? If you're on a connection which the other guy drops > > unexpectedly, wouldn't that cause you to mark your interface as down > > and have the routing layer invalidate all the routes through you? > > No. If I did that, then I could not use this PPP likn that I'm using > at this very instant. > > As far as the upper layers (starting with IP) are concerned, my > PPP links stay up all of the time. The fact that sometimes > the PPP stuff is turned off and not just the PPP state but a lot > more (SV STREAMS) state is gone is hidden from IP. > So then what you're saying is that you're implementing your *own* form of suspend/resume, just above the link layer. I believe that Patrick and I are stating that we'd like that standard functionality to be built into the link layer itself so that implementations may interoperate at this level. > > The idea is to not inform the upper layers that the connection has > > gone away so that routes will not get invalidated. In order to do > > this, you *need* to know why the connection was terminated and > > that it could be resumed at any time as necessary. > > That is not true. Again, if that were true, then I could not > use this PPP link. > > > > ... > > You're assuming that a "resume" is a long operation, presumably > > because you're in the async world. In digital telephony, this is > > not the case. The reason for saving connection state and avoiding > > renegotiation of all of the NCPs make resuming even faster. > > How am I assuming such a thing? If I am (I don't think I am), how > is it relevant? > > My code also runs over ISDN. Is that included in what you mean > by "digital telephony"? > > > It's irrelevant to system administrators whether you're really "DONE" > > or not, anyway. You're allocating a network media that has a $$ cost > > associated with it and you're not using it. Network administrators > > should be able to specify that if you do that for longer than a > > configurable period of time, the connection should be dropped > > to save toll charges and resumed when you're actually using it again. > > We agree about that. My PPP code (like MorningStar's and everyone > else's demand dialing code) has knobs for controlling how much idle > time under various circumstance causes the PPP link(s) (BF&I multilink) > to be dropped. > That's fine. If everyone's doing "demand dialing" what's the argument against putting a standard suspend/resume facility in PPP? Tim Henrion Principal Software Engineer Extension Technology Corporation 30 Hollis Street Framingham, MA 01701 Phone: (508) 872-7748 FAX: (509) 872-7533 Internet: thenrion@netcom.com - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 10:41:08 1994 Received: from rodan.UU.NET (389@rodan.UU.NET [153.39.128.10]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA28355 for ; Fri, 10 Jun 1994 10:41:07 -0400 Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA08459; Fri, 10 Jun 94 10:40:58 -0400 Message-Id: <9406101440.AA08459@rodan.UU.NET> To: Patrick Klos Cc: ietf-ppp@merit.edu, vjs@rhyolite.wpd.sgi.com From: "Louis A. Mamakos" Subject: Re: suspend/resume; virtual connections (fwd) In-Reply-To: Your message of "Fri, 10 Jun 1994 09:35:35 EDT." <199406101335.JAA08674@mv.mv.com> Date: Fri, 10 Jun 1994 10:40:56 -0400 Sender: louie@uunet.uu.net > I'm sure your code is perfect; you keep telling us how well it works! The > fact is, others would like to support demand-dialing as well, and there is > no standard definition of how it should be done. Everyone can guess, but > PPP is great because of it's interoperability! Instead of contantly > telling us what's so bad or useless about suspend/resume, maybe you should > write up a proposal for demand-dialing and how it should be implemented?? > People are looking for standard ways of doing things. Why not make your > demand-dialing algorithms a standard so we can all interoperate?? I don't think that it's been necessary to "write up a spec" on demand-dialing. When you decide that you need to establish the link (which is completely determined by local policy), you do the usual PPP link establishment procedure after establishing the physical link (which is another completely local issue). When you decide that you no longer "need" the link (which is completely determined by local policy), you can do the normal PPP protocol thing to turn off the various link protocols, and then you tear down the physical link (which is another completely local issue). What part of this process do we standardize? > The needs of IPX are not that much different from the needs of IP. But we > don't have a definition of how to support an idle link! Apparently, you > knew all along that some "connection state" information needed to be saved > when a link went IDLE. You just have your own way of defining and identifying > what IDLE means. Just because you have your own flavor of suspend/resume > and it works, doesn't mean others shouldn't strive for a standard definition! > As I'm sure you are aware, the DOS case is becoming less and less "the > restricted case" (as you put it). More and more people are using DOS > and Windows as their PPP platforms, and I'm sure that number will continue > to grow. Even so, there's enough benefit for those DOS folks that would > justify such considerations! UNIX (and NT) are NOT the only REAL PPP > users! Besides, for all practical reasons, DONE means any connection > that closes without the negotiation of a SUSPEND function. A link is > only IDLE once a SUSPEND has been requested and acknowledged. If the > phone gets disconnected or the machine gets turned off, the connection > should be assumed DONE. So if a link fails because the modem lost its connection, its just too bad for the user? We do better than this today; the link just demand-dials back again (e.g., when the next packet needs to be transmitted on the link). Some software is even more aggressive, and just restablishes the link should it drop without waiting for more traffic. My customers have become accustomed to this sort of thing. Since we have already made this work, what's the need for an explicit SUSPEND/RESUME? > >Right now, as I type this, I am about >1200 miles from my computers. > >I have logged into my home computer over a series of wide area, > >LAN and PPP links. How and why would I indicate to anything that > >I'm done? > > The only machine you'd need (or want) to indicate if you're DONE or IDLE > to would be the machine you're directly connected to (on the other end > of the phone line; routing your packets onto the Internet). That's the > connection that (could) cost money, so that's the connection that would > be suspended during IDLE time. But you miss the point. The machine he's logged into at the *other* end is also a demand-dialed link. Both ends could cost money. > >The DONE indication is inevitiably missing or wrong in those scenarios. > >In all cases the Internet Service Provider will have retained > >the address assignment for the same duration regardless of > >whether the user said "DONE". > > NO! The Internet Service Provider need NOT have retained the address > assignement for the client (unless they're using YOUR demand-dial, in > which case the client *might* call back [within a predetermined period > of time]). Perhaps you should be using a different Internet Service Provider :-) The existing PPP spec does not demand that you lose this way. > Only if the Internet Service Provider had received a SUSPEND > request, and had acknowledged it, should they retain the address > assignment for some time. Why exactly do you belive this? Consider the case where customers have dedicated IP addresses; suspend/resume is not necessary. Consider the case where (as someone suggested) addressed are assigned LRU. A robust and featureful PPP product would reassign the same address to the user when he dialed back after the link was dropped, either due to a physical link failure or the link going idle. This problem has been solved already. > >> PPP is an extensible protocol for a reason. It has the ability to grow as > >> it finds itself in more and more implementations and uses. I don't think > >> it has to "bend". > > > >Bloat is as bad as bending. The biggest complaint people have with > >PPP is that it is too big and complicated. THey say SLIP is far > >better because it is simpler. (Read comp.protocols.ppp) > > PPP is not that big or complicated! Some end users have problems understanding > PPP, sure! That's why it's up to us engineers to write the code to make it > work right. Why are we adding CCP? Why are we adding LCP extensions? Why is > there an option that says how much time you have left on a connection?? That's > not BLOAT?? The only thing BLOATED around here are all these unnecessary > postings debating how good your demand-dial implementation is and how useless > adding suspend and resume would be!! Compare PPP to SLIP before you make claims like that. I personally use a demand-dialed SLIP connection to my machine at home, with *NO* fancy negotiations at all, and it works just fine. Code and protocol bloat is a very, very real problem. If you add an option for anyone, you end up with the OSI stack, with two differnet network layer protocols and 5 differnt transport protocols. Options to PPP are added for a variety of reasons, some good and some bad; mostly because there is no other way to do it within the existing framework of the protocol. The sort of problem that SUSPEND/RESUME is supposed to solve seems to already be working today. > I wish you'd realize that PPP on DOS is REAL! It's used for alot more than > "dumb terminal emulation". I don't know where you get off telling people > where they should and shouldn't use PPP anyway! Is there any reason why demand-dialed PPP isn't possible on DOS platforms without SUSPEND/RESUME? Vernon's point (as I read it) was that basing your arguments extending a protocol to specifically support some OS specific issue isn't a good way to go. A protcool extension should be useful in an non-OS-specific way. > Until this suspend/resume debate started, I had respected you and your > comments in this and other groups. I sincerely hope you might open your > mind to this idea just a bit to see that it has value. There's no need > for bickering in a technical forum such as this, and I'd like to think > we can get past this. I don't percieve bickering going on; only disagreement over the issue. Just as you don't find Vernon's arguments compelling, I don't find your convicing me of the utility of SUSPEND/RESUME either. We're not bickering, we disagreeing. Louis A. Mamakos louie@alter.net Member of Technical Staff UUNET Technologies, Inc. uunet!louie 3110 Fairview Park Drive., Suite 570 Voice: +1 703 204 8023 Falls Church, Va 22042 Fax: +1 703 204 8001 - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 10:52:44 1994 Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA29130 for ; Fri, 10 Jun 1994 10:52:44 -0400 Received: by ftp.com ; Fri, 10 Jun 1994 10:49:36 -0400 Received: by ftp.com ; Fri, 10 Jun 1994 10:49:36 -0400 From: wilson@ftp.com (Brad Wilson) Message-Id: <9406101449.AA03101@ftp.com> Subject: Re: suspend/resume; virtual connections To: gerry@spider.co.uk (Gerry Meyer) Date: Fri, 10 Jun 1994 10:49:36 -0400 (EDT) Cc: thenrion@netcom.com, ietf-ppp@merit.edu In-Reply-To: <2759.9406100844@orbweb.spider.co.uk> from "Gerry Meyer" at Jun 10, 94 09:44:42 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 853 >> National ISDN connections in the UK take ~ 1 sec. >> International connections can take 3 - 10 seconds. >> >> How long does your PPP negotiation to bring an ISDN link up take ? I don't know about ISDN, but on a 57.6k serial (direct link, not through a modem) we can be up in *well* under a second ... on an optimally configured system, we can be up in about 2/ or 3/10ths I believe. -- Brad Wilson | Internet: wilson@ftp.com | #include FTP Software, Inc. | Voice: +1 800 282 4387 | #include 2 High Street | Facsimile: +1 508 659 6297 | #include N. Andover, MA 01845 | Support: support@ftp.com | msg++; smiley++; "If friends impose on you to babysit, it is within your rights to convert the child to a new religion." -- Dogbert, "Clues for the Clueless" - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 12:19:06 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id MAA06094 for ; Fri, 10 Jun 1994 12:19:05 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id MAA08280; Fri, 10 Jun 1994 12:19:03 -0400 Date: Fri, 10 Jun 1994 12:19:03 -0400 From: Patrick Klos Message-Id: <199406101619.MAA08280@mv.mv.com> To: jhalpern@mako.Newbridge.COM, klos@mv.MV.COM Subject: Re: suspend/resume; virtual connections (fwd) Cc: ietf-ppp@merit.edu >The key question for me is what the advantage of defining the packet would >be. It seems that all of the necessary behaviors have to occur even if >the packet is not sent/received. Hence, it seems to not be worth it. >I do not think that anyone doubts that being able to quickly restart a >previous connection is valuable. The debate is about whether we need >a new packet to help. We may need to write down the possible/desired >behaviors, even if no new packet is needed. This has nothing to do with speed. Someone got off on a speed tangent; that's not the issue. The issue is in gaining some knowledge about whether or not the peer is DONE (we can release thier resources) or they just want to disconnect the phone line temporarily (keep thier assignments; spoof if necessary). >Joel M. Halpern jhalpern@newbridge.com >Newbridge Networks Inc. - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 12:38:54 1994 Received: from ftp.com (ftp.com [128.127.2.122]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA07966 for ; Fri, 10 Jun 1994 12:38:54 -0400 Received: by ftp.com ; Fri, 10 Jun 1994 12:38:50 -0400 Received: by ftp.com ; Fri, 10 Jun 1994 12:38:50 -0400 From: wilson@ftp.com (Brad Wilson) Message-Id: <9406101638.AA08648@ftp.com> Subject: Re: suspend/resume To: rorem@mana.eecs.uic.edu (Doug Rorem) Date: Fri, 10 Jun 1994 12:38:50 -0400 (EDT) Cc: ietf-ppp@merit.edu In-Reply-To: <9406101543.AA06967@mana.eecs.uic.edu> from "Doug Rorem" at Jun 10, 94 10:43:24 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 498 >> >> How long does your PPP negotiation to bring an ISDN link up take ? >> Why would you tear down a connection on a dedicated 57.6 K line? Tearing >> down an ISDN (or analog modem) connection is done because of cost savings. >> For these cases, one incurs call setup times which are longer than .2 to .3 >> seconds. I presumed he wanted negotiation times here, since he asked about how long negotiation takes. I gave him negotiation times for my closest approximate to a B channel ISDN. Brad - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 12:54:09 1994 Received: from feta.cisco.com (feta.cisco.com [192.31.7.22]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id MAA09266 for ; Fri, 10 Jun 1994 12:54:08 -0400 Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id JAA25767; Fri, 10 Jun 1994 09:52:14 -0700 Date: Fri, 10 Jun 1994 09:52:14 -0700 From: Dave Katz Message-Id: <199406101652.JAA25767@feta.cisco.com> To: gerry@spider.co.uk Cc: thenrion@netcom.com, ietf-ppp@merit.edu In-Reply-To: Gerry Meyer's message of Fri, 10 Jun 94 09:44:42 +0100 <2759.9406100844@orbweb.spider.co.uk> Subject: suspend/resume; virtual connections Another random data point--ISDN bringup from my house in Santa Cruz CA to Mountain View CA (about 40 miles as the highway flies, intra-LATA) takes between 5 and 10 seconds due to the lack of SS7 signalling in PacBell's internal network; it turns into DTMF-signalled switched-56K service between the end switches. From: Gerry Meyer Date: Fri, 10 Jun 94 09:44:42 +0100 >It enables "resume" capability with minimal delay. Granted this >isn't very useful in the async modem world because reconnect times >are *significantly* longer than re-nogotiation times. This is >not necessarily true for digital telephony (ISDN). National ISDN connections in the UK take ~ 1 sec. International connections can take 3 - 10 seconds. How long does your PPP negotiation to bring an ISDN link up take ? Gerry - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 12:50:42 1994 Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA09141 for ; Fri, 10 Jun 1994 12:50:42 -0400 Received: by ftp.com ; Fri, 10 Jun 1994 12:47:22 -0400 Received: by ftp.com ; Fri, 10 Jun 1994 12:47:22 -0400 From: wilson@ftp.com (Brad Wilson) Message-Id: <9406101647.AA09041@ftp.com> Subject: Re: suspend/resume; virtual connections To: thenrion@netcom.com (Tim Henrion) Date: Fri, 10 Jun 1994 12:47:22 -0400 (EDT) Cc: vjs@rhyolite.wpd.sgi.com, ietf-ppp@merit.edu In-Reply-To: <199406101601.JAA16307@netcom.com> from "Tim Henrion" at Jun 10, 94 09:01:18 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1530 >> So then what you're saying is that you're implementing your *own* >> form of suspend/resume, just above the link layer. I believe that >> Patrick and I are stating that we'd like that standard functionality >> to be built into the link layer itself so that implementations may >> interoperate at this level. There's no harm in documenting the process in an RFC, but what's being done is not a part of the PPP protocol, it's a part of his PPP imple- mentation. He makes *NO* changes to the protocol to do what you call "suspend/resume". If you want him to document it, I'm sure he will... but there's no need to have an LCP option to do the work ... in fact, I would argue that such an options make assumptions that could never be disproved (eg, "prove I'll call back"). It adds complexity to the protocol without adding functionality that could otherwise be had outside the protocol. I'm quite certain that vjs's implementation is much cleaner than an LCP option would be, and makes less dangerous assumptions. >> That's fine. If everyone's doing "demand dialing" what's >> the argument against putting a standard suspend/resume facility >> in PPP? It is not required. It is marginally beneficial at best. -- Brad Wilson | Internet: wilson@ftp.com | #include FTP Software, Inc. | Voice: +1 800 282 4387 | #include 2 High Street | Facsimile: +1 508 659 6297 | #include N. Andover, MA 01845 | Support: support@ftp.com | msg++; smiley++; - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 13:11:24 1994 Received: from gordius.gordian.com (gordius.gordian.com [192.73.220.81]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id NAA10891 for ; Fri, 10 Jun 1994 13:11:22 -0400 Received: from hermes (hermes.gordian.com [192.73.220.111]) by gordius.gordian.com (8.6.5/8.6.5) with SMTP id KAA13166 for <@gordius.gordian.com:ietf-ppp@merit.edu>; Fri, 10 Jun 1994 10:10:49 -0700 Received: by hermes (920330.SGI/920502.SGI) for @gordius.gordian.com:ietf-ppp@merit.edu id AA10627; Fri, 10 Jun 94 10:10:47 -0700 Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.hermes.sgi.4d via MS.5.6.hermes.sgi_4d; Fri, 10 Jun 1994 10:10:47 -0700 (PDT) Message-Id: <0hy9uL30GRlj8Z85UE@hermes> Date: Fri, 10 Jun 1994 10:10:47 -0700 (PDT) From: Jay Laefer To: ietf-ppp@merit.edu Subject: suspend/resume; an idea I doubt this suspend/resume argument is going to go anywhere until and unless someone makes a concrete proposal. After reading the posts to this list, I remain unconvinced that there can be any real savings by implementing suspend/resume. I need to see something I can critique before I can support it. Would someone who supports this idea please put forth something a bit more tangible before this conversation degenerates any further? The bickering is mildly entertaining, but it's not productive. -Jay Laefer jay@gordian.com - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 13:02:35 1994 Received: from netcom14.netcom.com (netcom14.netcom.com [192.100.81.126]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id NAA10204 for ; Fri, 10 Jun 1994 13:02:34 -0400 Received: by netcom14.netcom.com (8.6.8.1/Netcom) id KAA15436; Fri, 10 Jun 1994 10:02:43 -0700 Date: Fri, 10 Jun 1994 10:02:43 -0700 From: thenrion@netcom.com (Tim Henrion) Message-Id: <199406101702.KAA15436@netcom14.netcom.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections > > > I'm glad you have no need for a PPP pause or resume facility. You seem to > > miss the point! There are other protocols that could benefit from them. > > Even IP (it has been suggested) could benefit from them. If you don't > > need them, DON'T USE THEM! As others have pointed out, it would be > > advantageous if there were a standard way to handle demand-dialing, and > > this mechanism would help. > > Don't we already have a standard way to do dial-on-demand? I seem to > see it working just fine with all of our dial-up PPP customers. Many > of us are arguing that its not NECESSARY to have another mechanism > when there are existing mechanisms which seem to work just fine. Are > the existing mechanism optimal for *every* situation - of course not. > O the other hand they work in a wide variety of environments very > well. > Sure you have "dial-on-demand" for UNIX machines over async lines. Funny though, because supposedly "everyone" has this but "everyone" has to go through the hassle of implementing it above the link layer. What's wrong with putting this *simple* functionality into PPP. If you don't like it, REJect it. One of the *important* points that putting this into the spec makes is that it brings the concept of suspend/resume into the standards limelight (so everyone knows about it). It will also allow suspend/resume implementations to interoperate. Right now if I write a PPP implementation which runs against one of the "demand-dial" implementations, how do I know that? Vernon says that when the PPP line drops for whatever reason (other side disconnected, nuclear war, etc.), he doesn't invalidate routes through his interface for any reason. I don't agree with this and wouldn't write my implementation to do this. He takes suspend/resume functionality for granted because he and others implemented their own *non-standard* versions of it. Putting this functionality into the specification would allow me, as a peer, to determine exactly what he's doing/not doing and *interoperate* with him. > > Why are you so against this??? I've pointed out several of the positive > > aspects of suspend/resume. If you want to help, maybe you can share with > > us what's so negative about having these features?? You DON'T have to > > implement them if you don't want to! So how does it hurt?!? The PPP world > > has nothing to lose by defining something like "suspend/resume". And some > > parts of the PPP world may benefit! So, where's the harm?!? > > Vernon is attempting to maintain some sort of "purity" in the protocol > in the sense of not allowing to to grow unsightly hair in places which > would make PPP impossible to reasonably implement. > Suspend/resume would actually serve a useful purpose. A lot more useful than the recent "you only have 5 minutes left on this connection" LCPEXT message addition, which I consider "unsightly". If suspend/resume is "impossible to reasonably implement", REJect it. For a lot of people, callback is going to be "impossible to reasonably implement". They will REJect it. > Simply put, the "harm" is that there is unneccary complexity in a > protocol (PPP) which some would argue is a few orders of magnitude too > complex already. Heck, lets just throw the kitchen sink in there, and > add reliable transport of frames, negotiaion of accounting and billing > options and many other things that properly don't belong in a > link-level protocol specification. > Well, why don't we all go back to SLIP? Who needs frame CRC? Isn't that what we have error correcting modems for? Why does anyone need CCP? My V.42bis modem compresses just fine, thank you. Plus, CSLIP has TCP header compression just like PPP, so who needs PPP? Answer: PPP addresses the "deficiencies" in SLIP/CSLIP. Some of those corrections will correct current deficiencies. Others will take us into the 21st century. Tim Henrion Principal Software Engineer Extension Technology Corporation 30 Hollis Street Framingham, MA 01701 Phone: (508) 872-7748 FAX: (509) 872-7533 Internet: thenrion@netcom.com - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 13:01:47 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA10166 for ; Fri, 10 Jun 1994 13:01:45 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for ietf-ppp@merit.edu id AA17615; Fri, 10 Jun 94 10:01:40 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA29154; Fri, 10 Jun 94 11:01:48 -0600 Date: Fri, 10 Jun 94 11:01:48 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406101701.AA29154@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections > From: thenrion@netcom.com (Tim Henrion) > ... > > > What about routing? If you're on a connection which the other guy drops > > > unexpectedly, wouldn't that cause you to mark your interface as down > > > and have the routing layer invalidate all the routes through you? > > > > No. If I did that, then I could not use this PPP likn that I'm using > > at this very instant. > > > > As far as the upper layers (starting with IP) are concerned, my > > PPP links stay up all of the time. The fact that sometimes > > the PPP stuff is turned off and not just the PPP state but a lot > > more (SV STREAMS) state is gone is hidden from IP. > > > > So then what you're saying is that you're implementing your *own* > form of suspend/resume, just above the link layer. Close, but not quite. No special packets are exchanged. Each end of the link does its own thing. I happen to use "symmetric demand dialing", but as far as the two ends are concerned, each does it entirely independently. It's not only "just above the link layer" but also involves routing (RIP) packets to keep routing advertisments going even when they're not coming over the link. I take credit for none of the ideas, except for the contortions required to keep System V STREAMS around and to connect 1 or more links to the STREAMS mux. All of the rest is standard stuff using standard tools (e.g. `gated`) the same as everyone else does. > I believe that > Patrick and I are stating that we'd like that standard functionality > to be built into the link layer itself so that implementations may > interoperate at this level. Why is it desirable to do this kind of stuff in the link layer? You could, but given that PPP is (mostly) an unreliable link, why would you? > That's fine. If everyone's doing "demand dialing" what's > the argument against putting a standard suspend/resume facility > in PPP? "why not add" a feature is absolutely always an inadmissable argument. YOU MUST ABSOLUTELY ALWAYS OMIT POSITIVELY EVERY FEATURE WITHOUT A COMPELLING REQUIREMENT. The fact that at least for IP and as far as most of us can tell, the current PPP mechanisms support demand dialing is why pause/resume should not be added. YOU ONLY ADD THAT WHICH YOU ABSOLUTELY REQUIRE FOR COMPELLING TECHNICAL OR BUSINESS REASONS. PPP is already bloated beyone belief. E.g. - link quality is rarely used and of at best limited utilty. - magic numbers are not really useful for detecting loop backs because that's not a common failure mechanism. - the "time remaining" facility has already been mentioned. - why 2 different authentication mechanisms? - self-describing-padding is rarely if at all used and the wrong way to handle the problem (i.e. more bits than alternatives) That PPP is morbidly obese does not mean it should go on a binge, that a few more unnecessray features won't hurt. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 13:50:14 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id NAA14178 for ; Fri, 10 Jun 1994 13:50:09 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id NAA23538; Fri, 10 Jun 1994 13:50:07 -0400 Date: Fri, 10 Jun 1994 13:50:07 -0400 From: Patrick Klos Message-Id: <199406101750.NAA23538@mv.mv.com> To: ietf-ppp@merit.edu, vjs@rhyolite.wpd.sgi.com Subject: Re: suspend/resume; virtual connections (fwd) >> From: Patrick Klos >> >> Guys, >> >> This is not just an IP thing. Other protocols can benefit from this also. > >Ok. Please say how. Explicitly. Including showning how other >protocols differ from IP and so cannot use the obvious solution for IP. IPX is the protocol I can make the best case for. Assume router R supports IPX Routing, including dial-in support. Whenever a remote client C dials in, the router assigned the client a unique IPX Network number. The router starts advertising that the route exists to the rest of the IPX internetwork. Client C logs into a file server through the router. The file server will attempt to verify the continued existance of client C by sending it "watchdog" packets if the file server hasn't heard from the client for 5 minutes. The workstation responds appropriately and the connection is maintained. Because phone charges are being incurred, the system administrator desires that after (for example) 15 minutes of inactivity (not counting watchdog, RIP or SAP packets), the phone should be hung up, and then reconnected when activity picks up again. In order for the router to know that the client still wants to dial back and pick up where he left off, the client needs to inform the router that it's only suspending, and would like the router to act on it's behalf to answer any watchdog packets sent by the file server(s) [spoofing]. In this case, the router would also need to continue advertising the route to the client as well. If the client did not want to "maintain" it's connection, the router would not have to spoof for the client, and the router could release the IPX Network Number assigned to the client for use by another dial-in client should the need arise. It appears that some form of indicator from the client to the router would assist the router in realizing the client's intent upon phone line disconnect. Perhaps ther are several modes a connection might be in: 1) Connected 2) Terminated (DONE) 3) Disconnected via IDLE 4) Disconnected via loss of phone line Mode 2 would be the default when unloading the driver (in DOS). Mode 3 would occur when the inactivity timeout period for the link expired. Mode 4 would occur when the phone line unexpectedly dropped. Mode 2 means release any resources assigned to the connection. Mode 3 means keep all necessary resources to maintain the appearence of a connection (except the phone line). To prevent waste of resources, some long timeout period may be assigned to the connection state in case remote client never calls back. Some way to determine if the remote client is calling back (but starting from scratch) might be desirable also, allowing the router to either reuse or release the original connection resources. The timeout period for mode 3 might be on the order of 1 or more days. Mode 4 could be similar to mode 3, but with a much shorter timeout. Since the router doesn't know why the disconnect occurred, it may try to maintain the connection state for a short while, hoping the client reconnects soon. This is quite like current demand-dial implementations. The timeout period for mode 4 might be on the order of minutes. Patrick - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 13:41:09 1994 Received: from netcom14.netcom.com (netcom14.netcom.com [192.100.81.126]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id NAA13548 for ; Fri, 10 Jun 1994 13:41:08 -0400 Received: by netcom14.netcom.com (8.6.8.1/Netcom) id KAA20583; Fri, 10 Jun 1994 10:41:22 -0700 Date: Fri, 10 Jun 1994 10:41:22 -0700 From: thenrion@netcom.com (Tim Henrion) Message-Id: <199406101741.KAA20583@netcom14.netcom.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections > > If only 10% of all PPP implementations would implement pause/resume, > then no implementaton could rely upon it. All implemenations that want > to be fast would have to use that burst technique, and so would not > need pause/resume, and so no one would implement it, and so the LCP > standard would be forever burdened with yet another extra wart. People > who push for vanity features don't realize that they do win lasting > fame, but of the wrong kind, that people grumble forever that "X added > this feature Y to this standard." > So tell me, are you saying that we should shut up or we'll look stupid and forever burn in the Internet Hell of Infamy? Just because *you* think something is a "vanity feature"? Gimme' a break... > Simply saying that pause/resume would be fast is not enough. You must > show that pause/resume is necessarily faster than alternatives. Do you > understand my point about sending all of the PPP LCP and NCP packets in > a burst? Would that be any slower than pause/resume? > What about *INTEROPERABILITY*? Right now if I want to write a PPP implementation that interoperates with yours (or Morningstar's) "demand-dial" implementation, I have no idea how to do it. You have essentially implemented "demand-dial" as a nonstandard extension of the link layer. At the link layer, when I determine that a media is no longer available, I should inform the upper layers (routing, specifically) that the media is unavailable. The routing layer would theoretically mark any routes pointing to the down media as invalid. Your "demand-dial" implementation wouldn't invalidate these routes because you are implementing a non-standard extension of the link layer. How do I *know* that that's what your doing, assuming that I want my implementation to work exactly like yours so that my customers don't complain "why do you drop the routes, Vernon doesn't"? Suspend/resume *enables interoperability* between potentially inoperable implementations by defining a new physical/logical state for a link which is benefitial to the upper layers. I know that when you "suspend" a link, the phone line went down but you want me to keep the logical connection alive because you may "resume" at any time, so I won't trash any routes pointing across the link. Keep in mind that *either* side can resume a suspended link so I can actually "resume" a link that you "suspended" if I have data to go over it. > No one has shown any reason why IP needs a PPP pause/resume facility. > As I have written, perhaps other protocols need such a facility, but so > far, all arguments for those other protocols have been based on > ignorance (I'm sorry, but that's the right word) of how PPP is and can > be implemented and used. > See above. > Please don't be offended when I repeat one of my favorite slogans. > "Anyone can always find a feature to add to anything, but it takes > hardwork, a thick skin, experience, skill, and perhaps even talent to > leave the right things out." I *am* offended because you are again subtly calling us stupid because we would like to see a standard link layer extension implemented for something that you do in a non-standard way. > > Simply saying that someone might use pause/resume is not enough. You > must show that someone would be complelled to use it for techical reasons. > See above. > Over the years, in more than one committee I've seen people push for > what I call "vanity features." These are features that exist because > one or a few people wanted them, but that are not and will not be > used. PPP already has plenty of them. I call them "vanity features" > because the reasons people push them are the same as the reasons people > publish books through that part of the publishing industry known as the > "vanity press" and the reasons people get what I call "vanity > (software) patents." > O.K., lets go back to CSLIP, add multiprotocol and CRC support, call it PPP and not let anyone extend it until the end of time. Sound good? Or are there some "non-vanity" features that *you* would like to add? Tim Henrion Principal Software Engineer Extension Technology Corporation 30 Hollis Street Framingham, MA 01701 Phone: (508) 872-7748 FAX: (509) 872-7533 Internet: thenrion@netcom.com - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 13:40:53 1994 Received: from netcom14.netcom.com (netcom14.netcom.com [192.100.81.126]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id NAA13535 for ; Fri, 10 Jun 1994 13:40:52 -0400 Received: by netcom14.netcom.com (8.6.8.1/Netcom) id KAA20540; Fri, 10 Jun 1994 10:41:04 -0700 Date: Fri, 10 Jun 1994 10:41:04 -0700 From: thenrion@netcom.com (Tim Henrion) Message-Id: <199406101741.KAA20540@netcom14.netcom.com> To: wilson@ftp.com Subject: Re: suspend/resume; virtual connections Cc: ietf-ppp@merit.edu > > >> So then what you're saying is that you're implementing your *own* > >> form of suspend/resume, just above the link layer. I believe that > >> Patrick and I are stating that we'd like that standard functionality > >> to be built into the link layer itself so that implementations may > >> interoperate at this level. > > There's no harm in documenting the process in an RFC, but what's being > done is not a part of the PPP protocol, it's a part of his PPP imple- > mentation. He makes *NO* changes to the protocol to do what you call > "suspend/resume". If you want him to document it, I'm sure he will... > but there's no need to have an LCP option to do the work ... in fact, > I would argue that such an options make assumptions that could never > be disproved (eg, "prove I'll call back"). > I disagree. Like it or not, what he's performing is the equivalent of a link level extension right above the link layer. Aparently other people are implementing it also. What we have is a de-facto standard for a non-standard link level extension. Not only is this inappropriate in a well architected system, it makes interoperability difficult. PPP is being touted as an "interoperability standard" for point-to-point links. Any link-level extensions not designed into the link layer make interoperability that much more difficult and hurt the end goals of PPP itself. There is no reason to have the peer "prove it will call back". The peer is telling you that it is disconnecting and might call back, please save your connection state and don't inform the upper layers (IP/IPX/etc.) that the link down. If I call back, please resume the connection as it was. This may also be merged with the callback functionality to enable the peer who did not initiate the suspend to resume the connection also. > It adds complexity to the protocol without adding functionality that > could otherwise be had outside the protocol. I'm quite certain that > vjs's implementation is much cleaner than an LCP option would be, and > makes less dangerous assumptions. > It is putting link level functionality at the link layer, where it belongs. I believe quite the contrary that an LCP implementation would be "cleaner" than Vernon's implementation. Just exactly what assumptions are being made that are "dangerous"? > >> That's fine. If everyone's doing "demand dialing" what's > >> the argument against putting a standard suspend/resume facility > >> in PPP? > > It is not required. It is marginally beneficial at best. > That is your opinion. I, and others, do not share it. Interoperability among differing "demand-dial" implementations is significantly more than "marginally beneficial". Tim Henrion Principal Software Engineer Extension Technology Corporation 30 Hollis Street Framingham, MA 01701 Phone: (508) 872-7748 FAX: (509) 872-7533 Internet: thenrion@netcom.com - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 14:01:54 1994 Received: from ftp.com (ftp.com [128.127.2.122]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA15573 for ; Fri, 10 Jun 1994 14:01:53 -0400 Received: by ftp.com ; Fri, 10 Jun 1994 13:59:23 -0400 Received: by ftp.com ; Fri, 10 Jun 1994 13:59:23 -0400 From: wilson@ftp.com (Brad Wilson) Message-Id: <9406101759.AA13326@ftp.com> Subject: What exactly *is* the need for suspend/resume? To: thenrion@netcom.com (Tim Henrion) Date: Fri, 10 Jun 1994 13:59:23 -0400 (EDT) Cc: wilson@ftp.com, ietf-ppp@merit.edu In-Reply-To: <199406101741.KAA20540@netcom14.netcom.com> from "Tim Henrion" at Jun 10, 94 10:41:04 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2430 >> I disagree. Like it or not, what he's performing is the equivalent >> of a link level extension right above the link layer. Define "link level extension". >> Not only is this inappropriate in a well architected system, it makes >> interoperability difficult. Show one system that he is not interoparable with because he has implemented dial on demand. >> Any link-level extensions not designed into the link layer >> make interoperability that much more difficult and hurt the >> end goals of PPP itself. He is not violating the spec, nor the spirit of the spec. He takes the line down when he doesn't need to use it anymore. In case you forgot, it *is* legal to take the line down. When he reestablishes the connection, things work fine. There are solutions that don't require an LCP option to work. If you are going to ignore these solutions, I cannot stop you. As of yet, you have not given a single, concrete reason that this is necessary (nor has anyone else). Some people suggest that is would be nice, some people suggest that it "fits better with ISDN", but nobody (that I have read yet) has said why, if their implementation doesn't get it, the world ends. In short, is there a reason, *other* than "it would be nice"? >> There is no reason to have the peer "prove it will call back". >> The peer is telling you that it is disconnecting and might call >> back, please save your connection state and don't inform the upper >> layers (IP/IPX/etc.) that the link down. If I call back, please >> resume the connection as it was. This can be done with a little planning on the part of the implementor. In the case of IP addresses, the LRU handout with request algorithm works just fine, and covers any reasonable case. Of course, I would attempt to address any other problems, had any been presented yet. >> That is your opinion. I, and others, do not share it. Interoperability >> among differing "demand-dial" implementations is significantly >> more than "marginally beneficial". When you prove that the current dial on demand sacrifices interoperability then I will accept this argument. -- Brad Wilson | Internet: wilson@ftp.com | #include FTP Software, Inc. | Voice: +1 800 282 4387 | #include 2 High Street | Facsimile: +1 508 659 6297 | #include N. Andover, MA 01845 | Support: support@ftp.com | msg++; smiley++; - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 14:07:06 1994 Received: from lloyd.com (harry.lloyd.com [158.222.1.6]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA15827 for ; Fri, 10 Jun 1994 14:07:03 -0400 Received: from [158.222.1.3] by lloyd.com with smtp (Smail3.1.28.1 #3) id m0qCAyk-00075AC; Fri, 10 Jun 94 11:06 PDT Message-Id: Date: Fri, 10 Jun 94 11:06 PDT X-Sender: brian@harry.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Patrick Klos From: brian@lloyd.com (Brian Lloyd) Subject: Re: suspend/resume; virtual connections (fwd) Cc: ietf-ppp@merit.edu >>2. the peer is dead/catatonic and I use that info to clean up my routing >>and service advertisements; > >It could take you a long time to determine that the peer is dead/catatonic. >All that time, you're carrying around alot of useless baggage. You're also >letting the rest of the network believe that certain routes or services are >still alive when they are not! It wastes RAM remembering that stuff, and it's >cleaner to be up to date. I guess we disagree. There are those who would say that Bellman-Ford routing algorithms like RIP, that constantly broadcast information, is a bigger waste of resources than keeping around some stale information in tables. >>So even if I am running IPX and am "spoofing" the SAP broadcasts and other >>cruft, it doesn't matter what is happening at the other end unless someone >>really needs to get there and then the probe will teach me what I need to >>learn. > >I'd rather have a router that know when to spoof and when to let the rest >of the network know something has gone away! Besides, this feature is not >just to support the router; it's there to cleanly support a remote client's >reconnection. Furthermore, we're still lacking a spec to help insure >interoperability of demand-dialed implementations. What many people seem to forget is that it often costs much more to deal with some unlikely and usually unimportant special case than it does to accept some suboptimal special-case behavior. If timely propagation of this information is critical, perhaps you need to be runing a fully-connected network. My admonition to you is to prove that you absolutely cannot make the simpler case work. Many of us have been pushing bits around the Internet for a long time and, frankly, the simplest case is usually adequate even if suboptimal. Let's look at it another way: does it matter that a client discover that a resource is unavailable at the time that the resource is requested? I hold that it does not. Consider that, even on a LAN, a resource could fail and a client could request that resource before the client discovered that the resouce was gone. Since whatever application you want to run, be it IP or IPX based, must deal with this case, delaying the propagation of said information does not break anything. Heck, you may get lucky and the resource could go away and come back. In that case the clients are none the wiser and everybody is still happy. >>Bottom line: it doesn't matter. > >It DOES matter! And it certainly doesn't hurt to add an option you won't >be forced to use, but others could clearly benefit from. I hope you won't be offended if I remain unconvinced by your argument. PPP has suffered from a severe case of "creeping featurism" for much of its life. I hope that you will forgive me and others who have lived with this for 6 years when we are reluctant to add YAO (Yet Another Option) when the option is arguably not required. Again, if you can show me that you cannot make things work without the option, I will be happy to support a new option. My experience leads me to believe that this option really isn't needed. Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 14:15:16 1994 Received: from rodan.UU.NET (389@rodan.UU.NET [153.39.128.10]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA16749 for ; Fri, 10 Jun 1994 14:15:15 -0400 Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA24653; Fri, 10 Jun 94 14:14:22 -0400 Message-Id: <9406101814.AA24653@rodan.UU.NET> To: Patrick Klos Cc: ietf-ppp@merit.edu, vjs@rhyolite.wpd.sgi.com From: "Louis A. Mamakos" Subject: Re: suspend/resume; virtual connections (fwd) In-Reply-To: Your message of "Fri, 10 Jun 1994 13:50:07 EDT." <199406101750.NAA23538@mv.mv.com> Date: Fri, 10 Jun 1994 14:14:21 -0400 Sender: louie@uunet.uu.net > IPX is the protocol I can make the best case for. Assume router R supports > IPX Routing, including dial-in support. Whenever a remote client C dials in, > the router assigned the client a unique IPX Network number. The router > starts advertising that the route exists to the rest of the IPX internetwork. > In order for the router to know that the client still wants to dial back and > pick up where he left off, the client needs to inform the router that it's > only suspending, and would like the router to act on it's behalf to answer > any watchdog packets sent by the file server(s) [spoofing]. In this case, > the router would also need to continue advertising the route to the client > as well. How about if the client, rather than indicating that it is suspending, instead indicates that it is done. There are already facilities in PPP to "gracefully" close the link. > It appears that some form of indicator from the client to the router would > assist the router in realizing the client's intent upon phone line disconnect. > Perhaps ther are several modes a connection might be in: > > 1) Connected Presumably we all know how to handle this state :-) > 2) Terminated (DONE) This can be entered by having the client close the link when it has finished its "session". > 3) Disconnected via IDLE > 4) Disconnected via loss of phone line I *think* that the issue at hand is how to distinguish between these two states, if at all. I believe that in both of these states there is some time interval involved after which you abandon the "session". > Mode 3 means keep all necessary resources to maintain the appearence > of a connection (except the phone line). To prevent waste of resources, > some long timeout period may be assigned to the connection state in case > remote client never calls back. Some way to determine if the remote client > is calling back (but starting from scratch) might be desirable also, allowing > the router to either reuse or release the original connection resources. > The timeout period for mode 3 might be on the order of 1 or more days. > > Mode 4 could be similar to mode 3, but with a much shorter timeout. Since > the router doesn't know why the disconnect occurred, it may try to maintain > the connection state for a short while, hoping the client reconnects soon. > This is quite like current demand-dial implementations. The timeout period > for mode 4 might be on the order of minutes. So, to continue the discussion, is it possible to somehow handle these as the same two states? Or in a similar sort of way? If not, let me suggest an approach, though it is from some ignorance of how the IPXCP works: First, we consider the case where the line drops due to a telco problem as just an abrupt failure of the physical link, likely detected by a hardware means (DCD is gone) or lack of link quality or PPP echos. To indicate that the link is going to drop, but that the IPX "state" as it were, is to be maintained how about this: close the LCP, but don't close the IPXCP, and then drop the physical link. As I said, I am somewhat ignorant of IPX over PPP, so I don't know if this can't possibly work or not. But it may be a way to signal your "intent" without adding any other machinary to the protocol. Louis A. Mamakos louie@alter.net Member of Technical Staff UUNET Technologies, Inc. uunet!louie 3110 Fairview Park Drive., Suite 570 Voice: +1 703 204 8023 Falls Church, Va 22042 Fax: +1 703 204 8001 - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 14:29:56 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id OAA17781 for ; Fri, 10 Jun 1994 14:29:54 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id OAA29637; Fri, 10 Jun 1994 14:29:53 -0400 Date: Fri, 10 Jun 1994 14:29:53 -0400 From: Patrick Klos Message-Id: <199406101829.OAA29637@mv.mv.com> To: klos@mv.MV.COM, louie@alter.net Subject: Re: suspend/resume; virtual connections (fwd) Cc: ietf-ppp@merit.edu, vjs@rhyolite.wpd.sgi.com >So, to continue the discussion, is it possible to somehow handle these as the >same two states? Or in a similar sort of way? > >If not, let me suggest an approach, though it is from some ignorance >of how the IPXCP works: > >First, we consider the case where the line drops due to a telco >problem as just an abrupt failure of the physical link, likely >detected by a hardware means (DCD is gone) or lack of link quality or >PPP echos. > >To indicate that the link is going to drop, but that the IPX "state" >as it were, is to be maintained how about this: close the LCP, but >don't close the IPXCP, and then drop the physical link. Again, the only item not addressed is determining the difference between a line drop from IDLE (which would be called a SUSPEND) and from a phone problem. Whereas a "phone problem" would constitute a shorter timeout period for the connection state, thus expecting a quick reconnect, the IDLE would imply that the remote machine is (at the moment) still there and healthy. It may be IDLE for a day (or more) but still there and ready. It would be nice to be able to determine the difference betwen the two. >As I said, I am somewhat ignorant of IPX over PPP, so I don't know if >this can't possibly work or not. But it may be a way to signal your >"intent" without adding any other machinary to the protocol. > >Louis A. Mamakos louie@alter.net >Member of Technical Staff >UUNET Technologies, Inc. uunet!louie >3110 Fairview Park Drive., Suite 570 Voice: +1 703 204 8023 >Falls Church, Va 22042 Fax: +1 703 204 8001 I wish someone else who has a possible use for this would describe thier situation to see how it may be different from the picture I'm drawing. (you know who you are :-) Patrick - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 14:39:17 1994 Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA18713 for ; Fri, 10 Jun 1994 14:39:10 -0400 Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (5.65a/94040804) id AA28707; Fri, 10 Jun 94 14:38:38 -0400 From: Karl Fox Received: by gefilte.MorningStar.Com (5.65a/94012401) id AA02998; Thu, 9 Jun 94 16:07:18 -0400 Date: Thu, 9 Jun 94 16:07:18 -0400 Message-Id: <9406092007.AA02998@gefilte.MorningStar.Com> To: Allen Rochkind/HQ/3Com Cc: ietf-ppp Subject: Re: suspend/resume; virtual connections (fwd) In-Reply-To: <9406091940.AA7000@notes.dev.3com.com> References: <9406091940.AA7000@notes.dev.3com.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Allen Rochkind/HQ/3Com writes: > However, I was wondering whether you made the assumption that the > NCPs that you had previously negotiated will stay up when you > transparently disconnect the LCP after the line idles. I don't understand what you mean by `transparently'. I have always interpreted RFC 1548 to require NCPs to be renegotiated each time. I don't consider it ambiguous, and we have never encountered an interoperability problem that would be explained by an interpretation such as you describe. Page 8: 3.1 Overview In order to establish communications over a point-to-point link, each end of the PPP link MUST first send LCP packets to configure and test the data link. After the link has been established, the peer MAY be authenticated. Then, PPP MUST send NCP packets to choose and configure one or more network-layer protocols. Once each of the chosen network-layer protocols has been configured, datagrams from each network-layer protocol can be sent over the link. Page 10: 3.6 Network-Layer Protocol Phase Once PPP has finished the previous phases, each network-layer protocol (such as IP, IPX, or AppleTalk) MUST be separately configured by the appropriate Network Control Protocol (NCP). ... After a NCP has reached the Opened state, PPP will carry the corresponding network-layer protocol packets. Any network-layer protocol packets received when the corresponding NCP is not in the Opened state MUST be silently discarded. Page 10-11: 3.7 Link Termination Phase ... Implementation Note: The closing of the link by LCP is sufficient. There is no need for each NCP to send a flurry of Terminate packets. Conversely, the fact that one NCP has Closed is not sufficient reason to cause the termination of the PPP link, even if that NCP was the only NCP currently in the Opened state. Page 15: - Later, the peer is finished, and closes the link. A Terminate- Request arrives (RTR: tld,zrc,sta/Stopping, Termination phase). The This-Layer-Down action sends the Down event to any NCPs, while the Terminate-Ack is sent. The Zero-Restart-Counter action causes the link to wait for the peer to process the Terminate-Ack, with no retries. Page 18: Down ... It also can be used by LCP to signal each NCP that the link is leaving Network-Layer Protocol phase. That is, the This-Layer- Down action from LCP triggers the Down event in the NCP. Page 23-24: This-Layer-Down (tld) This action indicates to the upper layers that the automaton is leaving the Opened state. Typically, this action is used by the LCP to signal the Down event to a NCP, Authentication Protocol, or Link Quality Protocol, or MAY be used by a NCP to indicate that the link is no longer available for its network layer traffic. - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 14:39:09 1994 Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA18710 for ; Fri, 10 Jun 1994 14:39:07 -0400 Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (5.65a/94040804) id AA28697; Fri, 10 Jun 94 14:38:33 -0400 From: Karl Fox Received: by gefilte.MorningStar.Com (5.65a/94012401) id AA02682; Thu, 9 Jun 94 13:56:59 -0400 Date: Thu, 9 Jun 94 13:56:59 -0400 Message-Id: <9406091756.AA02682@gefilte.MorningStar.Com> To: thenrion@netcom.com (Tim Henrion) Cc: ietf-ppp@merit.edu, vjs@calcite.rhyolite.com Subject: Re: suspend/resume; virtual connections In-Reply-To: <199406091635.JAA09075@netcom.com> References: <199406091635.JAA09075@netcom.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Tim Henrion writes: > The "connection state" is the state of all currently negotiated NCP > options so that no renegotiation has to take place when the link resumes. > The idea is to be able to resume the connection is as little time as > possible. When the line is brought up, the originator should be able to > tell the other side that he is resuming a suspended connection (by > passing some type of identifier) and re-authenticating himself. > The connection should then resume in the OPEN state with all NCP > options being set to what they were when the connection suspended. I assume that you would still authenticate, unless you are utterly unconcerned about security. Bill Simpson's suggestion of just rerunning CHAP periodically isn't secure, since someone could come in without authenticating and quickly do some severe damage before the CHAP timer came around. You'll also have to renegotiate LCP, since the `PC' may be coming in on a different line, perhaps one that uses XON/XOFF flow control (while the others use RTS/CTS) and therefore needs a different asyncmap. What have you saved? - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 14:47:07 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA19823 for ; Fri, 10 Jun 1994 14:47:06 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for ietf-ppp@merit.edu id AA03679; Fri, 10 Jun 94 11:47:01 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA29593; Fri, 10 Jun 94 12:47:01 -0600 Date: Fri, 10 Jun 94 12:47:01 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406101847.AA29593@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections (fwd) > From: Patrick Klos > From: "Louis A. Mamakos" The descripton of the IPX sounds very much like the problems with IP. As far as I can tell, the only differnces are: 1. there is no equivalent to static routing. Watchdogs are required. 2. the watchdogging and routing packets are handled by the lowest layers instead of separate daemons. Note that professional grade PPP IP implementations include mechanisms to optionally completely filter some IP packets (e.g. ICMP) and/or ignore them for the purposes of deciding the link is active (e.g. RIP or time protocols). > > 3) Disconnected via IDLE > > 4) Disconnected via loss of phone line > > I *think* that the issue at hand is how to distinguish between these two > states, if at all. I believe that in both of these states there is some > time interval involved after which you abandon the "session". > ... > First, we consider the case where the line drops due to a telco > problem as just an abrupt failure of the physical link, likely > detected by a hardware means (DCD is gone) or lack of link quality or > PPP echos. > > To indicate that the link is going to drop, but that the IPX "state" > as it were, is to be maintained how about this: close the LCP, but > don't close the IPXCP, and then drop the physical link. > > As I said, I am somewhat ignorant of IPX over PPP, so I don't know if > this can't possibly work or not. But it may be a way to signal your > "intent" without adding any other machinary to the protocol. Somewhere in the LCP RFC it says you do not need to send Terminate-Requests for each NCP when turning off. This means that common PPP implemenations even when demand-dialing IP send only an LCP Terminate-Request and no IPCP Terminate-Request when shutting down for any reason. I guess you could do something special for IPX, but why? As I see it, there is no reason to distinguish between cases #3 and #4. Instead, I would lump them together, and require that a peer that wants to maintain it's address or other state call back periodically, say once a day. With regard to this issue, I see nothing different between IP and IPX. The problems with IPX that I see are in spoofing and faking those RIP and other packets. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 15:41:29 1994 Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id PAA24521 for ; Fri, 10 Jun 1994 15:41:28 -0400 Received: from cixgate.3com.com by relay2.UU.NET with SMTP (rama) id QQwtso02829; Fri, 10 Jun 1994 15:41:26 -0400 Received: from gw.3Com.COM by cixgate.3com.com (4.1/SMI-4.1/3com-cixgate-GCA-931027-01) id AA11329; Fri, 10 Jun 94 12:43:02 PDT Received: from notes.DEV.3Com.COM by gw.3Com.COM with SMTP id AA20312 (5.65c/IDA-1.4.4 for ); Fri, 10 Jun 1994 12:41:24 -0700 Received: by notes.dev.3com.com (IBM OS/2 SENDMAIL VERSION 1.3.0)/1.0) id AA5844; Fri, 10 Jun 94 12:50:44 -0700 Message-Id: <9406101950.AA5844@notes.dev.3com.com> Received: from 3Com with "Lotus Notes Mail Gateway for SMTP" id C090ED3770CE6ADF8825606A00689285; Fri, 10 Jun 94 12:50:42 To: Karl Fox Cc: ietf-ppp From: Allen Rochkind/HQ/3Com Date: 10 Jun 94 12:40:01 PS Subject: Re: suspend/resume; virtual connections (fwd) X-Lotus-Type: RTALL Mime-Version: 1.0 Content-Type: Text/Plain Thank you, Karl, for your clarifications from the RFCs. By "transparently" I meant that the upper layers and their associated NCP sessions would not see the LCP connection going up and down. As far as the NCP is concerned the LCP never changed. By your contribution below, that is not what the current specs say. It appears that the current PPP RFCs say that the closing of the LCP implies that the NCPs running above it should also close their connections (although this should not work the other way around). If so that would mean if a dial on demand implementation closes its LCP when the physical line goes down on the idle condition, all of the NCPs would have to close too. When the dial on demand logic detects traffic and brings up the line and then renegotiates the LCP, then all of the NCPs would have to be renegotiated. So we have both all of the NCPs and the LCP going up and down with the line. For routers that may be supporting many protocols, this means that everytime the line goes up and down many NCPs will have to be renegotiated. The above is my understanding of what the current specs seem to imply for dial on demand implementations. My question is whether we really want things to work this way. If as was suggested before, dial on demand is really supposed to provide to upper layers (in routers the network layer protocols) a transparent virtual "permanent connection", do we really want the transient state of the line to affect the state (of the NCP connection) of the specific upper layer protocols? Shouldn't the NCP sessions keep working without interruption regardless of what the line physical line is doing below in dial on demand mode? If people are happy with the situation whereby the NCP is renegotiated each time the dial on demand line goes up and down, then I do not think we have to talk about suspend/resume further. If people feel that this is not how things should work, then FOR THE SAVE OF INTEROPERABILITY I think we need to have a new PPP mechanism, which indicates whether the link was temporarily suspended or not. My impression is that PPP got specified before dial on demand implementations really started to proliferate. Although the spec supports dial up lines, I get the impression that the model of operation of PPP was thought to be more like leased line operation: when the implementation resets or comes up the first time, it detects attachment to the leased line and then negotiates LCP and NCP and that is that. If the upper protocols determine that communications on the link are no longer required (e.g. via an administrator disabling a router port temporarily or permanently to another destination), then the PPP link can be closed down. So we terminate all of the NCPs and the LCP over the link. If we reconfigure or decide to reestablish communications with the remote port, then we reestablish the LCP and NCP (possibly with different configuration options). If dial lines are used, then they would be dialed infrequently. However, under dial on demand, dial lines can be dialed very frequently. In dial on demand we terminate the connection not to reconfigure or terminate an upper layer association with a remote side. We really would like to leave the line up but the reality of telecommunications is that it is cheaper to raise and drop the line on demand so we carry out this artifice. Do we want to use the same model as indicated above in this case? Date: 06/09/94 04:07:18 PM To: Allen Rochkind/HQ/3Com cc: ietf-ppp @ merit.edu @ UGATE From: karl @ MorningStar.Com (Karl Fox) @ UGATE Subject: Re: suspend/resume; virtual connections (fwd) Allen Rochkind/HQ/3Com writes: > However, I was wondering whether you made the assumption that the > NCPs that you had previously negotiated will stay up when you > transparently disconnect the LCP after the line idles. I don't understand what you mean by `transparently'. I have always interpreted RFC 1548 to require NCPs to be renegotiated each time. I don't consider it ambiguous, and we have never encountered an interoperability problem that would be explained by an interpretation such as you describe. Page 8: 3.1 Overview In order to establish communications over a point-to-point link, each end of the PPP link MUST first send LCP packets to configure and test the data link. After the link has been established, the peer MAY be authenticated. Then, PPP MUST send NCP packets to choose and configure one or more network-layer protocols. Once each of the chosen network-layer protocols has been configured, datagrams from each network-layer protocol can be sent over the link. Page 10: 3.6 Network-Layer Protocol Phase Once PPP has finished the previous phases, each network-layer protocol (such as IP, IPX, or AppleTalk) MUST be separately configured by the appropriate Network Control Protocol (NCP). ... After a NCP has reached the Opened state, PPP will carry the corresponding network-layer protocol packets. Any network-layer protocol packets received when the corresponding NCP is not in the Opened state MUST be silently discarded. Page 10-11: 3.7 Link Termination Phase ... Implementation Note: The closing of the link by LCP is sufficient. There is no need for each NCP to send a flurry of Terminate packets. Conversely, the fact that one NCP has Closed is not sufficient reason to cause the termination of the PPP link, even if that NCP was the only NCP currently in the Opened state. Page 15: - Later, the peer is finished, and closes the link. A Terminate- Request arrives (RTR: tld,zrc,sta/Stopping, Termination phase). The This-Layer-Down action sends the Down event to any NCPs, while the Terminate-Ack is sent. The Zero-Restart-Counter action causes the link to wait for the peer to process the Terminate-Ack, with no retries. Page 18: Down ... It also can be used by LCP to signal each NCP that the link is leaving Network-Layer Protocol phase. That is, the This-Layer- Down action from LCP triggers the Down event in the NCP. Page 23-24: This-Layer-Down (tld) This action indicates to the upper layers that the automaton is leaving the Opened state. Typically, this action is used by the LCP to signal the Down event to a NCP, Authentication Protocol, or Link Quality Protocol, or MAY be used by a NCP to indicate that the link is no longer available for its network layer traffic. - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 15:51:55 1994 Received: from netcom.com (netcom11.netcom.com [192.100.81.121]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id PAA25242 for ; Fri, 10 Jun 1994 15:51:54 -0400 Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom) id MAA01988; Fri, 10 Jun 1994 12:52:06 -0700 Date: Fri, 10 Jun 1994 12:52:06 -0700 From: thenrion@netcom.com (Tim Henrion) Message-Id: <199406101952.MAA01988@netcom.com> To: vjs@rhyolite.wpd.sgi.com Subject: Re: suspend/resume; virtual connections Cc: ietf-ppp@merit.edu > > > From: thenrion@netcom.com (Tim Henrion) > > > ... > > > > What about routing? If you're on a connection which the other guy drops > > > > unexpectedly, wouldn't that cause you to mark your interface as down > > > > and have the routing layer invalidate all the routes through you? > > > > > > No. If I did that, then I could not use this PPP likn that I'm using > > > at this very instant. > > > > > > As far as the upper layers (starting with IP) are concerned, my > > > PPP links stay up all of the time. The fact that sometimes > > > the PPP stuff is turned off and not just the PPP state but a lot > > > more (SV STREAMS) state is gone is hidden from IP. > > > > > > > So then what you're saying is that you're implementing your *own* > > form of suspend/resume, just above the link layer. > > Close, but not quite. > > No special packets are exchanged. > Each end of the link does its own thing. > I happen to use "symmetric demand dialing", but as far as the two > ends are concerned, each does it entirely independently. > > It's not only "just above the link layer" but also involves routing > (RIP) packets to keep routing advertisments going even when they're > not coming over the link. > For the purposes of this discussion, what you are doing above the link layer (RIP) is not as important as what you are doing at or right above the link layer. You are creating an artifical link state which is essentially == "suspended". Your link layer is not informing the upper layer protocols that the interface is unavailable. Because of this artifical link state that you have created through your link layer extension, the protocols stacks are functioning in a way that they would not be functioning without this link layer extension. > > > I believe that > > Patrick and I are stating that we'd like that standard functionality > > to be built into the link layer itself so that implementations may > > interoperate at this level. > > Why is it desirable to do this kind of stuff in the link layer? > Because you are implementing a link layer concept (suspend/resume) without informing me (the other end of the link) that you are doing so so that I may operate in a similar manner. > You could, but given that PPP is (mostly) an unreliable link, > why would you? > Once again, for interoperability purposes. > > > That's fine. If everyone's doing "demand dialing" what's > > the argument against putting a standard suspend/resume facility > > in PPP? > > "why not add" a feature is absolutely always an inadmissable > argument. > I'm not saying "why not?". I'm saying: "Put this de-facto link layer extension into the *standard* so that I can interoperate with you at this level on an equal footing". There are other reasons but this one seems to be the only one that has a remote chance of satisfying you. > > YOU MUST ABSOLUTELY ALWAYS OMIT POSITIVELY EVERY > FEATURE WITHOUT A COMPELLING REQUIREMENT. > Boy, I'd love to see the "compelling requirements" for some of the stuff in the spec right now... > The fact that at least for IP and as far as most of us can tell, > the current PPP mechanisms support demand dialing is why > pause/resume should not be added. YOU ONLY ADD THAT WHICH YOU > ABSOLUTELY REQUIRE FOR COMPELLING TECHNICAL OR BUSINESS REASONS. > O.K. Here it comes: COMPELLING TECHNICAL REASON: Current PPP mechanisms for demand-dialing provide no mechanism for clean interoperability. They implement non-standard link layer extensions which *fake* the state of the link layer to the upper layers. I'm not saying that this is a bad thing to do when required but it is bad to do *by default all the time*, especially if the other side has no knowledge of it. I feel that the way that you have implemented "demand-dial" is architecturally wrong because you are faking the state of the link layer to the upper layers without actually really knowing what the true state of the link layer is (suspended/disconnected). You have also made no effort to inform me what the state of the link is so that my link layer may determine whether it needs to fake out its upper layers or not (i.e. trash the routes or not). Keep in mind that I'm not saying that your concepts are necessarily wrong. I need to know what you think the logical state of the link is so that I may operate in a similar manner. Never trashing the routes when a call hangs up is architecturally deficient by modern standards of network design methodology. You are doing a disservice to your network by not informing it of the true state of the link and allowing it to find alternate routes, if they exist. The purpose of adding suspend/resume support is to create a *defined* way that a physical link can drop (to save connect charges) while informing those above the link layer that the link has really not disconnected. This way you allow your upper layers to take appropriate action which, believe it or not, is different depending on whether your are suspended or disconnected. If you would like a business reason, I could give you one but it is proprietary and not necessarily productive to the discussion. > PPP is already bloated beyone belief. E.g. > - link quality is rarely used and of at best limited utilty. > - magic numbers are not really useful for detecting loop backs > because that's not a common failure mechanism. > - the "time remaining" facility has already been mentioned. > - why 2 different authentication mechanisms? > - self-describing-padding is rarely if at all used and the > wrong way to handle the problem (i.e. more bits than > alternatives) > I agree that there's a lot of crap in PPP. I don't use it and I still sleep well at night. Tim Henrion Principal Software Engineer Extension Technology Corporation 30 Hollis Street Framingham, MA 01701 Phone: (508) 872-7748 FAX: (509) 872-7533 Internet: thenrion@netcom.com - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 16:11:20 1994 Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA26641 for ; Fri, 10 Jun 1994 16:11:17 -0400 Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (5.65a/94040804) id AA00718; Fri, 10 Jun 94 16:10:43 -0400 From: Karl Fox Received: by gefilte.MorningStar.Com (5.65a/94012401) id AA00281; Fri, 10 Jun 94 16:10:42 -0400 Date: Fri, 10 Jun 94 16:10:42 -0400 Message-Id: <9406102010.AA00281@gefilte.MorningStar.Com> To: Patrick Klos Cc: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections (fwd) In-Reply-To: <199406101447.KAA22998@mv.mv.com> References: <199406101447.KAA22998@mv.mv.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Patrick Klos writes: > >> I second Karl Fox's suggestion that there should be PPP support for > >> implementations to provide a dial on demand link layer, which fools > >> the upper layers into thinking it has a permanent connection and > >> does not have to concern itself with the transient state of the > >> link. > > > >I did not suggest that there should be such support; there already is > >such support. > > There is?!? Where is it defined?? What RFC? RFC 1548. Bring up the link when you want to send packets, tear it down when you're done or idle. It works fine for every single extant dial-on-demand PPP implementation, including those carrying IP, IPX, and Appletalk. > In routers, the upper layers (IP and IPX are upper layers to PPP) are > always busy making sure thier routing information is up to date. By > telling them the lower layer is down (with a REASON), they can either > spoof as necessary, or invalidate some of thier routing entries. Right. As Vernon described, you assume that the virtual link is up until you try to use it and it fails. This technique works; try it. > >As Vernon Schryver pointed out, you might not even be able to talk to > >the upper layers at all. In the vast majority of PPP installations, > >at least one of the ends of the upper layer sessions is not in the > >same place as either of the ends of the PPP link, so no communication > >is even possible. > > The suspend/resume capability would only be concerned with the two PPP > peers. Now I'm really confused, because that's not what you claimed before. What state, then, do you want to save? By your response above, it's not at the session layer. If it's about spoofing routing protocols, then `see above'. > >I have heard only one argument as to why it might be desirable to > >inform the upper layers that a session had, in fact, `ended' -- and > >that is so that existing TCP sessions could be shut down. However, > >the only way to determine from the link layer that a PPP session is > >`ended' as opposed to `paused' or `temporarily idle' is by watching > >the TCP sessions and shutting down when they are all closed! > > Not if we define this suspend/resume capability. I've spelled this out > several times already in other postings. You've got it backward. You can't even decide which of `suspend' or `done' to use because of the paragraph above (the one starting `I have heard') and this one: > >So, the > >only time this could be useful is exactly when it can't! > > Huh? See above. :-) > > 1) How would suspend/resume differ from standard PPP startup/shutdown? > > To shutdown a connection (DONE), send a Terminate Request, wait for > Terminate Ack. > > To suspend a connection (IDLE), send a Suspend Request, wait for a > Suspend Ack or Suspend Nak. If Suspend Nak, keep the link up. If Suspend > Ack, shut down link, but keep NCPs up (by some as yet undefined mechanism) > and wait for the link to come up and a Resume to be requested. First of all, you're not usually going to get the other end to not shut down just because you ask, so `Suspend-Nak' is pointless. In fact, sending a new LCP message type *will* cause many PPP implementations to just hang up! Second, I thought you wanted an option. Now you're defining new LCP message types? > > 2) When would each (suspend/resume versus startup/shutdown) be used? > > Shutdown (DONE) would be the default (loss of phone line, reboot, other > misc loss of connection. Suspend (IDLE) would be used when a peer decides > the link is IDLE long enough, but doesn't want to relinquish the resources > allocated to it. > > > 3) What `state' would suspend/resume record between PPP sessions? > > IPX Network Number assigned to the connection. IP Address assigned to the > connection. Spoofing requirements. Etc. But they can be (and are) negotiated at link start up. Why save them when you have to do some negotiating regardless? Just to keep from having to send 32 bits? > I don't see any "broad base of acceptance"; just the contrary! I see a broad > base of negative remarks without any credible reasons why this would NOT be > useful! I've given plenty of technical reasons why it would be a good thing. Many arguments have been presented on both sides. Those of us with working implementations, though, don't seem to understand the utility of your suggested feature. > Why does everyone seem to implement "demand dialing" support if they feel > this capability is useless?!? This is the same thing! We just want a spec > so we can all interoperate. We do have a spec. We do interoperate. What more do you want? - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 16:50:34 1994 Received: from pm002-25.dialip.mich.net (pm002-25.dialip.mich.net [35.1.48.106]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA29392 for ; Fri, 10 Jun 1994 16:50:31 -0400 Date: Fri, 10 Jun 94 20:10:17 GMT From: "William Allen Simpson" Message-ID: <2608.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Why Time-Remaining? > From: Patrick Klos > How necessary is the "Time-Remaining" LCP option?? In this case, it was proposed for both IPX and AppleTalk. So, rather than having two slightly different techniques, a single one was designed. It is primarily useful for what are called, in the NAS WG, Network Access Clients. > Personally, I > appreciate the (relatively) clean design of PPP and do not find it > that complex. > Thank you. As I wrote to you privately, as Editor, I have spent the better part of 4 years trying to keep a cohesive stable architecture, turning down requests for myriad new features. The features most often used (and most easily agreed upon) are in the main document. The other LCP options still had at least two vendors who proposed their use, and general agreement that they might be useful. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 16:45:46 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA28948 for ; Fri, 10 Jun 1994 16:45:46 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for ietf-ppp@merit.edu id AA21480; Fri, 10 Jun 94 13:44:22 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:thenrion@netcom.com id AA29929; Fri, 10 Jun 94 14:44:15 -0600 Date: Fri, 10 Jun 94 14:44:15 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406102044.AA29929@rhyolite.wpd.sgi.com> To: thenrion@netcom.com (Tim Henrion) Subject: Re: suspend/resume; virtual connections Cc: ietf-ppp@merit.edu > From: thenrion@netcom.com (Tim Henrion) > ... > Because you are implementing a link layer concept (suspend/resume) > without informing me (the other end of the link) that you are doing > so so that I may operate in a similar manner. My code, like MOrningstar's and Telebits and others', doesn't care if you operate in the same manner or not. > .... > I'm not saying "why not?". I'm saying: "Put this de-facto link > layer extension into the *standard* so that I can interoperate > with you at this level on an equal footing". There are other > reasons but this one seems to be the only one that has a > remote chance of satisfying you. > ... > COMPELLING TECHNICAL REASON: > Current PPP mechanisms for demand-dialing provide no mechanism > for clean interoperability. They implement non-standard > link layer extensions which *fake* the state of the link layer to > the upper layers. I'm not saying that this is a bad thing to > do when required but it is bad to do *by default all the time*, > especially if the other side has no knowledge of it. I feel that > the way that you have implemented "demand-dial" is architecturally > wrong because you are faking the state of the link layer > to the upper layers without actually really knowing what > the true state of the link layer is (suspended/disconnected). > You have also made no effort to inform me what the state of > the link is so that my link layer may determine whether it > needs to fake out its upper layers or not (i.e. trash the > routes or not). > .... Is it fair to summarize your objection to the current de facto industry standard for IP demand dialing as? : 1. you are not familiar with it. 2. it is not written down in an official standard. 3. it is architectually unclean. All of those seem true. I agree first two should be fixed, and I presume the first one has already been fixed. Those 3 reasons do not compel me to agree that suspend/resume would be better. I think #3 cannot and should not be fixed. For example, it is very effective to have the PPP box snoop on TCP SIN's and FIN's to infer the number of active TCP connections passing through the system but not necessarily terminating on either PPP peer, for the purposes of adjusting idle timers. I think it's neat to extend the VJ header compression state to track active connections. That way, I use a very short timeout when it looks as if the link has no active TCP connections, but a 5 minute timeout otherwise. Again, neither TCP terminus need be on either PPP peer. Even with suspend/resume, you would want this perversion of layers. That is at least an eggregious layering violation. However, most people how care about layering violations are still attending OSI and CCITT committee meetings. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 16:49:33 1994 Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA29125 for ; Fri, 10 Jun 1994 16:49:30 -0400 Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (5.65a/94040804) id AA01503; Fri, 10 Jun 94 16:48:57 -0400 From: Karl Fox Received: by gefilte.MorningStar.Com (5.65a/94012401) id AA00299; Fri, 10 Jun 94 16:48:55 -0400 Date: Fri, 10 Jun 94 16:48:55 -0400 Message-Id: <9406102048.AA00299@gefilte.MorningStar.Com> To: Patrick Klos Cc: ietf-ppp@merit.edu, klos@mv.mv.com, louie@alter.net, vjs@rhyolite.wpd.sgi.com Subject: Re: suspend/resume; virtual connections (fwd) In-Reply-To: <199406101526.LAA29632@mv.mv.com> References: <199406101526.LAA29632@mv.mv.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Patrick Klos writes: > Guys, > > Have you guys all standardized on demand-dialing so you all are > interoperable?? Yes. - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 16:52:32 1994 Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA29639 for ; Fri, 10 Jun 1994 16:52:31 -0400 Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (5.65a/94040804) id AA01564; Fri, 10 Jun 94 16:51:53 -0400 From: Karl Fox Received: by gefilte.MorningStar.Com (5.65a/94012401) id AA00302; Fri, 10 Jun 94 16:51:51 -0400 Date: Fri, 10 Jun 94 16:51:51 -0400 Message-Id: <9406102051.AA00302@gefilte.MorningStar.Com> To: rorem@mana.eecs.uic.edu (Doug Rorem) Cc: ietf-ppp@merit.edu Subject: Re: suspend/resume In-Reply-To: <9406101543.AA06967@mana.eecs.uic.edu> References: <9406101543.AA06967@mana.eecs.uic.edu> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Doug Rorem writes: > Why would you tear down a connection on a dedicated 57.6 K line? Tearing > down an ISDN (or analog modem) connection is done because of cost savings. > For these cases, one incurs call setup times which are longer than .2 to .3 > seconds. Not with our code, and I'll bet others will chime in too. Our code takes 0.6 seconds to negotiate LCP, CHAP, and IPCP over a V.32 (not even V.32bis!) modem, and is substantially faster over links with lower latency. - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 16:46:41 1994 Received: from netcom.com (netcom6.netcom.com [192.100.81.114]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id QAA28982 for ; Fri, 10 Jun 1994 16:46:39 -0400 Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom) id NAA12118; Fri, 10 Jun 1994 13:46:46 -0700 Date: Fri, 10 Jun 1994 13:46:46 -0700 From: thenrion@netcom.com (Tim Henrion) Message-Id: <199406102046.NAA12118@netcom.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections Karl Fox writes > > Tim Henrion writes: > > The "connection state" is the state of all currently negotiated NCP > > options so that no renegotiation has to take place when the link resumes. > > The idea is to be able to resume the connection is as little time as > > possible. When the line is brought up, the originator should be able to > > tell the other side that he is resuming a suspended connection (by > > passing some type of identifier) and re-authenticating himself. > > The connection should then resume in the OPEN state with all NCP > > options being set to what they were when the connection suspended. > > I assume that you would still authenticate, unless you are utterly > unconcerned about security. Bill Simpson's suggestion of just > rerunning CHAP periodically isn't secure, since someone could come in > without authenticating and quickly do some severe damage before the > CHAP timer came around. You'll also have to renegotiate LCP, since > the `PC' may be coming in on a different line, perhaps one that uses > XON/XOFF flow control (while the others use RTS/CTS) and therefore > needs a different asyncmap. > > What have you saved? > Yes, reauthentication should be required. I don't like the idea of periodically rerunning CHAP on an idle line because it would not allow idle lines to suspend. On this same thought, I also disagree with implementations which send periodic echo-requests to test the state of the connection. This would also not allow idle lines to suspend. You raise a good point here. I like the idea someone presented about making LCP renegotiate but having the NCPs stay in their previous state. As you mention above, it is important to have LCP renegotiate if the resume is made on a different line with different LCP requirements. What you save with suspend/resume vs. disconnect/reconnect is whether the upper layers are informed that the link is unavailable or not. Architecturally there are two distinctly different actions which should be taken for the two different cases. When the line suspends, you don't want the upper layers informed so that the routes through the connection don't get invalidated. When the line disconnects (either normally or abnormally), the upper layers must be informed so that invalid routes can be replaced with new valid routes, if they exist. Implementing suspend/resume in LCP would provide an architecturally sound interoperable way for "demand-dial" implementations to function and interoperate while not adding unnecessary windows of potential routing confusion. Tim Henrion Principal Software Engineer Extension Technology Corporation 30 Hollis Street Framingham, MA 01701 Phone: (508) 872-7748 FAX: (509) 872-7533 Internet: thenrion@netcom.com - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 16:56:24 1994 Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA29790 for ; Fri, 10 Jun 1994 16:56:22 -0400 Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (5.65a/94040804) id AA01748; Fri, 10 Jun 94 16:55:48 -0400 From: Karl Fox Received: by gefilte.MorningStar.Com (5.65a/94012401) id AA00310; Fri, 10 Jun 94 16:55:47 -0400 Date: Fri, 10 Jun 94 16:55:47 -0400 Message-Id: <9406102055.AA00310@gefilte.MorningStar.Com> To: thenrion@netcom.com (Tim Henrion) Cc: ietf-ppp@merit.edu, vjs@rhyolite.wpd.sgi.com Subject: Re: suspend/resume; virtual connections In-Reply-To: <199406101601.JAA16307@netcom.com> References: <199406101601.JAA16307@netcom.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Tim Henrion writes: > If everyone's doing "demand dialing" what's the argument against > putting a standard suspend/resume facility in PPP? If everyone's already doing demand dialing with the existing spec., what's the argument in favor of adding a facility whose only purpose is to support demand dialing? - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 16:50:38 1994 Received: from pm002-25.dialip.mich.net (pm002-25.dialip.mich.net [35.1.48.106]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA29421 for ; Fri, 10 Jun 1994 16:50:34 -0400 Date: Fri, 10 Jun 94 20:18:30 GMT From: "William Allen Simpson" Message-ID: <2609.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: suspend/resume; virtual connections > From: thenrion@netcom.com (Tim Henrion) > That's fine. If everyone's doing "demand dialing" what's > the argument against putting a standard suspend/resume facility > in PPP? > Since everyone's already doing demand dialing, there is no call for designing a new method of doing demand dialing. It already works. Adding another feature to do it in a different way would make the current techniques fail, unless carefully designed so that they all continue to work. This is the primary and most important technical consideration! Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 16:50:31 1994 Received: from pm002-25.dialip.mich.net (pm002-25.dialip.mich.net [35.1.48.106]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA29353 for ; Fri, 10 Jun 1994 16:50:27 -0400 Date: Fri, 10 Jun 94 18:48:47 GMT From: "William Allen Simpson" Message-ID: <2607.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: suspend/resume; virtual connections (fwd) > From: Patrick Klos > >Looking at your example, it would seem to me to be a bad IPXCP > >implementation. RFC-1552 clearly states that, by default, there is > >no network number assigned to a link that is not between two routers. > > By default, there is no network number assigned. That's why we negotiate one! > How else is a node on a local LAN supposed to address the node (or nodes) on > the PPP port! I guess EVERYONE with IPXCP has a BAD IMPLEMENTATION! I don't > even know what you're trying to say here! > Yes, this is rapidly becoming apparent.... Saying "by default, there is no network number assigned" means the link MUST operate correctly without a network number, since all implementations MUST operate correctly without negotiating any options. At the PPP-a-thon, implementations conforming to the spec interoperated. Since I wrote an IPXCP implementation (in more than one product), and they interoperated, perhaps you might revise your estimation about who _does_ know? > >As to demand dialing, there is no reason why the link cannot do a soft > >drop until more traffic is ready (on either end). The IPXCP should > >continue to spoof, since it should be unaware of the soft drop. > > > >Soft drop works just fine in MacPPP. > > A "soft drop"?? Could you tell me what RFC defines a "soft drop"?? I rest > my case! There is NONE! That's what we're trying to define. Why all the > opposition?!? > I already did, and already quoted the relevant sections 2 days ago. If you won't read what I wrote, then why should I bother replying? You are working really hard to join Vernon on my kill list. (Although, in this matter, by your replies he and I seem to be arguing on the same side for once.) Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 17:01:02 1994 Received: from netcom.com (netcom8.netcom.com [192.100.81.117]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id RAA00617 for ; Fri, 10 Jun 1994 17:01:01 -0400 Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom) id OAA15561; Fri, 10 Jun 1994 14:01:08 -0700 Date: Fri, 10 Jun 1994 14:01:08 -0700 From: thenrion@netcom.com (Tim Henrion) Message-Id: <199406102101.OAA15561@netcom.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections (fwd) Karl Fox writes: > > In routers, the upper layers (IP and IPX are upper layers to PPP) are > > always busy making sure thier routing information is up to date. By > > telling them the lower layer is down (with a REASON), they can either > > spoof as necessary, or invalidate some of thier routing entries. > > Right. As Vernon described, you assume that the virtual link is up > until you try to use it and it fails. This technique works; try it. > Great. On an analog phone line, how long is it going to take to figure out that you can't connect to the other side anymore (because he croaked and dropped the line)? 30 or 60 seconds? That technique may work but it's pretty darn crude. One of the main benefits of adding suspend/resume support is that you really *know*, at disconnect time, the true state of the link. Routes can be invalidated and routing consistency maintained *immediately* instead of waiting 60 seconds for an call to fail. Tim Henrion thenrion@netcom.com - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 16:46:48 1994 Received: from netcom.com (netcom6.netcom.com [192.100.81.114]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id QAA28993 for ; Fri, 10 Jun 1994 16:46:47 -0400 Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom) id NAA12132; Fri, 10 Jun 1994 13:47:01 -0700 Date: Fri, 10 Jun 1994 13:47:01 -0700 From: thenrion@netcom.com (Tim Henrion) Message-Id: <199406102047.NAA12132@netcom.com> To: ietf-ppp@merit.edu Subject: Re: What exactly *is* the need for suspend/resume? Brad Wilson writes: > > >> I disagree. Like it or not, what he's performing is the equivalent > >> of a link level extension right above the link layer. > > Define "link level extension". > Perhaps "link level extension" was an improper way of stating my opposition to the description that says the Down condition SHOULD inform the upper layers that the link is no longer available. I feel that there should be two "Down" conditions: "Down" and "Suspended". "Down" must inform the upper layers that the connection is no longer available and "Suspened" should not. > >> Not only is this inappropriate in a well architected system, it makes > >> interoperability difficult. > > Show one system that he is not interoparable with because he has > implemented dial on demand. > The PPP RFC states that when a link goes down, LCP SHOULD inform the upper layers. I feel that the implications of the current demand-dial implementations, specifically their implications in the routing world, need to be weighed further. Because the current DD model does not inform the upper layers until a window of time after the link has terminated, invalid routes may exist during that window, especially if the call cannot be re-established within the window. If the call is dropped due to any action other than a suspension, the upper layers should be informed immediately to avoid having a window of bad routes across the dead interface. Albeit adding suspend/resume will not eliminate this problem, it will minimize it in this particular type of failure condition. It would also allow the routing state on both sides of the link to be consistent. When I talk about about interoperability between DD implementations, I am specifically referring to consistency of routing state between each peer on the link. For example my PPP implementation, which would "architecturally correct" would inform the upper layers on the Down condition so that routing states would be accurately updated. Vernon's would not. This would cause routing state inconsistencies on opposite ends of the link. This is what I mean by "interoperability problems". Once again, I advocate separate "Down" and "Suspended" actions which ride along with suspend/resume functionality to allow DD implementations to interoperate more cleanly in this regard. If the current concensus here is "it ain't broke, don't fix it" then I've officially given up on beating this dead horse. Tim Henrion thenrion@netcom.com - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 17:05:19 1994 Received: from lobster.wellfleet.com (lobster.wellfleet.com [192.32.253.3]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id RAA00779 for ; Fri, 10 Jun 1994 17:05:18 -0400 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA03415; Fri, 10 Jun 94 17:03:53 EDT Received: from sgtpepper.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA04849; Fri, 10 Jun 94 17:00:57 EDT Date: Fri, 10 Jun 94 17:00:57 EDT From: ed_allen@wellfleet.com (Ed Allen) Message-Id: <9406102100.AA04849@pobox.wellfleet> Received: by sgtpepper.wellfleet (4.1/SMI-4.1) id AA00533; Fri, 10 Jun 94 17:07:44 EDT To: ietf-ppp@merit.edu Subject: Question on CHAP NAMEs Hi, Since some of us may be a bit weary from the suspend/resume conversations I thought I'd give us a new and less controversial thread. I'm trying to learn a bit about how CHAP NAMEs are used, mostly by router implementations, for purposes of interoperability. Could you please enlighten me by answering a few questions? What do routing implementations use for CHAP NAMEs? Is the value contained in a NAME consistent across all Challenge/Responses within a given LCP connections? Is the NAME a router uses consistent across all LCP connections until the router is reconfigured? Do all routers allow the NAME to be configured? Do any vendors "hardcode" the NAME to be the value of a backplane ID, or a MAC address, or similar? Thanks in advance, for your replies. - Ed P.S. Below is an extract from rfc 1334, which describes the NAME field. Name The Name field is one or more octets representing the identification of the system transmitting the packet. There are no limitations on the content of this field. For example, it MAY contain ASCII character strings or globally unique identifiers in ASN.1 syntax. The Name should not be NUL or CR/LF terminated. The size is determined from the Length field. Since CHAP may be used to authenticate many different systems, the content of the name field(s) may be used as a key to locate the proper secret in a database of secrets. This also makes it possible to support more than one name/secret pair per system. -- _____________________________________________________________________________ / | \ Ed Allen | The views expressed are not officially Wellfleet Communications, Inc. | endorsed by my employer. Any resemblance to Protocol Software Development | official or fictional opinions is coincidental \________________________________|_____________________________________________/ - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 19:37:43 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id TAA09462 for ; Fri, 10 Jun 1994 19:37:42 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id TAA15505; Fri, 10 Jun 1994 19:37:41 -0400 Date: Fri, 10 Jun 1994 19:37:41 -0400 From: Patrick Klos Message-Id: <199406102337.TAA15505@mv.mv.com> To: jhalpern@mako.Newbridge.COM Subject: Re: suspend/resume; virtual connections (fwd) Cc: ietf-ppp@merit.edu >You say that this has nothing to do with speed. However: >1) Many people have claimed that this is "faster" than renegotiating > the PPP connection. Maybe so, but that has nothing to do with the technical reasons why we're looking for suspend/resume functionality. We've been off on that tangent before, but it's not part of the considerations here! >2) There has been an argument about retained state. If the user is > going to expect this kind of retention, it probably needs to > be retain any time the link is unexpectedly terminated. > If that is true, the "suspend" packet is bringing the link down without > sending a terminate. As I see it, there are three types of terminations: 1) Terminate Request sent and acknowledged, 2) phone line lost for unknown reason, and 3) (hypothetical) Suspend request sent and acknowledged. For type 1, we can release all resources as the peer is indicating it's done with them. For type 2, we may want to retain the state information for a short period of time, allowing for the peer to re-establish the broken link. For type 3, the peer is saying "let's save some money on the phone bill, I'll call you back when I have something to say (or call me if you do)". Type 3 would retain the state information for a (definable) long period of time. >That is why I do not see the value in a new packet. There may be a >use for advisory text about state retention, but I am not even sure >where it would go. Remember, IP might not find this useful, but IPX certainly would! >Joel M. Halpern jhalpern@newbridge.com >Newbridge Networks Inc. Patrick - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 19:46:35 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id TAA09833 for ; Fri, 10 Jun 1994 19:46:34 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id TAA17324; Fri, 10 Jun 1994 19:46:31 -0400 Date: Fri, 10 Jun 1994 19:46:31 -0400 From: Patrick Klos Message-Id: <199406102346.TAA17324@mv.mv.com> To: ietf-ppp@merit.edu, vjs@rhyolite.wpd.sgi.com Subject: Re: suspend/resume; virtual connections (fwd) >As I see it, there is no reason to distinguish between cases #3 and >#4. Instead, I would lump them together, and require that a peer that >wants to maintain it's address or other state call back periodically, >say once a day. With regard to this issue, I see nothing different >between IP and IPX. I wasn't aware that demand-dialing IP had such a stipulation. >The problems with IPX that I see are in spoofing and faking those RIP >and other packets. > > >Vernon Schryver, vjs@sgi.com Patrick - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 20:22:51 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id UAA11625 for ; Fri, 10 Jun 1994 20:22:50 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id UAA22182; Fri, 10 Jun 1994 20:22:45 -0400 Date: Fri, 10 Jun 1994 20:22:45 -0400 From: Patrick Klos Message-Id: <199406110022.UAA22182@mv.mv.com> To: bill.simpson@um.cc.umich.edu Subject: Re: suspend/resume; virtual connections Cc: ietf-ppp@merit.edu >> That's fine. If everyone's doing "demand dialing" what's >> the argument against putting a standard suspend/resume facility >> in PPP? >> >Since everyone's already doing demand dialing, there is no call for >designing a new method of doing demand dialing. It already works. No one is trying to re-invent demand dialing for IP (not that I know of). Other protocols have different issues for demand dialing. >Adding another feature to do it in a different way would make the >current techniques fail, unless carefully designed so that they all >continue to work. That's why we're all cordially discussing the idea before running off and writing a spec (or worse yet, coding it). >This is the primary and most important technical consideration! I agree totally (well, 99.9% - I don't care for protecting bugs from eternal perpetuation). >Bill.Simpson@um.cc.umich.edu Patrick - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 20:25:58 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id UAA11690 for ; Fri, 10 Jun 1994 20:25:57 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id UAA22667; Fri, 10 Jun 1994 20:25:56 -0400 Date: Fri, 10 Jun 1994 20:25:56 -0400 From: Patrick Klos Message-Id: <199406110025.UAA22667@mv.mv.com> To: karl@morningstar.com Subject: Re: suspend/resume; virtual connections Cc: ietf-ppp@merit.edu >> If everyone's doing "demand dialing" what's the argument against >> putting a standard suspend/resume facility in PPP? > >If everyone's already doing demand dialing with the existing spec., >what's the argument in favor of adding a facility whose only purpose >is to support demand dialing? If you're referring to RFC1548, the words "demand dial" NEVER appear in the text. The word "demand" is non-existant in the spec, and the word "dial" only appears twice. - - - - - - - - - - - - - - - - - From list-admin Fri Jun 10 20:41:51 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id UAA12590 for ; Fri, 10 Jun 1994 20:41:51 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id UAA23919; Fri, 10 Jun 1994 20:41:46 -0400 Date: Fri, 10 Jun 1994 20:41:46 -0400 From: Patrick Klos Message-Id: <199406110041.UAA23919@mv.mv.com> To: bill.simpson@um.cc.umich.edu Subject: Re: suspend/resume; virtual connections (fwd) Cc: ietf-ppp@merit.edu >> By default, there is no network number assigned. That's why we negotiate one! >> How else is a node on a local LAN supposed to address the node (or nodes) on >> the PPP port! I guess EVERYONE with IPXCP has a BAD IMPLEMENTATION! I don't >> even know what you're trying to say here! >> >Yes, this is rapidly becoming apparent.... > >Saying "by default, there is no network number assigned" means the link >MUST operate correctly without a network number, since all implementations >MUST operate correctly without negotiating any options. In such a case, it is perfectly acceptable for an implementation to decide it doesn't want to continue if a certain option cannot be agreed upon. I don't know if a single IPX dial-in router (not bridge, router) that can work when no IPX network number is defined for a remote client to use (either by IPXCP or IPXWAN). >At the PPP-a-thon, implementations conforming to the spec interoperated. >Since I wrote an IPXCP implementation (in more than one product), and >they interoperated, perhaps you might revise your estimation about who >_does_ know? Funny, I was at the PPP-a-thon too. Funny, my IPXCP implementation worked FLAWLESSLY too. Maybe I too know what I'm talking about! Can you imagine that!?!? My PPP driver did quite well also. Do you want to arm wrestle?? >> >As to demand dialing, there is no reason why the link cannot do a soft >> >drop until more traffic is ready (on either end). The IPXCP should >> >continue to spoof, since it should be unaware of the soft drop. >> > >> >Soft drop works just fine in MacPPP. >> >> A "soft drop"?? Could you tell me what RFC defines a "soft drop"?? I rest >> my case! There is NONE! That's what we're trying to define. Why all the >> opposition?!? >> >I already did, and already quoted the relevant sections 2 days ago. If >you won't read what I wrote, then why should I bother replying? A lot of sh*t has been flying around the passed few days. I've been reading through almost all of it. I'm sorry if I missed some detail you stated. >You are working really hard to join Vernon on my kill list. Oh, now that's scary! (I'm sure Vern is shaking, too) A "kill list" sounds like an excuse for a closed mind. >(Although, >in this matter, by your replies he and I seem to be arguing on the same >side for once.) >Bill.Simpson@um.cc.umich.edu Patrick - - - - - - - - - - - - - - - - - From list-admin Sat Jun 11 08:27:16 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id IAA19938 for ; Sat, 11 Jun 1994 08:27:15 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id IAA08147; Sat, 11 Jun 1994 08:27:11 -0400 Date: Sat, 11 Jun 1994 08:27:11 -0400 From: Patrick Klos Message-Id: <199406111227.IAA08147@mv.mv.com> To: brian@lloyd.com, klos@mv.MV.COM Subject: Re: suspend/resume; virtual connections (fwd) Cc: ietf-ppp@merit.edu >What many people seem to forget is that it often costs much more to deal >with some unlikely and usually unimportant special case than it does to >accept some suboptimal special-case behavior. If timely propagation of >this information is critical, perhaps you need to be runing a >fully-connected network. For IPX, this is NOT an unlikely and usually unimportant special case! >My admonition to you is to prove that you absolutely cannot make the >simpler case work. Many of us have been pushing bits around the Internet >for a long time and, frankly, the simplest case is usually adequate even if >suboptimal. Did someone have to prove that every option currently in the PPP specs was absolutely necessary, and could not make a simpler case work?!? I have already made a case as to why it would be extremely useful to support suspend/resume for IPX. Without it, demand-dialing would be nothing but a kludge when IPX is involved. >Let's look at it another way: does it matter that a client discover that a >resource is unavailable at the time that the resource is requested? I hold >that it does not. Consider that, even on a LAN, a resource could fail and >a client could request that resource before the client discovered that the >resouce was gone. Since whatever application you want to run, be it IP or >IPX based, must deal with this case, delaying the propagation of said >information does not break anything. Heck, you may get lucky and the >resource could go away and come back. In that case the clients are none >the wiser and everybody is still happy. When using NCP (Netware Core Protocol), you cannot easily recover when logged into a file server, running Windows, and the file server decides you're no longer logged in (after a connection is re-established). Since we have no control of NCP under Windows, we'd like to put the control where we have control. Do you understand all the issues involved in IPX and NCP over PPP, and what is involved in supporting demand dialing for such an environment?? >I hope you won't be offended if I remain unconvinced by your argument. PPP >has suffered from a severe case of "creeping featurism" for much of its >life. I hope that you will forgive me and others who have lived with this >for 6 years when we are reluctant to add YAO (Yet Another Option) when the >option is arguably not required. This is not "Yet Another Option". It is a useful feature for protocols that are not as flexible (or easy to fool) as IP. >Again, if you can show me that you cannot make things work without the >option, I will be happy to support a new option. My experience leads me to >believe that this option really isn't needed. I've presented my case a few times, and again above. >Brian Lloyd, President Lloyd Internetworking >brian@lloyd.com 3031 Alhambra Drive >(916) 676-1147 - voice Suite 102 >(916) 676-3442 - fax Cameron Park, CA 95682 Patrick - - - - - - - - - - - - - - - - - From list-admin Sat Jun 11 10:42:15 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA26375 for ; Sat, 11 Jun 1994 10:42:15 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for ietf-ppp@merit.edu id AA16209; Sat, 11 Jun 94 07:42:10 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA02117; Sat, 11 Jun 94 08:23:43 -0600 Date: Sat, 11 Jun 94 08:23:43 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406111423.AA02117@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume > From: karl@MorningStar.Com (Karl Fox) > > Doug Rorem writes: > > Why would you tear down a connection on a dedicated 57.6 K line? Tearing > > down an ISDN (or analog modem) connection is done because of cost savings. > > For these cases, one incurs call setup times which are longer than .2 to .3 > > seconds. > > Not with our code, and I'll bet others will chime in too. Our code > takes 0.6 seconds to negotiate LCP, CHAP, and IPCP over a V.32 (not > even V.32bis!) modem, and is substantially faster over links with > lower latency. That 0.6 seconds is about 3 times longer than it needs to be. It is probably about the same as my from-scratch code, as well as the many implementations descended from the ancient Drew Perkins "proof of concept code." If we cared, we could reduce that number by a factor of 3 without any changes to any protocol or any features that were not in the first versions of the PPP, IPCP, and authentication RFCs of years ago. The following table is of upper bounds of savings from not renegotiating five (5) higher layer protocols (assuming each configure-request is 20 bytes). In other words, if you keep the NCP's open, you cannot save more than the following: line speed savings ---------- ------- v32+v.42 0.2 second v.32bis+v.42 0.11 second 56k (leased or switched) 0.03 second 64K (eg. ISDN) 0.025 second Anyone who cares about setup speed need only send all of the configure requests in one big burst, without waiting for a configure-Ack from LCP or authentication. YOU DO NOT NEED TO WAIT! Simply 1. save any non-default parameters negotiated in the very first connection 2. on each subsequent negotiation, send a single burst of HDLC or async-HDLC packets consisting of the LCP configure-request, the autentication response, and any NCP configure requests. 3. as required by the protocol, and since the values are all acceptible, the peer will process each of those packets in sequence and immediately transmit configure-Acks. THERE IS NO SIGNIFICANT LATENCY IN RENEGOTIATING THE ENTIRE CONNECTION. It would be really swell if the IETF PPP standards committee would not turn into a completely ANSI/IEEE/CCITT clone, where people feel compelled to argue for features intended to solve problems that do not exist on grounds they do not understand based on a lack of knowledge of both current de facto standards and the de jurie PPP standards. The persistent claims that suspend/resume would significantly reduced connection-restoration latency are a discouraging sign that the IETF is continuing its evolution into a standard standards organization. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Sat Jun 11 10:47:29 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA26401 for ; Sat, 11 Jun 1994 10:47:28 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for ietf-ppp@merit.edu id AA16479; Sat, 11 Jun 94 07:47:23 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA02184; Sat, 11 Jun 94 08:46:00 -0600 Date: Sat, 11 Jun 94 08:46:00 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406111446.AA02184@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: What exactly *is* the need for suspend/resume? > From: thenrion@netcom.com (Tim Henrion) > ... > The PPP RFC states that when a link goes down, LCP SHOULD > inform the upper layers. What is an "upper layer" and what is it required to do about anything? In the most common TCP/IP code, there is no upper layer state in IP to change. At most you would change some state in the network interface. You would not because you cannot do anything to IP. You could, but only if you do not understand, do something to TCP connections that have a cached route through the downed PPP link. > I feel that the implications of the current demand-dial > implementations, specifically their implications in the > routing world, need to be weighed further. Fine. It would also be really swell if you would look into how demand dialing is currently working for thousands of people. > Because the current DD model does not inform the upper layers until > a window of time after the link has terminated, invalid routes > may exist during that window, especially if the call cannot be > re-established within the window. What "window" is that? It cannot be a TCP window. Perhaps it is an upper layer timeout. If your demand-dialing PPP code cannot re-establish the link before TCP would time out, then what do you do except let TCP time out? > If the call is dropped due to > any action other than a suspension, the upper layers should be > informed immediately to avoid having a window of bad routes across > the dead interface. Albeit adding suspend/resume will not eliminate > this problem, That is almost entirely wrong and contains incorrect assumptions about how upper layers work, at least for TCP, IP, and UDP. There is no upper layer you could or should inform about most suspension, and at least for TCP/IP, there is nothing, NOTHING, that you could, would, or should do to the TCP state, with the possible exception of cache routes (an "unclean" layering violation) and RTT estimate. > it will minimize it in this particular type of > failure condition. It would also allow the routing state > on both sides of the link to be consistent. What "failure condition" are you talking about? Do you mean dropped packets or connections? How would you change any state anywhere to prevent that if the re-call took too long? > When I talk about about interoperability between DD implementations, > I am specifically referring to consistency of routing state between > each peer on the link. For example my PPP implementation, which would > "architecturally correct" would inform the upper layers on the Down > condition so that routing states would be accurately updated. > Vernon's would not. This would cause routing state inconsistencies > on opposite ends of the link. This is what I mean by "interoperability > problems". My code involves no "routing inconsistencies." As far as the upper layers are concerned, sometimes my links have very high latencies. Sometimes packets are delayed by up to 30 seconds. Nevertheless, the packets will still flow. THE ROUTES ARE CONSISTENT! Your entire assumption that LCP should tell something related to routing about the suspension of the link is flawed. If you could tell your routing code about the suspension, then YOUR ROUTING CODE WOULD HAVE TO IGNORE THAT INFORMATION! Your routing code must continue to advertise the link through the suspended link just as if it were not suspend, just as if it were not informed. The only other choice is to not advertise the route, and if you do that, then you will never have any packets to send over the link and so will never restore it. Similarly, if you could tell your upper layers, then YOUR UPPER LAYERS WOULD HAVE TO IGNORE THAT INFORMATION, with the possible exception of adjusting RTT estimates. > Once again, I advocate separate "Down" and "Suspended" actions > which ride along with suspend/resume functionality to allow DD > implementations to interoperate more cleanly in this regard. Cleanliness matters only if you do something different. Exactly what would any IP, TCP, or UDP code do differently if informed about the suspension of a PPP link? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Sat Jun 11 10:50:48 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA26736 for ; Sat, 11 Jun 1994 10:50:47 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for ietf-ppp@merit.edu id AA16759; Sat, 11 Jun 94 07:50:43 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA02205; Sat, 11 Jun 94 08:50:13 -0600 Date: Sat, 11 Jun 94 08:50:13 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406111450.AA02205@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections (fwd) > From: thenrion@netcom.com (Tim Henrion) > > Karl Fox writes: > > > In routers, the upper layers (IP and IPX are upper layers to PPP) are > > > always busy making sure thier routing information is up to date. By > > > telling them the lower layer is down (with a REASON), they can either > > > spoof as necessary, or invalidate some of thier routing entries. > > > > Right. As Vernon described, you assume that the virtual link is up > > until you try to use it and it fails. This technique works; try it. > > > > Great. On an analog phone line, how long is it going to take > to figure out that you can't connect to the other side anymore > (because he croaked and dropped the line)? 30 or 60 seconds? > That technique may work but it's pretty darn crude. What would you do instead? > One of the main benefits of adding suspend/resume support is > that you really *know*, at disconnect time, the true state of > the link. Routes can be invalidated and routing consistency > maintained *immediately* instead of waiting 60 seconds > for an call to fail. If you invalidate routes, then you have introduced a routing inconsistency. A route means that you are prepared to move packets. That is exactly what a demand-dialed link is intended to do, regardless of whether is active or not. As far as I can see, you feel that demand-dialing is a bad feature. You want us to kill all routes through demand-dialed links as soon as the link is turned off. That would completely destroy the utility of demand dialing. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Sat Jun 11 11:08:02 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA27383 for ; Sat, 11 Jun 1994 11:08:02 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for ietf-ppp@merit.edu id AA17579; Sat, 11 Jun 94 08:07:57 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA02261; Sat, 11 Jun 94 09:07:25 -0600 Date: Sat, 11 Jun 94 09:07:25 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406111507.AA02261@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections (fwd) >From: klos@mv.MV.COM (Patrick Klos) > ... >When using NCP (Netware Core Protocol), you cannot easily recover when >logged into a file server, running Windows, and the file server decides >you're no longer logged in (after a connection is re-established). Since >we have no control of NCP under Windows, we'd like to put the control where >we have control. Do you understand all the issues involved in IPX and NCP >over PPP, and what is involved in supporting demand dialing for such an >environment?? > >>I hope you won't be offended if I remain unconvinced by your argument. PPP >>has suffered from a severe case of "creeping featurism" for much of its >>life. I hope that you will forgive me and others who have lived with this >>for 6 years when we are reluctant to add YAO (Yet Another Option) when the >>option is arguably not required. > >This is not "Yet Another Option". It is a useful feature for protocols >that are not as flexible (or easy to fool) as IP. > >>Again, if you can show me that you cannot make things work without the >>option, I will be happy to support a new option. My experience leads me to >>believe that this option really isn't needed. > >I've presented my case a few times, and again above. Uh, you've shifted cases. This time, you've mentioned how much hassle it is to restore state However, the problems you've described are exactly the same as the ones I suffer and why I put a primitive version of demand-dialing in my SLIP code about 6 years ago. It is a royal pain to set up a bunch of X-windows and other TCP state and then have a bouncing modem mess things up. You have not said just what the upper layers would do with this information about a suspended instead of finished IPX connection. All you have said is that 1. for suspended links, more resources and saved state should be retained for a while 2. for finished links, those resources and saved state can be discarded immediately. In real life, you will cannot do (2). In real life your commecial code will have to save those resources and state for a supposedly finished link for a little while for several reasons. For one, you'll need to save the addresses to avoid re-assigning them to a new use in order to ensure routing stability. You'll probably also save the rest of the state and resources for a little while in case the DOS user calls back after a change of mind. Thus, the only thing you could do with a "suspend/done" indication is change how long you save those resources and state. Are you sure that is worth the hassle of yet another PPP option? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Sat Jun 11 14:07:11 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA06069 for ; Sat, 11 Jun 1994 14:07:11 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for ietf-ppp@merit.edu id AA28494; Sat, 11 Jun 94 11:07:07 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA03192; Sat, 11 Jun 94 12:06:35 -0600 Date: Sat, 11 Jun 94 12:06:35 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406111806.AA03192@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: I'm wrong I'm wrong about how to make PPP connection re-establishment blazingly fast, but the error can be corrected. I forgot about the configure-Acks needed to get LCP into Opened. Case I. you know the identity of the peer, perhaps from calling number ID or from UNIX getty/login. In this case, send the following train of PPP packets: your LCP configure-request LCP configure-Ack for the anticipated request of the peer. two PAP or CHAP packets your NCP configure-requests NCP configure-Acks for the anticipated requests of the peer. The Acks contain the ID's and other stuff you expect the peer to be sending even as you are sending your packet train. Yes, that means that you have somehow, probably by prior arrangement, agreed on how to compute the timestamps for the CHAP challenge and you have reasonably synchronized clocks. You will have also agreed on how you will pick ID's for each of those packets, perhaps "0 for the first packets and then a newly seeded random string for subsequent packets of the same kinds". Case II. you do not know the identity of the peer. In this case: do normal LCP and authentication negotiation. Send a train of PPP packets: your NCP configure-requests NCP configure-Acks for the anticipated requests of the peer. If you could have used a "resume" packet, then this scheme works. When this scheme does not work, then it is because the peer doesn't want the same stuff as last time or bits get lost, and a "resume" request cannot work either. In other words, this works exactly when a "resume" mechanism can work, and it is very nearly as fast. The only special hack is anticipating the ID's of the peer's configure requests. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Sun Jun 12 11:20:38 1994 Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA04890 for ; Sun, 12 Jun 1994 11:20:37 -0400 Received: by ftp.com ; Sun, 12 Jun 1994 11:20:29 -0400 Received: by ftp.com ; Sun, 12 Jun 1994 11:20:29 -0400 From: wilson@ftp.com (Brad Wilson) Message-Id: <9406121520.AA10303@ftp.com> Subject: Re: suspend/resume; virtual connections To: klos@mv.mv.com (Patrick Klos) Date: Sun, 12 Jun 1994 11:20:29 -0400 (EDT) Cc: bill.simpson@um.cc.umich.edu, ietf-ppp@merit.edu In-Reply-To: <199406110022.UAA22182@mv.mv.com> from "Patrick Klos" at Jun 10, 94 08:22:45 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1082 >> No one is trying to re-invent demand dialing for IP (not that I know >> of). Other protocols have different issues for demand dialing. That's really the issue, isn't it. It already works for IP, so the IP people don't want something unnecessarily complex. And I don't think anyone could presume to invent a suspend/resume sequence that covers all current and future protocols. So why don't you change the protocols that require additional support; you claim IPX needs it, and IP doesn't, so why put it at the LCP level? Are you certain what you design today will be the best for now and all future protocols? -- Brad Wilson | Internet: wilson@ftp.com | #include FTP Software, Inc. | Voice: +1 800 282 4387 | #include 2 High Street | Facsimile: +1 508 659 6297 | #include N. Andover, MA 01845 | Support: support@ftp.com | msg++; smiley++; "If friends impose on you to babysit, it is within your rights to convert the child to a new religion." -- Dogbert, "Clues for the Clueless" - - - - - - - - - - - - - - - - - From list-admin Sun Jun 12 16:50:10 1994 Received: from pm002-04.dialip.mich.net (pm002-04.dialip.mich.net [35.1.48.85]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA20813 for ; Sun, 12 Jun 1994 16:50:05 -0400 Date: Sun, 12 Jun 94 19:46:49 GMT From: "William Allen Simpson" Message-ID: <2615.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Compelling requirements .... > From: thenrion@netcom.com (Tim Henrion) > To: vjs@rhyolite.wpd.sgi.com > > YOU MUST ABSOLUTELY ALWAYS OMIT POSITIVELY EVERY > > FEATURE WITHOUT A COMPELLING REQUIREMENT. > > > > Boy, I'd love to see the "compelling requirements" for some > of the stuff in the spec right now... > I clearly and unequivically agree with Vernon's statement. We just don't agree that compelling means "useful to SGI". May I suggest that you read the archives for the early rationale, or ask some of the more experienced hands privately. Let me assure you, there was significant multi-vendor support for every feature in the PPP LCP and PPP HDLC RFCs. Many other proposals were winnowed away, combined, or discarded for lack of support. > > PPP is already bloated beyone belief. E.g. > > - link quality is rarely used and of at best limited utilty. > > - magic numbers are not really useful for detecting loop backs > > because that's not a common failure mechanism. > > - the "time remaining" facility has already been mentioned. > > - why 2 different authentication mechanisms? > > - self-describing-padding is rarely if at all used and the > > wrong way to handle the problem (i.e. more bits than > > alternatives) > > > > I agree that there's a lot of crap in PPP. I don't use it > and I still sleep well at night. > Vernon has a long history of saying such inflammatory statements. They are best ignored, because of his limited experience. LQM was designed for and by several medium and high-speed link vendors. It has no use on low-speed error correcting modems. Loop-backs and crossed-connections are historically a very common mode of failure in environments with large modem banks and patch panels. I answered time remaining in another message. There are at least 3 more authentication mechanisms in the pipe. The field is expanding, not contracting. To my knowledge, no one has specified an alternative to self-defining pads. They were first proposed by our fearless leader (before he was chair), and offer a very useful facility to those who have such hardware padding requirements. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Sun Jun 12 16:50:20 1994 Received: from pm002-04.dialip.mich.net (pm002-04.dialip.mich.net [35.1.48.85]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA20888 for ; Sun, 12 Jun 1994 16:50:16 -0400 Date: Sun, 12 Jun 94 20:20:42 GMT From: "William Allen Simpson" Message-ID: <2617.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: Question on CHAP NAMEs > From: ed_allen@wellfleet.com (Ed Allen) > Since some of us may be a bit weary from the suspend/resume > conversations I thought I'd give us a new and less controversial > thread. > Thanks. > What do routing implementations use for CHAP NAMEs? > Usually the configured name of the site. For example, three routers at the main office will all be named "main office", and any routers at each branch will be named "Branch #1", etc. > Is the value contained in a NAME consistent across all > Challenge/Responses within a given LCP connections? > Yes. One name for the Challenger, a different name for the Responder. > Is the NAME a router uses consistent across all LCP connections > until the router is reconfigured? > Usually. Often, consistent for every NAS in an administrative domain. > Do all routers allow the NAME to be configured? > All that I have tested. > Do any vendors "hardcode" the NAME to be the value of a backplane > ID, or a MAC address, or similar? > None that I have tested. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Sun Jun 12 16:50:24 1994 Received: from pm002-04.dialip.mich.net (pm002-04.dialip.mich.net [35.1.48.85]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA20917 for ; Sun, 12 Jun 1994 16:50:21 -0400 Date: Sun, 12 Jun 94 20:28:20 GMT From: "William Allen Simpson" Message-ID: <2618.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Why virtual connections.... Aha! I think I finally understand why these folks want the PPP link-layer to maintain a virtual connection for them: > From: Patrick Klos > Since > we have no control of NCP under Windows, we'd like to put the control where > we have control. > Because they have no control over the IPX routing code, they want to put network-layer assistance in the link-layer code. While I am not a strict layerist (an understatement), this is not a convincing argument. I do not believe we should "standardize" bad or problematic implementation practices. The fact that the PPP link has gone down SHOULD NOT affect the network-layer advertisements above it. In order for the link to come back when more traffic arrives, the routing protocol MUST continue advertising the availability of the route. I would suggest that in your implementation, since you have no control of the application, you insert a Network-Layer Dependent Convergence Function specific to your circumstances between PPP and IPX, which handles the spoofing required for IPX. PPP does not provide virtual connections. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Sun Jun 12 16:50:16 1994 Received: from pm002-04.dialip.mich.net (pm002-04.dialip.mich.net [35.1.48.85]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA20849 for ; Sun, 12 Jun 1994 16:50:10 -0400 Date: Sun, 12 Jun 94 20:03:34 GMT From: "William Allen Simpson" Message-ID: <2616.bill.simpson@um.cc.umich.edu> To: ietf-ppp Reply-to: bsimpson@morningstar.com Subject: demand-dialing > From: Allen Rochkind/HQ/3Com > By "transparently" I meant that the upper layers and their associated NCP > sessions would not see the LCP connection going up and down. As far as the NCP > is concerned the LCP never changed. By your contribution below, that is not > what the current specs say. > Karl is correct. When LCP is Down, the NCPs are Down as well. When LCP re-negotiates, the NCPs re-negotiate as well. > The above is my understanding of what the current specs seem to imply for dial > on demand implementations. My question is whether we really want things to > work this way. Yes. > If as was suggested before, dial on demand is really supposed > to provide to upper layers (in routers the network layer protocols) a > transparent virtual "permanent connection", do we really want the transient > state of the line to affect the state (of the NCP connection) of the specific > upper layer protocols? Shouldn't the NCP sessions keep working without > interruption regardless of what the line physical line is doing below in dial > on demand mode? > PPP is a connectionless protocol. This is clearly specified in the requirements (RFC-1547). There is no such thing as a "transparent virtual permanent connection". NCPs have no session. They are helpers for the upper-layers, and nothing more. > If people are happy with the situation whereby the NCP is renegotiated each > time the dial on demand line goes up and down, then I do not think we have to > talk about suspend/resume further. I am happy. There is a certain subset of LPDN folks whose vendors charge on a per packet basis which are unhappy. I aways encourage such vendors to go bankrupt at the earliest possible opportunity, by organized boycott of their services. > My impression is that PPP got specified before dial on demand implementations > really started to proliferate. Nothing could be further from the truth! I was first involved from an async link project. The first major supporter of PPP (the first BOF was in his room, before my time), later became the leader of the NetBlazer project at Telebit, which was one of the first dial-on-demand products. However, PPP is useful for many kinds of service, and I tried to keep my wording in terms that were not specific to one kind of media. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Mon Jun 13 06:03:05 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id GAA29851 for ; Mon, 13 Jun 1994 06:03:04 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id GAA19813; Mon, 13 Jun 1994 06:03:02 -0400 Date: Mon, 13 Jun 1994 06:03:02 -0400 From: Patrick Klos Message-Id: <199406131003.GAA19813@mv.mv.com> To: ietf-ppp@merit.edu, vjs@rhyolite.wpd.sgi.com Subject: Re: suspend/resume; virtual connections (fwd) >You have not said just what the upper layers would do with this >information about a suspended instead of finished IPX connection. >All you have said is that > > 1. for suspended links, more resources and saved state should be > retained for a while > > 2. for finished links, those resources and saved state can be > discarded immediately. > >In real life, you will cannot do (2). In real life your commecial code >will have to save those resources and state for a supposedly finished >link for a little while for several reasons. For one, you'll need to >save the addresses to avoid re-assigning them to a new use in order to >ensure routing stability. You'll probably also save the rest of the >state and resources for a little while in case the DOS user calls back >after a change of mind. > >Thus, the only thing you could do with a "suspend/done" indication is >change how long you save those resources and state. EXACTLY! YES! That sounds fine to me! >Are you sure that is worth the hassle of yet another PPP option? In my honest opinion, Y E S ! I wouldn't be making such a fool of myself on this mailing list if I didn't think it was worth it! > >Vernon Schryver, vjs@sgi.com > Patrick Klos klos@mv.mv.com - - - - - - - - - - - - - - - - - From list-admin Mon Jun 13 06:35:22 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id GAA01340 for ; Mon, 13 Jun 1994 06:35:22 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id GAA21312; Mon, 13 Jun 1994 06:35:20 -0400 Date: Mon, 13 Jun 1994 06:35:20 -0400 From: Patrick Klos Message-Id: <199406131035.GAA21312@mv.mv.com> To: ietf-ppp@merit.edu, wilson@ftp.com Subject: Re: suspend/resume; virtual connections >>> No one is trying to re-invent demand dialing for IP (not that I know >>> of). Other protocols have different issues for demand dialing. > >That's really the issue, isn't it. It already works for IP, so the IP >people don't want something unnecessarily complex. And I don't think >anyone could presume to invent a suspend/resume sequence that covers >all current and future protocols. Yes, IP works fine without it. And maybe we couldn't presume to invent a perfect suspend/resume like you say. But we could invent one that will be useful to at least several protocols, if not more. >So why don't you change the protocols that require additional support; >you claim IPX needs it, and IP doesn't, so why put it at the LCP level? >Are you certain what you design today will be the best for now and all >future protocols? No one said the changes HAD to be at the LCP level! I am not against adding this wherever appropriate. One of the suggestions for implementation implied that only LCP would even have to know what happened to the link (since it is the Link Control Protocol). If that's too general or too vague, I don't have a problem with that! I think adding the function at the LCP layer would help make the implementation more generic and simpler, but I am not against adding the suspend/resume functionalty to each protocol as they need (if that's the general concensus). >Brad Wilson | Internet: wilson@ftp.com | #include >FTP Software, Inc. | Voice: +1 800 282 4387 | #include >2 High Street | Facsimile: +1 508 659 6297 | #include >N. Andover, MA 01845 | Support: support@ftp.com | msg++; smiley++; Patrick Klos klos@mv.mv.com - - - - - - - - - - - - - - - - - From list-admin Mon Jun 13 06:25:40 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id GAA00800 for ; Mon, 13 Jun 1994 06:25:39 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id GAA20787; Mon, 13 Jun 1994 06:25:35 -0400 Date: Mon, 13 Jun 1994 06:25:35 -0400 From: Patrick Klos Message-Id: <199406131025.GAA20787@mv.mv.com> To: brian@lloyd.com, klos@mv.MV.COM Subject: Re: suspend/resume; virtual connections (fwd) Cc: ietf-ppp@merit.edu >>Did someone have to prove that every option currently in the PPP specs was >>absolutely necessary, and could not make a simpler case work?!? > >In essence? Yes! It started out fairly simple and people implemented. I don't recall any debates over which options were absolutely necessary before!? Both "Identification" and "Time-Remaining" packets are LCP extensions that are of questionably insignificant value. Sure, it's "nice" to have such information, but I don't see any REAL VALUE for them. And I certainly don't recall any postings recommending they be added with accompanying PROOF of failure to operate without them! >Only after significant experience did things change. More recently there >has been more acceptance of the, "just add it because someone wants it and >then don't use it," school of thought. I come from the, "what is the >absolutely simplest thing we can do that will be sufficient," school. I >have looked at what you desire and I believe that it is unnecessarily >complex. I have seen a number of IPX-over-PPP implementations and they >work without the changes you propose. Have you seen any IPX-over-PPP with proper demand-dialing support? I would like to know who has one? >>I have >>already made a case as to why it would be extremely useful to support >>suspend/resume for IPX. Without it, demand-dialing would be nothing but >>a kludge when IPX is involved. > >Again, personal speculation. If you want to implement something and then >show everyone how much better it *works*, you will find the working group >much more receptive. > >>When using NCP (Netware Core Protocol), you cannot easily recover when >>logged into a file server, running Windows, and the file server decides >>you're no longer logged in (after a connection is re-established). > >So what do you do if you are logged into a file server and someone reboots >that server? I don't think that the situation is any different. You must >deal with that case whether or not you are using a dial-up link. You can >always bring the link back up to check status. The point I am making is >that you still must deal with that special case whether or not the link is >up. If a file server goes down, there's nothing an IPX Router can do!! You're talking about a totally unrelated situation! We're not trying to solve a "how do I recover a demand-dialined link to a file server after it's gone down"! If that's the "special case" you're referring to in your last line, I disagree. Only the client would have to deal with that case when it was to comminucate with the server again. When that occurs, the client will realize that the connection to that file server is no longer valid, and be forced to log in again anyway. That has nothing to do with routing or the demand-dial capability we're looking to enhance. >>Since >>we have no control of NCP under Windows, we'd like to put the control where >>we have control. Do you understand all the issues involved in IPX and NCP >>over PPP, and what is involved in supporting demand dialing for such an >>environment?? > >>This is not "Yet Another Option". It is a useful feature for protocols >>that are not as flexible (or easy to fool) as IP. > >This is a matter of opinion. Yes. It happens to be my opinion! >>>Again, if you can show me that you cannot make things work without the >>>option, I will be happy to support a new option. My experience leads me to >>>believe that this option really isn't needed. >> >>I've presented my case a few times, and again above. > >Yes, you have presented your case. I would say that few are convinced. >Certainly I remain unconvinced. Since this discussion is going nowhere, I >am going to stop reading this thread. Actually, I think it is going somewhere. Maybe slowly, but I think the point is moving. As far as your desire to stop reading this thread, fine. You've expressed your opinions. We won't bother you anymore with this topic you find so useless. >Brian Lloyd, President Lloyd Internetworking >brian@lloyd.com 3031 Alhambra Drive >(916) 676-1147 - voice Suite 102 >(916) 676-3442 - fax Cameron Park, CA 95682 Patrick Klos klos@mv.mv.com - - - - - - - - - - - - - - - - - From list-admin Mon Jun 13 07:12:00 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id HAA03386 for ; Mon, 13 Jun 1994 07:11:57 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id HAA26182; Mon, 13 Jun 1994 07:11:53 -0400 Date: Mon, 13 Jun 1994 07:11:53 -0400 From: Patrick Klos Message-Id: <199406131111.HAA26182@mv.mv.com> To: bill.simpson@um.cc.umich.edu Subject: Re: Why virtual connections.... Cc: ietf-ppp@merit.edu >Aha! I think I finally understand why these folks want the PPP >link-layer to maintain a virtual connection for them: > >> From: Patrick Klos >> Since >> we have no control of NCP under Windows, we'd like to put the control where >> we have control. >> >Because they have no control over the IPX routing code, they want to put >network-layer assistance in the link-layer code. Actually, the IPX routing code is the one thing we do have control over! (draw yourself a picture) We don't have control of a Novell file server that will "logout" a user it hasn't heard from for 15 minutes. Do we force all demand-dial implementations for IPX to reconnect at least every 14 minutes so that the file server connections can be maintained?? What are people doing when they "monitor" TCP packets to determine how many sessions might be running over thier PPP link?? Might that not be called "network-layer assistance in the link-layer code"?? The "assistance" being that the link-layer will try to not go away while the network layer is still possibly using the link layer. >While I am not a strict layerist (an understatement), this is not a >convincing argument. I do not believe we should "standardize" bad or >problematic implementation practices. In a perfect world, there would be no "bad or problematic implementation practices", but there's no such thing as a perfect world! We can't tell Novell to stop logging out users just because they didn't hear from the user for 15 minutes. But if that user wants to dial-in and remain logged in to the server, but have the luxury of hanging up the phone line when it's not being used, we need to provide a mechanism to provide the best that we can. >The fact that the PPP link has gone down SHOULD NOT affect the >network-layer advertisements above it. In order for the link to come >back when more traffic arrives, the routing protocol MUST continue >advertising the availability of the route. In a normal implementation, the fact the the PPP link has gone down should ABSOLUTELY affect the network-layer advertisements above it!! Only when a demand-dialing feature were desired would you not want to affect the network layer advertisements. Of course, in order for the line to come back when more traffic arrives, the router must give the external appearance that the routes (and services) are still there, but ONLY IN A DEMAND DIALED ENVIRONMENT! Why continue to advertise a route to a client that has hung up the phone and turned off the equipment?!? There is a distiction between a connection waiting to have some traffic cross it and one that knows when it's no longer needed!! >I would suggest that in your implementation, since you have no control >of the application, you insert a Network-Layer Dependent Convergence >Function specific to your circumstances between PPP and IPX, which >handles the spoofing required for IPX. Call it what you will, it's still useless without knowing why a link went down or if it's expected to return. Just because IP can live with a specific set of rules for demand-dialed connections doesn't mean that all protocols can (or should)! >PPP does not provide virtual connections. What would you refer to demand-dialing for IP as?? >Bill.Simpson@um.cc.umich.edu Patrick Klos klos@mv.mv.com - - - - - - - - - - - - - - - - - From list-admin Mon Jun 13 10:29:55 1994 Received: from netcom.com (netcom10.netcom.com [192.100.81.120]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id KAA17151 for ; Mon, 13 Jun 1994 10:29:54 -0400 Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom) id HAA03272; Mon, 13 Jun 1994 07:30:08 -0700 Date: Mon, 13 Jun 1994 07:30:08 -0700 From: thenrion@netcom.com (Tim Henrion) Message-Id: <199406131430.HAA03272@netcom.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections (fwd) > > I don't recall any debates over which options were absolutely necessary > before!? Both "Identification" and "Time-Remaining" packets are LCP > extensions that are of questionably insignificant value. Sure, it's > "nice" to have such information, but I don't see any REAL VALUE for them. > And I certainly don't recall any postings recommending they be added with > accompanying PROOF of failure to operate without them! > Pat, Don't bitch too loud about "Identification" just yet... It's the only LCP command that allows you to send arbitrary data to the LCP on the other side. This may prove to be quite useful for negotiating "vendor-specific options". :-) Tim Henrion Principal Software Engineer Extension Technology Corporation 30 Hollis Street Framingham, MA 01701 Phone: (508) 872-7748 FAX: (509) 872-7533 Internet: thenrion@netcom.com - - - - - - - - - - - - - - - - - From list-admin Mon Jun 13 10:24:28 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id KAA16782 for ; Mon, 13 Jun 1994 10:24:27 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id KAA19544; Mon, 13 Jun 1994 10:24:25 -0400 Date: Mon, 13 Jun 1994 10:24:25 -0400 From: Patrick Klos Message-Id: <199406131424.KAA19544@mv.mv.com> To: jhalpern@mako.Newbridge.COM Subject: Re: suspend/resume; virtual connections (fwd) Cc: ietf-ppp@merit.edu >The question with suspend/resume is not whether IPX would find it useful. >I can understand your desire to retain state. > >The question, as I see it, is adding another, unreliable, mechanism to >the spec purely to extend the timeout on state retention. And, since >there is no way at suspend time to estimate the duration, this could make >for very long irrelevant state retention. It seems simpler just to set >the timers for state retention on the server side as the operator of the >server wants them. If everything is working (which is the usual case), >then terminates will arrive for properly terminated connection, and >everything else can be retained with the administrative times. The option would do more for IPX than define 2 timeout periods; it would also provide for a known intentional shutdown of the link, basically offering 3 forms of link shutdown: 1) Terminate ala PPP, means the driver is unloading or somehow done. No further use of this connection will be needed. 2) Lost connection due to phone lines or other events we are not necessarily in control of. Use a short (10 minutes) timeout for the connection state, giving the remote client (peer) a chance to re-establish the lost link. 3) SUSPEND; an intentional message of some sort that tells the peer that we don't feel an immediate need for the link (as it has probably been idle for a little while), and we'd like to shut down the link, but maintain the connection state for an indeterminate amount of time (which could still have a limit defineable in hours or days). I draw a BIG distinction between #2 and #3 (and #1 for that matter). #2 means the link got dropped and we don't know why. If the peer calls back soon, we'll still have thier information, but if they take too long, they'll need to start over. In contrast, #3 implies an intentional decision to shutdown the link with the explicit desire to maintain the connection information (for however long). On the other hand, #1 would be an explicit indication that the link, and any resources allocated to it, are known to no longer have value, and such resources could be released for use by others. >Other than two time-out values, what else would your option create? Along with two time-out values, it creates a distinction between the three forms of disconnect described above. >Yours, >Joel M. Halpern jhalpern@newbridge.com >Newbridge Networks Inc. Sincerely, Patrick Klos klos@mv.mv.com > - - - - - - - - - - - - - - - - - From list-admin Mon Jun 13 10:49:11 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA19177 for ; Mon, 13 Jun 1994 10:49:09 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for ietf-ppp@merit.edu id AA09221; Mon, 13 Jun 94 07:49:03 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA10421; Mon, 13 Jun 94 08:48:27 -0600 Date: Mon, 13 Jun 94 08:48:27 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406131448.AA10421@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections > >> No one is trying to re-invent demand dialing for IP (not that I know > >> of). Other protocols have different issues for demand dialing. > > That's really the issue, isn't it. It already works for IP, so the IP > people don't want something unnecessarily complex. And I don't think > anyone could presume to invent a suspend/resume sequence that covers > all current and future protocols. Not so. There are at least the following positions: 1. demand dialing in the same style as is cusomarily done for IP is too slow. 2. demand dialing as customarily done for IP does not work, and is not interoperable. 3. the customary IP demand dialing scheme does not work for other protocols, and the only way to make it work is to add suspend/resume options to LCP. 4. those protocols that cannot use the IP scheme should have something added to their NCP's. 5. the IP scheme is too expensive on packet switched networks that charge by the packet. 6. the IP scheme, which consists of hacks in code not really in either the PPP or upper layer code, can probably be done for other protocols. Some combinations have been advanced, such as ((3 or 4) and not 1). Those who hold (1), (2), and perhaps (5) are necessarily requiring that demand dialing be re-invented for IP. All except (5) have been pushed in the last 10 days. (1) has been advanced at least 3 times in the last 10 days. (1) and (4) have been pushed by the most people. (1) has come back every few months for years, and will continue to return until and unless an LCP suspend/resume option is defined. I appologize being abusive to those who hold (1) and (2). I think those positions can only be hold without really thinking about or using IP demand dialing, but it is tactless of me to say so. ] >Thus, the only thing you could do with a "suspend/done" indication is ] >change how long you save those resources and state. ] ] EXACTLY! YES! That sounds fine to me! ] ] >Are you sure that is worth the hassle of yet another PPP option? ] ] In my honest opinion, Y E S ! I wouldn't be making such a fool of myself ] on this mailing list if I didn't think it was worth it! = In a normal implementation, the fact the the PPP link has gone down should = ABSOLUTELY affect the network-layer advertisements above it!! Only when = a demand-dialing feature were desired would you not want to affect the = network layer advertisements. Of course, in order for the line to come = back when more traffic arrives, the router must give the external appearance = that the routes (and services) are still there, but ONLY IN A DEMAND DIALED = ENVIRONMENT! Why continue to advertise a route to a client that has hung up = the phone and turned off the equipment?!? There is a distiction between = a connection waiting to have some traffic cross it and one that knows when = it's no longer needed!! What is different about that for IPX? That entire paragraph sounds applicable to IP demand dialing? Do any of these IPX uses of demand dialing involve long periods of disconnection? Recent suspend/resume proposals suggest that no more than hours of disconnection are expected. If that is true, could the current time-remaining option be used? As far as IPX demand dialing is concerned, I've been told privately that: - The IPX/NCP watchdogs are not related to routing. They are like TCP keepalives but mandatory. - the solution being discussed is only for IPX workstations. Anything more requires spoofing of more than watchdogs. You would spoof any routes behind it if the PPP client is a router. You would also spoof any services being offered by the PPP client (be it a station, or a router with services behind it). - static routes are real and possible in IPX. - what is being done above PPP for IPX demand dialing is not covered by any open standards. The frames involved in NCP that have to be spoofed are not public information. For $10,000, Novell will tell you, along with the rest of NCP. So will a Sniffer. - Because IPX demand dialing is so dependent on Novell's trade secrets, it will be hard to standardize. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Mon Jun 13 11:29:53 1994 Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA22896 for ; Mon, 13 Jun 1994 11:29:51 -0400 Received: by ftp.com ; Mon, 13 Jun 1994 11:29:48 -0400 Received: by ftp.com ; Mon, 13 Jun 1994 11:29:48 -0400 From: wilson@ftp.com (Brad Wilson) Message-Id: <9406131529.AA03629@ftp.com> Subject: Re: suspend/resume; virtual connections To: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Date: Mon, 13 Jun 1994 11:29:47 -0400 (EDT) Cc: ietf-ppp@merit.edu In-Reply-To: <9406131448.AA10421@rhyolite.wpd.sgi.com> from "Vernon Schryver" at Jun 13, 94 08:48:27 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1003 >> 4. those protocols that cannot use the IP scheme should have >> something added to their NCP's. This is what I would advocate. Adding something to the LCP layer may have unknown implications when it's the NCP that it really belongs in. The dial on demand issues may be different on a per-protocol basis. >> 5. the IP scheme is too expensive on packet switched networks that >> charge by the packet. I would *love* to see this argument forwarded. ;-) >> 6. the IP scheme, which consists of hacks in code not really in either >> the PPP or upper layer code, can probably be done for other protocols. I would prefer that this option be taken whenever possible, because it doesn't require *both* sides to support to option in order for things to function. -- Brad Wilson, KA8RJS Email: wilson@ftp.com My title is *not* spokesman "I want to cut taxes 10% across the board" - Bill Clinton, seeking the US Presidency ... 6 months before he raised taxes. Vote in '96. - - - - - - - - - - - - - - - - - From list-admin Mon Jun 13 11:31:26 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA23338 for ; Mon, 13 Jun 1994 11:31:09 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for ietf-ppp@merit.edu id AA13545; Mon, 13 Jun 94 08:30:53 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA10753; Mon, 13 Jun 94 09:30:42 -0600 Date: Mon, 13 Jun 94 09:30:42 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406131530.AA10753@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: what's bloat I wish I'd saved that recent list of PPP features observed to be implemented at the most recent bake-off. Anything that has been around a while and that is not in more than 60% of observed implementations is dubious. Anything that has been around at least a year and is not in more than 20% is clearly protocol bloat. After dividing installations into districts, such as workstations and router boxes so that the numerically greater workstations do not skew the answer for dedicated routers, anything that is a year or two old and is not in active use in at least 20% of the installations of at least one district is protocol bloat. Bloat and vanity features eventually die. For example, I currently do not do LQM and rely upon either ISDN or modem signals to know when a link is dead. Second on my list of things to do is to fix that, to behave better on 3-wire async links or when customer are too pigheaded to follow the instructions and use modem cables that include DCD. I was going to implement LQM, but after noting how few people have implemented LQM and that echo's are required and so universally implemented, I'm going to use periodic echos instead, just as everyone else is already doing. Echos are simpler to implement and will always work, while LQM is a lot more work and will not always work. Thus, I'll probably never implement LQM, just like almost everyone else. (I don't mean to imply I'm being smart. I'm only describing a concrete example of typical implementor reasoning.) What will turn out to be bloat can usually be predicted. Optional features that duplicate other, easier or at least mandatory mechanisms are losers. For example, LQM was forseen as a loser because in real life you only care about (1) error statistics of real data and (2) the boolean indication "is the link broken." You can either develop an LQM protocol to monitor and inform everyone, or you can count FCS errors and send an occassional echo request to monitor, and let SNMP (or telnet-to-the-router) inform everyone. I recall that people made exactly this argument about LQM. (Not including me; I recall staying out of that fight.) As far as I can see, suspend/resume fits that profile. The purpose of suspend/resume seems to be to help minimize resources wasted on links that will not come back. High quality implementations will have hueristics that do the same thing (e.g. timers) whether suspend/resume exists or not. Unless suspend/resume is made mandatory, it will suffer the same fate as LQM of being rarely implemented and never relied upon. For already standardized NCP's, you can't make suspend/resume mandatory. You'll have to be upward compatible with existing implementations that do not have it and you will always have to deal with systems that do not support it, and so you'll learn to live without it, and so you'll never implement it. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Mon Jun 13 14:07:26 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA06413 for ; Mon, 13 Jun 1994 14:07:24 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for ietf-ppp@merit.edu id AA07102; Mon, 13 Jun 94 11:07:19 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA11266; Mon, 13 Jun 94 12:06:47 -0600 Date: Mon, 13 Jun 94 12:06:47 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406131806.AA11266@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections (fwd) If I could be sure that all of this suspend/resume would only apply to IPX, I'd shut up. However, all of the arguments for suspend/resume seem to apply equally to IP and IPX. IPX may be a little messier, it may involve trade secrets, and the tradition of hacking some code to do whatever is needed to fool other systems is not as strong, but those are the only differences I can see. > From: klos@mv.MV.COM (Patrick Klos) > ... > The option would do more for IPX than define 2 timeout periods; it would > also provide for a known intentional shutdown of the link, basically offering > 3 forms of link shutdown: > > 1) Terminate ala PPP, means the driver is unloading or somehow > done. No further use of this connection will be needed. > > 2) Lost connection due to phone lines or other events we are > not necessarily in control of. Use a short (10 minutes) > timeout for the connection state, giving the remote client > (peer) a chance to re-establish the lost link. > > 3) SUSPEND; an intentional message of some sort that tells > the peer that we don't feel an immediate need for the link > (as it has probably been idle for a little while), and we'd > like to shut down the link, but maintain the connection state > for an indeterminate amount of time (which could still have a > limit defineable in hours or days). > > I draw a BIG distinction between #2 and #3 (and #1 for that matter). #2 > means the link got dropped and we don't know why. If the peer calls back > soon, we'll still have thier information, but if they take too long, they'll > need to start over. In contrast, #3 implies an intentional decision to > shutdown the link with the explicit desire to maintain the connection > information (for however long). On the other hand, #1 would be an explicit > indication that the link, and any resources allocated to it, are known to > no longer have value, and such resources could be released for use by others. Won't you have to have at least a 5 minute timeout for #1? The most likely time to hear from a remote machine is just after it has signed off "permanently." People often turn things off, and then remember something else that needs to be done. How expensive is it to retain those IPX resources in #1 just in case? Would you really release all IPX resources? The main thing released in the IP world is the IP address. For IP that makes sense for Internet Service Providers who are selling FTP&Mosaic&shell-terminal-emulation over IP. Will there be similar anonymous services for IPX? People who run SMTP (email) or other fancier things on their IP/PPP links generally need permanent IP addresses. I would have guessed that IPX demand-dialing would be confined to similarly permanent connections of type #3 with practically infinite timeouts. When you get arround to implementating IPX demand dialing, I predict that you will choose to not distinguish between #2 and #3. You will decide that too many other implementations will do #2 when they mean #3. You will also decide that the loss of a SUSPEND message during #3 should not kill the session. You will decide that making SUSPEND be a separate message with a separate ACK before the Terminate-Ack and Terminate-Request takes too long and/or is too much hassle. In practice you will assume #2 is a #3 that went wrong, and use a long timeout. If that prediction is right, then the option does no more than adjust the timeout that holds onto resources from the few minutes in #1 to the much longer value in #3. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Mon Jun 13 14:40:08 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id OAA08958 for ; Mon, 13 Jun 1994 14:40:06 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id OAA28723; Mon, 13 Jun 1994 14:40:03 -0400 Date: Mon, 13 Jun 1994 14:40:03 -0400 From: Patrick Klos Message-Id: <199406131840.OAA28723@mv.mv.com> To: ietf-ppp@merit.edu, vjs@rhyolite.wpd.sgi.com Subject: Re: what's bloat >As far as I can see, suspend/resume fits that profile. The purpose of >suspend/resume seems to be to help minimize resources wasted on links >that will not come back. High quality implementations will have >hueristics that do the same thing (e.g. timers) whether suspend/resume >exists or not. Unless suspend/resume is made mandatory, it will suffer >the same fate as LQM of being rarely implemented and never relied >upon. For already standardized NCP's, you can't make suspend/resume >mandatory. You'll have to be upward compatible with existing >implementations that do not have it and you will always have to deal >with systems that do not support it, and so you'll learn to live >without it, and so you'll never implement it. I don't think I agree. Hueristics is a fancy name for "a good guesser". Guessing is not something routers should be doing. Having suspend/resume allows for a definable set of actions to occur based upon a definable event. I know suspend/resume will never be made mandatory, just as CHAP is not mandatory; yet some folks have CHAP and some folks don't. Compression protocols will be fun to see who implements what! It seems there are several "standard" compression protocols, yet who's going to implement them all?? Some will implement a common compression algorithm and benefit from interoperability, while others will stay with thier own proprietary algorithms. I have heard from several people privately indicating that they're interested in the concept of suspend/resume, just waiting for the dust to settle. >Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Mon Jun 13 15:23:58 1994 Received: from netmail.microsoft.com (netmail.microsoft.com [131.107.1.3]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id PAA12879 for ; Mon, 13 Jun 1994 15:23:57 -0400 From: andyni@microsoft.com Received: by netmail.microsoft.com (5.65/25-eef) id AA00592; Mon, 13 Jun 94 12:23:59 -0700 Received: by netmail using fxenixd 1.0 Mon, 13 Jun 94 12:23:59 PDT Message-Id: <9406071945.AA27183@itgmsm> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections Date: Tue, 07 Jun 94 12:39:00 PDT X-Mailer: Microsoft Mail V3.0 >> A while ago I seem to remember someone posting a suggestion for >>new LCP packet types to enable virtual connections, i.e. the ability to >>make a connection suspend (and hang up the phone) in the absense of any >>real user data traffic, then resume when there was traffic to send. That >> >I endorsed this idea at the time, but it was shot down by others as >unnecessary. I'm still not convinced it's unnecessary, and think it >would be a useful enhancement. Any other folks who think along the >same lines might want to speak up now, before we're urged not to try to >bring it up for discussion again. I agree that connection suspension would be valuable and worthwhile. Since PPP is attracting new protocols and features with no apparent end, I don't understand why a seemingly useful extension should be shot down as unnecessary. But then, between the IETF meeting where we discussed the "right way" to allow authentication retries, and the bakeoff, I implemented retries. At the bakeoff I found no other implementors who had actually done this. So I wonder if we might be seeing a divergence between the working group and the implementors taking place here. ----- Andy Nicholson Microsoft Corporation Microsoft wants nothing andyni@microsoft.com 1 Microsoft Way to do with my opinions. (206)936-3775 Redmond, WA 98052 - - - - - - - - - - - - - - - - - From list-admin Mon Jun 13 14:54:40 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id OAA10201 for ; Mon, 13 Jun 1994 14:54:36 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id OAA01979; Mon, 13 Jun 1994 14:54:27 -0400 Date: Mon, 13 Jun 1994 14:54:27 -0400 From: Patrick Klos Message-Id: <199406131854.OAA01979@mv.mv.com> To: brian@lloyd.com, klos@mv.MV.COM Subject: Re: Why virtual connections.... Cc: ietf-ppp@merit.edu >>>While I am not a strict layerist (an understatement), this is not a >>>convincing argument. I do not believe we should "standardize" bad or >>>problematic implementation practices. >> >>In a perfect world, there would be no "bad or problematic implementation >>practices", but there's no such thing as a perfect world! We can't tell >>Novell to stop logging out users just because they didn't hear from the >>user for 15 minutes. But if that user wants to dial-in and remain logged >>in to the server, but have the luxury of hanging up the phone line when >>it's not being used, we need to provide a mechanism to provide the best >>that we can. > >So both ends continue to spoof until they hear otherwise from the peer. >The goal is to simulate a permanent circuit with a demand-dial circuit. So >you always assume that the far end is there and that the info is valid. It >works. Sure, this works when you want both sides to continuously "think" the other side is there. For IPX that's true part of the time, but it's also wrong part of the time. When a remote client logs off the file server and unloads his/her driver, he/she NO LONGER wants the route between the client and the router to be advertised, as it is no longer a part of the network! What you're saying is fine for static routes (even IPX could support that), but a good amount of IPX-over-PPP users will be remote clients who may or may not require a simulated permanent circuit. IPX is not as simple and cut-and-dry as you imply it to be! >Brian Lloyd, President Lloyd Internetworking >brian@lloyd.com 3031 Alhambra Drive >(916) 676-1147 - voice Suite 102 >(916) 676-3442 - fax Cameron Park, CA 95682 Patrick klos@mv.mv.com - - - - - - - - - - - - - - - - - From list-admin Mon Jun 13 15:05:50 1994 Received: from apache.telebit.com (apache.telebit.com [143.191.3.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id PAA11175 for ; Mon, 13 Jun 1994 15:05:45 -0400 Received: from america.Sunnyvale.Telebit.CO (america-bb.sunnyvale.telebit.com) by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-930718) id AA06178 to ietf-ppp@merit.edu; Mon, 13 Jun 94 12:05:39 PDT Received: from yoyo.telebit.com by america.Sunnyvale.Telebit.COM (4.0/america.telebit.com-DBC-930718) id AA05277 to ietf-ppp@merit.edu; Mon, 13 Jun 94 12:04:44 PDT Date: Mon, 13 Jun 94 12:04:44 PDT From: mlewis@Telebit.COM (Mark S. Lewis) Message-Id: <9406131904.AA05277@america.Sunnyvale.Telebit.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA19577; Mon, 13 Jun 94 12:05:36 PDT To: vjs@rhyolite.wpd.sgi.com Cc: ietf-ppp@merit.edu In-Reply-To: <9406131530.AA10753@rhyolite.wpd.sgi.com> (vjs@rhyolite.wpd.sgi.com) Subject: Re: what's bloat Reply-To: Mark.S.Lewis@Telebit.COM Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII >>>>> On Mon, 13 Jun 94 09:30:42 -0600, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) said: > I wish I'd saved that recent list of PPP features observed to be > implemented at the most recent bake-off. Here it is again. ... Mark ==========-------------- Mark S. Lewis ----------========== Mark.S.Lewis@Telebit.com Telebit Corp. Voice (408) 745-3232 PPP Consortium Interoperability Testing April 18-22, 1994 The 3rd meeting of the PPP Consortium was completed in Redmond at host Microsoft. Twenty-eight (28) vendors met for an intensive week of interoperability testing. The full suite of PPP protocols was tested including IP, IPX, AppleTalk, and bridging. Almost all vendors were able to connect over dial-up async lines, sync leased-lines, and ISDN lines. Vendors made significant progress towards improving interoperability. They all found ways to improve their implementations like determining the best configuration options, adding authentication scripts, and fixing product bugs. Many vendors made corrections during the week and were able to confirm problem resolution. Survey Results -------------- Included below is a survey of PPP options implemented among the participating vendors. The data is reasonably accurate but a few disclaimers apply. This data describes implementations in various states of completion. Some implementations are being developed and are not yet in production. Some of the entries in the no options categories might not be correct, since there was not always enough information to determine which options were implemented for a given network protocol. Async PPP Options Implemented (25 total tested) Protocol Option Count -------- -------------------------------------------- ----- LCP Maximum-Receive-Unit (MRU) 25 LCP Async-Control-Character-Map (ACCM) 25 LCP Authentication-Protocol 20 LCP Quality-Protocol 4 LCP Magic-Number 25 LCP Protocol-Field-Compression (PFC) 25 LCP Address-and-Control-Field-Compression (ACFC) 24 LCP Identification 2 LCP Time-Remaining 1 PAP 18 CHAP 13 IPCP No Options 0 IPCP IP-Addresses (1) 11 IPCP IP-Compression-Protocol 21 IPCP IP-Address (3) 25 IPXCP No Options 3 IPXCP IPX-Network-Number 8 IPXCP IPX-Node-Number 8 IPXCP IPX-Compression-Protocol 5 IPXCP IPX-Routing-Protocol 2 IPXCP IPX-Router-Name 2 IPXCP IPX-Configuration-Complete 3 CIPX 5 IPXWAN 3 ATCP No Options 1 ATCP AppleTalk-Address 2 ATCP Routing-Protocol 2 ATCP Suppress-Broadcasts 2 ATCP AT-Compression-Protocol 1 ATCP Zone-Information 2 ATCP Default-Router-Address 2 Bridging 0 BCP 1 DNCP 0 OSINLCP 0 CCP 1 XNS 0 NBFCP 2 Sync PPP Implementations (10 total tested) Protocol Option Count -------- -------------------------------------------- ----- LCP Maximum-Receive-Unit (MRU) 10 LCP Authentication-Protocol 7 LCP Quality-Protocol 4 LCP Magic-Number 10 LCP Protocol-Field-Compression (PFC) 3 LCP Address-and-Control-Field-Compression (ACFC) 3 LCP Identification 0 LCP Time-Remaining 0 PAP 6 CHAP 4 IPCP No Options 2 IPCP IP-Addresses (1) 6 IPCP IP-Compression-Protocol 4 IPCP IP-Address (3) 8 IPXCP No Options 8 IPXCP IPX-Network-Number 1 IPXCP IPX-Node-Number 1 IPXCP IPX-Compression-Protocol 2 IPXCP IPX-Routing-Protocol 0 IPXCP IPX-Router-Name 0 IPXCP IPX-Configuration-Complete 0 CIPX 2 IPXWAN 4 ATCP No Options 4 ATCP AppleTalk-Address 0 ATCP Routing-Protocol 0 ATCP Suppress-Broadcasts 0 ATCP AT-Compression-Protocol 0 ATCP Zone-Information 0 ATCP Default-Router-Address 0 Bridging 3 BCP 3 DNCP 4 OSINLCP 2 CCP 1 XNS 1 Vines 2 PPP Reference Documents ----------------------- Baker, F., "Point-to-Point Protocol extensions for bridging", RFC 1220, April 1991 McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992 Simpson, W., "PPP Link Quality Monitoring" RFC 1333, May 1992 Lloyd, B., Simpson, W., "PPP Authentication Protocols" RFC 1334, October 1992 Senum, S., "The PPP DECnet Phase IV Control Protocol (DNCP)", RFC 1376, November 1992 Katz, D., "The PPP OSI Network Layer Control Protocol (OSINLCP)", RFC 1377, November 1992 Parker, B., "The PPP AppleTalk Control Protocol (ATCP)", RFC 1378, November 1992 Perkins, D., "Requirements for an Internet Standard Point-to-Point Protocol", RFC 1547 December 1993 Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1548, December 1993 Simpson, W., "PPP in HDLC Framing", RFC 1549, December 1993 Allen, M., "Novell IPX Over Various WAN Media (IPXWAN)", RFC 1551, December 1993 Simpson, W., "The PPP Internetworking Packet Exchange Control Protocol (IPXCP)", RFC 1552, December 1993 Mathur, S., Lewis, M., "Compressing IPX Headers Over WAN Media (CIPX)", RFC 1553, December 1993 Simpson, W., "PPP LCP Extensions", RFC 1570, January 1994 (Updates RFC 1548) Dimitri, T., "The PPP NetBIOS Frames Control Protocol (NBFCP)", work in progress, February 1994 Rand, D., "The PPP Contression Control Protocol (CCP)", work in process, March 1994 Baker, F., Bowen, R., "PPP Bridging Control Protocol (BCP)", work in progress, March 1994 PPP Consortium Participants --------------------------- Advanded Computer Commmunications 3Com Corporation Cayman Systems Cisco Systems Computone Corporation Digital Equipment Corporation FTP Software, Incorporated IBM Corporation Institute for Information Industry Taipei, Taiwan Klos Technologies Lachman Technologies Lantronics, Incorporated NEC America, Incorporated NetManage, Incorporated Network Application Technology Network Systems, Incorporated Networks Northwest, Incorporated Novell Microsoft Corporation Morning Star Technologies Proteon Shiva Corporation Spry, Incorporated SunSoft Telebit Corporation Wellfleet Communications Xylogics Xyplex Incorporated - - - - - - - - - - - - - - - - - From list-admin Mon Jun 13 15:54:21 1994 Received: from netmail.microsoft.com (netmail.microsoft.com [131.107.1.3]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id PAA15478 for ; Mon, 13 Jun 1994 15:54:20 -0400 From: andyni@microsoft.com Received: by netmail.microsoft.com (5.65/25-eef) id AA04195; Mon, 13 Jun 94 12:54:23 -0700 Received: by netmail using fxenixd 1.0 Mon, 13 Jun 94 12:54:23 PDT Message-Id: <9406072102.AA00762@itgmsm> To: ietf-ppp@merit.edu Subject: Why: suspend/resume; virtual connections Date: Tue, 07 Jun 94 12:58:00 PDT X-Mailer: Microsoft Mail V3.0 >>> A while ago I seem to remember someone posting a suggestion for >>> new LCP packet types to enable virtual connections, i.e. the ability to >>> make a connection suspend (and hang up the phone) in the absense of any >>> real user data traffic, then resume when there was traffic to send. That >>> way you could save phone carrier charges without actually bringing the PPP >>> link down as far as the protocol engine was concerned. Is anybody working > >Why is this necessary? I thought PPP was an unreliable delivery service. >What would be the advantage of such a system, besides (possibly) saving >you from renegotiating again? > PPP is actually a set of protocols for configuring point to point links to carry network protocols. The devices below provide the delivery service, and PPP stays mostly out of the way after the link is configured. But PPP supports the concept of link monitoring. It is not unreasonable to suggest that PPP might be smart enough to recognize that the link is unused and to suspend it to eliminate link related charges. Then when traffic returns, PPP could reestablish the link (on demand, don't you know) so that data can flow. All this could happen without user knowledge or intervention. There are issues, for example, I prefer to let the higher layers determine whether to drop the link. Whilst at Cray we had a project where we supported a connection switched T3 line based on attempts to route through it. I used the IP routing lookup to determine whether to activate or deactivate the link. But I added intelligence to TCP to recognize that we should drop the link during TIME-WAIT so that we didn't waste $120 during the 2 minute delay ($1 per second for the T3 line). If the filesystem has no active connections through the network, then it should have some say whether or not to keep the link active. But our networking architectures need to be a little better managed before any of this stuff will really work well. Cheers! ------ Andy Nicholson Microsoft Corporation Microsoft wants nothing andyni@microsoft.com 1 Microsoft Way to do with my opinions. (206)936-3775 Redmond, WA 98052 - - - - - - - - - - - - - - - - - From list-admin Mon Jun 13 16:46:40 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA19846 for ; Mon, 13 Jun 1994 16:46:40 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09228; 13 Jun 94 16:36 EDT To: IETF-Announce:; Cc: IESG cc: ietf-ppp@merit.edu From: IESG Secretary Subject: Last Call: The PPP Multilink Protocol (MP) to Proposed Standard Date: Mon, 13 Jun 1994 16:36:44 -0400 Sender: jstewart@IETF.CNRI.Reston.VA.US Message-ID: <9406131636.aa09228@IETF.CNRI.Reston.VA.US> The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider "The PPP Multilink Protocol (MP)" for the status of Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us, or ietf@cnri.reston.va.us mailing lists by 27 June. IESG Secretary - - - - - - - - - - - - - - - - - From list-admin Mon Jun 13 16:55:44 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA20494 for ; Mon, 13 Jun 1994 16:55:44 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09464; 13 Jun 94 16:41 EDT To: IETF-Announce:; Cc: IESG cc: ietf-ppp@merit.edu From: IESG Secretary Subject: Last Call: PPP in Frame Relay to Proposed Standard Date: Mon, 13 Jun 1994 16:41:12 -0400 Sender: jstewart@IETF.CNRI.Reston.VA.US Message-ID: <9406131641.aa09464@IETF.CNRI.Reston.VA.US> The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider "PPP in Frame Relay" for the status of Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us, or ietf@cnri.reston.va.us mailing lists by 27 June. IESG Secretary - - - - - - - - - - - - - - - - - From list-admin Mon Jun 13 17:35:33 1994 Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id RAA24043 for ; Mon, 13 Jun 1994 17:35:32 -0400 Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (5.65a/94040804) id AA21756; Mon, 13 Jun 94 17:34:59 -0400 From: Karl Fox Received: by gefilte.MorningStar.Com (5.65a/94012401) id AA01653; Mon, 13 Jun 94 17:34:58 -0400 Date: Mon, 13 Jun 94 17:34:58 -0400 Message-Id: <9406132134.AA01653@gefilte.MorningStar.Com> To: Patrick Klos Cc: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connections (fwd) In-Reply-To: <199406131424.KAA19544@mv.mv.com> References: <199406131424.KAA19544@mv.mv.com> Organization: Morning Star Technologies, Inc. Patrick Klos writes: > > The option would do more for IPX than define 2 timeout periods; it would > also provide for a known intentional shutdown of the link, basically offering > 3 forms of link shutdown: > > 1) Terminate ala PPP, means the driver is unloading or somehow > done. No further use of this connection will be needed. That isn't necessarily what Terminate-Request currently means. For example, some current dial on demand installations take it to mean `suspend'. Some take it to mean `I'm done'. Make sure your design accomodates current use. - - - - - - - - - - - - - - - - - From list-admin Mon Jun 13 17:38:45 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id RAA24168 for ; Mon, 13 Jun 1994 17:38:44 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09811; 13 Jun 94 16:54 EDT To: IETF-Announce:; Cc: IESG cc: ietf-ppp@merit.edu From: IESG Secretary Subject: Last Call: PPP Data Encapsulation and FR to Proposed Standard Date: Mon, 13 Jun 1994 16:54:01 -0400 Sender: jstewart@IETF.CNRI.Reston.VA.US Message-ID: <9406131654.aa09811@IETF.CNRI.Reston.VA.US> [The previous Last Call for "PPP in Frame Relay" alone was in error -- the two documents are being advanced together. Sorry.] The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider the Internet-Drafts: o "PPP LCP Option for Data Encapsulation Selection" o "PPP in Frame Relay" for the status of Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us, or ietf@cnri.reston.va.us mailing lists by 27 June. IESG Secretary - - - - - - - - - - - - - - - - - From list-admin Mon Jun 13 18:25:05 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id SAA27224 for ; Mon, 13 Jun 1994 18:25:04 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for ietf-ppp@merit.edu id AA20701; Mon, 13 Jun 94 15:24:59 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA12266; Mon, 13 Jun 94 16:24:52 -0600 Date: Mon, 13 Jun 94 16:24:52 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406132224.AA12266@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Why: suspend/resume; virtual connections > From: andyni@microsoft.com > ... > There are issues, for example, I prefer to let the higher layers determine > whether to drop the link. Whilst at Cray we had a project where we > supported a connection switched T3 line based on attempts to route through > it. I used the IP routing lookup to determine whether to activate or > deactivate the link. But I added intelligence to TCP to recognize that we > should drop the link during TIME-WAIT so that we didn't waste $120 during > the 2 minute delay ($1 per second for the T3 line). > > If the filesystem has no active connections through the network, then it > should have some say whether or not to keep the link active. How do you do that if you are not running PPP between a pair of hosts? If you are doing demand-dialed IP between a pair of routers (even workstations acting as routers), how does the PPP code know that the TCP state has reached TIME-WAIT on some distant host? How does PPP know about the state of file systems on remote hosts? The best work-around I've heard for the TCP part of the problem is to count TCP SYN's and FIN's in the PPP code, and adjust timeouts based on that. For example, my personal link runs with a 5 second timeout when it looks as if no active TCP connections are open, and 30 seconds the rest of the time. Unfortunately, the vaguries of routing and host timeouts mean that such snooping cannot be entirely accurate or reliable. Sometimes the router guesses wrong, but usually in the $30 direction. Note again that suspend/resume makes sense only for workstations that are not acting as routers (including $M supercomputer workstations). Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Tue Jun 14 00:03:05 1994 Received: from pm002-20.dialip.mich.net (pm002-20.dialip.mich.net [35.1.48.101]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id AAA19043 for ; Tue, 14 Jun 1994 00:03:02 -0400 Date: Tue, 14 Jun 94 03:11:52 GMT From: "William Allen Simpson" Message-ID: <2638.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: The meaning of Terminate > From: Karl Fox > Patrick Klos writes: > > > > 1) Terminate ala PPP, means the driver is unloading or somehow > > done. No further use of this connection will be needed. > > That isn't necessarily what Terminate-Request currently means. For > example, some current dial on demand installations take it to mean > `suspend'. Some take it to mean `I'm done'. Make sure your design > accomodates current use. > Karl is correct in that is not what Terminate-Request means. I disagree that it could ever mean either "Suspend" or "I'm Done". T-R merely means that the link is closing. It provides no reason. There are several reasons listed as to why it could be sent. You know that the link is Administratively Closed if you receive Terminate-Acks in response to a Configure-Request. You know that the driver is unloaded if you receive nothing at all. But that could very well be because the peer crashed or hung, common MS-Windows problems. There is no expectation that you will receive a T-R when the machine crashes, or even that it will hang up (DTR often stays high, keeping a modem on-line). In short, you never know what the terminate condition was until you attempt to re-connect. Having a special code will not improve this situation. We must design for reality. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Tue Jun 14 01:14:38 1994 Received: from lloyd.com (harry.lloyd.com [158.222.1.6]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id BAA23624 for ; Tue, 14 Jun 1994 01:14:37 -0400 Received: from [158.222.2.1] by lloyd.com with smtp (Smail3.1.28.1 #3) id m0qDQp6-00075DC; Mon, 13 Jun 94 22:14 PDT Message-Id: Date: Mon, 13 Jun 94 22:14 PDT X-Sender: brian@harry.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) From: brian@lloyd.com (Brian Lloyd) Subject: Re: what's bloat Cc: ietf-ppp@merit.edu >Bloat and vanity features eventually die. For example, I currently do >not do LQM and rely upon either ISDN or modem signals to know when a >link is dead. Well, we have LQM in our code and have found it to be very useful when trying to troubleshoot assymetrical link problems. No, you don't really need it but, if you have ever done any mechanical work, sometimes that one-of-a-kind, seldom-used tool is nice to have. Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 - - - - - - - - - - - - - - - - - From list-admin Tue Jun 14 09:28:13 1994 Received: from mv.mv.com (mv.MV.COM [192.80.84.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id JAA23562 for ; Tue, 14 Jun 1994 09:28:11 -0400 Received: by mv.mv.com (8.6.9/mem-931109) id JAA26895; Tue, 14 Jun 1994 09:27:45 -0400 Date: Tue, 14 Jun 1994 09:27:45 -0400 From: Patrick Klos Message-Id: <199406141327.JAA26895@mv.mv.com> To: karl@morningstar.com, klos@mv.MV.COM Subject: Re: suspend/resume; virtual connections (fwd) Cc: ietf-ppp@merit.edu >> The option would do more for IPX than define 2 timeout periods; it would >> also provide for a known intentional shutdown of the link, basically offering >> 3 forms of link shutdown: >> >> 1) Terminate ala PPP, means the driver is unloading or somehow >> done. No further use of this connection will be needed. > >That isn't necessarily what Terminate-Request currently means. For >example, some current dial on demand installations take it to mean >`suspend'. Some take it to mean `I'm done'. Make sure your design >accomodates current use. I am taking in all these comments. I certainly recognize that interoperability with existing implementations of PPP is the FIRST and FOREMOST consideration when proposing changes or enhancements. I am willing to concede that Terminate-Request has a specific meaning in current PPP implementations (a meaning that may not be consistant with the meaning under a suspend/resume environment). I will certainly keep in mind that a system implementing suspend/resume MUST be able to determine if the peer can support suspend/resume and be able to infer just what Terminate means in the context of that connection. Thanks for your comments, Patrick - - - - - - - - - - - - - - - - - From list-admin Tue Jun 14 10:03:58 1994 Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA26807 for ; Tue, 14 Jun 1994 10:03:56 -0400 Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (5.65a/94040804) id AA26261; Tue, 14 Jun 94 10:03:24 -0400 From: Karl Fox Received: by gefilte.MorningStar.Com (5.65a/94012401) id AA01771; Tue, 14 Jun 94 10:03:23 -0400 Date: Tue, 14 Jun 94 10:03:23 -0400 Message-Id: <9406141403.AA01771@gefilte.MorningStar.Com> To: bsimpson@MorningStar.Com Cc: ietf-ppp@merit.edu Subject: The meaning of Terminate In-Reply-To: <2638.bill.simpson@um.cc.umich.edu> References: <2638.bill.simpson@um.cc.umich.edu> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Bill Simpson writes: > > From: Karl Fox > > > > That isn't necessarily what Terminate-Request currently means. For > > example, some current dial on demand installations take it to mean > > `suspend'. Some take it to mean `I'm done'. Make sure your design > > accomodates current use. > > > Karl is correct in that is not what Terminate-Request means. I disagree > that it could ever mean either "Suspend" or "I'm Done". Wait a minute, look more carefully at my wording. I said that the *installations* have semantics, not the *implementations*. If I set up two dial-on-demand copies of Morning Star PPP on two machines such that either can call the other on demand, then the `virtual link' is always assumed to be up. Even if one end repeatedly tries to call the other and fails, it assumes that the peer will eventually come back up. The program `assumes' this because it never gives up attempting to reconnect -- it will gradually back off on its calling frequency, but it won't stop trying. TCP timers will eventually give up, but our PPP's implementation won't. In this case, a disconnect of any kind always means `suspend' in that both sides assume that the link will (or may) eventually be reestablished. On the other hand, consider a dial-in single-hunt-group POP (point of presence) belonging to an IP network provider that assigns IP addresses to dial-in customers based on the physical port that they attach to. Once they disconnect, whoever gets that port next is assigned the IP address given to the previous caller. Clearly, in this setup, a disconnect of any kind always means `I'm done', although the customer might wish differently. > T-R merely means that the link is closing. It provides no reason. > There are several reasons listed as to why it could be sent. Absolutely correct. The semantics are currently defined by the way the installer configures the overall behavior of IP addresses, IP interfaces, and routes. > You know that the link is Administratively Closed if you receive > Terminate-Acks in response to a Configure-Request. > > You know that the driver is unloaded if you receive nothing at all. > But that could very well be because the peer crashed or hung, common > MS-Windows problems. There is no expectation that you will receive a > T-R when the machine crashes, or even that it will hang up (DTR often > stays high, keeping a modem on-line). > > In short, you never know what the terminate condition was until you > attempt to re-connect. Even then you may not know. The peer might be temporarily down. > Having a special code will not improve this situation. We must > design for reality. Exactly. This has been my point all along; we have to consider how people *currently* *use* PPP in such a situation. Special codes can *never* be more than advisory, so you can never count on them having any effect at all. > Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Tue Jun 14 17:30:56 1994 Received: from pm002-14.dialip.mich.net (pm002-14.dialip.mich.net [35.1.48.95]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id RAA05288 for ; Tue, 14 Jun 1994 17:30:55 -0400 Date: Tue, 14 Jun 94 20:15:47 GMT From: "William Allen Simpson" Message-ID: <2662.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: The meaning of Terminate > From: Karl Fox > Wait a minute, look more carefully at my wording. I said that the > *installations* have semantics, not the *implementations*. > ... > > Having a special code will not improve this situation. We must > > design for reality. > > Exactly. This has been my point all along; we have to consider how > people *currently* *use* PPP in such a situation. Special codes can > *never* be more than advisory, so you can never count on them having > any effect at all. > Yes, you are quite correct. Thanks for the clarification. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Thu Jun 16 14:12:12 1994 Received: from tribe.tribe.com ([199.35.172.35]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA19940 for ; Thu, 16 Jun 1994 14:12:10 -0400 Received: from [199.35.172.67] by tribe.tribe.com (5.64/A/UX-3.00) id AA04026; Thu, 16 Jun 94 11:16:00 PDT Message-Id: <9406161816.AA04026@tribe.tribe.com> Date: Thu, 16 Jun 1994 10:21:11 -0800 To: ietf-ppp@merit.edu From: bill@tribe.tribe.com (Bill Jackson) X-Sender: bill@tribe.tribe.com Subject: AppleTalk over PPP test Cc: bill@tribe.tribe.com The AppleTalk Networking Forum is organizing a testing session for AppleTalk over PPP in conjunction with the Mactivity Trade Show in San Jose, July 19-21. Six vendors have already expressed interest via the AppleTalk Networking Forum mailing list (anf-disc@netcom.com), including Shiva, Novell, DEC, Cisco, Compatible Systems, and Tribe Computer Works. Are there others out there who are interested in participating? I realize that the PPP Consortium just held such an event two months ago, but there appears to be sufficient interest among AppleTalk vendors in another session specifically focused on AppleTalk over PPP. Testing could include both synchronous and asynchronous connections. It is also our goal to gather together as many AppleTalk over PPP client implementations as possible. Please e-mail me if you have any interest in participating in such an event. Also, I have two questions: 1. How can I subscribe to this list? I have sent mail to ietf-ppp-request@merit.edu to no avail. 2. Can anyone point me to a source for understanding how testing was conducted at the PPP Consortium session in April? I am interested in testing methodology, session formats, equipment used, etc. Thank you, Bill Jackson Bill Jackson bill@tribe.com 510-814-3941 - - - - - - - - - - - - - - - - - From list-admin Fri Jun 17 13:39:25 1994 Received: from ucdavis.ucdavis.edu (ucdavis.ucdavis.edu [128.120.250.250]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id NAA19757 for ; Fri, 17 Jun 1994 13:39:24 -0400 Received: from monk.proteon.com by ucdavis.ucdavis.edu (8.6.8/UCD2.50) id KAA05480; Fri, 17 Jun 1994 10:39:22 -0700 Received: from mcgarret.proteon.com by monk.proteon.com (4.1/Proteon-1.5) id AA17774; Fri, 17 Jun 94 13:38:50 EDT Received: by mcgarret.proteon.com (4.1/SMI-4.1) id AA10667; Fri, 17 Jun 94 13:38:50 EDT Date: Fri, 17 Jun 94 13:38:50 EDT From: Ken.Peirce@proteon.com (Kenneth L. Peirce) Message-Id: <9406171738.AA10667@mcgarret.proteon.com> To: ietf-ppp@ucdavis.edu Subject: PPP Stacker Compression Draft Hi, I am looking to implement compression over PPP. The stacker draft looks promising, but I do not wish to implement the reliable link mechanism. There appeared to be a lot of interest in changing the draft to allow for a simple, low overhead sequencing scheme. Was this issue settled or was it displaced by the "pause/resume" discussion? Ken Peirce klp@proteon.com Any opinions stated herein are my own and not those of Proteon, Inc. - - - - - - - - - - - - - - - - - From list-admin Fri Jun 17 16:29:00 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA02414 for ; Fri, 17 Jun 1994 16:28:59 -0400 Received: from [129.192.64.5] (coal.acc.com) by fennel.acc.com (4.1/SMI-4.1) id AA23839; Fri, 17 Jun 94 13:28:47 PDT Message-Id: <9406172028.AA23839@fennel.acc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Jun 1994 13:28:46 -0800 To: Ken.Peirce@proteon.com (Kenneth L. Peirce) From: fbaker@acc.com (Fred Baker) Subject: Re: PPP Stacker Compression Draft Cc: ietf-ppp@merit.edu > I am looking to implement compression over PPP. The stacker >draft looks promising, but I do not wish to implement the >reliable link mechanism. There appeared to be a lot of interest in >changing the draft to allow for a simple, low overhead sequencing >scheme. Was this issue settled or was it displaced by the "pause/resume" >discussion? I thought that they were addressed in the CCP draft... ============================================================================= "In sound wisdom there are two sides" Zophar, Job 11:6 - - - - - - - - - - - - - - - - - From list-admin Fri Jun 17 16:27:39 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA02368 for ; Fri, 17 Jun 1994 16:27:36 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for ietf-ppp@merit.edu id AA19722; Fri, 17 Jun 94 13:27:31 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA28921; Fri, 17 Jun 94 14:26:08 -0600 Date: Fri, 17 Jun 94 14:26:08 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406172026.AA28921@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: PPP Stacker Compression Draft > From: Ken.Peirce@proteon.com > I am looking to implement compression over PPP. The stacker > draft looks promising, but I do not wish to implement the > reliable link mechanism. There appeared to be a lot of interest in > changing the draft to allow for a simple, low overhead sequencing > scheme. Was this issue settled or was it displaced by the "pause/resume" > discussion? I think the stumbling block is STAC Electronics' lisensing. When asked exactly what they meant by "no changes to the free source except to make it compile," if the intent was to outlaw efforts to make free LZS fast, and how one might fit random source code into a real implementation without making substantial changes, they never answered and stayed silent. I think Karl Fox of Morning Star had an implementation running, but my impression is that he gave up and pulled it when STAC failed to deliver a copy if the free lisense. Maybe that situation has changed. I would like to see a single, reasonable performance, default compression algorithm, and from what I can tell, LZS fits the bill on technical grounds. However, the default algorithm must have lisense terms suitable for the myriad of public domain source implemenations of PPP. "Avaliable on equal terms to all" may be ok for purely commercial uses (e.g. v.42bis in modems), but "free for this purpose" is the only choice for the PPP default. It would really be swell if STAC Electronics would make available an LZS lisense that would work for the zillions of people reporting their PPP efforts in comp.protocols.ppp, comp.protocols.tcp-ip, and many other newsgroups and mailing lists. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Fri Jun 17 21:28:18 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id VAA17727 for ; Fri, 17 Jun 1994 21:28:16 -0400 Received: from [129.192.64.5] (coal.acc.com) by fennel.acc.com (4.1/SMI-4.1) id AA01999; Fri, 17 Jun 94 18:27:55 PDT Message-Id: <9406180127.AA01999@fennel.acc.com> X-Sender: fbaker@acc.com (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Jun 1994 18:27:58 -0800 To: stev@ftp.com, topolcic@bbn.com From: fbaker@acc.com (Fred Baker) Subject: Please consider these for Draft Standard Cc: sjs@network.com, katz@cisco.com, ietf-ppp@merit.edu Two weeks ago, I sent the following two notes: Date: Wed, 8 Jun 1994 18:44:07 -0800 To: ietf-ppp@merit.edu From: fbaker@acc.com (Fred Baker) Subject: The PPP DECnet Phase IV Control Protocol (DNCP) I have a question re: RFC 1376. The author, Steve Senum, advises me that several interoperable implementations exist and that there are no known reasons it could not be advanced to Draft Standard without modification. If there is any reason NOT to do so, plase comment to the list by 17 June 1994, failing which I shall advise the AD that this RFC is available for advancement in situ. Date: Wed, 8 Jun 1994 18:44:17 -0800 To: ietf-ppp@merit.edu From: fbaker@acc.com (Fred Baker) Subject: The PPP OSI Network Layer Control Protocol (OSINLCP) I have a question re: RFC 1377. The author, Dave Katz, advises me that several interoperable implementations exist and that there are no known reasons it could not be advanced to Draft Standard without modification. If there is any reason NOT to do so, plase comment to the list by 17 June 1994, failing which I shall advise the AD that this RFC is available for advancement in situ. I have received additional commentary on neither. These protocols have each been implemented by Cisco, Wellfleet, 3COM, Network Systems, Proteon, and Digital; I suspect strongly that there are others. I think they are ready to advance to Draft Standard without further editing. The authors (cc'd) can give you any supporting information that you need. Please ask the IESG to do so. Thanks ============================================================================= "In sound wisdom there are two sides" Zophar, Job 11:6 - - - - - - - - - - - - - - - - - From list-admin Mon Jun 20 11:42:57 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA24830 for ; Mon, 20 Jun 1994 11:42:56 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07534; 20 Jun 94 11:42 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@merit.edu From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-netbios-fcp-05.txt Date: Mon, 20 Jun 94 11:42:11 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9406201142.aa07534@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : The PPP NetBIOS Frames Control Protocol (NBFCP) Author(s) : T. Dimitri Filename : draft-ietf-pppext-netbios-fcp-05.txt Pages : 14 Date : 06/17/1994 The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols. The NBF protocol was originally called the NetBEUI protocol and was used in versions of DOS and OS/2 LAN Manager. It is now used in Microsoft Windows NT and Microsoft Windows for Workgroups. This document defines the Network Control Protocol for establishing and configuring the NBF protocol over PPP. The NBFCP protocol is only applicable for an end system to connect to a peer system or the LAN that peer system is connected to. It is not applicable for connecting two LANs together due to NetBIOS name limitations and NetBIOS name defense mechanisms. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-netbios-fcp-05.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-netbios-fcp-05.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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@ds.internic.net" Content-Type: text/plain Content-ID: <19940617133608.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-pppext-netbios-fcp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-netbios-fcp-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940617133608.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From list-admin Wed Jun 22 18:05:23 1994 Received: from ucdavis.ucdavis.edu (ucdavis.ucdavis.edu [128.120.250.250]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id SAA09895 for ; Wed, 22 Jun 1994 18:05:22 -0400 Received: from combinet.com by ucdavis.ucdavis.edu (8.6.8/UCD2.50) id PAA13533; Wed, 22 Jun 1994 15:05:20 -0700 Received: from combinetu.combinet.com by combinet.com (8.6.5/1.00) id PAA22655; Wed, 22 Jun 1994 15:05:30 -0700 Message-Id: <199406222205.PAA22655@combinet.com> To: Ken.Peirce@proteon.com (Kenneth L. Peirce) cc: ietf-ppp@ucdavis.edu, bobd@combinet.com Subject: Re: PPP Stacker Compression Draft In-reply-to: Your message of "Fri, 17 Jun 1994 13:38:50 EDT." <9406171738.AA10667@mcgarret.proteon.com> Date: Wed, 22 Jun 1994 15:05:28 -0700 From: Bob Downs In message <9406171738.AA10667@mcgarret.proteon.com>, Kenneth L. Peirce writes: >Hi, > I am looking to implement compression over PPP. The stacker >draft looks promising, but I do not wish to implement the >reliable link mechanism. There appeared to be a lot of interest in >changing the draft to allow for a simple, low overhead sequencing >scheme. Was this issue settled or was it displaced by the "pause/resume" >discussion? > I would also like to implement the Stac algorithm without LAPB for ISDN. Please let us know what issues you find. thx, Bob Downs Combinet - - - - - - - - - - - - - - - - - From list-admin Thu Jun 23 01:19:33 1994 Received: from gatekeeper.mcimail.com (gatekeeper.mcimail.com [192.147.45.5]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id BAA03831 for ; Thu, 23 Jun 1994 01:19:31 -0400 Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA00618; Thu, 23 Jun 94 00:21:09 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id by12605; 23 Jun 94 5:16 GMT Date: Wed, 22 Jun 94 19:35 EST From: BobL To: ietf-ppp To: Ken Peirce Subject: Re: PPP Stacker Compression Draft Message-Id: <84940623003548/0005015674ND4EM@mcimail.com> > From Vernon Schryver >> From: Ken.Peirce@proteon.com >> I am looking to implement compression over PPP. The stacker >> draft looks promising, but I do not wish to implement the >> reliable link mechanism. There appeared to be a lot of interest in >> changing the draft to allow for a simple, low overhead sequencing >> scheme. Was this issue settled or was it displaced by the "pause/resume" >> discussion? > I think the stumbling block is STAC Electronics' lisensing. When asked > exactly what they meant by "no changes to the free source except to > make it compile," if the intent was to outlaw efforts to make free LZS > fast, and how one might fit random source code into a real implementation > without making substantial changes, they never answered and stayed silent. Stac has never tried to hide its intent in participating in a standards environment. Furthermore, "intent" should normally not be used to determine an objective. What is important is the technology involved, and the terms and conditions under which it is available. Stac's data compression technology is used in the majority of data communication equipment in production today (which incorporate data compression). In fact, the DSU/CSU consortium recently selected to use Stac's data compression as the default standard in that market. The terms are very reasonable. The software is available for a $0 license in the C format. Our assembly language optimizations are available for $10K. This is quite a bargain when you consider how much Microsoft recently paid. Our hardware chips are also available for about $30 depending upon quantity. > I think Karl Fox of Morning Star had an implementation running, but my > impression is that he gave up and pulled it when STAC failed to deliver > a copy if the free lisense. Maybe that situation has changed. This is simply not true. But I am not at liberty to disclose customer details. > I would like to see a single, reasonable performance, default > compression algorithm, and from what I can tell, LZS fits the bill on > technical grounds. However, the default algorithm must have lisense > terms suitable for the myriad of public domain source implemenations of > PPP. "Avaliable on equal terms to all" may be ok for purely commercial > uses (e.g. v.42bis in modems), but "free for this purpose" is the only > choice for the PPP default. Vernon, I do not believe that this group is aiming toward a default compression algorithm. The CCP simply describes how to negotiate between different compression algorithms. There will probably be a defacto-default, but this will be based on consumer preferences and market demand. Stac's data compression technology is "available on equal terms to all", and the C library is "free for this purpose". As I mentioned previously, Stac's software and hardware is quite prevalent today. > It would really be swell if STAC Electronics would make available an > LZS lisense that would work for the zillions of people reporting their > PPP efforts in comp.protocols.ppp, comp.protocols.tcp-ip, and many > other newsgroups and mailing lists. > Vernon Schryver, vjs@sgi.com Returning to Ken Peirce's original question, the Stacker draft has been modified by Bill Simpson to include a low-overhead sequencing option. There are actually quite a few changes since the first draft based on many comments which have been received. I really appreciate Bill's efforts in combining all the various inputs that he has received and producing a meaningful document. I am not sure when Bill is going to post the new revision, but I suspect it will be soon. Robert Lutz Stac Electronics Product Manager 5993 Avenida Encinas (619) 431-7474 Carlsbad, CA 92008 (619) 431-5726(fax) Email:stac/stac/BobL%5015674@mcimail.com - - - - - - - - - - - - - - - - - From list-admin Thu Jun 23 09:51:21 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id JAA02283 for ; Thu, 23 Jun 1994 09:51:19 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (940621.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:ietf-ppp@merit.edu> id GAA17660; Thu, 23 Jun 1994 06:51:13 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA20092; Thu, 23 Jun 94 07:50:41 -0600 Date: Thu, 23 Jun 94 07:50:41 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406231350.AA20092@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: PPP Stacker Compression Draft > From: STAC/STAC/BobL%Stac_Electronics@mcimail.com (BobL) > > > From Vernon Schryver > > > I think the stumbling block is STAC Electronics' lisensing. When asked > > exactly what they meant by "no changes to the free source except to > > make it compile," if the intent was to outlaw efforts to make free LZS > > fast, and how one might fit random source code into a real implementation > > without making substantial changes, they never answered and stayed silent. > > Stac has never tried to hide its intent in participating in a standards > environment. Furthermore, "intent" should normally not be used to determine > an objective. What is important is the technology involved, and the terms > and conditions under which it is available. > > Stac's data compression technology is used in the majority of data > communication equipment in production today (which incorporate data > compression). In fact, the DSU/CSU consortium recently selected to use > Stac's data compression as the default standard in that market. > > The terms are very reasonable. The software is available for a $0 license > in the C format. Our assembly language optimizations are available for > $10K. This is quite a bargain when you consider how much Microsoft recently > paid. Our hardware chips are also available for about $30 depending upon > quantity. > ... Of course STAC Electronic's business goals are both entirely irrelevant and absolutely none of my business. I appologize for poorly phrasing my concern. My intent was to point out that it is not clear whether the "no changes except to compile" restriction in the STAC $0 lisense prohibits all significant change, including the significant changes necessary to fit LZS into real PPP implemenations. I have tried to ask that before, but, perhaps by not paying attention or bad wording, I have not noticed an answer to that question. Judging from private communications, I am not the only person who may be confused. Please let me try again. Would an implemention of LZS that started with your C source but that was substantially different from that C source, including involving some assembly language, violate the spirit of that $0 lisense? Please let me know if I have misphrased my question again. Perhaps I misunderstood your previous description of the $0 lisense, which I recall included the words "no changes except to compile." It is difficult to communicate in this format. For example, the reference to the recent legal unpleasantness with Microsoft could be misunderstood as threatening. Still, just to be on the safe side, please note that I have not considered looking LZS source in order to avoid the least suggestion of violating any LZS lisenses. (Yes, I know the issue is of patents instead of copyrights and so not looking at code is not sufficient.) The endorsments of consortia, trade groups, and individual concerns is largely irrelevant in this forum. Given a product or position or choice, no matter how wise or silly, it is possible to find a consortium that supports it. Given the supposed future of wide area networks involving only frame relay, ISDN, ATM, and SMDS, I puzzled why anyone would care about new CSU/DSU's with or without compression. I probably do not understand the kinds of products they are considering. That STAC Electronics lisenses LZS on equal terms to all is admirable but largely irrelevant here. This is not the ITU nor ANSI. For example, the Digital lisense on the longer PPP checksum ensured that it is not and never will be widely implemented. $10K for a "paid up" lisense is a very low price for many applications, but too high for others. Of course, if the difference between C and assembly language source is $10K, it is in favor of C. I can't imagine more than one or two STAC customers prefering assembly language to C even if their intent is to use assembly language in their products. Almost anyone would want to start from C to produce a highly optimized version. As you say, the de facto default compression algorithm will be based on consumer preferences and market demand. As I see it, for links between router boxes LZS is now a leading contender. For the links to the (literally) millions of individual systems ranging from MAC's and PC's to workstations, an algorithm with a significant lisense fee is a non-starter. If that is true, the larger volumes of boxes to talk to individual systems means the de facto default for them could become the de facto default between specialized PPP boxes as well. Unless LZS is also the choice in the larger market, its share in the smaller, profitable market could be affected. Predictor does not have great performance but it is not too bad, requires very few CPU cycles, and it seems cheap. I would rather see LZS instead of Predictor as the de facto default, but if the market is not given that choice, it will not choose it. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Thu Jun 23 21:01:34 1994 Received: from pm002-01.dialip.mich.net (pm002-01.dialip.mich.net [35.1.48.82]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id VAA18607 for ; Thu, 23 Jun 1994 21:01:32 -0400 Date: Fri, 24 Jun 94 00:05:32 GMT From: "William Allen Simpson" Message-ID: <2760.bill.simpson@um.cc.umich.edu> To: ietf-ppp Reply-to: bsimpson@morningstar.com Subject: Re: PPP Stacker Compression Draft > Returning to Ken Peirce's original question, the Stacker draft has been > modified by Bill Simpson to include a low-overhead sequencing option. There > are actually quite a few changes since the first draft based on many > comments which have been received. I really appreciate Bill's efforts in > combining all the various inputs that he has received and producing a > meaningful document. I am not sure when Bill is going to post the new > revision, but I suspect it will be soon. > Was yesterday soon enough? It takes internet-drafts a couple of days to get it announced. It's coming.... There are still some other issues regarding IETF Standards Process Intellectual Property language that may have to go in. I waited for a couple of weeks for ISoc specialists to get back to me, but decided to go ahead. There will probably be another draft later including that boilerplate. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Fri Jun 24 17:35:50 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id RAA09692 for ; Fri, 24 Jun 1994 17:35:49 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12307; 24 Jun 94 17:27 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@merit.edu From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-callback-cp-01.txt Date: Fri, 24 Jun 94 17:27:44 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9406241727.aa12307@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Proposal for Callback Control Protocol (CBCP). Author(s) : N. Gidwani Filename : draft-ietf-pppext-callback-cp-01.txt Pages : 9 Date : 06/24/1994 The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP is comprised of three main components: 1. A method for encapsulating multi-protocol datagrams. 2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. 3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines an interoperable method for negotiating dial-up callback over PPP links. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-callback-cp-01.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-callback-cp-01.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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@ds.internic.net" Content-Type: text/plain Content-ID: <19940624093047.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-pppext-callback-cp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-callback-cp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940624093047.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From list-admin Sat Jun 25 14:01:02 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA08782 for ; Sat, 25 Jun 1994 14:01:02 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04569; 25 Jun 94 13:40 EDT To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@merit.edu Cc: Internet Engineering Steering Group From: IESG Secretary Subject: Protocol Action: PPP in HDLC-like Framing to Standard Date: Sat, 25 Jun 1994 13:40:27 -0400 Sender: jstewart@IETF.CNRI.Reston.VA.US Message-ID: <9406251340.aa04569@IETF.CNRI.Reston.VA.US> The IESG has approved the Internet-Draft "PPP in HDLC-like Framing" as a Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Stev Knowles and Claudio Topolcic. Technical Summary The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of HDLC-like framing for PPP- encapsulated packets. This specification is widely implemented and enjoys tremendous support in the community. Working Group Summary The PPP Working Group has spent considerable time over the years honing the wording of this specification to remove the least ambiguities from the text. There is wide working group and community support for this specification Protocol Quality This specification has had every feature and process implemented in at least two independant implementations. The specification was reviewed by Stev Knowles, one of the Internet Area Directors, for the IESG. - - - - - - - - - - - - - - - - - From list-admin Sat Jun 25 14:20:15 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA09422 for ; Sat, 25 Jun 1994 14:20:13 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04612; 25 Jun 94 13:42 EDT To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@merit.edu Cc: Internet Engineering Steering Group From: IESG Secretary Subject: Protocol Action: The Point-to-Point Protocol (PPP) to Standard Date: Sat, 25 Jun 1994 13:42:16 -0400 Sender: jstewart@IETF.CNRI.Reston.VA.US Message-ID: <9406251342.aa04612@IETF.CNRI.Reston.VA.US> The IESG has approved the Internet-Draft "The Point-to-Point Protocol (PPP)" as a Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Stev Knowles and Claudio Topolcic. Technical Summary The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. The PPP Link Control Protocol (LCP) is described in terms of this mechanism. Working Group Summary This specification is the product of several years of working group effort and includes the individual work of a large number of volunteers. The individuals compromising the working group have spent considerable amounts of time both within the confines of the working group and in other forums working to assure the acceptance and quality of the specification. Protocol Quality This specification was reviewed by Stev Knowles, one of the Internet Area Directors for the IESG. The specification has been implemented by a large variety of organizations, and it appears that every feature and process has been independantly implemented by more than one organization. - - - - - - - - - - - - - - - - - From list-admin Wed Jun 29 14:01:54 1994 Received: from newsun.novell.com (newsun.Novell.COM [130.57.4.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA23206 for ; Wed, 29 Jun 1994 14:01:50 -0400 Received: from va.SJF.Novell.COM by newsun.novell.com (4.1/SMI-4.1) id AA14741; Wed, 29 Jun 94 11:01:14 PDT Received: by va.SJF.Novell.COM (4.1/SMI-4.1) id AA14473; Wed, 29 Jun 94 11:01:12 PDT From: Ruth_Tsai@Novell.COM (Ruth Tsai) Message-Id: <9406291801.AA14473@va.SJF.Novell.COM> Subject: Re: suspend/resume; virtual connection To: ietf-ppp@merit.edu Date: Wed, 29 Jun 1994 11:01:12 -0700 (PDT) Cc: rtsai@va.sjf.novell.com (Ruth Tsai) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 199 Has anyone thought about the compression benefiting from suspend/resume? The compression dictionary can be retained during suspend and be used upon resume. Thanks Ruth Tsai rtsai@novell.com - - - - - - - - - - - - - - - - - From list-admin Wed Jun 29 16:11:08 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id QAA04189 for ; Wed, 29 Jun 1994 16:11:07 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:ietf-ppp@merit.edu> id NAA17662; Wed, 29 Jun 1994 13:11:00 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA11701; Wed, 29 Jun 94 14:10:28 -0600 Date: Wed, 29 Jun 94 14:10:28 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406292010.AA11701@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: suspend/resume; virtual connection > From: Ruth_Tsai@Novell.COM (Ruth Tsai) > > Has anyone thought about the compression benefiting from suspend/resume? The > compression dictionary can be retained during suspend and be used upon resume. > > Thanks > > Ruth Tsai > rtsai@novell.com From my measurements of both Predictor and BSD Compress, I would say suspend/resume are not sufficiently helpful to saving compression state to justify the hassle of implementing suspend/resume. It does not take make packets to train either of those. What's more, the traffic after a resumption is likely to be different enough to force a dictonary clear in BSD Compress. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - -