home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / dcom / sys / cisco / 1864 < prev    next >
Encoding:
Text File  |  1992-12-16  |  2.9 KB  |  65 lines
  1. Newsgroups: comp.dcom.sys.cisco
  2. Path: sparky!uunet!spool.mu.edu!agate!boulder!recnews
  3. From: dave o'leary <doleary@cisco.com>
  4. Subject: FECN and BECN bits on Frame Relay
  5. Message-ID: <724556611.16854@news.Colorado.EDU>
  6. Sender: news
  7. Date: 16 Dec 92 13:59:31 -0800
  8. Approved: news
  9. X-Note1: mail msgid was <199212162202.AA07231@spot.Colorado.EDU>
  10. X-Note2: message-id generated by recnews
  11. Lines: 52
  12.  
  13.  
  14. In article <723936986.11433@news.Colorado.EDU> Tom_Karolyshyn@dgc.ceo.dg.com writes:
  15. >
  16.  (various header stuff deleted)
  17. > 
  18. > Promotion of FECN Bits for OSI and DECnet Phase IV
  19. > Frame Relay switches have the capability of setting congestion bits 
  20. > in packets (Forward Explicit Congestion Notification (FECN__ as they
  21. > transit the Frame Relay Network.
  22. > 
  23. > This feature allows promotion of FECN bits from the Frame Relay
  24. > network to the appropriate congestion management fields of OSI and
  25. > DECnet Phase IV packets. The protocols are expected to recognize the
  26. > fields and provide some congestion relief by whatever mechanism that
  27. > is available to them. There are no new commands associated with this
  28. > feature.
  29. > 
  30. >Do I read this correctly to mean that there is no benefit to TCP/IP 
  31. >users, i.e., FECN bits have no use in a Frame-relay / TCP/IP 
  32. >environment (like ours) ?
  33. >Tom Karolyshyn
  34. >Data General Corp
  35. >Westboro, MA 01580   508-870-7936
  36. >
  37.  
  38. Since IP, TCP, UDP, etc. have no "congestion control" bits in their
  39. headers (like OSI and DECnet), there isn't anything the cisco can
  40. really do.  I kind of wonder about the real value of this mechanism
  41. anyway, since the switch is setting the FECN bits because of
  42. congestion on an interface which may or may not be due to a specific
  43. host (and protocol and session on that host), i.e. some Appletalk node
  44. starts blasting away at another node across the frame relay through
  45. the cisco routers.  A pair on DECnet hosts using the same set of links
  46. could receive packets with the congestion bit set because the frame
  47. relay switch sees too much stuff coming at it from the cisco router.
  48. Most of it might be from the Appletalk node (which will never receive
  49. any noticification of the FECN, directly or indirectly), and the frame
  50. relay switch can't distinguish between the Appletalk node and the
  51. DECnet node - it just sees stuff coming from the cisco.  The DECnet
  52. node might back off but if the Appletalk node has more stuff to send
  53. it will just hog whatever bandwidth the DECnet session has given up.
  54. So the real problem is figuring out how to notify the offender that it
  55. is causing a problem in a multiprotocol environment with different (or
  56. no) means of congestion control per protocol and session.  Trying to 
  57. perform flow and congestion control at multiple layers in the stack 
  58. that don't know what the other layer is doing (wouldn't want to violate
  59. that model :-) can cause unexpected results, in particular really bad
  60. performance.  
  61.  
  62. dave o'leary        consulting engineer        cisco systems
  63. (714)261-5681             Newport Beach, CA    doleary@cisco.com
  64.  
  65.