BTW, is the RFC 2681? I looked that one up on ietf.org and the RFC by
that number was a different beast entirely - at least at a very quick
glance.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
http://www.faqs.org/rfcs/rfc2861.html
thanks.
Long periods when the sender is application-limited can lead to the
invalidation of the congestion window. During periods when the TCP
sender is network-limited, the value of the congestion window is
repeatedly "revalidated" by the successful transmission of a window
of data without loss. When the TCP sender is network-limited, there
is an incoming stream of acknowledgements that "clocks out" new data,
giving concrete evidence of recent available bandwidth in the
network. In contrast, during periods when the TCP sender is
application-limited, the estimate of available capacity represented
by the congestion window may become steadily less accurate over time.
In particular, capacity that had once been used by the network-
limited connection might now be used by other traffic.
May, might, could... :)
What concerned me the most was section 5, where the experiments were for
dial-up connections and an interactive user then cat'ing a large file to
the screen. How often does someone "list a moderately large file"
without using less or more? And the bit about the second experiment
with the real modem bank not showing any difference in what the user
experienced because the bank had buffering was interesting. It suggests
(to me anyway) that perhaps the TCP receive window was too large for a
modem connection in the first place. Leaves me wondering what effect
Linux's moderated receive window would have on that experiment.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
