From ietf-ppp-request@MERIT.EDU Tue Oct 1 08:50:52 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id IAA04704; Tue, 1 Oct 1996 08:50:52 -0400 (EDT) Resent-Date: Tue, 1 Oct 1996 08:50:52 -0400 (EDT) Date: Tue, 1 Oct 1996 08:51:22 -0400 From: Patrick Klos Message-Id: <199610011251.IAA03921@linux.klos.com> To: ietf-ppp@MERIT.EDU Subject: Re: I-D ACTION:draft-ietf-pppext-link-negot-00.txt Resent-Message-ID: <"PqNkF3.0.t81.sDHKo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2102 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> Just send the Peer-Identity (Endpoint-Descriminator if you like) during >> LCP, use that for configuring LCP, then hang up after authentication if >> the peer ID or password were wrong. > >That is another possibility, except that there is no suitable >Endpoint-Descriminator class. If you add a username ED class to RFC >1990, why not do it right and include authentication with the name? That's your opinion that including authentication is the "right thing", not mine. I don't see the problem being worth any more effort than adding a Peer-Identity option and allowing LCP to use that to help it configure itself. As has been mentioned before, this functionality exists now with LCP re-negotiation, so I don't see why a whole lot of effort should be expended on this proposed change. ============================================================================ Patrick Klos Email: klos@klos.com Klos Technologies, Inc. Voice: (603) 424-8300 604 Daniel Webster Highway FAX: (603) 424-9300 Merrimack, New Hampshire 03054 Web: http://web.klos.com/ ============================================================================ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Oct 1 10:56:52 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id KAA07376; Tue, 1 Oct 1996 10:56:52 -0400 (EDT) Resent-Date: Tue, 1 Oct 1996 10:56:52 -0400 (EDT) Date: Tue, 1 Oct 1996 08:56:34 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199610011456.IAA11029@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: I-D ACTION:draft-ietf-pppext-link-negot-00.txt Resent-Message-ID: <"PTYk.0.wo1.k4JKo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2103 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > From: Patrick Klos > > >> Just send the Peer-Identity (Endpoint-Descriminator if you like) during > >> LCP, use that for configuring LCP, then hang up after authentication if > >> the peer ID or password were wrong. > > > >That is another possibility, except that there is no suitable > >Endpoint-Descriminator class. If you add a username ED class to RFC > >1990, why not do it right and include authentication with the name? > > That's your opinion that including authentication is the "right thing", > not mine. I don't see the problem being worth any more effort than > adding a Peer-Identity option and allowing LCP to use that to help it > configure itself. As has been mentioned before, this functionality exists > now with LCP re-negotiation, so I don't see why a whole lot of effort > should be expended on this proposed change. Done right, no extra effort would be required by any system that does not want to play the game. I hope most people would agree that if a new ED "name" class were added, that it would be best to have the class consist of three fields, "username", "challenge," and "response." The second two could be null or ignored by systems that insist on spending time and more complexity on 6 more redundant packets packets later in the Authenticate Phase. Yes, more complexity, since you would have to deal with the corner cases, such as getting differing names from a CHAP packet than the ED class, as well as stalling some actions such as joining multilink bundles and calling back until the Network Phase. Yes, of course, those of us who have <> implemented multilink, call-back, and so forth under the current rules wouldn't gain much, except when dealing with the complaints from our customers trying to connect to new implementations, many of which are wrong at first. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Oct 1 23:15:22 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id XAA20927; Tue, 1 Oct 1996 23:15:22 -0400 (EDT) Resent-Date: Tue, 1 Oct 1996 23:15:22 -0400 (EDT) Date: Tue, 1 Oct 1996 23:13:19 -0400 (EDT) From: John Gregg Message-Id: <199610020313.XAA23861@shiva-dev.shiva.com> To: ietf-ppp@MERIT.EDU Subject: routing protocol option in IPXCP Resent-Message-ID: <"F47xB.0.e65.suTKo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2104 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Given that there are vendors doing triggered RIP/SAP for IPX, how is this being negotiated? Or is it simply not being negotiated, and both peers assume triggered RIP/SAP (thus sidestepping PPP negotiation entirely)? More to the point, if it is possible to configure a box to do, say, triggered SAP but no RIP, or triggered SAP but standard RIP, how is *this* negotiated? The IPXCP spec has one option (option 4) for routing protocol, with the following values: 0 = None, 1 = RESERVED, 2 = RIP/SAP, 4 = NLSP. The IANA just assigned the following: 6 = RFC 1582 Demand RIP, 7 = RFC 1582 Demand SAP, 8 = triggered RIP, 9 = triggered SAP. I assume that if a box wants to advertise its willingness to receive triggered RIP and triggered SAP, it includes the IPXCP routing protocol option twice in its Config Request, once with 8 and once with 9. If the other end wants to NAK one of those but not the other, what can it do that makes its intention completely clear? Maybe Nak with both options, set up the way it would like to see them in the next Config Request, even if one of them is no different than that sent in the Config Request being Nakked . . . Either way, I bet lots of implementations will have some problems with two instances of the same option in the same Config Request, conveying different kinds of information each time (as opposed to just containing more of the same information, as in the case of multiple instances of the NBFCP Names option). If in fact people can configure RIP independently from SAP, shouldn't they be separate options? This would involve deprecating the existing option and inventing two new ones. Alternatively, I suppose we could use the unused values of the existing Routing Protocol option and split it into distinct fields, one for RIP and one for SAP. How (if at all) do you all deal with this? -John Gregg Shiva Corp. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 2 03:52:05 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id DAA23482; Wed, 2 Oct 1996 03:52:05 -0400 (EDT) Resent-Date: Wed, 2 Oct 1996 03:52:05 -0400 (EDT) Mime-Version: 1.0 Date: Wed, 2 Oct 1996 08:50:35 +0100 Message-ID: <2521efa0@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: I-D ACTION:draft-ietf-pppext-link-negot-00.txt To: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"UcnAj3.0.bk5.WyXKo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2105 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From Vernon Schryver, vjs@sgi.com > I hope most people would agree that if a new ED "name" class were > added, that it would be best to have the class consist of three > fields, "username", "challenge," and "response." Actually, four fields are required: the ED must have more than just the username - this is the reason that the ED option was created in the first place. I don't think that we can take functionality away from the ED option. The 4th field therefore would be equivalent to the other classes of ED (i.e. with 6 sub-classes). > The second two could be null or ignored by systems that insist on > spending time and more complexity on 6 more redundant packets later > in the Authenticate Phase. Fortunately they'd be absent unless a system issued a challenge, so they WOULD be null. Also (I know it's obvious but it needs to be stated) this new class of ED is different to others, as not all of it is used for matching the link to other links in the bundle (i.e. the response field isn't used). Frankly I'd rather have a new LCP option as in the draft. --- Jonathan.Goodchild@rdl.co.uk - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 2 10:43:44 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id KAA28939; Wed, 2 Oct 1996 10:43:44 -0400 (EDT) Resent-Date: Wed, 2 Oct 1996 10:43:44 -0400 (EDT) Date: Wed, 2 Oct 1996 08:42:57 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199610021442.IAA02189@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: I-D ACTION:draft-ietf-pppext-link-negot-00.txt Resent-Message-ID: <"aq1RM.0.i37.xzdKo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2106 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > > I hope most people would agree that if a new ED "name" class were > > added, that it would be best to have the class consist of three > > fields, "username", "challenge," and "response." > > Actually, four fields are required: the ED must have more than just the > username - this is the reason that the ED option was created in the > first place. > > I don't think that we can take functionality away from the ED option. > The 4th field therefore would be equivalent to the other classes of ED > (i.e. with 6 sub-classes). On the contrary, an authenticated (host) name can be considered the equivalent of the other classes of ED. There would be no more reason for sending both the name and a magic number in one ED option that there was reason to send both an ED magic number and an ED IP address. I really wish people would not think of PPP as a dumb terminal protocol. The "username" fields of CHAP and PAP should have been called the "hostname." PPP does not connect people to NAS's. PPP connects computers. The name in the proposed new LCP option, the names in the CHAP and PAP packets, the name in the suggested new ED class, and the identifying strings in threee of the existing ED classes. Yes, that would mean you could not have more than one multilink bundle per pair of new ED class "name". So what? You can't have more than one multilink bundle between pairs of IP addresses, telephone numbers, or system serial numbers, thanks to ED. > > The second two could be null or ignored by systems that insist on > > spending time and more complexity on 6 more redundant packets later > > in the Authenticate Phase. > > Fortunately they'd be absent unless a system issued a challenge, so > they WOULD be null. > > Also (I know it's obvious but it needs to be stated) this new class of > ED is different to others, as not all of it is used for matching the > link to other links in the bundle (i.e. the response field isn't used). Not so. All of the fields would be "used for matching." It is only that the computation behind the answer "match/no-match" is more complicated than a simple bit-comparison. Such distinctions are important and not mere logic chopping. As has been demonstrated again and again (e.g. in the MS-CHAP mistake), the labels you put on things (i.e. the abstactions you use) are at least as important as the descriptions of the bits in the packets. > Frankly I'd rather have a new LCP option as in the draft. In my view, it's all the same. I suspose some will now say that it is desirable to have more than one human user of a (username,secret) pair. Oh, well. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 3 11:46:10 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id LAA27376; Thu, 3 Oct 1996 11:46:10 -0400 (EDT) Resent-Date: Thu, 3 Oct 1996 11:46:10 -0400 (EDT) Date: Thu, 3 Oct 1996 15:44:48 GMT Message-Id: <199610031544.PAA21283@carp.morningstar.com> From: Karl Fox To: ietf-ppp@MERIT.EDU Subject: San Jose IETF schedule for PPPEXT Working Group Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"1ENE.0.tg6.mzzKo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2107 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The PPPEXT Working Group will meet at the San Jose IETF on Tuesday, December 10 at 1300 (opposite rmonmib, pkix, mboned) Wednesday, December 11 at 1530 (opposite cat, disman, idmr)) -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Oct 4 17:44:50 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id RAA03854; Fri, 4 Oct 1996 17:44:50 -0400 (EDT) Resent-Date: Fri, 4 Oct 1996 17:44:50 -0400 (EDT) Date: Fri, 4 Oct 1996 14:43:35 -0700 (PDT) From: Kory Hamzeh To: ietf-ppp@MERIT.EDU Subject: Multiple BACP Call Requests Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"yynz_1.0.lx.sKOLo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2108 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU When using BACP, if I need to bring up, say, 6 additional links, do I need to wait for each Call Response before I send the next Call Request? Or, can I just fire off the 6 Call Requests? Thanks, Kory - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sat Oct 5 01:19:39 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id BAA10081; Sat, 5 Oct 1996 01:19:39 -0400 (EDT) Resent-Date: Sat, 5 Oct 1996 01:19:39 -0400 (EDT) Date: Fri, 4 Oct 1996 16:14:06 -0700 (PDT) From: Philip Rakity X-Sender: pmr@zeus To: ietf-ppp@MERIT.EDU Subject: CallBack LCP Extension Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Mu6WH2.0.FT2.T_ULo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2109 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU If I understand the problem with the previous version, it was that a local sytem could propose callback and a remote could accept it, and then refuse to callback. This would happen after the remote system authenicated the local system and then found that the remote system was not authorized to callback. I believe that there are 2 easy fixes to this problem that do not involve any protocol changes. 1. Redefine the meaning of the proposal to do callback. Make it simply mean, I would like you to call me back if you are able to do this in the future, rather than I require that you call me back. The ack to the request would then be fine, and a subsequent refusal to dialback would be fine too. (eg the receiver of the call does not disconnect if it cannnot callback.) 2. Keep the options as it now is, with 1), but add a new option that includes information need to dialback the caller and information to identify the caller (eg system name, pseudo password, etc). There are options currently available in the callback option to identify the user, as well as options to specify where to callback. Philip - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sat Oct 5 02:05:05 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id CAA10652; Sat, 5 Oct 1996 02:05:05 -0400 (EDT) Resent-Date: Sat, 5 Oct 1996 02:05:05 -0400 (EDT) Date: Sat, 5 Oct 1996 00:04:51 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199610050604.AAA17236@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: CallBack LCP Extension Resent-Message-ID: <"V_luC1.0.Ac2.DgVLo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2110 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Philip Rakity > ... > 1. Redefine the meaning of the proposal to do callback. Make it simply > mean, I would like you to call me back if you are able to do this in the > future, rather than I require that you call me back. The ack to the > request would then be fine, and a subsequent refusal to dialback would be > fine too. (eg the receiver of the call does not disconnect if it cannnot > callback.) What happens when (not just if) the phone company does everyone a favor and disconnects? How can the client tell the difference between the phone company killing the link and the server disconnecting in preparation for callling back? > 2. Keep the options as it now is, with 1), but add a new option that > includes information need to dialback the caller and information to > identify the caller (eg system name, pseudo password, etc). There are > options currently available in the callback option to identify the user, > as well as options to specify where to callback. What is the difference between a "pseudo password" and a full blown CHAP exchange. Again, it is possible to avoid extending PPP or anything. Simply do what the PPP standards currently allow and require, the following: client A server B CReq(MRU,Call-Back) --> <-- CReq(MRU,CHAP) CAck(MRU,CHAP) --> <-- CAck(MRU,Call-Back) <-- CHAP-Challenge(B,value) CHAP-Resp(A,resp) --> [oops, while the peer knows the secret and so is the real A, A is not allowed to use call-back] <-- CReq(MRU,CHAP) CAck(MRU,CHAP) --> CReq(MRU,Call-Back) --> <-- CReject(Call-Back) [what?! no callback?] CReq(MRU) --> <-- CAck(MRU) <-- CHAP-Challenge(B,value) CHAP-Resp(A,resp) --> <-- CHAP-ok IPCP-CReq(IPaddr,...)--> <-- IPCP-CReq(IPaddr,...) etc. Again, the only trouble with that is that it requires the client to deal gracefully with repeating the Establish phase. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Oct 7 04:39:54 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id EAA05351; Mon, 7 Oct 1996 04:39:54 -0400 (EDT) Resent-Date: Mon, 7 Oct 1996 04:39:54 -0400 (EDT) Date: Mon, 7 Oct 96 09:37:29 BST From: georgew@europe.shiva.com (George Wilkie) Message-Id: <9610070837.AA18916@queenbee.europe.shiva.com> To: kory@avatar.com Subject: Re: Multiple BACP Call Requests Newsgroups: from.ietf-ppp In-Reply-To: <04Oct9622071721879@crab.spider.co.uk> Organization: Shiva Europe Limited Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"vgEFk.0.BJ1.97CMo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2111 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In article <04Oct9622071721879@crab.spider.co.uk> you write: > >When using BACP, if I need to bring up, say, 6 additional links, do I need >to wait for each Call Response before I send the next Call Request? Or, can >I just fire off the 6 Call Requests? > My code only handles one at a time, so I'd reject your last 5 requests. I don't think there is anything in the spec to prevent what you suggest though. -- George Wilkie georgew@europe.shiva.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Oct 7 12:14:32 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id MAA12741; Mon, 7 Oct 1996 12:14:32 -0400 (EDT) Resent-Date: Mon, 7 Oct 1996 12:14:32 -0400 (EDT) Date: Mon, 7 Oct 1996 12:14:19 -0400 (EDT) Message-Id: <199610071614.MAA27720@carp.morningstar.com> From: Karl Fox To: ietf-ppp@MERIT.EDU Subject: CallBack LCP Extension In-Reply-To: <199610050604.AAA17236@mica.denver.sgi.com> References: <199610050604.AAA17236@mica.denver.sgi.com> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"mbS5j.0.Z63.5nIMo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2112 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver writes: > Again, the only trouble with that is that it requires the client to deal > gracefully with repeating the Establish phase. I know Vernon's main intent was not to deal with this issue, but let me assert again for those who may have forgotten that we do not design protocols to work around bugs in implementations. If the protocols themselves work as is, then there is no need for updates or enhancements. If somebody has a broken implementation, then they are welcome to fix it. In case the preceding paragraph wasn't clear enough: Renegotiation LCP at any time is and has always been a part of the PPP protocol. Designing features or capabilities that require that LCP be renegotiated are perfectly acceptable. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Oct 7 13:22:44 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id NAA14456; Mon, 7 Oct 1996 13:22:44 -0400 (EDT) Resent-Date: Mon, 7 Oct 1996 13:22:44 -0400 (EDT) Date: Mon, 7 Oct 1996 13:20:50 -0400 (EDT) From: John Shriver Message-Id: <199610071720.NAA17121@shiva-dev.shiva.com> To: iana@isi.edu CC: ietf-ppp@MERIT.EDU Subject: SNMP ifType value for PPP Multilink Resent-Message-ID: <"CUgFd1.0.cX3.VnJMo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2113 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The PPP extensions working group could use a new ifType assignment for PPP Multilink per RFC 1990. The PPP multilink bundle is an obvious candidate for a distinct ifType value. The operational model that appears to be obvious is that the bundle is ifStack'd on top of entries of ifType "ppp" for each individual link. I'd suggest "pppMultilinkBundle" for the name of the new ifType value. I'm presently using ifTYpe "ppp" for both the bundle and the individual links, but users find it very difficult navigating the ifTable and ifStackTable to figure out what's going on. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Oct 7 13:26:51 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id NAA14547; Mon, 7 Oct 1996 13:26:51 -0400 (EDT) Resent-Date: Mon, 7 Oct 1996 13:26:51 -0400 (EDT) Mime-Version: 1.0 Date: Mon, 7 Oct 1996 13:04:16 -0700 Message-ID: <2593e1b0@xircom.com> From: bryon_daly@xircom.com (Bryon Daly) Subject: PSCP status? To: ietf-ppp@MERIT.EDU Cc: bryon_daly@xircom.com (Bryon Daly) Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"NEHAs.0.zY3.NrJMo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2114 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hello, I'm trying to find out what the status of the PPP Protocol Spoofing Control Protocol (PSCP) is. The draft expired in August, apparently wasn't updated, and has been deleted from the IETF servers. I have sent email queries to both Ian Puleston (the author), and Fred Baker (listed in the draft as chair of the working group), and have not received a response from either person. I also checked the "1id-abstracts.txt" listing mentioned in the draft as containing the current status "of any Internet Draft", but there was no reference I could find in it to PSCP. Can someone here let me know what the situation is, or at least point me to where I can get this information? Thanks for your help, - Bryon Daly - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Oct 7 13:40:11 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id NAA14857; Mon, 7 Oct 1996 13:40:11 -0400 (EDT) Resent-Date: Mon, 7 Oct 1996 13:40:11 -0400 (EDT) Date: Mon, 7 Oct 1996 10:39:27 -0700 (PDT) From: Kory Hamzeh To: ietf-ppp@MERIT.EDU Subject: BACP Phone Delta Subcriber Number Opt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"IRX5W2.0.td3.t1KMo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2115 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Does the BACP Phone Delta Subscriber Number suboption need to be zero terminated? I don't think so since the length is included, but just checking. Thanks, Kory - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Oct 7 13:52:50 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id NAA15376; Mon, 7 Oct 1996 13:52:50 -0400 (EDT) Resent-Date: Mon, 7 Oct 1996 13:52:50 -0400 (EDT) From: Craig Fox Message-Id: <199610071746.KAA00804@greatdane.cisco.com> Subject: Re: PSCP status? To: bryon_daly@xircom.com (Bryon Daly) Date: Mon, 7 Oct 96 10:46:21 PDT Cc: ietf-ppp@MERIT.EDU, bryon_daly@xircom.com In-Reply-To: <2593e1b0@xircom.com>; from "Bryon Daly" at Oct 7, 96 1:04 pm X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"c7SUg3.0.yl3.jDKMo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2116 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > I have sent email queries to both Ian Puleston (the author), and Fred Baker > (listed in the draft as chair of the working group), and have not received a > response from either person. > Karl Fox of Ascend (formerly Morning Star Technologies) is the new PPP WG chair. He can be reached at karl@ascend.com. > I also checked the "1id-abstracts.txt" listing mentioned in the draft as > containing the current status "of any Internet Draft", but there was no > reference I could find in it to PSCP. > It has been discussed on the list within the last month. > Can someone here let me know what the situation is, or at least point me to > where I can get this information? > > Thanks for your help, > - Bryon Daly > > Craig - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Oct 7 18:25:57 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id SAA21709; Mon, 7 Oct 1996 18:25:57 -0400 (EDT) Resent-Date: Mon, 7 Oct 1996 18:25:57 -0400 (EDT) From: Guy Cote To: ietf-ppp Cc: Pierre-Luc Provencal Subject: FW: BACP testing (CIUG Workshop). Date: Mon, 07 Oct 96 18:22:00 PDT Message-Id: <3259ACDC@admin.eicon.com> Encoding: 17 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"RTBGF.0.rI5.cDOMo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2117 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Sorry for the broadcast. Eicon Technology is going to the next CIUG workshop in San Ramon and we are currently testing our implementation of BACP. We would like to test remotely with other participants prior to the CIUG workshop. if you are interested please send an email to : pierrelp@eicon.com. and send us your telephone number. P.S. It would be nice to have this type of information in the registration form. Thank you, Guy Cote gcote@eicon.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sun Oct 13 21:10:37 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id VAA16226; Sun, 13 Oct 1996 21:10:37 -0400 (EDT) Resent-Date: Sun, 13 Oct 1996 21:10:37 -0400 (EDT) From: DaphneKuo@acer.com.tw Date: Sun, 13 Oct 96 22:21:17 PST Message-Id: <9609138452.AA845270791@acer.com.tw> To: ietf-ppp@MERIT.EDU Subject: CHAP MD5 of Win95 Resent-Message-ID: <"bjt251.0.uy3.oBPOo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2118 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Dear All, I have a question in trying to communicate w/ CHAP of Windows 95. It will be highly appreciated if you could do me a favor to help make clear the situation. When our ISDN TA connected via RS232 to host PC running Dial Up Networking, I made a call to remote Router w/ CHAP capability and found the host will NOT respond to 2nd, 3rd, 4th.. CHAP CHALLENGE frame from peer side. Only reply the first one. - Do I have to set some parameters of Dial Up Networking to change the situation? - Should I install a more updated version of Windows 95? - Could you give me some advice on this puzzle? If this question has been discussed, please let me know how to find the answer. Thanks, Daphne Kuo -------------------------------------------------------------------- Daphne Kuo, Acer Netxus Inc, Project Researcher 5F-3, 5 Hsin Ann Road, Science-Based Industrial Park, Hsinchu 300, Taiwan, R.O.C. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Oct 14 10:53:39 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id KAA26617; Mon, 14 Oct 1996 10:53:39 -0400 (EDT) Resent-Date: Mon, 14 Oct 1996 10:53:39 -0400 (EDT) Date: Mon, 14 Oct 96 09:51:07 CDT Message-Id: <9610141451.AA15649@adtrn-ws01.adtran.com> X-Sender: kfrnswrt@mail Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: DaphneKuo@acer.com.tw, ietf-ppp@MERIT.EDU From: kfarnsworth@adtran.com (Kyle Farnsworth) Subject: Re: CHAP MD5 of Win95 X-Mailer: Resent-Message-ID: <"AxL911.0.bV6.QFbOo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2119 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 10:21 PM 10/13/96 PST, DaphneKuo@acer.com.tw wrote: > > Dear All, > > I have a question in trying to communicate w/ CHAP of Windows 95. It > will be highly appreciated if you could do me a favor to help make > clear the situation. > > When our ISDN TA connected via RS232 to host PC running Dial Up > Networking, I made a call to remote Router w/ CHAP capability and > found the host will NOT respond to 2nd, 3rd, 4th.. CHAP CHALLENGE > frame from peer side. Only reply the first one. > > - Do I have to set some parameters of Dial Up Networking to change the > situation? > > - Should I install a more updated version of Windows 95? > > - Could you give me some advice on this puzzle? > > If this question has been discussed, please let me know how to find > the answer. Thanks, > > Daphne Kuo > This is a known problem with Win95. We have run across this ourselfs with our TA's. Microsoft has said they will fix it in the next release of Win95. I do not know if they have released it yet or when it will be released. However, millions of copies our out there so it's going to be cropping up for years to come. -------------------------------------------------------- Kyle Farnsworth ADTRAN Inc. (205)971-8583 kfarnsworth@adtran.com -------------------------------------------------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Oct 14 11:21:57 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id LAA27543; Mon, 14 Oct 1996 11:21:57 -0400 (EDT) Resent-Date: Mon, 14 Oct 1996 11:21:57 -0400 (EDT) Mime-Version: 1.0 Date: Mon, 14 Oct 1996 16:16:24 +0100 Message-ID: <2625a7a0@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: CHAP MD5 of Win95 Cc: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"i_c0n.0.5k6.HgbOo"@merit.edu> To: ietf-ppp@MERIT.EDU Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2120 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Daphne Kuo writes: > I have a question in trying to communicate w/ CHAP of Windows 95. It > will be highly appreciated if you could do me a favor to help make clear > the situation. > When our ISDN TA connected via RS232 to host PC running Dial Up > Networking, I made a call to remote Router w/ CHAP capability and > found the host will NOT respond to 2nd, 3rd, 4th.. CHAP CHALLENGE > frame from peer side. Only reply the first one. Unfortunately this is a feature of Windows95 PPP. The Windows 95 Resource Kit Chapter 22: Remote Access states that: "Windows95 doesn't support ongoing challenges with Chap". > - Do I have to set some parameters of Dial Up Networking to change the > situation? If there is, we've not found it. > - Should I install a more updated version of Windows 95? You may interested to know that WindowsNT doesn't have this limitation, so you could try NT Workstation instead. > - Could you give me some advice on this puzzle? I suggest you contact Microsoft. --- Jonathan.Goodchild@rdl.co.uk - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Oct 14 18:28:44 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id SAA07158; Mon, 14 Oct 1996 18:28:44 -0400 (EDT) Resent-Date: Mon, 14 Oct 1996 18:28:44 -0400 (EDT) Message-ID: From: Gurdeep Singh Pall To: "'ietf-ppp@MERIT.EDU'" , "'Jonathan.Goodchild@rdl.co.uk'" Cc: Ken Crocker Subject: RE: CHAP MD5 of Win95 Date: Mon, 14 Oct 1996 15:06:49 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Encoding: 51 TEXT Resent-Message-ID: <"vkYyz2.0.al1.AwhOo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2121 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU i'll followup with the right guys on this. please feel free to contact kcrocker@microsoft.com directly for any issues you have with win95/winnt ppp implementations. gurdeep >---------- >From: Jonathan.Goodchild@rdl.co.uk[SMTP:Jonathan.Goodchild@rdl.co.uk] >Sent: Monday, October 14, 1996 8:16 AM >To: ietf-ppp@MERIT.EDU >Cc: ietf-ppp@MERIT.EDU >Subject: Re: CHAP MD5 of Win95 > > >Daphne Kuo writes: > >> I have a question in trying to communicate w/ CHAP of Windows 95. It >> will be highly appreciated if you could do me a favor to help make clear >> the situation. > >> When our ISDN TA connected via RS232 to host PC running Dial Up >> Networking, I made a call to remote Router w/ CHAP capability and >> found the host will NOT respond to 2nd, 3rd, 4th.. CHAP CHALLENGE >> frame from peer side. Only reply the first one. > >Unfortunately this is a feature of Windows95 PPP. The Windows 95 >Resource Kit Chapter 22: Remote Access states that: "Windows95 doesn't >support ongoing challenges with Chap". > >> - Do I have to set some parameters of Dial Up Networking to change the >> situation? > >If there is, we've not found it. > >> - Should I install a more updated version of Windows 95? > >You may interested to know that WindowsNT doesn't have this limitation, so >you >could try NT Workstation instead. > >> - Could you give me some advice on this puzzle? > >I suggest you contact Microsoft. > >--- >Jonathan.Goodchild@rdl.co.uk > > > > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 23 12:44:38 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id MAA13638; Wed, 23 Oct 1996 12:44:38 -0400 (EDT) Resent-Date: Wed, 23 Oct 1996 12:44:38 -0400 (EDT) From: "Brad Wilson" To: Subject: Re: 40-bit DES Date: Wed, 23 Oct 1996 11:59:45 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <19961023160256079.AAA223@ragnar> Resent-Message-ID: <"PRc0Y3.0.BK3.YiaRo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2122 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > As to exporting development, the NSA told us that not only couldn't we > export source with any kind of hook for encryption, we couldn't even > hire someone outside of the country to add encryption to an existing > product without running afoul of the U.S. laws. Of course, I'm not a > lawyer, and am not suggesting that their claims were necessarily valid. Of course not. You would have to move your development staff out of the country, make them citizens of the country in question, and do clean-room development for a new company, which could then sell the product to US citizens (as well as Europeans, et al). What a wonderful thing regulations are! -- Brad Wilson | crucial@pobox.com http://www.thebrads.com Objectivist Philosopher | "Take the time, reevaluate, Software Engineer | It's time to pick up the pieces Web Page Designer | Go back to square one System Administrator | I think it's time for a change" - Dream Theater - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Oct 28 10:24:28 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id KAA20078; Mon, 28 Oct 1996 10:24:28 -0500 (EST) Resent-Date: Mon, 28 Oct 1996 10:24:28 -0500 (EST) Message-ID: <01BBC4B9.5308CC60@tang.trisignal.com> From: tang@trisignal.com (tang) To: "'ietf-ppp@merit.edu'" Subject: PPP mailing list Date: Mon, 28 Oct 1996 09:47:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"nAAr3.0.xu4.y_CTo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2123 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi, I would like to have the info about the PPP mailing list. Thanks. Tang Trisignal Communications Inc. Tel: (514) 340-1334 Ex. 224 Email: tang@trisignal.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Oct 28 10:27:22 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id KAA20178; Mon, 28 Oct 1996 10:27:22 -0500 (EST) Resent-Date: Mon, 28 Oct 1996 10:27:22 -0500 (EST) Message-ID: <01BBC4B9.D5E3F1A0@tang.trisignal.com> From: tang@trisignal.com (tang) To: "'ietf-ppp@merit.edu'" Subject: PPP mailing list Date: Mon, 28 Oct 1996 10:21:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"24XyI3.0.xw4.M3DTo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2124 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi, I would like to have the info about PPP mailing list. Could you please send it to me? Thanks, Tang Nguyen Trisignal Communications Inc. Tel: (514)340 1334 email: tang@trisignal.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Oct 28 12:21:27 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id MAA22824; Mon, 28 Oct 1996 12:21:27 -0500 (EST) Resent-Date: Mon, 28 Oct 1996 12:21:27 -0500 (EST) Message-Id: <9610282020.AA4337@SMTP.shiva.com> To: Bryon Daly Cc: ietf-ppp From: Robert Webster/Shiva Corporation Date: 28 Oct 96 12:20:01 EDT Subject: Re: PSCP status? Mime-Version: 1.0 Content-Type: Text/Plain Resent-Message-ID: <"6vawk3.0.La5.JkETo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2125 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I believe Ian Puleston is no longer working on PPP (or at the very least not on PSCP). Unfortunately, PSCP now seems sort of orphaned. -Rob Webster To: ietf-ppp @ MERIT.EDU @ SMTPMAIL cc: bryon_daly @ xircom.com (Bryon Daly) @ SMTPMAIL From: bryon_daly @ xircom.com (Bryon Daly) @ SMTPMAIL Date: 10/07/96 01:04:16 PM Subject: PSCP status? Hello, I'm trying to find out what the status of the PPP Protocol Spoofing Control Protocol (PSCP) is. The draft expired in August, apparently wasn't updated, and has been deleted from the IETF servers. I have sent email queries to both Ian Puleston (the author), and Fred Baker (listed in the draft as chair of the working group), and have not received a response from either person. I also checked the "1id-abstracts.txt" listing mentioned in the draft as containing the current status "of any Internet Draft", but there was no reference I could find in it to PSCP. Can someone here let me know what the situation is, or at least point me to where I can get this information? Thanks for your help, - Bryon Daly - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Oct 29 19:29:39 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id TAA25278; Tue, 29 Oct 1996 19:29:39 -0500 (EST) Resent-Date: Tue, 29 Oct 1996 19:29:39 -0500 (EST) From: Archie Cobbs Message-Id: <199610300028.QAA01604@bubba.whistle.com> Subject: infinite loop To: ietf-ppp@MERIT.EDU Date: Tue, 29 Oct 1996 16:28:05 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"arbwH.0.ZA6.J5gTo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2126 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Has anyone ever seen this behavior? Two PPP automatons in an infinite loop, where each one is sending the other config-request, config-ack and bouncing between the opened and ack-sent states? As far as I can tell, this behavior is according to the spec (rfc 1661); I'm curious if this is actually possible or must there have been incorrect state transistion previously. Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 30 11:09:59 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id LAA08228; Wed, 30 Oct 1996 11:09:59 -0500 (EST) Resent-Date: Wed, 30 Oct 1996 11:09:59 -0500 (EST) From: Craig Fox Message-Id: <199610301608.IAA20765@greatdane.cisco.com> Subject: Re: infinite loop To: archie@whistle.com (Archie Cobbs) Date: Wed, 30 Oct 96 8:08:42 PST Cc: ietf-ppp@MERIT.EDU In-Reply-To: <199610300028.QAA01604@bubba.whistle.com>; from "Archie Cobbs" at Oct 29, 96 4:28 pm X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"mC_lP3.0.A02.tstTo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2127 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Has anyone ever seen this behavior? Two PPP automatons in an infinite > loop, where each one is sending the other config-request, config-ack > and bouncing between the opened and ack-sent states? I have only seen this when one or the other end is broken. Do you have a trace of this sequence of events? > As far as I can tell, this behavior is according to the spec (rfc > 1661); I'm curious if this is actually possible or must there have > been incorrect state transistion previously. I don't think so. I dug up my trusty 'PPP Quick Reference Guide' from Oct '92 (and verified that it matched the FSM table in 1661). We can assume that one side is Open and the other in Ack-Sent from your message. We can also assume that all config-requests are ack'd, since you did not mention any config-naks or config-rejects. So we have the following sequence of events. Side A Side B State Event Action State Event Action 1 AckSent TO+ scr Open 2 AckSent Open RCR+ tld scr sca AckSent 3 AckSent RCR+ sca AckSent 4 AckSent RCA irc tlu Open AckSent RCA irc tlu Open 5 Open Open Perhaps I assumed too much. How does your sequence of events differ from those above. Note that at step 5, both machines are Open and fsm timers have been disabled. Craig > Thanks, > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 30 17:37:01 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id RAA19018; Wed, 30 Oct 1996 17:37:01 -0500 (EST) Resent-Date: Wed, 30 Oct 1996 17:37:01 -0500 (EST) Message-ID: <32780F6B.5A6F@klos.com> Date: Wed, 30 Oct 1996 18:31:07 -0800 From: Michael Klos Organization: Klos, Inc. X-Mailer: Mozilla 2.0 (Win16; U) MIME-Version: 1.0 To: Craig Fox CC: Archie Cobbs , ietf-ppp@MERIT.EDU Subject: Re: infinite loop References: <199610301608.IAA20765@greatdane.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"lPFLK1.0.ue4.8YzTo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2129 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Craig Fox wrote: > > > Has anyone ever seen this behavior? Two PPP automatons in an infinite > > loop, where each one is sending the other config-request, config-ack > > and bouncing between the opened and ack-sent states? > > I have only seen this when one or the other end is broken. Do you have > a trace of this sequence of events? > > > As far as I can tell, this behavior is according to the spec (rfc > > 1661); I'm curious if this is actually possible or must there have > > been incorrect state transistion previously. > > I don't think so. I dug up my trusty 'PPP Quick Reference Guide' from > Oct '92 (and verified that it matched the FSM table in 1661). We can > assume that one side is Open and the other in Ack-Sent from your message. > We can also assume that all config-requests are ack'd, since you did not > mention any config-naks or config-rejects. So we have the following > sequence of events. > > Side A Side B > State Event Action State Event Action > 1 AckSent TO+ scr Open > 2 AckSent Open RCR+ tld scr sca AckSent > 3 AckSent RCR+ sca AckSent > 4 AckSent RCA irc tlu Open AckSent RCA irc tlu Open > 5 Open Open > > Perhaps I assumed too much. How does your sequence of events differ from > those above. Note that at step 5, both machines are Open and fsm timers > have been disabled. > > Craig > > > Thanks, > > -Archie > > > > ___________________________________________________________________________ > > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com Check the Magic Number. It appears both sides have the same number. Michael Klos Klos Technologies, Inc. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 30 17:36:20 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id RAA18957; Wed, 30 Oct 1996 17:36:20 -0500 (EST) Resent-Date: Wed, 30 Oct 1996 17:36:20 -0500 (EST) From: Archie Cobbs Message-Id: <199610302235.OAA04535@bubba.whistle.com> Subject: Re: infinite loop In-Reply-To: <199610301608.IAA20765@greatdane.cisco.com> from Craig Fox at "Oct 30, 96 08:08:42 am" To: fox@cisco.com (Craig Fox) Date: Wed, 30 Oct 1996 14:35:02 -0800 (PST) Cc: archie@whistle.com, ietf-ppp@MERIT.EDU X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"giD8P1.0.rd4.MXzTo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2128 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > Has anyone ever seen this behavior? Two PPP automatons in an infinite > > loop, where each one is sending the other config-request, config-ack > > and bouncing between the opened and ack-sent states? > > I have only seen this when one or the other end is broken. Do you have > a trace of this sequence of events? Included below are the two logs... I think the problem is that the retry timeout, which is set to 1 second, is too fast. Normally, over 28.8 modems this shouldn't be the case, but this line is particularly noisy... and with modem error correction enabled the retries, etc. may sometimes put the latency on the order of a second. I'd be very interested to hear your analysis... Below the relative time offsets are shown at the left... unfortunately, the precision is only one second... I've put line breaks after each transition to the opened state, and marked with a (*) config requests that were sent as a result of a retry timeout: LOG FOR PPP A +0 Up event +0 state change Starting --> Req-Sent +0 SendConfigReq #1 +0 rec'd Configure Request #1 (Req-Sent) +0 SendConfigAck #1 +0 state change Req-Sent --> Ack-Sent (*) +1 SendConfigReq #2 +1 rec'd Configure Ack #1 (Ack-Sent) +1 state change Ack-Sent --> Opened +1 LayerUp +2 rec'd Configure Request #2 (Opened) +2 LayerDown +2 SendConfigReq #3 +2 SendConfigAck #2 +2 state change Opened --> Ack-Sent +2 rec'd Configure Ack #2 (Ack-Sent) +2 state change Ack-Sent --> Opened +2 LayerUp +3 rec'd Configure Request #3 (Opened) +3 LayerDown +3 SendConfigReq #4 +3 SendConfigAck #3 +3 state change Opened --> Ack-Sent +4 rec'd Configure Ack #3 (Ack-Sent) +4 state change Ack-Sent --> Opened +4 LayerUp +4 rec'd Configure Request #4 (Opened) +4 LayerDown +4 SendConfigReq #5 +4 SendConfigAck #4 +4 state change Opened --> Ack-Sent +4 rec'd Configure Ack #4 (Ack-Sent) +4 state change Ack-Sent --> Opened +4 LayerUp +4 rec'd Configure Request #5 (Opened) +4 LayerDown +4 SendConfigReq #6 ... repeat ... LOG FOR PPP B +0 Up event +0 state change Starting --> Req-Sent +0 SendConfigReq #1 +0 rec'd Configure Request #1 (Req-Sent) +0 SendConfigAck #1 +0 state change Req-Sent --> Ack-Sent +0 rec'd Configure Ack #1 (Ack-Sent) +0 state change Ack-Sent --> Opened +0 LayerUp +1 rec'd Configure Request #2 (Opened) +1 LayerDown +1 SendConfigReq #2 +1 SendConfigAck #2 +1 state change Opened --> Ack-Sent (*) +2 SendConfigReq #3 +3 rec'd Configure Request #3 (Ack-Sent) +3 SendConfigAck #3 +3 rec'd Configure Ack #2 (Ack-Sent) +3 state change Ack-Sent --> Opened +3 LayerUp +3 rec'd Configure Request #4 (Opened) +3 LayerDown +3 SendConfigReq #4 +3 SendConfigAck #4 +3 state change Opened --> Ack-Sent +3 rec'd Configure Ack #3 (Ack-Sent) +3 state change Ack-Sent --> Opened +3 LayerUp +4 rec'd Configure Request #5 (Opened) +4 LayerDown +4 SendConfigReq #5 +4 SendConfigAck #5 +4 state change Opened --> Ack-Sent +4 rec'd Configure Ack #4 (Ack-Sent) +4 state change Ack-Sent --> Opened +4 LayerUp +5 rec'd Configure Request #6 (Opened) +5 LayerDown +5 SendConfigReq #6 ... repeat ... Very interesting... :-) -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Oct 30 17:42:06 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id RAA19129; Wed, 30 Oct 1996 17:42:06 -0500 (EST) Resent-Date: Wed, 30 Oct 1996 17:42:06 -0500 (EST) From: Archie Cobbs Message-Id: <199610302241.OAA04584@bubba.whistle.com> Subject: Re: infinite loop In-Reply-To: <32780F6B.5A6F@klos.com> from Michael Klos at "Oct 30, 96 06:31:07 pm" To: mike@klos.com (Michael Klos) Date: Wed, 30 Oct 1996 14:41:23 -0800 (PST) Cc: ietf-ppp@MERIT.EDU X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"FexW41.0.dg4.vczTo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2130 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > > Has anyone ever seen this behavior? Two PPP automatons in an infinite > > > loop, where each one is sending the other config-request, config-ack > > > and bouncing between the opened and ack-sent states? > > Check the Magic Number. It appears both sides have the same number. Unfortunately that's not the case... -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 31 04:02:08 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id EAA26101; Thu, 31 Oct 1996 04:02:08 -0500 (EST) Resent-Date: Thu, 31 Oct 1996 04:02:08 -0500 (EST) Mime-Version: 1.0 Date: Thu, 31 Oct 1996 08:59:21 +0000 Message-ID: <2786af10@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: infinite loop To: ietf-ppp@MERIT.EDU Cc: archie@whistle.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"qmae02.0.WN6.0i6Uo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2131 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From Archie Cobbs: .. > LOG FOR PPP A > > +0 Up event > +0 state change Starting --> Req-Sent > +0 SendConfigReq #1 > +0 rec'd Configure Request #1 (Req-Sent) > +0 SendConfigAck #1 > +0 state change Req-Sent --> Ack-Sent >(*) +1 SendConfigReq #2 > +1 rec'd Configure Ack #1 (Ack-Sent) This is wrong - Configure-Ack #1 must be ignored, as Configure-Request #2 has been sent (RFC 1661 section 5.2 [page 29]: ..the Identifier field MUST match that of the last transmitted Configure-Request). Alternatively, the error could be that the Identifier field in the Configure Request is not being incremented each time (i.e. the Identifier for Configure-Request #2 is the same as for #1). > +1 state change Ack-Sent --> Opened > +1 LayerUp Both Peer A and B seem to have the same problem. --- Jonathan.Goodchild@rdl.co.uk - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 31 04:42:58 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id EAA26438; Thu, 31 Oct 1996 04:42:58 -0500 (EST) Resent-Date: Thu, 31 Oct 1996 04:42:58 -0500 (EST) Message-Id: <9610310942.AA29363@blackse2.lmf.ericsson.se> Comments: Authenticated sender is From: "Mikael Latvala" Organization: Oy L M Ericsson Ab To: ietf-ppp@MERIT.EDU Date: Thu, 31 Oct 1996 11:39:13 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Error detection and retransmission Reply-To: Mikael.Latvala@lmf.ericsson.se Priority: normal X-Mailer: Pegasus Mail for Windows (v2.23) Resent-Message-ID: <"p4v641.0.nS6.UI7Uo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2132 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Does anybody know if someone has proposed a protocol enhancement to RFC1661 which specifies a mechanism which would allow a receiver to request a retransmission of a corrupted data packet? That is, ARQ with or without sliding window would be done only to valid data packets (i.e. IP datagrams). Error correction algorithm could be used instead of error detection + retransmission. However, some (if not all?) error correction algorithms can tell that a frame is corrupted but cannot not fix it. In this case it would make sense to ask a retransmission of the frame especially on slow links with high error rates. Thank you, Mikael ====================================================================== | Mikael Latvala | Mikael.Latvala@lmf.ericsson.se | | Oy L M Ericsson Ab | Research Department | | 02420 Jorvas, Finland | Tel: +358 0 299 2850 Fax: +358 0 299 7234 | ====================================================================== - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 31 05:03:53 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id FAA26634; Thu, 31 Oct 1996 05:03:53 -0500 (EST) Resent-Date: Thu, 31 Oct 1996 05:03:53 -0500 (EST) Message-Id: <9610311003.AB00719@blackse2.lmf.ericsson.se> Comments: Authenticated sender is From: "Mikael Latvala" Organization: Oy L M Ericsson Ab To: ietf-ppp@MERIT.EDU Date: Thu, 31 Oct 1996 11:48:04 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Error detection and retransmission Reply-To: Mikael.Latvala@lmf.ericsson.se Priority: normal X-Mailer: Pegasus Mail for Windows (v2.23) Resent-Message-ID: <"rJn2D3.0.rV6.4c7Uo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2133 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Does anybody know if someone has proposed a protocol enhancement to RFC1661 which specifies a mechanism which would allow a receiver to request a retransmission of a corrupted data packet? That is, ARQ with or without sliding window would be done only to valid data packets (i.e. IP datagrams). Error correction algorithm could be used instead of error detection + retransmission. However, some (if not all?) error correction algorithms can tell that a frame is corrupted but cannot not fix it. In this case it would make sense to ask a retransmission of the frame especially on slow links with high error rates. Thank you, Mikael ====================================================================== | Mikael Latvala | Mikael.Latvala@lmf.ericsson.se | | Oy L M Ericsson Ab | Research Department | | 02420 Jorvas, Finland | Tel: +358 0 299 2850 Fax: +358 0 299 7234 | ====================================================================== - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 31 07:37:41 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id HAA27692; Thu, 31 Oct 1996 07:37:41 -0500 (EST) Resent-Date: Thu, 31 Oct 1996 07:37:41 -0500 (EST) Date: Thu, 31 Oct 1996 07:37:45 -0500 (EST) Message-Id: <199610311237.HAA09973@carp.morningstar.com> From: Karl Fox To: Mikael.Latvala@lmf.ericsson.se Cc: ietf-ppp@MERIT.EDU Subject: Error detection and retransmission In-Reply-To: <9610311003.AB00719@blackse2.lmf.ericsson.se> References: <9610311003.AB00719@blackse2.lmf.ericsson.se> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"x5hKY2.0.Nm6.or9Uo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2134 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Mikael Latvala writes: > Does anybody know if someone has proposed a protocol > enhancement to RFC1661 which specifies a mechanism which would allow a > receiver to request a retransmission of a corrupted data packet? See RFC 1663, ``PPP Reliable Transmission'', which describes how to use ISO 7776 LAP-B under PPP. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 31 08:14:53 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id IAA28169; Thu, 31 Oct 1996 08:14:53 -0500 (EST) Resent-Date: Thu, 31 Oct 1996 08:14:53 -0500 (EST) Message-Id: <199610311314.IAA28138@merit.edu> Date: Thu, 31 Oct 96 14:13:36 +0100 X-Sender: cerveron@post.uv.es Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Mikael.Latvala@lmf.ericsson.se, ietf-ppp@MERIT.EDU From: Vicente.Cerveron@uv.es (Vicente.Cerveron) Subject: Re: Error detection and retransmission X-Mailer: Resent-Message-ID: <"4r31X2.0.qt6.9PAUo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2135 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 11:48 AM 31/10/96 +0200, Mikael.Latvala@lmf.ericsson.se wrote: >Does anybody know if someone has proposed a protocol >enhancement to RFC1661 which specifies a mechanism which would allow a >receiver to request a retransmission of a corrupted data packet? That >is, ARQ with or without sliding window would be done only to valid >data packets (i.e. IP datagrams). > >Error correction algorithm could be used instead of error detection + >retransmission. However, some (if not all?) error correction >algorithms can tell that a frame is corrupted but cannot not fix it. >In this case it would make sense to ask a retransmission of the frame >especially on slow links with high error rates. Dear all, I've read Karl Fox about Reliable PPP (I'm aware of that RFC). However, I've heard from some people that, since TCP asks for retransmission when needed, it's no sense to implement ARQ in the data link layer. I disagree. What do you think on that subject? Are there real PPP implementation supporting RFC 1663? Moreover, Mikael Latvala wrote about error correction algorithms. I've some thoughts about that but wanna read more opinions: Why PPP doesn't have a single word on error correction algorithms? Thanks for you (expected) answers Vicente Cerveron University of Valencia (SPAIN) - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 31 08:34:04 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id IAA28433; Thu, 31 Oct 1996 08:34:04 -0500 (EST) Resent-Date: Thu, 31 Oct 1996 08:34:04 -0500 (EST) Message-Id: <25489.9610311332@vulcan.xylogics.com> To: Vicente.Cerveron@uv.es (Vicente.Cerveron) Cc: ietf-ppp@MERIT.EDU Subject: Re: Error detection and retransmission In-Reply-To: Your message of "Thu, 31 Oct 1996 14:13:36 +0100." <199610311314.IAA28138@merit.edu> Date: Thu, 31 Oct 1996 08:32:41 -0500 From: James Carlson Resent-Message-ID: <"MMiSN1.0._x6.8hAUo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2136 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vicente Cerveron writes: > I've read Karl Fox about Reliable PPP (I'm aware of that RFC). > However, I've heard from some people that, since TCP asks > for retransmission when needed, it's no sense to implement > ARQ in the data link layer. I disagree. > > What do you think on that subject? I think they're right on the money. > Are there real PPP implementation supporting RFC 1663? I've not seen one. I'd certainly like to, though. It would be interesting to test against. > Moreover, Mikael Latvala wrote about error correction algorithms. > I've some thoughts about that but wanna read more opinions: > > Why PPP doesn't have a single word on error correction algorithms? Because TCP's error-recovery algorithm isn't just for correcting transmission errors. It's also the means by which TCP avoids congestion in intermediate links. In order to do this, TCP assumes that the underlying network and data-link layers have only delays related to congestion, and not related to any complex underlying protocol. The delays should therefore not be varying rapidly with time nor should they be varying by large amounts. In other words, if you run TCP over an error-correcting protocol which introduces wide variances in the packet-forwarding latency, TCP will "misread" those variances as packet loss and will attempt to recover anyway. This results in redundant data being sent, oscillatory behavior, and a net loss in performance. In general, running one retransmission-based error-correcting protocol atop another is a Bad Idea. As has been reported in IETF meetings in the past, experience with PPP over TELNET has shown that reliability is a much overrated property. --- James Carlson Tel: +1 617 272 8140 Annex Interface Development / Xylogics, Inc. +1 800 225 3317 53 Third Avenue / Burlington MA 01803-4491 Fax: +1 617 272 2618 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 31 09:46:42 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id JAA29689; Thu, 31 Oct 1996 09:46:42 -0500 (EST) Resent-Date: Thu, 31 Oct 1996 09:46:42 -0500 (EST) Mime-Version: 1.0 Date: Thu, 31 Oct 1996 14:35:42 +0000 Message-ID: <278bb600@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Error detection and retransmission To: Vicente.Cerveron@uv.es Cc: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"BwF6z3.0.dF7.DlBUo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2137 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU James Carlson writes: >Vicente Cerveron writes: > > I've read Karl Fox about Reliable PPP (I'm aware of that RFC). > > However, I've heard from some people that, since TCP asks > > for retransmission when needed, it's no sense to implement > > ARQ in the data link layer. I disagree. > > > What do you think on that subject? > >I think they're right on the money. > > > Are there real PPP implementation supporting RFC 1663? >I've not seen one. I'd certainly like to, though. It would be >interesting to test against. I've got an implementation of RFC 1663, and I'd be willing to do some interoperability testing if anyone is interested (but it's probably not worth an international phone call !). > > Moreover, Mikael Latvala wrote about error correction algorithms. > > I've some thoughts about that but wanna read more opinions: > > > > Why PPP doesn't have a single word on error correction algorithms? >Because TCP's error-recovery algorithm isn't just for correcting transmission >errors. It's also the means by which TCP avoids congestion in intermediate >links. In order to do this, TCP assumes that the underlying network and >data-link layers have only delays related to congestion, and not related >to any complex underlying protocol. The delays should therefore not be >varying rapidly with time nor should they be varying by large amounts. >In other words, if you run TCP over an error-correcting protocol which >introduces wide variances in the packet-forwarding latency, TCP will "misread" >those variances as packet loss and will attempt to recover anyway. This >results in redundant data being sent, oscillatory behavior, and a net loss >in performance. >In general, running one retransmission-based error-correcting protocol >atop another is a Bad Idea. As has been reported in IETF meetings in >the past, experience with PPP over TELNET has shown that reliability is >a much overrated property. I agree - we've not encountered any serious problems with running TCP over RFC 1663, but then I don't think we've ever done so on lines with sufficiently high error rates to cause more than occasional LAPB retransmissions. We've certainly had some problems in the past with TCP over X.25 networks (which amounts to pretty much the same thing as RFC 1663 in terms of performance). On the other hand, if using something other than TCP maybe reliable PPP can be useful. I'd be interested to hear of other people's experiences. --- Jonathan Goodchild Racal-Datacom, Hook, Hampshire, England - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 31 10:54:37 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id KAA01065; Thu, 31 Oct 1996 10:54:37 -0500 (EST) Resent-Date: Thu, 31 Oct 1996 10:54:37 -0500 (EST) Message-Id: <9610311554.AA20143@blackse2.lmf.ericsson.se> Comments: Authenticated sender is From: "Mikael Latvala" Organization: Oy L M Ericsson Ab To: James Carlson Date: Thu, 31 Oct 1996 17:50:49 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: Error detection and retransmission Reply-To: Mikael.Latvala@lmf.ericsson.se Cc: ietf-ppp@MERIT.EDU Priority: normal X-Mailer: Pegasus Mail for Windows (v2.23) Resent-Message-ID: <"UT-f81.0.LG.ukCUo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2138 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU First I'd like to thank you all for your answers. And then to the business ... James Carlson writes: > Vicente Cerveron writes: > > I've read Karl Fox about Reliable PPP (I'm aware of that RFC). > > However, I've heard from some people that, since TCP asks > > for retransmission when needed, it's no sense to implement > > ARQ in the data link layer. I disagree. > > > > What do you think on that subject? > > I think they're right on the money. > It varies by mileage. On very slow and error prone links (like radio links) retransmission is definately worth an investment. Unless I have misunderstood my collegues even GSM links use retransmission. Think about it! Retransmission on delay sensitive links. > > > Moreover, Mikael Latvala wrote about error correction algorithms. > > I've some thoughts about that but wanna read more opinions: > > > > Why PPP doesn't have a single word on error correction algorithms? > > Because TCP's error-recovery algorithm isn't just for correcting transmission > errors. It's also the means by which TCP avoids congestion in intermediate > links. In order to do this, TCP assumes that the underlying network and > data-link layers have only delays related to congestion, and not related > to any complex underlying protocol. The delays should therefore not be > varying rapidly with time nor should they be varying by large amounts. > Hmmm ... I think you misunderstood Vincente and me. When I talked about error correction algorithms I meant error-correcting codes, not general error control/flow control mechanismn implemented in TCP. Actually, I was wondering if someone has proposed an additional LCP Configuration Option which would allow PPP links to use error-correcting codes rather than error-detecting, i.e. Reed-Solomon code. > In other words, if you run TCP over an error-correcting protocol which > introduces wide variances in the packet-forwarding latency, TCP will "misread" > those variances as packet loss and will attempt to recover anyway. This > results in redundant data being sent, oscillatory behavior, and a net loss > in performance. > ??? Don't quite follow you here. Why would an error-correcting protocol introduce wider variances in the packet-forwarding latency than regular send-and-pray protocol? In a traditional scenario receiving PPP discards corrupted packets which means that TCP times out and asks for retransmission. If we use retranmission there might be a chance that the receiving TCP gets the retransmitted packet before it times out. If this happens we will avoid this Slow-Start-syndrome. We would only loose a small fraction of bandwidth to control packets which carry AQKs and NAKs. > In general, running one retransmission-based error-correcting protocol > atop another is a Bad Idea. As has been reported in IETF meetings in the > past, experience with PPP over TELNET has shown that reliability is a > much overrated property. > Perhaps if you have an ATM connection. However, if you surffed on the net through 9600bps GSM data link you'd appriciate every small increment in your throughput. Mikael ====================================================================== | Mikael Latvala | Mikael.Latvala@lmf.ericsson.se | | Oy L M Ericsson Ab | Research Department | | 02420 Jorvas, Finland | Tel: +358 0 299 2850 Fax: +358 0 299 7234 | ====================================================================== - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 31 11:23:34 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id LAA01642; Thu, 31 Oct 1996 11:23:34 -0500 (EST) Resent-Date: Thu, 31 Oct 1996 11:23:34 -0500 (EST) Message-Id: <13370.9610311622@vulcan.xylogics.com> To: Mikael.Latvala@lmf.ericsson.se Cc: ietf-ppp@MERIT.EDU Subject: Re: Error detection and retransmission In-Reply-To: Your message of "Thu, 31 Oct 1996 17:50:49 +0200." <9610311554.AA20143@blackse2.lmf.ericsson.se> Date: Thu, 31 Oct 1996 11:22:10 -0500 From: James Carlson Resent-Message-ID: <"jyyoT2.0.OP.2ADUo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2139 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Mikael Latvala wrote: > James Carlson: > > Because TCP's error-recovery algorithm isn't just for correcting transmission > > errors. It's also the means by which TCP avoids congestion in intermediate > > links. In order to do this, TCP assumes that the underlying network and > > data-link layers have only delays related to congestion, and not related > > to any complex underlying protocol. The delays should therefore not be > > varying rapidly with time nor should they be varying by large amounts. > > > Hmmm ... I think you misunderstood Vincente and me. When I talked > about error correction algorithms I meant error-correcting codes, not > general error control/flow control mechanismn implemented in TCP. I don't *think* I misunderstood him, but I'm willing to be convinced otherwise. He wrote: > > > I've read Karl Fox about Reliable PPP (I'm aware of that RFC). > > > However, I've heard from some people that, since TCP asks > > > for retransmission when needed, it's no sense to implement > > > ARQ in the data link layer. I disagree. I took that to mean MNP-style retransmission and recovery. > Actually, I was wondering if someone has proposed an additional > LCP Configuration Option which would allow PPP links to use > error-correcting codes rather than error-detecting, i.e. > Reed-Solomon code. That would be a FEC (forward error correction) protocol. No, I've seen no such thing proposed for PPP. Yes, I would agree that for some types of media this would be highly useful. It's not at all the same as a retransmission algorithm, though, nor are the implications for transport protocols similar. Some media, like GSM links, are prone to bit errors. These links, I agree, should use FEC techniques to trade a little bit of bandwidth for more probable reception. This is not at all the same as retransmission and error recovery. > > In other words, if you run TCP over an error-correcting protocol which > > introduces wide variances in the packet-forwarding latency, TCP will "misread" > > those variances as packet loss and will attempt to recover anyway. This > > results in redundant data being sent, oscillatory behavior, and a net loss > > in performance. > > > ??? Don't quite follow you here. Why would an error-correcting protocol > introduce wider variances in the packet-forwarding latency than > regular send-and-pray protocol? In a traditional scenario receiving If that error-correcting protocol needs to resend data which are garbled, then there will necessarily be a delay (as viewed from the other system) while the data are resent. Send-and-pray will not normally result in stale data being effectively buffered in this manner. If the error-correcting protocol, though, is a FEC protocol, then, no, it wouldn't necessarily change anything important about the timing. FEC protocols, though, are rather useless in the face of random *packet* loss, instead of random *bit* loss! Many wide-area systems experience packet loss far more often than bit loss. > PPP discards corrupted packets which means that TCP times out > and asks for retransmission. If we use retranmission there might be a > chance that the receiving TCP gets the retransmitted packet before it > times out. If this happens we will avoid this Slow-Start-syndrome. Of course, TCP is also estimating round-trip-times and is timing out rather quickly in the event of loss. I'd estimate the reverse -- I'd expect a well-designed implementation of TCP to time out *much* faster than any fixed-timer link-layer implementation. > We would only loose a small fraction of bandwidth to control packets > which carry AQKs and NAKs. Plus, of course, both TCP retransmitting, and your hypothetical link-level protocol *also* retransmitting. --- James Carlson Tel: +1 617 272 8140 Annex Interface Development / Xylogics, Inc. +1 800 225 3317 53 Third Avenue / Burlington MA 01803-4491 Fax: +1 617 272 2618 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 31 11:28:26 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id LAA01801; Thu, 31 Oct 1996 11:28:26 -0500 (EST) Resent-Date: Thu, 31 Oct 1996 11:28:26 -0500 (EST) Date: Thu, 31 Oct 1996 09:28:10 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199610311628.JAA01524@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Error detection and retransmission Resent-Message-ID: <"YqyQ2.0.tR.aEDUo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2140 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > James Carlson writes: > >Vicente Cerveron writes: > ... > > > Why PPP doesn't have a single word on error correction algorithms? > >>Because TCP's error-recovery algorithm isn't just for correcting transmission > >errors. ... Maybe also because forward error correction is at least messy and perhaps expensive in CPU cycles when done with software, and because most of the links on which PPP is run have very low error rates. For example, ISDN links seem to be quite reliable and modems are generally 100% reliable thanks to v.42 (yes, modulo host-modem overruns). > ... > >In general, running one retransmission-based error-correcting protocol > >atop another is a Bad Idea. As has been reported in IETF meetings in > >the past, experience with PPP over TELNET has shown that reliability is > >a much overrated property. > > I agree - we've not encountered any serious problems with running TCP > over RFC 1663, but then I don't think we've ever done so on lines with > sufficiently high error rates to cause more than occasional LAPB > retransmissions. We've certainly had some problems in the past with TCP > over X.25 networks (which amounts to pretty much the same thing as RFC > 1663 in terms of performance). > ... I thought the consensus since soon after the PPP group was formed by merging the other two groups is that adding error correction to any link layer medium, including PPP, is a good or bad idea if and only if the medium without error correction is bad. If your link is very lossy, then it is a good idea to recover errors on that link to avoid wasting timeouts and end-to-end bandwidth on end-to-end retransmissions, as well as fooling TCP into thinking congestion is causing the losses. If your PPP link is naturally mostly reliable, it is a bad idea to waste bandwidth and implementation complexity on error correction (either forward- and retransmissions). I doubt the bad experiences with TCP/IP/PPP/telnet/TCP/IP are relevant to TCP/IP/reliable-PPP, unless your reliable-PPP has extremely long timers such like TCP has when run over the Internet. If your reliable-PPP needs a second or more to figure out that a packet has been lost, then bad behavious such as oscillations should be expected from TCP. On the other hand, if your reliable-PPP does not add more than a few link-layer RTT's that are small fractions of the end-to-end RTT when recoverying from an error and if errors are frequent, then TCP will be better served by having those link layer errors recovered. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 31 12:07:24 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id MAA02624; Thu, 31 Oct 1996 12:07:24 -0500 (EST) Resent-Date: Thu, 31 Oct 1996 12:07:24 -0500 (EST) Date: Thu, 31 Oct 1996 11:25:45 -0500 (EST) From: John Shriver Message-Id: <199610311625.LAA18931@shiva-dev.shiva.com> To: Mikael.Latvala@lmf.ericsson.se CC: ietf-ppp@MERIT.EDU In-reply-to: <9610311554.AA20143@blackse2.lmf.ericsson.se> (Mikael.Latvala@lmf.ericsson.se) Subject: Re: Error detection and retransmission Resent-Message-ID: <"gxH6B2.0.ke.5pDUo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2141 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Perhaps you could define a forward error correction protocol as a proprietary encryption protocol, and negotiate it using ECP. (I was originally going to suggest using CCP, but Reed-Solomon expands, not contracts!) However, there's no way to negotiate away the 16 bit checksum on the frame layer. You might want that out of your way for forward error correction, too. Well, I suppose you could just ignore the errors. More difficult is the presence of errors that simulate the async hdlc escape characters, and bollux the framing. Forward error correction won't catch that. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 31 12:33:04 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id MAA03096; Thu, 31 Oct 1996 12:33:04 -0500 (EST) Resent-Date: Thu, 31 Oct 1996 12:33:04 -0500 (EST) Date: Thu, 31 Oct 1996 12:31:35 -0500 (EST) From: Ian Duncan X-Sender: iduncan@magnus2 Reply-To: Ian Duncan To: James Carlson cc: Mikael.Latvala@lmf.ericsson.se, ietf-ppp@MERIT.EDU Subject: Re: Error detection and retransmission In-Reply-To: <13370.9610311622@vulcan.xylogics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"x05TG3.0._l.CBEUo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2142 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Thu, 31 Oct 1996, James Carlson wrote: > Mikael Latvala wrote: > > Actually, I was wondering if someone has proposed an additional > > LCP Configuration Option which would allow PPP links to use > > error-correcting codes rather than error-detecting, i.e. > > Reed-Solomon code. > > That would be a FEC (forward error correction) protocol. No, I've seen no such > thing proposed for PPP. Yes, I would agree that for some types of media this > would be highly useful. It's not at all the same as a retransmission > algorithm, though, nor are the implications for transport protocols similar. Putting FEC inside PPP isn't a good model. It's better to consider it as an element within the physical modulation and run conventional PPP above the resulting highly reliable wireless medium. There is a problem in that existing spectrum allocation doesn't encourage doing this. If your interested, Phil Karn has done some very interesting work implementing practical Viterbi and other FEC schemes which he's made available. -- Ian Duncan Access Products Development Newbridge Networks Corp. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 31 13:24:06 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id NAA04219; Thu, 31 Oct 1996 13:24:06 -0500 (EST) Resent-Date: Thu, 31 Oct 1996 13:24:06 -0500 (EST) Message-Id: <15583.9610311822@vulcan.xylogics.com> To: Ian Duncan Cc: Mikael.Latvala@lmf.ericsson.se, ietf-ppp@MERIT.EDU Subject: Re: Error detection and retransmission In-Reply-To: Your message of "Thu, 31 Oct 1996 12:31:35 EST." Date: Thu, 31 Oct 1996 13:22:39 -0500 From: James Carlson Resent-Message-ID: <"trRpP1.0.X11.-wEUo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2143 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Ian Duncan wrote: > On Thu, 31 Oct 1996, James Carlson wrote: > > That would be a FEC (forward error correction) protocol. No, I've seen no such > > thing proposed for PPP. Yes, I would agree that for some types of media this > > would be highly useful. It's not at all the same as a retransmission > > algorithm, though, nor are the implications for transport protocols similar. > > Putting FEC inside PPP isn't a good model. It's better to consider it as > an element within the physical modulation and run conventional PPP above > the resulting highly reliable wireless medium. There is a problem in that > existing spectrum allocation doesn't encourage doing this. If your > interested, Phil Karn has done some very interesting work implementing > practical Viterbi and other FEC schemes which he's made available. I agree completely -- I wasn't suggesting that as a good way to design it. Only that FEC *somewhere* in some types of links would be a good thing, and that such error control is quite different in behavior than retransmission. --- James Carlson Tel: +1 617 272 8140 Annex Interface Development / Xylogics, Inc. +1 800 225 3317 53 Third Avenue / Burlington MA 01803-4491 Fax: +1 617 272 2618 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 31 14:14:18 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id OAA05330; Thu, 31 Oct 1996 14:14:18 -0500 (EST) Resent-Date: Thu, 31 Oct 1996 14:14:18 -0500 (EST) From: Archie Cobbs Message-Id: <199610311913.LAA00382@bubba.whistle.com> Subject: Re: infinite loop In-Reply-To: <2786af10@rdl.co.uk> from Jonathan Goodchild at "Oct 31, 96 08:59:21 am" To: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Date: Thu, 31 Oct 1996 11:13:01 -0800 (PST) Cc: ietf-ppp@MERIT.EDU X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Q4DjG.0.zI1.4gFUo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2144 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Jonathan Goodchild writes: > > LOG FOR PPP A > > > > +0 Up event > > +0 state change Starting --> Req-Sent > > +0 SendConfigReq #1 > > +0 rec'd Configure Request #1 (Req-Sent) > > +0 SendConfigAck #1 > > +0 state change Req-Sent --> Ack-Sent > >(*) +1 SendConfigReq #2 > > +1 rec'd Configure Ack #1 (Ack-Sent) > > This is wrong - Configure-Ack #1 must be ignored, as Configure-Request #2 has > been sent (RFC 1661 section 5.2 [page 29]: ..the Identifier field MUST match > that of the last transmitted Configure-Request). Alternatively, the error co That is the problem -- thanks!! -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 31 16:01:11 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id QAA08090; Thu, 31 Oct 1996 16:01:11 -0500 (EST) Resent-Date: Thu, 31 Oct 1996 16:01:11 -0500 (EST) From: Gina.Deplanche@proteon.com (Gina DePlanche) Message-Id: <9610312100.AA07658@banacek.proteon.com> Subject: IPXCP question To: ietf-ppp@MERIT.EDU Date: Thu, 31 Oct 1996 16:00:29 -0500 (EST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"tSUIL3.0.2-1.HEHUo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2145 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi all! Mega-apologies if this has already be asked and answered. I'm new to IPXCP. RFC 1552 states that the IPX-Node-Number MUST be unique for the network number. What should I do if the remote side (for some reason) send me a node number which is equal to my node number? Seems like I should send a Config-Nak, but what value do I suggest the remote side use? 0? Thanks for the help! - Gina -- Gina M. DePlanche | Proteon gmd@proteon.com | MailStop #23 (508) 898-2800 x2541 | 9 Technology Drive, Westborough, MA Fax: (508) 898-2547 | 01581-1799 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 31 16:58:03 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id QAA09492; Thu, 31 Oct 1996 16:58:03 -0500 (EST) Resent-Date: Thu, 31 Oct 1996 16:58:03 -0500 (EST) Date: Thu, 31 Oct 1996 16:58:42 -0500 (EST) Message-Id: <199610312158.QAA22639@carp.morningstar.com> From: Karl Fox To: ietf-ppp@MERIT.EDU Subject: MPPC PPP Compression - Working Group Last Call Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"g1qiW2.0._J2.c3IUo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2146 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU This is last call. I will advise the area directors that we want to take the Microsoft Point-To-Point Compression (MPPC) Protocol to Informational Standard on November 14 unless there is substantive comment raised on the list. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 31 17:06:45 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id RAA09741; Thu, 31 Oct 1996 17:06:45 -0500 (EST) Resent-Date: Thu, 31 Oct 1996 17:06:45 -0500 (EST) Date: Thu, 31 Oct 1996 17:07:24 -0500 (EST) Message-Id: <199610312207.RAA22659@carp.morningstar.com> From: Karl Fox To: ietf-ppp@MERIT.EDU Subject: BACP Withdrawn Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"s9pcT3.0.vN2.mBIUo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2147 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I have succeeded in getting the area director to put BACP on hold until we can issue another draft. It requires two changes: 1) It refers to RFC 1717 instead of RFC 1990. 2) It allows compression of BAP packets which make it impossible for some devices (certain terminal adapters) to work properly. This was discovered during the recent CIUG meeting at PacBell in San Ramon. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Oct 31 20:12:15 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id UAA12042; Thu, 31 Oct 1996 20:12:15 -0500 (EST) Resent-Date: Thu, 31 Oct 1996 20:12:15 -0500 (EST) Message-ID: <32794DB9.6735@cmtn.com> Date: Thu, 31 Oct 1996 17:09:13 -0800 From: "Eric L. Michelsen" X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: ietf-ppp@MERIT.EDU Subject: Re: Error detection and retransmission References: <15583.9610311822@vulcan.xylogics.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"tGsBp1.0.px2.gvKUo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2148 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Certainly it is better to have any FEC be part of the physical layer, to avoid the problems of lost framing. But of course, if FEC *is* part of the physical layer, that explains why it is not mentioned in PPP, because PPP has no part in it. Some points to consider on the delays of error correcting link layers carrying PPP frames: 1. Most likely, the PPP link will be carrying a bunch of traffic. If a single frame is corrupted, it will be followed quickly thereafter by subsequent frames, some of which will be uncorrupted. The receiving side therefore knows immediately that it has lost data, because it sees the out of sequence frames following the errored frames. The receiving side immediately requests retransmission, and there is no ARQ protocol timeout. This usually makes the retransmissions occur quickly; for telephone modems, within a few hundred milliseconds. In the unlikely event that a frame is corrupted, and it happens to be the last frame before a big pause in the data, then the transmitter will detect a lack of acknowledgement *after* the ARQ timeout, which for telephone protocols (LAPM (V.42) and MNP) is typically 2-3 seconds. 2. X.25 may have significantly different performance than LAPM (V.42) on links of similar speed, because X.25 has mostly been implemented without selective retransmission. In X.25, if a frame is lost, the sender must back up to the lost frame, and resend *all* frames from that point again. In V.42, if a frame is lost, the receiver can request retransmission of *only* the lost frame, and avoid retransmitting all the other good frames. (Actually, LAPM can request retransmission of any number of arbitrary frames). -- -Eric L. Michelsen, Copper Mountain Communications, Inc. - - - - - - - - - - - - - - - - -