Tim,
: [ Note: I composed this last week in response to Adrian Hooke's
: message, but for some reason did not send it. I'm sending it now,
: but it may be a little out of date given what's been discussed on the
: list since last week. -Tim ]
Since you were able to anticipate much of the traffic that followed, it
is clear that you have your finger on the pulse of these issues. I really
wish that you had raised these concerns before (or even during) the
Tuesday Working Group meeting so they could have been addressed there.
>From the discussions at Tuesday's meeting, it was clear that the concerns
voiced by Adrian were valid and shared by others in the group.
: The goal of the WG in the IETF should not be to craft how TCP can be
: optimized for communication that goes over a satellite. The goal
: should be to craft what TCP should be for the Internet as a whole
: (including satellites). The charter of the existing WG is to document
: things as they are today. It was unfortunate that the WG was named
: "TCP over Satellite" or just "TCPSAT", for that has caused much
: confusion about what this group should be about.
: "TCP over a more heterogeneous Internet" would have been a better name
: for the WG.
I think that the working group title is certainly consistent with its
charter and the original goals of this short-lived working group. Some
people realized a little later in the game (or just didn't voice this
opinion earlier than now) how these issues have a much wider applicability
than to just satellite links. Nevertheless, we were fortunate to be given
the opportunity to discuss the problem space within the IETF.
I don't detect any of the confusion you mention from any of the traffic
that I've read.
Everything that has been discussed to date can mapped to into the
characteristics of other "heterogeneous Internet" elements (including
wireless/mobile, cable-modems or terrestrial radio systems). Nobody has
been arguing for a "satellite only" solution - or even a solution which
unfairly benefits satellite links over other links. If anything, the
desire has been expressed to find ways of correcting the inherent
unfairness involved. This can not be done in a vacuum.
There are a lot of concepts/problems that people have latched on to over
the past couple of weeks that have been on the table for well over a year
now - it's unfortunate that it took until now for them to be addressed
with so much energy, as the working group is winding down. Everything
evolves at its own pace.
You mention that "the charter of the existing WG is to document things as
they are today"; I agree and assert that the discussion following Adrian's
message is right on target.
The only thing in the whole discussion that can really the subject of
disagreement is whether or not *future* satellite systems will have links
which are ALWAYS of fiber quality. There is no arguing with what the
characteristics of legacy systems. As for future systems, Craig has said
before that the industry representatives that he talked to said their
GOAL was to have fiber quality links. Nobody is questioning that
statement - whether that goal is going to be achievable or not, however,
remains to be seen. What we have heard over the past two weeks however,
are concerns from people in the field as to whether or not this goal
should be treated as a given quantity. I'll admit the discussion is taking
place a little late in the game, but that doesn't make it any less
appropriate.
This mailing list holds two official capacities (the TIA-SCD-CIS-Internet
Protocols Working Group, the IETF TCPSAT Working Group) and an unofficial
status as the belly-button of people dealing with TCP performance issues
when operating over satellite links. If this list is the *wrong* place
to discuss these things, then I'll be happy to set up a mailing list
chartered to do just that.
You are correct that engineering of candidate solutions to the problems
exhibited by emerging environments doesn't fit within the charter of any
existing IETF WG; this is precisely why we are looking into holding a
workshop where interested parties can get together and begin to build
synergy. If we are able to evolve promising solutions that are appropriate
for the IETF process, we should bring them into IETF at that point.
I think everyone will agree that the overall goal is to engineer stable
solutions which benefit the Internet as a whole, not to address isolated
communities using non-standard practices and protocols. To do this, the
heterogeneous elements of the Internet need to be handled transparently
at some level - ideally below the application/user level.
The point of Adrian's message seemed to be that this goal was NOT being
accomplished because important environmental and operational aspects were
being ignored. The solution being promoted requires knowledge not
generally available to both ends of a connection and hand-tuning
regardless. A "heterogeneous Internet" is one that has a variance of
characteristics.
The goal of this group is NOT optimization of a variant of TCP for
satellites at the expense of everything else - it is:
The TCP over Satellite Working Group shall produce an informational
RFC which describes the issues affecting TCP throughput over satellite
links. It identifies the domains in which each issue applies, including
including network topology, satellite orbit (LEO, MEO, GEO), and link
rates; fixes, both protocol and implementation, that ameliorate reduced
throughput; and areas for further research. The purpose of including
this information is to direct the research community to the areas in
which show promise, not to perform the research or even advocate the
results.
This is a documentation only effort - we are not chartered to suggest any
changes in TCP itself; It is within our charter to suggest engineering
solutions to address problems in the short-term. The ultimate solution
needs to be an end-to-end solution, but because of the logistics of a
ubiquitous transition (even if we had agreement on the right solution)
will be years away.
This being the case, I fail to see what part of Adrian's message (and the
resulting discussion) violates the Working Group's charter.
: Whatever the WG recommends, it should be a recommendation that people
: can take to all the large vendors of TCP implementations (you know who
: they are) and tell them *these* features should be included in all
: TCPs that you ship and should be turned on by default.
Absolutely not - this is a sure way to prevent the working group from
gaining closure on the current documents. I can not support such a
recommendation even, in an informational document and I'm sure that I'm
not alone.
There are plenty of environments where the enabling of TCP options by
default is not a good idea. While timestamps are generally useful, for
environments with relatively small useful, bandwidth-delay products (such
as in a dialup connection) they simply eat bandwidth. Sure, both of us are
capable of disabling something like timestamps if they are not necessary,
but I'm not sure my mother is or even wants to be bothered with it.
Further, not all currently deployed TCP implementations properly handle
options they don't understand; since I can not make everyone on the
Internet upgrade their old and broken protocol stacks, why should we
advocate people risking bad TCP interactions unnecessarily?
My recommendation would be to add the appropriate caveats to the "Standard
Mechanisms" document to allow that to smoothly reach consensus prior to
August. I'm writing up what I hope will be suitable words right now. The
important thing is not to delay the progress of the TCPSAT WG.
: (The computers at the endpoints of a connection and those who manage
: them should not be expected to have to know whether or not the packets
: between them are going over a satellite link.) Asking users at the end
: points to tweak knobs to tune their performance is not acceptable.
This statement seems to agree with Adrian's second concern. I certainly
agree with the inappropriateness of solutions that require "hand-tuning",
I have been all along - I'm glad that it is now getting more widespread
discussion.
: If your goal is to make use of the TCP/IP technology within a system
: in which you control all the pieces, then you can do what you want and
: hack your TCP however you want. But then exactly how that should be
: done should be (IMHO) outside of the scope of the IETF (and this WG).
I'm not sure where this is coming from - if any of us had that goal, we
wouldn't be participating in the IETF; the whole purpose of this effort is
seamless integration of satellites into a global network infrastructure.
I think that this is within the scope of the IETF (and this WG) as it has
the potential to impact the Internet as a whole. Are you mapping the use
of proxies into "a system where you control all the pieces"? Are you
suggesting that anything that might address the problems exhibited when
one or more satellite links are in a path is not going to be relevant
for use in Internet as a whole?
: (Also note that if IPSEC becomes popular, the TCP headers will be
: hidden behind end-to-end encryption, and there will be no opportunity
: to muck with them in the middle of the net.)
Ultimately an end-to-end solution is required, that will take time to
develop and prove stable for widespread deployment. In the meantime,
people have a "heterogeneous Internet" already exists and problems caused
by asymmetry, long-delays, large windows and mixed losses are already
being experienced. This is why people are spoofing and why an IPSEC
friendly way of addressing performance problems needs to be formulated.
If the implication of your message is that people connecting over any
media whose characteristics different than the technologies making up the
Internet backbone are rightfully "out of luck" with respect to performance
and will remain so - then I have to disagree. Widespread adoption of such
a position would no doubt suppress innovation and interest in technologies
like satellites - something which is orthogonal to the goals of almost
everyone reading this list.
We're almost at the end of our journey in this WG, let's hang together
till it finishes.
If I misunderstood your message (or even it's intent) then you have my
humble apologies.
Eric
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:39 EST