Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00761; 1 Jul 93 3:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00757; 1 Jul 93 3:44 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01939; 1 Jul 93 3:44 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00748; 1 Jul 93 3:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00744; 1 Jul 93 3:39 EDT Received: from [192.76.152.15] by CNRI.Reston.VA.US id aa01878; 1 Jul 93 3:39 EDT Received: from keks.netcs.com by thuer.netcs.com with SMTP (5.67a8+/25-eef) id AA22235; Thu, 1 Jul 1993 09:39:50 +0200 Received: by keks.netcs.com (5.65/25-eef) id AA20897; Thu, 1 Jul 93 09:39:50 +0200 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Oliver Korfmacher Message-Id: <9307010739.AA20897@keks.netcs.com> Subject: Re: Brutal Simplicity To: Keith Sklower Date: Thu, 1 Jul 93 9:39:49 MEST Cc: ietf-ppp@ucdavis.edu, iplpdn@CNRI.Reston.VA.US In-Reply-To: <199307010204.TAA24191@vangogh.CS.Berkeley.EDU>; from "Keith Sklower" at Jun 30, 93 7:04 pm X-Mailer: ELM [version 2.2 PL0] X-Charset: ASCII X-Char-Esc: 29 Guten Morgen -- > Unfortunately it doesn't work so well with old versions of NCSA > telnet for PC's (which don't understand IP fragmentation), and > it doesn't work so well with IPX. (which expects delivery in sequence) There are more implementations (even commercial ones) having problems with non-in-sequence delivery, at least performance problems. > But the real motivation for having sequencing and reliable delivery > over the links in the IP-only case is to do data compression at > the link layer. If you drop something, or get it out of order then > you screw up the data dictionary and have to start over. > > [..] > If you aren't running LAPB or LAPF > but you are doing compression and are just trusting the usual good > service of ISDN, for example, you still will want to know that the > last fragment you sent on the link to be brought down got there, > which you accomplish by trading config-requests with the MRCS > option, (which prevents further traffic on that link but not the > others), and then you bring down the link by sending LCP > Terminate-requests and acks. Yes. We have tested our V.42bis data compression over german ISDN (which is well, quite good regarding line quality), and every 1000..10000 datagram is broken if we are using HDLC-framing only. The problem with LAPB is, that if used over long distance lines, the end-to-end delay comes to ranges of seconds, which brings down the throughput (due to too small window sizes). And: please keep in mind that ISDN is mainly a dial-on-demand media, so extensive ppp-negotiations in connection setup will definitly delay the setup time! This is a delay the user directly experiences. Gruesse, Oliver Oliver Korfmacher (okorf@netcs.com, whois OK11)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01176; 1 Jul 93 6:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01172; 1 Jul 93 6:36 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04619; 1 Jul 93 6:36 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01167; 1 Jul 93 6:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01163; 1 Jul 93 6:36 EDT Received: from TIS.COM by CNRI.Reston.VA.US id aa04608; 1 Jul 93 6:36 EDT Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA22997; Thu, 1 Jul 93 06:36:30 EDT Message-Id: <9307011036.AA22997@TIS.COM> To: Tom Lyon Cc: iplpdn@CNRI.Reston.VA.US, westmark@dirac.scri.fsu.edu Subject: Re: Bandwidth available on DS-3 In-Reply-To: Your message of "Wed, 30 Jun 93 09:54:07 PDT." <9306301654.AA01265@whitsun.eng.sun.com> Date: Thu, 01 Jul 93 06:36:28 -0400 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Stephen D Crocker I'm not sure about the framing of a DS3, but a DS1 carries 1,544,000 bits when all the framing is stripped. As I recall, the frames are 193 bits, and there are 8,000 frames per second. When a DS1 line is subdivided into DS0 channels, the 193 bits is treated as 24 frames of 8 bits with one bit of framing, i.e. 24 * 8 + 1 = 193. One DS3 channel carries 28 DS1 channels. 28 * 1,544,000 = 43,232,000. I don't know how much additional framing overhead there is, but 45 Mbs seems a bit high. Steve > Sender: iplpdn-request@IETF.CNRI.Reston.VA.US > From: Tom Lyon > To: iplpdn@CNRI.Reston.VA.US, westmark@dirac.scri.fsu.edu > Date: Wed, 30 Jun 93 09:54:07 PDT > Subject: Re: Bandwidth available on DS-3 > > > A DS3 carries 7 DS2s which carry 4 DS1s which carry 24 DS0s which are 64Kbits. > So, I'd guess 7*4*24*64000 (not 65536!), which is 43008000 bits/sec. > The framing required to do all this bumps it up to the commonly heard > 45Mbps.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01510; 1 Jul 93 7:28 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01506; 1 Jul 93 7:28 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05443; 1 Jul 93 7:28 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01500; 1 Jul 93 7:28 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01496; 1 Jul 93 7:27 EDT Received: from mwunix.mitre.org by CNRI.Reston.VA.US id aa05406; 1 Jul 93 7:27 EDT Return-Path: Received: from mwmgate2.mitre.org by mwunix.mitre.org (5.65c/SMI-2.2) id AA13412; Thu, 1 Jul 1993 07:28:02 -0400 Message-Id: <199307011128.AA13412@mwunix.mitre.org> Date: Thu, 01 Jul 93 07:25:49 EDT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: m_fidler%W036_NW@mwmgate1.mitre.org To: Tom Lyon Cc: iplpdn@CNRI.Reston.VA.US, westmark@dirac.scri.fsu.edu Subject: Re: Re: Bandwidth available on DS-3 Well, the channel rate on a T3 is 44,732,000 (not 45m) so the difference is overhead (to 43.232). It seems to me that there is an "unframed" version of T3 (*not* DS3) that is not conformant to the M13 mux framing outlined here that is probably what we actually use for data and may differ from all the computations. Anyone have any insight? - Mike F. >I'm not sure about the framing of a DS3, but a DS1 carries 1,544,000 >bits when all the framing is stripped. As I recall, the frames are >193 bits, and there are 8,000 frames per second. When a DS1 line is >subdivided into DS0 channels, the 193 bits is treated as 24 frames of >8 bits with one bit of framing, i.e. 24 * 8 + 1 = 193. > >One DS3 channel carries 28 DS1 channels. 28 * 1,544,000 = 43,232,000. >I don't know how much additional framing overhead there is, but 45 Mbs >seems a bit high. > > >Steve > > >> Sender: iplpdn-request@IETF.CNRI.Reston.VA.US >> From: Tom Lyon >> To: iplpdn@CNRI.Reston.VA.US, westmark@dirac.scri.fsu.edu >> Date: Wed, 30 Jun 93 09:54:07 PDT >> Subject: Re: Bandwidth available on DS-3 >> >> >> A DS3 carries 7 DS2s which carry 4 DS1s which carry 24 DS0s which are >64Kbits. >> So, I'd guess 7*4*24*64000 (not 65536!), which is 43008000 bits/sec. >> The framing required to do all this bumps it up to the commonly heard >> 45Mbps.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03106; 1 Jul 93 8:42 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03101; 1 Jul 93 8:42 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08103; 1 Jul 93 8:42 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03074; 1 Jul 93 8:42 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03070; 1 Jul 93 8:41 EDT Received: from enet-gw.pa.dec.com by CNRI.Reston.VA.US id aa08082; 1 Jul 93 8:41 EDT Received: by enet-gw.pa.dec.com; id AA14047; Thu, 1 Jul 93 05:35:51 -0700 Message-Id: <9307011235.AA14047@enet-gw.pa.dec.com> Received: from manage.enet; by decwrl.enet; Thu, 1 Jul 93 05:42:15 PDT Date: Thu, 1 Jul 93 05:42:15 PDT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rick Szmauz 226-6693 LKG2-2/X12 To: iplpdn@CNRI.Reston.VA.US Cc: szmauz@manage.enet.dec.com Apparently-To: iplpdn@cnri.reston.va.us Subject: Re: Re: Bandwidth available on DS-3 Clear channel DS-3 utilizes 1 bit every 85 for DS-3 framing purposes. Therefore approx. 44.2 Mbps = 44.736 Mbps x 84/85 are available for DS-3 level payload in a native data link application. At the DS-3 level, framing is %98.8 efficient. Of course the efficiency of client data link would have to be factored in to provide the overall payload framing efficiency. ,Rick szmauz@hifi.lkg.dec.com ____________________________ From: HIFI::"m_fidler%W036_NW@mwmgate1.mitre.org@dec:.lkg.us1rmc.dnet" 1-JUL-1993 07:55:00.62 To: Tom Lyon CC: iplpdn@CNRI.Reston.VA.US, westmark@dirac.scri.fsu.edu Subj: Re: Re: Bandwidth available on DS-3 Well, the channel rate on a T3 is 44,732,000 (not 45m) so the difference is overhead (to 43.232). It seems to me that there is an "unframed" version of T3 (*not* DS3) that is not conformant to the M13 mux framing outlined here that is probably what we actually use for data and may differ from all the computations. Anyone have any insight? - Mike F. >I'm not sure about the framing of a DS3, but a DS1 carries 1,544,000 >bits when all the framing is stripped. As I recall, the frames are >193 bits, and there are 8,000 frames per second. When a DS1 line is >subdivided into DS0 channels, the 193 bits is treated as 24 frames of >8 bits with one bit of framing, i.e. 24 * 8 + 1 = 193. > >One DS3 channel carries 28 DS1 channels. 28 * 1,544,000 = 43,232,000. >I don't know how much additional framing overhead there is, but 45 Mbs >seems a bit high. > > >Steve > > >> Sender: iplpdn-request@IETF.CNRI.Reston.VA.US >> From: Tom Lyon >> To: iplpdn@CNRI.Reston.VA.US, westmark@dirac.scri.fsu.edu >> Date: Wed, 30 Jun 93 09:54:07 PDT >> Subject: Re: Bandwidth available on DS-3 >> >> >> A DS3 carries 7 DS2s which carry 4 DS1s which carry 24 DS0s which are >64Kbits. >> So, I'd guess 7*4*24*64000 (not 65536!), which is 43008000 bits/sec. >> The framing required to do all this bumps it up to the commonly heard >> 45Mbps. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by us1rmc.bb.dec.com; id AA10829; Thu, 1 Jul 93 07:53:16 -0400 % Received: by inet-gw-1.pa.dec.com; id AA08136; Thu, 1 Jul 93 04:54:52 -0700 % Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01500; 1 Jul 93 7:28 ED % Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01496; 1 Jul 93 7:27 ED % Received: from mwunix.mitre.org by CNRI.Reston.VA.US id aa05406; 1 Jul 93 7:27 ED % Return-Path: % Received: from mwmgate2.mitre.org by mwunix.mitre.org (5.65c/SMI-2.2) id AA13412; Thu, 1 Jul 1993 07:28:02 -040 % Message-Id: <199307011128.AA13412@mwunix.mitre.org> % Date: Thu, 01 Jul 93 07:25:49 EDT % Sender: iplpdn-request@IETF.CNRI.Reston.VA.US % From: m_fidler%W036_NW@mwmgate1.mitre.org % To: Tom Lyon % Cc: iplpdn@CNRI.Reston.VA.US, westmark@dirac.scri.fsu.edu % Subject: Re: Re: Bandwidth available on DS-3   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04328; 1 Jul 93 9:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04324; 1 Jul 93 9:36 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10177; 1 Jul 93 9:36 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04306; 1 Jul 93 9:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04302; 1 Jul 93 9:35 EDT Received: from inet-gw-1.pa.dec.com by CNRI.Reston.VA.US id aa10115; 1 Jul 93 9:35 EDT Received: by inet-gw-1.pa.dec.com; id AA15959; Thu, 1 Jul 93 06:33:13 -0700 Received: by flashy.tay2.dec.com (5.65/DEC-Ultrix/4.3) id AA05410; Thu, 1 Jul 1993 09:32:11 -0400 Message-Id: <9307011332.AA05410@flashy.tay2.dec.com> Date: Thu, 1 Jul 1993 09:25:34 -0400 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "k1io, FN42jk" To: crocker@tis.com, iplpdn@CNRI.Reston.VA.US Subject: Re: Bandwidth available on DS-3 X-Vms-To: SMTP%"crocker@tis.com" X-Vms-Cc: SMTP%"iplpdn@CNRI.Reston.VA.US" Well, that's the trouble with asking a question about payload of a DS-3. The real payload of a DS-3 is seven DS-2s, not 28 DS-1s, if you take the usual literal interpretation. A DS-2 is 6.312 Mbps; each DS-2 is of course plesiochronous. If you were using DS-3 for raw bits you wouldn't care about DS-1s, a second mux level, would you? Of course why care about DS-2's? But then you have to figure out just how you're going to use the various overheads at the DS-3 level, plus the options like C-bit parity, etc. I think that's why they invented SONET. (only half :-) needed) fred   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05647; 1 Jul 93 10:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05643; 1 Jul 93 10:31 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11856; 1 Jul 93 10:31 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05634; 1 Jul 93 10:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05628; 1 Jul 93 10:30 EDT Received: from uu5.psi.com by CNRI.Reston.VA.US id aa11823; 1 Jul 93 10:30 EDT Received: by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA00980 for ; Thu, 1 Jul 93 10:13:02 -0400 Date: Thu, 1 Jul 93 09:32:34 EDT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Chip Sharp 6424 Received: by teleoscom.com (4.1/3.2.083191-Teleos Communications Inc.) id AA22852; Thu, 1 Jul 93 09:32:34 EDT Message-Id: <9307011332.AA22852@teleoscom.com> To: Tom.Lyon@eng.sun.com Cc: iplpdn@CNRI.Reston.VA.US, westmark@dirac.scri.fsu.edu In-Reply-To: Tom Lyon's message of Wed, 30 Jun 93 09:54:07 PDT <9306301654.AA01265@whitsun.eng.sun.com> Subject: Bandwidth available on DS-3 The following is correct for the M23 Multiplex format of DS3: >From: Tom Lyon >A DS3 carries 7 DS2s which carry 4 DS1s which carry 24 DS0s which are 64Kbits. >So, I'd guess 7*4*24*64000 (not 65536!), which is 43008000 bits/sec. >The framing required to do all this bumps it up to the commonly heard >45Mbps. However, this includes all the overhead for the 7 DS2's and 4 DS1's. If you just take the raw bandwidth of the M23 multiplex you get 7 * 6312 kbit/s = 44184000 bit/s. If you take the raw bandwidth of the DS3 frame format (without the M23 multiplex format) it runs as follows (the frame structure is broken into Multiframes): DS3 raw bit rate = 44736000 bit/s (not 45 Mbit/s) 4760 bits per Multiframe 56 kbit/s overhead per Multiframe If you subtract the overhead from the total bit count you get 4704 bits per multiframe available to carry data. Thus to get the total bandwidth, you can divide the total bandwidth by the number of bits per multiframe to get the number of multiframes per second and then multiply by 4704 to get the number of bits per second: This number comes out to be approximately 44209694 bit/s In order to use this bandwidth you have to define a frame structure within the DS3 frame for your application. For example, the standards committees are now working on a mapping for ATM cells into DS3 frames (which is where I got most of this information). ======================================================================= Hascall H. Sharp Teleos Communications, Inc. System Engineering 2 Meridian Road Eatontown, NJ 07724 voice: +1 908 544 6424 fax: +1 908 544 9890 email: hhs@teleoscom.com ========================================================================   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05719; 1 Jul 93 10:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05715; 1 Jul 93 10:34 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11994; 1 Jul 93 10:34 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05700; 1 Jul 93 10:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05696; 1 Jul 93 10:34 EDT Received: from volitans.MorningStar.Com by CNRI.Reston.VA.US id aa11986; 1 Jul 93 10:34 EDT Received: from remora.MorningStar.Com by volitans.MorningStar.Com (5.65a/93052901) id AA00808; Thu, 1 Jul 93 10:34:37 -0400 Received: by remora.MorningStar.Com (5.65a/93052901) id AA02238; Thu, 1 Jul 93 10:34:31 -0400 Date: Thu, 1 Jul 93 10:34:31 -0400 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Karl Fox Message-Id: <9307011434.AA02238@remora.MorningStar.Com> To: Oliver Korfmacher Cc: iplpdn@CNRI.Reston.VA.US, ietf-ppp@ucdavis.edu, Keith Sklower Subject: Re: Brutal Simplicity References: <199307010204.TAA24191@vangogh.CS.Berkeley.EDU> <9307010739.AA20897@keks.netcs.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Oliver Korfmacher writes: > And: please keep in mind that ISDN is mainly a dial-on-demand > media, so extensive ppp-negotiations in connection setup will definitly > delay the setup time! This is a delay the user directly experiences. Then either your users are very perceptive or your PPP implementation is defective, because I see typical PPP setup times of 600 ms, and this over V.32/V.42/V.42bis modems which likely have much worse delay characteristics than your ISDN lines.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08503; 1 Jul 93 13:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08499; 1 Jul 93 13:17 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18658; 1 Jul 93 13:17 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08407; 1 Jul 93 13:16 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08403; 1 Jul 93 13:12 EDT Received: from mcigateway.mcimail.com by CNRI.Reston.VA.US id aa18563; 1 Jul 93 13:12 EDT Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ad26950; 1 Jul 93 16:59 GMT Date: Thu, 1 Jul 93 16:58 GMT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "David E. McDysan" <0002806303@mcimail.com> To: iplpdn Subject: (Forwarded) Bandwidth available on DS-3 Message-Id: <10930701165801/0002806303MT1EM@mcimail.com> From ANSI T1.107, section 8 (DS3) The nominal interface rate is 44.736 Mb/s. The DS3 signal is partitioned into M-frames of 4760 bits each. There are 56 frame overhead bits per M-frame (The C-bits, framing and other overhead bits are here), the rest of the M-frame bits are available for payload, M13, M23 or "Clear Channel" DS3. For "Clear Channel" DS3 the available rate is then: 4760-56 ------- 44.736 Mb/s = 44.209689 Mb/s 4760 From the ATM Forum UNI spec, version 2.0, section 2.2.2, when the PLCP overhead is taken into account, the bit rate available for transport of ATM cells is 40.704 Mb/s. Dave McDysan dmcdysan@mcimail.com --------------------------------- Forwarded message via: mailbox 1, dmcdysan on MCI ** Message Received OK Date: Wed Jun 30, 1993 5:57 am CDT Source-Date: Wed, 30 Jun 1993 05:47:45 -0400 From: Jay Westmark EMS: INTERNET / MCI ID: 376-5414 MBX: westmark@dirac.scri.fsu.edu TO: * David E. McDysan / MCI ID: 280-6303 TO: David Greenfield / MCI ID: 402-0699 TO: RND - RAD NETWORK DEVICES LTD. / MCI ID: 437-3580 TO: Jim Mollenauer / MCI ID: 478-7822 TO: Michael E. Conn / MCI ID: 438-7451 TO: Henry Sinnreich / MCI ID: 249-8337 TO: Laszlo I. Szerenyi / MCI ID: 432-7219 TO: Mary Jander / MCI ID: 473-4998 TO: Scott Brigham / MCI ID: 244-2341 TO: iplpdn EMS: INTERNET / MCI ID: 376-5414 MBX: iplpdn@cnri.reston.va.us Subject: Bandwidth available on DS-3 Message-Id: 53930630105735/0003765414NA3EM Source-Msg-Id: <199306300947.AA60900@dirac.scri.fsu.edu> All, Does anyone know what is the effective usable bandwidth on a clear channel DS-3 after the framing overhead? -jay westmark --------------------------------- End forwarded message   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15561; 1 Jul 93 18:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15556; 1 Jul 93 18:26 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28615; 1 Jul 93 18:26 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15551; 1 Jul 93 18:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15547; 1 Jul 93 18:25 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa28598; 1 Jul 93 18:25 EDT Received: from tuica-isdn.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 1 Jul 1993 23:25:37 +0100 To: Karl Fox cc: Oliver Korfmacher , iplpdn@CNRI.Reston.VA.US, ietf-ppp@ucdavis.edu, Keith Sklower Subject: Re: Brutal Simplicity In-reply-to: Your message of "Thu, 01 Jul 93 10:34:31 EDT." <9307011434.AA02238@remora.MorningStar.Com> Date: Thu, 01 Jul 93 23:34:19 +0100 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Graham Knight Message-ID: <9307011825.aa28598@CNRI.Reston.VA.US> Karl, In the way in which we use ISDN, 600ms is a significant time. We see ISDN call set-ups of the order of 500ms. This is just about small enough for users to tolerate as an echo delay. Mostly the echo delay on an ISDN call is unnoticable but, if there has been a pause so that the ISDN call has timed out, there will be a delay of the order of 500ms whilst the ISDN call is re-established. Adding another 600ms to this delay really does make a difference. Many users perception of the ISDN will move from "slick" to "clunky". Graham   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16258; 1 Jul 93 19:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16254; 1 Jul 93 19:48 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00411; 1 Jul 93 19:48 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16249; 1 Jul 93 19:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16245; 1 Jul 93 19:48 EDT Received: from volitans.MorningStar.Com by CNRI.Reston.VA.US id aa00406; 1 Jul 93 19:48 EDT Received: from remora.MorningStar.Com by volitans.MorningStar.Com (5.65a/93052901) id AA05095; Thu, 1 Jul 93 19:48:17 -0400 Received: by remora.MorningStar.Com (5.65a/93052901) id AA04553; Thu, 1 Jul 93 19:48:14 -0400 Date: Thu, 1 Jul 93 19:48:14 -0400 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Karl Fox Message-Id: <9307012348.AA04553@remora.MorningStar.Com> To: Graham Knight Cc: ietf-ppp@ucdavis.edu, iplpdn@CNRI.Reston.VA.US Subject: Re: Brutal Simplicity References: <9307011434.AA02238@remora.MorningStar.Com> <9307012225.AA11413@ucdavis.ucdavis.edu> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Graham Knight writes: > Karl, > > In the way in which we use ISDN, 600ms is a significant time. > We see ISDN call set-ups of the order of 500ms. This is just about > small enough for users to tolerate as an echo delay. Mostly the echo > delay on an ISDN call is unnoticable but, if there has been a pause so that > the ISDN call has timed out, there will be a delay of the order of 500ms > whilst the ISDN call is re-established. Adding another 600ms to this > delay really does make a difference. Many users perception of the ISDN > will move from "slick" to "clunky". The 1.1s delay doesn't happen on every keystroke, though -- only on the first keystroke after the idle timer has brought down the connection. How can the user distinguish the ISDN link reestablishment from simply being `swapped out'? How often does that happen, anyway? Are you running with a 5 second idle timer?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00528; 2 Jul 93 2:51 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00524; 2 Jul 93 2:51 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01107; 2 Jul 93 2:51 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00498; 2 Jul 93 2:51 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00494; 2 Jul 93 2:47 EDT Received: from [192.76.152.15] by CNRI.Reston.VA.US id aa01039; 2 Jul 93 2:47 EDT Received: from keks.netcs.com by thuer.netcs.com with SMTP (5.67a8+/25-eef) id AA02635; Fri, 2 Jul 1993 08:47:58 +0200 Received: by keks.netcs.com (5.65/25-eef) id AA23628; Fri, 2 Jul 93 08:47:59 +0200 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Oliver Korfmacher Message-Id: <9307020647.AA23628@keks.netcs.com> Subject: Re: Brutal Simplicity To: Cheng Chen 6444 Date: Fri, 2 Jul 93 8:47:58 MEST Cc: iplpdn@CNRI.Reston.VA.US, ietf-ppp@ucdavis.edu In-Reply-To: <9307011535.AA24681@teleoscom.com>; from "Cheng Chen 6444" at Jul 1, 93 11:35 am X-Mailer: ELM [version 2.2 PL0] X-Charset: ASCII X-Char-Esc: 29 > > > >Yes. We have tested our V.42bis data compression over german > >ISDN (which is well, quite good regarding line quality), and > >every 1000..10000 datagram is broken if we are using HDLC-framing > >only. > > Oliver, > > Could you please elaborate on the way it is "broken"? When it's > broken, is there any possible recovery procedures, or the connection > has to be taken down? Thanks. "broken" means in our context, that the hdlc chip has discarded the received datagram due to its wrong checksum. Higher protocol layers are informed, but in the case of V.42bis with its dynamically changed tables, there is no possibility to recover, since the de-compressor is out of synch. We are then going to tear down the link. But anyhow, our recommendation (to our customers) is to use LAPB is compression is used. Oliver > > Cheng T. Chen > Teleos Communications, Inc. >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00541; 2 Jul 93 2:51 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00537; 2 Jul 93 2:51 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01114; 2 Jul 93 2:51 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00519; 2 Jul 93 2:51 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00515; 2 Jul 93 2:51 EDT Received: from [192.76.152.15] by CNRI.Reston.VA.US id aa01091; 2 Jul 93 2:50 EDT Received: from keks.netcs.com by thuer.netcs.com with SMTP (5.67a8+/25-eef) id AA02647; Fri, 2 Jul 1993 08:51:06 +0200 Received: by keks.netcs.com (5.65/25-eef) id AA23639; Fri, 2 Jul 93 08:51:08 +0200 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Oliver Korfmacher Message-Id: <9307020651.AA23639@keks.netcs.com> Subject: Re: Brutal Simplicity To: karl@morningstar.com Date: Fri, 2 Jul 93 8:51:07 MEST Cc: okorf@netcs.com, iplpdn@CNRI.Reston.VA.US, ietf-ppp@ucdavis.edu, sklower@vangogh.cs.berkeley.edu In-Reply-To: <9307011434.AA02238@remora.MorningStar.Com>; from "Karl Fox" at Jul 1, 93 10:34 am X-Mailer: ELM [version 2.2 PL0] X-Charset: ASCII X-Char-Esc: 29 > > Oliver Korfmacher writes: > > And: please keep in mind that ISDN is mainly a dial-on-demand > > media, so extensive ppp-negotiations in connection setup will definitly > > delay the setup time! This is a delay the user directly experiences. > > Then either your users are very perceptive or your PPP implementation is > defective, because I see typical PPP setup times of 600 ms, and this > over V.32/V.42/V.42bis modems which likely have much worse delay > characteristics than your ISDN lines. As Graham already stated, due to relatively short timeout (in fact, some customers are using 19 seconds due to the local tariff structure) the user may percept the delay more than once. If they are using additional security features like callback or similar, the delay even doubles. Oliver   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04467; 2 Jul 93 9:16 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04463; 2 Jul 93 9:16 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08832; 2 Jul 93 9:16 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04449; 2 Jul 93 9:16 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04444; 2 Jul 93 9:14 EDT Received: from mail.bellcore.com by CNRI.Reston.VA.US id aa08763; 2 Jul 93 9:14 EDT Received: from eve (eve.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA20279; Fri, 2 Jul 1993 09:11:44 -0400 Return-Path: Received: from [128.96.69.98] (nvc-1h409-1) by eve (4.1/4.7) id AA19331; Fri, 2 Jul 93 09:16:28 EDT Date: Fri, 2 Jul 93 09:16:27 EDT X-Station-Sent-From: eve.bellcore.com Message-Id: <9307021316.AA19331@eve> To: jas@proteon.com, Jay Westmark X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: kaj@cc.bellcore.com X-Sender: kaj@eve.bellcore.com Subject: Re: IPX, DECNet, & AppleTalk over FDDI Cc: iplpdn@CNRI.Reston.VA.US, ecmt1@mail.bellcore.com At 5:14 PM 6/29/93 -0400, Jay Westmark wrote: >What about IPX and/or appletalk over frame relay/SMDS? > there are specifications by the SMDS Interest Group (SIG) on at least the following that i'm aware of: - DEC-IV over SMDS - OSI/DEC-V over SMDS - AppleTalk over SMDS (SMDSTalk) (informational spec) - IPX over SMDS (informational spec) IP over SMDS is RFC1209. contact Elysia Tan (SIG WG chair, ecmt1@mail.bellcore.com) for details. kaj 0------------0--------------0-------------0-------------0-----------0 Kaj Tesink pmail Bellcore vmail (908) 758-5254 331 Newman Springs Rd. faxmail (908) 758-4196 Red Bank, NJ 07701 email kaj@cc.bellcore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00748; 6 Jul 93 5:18 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00744; 6 Jul 93 5:18 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03439; 6 Jul 93 5:18 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00719; 6 Jul 93 5:18 EDT Received: from ben.uknet.ac.uk by IETF.CNRI.Reston.VA.US id aa00715; 6 Jul 93 5:08 EDT Received: from castle.ed.ac.uk by ben.uknet.ac.uk via JANET with NIFTP (PP) id ; Tue, 6 Jul 1993 10:09:18 +0100 Received: from spider.co.uk by castle.ed.ac.uk id aa13575; 6 Jul 93 10:09 WET DST Received: by widow.spider.co.uk; Tue, 6 Jul 93 10:15:09 +0100 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Gerry Meyer Date: Tue, 6 Jul 93 10:05:11 +0100 Message-Id: <23369.9307060905@orbweb.spider.co.uk> Received: by orbweb.spider.co.uk; Tue, 6 Jul 93 10:05:11 +0100 To: sklower@vangogh.cs.berkeley.edu Subject: re: Simple Multilink Cc: gerry@spider.co.uk, iplpdn@IETF.CNRI.Reston.VA.US Keith Sklower and I had some private correspondence, reproduced below. I have ADDED my response to his last posting as this new message. Keith wrote: >Feel free to re-post your questions and my responses to the mailing >list. I am trying to make the document reflect more of committee >consensus than my personal opinion. > > Hi. Me again. > > 1) The draft makes no mention of a re-assembly/flush timer on the receive > side other than negatively in #6.2.2. > Even with the null fragment stuffing (#6.2.1) one will still be required > >I am not convinced that a separate re-assembly/flush timer is needed in >addition to a link-dead timer. I am still trying to make this a >``simple'' protocol by not encouraging any options which aren't absolutely >necessary. Even if we specify that there should be such a timer, do we >need a control protocol option to set it? Wouldn't a setting of >4 times the transmission + round trip delay for a maximum sized packet >be a reasonable default? What is the link dead timer? I had assumed the null fragment stuffing had been put in as an attempt to do away with a receiver re-assembly/flush timer. I would actually prefer to do without the null fragment stuffing because: - they are not special, they can get lost just like any other datagram so a re-assembly timer is in my view needed. - they result in additional traffic (which costs on X.25 connections). I could envisage posting an unfragmented packet down one channel followed by null fragments down all channels. Like you, I am not particularly in favour of negotiating everything - the value probably has to be manually configured anyway - so why bother to negotiate it. It must be derivable from the buffer space allocated and the line speed. The real problem with the re-assembly timer is the amount of processing it can potentially consume. But if you've got to have it you've got to have it. > > 2) Is there some way to get round the double header if a datagram is not > being fragmented? > >If you have no requirement that the packet not be sequenced, then >just don't use the fragmentation header! If you do want it >sequenced, but not split, then you need to have some kind of >header saying that there is a sequencing header present. What I want is sequencing without fragmentation at an acceptable cost in terms of header. On X.25 we can support null NLPID (multiplexed) or specific NLPID (non multiplexed) VCs. Multiplexed use is preferred on a number of grounds which I won't go into here. So currently IP, CLNP have a 1 Octet header and IPX, DECnet etc have an additional 5 Octet SNAP header. To provide sequencing in this environment, my interpretation of the proposal introduces a fragment header NLPID (1) + SNAP (5) + SEQUENCE (2) + OFFSET (2) of 10 Octets. So the leading (or perhaps ONLY) fragment for IP, CLNP will have an 11 octet header and IPX, DECnet etc will have a 16 Octet header. Subsequent fragments will have a 10 Octet header independent of protocol. Since I am attracted to NOT fragmenting datagrams I find the leading fragment header rather too large. >I had this argument with a guy from gandalf. He proposed a different >header than the RFC1294 header which had only two bytes instead of >4 bytes (a first bit, a done bit, and a minimum of 11 bit sequence >number, but the sequence number applied to individual fragments). >Thus, his header is good for both sequencing and fragmentation reassembly >but at a cost of two bytes per packet instead of 4 bytes. (the cost >of the fragmentation/reassembly, is thus 2 **bits** out of the 2 byte >structure. > >With normal ppp type negotiation you could compress the fragmentation >header to 1 byte (3b) + the fragmentation/sequencing structure (4 >bytes now, 2 bytes his scheme), and then the header for the >encapsulated packet, which could be a single byte. So, yes you >can save 2 bytes per packet by not using the RFC1294 fragmentation >header. But, I really, really, really am opposed to using a >different header for PPP than 1294; saving two bytes per packet is >just not worth the increase in non-uniformity; on the other hand >I will glad support you in your attempts to convince the 1294 people >that they should change their way of doing segmentation. I am very much in favour of the information being the same wherever it comes from - so 4 bytes for sequnece number and offset is fine. > 3) I think it would be worth being more detailed about the > packet formats in the different variants - by the use of > examples in a future draft. > >OK. Other than the segmentation headers for 1294 and PPP what do >you suggest? A sample sequenced-but-not-fragmented IP packet? > Plus RFC1356 variants with NULL NLPID (IP + SNAP) and specific NLPID. Gerry   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06232; 6 Jul 93 12:11 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06228; 6 Jul 93 12:11 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23332; 6 Jul 93 12:11 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06220; 6 Jul 93 12:11 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06216; 6 Jul 93 12:09 EDT Received: from hobbit.gandalf.ca by CNRI.Reston.VA.US id aa23222; 6 Jul 93 12:09 EDT Received: from donut.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA24234; Tue, 6 Jul 93 12:10:13 EDT Received: by donut.gandalf.ca (4.1/SMI-4.1) id AA00727; Tue, 6 Jul 93 12:09:25 EDT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Carr Message-Id: <9307061609.AA00727@donut.gandalf.ca> Subject: Simple Multilink Comments (fwd) To: iplpdn@CNRI.Reston.VA.US Date: Tue, 6 Jul 1993 12:09:23 -0400 (EDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 3545 I'm not a regular on this list, but have been active on the PPP LAPB and Compression lists. Keith Sklower asked me to cross post here. I would like to see some changes to the Simple Multilink draft from Keith Sklower. Since Keith's proposal basically does away with the standard LAPB/multilink which had been proposed by Fred Baker, and backed by Dave Rand and myself, I felt the need to stur the stew. As many of you may know, I like to squeeze every last byte out of the link. As we start to add more and more header bytes, things like VJ compression start to become useless. Therefore, I propose to lternate method, saving bytes in the header, while reducing complexity. I can see some arguments that this will remove any compatability with RFC1294. SO WHAT! I never liked that one either. (Donning my asbestos suit :-)) At the same time, I also like speed, as I'm sure many of you may be in favour of. It is in this light that I propose the following simple multilink header. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | HDLC FLAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF | 0x03 | 0x00 | 0x3b | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fragmentation Offset field is deleted. This is really redundant information since it can be calculated from the individual fragments. Instead, the sequence number is bumped by one on each and every fragment, not on a per frame basis. The More (M) stolen from X.25 indicates that this packet is not the last fragment. Sequence number range would be a negotiable parameter. Like the protocol field, the sequence number field size compression can be negotiated to reduce the field down to a single byte. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | HDLC FLAG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF | 0x03 | 0x3b |M| Seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For a simple basic rate connection (2B), a sequence number from 0..127 is sufficient to keep the pipe full. For a larger number of links, the extended (default) range of 0..32767 is available. In Keith's proposal, the case of multilink without LAPB is straightforward. The reassembly queue can either be an array or a linked-list of fragments. When one implements LAPB however, the receiver may have to hold onto the fragments from many packets in the window in case of retransmissions. The only practical method I can see for this is a linked list of fragments chained to each receiver ring entry indexed by the sequence number. This means walking down the list to insert, as well as checking the list to check if all fragments have been received for a frame. From an implmentation standpoint, this proposal IMHO is simpler. The receiver simply needs a ring buffer, indexed by the sequence number (modulo as required). Please copy me on any responses to the list, as I haven't requested to be added to this list. -- 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.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09133; 6 Jul 93 14:19 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09129; 6 Jul 93 14:19 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28179; 6 Jul 93 14:19 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09100; 6 Jul 93 14:19 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09095; 6 Jul 93 14:17 EDT Received: from dry.cisco.com by CNRI.Reston.VA.US id aa28153; 6 Jul 93 14:17 EDT Received: from localhost by dry.cisco.com with SMTP id AA22391 (5.67a/IDA-1.5 for iplpdn@cnri.reston.va.us); Tue, 6 Jul 1993 11:12:02 -0700 Message-Id: <199307061812.AA22391@dry.cisco.com> To: Oliver Korfmacher Cc: karl@morningstar.com, iplpdn@CNRI.Reston.VA.US, ietf-ppp@ucdavis.edu, sklower@vangogh.cs.berkeley.edu Subject: Re: Brutal Simplicity In-Reply-To: Your message of "Fri, 02 Jul 1993 08:51:07 EST." <9307020651.AA23639@keks.netcs.com> Date: Tue, 06 Jul 93 11:12:01 MST X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kevin Paul Herbert >As Graham already stated, due to relatively short timeout (in fact, >some customers are using 19 seconds due to the local tariff structure) Interesting... now that many of the long distance carriers in the US are offering 6-second billing, I wonder if people in the US will want to use dial-on-demand in this way in order to do toll avoidance. Kevin   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14471; 6 Jul 93 22:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14467; 6 Jul 93 22:00 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10885; 6 Jul 93 22:00 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14457; 6 Jul 93 22:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14453; 6 Jul 93 21:58 EDT Received: from volitans.MorningStar.Com by CNRI.Reston.VA.US id aa10808; 6 Jul 93 21:58 EDT Received: from remora.MorningStar.Com by volitans.MorningStar.Com (5.65a/93052901) id AA06143; Tue, 6 Jul 93 21:59:27 -0400 Received: by remora.MorningStar.Com (5.65a/93052901) id AA16614; Tue, 6 Jul 93 21:59:25 -0400 Date: Tue, 6 Jul 93 21:59:25 -0400 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Karl Fox Message-Id: <9307070159.AA16614@remora.MorningStar.Com> To: iplpdn@CNRI.Reston.VA.US Subject: InvARP format Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. What PID do Reverse ARP and Inverse ARP use on a frame relay PVC? The latest Multiprotocol over Frame Relay draft contains a nice diagram showing that normal ARP requests and responses use PID 0x0806, but does Reverse ARP use 0x0806 or 0x8035 (the Reverse ARP Ethertype)? What does Inverse ARP use?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00958; 7 Jul 93 7:07 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00954; 7 Jul 93 7:07 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02856; 7 Jul 93 7:07 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00851; 7 Jul 93 7:07 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab00843; 7 Jul 93 7:02 EDT Received: from ben.uknet.ac.uk by CNRI.Reston.VA.US id aa01061; 7 Jul 93 5:01 EDT Received: from castle.ed.ac.uk by ben.uknet.ac.uk via JANET with NIFTP (PP) id ; Wed, 7 Jul 1993 09:50:57 +0100 Received: from spider.co.uk by castle.ed.ac.uk id aa01569; 7 Jul 93 9:50 WET DST Received: by widow.spider.co.uk; Wed, 7 Jul 93 09:57:09 +0100 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Gerry Meyer Date: Wed, 7 Jul 93 09:47:08 +0100 Message-Id: <27579.9307070847@orbweb.spider.co.uk> Received: by orbweb.spider.co.uk; Wed, 7 Jul 93 09:47:08 +0100 To: dcarr@gandalf.ca, iplpdn@CNRI.Reston.VA.US Subject: Re: Simple Multilink Comment Cc: gerry@spider.co.uk Dave Carr wrote: >I'm not a regular on this list, but have been active on the PPP >LAPB and Compression lists. Keith Sklower asked me to cross post >here. > >I would like to see some changes to the Simple Multilink draft from >Keith Sklower. Since Keith's proposal basically does away with the >standard LAPB/multilink which had been proposed by Fred Baker, and >backed by Dave Rand and myself, I felt the need to stur the stew. > >As many of you may know, I like to squeeze every last byte out of the >link. As we start to add more and more header bytes, things like >VJ compression start to become useless. Therefore, I propose to >lternate method, saving bytes in the header, while reducing complexity. > >I can see some arguments that this will remove any compatability >with RFC1294. SO WHAT! I never liked that one either. (Donning >my asbestos suit :-)) > >At the same time, I also like speed, as I'm sure many of you may >be in favour of. > >It is in this light that I propose the following simple multilink >header. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >+-+-+-+-+-+-+-+-+ >| HDLC FLAG | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| 0xFF | 0x03 | 0x00 | 0x3b | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >|M| Sequence | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >The fragmentation Offset field is deleted. This is really redundant >information since it can be calculated from the individual fragments. > >Instead, the sequence number is bumped by one on each and every >fragment, not on a per frame basis. The More (M) stolen from X.25 >indicates that this packet is not the last fragment. One of the problems I have with Keith's proposal is that unfragmented packets are penalised in terms of header length. I like the idea of increamenting the sequence number on every fragment and using the M-bit. One small thing to watch out for is that the packets/fragments following a lost fragment must be discarded up to and including the next one with the M-bit NOT set. If the first packet does NOT have the M-bit set it may be a perfectly valid packet being discarded - probably not a great loss. >Sequence number range would be a negotiable parameter. Like the >protocol field, the sequence number field size compression can be >negotiated to reduce the field down to a single byte. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >+-+-+-+-+-+-+-+-+ >| HDLC FLAG | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >| 0xFF | 0x03 | 0x3b |M| Seq | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >For a simple basic rate connection (2B), a sequence number from >0..127 is sufficient to keep the pipe full. For a larger number >of links, the extended (default) range of 0..32767 is available. To keep it simple I would NOT allow sequence space negotiation. I feel it is important to present the SAME sequence/fragment information in ALL circumstances. This allows you to combine packets/fragments from different sources. >In Keith's proposal, the case of multilink without LAPB is >straightforward. The reassembly queue can either be an array or >a linked-list of fragments. When one implements LAPB however, the >receiver may have to hold onto the fragments from many packets >in the window in case of retransmissions. The only practical >method I can see for this is a linked list of fragments chained >to each receiver ring entry indexed by the sequence number. This >means walking down the list to insert, as well as checking the >list to check if all fragments have been received for a frame. > >From an implmentation standpoint, this proposal IMHO is simpler. >The receiver simply needs a ring buffer, indexed by the sequence >number (modulo as required). > >Please copy me on any responses to the list, as I haven't requested >to be added to this list. Perhaps you could elaborate on its use in different environments: Frame Relay, X.25 and PPP. Gerry   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02615; 7 Jul 93 8:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02611; 7 Jul 93 8:54 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05835; 7 Jul 93 8:54 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02600; 7 Jul 93 8:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02596; 7 Jul 93 8:53 EDT Received: from [192.76.152.15] by CNRI.Reston.VA.US id aa05825; 7 Jul 93 8:53 EDT Received: from keks.netcs.com by thuer.netcs.com with SMTP (5.67a8+/25-eef) id AA18310; Wed, 7 Jul 1993 14:53:12 +0200 Received: by keks.netcs.com (5.65/25-eef) id AA02648; Wed, 7 Jul 93 14:52:58 +0200 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Oliver Korfmacher Message-Id: <9307071252.AA02648@keks.netcs.com> Subject: Re: Brutal Simplicity To: Kevin Paul Herbert Date: Wed, 7 Jul 93 14:52:57 MEST Cc: okorf@netcs.com, karl@morningstar.com, iplpdn@CNRI.Reston.VA.US, ietf-ppp@ucdavis.edu, sklower@vangogh.cs.berkeley.edu In-Reply-To: <199307061812.AA22391@dry.cisco.com>; from "Kevin Paul Herbert" at Jul 06, 93 11:12 am X-Mailer: ELM [version 2.2 PL0] X-Charset: ASCII X-Char-Esc: 29 > > >As Graham already stated, due to relatively short timeout (in fact, > >some customers are using 19 seconds due to the local tariff structure) > Interesting... now that many of the long distance carriers in the US are > offering 6-second billing, I wonder if people in the US will want to use > dial-on-demand in this way in order to do toll avoidance. > > Kevin > I wonder what happens if the so-called 'Spitzabrechnung' becomes thruth. This gives fine-granularity connect time accounting (gran.: 1 sec). Is there any national ISDN which already supports such a thing? Oliver   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05869; 7 Jul 93 10:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05865; 7 Jul 93 10:37 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13177; 7 Jul 93 10:37 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05856; 7 Jul 93 10:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05852; 7 Jul 93 10:36 EDT Received: from mwunix.mitre.org by CNRI.Reston.VA.US id aa13162; 7 Jul 93 10:36 EDT Return-Path: Received: from mwmgate2.mitre.org by mwunix.mitre.org (5.65c/SMI-2.2) id AA21085; Wed, 7 Jul 1993 10:37:26 -0400 Message-Id: <199307071437.AA21085@mwunix.mitre.org> Date: Wed, 07 Jul 93 10:40:03 EDT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: S_SILVERMAN%W035_NW@mwmgate1.mitre.org To: Oliver Korfmacher , Kevin Paul Herbert Cc: okorf@netcs.com, karl@morningstar.com, iplpdn@CNRI.Reston.VA.US, ietf-ppp@ucdavis.edu, sklower@vangogh.cs.berkeley.edu Subject: Re: Brutal Simplicity > > >As Graham already stated, due to relatively short timeout (in fact, > >some customers are using 19 seconds due to the local tariff structure) > Interesting... now that many of the long distance carriers in the US are > offering 6-second billing, I wonder if people in the US will want to use > dial-on-demand in this way in order to do toll avoidance. > > Kevin > I wonder what happens if the so-called 'Spitzabrechnung' becomes truth. This gives fine-granularity connect time accounting (gran.: 1 sec). Is there any national ISDN which already supports such a thing? Oliver There is a difference between the granularity on the timing of a call and the minumum call duration. The TELCO could easily time to 1 second but have a 1 minute minimum. The reality is that there is a real cost associated with setting up a call. This eats both signaling bandwidth and processor time. Somehow, this cost must be passed on to the user. Steve Silverman silverma@mitre.org   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06461; 7 Jul 93 11:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06456; 7 Jul 93 11:01 EDT Received: from ucdavis.ucdavis.edu by CNRI.Reston.VA.US id aa14217; 7 Jul 93 11:01 EDT Received: by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA18674; Wed, 7 Jul 93 07:43:58 PDT X-Orig-Sender: ietf-ppp-request@ucdavis.edu Received: from mwunix.mitre.org by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA18301; Wed, 7 Jul 93 07:36:51 PDT Return-Path: Received: from mwmgate2.mitre.org by mwunix.mitre.org (5.65c/SMI-2.2) id AA21090; Wed, 7 Jul 1993 10:37:29 -0400 Message-Id: <199307071437.AA21090@mwunix.mitre.org> Date: Wed, 07 Jul 93 10:40:03 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: S_SILVERMAN%W035_NW@mwmgate1.mitre.org To: Oliver Korfmacher , Kevin Paul Herbert Cc: okorf@netcs.com, karl@morningstar.com, iplpdn@CNRI.Reston.VA.US, ietf-ppp@ucdavis.edu, sklower@vangogh.cs.berkeley.edu Subject: Re: Brutal Simplicity > > >As Graham already stated, due to relatively short timeout (in fact, > >some customers are using 19 seconds due to the local tariff structure) > Interesting... now that many of the long distance carriers in the US are > offering 6-second billing, I wonder if people in the US will want to use > dial-on-demand in this way in order to do toll avoidance. > > Kevin > I wonder what happens if the so-called 'Spitzabrechnung' becomes truth. This gives fine-granularity connect time accounting (gran.: 1 sec). Is there any national ISDN which already supports such a thing? Oliver There is a difference between the granularity on the timing of a call and the minumum call duration. The TELCO could easily time to 1 second but have a 1 minute minimum. The reality is that there is a real cost associated with setting up a call. This eats both signaling bandwidth and processor time. Somehow, this cost must be passed on to the user. Steve Silverman silverma@mitre.org   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16429; 7 Jul 93 19:28 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16425; 7 Jul 93 19:28 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00631; 7 Jul 93 19:28 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16408; 7 Jul 93 19:28 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16404; 7 Jul 93 19:27 EDT Received: from vangogh.CS.Berkeley.EDU by CNRI.Reston.VA.US id aa00615; 7 Jul 93 19:27 EDT Received: from localhost (sklower@localhost) by vangogh.CS.Berkeley.EDU (8.1C/6.32) id QAA16820; Wed, 7 Jul 1993 16:27:57 -0700 Date: Wed, 7 Jul 1993 16:27:57 -0700 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith Sklower Message-Id: <199307072327.QAA16820@vangogh.CS.Berkeley.EDU> To: iplpdn@CNRI.Reston.VA.US Subject: Is 1356 cast in stone yet? There is a minor thing I'm wondering about - 1356 says that you if you put a snap header in the call-user-data then you logically prepend that snap header to each packet received. On a PVC, real honest-to-goodness call-request packets are not needed for the network sake. However, at least one ISO document (8878 AD2) says that you can make up a call-request, and put the q bit on it, and pass it through the PVC. They do this specifically to transmit the user-connect-data associated with CONS. Is it worth adding this technique to 1356?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17237; 7 Jul 93 20:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17233; 7 Jul 93 20:53 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01997; 7 Jul 93 20:53 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17227; 7 Jul 93 20:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17221; 7 Jul 93 20:52 EDT Received: from vangogh.CS.Berkeley.EDU by CNRI.Reston.VA.US id aa01983; 7 Jul 93 20:52 EDT Received: from localhost (sklower@localhost) by vangogh.CS.Berkeley.EDU (8.1C/6.32) id RAA17374; Wed, 7 Jul 1993 17:52:52 -0700 Date: Wed, 7 Jul 1993 17:52:52 -0700 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith Sklower Message-Id: <199307080052.RAA17374@vangogh.CS.Berkeley.EDU> To: Internet-Drafts@CNRI.Reston.VA.US Subject: multi-protocol over ISDN, parameter-negotiation, simple multi-link Cc: fbaker@acc.com, iplpdn@CNRI.Reston.VA.US Please find two revisions of previously issued internet-drafts, available via anonymous ftp at vangogh.cs.berkeley.edu, in the directory pub/ppp-ipldpn: draft-ietf-iplpdn-multi-isdn-01.txt draft-ietf-iplpdn-para-negotiation-01.txt (multi-isdn had its name changed at committee request, but I suggest keeping the ftp name the same to reduce confusion). Also, in the same directory find a proposal being made to the ppp and iplpdn commitees jointly: draft-ietf-iplpdn-simple-multi-00.txt This is work which mostly represents committee consensus as of the last meeting. ``We will take this up at Amsterdam, and there being no objections, will submit it for advancement to Proposed Standard.'' -- Bill.Simpson   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24944; 8 Jul 93 1:52 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24940; 8 Jul 93 1:52 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08095; 8 Jul 93 1:52 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24934; 8 Jul 93 1:52 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24930; 8 Jul 93 1:51 EDT Received: from mcigateway.mcimail.com by CNRI.Reston.VA.US id aa08084; 8 Jul 93 1:51 EDT Received: from mcimail.com by MCIGATEWAY.MCIMail.com id af22289; 8 Jul 93 5:45 GMT Date: Thu, 8 Jul 93 05:47 GMT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "RND - RAD NETWORK DEVICES LTD." <0004373580@mcimail.com> To: ietf rip To: iplpdn Subject: Message-Id: <84930708054748/0004373580NA1EM@mcimail.com> Hi All Are there any applications or NIC drivers that use (initiate) the LLC Type-1 XID and TEST commands. Are there any routers that use it ? regards Sefi   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00567; 8 Jul 93 3:02 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00563; 8 Jul 93 3:02 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01278; 8 Jul 93 3:02 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00547; 8 Jul 93 3:02 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00543; 8 Jul 93 2:59 EDT Received: from dnlts0.research.ptt.nl by CNRI.Reston.VA.US id aa01207; 8 Jul 93 2:58 EDT Received: from research.ptt.nl by research.ptt.nl (PMDF V4.2-13 #2928) id <01H0ALP15MCG8Y5ORV@research.ptt.nl>; Thu, 8 Jul 1993 09:01:27 +0200 Date: Thu, 08 Jul 1993 09:01:27 +0200 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Guntar Braaf Subject: Remove me from list To: iplpdn@CNRI.Reston.VA.US Message-id: <01H0ALP18KG28Y5ORV@research.ptt.nl> Organization: PTT Research, the Netherlands X-Envelope-to: iplpdn@cnri.reston.va.us X-VMS-To: IN%"iplpdn@cnri.reston.va.us" MIME-version: 1.0 Content-transfer-encoding: 7BIT Remove from this List.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02958; 8 Jul 93 8:19 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02954; 8 Jul 93 8:19 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06338; 8 Jul 93 8:19 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02926; 8 Jul 93 8:19 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02922; 8 Jul 93 8:18 EDT Received: from LOBSTER.WELLFLEET.COM by CNRI.Reston.VA.US id aa06317; 8 Jul 93 8:18 EDT Received: from carp.wellfleet (carp.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA28354; Thu, 8 Jul 93 08:14:18 EDT Received: by carp.wellfleet (4.1/SMI-4.1) id AA02662; Thu, 8 Jul 93 08:11:44 EDT Date: Thu, 8 Jul 93 08:11:44 EDT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Regan Message-Id: <9307081211.AA02662@carp.wellfleet> To: iplpdn@CNRI.Reston.VA.US Please remove me from this list.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09107; 8 Jul 93 12:13 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09103; 8 Jul 93 12:13 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14705; 8 Jul 93 12:13 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09036; 8 Jul 93 12:13 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09032; 8 Jul 93 12:11 EDT Received: from vela.acs.oakland.edu by CNRI.Reston.VA.US id aa14673; 8 Jul 93 12:11 EDT Received: from via.ws04.merit.edu by vela.acs.oakland.edu with SMTP id AA08436 (5.65c+/IDA-1.4.4); Thu, 8 Jul 1993 12:11:33 -0400 Date: Wed, 7 Jul 93 12:31:15 EDT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Message-Id: <1328.bill.simpson@um.cc.umich.edu> To: iplpdn@CNRI.Reston.VA.US Cc: ietf-ppp@ucdavis.edu Reply-To: bsimpson@morningstar.com Subject: Re: Brutal Simplicity I've been a bit appalled by the notion that someone would want to bring up and tear down a circuit between every character, or even between every command. A 6 second or 19 second call is simply ridiculous. I do not think that we should bother designing for such silly situations. It sounds to me as if someone is trying to spoof the telco into giving them "free" time. We should not encourage this, and it is likely to be self defeating in the long run (charges will become more punitive). The tariff structure here in the States includes a line setup "installation" charge, a monthly fee, a fee for the first minute (call setup), and a per 15 second fee after the first minute. The call setup charge is usually about SIX TIMES the incremental charge, and can range as high as TWENTY times. For standard analog local calls, there is no incremental charge. Only the call setup is charged ($0.08-0.25 per call). Calling every 19 seconds would be extremely foolhardy. On the contrary, you should NEVER hang up. Local connection office equipment is smart enough to know whether your call was actually connected, so you are not supposed to get charged for call setup if the call doesn't go through. This means that you ALWAYS get charged if your call completes, even for very short periods of time. Long distance companies (inter-LATA) are always charged for call setup by the local service provider -- whether or not the actual call goes through. For marketing reasons, some will not charge if the call is less than a minute, because they can't tell if the call completed. Most will ALWAYS charge regardless (to recoup the local connection cost). Looking at the above, there is no reason to call for less than the time that the incremental charge is less than the average of the cumulative incremental charge and the setup charge. In fact, the crossover point is at least 4 minutes, and often as long as 15 minutes. For other "special" services, which have the incremental charge, if you don't use a reasonable amount of time, you are really wasting the installation and monthly charges, so the few calls you make are actually *hideously* expensive. Finally, the theoretical (data transmission only) PPP setup time at 64Kbps sync would be approximately 30 milliseconds. For 9,600 bps async, it is theoretically as fast as 177 ms. I measured in the 200-240 ms range in my implementation. It's a bit longer for Morningstar, or the NetBlazer, because they have an extra login step before PPP starts. Bill.Simpson@um.cc.umich.edu   Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09270; 8 Jul 93 12:20 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14921; 8 Jul 93 12:20 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09250; 8 Jul 93 12:20 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09205; 8 Jul 93 12:18 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: iplpdn@CNRI.Reston.VA.US Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: ID ACTION:draft-ietf-iplpdn-multi-isdn-01.txt Date: Thu, 08 Jul 93 12:18:06 -0400 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9307081218.aa09205@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Large Public Data Networks Working Group of the IETF. Title : Determination of Encapsulation of Multi-protocol Datagrams in Circuit-switched Environments Author(s) : K. Sklower Filename : draft-ietf-iplpdn-multi-isdn-01.txt Pages : 9 This document enumerates the existing means for transmitting Internet Protocols across public data networks using circuit-mode ISDN, and other switched services. It recommends limiting the choices to the three most common methods, from which one can determine which method is in use by inspection of the packets. The intention is to capture in a slightly more formal way the level of consensus reached at the 24th - 26th IETF meetings. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-iplpdn-multi-isdn-01.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ietf-iplpdn-multi-isdn-01.txt". For questions, please mail to internet-drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server@nisc.sri.com" Content-Type: text/plain SEND draft-ietf-iplpdn-multi-isdn-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iplpdn-multi-isdn-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain --OtherAccess-- --NextPart--   Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09572; 8 Jul 93 12:27 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15105; 8 Jul 93 12:27 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09536; 8 Jul 93 12:27 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09334; 8 Jul 93 12:24 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: iplpdn@CNRI.Reston.VA.US Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: ID ACTION:draft-ietf-iplpdn-para-negotiation-01.txt Date: Thu, 08 Jul 93 12:24:27 -0400 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9307081224.aa09334@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Large Public Data Networks Working Group of the IETF. Title : Parameter Negotiation for the Multiprotocol Interconnect Author(s) : K. Sklower, C. Frost Filename : draft-ietf-iplpdn-para-negotiation-01.txt Pages : 7 This document describes mechanisms for negotiating operational parameters wherever SNAP encapsulation of Internet Protocols is available. For example, it is suitable for use in conjunction with RFC 1294 (Multiprotocol Over Frame Relay) and RFC 1356 (Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode), and potentially others. The mechanisms described here are intended as optional extensions, intended to facilitate interoperation in public networks were preconfiguration may not have been done symmetrically by all parties who wish to exchange information. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-iplpdn-para-negotiation-01.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ietf-iplpdn-para-negotiation-01.txt". For questions, please mail to internet-drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server@nisc.sri.com" Content-Type: text/plain SEND draft-ietf-iplpdn-para-negotiation-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iplpdn-para-negotiation-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain --OtherAccess-- --NextPart--   Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09648; 8 Jul 93 12:28 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15132; 8 Jul 93 12:28 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09600; 8 Jul 93 12:27 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09360; 8 Jul 93 12:24 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: iplpdn@CNRI.Reston.VA.US Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: ID ACTION:draft-ietf-iplpdn-simple-multi-00.txt Date: Thu, 08 Jul 93 12:24:52 -0400 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9307081224.aa09360@IETF.CNRI.Reston.VA.US> --NextPart A New Internet Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Large Public Data Networks Working Group of the IETF. Title : A Simple Multilink Protocol for Synchronizing the Transmission of Multi-protocol Datagrams. Author(s) : K. Sklower Filename : draft-ietf-iplpdn-simple-multi-00.txt Pages : 12 This document proposes a method for splitting and recombining datagrams across multiple logical data links. Such facilities are desirable to exploit the potential for increased bandwidth offered by multiple bearer channels in ISDN, yet to do so in such away that minimizes reordering of packets. More precisely, modifications to RFC1294 are proposed, and new PPP options and protocols are suggested. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-iplpdn-simple-multi-00.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ietf-iplpdn-simple-multi-00.txt". For questions, please mail to internet-drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server@nisc.sri.com" Content-Type: text/plain SEND draft-ietf-iplpdn-simple-multi-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iplpdn-simple-multi-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain --OtherAccess-- --NextPart--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11306; 8 Jul 93 13:40 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11302; 8 Jul 93 13:40 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17295; 8 Jul 93 13:40 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11275; 8 Jul 93 13:40 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11269; 8 Jul 93 13:39 EDT Received: from volitans.MorningStar.Com by CNRI.Reston.VA.US id aa17259; 8 Jul 93 13:39 EDT Received: from remora.MorningStar.Com by volitans.MorningStar.Com (5.65a/93052901) id AA18912; Thu, 8 Jul 93 13:39:47 -0400 Received: by remora.MorningStar.Com (5.65a/93052901) id AA29270; Thu, 8 Jul 93 13:39:45 -0400 Date: Thu, 8 Jul 93 13:39:45 -0400 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Karl Fox Message-Id: <9307081739.AA29270@remora.MorningStar.Com> To: William Allen Simpson Cc: ietf-ppp@ucdavis.edu, iplpdn@CNRI.Reston.VA.US Subject: Re: Brutal Simplicity References: <1328.bill.simpson@um.cc.umich.edu> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. William Allen Simpson writes: > For 9,600 bps async, it is theoretically as fast as 177 ms. I measured > in the 200-240 ms range in my implementation. > > It's a bit longer for Morningstar, or the NetBlazer, because they have > an extra login step before PPP starts. We usually recommend the extra login step because it's easier to understand and set up, but it's not required, and it's not what I use on my home system.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12764; 8 Jul 93 14:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12760; 8 Jul 93 14:34 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19237; 8 Jul 93 14:34 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12755; 8 Jul 93 14:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12747; 8 Jul 93 14:33 EDT Received: from motgate.mot.com by CNRI.Reston.VA.US id aa19219; 8 Jul 93 14:33 EDT Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.15 for ) id AA25607; Thu, 8 Jul 1993 13:34:14 -0500 Received: from merlin.dev.cdx.mot.com by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.15) id AA29048; Thu, 8 Jul 1993 13:34:11 -0500 Received: from dbg.dev.cdx.mot.com by merlin.dev.cdx.mot.com with SMTP id AA14369 (5.65a+/IDA-1.4.2 for bsimpson@morningstar.com); Thu, 8 Jul 93 14:34:08 -0400 Received: from localhost by dbg.dev.cdx.mot.com with SMTP id AA08387 (5.65a+/IDA-1.4.2 for ietf-ppp@ucdavis.edu); Thu, 8 Jul 93 14:34:06 -0400 Message-Id: <9307081834.AA08387@dbg.dev.cdx.mot.com> To: bsimpson@morningstar.com Cc: iplpdn@CNRI.Reston.VA.US, ietf-ppp@ucdavis.edu Subject: Re: Brutal Simplicity In-Reply-To: Your message of "Wed, 07 Jul 93 12:31:15 EDT." <1328.bill.simpson@um.cc.umich.edu> Date: Thu, 08 Jul 93 14:34:05 -0400 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dan@merlin.dev.cdx.mot.com X-Mts: smtp > I've been a bit appalled by the notion that someone would want to bring > up and tear down a circuit between every character, or even between > every command. ... > It sounds to me as if someone is trying to spoof the telco into giving > them "free" time. We should not encourage this, and it is likely to be > self defeating in the long run (charges will become more punitive). Let me echo that sentiment. Toll avoidance is an ethical issue. The telco folks tend to be paranoid about getting ripped off (result, as I understand it, of a wave of phone phraud during the late 1960's, when some considered stealing from big business a sacrament rather than a sin). Any hint of making standards that manipulate their systems into giving free service sets off alarm bells that, at a minimum, will cause them to obstruct progress. Worse, it creates a situation where features/capabilities needed to support data - like LLC negotiation in ISDN - get wrapped around the axle on the fact that the less progressive elements in the telcos believe they can't trust us to not misuse them. We should be working to build, rather than destroy, trust.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12910; 8 Jul 93 14:42 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12906; 8 Jul 93 14:42 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19731; 8 Jul 93 14:42 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12865; 8 Jul 93 14:42 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12861; 8 Jul 93 14:40 EDT Received: from uunet.ca by CNRI.Reston.VA.US id aa19576; 8 Jul 93 14:40 EDT Received: from tsgfred by mail.uunet.ca with UUCP id <101697(4)>; Thu, 8 Jul 1993 14:41:25 -0400 Received: from rosie.group.com by tsgfred.software.group.com id aa16076; Thu, 8 Jul 93 14:41:05 EDT Subject: Re: Is 1356 cast in stone yet? To: iplpdn@CNRI.Reston.VA.US Date: Thu, 8 Jul 1993 14:39:01 -0400 Cc: Ragnar Paulson In-Reply-To: <199307072327.QAA16820@vangogh.CS.Berkeley.EDU>; from "Keith Sklower" at Jul 7, 93 7:27 pm Reply-to: ragnar@software.group.com X-Mailer: ELM [version 2.2 PL13] X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ragnar Paulson Message-ID: <9307081439.aa21049@rosie.software.group.com> Keith, You write: > > There is a minor thing I'm wondering about - > > 1356 says that you if you put a snap header in the call-user-data > then you logically prepend that snap header to each packet received. > > On a PVC, real honest-to-goodness call-request packets are > not needed for the network sake. However, at least one > ISO document (8878 AD2) says that you can make up a call-request, > and put the q bit on it, and pass it through the PVC. They > do this specifically to transmit the user-connect-data associated > with CONS. Is it worth adding this technique to 1356? > This is the first I've heard of this PVC feature, so I don't think it's very wide spread in network implementations. It's certainly not CCITT conformant which is what most public network providers use. Also it seems to me that the nature of a PVC is it is not dynamic, and thus you don't require the call user data to specify the enscapsulation being used. You just configure both ends the same making it a local issue to the RFC implementation. Is this not a simpler and more reasonable approach? -- Ragnar Paulson email: ...uunet!tsgfred!ragnar The Software Group Limited or: ragnar@software.group.com Phone: 416 856 0238   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13011; 8 Jul 93 14:52 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13007; 8 Jul 93 14:52 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20327; 8 Jul 93 14:52 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13001; 8 Jul 93 14:52 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12997; 8 Jul 93 14:51 EDT Received: from MAIL.BARRNET.NET by CNRI.Reston.VA.US id aa20306; 8 Jul 93 14:51 EDT Received: from isaac.lloyd.COM by mail.barrnet.net (5.67/1.37) id AA01875; Thu, 8 Jul 93 11:51:41 -0700 Message-Id: <9307081851.AA01875@mail.barrnet.net> Date: Thu, 8 Jul 1993 11:52:22 +0800 To: William Allen Simpson , iplpdn@CNRI.Reston.VA.US X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Lloyd X-Sender: brian@mail.barrnet.net Subject: Re: Brutal Simplicity Cc: ietf-ppp@ucdavis.edu At 12:31 7/7/93 -0400, William Allen Simpson wrote: >I've been a bit appalled by the notion that someone would want to bring >up and tear down a circuit between every character, or even between >every command. > >A 6 second or 19 second call is simply ridiculous. I do not think that >we should bother designing for such silly situations. > >It sounds to me as if someone is trying to spoof the telco into giving >them "free" time. We should not encourage this, and it is likely to be >self defeating in the long run (charges will become more punitive). > >The tariff structure here in the States includes a line setup >"installation" charge, a monthly fee, a fee for the first minute (call >setup), and a per 15 second fee after the first minute. The call setup >charge is usually about SIX TIMES the incremental charge, and can range >as high as TWENTY times. > >For standard analog local calls, there is no incremental charge. Only >the call setup is charged ($0.08-0.25 per call). Calling every 19 >seconds would be extremely foolhardy. On the contrary, you should NEVER >hang up. > >Local connection office equipment is smart enough to know whether your >call was actually connected, so you are not supposed to get charged for >call setup if the call doesn't go through. This means that you ALWAYS >get charged if your call completes, even for very short periods of time. > >Long distance companies (inter-LATA) are always charged for call setup >by the local service provider -- whether or not the actual call goes >through. For marketing reasons, some will not charge if the call is >less than a minute, because they can't tell if the call completed. Most >will ALWAYS charge regardless (to recoup the local connection cost). > >Looking at the above, there is no reason to call for less than the time >that the incremental charge is less than the average of the cumulative >incremental charge and the setup charge. In fact, the crossover point >is at least 4 minutes, and often as long as 15 minutes. > >For other "special" services, which have the incremental charge, if you >don't use a reasonable amount of time, you are really wasting the >installation and monthly charges, so the few calls you make are actually >*hideously* expensive. > > >Finally, the theoretical (data transmission only) PPP setup time at >64Kbps sync would be approximately 30 milliseconds. > >For 9,600 bps async, it is theoretically as fast as 177 ms. I measured >in the 200-240 ms range in my implementation. > >It's a bit longer for Morningstar, or the NetBlazer, because they have >an extra login step before PPP starts. > >Bill.Simpson@um.cc.umich.edu Yes, we should be prepared to accommodate short calls because they are not silly. The telcos are starting to play games (read, "writing new tariffs") with call setup costs and billing granularity. Right now the standard granularities are on the order of minutes but one second or less billing granularity is just around the corner (some tariffs already exist). The bottom line is "the bottom line." If call setup costs drop and they start offering second or sub-second billing granularities it may turn out to be cost effective to create and tear down links in only a few seconds. Since we do not know what the future will bring in the way of tariffs, any design should accommodate a wide variety of call durations, even those lasting only a few seconds. Please do not make the mistake of assuming that the telecommunication industry is static and that today's tariffs will apply tommorow. Brian Lloyd BP Lloyd & Associates, Inc. brian@lloyd.com 3420 Sudbury Road brian@mail.barrnet.net Cameron Park, CA 95682 (916) 676-1147 - voice (916) 676-3442 - fax   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13995; 8 Jul 93 16:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13991; 8 Jul 93 16:17 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22928; 8 Jul 93 16:17 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13970; 8 Jul 93 16:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13966; 8 Jul 93 16:15 EDT Received: from merit.edu by CNRI.Reston.VA.US id aa22876; 8 Jul 93 16:15 EDT Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA10702; Thu, 8 Jul 93 16:15:49 -0400 Message-Id: <9307082015.AA10702@merit.edu> To: Karl Fox Cc: William Allen Simpson , ietf-ppp@ucdavis.edu, iplpdn@CNRI.Reston.VA.US Subject: Re: Brutal Simplicity In-Reply-To: Your message of "Thu, 08 Jul 1993 13:39:45 EDT." <9307081739.AA29270@remora.MorningStar.Com> Date: Thu, 08 Jul 1993 16:15:48 -0400 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Larry J. Blunk" > William Allen Simpson writes: > > For 9,600 bps async, it is theoretically as fast as 177 ms. I measured > > in the 200-240 ms range in my implementation. > > > > It's a bit longer for Morningstar, or the NetBlazer, because they have > > an extra login step before PPP starts. > > We usually recommend the extra login step because it's easier to > understand and set up, but it's not required, and it's not what I use on > my home system. It'd be nice if the terminal server vendors could get their act together and support auto-recognition of PPP (Livingston seems to be the only one doing it at this point). PAP and CHAP are so much cleaner than having the user setup some dumb login script (which is specific to the server that they are dialing into). How much code does in take to check for 7E FF 7D 23 .... ???   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14405; 8 Jul 93 16:59 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14399; 8 Jul 93 16:59 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23949; 8 Jul 93 16:59 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14376; 8 Jul 93 16:59 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14372; 8 Jul 93 16:57 EDT Received: from inet-gw-1.pa.dec.com by CNRI.Reston.VA.US id aa23885; 8 Jul 93 16:57 EDT Received: by inet-gw-1.pa.dec.com; id AA07831; Thu, 8 Jul 93 13:58:22 -0700 Received: by flashy.tay2.dec.com (5.65/DEC-Ultrix/4.3) id AA03717; Thu, 8 Jul 1993 16:58:20 -0400 Message-Id: <9307082058.AA03717@flashy.tay2.dec.com> Date: Thu, 8 Jul 1993 16:47:52 -0400 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "k1io, FN42jk" To: iplpdn@CNRI.Reston.VA.US Subject: Re: Brutal Simplicity X-Vms-To: SMTP%"iplpdn@CNRI.Reston.VA.US" >I've been a bit appalled by the notion that someone would want to bring >up and tear down a circuit between every character, or even between >every command. >A 6 second or 19 second call is simply ridiculous. I do not think that >we should bother designing for such silly situations. This is not silly at all. It was silly in the old days of relay- powered telephone lines. With all-digital switching (which you need for ISDN!), it's sensible.... >It sounds to me as if someone is trying to spoof the telco into giving >them "free" time. We should not encourage this, and it is likely to be >self defeating in the long run (charges will become more punitive). >The tariff structure here in the States includes a line setup >"installation" charge, a monthly fee, a fee for the first minute (call >setup), and a per 15 second fee after the first minute. The call setup >charge is usually about SIX TIMES the incremental charge, and can range >as high as TWENTY times. That is the "traditional" tariff structure. It still applies to some tariffs. New Jersey Bell, for instance, has really low (relatively) additional-minute rates, but really high first-minute rates. The long distance carriers, on the other hand, charge the same for the first and additional minutes, or a penny more for the first. They get their per-call surcharges by the rounding-up effect. A more modern tariff is applied by New England Telephone for intra-LATA business toll calls in Massachusetts. The price is quoted as 10.5c per minute (5.5c after 50 hours/month/account) plus I think a penny a call. Calls are timed to the second. The bill is based on total minutes (after adding up the seconds) plus total calls. Maybe it's 6 cents/call, I don't remember offhand, but it's low. >For standard analog local calls, there is no incremental charge. Only >the call setup is charged ($0.08-0.25 per call). Calling every 19 >seconds would be extremely foolhardy. On the contrary, you should NEVER >hang up. Even with antique tariffs like NJBell's, it sometimes makes sense to hang up, after a prolonged idle... The point is that the US is beginning to see rates more like Europe's, and more akin to modern costs. High call setup fees date back to the days of operator call setup. The true cost is in the penny range. For long distance, transmission time is more expensive. The long-term future, I posit, will be "fast circuit" communications, in which bandwidth is allocated for brief (packet-train, perhaps) intervals of time. Call setup is becoming cheaper and cheaper as CPUs get faster. What you pay your carriers today is more a vestige of the past than a portent of the future. fred   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14566; 8 Jul 93 17:16 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14562; 8 Jul 93 17:16 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24409; 8 Jul 93 17:16 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14557; 8 Jul 93 17:16 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14553; 8 Jul 93 17:15 EDT Received: from reggae.concert.net by CNRI.Reston.VA.US id aa24384; 8 Jul 93 17:15 EDT Received: from wg.com (chaos.wg.com) by reggae.concert.net (5.59/tas-reggae/8-15-92) id AA13916; Thu, 8 Jul 93 17:12:15 -0400 Received: from wgt-dev2.wg ([198.85.33.252]) by wg.com (4.1/SMI-4.1) id AA06426; Thu, 8 Jul 93 17:14:06 EDT Date: Thu, 8 Jul 93 17:14:06 EDT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Richard W. Cornetti" Message-Id: <9307082114.AA06426@wg.com> Received: by wgt-dev2.wg (4.1/SMI-4.1) id AA01364; Thu, 8 Jul 93 17:14:25 EDT To: iplpdn@CNRI.Reston.VA.US Subject: IP option I have come across what looks like and IP option type 58. I can not find a reference to it. Does anyone have any idea what it means? Any body know of a reference? Thanks Richard W. Cornetti | cornetti@wg.com | It is better to know Senior Marketing Engineer | TEL: (919) 941-5730 | useless things than Wandel & Goltermann Technologies | FAX: (919) 941-5751 | to know nothing.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14644; 8 Jul 93 17:28 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14640; 8 Jul 93 17:28 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24659; 8 Jul 93 17:28 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14635; 8 Jul 93 17:28 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14631; 8 Jul 93 17:27 EDT Received: from terminator.rs.itd.umich.edu by CNRI.Reston.VA.US id aa24639; 8 Jul 93 17:27 EDT Received: from terminator.rs.itd.umich.edu by terminator.rs.itd.umich.edu (5.67/2.2) with SMTP id AA06436; Thu, 8 Jul 93 16:48:56 -0400 Message-Id: <9307082048.AA06436@terminator.rs.itd.umich.edu> To: bsimpson@morningstar.com Cc: iplpdn@CNRI.Reston.VA.US, ietf-ppp@ucdavis.edu Subject: Re: Brutal Simplicity In-Reply-To: Your message of Wed, 07 Jul 1993 12:31:15 -0400. <1328.bill.simpson@um.cc.umich.edu> Date: Thu, 08 Jul 1993 16:48:53 -0400 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dory Leifer Bill - While I agree with many of your points in this message, I want to point out that there is no hard formula for what makes sense and that flexibility to implement a given policy is key. I would hate to make protocol design decisions because of a particular telco pricing approach. It is even impossible to talk about "tariff structures in the States" because of the wide range of carriers and carrier services. I could, for example, quote rate structures that contradict your assumptions and others that back it. Dory > I've been a bit appalled by the notion that someone would want to bring > up and tear down a circuit between every character, or even between > every command. > > A 6 second or 19 second call is simply ridiculous. I do not think that > we should bother designing for such silly situations. > > It sounds to me as if someone is trying to spoof the telco into giving > them "free" time. We should not encourage this, and it is likely to be > self defeating in the long run (charges will become more punitive). > > The tariff structure here in the States includes a line setup > "installation" charge, a monthly fee, a fee for the first minute (call > setup), and a per 15 second fee after the first minute. The call setup > charge is usually about SIX TIMES the incremental charge, and can range > as high as TWENTY times. > > For standard analog local calls, there is no incremental charge. Only > the call setup is charged ($0.08-0.25 per call). Calling every 19 > seconds would be extremely foolhardy. On the contrary, you should NEVER > hang up. > > Local connection office equipment is smart enough to know whether your > call was actually connected, so you are not supposed to get charged for > call setup if the call doesn't go through. This means that you ALWAYS > get charged if your call completes, even for very short periods of time. > > Long distance companies (inter-LATA) are always charged for call setup > by the local service provider -- whether or not the actual call goes > through. For marketing reasons, some will not charge if the call is > less than a minute, because they can't tell if the call completed. Most > will ALWAYS charge regardless (to recoup the local connection cost). > > Looking at the above, there is no reason to call for less than the time > that the incremental charge is less than the average of the cumulative > incremental charge and the setup charge. In fact, the crossover point > is at least 4 minutes, and often as long as 15 minutes. > > For other "special" services, which have the incremental charge, if you > don't use a reasonable amount of time, you are really wasting the > installation and monthly charges, so the few calls you make are actually > *hideously* expensive. > > > Finally, the theoretical (data transmission only) PPP setup time at > 64Kbps sync would be approximately 30 milliseconds. > > For 9,600 bps async, it is theoretically as fast as 177 ms. I measured > in the 200-240 ms range in my implementation. > > It's a bit longer for Morningstar, or the NetBlazer, because they have > an extra login step before PPP starts. > > Bill.Simpson@um.cc.umich.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14667; 8 Jul 93 17:29 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14663; 8 Jul 93 17:29 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24693; 8 Jul 93 17:29 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14658; 8 Jul 93 17:28 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14654; 8 Jul 93 17:28 EDT Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa24681; 8 Jul 93 17:28 EDT Received: from stev.d-cell.ftp.com by ftp.com via PCMAIL with DMSP id AA10609; Thu, 8 Jul 93 17:29:19 -0400 Date: Thu, 8 Jul 93 17:29:19 -0400 Message-Id: <9307082129.AA10609@ftp.com> To: iplpdn@CNRI.Reston.VA.US, ietf-ppp@ucdavis.edu Subject: Re: Brutal Simplicity X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: stev knowles X-Orig-Sender: stev@ftp.com Repository: babyoil.ftp.com Originating-Client: d-cell.ftp.com while i understand the desire to avoid un-necessary compilications in order to allow extreme cases to work (like tear down on a per character basis), please leave the legality, morality, or ethics of the desire out of it. it is not the intention of the IETF to deal with these issues. thanx.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15134; 8 Jul 93 18:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15130; 8 Jul 93 18:53 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26388; 8 Jul 93 18:53 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15125; 8 Jul 93 18:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15121; 8 Jul 93 18:53 EDT Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa26382; 8 Jul 93 18:53 EDT Received: from tuica-isdn.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 8 Jul 1993 23:52:39 +0100 To: bsimpson@morningstar.com cc: iplpdn@CNRI.Reston.VA.US, ietf-ppp@ucdavis.edu Subject: Re: Brutal Simplicity In-reply-to: Your message of "Wed, 07 Jul 93 12:31:15 EDT." <1328.bill.simpson@um.cc.umich.edu> Date: Fri, 09 Jul 93 00:01:35 +0100 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Graham Knight Message-ID: <9307081853.aa26382@CNRI.Reston.VA.US> Bill, In the UK we pay 4.935p per unit. Depending on time of day and distance one unit buys between 220 secs and 19.2 secs for national calls. For international calls the period drops to 2.19 secs in the worst case. All charge periods cost the same - including the first one of a call - so it is definitely worth timing out calls just before the end of a charge period if the data seems to have dried up. (The 42 pound per quarter per channel ISDN rental are on top of this). I don't think it is crazy for a customer to try to miminise his/her cost of using a service so timeouts of 19 secs or less will be used here. We should not design a solution which only makes sense for the US tariff structure. Actually I don't think your solution does do this since, as you point out, the PP setup time is small compared to the ISDN call setup time. Graham   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15527; 8 Jul 93 19:43 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15523; 8 Jul 93 19:43 EDT Received: from ucdavis.ucdavis.edu by CNRI.Reston.VA.US id aa27261; 8 Jul 93 19:43 EDT Received: by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA02239; Thu, 8 Jul 93 16:01:45 PDT X-Orig-Sender: ietf-ppp-request@ucdavis.edu Received: from haig.cs.ucl.ac.uk by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA01854; Thu, 8 Jul 93 15:53:22 PDT Message-Id: <9307082253.AA01854@ucdavis.ucdavis.edu> Received: from tuica-isdn.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 8 Jul 1993 23:52:39 +0100 To: bsimpson@morningstar.com Cc: iplpdn@CNRI.Reston.VA.US, ietf-ppp@ucdavis.edu Subject: Re: Brutal Simplicity In-Reply-To: Your message of "Wed, 07 Jul 93 12:31:15 EDT." <1328.bill.simpson@um.cc.umich.edu> Date: Fri, 09 Jul 93 00:01:35 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Graham Knight Bill, In the UK we pay 4.935p per unit. Depending on time of day and distance one unit buys between 220 secs and 19.2 secs for national calls. For international calls the period drops to 2.19 secs in the worst case. All charge periods cost the same - including the first one of a call - so it is definitely worth timing out calls just before the end of a charge period if the data seems to have dried up. (The 42 pound per quarter per channel ISDN rental are on top of this). I don't think it is crazy for a customer to try to miminise his/her cost of using a service so timeouts of 19 secs or less will be used here. We should not design a solution which only makes sense for the US tariff structure. Actually I don't think your solution does do this since, as you point out, the PP setup time is small compared to the ISDN call setup time. Graham   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16098; 8 Jul 93 21:15 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16094; 8 Jul 93 21:15 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29371; 8 Jul 93 21:15 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16085; 8 Jul 93 21:15 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16081; 8 Jul 93 21:14 EDT Received: from mescal.NOC.Vitalink.COM by CNRI.Reston.VA.US id aa29337; 8 Jul 93 21:14 EDT Received: from dumbcat.UUCP by mail-relay.Vitalink.COM with UUCP id AA29804 (5.65c/IDA-1.4.4 for iplpdn@cnri.reston.va.us); Thu, 8 Jul 1993 18:13:59 -0700 Received: from localhost by dumbcat.sf.ca.us (4.1/smail-24May90) id AA15003; Thu, 8 Jul 93 18:13:15 PDT To: iplpdn@CNRI.Reston.VA.US, ietf-ppp@ucdavis.edu Reply-To: marc@ascend.com Subject: Re: Brutal Simplicity In-Reply-To: Your message of "Fri, 09 Jul 1993 00:01:35 BST." <9307081853.aa26382@CNRI.Reston.VA.US> Date: Thu, 08 Jul 1993 18:13:14 -0700 Message-Id: <15001.742180394@dumbcat.sf.ca.us> X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marco S Hyman Graham Knight writes: > I don't think it is crazy for a customer to try to miminise > his/her cost of using a service so timeouts of 19 secs or less will > be used here. We should not design a solution which only makes sense > for the US tariff structure. OK, timeouts should be user setable. > Actually I don't think your solution does > do this since, as you point out, the PP setup time is small compared to > the ISDN call setup time. And ISDN isn't the only digital service, and, at least from my perspective*, interoperability over all switched digital services is required. This means that call setup time, in addition to setup cost, is another important factor. Four-wire switched 56 is *pulse* dialed and interoffice calls are likely to be MF dialed between COs. When it takes 10 seconds or more to set up a call you don't want do it every few keystroke, damn the cost! * I couldn't get BRI at home (PacBell land), nor two-wire switched 56. The only game in town was four-wire switched 56. // marc   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01759; 9 Jul 93 8:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01755; 9 Jul 93 8:39 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07250; 9 Jul 93 8:39 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01718; 9 Jul 93 8:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01714; 9 Jul 93 8:35 EDT Received: from ftp.com by CNRI.Reston.VA.US id aa07159; 9 Jul 93 8:35 EDT Received: by ftp.com id AA24105; Fri, 9 Jul 93 08:36:37 -0400 Date: Fri, 9 Jul 93 08:36:37 -0400 Message-Id: <9307091236.AA24105@ftp.com> To: iplpdn@CNRI.Reston.VA.US, ietf-ppp@ucdavis.edu Subject: Predicting the Future -- was Re: Brutal Simplicity X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz This discussion seems amazingly irrelevant. It appears to be all predicated on assumptions of how subscribers behave in face of tariff structures from telcos and other service providers. In other words, if the tariff structure is foo then subscriber's behavior will be bar. This discussion, then, is predicated on psychology, economics, and public policy, not technology. These three things are notoriously hard to predict (especially public policy, which is the domain of politicians and bureaucrats...). It seems to me that, since we can not predict with any certainty, what the tariff environment will be like, we ought not develop a technology that is limited to any one particular tariff regime, or highly pessimal towards other tariff regimes. The technology should allow for lots of short calls, it should allow for fewer, long calls. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08796; 9 Jul 93 17:29 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08792; 9 Jul 93 17:29 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25742; 9 Jul 93 17:29 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08766; 9 Jul 93 17:29 EDT Received: from nsco.network.com by IETF.CNRI.Reston.VA.US id aa08762; 9 Jul 93 17:28 EDT Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA21800; Fri, 9 Jul 93 16:31:55 -0500 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA24654; Fri, 9 Jul 93 16:28:30 CDT Date: Fri, 9 Jul 93 16:28:30 CDT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joel Halpern Message-Id: <9307092128.AA24654@anubis.network.com> To: iplpdn@IETF.CNRI.Reston.VA.US Subject: Simplifying MultiLink My apologies for not doing this up as a draft, and even further apologies for not doing it much sooner. I believe, subject to certain assumptions, that there is a simplication of Keith's very useful MultiLink proposal, which will allow operation over mismatched lines, and a range of behaviors, and will be more implementable on the sending side. [The sending complication I am trying to avoid is the necessity for the sending process to know what has actually started and finished transmission on the actual links, as opposed to what has been queued.] This simplication applies only to unreliable multilink. This procedure preserves order, but does not attempt to recover lost frames. Full LAPB/F procedures should be used for that problem. The encapsulation is exactly as specified by Keith. The transmitter discipline is simply to use increasing sequence numbers. No throttling to avoid windows is required. It is recommended that something be sent on every working link periodically. (Thus, there is a minor drawback if the charge for traffic is significant.) On the receiver side, assuming for discussion that there are N parallel links being used to distribute traffic (with our without link fragmentation), then when a gap is noted in the sequence number: 1) If a larger number is seen on every link, then the frame with the missing value may be presumed lost 2) If some link is not receiving traffic, and a time equal to the link transfer (delay + largest bit latency for a frame) elapses, then it may be presumed that the frame was not queued for that link, and test 1 need be applied only to the remaining links. Comments? Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02406; 10 Jul 93 14:05 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02402; 10 Jul 93 14:05 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11556; 10 Jul 93 14:05 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02393; 10 Jul 93 14:05 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02389; 10 Jul 93 14:02 EDT Received: from vela.acs.oakland.edu by CNRI.Reston.VA.US id aa11510; 10 Jul 93 14:02 EDT Received: from via.ws04.merit.edu by vela.acs.oakland.edu with SMTP id AA05494 (5.65c+/IDA-1.4.4); Sat, 10 Jul 1993 14:03:05 -0400 Date: Sat, 10 Jul 93 13:43:45 EDT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Message-Id: <1340.bill.simpson@um.cc.umich.edu> To: iplpdn@CNRI.Reston.VA.US Cc: ietf-ppp@ucdavis.edu Reply-To: bsimpson@morningstar.com Subject: Predicting the Future > The technology should allow for lots of short calls, it should allow for > fewer, long calls. > The PPP technology requires per call link setup packets. The IPLPDN folks think that (maximum reported) 600 milliseconds is too long. Should I add a qualification to the PPP LCP introduction, stating: This option negotiation typically lasts 600 milliseconds on a low speed link, and has been reported to be less than 30 milliseconds on medium speed links. PPP assumes that rapid switching of the link, such as might happen with mobility in a cell switched network or digital networks with low tariff granularity, is handled by the physical-layer, and is transparent to the link-layer. Bill.Simpson@um.cc.umich.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21586; 12 Jul 93 3:28 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21582; 12 Jul 93 3:28 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17464; 12 Jul 93 3:28 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21565; 12 Jul 93 3:28 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21561; 12 Jul 93 3:26 EDT Received: from dnlts0.research.ptt.nl by CNRI.Reston.VA.US id aa17427; 12 Jul 93 3:26 EDT Received: from PATHWORKS-MAIL by research.ptt.nl (PMDF V4.2-13 #2928) id <01H0G7U4FG0W8Y5ZPT@research.ptt.nl>; Mon, 12 Jul 1993 09:29:03 +0200 Date: Mon, 12 Jul 1993 09:29:03 +0200 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Freddy Bergsma, PTT Research, The Netherlands" Subject: list To: iplpdn@CNRI.Reston.VA.US Message-id: <01H0G7U4GILU8Y5ZPT@research.ptt.nl> Organization: PTT Research, the Netherlands X-Envelope-to: iplpdn@cnri.reston.va.us X-VMS-To: IN%"iplpdn@cnri.reston.va.us" MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Please subscribe to this mailing list.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07649; 14 Jul 93 12:22 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07645; 14 Jul 93 12:22 EDT Received: from ucdavis.ucdavis.edu by CNRI.Reston.VA.US id aa14378; 14 Jul 93 12:22 EDT Received: by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA15797; Wed, 14 Jul 93 08:42:08 PDT X-Orig-Sender: ietf-ppp-request@ucdavis.edu Received: from thuer.netcs.com ([192.76.152.15]) by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA15432; Wed, 14 Jul 93 08:31:53 PDT Received: from keks.netcs.com by thuer.netcs.com with SMTP (5.67a8+/25-eef) id AA07749; Wed, 14 Jul 1993 17:32:21 +0200 Received: by keks.netcs.com (5.65/25-eef) id AA17421; Wed, 14 Jul 93 17:32:18 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Oliver Korfmacher Message-Id: <9307141532.AA17421@keks.netcs.com> Subject: Re: Brutal Simplicity To: bsimpson@morningstar.com Date: Wed, 14 Jul 93 17:32:17 MEST Cc: iplpdn@CNRI.Reston.VA.US, ietf-ppp@ucdavis.edu In-Reply-To: <1328.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Jul 7, 93 12:31 pm X-Mailer: ELM [version 2.2 PL0] X-Charset: ASCII X-Char-Esc: 29 > Finally, the theoretical (data transmission only) PPP setup time at > 64Kbps sync would be approximately 30 milliseconds. Can you give the theory in simple words? My feelings are the same (roughly 50milliseconds), using the following estimation: LCP send conf req send conf ack NCP send conf req send conf ack all theses packets are at least 11 octets without any options, the receive conf ack/naks are omitted since they may interleave with sending, agreed? This gives 44 octets, at 8kbytes/sec minimal 55ms transmission time. Don't misconceive me - I do not want to be pedanticly, but to clarify my own understanding. Oliver   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02549; 15 Jul 93 9:11 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02545; 15 Jul 93 9:11 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07429; 15 Jul 93 9:11 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab02496; 15 Jul 93 9:11 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02492; 15 Jul 93 9:05 EDT Received: from SAFFRON.ACC.COM by CNRI.Reston.VA.US id aa07314; 15 Jul 93 9:05 EDT Received: by saffron.acc.com (4.1/SMI-4.1) id AA18101; Thu, 15 Jul 93 06:03:47 PDT Date: Thu, 15 Jul 93 06:03:47 PDT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Fred Baker Message-Id: <9307151303.AA18101@saffron.acc.com> To: ietf-ppp@ucdavis.edu, iplpdn@nri.reston.va.us Subject: Minutes of IPLPDN and PPP Joint Meetings Cc: dave@mail.bellcore.com, ftev@ftp.com, minutes@nri.reston.va.us Minutes of the Joint Meetings of the PPP Extentions and the IPLPDN Working Groups at the 27th IETF, July 12-14 1993. 1. RFC 1356 X.25 To be recommended as a Draft Standard. Aware of 6-7 implementations with no inter-operability problems. RFC 1294 has already been recommended for advancement to Draft Standard. 2. Protocol Discrimination PPP/Q.922 NLPID value coming up. Bill Simpson needs to resend his justification note to Lyman Chapin, but Lyman has agreed to make this happen. There is a separate issue with the ISDN Lower Layer Compatibility Information Element; George Clapp will pursue obtaining a value indicating PPP. IP/Circuit Switched Service The question was seriously discussed whether we in fact need a default way to send IP over circuit switched services such as ISDN B channel. It was observed that the question is malformed; we do not need a default way to send IP over a V.35 or V.11 interface, for example. We need a way to speak to a peer system at the data link layer, which might be a Frame Relay or X.25 switch, or a peer host or router. We already have standards for PPP, Frame Relay, and X.25. In different contexts, we are willing to run any of the three standards. This approach is recommended for circuit switched services: Systems MUST implement PPP, on the assumption that circuit switched communications communications are generally {host or router} to {host or router}. Systems MAY implement other protocols such as Frame Relay or X.25 The implication here is not that all calls will be initiated with PPP signaling and encapsulation, but that PPP signaling and encapsulation will be a universally implemented option. 3. Multi-link Protocol Changed the header to one of the following: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|P|0|0| Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M - More - 1 if a non-terminal fragment, 0 if the last fragment P - Phase - has the same value on each fragment of a message, inverts from message to message 0 - Reserved, Must be zero Sequence Number - 0..4095 fragment sequence number +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|L|0|0| Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ F - First - 1 if first fragment in a message L - Last - 1 if last fragment in a message 0 - Reserved, Must be zero Sequence Number - 0..4095 fragment sequence number Including a link in the multi-link group is done by authenticating inclusion in the multi-link group and negotiation of the Fragmentation Protocol Control Protocol (FPCP). Removing a link from the multi-link group is done by terminating the FPCP on that link. In the worst case, receiver recovery from a sequence error (fragment loss) is done by sending an FPCP Configure Request in the OPEN state on all links; in most cases, one of the following two conditions is sufficient to detect and step past the loss of a sequenced fragment: receipt of a frame on each link with a successor to the omitted sequence number the expiration of an implementation specific receipt timer; this should be long enough to handle the relevant timing issues There is a separate LCP negotiation, authentication step, and set of Control Protocol negotiations for each link in a multi-link group. Several other options were considered, including the use of the RFC 1294 fragmentation header, which was agreed on in the March meeting; 1294 provides the same essential features as this but requires four octets, and additionally provides only compatibility with RFC 1294. 4. PPP on Frame Relay We need to have an applicability statement for PPP over Frame Relay, in view of the existence of RFC 1294. The default encapsulation is as described in the March IETFs minutes. Various edits were recommended, which will be included in an updated draft, including collapsing of Keith Sklowers parameter negotiation document (with attribution as author) into this document. LQM SHOULD NOT be used on a Frame Relay DLCI. 5. PPP on X.25 We need to have an applicability statement for PPP over X.25 in view of RFCs 877 and 1356. Various edits were recommended, which will be included in an updated draft. Primary attention should be given to reducing the size of the X.25 frame. LQM SHOULD NOT be used in this environment. The PPP NLPID SHOULD be placed in the call user data rather than being carried in each frame. 6. PPP/ISDN Bill Simpson presented his paper on PPP over ISDN. PPP must have the same default MRU (and any other defaults) on ISDN as in other environments. Keith Sklower will publish his IPLPDN document Determination of Encapsulation of Multi-Protocol Datagrams in Circuit Switched Environment, and Bill indicates that he would like to copy some of the technical material from them into this document. It was decided that he would reference Keiths document. 7. Parameter Negotiation Keith and Bill will merge their documents. This document should be separate from the PPP over documents, as it is desired to be placed on the standards track, and the PPP over documents may not be placed on that track. Respectfully submitted Fred Baker, PPP Chair George Clapp, IPLPDN Chair   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05139; 15 Jul 93 14:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05135; 15 Jul 93 14:03 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15234; 15 Jul 93 14:03 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05128; 15 Jul 93 14:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05124; 15 Jul 93 14:01 EDT Received: from volitans.MorningStar.Com by CNRI.Reston.VA.US id aa15218; 15 Jul 93 14:01 EDT Received: from remora.MorningStar.Com by volitans.MorningStar.Com (5.65a/93052901) id AA11327; Thu, 15 Jul 93 14:02:14 -0400 Received: by remora.MorningStar.Com (5.65a/93052901) id AA11159; Thu, 15 Jul 93 14:01:47 -0400 Date: Thu, 15 Jul 93 14:01:47 -0400 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Karl Fox Message-Id: <9307151801.AA11159@remora.MorningStar.Com> To: Fred Baker Cc: iplpdn@CNRI.Reston.VA.US, ietf-ppp@ucdavis.edu Subject: Minutes of IPLPDN and PPP Joint Meetings References: <9307151303.AA18101@saffron.acc.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Fred Baker writes: > Minutes of the Joint Meetings of the PPP Extentions and the IPLPDN > Working Groups at the 27th IETF, July 12-14 1993. ... > 3. Multi-link Protocol ... > There is a separate LCP negotiation, authentication step, and set of > Control Protocol negotiations for each link in a multi-link group. When adding a second circuit to carry, say, IP traffic, do you just run LCP, authentication, and FPCP, or do you also have to run IPCP? I would think you'd just piggyback on the earlier IPCP negotiations and avoid a second (and potentially conflicting) set of IPCP parameters.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05129; 1 Jul 93 10:09 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05125; 1 Jul 93 10:09 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11199; 1 Jul 93 10:09 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05116; 1 Jul 93 10:09 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05112; 1 Jul 93 10:09 EDT Received: from flash.bellcore.com by CNRI.Reston.VA.US id aa11191; 1 Jul 93 10:09 EDT Received: from bulkrate.cc.bellcore.com by flash.bellcore.com (5.61/1.34) id AA27515; Thu, 1 Jul 93 10:09:38 -0400 Received: from blitzen.UUCP by bulkrate.cc.bellcore.com id AA25131 (5.65c/IDA-1.4.4); Thu, 1 Jul 1993 10:11:04 -0400 Message-Id: <199307011411.AA25131@bulkrate.cc.bellcore.com> X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "krishnaswamy,padma" To: X-To: ~iplpdn Date: 1 Jul 1993 10:04 EDT Subject: ds3's -------------------- begin forwarded message -------------------- >From: blitzen!kri (krishnaswamy,padma) To: ietf.nri.reston.va.us!iplpdn-request Date: 1 Jul 1993 8:29 EDT Subject: Re: Bandwidth available on DS-3 Posting from memory, I think the question was about how much data you can have in a DS3.Not all DS3's have to carry 28 DS1's- especially not clear channel DS3's. The nominal line rate in a DS-3 is 44.736. The DS3 overhead functions occupy 1 bit in every 85; the frame is 106.4 microseconds long- the actual 'data' bit rate is 84/85x44.736=44.210 Mbps For further and better particulars, there are a couple of ANSI docs- T1.102 and T1.107 Padma Krishnaswamy   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09669; 22 Jul 93 15:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09661; 22 Jul 93 15:31 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28987; 22 Jul 93 15:31 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09620; 22 Jul 93 15:31 EDT Received: from nsco.network.com by IETF.CNRI.Reston.VA.US id aa09615; 22 Jul 93 15:28 EDT Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA09663; Thu, 22 Jul 93 14:31:33 -0500 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA04227; Thu, 22 Jul 93 14:28:33 CDT Date: Thu, 22 Jul 93 14:28:33 CDT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joel Halpern Message-Id: <9307221928.AA04227@anubis.network.com> To: rolc@nsco.network.com, atm@sun.com, Big-Internet@munnari.oz.au, iplpdn@IETF.CNRI.Reston.VA.US Subject: Routing Over Large Clouds As a consequence of several discussions at the last IETF, and new WG/BOF is being formed. This group will be focussed on the problems of routing over large switched clouds. A charter for this group is being developed with the Routing Area director. To facilitate discussion, I have created the e-mail list, and am sending out this announcement. The list is: rolc@network.com Request for addition should be sent to: rolc-request@network.com The Repostory for the Archive of this list, accessible via anonymous FTP is: nsco.network.com:/rolc/rolc.arc Files of interest to the group will be made available there (in addition to the formal internet-drafts, which of course will be available in the standard repositories.) The topics to be addressed by this group (probably) cover all aspects of routing IP over "large clouds". In this context, large clouds refer primarily to large public data services, such as future ATM, SMDS, and Frame Relay (X.25 may also qualify). In practice a network large enough that a single router can not peer with all other routers is subject to the same problems, and should be addressed by the same solutions. (Thus, it is hoped that this will work on a VERY large bridged ethernet.) Subtopics to be addressed include: A) Architectural implications of relaxing the current requirement that communicating IP entites have a common NET number. B) Routing over Demand Circuits. Gerry Meyers work provides a starting point for making more effective use of the communication media when one is willing/able to peer. C) Operating IS-IS over clouds. Radia Perlman's draft on this should be reviewed. D) Routing and Address Resolution. This is an outgrowth of much previous work, including Directed ARP, Shortcut Routing, NBMA ARP, and architectural thinking by several IAB members. The current proposal (to be fleshed out on the email list, with a clear proposal soon) is based oround a query/response protocol between routers, with MAC addresses carried. Host operation is possible in several different ways (and we need to pick). [The number of individuals who have already contributed to this is too numerous to name, although some individual credits will probably appear in the proposal. Apologies to those who feel that they have contribted much and should be mentioned by name.] Note: The charter is still to be worked, so ideas for other areas should be mailed directly to me. Many people may receive multiple copies of this, but I feel the wide coverage is needed, since the formal IETF announcement of the WG may be a bit in the future. Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11004; 22 Jul 93 16:47 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11000; 22 Jul 93 16:47 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03084; 22 Jul 93 16:47 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10982; 22 Jul 93 16:47 EDT Received: from Sun.COM by IETF.CNRI.Reston.VA.US id aa10978; 22 Jul 93 16:46 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA29475; Thu, 22 Jul 93 13:46:41 PDT Received: from whitsun.eng.sun.com by Eng.Sun.COM (4.1/SMI-4.1) id AA24221; Thu, 22 Jul 93 13:46:44 PDT Received: by whitsun.eng.sun.com (4.1/SMI-4.1) id AA04479; Thu, 22 Jul 93 13:46:40 PDT Date: Thu, 22 Jul 93 13:46:40 PDT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tom Lyon Message-Id: <9307222046.AA04479@whitsun.eng.sun.com> To: rolc@nsco.network.com, atm@sun.com, Big-Internet@munnari.oz.au, iplpdn@IETF.CNRI.Reston.VA.US, jmh@anubis.network.com Subject: Re: Routing Over Large Clouds >This group will be focussed on the problems of routing over large >switched clouds. I think the chief problem of routing over the clouds is brain-damage due to oxygen deprivation. :-)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12839; 23 Jul 93 16:15 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12835; 23 Jul 93 16:15 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06865; 23 Jul 93 16:15 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12774; 23 Jul 93 16:15 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12770; 23 Jul 93 16:12 EDT Received: from relay2.UU.NET by CNRI.Reston.VA.US id aa06724; 23 Jul 93 16:12 EDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA20189; Fri, 23 Jul 93 16:12:24 -0400 Received: from telenet.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 160959.26523; Fri, 23 Jul 1993 16:09:59 EDT Received: from everest.telenet.com by telenet.telenet.com (4.1/SMI-3.2) id AA29809; Fri, 23 Jul 93 16:04:18 EDT Received: by everest.telenet.com (4.1/SMI-4.0) id AA04097; Fri, 23 Jul 93 16:04:19 EDT Date: Fri, 23 Jul 93 16:04:19 EDT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Wu Message-Id: <9307232004.AA04097@everest.telenet.com> To: uunet!NRI.Reston.VA.US!iplpdn@uunet.uu.net Subject: subscribe subscribe   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24439; 24 Jul 93 0:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24435; 24 Jul 93 0:03 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25375; 24 Jul 93 0:03 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24416; 24 Jul 93 0:02 EDT Received: from gibbs.oit.unc.edu by IETF.CNRI.Reston.VA.US id aa24412; 24 Jul 93 0:02 EDT Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1) id AA08573; Sat, 24 Jul 93 00:02:41 -0400 Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1) id AA02800; Sat, 24 Jul 93 00:04:51 EDT Message-Id: <9307240404.AA02800@tipper> X-Really-To: gibbs.oit.unc.edu To: Joel Halpern Cc: rolc@nsco.network.com, atm@sun.com, Big-Internet@munnari.oz.au, iplpdn@IETF.CNRI.Reston.VA.US Subject: Re: Routing Over Large Clouds In-Reply-To: Your message of "Thu, 22 Jul 93 14:28:33 CDT." <9307221928.AA04227@anubis.network.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 24 Jul 93 00:04:51 -0400 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Simon E Spero Don't forget, you have to circle O'hare fifty times for back-compatibility   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06421; 24 Jul 93 22:42 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06417; 24 Jul 93 22:42 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18415; 24 Jul 93 22:42 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06403; 24 Jul 93 22:42 EDT Received: from mcigateway.mcimail.com by IETF.CNRI.Reston.VA.US id aa06399; 24 Jul 93 22:40 EDT Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ad00178; 25 Jul 93 2:20 GMT Date: Sun, 25 Jul 93 00:35 GMT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Henry Sinnreich <0002498337@mcimail.com> To: Joel Halpern Cc: "David E. McDysan" <0002806303@mcimail.com> Cc: David Greenfield <0004020699@mcimail.com> Cc: "RND - RAD NETWORK DEVICES LTD." <0004373580@mcimail.com> Cc: Jim Mollenauer <0004787822@mcimail.com> Cc: "Michael E. Conn" <0004387451@mcimail.com> Cc: "Laszlo I. Szerenyi" <0004327219@mcimail.com> Cc: Mary Jander <0004734998@mcimail.com> Cc: Scott Brigham <0002442341@mcimail.com> Cc: rolc Cc: atm Cc: Big Internet Cc: iplpdn Subject: Re: Routing Over Large Clouds Message-Id: <13930725003531/0002498337MT1EM@mcimail.com> Please add me to the list - this is a very timely topic ! Thanks, Henry Sinnreich MCI Engineering Richardson, Texas   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08076; 26 Jul 93 17:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08072; 26 Jul 93 17:37 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27893; 26 Jul 93 17:37 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08033; 26 Jul 93 17:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08029; 26 Jul 93 17:35 EDT Received: from vangogh.CS.Berkeley.EDU by CNRI.Reston.VA.US id aa27847; 26 Jul 93 17:35 EDT Received: from localhost (sklower@localhost) by vangogh.CS.Berkeley.EDU (8.1C/6.32) id OAA02371; Mon, 26 Jul 1993 14:35:56 -0700 Date: Mon, 26 Jul 1993 14:35:56 -0700 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith Sklower Message-Id: <199307262135.OAA02371@vangogh.CS.Berkeley.EDU> To: iplpdn@CNRI.Reston.VA.US Subject: Multilink Discussion redirected Since, as a consequence of the Amsterdam meeting, the Mutlilink Protocol proposal uses PPP encapsulations (even for Frame Relay and X.25), and since iplpdn is going on hiatus soon, I am directing any more of my comments only to the ietf-ppp@ucdavis.edu list. I am announcing there the location of a new draft reflecting what agreement there was in Amsterdam. 'T's been fun! See y'all later!   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07763; 28 Jul 93 12:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07759; 28 Jul 93 12:03 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18228; 28 Jul 93 12:03 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07663; 28 Jul 93 12:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07659; 28 Jul 93 11:57 EDT Received: from digibd.digibd.com by CNRI.Reston.VA.US id aa17997; 28 Jul 93 11:57 EDT Received: by digibd.com (5.65/DBI-1.19) id AA10366; Wed, 28 Jul 93 10:51:28 -0500 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tom Coradetti Message-Id: <9307281551.AA10366@digibd.com> Subject: Comments on Sklower Multilink To: ietf-ppp@ucdavis.edu Date: Wed, 28 Jul 1993 10:51:27 -0500 (CDT) Cc: iplpdn@CNRI.Reston.VA.US X-Mailer: ELM [version 2.4 PL16] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 7339 Keith, Here are some comments on your draft. This is quite close to being something I would be happy with. tc > > >Draft Simple Multilink July 1993 > > >INTERNET DRAFT >Expires: January 31st, 1994 > ... >This draft incorporates comments arising at the 26th IETF ^^^^ >meeting in Amsterdam. > 27th IETF ... >There are proposals being advanced by communications >providers for providing synchronization between multiple >streams at the bit level; such features are not as yet >widely deployed and it may be useful to have a software >solution as what may prove to be a stopgap measure. 'Stopgap' unnecessarily denegrates this document. ... > >Furthermore, even if the ISDN service providers guarantee >bit-synchronization between different switched circuits, >there may not be sufficiently flexible hardware to combine >the multiple bit streams in arbitrary orders for HDLC bit- >unstuffing. There are plenty of time-space switches on the market. What is problematical is the combination of variable rate circuits. ... > >6.1. Crude Description of Overall Intent 'Crude' is self deprecating. ... >We suggest that multilink operation can be modeled as a sep- >arate PPP Network-Layer protocol with its own control proto- >col, which may be negotiated in the usual PPP manner. A >slightly unusually convention (for PPP) might be to identify ^^ ... >Any changes to the state of logical (group) link from the >default state MUST be made by encapsulating LCP or NCP pack- >ets inside Fragmentation Protocol packets. (I.e. By placing >LCP or NCP packet headers after the fragmentation headers). > LCP packets should never be encapsulated. In the recommended case, LCP, authentication CP, and the Multilink control protocol would run over the physical link, all other NCPs and NPs would run over the bundle. LCP should not be run on the bundle. In some cases it might be acceptable to run some NCP/NP pairs on physical links and other NCP/NP pairs on the bundle. The even more complex case of running the same NCP or NP on both a bundle and its constituent links would not likey be practical. The recommended usage may be concisely represented by a table. On constituient links On the bundle Link LCP Bundle NCP Authentication NCP (1) Compression NP/NCP (5) Link Quality NCP (1) NCP/NP_a (6) Error Correction (2) Compression NP/NCP (3) NCP/NP_b (4) (1) Optional, typical for bundled link (2) Optional, may be needed by compression (3) Optional, may reqire error correcting link (4) Optional, atypical on link (5) Optional, alternate to (3), still may require correcting links (6) Optional, typical on bundle ... >However, in any case the sender MUST transmit fragments with >non-decreasing sequence numbers over any constituent circuit >in a multilink arrangement. In this section we present a Increasing. Non-decreasing includes equal values. ... >The idea is that the receiver should keep track of the mini- >mum of the sequence numbers of all fragments received on all >channels participating in the multilink procedure. (Call >this M). Every time M advances past a fragment bearing an >(E)nding bit that hasn't otherwise been reassembled and >sent, one can discard all fragments with sequence number >less than M. So does this mean that as soon as all of packet B is received that the partial fragments of packet A are discarded? How do you know, simply on the basis of the sequence numbers, what links were used to transmit which fragments? >The sender should transmit a null fragment increasing the >sequence number for each channel when the queue for each >physical link becomes empty; otherwise the receiver will >stall until new packets arrive. This adds work at the transmitter, without much increase in reliability. The null fragment will probably be lost for the same reason as the the missing fragment it is pushing along. Are the null packets part of some other packet? If not, they should be some specific protocol. >As this was intended to be a simple fragmentation/reassembly >protocol, we'll just mention that it would be possible to Maybe you should make the goal viability rather than simplicity. > >have a more-elaborate timer and/or buffer size based imple- >mentations (like the tradition IP reassembly queues in end- >system implementations), but we'll leave that to more ambi- >tious future extensions. > The receiver can implement a buffer wrap scheme as suggested above, or use a timer, without negotiation with the transmitter. However, it would be useful to negotiate the maximum relative window size in units of octets between channels, otherwise the sender could place 100 fragments in one channel each containing 99% of a complete packet, then send the remaining 1% on another channel. This is an extreme case, but asymmetric use of channels is potentially useful. Negotiation of window size is equivalent to negotiation of a timer, but is perhaps less suggestive of implementation. ... >Precedence > FPCP packets may not be exchanged until the Link Con- > trol Protocol has reached the network-layer Protocol > Configuration Negotiation phase (i.e. Authentication > and Link Negotiation have concluded). The FPCP negoti- > ation must precede any other network protocol negotia- > tion. Only for NCP/Nps over the bundle. NCPs on the link can run in parallel. >[The author of this proposal realizes the title of it was >the ***SIMPLE*** multilink protocol, and would not be >gravely disappointed if none of the options were permitted, >but is enumerating them here merely for completeness' sake.] Simplicity is in the eye of the beholder. > >6.4.1. Sequenced Delivery Option > > Figure 3: Sequenced Delivery Option > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | type=1 | length = 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >This option requests the system at the other end of the link >not to deliver packets out of sequence. In the absence of >reliable delivery, a missing fragment in the packet number N >would delay the delay the delivery of packet number N+1 >until receipt of any fragment for packet N+G, where G is the >number of channels participating in the multilink procedure. G should be a parameter. The size of the bundle is a nice default but too restrictive. This makes a presumption about the distribution of fragments over links. >6.4.3. Maximum Receive Reconstructed Unit ... > >This option advises the peer that the implementation will be >able to reconstruct a datagram consisting of the specified >number of bytes. > ?? Can the transmitter negotiate a smaller value? The receiver could reduce its buffer space allocation accordingly. ... >The default value is 8192 bytes. > >Note: this option controls the MRU of the logical (group) >link, and could be negotiated by and LCP options exchange ^ >inside fragmentation packets. Having a protocol option at >the FPCP allows it to be piggy-backed onto other FPCP >options. >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12746; 28 Jul 93 16:41 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12742; 28 Jul 93 16:41 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28786; 28 Jul 93 16:41 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12731; 28 Jul 93 16:41 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12727; 28 Jul 93 16:41 EDT Received: from ftp.com by CNRI.Reston.VA.US id aa28778; 28 Jul 93 16:41 EDT Received: from stev.d-cell.ftp.com by ftp.com via PCMAIL with DMSP id AA18146; Wed, 28 Jul 93 16:42:09 -0400 Date: Wed, 28 Jul 93 16:42:09 -0400 Message-Id: <9307282042.AA18146@ftp.com> To: bill.simpson@um.cc.umich.edu Subject: X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: stev knowles Cc: Joel Halpern , network.com@ftp.com, atm@sun.com, Big-Internet@munnari.oz.au, iplpdn@IETF.CNRI.Reston.VA.US, iesg@CNRI.Reston.VA.US MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US X-Orig-Sender: stev@ftp.com Repository: babyoil.ftp.com Originating-Client: d-cell.ftp.com >I oppose the formation of a new working group for this area, unless it >can be shown that existing groups are incapable of handling this task. >This was the purpose of the IPLPDN WG. IPLPDN folded after amsterdam. it is not the job of a WG in the internet area to be doing work that is clearly in the routing domain. we have a very nice man (bob, hold your hand up) who deals with the routing end of the world. >Extract from IPLPDN charter: this will not be the first time that a group has selectively implemented its charter. >We never did see any *routing* work out of them. Since you were a >prominent member of that group, I don't see how making a new working >group will improve the performance. bill, even though i would not consider my interactions with joel to be as great as those i have had with others, i have found him a very strong and vocal proponent of what he feels is correct, while maintaining the dignity and respect of both himself and the others around him in a technical discussion. unfortunately, i have not found this trait in your interactions with other members of WGs i have observed you in. i woudl imagine that joel would make a wonderful chair of this working group, and i have encouraged bob, remember bob?, to let joel run this new working group. >I suspect that we will see more turf wars as the new group conflicts >with the efforts of existing WGs, and with the IPng groups, which are >also working on the broader routing questions. i have already suggested to the SIP group that any routing work it does beyond just porting existing routing protocols, should be carried out where the routing area (remember bob?) can be sure to provide them with the guideance that they surely will need, since routing is canonically a messy subject. (least, i always feel messy when i leave a routing discussion.) i woudl also imagine that most turf wars about routing will be lost by the internet area, if it finds itself one of the sides. so, this shoudl not be a concern. >I suggest that we disband the IPLPDN group, and focus on building the >desired routing features into the various IPng proposals. while i appreciate your feedback, and i have not discussed my position with my partner, i will strongly resist putting routing work in internet area WGs, other than that i outlined above (minimal changes necessary for porting to the new architecture.) i will keep your comments in mind, along with any other comments this issue generates, and will be sure to let you know if my position is changed by the weight of public opinion. as it stands now, the process for creating this WG seems to be running correctly, since it allowed you to register your complaint before the process had gone too far. if there are a substantial number of complaints, i am sure bob, dave (whom i have only mentioned obliquely as "my partner") and myself will have a discussion about the viability of our current course of action. the final resolution will, i am sure, be announced where ever you read the first announcement. stev knowles still one of the internet area directors   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03862; 30 Jul 93 9:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03858; 30 Jul 93 9:26 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09358; 30 Jul 93 9:26 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03847; 30 Jul 93 9:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03842; 30 Jul 93 9:26 EDT Received: from ftp.com by CNRI.Reston.VA.US id aa09353; 30 Jul 93 9:26 EDT Received: by ftp.com id AA03738; Fri, 30 Jul 93 09:27:04 -0400 Date: Fri, 30 Jul 93 09:27:04 -0400 Message-Id: <9307301327.AA03738@ftp.com> To: bill.simpson@um.cc.umich.edu Subject: X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: jmh@anubis.network.com, atm@sun.com, Big-Internet@munnari.oz.au, iplpdn@IETF.CNRI.Reston.VA.US, iesg@CNRI.Reston.VA.US Bill, at al. History has shown that large, broadly focussed working groups tend to be less productive than do tightly focussed, highly specific working groups. I think that this working group will be an excellent idea. Its members can concentrate on their one, well defined, task and there will be a much higher probability of them producing the right thing in a reasonable time frame. > We never did see any *routing* work out of them. Since you were a > prominent member of that group, I don't see how making a new working > group will improve the performance. These sorts of comments are completely out of order here. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07877; 30 Jul 93 13:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07873; 30 Jul 93 13:01 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16536; 30 Jul 93 13:01 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07864; 30 Jul 93 13:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07857; 30 Jul 93 13:01 EDT Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa16531; 30 Jul 93 13:01 EDT Received: by ginger.lcs.mit.edu id AA28659; Fri, 30 Jul 93 13:01:39 -0400 Date: Fri, 30 Jul 93 13:01:39 -0400 X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Noel Chiappa Message-Id: <9307301701.AA28659@ginger.lcs.mit.edu> To: bill.simpson@um.cc.umich.edu, jmh@anubis.network.com Subject: Routing Over Large Clouds Cc: atm@sun.com, big-internet@munnari.oz.au, iesg@CNRI.Reston.VA.US, iplpdn@IETF.CNRI.Reston.VA.US, jnc@ginger.lcs.mit.edu, rolc@network.com We never did see any *routing* work out of them. Since you were a prominent member of that group, I don't see how making a new working group will improve the performance. I agree with your assessment that the IPLPDN group never got done what the IESG had wanted it to do when it was created, but the blame for that lies in many places, including me (as I'll explain), and I think it's really unfair to beat up one individual member about it, even a vocal and influential one. If you wanted to beat people up, you should beat up the Chair (for allowing the group to get sidetracked), the Area Director (for not seeing that the Chair followed the charter), etc, etc on up the ladder, and me (see below). Now, in all fairness, all these people are volunteers, serving without compensation, with other calls on their time, etc, etc, etc, but they are some of the ones who are supposed to see that this doesn't happen. *All* the WG members themselves also have to bear some blame; this isn't kindergarden, and they are expected to help make things work. I would agree that IPLPDN has not handled the work assigned to them, but was diverted to simpler tasks outside their charter Here's where I catch some blame. I was serving as Internet AD during the period when this happened, and I was *supposed* to set up a number of WG's to do things like define "IP over ATM", "IP over Frame Relay", "IP over ISDN", etc. I didn't. It wasn't just obviously needed, I actually discussed it with the IESG, said I would do so, and talked to potential chairs. I just never followed through (for personal reasons having nothing to do with stuff inside the IETF). I was "derelict in my duty", to use the technical phrase, and any brickbats thrown in my direction for this will be deserved. The inevitable happened: "Nature abhors a vacuum". Without the correct WG's set up to do this in, people who needed it done drifted to IPLPDN and did it there. Should 17 different people have seen this, and stepped in? Yup. Did they try? Yes, actually. Did it do any good? No. creating several incompatible schemes for sending multi-protocol datagrams over LPDN. This just resulted in turf wars with other multi-protocol efforts. Let's not get into this, but there are lots of people out there who think bridging from one type of WAN technology to another is a Good Thing, and are trying to harmonize packet formats to make this easier. I think they are wrong, but there's no way to stop people trying it. Time will tell... I suspect that we will see more turf wars as the new group conflicts with the efforts of existing WGs, and with the IPng groups, which are also working on the broader routing questions. I suggest that we disband the IPLPDN group, and focus on building the desired routing features into the various IPng proposals. I'm less concerned with turf wars, and more with getting the darn problems solved. Tying them into IPng will just create an even *bigger* ball of politics and hassle, and slow down work on these technical problems. Yes, all the IPng groups will need to make sure their schemes handle these issues, but there's no more reason to put these things in IPng groups than there is to bust up, say, multicast work and move it all to IPng groups. The Right Thing *is* to dissolve IPLPDN, and set up two WG's: one each *specifically* for i) address resolution mechanisms on large WAN's (since we have current need for this, plus at least one IPng candidate with a very determined camp of shortish-fixed-length-internetwork-address advocates), and ii) routing mechanisms for large WAN's. The charters should *specifically prohibit* any work on stuff outside the charters, and the Chair's and AD's have to enforce these. Noel   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13059; 30 Jul 93 17:50 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13051; 30 Jul 93 17:50 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26234; 30 Jul 93 17:50 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13034; 30 Jul 93 17:50 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13025; 30 Jul 93 17:50 EDT Received: from vela.acs.oakland.edu by CNRI.Reston.VA.US id aa26211; 30 Jul 93 17:50 EDT Received: from via.ws13.merit.edu by vela.acs.oakland.edu with SMTP id AA23822 (5.65c+/IDA-1.4.4); Fri, 30 Jul 1993 17:50:30 -0400 Date: Fri, 30 Jul 93 15:23:51 EDT X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Message-Id: <922.bill.simpson@um.cc.umich.edu> To: Noel Chiappa Cc: atm@sun.com, big-internet@munnari.oz.au, iesg@CNRI.Reston.VA.US, iplpdn@IETF.CNRI.Reston.VA.US, rolc@network.com Reply-To: bsimpson@morningstar.com Subject: Re: Routing Over Large Clouds > I agree with your assessment that the IPLPDN group never got done what the > IESG had wanted it to do when it was created, but the blame for that lies in > many places, including me (as I'll explain), and I think it's really unfair > to beat up one individual member about it, even a vocal and influential one. OK. I'll agree with that. I like a fellow with the integrity to say "the buck stops here" (to coin a phrase). Your humility becomes you. ;-) In this case, I wanted to make sure this wasn't "I didn't get my way, so I'm forming another group." We have too many working groups already, it's impossible to attend all of the meetings and follow the mailing lists. Also, it is very important that the other affected groups are taken into consideration. Every IPng will be affected. The "cloud" problem isn't fundamentally different from the "radio" problem, so mobile-ip has to be consulted. People have already been working on the problem. > I'm less concerned with turf wars, and more with getting the darn problems > solved. Tying them into IPng will just create an even *bigger* ball of > politics and hassle, and slow down work on these technical problems. Yes, > all the IPng groups will need to make sure their schemes handle these issues, > but there's no more reason to put these things in IPng groups than there is > to bust up, say, multicast work and move it all to IPng groups. > No, but since it may require fundamental paradigm shifts, I think this should be delayed until we have picked IPng, and then all of the various existing IETF WGs would work on the problems in that context, the same as with multicast. The one positive thing that I note in Stev Knowles' message is that the WG will be in the Routing rather than the Internet Area. What the difference is, I don't know, but hopefully that will be more focused. Bill.Simpson@um.cc.umich.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01869; 31 Jul 93 11:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01865; 31 Jul 93 11:36 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10558; 31 Jul 93 11:36 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01852; 31 Jul 93 11:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01848; 31 Jul 93 11:36 EDT Received: from datanet.tele.fi by CNRI.Reston.VA.US id aa10553; 31 Jul 93 11:36 EDT Received: from datanet.tele.fi by datanet.tele.fi id <04447-0@datanet.tele.fi>; Sat, 31 Jul 1993 18:37:11 +0300 To: bsimpson@morningstar.com CC: jnc@ginger.lcs.mit.edu, atm@sun.com, big-internet@munnari.oz.au, iesg@CNRI.Reston.VA.US, iplpdn@IETF.CNRI.Reston.VA.US, rolc@network.com In-reply-to: <922.bill.simpson@um.cc.umich.edu> Subject: Routing Over Large Clouds Date: Sat, 31 Jul 1993 18:37:11 +0300 X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Juha Heinanen X-Orig-Sender: Juha.Heinanen@datanet.tele.fi Message-ID: <9307311136.aa10553@CNRI.Reston.VA.US> i oppose delaying any IP developments "before we have picked IPng", since noone knows when that will happen (if ever). we have god knows how many IP hosts out there which will have a long life still ahead of them. -- juha   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01895; 31 Jul 93 11:40 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01891; 31 Jul 93 11:40 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10642; 31 Jul 93 11:40 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01863; 31 Jul 93 11:40 EDT Received: from datanet.tele.fi by IETF.CNRI.Reston.VA.US id aa01859; 31 Jul 93 11:36 EDT Received: from datanet.tele.fi by datanet.tele.fi id <04447-0@datanet.tele.fi>; Sat, 31 Jul 1993 18:37:11 +0300 To: bsimpson@morningstar.com CC: jnc@ginger.lcs.mit.edu, atm@sun.com, big-internet@munnari.oz.au, iesg@CNRI.Reston.VA.US, iplpdn@IETF.CNRI.Reston.VA.US, rolc@network.com In-reply-to: <922.bill.simpson@um.cc.umich.edu> Subject: Routing Over Large Clouds Date: Sat, 31 Jul 1993 18:37:11 +0300 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Juha Heinanen X-Orig-Sender: Juha.Heinanen@datanet.tele.fi Message-ID: <9307311136.aa01859@IETF.CNRI.Reston.VA.US> i oppose delaying any IP developments "before we have picked IPng", since noone knows when that will happen (if ever). we have god knows how many IP hosts out there which will have a long life still ahead of them. -- juha   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01954; 31 Jul 93 11:52 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01950; 31 Jul 93 11:52 EDT Received: from Sun.COM by CNRI.Reston.VA.US id aa10896; 31 Jul 93 11:52 EDT Received: from Eng.Sun.COM (engnews1.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA29046; Sat, 31 Jul 93 08:39:07 PDT Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA21720; Sat, 31 Jul 93 08:37:34 PDT Received: by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA26931; Sat, 31 Jul 93 08:37:44 PDT Received: from Eng.Sun.COM (engnews1) by atm.Eng.Sun.COM (4.1/SMI-4.1) id AA26925; Sat, 31 Jul 93 08:37:42 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA21682; Sat, 31 Jul 93 08:36:19 PDT Received: from datanet.tele.fi by Sun.COM (4.1/SMI-4.1) id AA28994; Sat, 31 Jul 93 08:37:45 PDT Message-Id: <9307311537.AA28994@Sun.COM> Received: from datanet.tele.fi by datanet.tele.fi id <04447-0@datanet.tele.fi>; Sat, 31 Jul 1993 18:37:11 +0300 To: bsimpson@morningstar.com Cc: jnc@ginger.lcs.mit.edu, atm@sun.com, big-internet@munnari.oz.au, iesg@CNRI.Reston.VA.US, iplpdn@IETF.CNRI.Reston.VA.US, rolc@network.com In-Reply-To: <922.bill.simpson@um.cc.umich.edu> Subject: Routing Over Large Clouds Date: Sat, 31 Jul 1993 18:37:11 +0300 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Juha Heinanen X-Orig-Sender: atm-request@atm.eng.sun.com i oppose delaying any IP developments "before we have picked IPng", since noone knows when that will happen (if ever). we have god knows how many IP hosts out there which will have a long life still ahead of them. -- juha   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02994; 31 Jul 93 15:23 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02990; 31 Jul 93 15:23 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa16035; 31 Jul 93 15:23 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21477; Sun, 1 Aug 1993 04:33:51 +1000 (from owner-big-internet) Message-Id: <9307311833.21477@munnari.oz.au> Received: from datanet.tele.fi by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16458; Sun, 1 Aug 1993 01:37:59 +1000 (from Juha.Heinanen@datanet.tele.fi) Received: from datanet.tele.fi by datanet.tele.fi id <04447-0@datanet.tele.fi>; Sat, 31 Jul 1993 18:37:11 +0300 To: bsimpson@morningstar.com Cc: jnc@ginger.lcs.mit.edu, atm@sun.com, big-internet@munnari.oz.au, iesg@CNRI.Reston.VA.US, iplpdn@IETF.CNRI.Reston.VA.US, rolc@network.com In-Reply-To: <922.bill.simpson@um.cc.umich.edu> Subject: Routing Over Large Clouds Date: Sat, 31 Jul 1993 18:37:11 +0300 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Juha Heinanen X-Orig-Sender: Juha.Heinanen@datanet.tele.fi i oppose delaying any IP developments "before we have picked IPng", since noone knows when that will happen (if ever). we have god knows how many IP hosts out there which will have a long life still ahead of them. -- juha