It has already been suggested that one can use appropriate
FEC and retransmit schemes to design a link layer that may
work well with TCP.
Here are a couple of other ideas that may make sense in
certain cases.
The premise here is that, on slow wireless links, the end-to-end
RTT is largely spent on the wireless link. Therefore, when
the wireless link retransmits a packet (due to errors), the
time required to deliver the packet exceeds TCP RTO,
which times-out the TCP sender, causing bad things.
(A recent paper by Reiner Ludwig seems to suggest
that this premise may not be correct, although I am not
convinced of that yet ...)
There are two ways to work around the problem that have not
quite been explored yet:
(i) Tweak wireless link layer so that the end-to-end RTT would
not change despite retransmissions. Purely a link layer
change.
(ii) Tweak RTO calculations so that the TCP sender would not
timeout despite link-level retransmits. No changes to
link layer. Purely a TCP change.
Some thoughts on each approach follow.
Reducing RTT variability despite link-level retransmissions
-----------------------------------------------------------
In short, the idea here is that on the wireless hop, a given
packet would be delivered X duration after it is first
transmitted on the wireless link, with upto K link-level
retransmits -- the duration X should be large enough to
allow up to K retransmissions to take place in that interval.
For instance, for K=1, X will approximately need to be
2 round-trips on the wireless link when using stop-and-go.
Clearly, some packets would not need to be retransmitted.
Such packets would have to be delayed by the wireless receiver
(at link layer), before they are delivered to the upper layers.
To the sender, this would simply appear as a pipe with a
(much) longer delay.
The disadvantage of this approach is that there is
greater latency in packet
delivery. Latency may not be the major issue in bulk data
transfer, but would certainly be troublesome for interactive
applications. Thus, the above policy could be used on a per-packet
basis using the TOS bits (as has been suggested in other contexts).
An advantage of this approach is that with up to K retransmissions,
the end-to-end RTT is unaffected. So the TCP sender should not
notice them.
Another advantage is that each link can be implemented independently.
Link layer delays need to be know only at the link layer to
implement this.
For bulk transfers, this approach should benefit performance.
I should be able to say how much after some simulations in the
near future. (In a similar approach, some variability can be
added to the link level RTT so as to inflate TCP rttvar_.)
Tweaking RTO Calculations
-------------------------
This is harder, and I do not know what may work well.
But here are some initial thoughts ...
What is worth considering is a RTO calculation scheme that behaves
differently (than current calculations) when used on slow links,
and works as usual on fast links.
For instance, the current RTO is srtt + 4 rttvar.
This could be replaced by
RTO = max (srtt + 4rttvar , srtt + K*TX_bottleneck)
TX_bottleneck is the transmission time on the bottleneck link,
which would be the wireless link in our scenario.
The above expression reduces to standard calculations when
TX_wireless is
small. But when TX_wireless is dominant fraction of end-to-end
RTT, the above RTO allows for K retransmits. (One could
potentially add 2*rttvar to the second term above to account
for other delay variations.)
The net effect of the above expression is to inflate RTO when
going over slow links, which could be a problem when congestion
losses occur (since timeouts would be delayed).
This could potentially be tackled by triggering fast retransmits
on the first dupack when using small windows (early fast retransmit
has also been suggested by other people in somewhat different
context).
By the way, the ideas above could be applied to any delay
variability, not just due to retransmissions.
Criticism welcome ...
- nitin
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:20 EST