On Thu, 18 Jun 1998, Falk, Aaron wrote:
> => Mark and I went around on this early on and wound up moving
> => acknowledgement issues to the research issues draft. I would
> => tend to go along with you with the caveat that asymmetric systems
> => should consider the impact on their return channel. Also, if
> => everyone started acking every packet, would this hurt the network?
> =>
>
> My opinion is to include it as a recommendation with appropriate
> caveats. I don't think that because it is only good in some satellite
> scenarios that it now becomes a research issue.
Aaron,
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(
I would have supported a wider-scope of things earlier on (in fact,
I did), but with the lifespan of the working group in its closing
stages, it's too late to divert from the chosen path.
>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:
1) Is it legal with respect to RFC 793 (and 1122, and...)?
2) Are we violating fairness/Are we sure that it won't
degrade performance for other connections on shared paths?
3) Is it expected to be a readily available item in
modern TCP implementations? (Will it be readily available)
The answers seem to be:
(1) - yes, but discouraged in spirit by RFC-1122's *should*
clauses regarding delayed acks.
(2) - Is it OK for some connections to be more aggressive than
others? If so, how does a client *know* that it traversing
a long delay path instead of a terrestrial path? Where is
the proof that this is a safe thing to allow for general use?
(3) - In the recent past, I seem to remember some TCP implementations
that didn't implement delayed-acks as being regarded as "broken";
Should vendors be offering two different TCP implementations:
one with/one without delayed-acks? Granted, you can do this with
just a knob - but this then falls into the "hand-tuning" category,
and it *might* be desirable on a connection-by-connection basis.
Am I the only one thinking it fails one (if not two) of these tests?
Finally, since "byte-counting" is the moral equivalent of acking
every packet - but more bandwidth/processor friendly, will this be
included also? I can extrapolate further "tweaks" that fall into
the same grey area of legality...
I've gotten poor performance with the "ack every segment" approach,
better with "byte counting", yet because of the *possibility* of
negative impacts on asymmetry and OTHER traffic on shared paths,
I don't feel that moving this from the research draft to the
document that covers standards-track mechanisms.
I wasn't in Munich (although my slides were) and get feedback
telling me that both these possibilities met with some fairly
hostile response. That was the last time the subject was broached
in this forum - have things changed?
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.
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:44 EST