From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 1 07:33:11 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22245; Mon, 1 Jun 92 07:24:20 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA26204; Mon, 1 Jun 92 07:09:49 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21622; Mon, 1 Jun 92 07:00:40 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21487; Mon, 1 Jun 92 06:55:28 -0700 Received: by europa.clearpoint.com (4.1/1.34) id AA16414; Mon, 1 Jun 92 09:47:27 EDT Date: Mon, 1 Jun 92 09:47:27 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9206011347.AA16414@europa.clearpoint.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: ID ACTION:draft-ietf-pppext-pppmib-03.txt Forwarding: Mail from 'Internet-Drafts@nri.reston.va.us' dated: Fri, 29 May 92 09:43:42 -0400 just in case you missed my posting last week. this version is slightly different than the one i mailed to you all -- the name had to be changed to comply with the new guidelines for id's and there were some typos that were pointed out and i fixed. frank ---------- Begin Forwarded Message ---------- Message 25: >From owner-ietf@isi.edu Fri May 29 18:23:39 1992 To: IETF From: Internet-Drafts@nri.reston.va.us Reply-To: Internet-Drafts@nri.reston.va.us Subject: ID ACTION:draft-ietf-pppext-pppmib-03.txt Sender: cclark@nri.reston.va.us 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 Definitions of Managed Objects for the Point-to-Point Protocol Author(s) : Frank Kastenholz Filename : draft-ietf-pppext-pppmib-03.txt Pages : 64 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing subnetwork interfaces using the family of Point-to-Point Protocols. 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-pppmib-03.txt". Internet-Drafts directories are located at: o East Coast (US) Address: nnsc.nsf.net (128.89.1.178) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) 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: mail-server@nisc.sri.com. In the body type: "SEND internet-drafts/draft-ietf-pppext-pppmib-03.txt". For questions, please mail to internet-drafts@nri.reston.va.us. ----------- End Forwarded Message ----------- From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 1 12:52:06 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02426; Mon, 1 Jun 92 12:48:17 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA29469; Mon, 1 Jun 92 12:21:47 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01274; Mon, 1 Jun 92 12:13:25 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from mts-gw.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00938; Mon, 1 Jun 92 12:00:51 -0700 Received: by mts-gw.pa.dec.com; id AA10484; Mon, 1 Jun 92 11:59:51 -0700 Message-Id: <9206011859.AA10484@mts-gw.pa.dec.com> Received: from eider.enet; by decpa.enet; Mon, 1 Jun 92 11:59:53 PDT Date: Mon, 1 Jun 92 11:59:53 PDT From: Jesse Walker To: kasten@europa.clearpoint.com Cc: ietf-ppp@ucdavis.ucdavis.edu Apparently-To: kasten@europa.clearpoint.com, ietf-ppp@ucdavis.edu Subject: PPP MIB Frank: The latest version of the MIB addresses all the concerns I've raised. It looks very good to me. Attached are a few more comments which are largely cosmetic in nature. -- Jesse Walker 5. Definitions -- -- The following are place holders for later -- elements of the PPP MIBs. When the -- indicated encpasulation is finished, the -- MIB for that encapsulation will be placed -- under the given OID. -- pppIpx OBJECT IDENTIFIER ::= { ppp 7 } pppIso OBJECT IDENTIFIER ::= { ppp 8 } pppAppleTalk OBJECT IDENTIFIER ::= { ppp 9 } pppDecNet OBJECT IDENTIFIER ::= { ppp 10 } This is a good way to handle these as yet undefined MIBs. 5.1. PPP Link Group pppLinkStatusLocalMRU OBJECT-TYPE SYNTAX INTEGER(1..2147483648) ACCESS read-only STATUS mandatory DESCRIPTION "The final negotiated MRU value for the local PPP Entity. This value is the MRU that the remote entity has accepted for the local PPP entity." ::= { pppLinkStatusEntry 7 } Just a pedantic nit here. Given that it is legal to build implementations that do not implement the MRU option, it would probably be wise to modify the text slightly to say something like "The final MRU value for the local PPP Entity. When the MRU option is implemented, this value gives the MRU that the remote entity has accepted for the local PPP entity. Similar minor textual changes could also be applied to the DESCRIPTION clauses for pppLinkStatusRemoteMRU, pppLinkStatusLocalToRemoteProtocolCompression, pppLinkStatusRemoteToLocalProtocolCompression, pppLinkStatusLocalToRemoteACCompression, and pppLinkStatusRemoteToLocalACCompression objects. pppLinkConfigInitialMRU OBJECT-TYPE SYNTAX INTEGER(0..2147483648) ACCESS read-write STATUS mandatory DESCRIPTION "The initial Maximum Receive Unit (MRU) that the local PPP entity will advertise to the remote entity. If the value of this variable is 0 then the local PPP entity will not advertise any MRU to the remote entity and the default MRU will be assumed. Changing this object will have effect when the link is next restarted." REFERENCE "Section 7.2, Maximum Receive Unit of [8]." DEFVAL { 1500 } ::= { pppLinkConfigEntry 2 } As with the previous table, this and the DESCRIPTION clause for the pppLinkConfigMagicNumber and pppLinkConfig32BitFCS object could use a bit tinkering to apply to the case when a particular option is not implemented. For the pppLinkConfigInitialMRU object, the revised text could read something like "If the MRU is implemented, the initial Maximum Receive Unit (MRU) that the local PPP entity will advertise to the remote entity; the value it expects its peer is configured to use if the option is not implemented. If the value of this variable is 0 then the local PPP entity will not advertise any MRU to the remote entity and the default MRU will be assumed. Changing this object will have effect when the link is next restarted." 5.2. PPP LQR Group pppLqrLocalPeriod OBJECT-TYPE SYNTAX INTEGER(1..2147483648) ACCESS read-only STATUS mandatory DESCRIPTION "The LQR reporting period that is in effect for the local PPP entity. The local entity received a configure-ack for this value from the remote PPP entity." REFERENCE "Section 2.5, Configuration Option Format, of [12]." ::= { pppLqrEntry 4 } pppLqrRemotePeriod OBJECT-TYPE SYNTAX INTEGER(1..2147483648) ACCESS read-only STATUS mandatory DESCRIPTION "The LQR reporting period that is in effect for the remote PPP entity. The local entity sent a configure-ack for this value in response to the configure-req from the remote PPP entity." REFERENCE "Section 2.5, Configuration Option Format, of [12]." ::= { pppLqrEntry 5 } The pppLqrLocalPeriod and pppLqrRemotePeriod are calibrated in units of ??? (undoubtedly seconds) 5.6. PPP Security Configuration Group pppSecurityConfigEntry OBJECT-TYPE SYNTAX PppSecurityConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "CHAP information for a particular PPP link." INDEX { pppSecurityConfigLink, pppSecurityConfigPreference } ::= { pppSecurityConfigTable 1 } The DESCRIPTION clause of the pppSecurityConfigEntry avoid referencing CHAP. There seem to be other tables to provide CHAP control. 5.7. PPP CHAP Group pppChapSecretsSecret OBJECT-TYPE SYNTAX OCTET STRING -- (SIZE(16)) when MD5 ACCESS read-write STATUS mandatory DESCRIPTION "The digest secret to be associated with the name." ::= { pppChapSecretsEntry 4 } pppChapPeerSecretsSecret OBJECT-TYPE SYNTAX OCTET STRING -- (SIZE(16)) when using MD5 ACCESS read-write STATUS mandatory DESCRIPTION "The Secret associated with the Peer-Name identified in pppChapPeerSecretsName." ::= { pppChapPeerSecretsEntry 4 } The Party MIB has the following language for the partySecretsAuthPrivate and partySecretsPrivPrivate objects, which we might fruitfully adopt as well: ... Although the value of this variable may be altered by a management operation (e.g., a SNMP Set-Request), its value cannot be retrieved by a management operation: when read, the value of this variable is the zero length OCTET STRING. Such a policy would help keep secrets secret. The party MIB goes on to define an encoding of secrets which we might also use, to minimize the number of different techniques we use for transfering secrets via SNMP: ...The value is the exclusive-OR of the old key value with the new key value...when calculating the exclusive-OR, the old key value is padded with zeroes if it is shorter than the new 5.8. PPP PAP Group pppPapSecretsPassword OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "The password to be associated with the Peer ID." ::= { pppPapSecretsEntry 4 } pppPapPeerSecretsPassword OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "The Password associated with the Peer-ID identified in pppPapPeerSecretsId." ::= { pppPapPeerSecretsEntry 4 } I'm inclined to suggest the same consideration is shown a password as any other secret, so please consider incorporating text saying that reads of this object return the zero length OCTET STRING. From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 1 19:21:01 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15112; Mon, 1 Jun 92 19:19:44 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA03364; Mon, 1 Jun 92 18:59:53 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14196; Mon, 1 Jun 92 18:50:59 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14077; Mon, 1 Jun 92 18:46:08 -0700 Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA09252; Mon, 1 Jun 92 18:45:16 -0700 Date: Mon, 1 Jun 92 19:19:06 EDT From: "William Allen Simpson" Message-Id: <386.bsimpson@angband.stanford.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: In-Reply-To: PPP MIB > From: Jesse Walker > > pppLinkStatusLocalMRU OBJECT-TYPE > SYNTAX INTEGER(1..2147483648) > ACCESS read-only > STATUS mandatory > DESCRIPTION > "The final negotiated MRU value for the local > PPP Entity. This value is the MRU that the > remote entity has accepted for the local PPP > entity." > ::= { pppLinkStatusEntry 7 } > > Just a pedantic nit here. Given that it is legal to build implementations > that do not implement the MRU option, it would probably be wise to > modify the text slightly to say something like > > "The final MRU value for the local PPP > Entity. When the MRU option is implemented, > this value gives the MRU that the remote > entity has accepted for the local PPP entity. > I disagree. Although the remote MAY not implement the MRU configuration option, since the option has not been negotiated, the remote has therefore *accepted* the default of 1500. "Silence is consent." > "If the MRU is implemented, the initial > Maximum Receive Unit (MRU) that the local PPP > entity will advertise to the remote entity; ===============>> the value it expects its peer is configured to ===============>> use if the option is not implemented. If the > value of this variable is 0 then the local PPP > entity will not advertise any MRU to the remote > entity and the default MRU will be assumed. > Changing this object will have effect when > the link is next restarted." > It would be hard to disagree with you more! This is *utterly* wrong! (I never claimed to be diplomatic.) If the option is not negotiated, then it MUST be 1500! Always! What are you trying to do, make a SLIP that has PPP headers?!? If you don't plan on implementing even the most basic of LCP options, why are you calling it PPP??? You think that PPP options are harder than SNMP? > The pppLqrLocalPeriod and pppLqrRemotePeriod are calibrated in units > of ??? (undoubtedly seconds) Hundredths of seconds, just like all SNMP timers (we changed it from microseconds at the last IETF). Is this the wrong SYNTAX type? Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 2 06:10:47 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01520; Tue, 2 Jun 92 06:02:51 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05502; Tue, 2 Jun 92 05:39:52 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00752; Tue, 2 Jun 92 05:32:02 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from mts-gw.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00280; Tue, 2 Jun 92 05:25:47 -0700 Received: by mts-gw.pa.dec.com; id AA08914; Tue, 2 Jun 92 05:25:12 -0700 Message-Id: <9206021225.AA08914@mts-gw.pa.dec.com> Received: from eider.enet; by decpa.enet; Tue, 2 Jun 92 05:25:14 PDT Date: Tue, 2 Jun 92 05:25:14 PDT From: Jesse Walker To: ietf-ppp@ucdavis.ucdavis.edu Apparently-To: ietf-ppp@ucdavis.edu Subject: Re: In-Reply-To: PPP MIB Bill: > What are you trying to do, make a SLIP that has PPP headers?!? If you > don't plan on implementing even the most basic of LCP options, why are > you calling it PPP??? You think that PPP options are harder than SNMP? Frankly I cannot imagine anyone implementing PPP without also implementing the MRU option; they simply would not have a competative product without it. The reason for suggesting more flexible language is someone named Bill Simpson wrote RFC 1331 in such a way that implementation of any option is optional, not mandatory. I interpret the current language as mandating the MRU option (certainly no one has to agree with my interpretation), and it seems reasonable to expect the MIB to be consistent with the published LCP specification. > Hundredths of seconds, just like all SNMP timers (we changed it from > microseconds at the last IETF). Is this the wrong SYNTAX type? Hundreths of a second sounds fine to me. But please note the MIB already calibrates pppLqrConfigPeriod object in seconds. While there is no requirement to do so, it appears like it might be less confusing to most users to calibrate the pppLqrConfigPeriod object in the same units that are selected for pppLqrLocalPeriod and pppLqrRemotePeriod. -- Jesse Walker From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 2 12:12:37 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11432; Tue, 2 Jun 92 12:00:04 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07277; Tue, 2 Jun 92 09:29:59 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06717; Tue, 2 Jun 92 09:21:11 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06673; Tue, 2 Jun 92 09:19:10 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA00757; Tue, 2 Jun 92 09:18:02 PDT Date: Tue, 2 Jun 92 09:18:02 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9206021618.AA00757@saffron.acc.com> To: bsimpson@angband.stanford.edu Subject: Re: In-Reply-To: PPP MIB Cc: ietf-ppp@ucdavis.ucdavis.edu >> > The pppLqrLocalPeriod and pppLqrRemotePeriod are calibrated in units >> > of ??? (undoubtedly seconds) >> >> Hundredths of seconds, just like all SNMP timers (we changed it from >> microseconds at the last IETF). Is this the wrong SYNTAX type? I get SNMP timers explained to me periodically, let me pass the wisdom along. SNMP assumes that there is a clock ticking somewhere. To read it, you GET sysUpTime. If you capture the value of sysUpTime in some other object as a timestamp (as, for example, ifLastChange does whenever an interface status changes), the syntax is TimeTicks. To calibrate timers - to say "do every/after ", you must specify the time unit. This is generally either hundredths of a second (corresponding to TimeTicks) or seconds, and is stated in the DESCRIPTION. The syntax of the number is, however, INTEGER or a textual convention restricting of INTEGER to a valid range. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 3 07:10:32 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13694; Wed, 3 Jun 92 07:04:23 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA15709; Wed, 3 Jun 92 06:49:45 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13120; Wed, 3 Jun 92 06:40:34 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12976; Wed, 3 Jun 92 06:35:52 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA11031; Wed, 3 Jun 92 06:35:03 -0700 Date: Wed, 3 Jun 92 08:44:02 EDT From: "William Allen Simpson" Message-Id: <394.bsimpson@angband.stanford.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: In-Reply-To: PPP MIB > someone named Bill Simpson wrote RFC 1331 in such a way that > implementation of any option is optional, not mandatory. I interpret > the current language as mandating the MRU option (certainly no one has > to agree with my interpretation), and it seems reasonable to expect the > MIB to be consistent with the published LCP specification. > The MIB *is* consistent with the published spec. I believe that you have mistaken the "option" meaning. ----- For the record: *** The MRU is *not* optional. The concept of the MRU is integral to *** PPP. If the MRU is not negotiated to be some other value, the *** default is 1500. Even when the MRU is negotiated to some other value, 1500 octet packets (after escaping) must always be accepted. This means the unescaped receive buffer should be a minimum of 3010 (since nearly every byte including the header and FCS is subject to escaping). *** The MRU Configuration Option *is* optional (the name says it). *** There is no need to negotiate the MRU if only the default is used. I would expect that an implementation which never negotiates the MRU to any other value would simply ignore the attempt to set the MIB variable, without error, and would always return 0 (not negotiated). *** The same goes for other elements of the design, such as the ACCM. *** Every element *MUST* be implemented, and each has a clearly *** delineated default. The most complicted case is the ACCM. The Async Control Character Map *must* be implemented, even for sync links. For async links, the default is 0xffffffff. For sync links, the ACCM must *not* be used, but MAY be negotiated (which really stretches the concept). There is a fair bit of text regarding this. ----- If you find any language in the documents which contradicts these statements, please let us know. It will be corrected. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 3 07:10:36 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13732; Wed, 3 Jun 92 07:08:59 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA15722; Wed, 3 Jun 92 06:54:32 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13125; Wed, 3 Jun 92 06:40:40 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12995; Wed, 3 Jun 92 06:36:04 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA11034; Wed, 3 Jun 92 06:35:17 -0700 Date: Wed, 3 Jun 92 09:27:40 EDT From: "William Allen Simpson" Message-Id: <395.bsimpson@angband.stanford.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: In-Reply-To: PPP MIB > To calibrate timers - to say "do every/after > ", you must specify the time unit. This is generally > either hundredths of a second (corresponding to TimeTicks) or seconds, > and is stated in the DESCRIPTION. The syntax of the number is, > however, INTEGER or a textual convention restricting of INTEGER to a > valid range. > > Fred > Thanks. So we need to make sure that the units is correctly specified in the description. The units for LQRs should be hundredths of seconds. It says seconds in one place, and is silent in two others. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 3 14:53:18 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27891; Wed, 3 Jun 92 14:40:56 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA20587; Wed, 3 Jun 92 13:50:12 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26067; Wed, 3 Jun 92 13:41:37 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from mts-gw.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25895; Wed, 3 Jun 92 13:35:59 -0700 Received: by mts-gw.pa.dec.com; id AA01163; Wed, 3 Jun 92 12:11:24 -0700 Message-Id: <9206031911.AA01163@mts-gw.pa.dec.com> Received: from eider.enet; by decpa.enet; Wed, 3 Jun 92 12:14:59 PDT Date: Wed, 3 Jun 92 12:14:59 PDT From: Jesse Walker To: bsimpson@angband.stanford.edu Cc: ietf-ppp@ucdavis.ucdavis.edu Apparently-To: bsimpson@angband.stanford.edu, ietf-ppp@ucdavis.edu Subject: Re: In-Reply-To: PPP MIB Bill: > > someone named Bill Simpson wrote RFC 1331 in such a way that > > implementation of any option is optional, not mandatory. I interpret > > the current language as mandating the MRU option (certainly no one has > > to agree with my interpretation), and it seems reasonable to expect the > > MIB to be consistent with the published LCP specification. > > > The MIB *is* consistent with the published spec. I believe that you > have mistaken the "option" meaning. > > - ----- > > For the record: > *** The MRU is *not* optional. The concept of the MRU is integral to > *** PPP. If the MRU is not negotiated to be some other value, the > *** default is 1500. > > Even when the MRU is negotiated to some other value, 1500 octet packets > (after escaping) must always be accepted. This means the unescaped > receive buffer should be a minimum of 3010 (since nearly every byte > including the header and FCS is subject to escaping). > > *** The MRU Configuration Option *is* optional (the name says it). > *** There is no need to negotiate the MRU if only the default is used. Let me avow here and now that by "option" I've always meant "Configuration Option". If it is wrong to drop the the modifier "Configuration" and replace the capital "O" by a lower case letter, then I freely confess my sin. Now I never intended to suggest in any way that MRU or ACC are optional parts of LCP. My intent rather was to point out that RFC 1331 makes implementation of the Configuration Options to negotiate values for these functions optional (you seem to agree in your reply), while the same story does not come through clearly, at least to me, from the MIB. It seemed to me that one document said anyone MAY support Configuration Options to negotiate values for functions X, Y, Z, ..., but that the MIB said everyone MUST, raising the question of which governs implementations trying to comply with both. There is a level at which I really don't care which view is given precedence, as neither will require modification of any implemention I am familiar with, but, if a possibility existed that my interpretation might be correct, there would have been a need to clarify the documents for consistency's sake. So I apparently drew my concerns in a manner you for one found ambigous. Be that as it may, I am utterly delighted to learn that I have mis-interpretted what the MIB status DESCRIPTION clauses intend by "negotiation". I heartily thank you for clarifying the meaning of the MIB. Your response gives a definitive statement for which I vainly searched the text of the MIB itself. I do wish we could incorporate some of the penetrating comments from your reply into the MIB, so no one will repeat my folly. This undoubtedly would be, however, a needless precaution against ambiguity, as, surely, there is absolutely no chance whatsoever that anyone could possibly mis-construe the MIB the way I did. With that, I've said all I intend to say on this issue. -- Jesse Walker From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 5 08:46:53 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11236; Fri, 5 Jun 92 08:35:46 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08293; Fri, 5 Jun 92 07:49:45 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09703; Fri, 5 Jun 92 07:40:32 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09468; Fri, 5 Jun 92 07:32:10 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA13350; Fri, 5 Jun 92 07:31:14 -0700 Date: Thu, 4 Jun 92 13:49:37 EDT From: "William Allen Simpson" Message-Id: <397.bsimpson@angband.stanford.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: new mib Frank: In addition to the list of suggested changes that I previously sent you privately, I suggest the following general changes: For each Local and Remote status variable: DESCRIPTION "The current value of the for the PPP Entity. Initially, and during negotiation, the value is the default. The value is changed to its final value when negotiation has completed." For each configuration option: DESCRIPTION "The initial that the local PPP entity will advertise to the remote entity. If the value of this variable is equal to the default, then the local PPP entity will not advertise the to the remote entity and the default will be assumed. Changing this object will have effect when the link is next restarted." This means that each config status and initial object should have the DEFVAL part as well. Hopefully, this will better describe when the values change, but still give the correct impression that the values are NOT optional, only the negotiation is optional. ----- On another note, your use of separate Transmit and Receive initial values for the ACCM was a good idea, and I am changing my implementation to match your MIB. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 5 09:53:02 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13539; Fri, 5 Jun 92 09:47:03 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09079; Fri, 5 Jun 92 08:49:57 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11577; Fri, 5 Jun 92 08:46:43 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11269; Fri, 5 Jun 92 08:37:44 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA00620; Fri, 5 Jun 92 08:35:45 PDT Date: Fri, 5 Jun 92 08:35:45 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9206051535.AA00620@ray.lloyd.com> To: gunner@libeb.LKG.DEC.COM Cc: ietf-ppp@ucdavis.ucdavis.edu, lauck@dec:.lkg.erlang.dnet In-Reply-To: "(Chris Gunner)"'s message of Fri, 05 Jun 92 09:30:37 -0400 <9206051330.AA05425@libeb.LKG.DEC.COM> Subject: What happened to 16/32 bit FCS negotiation option in RFC 1331 ? I am going to answer quickly so noone freaks re 16/32bit FCS. There is some question re the ownership of the 48 bit FCS required by the 16/32 bit FCS negotiation. DEC (you guys) owns the patent and has promised to grant blanket license at no cost but that hasn't happened yet. So it was decided that the 16/32bit FCS should be moved to a document separate from the LCP doc. Until DEC grants that license I don't think it would be wise to include that opation as part of "standard" LCP. There is absolutely nothing wrong with implementing the 16/32bit FCS negotiation and you should still be interoperable with everyone else. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 5 09:53:10 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13556; Fri, 5 Jun 92 09:49:05 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09464; Fri, 5 Jun 92 09:30:43 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12782; Fri, 5 Jun 92 09:25:44 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from inet-gw-1.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12255; Fri, 5 Jun 92 09:12:09 -0700 Received: by inet-gw-1.pa.dec.com; id AA10339; Fri, 5 Jun 92 09:11:28 -0700 Received: by libeb.LKG.DEC.COM (5.57/Ultrix3.0-C)id AA05624; Fri, 5 Jun 92 12:11:26 -0400 Message-Id: <9206051611.AA05624@libeb.LKG.DEC.COM> To: brian%lloyd.com@inet-gw-1.pa.dec.com Cc: gunner@libeb.lkg.dec.com, ietf-ppp%ucdavis.edu@inet-gw-1.pa.dec.com, lauck@dec:.lkg.erlang.dnet Subject: Re: What happened to 16/32 bit FCS negotiation option in RFC 1331 ? In-Reply-To: Your message of "Fri, 05 Jun 92 08:35:45 PDT." <9206051535.AA00620@ray.lloyd.com> Date: Fri, 05 Jun 92 12:11:25 -0400 From: "(Chris Gunner)" X-Mts: smtp Brian, >There is some question re the ownership of the 48 bit FCS required by >the 16/32 bit FCS negotiation. DEC (you guys) owns the patent and has >promised to grant blanket license at no cost but that hasn't happened >yet. So it was decided that the 16/32bit FCS should be moved to a >document separate from the LCP doc. Until DEC grants that license I >don't think it would be wise to include that opation as part of >"standard" LCP. > >There is absolutely nothing wrong with implementing the 16/32bit FCS >negotiation and you should still be interoperable with everyone else. OK, thanks for the prompt reply. Is the option actually described in a separate document yet or is that just the plan ? Meanwhile we just assume that the option still exists as described in the lcp-03 Internet Draft and the 32bitFCS Internet Draft ? Chris From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 5 10:56:17 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15237; Fri, 5 Jun 92 10:45:06 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09945; Fri, 5 Jun 92 10:20:46 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14299; Fri, 5 Jun 92 10:13:37 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14100; Fri, 5 Jun 92 10:07:14 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA13437; Fri, 5 Jun 92 10:06:13 -0700 Date: Fri, 5 Jun 92 12:25:04 EDT From: "William Allen Simpson" Message-Id: <403.bsimpson@angband.stanford.edu> To: "(Chris Gunner)" Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: What happened to 16/32 bit FCS negotiation option in RFC 1331 ? > From: "(Chris Gunner)" > I've just discovered that RFC 1331 no longer defines the LCP 16/32 bit > FCS negotiation option. How come this got removed - I didn't see any > warning that this was going to happen ? This option existed in the > lcp-03 draft in the internet-drafts directory - isn't that the draft > that got moved to RFC 1331 ? > At the San Diego meeting, we discovered that DEC was claiming some sort of patent on the use of the 16/32/48 FCS mechanism. Tony Lauck promised it would be released to the public for free use in PPP, but the "formal" statement was not released in time for publication of 1331. We discussed this problem several times on the list. I pulled the option out during the (2nd) last call period, and the copy at Angband doesn't have it. The internet-draft shouldn't have it either, but maybe they missed one of the update windows. There will be a separate spec for FCS extensions later. > We've just implemented this option. If it is no longer defined in RFC > 1331 we have a real problem - if we leave it in then we may get > interworking problems in the future if the option code (9) gets used > for something else. I think we would have to pull it out of our > implementation but then we can't use 32 bit FCS. > I have reserved code 9 with the IANA. The form of the option as I currently have it has three bytes, and therefore you will need to check the length. I expect to make this backward compatible, unless the DEC scheme isn't formally released, in which case we must be deliberately incompatible. You work for DEC. Perhaps you can lobby more effectively than I have. I merely send Tony a reminder once or twice a month. I thought that more often would be irritating to him. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 5 13:12:50 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19737; Fri, 5 Jun 92 13:05:43 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11450; Fri, 5 Jun 92 12:23:14 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18001; Fri, 5 Jun 92 12:12:54 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17719; Fri, 5 Jun 92 12:02:15 -0700 Received: from na.novell.com by newsun.novell.com (4.1/smi4.1.1.v91190) id AA25869; Fri, 5 Jun 92 12:01:34 PDT Received: by na.novell.com (4.1/SMI-4.1) id AA06304; Fri, 5 Jun 92 12:03:22 PDT Date: Fri, 5 Jun 92 12:03:22 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9206051903.AA06304@na.novell.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Novell IPXCP Internet Draft Cc: cranch@novell.com, mallen@novell.com Hi Y'all, Here it is! Brian, you help me submit it to the internet drafts directories? Chris Ranch and Michael Allen Internetworking Products Division Novell, Inc. ==============================cut here===================================== Network Working Group M. Allen Internet Draft Novell, Inc. June, 1992 IPX PPP Internetwork Packet Exchange Control Protocol [IPXCP] Status of this Memo This document proposes an IAB standards track protocol for the Internet community. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. This proposal is the product of the Point-to-Point Protocol Working Group of the Internet engineering Task Force (IETF). Comments on this memo should be submitted to the ietf- ppp@ucdavis.edu mailing list. Distribution of this memo is unlimited. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring the IPX protocol over PPP and MUST be used in conjunction with the Informational RFC "Novell IPX Over Various WAN Media", June 1992, Michael Allen. 1. Introduction PPP has three main components: a. A method for encapsulating datagrams over serial links. b. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. c. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. PPP is designed to allow the simultaneous use of multiple network-layer protocols. Allen [Page 1] Internet Draft IPXCP June 1992 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 and optional facilities have been negotiated as needed by the LCP, 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. The link will remain configured for communications until explicit LCP or NCP packets close the link down, or until some external event occurs (an inactivity timer expires or network administrator intervention). 2. IPX PPP Network Control Protocol (NCP) The IPX Control Protocol (IPXCP) is responsible for configuring, enabling, and disabling the IPX protocol modules on both ends of the point-to-point link. IPXCP uses the same packet exchange mechanism as the Link Control Protocol (LCP). IPXCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. IPXCP packets received before this phase is reached should be silently discarded. The IPX Control Protocol is exactly the same as the Link Control Protocol [1] with the following exceptions: Data Link Layer Protocol Field Exactly one IPXCP packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 802B (IPX Control Protocol). Code field Only Codes 1 through 7 (Configure-Request, Configure- Ack, Configure-Nak, Configure-Reject, Terminate- Request, Terminate-Ack and Code-Reject) are used. Other Codes should be treated as unrecognized and should result in CodeRejects. Timeouts IPXCP packets may not be exchanged until PPP has reached the Network- Layer Protocol phase. An implementation should be prepared to wait for Authentication and Link Quality Determination to finish before timing out waiting for a Configure-Ack or other response. It is suggested that an implementation give up only after user intervention or a configurable amount of time. Allen [Page 2] Internet Draft IPXCP June 1992 Configuration Option Types Since IPX is intended to use a variety of data link mechanisms transparently (emulated or otherwise), end- to-end knowledge of IPX specifics are included in the IPX WAN protocol defined in [Ref 5] (which includes use over PPP). Therefore no configuration options are used. Sending IPX Datagrams Before any IPX packets may be communicated, PPP must reach the Network-Layer Protocol phase, and the IPX Control Protocol must reach the Opened state. Exactly one IPX packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 002B (IPX Protocol). The maximum length of an IPX packet transmitted over a PPP link is the same as the maximum length of the Information field of a PPP data link layer frame. 3. IPXCP Configuration Options There are currently no configuration options defined for the IPX Control Protocol. 4. Security Considerations Security issues are not discussed in this memo. 5. References [1] Simpson, W. A., "The Point-to-Point Protocol for the Transmission of Multi-Protocol of Datagrams Over Point- toPoint Links", RFC 1331, May 1992. [2] Postel, J., "Internet Protocol", RFC 791, USC/Information Sciences Institute, September 1981. [3] Reynolds, J., Postel,J., "Assigned Numbers", RFC 1060, USC/Information Sciences Institute, March 1990. [4] Novell, Inc., "NetWare System Interface Technical Overview", Novell Part Number 883-001143-001 [5] Allen, M., "Novell IPX Over Various WAN Media", Novell, Inc., June 1992. Allen [Page 3] Internet Draft IPXCP June 1992 6. Acknowledgments Most of the text in this document was taken from RFC 1331, May 1992. 7. Obsoletes This document obsoletes an earlier document produced in January 1992 which limited this Internet Draft to IPX with a RIP/SAP only routing protocol. This document does not impose this restriction, but instead references an Informational RFC describing how Novell operates over ALL WAN media and negotiates the routing protocol at an IPX level using IPX packets [Ref 5]. 8. Contact Points Chair's Address: The working group can be contacted via the current chair: Brian Lloyd Lloyd & Associates 3420 Sudbury Road Cameron Park, California 95682 Phone: (916) 676-1147 EMail: brian@ray.lloyd.com Author's Address: Michael Allen Novell, Inc., 2180, Fortune Drive, San Jose, CA 95131 EMail: MALLEN@NOVELL.COM Allen [Page 4] From ietf-ppp-request@ucdavis.ucdavis.edu Sat Jun 6 12:42:03 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22078; Sat, 6 Jun 92 12:39:10 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18477; Sat, 6 Jun 92 12:19:56 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21510; Sat, 6 Jun 92 12:10:32 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21429; Sat, 6 Jun 92 12:05:36 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA00527; Sat, 6 Jun 92 12:03:35 PDT Date: Sat, 6 Jun 92 12:03:35 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9206061903.AA00527@ray.lloyd.com> To: gunner@libeb.LKG.DEC.COM Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: "(Chris Gunner)"'s message of Fri, 05 Jun 92 12:11:25 -0400 <9206051611.AA05624@libeb.LKG.DEC.COM> Subject: What happened to 16/32 bit FCS negotiation option in RFC 1331 ? Date: Fri, 05 Jun 92 12:11:25 -0400 From: "(Chris Gunner)" X-Mts: smtp Brian, OK, thanks for the prompt reply. Is the option actually described in a separate document yet or is that just the plan ? Meanwhile we just assume that the option still exists as described in the lcp-03 Internet Draft and the 32bitFCS Internet Draft ? Your assumption is correct. I look forward to seeing your implementation. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Sat Jun 6 12:50:41 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22182; Sat, 6 Jun 92 12:44:55 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18488; Sat, 6 Jun 92 12:23:44 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21514; Sat, 6 Jun 92 12:10:43 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21447; Sat, 6 Jun 92 12:08:36 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA00536; Sat, 6 Jun 92 12:07:53 PDT Date: Sat, 6 Jun 92 12:07:53 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9206061907.AA00536@ray.lloyd.com> To: jnc@ginger.lcs.mit.edu Cc: gunner@libeb.lkg.dec.com, ietf-ppp@ucdavis.ucdavis.edu, jnc@ginger.lcs.mit.edu In-Reply-To: Noel Chiappa's message of Fri, 5 Jun 92 17:23:00 -0400 <9206052123.AA14369@ginger.lcs.mit.edu> Subject: What happened to 16/32 bit FCS negotiation option in RFC 1331 ? Yes, as far as I know, the numbers for 16/32bit FCS are still reserved by the IANA but do not appear in the LCP document for obvious reasons. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 8 09:23:22 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20097; Mon, 8 Jun 92 09:10:28 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25787; Mon, 8 Jun 92 08:30:20 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18556; Mon, 8 Jun 92 08:21:26 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18321; Mon, 8 Jun 92 08:10:39 -0700 Received: by europa.clearpoint.com (4.1/1.34) id AA00277; Mon, 8 Jun 92 11:02:13 EDT Date: Mon, 8 Jun 92 11:02:13 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9206081502.AA00277@europa.clearpoint.com> To: bsimpson@angband.stanford.edu, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: new mib In-Reply-To: Mail from '"William Allen Simpson" ' dated: Thu, 4 Jun 92 13:49:37 EDT bill, i'll make the general changes you suggest. however, i intend to back away some from the text in the description that seems to be "specifying" ppp protocol activities. a mib does not specify the "mib-ed" protocol. the status variables will just say: "the current value of the for the local|remote ppp entity" instead of > > DESCRIPTION > "The current value of the for the > PPP Entity. Initially, and during negotiation, the > value is the default. The value is changed to its final > value when negotiation has completed." the second and third sentences smack too much of protocol actions. the possibility exists that the ppp spec would be changed and the mib is overlooked. this would lead to confusion in the community. > This means that each config status and initial object should have the > DEFVAL part as well. DEFVALs are only needed on settable objects. From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 8 10:54:30 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22784; Mon, 8 Jun 92 10:32:58 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27168; Mon, 8 Jun 92 09:52:04 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21130; Mon, 8 Jun 92 09:43:49 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from uu2.psi.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20921; Mon, 8 Jun 92 09:34:31 -0700 Received: from python.microcom.com by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA07689; Mon, 8 Jun 92 12:33:31 -0400 Date: Mon, 8 Jun 92 10:22:59 EDT From: kec@microcom.com (Ken Culbert) Received: by python.microcom.com (4.1/3.1.090690-Microcom Inc.) id AA10873; Mon, 8 Jun 92 10:22:59 EDT Message-Id: <9206081422.AA10873@python.microcom.com> To: cranch@novell.com Subject: IPXCP and IPXWAN Cc: ietf-ppp@ucdavis.ucdavis.edu Chris, I read with interest the long-anticpated IPXCP and IPXWAN drafts but was disappointed as neither addressed our (Microcom's) main concern: Netware traffic over switched telephone lines. Do you have any plans to further develop either document to include such topics as NCP/IPX compression, windowing, address negotiation and routing protocols (some of which were included in the Shiva draft)? I realize Novell's position is that you DON'T want to include these options, but at least 2 vendors (Shiva and ICC) are using PPP to carry IPX traffic and performing some sort of proprietary compression. I would hope that Novell would define a spec so that things don't get totally out of control, which would presumably NOT be in your interest. Regards, Ken Culbert kec@microcom.com 617.551.1146 From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 9 08:33:26 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28923; Tue, 9 Jun 92 08:26:50 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06534; Tue, 9 Jun 92 07:59:50 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27920; Tue, 9 Jun 92 07:50:46 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27857; Tue, 9 Jun 92 07:47:27 -0700 Received: by europa.clearpoint.com (4.1/1.34) id AA00652; Tue, 9 Jun 92 10:39:09 EDT Date: Tue, 9 Jun 92 10:39:09 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9206091439.AA00652@europa.clearpoint.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: the mib well, things have quieted down some here. i've made the changes to the mib that have been suggested over the past couple of weeks and have a couple of questions: 1. before i burn up some computrons and email the revised mib to the group and to the i.d. directory, are there any other comments? make them NOW. PLEASE!!!!!! 2. at san diego we talked about splitting the mib documents up so that each sub-protocol of the ppp has its own mib document. this is a necessary task -- e.g. the current document could not be put forth as a standard because it talks about the ppp security stuff and ppp security is not standard and the mib can not be "ahead" of the "mibbed protocols" in terms of standardization. i will make this change. i propose the following documents: ppplcp-mib -- contains the lcp level stuff. also contains the parts common to all the other mibs (e.g. definition of the OBJECT IDENTIFIERS under which all other parts of the mib lie). ppplqr-mib -- lqr-specific mib variables. pppipcp-mib -- ipncp-specific mib variables. pppbncp-mib -- bridging-specific mib variables. pppsecurity-mib -- security-specific mib variables. (later on there will be ppp-decnet, ppp-osi, ppp-novell, ppp-slithernet, etc, etc, etc). how does this sound? 3. i would like to take this opportunity to remind folks that the new specs are now standards, so we really really really really need to finish the parts of the mib that pertain to the standardized parts of ppp. do we think that we can wrap up the lcp, lqr, ipcp and bncp parts of the mib at the boston ietf? i think that we should. frank From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 9 11:57:24 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05208; Tue, 9 Jun 92 11:42:55 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08775; Tue, 9 Jun 92 11:20:23 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04303; Tue, 9 Jun 92 11:14:23 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03955; Tue, 9 Jun 92 11:00:44 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA00436; Tue, 9 Jun 92 10:59:32 PDT Date: Tue, 9 Jun 92 10:59:32 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9206091759.AA00436@ray.lloyd.com> To: kasten@europa.clearpoint.com Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Frank Kastenholz's message of Tue, 9 Jun 92 10:39:09 EDT <9206091439.AA00652@europa.clearpoint.com> Subject: the mib Sender: ietf-ppp-request@ucdavis.edu Date: Tue, 9 Jun 92 10:39:09 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) 2. at san diego we talked about splitting the mib documents up so that each sub-protocol of the ppp has its own mib document. this is a necessary task -- e.g. the current document could not be put forth as a standard because it talks about the ppp security stuff and ppp security is not standard and the mib can not be "ahead" of the "mibbed protocols" in terms of standardization. The security document has been reported out of the IESG to the IAB. What I hear is that voting on this doc is merely a formallity (actually there was a request for a very minor editorial change) and then the security doc will become an RFC (RFC 1334 to be exact). Therefore it is acceptable to treat the security doc as if it is an RFC. i will make this change. i propose the following documents: ppplcp-mib -- contains the lcp level stuff. also contains the parts common to all the other mibs (e.g. definition of the OBJECT IDENTIFIERS under which all other parts of the mib lie). ppplqr-mib -- lqr-specific mib variables. pppipcp-mib -- ipncp-specific mib variables. pppbncp-mib -- bridging-specific mib variables. pppsecurity-mib -- security-specific mib variables. (later on there will be ppp-decnet, ppp-osi, ppp-novell, ppp-slithernet, etc, etc, etc). how does this sound? This makes a great deal of sense to me since it appears as if PPP is going to be very dynamic over then next year. From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 10 09:22:58 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12535; Wed, 10 Jun 92 09:15:22 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17771; Wed, 10 Jun 92 08:41:24 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11317; Wed, 10 Jun 92 08:35:02 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from sonny.proteon.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11083; Wed, 10 Jun 92 08:27:12 -0700 Received: by sonny.proteon.com (5.59/1.6) id AA28430; Wed, 10 Jun 92 11:25:39 EDT Date: Wed, 10 Jun 92 11:25:39 EDT From: jas@proteon.com (John A. Shriver) Message-Id: <9206101525.AA28430@sonny.proteon.com> To: brad@Cayman.COM Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: brad@Cayman.COM's message of Wed, 10 Jun 92 09:44:09 -0400 <9206101344.AA10380@haiti.Cayman.COM> Subject: Novell IPXWAN 1. On the other side of the fence, I presently implement IPX over X.25 in a proprietary way. Obviously, I want to get with the program, and will have to implement IPXWAN for X.25. I'd rather be able to use that code on PPP as well, rather than write another LCP. 2. The protocol Novell uses for NETBIOS emulation requires all networks to have network numbers. (I won't go further than that, since Novell hasn't published that protocol, and I don't feel like helping the competitors who haven't figured it out yet.) If you're not using that NETBIOS emulation, you don't need to number all networks. We allow that, but it does let the users sabotage themselves. (They are so good at that!) 3. As for using the home port's network number in IPXWAN, that may not work. It is not necessarily unique, and they want a unique number. The internal network number does have to be unique. You're not obligated to report it via RIP if there's nothing on it. (However, putting your SAP services on it does have advantages, elminating the bias towards the `A' LAN.) It's just something the user has to type in (ugh) if you don't have an internal net. From ietf-ppp-request@aggie.ucdavis.edu Wed Jun 10 09:52:12 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13319; Wed, 10 Jun 92 09:43:06 -0700 Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA18278; Wed, 10 Jun 92 09:24:48 -0700 Sender: ietf-ppp-request@aggie.ucdavis.edu Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA18124; Wed, 10 Jun 92 09:11:06 -0700 From: ccskiz@aggie.ucdavis.edu (Elizabeth St. Goar) Date: Wed, 10 Jun 92 09:11:06 -0700 Message-Id: <9206101611.AA18124@aggie.ucdavis.edu> To: ietf-ppp@aggie.ucdavis.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14047; Tue, 9 Jun 92 18:50:50 -0700 Received: from uu.psi.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19336; Tue, 9 Jun 92 18:44:13 -0700 Received: from svcdudes.comby uu.psi.com (5.65b/4.1.031792-PSI/PSINet) id AA09495; Tue, 9 Jun 92 21:22:40 -0400 Received: by svcdudes.com (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA18604; Tue, 9 Jun 92 17:30:49 PDT Date: Tue, 9 Jun 92 17:30:49 PDT From: roger@svcdudes.com (Roger Phillip) Message-Id: <9206100030.AA18604@svcdudes.com> To: ietf-ppp-request@ucdavis.ucdavis.edu Subject: PPP vs. SLIP Cc: svctech!roger My request is mainly for information. We at Software Ventures are investi- gating implementing PPP support in our product. In our investigations we have become increasingly aware of PPP and SLIP. I was wondering if anyone could clear up a few points for me: 1) Do you feel that vendors are better serving their clients and their firms by implementing PPP versus SLIP at this point in time? 2) Is there significant support for PPP on the Internet today or in the near future, or is the short and mid-term reality SLIP? 3) To my kknowledge PPP is a superset of SLIP in terms of facilities support, reliable transport, etc. Does this also imply that if I have PPP support in my product that I am also compatible to and can use SLIP facilities? Thanks in advance for your time and information. I look forward to hearing from you in the near future. Roger Phillip Director, Product Management Software Ventures Corporation From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 10 11:49:13 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17282; Wed, 10 Jun 92 11:39:58 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA19838; Wed, 10 Jun 92 11:10:20 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15936; Wed, 10 Jun 92 11:02:18 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15708; Wed, 10 Jun 92 10:57:42 -0700 Received: from na.novell.com by newsun (4.1/smi4.1.1.v91190) id AA06930; Wed, 10 Jun 92 10:48:16 PDT Received: by na.novell.com (4.1/SMI-4.1) id AA27041; Wed, 10 Jun 92 10:50:09 PDT Date: Wed, 10 Jun 92 10:50:09 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9206101750.AA27041@na.novell.com> To: brad@Cayman.COM, cranch@novell.com Subject: Re: Novell IPXCP Internet Draft Cc: MALLEN@novell.com, ietf-ppp@ucdavis.ucdavis.edu Hi Brad, You wrote: > Mummm... I have several questions, most likely reflecting ignorance on my > part. If this is not right for the list, someone please slap my hand. I think it belongs on the list. > re: IPXCP and IPXWAN > > 1. Gosh. Another protocol to negotiate routing info. Ok, but how do I > reconcile this with my anal-retentive desire to reuse my existing PPP > option code for IPX? > > Try this on for size: I implement some flavor or Marty's (a.k.a. > Shiva's) IPXCP which has options. If I like them and we converge, all > is good and IPX flows. I also implement IPXWAN but it is "dormant" > (perhaps "submissive" is a better words, but I don't read > alt.sex.bondage.what-have-you ;-) until it receives a timer request. > Certainly I could add a knerd-knob which says "bag IPXCP options and > only use IPXWAN" for hard-core Novell users. This seems like a reasonable approach. Not that we should adopt Marty's proposal's options, but something like them. (We are considering adding them to our draft). The problem is that since we own IPX, and customers wanting to run IPX will be running NetWare, your primary objective should be to interoperate with NetWare, meaning IPXWAN. We are considering migrating toward an NCP protocol engine generic to all WAN medias, as is the iplpdn wg. That makes adding the options now appear very forward-looking. > 2. In IPXWAN, is appears the link *must* have a network number. Is > there a technical reason for this? Or even an "it's easier to > administer" reason? I'm open to any good reason, but please > understand I'm currently on a extended "plug and play, no > configuration" jag. This is our implementation limitation, and will be removed in the future. Right now, it is requrired. To help with config ease of use, you can set up a pool of addresses to assign to WAN links, as is suggested in the draft. > 3. If my IPX router has no "internal net #" (mine does not), can I use > the "home port's" network # instead? I'm confused. My local services > (i.e. advertised via SAP) live on one port, which I call the "home port" > (ok, now you know, multihoming is hard and I punted for now) Hmmm. Good question. I'll let Michael answer that one. > -brad Chris From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 10 12:14:47 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18284; Wed, 10 Jun 92 12:06:22 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA20244; Wed, 10 Jun 92 11:40:35 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17085; Wed, 10 Jun 92 11:34:06 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16761; Wed, 10 Jun 92 11:27:03 -0700 Received: from na.novell.com by newsun (4.1/smi4.1.1.v91190) id AA07390; Wed, 10 Jun 92 11:26:18 PDT Received: by na.novell.com (4.1/SMI-4.1) id AA27949; Wed, 10 Jun 92 11:28:06 PDT Date: Wed, 10 Jun 92 11:28:06 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9206101828.AA27949@na.novell.com> To: brad@Cayman.COM, cranch@novell.com Subject: Re: Novell IPXCP Internet Draft Cc: MALLEN@novell.com, ietf-ppp@ucdavis.ucdavis.edu Hi Brad, I've been thinking, and talking to Michael. So... I wrote: > > re: IPXCP and IPXWAN > > > > 1. Gosh. Another protocol to negotiate routing info. Ok, but how do I > > reconcile this with my anal-retentive desire to reuse my existing PPP > > option code for IPX? > > > > Try this on for size: I implement some flavor or Marty's (a.k.a. > > Shiva's) IPXCP which has options. If I like them and we converge, all > > is good and IPX flows. I also implement IPXWAN but it is "dormant" > > (perhaps "submissive" is a better words, but I don't read > > alt.sex.bondage.what-have-you ;-) until it receives a timer request. > > Certainly I could add a knerd-knob which says "bag IPXCP options and > > only use IPXWAN" for hard-core Novell users. > > This seems like a reasonable approach. Not that we should adopt > Marty's proposal's options, but something like them. (We are > considering adding them to our draft). The problem is that since > we own IPX, and customers wanting to run IPX will be running NetWare, > your primary objective should be to interoperate with NetWare, > meaning IPXWAN. We are considering migrating toward an NCP protocol > engine generic to all WAN medias, as is the iplpdn wg. That makes > adding the options now appear very forward-looking. Reasonable, but too early. If everyone plays ball, and does IPXWAN, why would you want to do it another way that is not interoperable with us? This is a reasonable approach AFTER we put the IPXCP NCP of PPP over all other WAN medias, like X.25, ISDN in the packet mode, etc. In the mean-time, you are welcome to come to us to get a number for an option that we haven't defined yet, like compression, and add it to IPXWAN. We can also discuss what the options are, numbers they will have, and publish it AFTER we get an NCP engine for all WAN links. Now here's an honest look at the hole we are trying to avoid. If we do assign numbers and publish now, and get an rfc number, y'all will go off and do it, and not IPXWAN. Then our customers will bitch at us for not interoperating with you third parties. That would be VERY bad. Now there IS something everyone can do to accelerate this process: work with us to put NCP over all WAN media. So far, the IPlPDN WG seems most appropriate for this. Brian succesfully evangelized this idea in San Diego, and now is the time to make it happen. The bottom line is that we CANNOT do anything that is not general for ALL WAN media. That's why we did IPXWAN. > > 3. If my IPX router has no "internal net #" (mine does not), can I use > > the "home port's" network # instead? I'm confused. My local services > > (i.e. advertised via SAP) live on one port, which I call the "home port" > > (ok, now you know, multihoming is hard and I punted for now) > > Hmmm. Good question. I'll let Michael answer that one. Michael sez use your primary net# (your 'home port's #). This is in the spec. > > -brad > Chris Chris From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 10 12:23:18 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18429; Wed, 10 Jun 92 12:10:41 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA20525; Wed, 10 Jun 92 11:50:34 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17602; Wed, 10 Jun 92 11:47:16 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17022; Wed, 10 Jun 92 11:31:56 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA01646; Wed, 10 Jun 92 11:31:04 PDT Date: Wed, 10 Jun 92 11:31:04 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9206101831.AA01646@ray.lloyd.com> To: brad@Cayman.COM Cc: cranch@novell.com, MALLEN@NOVELL.COM, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: brad@Cayman.COM's message of Wed, 10 Jun 92 09:44:09 -0400 <9206101344.AA10380@haiti.Cayman.COM> Subject: Novell IPXCP Internet Draft I just want to add here that I told the Novell folks that they had to provide a mechanism for address negotiation but that I wouldn't insist on them doing it in an NCP negotiation so long as they document the mechanism so that others may be interoperable. I was fully aware that this might break existing IPX-over-PPP. On the other hand, IPX is Novell's *proprietary* protocol. We have no say in how they do things and if they choose to do things in a different manner, we have no power to push them in our desired direction. I did "encourage" them to document their upper-layer address negotiation scheme by "resisting" their desire to get the IPXCP doc turned into an RFC without the address negotiation. I feel that what we now have is a reasonable compromise. On the other hand, I still encourage you and the folks at Shiva to document the IPX/SPX header compression mechanism. Adding that to Novell's draft would be, IMHO, a good idea. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 10 12:56:50 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19770; Wed, 10 Jun 92 12:48:51 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA21266; Wed, 10 Jun 92 12:30:12 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18798; Wed, 10 Jun 92 12:21:10 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18425; Wed, 10 Jun 92 12:10:34 -0700 Received: from na.novell.com by newsun (4.1/smi4.1.1.v91190) id AA08102; Wed, 10 Jun 92 12:06:15 PDT Received: by na.novell.com (4.1/SMI-4.1) id AA28855; Wed, 10 Jun 92 12:08:09 PDT Date: Wed, 10 Jun 92 12:08:09 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9206101908.AA28855@na.novell.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Updated IPXCP draft Hi Y'all, I updated the Status boilerplate, and added expiration dates, as required for internet drafts. cut here------ Network Working Group M. Allen Internet Draft Novell, Inc. June, 1992 IPX PPP Internetwork Packet Exchange Control Protocol [IPXCP] Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other that as a ''working draft'' or ''work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf- ppp@ucdavis.edu mailing list. The expiration date is 12/15/92. Distribution of this memo is unlimited. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring the IPX protocol over PPP and MUST be used in conjunction with the Informational RFC "Novell IPX Over Various WAN Media", June 1992, Michael Allen. Allen [Page 1] Internet Draft IPXCP June 1992 1. Introduction PPP has three main components: a. A method for encapsulating datagrams over serial links. b. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. c. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. PPP is designed to allow the simultaneous use of multiple network-layer protocols. 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 and optional facilities have been negotiated as needed by the LCP, 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. The link will remain configured for communications until explicit LCP or NCP packets close the link down, or until some external event occurs (an inactivity timer expires or network administrator intervention). 2. IPX PPP Network Control Protocol (NCP) The IPX Control Protocol (IPXCP) is responsible for configuring, enabling, and disabling the IPX protocol modules on both ends of the point-to-point link. IPXCP uses the same packet exchange mechanism as the Link Control Protocol (LCP). IPXCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. IPXCP packets received before this phase is reached should be silently discarded. The IPX Control Protocol is exactly the same as the Link Control Protocol [1] with the following exceptions: Data Link Layer Protocol Field Exactly one IPXCP packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 802B (IPX Control Protocol). Allen [Page 2] Internet Draft IPXCP June 1992 Code field Only Codes 1 through 7 (Configure-Request, Configure- Ack, Configure-Nak, Configure-Reject, Terminate- Request, Terminate-Ack and Code-Reject) are used. Other Codes should be treated as unrecognized and should result in CodeRejects. Timeouts IPXCP packets may not be exchanged until PPP has reached the Network- Layer Protocol phase. An implementation should be prepared to wait for Authentication and Link Quality Determination to finish before timing out waiting for a Configure-Ack or other response. It is suggested that an implementation give up only after user intervention or a configurable amount of time. Configuration Option Types Since IPX is intended to use a variety of data link mechanisms transparently (emulated or otherwise), end- to-end knowledge of IPX specifics are included in the IPX WAN protocol defined in [Ref 5] (which includes use over PPP). Therefore no configuration options are used. Sending IPX Datagrams Before any IPX packets may be communicated, PPP must reach the Network-Layer Protocol phase, and the IPX Control Protocol must reach the Opened state. Exactly one IPX packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 002B (IPX Protocol). The maximum length of an IPX packet transmitted over a PPP link is the same as the maximum length of the Information field of a PPP data link layer frame. 3. IPXCP Configuration Options There are currently no configuration options defined for the IPX Control Protocol. 4. Security Considerations Security issues are not discussed in this memo. Allen [Page 3] Internet Draft IPXCP June 1992 5. References [1] Simpson, W. A., "The Point-to-Point Protocol for the Transmission of Multi-Protocol of Datagrams Over Point- toPoint Links", RFC 1331, May 1992. [2] Postel, J., "Internet Protocol", RFC 791, USC/Information Sciences Institute, September 1981. [3] Reynolds, J., Postel,J., "Assigned Numbers", RFC 1060, USC/Information Sciences Institute, March 1990. [4] Novell, Inc., "NetWare System Interface Technical Overview", Novell Part Number 883-001143-001 [5] Allen, M., "Novell IPX Over Various WAN Media", Novell, Inc., June 1992. 6. Acknowledgments Most of the text in this document was taken from RFC 1331, May 1992. 7. Obsoletes This document obsoletes an earlier document produced in January 1992 which limited this Internet Draft to IPX with a RIP/SAP only routing protocol. This document does not impose this restriction, but instead references an Informational RFC describing how Novell operates over ALL WAN media and negotiates the routing protocol at an IPX level using IPX packets [Ref 5]. 8. Expiration Date The expiration date of this document is 12/15/92. Allen [Page 4] Internet Draft IPXCP June 1992 9. Contact Points Chair's Address: The working group can be contacted via the current chair: Brian Lloyd Lloyd & Associates 3420 Sudbury Road Cameron Park, California 95682 Phone: (916) 676-1147 EMail: brian@ray.lloyd.com Author's Address: Michael Allen Novell, Inc., 2180, Fortune Drive, San Jose, CA 95131 EMail: MALLEN@NOVELL.COM Allen [Page 5] From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 10 14:32:41 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23002; Wed, 10 Jun 92 14:28:36 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA22406; Wed, 10 Jun 92 14:10:37 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22195; Wed, 10 Jun 92 14:02:22 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21870; Wed, 10 Jun 92 13:53:37 -0700 Received: from na.novell.com by newsun (4.1/smi4.1.1.v91190) id AA10939; Wed, 10 Jun 92 13:52:51 PDT Received: by na.novell.com (4.1/SMI-4.1) id AA01189; Wed, 10 Jun 92 13:54:43 PDT Date: Wed, 10 Jun 92 13:54:43 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9206102054.AA01189@na.novell.com> To: brian@lloyd.com, cranch@novell.com Subject: Re: Novell IPXCP Internet Draft Cc: MALLEN@novell.com, brad@Cayman.COM, ietf-ppp@ucdavis.ucdavis.edu Hi Brian, > Sender: ietf-ppp-request@ucdavis.edu > Date: Wed, 10 Jun 92 11:28:06 PDT > From: cranch@novell.com (Christopher Ranch) > > ... In the mean-time, > you are welcome to come to us to get a number for an option that we haven't > defined yet, like compression, and add it to IPXWAN. We can also discuss > what the options are, numbers they will have, and publish it AFTER we get > an NCP engine for all WAN links. > > Uh, that is not quite how it works. You need to go to IANA to get a > number, not to Novell. Chris, you need to work WITH Brad and Marty > who are giving you valid input. This is the IETF way of doing things. > (I am not trying to be either pompous or nasty here so please don't > read that into this message.) Nasty? You? Wouldn't dream of it ;). However, the numbers I am referring to are for extending OUR proprietary protocol to provide new options, whether we propose them or someone else. I am NOT talking about usurping IANA's control over Internet numbers. > Now here's an honest look at the hole we are trying to avoid. If we do > assign numbers and publish now, and get an rfc number, y'all will go off > and do it, and not IPXWAN. Then our customers will bitch at us for not > interoperating with you third parties. That would be VERY bad. > > As I understand it, that is not what we are talking about here. We > are talking about a compression scheme similar to VJ header > compression for IP that is outside of the scope of IPXWAN. In that > case it is reasonable that they add the compression to the IPXCP > rather than to the IPXWAN doc. If you think about it this header > compression is more appropriate to low-speed dedicated links and may > not be appropriate on other WAN media. We can add the VJish compression into IPXWAN, when and if anyone asks. We're looking into not just header, but data compression. > Now there IS something everyone can do to accelerate this process: work > with us to put NCP over all WAN media. So far, the IPlPDN WG seems most > appropriate for this. Brian succesfully evangelized this idea in San Diego, > and now is the time to make it happen. The bottom line is that we CANNOT > do anything that is not general for ALL WAN media.That's why we did IPXWAN. > > Chris: in general, I agree with you. I only disagree on the details. > I think that you (Novell) need to be a little more flexible in the > area of IPXCP, OK? > > Brian Lloyd, WB6RQN Lloyd & Associates I think we agree all around. We (Novell) just doesn't want to shoot ourselves in the collective foot by incorrectly setting customer expectations that you only need IPXCP options, when you MUST have all the required IPXWAN options. I think semantics will be everything here. The problem we need to solve is convincing ourselves that we can require IPXWAN until we are ready to say otherwise. Defining IPXCP options would naturally lead customers to believe that we support them. Again, this is what IPX is over WAN links. Ask your marketing folk what value interoperating with us is. I didn't have anything to do with the history, just documenting it. I feel I must quote Brian for myself here: > (I am not trying to be either pompous or nasty here so please don't > read that into this message.) Respectfully, Chris From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 10 16:31:54 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26593; Wed, 10 Jun 92 16:20:07 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23386; Wed, 10 Jun 92 16:00:15 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25924; Wed, 10 Jun 92 15:53:43 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from CAYMAN.CAYMAN.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25643; Wed, 10 Jun 92 15:45:10 -0700 Received: from haiti.Cayman.COM (moon-patrol.cayman.com) by cayman.Cayman.COM (4.1/SMI-4.0) id AA11543; Wed, 10 Jun 92 18:44:11 EDT Received: from localhost by haiti.Cayman.COM (4.1/SMI-4.1) id AA10598; Wed, 10 Jun 92 18:47:56 EDT Message-Id: <9206102247.AA10598@haiti.Cayman.COM> To: jas@proteon.com (John A. Shriver) Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: Novell IPXWAN In-Reply-To: Mail from jas@proteon.com (John A. Shriver) dated Wed, 10 Jun 92 11:25:39 EDT <9206101525.AA28430@sonny.proteon.com> Date: Wed, 10 Jun 92 18:47:55 -0400 From: brad@Cayman.COM >> >> 2. The protocol Novell uses for NETBIOS emulation requires all networks >> to have network numbers. (I won't go further than that, since Novell >> hasn't published that protocol, and I don't feel like helping the >> competitors who haven't figured it out yet.) >> >> If you're not using that NETBIOS emulation, you don't need to number >> all networks. We allow that, but it does let the users sabotage >> themselves. (They are so good at that!) I guess I don't see how this could even be a factor on a point-to-point link. I.e. the link should play no factor in any traffic, even the NETBIOS emulation. Am I crazy? (i.e. the end nodes will never know that the link was transited) >> 3. As for using the home port's network number in IPXWAN, that may not >> work. It is not necessarily unique, and they want a unique number. >> The internal network number does have to be unique. You're not >> obligated to report it via RIP if there's nothing on it. (However, >> putting your SAP services on it does have advantages, elminating the >> bias towards the `A' LAN.) It's just something the user has to type >> in (ugh) if you don't have an internal net. I'm confused by this. How can any network number in IPX not be unique? They all have to be unique, yes? If you mean that the protocol needs a unique # because there could be two different routers, each with the same "home port net #" (from my example) dialing into the *same* netware router, then I understand. If this is not the case, please explain. thanks -brad From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 10 16:43:18 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27058; Wed, 10 Jun 92 16:35:11 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23516; Wed, 10 Jun 92 16:20:06 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26383; Wed, 10 Jun 92 16:12:05 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from sonny.proteon.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26185; Wed, 10 Jun 92 16:03:26 -0700 Received: by sonny.proteon.com (5.59/1.6) id AA03837; Wed, 10 Jun 92 19:02:02 EDT Date: Wed, 10 Jun 92 19:02:02 EDT From: jas@proteon.com (John A. Shriver) Message-Id: <9206102302.AA03837@sonny.proteon.com> To: brad@Cayman.COM Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: brad@Cayman.COM's message of Wed, 10 Jun 92 18:47:55 -0400 <9206102247.AA10598@haiti.Cayman.COM> Subject: Novell IPXWAN The NETBIOS API syntax requires global broadcast for naming, across an IPX internet. Novell did NOT do this using the FFFFFFFF IPX network number and reverse path forwarding. (Some XNS implementations do this.) They hacked up their own algorithm, an extension to IPX, and it requires all links to have non-zero network numbers to prevent looping. As for unique numbers, I guess using the home network number would fail to be unique only if you ran a WAN link between two routers on the same LAN. Oh, maybe you would also have problems if the home interface was a WAN. At any rate, a unique number is "just" another one of those blasted things the user has to enter. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 11 04:22:04 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17759; Thu, 11 Jun 92 04:16:16 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA26255; Thu, 11 Jun 92 03:59:48 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17287; Thu, 11 Jun 92 03:51:38 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from azea.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17133; Thu, 11 Jun 92 03:44:52 -0700 Received: by azea.clearpoint.com (4.1/1.34) id AA00350; Thu, 11 Jun 92 06:35:09 EDT Date: Thu, 11 Jun 92 06:35:09 EDT From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) Message-Id: <9206111035.AA00350@azea.clearpoint.com> To: ietf-ppp@ucdavis.ucdavis.edu Cc: martillo@azea.clearpoint.com In-Reply-To: Elizabeth St. Goar's message of Wed, 10 Jun 92 09:11:06 -0700 <9206101611.AA18124@aggie.ucdavis.edu> Subject: Sender: ietf-ppp-request@ucdavis.edu From: estgoar@ucdavis.edu (Elizabeth St. Goar) Date: Wed, 10 Jun 92 09:11:06 -0700 ---------------------- Forwarded Message Follows ---------------------- Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14047; Tue, 9 Jun 92 18:50:50 -0700 Received: from uu.psi.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19336; Tue, 9 Jun 92 18:44:13 -0700 Received: from svcdudes.comby uu.psi.com (5.65b/4.1.031792-PSI/PSINet) id AA09495; Tue, 9 Jun 92 21:22:40 -0400 Received: by svcdudes.com (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA18604; Tue, 9 Jun 92 17:30:49 PDT Date: Tue, 9 Jun 92 17:30:49 PDT From: roger@svcdudes.com (Roger Phillip) Message-Id: <9206100030.AA18604@svcdudes.com> To: ietf-ppp-request@ucdavis.ucdavis.edu Subject: PPP vs. SLIP Cc: svctech!roger My request is mainly for information. We at Software Ventures are investi- gating implementing PPP support in our product. In our investigations we have become increasingly aware of PPP and SLIP. I was wondering if anyone could clear up a few points for me: 1) Do you feel that vendors are better serving their clients and their firms by implementing PPP versus SLIP at this point in time? Investigations here indicate that there are few complete implementations of PPP and that many of those which exist are basically non-interoperable. (Of course, Clearpoint's implementation is complete modulo supported network and link layers and will interoperate with complete PPP implementations modulo supported network and link layers. There is as of now no way to get around the inherent incorrectness of the PPP protocol reject mechanism.) PPP itself is misdesigned, overly complex protocol which shows little understanding of issues relating to inexpensive high-performance bridging over moderate to high-speed synchronous serial links. PPP will cause network topological problems in complex networks. PPP also breaks both the DOD Internetwork architecture and the ISO OSI architecture. In general the specification of PPP shows a lack of understanding of protocol design. This particular problem is however hardly unique to the PPP work emanating from the IETF but rather is generic to the serial line protocol work in practically all cases. SLIP on the other the other hand carries out one function well. 2) Is there significant support for PPP on the Internet today or in the near future, or is the short and mid-term reality SLIP? Significant support for PPP exists in the minds of the designers of PPP. 3) To my kknowledge PPP is a superset of SLIP in terms of facilities support, reliable transport, etc. Does this also imply that if I have PPP support in my product that I am also compatible to and can use SLIP facilities? No. Thanks in advance for your time and information. I look forward to hearing from you in the near future. A more cost effective more flexible approach to the issue of serial communications is to design a virtual mac/llc (link) protocol which runs on top of a virtual communications subnet composed of less expensive bridges (acting as packet switches) which can transparently interwork between FR, X.25, point-to-point serial links and whatever the latest fad in serial communications happens to be. In general, building wide-area networks via interconnecting multiprotocol routers is a relatively silly ill-considered idea (except from the standpoint of vendors of expensive multiprotocol routers). In the case of a TCP/IP-type network, such an exercise is essentially equivalent to having routers handle path-selection between hosts as well as path-selection between networks. While one can certainly do such a thing and such a design is not uncommon in older network designs uninfluenced by TCP/IP design concepts, such an approach does lead to problems which the IP design was supposed to correct. Virtual communications subnets may simplify some aspects of internetworking with demand circuits in that all issues of circuit establishment and teardown can be handled transparently (to routers) by bridges (acting as packet switches). The approach of implementing host-to-host path selection as well as physical link establishment at the network layer violates the spirit of both DARPA Internet Architecture and ISO OSI. PPP and a large part of IETF serial line protocol design represents the reincarnation of a networking model which the DOD Internet Architecture was created to supersede. Roger Phillip Director, Product Management Software Ventures Corporation Joachim Carlo Santos Martillo Ajami From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 11 07:12:13 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21704; Thu, 11 Jun 92 07:06:53 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA26677; Thu, 11 Jun 92 06:49:59 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21065; Thu, 11 Jun 92 06:42:17 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from alpha.Xerox.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20894; Thu, 11 Jun 92 06:33:51 -0700 Received: from dnsmaster ([13.252.44.4]) by alpha.xerox.com with SMTP id <12516>; Thu, 11 Jun 1992 06:32:48 PDT Received: from secundus.cinops.xerox.com by dnsmaster (4.1/SMI-4.1) id AA04935; Thu, 11 Jun 92 09:32:46 EDT Date: Thu, 11 Jun 1992 06:32:46 PDT From: eer@cinops.xerox.com (Edwards Reed) Message-Id: <9206111332.AA04935@dnsmaster> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: bizzare diatribe from Joachim Martillo Cc: martillo@azea.clearpoint.com My, what a pleasantly bizzare way to start a day. I guess we don't have to concern ourselves with yet another set of multiprotocol routers comming from Clearpoint, now do we? Well, their memory isn't bad, anyway... I am continually amused and dismayed by LAN centric experts who believe that if we just made spanning trees big enough, we could all play on the same virtual ethernet (or token ring) in the sky. This, after all, is the enabling technology that give us NETBIOS, LAT, and other similarly non-routable protocols which rely on regular flooding broadcasts to locate one another. Dandy for small 10-20 network clusters in a metro area with high bandwidth interconnnections. Questionable as a strategy for lashing together 18 timezones, 700-1000 lans and 20-30 countries. soapbox... Until the industry of 'experts' encounter networks of devices with more machines than they can count without taking off their shoes, they're not going to pursuade network service providers like me, with 45,000 hosts and many lans having 600+ hosts each, that bridging is the answer to everything. And no solution will be viable without very strict broadcast suppression techniques, of which universal (in the environment) directory services are the second most important tool (after routing technologies, themselves). ...soapbox Mr. Martillo's ascerbic comments about PPP design may or may not be accurate. I expect there'll be more network traffic from others on that matter. My objection is more to the tone of his remarks, and to the zealous self-righteousness that it conveys to this reader. Sweeping condemnations of broad technologies (like wide area routed networks) are amusing, but without constructive alternatives being proposed, do nothing but make the rest of the gentleperson's remarks so dubious as to cause me to dismiss the entire message as the ravings of someone with whom I'm grateful not to have to work on a daily basis. Ed Reed Xerox Corporation Corporate Internet From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 11 08:37:36 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23832; Thu, 11 Jun 92 08:22:51 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27689; Thu, 11 Jun 92 07:59:52 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23019; Thu, 11 Jun 92 07:53:30 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from hobbit.gandalf.ca by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22884; Thu, 11 Jun 92 07:47:31 -0700 Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA03416; Thu, 11 Jun 92 10:46:43 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA22513; Thu, 11 Jun 92 10:46:40 EDT Date: Thu, 11 Jun 92 10:46:40 EDT From: mm@gandalf.ca (Mississippi Mud) Message-Id: <9206111446.AA22513@cannibal.gandalf.ca> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: bizzare diatribe from Joachim Martillo Actually, Mr. Martillo is the best promoter of PPP anyone could ask for. If I had not read the ppp archives of his commentary, I would certainly not have quite the interest in it I currently have. I have therefore conluded that he is a mole in the service of Drew Perkins, Bill Simpson, and probably others who have an even greater stake in its success. Whether he comes out of this assignment alive or not, he should be given a medal. -Chris Sullivan mm@gandalf.ca From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 11 10:05:30 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26384; Thu, 11 Jun 92 09:52:23 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA28122; Thu, 11 Jun 92 08:43:58 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24279; Thu, 11 Jun 92 08:36:56 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from animal.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23774; Thu, 11 Jun 92 08:20:38 -0700 Received: by animal.clearpoint.com (4.1/1.34) id AA03395; Thu, 11 Jun 92 11:15:02 EDT Date: Thu, 11 Jun 92 11:15:02 EDT From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9206111515.AA03395@animal.clearpoint.com> To: eer@cinops.xerox.com, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: bizzare diatribe from Joachim Martillo In-Reply-To: Mail from 'eer@cinops.xerox.com (Edwards Reed)' dated: Thu, 11 Jun 1992 06:32:46 PDT >I guess we don't have to concern ourselves with yet another set of >multiprotocol routers comming from Clearpoint, now do we? Well, their >memory isn't bad, anyway... The comments of Mr. Martillo are not necessiarly those of Clearpoint Research Corporation. -- Frank Solensky / Clearpoint Research From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 11 10:05:46 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26591; Thu, 11 Jun 92 09:59:47 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA28491; Thu, 11 Jun 92 09:10:01 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24976; Thu, 11 Jun 92 09:00:51 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from azea.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24646; Thu, 11 Jun 92 08:50:20 -0700 Received: by azea.clearpoint.com (4.1/1.34) id AA00483; Thu, 11 Jun 92 11:39:09 EDT Date: Thu, 11 Jun 92 11:39:09 EDT From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) Message-Id: <9206111539.AA00483@azea.clearpoint.com> To: eer@cinops.xerox.com Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Edwards Reed's message of Thu, 11 Jun 1992 06:32:46 PDT <9206111332.AA04935@dnsmaster> Subject: bizzare diatribe from Joachim Martillo Date: Thu, 11 Jun 1992 06:32:46 PDT From: eer@cinops.xerox.com (Edwards Reed) My, what a pleasantly bizzare way to start a day. I guess we don't have to concern ourselves with yet another set of multiprotocol routers comming from Clearpoint, now do we? Actually, Clearpoint does make multiprotocol routers. Well, their memory isn't bad, anyway... Nor are our multiprotocol routers. I am continually amused and dismayed by LAN centric experts who believe that if we just made spanning trees big enough, we could all play on the same virtual ethernet (or token ring) in the sky. Did I say anything about spanning tree? I only mentioned path selection and communications subnets. There are other algorithms for path selection. And by the way I have over 10 years experience designing and implementing wide-area networks. I am continually amused and dismayed by routing fanatics who refuse to understand that there is no real distinction between networks composed of packet-switches and wide-area links and networks composed of bridges and LAN segments. They are both switching-fabric communications subnets. And by the way there is no real mathematical distinction between bridging and routing (both switch packets from one interface to another according to some algorithm). IP routers merely do a lot of work in deencapsulating and reencapsulating packets. You must pay for this extra work either in higher cost for faster technology or in lower performance. Now sometimes the extra cost is necessary in moving packets from one technology to another. At other times it is not. Though I have to admit that multiprotocol router vendors (Clearpoint included) won't object to your purchase of the top-of-the line most powerful multiprotocol router even if a less powerful less costly (but wire-speed) bridge were sufficient for your purposes. This, after all, is the enabling technology that give us NETBIOS, LAT, and other similarly non-routable protocols which rely on regular flooding broadcasts to locate one another. Dandy for small 10-20 network clusters in a metro area with high bandwidth interconnnections. Questionable as a strategy for lashing together 18 timezones, 700-1000 lans and 20-30 countries. The goodness or badness of NETBIOS and LAT is irrelevent to building wide-area networks using bridging (i.e. packet-switching technology). Anyway, did I say anything about make the wide-area networks of the world one gigantic communications subnet? Only some PTTs and major telephone carriers have this particular dream. It might make sense to build subnetworks from subcollections of wide-area links and bridges acting as packet-switches (much cheaper than multiprotocol routers) and then route between separate wide-area communications subnets. soapbox... Until the industry of 'experts' encounter networks of devices with more machines than they can count without taking off their shoes, they're not going to pursuade network service providers like me, with 45,000 hosts and many lans having 600+ hosts each, that bridging is the answer to everything. It is very easy to argue against points I did not make. And no solution will be viable without very strict broadcast suppression techniques, of which universal (in the environment) directory services are the second most important tool (after routing technologies, themselves). This comment is random. Do you seriously think strict broadcast suppression is impossible in a bridged (packet-switched) network? ...soapbox Mr. Martillo's ascerbic comments about PPP design may or may not be accurate. I write exactly what I think and prefer others do as well. Who wants to deal with obscure periphrasis and implications as an alternative to plain expression. I have yet to get a solution from PPP fans to the PPP protocol reject mechanism problem. I am beginning to suspect there isn't one. I expect there'll be more network traffic from others on that matter. My objection is more to the tone of his remarks, and to the zealous self-righteousness that it conveys to this reader. Accusations of self-righteousness are the last resort of politically correct when they have no response to valid criticism. Sweeping condemnations of broad technologies (like wide area routed networks) are amusing, but without constructive alternatives being proposed, do nothing but make the rest of the gentleperson's remarks so dubious as to cause me to dismiss the entire message as the ravings of someone with whom I'm grateful not to have to work on a daily basis. Let's try again then. By definition (in the DOD Internet Architecture) routers route between IP subnetworks which correspond to communications subnetworks. Building the wide-area communications subnetwork solely using IP routers may be an ill-considered idea for many reasons including 1) manageability, 2) typical router design choices, 3) flexibility and 4) cost which is an issue of consequence both to service users and service provides. Ed Reed Xerox Corporation Corporate Internet Joachim Carlo Santos Martillo Ajami From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 11 10:23:26 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27064; Thu, 11 Jun 92 10:14:56 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA28972; Thu, 11 Jun 92 09:39:45 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25853; Thu, 11 Jun 92 09:30:56 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from STATE.BBN.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25509; Thu, 11 Jun 92 09:22:09 -0700 Message-Id: <9206111622.AA25509@ucdavis.ucdavis.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: OSI over PPP Date: Thu, 11 Jun 92 12:16:36 -0400 From: akullber@BBN.COM Does a document exist which describes the OSI Control Protocol? If so, how do I get a copy? Is it on line? Thanks, Alan Kullberg From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 11 10:35:13 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27451; Thu, 11 Jun 92 10:26:59 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA29098; Thu, 11 Jun 92 09:50:09 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26238; Thu, 11 Jun 92 09:45:49 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from GINGER.LCS.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26092; Thu, 11 Jun 92 09:39:34 -0700 Received: by ginger.lcs.mit.edu id AA06915; Thu, 11 Jun 92 12:38:29 -0400 Date: Thu, 11 Jun 92 12:38:29 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206111638.AA06915@ginger.lcs.mit.edu> To: ietf-ppp@ucdavis.ucdavis.edu, martillo@azea.clearpoint.com Subject: Re: Cc: jnc@ginger.lcs.mit.edu Joachim, I've learned that it does little good to argue with you, but your latest blast of afterburner says something so off the wall that I can't resist responding. The approach of implementing host-to-host path selection as well as physical link establishment at the network layer violates the spirit of [the] DARPA Internet Architecture ... This statement is so wrong I can't find words to describe it. It just so happens that I was in the room(s) in the late 70's when the IP architecture was being written down. As a matter of fact, at one point, together with Ed Cain, I was handed the responsibility of editing the document that later became RFC-791. Having been there at the birth (and since I don't recall seeing you there), I suspect that my view of the 'spirit of the architecture' is probably more accurate than yours. In my book, PPP is fits *exactly* within the architecture. We recognized even that that the fact that the ARPANet (may it rest in peace) was wrong to do routing in the data link layer. I realize that this statement will have about the effect on you that a spitball does on an elephant, and I'm sure I'll get a long, detailed reply pointing out the 17 errors in each line of my message. Sorry, everyone, I just couldn't resist replying to this piece of utter nonsense. Noel From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 11 10:54:29 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28111; Thu, 11 Jun 92 10:45:46 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA29346; Thu, 11 Jun 92 10:11:06 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26736; Thu, 11 Jun 92 10:03:27 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from GINGER.LCS.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26444; Thu, 11 Jun 92 09:54:09 -0700 Received: by ginger.lcs.mit.edu id AA07039; Thu, 11 Jun 92 12:53:12 -0400 Date: Thu, 11 Jun 92 12:53:12 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206111653.AA07039@ginger.lcs.mit.edu> To: eer@cinops.xerox.com, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: bizzare diatribe from Joachim Martillo Cc: jnc@ginger.lcs.mit.edu, martillo@azea.clearpoint.com Ahah, you're new to the list! A number of us have had the pleasant experience of trying to debate Joachim, and the list at one point seriously debated asking that he be removed (which I was willing to recommend to the rest of the IESG if the WG so decided). While he often has some good points (I'd be the last to disagree that PPP is neither fish nor fowl), it's hard to get him to change his opinions. I am reminded of a quote by Burke (?) - "It is as futile to argue with those who have renounced the use of reason as it is to administer medicine to the dead". I'm not saying Joachim's renounced reason, but I must say, arguing with him does seem to bear an eerie resemblence to the latter activity. Noel From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 11 13:44:22 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03101; Thu, 11 Jun 92 13:38:09 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01933; Thu, 11 Jun 92 12:59:53 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01779; Thu, 11 Jun 92 12:51:02 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01343; Thu, 11 Jun 92 12:35:05 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02295; Thu, 11 Jun 92 12:33:24 PDT Date: Thu, 11 Jun 92 12:33:24 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9206111933.AA02295@ray.lloyd.com> To: jnc@ginger.lcs.mit.edu Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Noel Chiappa's message of Thu, 11 Jun 92 12:38:29 -0400 <9206111638.AA06915@ginger.lcs.mit.edu> Subject: No problem Noel. He is so off the wall sometimes that you feel compelled to try to bring some reason to the communication. In this case it is best to laugh, roll on the floor, invite in your friends, point to the screen, and generally treat it as an excellent work of technical humor. I must admit that his apparent dogmatic attitude is just about the best humor I have found on the Internet in quite some time. Just don't take it seriously. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 11 14:04:38 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03662; Thu, 11 Jun 92 13:56:26 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01561; Thu, 11 Jun 92 12:40:16 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01287; Thu, 11 Jun 92 12:32:51 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00940; Thu, 11 Jun 92 12:23:52 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02283; Thu, 11 Jun 92 12:21:49 PDT Date: Thu, 11 Jun 92 12:21:49 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9206111921.AA02283@ray.lloyd.com> To: eer@cinops.xerox.com Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Edwards Reed's message of Thu, 11 Jun 1992 06:32:46 PDT <9206111332.AA04935@dnsmaster> Subject: bizzare diatribe from Joachim Martillo Perhaps you are new here. The diatribes from JCSMA used to be a regular event on this mailing list. He would precipitate a discussion (I say this tongue-in-cheek) which would lead nowhere. The solution has been to basically ignore him and that seems to solve the problem. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 11 14:31:15 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04445; Thu, 11 Jun 92 14:17:08 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA02399; Thu, 11 Jun 92 13:30:14 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02610; Thu, 11 Jun 92 13:21:30 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from regal.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02374; Thu, 11 Jun 92 13:14:07 -0700 Received: by regal.cisco.com; Thu, 11 Jun 92 13:13:08 -0700 Date: Thu, 11 Jun 92 13:13:08 -0700 From: Dave Katz Message-Id: <9206112013.AA00556@regal.cisco.com> To: akullber@BBN.COM Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: akullber@BBN.COM's message of Thu, 11 Jun 92 12:16:36 -0400 <9206111622.AA25509@ucdavis.ucdavis.edu> Subject: OSI over PPP An Internet Draft on the subject should be appearing soon. Watch this space for details. Sender: ietf-ppp-request@ucdavis.edu Date: Thu, 11 Jun 92 12:16:36 -0400 From: akullber@BBN.COM Does a document exist which describes the OSI Control Protocol? If so, how do I get a copy? Is it on line? Thanks, Alan Kullberg From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 11 17:43:35 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11009; Thu, 11 Jun 92 17:30:29 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05118; Thu, 11 Jun 92 17:09:52 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09979; Thu, 11 Jun 92 17:00:52 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09662; Thu, 11 Jun 92 16:52:33 -0700 Received: from napa.TELEBIT.COM by apache (4.1/SMI-4.1/Telebit-Apache-Brent-910926) id AA20503 to ietf-ppp@ucdavis.edu; Thu, 11 Jun 92 16:51:36 PDT Received: from yoyo.telebit.com by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910507) id AA11794 to ietf@isi.edu; Thu, 11 Jun 92 16:51:35 PDT Date: Thu, 11 Jun 92 16:51:35 PDT From: mlewis@napa.Telebit.COM (Mark S. Lewis) Message-Id: <9206112351.AA11794@napa.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA09257; Thu, 11 Jun 92 16:52:28 PDT To: ietf@isi.edu, ietf-ppp@ucdavis.ucdavis.edu Subject: PPP Interoperability Meeting During the week of June 1-5, ten (10) of the leading networking vendors attended an event called the "PPP-Athon". It was hosted by Telebit in Sunnyvale. The pupose of the event was to determine the extent to which these vendor's products interoperate using PPP. The Point-to-Point-Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. 3Com Cayman cisco Systems FTP Software Livingston Enterprises Morning Star Technologies Network Applications Technology (NAT) Network Systems Novell Corp. Telebit Corp. Vendors tested their products interoperability over synchronous and dial-up asynchronous PPP connections. They tested routing IP, IPX (NetWare), AppleTalk, DECnet IV, and OSI protocol packets. Several vendors tested bridging over PPP links. Without exception, all vendors demonstrated interoperability. In every combination, products were able to open connections and send datagrams. During the week, almost all vendors made improvements to their products. There was an open dialog between vendors about their respective implementations. As a result, new features were added, numerous bugs were found and fixed, and interoperability issues were resolved. By their participation, these vendors also demonstrated a commitment to making their products interoperate. These vendors committed significant time and resources to testing their implementations at this event. ... Mark =========----------- Mark S. Lewis -----------========== inet: mlewis@telebit.com Telebit Corp. Telebit (408) 745-3232 uucp: uunet!telebit!mlewis Fax (408) 745-3810 From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 11 20:00:54 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15343; Thu, 11 Jun 92 19:53:43 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05845; Thu, 11 Jun 92 19:39:48 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14696; Thu, 11 Jun 92 19:30:47 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from GINGER.LCS.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14438; Thu, 11 Jun 92 19:24:24 -0700 Received: by ginger.lcs.mit.edu id AA10952; Thu, 11 Jun 92 22:23:27 -0400 Date: Thu, 11 Jun 92 22:23:27 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206120223.AA10952@ginger.lcs.mit.edu> To: brian@lloyd.com Subject: Re: Cc: ietf-ppp@ucdavis.ucdavis.edu, jnc@ginger.lcs.mit.edu Arrh, sorry everyone, for going non-linear like that. I was running on about 4 hours sleep for the last N days.. get a little snappy when I get like that. Noel From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 11 21:31:05 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18376; Thu, 11 Jun 92 21:25:44 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06123; Thu, 11 Jun 92 21:09:56 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17501; Thu, 11 Jun 92 21:00:30 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17404; Thu, 11 Jun 92 20:59:15 -0700 Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA01514; Thu, 11 Jun 92 20:58:07 -0700 Date: Thu, 11 Jun 92 12:39:10 EDT From: "William Allen Simpson" Message-Id: <415.bsimpson@angband.stanford.edu> To: eer@cinops.xerox.com (Edwards Reed) Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: bizzare diatribe from Joachim Martillo Good Sir: 1) we just ignore Joachim [...] Adjani, and have an official policy of not responding to his religious cruft. This is the PPP implementors working group list, and he is not a PPP implementor. 2) Unfortunately, he also pollutes other parts of the IETF, even though he obviously doesn't approve of the work. I no longer recommend Clearpoint equipment to clients, since their user relations are egregiously poor. 3) your text exceeded the 1000 bytes per line of SMTP, and I lost most of your comments. In the future, please reformat (to 70 or 80). 4) your pithy comments that were readable seemed on the mark. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 11 22:20:27 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20083; Thu, 11 Jun 92 22:16:52 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06293; Thu, 11 Jun 92 21:59:59 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19246; Thu, 11 Jun 92 21:50:55 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19158; Thu, 11 Jun 92 21:48:05 -0700 Received: by volitans.morningstar.com (5.65a/92042102) id AA03642; Fri, 12 Jun 92 00:46:30 -0400 Date: Fri, 12 Jun 92 00:46:30 -0400 From: Bob Sutterfield Message-Id: <9206120446.AA03642@volitans.morningstar.com> To: martillo@azea.clearpoint.com Cc: ietf-ppp@ucdavis.ucdavis.edu, roger@svcdudes.com (Roger Phillip), svctech!roger@mstar.morningstar.com In-Reply-To: martillo@azea.clearpoint.com (Joachim Martillo's message of Thu, 11 Jun 92 06:35:09 EDT <9206111035.AA00350@azea.clearpoint.com> Subject: PPP vs. SLIP Date: Thu, 11 Jun 92 06:35:09 EDT From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) Date: Tue, 9 Jun 92 17:30:49 PDT From: roger@svcdudes.com (Roger Phillip) Subject: PPP vs. SLIP We at Software Ventures are investigating implementing PPP support in our product.... 1) Do you feel that vendors are better serving their clients and their firms by implementing PPP versus SLIP at this point in time? Investigations here indicate that there are few complete implementations of PPP and that many of those which exist are basically non-interoperable. Hmmm, I'd like to see the results of your investigations, and the methology of your interoperability tests. Was the problem that few of the implementations you tested worked with each other, or that they didn't work with yours? If the former, those boxes' makers would benefit from your sharing what you found. (In fact, the reports I heard from last week's bake-off were much more encouraging than your bleak assessment.) If the latter, I didn't see Clearpoint mentioned on the preliminary list of bake-off attendees. Maybe your router would have benefitted from the week of packet-slinging. 2) Is there significant support for PPP on the Internet today or in the near future, or is the short and mid-term reality SLIP? Most of the dial-up IP connectivity vendors offer some of each. Those I've talked to are glad to see the increasing availability of PPP on their customers' machines, because it eases their support burden. They're glad for the commercial software because it's supported, and they're glad for PPP replacing SLIP because the finite-state machine can offer diagnostic information about why a failed connection failed. 3) To my knowledge PPP is a superset of SLIP in terms of facilities support, reliable transport, etc. Does this also imply that if I have PPP support in my product that I am also compatible to and can use SLIP facilities? No, the two framing schemes are incompatible. Once you've gotten your features running with PPP framing, it should be simple to add SLIP: just branch around the FCS parts, and hot-wire the finite state machine "open". It took me a half-morning to add SLIP to our PPP daemon, and maybe a cumulative hour of further debugging later because I forgot to deal with some shutdown conditions. Dunno about going the other direction; maybe someone who did the KA9Q work can discuss their experiences. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 12 06:31:20 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02306; Fri, 12 Jun 92 06:29:41 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07865; Fri, 12 Jun 92 06:10:02 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01748; Fri, 12 Jun 92 06:00:45 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01641; Fri, 12 Jun 92 05:58:49 -0700 Received: by europa.clearpoint.com (4.1/1.34) id AA05450; Fri, 12 Jun 92 08:48:59 EDT Date: Fri, 12 Jun 92 08:48:59 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9206121248.AA05450@europa.clearpoint.com> To: bsimpson@angband.stanford.edu, eer@cinops.xerox.com (Edwards Reed) Subject: Re: bizzare diatribe from Joachim Martillo In-Reply-To: Mail from '"William Allen Simpson" ' dated: Thu, 11 Jun 92 12:39:10 EDT Cc: ietf-ppp@ucdavis.ucdavis.edu bill for various reasons i have been staying on the sidelines of the latest flap caused by one of our employees. however, your note has prompted me to action. joachim is not representative of the entire company -- some of us have been active and (i believe) constructive in the ietf community for some time now. furthermore, this mailing list is for techincal discussions. while joachim's comments might be considered inappropriate to the purpose of the list, this is a place where technical people have discussions, sometimes disagreements, and occasionally arguments. if, every time we post some message to this list, we have to ask our selves "what impact does this have on potential customer relations" then the techical quality of the discussion will suffer greatly. finally, i hope that one employee's inflamatory style, regardless of the appropriateness of the forum in which that style appeared, is not taken as an indictment of an entire company of people who are dedicated to producing good products and good technology, to helping our customers solve their problems and to helping the internet move forward and to grow. i apologize if this note seems like advertising. normally i would not presume to send such a note, but the discussion has escalated from person-bashing to company-bashing. frank kastenholz clearpoint research corporation. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 12 07:13:33 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03322; Fri, 12 Jun 92 07:09:18 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08108; Fri, 12 Jun 92 06:59:52 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02964; Fri, 12 Jun 92 06:52:47 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from animal.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02650; Fri, 12 Jun 92 06:40:04 -0700 Received: by animal.clearpoint.com (4.1/1.34) id AA07493; Fri, 12 Jun 92 09:35:49 EDT Date: Fri, 12 Jun 92 09:35:49 EDT From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9206121335.AA07493@animal.clearpoint.com> To: bob@morningstar.com, martillo@azea.clearpoint.com Subject: Re: PPP vs. SLIP Cc: ietf-ppp@ucdavis.ucdavis.edu, roger@svcdudes.com, svctech!roger@trigger.morningstar.com FWIW: Clearpoint does not _yet_ support PPP in the first release of the router. There _is_, however, work underway to add this functionality. I am not aware of what results Joachim has found to back up his statements. -- Frank Solensky / Clearpoint From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 12 07:32:54 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03774; Fri, 12 Jun 92 07:28:02 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08158; Fri, 12 Jun 92 07:09:47 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03242; Fri, 12 Jun 92 07:03:04 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from research.att.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03031; Fri, 12 Jun 92 06:56:26 -0700 Message-Id: <9206121356.AA03031@ucdavis.ucdavis.edu> Received: by inet; Fri Jun 12 09:55 EDT 1992 From: smb@ulysses.att.com To: kasten@europa.clearpoint.com (Frank Kastenholz) Cc: bsimpson@angband.stanford.edu, eer@cinops.xerox.com (Edwards Reed), ietf-ppp@ucdavis.ucdavis.edu Subject: Re: bizzare diatribe from Joachim Martillo Date: Fri, 12 Jun 92 09:55:14 EDT Let me underscore what Frank has said. If people start treating mailing list items as the official position of the author's company, then the companies are going to start reacting the same way. That's going to mean things like approvals, clearance reviews, lawyers, and all the rest. If Martillo wants to behave like an obnoxious broken record -- fine, let him. It has nothing to do with Clearpoint's merits as a company. --Steve Bellovin From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 12 08:52:40 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05789; Fri, 12 Jun 92 08:48:17 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08805; Fri, 12 Jun 92 08:29:50 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05151; Fri, 12 Jun 92 08:20:54 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nsco.network.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04908; Fri, 12 Jun 92 08:12:02 -0700 Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA05768; Fri, 12 Jun 92 10:12:53 -0500 Received: from zebo.network.com by anubis.network.com (4.0/SMI-4.0) id AA14971; Fri, 12 Jun 92 10:10:24 CDT Date: Fri, 12 Jun 92 10:10:24 CDT From: muchow@anubis.network.com (Jim Muchow) Message-Id: <9206121510.AA14971@anubis.network.com> Received: by zebo.network.com (4.1/SMI-4.1) id AA04665; Fri, 12 Jun 92 10:10:22 CDT To: smb@ulysses.att.com Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: smb@ulysses.att.com's message of Fri, 12 Jun 92 09:55:14 EDT <9206121356.AA03031@ucdavis.ucdavis.edu> Subject: bizzare diatribe from Joachim Martillo From: smb@ulysses.att.com Date: Fri, 12 Jun 92 09:55:14 EDT If Martillo wants to behave like an obnoxious broken record -- fine, let him. It has nothing to do with Clearpoint's merits as a company. If Mr. Martillo did not invoke his company's name as often as he does when expressing his supposedly personal opnions, Clearpoint would not find itself dragged through the mud of Mr. Martillo's own making. I for one have always had the impression from Mr. Martillo's messages that he did in fact speak for Clearpoint. If this is not the case, that is Clearpoint's problem, not mine. Jim Muchow From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 12 10:22:20 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08148; Fri, 12 Jun 92 10:14:50 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08382; Fri, 12 Jun 92 07:49:47 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04161; Fri, 12 Jun 92 07:40:30 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from CAYMAN.CAYMAN.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04110; Fri, 12 Jun 92 07:36:06 -0700 Received: from haiti.Cayman.COM (moon-patrol.cayman.com) by cayman.Cayman.COM (4.1/SMI-4.0) id AA12317; Fri, 12 Jun 92 10:35:04 EDT Received: from localhost by haiti.Cayman.COM (4.1/SMI-4.1) id AA10978; Fri, 12 Jun 92 10:38:51 EDT Message-Id: <9206121438.AA10978@haiti.Cayman.COM> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: PPP Interoperability Meeting In-Reply-To: Mail from mlewis@napa.Telebit.COM (Mark S. Lewis) dated Thu, 11 Jun 92 16:51:35 PDT <9206112351.AA11794@napa.TELEBIT.COM> Date: Fri, 12 Jun 92 10:38:50 -0400 From: brad@Cayman.COM >> >> During the week of June 1-5, ten (10) of the leading networking >> vendors attended an event called the "PPP-Athon". It was hosted by >> Telebit in Sunnyvale. The pupose of the event was to determine the And it must be said that Mark Lewis did a *splendid* job or organizing and coordinating the event. While I was only there for a short time it was an *excellent* use of my time (and I hope everyone elses) and appeared to accomplished a lot for everyone involved. Thanks Mark! Let's do it again! -brad From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 12 11:21:03 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09804; Fri, 12 Jun 92 11:13:29 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10301; Fri, 12 Jun 92 10:49:51 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08845; Fri, 12 Jun 92 10:41:37 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from hobbit.gandalf.ca by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08693; Fri, 12 Jun 92 10:35:02 -0700 Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA00792; Fri, 12 Jun 92 13:34:11 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA27158; Fri, 12 Jun 92 13:34:07 EDT Date: Fri, 12 Jun 92 13:34:07 EDT From: mm@gandalf.ca (Mississippi Mud) Message-Id: <9206121734.AA27158@cannibal.gandalf.ca> To: brad@Cayman.COM, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: PPP Interoperability Meeting >And it must be said that Mark Lewis did a *splendid* job or organizing >and coordinating the event. While I was only there for a short time >it was an *excellent* use of my time (and I hope everyone elses) and >appeared to accomplished a lot for everyone involved. I was one of a couple of observers who also attended, and I want to echo that. I admit amazement at the amount and quality of the work done there. If there is another one, there will likely be one or more Gandalf ppp products there, partly due to what went down at the first one. Yes, thanks, Mark! -Chris Sullivan mm@gandalf.ca From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 12 11:42:58 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10498; Fri, 12 Jun 92 11:34:36 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10356; Fri, 12 Jun 92 10:54:48 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08862; Fri, 12 Jun 92 10:42:31 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from GINGER.LCS.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08788; Fri, 12 Jun 92 10:38:50 -0700 Received: by ginger.lcs.mit.edu id AA13386; Fri, 12 Jun 92 13:37:42 -0400 Date: Fri, 12 Jun 92 13:37:42 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206121737.AA13386@ginger.lcs.mit.edu> To: eer@cinops.xerox.com, kasten@europa.clearpoint.com Subject: Re: bizzare diatribe from Joachim Martillo Cc: ietf-ppp@ucdavis.ucdavis.edu, jnc@ginger.lcs.mit.edu I would second absolutely what Frank said. People have to be able to express themselves freely as concientous engineers, without penalty to their employers. This fits, parenthetically, with my fervent hope (I'm not so naivce as to think it corresponds to reality :-) that everyone doffs their company hat when the come through the IETF door, and sets their minds to simply producing the best technical design we can. So, I think anyone has the right to make an fool of himself in an IETF forum, without it reflecting on his employer. People are here as individuals, not company representatives. I was willing to take the case to my fellow IESG members to restrict the rights of Joachim to send material to the list (as we do occasionally limit rights to speak in other WG's, although it is usually not targeted at an individual), but that was *solely* in the interests of group productivity, not because anything particular about the content of what he was saying. Getting good specs out quickly (I know, I know, IETF bureacracy increases by the day :-) is our reason for being. Noel From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 12 14:02:50 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14657; Fri, 12 Jun 92 13:53:51 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11669; Fri, 12 Jun 92 12:30:18 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11915; Fri, 12 Jun 92 12:23:12 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from anu.anu.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11764; Fri, 12 Jun 92 12:17:39 -0700 Received: from cscgpo.anu.edu.au by anu.anu.edu.au (4.1/SMI-4.1) id AA04437; Sat, 13 Jun 92 05:16:16 EST Received: from huxley.anu.edu.au by cscgpo.anu.edu.au (4.1/SMI-4.1) id AA21761; Sat, 13 Jun 92 05:16:12 EST Date: Sat, 13 Jun 92 05:16:12 EST From: cmf851@cscgpo.anu.edu.au (Albert Langer) Message-Id: <9206121916.AA21761@cscgpo.anu.edu.au> To: kasten@europa.clearpoint.com Subject: Re: the mib Cc: ietf-ppp@ucdavis.ucdavis.edu Ok, I've just been lurking quietly and trying to catch up on the mailing list archives before speaking up, but I guess it's "Speak now or forever hold your peace" time on the MIB. 1. In addition to the split already listed I'd like to see the sync and async "serial port MAC" sublayer used by PPP split off into a separate MIB (i.e. the ISO 3309 framing and transparency and CRC calculations) - and also into a separate (non-PPP) base RFC. This also requires clarifying the charMIB and related structures to show how a given U(S)ART port can be sequentially used as EITHER a sync or async serial port, and EITHER as a character oriented login "PAD" for telnet etc OR with the MAC sublayer to support PPP or LAP B etc and whatever higher layer protocols they carry (which may end up returning to an error corrected login port). 2. Main point is that other protocols will use the same "serial port MAC" sublayer - especially LAP B and perhaps also LLC and/or LAP D. I would like to see it end up being a requirement for terminal servers on Internet hosts to support this MAC sublayer, along with related management functions, local relay protocol and switched network control. For bit oriented "synchronous" serial ports the functions of framing, transparency and CRC calculation are normally built into the USRT anyway. For octet oriented start-stop or "async" UARTs the ONLY efficient implementation is to do ALL character processing for framing, transparency and CRC calculation together in the serial port driver when the CPU accesses each incoming or outgoing character, so that higher sub-layers need only process packets and their headers rather than repeating the individual character processing required for transparency and CRC. Therefore the MAC layer should be located where the serial ports are in the terminal servers, even if higher sublayers are implemented elsewhere (e.g. PPP on a nearby router or LAP B for dialup access on a host). 3. Although my concerns relate mainly to "dialup" access (and "dialout") and I have little interest in multi-protocol routers and bridges, it seems to me important that telephone lines at Internet sites should be available for multiple functions rather than dedicated to particular applications. Obviously when PPP is used on a T1 link this is irrelevant, but at least the async framing version of PPP is also intended for use on ordinary serial ports with low speed modems on the General Switched Telephone Network. The more phone lines and modems can be shared using the same terminal servers, the less total phone lines are required to meet a given grade of service for all the different applications. Even a T1 PPP link could be backed up by using ordinary dialup login ports to connect site routers to one or more neigbouring sites, at a considerable saving compared with using extra phone lines and modems at a site and it's neighbours, exclusively dedicated to the backup function. 4. A standard "serial port MAC" for terminal servers (and other serial ports) should conform to the ISO 3309 standards, especially since PPP is already based on them and they are mandatory for GOSIP WAN conformance. The sync version is already mandatory and the async version is expected to be included as an option for X.25(1992). Since the async version can be used with ordinary PC COM ports and modems it can be expected to "take off" and be used far more widely than the sync version, once it is an official international standard. (Certainly a much cheaper way to comply with GOSIP WAN requirements than adding a sync port and modem :-) Unfortunately there are several problems with PPP's version: a) PPP specifies that "DEL" is not a control character included in the control character transparency mode, whereas ISO 3309 specifies that it is (with either parity bit). This seems to be a simple mistake (pointed out by Markus Kuhn), or perhaps arising from some earlier version of ISO 3309. Can it be simply corrected? b) Recent amendments to ISO 3309 provide for a 7 bit transparency mode which converts 8 septet characters (ignoring parity bits) to 7 octets and vice versa. This may be of little interest to PPP but it may be handy for dialup users or login ports with only 7 bit paths. It requires very little effort to implement (by simply recognizing the use of that mode at the start of a call). Can this be added to the MAC spec? c) ISO 3309 assumes only the "basic" transparency mode in which only the control-escape and flag characters (with either parity bit) are escaped. Anything else is by prior agreement. PPP assumes the "control character" transparency mode in which all control characters (with either parity bit) are escaped (should also include DEL). Then PPP uses it's own Link Control Protocol to undo the considerable inefficiency that results from such extensive doubling of characters by specifying a map of precisely which characters are to be escaped. This would cause problems for a MAC trying to handle both PPP and LAP B calls with the async framing and transparency. A "minimal" LAP B implementation should not need to include the XID negotiation procedures which allow specification of the transparency mode, but even dialup users with the smallest palmtop PCs would usually have to implement XID if the default transparency extra character was applied to all 66 control characters (and DEL) with either parity bit, rather than just the 4 extra required for "flow control transparency". Would it be possible to make "flow control transparency" the default for PPP and so also for a MAC sublayer common to PPP and LAP B? This would escape only the "basic" mode plus XON/XOFF or ctrl-S/ctrl-Q (with either parity bit), in order to avoid any problems with flow control on modems etc. Any other control characters that need to be escaped by the sender CAN be, without any need for negotiation with the receiver, whether using LCP or XID - only characters which the RECIEVER requires that the sender escape need to be established by prior agreement. (Thus the modem control character substituted for "+++" can be escaped by the sender without prior agreement, as long as it is a control character or DEL with either parity bit. Ditto for any similar PAD escape character etc.) Can anyone provide examples of situations where the RECEIVER needs control characters other than XON/XOFF to be escaped and this needs to be a universal default rather than private bilateral agreement with the sender? Perhaps the whole PPP "character map" was also just a mistake arising from a misreading of ISO 3309 or an early version that did not specify the option of "flow character transparency" as well as the full "control character transparency"? 5. A terminal server requirement for "serial port MAC" also needs to specify a well defined relay protocol for passing MAC sublayer frames between the terminal server and whatever is implementing the higher sublayers, so that the terminal server can just be configured with appropriate addresses etc. Within a LAN this does not seem very difficult - just a form of MAC bridging or LLC1 UI SAP that identifies which serial port the packets are to or from, however there are several problems and I would appreciate comments from anyone who can suggest solutions or point out additional problems: a) A reliable "up/down" protocol is required for incoming calls to ensure the higher sublayer is aware when the phone line hangs up and that the phone line does hang up when told to by the higher sublayer. This is at least a three way handshake with timeouts. (Even the standard SABM/DISC/UA "up/down" protocol of HDLC has problems, although they are not usually noticed with reasonable choices of timeouts.) b) Although simple relaying of serial port MAC frames in UI frames or LAN MAC frames may be acceptable (with the framing and transparency and CRCs being done by LAN hardware rather than CPU and software), this does not extend easily beyond a LAN to a (local) Internet. Just using UDP for example might work for PPP but could cause problems for LAP B etc since packets might arrive out of order as a result of multiple routes. LAP B would only recognize duplicate sequence numbers within a small window of 7 (or even 128), which is adequate for a serial line where packets only get lost, but not for even a local multiply connected Internet where they can be subject to arbitrary delays. Can this be adequately dealt with by specifying a maximum of 1 or 2 hops with IP? If not, then I presume the answer is TCP, which should be available on terminal servers anyway to perform their login/telnet functions. This could also handle problem a) by using the TCP CONNECT and DISCONNECT to control the phone line and vice versa. Are there any problems using TCP? How precisely should it be specified? c) There is also a requirement to call out, which means that some function has to control the modem. If there is already a standard protocol for this, please point me to it. I could only find the char and rs232 and PPP MIBs but no "modemMIB" or related "modemControl" protocol. This seems an essential function for at least one end of most PPP implementations and for some other "dialup" or at least "dialout" capabilities. Some modems are controlled by +++ with facilities to specify the guard period and alternative characters instead of "+". This may involve coordination with the MAC transparency facility to escape the chosen control character. Others may use DTR or "break" to put the modem in command mode. There are also other requirements to access CD, RTS, RING etc and to detect or cause framing or parity errors etc. It seems to me that the simplest requirement for terminal servers would just be to support a "generic" U(S)ART control protocol that reports the current status of the V.24 interchange circuits (RTS, DTR etc) and/or updates that status (including line conditions like "break" and "idle"). A higher layer can use this for "modem control" and therefore also "switched network control" depending on the specific modem attached to a particular port and how it is configured. The rs232MIB seems to provide much of what is needed, but surely "management" refers more to setting up dedicated circuits rather than handling large numbers of individual calls at each dialup/dialout port? Something integrated with the data relaying and MAC control and hangup "up/down" protocols seems desirable. Also, although the modem state is controlled by the rs232 port, it should be tracked separately. A "cableMIB" might also be handy. Incidentally, cheap modem chipsets now also include fax, DTMF and voice facilities which can also use the same pool of phone lines instead of having separate lines for fax etc, and which also need to be controlled by terminal servers and managed through the MIB. This suggests the need for a "call assigner" within the terminal server, which can recognize the presence of sync or async framing (or it's absence on an ordinary login call to a telnet PAD etc) and can also recognize other "protocols" used on incoming dialup calls or by the modem (e.g. "class 1" and "class 2" fax interface with the modem, FidoNet dialup calls, ordinary and UUCP login etc). Once the MAC layer is engaged and 7 or 8 bit mode selected, separation of PPP from LAP B etc can be left to a higher layer, and need not necessarily be implemented on the terminal server. But if the "call assigner" has to be present in the terminal server anyway, it may be appropriate for it to also perform some header analysis of the packets delivered from MAC to assign the call to either PPP (perhaps at a router IP address) or LAP B (perhaps at a different End System address). This would avoid having to route packets through the LAN or local Internet twice - e.g. once from the terminal server to a router, and then forwarding to a host when it turns out to be a LAP B call or vice versa. Well, I guess that's enough for now. Suggestions welcome. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 12 14:48:00 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16160; Fri, 12 Jun 92 14:38:18 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA12885; Fri, 12 Jun 92 14:09:49 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14965; Fri, 12 Jun 92 14:00:56 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14660; Fri, 12 Jun 92 13:53:55 -0700 Received: from harry. (harry.lloyd.COM) by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA00432; Fri, 12 Jun 92 13:52:58 PDT Date: Fri, 12 Jun 92 13:52:58 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9206122052.AA00432@ray.lloyd.com> Received: by harry. (4.1/SMI-4.1) id AA00278; Fri, 12 Jun 92 13:52:44 PDT To: kasten@europa.clearpoint.com Cc: bsimpson@angband.stanford.edu, eer@cinops.xerox.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Frank Kastenholz's message of Fri, 12 Jun 92 08:48:59 EDT <9206121248.AA05450@europa.clearpoint.com> Subject: bizzare diatribe from Joachim Martillo Your words are quite reasonable Frank. I think that Bill was a bit out of line in slamming Clearpoint on the basis of another of Mr. Martillo's tirades. On the other hand is there anyone at Clearpoint that can put Mr. Martillo on a shorter leash? I am *sorely* tempted to remove his name from the mailing list. Which reminds me of my tonsils. When I was growing up I constantly had trouble with my tonsils and the doctor would always say something like, "if they give you any more trouble we will remove them." Then I wouldn't have trouble with them for quite a while. I put up with this until I was 22 when a single sore throat caused me to decide to have them removed. I haven't had any trouble since. Given this experience I believe that it is just best to deal with a known latent problem than to wait for it to crop up again. However, in the case of Mr. Martillo I will refrain one more time. Rest assured that if I see another "Blast from the Clear[point]" Mr. Martillo will be off this mailing list as fast as I can get to a terminal. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 12 15:29:06 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17253; Fri, 12 Jun 92 15:13:21 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13328; Fri, 12 Jun 92 14:54:39 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15662; Fri, 12 Jun 92 14:23:56 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from mts-gw.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15446; Fri, 12 Jun 92 14:15:50 -0700 Received: by mts-gw.pa.dec.com; id AA12285; Fri, 12 Jun 92 14:14:52 -0700 Message-Id: <9206122114.AA12285@mts-gw.pa.dec.com> Received: from eider.enet; by decpa.enet; Fri, 12 Jun 92 14:14:53 PDT Date: Fri, 12 Jun 92 14:14:53 PDT From: Jesse Walker To: ietf-ppp@ucdavis.ucdavis.edu Apparently-To: ietf-ppp@ucdavis.edu Subject: IPCP IP Address Option Query Someone kindly help me understand the following. I'm trying to understand what kind of policies should apply to a particularly degenerate case of IPCP negotiation. Suppose box A includes the IP Address Option in an IPCP Configure-Request it sends to box B over some link. Box A specifies its own IP address as address 0, to request that B assign A an IP address for A's interface on the link. Unfortunately, B is not configured to do so. I expect B to Reject the option in this case, to say "there is absolutely no way I can accomodate your request". But what if it doesn't? What if B returns a Nak with address 0? Should A interpret this as an invalid response (I believe it should, as the response does not return a valid IP address, as required by the Description clause of Paragraph 3.3 of RFC 1332)? Or is there some other meaning that can be ascribed to such a response? Or what if B returns with some other address, such as some kind of a broadcast address? Again, this seems like an invalid response, because the value the response suggests is not a valid IP address for A to use as its own. On the other hand, B may believe it needs to know A's address. If B issues a Reject, I expect A to omit the option in further Configure-Requests. But RFC 1332 permits B to return a Configure-Nak conveying the option to such a request from A. The RFC says that the option may in this case indicate that the peer must provide an address for itself; by this is it meant that the Nak specify address 0? This would seem to lead us back to the previous scenario? Maybe there is no problem, because the two parties will go round and round several times and eventually terminate IP over the link, because they cannot come to any agreement about the configuration; they are simply incompatible "types" with regard to this option. This is understandable, as there is simply not enough information configured at A and B to do any better. Is this the expected result? Since there are a number of implementations now, an equal or greater number of people have probably worked through these scenarios in detail. Can anyone offer some insights from their experience? I'd be very grateful. -- Jesse Walker From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 12 16:02:28 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18221; Fri, 12 Jun 92 15:50:09 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13803; Fri, 12 Jun 92 15:30:13 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17596; Fri, 12 Jun 92 15:27:55 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17396; Fri, 12 Jun 92 15:16:38 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA13804; Fri, 12 Jun 92 15:15:16 PDT Date: Fri, 12 Jun 92 15:15:16 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9206122215.AA13804@saffron.acc.com> To: brian@lloyd.com Subject: Re: bizzare diatribe from Joachim Martillo Cc: ietf-ppp@ucdavis.ucdavis.edu >> Rest assured that if I see another "Blast from the Clear[point]" >> Mr. Martillo will be off this mailing list as fast as I can get to a >> terminal. So what? That only stops mail sent to the list from getting to him; it doesn't stop him from originating mail to this list or any other. I think that the only effective fall-back (given that his employer is unable to corral him) is for people to simply ignore him. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 12 17:31:41 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20929; Fri, 12 Jun 92 17:25:48 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14515; Fri, 12 Jun 92 17:09:47 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20203; Fri, 12 Jun 92 17:00:23 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20065; Fri, 12 Jun 92 16:57:51 -0700 Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA02443; Fri, 12 Jun 92 16:56:53 -0700 Date: Fri, 12 Jun 92 18:17:29 EDT From: "William Allen Simpson" Message-Id: <419.bsimpson@angband.stanford.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: bizzare diatribe from Joachim Martillo It's time to eat my words and publicly apologize to the Franks, who happen to also be from Clearpoint. These guys are *GREAT*, a joy to work with, and are part of the solution, not the problem. I just didn't think of them as from anywhere in particular. I only think of them as good engineers who have done a lot on the IETF lists for issues that I care about (especially Kastenholz). They could change jobs, companies, etc, and I'd probably never notice. But I definitely would regret it if they stopped being around. My difficulty is, whenever I see the name Clearpoint, I think "That's the gawd-awful company that Joachim rananabanana designs for ...." and look elsewhere. Pretty irrational in the case of memory (I've never even seen a flyer for "Slithernet"). He really hurts your product image in my mind. >From now on, I promise to think, "Maybe *Frank* worked on this". Especially when it has PPP in it (I know Joachim won't have anything to do with that :-). Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 12 19:40:03 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25027; Fri, 12 Jun 92 19:34:10 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA15088; Fri, 12 Jun 92 19:19:43 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24296; Fri, 12 Jun 92 19:10:39 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from GINGER.LCS.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24072; Fri, 12 Jun 92 19:03:00 -0700 Received: by ginger.lcs.mit.edu id AA15139; Fri, 12 Jun 92 22:02:00 -0400 Date: Fri, 12 Jun 92 22:02:00 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206130202.AA15139@ginger.lcs.mit.edu> To: brian@lloyd.com, kasten@europa.clearpoint.com Subject: Re: bizzare diatribe from Joachim Martillo Cc: bsimpson@angband.stanford.edu, eer@cinops.xerox.com, ietf-ppp@ucdavis.ucdavis.edu, jnc@ginger.lcs.mit.edu Brian, that might be a big hasty. I note that some irrestable force, whether internal or not I don't know, has caused Joachim to not respond to a number of messages, including my two door-slammers, so the situation does seem to have improved a bit. Joachim, wherever you are, may I suggest that you give up on us a bunch of irreconcilable idiots who can't see the light of day with respect to routing in the data link layer, and omit that point from future messages? As many of us have pointed out, there are some good points in your notes, and not having to read through the usual sermon on this point would make your messages much more welcome. Noel From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 12 23:40:34 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01809; Fri, 12 Jun 92 23:34:14 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA15710; Fri, 12 Jun 92 23:09:45 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00988; Fri, 12 Jun 92 23:00:17 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00790; Fri, 12 Jun 92 22:52:35 -0700 Received: from harry. (harry.lloyd.COM) by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA00647; Fri, 12 Jun 92 22:51:46 PDT Date: Fri, 12 Jun 92 22:51:46 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9206130551.AA00647@ray.lloyd.com> Received: by harry. (4.1/SMI-4.1) id AA00395; Fri, 12 Jun 92 22:51:33 PDT To: ietf-ppp@ucdavis.ucdavis.edu Subject: Interop demo I have proposed a formal PPP demo to Interop for the fall show. Could you please let me know which of you would be interested in participating. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Sat Jun 13 16:30:12 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21671; Sat, 13 Jun 92 16:23:44 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17936; Sat, 13 Jun 92 16:09:45 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21243; Sat, 13 Jun 92 16:00:33 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from relay2.UU.NET by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21125; Sat, 13 Jun 92 15:56:06 -0700 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA29148; Sat, 13 Jun 92 18:55:25 -0400 Received: from uncng.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 185424.21071; Sat, 13 Jun 1992 18:54:24 EDT Received: by uncng.com (4.1/SMI-4.1) id AA00591; Sat, 13 Jun 92 15:21:51 PDT Date: Sat, 13 Jun 92 15:21:51 PDT From: uncng!michele@uunet.UU.NET Message-Id: <9206132221.AA00591@uncng.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: ppp mailing list I like to remain on the ppp mailing list, but I need to change where my mail is sent. Please change my email from uncng!michele@uunet.uu.net to uncng!wright@uunet.uu.net Thank you, Michele Wright ascom Timeplex P.S. Also we would be interested in participating in a PPP demo at Interop in the Fall. From ietf-ppp-request@ucdavis.ucdavis.edu Sun Jun 14 22:10:19 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01873; Sun, 14 Jun 92 22:09:16 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA22034; Sun, 14 Jun 92 21:49:43 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01388; Sun, 14 Jun 92 21:40:11 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from azea.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01233; Sun, 14 Jun 92 21:30:33 -0700 Received: by azea.clearpoint.com (4.1/1.34) id AA01639; Mon, 15 Jun 92 00:20:14 EDT Date: Mon, 15 Jun 92 00:20:14 EDT From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) Message-Id: <9206150420.AA01639@azea.clearpoint.com> To: jnc@ginger.lcs.mit.edu Cc: brian@lloyd.com, kasten@europa.clearpoint.com, bsimpson@angband.stanford.edu, eer@cinops.xerox.com, ietf-ppp@ucdavis.ucdavis.edu, jnc@ginger.lcs.mit.edu, martillo@azea.clearpoint.com In-Reply-To: Noel Chiappa's message of Fri, 12 Jun 92 22:02:00 -0400 <9206130202.AA15139@ginger.lcs.mit.edu> Subject: bizzare diatribe from Joachim Martillo Hey guys, I just have to much work to continue this debate. I will see you in Boston. But if you want the list of my concerns which I would like to see addressed: 1) 1 PPP link within a network is okay but more than 2 within a network can lead to topological problems remote from the WAN links. (This result just comes from graph theory.) 2) Suppose the remote is sending IPX in MAC frames but the local wants the IPX packets to come in the network layer packet representation. How does the local tell the remote to send IPX packets using the packet encapsulation without rejecting all MAC frames (this is a situation which could occur during a router upgrade on the local side when the supplanted router did not support IPX routing, but the new one did). 3) If it makes sense to run multiple network layers of different protocol stacks, doesn't it also make sense to run multiple instantiations of each network layer of the different protocol stacks? Then it might be possible to run a secure encrypted IP in parallel with an insecure unencrypted IP. With certain sorts of multiport routers this might make sense if only one wide-area link is available. 4) Suppose we accept as I think Noel claims that the network layer should have intimate knowledge of the establishment and disestablishment of physical links (demand CSCs). Does this mean that there should be some level of synchronization of the network layers or NCPs so that if IP is shutdown, the physical link is not torn down while other network layers are still established? Joachim Carlo Santos Martillo Ajami From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 15 09:33:08 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15851; Mon, 15 Jun 92 09:24:05 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA24982; Mon, 15 Jun 92 08:49:49 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14919; Mon, 15 Jun 92 08:45:34 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14676; Mon, 15 Jun 92 08:37:55 -0700 Received: from napa.TELEBIT.COM by apache (4.1/SMI-4.1/Telebit-Apache-Brent-910926) id AA10273 to ietf-ppp@ucdavis.edu; Mon, 15 Jun 92 08:36:31 PDT Received: from yoyo.telebit.com by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910507) id AA02964 to ietf-ppp@ucdavis.edu; Mon, 15 Jun 92 08:36:29 PDT Date: Mon, 15 Jun 92 08:36:29 PDT From: mlewis@napa.Telebit.COM (Mark S. Lewis) Message-Id: <9206151536.AA02964@napa.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA09557; Mon, 15 Jun 92 08:37:24 PDT To: brian@lloyd.com Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <9206130551.AA00647@ray.lloyd.com> "brian@lloyd.com" Subject: Interop demo > I have proposed a formal PPP demo to Interop for the fall show. Could > you please let me know which of you would be interested in > participating. > Brian Lloyd, WB6RQN Lloyd & Associates > Principal and Network Architect 3420 Sudbury Road > brian@lloyd.com Cameron Park, CA 95682 > voice (916) 676-1147 -or- (415) 725-1392 Telebit would definitely like to participate. ... Mark =========----------- Mark S. Lewis -----------========== inet: mlewis@telebit.com Telebit Corp. Telebit (408) 745-3232 uucp: uunet!telebit!mlewis Fax (408) 745-3810 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 15 13:13:24 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21488; Mon, 15 Jun 92 13:04:21 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27887; Mon, 15 Jun 92 12:40:02 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20634; Mon, 15 Jun 92 12:31:59 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from merit.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20394; Mon, 15 Jun 92 12:20:04 -0700 Return-Path: Received: from asterix.merit.edu by merit.edu (5.65/1123-1.0) id AA25918; Mon, 15 Jun 92 15:19:10 -0400 Received: by asterix.merit.edu (4.1/dumb-0.9) id AA20416; Mon, 15 Jun 92 15:19:08 EDT Message-Id: <9206151919.AA20416@asterix.merit.edu> From: Glenn.McGregor@merit.edu To: ietf-ppp@ucdavis.ucdavis.edu Subject: IPCP IP address negotiation Date: Mon, 15 Jun 92 15:19:06 -0400 There has been some confusion about the IP address negotiation in IPCP and after some head scratching (and implementation) here are my thoughts/clarifications/expansions on the new option. Address values in examples: 0.0.0.0 - a request for the peer to provide an address. This could also be interpretted as the address is unknown/unavailable/non-existant. w.x.y.z - an arbitrary non-zero IP address. a.b.c.d - a different arbitrary non-zero IP address case 1 - sending a config-req with IP-address = 0.0.0.0 This means that the requestor does not know the IP address of his end of the link. One way to think about this is that he is asserting that the IP address is unknown. possible responses: config-ack with IP-address = 0.0.0.0 This means that the peer also doesn't know the IP address. One way to think about this is that the peer agreees that the IP address is unknown. config-ack with IP-address = w.x.y.z Illegal. An ACK should not change the value. config-nak with IP-address = 0.0.0.0 Illegal. A NAK should change the value. config-nak with IP-address = w.x.y.z This would be the normal way for the peer to return an IP address. Think- the peer disagrees, the IP address is known. config-rej with IP-address = 0.0.0.0 This would indicate that the peer doesn't understand this option. Maybe it should try the IP-addresses option. config-rej with IP-address = w.x.y.z Illegal. A REJ should not change the value. case 2 - sending a config-req with IP-address = w.x.y.z This means that the requestor knows the IP address of his end of the link. (Or else that he hopes that it is?). possible responses: config-ack with IP-address = 0.0.0.0 or a.b.c.d Illegal. An Ack must not change the value. config-ack with IP-address = w.x.y.z The peer agress with this IP address assignment. config-nak with IP-address = 0.0.0.0 This is probably not useful. This could be a way to assert that there is no IP address on the link. I wouldn't try to use this in my implementation. config-nak with IP-address = w.x.y.z Illegal. A NAK must change the value. config-nak with IP-address = a.b.c.d This would be the way for the peer to disagree with the IP address assertion. It's not clear to me how the ends reconcile there differences. config-rej with IP-address = 0.0.0.0 or a.b.c.d Illegal. A REJ must not change the value. config-rej with IP-address = w.x.y.z This would indicate that the peer doesn't understand this option. Maybe it should try the IP-addresses option. I'm sorry that this isn't clearly spelled out in RFC1332. There always seems to something like this after things get published. Glenn McGregor Merit Network, Inc. ghm@merit.edu From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 15 13:54:44 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22782; Mon, 15 Jun 92 13:45:19 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA28766; Mon, 15 Jun 92 13:19:46 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21657; Mon, 15 Jun 92 13:12:29 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from babyoil.ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21515; Mon, 15 Jun 92 13:05:33 -0700 Received: from gordon.repeater.ftp.com by ftp.com via PCMAIL with DMSP id AA05090; Mon, 15 Jun 92 16:08:24 -0400 Date: Mon, 15 Jun 92 16:08:24 -0400 Message-Id: <9206152008.AA05090@ftp.com> To: walker@eider.ENET.dec.com Subject: Re: IPCP IP Address Option Query From: gordon@ftp.com (Gordon Lee) Cc: ietf-ppp@ucdavis.ucdavis.edu Repository: babyoil.ftp.com Originating-Client: repeater.ftp.com > From: Jesse Walker > Subject: IPCP IP Address Option Query It would be nice if the RFC clarified some of this, but here is my own interpretation of the usage of this option, gathered largely from working with other vendors who support the option (thanks guys). > Suppose box A includes the IP Address Option in an IPCP > Configure-Request it sends to box B over some link. Box A specifies its > own IP address as address 0, to request that B assign A an IP address > for A's interface on the link. yes, a behaviour suggested verbatim in RFC1332 > Unfortunately, B is not configured to do so. > I expect B to Reject the option in this case, to say "there is > absolutely no way I can accomodate your request". > But what if it doesn't? What if B returns a Nak with address 0? Given that the RFC does not specify the appropriate response, we wander into the grey area of "implementation-specific". My own feeling is that B really should NAK with address zero as a way of saying "I don't have an address for you". I think if B Rejects the address option it is saying strongly that it cannot use this option to negotiate addresses, which is a very different message. Indeed, my implementation and I believe others use the rejection of IPCP option 3 as a way for A to know that B cannot handle IPCP option 3 but should use option 1 instead, (backwards compatability fallback). Other vendors should comment here to confirm or deny my statement. > Should A interpret > this as an invalid response (I believe it should, as the response does > not return a valid IP address, as required by the Description clause of > Paragraph 3.3 of RFC 1332)? "The peer can provide this information by NAKing the option, and returning a valid IP-address." Well, there isn't a must in there, so I don't read any requirement there. But it should be clarified. > On the other hand, B may believe it needs to know A's address. If B > issues a Reject, I expect A to omit the option in further > Configure-Requests. yes, this is what lead me to use Rejection of option 3 to trigger use of option 1 as a substitute. > Maybe there is no problem, because the two parties will go round and > round several times and eventually terminate IP over the link, because > they cannot come to any agreement about the configuration; they are > simply incompatible "types" with regard to this option. This is > understandable, as there is simply not enough information configured at > A and B to do any better. Is this the expected result? Assuming a worst case scenario of divergent interpretations of the spec on the part of two implementors, I would agree that this is the expected result. With some clarification, I believe that convergence (be it "success" or "failure") could be achieved earlier in a more controlled deterministic fashion. > Since there are a number of implementations now, an equal or greater > number of people have probably worked through these scenarios in > detail. Can anyone offer some insights from their experience? I hope others have the time to share their thoughts also. 2 cents, - GL == Gordon Lee == voice: (617) 246-0900 == fax: (617) 245-7943 == FTP Software Inc. == 26 Princess St == Wakefield, MA 01880-3004 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 15 15:35:01 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26026; Mon, 15 Jun 92 15:21:44 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA00142; Mon, 15 Jun 92 15:00:14 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25143; Mon, 15 Jun 92 14:55:13 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24861; Mon, 15 Jun 92 14:47:46 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA22746; Mon, 15 Jun 92 14:46:21 PDT Date: Mon, 15 Jun 92 14:46:21 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9206152146.AA22746@saffron.acc.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: lapb Sentient Beings: The following document is for your edification and comment, and for discussion in the PPP Working Group meeting in Boston. ==================================================================== ^L Network Working Group F Baker Internet Draft Troublemaker June 1992 PPP LAPB Numbered Mode Status of this Memo This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list. Distribution of this memo is unlimited. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol. This document defines a protocol for negotiating and using LAPB, as defined by ISO 7776, to provide a reliable serial link. Baker [Page i] Internet Draft PPP LAPB Numbered Mode June 1992 1. Introduction PPP has three main components: 1. A method for encapsulating datagrams over serial links. 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 describes an option of the Link Control Protocol to negotiate the use of LAPB Numbered Mode. This facility is optional. Baker [Page 1] Internet Draft PPP LAPB Numbered Mode June 1992 2. Reliable Link Support 2.1. Design Motivation Generally, serial link reliability is not a major issue. The architecture of protocols used in datagram networking presume best effort non-sequential delivery. However, in certain circumstances, it is advisable to provide a reliable link, at least for a subset of the messages. The most obvious case is when the link is compressed. Since the dictionary is recovered from the compressed data stream, and a lost datagram corrupts the dictionary, datagrams may not be lost. Another case is where multiple parallel links are used to emulate a single link of higher speed. In this case, Bridged traffic, Source Routed traffic, and traffic subjected to Van Jacobsen compression must be delivered to the higher layer in a certain sequence. However, the fact of the links being relatively asynchronous makes traffic reordering certain. The ISO 7776 Multi-Link Protocol can be used to restore order. Baker [Page 2] Internet Draft PPP LAPB Numbered Mode June 1992 2.2. Configuration Option Format Description The LAPB Numbered Mode Configuration Option of the Link Control Protocol negotiates the use or abuse of LAPB on the link. By default or ultimate disagreement, Unnumbered Mode is used. The use of unnumbered (UI) messages remains optional during the LAPB session. A summary of the LAPB Numbered Mode Configuration Option format to negotiate datagram encryption is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Window | Address... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length at least 4 Window A value between 1 and 127. This indicates the number of frames the receiver will buffer for, and therefore the maximum number that the sender should send without receiving an acknowledgement. If window < 8, then modulo 8 sequencing is used on the link. Otherwise, modulo 128 sequencing is used. It is conceivable and legal that differing window values might be announced and used. However, LAPB does not permit one system to use modulo 8 sequencing and the other to use modulo 128. Therefore, the rule is: A NAK may reduce the window but may not increase it. Address An HDLC Address as specified in ISO 3309. ISO 7776 specifies four of the possible values: 1 and 3 for single link LAPB, 7 and 15 for the Multi-Link Procedure. Other values consistent with ISO 3309 Baker [Page 3] Internet Draft PPP LAPB Numbered Mode June 1992 are considered legal. Implementation of the MultiLink procedure is optional; A NAK may therefore force a change from MLP to single link mode, but not the reverse. If Multilink is configured, the peers should use the same Magic Number on all of the links interconnecting them. Should the address be zero upon receipt, the receiver MUST NAK with an appropriate address. If both peers send the address 00, then the system with the numerically smaller Magic Number will select the link addresses. Baker [Page 4] Internet Draft PPP LAPB Numbered Mode June 1992 2.3. Packet Format Standard PPP uses an ISO 3309 Address of 0xFF (Broadcast) and a control field of 0x03 (UI). While LAPB is operational, the use of these values remains legal. However, the Address Field of the frame may also take the value announced in the configuration option, and the control field may take any value valid in ISO 7776. The fields are transmitted from left to right. Therefore, the following packet formats are valid under LAPB mode: Standard UI Broadcast Messages: +----------+----------+----------+----------+------------ | Flag | Address | Control | Protocol | Information | 01111110 | 11111111 | 00000011 | 16 bits | * +----------+----------+----------+----------+------------ ---+----------+----------+----------------- | FCS | Flag | Inter-frame Fill | 16 bits | 01111110 | or next Address ---+----------+----------+----------------- LAPB +----------+----------+----------+----------+------------ | Flag | Address | Control | Protocol | Information | 01111110 |1-2 octets|1-2 octets| 16 bits | * +----------+----------+----------+----------+------------ ---+----------+----------+----------------- | FCS | Flag | Inter-frame Fill | 16 bits | 01111110 | or next Address ---+----------+----------+----------------- Multi-Link Procedure +----------+----------+----------+----------+ | Flag | Address | Control | MLC Field| | 01111110 |1-2 octets|1-2 octets| 16 bits | +----------+----------+----------+----------+ +----------+----------+-- | Protocol | Information | 16 bits | * +----------+----------+-- ---+----------+----------+----------------- | FCS | Flag | Inter-frame Fill | 16 bits | 01111110 | or next Address ---+----------+----------+----------------- Baker [Page 5] Internet Draft PPP LAPB Numbered Mode June 1992 2.4. SABM Exchange Correct startup of LAPB requires the use of a SABM or SABM(E), with a UA response. Following the successful negotiation of LAPB Numbered Mode, the system with the numerically smaller magic number will send a SABM, and the other will respond with a UA. In the event that either the SABM or UA is lost, this exchange may be repeated according to the same parameters as the configure exchange itself, both the timeout and the restart counter. Link Quality Determination and NCP Configuration follow this step. Baker [Page 6] Internet Draft PPP LAPB Numbered Mode June 1992 Security Considerations Security issues are not discussed in this memo. References [1] Simpson, W. A., RThe Point-to-Point ProtocolS, RFC in progress. [2] ISO 7776, Information Processing Systems - Data Communication - High Level Data Link Control Procedures - Description of the X.25 LAPB-Compatible DTE Data Link Procedures Acknowledgments Chair's Address The working group can be contacted via the current chair: Brian Lloyd Lloyd & Associates 3420 Sudbury Road Cameron Park, California 95682 Phone: (916) 676-1147 EMail: Brian@ray.lloyd.com Author's Address Questions about this memo can also be directed to: Fred Baker Advanced Computer Communications 315 Bollay Drive Santa Barbara, California 93117 EMail: fbaker@acc.com Baker [Page 7] Internet Draft PPP LAPB Numbered Mode June 1992 Table of Contents 1. Introduction .......................................... 1 2. Reliable Link Support ................................. 2 2.1 Design Motivation ............................... 2 2.2 Configuration Option Format ..................... 3 2.3 Packet Format ................................... 5 2.4 SABM Exchange ................................... 6 SECURITY CONSIDERATIONS ...................................... 7 REFERENCES ................................................... 7 ACKNOWLEDGEMENTS ............................................. 7 CHAIR'S ADDRESS .............................................. 7 AUTHOR'S ADDRESS ............................................. 7 Baker [Page ii] From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 15 15:45:17 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26555; Mon, 15 Jun 92 15:36:24 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA00201; Mon, 15 Jun 92 15:04:02 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25152; Mon, 15 Jun 92 14:55:28 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24862; Mon, 15 Jun 92 14:47:47 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA22755; Mon, 15 Jun 92 14:46:23 PDT Date: Mon, 15 Jun 92 14:46:23 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9206152146.AA22755@saffron.acc.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: compress Sentient Beings: The following document is for your edification and comment, and for discussion in the PPP Working Group meeting in Boston. ==================================================================== Network Working Group F Baker Internet Draft Troublemaker June 1992 PPP Datagram Compression Status of this Memo This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list. Distribution of this memo is unlimited. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol. This document defines a protocol for negotiating and using software data compression. Baker [Page i] Internet Draft PPP Datagram Compression June 1992 1. Introduction PPP has three main components: 1. A method for encapsulating datagrams over serial links. 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 describes a Control Protocol to facilitate the use of software data compression on the network layer (data, as opposed to control) protocols on a link. This facility is optional. Data compression technology takes many forms. Link bit stream compression is a common approach over very low speed asynchronous links, normally performed by modems transparently. Transparent bit stream compression is also offered in some DSUs and some routers and bridges a feature for improving the utilization of high bandwidth links; this constitutes an extra cost, often optional. Certain applications are amenable to protocol dependent message compression algorithms such as Van Jacobsen compression. In between these, at common synchronous link speeds, software compression may be used to improve link utilization without the extra cost of hardware support. Software compression, however, is not transparent, and so presents a special set of considerations. Its use must be consistent with the negotiation philosophy of PPP, especially the Link Control Protocol. It also must either calculate a new dictionary for each compressed message sent (and either send it to the receiver or assure that the receiver can derive it), or must use a reliable protocol such as LAPB to assure that all data arrives in the order sent. This document describes a way for two systems to negotiate the use of software message compression. The negotiation mechanism is independent in each direction. To assure that the LCP and NCPs are not compromised, it is used only on the network layer protocols; the LCP, NCPs, and other Control Protocols remain uncompressed. Baker [Page 1] Internet Draft PPP Datagram Compression June 1992 2. Link Compression 2.1. Design Motivation Data communications links come in various speeds, corresponding to differing bandwidth requirements and economic constraints. At speeds at and below 64 KBPS, delays imposed by bit rate, propagation delays, and queuing delays are quite noticeable to the user, and link congestion is a fact of life. Users are faced with the trade-off between uncomfortable delays and uncomfortable budgets. At the same time, the microprocessors in most modern communications systems, having sufficient capability to effectively use T-1 or E-1 links, are underutilized. They can execute complex compression and decompression algorithms in software (and therefore at no recurring hardware cost), and relieve some of these delays. 2.2. Algorithms There exist a number of good algorithms for data compression, some proprietary and some publicly documented. This document will provide a means to negotiate among many; however, it will only define the use of the algorithm described in CCITT Recommendation V.42bis. Identifiers for other (proprietary) algorithms are obtainable from the Internet Assigned Numbers Authority (iana@isi.edu). Baker [Page 2] Internet Draft PPP Datagram Compression June 1992 2.3. Configuration Option Format Description The Datagram Compression Configuration Option of the Link Control Protocol negotiates the type of datagram compression used on a data link. By default or ultimate disagreement, datagrams are uncompressed. A mental note: the significant difference between compression and encryption of data is lost on the author. Both are mechanisms of re-encoding data in a manner that only the receiver will understand... A summary of the Compression Configuration Option format to negotiate datagram encryption is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Compression-Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length 4 Compression-Algorithm c0?? (hex) for V.42bis Compressed-Datagram Baker [Page 3] Internet Draft PPP Datagram Compression June 1992 2.4. Packet Format Exactly one datagram is encapsulated in the Information field of PPP Data Link Layer frames where the protocol field indicates type hex c0?? (V.42bis Compressed Datagram). The compressed data, after decompression, has the format described by its NCP description RFC without the address or control fields. The fields are transmitted from left to right. The use of V.42bis compression requires the successful negotiation of the LAPB Numbered Mode option. Format of Information Field: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Identifier | Compressed Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Compressed Data... +-+-+-+-+-+-+-+-+-+-+-+- Protocol Identifier Value to be assigned Compressed-Data-Length The length of Compressed-Data, in octets. Any octets following are PPP pad as specified in RFC 1331 section 3.1, and should not be decompressed. Compressed-Data The Compressed-Data field contains the compressed version of frame encoded according to some other protocol. No explicit restrictions are placed on this except that it must be a network layer (as opposed to control) protocol. Baker [Page 4] Internet Draft PPP Datagram Compression June 1992 Security Considerations Security issues are not discussed in this memo. References [1] Simpson, W. A., RThe Point-to-Point ProtocolS, RFC in progress. [2] CCITT Recommendation V.42bis Error Correcting Procedures for DCEs using Error Correction Procedures Acknowledgments Significant input was given by Chris Sullivan and Dave Carr of Gandolf Ltd. Chair's Address The working group can be contacted via the current chair: Brian Lloyd Lloyd & Associates 3420 Sudbury Road Cameron Park, California 95682 Phone: (916) 676-1147 EMail: Brian@ray.lloyd.com Author's Address Questions about this memo can also be directed to: Fred Baker Advanced Computer Communications 315 Bollay Drive Santa Barbara, California 93117 EMail: fbaker@acc.com Baker [Page 5] Internet Draft PPP Datagram Compression June 1992 Table of Contents 1. Introduction .......................................... 1 2. Link Compression ...................................... 2 2.1 Design Motivation ............................... 2 2.2 Algorithms ...................................... 2 2.3 Configuration Option Format ..................... 3 2.4 Packet Format ................................... 4 SECURITY CONSIDERATIONS ...................................... 5 REFERENCES ................................................... 5 ACKNOWLEDGEMENTS ............................................. 5 CHAIR'S ADDRESS .............................................. 5 AUTHOR'S ADDRESS ............................................. 5 Baker [Page ii] From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 15 17:01:00 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29224; Mon, 15 Jun 92 16:57:27 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01398; Mon, 15 Jun 92 16:39:46 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28449; Mon, 15 Jun 92 16:32:01 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28117; Mon, 15 Jun 92 16:23:54 -0700 Received: from harry. (harry.lloyd.COM) by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA01750; Mon, 15 Jun 92 16:22:59 PDT Date: Mon, 15 Jun 92 16:22:59 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9206152322.AA01750@ray.lloyd.com> Received: by harry. (4.1/SMI-4.1) id AA00622; Mon, 15 Jun 92 16:22:44 PDT To: fbaker@acc.com Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Fred Baker's message of Mon, 15 Jun 92 14:46:23 PDT <9206152146.AA22755@saffron.acc.com> Subject: compress Network Working Group F Baker Internet Draft Troublemaker ^^^^^^^^^^^^ Boy! You sure got that right! :-) Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 16 06:52:06 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21683; Tue, 16 Jun 92 06:38:23 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04911; Tue, 16 Jun 92 06:19:41 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21025; Tue, 16 Jun 92 06:11:45 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from anu.anu.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20910; Tue, 16 Jun 92 06:06:13 -0700 Received: from cscgpo.anu.edu.au by anu.anu.edu.au (4.1/SMI-4.1) id AA17235; Tue, 16 Jun 92 23:05:14 EST Received: from huxley.anu.edu.au by cscgpo.anu.edu.au (4.1/SMI-4.1) id AA20660; Tue, 16 Jun 92 23:05:12 EST From: cmf851@cscgpo.anu.edu.au (Albert Langer) Message-Id: <9206161305.AA20660@cscgpo.anu.edu.au> Subject: Re: compress To: fbaker@acc.com (Fred Baker) Date: Tue, 16 Jun 92 23:05:09 EST Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <9206152146.AA22755@saffron.acc.com>; from "Fred Baker" at Jun 16, 92 02:46:23 pm X-Mailer: ELM [version 2.4dev PL32] I'm delighted to see LAP B and V.42bis compression under discussion and would like to offer some suggestions: 1. Should not be called "Datagram Compression" since in fact it doesn't work with datagrams but only with error corrected connection. 2. Design Motivation re delays seems to reflect a popular fallacy. Of course anything that increases throughput will reduce delays, therefore compression will reduce delays, however it ONLY does so indirectly - by increasing throughput. I would imagine that unacceptable latency is experienced when using interactive applications over a PPP link (e.g. Virtual Terminal such as telnet) simply because the packet sizes are too large (not necessarily in the interactive session - perhaps in a simultaneous file transfer session over the same link). A 1K frame will take 1 second to cross a 9600 bps link and any high priority interactive packets waiting to cross simply have to wait until it has crossed. Compressing it will just proportionately reduce the delay. Providing QOS negotiation of acceptable transit delay so that smaller packet sizes are used by ALL sessions when ANY sessions require interactive performance is the ONLY way to reduce transit time. Then a high priority interactive packet can only find itself waiting for another packet of say 32 octets before crossing. That would be a delay more like 1/30th of a second, with only a slight reduction in throughput due to the increased overhead of more packets. 3. Once you have LAP B it is easy to use small frames without much reduction in throughput, by simply using a "More" bit to segment a large LAN frame into multiple LAP B frames of the maximum size selected according to transit delay considerations. This can be done with or without data compression. 4. Incidentally, LAP B also allows you to eliminate the "Link Quality Monitoring" protocol since both sides know how many errors they are correcting. As well as providing support for connection oriented protocols it will also SUBSTANTIALLY improve performance of connectionless protocols by correcting errors where they occur instead of transmitting the errors right across the network, with correction requests back right across the network and then still having to transmit the correction across the PPP link anyway. I know it is POSSIBLE to transmit IP across a phone line without any error detection, let alone correction (e.g. SLIP) but the plain fact is that error rates on phone lines are at least one or two orders of magnitude higher than on LANs so the design appropriate for (some) connectionless protocols on LANs simply isn't appropriate for phone lines. The recent DECnet NCP draft noted that DEC "connectionless" management protocols won't work properly with error rates typical of phone lines - I suggest that is true of many other "connectionless" protocols and that ALL such protocols likely to be used on PPP links will benefit substantially from LAP B. (The only exception I can think of is things like digitized speech where transit delay is more important than error correction, which are not likely to be relevant to low or moderate speed PPP links). So, why not just use LAP B (plus a "More" bit) for ALL PPP protocols? The contribution made by the PPP group would then be recognized as defining paramaters etc for control of various network layer protocols in a multi-protocol environment, rather than as inventing a new "point to point protocol". Whatever the merits of multi-protocol routing, that surely IS the contribution of the PPP group, which may well be lost sight of in reaction against the PPP "protocol" itself, which as far as I can see, basically does NOTHING that is not provided for better by LAP B and associated protocols. 5. Speaking of associated protocols, HDLC XID frames specified in ISO 8885 provide superior facilities to the "Link Control Protocol" for defining link paramaters and the "Private Paramaters" defined within it can be used to carry any special paramaters required for multi-protocol control desired by the PPP group. Frame sizes, unique identifiers ("magic numbers"), choice of async transparency mode, 16 or 32 bit CRC calculations etc etc are all already provided for and X.32 adds comprehensive authentication options. Why re-invent things that already have recognized International Standards developed on the basis of VASTLY more experience on "point to point" links using telephone lines than is available among Internet developers of multi-protocol LAN routers. Why not just add the paramaters required for control of those routers, which is within YOUR field of expertize. 6. Also, once you have LAP B, adding the rest of X.25 (the Packet Layer Protocol - PLP) is relatively simple. The standard (ISO 8208) looks incredibly complex because of all the options, but you only need the bare minimum for multiplexing and a Call User Data Field in CONNECT packets that can contain the Subsequent Protocol Identifier defined in ISO TR 9577 (e.g. IEEE SNAP code plus any defined for your "control" protocols - or use the Q bit for the latter). Even WITH all the options, the full X25 standard is SUBSTANTIALLY shorter than the rapidly growing collection of PPP "protocols", each of which could EASILY be reduced to simple lines in a table of paramaters. This may be just because ISO has chosen NOT to list each of the 4095 available Logical Channels separately, together with an explanation of the corresponding "Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject" but has instead defined the concept of a Virtual Circuit just ONCE. Nevertheless the plain fact is X25 PLP and TR 9577 provides a similar but simpler mechanism for identifying protocols. By doing it over an error corrected data link layer, X25 is ALSO able to provide a "More" bit and QOS negotiation and separate flow control for each channel - ALL of which should be of SUBSTANTIAL benefit to multi-protocol routers. That is all WITHOUT the network layer routing and relaying that X25 was designed for (which could also be used to configure complex multi-protocol multi-point links). 7. In any case, X25 IS already used this way, for multi-protocol routers over public data networks. Given the MANDATORY GOSIP requirements for X25 to support EITHER CLNP or CONS over WANs, surely X25 ought to be standard equipment on multi-protocol routers - especially now that ISO DIS 10732/X.614 defines CONS over the PSTN and given the MANDATORY requirements for TP0/CONS to access public X.400 MHS and Directory Services? Used with NSAP addressing in (only) the Extended address field and full QOS negotiation for individual CONS connections or with SNPA addressing for individual CLNP links it can provide adequate OSI networking. Used without addressing or with only the normal address field and TR 9577 protocol identification it can support multi-protocol routers. Note: I know better than to preach the virtues of protocol architecture integrity and the benefits of OSI, to a congregation of multi-protocol router developers. While I personally would prefer that you "get ye hence and sin no more", I am just suggesting a simpler and more effective way to do your sinning, which at least avoids diverting resources into supporting a non-standard and increasingly complex and ever widening set of bizarre new "protocols", when you can do the SAME job with EXISTING well designed and internationally standardized protocols that you KNOW you will have to implement anyway - by just specifying whatever tables of paramaters you need. 8. It may be suggested that PPP has the advantage of needing only 1 header octet for most protocols and two for the rest, whereas X25 uses 2+3=5. But this is achieved by means of separately negotiating BOTH header compression AND protocol ID compression. The PPP group could make EXACTLY the same contribution to the efficiency of X25 by defining a header compression method for X25 (it already includes protocol ID compression since the protocol ID is only required in the CONNECT packet, with the protocol for each packet subsequently idenfitied by the Logical Channel number alone). I have already worked out a header compression scheme that uses only three octets for normal data packets, which preserves full multiplexed flow control and receipt acknowledgement with D, Q and M bits and can be used alongside the normal use of addresses A and B for LAP B single link procedures (and C and D for multi-link procedures) without needing prior XID negotiation (and also providing for Network Protocol ID, Transport and Upper layer compression :-). If you aren't interested in multiplexed flow control and acknowledgement but only want LAP B error correction with an M bit and protocol ID, then it could be done in two octets, though I would not recommend that. The LAP B address octet only carries two bits of information - that it is not an extended address and that it is a Command or Response. This leaves 6 bits plus the C/R bit which can identify up to 128 protocols that use the second octet as the control for a numbered "I" frame with P/F and M bits (less 6 to preserve the standard meanings of addresses A, B, C, D, 0xFF (global) and 0 (null) - say 120 protocol IDs. 9. Returning to (data) "compression", I think the "compressed data length" field before the compressed data in section 2.4 may be a mistake. A three bit field (i.e. one octet, reserving the other five bits), at the END of the packet might be better. The frames are self-delimiting so it should only be necessary to specify how much of the last compressed data octet is padding, which only needs 3 bits for 0-7 bits of padding. More important this allows for "streaming" with the frame being output before it's final length is known. This is an important feature of the V.42 design, to improve latency for interactive applications, and I imagine it would be included in V.42 bis as well. Incidentally, why not do it EXACTLY according to V.42bis when a sync serial port is available, and a close equivalent for async? (LAP M is based on LAP D, which is pretty similar to LAP B with multiple LSAP addresses instead of just A and B). 10. Re the "mental note" about encryption vs. data compression in section 2.3. Surely the difference is that with data compression you only need the algorithm to extract the original data whereas with encryption you ALSO need either a "key" or expensive "cryptanalysis" (assuming you afeady have the algorithm). 11. Any response re separating out the MAC sublayer etc? From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 16 10:07:23 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27265; Tue, 16 Jun 92 09:58:20 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06784; Tue, 16 Jun 92 09:30:41 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26154; Tue, 16 Jun 92 09:23:00 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25989; Tue, 16 Jun 92 09:17:33 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA00716; Tue, 16 Jun 92 09:15:55 PDT Date: Tue, 16 Jun 92 09:15:55 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9206161615.AA00716@saffron.acc.com> To: cmf851@cscgpo.anu.edu.au Subject: Re: compress Cc: ietf-ppp@ucdavis.ucdavis.edu >> 1. Should not be called "Datagram Compression" since in fact it >> doesn't work with datagrams but only with error corrected >> connection. OK, global replace "Datagram" with "Data". There are some things I'm real easy on. :^) >> 2. Design Motivation re delays seems to reflect a popular fallacy. >> Of course anything that increases throughput will reduce delays, >> therefore compression will reduce delays, however it ONLY does so >> indirectly - by increasing throughput. I would imagine that >> unacceptable latency is experienced when using interactive >> applications over a PPP link (e.g. Virtual Terminal such as telnet) >> simply because the packet sizes are too large (not necessarily in >> the interactive session - perhaps in a simultaneous file transfer >> session over the same link). A 1K frame will take 1 second to >> cross a 9600 bps link and any high priority interactive packets >> waiting to cross simply have to wait until it has crossed. >> Compressing it will just proportionately reduce the delay. >> Providing QOS negotiation of acceptable transit delay so that smaller >> packet sizes are used by ALL sessions when ANY sessions require >> interactive performance is the ONLY way to reduce transit time. Then >> a high priority interactive packet can only find itself waiting for >> another packet of say 32 octets before crossing. That would be a >> delay more like 1/30th of a second, with only a slight reduction in >> throughput due to the increased overhead of more packets. I'm not sure I agree with your analysis here. When you said "increasing throughput reduces delay" is a fallacy, I was expecting you to point out that compression and decompression take time, and passing compressed data only reduces delay if the total time from "packet in the clear" to "packet in the clear" is less, which is a function of processor performance as well as line speed. But you seem to be arguing that carving packets up into peices 1/30 the size will reduce delay. If I have a 1024 TCP segment , and send it instead as 32 32 byte segments, I have added at least 31*20 octets (that's fragmentation; 31*40 if TCP does it), disregarding line overhead, to the data stream. *That* doesn't sound much like it will reduce delay. I'll yield the point that we're only affecting throughtput rate induced delays. >> 3. Once you have LAP B it is easy to use small frames without much >> reduction in throughput, by simply using a "More" bit to segment a >> large LAN frame into multiple LAP B frames of the maximum size >> selected according to transit delay considerations. This can be done >> with or without data compression. LAPB has no "more" bit. You're thinking X.25. >> 4. Incidentally, LAP B also allows you to eliminate the "Link >> Quality Monitoring" protocol since both sides know how many errors >> they are correcting. As well as providing support for connection >> oriented protocols it will also SUBSTANTIALLY improve performance of >> connectionless protocols by correcting errors where they occur >> instead of transmitting the errors right across the network, with >> correction requests back right across the network and then still >> having to transmit the correction across the PPP link anyway. Um, my company runs a LOT of LAPB. This statement is NOT supported by our experience. In point of fact, links generally run error-free. A couple of orders of magnitude worse than 10^-9 is only 10^-7, and frankly, that's a pretty pessimistic estimate as well. We don't see a single bit error every three minutes (10^7/56000) on ANYTHING. We see total outages once in a blue moon that average together to 10^-9 or 10^-7 BERs, but when the link's up, it generally runs dead clean. The only effect LAPB has on the link is to occasionally close the window in one direction, as a large packet going one way effectively withholds acknowledgement of a stream of small packets going the other way. In the event of an error, sometimes you get an REJ which restarts the data stream, but you get T1 timeouts about as frequently. The duration of a T1 timeout (at least three times the maximum packet size divided by the bit rate, to avoid spurious timeouts) is often comparable to TCP's SRTT. >> I know it is POSSIBLE to transmit IP across a phone line without any >> error detection, let alone correction (e.g. SLIP) but the plain fact >> is that error rates on phone lines are at least one or two orders of >> magnitude higher than on LANs so the design appropriate for (some) >> connectionless protocols on LANs simply isn't appropriate for phone >> lines. The recent DECnet NCP draft noted that DEC "connectionless" >> management protocols won't work properly with error rates typical >> of phone lines - I suggest that is true of many other "connectionless" >> protocols and that ALL such protocols likely to be used on PPP links >> will benefit substantially from LAP B. (The only exception I can >> think of is things like digitized speech where transit delay is more >> important than error correction, which are not likely to be relevant >> to low or moderate speed PPP links). So, why not just use LAP B >> (plus a "More" bit) for ALL PPP protocols? Well, this is an issue that was discussed before I joined the working group, and *that* was a long time ago. I think, in view of my comments on LAPB above, one might as easily ask "why do so?" I am suggesting it for cases where it is useful, not as the general practice. I don't think it's a good practice unless there's a good reason. >> 6. Also, once you have LAP B, adding the rest of X.25 (the Packet >> Layer Protocol - PLP) is relatively simple. Once again, my company has, um, heard of that protocol before. The question might best be phrased "yes, but who would want to?" Have you noticed that it's the X.25 vendors who are pushing Frame Relay, and that FR is explicitly un-X.25 like? >> 9. Returning to (data) "compression", I think the "compressed data >> length" field before the compressed data in section 2.4 may be a >> mistake. A three bit field (i.e. one octet, reserving the other >> five bits), at the END of the packet might be better. The frames are >> self-delimiting so it should only be necessary to specify how much >> of the last compressed data octet is padding, which only needs 3 >> bits for 0-7 bits of padding. The issue, of course, is that PPP defines a pad and mandates that someone else figure out how to remove it. That's a little bit like our federal government mandating that the states fund and offer welfare programs. I hope the Australian government is more sensible. I'll take votes here. I did it with a "length of pad" in RFC 1220 and caught flack. I'm doing it with a "length of data" here, and yes, two octets seems a tad excessive. I could invent yet a third way, with a self defining pad at the end, but now every packet *must* be padded. PPP is far more usually unpadded. Opinions? >> More important this allows for "streaming" with the frame being >> output before it's final length is known. This is an important >> feature of the V.42 design, to improve latency for interactive >> applications, and I imagine it would be included in V.42 bis as >> well. Incidentally, why not do it EXACTLY according to V.42bis >> when a sync serial port is available, and a close equivalent for >> async? (LAP M is based on LAP D, which is pretty similar to LAP B >> with multiple LSAP addresses instead of just A and B). Well, to become *exact*, I have to change PPP in two ways. I have to eliminate the possibility of the pad, and I have to make compressed LCP packets the default. It'll take a lot of thrust to make that bird fly. >> 11. Any response re separating out the MAC sublayer etc? I'm not trying to make something protocol specific here. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 16 10:32:13 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28102; Tue, 16 Jun 92 10:25:32 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07140; Tue, 16 Jun 92 09:59:47 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27096; Tue, 16 Jun 92 09:52:39 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from GINGER.LCS.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26904; Tue, 16 Jun 92 09:46:05 -0700 Received: by ginger.lcs.mit.edu id AA01365; Tue, 16 Jun 92 12:45:11 -0400 Date: Tue, 16 Jun 92 12:45:11 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206161645.AA01365@ginger.lcs.mit.edu> To: martillo@azea.clearpoint.com Subject: Re: bizzare diatribe from Joachim Martillo Cc: ietf-ppp@ucdavis.ucdavis.edu, jnc@ginger.lcs.mit.edu 4) Suppose we accept ... that the network layer should have intimate knowledge of the establishment and disestablishment of physical links (demand CSCs). .... Maybe I'm confused, but I thought PPP already did basically what was being suggested here; i.e. you can take NCP's up and down individually, but the LCP stays up. 2) Suppose the remote is sending IPX in MAC frames but the local wants the IPX packets to come in the network layer packet representation.... (Following discussion is extremely inarticulate, please excuse me, I don't have the energy to rework it into clarity.) This is a problem, but one not unique to PPP. Other network layers suffer similar problems; e.g. what format do you send an IP packet on over an Ethernet; the old Ethernet 16 bit header, the SNAP header, or what? (There used to be a third legal one, but mercifully, it's gone.) Which format we should be using depends, I would suggest, on what the boxes on the ends are *doing* with the packet. If they are *routing* it (i.e. processing the level 3 header), then it more or less has to be sent as an IPX frame; it they are *bridging*, then it has to be sent as a MAC frame. How to get the boxes to agree as to whether they are are routing or bridging is water that is simply too deep for me to want to jump into! It's is partially an issue of what the network designer wants, so it is legitimately a configuration issue (i.e. smart autoconfigure can't 'always' do the right thing). As to whether it makes sense to allow the possibility of having a different kind of box (or at least boxes which act differently with respect to packets of a single type) on each end, similar to the way a bridge may pass on a packet to a router over an Ethernet, this is even deeper water. I would suggest that given the tight coupling of the two ends, it makes sense to assume an agreement between the ends of the link as to how to handle packets of any given type. In fact, point-point links are often special cased in the internet model (this is the half-router model), and are given such special support as unnumbered links (e.g., in OSPF). This would of course break down if PPP were used for switch-switch connetions made in a much more dynamic way, e.g. with dialups. You then have a situation much more like the Ethernet one. The fact that this WG picked different formats for bridged and routed packets was not deliberate, but historical. One of the two original goals of this WG was to provide multi-vendor multi-protocol router connectivity. They picked, in all innocence, a format that was optimal for that. It is also a network which does not use MAC addresses at the hardware level (nice, for efficiency on slow lines). Thus, when demand for bridging over PPP came along, a special Bridge framing NCP was created, which kept the MAC addresses and the MAC protocol framing. PPP will, I believe, work well to connect half-bridges in a vendor independant way. OK, but this all created the problem Joaquin pointed out. All I can say there is that this problem is caused by trying to operate a bridge, not as a half-bridge, but as a multi-media bridge; connecting a point-point link to a LAN *in a general way*. (I.e. as opposed to simply using a point-point link to connect two half-bridges.) This problem is similar in spirit to all the other tricky problems with bridging packets between different media, and with which the MMB WG has been wrestling; it's just one more instance of the way MMB's don't respond well to the fragmented nature of level 2 development. PPP simply does not offer good support for MMB's. I think, given the (reasonable) charges that PPP is trying to be too many things to too many people, this was a reasonable (if not really understood) choice. PPP is partially optimized for router/router operation, with headers that are simple to construct, but not general enough for MMB interoperability. This seems to me hardly a fatal error; MMB problems already existed, and would not go away even (e.g. different MTU) even if all the networks in the world used the same addressing and wrapping conventions. True, this is one more nasty, intractable problem MMB's have to grapple with, but I'm not going to lose a lot of sleep over it. I mean, it's not like it was done deliberately to screw them PPP simply won't work when you have a router for protocol X on one end of link, and a bridge on the other. That's that, sorry. Having said all that, I hereby suggest we remand the problem of what to do when both ends are not simultaneously routing or bridging packets of a particular protocol to the MMB Working Group of the IETF! I'm tired of thinking about this one, it makes my head hurt.... Noel PS: It's not that I'm trying to screw MMB's. I will admit, not seeing the advantages of bridges, and thus predicting their popularity, was my second-wrost mistake while I was at Proteon, but I'm not out to get MMB's. It's just that they have real problems, and I don't think they are the best development path for very large internets, which I see as the goal we need to be working towards. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 16 11:32:10 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29965; Tue, 16 Jun 92 11:23:37 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07853; Tue, 16 Jun 92 10:59:52 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28950; Tue, 16 Jun 92 10:52:19 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28794; Tue, 16 Jun 92 10:45:46 -0700 Received: from harry. (harry.lloyd.COM) by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02413; Tue, 16 Jun 92 10:44:49 PDT Date: Tue, 16 Jun 92 10:44:49 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9206161744.AA02413@ray.lloyd.com> Received: by harry. (4.1/SMI-4.1) id AA00875; Tue, 16 Jun 92 10:44:33 PDT To: fbaker@acc.com Cc: cmf851@cscgpo.anu.edu.au, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Fred Baker's message of Tue, 16 Jun 92 09:15:55 PDT <9206161615.AA00716@saffron.acc.com> Subject: compress Intranetwork fragmentation can be a good thing. If the interface sees that it has interactive packets in its queue and it is in the middle of sending a big packet, the ability to arbitrarily chop up the big packets and interleave the smaller ones could greatly reduce response time for interactive applications. In this case the network (PPP) layer performs the fragmentation and reassembly without IP being aware of the process. On the other hand, is it really worth the extra complexity? Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 16 12:53:40 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02631; Tue, 16 Jun 92 12:47:17 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09018; Tue, 16 Jun 92 12:30:06 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01924; Tue, 16 Jun 92 12:23:27 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01817; Tue, 16 Jun 92 12:18:10 -0700 Received: by volitans.morningstar.com (5.65a/92042102) id AA23175; Tue, 16 Jun 92 15:17:10 -0400 Date: Tue, 16 Jun 92 15:17:10 -0400 From: Bob Sutterfield Message-Id: <9206161917.AA23175@volitans.morningstar.com> To: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Fred Baker's message of Tue, 16 Jun 92 09:15:55 PDT <9206161615.AA00716@saffron.acc.com> Subject: compress Sender: ietf-ppp-request@ucdavis.edu Date: Tue, 16 Jun 92 09:15:55 PDT From: fbaker@acc.com (Fred Baker) In point of fact, links generally run error-free. Not all of them, not end-to-end. Modern modems generally deliver clean bits, and I haven't ever chalked any errors up to cosmic rays hitting the wires between the modems and the hosts. But our PPP daemon must work within the constraints of various UNIX vendors' serial I/O hardware and driver software. Some are able to keep the UARTs' input silos drained in a timely fashion, but others can't keep up, even at only 38400. We don't see a single bit error every three minutes (10^7/56000) on ANYTHING. On some systems, our daemon (catching incoming frames from the serial driver) sees FCS errors as a fairly common event, discarding one frame in every twenty to fifty. In such an environment, activities like dictionary resyncs would be relatively frequent and therefore expensive. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 16 13:11:49 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02998; Tue, 16 Jun 92 13:00:20 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09066; Tue, 16 Jun 92 12:34:39 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01927; Tue, 16 Jun 92 12:23:32 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01830; Tue, 16 Jun 92 12:19:05 -0700 Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA05766; Tue, 16 Jun 92 12:18:07 -0700 Date: Tue, 16 Jun 92 14:42:18 EDT From: "William Allen Simpson" Message-Id: <431.bsimpson@angband.stanford.edu> To: internet-drafts@nri.reston.va.us Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: ppp-osi draft There is a new draft for the PPP over OSI NCP. It may be found at angband.stanford.edu:pub/ppp/osi.txt Please issue the "Last Call" when the draft is posted. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 16 14:22:58 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05549; Tue, 16 Jun 92 14:16:49 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09810; Tue, 16 Jun 92 13:51:16 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04380; Tue, 16 Jun 92 13:43:22 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04194; Tue, 16 Jun 92 13:36:30 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA06910; Tue, 16 Jun 92 13:34:47 PDT Date: Tue, 16 Jun 92 13:34:47 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9206162034.AA06910@saffron.acc.com> To: bob@MorningStar.Com Subject: Re: compress Cc: ietf-ppp@ucdavis.ucdavis.edu I should clarify my perspective. If ASYNC were in view in that document, I would simply say "buy a V.42bis modem". I am refering to synchronous links, especially 9.6 .. 64 KBPS DDS links, and I am referring, I suppose, to products I sell. The document talks rather specifically about things that are designed to run T-1 lines being underutilized on synchronous links at and below 64 KBPS. If you are running a DDS circuit and you are seeing single bit errors at one every 3 minutes, you have a faulty circuit, and if your vendor takes his tarrif so lightly that you can't get it fixed, you are far better off with 7/8 forward error correction than with a go-back-n policy. If you have a CPU spec'd for T-1 and you are messing with UNIX silos, may the Force be with you. :^) Fred From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 17 07:10:09 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01411; Wed, 17 Jun 92 07:09:31 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA15474; Wed, 17 Jun 92 06:49:41 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00763; Wed, 17 Jun 92 06:40:47 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [134.22.80.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00688; Wed, 17 Jun 92 06:37:14 -0700 Received: from donut.gandalf.ca.adg.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA28490; Wed, 17 Jun 92 09:36:11 EDT Received: by donut.gandalf.ca.adg.gandalf.ca (4.1/SMI-4.1) id AA13173; Wed, 17 Jun 92 09:36:10 EDT From: dcarr@donut.gandalf.ca (Dave Carr) Message-Id: <9206171336.AA13173@donut.gandalf.ca.adg.gandalf.ca> Subject: Data(gram) Compression To: ietf-ppp@ucdavis.ucdavis.edu Date: Wed, 17 Jun 92 9:36:08 EDT Cc: fbaker@acc.com X-Mailer: ELM [version 2.3 PL11] >> Of course anything that increases throughput will reduce delays, >> therefore compression will reduce delays, however it ONLY does so >> indirectly - by increasing throughput. I would imagine that >> unacceptable latency is experienced when using interactive >> applications over a PPP link (e.g. Virtual Terminal such as telnet) >> simply because the packet sizes are too large (not necessarily in >> the interactive session - perhaps in a simultaneous file transfer >> session over the same link). Fred>But you seem to be arguing that carving packets up into peices 1/30 the Fred>size will reduce delay. If I have a 1024 TCP segment , and Fred>send it instead as 32 32 byte segments, I have added at least 31*20 Fred>octets (that's fragmentation; 31*40 if TCP does it), disregarding line Fred>overhead, to the data stream. *That* doesn't sound much like it will Fred>reduce delay. You missed the point Fred. The key words is HIGH PRIORITY interactive packets. Assume the 1024 TCP segment is LOW priority traffic. Then, fragmenting the low priority packet get the HIGH priority packet through sooner. I would also like to see some form of fragmentation specified. There is a problem here however. If both packets are compressed using the same tables, then although fragmentation gets the high priority packet over the link sooner, you cannot decompress it until the low priority packet is received. There are 2 solutions. Fragment the TCP packet before compression and incur more overhead on long packets, or use separate compression tables for each priority level supported. I favour the latter. Now, let's consider 4500 byte FDDI packets with fragmentation over a 9600 bps link. Ouch! >> 9. Returning to (data) "compression", I think the "compressed data >> length" field before the compressed data in section 2.4 may be a >> mistake. A three bit field (i.e. one octet, reserving the other >> five bits), at the END of the packet might be better. The frames are >> self-delimiting so it should only be necessary to specify how much >> of the last compressed data octet is padding, which only needs 3 >> bits for 0-7 bits of padding. Fred>The issue, of course, is that PPP defines a pad and mandates that Fred>someone else figure out how to remove it. Fred>I'll take votes here. I did it with a "length of pad" in RFC 1220 and Fred>caught flack. I'm doing it with a "length of data" here, and yes, two Fred>octets seems a tad excessive. I could invent yet a third way, with a Fred>self defining pad at the end, but now every packet *must* be padded. Fred>PPP is far more usually unpadded. I think it should be simply stated that there is *no* padding allowed period with V.42bis PPP data compression. Would any vendor serious about saving bandwidth with compression REQUIRE padding? I should think not. Of course, if they use Zilog 16C30's is 16-bit mode... Put it to a vote. Turf the pad is mine. -- Dave Carr | dcarr@gandalf.ca | It's what you learn, Principal Designer | TEL (613) 723-6500 | after you know it all, Gandalf Data Limited | FAX (613) 226-1717 | that counts. From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 17 09:54:57 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05768; Wed, 17 Jun 92 09:34:33 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA16257; Wed, 17 Jun 92 08:40:56 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03908; Wed, 17 Jun 92 08:36:12 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03452; Wed, 17 Jun 92 08:22:38 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA08481; Wed, 17 Jun 92 08:21:05 PDT Date: Wed, 17 Jun 92 08:21:05 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9206171521.AA08481@saffron.acc.com> To: dcarr@donut.gandalf.ca, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: Data(gram) Compression Cc: fbaker@acc.com >> You missed the point Fred. The key words is HIGH PRIORITY interactive >> packets. Assume the 1024 TCP segment is LOW priority traffic. Then, >> fragmenting the low priority packet get the HIGH priority packet >> through sooner. OK, thats fair, BUT... In light of current research, I'm not convinced that fixed priorities make for good line disciplines when bottleneck behavior is frequent. I suppose I could set up a separate mailing list to discuss all that, if anyone wants to; we needn't clutter this list with that discussion. Prioritization algorithms exist that take no more instruction executions than precedence queuing during a congestion event, take zero effort when congestion isn't present, require no configuration, and achieve better service than fixed priorities. I'd rather optimize towards the state of the art. [marketing blurb intentionally left out :^} ] >> I would also like to see some form of fragmentation specified. I would rather rely on CLNP/IP fragmentation, and (for other protocols), the limited header size. Color me minimalist if you like. >> Now, let's consider 4500 byte FDDI packets with fragmentation over a >> 9600 bps link. Ouch! 4500 byte FDDI/9600 is a bad example. 4500 byte Tolkien Ring/9600 is rather realistic. ======================================================================= >> Of course, if they use Zilog 16C30's is 16-bit mode... >> >> Put it to a vote. Turf the pad is mine. Maybe Bill will liberate me on this one. My understanding of RFC 1331 section 3.1 leads me to believe that, although that is the best solution, it is the one I'm not allowed to choose. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 17 14:24:04 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14599; Wed, 17 Jun 92 14:18:21 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05118; Thu, 11 Jun 92 17:09:52 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09979; Thu, 11 Jun 92 17:00:52 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09662; Thu, 11 Jun 92 16:52:33 -0700 Received: from napa.TELEBIT.COM by apache (4.1/SMI-4.1/Telebit-Apache-Brent-910926) id AA20503 to ietf-ppp@ucdavis.edu; Thu, 11 Jun 92 16:51:36 PDT Received: from yoyo.telebit.com by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910507) id AA11794 to ietf@isi.edu; Thu, 11 Jun 92 16:51:35 PDT Date: Thu, 11 Jun 92 16:51:35 PDT From: mlewis@napa.Telebit.COM (Mark S. Lewis) Message-Id: <9206112351.AA11794@napa.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA09257; Thu, 11 Jun 92 16:52:28 PDT To: ietf@isi.edu, ietf-ppp@ucdavis.ucdavis.edu Subject: PPP Interoperability Meeting During the week of June 1-5, ten (10) of the leading networking vendors attended an event called the "PPP-Athon". It was hosted by Telebit in Sunnyvale. The pupose of the event was to determine the extent to which these vendor's products interoperate using PPP. The Point-to-Point-Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. 3Com Cayman cisco Systems FTP Software Livingston Enterprises Morning Star Technologies Network Applications Technology (NAT) Network Systems Novell Corp. Telebit Corp. Vendors tested their products interoperability over synchronous and dial-up asynchronous PPP connections. They tested routing IP, IPX (NetWare), AppleTalk, DECnet IV, and OSI protocol packets. Several vendors tested bridging over PPP links. Without exception, all vendors demonstrated interoperability. In every combination, products were able to open connections and send datagrams. During the week, almost all vendors made improvements to their products. There was an open dialog between vendors about their respective implementations. As a result, new features were added, numerous bugs were found and fixed, and interoperability issues were resolved. By their participation, these vendors also demonstrated a commitment to making their products interoperate. These vendors committed significant time and resources to testing their implementations at this event. ... Mark =========----------- Mark S. Lewis -----------========== inet: mlewis@telebit.com Telebit Corp. Telebit (408) 745-3232 uucp: uunet!telebit!mlewis Fax (408) 745-3810 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 17 19:42:00 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24811; Wed, 17 Jun 92 19:34:48 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23668; Wed, 17 Jun 92 19:19:45 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23963; Wed, 17 Jun 92 19:10:30 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from anu.anu.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23739; Wed, 17 Jun 92 19:01:28 -0700 Received: from cscgpo.anu.edu.au by anu.anu.edu.au (4.1/SMI-4.1) id AA25388; Thu, 18 Jun 92 12:00:11 EST Received: from huxley.anu.edu.au by cscgpo.anu.edu.au (4.1/SMI-4.1) id AA07546; Thu, 18 Jun 92 12:00:10 EST From: cmf851@cscgpo.anu.edu.au (Albert Langer) Message-Id: <9206180200.AA07546@cscgpo.anu.edu.au> Subject: Re: Data(gram) Compression To: dcarr@donut.gandalf.ca (Dave Carr) Date: Thu, 18 Jun 92 12:00:08 EST Cc: ietf-ppp@ucdavis.ucdavis.edu, fbaker@acc.com In-Reply-To: <9206171336.AA13173@donut.gandalf.ca.adg.gandalf.ca>; from "Dave Carr" at Jun 18, 92 09:36:08 am X-Mailer: ELM [version 2.4dev PL32] > You missed the point Fred. The key words is HIGH PRIORITY interactive > packets. Assume the 1024 TCP segment is LOW priority traffic. Then, > fragmenting the low priority packet get the HIGH priority packet > through sooner. Right. However there is a slight distinction between "fragmenting" as applied to "connectionless" protocols like IP and CLNP, and the "segmenting" of connection oriented protocols implied by a "More" bit. This may sound pedantic but it is relevant to the next point you raise. > I would also like to see some form of fragmentation specified. > > There is a problem here however. If both packets are compressed using > the same tables, then although fragmentation gets the high priority > packet over the link sooner, you cannot decompress it until the low > priority packet is received. > > There are 2 solutions. Fragment the TCP packet before compression > and incur more overhead on long packets, or use separate compression > tables for each priority level supported. I favour the latter. Nope, compression is applied to ALL the data in the I frames of the LAP B data link layer, which are maintained in sequence by the LAP B procedures, regardless of what network layer packets and priorities they belong to. Hence only one set of compression tables is needed. Each (sub)Network Prococol Data Unit is extracted from the I frames and decompressed as it is received and each (sub)Network Service Data Unit can be reassembled as soon as all the segments have been delivered. A high priority Virtual Circuit simply gets its (one or more) segments for each SDU transmitted ahead of lower priority VCs, so a lower priority SDU cannot be reassembled and delivered until later, even if it started being transmitted before the higher priority SDU. There is no reason to wait until the low priority SDU is received before decompressing the high priority SDU - its individual segments were compressed in the sequence they were transmitted and decompressed in the same sequence. The same applies to encryption. Applying compression and (then) encryption at the (connection oriented) data link layer is COMPLETELY transparent to the (sub)Network layer, whether that is connection oriented (and segmented) or connectionless (and fragmented). Incidentally, this is an argument for applying compression at the Presentation layer where it can adapt to the characteristics of the individual data stream, rather than at the data link layer where random binary data from one session (e.g. encrypted) can disrupt the compression tables that are being used on the same data link with other data streams such as email text that COULD have benefited from compression if they were separated. Nevertheless, it can't do any harm at the data link layer and can compensate at least to some extent for failure to provide it higher up. Fragmentation can be complex in connectionless (sub)networks (in fact setting up and then tearing down a "connection" for every fragmented packet, instead of just once between two network layer entities). But segmentation and reassembly, is quite trivial to implement and requires only 1 bit of "overhead" in a connection oriented (sub)network. Consequently it is relatively easy to guarantee a particular Quality of Service for transit delay by enforcing a maximum packet size and using a "More" bit for segmentation and reassembly in a connection oriented (sub)Network. Although such segmentation and reassembly is at the (sub)network level rather than at the data link layer, it is again COMPLETELY transparent to the Network layer, which may be connection oriented or connectionless. Note that this argument for a connection oriented SUBnetwork layer, is quite independent of whether the Network Layer itself is connectionless or connection oriented. Thus both the DDN specification of IP/X25 and the US GOSIP specification of CLNP/X25 recognize the necessity of a connection oriented subnetwork layer over point-to-point links even in a "connectionless" WAN environment. A "point-to-point" link is INHERENTLY "connection oriented", whether it is a single link connecting a "stub" sub-network or one of many providing a richly connected topology for interconnections between several LANs via several WANs. The link HAS to be "connected" between the two "points" before any data can flow and once it is connected, the data CANNOT travel by multiple routes and thus arrive in a different sequence, since there is only one route connecting all the endpoints, and it CANNOT be individually addressed to different endpoints because there are only the two. Hence NO benefits can be obtained by using a connectionless data link and sub-network layer over a point-to-point link. (Multi-link procedures are a special case of connection oriented point-to-point data link with multiple physical links.) As well as compression and encryption, I would argue that implementing even the very minimal transit delay priority bit specified for IP REQUIRES use of segmentation and a "More" bit with a connection oriented data link and subNetwork layer over a low speed WAN. At T1 speeds and maybe even 56Kbps it may not matter very much, but at 9600bps I don't see how you CAN give effective priority to some IP packets over others, and meet ANY reasonable transit delay requirements for interavtive sessions, without segmenting ALL the IP packets to a size shorter than the transit delay requirement. Using IP fragmentation would leave the low priority packets still too large for the high priority packets to meet the transit delay requirement and/or substantially reduce throughput by adding the completely unnecessary overhead of IP segment headers. A side benefit of course is that you can COMPLETELY avoid "fragmentation" of either IP or CLNP packets, thus avoiding both the extra complexity and the reduced throughput due to segment headers. This should be especially useful in point-to-point WAN links between routers, where the packets should be already ressembled at one router before they are routed to another one and it would be simply wasting bandwidth and adding complexity to fragment them in order to meet transit delay priority considerations on the WAN link. Segmentation achieves transit delay priority requirements, COMPLETELY transparent to the routers, and with negligible overhead. Likewise, this should be especially useful when connecting a single workstation, over a low speed telephone line link to an office or campus LAN or WAN. The workstation may want to use IP or CLNP for the connection, just because the office or campus LAN uses it, but implementation would be MUCH simpler if it could use the non-segmenting subset. Provided LAP B and a "More" bit are used, this can be achieved while ALSO giving the necessary priority to interactive sessions. This would seem to be a pretty commonplace requirement. How else COULD it be met? From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 17 21:01:43 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27261; Wed, 17 Jun 92 20:58:09 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23911; Wed, 17 Jun 92 20:39:47 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26620; Wed, 17 Jun 92 20:31:22 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from anu.anu.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26315; Wed, 17 Jun 92 20:23:31 -0700 Received: from cscgpo.anu.edu.au by anu.anu.edu.au (4.1/SMI-4.1) id AA25808; Thu, 18 Jun 92 13:22:26 EST Received: from huxley.anu.edu.au by cscgpo.anu.edu.au (4.1/SMI-4.1) id AA08471; Thu, 18 Jun 92 13:22:24 EST From: cmf851@cscgpo.anu.edu.au (Albert Langer) Message-Id: <9206180322.AA08471@cscgpo.anu.edu.au> Subject: Re: compress To: brian@lloyd.com (Brian Lloyd) Date: Thu, 18 Jun 92 13:22:18 EST Cc: fbaker@acc.com, cmf851@cscgpo.anu.edu.au, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <9206161744.AA02413@ray.lloyd.com>; from "Brian Lloyd" at Jun 17, 92 10:44:49 am X-Mailer: ELM [version 2.4dev PL32] > Intranetwork fragmentation can be a good thing. If the interface sees > that it has interactive packets in its queue and it is in the middle > of sending a big packet, the ability to arbitrarily chop up the big > packets and interleave the smaller ones could greatly reduce response > time for interactive applications. In this case the network (PPP) > layer performs the fragmentation and reassembly without IP being aware > of the process. > > On the other hand, is it really worth the extra complexity? > > Brian Lloyd, WB6RQN Lloyd & Associates Please note that this concept of interrupting a big low priority packet to chop it up for higher priority packets to get past is different from (and substantially more complex than) my proposal for a "More" bit, although BOTH proposals would operate at the subNetwork layer with IP being unaware of the process. The extra complexity of chopping up big packets "in the middle" of sending them would only be worthwhile if one was trying to squeeze the very last drop of throughput out of the link by using full-size segments as the default for low priority big IP packets so as to avoid the overhead from using small link frames. But this overhead does NOT include IP segment headers and is only about 5 octets per frame anyway (flag, 2 CRC, address and control), with further reduction possible through header compression if desired (and certainly more productive if one is trying for such extreme throughput maximization). The "More" bit segmentation really adds negligible complexity (and in fact simplifies things by avoiding ALL IP segmentation issues and also avoiding any need to negotiate a common packet size at all). An implementation that wants no extra complexity can simply ignore any transit delay QOS specifications (and guaranteed throughput specifications) that are given to it by the other end when opening Virtual Circuits, and refrain from demanding such requirements itself. It is up to the implementation that requests QOS guarantees to monitor whether they are actually being met or not (which can be done from either end without any need for a Link Quality Monitoring protocol when using LAP B). An implementation that just wants to support the transit delay priority bit of IP to a minimal extent, can simply configure a fixed frame size for all Virtual Circuits, depending only on the line speed rather than on the result of transit delay QOS negotiation per protocol. Then it can simply schedule high priority segments ahead of low priority ones with very little extra complexity. This may well be sufficient to support running interactive sessions as well as file transfer type sessions over low speed point-to-point links. A more sophisticated implementation would reserve bandwidth for each VC according to the throughput requested, refusing connection when more bandwidth is being demanded in total than is available on the link. It would set maximum frame size according to the most stringent transit delay being demanded (or reject the demand if that had too great an adverse effect on throughput). Even more sophisticated implementations could adapt frame sizes according to actual use of the link with throughput and transit delay QOS requirements as a starting point rather than assuming all VCs will attempt to use their full bandwidth quota simultaneously and will need to contend for transit delay. Other QOS paramaters for "priority" in establishing connections and dropping or degrading them to recover resources for other connections could also be taken into account, as could the difference between "minimal acceptable" and "target" transit delay and throughput. Algorithms for implementing priorities to best balance conflicting transit delay and throughput requirements are entirely up to the implementor. ALL that needs to be in the standard is the basic facility to segment packets with a "More" bit and to (optionally) negotiate QOS paramaters. This adds negligible complexity. As for interrupting "in the middle", that could be done with the async MAC sublayer by using a control escape sequence with a second octet that does not result in a flag, control escape, control character or DEL when flipped (and is also not the flag - used for "abort"). All the flipped printable characters (with either parity bit) are available to define such special tricks, except the one already used for "abort". One would simply define a "push" that puts the low priority frame and it's CRC calculation on the stack while a higher priority frame goes through, followed by a "pop". Implementations would require as many incoming frame buffers (and CRC temporary storage variables) as there were priority levels. This would not be VERY complex, but the benefit would also be fairly small for most situations. I was going to propose it as an option for low speed dialup connections of PCs in situations where they are mainly doing mail (and news) transfers or similar low priority large packets in the background, and also need rapid reaction for interactive VT type traffic. The SOLE purpose would be to reduce overhead by not segmenting the large packets when there are no higher priority packets that need to interrupt them. This seems unlikely to be of much benefit except on very low speed links (2400 bps rather than 9600 bps). It is certainly only an optional extra and I would strongly oppose attempting to define it as the MAIN way to achieve transit priority. (Also I suspect it would be very difficult to implement on sync links - effectively reducing them to async and thus counteracting any benefit). From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 17 22:50:45 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29968; Wed, 17 Jun 92 22:49:55 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA24286; Wed, 17 Jun 92 22:29:52 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29340; Wed, 17 Jun 92 22:23:20 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from anu.anu.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29233; Wed, 17 Jun 92 22:18:34 -0700 Received: from cscgpo.anu.edu.au by anu.anu.edu.au (4.1/SMI-4.1) id AA26533; Thu, 18 Jun 92 15:17:32 EST Received: from huxley.anu.edu.au by cscgpo.anu.edu.au (4.1/SMI-4.1) id AA09976; Thu, 18 Jun 92 15:17:26 EST From: cmf851@cscgpo.anu.edu.au (Albert Langer) Message-Id: <9206180517.AA09976@cscgpo.anu.edu.au> Subject: Re: compress To: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Date: Thu, 18 Jun 92 15:17:25 EST Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <9206171505.AA03043@rhyolite.wpd.sgi.com>; from "Vernon Schryver" at Jun 18, 92 09:05:49 am X-Mailer: ELM [version 2.4dev PL32] [Vernon Schryver] > This looks like a proposal to dump PPP in favor of x.25. Given the ever > increasing complexity of PPP, apparently aimed at approximating and > superceding all possible point-to-point protocols except raw MAC frames, > there is some merit such a nasty idea. Not exactly - I'm not at all diplomatic so I would just say so if I favoured simply dumping the PPP work. RFCs for connecting multi-protocol routers over X.25 and frame relay are already available so I expect people attracted to that "nasty idea" would simply use them over the PSTN or private point-to-point links in exactly the same way they are used over public data networks. I don't know much about multi-protocol routers but I gather from the PPP work that a need is perceived to negotiate certain paramaters in connection with many of the network layer protocols. One such requirement I think I DO understand is the need to enhance SLIP by allocating IP addresses (though there may be other ways to do that), and by specifying whether or not VJ header compression is used (although that could simply be identified as a different protocol). What I am proposing is that the work done on defining PARAMATERS related to multiple protocol router requirements be SEPARATED from the work done on data link layer protocols. The HDLC XID negotiation procedure already provides most things needed for a Link Control Protocol and anything extra can be defined as "private paramaters" within the existing framework. Likewise the PPP group's paramaters for each network layer protocol can be specified in the Call User Data Field or as facilities, or perhaps even in Q bit packets with each VC. Mechanisms for COMMUNICATING such paramaters across a LAP B data link layer HAVE been standardized. All the PPP group needs to do is USE them for it's own purposes, not invent new mechanisms and new data link layer protocols or subnetwork protocols. Thus the main part of the PPP group's work could be summarized in a simple table of paramaters to be used with EXISTING standard mechanisms. Instead of aiming for the highest ratio of protocol specification to function, the PPP group could end up winning the rather more prestigious award for achieving the LOWEST such ratio. Another aspect the PPP group seems very concerned with is header padding to improve processing performance and/or header compression (removing the address and UI control octets and using just a one or two octet header to identify the network layer or control procotol). I believe padding could be very simply defined as a "facility" negotiated with each protocol Virtual Circuit - either specifying the number of PAD octets to precede every SDU and/or every segment, or even allowing different padding for each SDU by specifying a single octet pad length, followed by that number of pad bits at the start or end of each SDU and/or each segment. Define the negotiation procedure ONCE, for ALL VCs and allow each side to negotiate whatever padding it likes instead of issuing "protocol specifications" for every protocol! I believe that header compression could be VERY useful, not just for PPP but for ANY use of data link layer and subnetwork protocols. For example a "More" bit could be added to LAP B by simply using one of the unused bits of the address octet with plenty of spare room and no impact on data link layer procedures. (Needs definition of how to "decompress" the compressed headers before applying data link layer compression and encryption). A single octet could carry both a (limited but extensible) range of Virtual Circuit Logical Channel numbers and flow control sequencing and acknowledgement numbers. Thus a typical X.25 packet could be reduced to a 3 octet header instead of 2+3. (Throw in optional default length frames and those frames that are of the default length might be able to use just 1 bit to specify that instead of a flag octet and transparency octets or bits. Use with a properly configured error correcting modem and the two CRC characters could also be optionally deleted. So the header compression work could also be taken further and applied more widely. As for the attempt to invent a new "connectionless" data link layer protocol for use over point-to-point CONNECTIONS, together with attempts to overcome the INHERENT problems of such an approach by adding in Link Quality Monitoring and a SUITE of protocols for opening and closing VCs, and an "option" for an entirely different connection oriented data link layer protocol (LAP B) - yes, I AM saying dump that. The world just doesn't need the complexity. X.25 is bad enough and it will be included in most multi-protocol routers anyway. > Is anyone else beginning to see a resemblence between the PPP development > history and the familiar caricature of the "Standards Process" as played by > ANSI, CCITT, IEEE, and the rest? Continual additions of features? All > comers completely accomodated? (except, of course, someone proposing a > particular "lower layer" scheme). All design choices answered "yes"? One > of my favorite design maxims is "Any fool can add features; the trick is > knowing what to leave out." When was something last proposed for PPP and > finally left out? (Except, of course, you-know-who's) Well, not being a diplomat, let me suggest that the problem is at a higher level. There is NOTHING wrong with a working group EXPERIMENTING with proposals for a new data "connectionless" data link layer protocol when their main focus is supposed to be on paramaters required to support multi-protocol routers etc. Having proposed an experimental protocol and gained some experience using that, it seems to me that responsibility lies with the IAB, or whoever approves upgrading status from "experimental" to "proposed" to "standard", to review the results, ask the hard questions and take the hard decisions. The problem isn't "continual additions of features" - that is a CONSEQUENCE of something wrong in the basic design that is making it NECESSARY to add "features" in support of particular requirements. For example a Link Quality Monitoring protocol is needed BECAUSE the basic design decision not to correct errors leaves each side not knowing which of the packets it transmitted were bad. A separate VC establishment protocol is needed for EVERY damn protocol BECAUSE of the basic design decision to think in terms of "protocol IDs" rather than Virtual Circuits and not to use the well established and much simpler means already standardized for setting up and tearing down VCs over a connection oriented data link layer. A LAP B "option" is needed to support compression (and encryption) and in my opinion also to support transit delay priorities, BECAUSE of the original "connectionless" mistake. That mistake arises from transplanting the experience with connectionless data link layer and subnetwork and network protocols on high bandwidth, low error rate LANs and applying it blindly to the completely different environment of WANs - ignoring the IMMENSE amount of experience that has been accumulated with "point-to-point" protocols on serial lines over DECADES. Isn't that just as big a mistake as blindly applying "connection oriented" WAN experience to the LAN environment? It isn't a problem of "all design choices answered 'yes'", but of a mistaken attempt to invent a new "point-to-point" PROTOCOL (as opposed to paramaters and header padding and/or compression techniques) in the first place. Such mistakes are INEVITABLE in a vigorously evolving R&D environment. Responsibility for saying "No" to STANDARDIZING such mistakes lies with the standards authority - i.e. the IAB I presume. It should be able to say "NO" to a "proposed" protocol for exactly the same reasons that designers of a protocol should be able to say "NO" to a new feature. SOMEBODY has to take the decision "do we need another protocol for point- to-point serial links" and it can't be those who designed it. (Nor of course should it be those who favour the existing internationally standardized protocols for serial point-to-point links. Whoever takes the decision should independently consider arguments from both sides.) From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 17 23:40:11 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01295; Wed, 17 Jun 92 23:37:52 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA24497; Wed, 17 Jun 92 23:19:43 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00566; Wed, 17 Jun 92 23:11:02 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from anu.anu.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00493; Wed, 17 Jun 92 23:08:34 -0700 Received: from cscgpo.anu.edu.au by anu.anu.edu.au (4.1/SMI-4.1) id AA26739; Thu, 18 Jun 92 16:07:32 EST Received: from huxley.anu.edu.au by cscgpo.anu.edu.au (4.1/SMI-4.1) id AA10470; Thu, 18 Jun 92 16:07:31 EST From: cmf851@cscgpo.anu.edu.au (Albert Langer) Message-Id: <9206180607.AA10470@cscgpo.anu.edu.au> Subject: Re: ppp-osi draft To: bsimpson@angband.stanford.edu (William Allen Simpson) Date: Thu, 18 Jun 92 16:07:29 EST Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <431.bsimpson@angband.stanford.edu>; from "William Allen Simpson" at Jun 17, 92 02:42:18 pm X-Mailer: ELM [version 2.4dev PL32] > > There is a new draft for the PPP over OSI NCP. It may be found at > angband.stanford.edu:pub/ppp/osi.txt > > Please issue the "Last Call" when the draft is posted. > > Bill_Simpson@um.cc.umich.edu > bsimpson@ray.lloyd.com > Well, since it is "Last Call" time, here's a few suggestions. 1. Reference [7] (ISO TR 9577) is now "published". 2. The "inactive subset" of CLNP can be quite useful for a workstation or laptop that simply needs a connection to it's "host" system and not to other addresses. MHS, Directory Service and the entire range of "Distributed Office Applications Model" applications can be accessed using TP4 over this essentially "null" network layer. Although I have no doubt that accessing them over a connection oriented "Minimal Network Layer" and TP0 or TP1 makes more sense (using LAP B plus a "More" bit), some will prefer that route and I know Christian Huitema has been advocating it. 3. Therefore padding should not be unnecessarily defined in a way that excludes this option. (I would say the same for the similar provision with frame relay - but at least a single workstation or laptop using frame relay with the "inactive subset" of CLNP is a rather bizarre configuration, whereas it would be quite natural for PPP). 4. As I suggested in another recent message, the padding option should be defined uniformly for all network layer protocols. The "OSI" case is an example of needing the option to define different padding for individual SDUs and/or segments since CLNP and ES-IS and perhaps others are all carried on the same protocol ID or VC. The NCP negotiation could simply specify that a single octet which defines the number of pad bits is included (for each direction separately) at the start of ALL segments. A value of 8 would indicate two pad octets (including the one that holds this value). A value of 24 would indicate 4 (which could more efficiently have been defined as zero if the variable length pad octet was not always included, but them's the breaks... this inefficiency could be avoided by giving a separate protocol ID and negotiating a separate fixed padding for each individual network layer protocol). 5. Most of the document is devoted to explaining the contortions that may be needed to set holding time paramaters properly to take into account the fact that connectionless protocols are being used over a link with a much higher error rate than they may be normally configured for. All of that could be eliminated (and CONS supported) by simply using LAP B instead of PPP. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 18 02:50:11 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05017; Thu, 18 Jun 92 02:44:41 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25074; Thu, 18 Jun 92 02:29:46 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04512; Thu, 18 Jun 92 02:20:07 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04378; Thu, 18 Jun 92 02:14:47 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA07260; Thu, 18 Jun 92 02:13:45 -0700 Date: Thu, 18 Jun 92 04:01:42 EDT From: "William Allen Simpson" Message-Id: <441.bsimpson@angband.stanford.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: Data(gram) Compression > >> Put it to a vote. Turf the pad is mine. > > Maybe Bill will liberate me on this one. My understanding of RFC 1331 > section 3.1 leads me to believe that, although that is the best > solution, it is the one I'm not allowed to choose. > > Fred > Sorry Fred. Padding is required. Anybody with 16-bit or 32-bit only DMA transfers has to have it. And as I learned from ISO over PPP, there's a lot of those out there. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 18 03:00:48 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05238; Thu, 18 Jun 92 02:56:53 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25078; Thu, 18 Jun 92 02:33:51 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04516; Thu, 18 Jun 92 02:20:11 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04444; Thu, 18 Jun 92 02:15:10 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA07263; Thu, 18 Jun 92 02:13:53 -0700 Date: Thu, 18 Jun 92 04:10:50 EDT From: "William Allen Simpson" Message-Id: <442.bsimpson@angband.stanford.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: the mib > Date: Sat, 13 Jun 92 05:16:12 EST > From: cmf851@cscgpo.anu.edu.au (Albert Langer) > > Ok, I've just been lurking quietly and trying to catch up on the > mailing list archives before speaking up, but I guess it's > "Speak now or forever hold your peace" time on the MIB. > This is wonderful! A person who actually read the archives! I've been advocating this for a long time for new users. (Personally, I read the archives, and watched the group for a month before I made my first comment to the list.) The MIB comments will presumably be addressed by Frank. I will confine myself to the PPP historical design elements of the discussion. > For bit oriented "synchronous" serial ports the functions of framing, > transparency and CRC calculation are normally built into the USRT anyway. > For octet oriented start-stop or "async" UARTs the ONLY efficient > implementation is to do ALL character processing for framing, transparency > and CRC calculation together in the serial port driver when the CPU accesses > each incoming or outgoing character, so that higher sub-layers need only > Actually, in a time profile that I conducted, doing this for async left the interrupts off for too long. Using a software FIFO, and doing the framing/escaping in a higher level task in larger chunks actually improved overall system throughput considerably. > a) PPP specifies that "DEL" is not a control character included in the > control character transparency mode, whereas ISO 3309 specifies that it > is (with either parity bit). This seems to be a simple mistake (pointed > out by Markus Kuhn), or perhaps arising from some earlier version of > ISO 3309. Can it be simply corrected? > It is much too late to change. It was a deliberate design choice. Can you give an example (in post-paper-tape experience) of the loss of DEL on 8-bit lines? > b) Recent amendments to ISO 3309 provide for a 7 bit transparency mode > which converts 8 septet characters (ignoring parity bits) to 7 octets > and vice versa. This may be of little interest to PPP but it may be > handy for dialup users or login ports with only 7 bit paths. It requires > very little effort to implement (by simply recognizing the use of that > mode at the start of a call). Can this be added to the MAC spec? > No. The use of 8-bit data was one of the early design decisions for PPP. If, as you say, the use of the mode has to be recognized at the start of the call, this would be contrary to the design philosophy of PPP. > c) ISO 3309 assumes only the "basic" transparency mode in which only > the control-escape and flag characters (with either parity bit) are escaped. > Anything else is by prior agreement. > ... > Would it be possible to make "flow control transparency" the default > for PPP and so also for a MAC sublayer common to PPP and LAP B? > No. There is no need for escaping "either parity bit", since the data is 8-bit there is no parity bit. And your request for "flow control transparency" conflicts with your request for strict 3309 addendum compliance. Again, the need for prior agreement is contrary to the PPP design philosophy. > Can anyone provide examples of situations where the RECEIVER needs > control characters other than XON/XOFF to be escaped and this > needs to be a universal default rather than private bilateral agreement > with the sender? > Modems for HP terminals: ENQ/ACK; UNIX login prompt: EOT, NAK, CR, LF, etc. Again, the need for prior agreement is contrary to the PPP design philosophy. The "private bilateral agreement" is the LCP negotiation. > a) A reliable "up/down" protocol is required for incoming calls to ensure > the higher sublayer is aware when the phone line hangs up and that the > phone line does hang up when told to by the higher sublayer. This is > at least a three way handshake with timeouts.... > It's already in the FSM. The other points you have about design of terminal servers and routing of multiprotocol packets are well taken, but are not applicable to PPP as a link layer protocol. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 18 04:50:08 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07321; Thu, 18 Jun 92 04:49:29 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25279; Thu, 18 Jun 92 04:19:40 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06689; Thu, 18 Jun 92 04:10:13 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from anu.anu.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06587; Thu, 18 Jun 92 04:05:09 -0700 Received: from cscgpo.anu.edu.au by anu.anu.edu.au (4.1/SMI-4.1) id AA27732; Thu, 18 Jun 92 21:04:08 EST Received: from huxley.anu.edu.au by cscgpo.anu.edu.au (4.1/SMI-4.1) id AA12098; Thu, 18 Jun 92 21:04:06 EST From: cmf851@cscgpo.anu.edu.au (Albert Langer) Message-Id: <9206181104.AA12098@cscgpo.anu.edu.au> Subject: Re: compress To: fbaker@acc.com (Fred Baker) Date: Thu, 18 Jun 92 21:04:04 EST Cc: cmf851@cscgpo.anu.edu.au, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <9206161615.AA00716@saffron.acc.com>; from "Fred Baker" at Jun 17, 92 09:15:55 am X-Mailer: ELM [version 2.4dev PL32] > > >> 1. Should not be called "Datagram Compression" since in fact it > >> doesn't work with datagrams but only with error corrected > >> connection. > > OK, global replace "Datagram" with "Data". There are some things I'm > real easy on. :^) Fine. > I'm not sure I agree with your analysis here. When you said > "increasing throughput reduces delay" is a fallacy, I was expecting you > to point out that compression and decompression take time, and passing > compressed data only reduces delay if the total time from "packet in > the clear" to "packet in the clear" is less, which is a function of > processor performance as well as line speed. Sorry to disappoint you. As it happens I find the concern about "performance" and measures like padding to enhance it somewhat perplexing - perhaps because I have no experience with T1 links and my interest in this whole area relates to dialup PC access typically at 9600 bps with likely potential migration to 16Kbs D channel and 64Kbs B channel ISDN. My instinct is that if you can't keep up with the line speed you either don't need that line speed or you need faster hardware. At the speeds I am interested in, both LAP B (or more precisely LAP M for modems - derivative of LAP D) and V42bis compression are commonly implemented within modems - often with only an 8 bit processor available. There should not be much problem implementing them in multi-protocol routers and keeping up with line speed. Latency added by compression is negligible because the first bits of decompressed data can be delivered immediately after the first bits of compressed data are received - even if the CPU processing took LONGER than transmission that would only be a delay comparable to the size of the compressed tokens - say 9 bits for V.42bis or 16 bits for larger LZW tables. The problem you mention would result ONLY from your proposal to determine the compressed length before starting transmission, which is easily corrected. (Subject of course to being able to retrospectively abort a frame that turns out to have a bad CRC after it has been decompressed.) > But you seem to be arguing that carving packets up into peices 1/30 the > size will reduce delay. If I have a 1024 TCP segment , and > send it instead as 32 32 byte segments, I have added at least 31*20 > octets (that's fragmentation; 31*40 if TCP does it), disregarding line > overhead, to the data stream. *That* doesn't sound much like it will > reduce delay. > > I'll yield the point that we're only affecting throughtput rate induced > delays. David Carr has explained this point. Note also that segmentation to 32 octet segments would add ONLY the "line overhead" which you are willing to "disregard". ABSENCE of segmentation could require fragmentation with the 31*20 octets wasted throughput you mention. > LAPB has no "more" bit. You're thinking X.25. I was proposing LAP B PLUS a "More" bit, which is made POSSIBLE by using LAP B - you can't simply add a "More" bit to PPP. Actually I was thinking of the "Minimal Network Layer" defined in T.70. This uses one octet for a TR 9577 Network Protocol ID and a second octet to carry just an "M"(ore) and "Q" bit. I have been advocating it as a way to avoid the unnecessary complexity of X.25 for connecting a dialup PC to OSI MHS etc where multiplexing and addressing/routing is not an essential requirement. With header compression the M and Q bits could simply be added to the address octet (and the Q bit could be used for high priority traffic, though I don't recommend it). This would be sufficient to implement the transit priority bit of IP WITHOUT X.25 and using ONLY the two octet header required by LAP B anyway. Although addressing/routing is also not an essential requirement for multi-protocol routers (so you don't need X.25 addresses or extended addresses), multiplexed "Virtual Circuits" are clearly essential for multi-protocol routers. A minimal version of X.25 can provide that plus flow control and NOTHING MORE. (Use the alternate logical references procedure to assign VC numbers so there is no need to register highest and lowest incoming and outgoing and two way VC channel number ranges and no need for registration packets at all. Then X.25 PLP is just a means of multiplexing VCs with flow control and uses LESS packet types and LESS states than PPP.) The ONLY extra that comes with even a minimal X.25 is that you get flow control whether you want it or not. However I don't see that as a disadvantage. It may just be my ignorance of multi-protocol routers, but it strikes me that separate flow control for each protocol would be highly DESIRABLE. > In point of fact, links generally run error-free. A couple of orders > of magnitude worse than 10^-9 is only 10^-7, and frankly, that's a > pretty pessimistic estimate as well. We don't see a single bit error > every three minutes (10^7/56000) on ANYTHING. We see total outages > once in a blue moon that average together to 10^-9 or 10^-7 BERs, but > when the link's up, it generally runs dead clean. Ok, I gather from another message that you are mainly thinking in terms of T1 and DS1 type links and are presumably supporting LAP B in that context because even a much LESS frequent reset rate than once every 3 minutes would be unpleasant if it required re-synchronizing compression tables. PPP is intended for use on low and moderate speed serial lines with non-error correcting modems as well. The corresponding error rates ARE worse than 10^7 and this DOES affect performance both for "connectionless" management protocols configured to expect LAN error rates and for the large majority of applications that use connection oriented transport protocols. The default should therefore be LAP B. If certain links such as T1 and DS1 and ISDN and error correcting modems (with proper UART flow control configuration) do not NEED error correction, it still does them no harm. A XID option could allow negotiation of UI instead of LAP B I frames and/or omit CRC FCS. (I advocate that for laptops and MSDOS desktops with severe RAM limitations that happen to have error correcting modems, but I can't see the relevance to multi-protocol routers with T1 links - why should they CARE about the code and buffers required to implement LAP B? If the line is error free, that is even LESS reason to care, since LESS processing is involved.) > The only effect LAPB has on the link is to occasionally close the > window in one direction, as a large packet going one way effectively > withholds acknowledgement of a stream of small packets going the other > way. This of course is a STRONG argument for the "More" bit so you won't HAVE such large packets going one way. (A partial but insufficient alternative is to use the optional extended mode with modulo 128 frame numbers. This does not need LCP or even XID negotiation since rejection of SABME can just be followed by SABM.) Incidentally a package called ABMDEMO.EXE (or .ZIP) is available which displays animation of Asynchronous Balanced Mode HDLC (i.e. LAP B) with various error rates and packet sizes etc. Anyone interested in visualizing how it works out in practice can ftp from: faui43:portal/doc/ISO/english/ The same directory also has an unfinished prototype of LAP B plus X.25 PLP for MSDOS with source code called OSIRIS. LAP B and X25 freely available source code is also included in the BSD networking release and many versions of LAP B are included with AX.25 packet radio software. > In the event of an error, sometimes you get an REJ which restarts the > data stream, but you get T1 timeouts about as frequently. The duration > of a T1 timeout (at least three times the maximum packet size divided > by the bit rate, to avoid spurious timeouts) is often comparable to > TCP's SRTT. This can ONLY be true when TCP is used over a single hop. > Well, this is an issue that was discussed before I joined the working > group, and *that* was a long time ago. I think, in view of my comments > on LAPB above, one might as easily ask "why do so?" 1. Simplifies protocol design (no LQP, simple VC CONNECT instead of complex PPP NCPs that are still likely to result in ambiguity and flapping). 2. Improved efficiency for most applications (i.e. connection oriented transport service). 3. Simplified configuration of "connectionless" management protocols that expect lower LAN error rates. 4. Greatly improved latency for interactive applications that need priority for transit delay QOS together with other applications that use long packets. 5. Supports connection oriented network layers. 6. Complies with GOSIP WAN requirements. 7. Required software is mature, well established, internationally standardized and will be included in most multi-protocol routers anyway. 8. Fully supports connectionless network layers, including non-segmenting subsets and IP transit delay priority bit. Last and perhaps least :-) 9. Supports compression and encryption. So "why not"? > I am suggesting it for cases where it is useful, not as the general > practice. I don't think it's a good practice unless there's a good > reason. If being better, faster, simpler, more flexible and able to leap wide Internets in multiple bounds is not a good enough reason, what would be? > >> 6. Also, once you have LAP B, adding the rest of X.25 (the Packet > >> Layer Protocol - PLP) is relatively simple. > > Once again, my company has, um, heard of that protocol before. The > question might best be phrased "yes, but who would want to?" Have you > noticed that it's the X.25 vendors who are pushing Frame Relay, and > that FR is explicitly un-X.25 like? My understanding is that the big difference lies in Frame Relay relying on a low error rate physical layer instead of providing LAP B style error correction at the data link layer. I can't see any big difference at the packet layer at all, which is indeed probably why X.25 vendors are interested. The difference is in LAP B, not the PLP and my statement quoted above was very explicitly qualified by "once you have LAP B". Both FR and X.25 PLP provide multiplexed Virtual Circuits which are easy to open and close. The difference in header format with Frame Relay providing more flexible channel numbering and less flow control seems trivial to me. It could be included under the topic of "header compression" for X25 to ALSO use only one octet for channel numbers instead of 12 bits when less than 128 channels are in use. If you REALLY want less flow control I guess that could be deleted from X.25 as well, but it seems a strange desire in a multi-protocol routing context. > I'll take votes here. I did it with a "length of pad" in RFC 1220 and > caught flack. I'm doing it with a "length of data" here, and yes, two > octets seems a tad excessive. I could invent yet a third way, with a > self defining pad at the end, but now every packet *must* be padded. > PPP is far more usually unpadded. We seem to be at cross purposes here. I assumed the length of data was specified because V.42bis compression data is a bit string that may not necessarily end on an octet boundary. Although the sync HDLC framing would not mind that, it might be necessary to specify how many bits of the last octet were spare so that the async version would not mistake the spare bits for an additional compression table token. I gather now that you had something else in mind, though I don't understand how specifying a "length of data" can help with padding to 16 or 32 bit boundaries. As far as I can see, only a "length of pad" field can do that. > >> More important this allows for "streaming" with the frame being > >> output before it's final length is known. This is an important > >> feature of the V.42 design, to improve latency for interactive > >> applications, and I imagine it would be included in V.42 bis as > >> well. Incidentally, why not do it EXACTLY according to V.42bis > >> when a sync serial port is available, and a close equivalent for > >> async? (LAP M is based on LAP D, which is pretty similar to LAP B > >> with multiple LSAP addresses instead of just A and B). > > Well, to become *exact*, I have to change PPP in two ways. I have to > eliminate the possibility of the pad, and I have to make compressed LCP > packets the default. Ok, forget the EXACT V.42bis idea. But please don't ignore the previous sentence about "streaming". Given a design goal to improve latency, requiring that the length of the compressed packet be known before transmission starts seems an odd way to go about it. > >> 11. Any response re separating out the MAC sublayer etc? > > I'm not trying to make something protocol specific here. That (one) item was not referring to your message but to my previous message responding to the "last call" on PPP MIB by suggesting that the MAC layer be separated out and also corrections for DEL as a control character etc. I got a copy echoed from the list server so I guess it must have been distributed although there has been no response at all (unlike my second message :-) If anyone didn't see it, please email for a copy. Surely I should at least get a response on the DEL correction? From ietf-ppp-request@aggie.ucdavis.edu Thu Jun 18 09:11:43 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14241; Thu, 18 Jun 92 09:07:36 -0700 Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA27280; Thu, 18 Jun 92 08:43:56 -0700 Sender: ietf-ppp-request@aggie.ucdavis.edu Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA27131; Thu, 18 Jun 92 08:30:57 -0700 From: ccskiz@aggie.ucdavis.edu (Elizabeth St. Goar) Date: Thu, 18 Jun 92 08:30:57 -0700 Message-Id: <9206181530.AA27131@aggie.ucdavis.edu> To: ietf-ppp@aggie.ucdavis.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA26135; Thu, 18 Jun 92 06:41:17 -0700 Received: from hobbit.gandalf.ca by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09985; Thu, 18 Jun 92 06:38:38 -0700 Received: from donut.gandalf.ca.adg.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA24900; Thu, 18 Jun 92 09:37:42 EDT Received: by donut.gandalf.ca.adg.gandalf.ca (4.1/SMI-4.1) id AA13798; Thu, 18 Jun 92 09:37:40 EDT From: dcarr@donut.gandalf.ca (Dave Carr) Message-Id: <9206181337.AA13798@donut.gandalf.ca.adg.gandalf.ca> Subject: PADDING To: ietf-ppp-request@ucdavis.ucdavis.edu Date: Thu, 18 Jun 92 9:37:38 EDT X-Mailer: ELM [version 2.3 PL11] >>> Put it to a vote. Turf the pad is mine. >> >> Maybe Bill will liberate me on this one. My understanding of RFC 1331 >> section 3.1 leads me to believe that, although that is the best >> solution, it is the one I'm not allowed to choose. >> >> Fred >> >Sorry Fred. Padding is required. Anybody with 16-bit or 32-bit only >DMA transfers has to have it. And as I learned from ISO over PPP, >there's a lot of those out there. > >Bill_Simpson@um.cc.umich.edu > bsimpson@ray.lloyd.com How about at least negotiating this at link setup using XID at least. Adding up to 3 bytes of padding to a compressed frame, plus at least 3 bits of padding length information is definitely not my idea of compression. Let those people who wish to implement PADDED V42.bis compression have a separate number, and stop penalizing me please! It's not my fault they didn't have the foresight to pick the right serial link controller or DMA. -- Dave Carr | dcarr@gandalf.ca | It's what you learn, Principal Designer | TEL (613) 723-6500 | after you know it all, Gandalf Data Limited | FAX (613) 226-1717 | that counts. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 18 09:45:47 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14716; Thu, 18 Jun 92 09:22:29 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27448; Thu, 18 Jun 92 08:59:47 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13765; Thu, 18 Jun 92 08:51:02 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13583; Thu, 18 Jun 92 08:45:47 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA01000; Thu, 18 Jun 92 08:44:38 PDT Date: Thu, 18 Jun 92 08:44:38 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9206181544.AA01000@ray.lloyd.com> To: cmf851@cscgpo.anu.edu.au Cc: vjs@rhyolite.wpd.sgi.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Albert Langer's message of Thu, 18 Jun 92 15:17:25 EST <9206180517.AA09976@cscgpo.anu.edu.au> Subject: compress Sender: ietf-ppp-request@ucdavis.edu From: cmf851@cscgpo.anu.edu.au (Albert Langer) Date: Thu, 18 Jun 92 15:17:25 EST X-Mailer: ELM [version 2.4dev PL32] The problem isn't "continual additions of features" - that is a CONSEQUENCE of something wrong in the basic design that is making it NECESSARY to add "features" in support of particular requirements. The addition of features is a means to support local optimization for some reason. No one needs to add the new features to be interoperable. Therefore it is not "necessary" to add the features, only desirable in some cases. For example a Link Quality Monitoring protocol is needed BECAUSE the basic design decision not to correct errors leaves each side not knowing which of the packets it transmitted were bad. Not so. We are not interested in whether or not a single d'gram made it to the other side, we are only interested statisticly how badly the link is losing. Better to ask periodically that to send an "I got it" message for every bloody packet that goes across the link. LAPB could certainly perform this function as a side effect of providing "error-free" transmission but that is like using dynamite to drive a nail. A separate VC establishment protocol is needed for EVERY damn protocol BECAUSE of the basic design decision to think in terms of "protocol IDs" rather than Virtual Circuits and not to use the well established and much simpler means already standardized for setting up and tearing down VCs over a connection oriented data link layer. A LAP B "option" is needed to support compression (and encryption) and in my opinion also to support transit delay priorities, BECAUSE of the original "connectionless" mistake. Now you are into the realm of religion. Even the ISO recognizes the need for connectionless network layers or we wouldn't have CLNS. The intrest in compression stems from a desire to optimize low-speed links. We already have what we need in async modems (V.42bis) and now some of the router vendors are trying to accomplish the same thing with low-speed (<64Kbps) sync links. We are talking about special case optimization that no-one is reqired to use. That mistake arises from transplanting the experience with connectionless data link layer and subnetwork and network protocols on high bandwidth, low error rate LANs and applying it blindly to the completely different environment of WANs - ignoring the IMMENSE amount of experience that has been accumulated with "point-to-point" protocols on serial lines over DECADES. Isn't that just as big a mistake as blindly applying "connection oriented" WAN experience to the LAN environment? Well, the telcos in the US would take exception with you over your implication that WAN links suffer from high error-rates. Certainly I get as many or more errors on my Ethernet (collisions mostly) than I get on my 56K link. Therefore by your own argument I should be running some sort of CONS over my Ethernet. Absurd! It isn't a problem of "all design choices answered 'yes'", but of a mistaken attempt to invent a new "point-to-point" PROTOCOL (as opposed to paramaters and header padding and/or compression techniques) in the first place. PPP is well established. It is not going to go away now. Responsibility for saying "No" to STANDARDIZING such mistakes lies with the standards authority - i.e. the IAB I presume. It should be able to say "NO" to a "proposed" protocol for exactly the same reasons that designers of a protocol should be able to say "NO" to a new feature. There is a big difference between PPP and other protocols: you can do a minimal implementation of PPP and still be interoperable. cisco has, up to now, provided only the minimum set of features to interoperate with PPP. Morning Star has darn near every option in PPP. They interoperate very well. Therefore the ability to add a feature/option to meet some perceived need without breaking previous implementations is a win not seen in other protocols. SOMEBODY has to take the decision "do we need another protocol for point- to-point serial links" and it can't be those who designed it. (Nor of course should it be those who favour the existing internationally standardized protocols for serial point-to-point links. Whoever takes the decision should independently consider arguments from both sides.) The decision has been made. It was made by the IETF in seeking a new protocol, it has been approved by the IESG and IAB (I refer you to RFCs 1134, 1171, 1172, 1331, 1332, 1333, and soon 1334), it has been adopted by the vendors, and fielded by the users. At BARRNet almost all new links run PPP and we are removing all the routers that do not support PPP in large part BECAUSE they do not support PPP. We do not use X.25 or Frame Relay because the telcos don't provide the services (in most of the world "X.25 service" is an oxymoron). Telcos all over the world understand switched and dedicated circuits so PPP is VERY useful. Sorry, but that is a fact of life. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 18 10:12:47 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16105; Thu, 18 Jun 92 10:06:18 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27874; Thu, 18 Jun 92 09:30:22 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14696; Thu, 18 Jun 92 09:21:38 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from OPAL.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14591; Thu, 18 Jun 92 09:17:58 -0700 Received: by opal.acc.com (4.1/SMI-4.0) id AA24089; Thu, 18 Jun 92 09:18:19 PDT Date: Thu, 18 Jun 92 09:18:19 PDT From: art@opal.acc.com (Art Berggreen) Message-Id: <9206181618.AA24089@opal.acc.com> To: cmf851@cscgpo.anu.edu.au, fbaker@opal.acc.com Subject: Re: compress Cc: ietf-ppp@ucdavis.ucdavis.edu > . > . >I was proposing LAP B PLUS a "More" bit, which is made POSSIBLE by >using LAP B - you can't simply add a "More" bit to PPP. > . > . What I see, is a lot of discussion about potential ideas for a new serial interconnect, which have little to do with PPP. It's much too late to make changes of that scope. If a group wants to get together, set up a separate list and spend the next couple of years trying to reach consensus and getting the vendors to implement a new interface spec, go ahead. But PPP must continue from its current architecture if it is going to get used in the real world. (I'm not overly fond of PPP, but I'm less fond of protocols which keep evolving and are never stable enough for use) > . > . >Ok, I gather from another message that you are mainly thinking in >terms of T1 and DS1 type links and are presumably supporting LAP B >in that context because even a much LESS frequent reset rate than >once every 3 minutes would be unpleasant if it required re-synchronizing >compression tables. > >PPP is intended for use on low and moderate speed serial lines >with non-error correcting modems as well. The corresponding error >rates ARE worse than 10^7 and this DOES affect performance both >for "connectionless" management protocols configured to expect >LAN error rates and for the large majority of applications that >use connection oriented transport protocols. > . > . It's clear to me that there are two distinct communities using PPP. There is the asynch, dial-up, SLIP replacement PPP and the synch, high speed, dedicated channel PPP. Our perspective is focussed mostly on the later. Art From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 18 10:56:24 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17054; Thu, 18 Jun 92 10:35:07 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27120; Thu, 18 Jun 92 08:29:55 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12865; Thu, 18 Jun 92 08:23:20 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12477; Thu, 18 Jun 92 08:10:34 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA00889; Thu, 18 Jun 92 08:09:29 PDT Date: Thu, 18 Jun 92 08:09:29 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9206181509.AA00889@ray.lloyd.com> To: cmf851@cscgpo.anu.edu.au Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Albert Langer's message of Thu, 18 Jun 92 15:17:25 EST <9206180517.AA09976@cscgpo.anu.edu.au> Subject: compress One thing that was eminently clear at the IPLPDN WG at the last IETF was that the IPLPDN folk are seeking precisely what we have created with the varied NCPs. It would require very little work to run our authentication, LQM, and varied NCPs over other packet switched network layer protocols instead of over LCP atop point-to-point or circuit switched media. Sounds awfully interesting to me. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 18 12:01:25 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19704; Thu, 18 Jun 92 11:56:14 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA28726; Thu, 18 Jun 92 10:41:52 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17024; Thu, 18 Jun 92 10:34:18 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from hobbit.gandalf.ca by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16781; Thu, 18 Jun 92 10:29:07 -0700 Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA17459; Thu, 18 Jun 92 13:28:08 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA19498; Thu, 18 Jun 92 13:28:04 EDT Date: Thu, 18 Jun 92 13:28:04 EDT From: mm@gandalf.ca (Mississippi Mud) Message-Id: <9206181728.AA19498@cannibal.gandalf.ca> To: dcarr@donut.gandalf.ca, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: PADDING >How about at least negotiating this at link setup using XID at least. >Adding up to 3 bytes of padding to a compressed frame, plus at least >3 bits of padding length information is definitely not my idea of >compression. How it's negotiated is not at issue. The LCP and the compression NCP should suffice. Sorry I can't resist: we need compression length field compression (negotiating away the length field if padding is not required by either side). It does complicate negotiation somewhat, and I'm not sure it's worth it, since all we're talking about is a single byte, if we change to a pad length. That would be my vote. -Chris Sullivan Gandalf Data Ltd. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 18 13:53:48 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22891; Thu, 18 Jun 92 13:39:59 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01153; Thu, 18 Jun 92 12:09:55 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19895; Thu, 18 Jun 92 12:01:09 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19769; Thu, 18 Jun 92 11:58:49 -0700 Received: by europa.clearpoint.com (4.1/1.34) id AA00826; Thu, 18 Jun 92 14:49:52 EDT Date: Thu, 18 Jun 92 14:49:52 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9206181849.AA00826@europa.clearpoint.com> To: cmf851@cscgpo.anu.edu.au Subject: Re: the mib In-Reply-To: Mail from 'cmf851@cscgpo.anu.edu.au (Albert Langer)' dated: Sat, 13 Jun 92 05:16:12 EST Cc: ietf-ppp@ucdavis.ucdavis.edu Albert, Bill Simpson seemed to address the protocol specific issues. As far as the MIB goes, we are obligated to make the MIB reflect what the protocol IS, not what it ought to be. So, if some of your thoughts find their way into the protocol at some point in time, the MIB would be changed accordingly. I realize that some alignment may be needed between the PPP mib and the RS-232 MIB, that a modem MIB may be interesting and so on. I had hoped that Bob Stewart and I could work out the alignment issues between our MIBs when the RS-232 MIB goes up for Draft Standard. It is important that the "base" PPP mib be finished up soon though. I think that all of your other points were more along the lines of PPP Protocol issues. Frank From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 18 16:51:40 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28747; Thu, 18 Jun 92 16:40:45 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04059; Thu, 18 Jun 92 15:30:15 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26104; Thu, 18 Jun 92 15:21:46 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from signet3.signet.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25956; Thu, 18 Jun 92 15:16:02 -0700 Received: from sigmadsk2.signet.com by signet.com (4.1/SMI-4.1) id AA29343; Thu, 18 Jun 92 17:30:52 EDT Date: Thu, 18 Jun 92 17:30:52 EDT From: ken@signet.com (Kenneth Virgile) Message-Id: <9206182130.AA29343@signet.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: PPP MIB Comments Concerning the PPP MIB: MIB-II allows for both "ppp" and physical (e.g. "ds3") values for ifType. It's not clear from MIB-II if its designers intended for multiple ifEntrys per interface, or if the designers intended for just one ifEntry and intended the Agent to select just one from the possible options. In any event, NMS vendors (and SNMP agents as well) have for the most part implemented a one-to-one relationship between ifEntry and physical interface. Question: Should the PPP MIB be changed so that pppLinkStatusIndex is allowed to contain zero? [A value of zero would indicate that there is no corresponding "ppp" ifEntry. Also, the wording of related PPP MIB variables would have to be changed to allow zero.] My opinion is: CHANGE THE MIB!!! The information that might be lost is of little concern, yet by changing the MIB, the number of vendors (both NMSes and Agents) who implement the MIB would increase enormously. In addition, those Agents who implement the MIB would remain compatible with existing NMSes. Ken V. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 18 17:30:51 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00217; Thu, 18 Jun 92 17:25:44 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA00142; Mon, 15 Jun 92 15:00:14 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25143; Mon, 15 Jun 92 14:55:13 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24861; Mon, 15 Jun 92 14:47:46 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA22746; Mon, 15 Jun 92 14:46:21 PDT Date: Mon, 15 Jun 92 14:46:21 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9206152146.AA22746@saffron.acc.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: lapb Sentient Beings: The following document is for your edification and comment, and for discussion in the PPP Working Group meeting in Boston. ==================================================================== ^L Network Working Group F Baker Internet Draft Troublemaker June 1992 PPP LAPB Numbered Mode Status of this Memo This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list. Distribution of this memo is unlimited. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol. This document defines a protocol for negotiating and using LAPB, as defined by ISO 7776, to provide a reliable serial link. Baker [Page i] Internet Draft PPP LAPB Numbered Mode June 1992 1. Introduction PPP has three main components: 1. A method for encapsulating datagrams over serial links. 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 describes an option of the Link Control Protocol to negotiate the use of LAPB Numbered Mode. This facility is optional. Baker [Page 1] Internet Draft PPP LAPB Numbered Mode June 1992 2. Reliable Link Support 2.1. Design Motivation Generally, serial link reliability is not a major issue. The architecture of protocols used in datagram networking presume best effort non-sequential delivery. However, in certain circumstances, it is advisable to provide a reliable link, at least for a subset of the messages. The most obvious case is when the link is compressed. Since the dictionary is recovered from the compressed data stream, and a lost datagram corrupts the dictionary, datagrams may not be lost. Another case is where multiple parallel links are used to emulate a single link of higher speed. In this case, Bridged traffic, Source Routed traffic, and traffic subjected to Van Jacobsen compression must be delivered to the higher layer in a certain sequence. However, the fact of the links being relatively asynchronous makes traffic reordering certain. The ISO 7776 Multi-Link Protocol can be used to restore order. Baker [Page 2] Internet Draft PPP LAPB Numbered Mode June 1992 2.2. Configuration Option Format Description The LAPB Numbered Mode Configuration Option of the Link Control Protocol negotiates the use or abuse of LAPB on the link. By default or ultimate disagreement, Unnumbered Mode is used. The use of unnumbered (UI) messages remains optional during the LAPB session. A summary of the LAPB Numbered Mode Configuration Option format to negotiate datagram encryption is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Window | Address... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length at least 4 Window A value between 1 and 127. This indicates the number of frames the receiver will buffer for, and therefore the maximum number that the sender should send without receiving an acknowledgement. If window < 8, then modulo 8 sequencing is used on the link. Otherwise, modulo 128 sequencing is used. It is conceivable and legal that differing window values might be announced and used. However, LAPB does not permit one system to use modulo 8 sequencing and the other to use modulo 128. Therefore, the rule is: A NAK may reduce the window but may not increase it. Address An HDLC Address as specified in ISO 3309. ISO 7776 specifies four of the possible values: 1 and 3 for single link LAPB, 7 and 15 for the Multi-Link Procedure. Other values consistent with ISO 3309 Baker [Page 3] Internet Draft PPP LAPB Numbered Mode June 1992 are considered legal. Implementation of the MultiLink procedure is optional; A NAK may therefore force a change from MLP to single link mode, but not the reverse. If Multilink is configured, the peers should use the same Magic Number on all of the links interconnecting them. Should the address be zero upon receipt, the receiver MUST NAK with an appropriate address. If both peers send the address 00, then the system with the numerically smaller Magic Number will select the link addresses. Baker [Page 4] Internet Draft PPP LAPB Numbered Mode June 1992 2.3. Packet Format Standard PPP uses an ISO 3309 Address of 0xFF (Broadcast) and a control field of 0x03 (UI). While LAPB is operational, the use of these values remains legal. However, the Address Field of the frame may also take the value announced in the configuration option, and the control field may take any value valid in ISO 7776. The fields are transmitted from left to right. Therefore, the following packet formats are valid under LAPB mode: Standard UI Broadcast Messages: +----------+----------+----------+----------+------------ | Flag | Address | Control | Protocol | Information | 01111110 | 11111111 | 00000011 | 16 bits | * +----------+----------+----------+----------+------------ ---+----------+----------+----------------- | FCS | Flag | Inter-frame Fill | 16 bits | 01111110 | or next Address ---+----------+----------+----------------- LAPB +----------+----------+----------+----------+------------ | Flag | Address | Control | Protocol | Information | 01111110 |1-2 octets|1-2 octets| 16 bits | * +----------+----------+----------+----------+------------ ---+----------+----------+----------------- | FCS | Flag | Inter-frame Fill | 16 bits | 01111110 | or next Address ---+----------+----------+----------------- Multi-Link Procedure +----------+----------+----------+----------+ | Flag | Address | Control | MLC Field| | 01111110 |1-2 octets|1-2 octets| 16 bits | +----------+----------+----------+----------+ +----------+----------+-- | Protocol | Information | 16 bits | * +----------+----------+-- ---+----------+----------+----------------- | FCS | Flag | Inter-frame Fill | 16 bits | 01111110 | or next Address ---+----------+----------+----------------- Baker [Page 5] Internet Draft PPP LAPB Numbered Mode June 1992 2.4. SABM Exchange Correct startup of LAPB requires the use of a SABM or SABM(E), with a UA response. Following the successful negotiation of LAPB Numbered Mode, the system with the numerically smaller magic number will send a SABM, and the other will respond with a UA. In the event that either the SABM or UA is lost, this exchange may be repeated according to the same parameters as the configure exchange itself, both the timeout and the restart counter. Link Quality Determination and NCP Configuration follow this step. Baker [Page 6] Internet Draft PPP LAPB Numbered Mode June 1992 Security Considerations Security issues are not discussed in this memo. References [1] Simpson, W. A., RThe Point-to-Point ProtocolS, RFC in progress. [2] ISO 7776, Information Processing Systems - Data Communication - High Level Data Link Control Procedures - Description of the X.25 LAPB-Compatible DTE Data Link Procedures Acknowledgments Chair's Address The working group can be contacted via the current chair: Brian Lloyd Lloyd & Associates 3420 Sudbury Road Cameron Park, California 95682 Phone: (916) 676-1147 EMail: Brian@ray.lloyd.com Author's Address Questions about this memo can also be directed to: Fred Baker Advanced Computer Communications 315 Bollay Drive Santa Barbara, California 93117 EMail: fbaker@acc.com Baker [Page 7] Internet Draft PPP LAPB Numbered Mode June 1992 Table of Contents 1. Introduction .......................................... 1 2. Reliable Link Support ................................. 2 2.1 Design Motivation ............................... 2 2.2 Configuration Option Format ..................... 3 2.3 Packet Format ................................... 5 2.4 SABM Exchange ................................... 6 SECURITY CONSIDERATIONS ...................................... 7 REFERENCES ................................................... 7 ACKNOWLEDGEMENTS ............................................. 7 CHAIR'S ADDRESS .............................................. 7 AUTHOR'S ADDRESS ............................................. 7 Baker [Page ii] From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 18 17:52:11 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00947; Thu, 18 Jun 92 17:47:33 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05596; Thu, 18 Jun 92 17:14:02 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29539; Thu, 18 Jun 92 17:06:25 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29025; Thu, 18 Jun 92 16:50:31 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA08030; Thu, 18 Jun 92 16:49:27 -0700 Date: Thu, 18 Jun 92 18:02:31 EDT From: "William Allen Simpson" Message-Id: <446.bsimpson@angband.stanford.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: focus: appletalk & OSI Folks, it's time to get down to business, and get some of these protocols out the door. OSI/PPP has been languishing for 2 years, waiting for implementors. Now, I understand that we have at least one implementation. We should make a last call for comments (2 weeks), and ship it off to the IESG. Appletalk/PPP has been nearly ready for some time. I understand that we have at least one implementation. We should make a last call for comments (same 2 weeks as above), and ship it off to the IESG. After those two, we should deal with IPX and DECnet. That will bring us up to IETF Boston, where we can deal with design issues for the MIB (one last time) and LAPB. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 18 17:52:17 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00981; Thu, 18 Jun 92 17:48:53 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05556; Thu, 18 Jun 92 17:10:19 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29536; Thu, 18 Jun 92 17:06:17 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29023; Thu, 18 Jun 92 16:50:24 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA08027; Thu, 18 Jun 92 16:48:00 -0700 Date: Thu, 18 Jun 92 16:43:14 EDT From: "William Allen Simpson" Message-Id: <445.bsimpson@angband.stanford.edu> To: fbaker@acc.com (Fred Baker) Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: compress comments > The use of V.42bis compression requires the successful negotiation of > the LAPB Numbered Mode option. > Question: Is it possible that compression can always be used when LAPB Numbered mode is used? If that is the case, I think we should dispense with the compression option, and merely have the LAPB Numbered Mode option handle it. It is more difficult to have interdependent options negotiated simultaneuously. Question: When LAPB Numbered mode is used on the link, then we also must *not* do Address/Control field compression. This should probably also be mentioned. > Format of Information Field: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Protocol Identifier | Compressed Data Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Compressed Data... > +-+-+-+-+-+-+-+-+-+-+-+- > Looking at this format, and at Steve Senum's DECnet format, I see a similarity. Could you put the Data Length first? Then the Protocol Identifier could be compressed, too. > Compressed-Data-Length > > The length of Compressed-Data, in octets. Any octets following > are PPP pad as specified in RFC 1331 section 3.1, and should not > be decompressed. > I suggest that this be the length of the UN-compressed data, that is, the original data. That would allow the uncompressor to run without checking for padding, and then a simple assignment would fix the length. There was also a previous comment that the length of the compressed data might not end on a byte boundary, whereas the origianl data always would. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 18 18:20:38 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01420; Thu, 18 Jun 92 18:02:48 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05624; Thu, 18 Jun 92 17:17:39 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29542; Thu, 18 Jun 92 17:06:30 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29039; Thu, 18 Jun 92 16:50:55 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA08033; Thu, 18 Jun 92 16:49:36 -0700 Date: Thu, 18 Jun 92 18:30:25 EDT From: "William Allen Simpson" Message-Id: <447.bsimpson@angband.stanford.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: ppp-osi draft > 2. The "inactive subset" of CLNP can be quite useful for a workstation > or laptop that simply needs a connection to it's "host" system and not > to other addresses. MHS, Directory Service and the entire range of > "Distributed Office Applications Model" applications can be accessed > using TP4 over this essentially "null" network layer. Although I have > no doubt that accessing them over a connection oriented "Minimal Network > Layer" and TP0 or TP1 makes more sense (using LAP B plus a "More" bit), > some will prefer that route and I know Christian Huitema has been > advocating it. > The sub-group that was deputized by the chair to work out the details a couple of months ago seemed to be in favor of discouraging use of the null NLPID. We did discuss assigning a separate protocol number. How common a practice is this usage of the null NLPID? Can you name 3 vendors who currently do this? > 4. As I suggested in another recent message, the padding option > should be defined uniformly for all network layer protocols. The "OSI" > case is an example of needing the option to define different padding > for individual SDUs and/or segments since CLNP and ES-IS and perhaps This is completely unnecessary. PPP was designed with the Internet penchant for alignment on 32-bit boundaries. However, the alignment for all protocols can be altered by varying the header length. The sender is in control of the header length. Moreover, the design philosophy of PPP is that each network-layer protocol negotiate for it's particular needs. As explained in the draft, only OSI is likely to have an odd alignment. Therefore, special effort was expended to make it work better (without large amounts of data copying). It would be very easy to do the same for any other individual protocol that was determined to need the assistance. Finally, it was decided long ago that all of the OSI network protocols would be differentiated by the NLPID, rather than demultiplexing and remultiplexing them, assigning separate NCPs, etc. This allows future growth of the OSI suite, without future changes to the PPP suite. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 18 18:51:12 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02760; Thu, 18 Jun 92 18:45:12 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06152; Thu, 18 Jun 92 18:29:51 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01949; Thu, 18 Jun 92 18:20:23 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01717; Thu, 18 Jun 92 18:13:39 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA02307; Thu, 18 Jun 92 18:12:07 PDT Date: Thu, 18 Jun 92 18:12:07 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9206190112.AA02307@saffron.acc.com> To: bsimpson@angband.stanford.edu Subject: Re: compress comments Cc: ietf-ppp@ucdavis.ucdavis.edu >> > The use of V.42bis compression requires the successful negotiation of >> > the LAPB Numbered Mode option. >> Question: Is it possible that compression can always be used when LAPB >> Numbered mode is used? >> >> If that is the case, I think we should dispense with the compression option, >> and merely have the LAPB Numbered Mode option handle it. It is more >> difficult to have interdependent options negotiated simultaneuously. I have had questions from time to time about running multiple PPP links in parallel, which is fine for non-sequential data streams (IP, etc), but not for sequential ones (bridged traffic, VJ compressed traffic). Maybe we have a "LAPB and Compressed" option and a "LAPB MultiLink" option. (but what about compressed multilink?) I dunno, maybe I can be argued to your side in this case, as multilink is generally for low speed lines. But I am not of that opinion yet. >> > Format of Information Field: >> > >> > 0 1 2 3 >> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > | Protocol Identifier | Compressed Data Length | >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > | Compressed Data... >> > +-+-+-+-+-+-+-+-+-+-+-+- >> > >> Looking at this format, and at Steve Senum's DECnet format, I see a >> similarity. Could you put the Data Length first? Then the Protocol >> Identifier could be compressed, too. I thought PPP pretty much required the protocol identifier to be the two octets following the address and control field? I wonder if it's wise to propogate the way we distinguish between Ethernet and 802.3 traffic on a CSMA/CD LAN ("if packet type < 0x0600, it's a length") is something we really want to do? >> > Compressed-Data-Length >> > >> > The length of Compressed-Data, in octets. Any octets following >> > are PPP pad as specified in RFC 1331 section 3.1, and should not >> > be decompressed. >> > >> I suggest that this be the length of the UN-compressed data, that is, >> the original data. That would allow the uncompressor to run without >> checking for padding, and then a simple assignment would fix the length. >> There was also a previous comment that the length of the compressed data >> might not end on a byte boundary, whereas the origianl data always would. I can see that. Votes? Fred From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jun 18 21:01:55 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06492; Thu, 18 Jun 92 20:55:57 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06745; Thu, 18 Jun 92 20:39:44 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05958; Thu, 18 Jun 92 20:33:15 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05723; Thu, 18 Jun 92 20:27:31 -0700 Received: from remora.morningstar.com by volitans.morningstar.com (5.65a/92042102) id AA06938; Thu, 18 Jun 92 23:26:32 -0400 Received: by remora.morningstar.com (5.65a/91072901) id AA03626; Thu, 18 Jun 92 23:26:31 -0400 Date: Thu, 18 Jun 92 23:26:31 -0400 From: Karl Fox Message-Id: <9206190326.AA03626@remora.morningstar.com> To: Fred Baker Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: lapb References: <9206152146.AA22746@saffron.acc.com> Organization: Morning Star Technologies, Inc. Fred Baker writes: > Should the address be zero upon receipt, the receiver MUST NAK > with an appropriate address. If both peers send the address 00, > then the system with the numerically smaller Magic Number will > select the link addresses. I feel uneasy about making one option so dependent on the existence of another -- imagine trying to decide whether to Ack or Nak if the Numbered-Mode option comes before the Magic-Number option in the Configure-Request. I would much prefer adding another field (`random number') to the Numbered-Mode configuration option to serve as the coin toss. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 19 00:00:51 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10842; Thu, 18 Jun 92 23:53:52 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07286; Thu, 18 Jun 92 23:40:08 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10326; Thu, 18 Jun 92 23:30:22 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10172; Thu, 18 Jun 92 23:27:41 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA08226; Thu, 18 Jun 92 23:26:34 -0700 Date: Thu, 18 Jun 92 20:09:27 EDT From: "William Allen Simpson" Message-Id: <449.bsimpson@angband.stanford.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: PPP MIB Comments > MIB-II allows for both "ppp" and physical (e.g. "ds3") > values for ifType. It's not clear from MIB-II if its > designers intended for multiple ifEntrys per interface, > or if the designers intended for just one ifEntry and > intended the Agent to select just one from the possible > options. In any event, NMS vendors (and SNMP agents as > well) have for the most part implemented a one-to-one > relationship between ifEntry and physical interface. > > Question: > Should the PPP MIB be changed so that > pppLinkStatusIndex is allowed to contain zero? [A value > of zero would indicate that there is no corresponding > "ppp" ifEntry. Also, the wording of related PPP MIB > variables would have to be changed to allow zero.] > I disagree with this. The ifType description clearly says "physical/link protocol(s) immediately `below' the network layer in the protocol stack." If the DS3 is a bare physical layer immediately below, then ds3 would be used. When PPP is insinuated between the network and physical layers, ppp should be used. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 19 06:10:37 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17633; Fri, 19 Jun 92 06:06:29 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08270; Fri, 19 Jun 92 05:50:03 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16940; Fri, 19 Jun 92 05:41:01 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from anu.anu.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16901; Fri, 19 Jun 92 05:39:25 -0700 Received: from cscgpo.anu.edu.au by anu.anu.edu.au (4.1/SMI-4.1) id AA03035; Fri, 19 Jun 92 22:38:24 EST Received: from huxley.anu.edu.au by cscgpo.anu.edu.au (4.1/SMI-4.1) id AA22696; Fri, 19 Jun 92 22:38:22 EST From: cmf851@cscgpo.anu.edu.au (Albert Langer) Message-Id: <9206191238.AA22696@cscgpo.anu.edu.au> Subject: Re: lapb To: fbaker@acc.com (Fred Baker) Date: Fri, 19 Jun 92 22:38:20 EST Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <9206152146.AA22746@saffron.acc.com>; from "Fred Baker" at Jun 16, 92 02:46:21 pm X-Mailer: ELM [version 2.4dev PL32] > Internet Draft PPP LAPB Numbered Mode June 1992 > > > 2.3. Packet Format > > Standard PPP uses an ISO 3309 Address of 0xFF (Broadcast) and a > control field of 0x03 (UI). While LAPB is operational, the use of > these values remains legal. However, the Address Field of the frame > may also take the value announced in the configuration option, and > the control field may take any value valid in ISO 7776. The fields > are transmitted from left to right. It's unclear to me whether this is intended to permit or prohibit the use of header compression in non-LAPB mode. If prohibited, it should say so explicitly. If permitted, I suspect there would need to be reservation of single octet protocol IDs that have values 1, 3, 7 or 15 since these would appear to be LAPB frames rather than header compressed UI frames (control octet could take on almost any value). More complications if other address values also allowed. Is there any real value in allowing other LAPB addresses and even two octet addresses? Is there any real value in allowing UI mode simultaneously? (BTW, I haven't checked whether it is in the current version but I recall noticing some clumsy wording about having to use 0xFF, UI when in compressed mode if compression would be ambiguous as a result of the protocol ID being 0xFF and the first octet of data being equal to UI. Should simply reserve 0xFF instead, unless that has been done already.) From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 19 07:01:45 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18815; Fri, 19 Jun 92 06:55:25 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08414; Fri, 19 Jun 92 06:39:41 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18269; Fri, 19 Jun 92 06:32:30 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from anu.anu.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18056; Fri, 19 Jun 92 06:28:25 -0700 Received: from cscgpo.anu.edu.au by anu.anu.edu.au (4.1/SMI-4.1) id AA03133; Fri, 19 Jun 92 23:27:25 EST Received: from huxley.anu.edu.au by cscgpo.anu.edu.au (4.1/SMI-4.1) id AA22918; Fri, 19 Jun 92 23:27:24 EST From: cmf851@cscgpo.anu.edu.au (Albert Langer) Message-Id: <9206191327.AA22918@cscgpo.anu.edu.au> Subject: Re: compress To: art@opal.acc.com (Art Berggreen) Date: Fri, 19 Jun 92 23:27:21 EST Cc: cmf851@cscgpo.anu.edu.au, fbaker@opal.acc.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <9206181618.AA24089@opal.acc.com>; from "Art Berggreen" at Jun 19, 92 09:18:19 am X-Mailer: ELM [version 2.4dev PL32] > It's clear to me that there are two distinct communities using PPP. > There is the asynch, dial-up, SLIP replacement PPP and the synch, > high speed, dedicated channel PPP. Our perspective is focussed mostly > on the later. > > Art Yep, recognizing these two distinct aspects is very important. My remarks are focussed on the former (and any comments from me concerning the latter are from a position of admitted ignorance). [Art - earlier] > What I see, is a lot of discussion about potential ideas for a > new serial interconnect, which have little to do with PPP. It's > much too late to make changes of that scope. If a group wants to > get together, set up a separate list and spend the next couple of years > trying to reach consensus and getting the vendors to implement a new > interface spec, go ahead. But PPP must continue from its current > architecture if it is going to get used in the real world. > (I'm not overly fond of PPP, but I'm less fond of protocols which keep > evolving and are never stable enough for use) Turn this around. So far as async dialup is concerned, both SLIP and PPP represent a "new" serial interconnect protocol, with SLIP having the (sole) merit of simplicity and PPP having started out as a plausible enhanced replacement for SLIP but having then grown like topsy with a focus mainly on features for high speed dedicated channel use with multi-protocol routers. LAPB on the other hand represents well established internationally standardized technology which (in the guise of LAPM and V.42) is even included in modems by vendors. The recent international standardization of the async framing for use with LAPB represents an exciting opportunity to get away from all the hassles of modem connections and make it no more difficult than any LAN connection, without having to use special hardware (ordinary async COM ports and modems). Since it seems to be the considered opinion of a number of users of dedicated high speed channels for interconnecting routers etc, that a new serial interconnection protocol is needed in that context, so be it. I am doubtful, but it's probably none of my business. The async MAC layer used by PPP strikes me as being of very little relevance to the high speed, dedicated channel aspect, and SOLELY relevant to async, dialup SLIP replacement and related applications. Separating the async MAC layer from other aspects of PPP would help clarify this distinction, even though one can use the sync equivalent on low speed links and vice versa. Even IF LAPB is only of interest for special purposes like compression in the high speed, dedicated channel context, the totally different error rates and transit delays on low speed PSTN links suggests it has far wider importance there. I am especially concerned that terminal servers supporting EITHER PPP SLIP replacement applications OR GOSIP compliant equivalents should be able to support BOTH without hassles. Essentially the same sorts of dialup users will be using the same phone lines for similar purposes and it makes NO sense to not be able to use a common MAC sublayer because of different treatment of "DEL"! I also believe that LAPB will make a critical difference to transit delay etc for async dialup as well as enabling support for much simpler connection oriented networking (all that is needed when there is only one link anyway). So, I'll be returning to those issues when I catch up with several messages still waiting for replies. Meanwhile, thanks for clarifying the important distinction between the two aspects of PPP. Please consider my comments entirely in the low speed, high error rate, async dialup context. Thanks to others for the detailed responses. I'll follow up shortly. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 19 07:52:58 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20030; Fri, 19 Jun 92 07:43:49 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08660; Fri, 19 Jun 92 07:19:43 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19166; Fri, 19 Jun 92 07:10:46 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from uu2.psi.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19078; Fri, 19 Jun 92 07:05:18 -0700 Received: from python.microcom.com by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA28327; Fri, 19 Jun 92 10:04:18 -0400 Date: Fri, 19 Jun 92 10:01:26 EDT From: kec@microcom.com (Ken Culbert) Received: by python.microcom.com (4.1/3.1.090690-Microcom Inc.) id AA16970; Fri, 19 Jun 92 10:01:26 EDT Message-Id: <9206191401.AA16970@python.microcom.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Compressing pad/compression length I agree with Chris Sullivan that we should negotiate away compression (or pad) length (at least I think he was in favor of the idea). Not only would a minimum of a byte be saved on each frame (this could add up for many short frames), but, more importantly, as Albert Langer pointed out, it would allow for streaming, which could significantly decrease latency, especially for large frames. From ietf-ppp-request@aggie.ucdavis.edu Fri Jun 19 09:01:32 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21977; Fri, 19 Jun 92 08:53:45 -0700 Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA09557; Fri, 19 Jun 92 08:34:33 -0700 Sender: ietf-ppp-request@aggie.ucdavis.edu Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA09357; Fri, 19 Jun 92 08:17:05 -0700 From: ccskiz@aggie.ucdavis.edu (Elizabeth St. Goar) Date: Fri, 19 Jun 92 08:17:05 -0700 Message-Id: <9206191517.AA09357@aggie.ucdavis.edu> To: ietf-ppp@aggie.ucdavis.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08487; Fri, 19 Jun 92 07:01:13 -0700 Received: from hobbit.gandalf.ca by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18683; Fri, 19 Jun 92 06:50:47 -0700 Received: from donut.gandalf.ca.adg.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA10766; Fri, 19 Jun 92 09:48:57 EDT Received: by donut.gandalf.ca.adg.gandalf.ca (4.1/SMI-4.1) id AA14232; Fri, 19 Jun 92 09:48:55 EDT From: dcarr@donut.gandalf.ca (Dave Carr) Message-Id: <9206191348.AA14232@donut.gandalf.ca.adg.gandalf.ca> Subject: RE: Compress Comments To: ietf-ppp-request@ucdavis.ucdavis.edu Date: Fri, 19 Jun 92 9:48:53 EDT Cc: fbaker@acc.com X-Mailer: ELM [version 2.3 PL11] > >> If that is the case, I think we should dispense with the compression option, > >> and merely have the LAPB Numbered Mode option handle it. It is more > >> difficult to have interdependent options negotiated simultaneuously. > > I have had questions from time to time about running multiple PPP links > in parallel, which is fine for non-sequential data streams (IP, etc), > but not for sequential ones (bridged traffic, VJ compressed traffic). > Maybe we have a "LAPB and Compressed" option and a "LAPB MultiLink" > option. (but what about compressed multilink?) > > I dunno, maybe I can be argued to your side in this case, as multilink > is generally for low speed lines. But I am not of that opinion yet. We would like to have support for compressed multi-link. Our current product supports this, and 2x64Kbps is a convenient number these days. So add "LAPB,multi-link, compressed". > >> > Compressed-Data-Length > >> > > >> > The length of Compressed-Data, in octets. Any octets following > >> > are PPP pad as specified in RFC 1331 section 3.1, and should not > >> > be decompressed. > >> > > >> I suggest that this be the length of the UN-compressed data, that is, > >> the original data. That would allow the uncompressor to run without > >> checking for padding, and then a simple assignment would fix the length. > >> There was also a previous comment that the length of the compressed data > >> might not end on a byte boundary, whereas the origianl data always would. > > I can see that. Votes? Specifying the UNcompressed length only wastes more bandwidth. I'm not interested in saving an infinitesimal amount of CPU and losing bandwidth. If you must have padding (which I sense from others that we must), then minimize it. According to the comments, it is sufficient to use 2 BITS to indicate how many pad bytes are necessary to provide padding to the nearest 32 bit boundary. Note, it is not necessary to waste the other 6 bits in the byte. Start shifting the compressed data into these bits. I can live with 2 BITS, but certainly not 2 BYTES. -- Dave Carr | dcarr@gandalf.ca | It's what you learn, Principal Designer | TEL (613) 723-6500 | after you know it all, Gandalf Data Limited | FAX (613) 226-1717 | that counts. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 19 09:21:29 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22457; Fri, 19 Jun 92 09:11:44 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09710; Fri, 19 Jun 92 08:49:45 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21703; Fri, 19 Jun 92 08:41:10 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from hobbit.gandalf.ca by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21370; Fri, 19 Jun 92 08:30:13 -0700 Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA23604; Fri, 19 Jun 92 11:29:10 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA23452; Fri, 19 Jun 92 11:29:06 EDT Date: Fri, 19 Jun 92 11:29:06 EDT From: mm@gandalf.ca (Mississippi Mud) Message-Id: <9206191529.AA23452@cannibal.gandalf.ca> To: bsimpson@angband.stanford.edu, fbaker@acc.com Subject: Re: compress comments Cc: ietf-ppp@ucdavis.ucdavis.edu >I dunno, maybe I can be argued to your side in this case, as multilink >is generally for low speed lines. But I am not of that opinion yet. Plus it has been pointed out to me that in future the compress algorithm field could potentially take on a value which represents more of the attributes Mr. Schryver would prefer: no royalties, no reliablility requirement, and *not* "not-exactly-OSI". >I thought PPP pretty much required the protocol identifier to be the >two octets following the address and control field? I wonder if it's >wise to propogate the way we distinguish between Ethernet and 802.3 >traffic on a CSMA/CD LAN ("if packet type < 0x0600, it's a length") is >something we really want to do? I would rather not. However this brings up an interesting point. (Don't they all?) It will be necessary to include, in a field all on its own (once decompressed) a protocol ID which identifies the protocol of the compressed packet. Any votes for TR9577? Sorry, it was just a joke, really. :-} (Runs away pelted by spitballs, paper airplanes, other projectiles...) -Chris Sullivan From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 19 10:01:02 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23953; Fri, 19 Jun 92 09:57:43 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10046; Fri, 19 Jun 92 09:29:54 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22868; Fri, 19 Jun 92 09:20:55 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from signet3.signet.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22695; Fri, 19 Jun 92 09:16:15 -0700 Received: from sigmadsk2.signet.com by signet.com (4.1/SMI-4.1) id AA01145; Fri, 19 Jun 92 08:58:17 EDT Date: Fri, 19 Jun 92 08:58:17 EDT From: ken@signet.com (Kenneth Virgile) Message-Id: <9206191258.AA01145@signet.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: PPP MIB Comments >> MIB-II allows for both "ppp" and physical (e.g. "ds3") >> values for ifType. It's not clear from MIB-II if its >> designers intended for multiple ifEntrys per interface, >> or if the designers intended for just one ifEntry and >> intended the Agent to select just one from the possible >> options. In any event, NMS vendors (and SNMP agents as >> well) have for the most part implemented a one-to-one >> relationship between ifEntry and physical interface. >> >> Question: >> Should the PPP MIB be changed so that >> pppLinkStatusIndex is allowed to contain zero? [A value >> of zero would indicate that there is no corresponding >> "ppp" ifEntry. Also, the wording of related PPP MIB >> variables would have to be changed to allow zero.] >> >I disagree with this. The ifType description clearly says >"physical/link protocol(s) immediately `below' the network layer in the >protocol stack." > >If the DS3 is a bare physical layer immediately below, then ds3 would be >used. When PPP is insinuated between the network and physical layers, >ppp should be used. In this scenario (PPP over DS3), that intepretation of mib-2 indicates that there should be just one ifEntry, since ds3 is not immediately below the network layer; however, implementation of the DS3 MIB (RFC 1233) requires a corresponding ds3 ifType. If a Network Manager were forced to select just one MIB, the DS3 MIB would win almost every time. Allowing the zero option in the PPP MIB gives Agents the following benefits: 1. Both the PPP MIB and the DS3 MIB can be implemented. 2. When the DS3 MIB is corrected (by it also allowing zero, so that there does not have to be a ds3 ifEntry), then both MIBs can still be implemented. Ken V. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 19 10:38:50 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24684; Fri, 19 Jun 92 10:27:09 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10239; Fri, 19 Jun 92 09:49:57 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23558; Fri, 19 Jun 92 09:43:32 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23391; Fri, 19 Jun 92 09:36:56 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA00171; Fri, 19 Jun 92 09:35:15 PDT Date: Fri, 19 Jun 92 09:35:15 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9206191635.AA00171@saffron.acc.com> To: cmf851@cscgpo.anu.edu.au Subject: Re: lapb Cc: ietf-ppp@ucdavis.ucdavis.edu >> > 2.3. Packet Format >> > >> > Standard PPP uses an ISO 3309 Address of 0xFF (Broadcast) and a >> > control field of 0x03 (UI). While LAPB is operational, the use of >> > these values remains legal. However, the Address Field of the frame >> > may also take the value announced in the configuration option, and >> > the control field may take any value valid in ISO 7776. The fields >> > are transmitted from left to right. >> >> It's unclear to me whether this is intended to permit or prohibit the >> use of header compression in non-LAPB mode. I don't recall the document saying *anything* about non-LAPB mode. In LAPB mode, I think header compression MUST NOT be permitted, as "00" (the first octet of, say, 0023 and 0021) is "I frame, n(r)=0, n(s)=0, no P" in LAPB. Having said which, header compression is *never* permitted on LCP frames anyway... >> Is there any real value in allowing other LAPB addresses and even >> two octet addresses? Is there any real value in allowing UI mode >> simultaneously? I dunno. Is there any plan to use PPP over Q.921 or Q.922? I tried to be sufficiently vague as to not preclude applications that aren't foremost in my mind. Applications I'm thinking about would almost certainly use the ISO 7776 definitions. >> (BTW, I haven't checked whether it is in the current version but >> I recall noticing some clumsy wording about having to use 0xFF, UI >> when in compressed mode if compression would be ambiguous as a result of >> the protocol ID being 0xFF and the first octet of data being equal to UI. >> Should simply reserve 0xFF instead, unless that has been done already.) Which compression was this? My document presumed LAPB... Fred From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 19 11:03:45 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25567; Fri, 19 Jun 92 10:54:20 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10756; Fri, 19 Jun 92 10:30:14 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24560; Fri, 19 Jun 92 10:22:23 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from GINGER.LCS.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24344; Fri, 19 Jun 92 10:12:14 -0700 Received: by ginger.lcs.mit.edu id AA26353; Fri, 19 Jun 92 13:11:07 -0400 Date: Fri, 19 Jun 92 13:11:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206191711.AA26353@ginger.lcs.mit.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: compress Cc: cmf851@cscgpo.anu.edu.au, jnc@ginger.lcs.mit.edu This discussion is so diffuse it's hard to understand exactly what the point of it is. On to more substantive things: the primary reason PPP came into existence was the lack of any reasonable *multi-protocol* serial line protocol. This lack existed in both the low speed async as well as high speed sync arenas. I must confess I am not totally familiar with LAP-B, but how would using LAP-B have given us this capability? Relevant existing work was used wherever possible; HDLC is used as the lowest framing layer, since it did that and did it reasonably well. The existence of a lot of working hardware was, of course, a big plus. LAP-B was ignored since the things it gives you (reliability, etc) were not things that PPP was supposed to provide. So what if PPP has lots of optional features for high speed channels? Nobody has to support LQM on a low speed serial link. That's why they are optional. I personally don't give two hoots that LAPB "represents well established internationally standardized technology". That and 25 cents will get you a cup of coffee around me. If that kind of thing meant anything, IP would never have existed, and we'd all be using X.25. What is important is what does it do, how well does it do it, and how does that relate to what we need to do now. Now, I'm not as familiar with the needs of the low speed async community (especially as to what those needs were at the time the PPP effort started), and maybe there are some needs that LAPB will meet, but I'd like to hear clearly what those needs are, and how LAPB will do them. Useless international standards propoganda should be left at home, since it causes any message which contains it to be subject to instant deletion without consideration. To paraphrase Goering: "whenever I hear the word GOSIP I want to pull out my gun". Noel From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 19 11:33:29 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26485; Fri, 19 Jun 92 11:24:25 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11070; Fri, 19 Jun 92 10:49:59 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25173; Fri, 19 Jun 92 10:41:46 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25042; Fri, 19 Jun 92 10:36:47 -0700 Received: by europa.clearpoint.com (4.1/1.34) id AA02078; Fri, 19 Jun 92 13:28:03 EDT Date: Fri, 19 Jun 92 13:28:03 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9206191728.AA02078@europa.clearpoint.com> To: ken@signet.com Subject: Re: PPP MIB Comments Cc: ietf-ppp@ucdavis.ucdavis.edu Ken, It seems that there is some confusion here. If there were a host with a single PPP entity running over a single ds3 interface, there would be two ifTable entries, one for the DS3 and one for the PPP. For the sake of discussion I'll suppose that the ds3 ifEntry has ifIndex = 1 and the ppp ifEntry has ifIndex = 2. The values of selected objects in the MIB would be: ifIndex: 1 2 ifType: ds3(30) ppp(23) (INTEGER values) ifSpecific: ds3 ppp (OBJECT IDENTIFIER values) pppLinkStatusPhysicalIndex: 1 Furthermore, the ppp entry is the one that the various IP tables reference since that is what is providing the IP layer's "interface" to the network. The wording in the ifType DESCRIPTION text is not very good. We have several cases in the MIBs where the entities that are "MIB'ed" by the ifTable are not "immediately `below' the network layer." FOr example, see the Bridge MIB. Hope this helps. Frank Kastenholz From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 19 12:41:53 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28891; Fri, 19 Jun 92 12:39:37 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11905; Fri, 19 Jun 92 11:59:56 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27376; Fri, 19 Jun 92 11:50:38 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from crl.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27061; Fri, 19 Jun 92 11:42:33 -0700 Received: by crl.dec.com; id AA23971; Fri, 19 Jun 92 13:49:40 -0400 Received: by easynet.crl.dec.com; id AA29220; Fri, 19 Jun 92 14:39:04 -0400 Message-Id: <9206191839.AA29220@easynet.crl.dec.com> Received: from bigfut.enet; by crl.enet; Fri, 19 Jun 92 14:39:09 EDT Date: Fri, 19 Jun 92 14:39:09 EDT From: Ross Callon To: cmf851@cscgpo.anu.edu.au Cc: ietf-ppp@ucdavis.ucdavis.edu, callon@bigfut.enet.dec.com Apparently-To: cmf851@cscgpo.anu.edu.au, ietf-ppp@ucdavis.edu Subject: re: Re: ppp-osi draft > > 2. The "inactive subset" of CLNP can be quite useful for a workstation > or laptop that simply needs a connection to it's "host" system and not > to other addresses. MHS, Directory Service and the entire range of > "Distributed Office Applications Model" applications can be accessed > using TP4 over this essentially "null" network layer. Although I have > no doubt that accessing them over a connection oriented "Minimal Network > Layer" and TP0 or TP1 makes more sense (using LAP B plus a "More" bit), > some will prefer that route and I know Christian Huitema has been > advocating it. > The Inactive subset would basically be useful when (and only when) you want to run a transport layer protocol directly over PPP (i.e., you are sticking the single byte of zeroes in between only to fulfill the requirement that some network layer header be there). If anyone actually wants to run an OSI transport layer protocol (perhaps TP4) directly over PPP, then why not do so in a straightforward manner, by defining a new PPP protocol type to say "OSI Transport Layer", and sticking the transport layer header directly inside a PPP header? Ross From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 19 14:53:44 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02955; Fri, 19 Jun 92 14:45:32 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA12824; Fri, 19 Jun 92 13:30:06 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00298; Fri, 19 Jun 92 13:21:05 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from signet3.signet.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00160; Fri, 19 Jun 92 13:15:58 -0700 Received: from sigmadsk2.signet.com by signet.com (4.1/SMI-4.1) id AA01862; Fri, 19 Jun 92 15:32:34 EDT Date: Fri, 19 Jun 92 15:32:33 EDT From: ken@signet.com (Kenneth Virgile) Message-Id: <9206191932.AA01862@signet.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: PPP MIB Comments > Question: > Should the PPP MIB be changed so that > pppLinkStatusIndex is allowed to contain zero? [A value > of zero would indicate that there is no corresponding > "ppp" ifEntry. Also, the wording of related PPP MIB > variables would have to be changed to allow zero.] > Whether or not my box supports the eventual RFC-standard PPP MIB is a minor issue when my box is sold and installed. Whether or not my box is manageable by existing NMSes is a MAJOR (and often REQUIRED) issue. If I create two ifEntrys (one for PPP and one for DS3), many existing NMSes will NOT be able to manage my box. In order to capture the biggest possible portion of the market with my box, my approach is to NOT implement the PPP MIB (as it stands now). When/If the PPP MIB becomes widely adopted, then I would support it if that would help sell my box. My initial Question was an attempt to merge the "engineering" desires with the "marketing" desires. I believe that such a merging is necessary, in order for the PPP MIB to become widely used. Ken V. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 19 15:21:15 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03867; Fri, 19 Jun 92 15:19:16 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14737; Fri, 19 Jun 92 14:59:51 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03166; Fri, 19 Jun 92 14:53:22 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from regal.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02900; Fri, 19 Jun 92 14:45:05 -0700 Received: by regal.cisco.com; Fri, 19 Jun 92 14:44:01 -0700 Date: Fri, 19 Jun 92 14:44:01 PDT From: William "Chops" Westfield To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: ietf-ppp@ucdavis.ucdavis.edu, cmf851@cscgpo.anu.edu.au, jnc@ginger.lcs.mit.edu Subject: Re: compress In-Reply-To: Your message of Fri, 19 Jun 92 13:11:07 -0400 Message-Id: Yeah, everything Noel said (even the parts I didn't quote below). On to more substantive things: the primary reason PPP came into existence was the lack of any reasonable *multi-protocol* serial line protocol. This lack existed in both the low speed async as well as high speed sync arenas. I must confess I am not totally familiar with LAP-B, but how would using LAP-B have given us this capability? It doesn't. cisco routers have supported IP over LAPB for more than 5 years. Multiple protocols over lapb for more than 3 years. Does it do us any good? Does it allow use to interoperate? Of course not! I personally don't give two hoots that LAPB "represents well established internationally standardized technology". That and 25 cents will get you a cup of coffee around me. If that kind of thing meant anything, IP would never have existed, and we'd all be using X.25. What is important is what does it do, how well does it do it, and how does that relate to what we need to do now. LAPB is a well established [...] technology that gives you ... LAPB. This is useful if you want to run X.25 over it. NEITHER LAPB nor X.25 solve the problems that the "agonizing complexities" of PPP address: multiple protocols, compression, authentication (x.25 has a little, I guess), address negotiation, LQM, non-transparent path negotiation, etc, etc. Now, it may be useful to define a standard for running multiple protocols over LAPx, and it would certainly be nice if that standard picked up the "upper level" negotiations in a manner compatible with PPP, but JUST using LAPB does not solve ANY problems. So what if PPP has lots of optional features for high speed channels? Nobody has to support LQM on a low speed serial link. That's why they are optional. PPP has lots of optional features for low speed channels too. It is particularly amusing that the low-speed people complain about the high speed features of PPP, and the high-speed people complain about the low-speed features. I guess this is a sign of a successful standard - nobody is happy, everybody grumbles a lot, and it works... BillW From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 19 17:11:27 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07277; Fri, 19 Jun 92 17:02:03 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA16034; Fri, 19 Jun 92 16:39:57 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06303; Fri, 19 Jun 92 16:31:13 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06020; Fri, 19 Jun 92 16:24:39 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA00165; Fri, 19 Jun 92 16:22:44 PDT Date: Fri, 19 Jun 92 16:22:44 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9206192322.AA00165@saffron.acc.com> To: billw@regal.cisco.com Subject: Re: compress Cc: ietf-ppp@ucdavis.ucdavis.edu >> I guess this is a sign of a successful standard - >> nobody is happy, everybody grumbles a lot, and it works... Right. :^) Actually, LAPB does gove you one other thing, and that is the one thing that I'm proposing it for: reliable sequential delivery, a prerequisite for most compression algorithms. compression, in its turn, can be a *very* useful feature. I can't say I'm very interested in all the other brouhaha here. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 19 17:23:02 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07617; Fri, 19 Jun 92 17:14:26 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA16066; Fri, 19 Jun 92 16:44:43 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06308; Fri, 19 Jun 92 16:31:19 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06082; Fri, 19 Jun 92 16:26:33 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA09033; Fri, 19 Jun 92 16:25:10 -0700 Date: Fri, 19 Jun 92 19:07:31 EDT From: "William Allen Simpson" Message-Id: <452.bsimpson@angband.stanford.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: lapb > From: Karl Fox > Fred Baker writes: > > Should the address be zero upon receipt, the receiver MUST NAK > > with an appropriate address. If both peers send the address 00, > > then the system with the numerically smaller Magic Number will > > select the link addresses. > > I feel uneasy about making one option so dependent on the existence of > another -- imagine trying to decide whether to Ack or Nak if the > Numbered-Mode option comes before the Magic-Number option in the > Configure-Request. I would much prefer adding another field (`random > number') to the Numbered-Mode configuration option to serve as the coin > toss. > Also, both sides could ask for 01 or 03. However, the peer knows what it just sent in its Request (it sends the request just before the NAK, see the FSM). Let's not clutter up the option. How about just saying "If both peers request the same address, or both request 00, the system should randomize the address choice for the NAK. If a suffiently random source is used, the values should diverge quickly. See Magic-Number for a discussion of good sources of randomness." Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Fri Jun 19 19:30:30 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11560; Fri, 19 Jun 92 19:21:35 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA16627; Fri, 19 Jun 92 17:50:00 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08549; Fri, 19 Jun 92 17:42:02 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from azea.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08430; Fri, 19 Jun 92 17:38:10 -0700 Received: by azea.clearpoint.com (4.1/1.34) id AA01109; Fri, 19 Jun 92 20:28:03 EDT Date: Fri, 19 Jun 92 20:28:03 EDT From: martillo@azea.clearpoint.com (Joachim Martillo @ azea) Message-Id: <9206200028.AA01109@azea.clearpoint.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Lost Mail Someone at McGill who reads this list sent me a request which I can probably fulfil. Unfortunately, an emacs crash wiped out the mail. If this person is reading, he should please resend his mail. Joachim Carlo Santos Martillo Ajami From ietf-ppp-request@ucdavis.ucdavis.edu Sat Jun 20 00:00:20 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18721; Fri, 19 Jun 92 23:53:38 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17569; Fri, 19 Jun 92 23:39:40 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18323; Fri, 19 Jun 92 23:30:21 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18214; Fri, 19 Jun 92 23:29:25 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA09165; Fri, 19 Jun 92 23:27:59 -0700 Date: Sat, 20 Jun 92 00:21:17 EDT From: "William Allen Simpson" Message-Id: <454.bsimpson@angband.stanford.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: compress > From: cmf851@cscgpo.anu.edu.au (Albert Langer) > > It's clear to me that there are two distinct communities using PPP. > > There is the asynch, dial-up, SLIP replacement PPP and the synch, > > high speed, dedicated channel PPP. Our perspective is focussed mostly > > on the later. > > > > Art > > Yep, recognizing these two distinct aspects is very important. My remarks are > focussed on the former (and any comments from me concerning the latter are > from a position of admitted ignorance). > > ... > > I also believe that LAPB will make a critical difference to > transit delay etc for async dialup as well as enabling support > for much simpler connection oriented networking (all that is > needed when there is only one link anyway). > > ... > > Meanwhile, thanks for clarifying the important distinction between > the two aspects of PPP. Please consider my comments entirely in > the low speed, high error rate, async dialup context. > I come from a low speed, high error rate, async dialup environment, and your LAPB CONS penchant doesn't make any sense to me, either. In fact, your desire for error correcting, selective retransmission is particularly bad in low speed lines. Delay of a few dozen bytes at 2400bps looks like infinity to an ethernet pumping data in. I turn *off* the error correction in the modems when running TCP/IP. You see, error correction and retransmission at the link layer causes that packet, and all other packets behind it, to have a longer effective round trip time. So even though you have managed to get the packet across the link successfully, a well-designed TCP at the host has already timed out, and retransmitted. Unfortunately, the other packets also are delayed, and their hosts all retransmit too, causing an avalanche of congestion across the net. The resulting large queue at the local interface causes more packets to be dropped, and more retransmissions. Eventually, this stabilizes at a very long SRTT at the hosts (everyone backs off), and a lot of dead time on the link. Very bad bandwidth utilization. All of this from only *one* error-correcting link retransmission. If the line is always dirty, it gets worse; retraining time, much worse. Retransmission should be left to the transport layer. We made this decision long, long, long ago. It works. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Sat Jun 20 00:10:24 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18999; Sat, 20 Jun 92 00:03:46 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17577; Fri, 19 Jun 92 23:41:49 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18340; Fri, 19 Jun 92 23:30:27 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18216; Fri, 19 Jun 92 23:29:39 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA09168; Fri, 19 Jun 92 23:28:30 -0700 Date: Sat, 20 Jun 92 01:07:18 EDT From: "William Allen Simpson" Message-Id: <455.bsimpson@angband.stanford.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: lapb > >> (BTW, I haven't checked whether it is in the current version but > >> I recall noticing some clumsy wording about having to use 0xFF, UI > >> when in compressed mode if compression would be ambiguous as a result of > >> the protocol ID being 0xFF and the first octet of data being equal to UI. > >> Should simply reserve 0xFF instead, unless that has been done already.) > > Which compression was this? My document presumed LAPB... > He's remembering 1171 or 1134. Yes, we reserved protocol 00FF long ago. Saves all of 2 comparisons. And yes, if you request the LAPB option, you can't request the Address/Control compression option. But the Protocol compression option would still be good. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Sat Jun 20 00:20:19 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19186; Sat, 20 Jun 92 00:13:54 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17589; Fri, 19 Jun 92 23:49:58 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18576; Fri, 19 Jun 92 23:45:11 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18266; Fri, 19 Jun 92 23:30:11 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA09171; Fri, 19 Jun 92 23:28:50 -0700 Date: Fri, 19 Jun 92 18:28:20 EDT From: "William Allen Simpson" Message-Id: <451.bsimpson@angband.stanford.edu> To: fbaker@acc.com (Fred Baker) Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: compress comments > > >> > Format of Information Field: > >> > > I thought PPP pretty much required the protocol identifier to be the > two octets following the address and control field? > Ah, you had me confused since you said format of Information field. Usually, I don't think of the PPP Protocol number as being in the Information field. Of course, from a LAPB perspective, it is. And there are really *TWO* PPP protocol numbers in the packet! How about a diagram like: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | address | control | PPP Compression Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Length | PPP Data Protocol (compressed) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data (compressed) ... +-+-+-+-+-+-+-+-+-+-+-+- With a blurb saying something like, "When the Compression Protocol and Data Length are removed, and the remainder of the Information field is decompressed, the result will resemble a PPP protocol packet with the Address and Control fields removed, and can be processed as if it had arrived in the same fashion as any other PPP frame." Also, "Notwithstanding the alignments shown in the diagram, the Compression Protocol and Data Protocol fields may be compressed from 2 octets to 1 octets using the usual PPP Protocol Field Compression mechanism." Now that I understand what you are doing, I must say, this is a great design! Nice and general -- it could be used for other compression schemes than V.29bis over LAPB. I'm now glad you split this into 2 options. However, because you *only* can use LAPB as a compression transporter for PPP (since the PPP protocol will be stripped off of the information field), could you combine these 2 documents into one? Something like the Authentication Protocols document? Otherwise, someone might get the idea they could run X.25 or Frame Relay over the same link with PPP. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Sat Jun 20 00:30:41 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19433; Sat, 20 Jun 92 00:26:03 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17602; Fri, 19 Jun 92 23:52:05 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18600; Fri, 19 Jun 92 23:45:18 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18342; Fri, 19 Jun 92 23:30:27 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA09174; Fri, 19 Jun 92 23:29:11 -0700 Date: Sat, 20 Jun 92 01:27:39 EDT From: "William Allen Simpson" Message-Id: <456.bsimpson@angband.stanford.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: > > >> I suggest that this be the length of the UN-compressed data, that is, > > >> the original data. That would allow the uncompressor to run without > > >> checking for padding, and then a simple assignment would fix the length. > > >> There was also a previous comment that the length of the compressed data > > >> might not end on a byte boundary, whereas the origianl data always would. > > > > I can see that. Votes? > > I can live with 2 BITS, but certainly not 2 BYTES. > > Dave Carr I don't know the limits of V.42bis. Do we need to know the padding at all? Why can't we just specify that the compression stops at the end of the packet, which may include padding. We just pass the decompressed packet to the PPP network-layer protocol anyway. Any network-layer protocols over PPP must already be able to discern where the legitimate end of their packet is, and trim off the padding. This may mean that the compression routines have to have the ability to generate a bitstream of a particular length at the end of the packet, to meet the alignment, but that is the problem of the guy with the hardware that needs the padding. The expansion could have any value, since it's just thrown away anyway. This could eliminate both bytes! Wow! Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com (And Dave, could you please stop sending to ietf-ppp-request. Just send to ietf-ppp.) From ietf-ppp-request@ucdavis.ucdavis.edu Sat Jun 20 04:20:07 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23064; Sat, 20 Jun 92 04:14:21 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18187; Sat, 20 Jun 92 03:59:43 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22740; Sat, 20 Jun 92 03:50:15 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from anu.anu.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22609; Sat, 20 Jun 92 03:40:57 -0700 Received: from cscgpo.anu.edu.au by anu.anu.edu.au (4.1/SMI-4.1) id AA04992; Sat, 20 Jun 92 20:39:56 EST Received: from huxley.anu.edu.au by cscgpo.anu.edu.au (4.1/SMI-4.1) id AA27604; Sat, 20 Jun 92 20:39:53 EST From: cmf851@cscgpo.anu.edu.au (Albert Langer) Message-Id: <9206201039.AA27604@cscgpo.anu.edu.au> Subject: Re: Re: ppp-osi draft To: callon@bigfut.enet.dec.com (Ross Callon) Date: Sat, 20 Jun 92 20:39:52 EST Cc: cmf851@cscgpo.anu.edu.au, ietf-ppp@ucdavis.ucdavis.edu, callon@bigfut.enet.dec.com In-Reply-To: <9206191839.AA29220@easynet.crl.dec.com>; from "Ross Callon" at Jun 20, 92 02:39:09 pm X-Mailer: ELM [version 2.4dev PL32] > The Inactive subset would basically be useful when (and only when) > you want to run a transport layer protocol directly over PPP > (i.e., you are sticking the single byte of zeroes in between only > to fulfill the requirement that some network layer header be there). True. But it isn't just an arbitrary requirement. It is what makes it possible to multiplex protocols TR 9577 style instead of HAVING to go through hoops defining protocol IDs etc. The PPP "osi" draft makes use of that technique for other OSI protocols but then arbitrarily excludes the ONE that might most plausibly be used with PPP (since at least it doesn't repeat the caller and called NSAP addresses and other redundant CLNP header information every single packet despite being on an inherently connection oriented physical network). > If anyone actually wants to run an OSI transport layer protocol > (perhaps TP4) directly over PPP, then why not do so in a > straightforward manner, by defining a new PPP protocol type to say > "OSI Transport Layer", and sticking the transport layer header > directly inside a PPP header? Fair enough. To me it is the opposite of "straightforward", but I suspect that you are right that anyone who actually DOES want to run TP4 directly over PPP (i.e. not me!) might well be perfectly happy with that solution. After all, there isn't much sense in multiplexing it with anything in this context. (If they are happy with using CLNP fragmentation instead of a simple "More" bit to achieve any kind of reasonable interactive response on a low speed line then they are probably easily satisfied :-) I just thought I should mention that some people may want the inactive subset provided for. I have no interest in it myself and am happy to leave it there. It might be a good idea to check with Christian Huitema. From ietf-ppp-request@ucdavis.ucdavis.edu Sat Jun 20 05:00:10 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23662; Sat, 20 Jun 92 04:54:22 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18247; Sat, 20 Jun 92 04:39:41 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23325; Sat, 20 Jun 92 04:30:11 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from anu.anu.edu.au by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23243; Sat, 20 Jun 92 04:25:47 -0700 Received: from cscgpo.anu.edu.au by anu.anu.edu.au (4.1/SMI-4.1) id AA05027; Sat, 20 Jun 92 21:24:47 EST Received: from huxley.anu.edu.au by cscgpo.anu.edu.au (4.1/SMI-4.1) id AA27711; Sat, 20 Jun 92 21:24:45 EST From: cmf851@cscgpo.anu.edu.au (Albert Langer) Message-Id: <9206201124.AA27711@cscgpo.anu.edu.au> Subject: Re: compress To: bsimpson@angband.stanford.edu (William Allen Simpson) Date: Sat, 20 Jun 92 21:24:43 EST Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <454.bsimpson@angband.stanford.edu>; from "William Allen Simpson" at Jun 21, 92 00:21:17 am X-Mailer: ELM [version 2.4dev PL32] > In fact, your desire for error correcting, selective retransmission is > particularly bad in low speed lines. Delay of a few dozen bytes at > 2400bps looks like infinity to an ethernet pumping data in. I turn > *off* the error correction in the modems when running TCP/IP. Good idea. The modems have LAP B (equivalent), but they do NOT have a "More" bit. I have consistently been asserting the need for LAPB PLUS a "More" bit. > You see, error correction and retransmission at the link layer causes > that packet, and all other packets behind it, to have a longer effective > round trip time. So even though you have managed to get the packet > across the link successfully, a well-designed TCP at the host has > already timed out, and retransmitted. Unfortunately, the other packets > also are delayed, and their hosts all retransmit too, causing an > avalanche of congestion across the net. Yes, I DO see, and these endearing characteristics of a "well-designed TCP" go far towards explaining my "penchant for CONS". But I was explicitly advocating LAPB plus "More" bit to provide a connection oriented SUBnetwork layer to support connectionLESS network layer protocols, AS WELL as being necessary for CONS. By splitting the IP packet into SMALL frames, WITHOUT suffering the overheads of IP fragmentation, a "More" bit allows for error correction WITHOUT other traffic banking up behind. If that seems counter-intuitive, it is essentially the same counter-intuitive cponcept that lies behind the whole idea that you can improve performance by using a "packet" network instead of a circuit switched or message switched network. Think "pipelining". If you can't visualize it, try the animated demo I mentioned. > Retransmission should be left to the transport layer. We made this > decision long, long, long ago. It works. It doesn't work with large packets and interactive traffic multiplexed over low speed noisy lines. Interactive latency DOES need improving. You can get better telnet performance over an international high speed link than you can over a local low speed PPP link that is also being used for mail or file transfer traffic - despite the fact that PPP does NO error correction and leaves it all to TCP. Performance is MUCH better if you log in direct (even with an error correcing modem in "streaming" mode). This points to the fact that latency problems are caused by long packets multiplexed together with an interactive session. I have got the message that I am challenging ancient prejudices. "We made this decision long, long ago." I am still waiting for a safety timeout to expire before responding to some of the more EXPLICITLY religious defences of Internet orthodoxy, and I still have to catch up with some other messages first, but I thought the above should be responded to as it appears to raise a serious technical objection. Can we agree on this much? a) IF I am right that segmenting packets with LAPB plus a "More" bit can improve delays instead of making it worse as you suggest, then it ought to be looked at seriously. After all, there would not be much point in you raising the above point about LAPB WITHOUT a "More" bit if your attitude would not be affected by discovering that the OPPOSITE is true concerning LAPB WITH a "More" bit. b) WHETHER I am right or wrong about that is a matter of fact, unaffected by the relative authority of ISO, prevailing Internet opinion, my attitude etc etc? It isn't even the sort of issue that can be treated as a matter of opinion to be decided according to one's best judgment and experience. It is something that can either be proved or refuted by reference to objective arguments. From ietf-ppp-request@ucdavis.ucdavis.edu Sat Jun 20 12:10:08 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01249; Sat, 20 Jun 92 12:03:49 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA19210; Sat, 20 Jun 92 11:49:49 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00861; Sat, 20 Jun 92 11:40:14 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00763; Sat, 20 Jun 92 11:36:31 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA09726; Sat, 20 Jun 92 11:35:09 -0700 Date: Sat, 20 Jun 92 13:23:55 EDT From: "William Allen Simpson" Message-Id: <459.bsimpson@angband.stanford.edu> To: cmf851@cscgpo.anu.edu.au (Albert Langer) Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: LAP-B or not LAP-B, that is the question? I seem to get the job of "shushing" folks, so this is primarily to you, but addressed to the wider audience as well. You've been sending comments to this group a week (as of today). I was initially encouraged that you read the archives. You therefore should know much of the thought processes that went into designing PPP. This is the IETF PPP Working Group, a group for implementors of PPP. The IETF tradition is that new features and implementations are done hand-in-hand. I am discouraged that you have made several proposals for changes, and then said things like: > I just thought I should mention that some people may want the > inactive subset provided for. I have no interest in it myself > and am happy to leave it there. Please do not suggest that we add features that you are not planning to implement yourself. If you are really interested in adding a "more" bit to the special case of the PPP link compression LAPB-like header, and you are planning to demonstrate an implementation, by all means write it up. Show us how good you are, by doing it, not blathering about it! Remember that the primary consideration for the design for PPP was that it be able to run over nearly all existing hardware. Any "more" bit scheme must be able to run over all existing HDLC and LAPB chip sets, or be separately negotiable and not required for operation. > Yes, I DO see, and these endearing characteristics of a "well-designed > TCP" go far towards explaining my "penchant for CONS". > ... > But I was explicitly advocating LAPB plus "More" bit to provide a > connection oriented SUBnetwork layer to support connectionLESS > network layer protocols, AS WELL as being necessary for CONS. > ... > a) IF I am right that segmenting packets with LAPB plus a "More" > bit can improve delays instead of making it worse as you suggest, > then it ought to be looked at seriously. > ... > b) WHETHER I am right or wrong about that is a matter of fact, > unaffected by the relative authority of ISO, prevailing Internet > opinion, my attitude etc etc? > The problems of link delay due to packet size for real-time systems have been raised before in this and many other forums. Cell Relay and Asynchronous Transfer Mode have chosen a scheme similar to that which you are suggesting. PPP, Frame Relay, and many others have chosen a different design. You seem to have contempt for what has gone on before, and desire to re-design the entire protocol stack of several competing standards. Perhaps you should. Publish it, get your PhD, and become famous. But please do it in an academic journal, not a working group mailing list. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Sat Jun 20 12:20:28 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01474; Sat, 20 Jun 92 12:15:54 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA19240; Sat, 20 Jun 92 12:00:16 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01076; Sat, 20 Jun 92 11:52:41 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01016; Sat, 20 Jun 92 11:49:30 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02565; Sat, 20 Jun 92 11:48:32 PDT Date: Sat, 20 Jun 92 11:48:32 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9206201848.AA02565@ray.lloyd.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: good/bad PPP, LAPB, last-call There is virtually no difference between high-speed sync PPP and low-speed async PPP other than the framing. The difference exists there only because bit stuffing is part of generic sync hardware and not part of generic async hardware. Other than that, PPP does a good job of hiding the differences. This makes it possible to reuse code for both sync and async interfaces. The apparent differences are going to be further reduced by services like circuit-switched ISDN. Now you have a service that looks like a dial-up modem, traditionally an async environment, that runs sync data over the link. LAPB is intended to provide a reliable link. In most cases a reliable link is not required therefore the added complexity of LAPB is not needed. Fred, set me straight; I would expect the address/control compression option and the LAPB option to be mutually exclusive. Seems to me that the address and control fields must be present for LAPB to work (I can not see any way around it). Am I right? Lastly, let's quit arguing about how stupid/not-stupid PPP is and let's get on with whatever is necessary to put some of the new documents to bed. I am getting ready to put out a last call for comments on the OSI-over-PPP, DECNet-over-PPP, and IPX-over-PPP documents. Does anyone have any objections? I would like to push these documents onto the standards track now that there is implementation experience. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Sat Jun 20 13:40:12 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02965; Sat, 20 Jun 92 13:33:37 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA19413; Sat, 20 Jun 92 13:19:40 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02498; Sat, 20 Jun 92 13:10:20 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02394; Sat, 20 Jun 92 13:05:16 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02634; Sat, 20 Jun 92 13:04:16 PDT Date: Sat, 20 Jun 92 13:04:16 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9206202004.AA02634@ray.lloyd.com> To: bsimpson@angband.stanford.edu Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: "William Allen Simpson"'s message of Sat, 20 Jun 92 00:21:17 EDT <454.bsimpson@angband.stanford.edu> Subject: compress Bill, I have to disagree with you (note that I avoided using one of your favorite phrases, "YOU'RE WRONG!"). I have extensive experimental experience running IP over horribly lossy links in both telephony and amateur packet radio. In amateur packet radio packet losses on the order of 30% are not unusual. It became clear through experimentation that error correction at the link layer could yield significant improvements in increased throughput and reduced latency. End-to-end retransmission, ala TCP, is necessary and sufficient but it is not optimal in the case of a single lossy link in the middle of an otherwise reliable, e.g., low bit-error-rate, network. One other thing: turning on V.42 (LAPM) in an async modem increases its throughput because the modem switches to sync data transmission over the phone line (the modem performs async => sync conversion on the transmit end and sync => async conversion on the receiving end). In the case of a 2400 bps modem this means an increase in throughput from 240 bytes/sec to just under 300 bytes/sec. Latency is reduced except in the case of a retransmission. On the other hand, retransmission at the TCP layer does not occur until 2*SRTT (smoothed round-trip time). This is a BIG time hit. A properly designed modem will not delay a packet by this much time when it retransmits a frame within LAPM and therefore will not trigger a retransmission at the TCP layer. If the line is losing so badly that there are significant retransmissions at the link layer the decreased throughput and increased latency will cause TCP to converge on a new, longer SRTT. This will cause the TCP layer to avoid unnecessary retransmissions (this is very high in my "reasons why I love TCP" catagory). If you are seeing the behavior you describe, e.g. congestive collapse due to excessive retransmissions at both the link and transport layers, the link is probably so bad that it is unusable for reasonable operation. Suggestion: if you are running MNP4 error correction instead of LAPM some modems offer an option that permits you to adjust the MNP packet size. When the bit-error-rate increases, large packets become suboptimal. It is better to give up bandwidth to frame overhead than it is to give it up to retransmitting long frames. Adjust the MNP packet size downward and see what happens. So the bottom line is that it is -**- better to turn on the v.42 error correction in the modem than to run without it. It is better to run MNP with smaller packet sizes on a lossy link. Actually there is an exception in the case of latency. It is possible for the modem manufacturer to screw up the packetizing algorithm in the modem and increase latency even as LAPM or MNP increases throughput. It is worthwhile to test the latency in the modem before you choose it. Latency is critical to the performance when running interactive applications like TELNET. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Sat Jun 20 13:50:08 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03090; Sat, 20 Jun 92 13:44:06 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA19430; Sat, 20 Jun 92 13:29:53 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02750; Sat, 20 Jun 92 13:26:02 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02675; Sat, 20 Jun 92 13:20:01 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA02644; Sat, 20 Jun 92 13:18:55 PDT Date: Sat, 20 Jun 92 13:18:55 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9206202018.AA02644@ray.lloyd.com> To: cmf851@cscgpo.anu.edu.au Cc: bsimpson@angband.stanford.edu, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Albert Langer's message of Sat, 20 Jun 92 21:24:43 EST <9206201124.AA27711@cscgpo.anu.edu.au> Subject: compress Sender: ietf-ppp-request@ucdavis.edu From: cmf851@cscgpo.anu.edu.au (Albert Langer) Date: Sat, 20 Jun 92 21:24:43 EST X-Mailer: ELM [version 2.4dev PL32] ... Yes, I DO see, and these endearing characteristics of a "well-designed TCP" go far towards explaining my "penchant for CONS". You are a CONS bigot. I, and I suspect that most of the others on this list, are CLNS bigots (there doesn't seem to be much middle ground in the world on this issue). Please let's keep network religion elsewhere. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Sat Jun 20 18:10:10 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07635; Sat, 20 Jun 92 18:04:12 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA19895; Sat, 20 Jun 92 17:49:40 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07232; Sat, 20 Jun 92 17:40:09 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SGI.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07187; Sat, 20 Jun 92 17:36:28 -0700 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for ietf-ppp@ucdavis.edu id AA00977; Sat, 20 Jun 92 17:35:11 -0700 Received: by rhyolite.wpd.sgi.com (911016.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@ucdavis.edu id AA01861; Sat, 20 Jun 92 18:34:52 -0600 Date: Sat, 20 Jun 92 18:34:52 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9206210034.AA01861@rhyolite.wpd.sgi.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: compress > It isn't even the sort of issue that can be > treated as a matter of opinion to be decided according to one's > best judgment and experience. It is something that can either > be proved or refuted by reference to objective arguments. In no useful sense is there such a thing as an "objective argument." Everyone is equally objective. In the mathematical world, "proof" means no more or less than "convincing argument". Yes, I know about formal stuff, having been trained in it instead of this mundane computer stuff. No one is talking about that. If nothing else, the mathematican's meaning is the outcome of the Hilbert program and the herculean efforts of Whitehead and Russell. So the last sentence must be read as: ] something that can either ] convince or refute by reference to convincing arguments or ] to objective arguments. URGH! In other words, enough arguments, objective or not! Especially enough of the reliable link arguments that were old years ago at the start of this mailing list. There is something else that is convincing, MEASUREMENT and EXPERIMENT. How about comparing a prototype implementation of SLIP over LAPB with the usual SLIP? Such a beast should take only a few days to throw together. You could just take SLIP and put it's bytes out over a LAPB or x.25 link. It doesn't have to be production quality. Try it over low speed 9600b/s lines, so the code does not have to be fast. Fix the serial line code to psuedo-randomly change or drop bytes. See how the reliable link-layer improves latency and through-put for various error rates. If LAPB is good, then it will be obvious. If LAPB is bad only because the higher layer protocols are TCP/IP and NFS/UDP/IP, then I for one will not care. I do not anticipate switching to one of the TP family (except, of course, for the ubiqutious GOSIP checklists, which require x.25 and not PPP.) My sloppy measurements of IP over modems (SLIP; mae maxima culpa) almost but not quite agree with Mr. Simpson's. They are culled from about 1000 hours of personally supervised connect time. But they are little more than anecdotes, and should not be convincing. They should be less unconvincing that any arguments, objective or not. Vernon Schryver, vjs@sgi.com (One of my peeves with the OSI/ANSI/CCITT/IEEE standards process is that "proof" is a common word, but it always means "you wouldn't dare argue with me", and never "convincing argument" nor a formal expression in some predicate calculus. Somehow, "engineering", "science", "measurement", "experiment", and "documented experience" isn't good enough.) From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 22 12:11:58 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02609; Mon, 22 Jun 92 12:00:21 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25924; Mon, 22 Jun 92 08:49:46 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26139; Mon, 22 Jun 92 08:41:37 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from OPAL.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25921; Mon, 22 Jun 92 08:32:49 -0700 Received: by opal.acc.com (4.1/SMI-4.0) id AA26508; Mon, 22 Jun 92 08:33:14 PDT Date: Mon, 22 Jun 92 08:33:14 PDT From: art@opal.acc.com (Art Berggreen) Message-Id: <9206221533.AA26508@opal.acc.com> To: brian@lloyd.com, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: good/bad PPP, LAPB, last-call > > There is virtually no difference between high-speed sync PPP >and low-speed async PPP other than the framing. The difference exists >there only because bit stuffing is part of generic sync hardware and >not part of generic async hardware. Other than that, PPP does a good >job of hiding the differences. This makes it possible to reuse code >for both sync and async interfaces. The apparent differences are >going to be further reduced by services like circuit-switched ISDN. >Now you have a service that looks like a dial-up modem, traditionally >an async environment, that runs sync data over the link. I agree that this is little technical difference between the two uses, but I'd argue that there is a great deal of difference in the problems being solved, the expectations of the users and the types of communications channels being utilized. >LAPB is intended to provide a reliable link. In most cases a reliable >link is not required therefore the added complexity of LAPB is not >needed. Absolutly no argument. (also LAPB modifies the delay characteristics) >Fred, set me straight; I would expect the address/control compression >option and the LAPB option to be mutually exclusive. Seems to me that >the address and control fields must be present for LAPB to work (I can >not see any way around it). Am I right? Correct. >Lastly, let's quit arguing about how stupid/not-stupid PPP is and >let's get on with whatever is necessary to put some of the new >documents to bed. I am getting ready to put out a last call for >comments on the OSI-over-PPP, DECNet-over-PPP, and IPX-over-PPP >documents. Does anyone have any objections? I would like to push >these documents onto the standards track now that there is >implementation experience. I'm with you here, it's really hard to respond to marketplace demand for PPP when the specs for most of the protocols are still not stable. Let's move forward! >Brian Lloyd, WB6RQN Lloyd & Associates Art From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 22 12:21:42 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03167; Mon, 22 Jun 92 12:18:39 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA26116; Mon, 22 Jun 92 09:11:59 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26701; Mon, 22 Jun 92 09:01:08 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26513; Mon, 22 Jun 92 08:55:09 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA00369; Mon, 22 Jun 92 08:53:33 PDT Date: Mon, 22 Jun 92 08:53:33 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9206221553.AA00369@saffron.acc.com> To: bsimpson@angband.stanford.edu Subject: Re: Cc: ietf-ppp@ucdavis.ucdavis.edu >> I don't know the limits of V.42bis. Do we need to know the padding at all? Well, yes we do. BUT... I'm not sure we should be centering on V.42bis. Other algorithms could be used - all it takes is a number assignment from IANA. As a matter of fact, better choices may be the STAKS compression engine (available to all comers for $5/installation royalty in either software or hardware, but I don't want to write somebody's proprietary algorithm into a standard), and various other proprietary schemes. I pointed to V.42bis for the simple reason that I could point to it. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 22 12:56:01 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03965; Mon, 22 Jun 92 12:44:23 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA26165; Mon, 22 Jun 92 09:20:01 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27227; Mon, 22 Jun 92 09:17:23 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26845; Mon, 22 Jun 92 09:06:17 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA00381; Mon, 22 Jun 92 09:03:11 PDT Date: Mon, 22 Jun 92 09:03:11 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9206221603.AA00381@saffron.acc.com> To: brian@lloyd.com, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: good/bad PPP, LAPB, last-call >> Fred, set me straight; I would expect the address/control compression >> option and the LAPB option to be mutually exclusive. Seems to me that >> the address and control fields must be present for LAPB to work (I can >> not see any way around it). Am I right? You are correct. >> Lastly, let's quit arguing about how stupid/not-stupid PPP is Hear, Hear! Fred From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 22 12:56:12 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04167; Mon, 22 Jun 92 12:49:11 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA26434; Mon, 22 Jun 92 09:40:27 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27732; Mon, 22 Jun 92 09:32:47 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27444; Mon, 22 Jun 92 09:26:03 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA00403; Mon, 22 Jun 92 09:24:31 PDT Date: Mon, 22 Jun 92 09:24:31 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9206221624.AA00403@saffron.acc.com> To: jnc@ginger.lcs.mit.edu Subject: Re: compress Cc: ietf-ppp@ucdavis.ucdavis.edu >> I'm perfectly willing to entertain the concept of running LAPB, >> if someone will just explain to me clearly what the advantages are. I >> understand the need for compression; why do we need LAPB to do this? There are two reasons one might want LAPB. Both center on its ability to provide reliable sequential delivery. You can think of compression as a re-encoding of the data in a packet according to a disctionary. You can think of encryption the same way; the significant difference being not the result but the reason why one did it and how closely one guards the dictionary. In most compression schemes, the dictionary is not static, but dynamic. There exist encoding rules wherein the sender identifies strings and says "when I use this symbol, understand that I mean this string." The receiver first sees the matchup, and later sees only the symbol. There are several different ways this can be done, explicit and implicit; the most common ones have the sender and receiver analyzing the data in the same way, and therefore reaching the same conclusions. It is necessary for the sender and the receiver to see exactly the same data in the same sequence in order to keep their dictionarys in sync. Hence LAPB; it is a widely available, well understood, and reasonably efficient way to do that. I keep pointing out that the Multilink procedure can be useful at low speed, regardless of compression. I am not, as I've said, suggesting that LAPB be used to *replace* datagram mode; I generally prefer datagram behavior. But I don't believe that compression is a viable technology without reliable delivery. Does that help? Fred From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 22 13:32:36 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05443; Mon, 22 Jun 92 13:28:03 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27051; Mon, 22 Jun 92 10:40:06 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29726; Mon, 22 Jun 92 10:35:01 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29470; Mon, 22 Jun 92 10:29:53 -0700 Received: by europa.clearpoint.com (4.1/1.34) id AA04794; Mon, 22 Jun 92 13:20:50 EDT Date: Mon, 22 Jun 92 13:20:50 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9206221720.AA04794@europa.clearpoint.com> To: ietf-ppp@ucdavis.ucdavis.edu, ken@signet.com Subject: Re: PPP MIB Comments ken i do not understand how having two ifEntrys will make a box unmanageable. if an nms understands that the ppp interface is layered on top of the (e.g.) rs232 interface, then all is good and it can present the right thing on the screen. if an nms does not understand that the ppp interface is layered on top of the (e.g.) rs232 interface, then you will see two ifEntrys in the tables with no indication on the nms screen that the two ifEntry's are related. nothing will break. frank > From ietf-ppp-request@ucdavis.edu Fri Jun 19 17:35:51 1992 > Sender: ietf-ppp-request@ucdavis.edu > From: ken@signet.com (Kenneth Virgile) > To: ietf-ppp@ucdavis.edu > Subject: Re: PPP MIB Comments > > > Question: > > Should the PPP MIB be changed so that > > pppLinkStatusIndex is allowed to contain zero? [A value > > of zero would indicate that there is no corresponding > > "ppp" ifEntry. Also, the wording of related PPP MIB > > variables would have to be changed to allow zero.] > > > > Whether or not my box supports the eventual RFC-standard > PPP MIB is a minor issue when my box is sold and installed. > Whether or not my box is manageable by existing NMSes > is a MAJOR (and often REQUIRED) issue. If I create > two ifEntrys (one for PPP and one for DS3), many existing > NMSes will NOT be able to manage my box. > > In order to capture the biggest possible portion of > the market with my box, my approach is to NOT implement > the PPP MIB (as it stands now). When/If the PPP MIB > becomes widely adopted, then I would support it if that > would help sell my box. > > My initial Question was an attempt to merge the "engineering" > desires with the "marketing" desires. I believe that such > a merging is necessary, in order for the PPP MIB to become > widely used. > > Ken V. > From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 22 13:52:10 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05778; Mon, 22 Jun 92 13:36:44 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27409; Mon, 22 Jun 92 11:10:28 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00715; Mon, 22 Jun 92 11:03:11 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00478; Mon, 22 Jun 92 10:55:35 -0700 Received: by europa.clearpoint.com (4.1/1.34) id AA04967; Mon, 22 Jun 92 13:46:45 EDT Date: Mon, 22 Jun 92 13:46:45 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9206221746.AA04967@europa.clearpoint.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: new mibs hi i've mailed off revised mib documents to the internet-drafts repository. they ought to be showing up real soon now. those of you who notice that i now use the plural to refer to these documents can pat yourself on the back :-) one of the things that i've done is to split them into four documents: ppp-lcp mib ppp-security mib ppp-ip mib ppp-bridging mib i will be somewhat hard to get a hold of for the next week or two so i would suggest that you all read them and bring any comments to the ietf meeting in boston. frank From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 22 14:11:47 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06880; Mon, 22 Jun 92 14:09:31 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA28840; Mon, 22 Jun 92 12:49:50 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03908; Mon, 22 Jun 92 12:42:10 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from relay.hp.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03712; Mon, 22 Jun 92 12:35:14 -0700 Received: from hprnd.rose.hp.com by relay.hp.com with SMTP (16.6/15.5+IOS 3.13) id AA02889; Mon, 22 Jun 92 12:34:12 -0700 Received: from hprnls7b.rose.hp.com by hprnd.rose.hp.com with SMTP (15.11.1.3/15.5+IOS 3.21) id AA29603; Mon, 22 Jun 92 12:33:44 pdt Received: by hprnls7.rose.hp.com (16.6/15.5+IOS 3.21) id AA04412; Mon, 22 Jun 92 12:33:16 -0700 From: Rex Pugh Message-Id: <9206221933.AA04412@hprnls7.rose.hp.com> Subject: Where does ISDN fit in? To: ietf-ppp@ucdavis.ucdavis.edu Date: Mon, 22 Jun 92 12:33:15 PDT Mailer: Elm [revision: 66.25] This may be the wrong place to ask, but who is addressing the issue of running IP (though multi-protocol is more interesting) over ISDN? Would you use PPP or is it an issue for the IPLPDN working group? Any thoughts? Rex Pugh HP-Roseville From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 22 16:02:17 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10354; Mon, 22 Jun 92 15:52:10 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA00615; Mon, 22 Jun 92 15:10:05 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08740; Mon, 22 Jun 92 15:02:04 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08550; Mon, 22 Jun 92 14:58:17 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA03876; Mon, 22 Jun 92 14:56:44 PDT Date: Mon, 22 Jun 92 14:56:44 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9206222156.AA03876@saffron.acc.com> To: ietf-ppp@ucdavis.ucdavis.edu, pugh@hprnls7.rose.hp.com Subject: Re: Where does ISDN fit in? >> This may be the wrong place to ask, but who is addressing the issue >> of running IP (though multi-protocol is more interesting) over ISDN? >> Would you use PPP or is it an issue for the IPLPDN working group? >> Any thoughts? That can be argued either way. *My* preference would be to run PPP. To me, the B channel is nothing more than a Dial Line, with some special considerations (and there always are special considerations) about what it means to "dial". Fred From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 22 21:49:06 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01910; Mon, 22 Jun 92 21:35:55 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA03616; Mon, 22 Jun 92 21:13:59 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00830; Mon, 22 Jun 92 21:03:15 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from netmail.microsoft.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00537; Mon, 22 Jun 92 20:53:26 -0700 Received: by netmail.microsoft.com (5.65/25-eef) id AA00885; Mon, 22 Jun 92 18:16:53 -0700 From: tommyd@microsoft.com Message-Id: <9206230116.AA00885@netmail.microsoft.com> X-Msmail-Message-Id: F835FE39 X-Msmail-Conversation-Id: F835FE39 X-Msmail-Fixed-Font: 0001 X-Msmail-Wiseremark: Microsoft Mail -- 3.0.620 To: ietf-ppp-request@ucdavis.ucdavis.edu, jnc@ginger.lcs.mit.edu Date: Mon, 22 Jun 92 18:15:06 PDT Subject: Re: compress Cc: ietf-ppp@ucdavis.ucdavis.edu Well, since I just joined this mailing list, I'm not sure I fully understand all the issues or the arguments going on. However, it appears, and someone please correct me if I'm wrong, that one of the arguments is whether or not to compress on a per frame basis, or on a multi-frame basis (using LAPB to guarantee sequential delivery). |From: Fred Baker |Subject: Re: compress |Date: Mon, Jun 22, 1992 9:24AM | |I am not, as I've said, suggesting that LAPB be used to *replace* |datagram mode; I generally prefer datagram behavior. But I don't |believe that compression is a viable technology without reliable |delivery. | I disagree with this. Right now, on a hodge-podge of executable files, text files, documents, bitmaps, and assorted other files that popular apps spit-out (11 megs in all -- this is my test suite, and in general represents network traffic minus protocol headers), we are compressing 1500 byte frames to about 58% the original size. Since the 58% algorithm we have is a bit slow because it operates on the bit level, we are opting for the 63% algorithm. Once we prime the adaptive dictionary, we should get back down to about 60%. If these files were compressed using let's say V.42bis or LZW, you would get about 50-55% compression. Not much better for the hit in software size and extra data structure size. Not to mention added complexity for every PPP compression implementor. There are, of course, as previously mentioned, reasons why NOT using LAPB can allow a transport to perform better. Especially when you have multiple sessions on the same point to point link and data being sent across which does NOT need to have guaranteed delivery. --Thomas From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 22 21:49:09 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01928; Mon, 22 Jun 92 21:36:06 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA03611; Mon, 22 Jun 92 21:10:17 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00824; Mon, 22 Jun 92 21:03:01 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from wolf.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00501; Mon, 22 Jun 92 20:52:16 -0700 Received: from lager.cisco.com by wolf.cisco.com with TCP; Mon, 22 Jun 92 19:35:51 -0700 Message-Id: <9206230235.AA12778@wolf.cisco.com> To: fbaker@acc.com (Fred Baker) Cc: ietf-ppp@ucdavis.ucdavis.edu, pugh@hprnls7.rose.hp.com Subject: Re: Where does ISDN fit in? In-Reply-To: Your message of "Mon, 22 Jun 92 14:56:44 PDT." <9206222156.AA03876@saffron.acc.com> Date: Mon, 22 Jun 92 19:35:51 PDT From: Jim Forster I agree with Fred; I'd like to see IP over ISDN be done with PPP on the B channels. -- Jim >> >> This may be the wrong place to ask, but who is addressing the issue >> >> of running IP (though multi-protocol is more interesting) over ISDN? >> >> Would you use PPP or is it an issue for the IPLPDN working group? >> >> Any thoughts? >> >> That can be argued either way. *My* preference would be to run PPP. >> To me, the B channel is nothing more than a Dial Line, with some >> special considerations (and there always are special considerations) >> about what it means to "dial". >> >> Fred From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 22 22:01:05 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02591; Mon, 22 Jun 92 21:57:59 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA03672; Mon, 22 Jun 92 21:30:24 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01389; Mon, 22 Jun 92 21:21:15 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01279; Mon, 22 Jun 92 21:17:42 -0700 Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA11948; Mon, 22 Jun 92 19:15:26 -0700 Date: Mon, 22 Jun 92 17:42:59 EDT From: "William Allen Simpson" Message-Id: <463.bsimpson@angband.stanford.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: good/bad PPP, LAPB, last-call > From: brian@lloyd.com (Brian Lloyd) > I am getting ready to put out a last call for > comments on the OSI-over-PPP, DECNet-over-PPP, and IPX-over-PPP > documents. Does anyone have any objections? > I sure do. We are ready to go with OSI (I think) and Appletalk (although it still has many typos). I indicated that in a previous message. We have had considerable debate on both these designs. I have severe objections to both the DECnet and the IPX proposals. As I already told you personally, I am composing a competing IPX proposal (since the Shiva folks seem to have faded into the woodwork). Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 23 09:11:34 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18315; Tue, 23 Jun 92 09:00:49 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06890; Tue, 23 Jun 92 08:40:11 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17558; Tue, 23 Jun 92 08:32:09 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [134.22.80.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17401; Tue, 23 Jun 92 08:29:42 -0700 Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA01218; Tue, 23 Jun 92 11:29:00 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA07392; Tue, 23 Jun 92 11:28:56 EDT Date: Tue, 23 Jun 92 11:28:56 EDT From: mm@gandalf.ca (Mississippi Mud) Message-Id: <9206231528.AA07392@cannibal.gandalf.ca> To: fbaker@acc.com, ietf-ppp@ucdavis.ucdavis.edu Subject: ISDN, multilink, compression I keep pointing out that the Multilink procedure can be useful at low speed, regardless of compression. The MLP could be used on ISDN for combining B channels to form a single higher rate logical link (an operation which should be transparent to LCP). This is getting popular for isochronous traffic, but would make remote LAN access perform better too. Again this type of operation can be done in hardware, or in a less "not-quite-OSI" way, but if MLP works, and the CPUs can handle it, and a lot of vendors have it already coded, why not? Same for the V.42 issue, as far as time to implement is concerned. -Chris Sullivan From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 23 10:31:52 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21255; Tue, 23 Jun 92 10:29:13 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07900; Tue, 23 Jun 92 10:01:30 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20006; Tue, 23 Jun 92 09:54:03 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19534; Tue, 23 Jun 92 09:41:11 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA08365; Tue, 23 Jun 92 09:39:49 PDT Date: Tue, 23 Jun 92 09:39:49 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9206231639.AA08365@saffron.acc.com> To: bsimpson@angband.stanford.edu Subject: Re: compression methods Cc: brad@Cayman.COM, ietf-ppp@ucdavis.ucdavis.edu, karl@MorningStar.Com, vjs@sgi.com >> Could you three please make a sub-committee and explore a splay tree >> algorithm for PPP? If Karl wants to go design a splay tree approach, I'm willing. It is my understanding, based on his comments, that it requires the data on a specific conversation to all traverse a single network route in a specific order. If this is the case, it will only work for host-to-foo data; the Internet re-orders datagrams. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 23 12:08:25 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24194; Tue, 23 Jun 92 11:56:53 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09129; Tue, 23 Jun 92 11:20:03 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22665; Tue, 23 Jun 92 11:10:59 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from omnigate.clarkson.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22359; Tue, 23 Jun 92 11:01:22 -0700 Message-Id: <9206231801.AA22359@ucdavis.ucdavis.edu> Date: Tue, 23 Jun 92 13:55:01 EDT From: Brad Clements To: Fred Baker Cc: bsimpson@angband.stanford.edu, brad@cayman.com, ietf-ppp@ucdavis.ucdavis.edu, karl@morningstar.com, vjs@sgi.com Subject: splay compression comments (long) In my implementation of Splay compression for VJ packets over PPP/SLIP, it did not matter in which order the packets were sent by various routers. Compression took place immediately before the segment was transmitted over the link, and decrypted immediately after reception. There was no possibility in my implementation of reordering because I did not support multiple link transmission. The implementation only worked with VJ compression because it relied on VJ compression to know when to reset the splay trees (after a retransmission) If one reset the tree for every segment, splay compression could handle any protocol, however I found that it took several segments to build up a decent compression ratio. As each character was compressed/decompressed, the next tree was chosen by octect_value mod number_of_trees Trees could be added or removed without resetting the other trees assigned to that `stream'. small segments (fewer than 10 data octects) where not compressed. The compression routines attempted to compress all segments, however if previously compressed data was being transmitted (ftp of .Z file), the routine would note that the result of the compression was larger than the original and 1. reset the trees 2. make a note not to compress for a `while'. 3. send the segment uncompressed -- This experiment was targetted for slow links, < 19.2K baud async. The reason for that was because it was intended for use by PCs connected to Unix hosts (or routers, if a manufacturer eventually adopted it). The typical PC at the time (2 years ago) was an 8mhz 80286. At faster link speeds the compression took longer than the transmission time, so it wasn't worth it. However at these speeds the routine worked quite well, and gave varying results based on data transmitted. As I recall 3278 datastreams compressed the best, around 50% reduction, with text (csh.1) at about 37% reduction These numbers are from memory... -- For generic PPP compression, one could compress every segment beginning with a fresh tree. Even this wouldn't be bad if the definition of 'fresh' meant something other than 'all zeros tree'. For example, a suffuciently complex design (arg) could allow the sender to say 'here's a state tree, its resident tree #1, remember it' later it could say "here's a datagram, decompress by starting with a copy of tree #1" In essence, this is what the VJ/Splay compression stuff did. Except the tree(s) were tied to the VJ slot number. I think this might be too complex, as the `best tree' depends on the data being compressed. The reason splay compression worked so well with VJ compression is because we were not compressing the TCP/IP headers. Consider an IPX transmission of a text file read. If the headers get compressed with the data, the resulting compression ratio will be lower than separating out the data from the headers. It might be interesting to see if the total compressibility of an arbitrary protocol could be improved by chosing: 1. compressing the entire packet with the same starting tree. 2. compressing only the data section, transmitting the header section uncompressed 3. compressing both the header and the data with their own set of trees. -- I wasn't aware that caymen had also done a splay compression trail, brad can you tell us about yours? (someone on this list mentioned that you did one). | Brad Clements bkc@omnigate.clarkson.edu bkc@clutx.bitnet | Sr. Network Engineer Clarkson University (315)268-2292 From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 23 12:12:52 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24405; Tue, 23 Jun 92 12:02:20 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09260; Tue, 23 Jun 92 11:30:43 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23250; Tue, 23 Jun 92 11:29:25 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22962; Tue, 23 Jun 92 11:19:12 -0700 Received: from remora.morningstar.com by volitans.morningstar.com (5.65a/92042102) id AA09933; Tue, 23 Jun 92 14:17:56 -0400 Received: by remora.morningstar.com (5.65a/91072901) id AA09542; Tue, 23 Jun 92 14:17:52 -0400 Date: Tue, 23 Jun 92 14:17:52 -0400 From: Karl Fox Message-Id: <9206231817.AA09542@remora.morningstar.com> To: fbaker@acc.com (Fred Baker) Cc: vjs@sgi.com, ietf-ppp@ucdavis.ucdavis.edu, brad@Cayman.COM, bsimpson@angband.stanford.edu Subject: Re: compression methods References: <9206231639.AA08365@saffron.acc.com> Organization: Morning Star Technologies, Inc. Fred Baker writes: > > If Karl wants to go design a splay tree approach, I'm willing. It is > my understanding, based on his comments, that it requires the data on > a specific conversation to all traverse a single network route in a > specific order. If this is the case, it will only work for host-to-foo > data; the Internet re-orders datagrams. As Brad said in his message, VJ TCP header compression solves that for you. If VJ resyncs due to lost packets, packets out of order, etc., then the compressor restarts. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 23 12:42:09 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25558; Tue, 23 Jun 92 12:36:20 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09892; Tue, 23 Jun 92 12:00:29 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24049; Tue, 23 Jun 92 11:51:59 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from mescal.NOC.Vitalink.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23970; Tue, 23 Jun 92 11:49:39 -0700 Received: from hebron.ENG.Vitalink.COM by mescal.NOC.Vitalink.COM with SMTP id AA08295 (5.65c/IDA-1.4.4 for ); Tue, 23 Jun 1992 11:43:00 -0700 Received: by hebron.ENG.Vitalink.COM (5.65+V1.2/V1.3) id AA01118; Tue, 23 Jun 92 11:54:00 -0700 Date: Tue, 23 Jun 92 11:54:00 -0700 From: tai@eng.vitalink.com (Dan Tai) Message-Id: <9206231854.AA01118@hebron.ENG.Vitalink.COM> To: ietf-ppp@ucdavis.ucdavis.edu Please add me in your mail list. Thanks, Daniel Tai tai@vitalink.com From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 23 13:51:27 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27866; Tue, 23 Jun 92 13:48:36 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11080; Tue, 23 Jun 92 13:20:16 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26656; Tue, 23 Jun 92 13:11:34 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newton.ncsa.uiuc.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26456; Tue, 23 Jun 92 13:05:12 -0700 Received: from riker.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA25374 (5.65a/IDA-1.4.2 for ietf-ppp@ucdavis.edu); Tue, 23 Jun 92 15:04:31 -0500 Return-Path: Received: by riker.ncsa.uiuc.edu (4.1/NCSA-4.1) id AA03227; Tue, 23 Jun 92 15:04:30 CDT Date: Tue, 23 Jun 92 15:04:30 CDT From: arlanf@ncsa.uiuc.edu (Arlan Finestead) Message-Id: <9206232004.AA03227@riker.ncsa.uiuc.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: delete me, please Please remove me from the mailing list. Thanks! Arlan Finestead arlanf@ncsa.uiuc.edu From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 23 16:01:35 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02330; Tue, 23 Jun 92 15:52:26 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA12516; Tue, 23 Jun 92 15:20:19 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00880; Tue, 23 Jun 92 15:11:26 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from harvard.harvard.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00331; Tue, 23 Jun 92 14:55:55 -0700 Received: by harvard.harvard.edu (5.54/a0.25) (for ietf-ppp@ucdavis.edu) id AA14443; Tue, 23 Jun 92 17:55:00 EDT Received: by Xylogics.COM (4.12/4.7_jlv1/7/90) id AA28519; Tue, 23 Jun 92 16:55:40 edt Message-Id: <9206232055.AA28519@Xylogics.COM> From: reeve@Xylogics.COM (Scott Reeve) Date: Tue, 23 Jun 1992 16:55:39 EDT X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: ietf-ppp@ucdavis.ucdavis.edu Subject: Please take me off the mailing list. Thank you. - Scott Reeve From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 24 07:50:37 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27088; Wed, 24 Jun 92 07:42:03 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17568; Wed, 24 Jun 92 07:10:05 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25964; Wed, 24 Jun 92 07:01:06 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25880; Wed, 24 Jun 92 06:59:46 -0700 Received: by europa.clearpoint.com (4.1/1.34) id AA10333; Wed, 24 Jun 92 09:51:13 EDT Date: Wed, 24 Jun 92 09:51:13 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9206241351.AA10333@europa.clearpoint.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: mib id announcement in case no one gets the internet-draft announcements, this morning i saw the announcements for the security mib and the bridge mib for ppp. their file names are draft-ietf-pppext-secmib-00.txt and draft-ietf-pppext-bridgemib-00.txt. the others may be available too, though i did not see any announcement for them. to get an internet draft... 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-bridgemib-00.txt". or "get draft-ietf-pppext-secmib-00.txt". Internet-Drafts directories are located at: o East Coast (US) Address: nnsc.nsf.net (128.89.1.178) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) 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: mail-server@nisc.sri.com. In the body type: "SEND internet-drafts/draft-ietf-pppext-bridgemib-00.txt". For questions, please mail to internet-drafts@nri.reston.va.us. From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 24 11:43:11 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04507; Wed, 24 Jun 92 11:33:35 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA19478; Wed, 24 Jun 92 09:50:03 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00802; Wed, 24 Jun 92 09:41:07 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from CAYMAN.CAYMAN.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00586; Wed, 24 Jun 92 09:32:10 -0700 Received: from haiti.Cayman.COM (moon-patrol.cayman.com) by cayman.Cayman.COM (4.1/SMI-4.0) id AA17867; Wed, 24 Jun 92 12:31:07 EDT Received: from localhost by haiti.Cayman.COM (4.1/SMI-4.1) id AA04914; Wed, 24 Jun 92 12:35:06 EDT Message-Id: <9206241635.AA04914@haiti.Cayman.COM> To: Brad Clements Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: splay compression comments (long) In-Reply-To: Mail from Brad Clements dated Tue, 23 Jun 92 13:55:01 EDT <9206231759.AA26989@cayman.Cayman.COM> Date: Wed, 24 Jun 92 12:35:05 -0400 From: brad@Cayman.COM I'm behind on my mail. I've not (yet) done any work on splay tree compression. All of the work I've done has been focused on header compression of a single stream for AppleTalk, IPX, and TCP (using Van's code). In reading all of this (and I'm still reading - expect more ;-) I think I have to say I agree with Fred. VJ compress is great for a host or any single point-to-point link, but does not seem to fit the bill for a generalized router with many redundant links. I wonder if things might be split into (1) PPP + VJ (2) PPP' + V.42/splay/what-have-you where PPP' is really LAPB (i.e. provides a reliable substrate for compression). It's a bit of a stretch for me to get real excited about how much true compression I'm going to see if I split my text file over 5 different serial connections, but I'm sure it's more than zero (how much more, I'd like to see - sounds like a good research paper ;-) Having said that, I'm sure that something like V.42 or splay over multiple links is *much better* than trying to do VJ header compression over multiple links. I agree with Fred, it was never intended to work in that case (I mean hey, it was only designed so Van could work at home on a 3/50 over a 1200 baud modem - it's not a cure-all). Interestingly (and not suprising), it works great from my home to work over a *single* link. ;-) The moment they upgrade the local DMS switch to ISDN (6 months) you can bet I'll fire up both B channels at one time and (here comes the controversy) my VJ compression will not be as good as V.42 running on both channels, even *with* the overhead of the LAPB running over an already LAPB channel. -brad From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 24 13:01:29 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07072; Wed, 24 Jun 92 12:54:56 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA21275; Wed, 24 Jun 92 12:30:41 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06039; Wed, 24 Jun 92 12:22:40 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05851; Wed, 24 Jun 92 12:15:20 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA06385; Wed, 24 Jun 92 12:14:29 PDT Date: Wed, 24 Jun 92 12:14:29 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9206241914.AA06385@ray.lloyd.com> To: brad@Cayman.COM Cc: bkc@omnigate.clarkson.edu, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: brad@Cayman.COM's message of Wed, 24 Jun 92 12:35:05 -0400 <9206241635.AA04914@haiti.Cayman.COM> Subject: splay compression comments (long) With regard to compression: wouldn't it make sense to support multiple dictionaries ala VJ header compression? VJ already keeps track of the TCP sessions. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 24 14:22:03 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09378; Wed, 24 Jun 92 14:04:55 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA22109; Wed, 24 Jun 92 13:40:10 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08283; Wed, 24 Jun 92 13:31:04 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [134.22.80.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08081; Wed, 24 Jun 92 13:26:56 -0700 Received: from donut.gandalf.ca.adg.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA09543; Wed, 24 Jun 92 16:26:13 EDT Received: by donut.gandalf.ca.adg.gandalf.ca (4.1/SMI-4.1) id AA15978; Wed, 24 Jun 92 16:26:11 EDT From: dcarr@donut.gandalf.ca (Dave Carr) Message-Id: <9206242026.AA15978@donut.gandalf.ca.adg.gandalf.ca> Subject: splay compression comments (long) To: ietf-ppp@ucdavis.ucdavis.edu Date: Wed, 24 Jun 92 16:26:09 EDT Cc: ~@donut.gandalf.ca X-Mailer: ELM [version 2.3 PL11] > VJ compress is great for a host or any single point-to-point link, > but does not seem to fit the bill for a generalized router with > many redundant links. VJ is fine, the problem is the reordering of packets. If a multi-link operation over LAPB is used, there is no problem here. > where PPP' is really LAPB (i.e. provides a reliable substrate for > compression). It's a bit of a stretch for me to get real excited about > how much true compression I'm going to see if I split my text file over > 5 different serial connections, but I'm sure it's more than zero (how much > more, I'd like to see - sounds like a good research paper ;-) Again, you don't want five independent links, but one multi-link. Then, there is only one compressed stream and you'll get great compression. This is how our bridge works today. > Having said that, I'm sure that something like V.42 or splay over > multiple links is *much better* than trying to do VJ header > compression over multiple links. I agree with Fred, it was never > intended to work in that case VJ works fine over multi-link. But not over multiple independent links. > The moment they upgrade the local DMS switch to ISDN (6 months) you can > bet I'll fire up both B > channels at one time and (here comes the controversy) my VJ > compression will not be as good as V.42 running on both channels, even > *with* the overhead of the LAPB running over an already LAPB channel. I doubt it. I've performed lots of experiments when designing our bridge compression product. Don't expect V.42 bis to do a great job at header compression that VJ does. Each is specific. V.42 bis was made to compress DATA, and VJ for HEADERS. You wouldn't expect VJ to do a good job on DATA, so why expect V.42 bis to do a good job on the headers. By the way, you'll be lucky to get 2:1 on TCP headers out of V.42 bis. VJ gets what, 15:1. Pick the right tool for the job ! ---- Dave Carr | dcarr@gandalf.ca | It's what you learn, Principal Designer | TEL (613) 723-6500 | after you know it all, Gandalf Data Limited | FAX (613) 226-1717 | that counts. From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 24 17:35:26 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15526; Wed, 24 Jun 92 17:24:52 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA24993; Wed, 24 Jun 92 17:10:16 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14863; Wed, 24 Jun 92 17:02:29 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14642; Wed, 24 Jun 92 16:56:11 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA14699; Wed, 24 Jun 92 16:54:50 PDT Date: Wed, 24 Jun 92 16:54:50 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9206242354.AA14699@saffron.acc.com> To: dcarr@donut.gandalf.ca Subject: Re: splay compression comments (long) Cc: ietf-ppp@ucdavis.ucdavis.edu >> By the way, you'll be lucky to get 2:1 on TCP headers out of V.42 bis. >> VJ gets what, 15:1. >> >> Pick the right tool for the job ! Lessee, the TCP and IP headers are 40 octets out of 500+... Yeah, I guess thinking primarily about the headers makes the most sense. The data is such an insignificant part of the message. :^) Fred From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 24 18:00:58 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16147; Wed, 24 Jun 92 17:45:40 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25146; Wed, 24 Jun 92 17:30:23 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15430; Wed, 24 Jun 92 17:21:12 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from relay1.UU.NET by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15350; Wed, 24 Jun 92 17:18:04 -0700 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA16661; Wed, 24 Jun 92 20:17:10 -0400 Received: from penril.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 201610.9072; Wed, 24 Jun 1992 20:16:10 EDT Received: from Jaymes.penril.com by penril.com (4.1/SMI-4.0) id AA00278; Wed, 24 Jun 92 20:07:15 EDT Received: by Jaymes.penril.com (4.0/SMI-4.0) id AA16587; Wed, 24 Jun 92 20:02:18 EDT Date: Wed, 24 Jun 92 20:02:18 EDT From: laird@penril.com (Bruce Laird) Message-Id: <9206250002.AA16587@Jaymes.penril.com> To: ietf-ppp@ucdavis.ucdavis.edu, snmp-wg@nisc.psi.net Subject: MIB-II implementation questions Cc: eva@Jaymes.penril.com, jomama@Jaymes.penril.com, keith@Jaymes.penril.com, laird@penril.com Folks, I am speaking as a router vendor who is in the process of implementing MIB-II, plus support for five or six of the experimental MIBs that have sprung up for layer1 or layer2 transmission services/protocols (including ppp). I have several questions concerning Agent MIB implementation in that context: 1. What is the status of the MIB-II Transmission Group? It appears that MIB-II defines the existence of this group, but not much more. Is anyone implementing any objects for this group or is its purpose just to insure a relatively homogeneous approach to choosing prefix characters for the various experimental MIBs designed by autonomous WGs? A typical router these days is likely to support link protocols and physical interface types that could/should (soon must?) be instrumented with experimental MIBs for many of the following: Phys. Interface Link Protocol Real-world Combinations --------------- ------------ ----------------------- sync LAPB LAPB/sync RS232-like ppp ppp/{sync, RS232-like, HSSI} fracT1 Frame Relay FR/{fracT1, DS1, E1} DS1, E1 HDLC HDLC/{sync, HSSI} DS3 SDLC SDLC/{sync, DS1, E1} HSSI I am instrumenting more than one from Column A, and more than one from Column B - running contemporaneously in the same Agent. For instance, my router may have one interface running frame- relay/fracT1; another running LAPB/sync; several others running ppp/sync or ppp/T1. 2. Given that I am instrumenting more than one experimental and/or private layer2/layer1 MIB extension for a physical interface on my device, what is the proper way to structure ifEntries in the MIB-II ifTable object? My reading of the MIB-II RFC is: - I should have just one "row" in my ifTable for each physical interface. - If I am running a recognized "MIBed" link layer protocol on the interface, I should report for the "ifType" column in the interface's row, the integer value assigned in RFC-1213 (e.g. frame-relay=32). - If I am NOT running a recognized "MIBed" link layer protocol on the interface, but the interface uses a recognized medium, then I should report for the "ifType" column in the interface's row, the integer value assigned to that transmission medium in RFC-1213 (e.g. DS1=18). Have I got this right? Continuing, I can use the "ifSpecific" column for each entry to point to the head-end of *one* MIB extension that I have instrumented for the interface. (A nice way of letting network managers know what additional protocol or medium-specific info is available below the network layer for a given interface. 3. But, what do I do with ifSpecific if I have instrumented *multiple* independent MIBs below the network layer for the interface? (E.g. DS1 and ppp). Hopefully some defacto standard way of handling this last issue has emerged in the SNMP-oriented device vendor community. Otherwise, I pity the poor SNMP NMS vendors and End Users out there who will soon have to cope with a surprising variety of ad hoc, layer1/2 MIB Working Group-centric solutions to this problem. Perhaps one of you SNMP gurus out there can clear all of this up. Thanks in advance, Bruce Laird laird@penril.com Penril DataComm Networks, Inc (301) 921-8600 x8866 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jun 24 21:31:12 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22560; Wed, 24 Jun 92 21:23:36 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA21275; Wed, 24 Jun 92 12:30:41 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06039; Wed, 24 Jun 92 12:22:40 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05851; Wed, 24 Jun 92 12:15:20 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA06385; Wed, 24 Jun 92 12:14:29 PDT Date: Wed, 24 Jun 92 12:14:29 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9206241914.AA06385@ray.lloyd.com> To: brad@Cayman.COM Cc: bkc@omnigate.clarkson.edu, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: brad@Cayman.COM's message of Wed, 24 Jun 92 12:35:05 -0400 <9206241635.AA04914@haiti.Cayman.COM> Subject: splay compression comments (long) With regard to compression: wouldn't it make sense to support multiple dictionaries ala VJ header compression? VJ already keeps track of the TCP sessions. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jun 29 11:21:43 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02752; Mon, 29 Jun 92 11:17:29 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09296; Mon, 29 Jun 92 10:59:46 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01939; Mon, 29 Jun 92 10:51:33 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01698; Mon, 29 Jun 92 10:44:48 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA00467; Mon, 29 Jun 92 10:43:26 PDT Date: Mon, 29 Jun 92 10:43:26 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9206291743.AA00467@saffron.acc.com> To: stev@ftp.com Subject: Re: compress Cc: ietf-ppp@ucdavis.ucdavis.edu >> Network Working Group F Baker >> Internet Draft Troublemaker >> ^^^^^^^^^^^^ >> >> Boy! You sure got that right! :-) >> >> hey!, i'm not sure i have ever seen fred at one of the meetings! Surely you jest. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 30 13:52:17 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15834; Tue, 30 Jun 92 13:44:55 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA19523; Tue, 30 Jun 92 13:29:44 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15160; Tue, 30 Jun 92 13:21:35 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14887; Tue, 30 Jun 92 13:14:02 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA10641; Tue, 30 Jun 92 13:13:11 PDT Date: Tue, 30 Jun 92 13:13:11 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9206302013.AA10641@ray.lloyd.com> To: string.opt@ftp.com Cc: fbaker@acc.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: (stev knowles's message of Mon, 29 Jun 92 09:34:56 -0400 <9206291334.AA08146@ftp.com> Subject: compress Date: Mon, 29 Jun 92 09:34:56 -0400 From: stev@ftp.com (stev knowles) Reply-To: % Sender: stev@ftp.com Repository: babyoil.ftp.com Originating-Client: d-cell.ftp.com Network Working Group F Baker Internet Draft Troublemaker ^^^^^^^^^^^^ Boy! You sure got that right! :-) hey!, i'm not sure i have ever seen fred at one of the meetings! Well, he obviously should be invited along with Bill Simpson. Both are serious troublemakers and should be made members of the unofficial Troublemakers Working Group. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 30 14:13:49 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16478; Tue, 30 Jun 92 14:02:16 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA19551; Tue, 30 Jun 92 13:33:47 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15168; Tue, 30 Jun 92 13:21:48 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15011; Tue, 30 Jun 92 13:16:14 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA10656; Tue, 30 Jun 92 13:15:29 PDT Date: Tue, 30 Jun 92 13:15:29 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9206302015.AA10656@ray.lloyd.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: [jkrey@ISI.EDU: re: PPP number assignment requests] Comments people? Brian ------------------------------------------------- Return-Path: Date: Mon, 29 Jun 1992 09:46:12 -0700 From: jkrey@ISI.EDU Posted-Date: Mon, 29 Jun 1992 09:46:12 -0700 To: brian@lloyd.com Subject: re: PPP number assignment requests Cc: iana@ISI.EDU Brian, Enclosed are requests for PPP number assignments. Could you please review and comment. We are waiting on you for an answer. Thanks, Joyce and --jon. ----- Begin Included Message ----- >From bsimpson@angband.stanford.edu Fri Jun 26 07:45:28 1992 Date: Fri, 26 Jun 92 09:52:47 EDT From: "William Allen Simpson" To: iana@ISI.EDU Reply-To: bsimpson@angband.stanford.edu Subject: PPP OSI Inactive Network Layer Please assign the PPP Protocol Field number: OSI Inactive Network Layer 4023 This number matches the OSI Network Layer 0023 and the OSI Network Layer Control Protocol 8023 There is an internet-draft describing OSI over PPP. The inactive network layer should be low volume traffic, and I would like to begin the 4000 series. The official author of the OSI over PPP document is Dave Katz, formerly with Merit, now with cisco. Here's his new info, just in case he's not updated in whois: cisco Systems 1525 O'Brien Dr. Menlo Park, CA 94025 (415) 688-8284 Thanks. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com ----- End Included Message ----- ----- Begin Included Message ----- >From bsimpson@angband.stanford.edu Fri Jun 26 07:45:37 1992 Date: Fri, 26 Jun 92 10:10:10 EDT From: "William Allen Simpson" To: iana@ISI.EDU Reply-To: bsimpson@angband.stanford.edu Subject: PPP compression protocols We need several numbers for Fred Baker's latest internet-draft. In the PPP Protocol numbers, we need 4 high volume (00xx) protocols. Not all of these may last, since this is primarily for testing. I recommend assigning these experimental numbers from the high end, to keep them together. Zip Compression 00f7 Splay Tree Compression 00f9 Stacker Compression 00fb V.42bis Compression 00fd In addition, we need two more LCP configuration options: 10 Data-Compression-Protocol 11 LAPB-Numbered-Mode Here's Fred's listed data: Advanced Computer Communications 315 Bollay Drive Santa Barbara, California 93117 EMail: fbaker@acc.com Thanks, again. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com ----- End Included Message ----- From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 30 15:21:38 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18700; Tue, 30 Jun 92 15:11:16 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA20371; Tue, 30 Jun 92 14:50:15 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17747; Tue, 30 Jun 92 14:41:37 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from regal.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17279; Tue, 30 Jun 92 14:27:32 -0700 Received: by regal.cisco.com; Tue, 30 Jun 92 14:26:41 -0700 Date: Tue, 30 Jun 92 14:26:41 -0700 From: Dave Katz Message-Id: <9206302126.AA18396@regal.cisco.com> To: brian@lloyd.com Cc: ietf-ppp@ucdavis.ucdavis.edu, iana@isi.edu In-Reply-To: Brian Lloyd's message of Tue, 30 Jun 92 13:15:29 PDT <9206302015.AA10656@ray.lloyd.com> Subject: [jkrey@ISI.EDU: re: PPP number assignment requests] There's no reliable algorithmic method to determine what is running *over* the inactive network layer; the procedures for disambiguating TP from everything else really only work when an NSAP selector is present (which isn't, of course, with no network layer). It might be better to assign code points to TP and CLTP instead, but such decisions should really be left to somebody who is actually interested in this stuff enough to write a spec and an implementation. Has anyone stepped forward to take the lead on this? If not, I would recommend not assigning a code point at this time. Note that the Frame Relay people punted on this issue in the same way for nominally the same reasons--the use of x'00' for padding (which is the Inactive Network Layer's "NLPID") before the NLPID field. Please assign the PPP Protocol Field number: OSI Inactive Network Layer 4023 From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 30 16:04:30 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20226; Tue, 30 Jun 92 15:58:55 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA20883; Tue, 30 Jun 92 15:39:37 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19391; Tue, 30 Jun 92 15:30:37 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [129.192.64.32] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19139; Tue, 30 Jun 92 15:24:12 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA02633; Tue, 30 Jun 92 15:21:51 PDT Date: Tue, 30 Jun 92 15:21:51 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9206302221.AA02633@saffron.acc.com> To: brian@lloyd.com Subject: Re: [jkrey@ISI.EDU: re: PPP number assignment requests] Cc: ietf-ppp@ucdavis.ucdavis.edu, jkrey@ISI.EDU >> We need several numbers for Fred Baker's latest internet-draft. >> >> In the PPP Protocol numbers, we need 4 high volume (00xx) protocols. >> Not all of these may last, since this is primarily for testing. I >> recommend assigning these experimental numbers from the high end, to >> keep them together. >> >> Zip Compression 00f7 >> Splay Tree Compression 00f9 >> Stacker Compression 00fb >> V.42bis Compression 00fd May I suggest a better approach? (at least I think it's better): These numbers are used for the process that receives compressed datagrams; it decompresses them and then sends them to other processes; IP, etc. Since there is only one compression algorithm in use on any link, I think we should use one protocol ID (there's only 128 and some are reserved, we should preserve them) and use the compression option to negotiate what algorithm the compression engine uses. Hence: Protocol: >> 00FD Compressed Data LCP Option: >> 10 Data-Compression-Protocol Compression Algorithm Identifier 1 Zip Compression 2 Splay Tree 3 STAC DCS221-C 4 V.42bis LCP Option: >> 11 LAPB-Numbered-Mode From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jun 30 18:30:22 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25187; Tue, 30 Jun 92 18:28:45 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA22032; Tue, 30 Jun 92 18:09:38 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24356; Tue, 30 Jun 92 18:00:30 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from bridge2.NSD.3Com.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23938; Tue, 30 Jun 92 17:50:12 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA03113 (5.65c/IDA-1.4.4nsd for ); Tue, 30 Jun 1992 17:49:25 -0700 Received: by jaspar.NSD.3Com.COM id AA00405 (5.65c/IDA-1.4.4-910730); Tue, 30 Jun 1992 17:48:50 -0700 Date: Tue, 30 Jun 1992 17:48:50 -0700 From: "Cyndi M. Jung" Message-Id: <199207010048.AA00405@jaspar.NSD.3Com.COM> To: brian@lloyd.com, ietf-ppp@ucdavis.ucdavis.edu Subject: re: PPP number assignment requests Assigning a PPP Protocol Field Number to the OSI Inactive Network Layer seems a bit premature. If someone really has a case for it (more than an existence proof), then I can understand, but so far all I've seen is an isolated remark that such a thing exists - there has been more discussion around running X.25 over PPP than there has been about the OSI Inactive Network Layer (and I hope this isn't the time to assign a number for that). I think Fred made a good point about preserving the number space - OSI may need the 4000 series for some other low volume traffic. Cyndi Jung