From ietf-ppp-request@ucdavis.ucdavis.edu Tue Sep 1 20:52:28 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08664; Tue, 1 Sep 92 20:41:50 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA24530; Tue, 1 Sep 92 20:10:08 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07318; Tue, 1 Sep 92 20:00:24 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [134.22.80.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07041; Tue, 1 Sep 92 19:52:56 -0700 Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA02334; Tue, 1 Sep 92 22:52:48 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA21989; Tue, 1 Sep 92 22:52:44 EDT From: chris@gandalf.ca (Chris Sullivan) Message-Id: <9209020252.AA21989@cannibal.gandalf.ca> Subject: Re: lcp-ext text To: bill.simpson@um.cc.umich.edu (William Allen Simpson) Date: Tue, 1 Sep 92 22:52:43 EDT Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <682.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Sep 1, 92 12:49 pm X-Mailer: ELM [version 2.3 PL11] > If the option is Rejected, the peer MUST NOT add padding to such > protocols, but MAY add padding to other protocols. > > If the option is Ack'd, the peer MUST add at least one octet of > self-describing pad to such protocols, but is not required to add > unnecessary padding to other protocols. > > Each octet of self-describing pad contains the index of that > octet. After removing the FCS, the final octet contains the > number of pad octets to remove. If any of the pad octets contain > an incorrect index value, the entire frame SHOULD be silently > discarded. My memory is probably at fault, but I thought it was, if the option is Ack'd, at least one octet of pad will be added to *all* protocols; if it is Rejected, as it will be by existing implementations, then neither side acts on the proposal and the usual rules about padding apply (which BTW maybe it should be mentioned is the default behaviour for this option); and the signal that I'm not going to pad at all is that I Nak the option. This requires a value, so that I can propose an alternate in my Nak. So it could be: Value 01 = ON (I want to send/can accept Self-Describing Pad bytes) Value 02 = OFF (I want to send/am expecting from you only unpadded packets) If the value OFF is proposed in a Config Request, it does not require any Nak cycles, in order to come to agreement on not padding. Just an Ack with the OFF value. If compressed user data or some other non-self-delimiting packet type is to be negotiated once the authentication phase has been completed, this LCP option must have been proposed by the party wishing to send such packets and must have been Ack'd by the party which is to receive such packets. Of course if you really *want* to provide the choice of padding on a by- protocol basis, you might need the value descriptions to say something like ANY, NONE, and SOME. But I don't see the necessity. If I have to pad, I have to pad, and I'm probably unable to turn it off even when I would like to. So I'll ACK the value ON, or Reject (using my semantics). By "index" do you mean, starting at the end of the real user data the pad octets should contain the values 01, 02, 03...? Wouldn't it be easier, and require less cpu, if they *all* contained the number of octets to be removed? I'd happily strip the indicated number of octets once I had verified that some percentage of them were correctly identical, and wouldn't bother checking all. In fact, I'd probably believe just one of them if my FCS was correct. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris Sullivan "Musical innovation is full of Gandalf Data Limited danger to the State, for when chris@gandalf.ca the modes of music change, the laws of the State always change with them." Plato _Republic_ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From ietf-ppp-request@ucdavis.ucdavis.edu Wed Sep 2 07:30:58 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29739; Wed, 2 Sep 92 07:21:25 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA26732; Wed, 2 Sep 92 07:00:11 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28872; Wed, 2 Sep 92 06:50:28 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from relay1.UU.NET by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28749; Wed, 2 Sep 92 06:46:13 -0700 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA09319; Wed, 2 Sep 92 09:46:07 -0400 Received: from peernet.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 094555.18718; Wed, 2 Sep 1992 09:45:55 EDT Received: from dorothy.peer.com by peer.com (4.1/SMI-4.1) id AA08358; Tue, 1 Sep 92 19:40:43 PDT Received: from peer.com (peernet) by dorothy.peer.com (4.1/SMI-4.1) id AA05014; Tue, 1 Sep 92 19:40:42 PDT Date: Tue, 1 Sep 92 19:40:42 PDT From: peernet!dorothy!timon@uunet.UU.NET (Timon Sloane) Message-Id: <9209020240.AA05014@dorothy.peer.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: PPP & Bridging pkts I need some help. I've been looking for info on using PPP to connect half-bridges. While I've seen lots of indicators that a standard exists for using PPP for this purpose, I cannot seem to locate all the appropriate documents. I also don't have access to the mail archives on this list because I don't have internet ftp access. Can someone help me out? What is the complete list of standards (or internet drafts) I need to implement? Do any vendors have release or announced product I could use for interoperability testing? Thanks, timon From ietf-ppp-request@ucdavis.ucdavis.edu Wed Sep 2 07:31:06 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29854; Wed, 2 Sep 92 07:28:49 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA26783; Wed, 2 Sep 92 07:10:08 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29340; Wed, 2 Sep 92 07:05:54 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28918; Wed, 2 Sep 92 06:52:58 -0700 Received: by volitans.morningstar.com (5.65a/92042102) id AA04636; Wed, 2 Sep 92 09:52:49 -0400 Date: Wed, 2 Sep 92 09:52:49 -0400 From: Bob Sutterfield Message-Id: <9209021352.AA04636@volitans.morningstar.com> To: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: bill.simpson@um.cc.umich.edu's message of Tue, 1 Sep 92 12:49:08 EDT Subject: lcp-ext text Date: Tue, 1 Sep 92 12:49:08 EDT From: bill.simpson@um.cc.umich.edu ("William Allen Simpson") This document concerns the following values: 9 FCS-Alternatives 10 Self-Describing-Pad (What happened to 11 and 12?) 13 Callback 14 Connect-Time 2.1. FCS-Alternatives ... The null FCS option is most useful when the link is operating over an external source of error detection or correction, such as an error-correcting modem, Using an error-correcting modem isn't sufficient, because we still see plenty of bad frames that can be attributed to overruns in slow host UARTs and ancient OS serial I/O architectures. I think you should include a strongly worded Implementation Note pointing out that the user is taking his life in his own hands when running without FCS. Yes, you only said here that it's "most useful", but you should weaken that to "may be useful" or something similar. Yes, it's good to have the null-FCS option for those users who know what they want and why they want it, and are familiar and comfortable with the consequences (e.g. they're sophisticated enough to know and remember not to run NFS over non-checksummed UDP over SLIP or null-FCS PPP). But if you give a naive user enough rope, he'll invariably hang himself. With a strongly-worded warning, at least he'll have less basis on which to blame the protocol designers. or the network-layer protocols have an internal checksum available, such as TCP/IP with header compression. Header compression is irrelevant, it's the TCP or UDP checksum that you want them to depend upon. From ietf-ppp-request@ucdavis.ucdavis.edu Wed Sep 2 08:52:42 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02214; Wed, 2 Sep 92 08:47:51 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27424; Wed, 2 Sep 92 08:30:25 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01415; Wed, 2 Sep 92 08:21:38 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01232; Wed, 2 Sep 92 08:15:46 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA00913; Wed, 2 Sep 92 08:15:08 PDT Date: Wed, 2 Sep 92 08:15:08 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9209021515.AA00913@saffron.acc.com> To: peernet!dorothy!timon@uunet.UU.NET Subject: Re: PPP & Bridging pkts Cc: ietf-ppp@ucdavis.ucdavis.edu You might want to take a look at these. Yes, 3COM, ACC, Xyplex, ... there are a number of Bridge implementations over PPP. 1333 PPP link quality monitoring. Simpson, W.A. 1992 May; 15 p. (Format: TXT=29965 bytes) 1331 Point-to-Point Protocol (PPP) for the transmission of multi-protocol datagrams over point-to-point links. Simpson, W.A. 1992 May; 66 p. (Format: TXT=129892 bytes) (Obsoletes RFC 1171, RFC 1172) 1220 Point-to-Point Protocol Extensions for Bridging. Baker, F.,ed. 1991 April; 18 p. (Format: TXT=38165 bytes) From ietf-ppp-request@ucdavis.ucdavis.edu Sun Sep 6 16:30:40 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20742; Sun, 6 Sep 92 16:29:22 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA28710; Sun, 6 Sep 92 16:10:03 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20244; Sun, 6 Sep 92 16:00:24 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nero.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20134; Sun, 6 Sep 92 15:56:42 -0700 Received: by nero.clearpoint.com (4.1/1.34) id AA15458; Sun, 6 Sep 92 18:56:14 EDT Date: Sun, 6 Sep 92 18:56:14 EDT From: martillo@nero.clearpoint.com (Joachim Martillo) Message-Id: <9209062256.AA15458@nero.clearpoint.com> To: vjs@rhyolite.wpd.sgi.com Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Vernon Schryver's message of Sat, 20 Jun 92 18:34:52 -0600 <9206210034.AA01861@rhyolite.wpd.sgi.com> Subject: compress Sender: ietf-ppp-request@ucdavis.edu Date: Sat, 20 Jun 92 18:34:52 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) To: ietf-ppp@ucdavis.edu Subject: Re: compress 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.) Vernon Schryver, vjs@sgi.com Actually, you would only be testing the quality of the implementation and not necessarily whether LAPB is good. If the link is noisy, you would need X.25 for fragmentation. Many implementations handle such fragmentation via copies which might lower performance of the interface even though such copies are rarely necessary even in the case of a bridge where a packet might be flooded out several ether and x.25 interfaces even if the maximum packet sizes on the X.25 interfaces were less than the ether max packet size and were all different on each VC. Joachim Carlo Santos Martillo Ajami From ietf-ppp-request@ucdavis.ucdavis.edu Sun Sep 6 19:20:54 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24389; Sun, 6 Sep 92 19:18:01 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA29051; Sun, 6 Sep 92 19:00:03 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23792; Sun, 6 Sep 92 18:50:21 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from CAYMAN.CAYMAN.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23636; Sun, 6 Sep 92 18:43:12 -0700 Received: from stemwinder.UUCP by cayman.Cayman.COM (4.1/SMI-4.0) id AA25983; Sun, 6 Sep 92 21:43:17 EDT Received: from stemwinder by stemwinder (4.1/SMI-4.1) id AA00979; Sun, 6 Sep 92 21:13:39 EDT Message-Id: <9209070113.AA00979@stemwinder> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: compress In-Reply-To: Mail from nero.clearpoint.com!martillo@cayman.Cayman.COM (Joachim Martillo) dated Sun, 06 Sep 92 18:56:14 EDT <9209062256.AA15458@nero.clearpoint.com> Date: Sun, 06 Sep 92 21:13:39 -0400 From: Brad Parker [ note: don't reply my mailing address; I believe it's broken; brad@cayman.com does, however work. ] >> Sender: ietf-ppp-request@ucdavis.edu >> Date: Sat, 20 Jun 92 18:34:52 -0600 >> From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) >> To: ietf-ppp@ucdavis.edu >> Subject: Re: compress >> >> 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. >>... >> Actually, you would only be testing the quality of the implementation >> and not necessarily whether LAPB is good. If the link is noisy, you >> would need X.25 for fragmentation... I must confess to being less than knowledgable about this - perhaps Joachim, Vern or Fred can point me in the right direction. I like the idea of negotiating LAPB for a number of reasons (v.42bis being one ;-); The other is that some "higher level" protocols can take a big hit in performance from a single dropped packet (no flames - I only report the bad news). So, if one desires to support these less-than-tolerent protocols over PPP, and the PPP "pipe" drops packets (for whatever reason) the upper level protocols are left to retransmit. Which with fixes 2 second timeouts at 9600 can take a long time ;-( Speaking practically (because I would say a whole lot to the contrary from the theoretical side), it is "nice" to have a reliable link. If LAPB was negotiated to send the entire protocol frame (again, no flames), and used some strategy to make sure the packets got to the other side, the upper layer protocols would not need to practice their less-than-efficient behavior. This is a win from the practical "gosh, I'm just a user" side. I realize that smart modems do this, but assume for the moment that the link is just a lossy, slow, serial line. Does LAPB perform this function? (I realize it provides a reliable link - I don't know how it does this and how responsive it is or if it will carry an entire PPP frame) (and, on another note, is ISO3309-1984 ftp-able? How about ISO-7776? Am I forced to call Global Engineering? I tried archie and got nothing) Anyway, by using LAPB (as proposed) will I get the effect I am trying to describe above? (i.e. will dropped PPP frames be retransmitted by the LAPB "protocol" in a timely manner?) -brad From ietf-ppp-request@ucdavis.ucdavis.edu Sun Sep 6 22:20:12 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28292; Sun, 6 Sep 92 22:16:31 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA29394; Sun, 6 Sep 92 22:00:10 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27762; Sun, 6 Sep 92 21:50:07 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from FENNEL.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27720; Sun, 6 Sep 92 21:47:29 -0700 Received: by fennel.acc.com (4.1/SMI-4.1) id AA12389; Sun, 6 Sep 92 21:47:22 PDT Date: Sun, 6 Sep 92 21:47:22 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9209070447.AA12389@fennel.acc.com> To: brad@cayman.com Subject: Re: compress Cc: ietf-ppp@ucdavis.ucdavis.edu >> Anyway, by using LAPB (as proposed) will I get the effect I am >> trying to describe above? (i.e. will dropped PPP frames be >> retransmitted by the LAPB "protocol" in a timely manner?) Brad: You should be aware that I only proposed LAPB usage in two contexts: (1) when multiple links are used in an inverse multiplexing application that is message sequence sensitive (ISO 7776 MultiLink used to support VJ Compressed or Bridged traffic) (2) when using a compression algorithm on the link in which the loss or reordering of compressed traffic can result in loss of synchronization between the sender and the receiver. The timeliness of LAPB is largely a question of its parameterization and your definitions. It can be MUCH better than the application's own timeouts, or it can exacerbate a problem. LAPB, as Vern is apt to point out, is neither free nor a solution for all problems. If the end to end retransmission period of an application approximates the link layer retransmission period of a LAPB implementation, the bad side of a fuzzy link can be magnified immensely. However, it solves the two problems above quite handily. Note that this is not an issue of measurement and experimentation. LAT, a protocol commonly bridged, will reset all virtual circuits between a remote station and itself if it receives a message from the remote out of sequence. You can measure yourself blue in the face if you care to; most of us are able to work out that an inverse multiplexor resequences traffic, absent an algorithm to avoid it, without inconveniencing our customers. I shudder to think what would happen to VJ compressed data on an inverse multiplexed link where message sequence was ignored. The same logic holds for compressed data; if the receiving side must receive the sender's data exactly and in the order that the sender sent it to maintain its database - something true of virtually all worthwhile compression algorithms - then an unreliable link is inadequate. This is determinable without resort to experimentation, though someone could probably earn a master's thesis proving the obvious if he chose to. I really don't care to continue this conversation absent new proposals or new data. Joachim has never particularly shown himself interested in consensus or solution of problems, and he cites a debate between Vernon and I which greatly saddened me. I respect Vernon a lot and have learned much from his opinions in the past; on this particular subject, I believe it would be safe to say that we strongly disagree, and that neither he nor Joachim has offered a viable alternative to my proposal. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Sun Sep 6 23:40:21 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29976; Sun, 6 Sep 92 23:35:58 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA29542; Sun, 6 Sep 92 23:20:03 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29350; Sun, 6 Sep 92 23:10:09 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29153; Sun, 6 Sep 92 23:00:53 -0700 Received: from harry.lloyd.com. by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA07575; Sun, 6 Sep 92 23:00:33 PDT Date: Sun, 6 Sep 92 23:00:33 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9209070600.AA07575@ray.lloyd.com> Received: by harry.lloyd.com. (4.1/SMI-4.1) id AA01325; Sun, 6 Sep 92 23:00:33 PDT To: vjs@rhyolite.wpd.sgi.com Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Joachim Martillo's message of Sun, 6 Sep 92 18:56:14 EDT <9209062256.AA15458@nero.clearpoint.com> Subject: compress I spent many years running IP in UI frames (very much like PPP) and over LAPB. This is how IP is run in amateur packet radio. In fact, KA9Q includes IP over UI frames or within LABP (both as part of his AX.25 implementation -- AX.25 being LAPB with source and destination addresses so that it can be used on a shared channel). The results are suprising. LAPB was valuable in only a small set of conditions, wherein the BER was high enough that intranetwork fragmentation allowed the transmission of smaller frames to minimize the loss rate in spite of the increased overhead. In all other cases the link was either too bad to support communications or the overhead associated with LAPB decreased throughput relative to IP/TCP within UI frames. Needless to say, the BERs where LAPB was advantageous were orders of magnitude higher than any rational datacomm manager would accept from a TELCO line (we considered ourselves lucky to have BERs of less that 10e-4 and 10e-5 was heaven). The key point here is that we are adding LAPB to PPP for its other features, not because it is going to improve throughput. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 fax (916) 676-3442 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Sep 7 08:30:33 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15208; Mon, 7 Sep 92 08:25:29 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA00790; Mon, 7 Sep 92 08:00:03 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14501; Mon, 7 Sep 92 07:50:48 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SGI.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14296; Mon, 7 Sep 92 07:42:16 -0700 Received: by sgi.sgi.com (920330.SGI/910110.SGI) for ietf-ppp@ucdavis.edu id AA20084; Mon, 7 Sep 92 07:42:05 -0700 To: ietf-ppp@ucdavis.ucdavis.edu X-Approved: newsmail@sgi.sgi.com From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Subject: Re: compress Message-Id: Date: Mon, 7 Sep 1992 14:38:24 GMT In article , brian@lloyd.com (Brian Lloyd) writes: > ... > The key point here is that we are adding LAPB to PPP for its other > features, not because it is going to improve throughput. > ... The recent message from Joachim Carlo Santos Martillo Ajamii contained some of my arguments from June, somewhat out of context. I was arguing that at low speeds <= 19.2Kb/s, where CPU cycles do not matter regardless of the inefficency of the implementation and where all that matters is link bandwidth, LAPB might not be a good deal. I think at the time I was also arguing that LAPB is not needed for link-layer compression. I don't remember for certain, but I think that the existent "splay-tree-VJ-compress" PPP implementations were pointed at about that time. With Fred, I think that discussion was long enough. I see no need to re-open it before there are implementations to compare, and perhaps not even then. Vernon Schryver, vjs@sgi.om From ietf-ppp-request@ucdavis.ucdavis.edu Thu Sep 10 12:45:32 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25388; Thu, 10 Sep 92 12:39:22 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25110; Thu, 10 Sep 92 11:12:18 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22296; Thu, 10 Sep 92 11:08:36 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from gateway.morgan.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21702; Thu, 10 Sep 92 10:47:35 -0700 Received: from is11.is.morgan.com ([138.20.93.11]) by gateway.morgan.com with SMTP id <41389>; Thu, 10 Sep 1992 13:47:13 -0400 Received: by is11.is.morgan.com (4.1/is.morgan.com 1.0) id AA16217; Thu, 10 Sep 92 13:47:08 EDT Date: Thu, 10 Sep 1992 13:47:08 -0400 From: jae@is.morgan.com (Jae Sang) Message-Id: <9209101747.AA16217@is11.is.morgan.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: mailing list removal request please remove me from this mailing list. thanks. From ietf-ppp-request@ucdavis.ucdavis.edu Thu Sep 10 16:11:47 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02174; Thu, 10 Sep 92 15:57:19 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27777; Thu, 10 Sep 92 15:20:17 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00746; Thu, 10 Sep 92 15:14:48 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00351; Thu, 10 Sep 92 15:03:07 -0700 Received: from na.novell.com (na.SJF.Novell.COM) by newsun.novell.com with SMTP id AA13559 (5.65c/IDA-1.4.4 for ); Thu, 10 Sep 1992 15:02:50 -0700 Received: by na.novell.com (4.1/SMI-4.1) id AA26914; Thu, 10 Sep 92 15:05:47 PDT Date: Thu, 10 Sep 92 15:05:47 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9209102205.AA26914@na.novell.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: IPXWAN is rfc1362 Hi Y'all, Just off the net: Chris Date: Thu, 10 Sep 92 13:44:40 PDT From: jkrey@isi.edu To: ietf@isi.edu, rfc-dist@nic.ddn.mil Subject: RFC1362 on IPXWAN Cc: jkrey@isi.edu A new Request for Comments is now available in online RFC libraries. RFC 1362: Title: Novell IPX Over Various WAN Media (IPXWAN) Author: M. Allen Mailbox: MALLEN@NOVELL.COM Pages: 13 Characters: 30,219 Updates/Obsoletes: none This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@NRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-REQUEST@NIC.DDN.MIL. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to "rfc-info@ISI.EDU" with the message body "help: ways_to_get_rfcs". For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to NIC@NIC.DDN.MIL. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1111, "Instructions to RFC Authors", for further information. Joyce K. Reynolds USC/Information Sciences Institute ====================================================================== From ietf-ppp-request@ucdavis.ucdavis.edu Fri Sep 11 12:52:06 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08449; Fri, 11 Sep 92 12:48:11 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06828; Fri, 11 Sep 92 12:11:05 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07205; Fri, 11 Sep 92 12:07:48 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [138.20.30.3] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06861; Fri, 11 Sep 92 11:54:02 -0700 Received: from is11.is.morgan.com ([138.20.93.11]) by gateway.morgan.com with SMTP id <41393>; Fri, 11 Sep 1992 14:52:29 -0400 Received: by is11.is.morgan.com (4.1/is.morgan.com 1.0) id AA04534; Fri, 11 Sep 92 14:52:27 EDT Date: Fri, 11 Sep 1992 14:52:27 -0400 From: datk@is.morgan.com (Dave Atkinson) Message-Id: <9209111852.AA04534@is11.is.morgan.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: remove me please please remove me from the ppp mailing list.. thanks. datk@is.morgan.com From ietf-ppp-request@ucdavis.ucdavis.edu Sun Sep 13 15:40:24 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23361; Sun, 13 Sep 92 15:34:28 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA15588; Sun, 13 Sep 92 15:20:05 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22670; Sun, 13 Sep 92 15:10:16 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nero.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22459; Sun, 13 Sep 92 15:02:22 -0700 Received: by nero.clearpoint.com (4.1/1.34) id AA03404; Sun, 13 Sep 92 18:01:52 EDT Date: Sun, 13 Sep 92 18:01:52 EDT From: martillo@nero.clearpoint.com (Joachim Martillo) Message-Id: <9209132201.AA03404@nero.clearpoint.com> To: fbaker@acc.com Cc: jnc@ginger.lcs.mit.edu, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Fred Baker's message of Mon, 22 Jun 92 09:24:31 PDT <9206221624.AA00403@saffron.acc.com> Subject: compress To: jnc@ginger.lcs.mit.edu Subject: Re: compress >> 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. Some forms of compression are like re-encoding according to a dictionary in which common patterns are assigned shorter encodings while less common ones get longer encodings or transmitted without re-encoding but perhaps with preceding and succeeding "escape sequences." But the simplest form of compression which removes repeats does not correspond to this model. 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. With repeat-based compression schemes there is no need to keep "dictionaries" nor is there a need for a reliable virtual data link. The key to good performance at low cost in bridging and routing systems is the avoidance of buffer copies. (Otherwise more expensive more power microprocessors and faster more expensive memories are required.) Any compression scheme which requires buffer copies is probably bad from the standpoint of bridging or routing. Because any compression scheme which required the use of LAPB for reliability would probably be doing buffer copies, any such compression scheme would probably be bad from the standpoint of bridges or routers. Fred Joachim Carlo Santos Martillo Ajami From ietf-ppp-request@ucdavis.ucdavis.edu Sun Sep 13 16:40:25 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26026; Sun, 13 Sep 92 16:35:03 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA15702; Sun, 13 Sep 92 16:20:05 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25023; Sun, 13 Sep 92 16:10:28 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from bridge2.NSD.3Com.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24628; Sun, 13 Sep 92 16:01:21 -0700 Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA07118 (5.65c/IDA-1.4.4nsd for ); Sun, 13 Sep 1992 16:00:53 -0700 Received: by jaspar.NSD.3Com.COM id AA02537 (5.65c/IDA-1.4.4-910730); Sun, 13 Sep 1992 16:00:51 -0700 Date: Sun, 13 Sep 1992 16:00:51 -0700 From: "Cyndi M. Jung" Message-Id: <199209132300.AA02537@jaspar.NSD.3Com.COM> To: martillo@nero.clearpoint.com Subject: Re: compress Cc: ietf-ppp@ucdavis.ucdavis.edu > Any compression scheme which requires buffer copies is >probably bad from the standpoint of bridging or routing. Because any >compression scheme which required the use of LAPB for reliability >would probably be doing buffer copies, any such compression scheme >would probably be bad from the standpoint of bridges or routers. The situation the LAPB and dictionary-based compression is trying to address is one where the line speed is the bottleneck and the CPU has plenty of cycles to spare. You wouldn't do this when the CPU is precious and the line has lots of extra flags between frames. From ietf-ppp-request@ucdavis.ucdavis.edu Mon Sep 14 09:32:13 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03989; Mon, 14 Sep 92 09:21:10 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18717; Mon, 14 Sep 92 09:00:21 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02659; Mon, 14 Sep 92 08:51:46 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from OPAL.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01773; Mon, 14 Sep 92 08:34:26 -0700 Received: by opal.acc.com (4.1/SMI-4.0) id AA00891; Mon, 14 Sep 92 08:35:45 PDT Date: Mon, 14 Sep 92 08:35:45 PDT From: art@opal.acc.com (Art Berggreen) Message-Id: <9209141535.AA00891@opal.acc.com> To: fbaker@opal.acc.com, martillo@nero.clearpoint.com Subject: Re: compress Cc: ietf-ppp@ucdavis.ucdavis.edu > 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. > >With repeat-based compression schemes there is no need to keep >"dictionaries" nor is there a need for a reliable virtual data link. RLE (Run Length Encoding) algorithms may be simple, but for most of the kinds of data found on computer networks they don't provide very interesting compression ratios. > > >The key to good performance at low cost in bridging and routing >systems is the avoidance of buffer copies. (Otherwise more expensive >more power microprocessors and faster more expensive memories are >required.) Any compression scheme which requires buffer copies is >probably bad from the standpoint of bridging or routing. Because any >compression scheme which required the use of LAPB for reliability >would probably be doing buffer copies, any such compression scheme >would probably be bad from the standpoint of bridges or routers. The key to low cost for the customer is very often minimizing the recurring costs that the communications links represent. The cost of the bridge/router is often insignificant over its life cycle compared to other costs. It's not difficult to build an inexpensive bridge/router which can employ modern, adaptive compression algorithms and keep up with a 64Kb/s link. Certainly, more expensive, but easily done with current technology is supporting multiple compressed T1 links. T1 links may have dropped significantly in cost, but any significant mesh is still very expensive. This is one reason why Frame Relay SMDS and even ATM technologies are getting so much attention. > Fred > >Joachim Carlo Santos Martillo Ajami Art From ietf-ppp-request@ucdavis.ucdavis.edu Wed Sep 16 05:31:54 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14380; Wed, 16 Sep 92 05:27:10 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09507; Wed, 16 Sep 92 05:00:07 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14070; Wed, 16 Sep 92 04:50:13 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nero.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13982; Wed, 16 Sep 92 04:42:35 -0700 Received: by nero.clearpoint.com (4.1/1.34) id AA21333; Wed, 16 Sep 92 07:42:03 EDT Date: Wed, 16 Sep 92 07:42:03 EDT From: martillo@nero.clearpoint.com (Joachim Martillo) Message-Id: <9209161142.AA21333@nero.clearpoint.com> To: cmj@nsd.3com.com Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: "Cyndi M. Jung"'s message of Sun, 13 Sep 1992 16:00:51 -0700 <199209132300.AA02537@jaspar.NSD.3Com.COM> Subject: compress Sender: ietf-ppp-request@ucdavis.edu Date: Sun, 13 Sep 1992 16:00:51 -0700 From: "Cyndi M. Jung" To: martillo@nero.clearpoint.com Subject: Re: compress Cc: ietf-ppp@ucdavis.edu > Any compression scheme which requires buffer copies is >probably bad from the standpoint of bridging or routing. Because any >compression scheme which required the use of LAPB for reliability >would probably be doing buffer copies, any such compression scheme >would probably be bad from the standpoint of bridges or routers. The situation the LAPB and dictionary-based compression is trying to address is one where the line speed is the bottleneck and the CPU has plenty of cycles to spare. You wouldn't do this when the CPU is precious and the line has lots of extra flags between frames. Do existing WAN-LAN transparent bridges have lots of cycles to spare? If a company were building a LAN-WAN bridge and there were lots of cycles left over, it might be better from a marketing standpoint to add another LAN port than to use these cycles for compression on the WAN link, at which point the bridge might be cycle starved rather than cycle rich. Joachim Carlo Santos Martillo Ajami From ietf-ppp-request@ucdavis.ucdavis.edu Wed Sep 16 07:23:35 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15876; Wed, 16 Sep 92 07:19:07 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10133; Wed, 16 Sep 92 06:50:11 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15388; Wed, 16 Sep 92 06:41:37 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nero.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15337; Wed, 16 Sep 92 06:34:21 -0700 Received: by nero.clearpoint.com (4.1/1.34) id AA21789; Wed, 16 Sep 92 09:33:54 EDT Date: Wed, 16 Sep 92 09:33:54 EDT From: martillo@nero.clearpoint.com (Joachim Martillo) Message-Id: <9209161333.AA21789@nero.clearpoint.com> To: martillo@nero.clearpoint.com Cc: cmj@nsd.3com.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Joachim Martillo's message of Wed, 16 Sep 92 07:42:03 EDT <9209161142.AA21333@nero.clearpoint.com> Subject: compress Sender: ietf-ppp-request@ucdavis.edu Date: Wed, 16 Sep 92 07:42:03 EDT From: martillo@nero.clearpoint.com (Joachim Martillo) To: cmj@nsd.3com.com Cc: ietf-ppp@ucdavis.edu In-Reply-To: "Cyndi M. Jung"'s message of Sun, 13 Sep 1992 16:00:51 -0700 <199209132300.AA02537@jaspar.NSD.3Com.COM> Subject: compress Sender: ietf-ppp-request@ucdavis.edu Date: Sun, 13 Sep 1992 16:00:51 -0700 From: "Cyndi M. Jung" To: martillo@nero.clearpoint.com Subject: Re: compress Cc: ietf-ppp@ucdavis.edu > Any compression scheme which requires buffer copies is >probably bad from the standpoint of bridging or routing. Because any >compression scheme which required the use of LAPB for reliability >would probably be doing buffer copies, any such compression scheme >would probably be bad from the standpoint of bridges or routers. The situation the LAPB and dictionary-based compression is trying to address is one where the line speed is the bottleneck and the CPU has plenty of cycles to spare. You wouldn't do this when the CPU is precious and the line has lots of extra flags between frames. Do existing WAN-LAN transparent bridges have lots of cycles to spare? If a company were building a LAN-WAN bridge and there were lots of cycles left over, it might be better from a marketing standpoint to add another LAN port than to use these cycles for compression on the WAN link, at which point the bridge might be cycle starved rather than cycle rich. Joachim Carlo Santos Martillo Ajami Actually, the question might be better posed, "should one architect software and design protocol specs as if there are cycles to spare." I would argue such architecture is improper, because if one architects in such a way, one will invariably require more expensive hardware and will probably loose in competition with a manufacturer whose engineers know how to design in a cycle scarce environment and who can therefore produce equal or better performance with less expensive hardware or who with comparable hardware will supply many more features. Of course, when I was at Prime, the dominant architecture practice, which irritated me endlessly, was to design as if there were cycles to spare. I just read that Prime manufacturing has shutdown, and all but the Prime Computervision division has been jettisoned, and this division has been renamed Computervision, which is all that remains. Of course, Computervision software was developed in isolation from the rest of the Prime software base. In the case of compression standards, it might be possible to specify forms of compression which spare computer cycles while satisfying 90-95% of customer needs. The other 5-10% of the cases, which require expensive specialized forms of compression, might best be served by special purpose non-standardized techniques. Joachim Carlo Santos Martillo Ajami From ietf-ppp-request@ucdavis.ucdavis.edu Wed Sep 16 07:37:06 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15946; Wed, 16 Sep 92 07:29:58 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10210; Wed, 16 Sep 92 07:00:37 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15587; Wed, 16 Sep 92 06:59:39 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from CAYMAN.CAYMAN.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15410; Wed, 16 Sep 92 06:43:40 -0700 Received: from stemwinder.UUCP by cayman.Cayman.COM (4.1/SMI-4.0) id AA13992; Wed, 16 Sep 92 09:43:41 EDT Received: from stemwinder by stemwinder (4.1/SMI-4.1) id AA20064; Wed, 16 Sep 92 09:18:29 EDT Message-Id: <9209161318.AA20064@stemwinder> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: COMPRESS In-Reply-To: Mail from donut.gandalf.ca!dcarr@cayman.Cayman.COM (Dave Carr) dated Tue, 15 Sep 92 12:07:50 EDT <9209151607.AA03847@donut.gandalf.ca.adg.gandalf.ca> Date: Wed, 16 Sep 92 09:18:28 -0400 From: Brad Parker Thank you Dave Carr & Cyndi Jung... I just love this list. Just when I think I have to say something (on this list), it gets said. ;-) -brad From ietf-ppp-request@ucdavis.ucdavis.edu Wed Sep 16 10:13:17 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17368; Wed, 16 Sep 92 08:57:44 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10808; Wed, 16 Sep 92 08:01:28 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16286; Wed, 16 Sep 92 07:53:02 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from hobbit.gandalf.ca by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16156; Wed, 16 Sep 92 07:44:43 -0700 Received: from donut.gandalf.ca.adg.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA01756; Wed, 16 Sep 92 10:44:13 EDT Received: by donut.gandalf.ca.adg.gandalf.ca (4.1/SMI-4.1) id AA04889; Wed, 16 Sep 92 10:44:11 EDT From: dcarr@donut.gandalf.ca (Dave Carr) Message-Id: <9209161444.AA04889@donut.gandalf.ca.adg.gandalf.ca> Subject: Re: compress To: ietf-ppp@ucdavis.ucdavis.edu Date: Wed, 16 Sep 92 10:44:10 EDT In-Reply-To: <9209161333.AA21789@nero.clearpoint.com>; from "Joachim Martillo" at Sep 16, 92 9:33 am X-Mailer: ELM [version 2.3 PL11] > Do existing WAN-LAN transparent bridges have lots of cycles to spare? > If a company were building a LAN-WAN bridge and there were lots of > cycles left over, it might be better from a marketing standpoint to > add another LAN port than to use these cycles for compression on the > WAN link, at which point the bridge might be cycle starved rather than > cycle rich. > > Joachim Carlo Santos Martillo Ajami > > Actually, the question might be better posed, "should one architect > software and design protocol specs as if there are cycles to spare." > I would argue such architecture is improper, because if one architects > in such a way, one will invariably require more expensive hardware and > will probably loose in competition with a manufacturer whose engineers > know how to design in a cycle scarce environment and who can therefore > produce equal or better performance with less expensive hardware or > who with comparable hardware will supply many more features. > > In the case of compression standards, it might be possible to specify > forms of compression which spare computer cycles while satisfying > 90-95% of customer needs. The other 5-10% of the cases, which require > expensive specialized forms of compression, might best be served by > special purpose non-standardized techniques. Sound good in theory, but I've done projects both ways. If you shoe- string an application into just the right amount of CPU, it will take you longer to get to market. You spend the last 2 months getting it running fast enough. With 20-30% CPU to spare, you don't get held up tuning. You get to market sooner. Also, the CPU represents a small cost of the bridge. In our case, we could probably save $40/bridge for a less powerful CPU, but on a $2000+ product why bother. Now if the sell price was $400, I might get concerned. Finally, the our bridge has 2 particular modes where the CPU has just the right amount of CPU, 128 Kbps compressed, or T1 uncompressed. Since these are the 2 intended markets, I'd say we met the marketting requirements. -- 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 Sep 16 14:51:46 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28705; Wed, 16 Sep 92 14:36:46 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14685; Wed, 16 Sep 92 12:40:42 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24381; Wed, 16 Sep 92 12:31:58 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from bridge2.NSD.3Com.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23984; Wed, 16 Sep 92 12:21:36 -0700 Received: from himagiri.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA27861 (5.65c/IDA-1.4.4nsd for ); Wed, 16 Sep 1992 12:21:12 -0700 Received: from localhost.NSD.3Com.COM by himagiri.NSD.3Com.COM with SMTP id AA24157 (5.65c/IDA-1.4.4-910725 for ); Wed, 16 Sep 1992 12:21:08 -0700 Message-Id: <199209161921.AA24157@himagiri.NSD.3Com.COM> To: ietf-ppp@ucdavis.ucdavis.edu Cc: vsp@NSD.3Com.COM Subject: Re: compress Organization: 3Com, 5400 Bayfront Plaza, Santa Clara, CA 95052-8145 Phone.......: (408) 764-5226 (Office) (408) 764-5000 (General Office) In-Reply-To: Mail from dcarr@donut.gandalf.ca (Dave Carr) dated Wed, 16 Sep 92 10:44:10 EDT <9209161444.AA04889@donut.gandalf.ca.adg.gandalf.ca> Date: Wed, 16 Sep 92 12:21:07 -0700 From: Venkat Prasad I think we have gone this route once... Architects design products both ways. Some design with cpu cyles to spare so that they can get in the bells and whistles later. Some design using up the last cpu cycle available to get the best out of the investment. If it is the former then definitely the spare cpu cylces can be used for data compression. If it is the later then compression can be turned on a situation basis. Ex: Let's say there is a bridge/router that uses up all the cpu cycles in keeping up with an ethernet and a T1 interface at full speed. A customer buys it but really wants to use it in a ethernet and 64K set up. However he/she wants to get more out of 64K so turns on compression and gets 128K. As his/her requirements grow he/she will finally upgrade to a T1 link and turn off compression. I do not see an *optional* compression on a bridge/router as being a handicap. /Prasad >On Wed, 16 Sep 92 10:44:10 EDT, dcarr@donut.gandalf.ca (Dave Carr) said: > Do existing WAN-LAN transparent bridges have lots of cycles to spare? > If a company were building a LAN-WAN bridge and there were lots of > cycles left over, it might be better from a marketing standpoint to > add another LAN port than to use these cycles for compression on the > WAN link, at which point the bridge might be cycle starved rather than > cycle rich. > > Joachim Carlo Santos Martillo Ajami > > Actually, the question might be better posed, "should one architect > software and design protocol specs as if there are cycles to spare." > I would argue such architecture is improper, because if one architects > in such a way, one will invariably require more expensive hardware and > will probably loose in competition with a manufacturer whose engineers > know how to design in a cycle scarce environment and who can therefore > produce equal or better performance with less expensive hardware or > who with comparable hardware will supply many more features. > > In the case of compression standards, it might be possible to specify > forms of compression which spare computer cycles while satisfying > 90-95% of customer needs. The other 5-10% of the cases, which require > expensive specialized forms of compression, might best be served by > special purpose non-standardized techniques. >> Sound good in theory, but I've done projects both ways. If you shoe- >> string an application into just the right amount of CPU, it will take >> you longer to get to market. You spend the last 2 months getting it >> running fast enough. With 20-30% CPU to spare, you don't get held up >> tuning. You get to market sooner. >> Also, the CPU represents a small cost of the bridge. In our case, >> we could probably save $40/bridge for a less powerful CPU, but on >> a $2000+ product why bother. Now if the sell price was $400, I >> might get concerned. >> Finally, the our bridge has 2 particular modes where the CPU has just >> the right amount of CPU, 128 Kbps compressed, or T1 uncompressed. >> Since these are the 2 intended markets, I'd say we met the marketting >> requirements. >> >> -- >> 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 Sep 16 16:03:28 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01651; Wed, 16 Sep 92 15:54:47 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17100; Wed, 16 Sep 92 15:40:09 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00966; Wed, 16 Sep 92 15:36:23 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SGI.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00507; Wed, 16 Sep 92 15:25:14 -0700 Received: by sgi.sgi.com (920330.SGI/910110.SGI) id AA18514; Wed, 16 Sep 92 15:21:12 -0700 To: ietf-ppp@ucdavis.ucdavis.edu X-Approved: newsmail@sgi.sgi.com From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Subject: Re: COMPRESS Message-Id: Date: Wed, 16 Sep 1992 22:04:53 GMT dcarr@donut.gandalf.ca (Dave Carr) writes: > ... > Finally, LZ77, LZA, LZSS all can be run over an unreliable link. But, > history information can only come from the current packet. That is, > compression must be done on one packet at a time, with a dictionary > reset between packets. > ... There are reports of implementations of PPP that demonstrate that this statement is not true. Those implementations use the VJ header prediction notion to figure out state on links supporting several different simultaneous conversations, and this state is used to compress and decompress packets. I'm not trying to re-open that argument. The details should be in the archives. Vernon Schryver, vjs@sgi.com From ietf-ppp-request@ucdavis.ucdavis.edu Fri Sep 18 11:43:54 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01335; Fri, 18 Sep 92 11:39:37 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05438; Fri, 18 Sep 92 11:10:06 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29956; Fri, 18 Sep 92 11:02:23 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [143.191.3.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29715; Fri, 18 Sep 92 10:56:31 -0700 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-920708) id AA03154 to ietf-ppp@ucdavis.edu; Fri, 18 Sep 92 10:55:35 PDT Received: from yoyo.telebit.com by napa.TELEBIT.COM (4.1/napa.telebit.com-Brent-920717) id AA06981 to ietf-ppp@ucdavis.edu; Fri, 18 Sep 92 10:55:32 PDT Date: Fri, 18 Sep 92 10:55:32 PDT From: mlewis@napa.Telebit.COM (Mark S. Lewis) Message-Id: <9209181755.AA06981@napa.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA28484; Fri, 18 Sep 92 10:55:44 PDT To: ietf-ppp@ucdavis.ucdavis.edu Subject: IPXCP Status We want to stimulate some discussion about the status of IPXCP. Bill is working on this and we would like to provide some input. Telebit is field testing a version of code that implements IPXCP. Since there has been little convergence on IPXCP options, we would like to suggest the following: NUMBER OPTION 1 IPX-Network-Number 2 IPX-Node-Number 3 IPX-Routing-Protocol 4 IPX-Header-Compression 5 IPX-Router-Name This scheme is based on Bill's recent IPXCP draft, the older Shiva drafts, and some recent discussion. We suggest splitting address negotiation into IPX-Network-Number and IPX-Node-Number. We suggest minor changes in renumber and renaming as above. It is important to us that we nail this down, because we are going to ship soon. Please comment or forever hold your peace. ... 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 Sat Sep 19 14:20:40 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04115; Sat, 19 Sep 92 14:16:42 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA12108; Sat, 19 Sep 92 14:00:21 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03347; Sat, 19 Sep 92 13:51:53 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03169; Sat, 19 Sep 92 13:45:21 -0700 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA01933; Sat, 19 Sep 92 13:45:03 -0700 Date: Sat, 19 Sep 92 16:05:36 EDT From: "William Allen Simpson" Message-Id: <734.bill.simpson@um.cc.umich.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: IPXCP Status > From: mlewis@napa.Telebit.COM (Mark S. Lewis) > It is important to us that we nail this down, because we are going to > ship soon. Please comment or forever hold your peace. > How many other people have actually implemented this stuff? 1) Who is shipping IPXCP with options? 2) Who is shipping IPXWAN? 3) Who is shipping an IPX or NCP/IPX compression scheme? 4) Is anyone planning on doing IPXCP without IPXWAN? I entered into this to try to build a consensus because people were beta-testing completely incompatible versions. Shiva and Novell weren't converging. (The list of option numbers that Telebit just listed is not the one currently in beta test there, and both their versions are different than any of the various drafts.) When we started, IPXCP and IPXWAN had very few options in common, and Novell was pretty belligerent about "their" protocol. Now Novell has gotten a lot friendlier (at least some of them have), are involved with the IETF, and published an IPXWAN which includes *every* feature that we have in IPXCP. They even added a reference to a Telebit Compression Option. I'm looking for a good reason not to just scrap IPXCP, and go with IPXWAN. The only thing that I think of is a possible header compression option which would require PPP protocol numbers (IPXWAN can't do that), or the *need* to have IPXCP *without* IPXWAN. The deadline for a response is Friday, Sept 25, 1992. Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Sun Sep 20 13:20:35 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03729; Sun, 20 Sep 92 13:11:09 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA15479; Sun, 20 Sep 92 12:50:23 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02433; Sun, 20 Sep 92 12:40:15 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02252; Sun, 20 Sep 92 12:35:04 -0700 Received: from na.novell.com (na.SJF.Novell.COM) by newsun.novell.com with SMTP id AA12364 (5.65c/IDA-1.4.4 for ); Sun, 20 Sep 1992 12:34:44 -0700 Received: by na.novell.com (4.1/SMI-4.1) id AA18027; Sun, 20 Sep 92 12:37:48 PDT Date: Sun, 20 Sep 92 12:37:48 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9209201937.AA18027@na.novell.com> To: bill.simpson@um.cc.umich.edu, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: IPXCP Status Hi Y'all, > From: "William Allen Simpson" > > > From: mlewis@napa.Telebit.COM (Mark S. Lewis) > > It is important to us that we nail this down, because we are going to > > ship soon. Please comment or forever hold your peace. > > > How many other people have actually implemented this stuff? > > 1) Who is shipping IPXCP with options? Not us ;). > 2) Who is shipping IPXWAN? We are, and will for the forseeable future. > 3) Who is shipping an IPX or NCP/IPX compression scheme? Not us, but that's not to say we won't. > 4) Is anyone planning on doing IPXCP without IPXWAN? Nope. > I entered into this to try to build a consensus because people were > beta-testing completely incompatible versions. Shiva and Novell weren't > converging. (The list of option numbers that Telebit just listed is not > the one currently in beta test there, and both their versions are > different than any of the various drafts.) This IS disconcerting... > When we started, IPXCP and IPXWAN had very few options in common, and > Novell was pretty belligerent about "their" protocol. > > Now Novell has gotten a lot friendlier (at least some of them have), are > involved with the IETF, and published an IPXWAN which includes *every* > feature that we have in IPXCP. They even added a reference to a Telebit > Compression Option. > > I'm looking for a good reason not to just scrap IPXCP, and go with > IPXWAN. The only thing that I think of is a possible header compression > option which would require PPP protocol numbers (IPXWAN can't do that), > or the *need* to have IPXCP *without* IPXWAN. I'm not so sure that IPXWAN can't do it. Mark's VJ style compression is headed in that direction, and Michael Allen seems to like it. We won't object if you scrap IPXCP options, but leave the IPXCP code points alone ;). > The deadline for a response is Friday, Sept 25, 1992. > > Bill.Simpson@um.cc.umich.edu Chris Ranch From ietf-ppp-request@ucdavis.ucdavis.edu Mon Sep 21 13:33:45 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13216; Mon, 21 Sep 92 13:29:26 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA21823; Mon, 21 Sep 92 12:10:23 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10363; Mon, 21 Sep 92 12:00:56 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from hobbit.gandalf.ca by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10063; Mon, 21 Sep 92 11:50:32 -0700 Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA13322; Mon, 21 Sep 92 14:50:18 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA11710; Mon, 21 Sep 92 14:50:04 EDT Date: Mon, 21 Sep 92 14:50:04 EDT From: chris@gandalf.ca (Chris Sullivan) Message-Id: <9209211850.AA11710@cannibal.gandalf.ca> To: ietf-ppp@ucdavis.ucdavis.edu Subject: LAPB A question came up the other day: if the LCP goes from OPEN to CLOSED, does it start tearing down LAPB? I.e., there is a twilight zone between successful LCP negotiation and the startup of LAPB, so do we go back through this same zone once LCP closes? I would think so, since the next time it comes up it might not converge on using LAPB for some reason. However, another approach could be to treat it as a physical tranport and leave it up. At IETF the issue of whether LCP gets encapsulated in I frames once LAPB has been negotiated came up. Some vendors, it turns out, have chips that do the LAPB protocol. But surely these chips can handle U frames, and since PPP is just user data in U frames, why couldn't LCP and the NCPs live alongside LAPB? Or is it a problem with the use of the broadcast address? It makes not a lot of difference to me, I just want to know what the "rough consensus" is, so I can get some code working. -Chris Sullivan From ietf-ppp-request@ucdavis.ucdavis.edu Tue Sep 22 16:05:16 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02035; Tue, 22 Sep 92 15:55:48 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA12108; Sat, 19 Sep 92 14:00:21 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03347; Sat, 19 Sep 92 13:51:53 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03169; Sat, 19 Sep 92 13:45:21 -0700 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA01933; Sat, 19 Sep 92 13:45:03 -0700 Date: Sat, 19 Sep 92 16:05:36 EDT From: "William Allen Simpson" Message-Id: <734.bill.simpson@um.cc.umich.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: IPXCP Status > From: mlewis@napa.Telebit.COM (Mark S. Lewis) > It is important to us that we nail this down, because we are going to > ship soon. Please comment or forever hold your peace. > How many other people have actually implemented this stuff? 1) Who is shipping IPXCP with options? 2) Who is shipping IPXWAN? 3) Who is shipping an IPX or NCP/IPX compression scheme? 4) Is anyone planning on doing IPXCP without IPXWAN? I entered into this to try to build a consensus because people were beta-testing completely incompatible versions. Shiva and Novell weren't converging. (The list of option numbers that Telebit just listed is not the one currently in beta test there, and both their versions are different than any of the various drafts.) When we started, IPXCP and IPXWAN had very few options in common, and Novell was pretty belligerent about "their" protocol. Now Novell has gotten a lot friendlier (at least some of them have), are involved with the IETF, and published an IPXWAN which includes *every* feature that we have in IPXCP. They even added a reference to a Telebit Compression Option. I'm looking for a good reason not to just scrap IPXCP, and go with IPXWAN. The only thing that I think of is a possible header compression option which would require PPP protocol numbers (IPXWAN can't do that), or the *need* to have IPXCP *without* IPXWAN. The deadline for a response is Friday, Sept 25, 1992. Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Tue Sep 22 16:14:43 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02296; Tue, 22 Sep 92 16:03:10 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA02729; Tue, 22 Sep 92 12:00:32 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23740; Tue, 22 Sep 92 11:51:50 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23636; Tue, 22 Sep 92 11:45:53 -0700 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA05322; Tue, 22 Sep 92 11:45:14 -0700 Date: Tue, 22 Sep 92 14:30:53 EDT From: "William Allen Simpson" Message-Id: <741.bill.simpson@um.cc.umich.edu> To: ietf-ppp@ucdavis.ucdavis.edu Cc: dorman@dorman.enet.dec.com, Housley.McLean_CSD@xerox.com Subject: Re: PPP support for ISO CLNP > From: Housley.McLean_CSD@xerox.com > If so, is an Internet Draft available? > > Thanks, > Russ > It's done, and on its way to be published as an RFC. Look for *pppext-osi* in the internet-drafts, or angband.stanford.edu:pub/ppp/osi.txt (local to you). -- The Editor Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Wed Sep 23 08:32:26 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01672; Wed, 23 Sep 92 08:29:10 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11056; Wed, 23 Sep 92 08:00:27 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00697; Wed, 23 Sep 92 07:51:36 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from uu2.psi.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00595; Wed, 23 Sep 92 07:47:20 -0700 Received: from python.microcom.com by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA20391; Wed, 23 Sep 92 10:46:59 -0400 Date: Wed, 23 Sep 92 10:47:33 EDT From: kec@microcom.com (Ken Culbert) Received: by python.microcom.com (4.1/3.1.090690-Microcom Inc.) id AA27344; Wed, 23 Sep 92 10:47:33 EDT Message-Id: <9209231447.AA27344@python.microcom.com> To: ietf-ppp@ucdavis.ucdavis.edu >From kec Wed Sep 23 10:30:59 1992 Date: Wed, 23 Sep 92 10:30:36 EDT >From: kec (Ken Culbert) Received: by python.microcom.com (4.1/3.1.090690-Microcom Inc.) id AA27156; Wed, 23 Sep 92 10:30:36 EDT Message-Id: <9209231430.AA27156@python.microcom.com> To: bill.simpson@um.cc.umich.edu Subject: Re: IPXCP Status Cc: kec@python.microcom.com Status: RO >I entered into this to try to build a consensus because people were >beta-testing completely incompatible versions. Shiva and Novell weren't >converging. (The list of option numbers that Telebit just listed is not >the one currently in beta test there, and both their versions are >different than any of the various drafts.) > >When we started, IPXCP and IPXWAN had very few options in common, and >Novell was pretty belligerent about "their" protocol. > >Now Novell has gotten a lot friendlier (at least some of them have), are >involved with the IETF, and published an IPXWAN which includes *every* >feature that we have in IPXCP. They even added a reference to a Telebit >Compression Option. > >I'm looking for a good reason not to just scrap IPXCP, and go with >IPXWAN. The only thing that I think of is a possible header compression >option which would require PPP protocol numbers (IPXWAN can't do that), >or the *need* to have IPXCP *without* IPXWAN. I may be speaking out of turn, since we don't have an IPXCP application, but isn't IPXWAN a description of how Novell handles router-to-router comms over PPP, rather than a PPP NCP? So how could IPXWAN exist without IPXCP? Also, Shiva's use of IPXCP (at least in their NetModem) is router-to-workstation, and so IPXWAN is irrelevant to it. (By the way, where is Shiva in this discussion?) IPXCP without IPXWAN could serve to provide interoperabilty between such products in the future; why require IPXWAN just because that use hasn't yet been implemented? (end of flame) Ken Culbert kec@microcom.com From ietf-ppp-request@ucdavis.ucdavis.edu Wed Sep 23 10:43:10 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06073; Wed, 23 Sep 92 10:40:00 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA12551; Wed, 23 Sep 92 09:31:37 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03529; Wed, 23 Sep 92 09:28:23 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [134.22.80.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03166; Wed, 23 Sep 92 09:16:41 -0700 Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA23775; Wed, 23 Sep 92 12:15:51 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA18893; Wed, 23 Sep 92 12:15:31 EDT Date: Wed, 23 Sep 92 12:15:31 EDT From: chris@gandalf.ca (Chris Sullivan) Message-Id: <9209231615.AA18893@cannibal.gandalf.ca> To: ietf-ppp@ucdavis.ucdavis.edu, kec@microcom.com Subject: IPXWAN & IPXCP :-) I may be speaking out of turn, since we don't have an IPXCP application, but :-) isn't IPXWAN a description of how Novell handles router-to-router comms over :-) PPP, rather than a PPP NCP? So how could IPXWAN exist without IPXCP? Also, :-) Shiva's use of IPXCP (at least in their NetModem) is router-to-workstation, :-) and so IPXWAN is irrelevant to it. If IPXWAN is indeed only for server to server then it kind of goes against the usual PPP tenet of being both a candy mint and a breath mint, I mean, a host-to- router and a router-to-router (suite of) protocol(s). It would be a pain if a box that supported IPX over PPP had to do both IPXCP and IPXWAN, depending on whether it was talking to a server or a client. -Chris Sullivan From ietf-ppp-request@aggie.ucdavis.edu Wed Sep 23 15:23:45 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14893; Wed, 23 Sep 92 15:18:06 -0700 Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA15676; Wed, 23 Sep 92 13:33:36 -0700 Sender: ietf-ppp-request@aggie.ucdavis.edu Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA15091; Wed, 23 Sep 92 13:01:13 -0700 From: ccskiz@aggie.ucdavis.edu (Elizabeth St. Goar) Date: Wed, 23 Sep 92 13:01:13 -0700 Message-Id: <9209232001.AA15091@aggie.ucdavis.edu> To: ietf-ppp@aggie.ucdavis.edu Subject: Re: Re: IPXCP Status -- Forwarded Message > Date: Wed, 23 Sep 92 09:15:15 EDT > From: sgw@sgw.xyplex.com (Scott Wasson) > To: bill.simpson@um.cc.umich.edu > Subject: Re: IPXCP Status > Cc: ietf-ppp-request@ucdavis.edu > > We have implemented and shipped IPXCP without options, and without IPXWAN. > We have the IPXWAN spec and are reviewing it for merit, but we're waiting > for a statement of direction from the IETF. Personally I'd like to see > options in IPXCP, one of which is to negotiate to do IPXWAN. Thus an > implementation which has no options (including no IPXWAN) will be fully > interoperable with one that does. > > Scott Wasson > sgwasson@eng.xyplex.com > From ietf-ppp-request@ucdavis.ucdavis.edu Wed Sep 23 17:41:41 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19506; Wed, 23 Sep 92 17:34:08 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18538; Wed, 23 Sep 92 17:02:30 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18250; Wed, 23 Sep 92 16:55:00 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17860; Wed, 23 Sep 92 16:42:20 -0700 Received: from na.novell.com (na.SJF.Novell.COM) by newsun.novell.com with SMTP id AA08889 (5.65c/IDA-1.4.4 for ); Wed, 23 Sep 1992 16:41:59 -0700 Received: by na.novell.com (4.1/SMI-4.1) id AA29097; Wed, 23 Sep 92 16:45:07 PDT Date: Wed, 23 Sep 92 16:45:07 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9209232345.AA29097@na.novell.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: IPXCP Status Hi Scott, Bill, et al, > From: sgw@sgw.xyplex.com (Scott Wasson) > > We have implemented and shipped IPXCP without options, and without IPXWAN. I hope you are aware that you will not interoperate with the NetWare MultiProtocol Router v2.0 without IPXWAN. > We have the IPXWAN spec and are reviewing it for merit, but we're waiting > for a statement of direction from the IETF. Well, we have not (yet ;) delegated to the IETF the design of IPX and related protocols, namely IPXWAN. It appears you are waiting for a statement from 'the IETF', which is really the PPP-EXT WG, on whether YOU should interoperate with NetWare. That sounds more like a question for your marketing folks. > Personally I'd like to see > options in IPXCP, one of which is to negotiate to do IPXWAN. Now that's an interesting thought. The option should really allow you to DISABLE IPXWAN, and by default IPXWAN is enabled. If the option is rejected, you know you're going to have to do IPXWAN. This will work with the currently shipping NetWare MPR (which will reject all IPXCP options). > Thus an > implementation which has no options (including no IPXWAN) will be fully > interoperable with one that does. Not quite. You left out NetWare as being interoperable. The bottom line is: if your implementation has no options, you MUST do IPXWAN (unless you can convince your marketing folk that you don't need to interoperate with NetWare). > Scott Wasson > sgwasson@eng.xyplex.com --- Chris Ranch Internetworking Products Division Novell, Inc. San Jose, CA (408)473-8667 cranch@novell.com From ietf-ppp-request@ucdavis.ucdavis.edu Thu Sep 24 09:14:46 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19564; Thu, 24 Sep 92 09:01:29 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23238; Thu, 24 Sep 92 08:20:40 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17986; Thu, 24 Sep 92 08:12:12 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17788; Thu, 24 Sep 92 08:05:55 -0700 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA07804; Thu, 24 Sep 92 08:05:26 -0700 Date: Thu, 24 Sep 92 10:18:48 EDT From: "William Allen Simpson" Message-Id: <755.bill.simpson@um.cc.umich.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: IPXCP Status > > Personally I'd like to see > > options in IPXCP, one of which is to negotiate to do IPXWAN. > > Now that's an interesting thought. The option should really > allow you to DISABLE IPXWAN, and by default IPXWAN is enabled. > If the option is rejected, you know you're going to have to do > IPXWAN. This will work with the currently shipping NetWare MPR > (which will reject all IPXCP options). > A good idea. That way, we wouldn't have to guess. So what we need is a list of times that you don't need IPX-WAN. Am I correct that Novell will operate correctly with complete hand configuration (net, node), a NULL IPXCP, and no IPX-WAN negotiation? Or does it *require* IPX-WAN, in which case it won't talk to older Novell boxes, let alone anyone else's? Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Thu Sep 24 13:09:19 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26542; Thu, 24 Sep 92 12:25:48 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA24408; Thu, 24 Sep 92 09:47:00 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20637; Thu, 24 Sep 92 09:34:33 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from hobbit.gandalf.ca by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20288; Thu, 24 Sep 92 09:24:36 -0700 Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA28059; Thu, 24 Sep 92 12:24:20 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA22482; Thu, 24 Sep 92 12:23:57 EDT Date: Thu, 24 Sep 92 12:23:57 EDT From: chris@gandalf.ca (Chris Sullivan) Message-Id: <9209241623.AA22482@cannibal.gandalf.ca> To: kasten@ftp.com Subject: Re: SIP's extra 32 bits Cc: big-internet@munnari.oz.au, ietf-ppp@ucdavis.ucdavis.edu Sorry: I *was* feeling a little air-headed yesterday. However invitations to admit being a fool are only being accepted once per demonstration thereof. Garrett beat you to it. Henning Schulzrinne wrote: > Regarding the length field in SIP: > since not all data link layers need it, wouldn't it make sense to > make it part of the SIP-over-xyz spec so that SIP-over-802.3 would be > prefixed by a length field (given the MTU, 16 bit would be sufficient here) > but SIP-over-PPP wouldn't (which would help particularly for the typically > low bit rates PPP is used for). Omitting the length field has two > advantages: a) saves space, b) one less check to worry about (or, if > you want, one less opportunity to throw out corrupted packets). Bill Simpson replied: > PPP needs the length field, it has arbitrary padding. but he also recently sent out a new document containing a "Self Describing Pad" option the use of which in SIP over PPP would allow the SIP packet to be distinguished from any pad chracters. It effectively puts the info where it belongs: in the pad. -Chris From ietf-ppp-request@ucdavis.ucdavis.edu Thu Sep 24 13:23:28 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26753; Thu, 24 Sep 92 12:30:58 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA24891; Thu, 24 Sep 92 10:20:54 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21520; Thu, 24 Sep 92 10:15:19 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20867; Thu, 24 Sep 92 09:43:39 -0700 Received: from na.novell.com (na.SJF.Novell.COM) by newsun.novell.com with SMTP id AA19480 (5.65c/IDA-1.4.4 for ); Thu, 24 Sep 1992 09:43:22 -0700 Received: by na.novell.com (4.1/SMI-4.1) id AA04735; Thu, 24 Sep 92 09:46:29 PDT Date: Thu, 24 Sep 92 09:46:29 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9209241646.AA04735@na.novell.com> To: bill.simpson@um.cc.umich.edu, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: IPXCP Status Hi Bill, > From: "William Allen Simpson" > > > > Personally I'd like to see > > > options in IPXCP, one of which is to negotiate to do IPXWAN. > > > > Now that's an interesting thought. The option should really > > allow you to DISABLE IPXWAN, and by default IPXWAN is enabled. > > If the option is rejected, you know you're going to have to do > > IPXWAN. This will work with the currently shipping NetWare MPR > > (which will reject all IPXCP options). > > > A good idea. That way, we wouldn't have to guess. So what we need > is a list of times that you don't need IPX-WAN. Only when you don't want to interoperate with NetWare routers. End systems connecting to a router is an open issue (that we ARE working on). I can imagine others saying they don't need IPXWAN when they connect to themselves or a similar product, presumably one that also doesn't support IPXWAN. But they will miss out on the market that DOES have NetWare MPRs in there. Just ask your marketing folk; don't rely on just me saying it's BIG. > Am I correct that Novell will operate correctly with complete hand > configuration (net, node), a NULL IPXCP, and no IPX-WAN negotiation? No, unfortunately. IPXWAN must complete before we'll send or receive any IPX packets. :-|. > Or does it *require* IPX-WAN, in which case it won't talk to older > Novell boxes, let alone anyone else's? We do require it, but we don't have a Novell product downward compatibility issue. This is the first time we've shipped a PPP product. Third party products anticipated a design over PPP, and happend to be wrong (not that anyone could anticipate IPXWAN). We would like to encourage all IPX over PPP router vendors to correct their design as soon as possible. If you need any assistance, let us know. You can also get your IPXWAN implementation and IPX router implementation Novell Certified (tested) by our IMSP program. Call Novell Labs if you're interested at 801-429-5713. The IPXWAN testing in IMSP is under development (not there yet). > Bill.Simpson@um.cc.umich.edu --- Chris Ranch Internetworking Products Division Novell, Inc. San Jose, CA (408)473-8667 cranch@novell.com From ietf-ppp-request@ucdavis.ucdavis.edu Thu Sep 24 15:08:35 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00490; Thu, 24 Sep 92 14:30:14 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27156; Thu, 24 Sep 92 13:46:47 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28437; Thu, 24 Sep 92 13:29:59 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from xap.xyplex.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27497; Thu, 24 Sep 92 12:55:22 -0700 Received: from sgw.xyplex.com by xap.xyplex.com id ; Thu, 24 Sep 92 15:53:31 -0500 Received: by sgw.xyplex.com (4.1/SMI-4.1) id AA10090; Thu, 24 Sep 92 15:57:06 EDT Date: Thu, 24 Sep 92 15:57:06 EDT From: sgw@sgw.xyplex.com (Scott Wasson) Message-Id: <9209241957.AA10090@sgw.xyplex.com> To: cranch@novell.com Subject: Re: IPXCP Status Cc: ietf-ppp@ucdavis.ucdavis.edu > > > > Personally I'd like to see > > Am I correct that Novell will operate correctly with complete hand > > configuration (net, node), a NULL IPXCP, and no IPX-WAN negotiation? > No, unfortunately. IPXWAN must complete before we'll send or > receive any IPX packets. :-|. Is there a technical reason why this is so, or are you just concerned with backward compatibility with the NMR? > > Personally I'd like to see > > options in IPXCP, one of which is to negotiate to do IPXWAN. > Now that's an interesting thought. The option should really > allow you to DISABLE IPXWAN, and by default IPXWAN is enabled. > If the option is rejected, you know you're going to have to do > IPXWAN. This will work with the currently shipping NetWare MPR > (which will reject all IPXCP options). That seems strange to me. Typically PPP negotiates which options to do, not which options NOT to do. > > Thus an > > implementation which has no options (including no IPXWAN) will be fully > > interoperable with one that does. > Not quite. You left out NetWare as being interoperable. The > bottom line is: if your implementation has no options, you > MUST do IPXWAN (unless you can convince your marketing folk > that you don't need to interoperate with NetWare). Why won't NetWare work without IPXWAN? Because that's just the way it is? Come on. Hand-configuring works just fine; we've had IPX running over PPP for many months with no options, no IPXWAN and no problems. It seems unreasonable for an NCP of PPP to have an independent, required means of negotiating options. What's next? Will Apple invent MACWAN? Will DEC require DECWAN? BanyanWAN? Suddenly PPP doesn't seem like PPP anymore. Scott Wasson sgwasson@eng.xyplex.com From ietf-ppp-request@ucdavis.ucdavis.edu Thu Sep 24 15:44:30 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02705; Thu, 24 Sep 92 15:36:06 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27941; Thu, 24 Sep 92 14:32:10 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00234; Thu, 24 Sep 92 14:22:40 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Shiva.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28762; Thu, 24 Sep 92 13:39:49 -0700 Received: by Shiva.COM (1.34b) Thu, 24 Sep 92 16:39:22 EDT Date: Thu, 24 Sep 92 16:39:22 EDT From: Robert D. Vincent Message-Id: <9209242039.AA08231@Shiva.COM> To: ietf-ppp@ucdavis.ucdavis.edu Subject: IPXCP & IPXWAN My preference is for these two protocols to coexist as peacefully and equally as possible. As far as I know, we have no immediate plans to support IPXWAN. We would like to replace our currently shipping (and non-standard) IPXCP with the standard version as soon as it exists, but we will take longer to support IPXWAN. -bert Bert Vincent Firmware Engineer Shiva Corporation From ietf-ppp-request@ucdavis.ucdavis.edu Thu Sep 24 16:30:27 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03948; Thu, 24 Sep 92 16:11:50 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA28160; Thu, 24 Sep 92 14:54:12 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00858; Thu, 24 Sep 92 14:43:07 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00637; Thu, 24 Sep 92 14:33:36 -0700 Received: from na.novell.com (na.SJF.Novell.COM) by newsun.novell.com with SMTP id AA24322 (5.65c/IDA-1.4.4 for ); Thu, 24 Sep 1992 14:32:54 -0700 Received: by na.novell.com (4.1/SMI-4.1) id AA09170; Thu, 24 Sep 92 14:35:59 PDT Date: Thu, 24 Sep 92 14:35:59 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9209242135.AA09170@na.novell.com> To: cranch@novell.com, sgw@sgw.xyplex.com Subject: Re: IPXCP Status Cc: ietf-ppp@ucdavis.ucdavis.edu Hi Scott, > From: sgw@sgw.xyplex.com (Scott Wasson) > > > > > > Personally I'd like to see > > > Am I correct that Novell will operate correctly with complete hand > > > configuration (net, node), a NULL IPXCP, and no IPX-WAN negotiation? > > > No, unfortunately. IPXWAN must complete before we'll send or > > receive any IPX packets. :-|. > > Is there a technical reason why this is so, or are you just concerned > with backward compatibility with the NMR? This is the first release or the MPR, so we don't have a downward compatibility problem. The IPXWAN requirement is part of the design on how to do Novell IPX over _any_ WAN link, like PPP and X.25. Intrinsic to IPX RIP is assigning a link delay value to each route, which is propagated along with RIP information. The only good way to determine link delay is to measure it. That's a key feature of IPXWAN. Manually configured link delays are inferior, and not the design. > > > Personally I'd like to see > > > options in IPXCP, one of which is to negotiate to do IPXWAN. > > > Now that's an interesting thought. The option should really > > allow you to DISABLE IPXWAN, and by default IPXWAN is enabled. > > If the option is rejected, you know you're going to have to do > > IPXWAN. This will work with the currently shipping NetWare MPR > > (which will reject all IPXCP options). > > That seems strange to me. Typically PPP negotiates which options to do, > not which options NOT to do. Not really. Higher level protocol behavior can default either way, and not break the spirit of PPP. The option is NOT to do it. Rejecting it means you will do IPXWAN. What do you think, Bill? > > > Thus an > > > implementation which has no options (including no IPXWAN) will be fully > > > interoperable with one that does. > > > Not quite. You left out NetWare as being interoperable. The > > bottom line is: if your implementation has no options, you > > MUST do IPXWAN (unless you can convince your marketing folk > > that you don't need to interoperate with NetWare). > > Why won't NetWare work without IPXWAN? Because that's just the way it is? Well, yes. > Come on. Hand-configuring works just fine; we've had IPX running over > PPP for many months with no options, no IPXWAN and no problems. Manual configuration is an inferior design for two reasons: 1) configuration just got MUCH more complex. We're currently bending over backwards to make confuration EASY. You ought to take a look :). 2) If you can get access to the line speed programatically, you cannot just infer throughput from it. Any guesses as to what kind of throughput or rtt you can get from an X.25 link? We have had lab experience in determining the link delay calculation in the IPXWAN spec. A 1000+ node, maximum diameter internet helped ;). When routers get congested (or links for that matter), end systems may loose their connections. Maybe something to take a look at for your test plan. > It seems unreasonable for an NCP of PPP to have an independent, required > means of negotiating options. I ask you to reconsider your model. This isn't an NCP requirement, this is an IPX requirement. The code should go on the bottom of your IPX, not in IPXCP. > What's next? Will Apple invent MACWAN? They already did: it's called ARAP. > Will DEC require DECWAN? BanyanWAN? Suddenly PPP doesn't seem like PPP > anymore. One hopes not. > Scott Wasson > sgwasson@eng.xyplex.com --- Chris Ranch Internetworking Products Division Novell, Inc. San Jose, CA (408)473-8667 cranch@novell.com From ietf-ppp-request@ucdavis.ucdavis.edu Thu Sep 24 17:13:43 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05860; Thu, 24 Sep 92 17:08:12 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA29057; Thu, 24 Sep 92 16:01:27 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03286; Thu, 24 Sep 92 15:53:41 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02985; Thu, 24 Sep 92 15:45:10 -0700 Received: from na.novell.com (na.SJF.Novell.COM) by newsun.novell.com with SMTP id AA25622 (5.65c/IDA-1.4.4 for ); Thu, 24 Sep 1992 15:44:55 -0700 Received: by na.novell.com (4.1/SMI-4.1) id AA10691; Thu, 24 Sep 92 15:47:58 PDT Date: Thu, 24 Sep 92 15:47:58 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9209242247.AA10691@na.novell.com> To: bill.simpson@um.cc.umich.edu, kph@cisco.com Subject: Re: IPXCP Status Cc: ietf-ppp@ucdavis.ucdavis.edu Hi Kevin, > From: kph@cisco.com > Status: R > Bill asked: > >Am I correct that Novell will operate correctly with complete hand > >configuration (net, node), a NULL IPXCP, and no IPX-WAN negotiation? I answered in a previous message that NetWare MPR will NOT operate under these circumstances. > The protocol will operate correctly, and we would like to see the negotiation > of "hand configuration - no IPXWAN" into IPXCP,as this would allow for certain > applications where interoperation with Novell routers is not a requirement. Help yourself... Are you serious about not caring to interoperate with NetWare ?!? I wonder if your marketing folk understand the issue. > Kevin Chris From ietf-ppp-request@ucdavis.ucdavis.edu Thu Sep 24 17:32:11 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06391; Thu, 24 Sep 92 17:22:34 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA29711; Thu, 24 Sep 92 16:40:39 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04687; Thu, 24 Sep 92 16:32:00 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04352; Thu, 24 Sep 92 16:22:47 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA03335; Thu, 24 Sep 92 16:21:15 PDT Date: Thu, 24 Sep 92 16:21:15 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9209242321.AA03335@saffron.acc.com> To: bert@Shiva.COM Subject: Re: IPXCP & IPXWAN Cc: ietf-ppp@ucdavis.ucdavis.edu We too are using a null NCP for IPX, and would like to implement a standard PPP NCP with certain features. We don't find IPXWAN to be architecturally attractive, and would far rather implement its features in the NCP proper. And we would agree that PPP standard behavior is that a system with a NULL NCP and appropriate configuration is always acceptable link behavior. Fred From ietf-ppp-request@aggie.ucdavis.edu Thu Sep 24 18:02:16 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07533; Thu, 24 Sep 92 17:57:53 -0700 Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA00321; Thu, 24 Sep 92 16:58:28 -0700 Sender: ietf-ppp-request@aggie.ucdavis.edu Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA29294; Thu, 24 Sep 92 16:16:20 -0700 From: ccskiz@aggie.ucdavis.edu (Elizabeth St. Goar) Date: Thu, 24 Sep 92 16:16:20 -0700 Message-Id: <9209242316.AA29294@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 AA27693; Thu, 24 Sep 92 14:21:01 -0700 Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29151; Thu, 24 Sep 92 13:52:10 -0700 Received: from sjfsmtp.novell.com (ss.Corp.SJF.Novell.COM) by newsun.novell.com with SMTP id AA23506 (5.65c/IDA-1.4.4 for <@newsun.Novell.COM:ietf-ppp-request@ucdavis.edu>); Thu, 24 Sep 1992 13:51:54 -0700 Message-Id: <199209242051.AA23506@newsun.novell.com> From: MALLEN@novell.com (MALLEN) To: ietf-ppp-request@ucdavis.ucdavis.edu (X) Subject: Re: a new question on the ppp Date: Thu, 24 Sep 92 11:58 >It would be a pain if a box that supported IPX over PPP had to do both IPXCP and >IPXWAN, depending on whether it was talking to a server or a client. The IPXWAN protocol currently defines what we (Novell) is supporting. We plan (and are actively looking into) server/router -> workstation access. The implementation will be in the form of an extension to IPXWAN (new options/option values). For example, a workstation calling a router (or the other way round) would specify a Router Type = WS. The router when it received the WS Router Type would become the link master (in IPXWAN terms) and control the link allocating any network numbers/node numbers etc. I would like to stress that IPXWAN is really very similar to the PPP NCP protocol in that extra options can be specified and negotiated. The ONLY real difference is that IPXWAN is NOT PPP specific - it works over media (like X.25) which have no concept of option negotiation. >So how could IPXWAN exist without IPXCP? IPXWAN cannot exist without IPXCP (although it does have an NCP with NO options). IPXWAN does NOT begin until after the NCP is fully OPEN. I agree with Chris Ranch's suggestion where IPXWAN is negotiated OFF if implementations are using a purely IPXCP protocol. A Novell implementation would reject the option thereby implying use of the IPXWAN protocol. Michael Allen, Novell Inc. From ietf-ppp-request@aggie.ucdavis.edu Thu Sep 24 18:02:20 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07584; Thu, 24 Sep 92 17:59:41 -0700 Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA00456; Thu, 24 Sep 92 17:08:30 -0700 Sender: ietf-ppp-request@aggie.ucdavis.edu Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA29347; Thu, 24 Sep 92 16:20:15 -0700 From: ccskiz@aggie.ucdavis.edu (Elizabeth St. Goar) Date: Thu, 24 Sep 92 16:20:15 -0700 Message-Id: <9209242320.AA29347@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 AA27726; Thu, 24 Sep 92 14:21:47 -0700 Received: from ns.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29264; Thu, 24 Sep 92 13:56:31 -0700 Received: by ns.Novell.COM (4.1/SMI-4.1) id AA06122; Thu, 24 Sep 92 14:56:18 MDT Received: by MHS.Novell.COM id 6105C22A81F901D0; Thu, 24 Sep 92 14:56:18 MDT Return-Path: Precedence: first-class X-Date-Posted: 23-Sep-92 13:21:59 X-Smf-Version: 70 To: ietf-ppp-request@ucdavis.ucdavis.edu From: Michael_Allen@Novell.COM Message-Id: <6923C22A01F901D0@MHS.Novell.COM> Subject: Re: IPXCP Status Date: Thu, 24 Sep 92 13:21:00 MDT O-Dvs-Trail: Originated by :INET-1 09-24-92 2:18p Replied by :MALLEN 09-24-92 11:59a X-Via-Host: ETEMP.novell >Am I correct that Novell will operate correctly with complete hand configuration >(net, node), a NULL IPXCP, and no IPX-WAN negotiation? > >Or does it *require* IPX-WAN, in which case it won't talk to older Novell boxes, let >alone anyone else's? Novell's WAN products MUST use the IPXWAN protocol. There is not a way to hand configure them to work with older products which use hard coded net/node values. If an IPXWAN product fails to receive correct IPXWAN packets, the link will/should be disconnected. >A good idea. That way, we wouldn't have to guess. So what we need is a list of times >that you don't need IPX-WAN. I do not think there is a "list" of times that IPXWAN is not needed. Often when a company's products are interoperating with themselves there are some optimizations that they can get by adopting IPXWAN or IPXCP. If a company can/wants to use IPXCP by default, they should be able to. However, they should also support the IPXWAN protocol for the cases where 3rd party interoperability is required. In the future (probably a couple of years), the PPP LCP/NCP will be implemented on top of other WAN media, allowing migration to a purely IPXCP implementation. If there is a set of rules for when IPXWAN should be used (like due to IPXCP negotiation failure) we do not need a list of times to use IPXWAN anyway :-) Michael Allen Novell Inc. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Sep 25 06:31:49 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29192; Fri, 25 Sep 92 06:26:06 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06118; Fri, 25 Sep 92 06:10:25 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28483; Fri, 25 Sep 92 06:00:58 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from xap.xyplex.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28278; Fri, 25 Sep 92 05:54:03 -0700 Received: from sgw.xyplex.com by xap.xyplex.com id ; Fri, 25 Sep 92 08:52:23 -0500 Received: by sgw.xyplex.com (4.1/SMI-4.1) id AA10967; Fri, 25 Sep 92 08:56:00 EDT Date: Fri, 25 Sep 92 08:56:00 EDT From: sgw@sgw.xyplex.com (Scott Wasson) Message-Id: <9209251256.AA10967@sgw.xyplex.com> To: cranch@novell.com Subject: Re: IPXCP Status Cc: ietf-ppp@ucdavis.ucdavis.edu Hi Chris, Chris Ranch writes: > Manual configuration is an inferior design for two reasons: > 1) configuration just got MUCH more complex. We're currently > bending over backwards to make confuration EASY. You ought > to take a look :). 2) If you can get access to the line speed > programatically, you cannot just infer throughput from it. Any > guesses as to what kind of throughput or rtt you can get from > an X.25 link? > We have had lab experience in determining the link delay calculation > in the IPXWAN spec. A 1000+ node, maximum diameter internet > helped ;). When routers get congested (or links for that matter), > end systems may loose their connections. Maybe something to > take a look at for your test plan. Of course manual configuration is an inferior design; I'm not debating that. Here's my issue: In my opinion, (this statement made just to make a point) any implementation which doesn't support Link Quality Monitoring is also an inferior design. Does this make LQM a mandatory option? Clearly not. All of PPP's options make life nicer in some way or another. But a tenet of PPP is to allow support for a minimum architecture and still guarantee interoperability. And manual configuration is clearly a minimum architecture. Fred Baker writes: > We too are using a null NCP for IPX, and would like to implement a >standard PPP NCP with certain features. We don't find IPXWAN to be >architecturally attractive, and would far rather implement its features >in the NCP proper. >And we would agree that PPP standard behavior is that a system with a >NULL NCP and appropriate configuration is always acceptable link >behavior. Thank you. Scott Wasson sgwasson@eng.xyplex.com From ietf-ppp-request@ucdavis.ucdavis.edu Fri Sep 25 08:21:36 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02423; Fri, 25 Sep 92 08:17:13 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06886; Fri, 25 Sep 92 07:50:23 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01334; Fri, 25 Sep 92 07:40:22 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from relay1.UU.NET by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01091; Fri, 25 Sep 92 07:30:58 -0700 Received: from speedo.penril.com (via [155.93.224.2]) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA05714; Fri, 25 Sep 92 10:30:40 -0400 Received: from keith.penril.com by speedo.penril.com (4.1/SMI-4.1) id AA17709; Fri, 25 Sep 92 10:22:11 EDT Date: Fri, 25 Sep 92 10:22:11 EDT From: jhsu@penril.com (Johnathan Hsu) Message-Id: <9209251422.AA17709@speedo.penril.com> To: bill.simpson@um.cc.umich.edu Subject: IPXCP Status Cc: ietf-ppp@ucdavis.ucdavis.edu We will have IPX in our router soon, and are going to implement IPXCP, we also would like to see the negotiation of "no IPXWAN" into IPXCP. =============================================================== Jonathan Hsu (301)921-8600x8795 Penril Datacomm Networks jhsu@.penril.com From ietf-ppp-request@ucdavis.ucdavis.edu Fri Sep 25 08:34:53 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02821; Fri, 25 Sep 92 08:30:09 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06976; Fri, 25 Sep 92 08:00:25 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01763; Fri, 25 Sep 92 07:55:28 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from xap.xyplex.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01578; Fri, 25 Sep 92 07:47:19 -0700 Received: from sgw.xyplex.com by xap.xyplex.com id ; Fri, 25 Sep 92 10:45:41 -0500 Received: by sgw.xyplex.com (4.1/SMI-4.1) id AA11079; Fri, 25 Sep 92 10:49:18 EDT Date: Fri, 25 Sep 92 10:49:18 EDT From: sgw@sgw.xyplex.com (Scott Wasson) Message-Id: <9209251449.AA11079@sgw.xyplex.com> To: estgoar@ucdavis.ucdavis.edu Subject: Re: Cc: ietf-ppp@ucdavis.ucdavis.edu estgoar@ucdavis.edu writes: > I would like to stress that IPXWAN is really very similar to the PPP NCP > protocol in that extra options can be specified and negotiated. The ONLY > real difference is that IPXWAN is NOT PPP specific - it works over media > (like X.25) which have no concept of option negotiation. That's wonderful, except I don't see how it could work over multiaccess media, e.g. X.25 and frame relay. What do you do when you don't have a simple point-to-point link? Is there one Master and NN Slaves? But what if you don't have a fully-meshed topology? Node A has a VC to B and and a VC to C, but B and C don't have a direct connection. What if B becomes Master, then what? The same problem applies to frame relay, just substitute 'DLCI' for 'VC'. Given that, I can't get excited about IPXWAN's multi-media capabilities when in the case of 2 out of the 3 media is mentions in the spec, it doesn't work under all circumstances (it will work if the frame relay or X.25 network is very simple, just one DLCI or VC, effectively point-to-point). If I'm wrong, please educate me. Scott Wasson sgwasson@eng.xyplex.com From ietf-ppp-request@ucdavis.ucdavis.edu Fri Sep 25 15:34:53 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02430; Fri, 25 Sep 92 15:25:46 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01272; Fri, 25 Sep 92 14:18:51 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00555; Fri, 25 Sep 92 10:27:29 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from regal.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04863; Fri, 25 Sep 92 09:36:35 -0700 Received: by regal.cisco.com; Fri, 25 Sep 92 09:36:05 -0700 Date: Fri, 25 Sep 92 9:36:04 PDT From: William "Chops" Westfield To: sgw@sgw.xyplex.com (Scott Wasson) Cc: estgoar@ucdavis.ucdavis.edu, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: In-Reply-To: Your message of Fri, 25 Sep 92 10:49:18 EDT Message-Id: That's wonderful, except I don't see how it could work over multiaccess media, e.g. X.25 and frame relay. What do you do when you don't have a simple point-to-point link? Is there one Master and NN Slaves? But what if you don't have a fully-meshed topology? Node A has a VC to B and and a VC to C, but B and C don't have a direct connection. What if B becomes Master, then what? The same problem applies to frame relay, just substitute 'DLCI' for 'VC'. My interpretation of the IPXWAN document is that in an X.25 network, each virtual circuit would have its own network number assigned - eg, an IPXWAN router must have a pool of network numbers at least as large as the number of virtual circuits it expects to every have open. I'm not sure how IPXWAN avoids manual configuration. It seems to me that you still have to configure each router with its "internal" network, as well as speciying the pool of network numbers that it will use for dynamic assignment of networks to "Slave" systems. And these still have to be unique across the entire WAN, so it isn't clear that this is much easier than statically configuring each box. Indeed, it may be worse from a network managment perspective, since there isn't a fixed mapping from network numbers to hardware links... BillW From ietf-ppp-request@ucdavis.ucdavis.edu Fri Sep 25 15:35:03 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02503; Fri, 25 Sep 92 15:28:20 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07956; Fri, 25 Sep 92 09:21:02 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04124; Fri, 25 Sep 92 09:13:08 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from monk.proteon.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03675; Fri, 25 Sep 92 08:59:37 -0700 Received: from sonny.proteon.com by monk.proteon.com (5.65/1.8) id AA24448; Fri, 25 Sep 92 12:00:19 -0400 Received: by sonny.proteon.com (3.2/SMI-3.2) id AA24052; Fri, 25 Sep 92 11:58:04 EDT Date: Fri, 25 Sep 92 11:58:04 EDT From: jas@proteon.com (John A. Shriver) Message-Id: <9209251558.AA24052@sonny.proteon.com> To: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Scott Wasson's message of Fri, 25 Sep 92 10:49:18 EDT <9209251449.AA11079@sgw.xyplex.com> Subject: IPXWAN over PDNs As I read the IPXWAN RFC, you treat an X.25 network as a mesh of point-to-point links. That is, if you are a router talking to four other routers over X.25, there is a unique IPX network number for each of those neighbors. Of course, this can use a lot of IPX network numbers, 4 routers require 6 network numbers, 5 routers require 10 network numbers, and so forth. (N things taken 2 at a time? Grows fast!) You can't use the "treat the PDN as a LAN" model unless you have perfect n-way connectivity. With IPX's split-horizon in RIP and SAP, that does not work right. (We KNOW, we've seen it in our own IPX over Frame Relay network, which is not fully connected.) This is probably why Frame Relay was left dangling in the IPXWAN RFC, because non-transitivity is so common. However, without re-architecting the RIP and SAP layers of IPX, you probably are stuck treating Frame Relay the same way as X.25. Novell is not the only people to struggle with this problem. The MAC bridging over Frame Relay RFC totally misses this point, also. Is a Frame Relay interface to a bridge one 802.1D "port", or is each PVC/SVC one 802.1D "port"? That issue is completely ignored! (Maybe they are deferring to 802.1G to solve this, that certainly is getting some coverage in iplpdn.) From ietf-ppp-request@aggie.ucdavis.edu Mon Sep 28 11:10:47 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12087; Mon, 28 Sep 92 10:57:24 -0700 Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA15486; Mon, 28 Sep 92 08:35:28 -0700 Sender: ietf-ppp-request@aggie.ucdavis.edu Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA15226; Mon, 28 Sep 92 08:23:47 -0700 From: ccskiz@aggie.ucdavis.edu (Elizabeth St. Goar) Date: Mon, 28 Sep 92 08:23:47 -0700 Message-Id: <9209281523.AA15226@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 AA03326; Fri, 25 Sep 92 17:01:20 -0700 Received: from ns.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05507; Fri, 25 Sep 92 16:59:40 -0700 Received: by ns.Novell.COM (4.1/SMI-4.1) id AA10996; Fri, 25 Sep 92 17:59:26 MDT Received: by MHS.Novell.COM id 3339C32A81F901D0; Fri, 25 Sep 92 17:59:25 MDT Return-Path: Precedence: first-class X-Date-Posted: 24-Sep-92 16:09:24 X-Smf-Version: 70 To: ietf-ppp-request@ucdavis.ucdavis.edu From: Michael_Allen@Novell.COM Message-Id: <269CC32A01F901D0@MHS.Novell.COM> Subject: Re: IPXWAN over PDNs Date: Fri, 25 Sep 92 16:09:00 MDT O-Dvs-Trail: Originated by :ietf-ppp 09-25-92 3:58p Replied by :MALLEN 09-25-92 4:02p X-Via-Host: ETEMP.novell >As I read the IPXWAN RFC, you treat an X.25 network as a mesh of point-to-point links. >That is, if you are a router talking to four other routers over X.25, there is a unique IPX >network number for each of those neighbors. Of course, this can use a lot of IPX network >numbers, 4 routers require 6 network numbers, 5 routers require 10 network numbers, >and so forth. (N things taken 2 at a time? Grows fast!) > >You can't use the "treat the PDN as a LAN" model unless you have perfect n-way >connectivity. With IPX's split-horizon in RIP and SAP, that does not work right. (We >KNOW, we've seen it in our own IPX over Frame Relay network, which is not fully >connected.) This is probably why Frame Relay was left dangling in the IPXWAN RFC, >because on-transitivity is so common. > >However, without re-architecting the RIP and SAP layers of IPX, you probably are stuck >treating Frame Relay the same way as X.25. > >Novell is not the only people to struggle with this problem. The MAC bridging over Frame >Relay RFC totally misses this point, also. Is a Frame Relay interface to a bridge one >802.1D "port", or is each PVC/SVC one 802.1D "port"? That issue is completely ignored! >(Maybe they are deferring to 802.1G to solve this, that certainly is getting some coverage >in iplpdn.) Great!!! I totally agree. However, a fully interconnected mesh is NOT necessary - N-1 connections (and thus N-1 network numbers) is all that is necessary to obtain full connectivity between N nodes. There will of course be a double hop between some nodes. It is looking like Novell will be doing an IPXWAN version of Frame Relay (don't quote me on that though). Michael Allen, Novell Inc. From ietf-ppp-request@aggie.ucdavis.edu Mon Sep 28 14:25:41 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18027; Mon, 28 Sep 92 13:52:34 -0700 Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA18191; Mon, 28 Sep 92 12:00:10 -0700 Sender: ietf-ppp-request@aggie.ucdavis.edu Received: by aggie.ucdavis.edu (5.61/UCD2.04) id AA17618; Mon, 28 Sep 92 11:12:34 -0700 From: ccskiz@aggie.ucdavis.edu (Elizabeth St. Goar) Date: Mon, 28 Sep 92 11:12:34 -0700 Message-Id: <9209281812.AA17618@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 AA15852; Mon, 28 Sep 92 09:06:33 -0700 Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03825; Mon, 28 Sep 92 08:40:53 -0700 Received: from sjfsmtp.novell.com (ss.Corp.SJF.Novell.COM) by newsun.novell.com with SMTP id AA19985 (5.65c/IDA-1.4.4 for <@newsun.Novell.COM:ietf-ppp-request@ucdavis.edu>); Mon, 28 Sep 1992 08:40:37 -0700 Message-Id: <199209281540.AA19985@newsun.novell.com> From: MALLEN%sjfsmtp@novell.com (MALLEN) To: ietf-ppp-request@ucdavis.ucdavis.edu (X) Subject: IPXWAN Date: Fri, 25 Sep 92 14:04 Hi Scott, >That's wonderful, except I don't see how it could work over multiaccess media, e.g. X.25 >and frame relay. What do you do when you don't have a simple point-to-point link? Is >there one Master and NN Slaves? But what if you don't have a fully-meshed topology? >Node A has a VC to B and and a VC to C, but B and C don't have a direct connection. >What if B becomes Master, then what? The same problem applies to frame relay, just >substitute 'DLCI' for 'VC'. > >Given that, I can't get excited about IPXWAN's multi-media capabilities when in the case >of 2 out of the 3 media is mentions in the spec, it doesn't work under all circumstances (it >will work if the frame relay or X.25 network is very simple, just one DLCI or VC, effectively >point-to-point). If I'm wrong, please educate me. IPXWAN does work for X.25 - infact very well - we currently have a product which uses the protocol for both X.25 and PPP. We use the protocol on both PVCs and SVCs on X.25. Each VC looks like a separate LAN to the IPX protocol with its own network number. Each VC has one master and one slave. For Frame Relay, there is mixed opinion in the market place on how to implement it for PVCs. Some implement the PVC as a LAN and simulate broadcasts to all endpoints, with an IPX network number assigned to the PVC. Others implement the PVC as several point to point connections - creating either a tree, or a fully interconnected mesh. Some then offer a choice and implement both methods & leave it to the customer ot choose which they want to use. If the PVC is treat as several pt-2-pt connections, each endpoint-endpoint would be treat as a WAN pt-2-pt connection on which IPXWAN would be run. The most efficient method of connecting (which had the least number of interconnections to manage) would be for one endpoint to perform the connection/routing responsibility to all other endpoints. The worst case now is that a packet takes an extra hop to get to its destination. For FR SVCs, these would be treat just like X.25 SVCs - several pt-2-pt connections each running the IPXWAN protocol when the connection is first made. If there are 5 FR SVCs, there will be 5 IPXWAN protocols run, with 5 masters and 5 slaves. A master and a slave are related to an individual pt-2-pt connection. If a node is a master for one connection, he can also be a slave to another connection running at the same time. I hope this helps to clarify some of the IPXWAN issues. Michael Allen Novell Inc. mallen@novell.com From ietf-ppp-request@ucdavis.ucdavis.edu Tue Sep 29 17:47:07 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11577; Tue, 29 Sep 92 17:37:35 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04321; Tue, 29 Sep 92 17:11:26 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10412; Tue, 29 Sep 92 17:03:38 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10084; Tue, 29 Sep 92 16:55:57 -0700 Received: from napa.TELEBIT.COM by apache (4.1/SMI-4.1/Telebit-Apache-Brent-920708) id AA17236 to ietf-ppp@ucdavis.edu; Tue, 29 Sep 92 16:55:27 PDT Received: from yoyo.telebit.com by napa.TELEBIT.COM (4.1/napa.telebit.com-Brent-920717) id AA27391 to ietf-ppp@ucdavis.edu; Tue, 29 Sep 92 16:55:24 PDT Date: Tue, 29 Sep 92 16:55:24 PDT From: mlewis@napa.Telebit.COM (Mark S. Lewis) Message-Id: <9209292355.AA27391@napa.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA19462; Tue, 29 Sep 92 16:55:43 PDT To: brian@lloyd.com, gordon@ftp.com, grant@xylogics.com, brad@cayman.com, misko@cisco.com, walkerl@med.ge.com, centrum@netcom.com, karl@morningstar.com, chris@gandalf.ca, ptrubey@netcom.com, foxcj@network.com, cbrown@wellfleet.com, natadm!ycw@uunet.uu.net, natadm!rching@uunet.uu.net, dgotelli@novell.com, gregl@novell.com, ebautist@novell.com, sjamar@novell.com, steve@livingston.com, hih@nsd.3com.com, vsp@nsd.3com.com, jxh@relay.proteon.com, gsb@proteon.com, bobsher@vnet.ibm.com, steve_richard@net.com, ken_cheng@net.com, tayler@heart.enet.dec.com, sunman@reo.mts.dec.com, pugh@hprnls7.rose.hp.com, sreed@hprnd.rose.hp.com, tthornto@xircom.com, martillo@azea.clearpoint.com, reeve@xylogics.com, chen@i88.isc.com, jim@dss.com, irfan@pluto.dss.com, ljb@merit.edu, wright_m@timeplex.com, sgwasson@eng.xyplex.com, rcstevens@eng.xyplex.com, mitch@nat.com Cc: ietf-ppp@ucdavis.ucdavis.edu, ppp-demo@lloyd.com Subject: PPP Consortium Update It's time to update everyone on the upcoming 2nd meeting of the PPP Consortium. This meeting will be hosted by Telebit in Sunnyvale, California on October 19-23 (the week before the Fall InterOp). During this week, participating vendors will have the opportunity to test their products with others. It will be a primarily technical session which focuses on interoperability between products. The goals of the meeting are: 1. Test interoperability to identify problems and limitations 2. Resolve interoperability problems 3. Identify areas for improvement in the specification and implementation of PPP INVITEES At this point, we have 17 confirmed participants and 7 others who are likely to participate. All organizations with a PPP implementation are invited to participate. This is not intended to exclude anyone who would like to participate or observe. Editors from industry publications are invited to attend a briefing on the nature of the meeting (Wednesday October 22). INTEROP PPP-DEMO A number of the participants will also be involved in a demonstration of PPP interoperability at the InterOP show the following week. The results of this interoperability testing will be used to determine what to show at InterOp. All firms in the PPP-Demo are expected to participate in this testing session (October 19-23). If you need more details on the the PPP-Demo, please contact Brian of Lloyd & Associates (brian@lloyd.com or voice (916) 676-1147). MARKETING ISSUES All participants in the testing session should supply a marketing contact. This will enable us to coordinate press releases and such. It is important that all participants work together to properly promote the work of these sessions. This session will be conducted in a spirit of cooperation, where competitive issues will be minimized. We want to support the work of the Consortium and it's members. If your company has confirmed its participation but has not yet provided a marketing contact, please do so as soon as possible. CONFIRMED PARTICIPANTS Ascom Timeplex Clearpoint Research Corporation Centrum Communications Datability Inc. Digital Equipment Corp Ltd. FTP Software Interactive Systems Co. Hewlett Packard Merit Network, Inc. Morning Star Technologies Network Application Technology, Inc. Network Equipment Technologies Novell, Inc. (Internetworking Products Division) Novell, Inc. (LAN WorkPlace) Telebit Corp. Xylogics Inc. Xyplex UNCONFIRMED PARTICIPANTS 3Com* Advanced Computer Communications Cayman Systems cisco Systems CMC Digital Equipment Corp. (DECserver Group) Gandalf Data Ltd.* IBM* Livingston Technologies* NEC* Network Systems* Penril Datacom Networks Proteon* Shiva Corp. Wellfleet Communications *These companies have somehow indicated their intent to participate but have not provided the requested information. We need to know who will attend and what they want to test. Companies should confirm their participation by e-mailing (preferred) or faxing the RSVP included below. ... Mark =========----------- Mark S. Lewis -----------========== inet: mlewis@telebit.com Telebit Corp. Telebit (408) 745-3232 uucp: uunet!telebit!mlewis Fax (408) 745-3810 ----------------------------- Cut Here ------------------------------ PPP Consortium RSVP October 19-23, 1992 Yes, our company would like to participate in the 2nd meeting of the PPP Interoperability Consortium. Company: Address: Address: Address: Address: Please indicate who will attend the session: COMPANY REPRESENTATIVES Technical Contact(s) E-mail Voice Fax ------------------- ------ ----- --- Marketing Contact(s) E-mail Voice Fax ------------------- ------ ----- --- Please indicate the protocols supported over which media: PROTOCOL MEDIA MATRIX Protocol Sync Link Asyc Link -------- --------- --------- Link Control (LCP) Password Authentication (PAP) Challenge Authentication (CHAP) Link Quality Monitoring (LQM) Internet Protocol (IPCP) AppleTalk (ATKCP) Novell IPX (IPXCP) Xerox NS DECnet Phase IV OSI Network Layer Bridging PDU Other (specify) Commments: ---------------------------- Cut Here ----------------------------- From ietf-ppp-request@ucdavis.ucdavis.edu Tue Sep 29 19:11:44 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14543; Tue, 29 Sep 92 19:06:15 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05745; Tue, 29 Sep 92 18:50:14 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13737; Tue, 29 Sep 92 18:41:26 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [134.22.80.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13619; Tue, 29 Sep 92 18:37:04 -0700 Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA22217; Tue, 29 Sep 92 21:36:47 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA10894; Tue, 29 Sep 92 21:36:10 EDT From: chris@gandalf.ca (Chris Sullivan) Message-Id: <9209300136.AA10894@cannibal.gandalf.ca> Subject: PPP Consortium Update To: ietf-ppp@ucdavis.ucdavis.edu Date: Tue, 29 Sep 92 21:36:09 EDT X-Mailer: ELM [version 2.3 PL11] Mark: Is there a deal on the Wyndham Gardens Hotel again? -Chris Sullivan From ietf-ppp-request@ucdavis.ucdavis.edu Wed Sep 30 17:42:54 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27793; Wed, 30 Sep 92 17:37:30 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14961; Wed, 30 Sep 92 17:20:20 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26929; Wed, 30 Sep 92 17:10:57 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26607; Wed, 30 Sep 92 17:01:12 -0700 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA03455; Wed, 30 Sep 92 17:00:45 -0700 Date: Wed, 30 Sep 92 19:27:38 EDT From: "William Allen Simpson" Message-Id: <781.bill.simpson@um.cc.umich.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: IPXCP Status Thank you all for your status messages. Most enlightening. As far as I can tell, everyone wants IPXCP, and only Novell and Telebit are supporting IPXWAN. Nobody is shipping any IPXCP options, but Telebit and Shiva are ready (in beta). Novell can't talk to anyone else but Telebit, even with static configuration. The "no IPXWAN" option is clever, but not really useful unless you *do* support IPXWAN, and want to ignore it. I identified (with help from Bert@Shiva and Saroop@Telebit) a set of required parameters. If they haven't been configured or negotiated, then fall thru into IPXWAN. Now, I need implementors to look carefully at the spec (particularly net and node numbers) and give some feedback (to the list). You can find it at angband.stanford.edu:pub/ppp/ipxcp.txt Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Wed Sep 30 19:54:23 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01363; Wed, 30 Sep 92 19:37:15 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA15481; Wed, 30 Sep 92 19:20:37 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00674; Wed, 30 Sep 92 19:12:54 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00418; Wed, 30 Sep 92 19:02:45 -0700 Received: from harry.lloyd.com. by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA11486; Wed, 30 Sep 92 18:48:55 PDT Date: Wed, 30 Sep 92 18:48:55 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9210010148.AA11486@ray.lloyd.com> Received: by harry.lloyd.com. (4.1/SMI-4.1) id AA02001; Wed, 30 Sep 92 18:48:54 PDT To: mlewis@Telebit.COM Cc: gordon@ftp.com, grant@xylogics.com, brad@cayman.com, misko@cisco.com, walkerl@med.ge.com, centrum@netcom.com, karl@morningstar.com, chris@gandalf.ca, ptrubey@netcom.com, foxcj@network.com, cbrown@wellfleet.com, natadm!ycw@uunet.uu.net, natadm!rching@uunet.uu.net, dgotelli@novell.com, gregl@novell.com, ebautist@novell.com, sjamar@novell.com, steve@livingston.com, hih@nsd.3com.com, vsp@nsd.3com.com, jxh@relay.proteon.com, gsb@proteon.com, bobsher@vnet.ibm.com, steve_richard@net.com, ken_cheng@net.com, tayler@heart.enet.dec.com, sunman@reo.mts.dec.com, pugh@hprnls7.rose.hp.com, sreed@hprnd.rose.hp.com, tthornto@xircom.com, martillo@azea.clearpoint.com, reeve@xylogics.com, chen@i88.isc.com, jim@dss.com, irfan@pluto.dss.com, ljb@merit.edu, wright_m@timeplex.com, sgwasson@eng.xyplex.com, rcstevens@eng.xyplex.com, mitch@nat.com, ietf-ppp@ucdavis.ucdavis.edu, ppp-demo@lloyd.com In-Reply-To: Mark S. Lewis's message of Tue, 29 Sep 92 16:55:24 PDT <9209292355.AA27391@napa.TELEBIT.COM> Subject: PPP Consortium Update All participants in the PPP Demonstration will definitely be at the bake-off. From you list of unconfirmed attendees this includes 3-Com, CMC, DEC, Gandalf, Livingston, NEC, Network Systems, Penril, and Proteon. Count on their presence. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 fax (916) 676-3442