Bob Gustafson writes: > But, But, - this is really just software. We are not trying to cram wine > bottles down the internet pipe (although many would really like to do > that!). The limitations I point out are inherent in tcp/ip. I think I sent a proposal to this list describing a modification to tcp that would allow one connection to use many ip addresses (for each endpoint). That would allow substantial improvement, since you would be able to switch addresses in "mid stream" (in a live connection). It would not solve all of the problems. In particular, you would not be able to efficiently use both/all addresses at once because tcp has been adapted to work well in the case where packets arrive in order. That could also perhaps be overcome with changes to tcp. Note, however, that these changes would only help you in cases where both machines are using the modified versions. > >From the requestee point of view, I know how much bandwidth I need to > listen to the BBC newscast, or to a company conference call. I can also > request email and ftp sessions to work in the 'background' at a lower > bandwidth allocation (cost?), but if I am talking to someone interactively, > it would be nice if my packets were transferred at a regular rate without > jitter or delay. IP doesn't do this, and one can argue that it cannot. But, > the whole thing is run by software and software can change. All of the things above can already be done on a single link. What cannot be done is make two links work like one with the sum of the bandwidth.
