Just how thin can a thin stream be when a thin stream is found thin? (to
the
cadence of "How much wood could a woodchuck chuck if a woodchuck could
chuck wood?")
Does a stream get so thin that a user's send could not be split into
four,
sub-MSS TCP segments?
That was a nifty idea: Anti-Nagle the segments to be able to trigger fast
retransmissions. I think it is possible.
Besides using more resources on each send, this scheme will introduce the
need to delay parts of the segment, which is undesirable for
time-dependent applications (the intended target of the mechanisms).
I think it would be fun to implement and play around with such a mechanism
to see the effects.
Regards,
Andreas
apetlund@simula.no wrote:
quoted
Just how thin can a thin stream be when a thin stream is found thin? (to
the cadence of "How much wood could a woodchuck chuck if a woodchuck could
chuck wood?")
quoted
Does a stream get so thin that a user's send could not be split into four,
sub-MSS TCP segments?
That was a nifty idea: Anti-Nagle the segments to be able to trigger fast
retransmissions. I think it is possible.
Besides using more resources on each send, this scheme will introduce the
need to delay parts of the segment, which is undesirable for
time-dependent applications (the intended target of the mechanisms).
I think it would be fun to implement and play around with such a mechanism
to see the effects.
Indeed, it does feel a bit "anti-nagle" but at the same time, these thin streams
are supposed to be quite rare right? I mean we have survived 20 odd years of
congestion control and fast retransmission without it being a big issue.
They are also supposed to not have terribly high bandwidth requirements yes?
Suppose that instead of an explicit "I promise to be thin" setsockopt(), they
instead set a Very Small (tm) in today's thinking socket buffer size and the
stack then picks the MSS to be no more than 1/4 that size? Or for that matter,
assuming the permissions are acceptable, the thin application makes a
setsockopt(TCP_MAXSEG) call such that the actual MSS is small enough to allow
the send()'s to be four (or more) segments. And, if one wants to spin-away the
anti-Nagle, Nagle is defined by the send() being smaller than the MSS, so if the
MSS is smaller, it isn't anti-Nagle :)
Further blue-skying...
If SACK were also enabled, it would seem that only loss of the last segment in
the "thin train" would be an issue? Presumably, the thin stream receiver would
be in a position to detect this, perhaps with an application-level timeout.
Whether then it would suffice to allow the receiving app to make a setsockopt()
call to force an extra ACK or two I'm not sure. Perhaps if the thin-stream had
a semi-aggressive "heartbeat" going...
But it does seem that it should be possible to deal with this sort of thing
without having to make wholesale changes to TCP's RTO policies and whatnot?
rick jones
Rick Jones wrote:
apetlund@simula.no wrote:
quoted
quoted
Just how thin can a thin stream be when a thin stream is found thin?
(to the cadence of "How much wood could a woodchuck chuck if a
woodchuck could chuck wood?")
quoted
quoted
Does a stream get so thin that a user's send could not be split into
four,
sub-MSS TCP segments?
That was a nifty idea: Anti-Nagle the segments to be able to trigger fast
retransmissions. I think it is possible.
Besides using more resources on each send, this scheme will introduce the
need to delay parts of the segment, which is undesirable for
time-dependent applications (the intended target of the mechanisms).
I think it would be fun to implement and play around with such a
mechanism
to see the effects.
Indeed, it does feel a bit "anti-nagle" but at the same time, these thin
streams are supposed to be quite rare right? I mean we have survived 20
odd years of congestion control and fast retransmission without it being
a big issue.
They are also supposed to not have terribly high bandwidth requirements
yes? Suppose that instead of an explicit "I promise to be thin"
setsockopt(), they instead set a Very Small (tm) in today's thinking
socket buffer size and the stack then picks the MSS to be no more than
1/4 that size? Or for that matter, assuming the permissions are
acceptable, the thin application makes a setsockopt(TCP_MAXSEG) call
such that the actual MSS is small enough to allow the send()'s to be
four (or more) segments. And, if one wants to spin-away the anti-Nagle,
Nagle is defined by the send() being smaller than the MSS, so if the MSS
is smaller, it isn't anti-Nagle :)
This is not a new idea. Folks used to set the MSS really low for M$
Windows, so that their short little packets went over dialup links more
quickly and they saw a little bit more of their graphic as it crawled to
the screen. Even though it was actually slower in total time, it "felt"
faster because of the continuing visual feedback. It depended upon VJ
Header Prediction to keep the overhead down for the link.
These are/were called "TCP mice", and the result was routers and servers
being nibbled by mice. Not pleasant.
Further blue-skying...
If SACK were also enabled, it would seem that only loss of the last
segment in the "thin train" would be an issue? Presumably, the thin
stream receiver would be in a position to detect this, perhaps with an
application-level timeout. Whether then it would suffice to allow the
receiving app to make a setsockopt() call to force an extra ACK or two
I'm not sure. Perhaps if the thin-stream had a semi-aggressive
"heartbeat" going...
Heartbeats are the usual solution for gaming. Handles a host of
issues, including detection of clients that have become unreachable.
(No, these are not the same as TCP keep-alives.)
Beside my code in the field and widespread discussion, I know that Paul
Francis had several related papers a decade or so ago. My memory is that
younger game coders weren't particularly avid readers....
But it does seem that it should be possible to deal with this sort of
thing without having to make wholesale changes to TCP's RTO policies and
whatnot?
Yep.
William Allen Simpson wrote:
quoted
Further blue-skying...
If SACK were also enabled, it would seem that only loss of the last
segment in the "thin train" would be an issue? Presumably, the thin
stream receiver would be in a position to detect this, perhaps with an
application-level timeout. Whether then it would suffice to allow the
receiving app to make a setsockopt() call to force an extra ACK or two
I'm not sure. Perhaps if the thin-stream had a semi-aggressive
"heartbeat" going...
Heartbeats are the usual solution for gaming. Handles a host of
issues, including detection of clients that have become unreachable.
(No, these are not the same as TCP keep-alives.)
Beside my code in the field and widespread discussion, I know that Paul
Francis had several related papers a decade or so ago. My memory is that
younger game coders weren't particularly avid readers....
quoted
But it does seem that it should be possible to deal with this sort of
thing without having to make wholesale changes to TCP's RTO policies
and whatnot?
Yep.
We recognise the possibility of increasing the aggressiveness of application
send rate in order to counteract the effect of thin streams on retransmission
latency. Applications are by nature uninformed about the state of the layers
below. To work around the fast-retransmit latency problems, an application
would have to keep a very aggressive heartbeat rate even though there is no
data to send, thus spamming the network with unneeded traffic.
To exemplify this, let's choose an SSH session from this set of statistics:
http://folk.uio.no/apetlund/lktmp/thin_apps_table.pdf. This thin stream has
an averge packet interarrival time of 323ms. The application developer would
have to consider how many "duds" to send in order to ensure a low
retransmission latency. Let's say he considers RTTs lower than 60ms harmless,
he would need to send more than 4 packets per 60ms. This would mean a
heartbeat rate of one packet each 15ms. Considering this, the aggressively
heartbeated application would send 67 packets per second compared to 3 in
the original stream.
By including thin-stream semantics into the TCP code, informed decisions
can be made to minimise the overhead while still reducing the retransmission
latency.
Best regards,
Andreas