>I have been searching as to the purpose of these FECN and BECN bits, and I >found this in an old newsgroup from 1994 from a guy who wrote part of Frame >Relay standards. Looks like Howard and Pricilla were right in that IP >wasn't a concern, as IBM had SDLC and ATT & BellCore had x.25 and other >netowrks. Looks like x.25 had congestion issues cause of no layer 4? Am I >right?
First, you've found an excellent source. Fred's "ISDN in Perspective" is one of the best books around. Second, you're still thinking in an IP-ish way when you talk about congestion issues. SDLC is part of SNA, and there are definitely flow control mechanisms in it. But there was an even more fundamental issue in the SNA world: the host was in control. As a terminal, you didn't transmit until you were invited to transmit. The controlling mainframe or front end did not send out invitations until it was ready to receive. Remember also that the mainframe (or equivalent) was assumed under the control of a single organization, who usually kept a very close eye on resource utilization. New devices COULDN'T be added to an SNA network without intervention by the system programming group. Now, as to X.25 -- you have to think telephony. We don't think of congestion during traditional telephone calls as an issue, because the PSTN uses connection admission control. If the core network is at capacity, you'll get the "fast busy" (technically reorder) signal and you can't make that call. X.25 had a bunch of congestion management features, but using a smart network/dumb host model rather than the reverse model in IP. To start with, it was an access, not an end-to-end protocol. The network was perfectly free to refuse to accept a call request if the network decided it didn't have the needed capacity. In extreme conditions, the network could clear calls in progress if the network became overcongested. ATM has the same capabilities. Early X.25 applications were telnet-like, and half duplex -- so there was end-to-end control at the application layer. X.25 also had a very limited end-to-end function at the packet layer, which was never widely implemented -- called the D bit. Typically, if you had X.25 network performance problems, the first bottleneck was bandwidth on the link to the network entry point. You would either upgrade the link, or reduce the number of simultaneous calls that it would accept (i.e., the number of users). I suppose I'm saying that SNA and X.25 were appropriate protocols for a much more centrally managed organization than today's networks. In the right context, they tend to be more reliable than many Internet applications, but they are more expensive in many ways. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=31330&t=31219 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
