Is it okay to start the PROBE0 timer alltough:
- no data is pending
There is nothing to probe for, so implementations do typically not do
so.
Another point to always keep in mind is that the retransmit and probe0
timers are mutually exclusive. In fact the BSD networking panics if
it detects that both are active at the same time.
- the receiver has advertised a small but non zero window ?
In my previous email I outline the mechanism which deals with lost
acks when non-zero windows are known. The retransmit timer at the
sender.
It will push at a minimum, one data packet out, and in doing so it
will fragment the packet to get it to fit into the allowed constrained
space (here the receivers window). (the one case where the retransmit
timer cannot legitimately send out a packet, is when there is a zero
window, and in that case the probe0 timer should be active, not the
retransmit timer).
Is it okay that tcp_send_probe0() does always reset the PROBE0 timer
allthough tcp_write_wakeup() might already have started the retrans
timer?
As stated previously, retrans and probe0 timers should be mutually
exclusive. At least, this is the intention. Note that all code
paths which re-enable the retransmit timer are in a place where
they are sending a packet _and_ this implies that a non-zero window is
known (else you shouldn't be sending anything :-)
I believe we follow this rule everywhere in the stack, but we could
miss a case somewhere, who knows.
I hope this clarifies things.
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/