In message <[email protected]>, "Adrian J. Hook
e" writes:
>The TCP solutions for satellite applications that have so far been proposed
>by the group appear to be solely focused on the delay problem, i.e., they
>treat satellites as "long-delay fibers". Furthermore, they seem to require
>that the end user has a-priori knowledge of the precise end-to-end
>transmission path, and in particular the detailed characteristics of the
>space channel. My first concern, therefore, is that any dialog which
>requires the user to tune the communications parameters is hardly "seamless".
I believe the need to tune is going to go away for some problems shortly --
there's some interesting work in the pipe.
>Instead of pushing the problem off to the global end-user community,
>wouldn't a better solution be to handle the problem locally - where it
>occurs, i.e., over the satellite link - via a transparent gateway approach
>(at least in the near term)?
My concern is that all the "transparent" approaches I've seen are actually
"opaque" in certain key situations -- in short, they add failure modes.
>My second concern is that the error-prone nature of space channels is being
>glossed over by the assertion that you can simply "FEC the problem away".
Allow me to grumble a bit here. I'm part of a team funded by NASA to
work on TCP over satellite issues. We went to a variety of industry meetings
and talked about handling error rate issues and were told, point blank, by
industry reps that the satellite community thought that was a waste of time
because their (near-term) goal was to make satellite error rates consistent
with fiber.
Craig
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:37 EST