>At 05:49 PM 1/7/02, Steven A. Ridder wrote: >>I understand that FR is multi-protocol, but I feel confident in saying that >>most traffic is IP based. > >Traffic wasn't so overwhelmingly IP-based at the time that Frame Relay was >designed.
And I'll draw attention to Priscilla's observation that these specifications were developed by the CCITT/ITU, which comes from a telephony perspective. The classic telephony paradigm is the network is intelligent and the host is stupid, while IP uses the reverse paradigm. CCITT wasn't wrong when the end host was an analog telephone. I freely admit BECN/FECN is a terrible method. But it fit the mindset of the time. Remember, also, that Frame Relay was _not_ designed as an end-to-end protocol, but as a low- to medium-speed access protocol to ATM networks -- which would have the bandwidth not to congest. FR is essentially X.25 intended to work on more reliable transmission media. In the case of both reliable link protocols and TCP, you can't really separate flow control and congestion control. >And even in the case of the IP traffic, quite a bit of it was and >still is UDP-based. Also, I don't think the CCITT (ITU) really cared too >much about what was riding above. The OSI layers dictate modularity. > >I doubt that answers your question, though! I hope someone else answers >too. Also see one additional comment below. > > >>With that out of the way, historically, why did the writers of frame-relay >>include BECN as a method of congestion control when 1, it isn't end-to-end >>as TCP is, and therefore not as "good" as TCP, and 2, > >End-to-end congestion control isn't necessarily better. Consider three >regions: > >Region 1 Region 2 Region 2 > >If Region 2 experiences congestion and can notify Region 1 (and Region 1 >can adjust), then Region 3 never experiences the congestion. This is a good >thing. > >>not nearly as robust > >and complex as TCP's tried and true methods of congestion control. TCP is not the be-all, end-all of congestion control. If you hunt through various RFCs, often on the Experimental side, you will see many problems, and also suggested modifications. TCP tends to optimize to maximize throughput rather than minimize delay. In the Cisco context, look at Random Early Detect and how it interacts with TCP to make TCP congestion control much more intelligent. Even so, the industry perceives a need for congestion avoidance as well as congestion response, through various mechanisms as bandwidth reservation with traffic engineering, connection admission control, traffic shaping, etc., none of which are present in standard TCP. > > >>Is there another reason that I don't understand. >> >>-- >> >>RFC 1149 Compliant. >> >> >>FAQ, list archives, and subscription info: >>http://www.groupstudy.com/list/cisco.html >>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > > >________________________ > >Priscilla Oppenheimer >http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=31230&t=31219 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
