Phil,
:>I've been approached by folks in the wireless/mobile areas who would
like
:>to get similar mind-share for end-to-end solutions, but who are afraid
:>they will be told their environment is too "crappy" and that they should
:>clean it up.
:
:Speaking as a wireless person, I actually *agree* that many radio
:environments are "crappy" and should be cleaned up without hacking
:TCP.
I suppose my wording was poorly chosen and led you to believe that
the concerns I was relating were limited to noisy channels; perhaps
I should have chosen a less controversial "emerging" environment...
For the folks to which I was referring, packet errors are but one
component of a "crappy" environment; Other elements are things like
asymmetry, fairly significant variance in delays (due to a number of
environmental factors, link protocol activities and other design choices)
and intermittent/changing connectivity. This is not an exhaustive list,
but the above map easily into non-wireless/mobile environments - the
point of this whole exchange.
To these folks, "cleaning up the environment" means insulating protocols
above the link layer from *all* these effects (making it look just like
a wire in ALL respects). Failing this so far, they are concerned that the
Internet community is going to dismiss them as an unworthy or irrelevant
fringe element. Modern TCPs have a fair number of implicit assumptions
regarding the characteristics of the network. I don't know whether or not
you agree on the validity of their concerns, but it wasn't my intent to
start a debate on a single technology/community (or aspect thereof).
The wireless/mobile people saw that the major "products" of the TCPSAT WG
was the cultivating of a much wider awareness of the satellite environment
by the larger Internet community and getting the folks who know the
protocols together with the people who know the underlying technology and
environmental constraints. Judging this be a very positive thing for
everyone involved, they feel similar exposure would have the same
widespread benefits.
The point of all this is that there are a number of different "emerging"
environments that exhibit rough-edges with regarding TCP. The intersection
of this problem set (which is not limited to large-windows) is probably
worthy of joint examination (and possible engineering) by members of all
relevant communities. We've got IP over everything, we're seeing that this
leads to some unexpected things related to TCP.
Regards,
Eric
Note for the record:
I don't think there is anyone seriously considering proposal of
anything related to mixed-loss environments that:
1) attempts to signal the experiencing of *individual* errors
experienced
or
2) attempting to infer corruption versus congestion from loss
patterns.
These are (in my opinion) simply unworkable.
What CAN be detected (and signaled) are delimited *periods* of
link difficulties. This can be a link-outage (i.e., you've lost
a link-lock, are hunting in the noise to resync after a deep
enough fade, had a hand-off, etc.) or detection of a significant
fade on the channel. FEC may get you a pristine channel in some
environments if you can pay the appropriate price - but that price
can also mean that you lose access to the channel for periods of time.
The detection and recovery of link problems *is* in the realm of the
link protocol, but unless you get a clue to the transport protocol's
state-machinery, you run the risk of triggering false congestion
responses. These congestion-responses will impose further (unnecessary)
performance degradation during periods when the path bottleneck is not
congested.
Making the extra information on link (un)availability to the transport
protocol *can* improve things.
This does not "burden TCP" with link layer problems, it merely allows
the signaling of additional advisory information about the network to
the transport protocol.
It wasn't my desire to rehash the noisy link debate here.
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:39 EST