I think the reasoning is to prevent the transmission of traffic almost all the way through the frame cloud only to have it dropped by the last telco switch. With congestion notification you can shape the traffic for a more even flow reducing packet loss and retransmission based on information from the cloud.
If the traffic is traveling across the cloud only to be dropped at an intermediate switch, it is still consuming valuable bandwidth. Imagine one end with T1 access speed and the other end with a 64K port. The T1 end will crush the line with everything it has only to have it dropped by the last switch attached to the 64K port. Then the T1 end will cycle through retransmission, and on, and on. You would waste a terrible amount of bandwidth. -----Original Message----- From: Steven A. Ridder [mailto:[EMAIL PROTECTED]] Sent: Monday, January 07, 2002 3:49 PM To: [EMAIL PROTECTED] Subject: BECN vs TCP congesttion control [7:31219] I understand that FR is multi-protocol, but I feel confident in saying that most traffic is IP based. 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, not nearly as robust and complex as TCP's tried and true methods of congestion control. 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] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=31223&t=31219 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
