home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / protocol / nfs / 3220 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  2.6 KB

  1. Xref: sparky comp.protocols.nfs:3220 comp.dcom.isdn:1250
  2. Newsgroups: comp.protocols.nfs,comp.dcom.isdn
  3. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!torn!nott!hobbit.gandalf.ca!dcarr
  4. From: dcarr@gandalf.ca (Dave Carr)
  5. Subject: Re: Low cost ether/isdn brouters
  6. Message-ID: <1993Jan26.182202.16972@gandalf.ca>
  7. Organization: Gandalf Data Ltd.
  8. References: <1993Jan21.151029.13640@gandalf.ca> <1993Jan22.002029.27149@informix.com> <1993Jan25.142206.17177@gandalf.ca> <1993Jan26.011730.185@informix.com>
  9. Distribution: na
  10. Date: Tue, 26 Jan 1993 18:22:02 GMT
  11. Lines: 35
  12.  
  13. In <1993Jan26.011730.185@informix.com> johng@informix.com (John Galloway) writes:
  14.  
  15. >In article <1993Jan25.142206.17177@gandalf.ca> dcarr@gandalf.ca (Dave Carr) writes:
  16. >>
  17. >>With bonding you only have one channel.  With some software running on top
  18. >>of multilink, you can split the packet in pieces and load balance. 
  19. >>Fragmentation in this case is not done like a router, but similar to the
  20. >>more bit in X.25.
  21.  
  22. >These two topcis are also realated.  If running completely seperate
  23. >B channels, then a user could leave one up all the time (and have a single
  24. >B chanles worth of resource on the host end dedicated to this user) but
  25. >only add the second on demand and thus have something like 1.25 B channels
  26. >for each user at the hub, and give 2 64K channels to most folks when
  27. >the need arises, but not have to have 2B channels dedicated to each user.
  28. >Digiboard claims they can do this with their IMAC with each B channel going
  29. >to a different user.  However this scheme would not allow the 2Bs to be bonded.
  30. >In part this comes down to the question: do apps like ftp want an
  31. >ack after every packet and hence not be able to make use of 2 64K channels
  32. >as opposed to one 128K channel?
  33.  
  34. This isn't an issue if you run LAPB multilink over multiple (not necessarily 2)
  35. links.  You are free to split the frame, not fragment but equivalent to the
  36. X.25 more bit at layer 3, over the links and reassemble at the remote before
  37. transmitting out the ethernet.  Then, you can load balance a single frame.
  38.  
  39. Alternately, if the protocol supports a tranmission window as FTP does, you
  40. can use the links independently.  However, I believe that a bridge/router
  41. should maintain the sequence of packets.  This is not possible without adding
  42. the equivalent to a multilink sequence number over the links.  You don't
  43. need LAPB for this.  I don't know what Digiboard does.  
  44.  
  45. We run LAPB with multilink.  But we do not (yet) split the frames for load
  46. balancing.  We do it on a frame-by-frame basis.
  47.  
  48.