=> -----Original Message-----
=> From: Eric Travis [mailto:[email protected]]
=> Please don't open Pandora's box with:
=>
=> I don't think that because it is only good in some
=> satellite scenarios that it now becomes a research issue.
=>
=> It blows the scope of the document wide-open and *every* element
=> that is currently "research" would need to be revisited for
=> inclusion by this criteria. :o(
Perhaps I was too hasty in my posting. My intention was the following.
Given that -stand-mech- contains ONLY legal mechanisms and a consensus
that the only negative impact of ACKing every packet is to asymmetric
bandwidth environments, then it seems that this is a recommendation that
we can make. However, I am swayed by some of your comments and am going
to play devils adovcate, not as wg chair but to build a consensus...
=> From my observations, the effective litmus tests that seem to
=> have been in effect for inclusion into the standards mechanisms
=> draft (and the working-group as a whole) are:
<...test deleted...>
=> (2) - Is it OK for some connections to be more aggressive than
=> others?
We all know that congestion control isn't fair to long delay
connections. It takes longer for the window to open to use available
bandwidth. Contrarily, when there is congestion, it takes longer for the
window to close--making long delay connections fairly unresponsive to
network congestion, i.e. the window is closed when it should open and
continues to open when it should close. The question in my mind is: does
ACKing every packet make that worse? Dangerously worse? If there's doubt
in the community, then, of course it belongs in -res-mech-. So, I'm
looking for feedback.
=> If so, how does a client *know* that it traversing
=> a long delay path instead of a terrestrial path?
There will be a significant community of users of satellite networks who
will know absolutely that they are over a long delay path. That
knowledge is much easier to come by for the client than the server.
=> Where is
=> the proof that this is a safe thing to allow for general use?
=>
I second your question.
=> If the satellite subnetworks were guaranteed to be separated
=> from the Internet backbone (say, via a proxy or splitting gateway),
=> the scope of the "standard mechs" document would have been different;
=> Lot's of things are research because of the uncertainty of their
=> behavior in the public paths. This (in my opinion) falls into that
=> category.
=>
=> The original document got split in part for this reason; I think
=> it is too late in the process to widen the scope, because it opens
=> a flood gate of other possibilities and requires the inclusion of
=> text describing the differences in behavior.
=>
Let's see. Perhaps we should confine this discussion to split
connections on satellite subnetworks only. Comments?
--aaron
PS. if I drop offline, it's not because I lost interest but I'm going on
vacation for a week and may not have access. Leaving tonight. af
_________________________________________________________________
Aaron Falk TRW Space & Electronics Group
Network Systems Engineer One Space Park
(310) 814-4932 [email protected]
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:44 EST