John,
: What I really wanted to offer up, though, is an observation. The
: product I work with is mainly used to implement private networks. But,
: I think this observation is going to eventually carry over into the
: Internet. What we are finding is that our customers are starting to
: do a lot of stuff on top of UDP in order to get around perceived limits
: of TCP. They simply implement their own error recovery, etc. on top of
: UDP. (Also, I know of at least one product (not ours) which implements
: TCP spoofing by converting it to UDP over the WAN.) Using UDP totally
: bypasses TCP congestion control. This is not so bad with a private
: network where other methods of congestion control can be implemented.
: But, if this does start showing up in the Internet, it might cause a lot
: of problems. I guess I am just offering this up as another reason
: why we need to solve some of the perceived TCP problems related to long
: delay paths...
I also encounter, on a regular basis, folks that seriously consider
UDP-based approaches. For me, this is currently within a NASA domain
(but not all of NASA will agree with my position on this), but it was
also a regular thing with DoD and commercial sponsors too.
It is a "solution" that should be addressed, if for no other reason
than to spell out it's pitfalls prior to someone going down that path.
(Not to knock anyone's commercial solutions, but...):
- You need to recreate TCP mechanisms in a new protocol
encapsulated by UDP; Reinventing the wheel can be
time-consuming and difficult to debug and tune and must
be maintained. This translates to $$$
- Standards would be nice - my folks are trying to realize
cost savings by going with industry standards whenever
possible. Proprietary products tend to lock you into a vendor
and do little for costs.
- You need to play well with other TCP traffic sharing
bottleneck resources (even in private networks); This
means implementing some sort of congestion-control.
Even without shared paths, you at least need end-to-end
flow-control and rate control (to prevent you from dumping
data on the floor at your own interfaces).
- You are going to be doing this in user-space, so if you've
got BIG pipes (> 10Mbps) you're going to start having problems
depending on your implementation. You've got more copying
going on then you'd like in user-space and pushing data across
to kernel-space.
- You're not going to be using "off-the-shelf" applications
without localized spoofing and i/o redirection.
I've got to point out that the people considering these approaches are
often well aware of (and have tried) the documented "fixes" - large
windows and time-stamps and still can not satisfy their requirements.
SACK is a new (and useful) wrinkle, but it doesn't change the bottom
line for these folks.
Such a discussion really doesn't fit in the "use RFC-1323/2018" draft,
but probably should be in the other draft labeled as a *bad* "research"
idea.
[Heresy Mode On]
I'll probably upset a good cross-section of the people on this list, so
I apologize in advance.
RFC 1323 is a great point solution if all your problems are traceable
to (or can be reduced to) large windows - but even when you can
effectively use it (knowing and coordinating the correct magic numbers),
it still does nothing for folks who need to worry about the efficiency of
resource utilization;
Hand tuning is not a generally acceptable solution for the real-world. It
should not be billed as all anyone will ever need. (The current draft
doesn't say that, but it sure implies it). I'd like to reduce the
complexity of solutions presented to my users - I'm not sure exactly how
to do that, but hand-tuning goes in the wrong direction.
We'd all prefer to be able to provide solutions to people that don't
require them to pull out calipers and a screwdriver. I want then to to the
science they are paying for as efficiently as possible and with the
minimal amount of environmental scaffolding. Ideally, this would mean that
operating in a stressed and/or long-delay environment would be as
transparent as possible to the application and user.
I don't want my users to (artificially) tailor their missions in order to
mitigate problems associated with using a particular transport protocol.
The same would apply if I were selling bandwidth or connectivity services.
I want them to realize the cost savings and interoperability provided by
using TCP; I *know* that there are other environments that have similar
problems; I'm stupid enough to believe that solving the problems for all
these environments can be done simultaneously.
Let's face it, the problems we're alluding to aren't perceived - they are
all too real. That doesn't diminish the virtues of satellites as valuable
additions to network infrastructure. Don't fear fiber, play up the
benefits of satellites (cost, relative ease of deployment and flexibility)
The problems (and their causes) need to be understood for network
architects to minimize their impacts. Someday (not in the near future)
perhaps we'll see an evolution of the protocols to address these problems,
as they are identical to that encountered in other RF-based and/or
asymmetric environments.
I really think we would be doing a great service if we began addressing
the problems facing the *user-community* rather than the bandwidth-providers.
Taking care of the users are what the bandwidth-providers exist for, so
they also benefit from such a discussion.
Again, to those whose feathers were ruffled, I apologize.
[Heresy Mode Off]
Eric
As an aside,
Spoofing becomes more difficult if/when end-to-end security (such as
IPSEC) becomes deployed. It's not impossible, just harder because it
requires coordination and trust of the spoofer.
Even in private networks, managing congestion is hard. You can either
severely restrict network activity, strictly manage network activity or
vastly over-provision you network paths. None of these are attractive to
organizations managing to cost (or who must match increases in
infrastructure costs with decreases in actual science budgets).
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:36 EST