home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / dcom / cellrel / 730 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  3.3 KB
  1. Path: sparky!uunet!stanford.edu!ames!haven.umd.edu!mimsy!partho
  2. From: partho@cs.umd.edu (partho pratim mishra)
  3. Newsgroups: comp.dcom.cell-relay
  4. Subject: Hop by hop vs End to end flow control
  5. Message-ID: <62141@mimsy.umd.edu>
  6. Date: 17 Nov 92 15:35:32 GMT
  7. Sender: news@mimsy.umd.edu
  8. Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
  9. Lines: 59
  10.  
  11. craig@sics.se (Craig Partridge) writes
  12.  
  13.  
  14. >>"Allen Robel" <cell@mythos.ucs.indiana.edu> writes:
  15.  
  16. > they compared
  17. > their hop by hop (HBH) scheme of flow control to TCP as implemented in
  18. > 4.3-Tahoe BSD (they also compare HBH with the modified window adjustment
  19. > in the 4.3 BSD Reno version of TCP).  Their results seem to indicate
  20. > that, in a network with a high bandwidth-delay product, TCP exhibits
  21. > very large oscillations in end-to-end delay, and takes about 100
  22. > round trip times (losing about 190 packets) before a link becomes
  23. > fully utilized.  In contrast, HBH loses NO packets and  maintains
  24. > a very even end-to-end delay variance.  Note that I'm not condoning
  25. > their scheme.  I'm just saying that there are schemes out there that
  26. > do better in the area of flow control than current implementations of
  27. > TCP in high speed networks.
  28.  
  29. >>    I'd just like to note that the jury is still out on these results.
  30. >>In general, the literature (both theory, simulation and practice) shows 
  31. >>end-to-end flow control outperforming hop-by-hop.  And I've heard folks
  32. >>question whether the representation of TCP-IP in the model was accurate.
  33. >>Certainly, given the weight of results one way, it is not clear that one
  34. >>dissenting paper should be sufficient to lead us.
  35.  
  36. and later Rob Warnock writes 
  37.  
  38. >The oscillation is real, and quite large; I have seen it during FTPs with
  39. >"hash" turned on. But also note that Jon Crowcroft (et al?) published a paper
  40. >some time ago which proposed a simple change to TCP slow-start that smooths
  41. >out most of the oscillation. I wouldn't count TCP (or end-to-end congestion
  42. >control) out yet...
  43.  
  44.  
  45. There seems to be some misunderstanding about the "accuracy of the
  46. TCP model". We used the 4.3 BSD Tahoe version of TCP as our model.
  47. In fact the simulator we used was written by Lixia Zhang and used in several
  48. previous studies of TCP (which appeared in CCR and Sigcomm).  What
  49. we found was there were many reasons why 4.3 BSD TCP would perform
  50. badly over high speed links (45 Mb/s and faster). For lack of space
  51. we had to leave out most of the explanation in our Sigcomm paper,
  52. although a companion Technical Memorandum examines the issues in some
  53. more detail. 4.3 BSD Reno and selective acks togther do solve some of the 
  54. problems though not all.  I would be glad to discuss with interested people
  55. what it does and what it does not fix.
  56.  
  57. As far as the hop by hop vs end to end argument goes I believe we are 
  58. entering the domain of religion so I will hold my horses. However, I
  59. would like to disagree with the claim that "the literature (both theory, 
  60. simulation and practice) shows end-to-end flow control outperforming 
  61. hop-by-hop".  One has to compare specfic mechanisms before making such
  62. a sweeping statement.
  63.  
  64. -Partho Mishra
  65. -- 
  66.                                |  Systems Design and Analysis Group
  67.       Partho Pratim Mishra     |  Department of Computer Science    
  68.          partho@cs.umd.edu     |  University of Maryland         
  69.                                |  College Park, MD 20742      
  70.