So I guess frame-relay assumes a smart network/dumb host type situation? The only other thing I saw was Fred's statement
"...None of these companies had much IP experience at the time, and it was mostly X.25-experienced people working on it. So the congestion issues needed to be brought out. I was working for a company that sold connectionless networks, and we KNEW about congestion and the possibilities of congestion collapse. (Firsthand experience with congestion collapse in the eary '80s was a very good learning experience.)..." What does he mean when he speaks about "congestion collapse"? Was this the case in a "dumb" network where too many calls would just bring it down? Did this bring up the need to create fecn/becn as a sort of next-generation type thing to correct the problems they may have experienced in previous type networks? Was there a parallel, but opposite school of thought in the TCP/IP networks (I guess the Internet and ARPANET) of a smart host/dumb network where the hosts and rotuters would handle congestion with TCP and ICMP source quench messages and the such? If I can assume that there were two schools of thought, can I also assume that frame-relay with it's smart network/dumb host model and tcp/ip's smart host, peer-to-peer network were never meant to merge? Also, what effect does becn/fecn (if implemented) have on TCP/IP's windowing? Any? Should the two never be used together, or can they co-exist peacefully if implemented right? Sorry to ask all these questions, but this is like a history lesson to me (IP was RFC'd in 1981, so I was 3 years old) and I learn best if I can get a grasp on not only how things are done, but why. -- RFC 1149 Compliant. FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
