> 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...
To be honest, I'm less worried about how it effects asymmetric
environments as I am about the shared paths; What people do to their
own ack-channels is their responsibility. If I wanted to harp on things
that were potential problems with asymmetric links, I'd have mentioned
the possible negative impacts of timestamps and SACK on asymmetry. People
who don't think they have asymmetry problems might be in for a rude
awakening even w/o acking every segment. :o(
Let me contrast this proposal with the increase in initial cwnd that
caused a stir. With initial-cwnd increase you are being slightly more
aggressive only at the start of a connection. Here, we have the
possibility of advocating being *twice* as aggressive for the life of the
connection. This is a good thing from the perspective of the larger
community?
A large bandwidth-delay product acts like a magnifying glass to
TCP-behavior... Do we want to be the modern equivalents of
Hannibal, advocating the potential unleashing of severely aggressive
elephants on the rest of the (unsuspecting) Internet?
Personally, I've flip-flopped on this very issue at least twice in the
past 12 months (bad->good->bad) from the stuff that I'm doing. It's not
a clear win, even if you don't have asymmetry problems - acking every
segment (or receiving acks for every segment) have a noted impact on
end-system performance too. Frankly, generated acks less frequently
(with byte-counting and/or rate-control) can get you better performance
than acking every packet.
My goal in whining here is that, as a group, we don't rush into something.
Leave it as research, and when we have more information one way or the
other, it can be raised in an appropriate forum.
> => (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 you are looking for feedback from the larger community that may face
our rampaging elephants, we need to raise the issue on end-to-end...
> => 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.
And it is the servers pumping data to these users that will potentially
end-up congesting it's forward paths with aggressive behavior (clueless
that it is going over a satellite path - perhaps); This impacts folks who
are NOT on satellite paths, hence it is anti-social behavior.
> => 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?
It's still a *substantial* scope growth of the existing documents that is
the problem. The plan from LA was to have a last call prior to Chicago
was it not? Adding this is of questionable value in comparison to
meeting that deadline.
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:44 EST