One topic that I think we need to keep in mind as we talk about how smart or
stupid TCP is about link-layer corruption is that we need to have solutions
that work in non-trivial network topologies.
When we talk about TCP "knowing" about link-level characteristics, like
"knowing" that radio signal strength has fallen below a usable level,
(ignoring whether we SHOULD do this) we CAN easily tell the TCP on a mobile
wireless device that this has happened, but it is much more difficult to
imagine telling the TCP on the far-end device, five hops into the network,
that the same thing has happened. Such a notification is subject to all the
latency of TCP-level feedback - end-to-end IS end-to-end, and no miracles
occur.
If most end-user applications were peer-to-peer, these issues could be
considered separately, but because our applications are so intensely
client-server, if we aren't transmitting in one direction, we won't be
transmitting in the other direction very much or very often.
The alternative, using a Performance-Enhancing Proxy to "split" the TCP
connection at the border of the wireless and wireline networks, does allow
both wireless-interface TCPs to get link-level notifications directly - but
we understand a lot less about the impact of split-TCP operation on
end-to-end throughput than we do about end-to-end TCP.
IMHO, of course.
Spencer
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:20 EST