>So I guess frame-relay assumes a smart network/dumb host type situation?
Yes, and also generally with the caveat the host is directly
connected to the network, with no intervening devices such as routers.
>
>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?
Different things in different networks. Generally, think of
situations where traffic doesn't get through due to congestion, and
there's no negative feedback to the hosts to slow down. So at the
time when you least want more traffic in the network, the hosts are
merrily retransmitting and the load goes up exponentially.
Eventually, you may congest to the point that key control information
(e.g., routing updates) don't get through, and the network fails.
>
>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?
Definitive answer: yes and no. Depends on your configuration. FR
assumed the host was directly connected to the network, so could
respond to BECN/FECN. But the more common model is:
Host(s)---LAN---Router----FR
where there is no L2 connectivity between the FR network and the
hosts. If the network sends FECN/BECN, how does that information get
to the hosts?
There are scenarios where the router can reduce transmission rates,
or selectively drop packets or not send DE packets, etc., if it
receives BECN/FECN. Selective drop certainly is a TCP feedback
mechanism in Random Early Detect.
Packet drops may or may not have any effect on either TCP that is
coded not to comply with congestion control but to maximize
throughput for marketing reasons, or for UDP.
>
>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.
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=31472&t=31219
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
