Dan,
> The hope is that there is research that can address the error problem in
> future TCP mechanisms or versions. There are sections in the research
> draft that are meant to address these issues and we have been actively
> soliciting contributions to the draft. I hope that you or Eric can help.
I don't have a copy of Adrian's message, but I get the gist of what
you are responding to...
The problem with *depending* on FEC is that it's a tattered safety
blanket. The current approach to treating the satellite environment
as a long-fibre is (in my opinion) overly optimistic, but that is
old news to many on this list :o(
You use the tools you've got now (which are more window-oriented
than anything else) and build upon that. It's the "build upon that"
piece of the puzzle that gets lost; I remember reading a "what are
we here for/what's the purpose of this group" thread in Mark's
(very useful) mailing-list archive - I think the points are related...
Anyway, there are things that can be done IN CONJUNCTION with FEC
to reduce the impacts. Some are research - and most certainly get
you something that can no longer be classified as TCP, others
require no changes to TCP but add fuzziness with regard to the
end-to-end argument (maybe!) or fall into the spoofing category.
The latter will be addressed (probably in a separate I-D) with
other spoofing/gateway topics.
With regards to the current standard-mechanisms draft, we can
go over specifics in LA (before, during or after) the TCPSAT
session. I'm looking forward to the opportunity, actually.
(Pulling Mark's latest mailing-list archive now to see what else
I missed :o( )
Regards,
Eric
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:37 EST