Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ncar!noao!arizona!rogerh From: rogerh@arizona.edu (Roger Hayes) Newsgroups: comp.protocols.tcp-ip Subject: Re: Multiple TCP/IP servers on one host Message-ID: <7041@megaron.arizona.edu> Date: 14 Sep 88 03:43:48 GMT References: <8809080134.AA05073@ucbvax.Berkeley.EDU> <957@helios.ee.lbl.gov> Reply-To: rogerh@arizona.edu (Roger Hayes) Organization: U of Arizona CS Dept, Tucson Lines: 33 In article <957@helios.ee.lbl.gov> dagg@lbl.gov (Darren Griffiths) writes: >[...] In >many cases there are different paths to the same host, [...] >there are two ways of making use of this path. > > 1) If the second path was 25% of the speed of the first path then 25% of > the packets could be sent that way. [...] > if the two end sides were running the Van Jacobsen/Mike Karels code > I believe this wouldn't be to much of a problem. [...] > > 2) The second thing that can be done is a little nicer. [...] The first thing (splitting load among routes) would screw up the Jacobson/Karels improved TCP completely. They get a big win by estimating the variance of the round trip time; using alternating routes for different packets would drive this variance way up, causing the timeout to be set high, causing long stoppages on lost packets. Further, their code for calculating optimum window size, which is pretty subtle, tests for increased available bandwidth by increasing window size. I can imagine that this code would get pretty thoroughly confused if the period of route-switching was near the window size, as that would cause successive windows to have wildly varying proportions of samples from the two routes. The slower route would periodically be heavily overloaded (when the outstanding packets in the window happened to mostly be sent via the slow route) while the faster route would operate below its optimal point. Seems like the best way to make use of alternate routes is by implementing the type-of-service stuff. Roger Hayes rogerh@arizona.edu