home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.dcom.cell-relay
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!ux1.cso.uiuc.edu!usenet.ucs.indiana.edu!cell@mythos.ucs.indiana.edu
- From: "Allen Robel" <cell@mythos.ucs.indiana.edu>
- Subject: Re: new AAL (SSCOP?)
- Message-ID: <BxFIuK.IzJ@usenet.ucs.indiana.edu>
- Sender: <cell@mythos.ucs.indiana.edu>
- Organization: Indiana University
- Date: Mon, 9 Nov 1992 03:19:44 GMT
- Lines: 29
-
- atkinson@itd.nrl.navy.mil writes:
-
- >This is a strong statement. It is not at all clear to me that a Van
- >Jacobson TCP will not be sufficiently effective. I'd be much obliged
- >if you'd explain why you believe there is a problem with handling
- >things with TCP/IP/AAL5 without the other mechanism you mention.
-
- Ran,
-
- Partho Mishra and Hemant Kanakia give fairly convincing evidence
- that TCP is not all that effective at efficient flow control
- over multihop high-speed networks in their paper "A Hop by Hop
- Rate-based Congestion Control Scheme" that appeared in Computer
- Communication Review SIGCOMM '92 Proceedings in which they compared
- their hop by hop (HBH) scheme of flow control to TCP as implemented in
- 4.3-Tahoe BSD (they also compare HBH with the modified window adjustment
- in the 4.3 BSD Reno version of TCP). Their results seem to indicate
- that, in a network with a high bandwidth-delay product, TCP exhibits
- very large oscillations in end-to-end delay, and takes about 100
- round trip times (losing about 190 packets) before a link becomes
- fully utilized. In contrast, HBH loses NO packets and maintains
- a very even end-to-end delay variance. Note that I'm not condoning
- their scheme. I'm just saying that there are schemes out there that
- do better in the area of flow control than current implementations of
- TCP in high speed networks.
-
- regards,
-
- allen
-