Daniel Shell wrote:
>
> Is SCPS an IETF RFC on a standards track yet?
>
> Dan Shell
> Network Architect
> CISCO Systems
> Gobal Defense and Space Group
> Wireless/Mobile Networking/ Satellite
> 216 643 2422
Hi Dan,
How are things going at Glenn?
I'm confused by what you are asking but you've been
affiliated with NASA/Glenn and familiarity with SCPS
goes back long enough for me to remind you (sadly, not
for the first time):
SCPS is NOT a protocol, but it is a set of
recommendations covering four protocol layers
(or 3.5 if you consider security a sublayer).
Lots of things in the SCPS recommendations are
covered by IETF RFCs that are standards or standards
track - those things include such obscure things as
IP, TCP, UDP, ICMP, etc.
You knew all that, however.
If you are specifically asking whether the enhancements
that contribute to TCP Tranquility are covered by an IETF
RFC (Standard, Standards Track, Experimental, etc.) - then
the answer is:
Nope - nobody every claimed they were, and
nobody in known space loses any sleep over it.
But:
The SCPS options have valid IANA assignments
(Options 20-23) and the protocol 106 covers
operation when using the SCPS compressed TCP
headers.
As an aside:
I happen to pass lots of traffic onto the Internet
using TCP-Tranquility and I'm at least as nice as
every other TCP flow that I observe.
Had NASA (or any other Space agency) expressed
a non niche interest (backed with the commitment
of necessary resources) in deploying any Internet
derived technologies over the space link and
beyond, the TCP modifications probably would have
been submitted as IDs with the desirement/goal of
having them someday make Experimental RFCs[*];
[*] If I remember correctly, you folks at GRC
stated several times that you were going to
take elements of the SCPS recommendations
into IETF as part of the ACTS 118X (or Next?)
activities - maybe I should be asking you
your question - eh? :o)
As it stands, the question needs to be answered:
Why waste the IETF's time and meeting space on such
a insignificant problem space (no pun desired) that
even the mission folk at the space agencies don't
realm consider more than research?
Does everything need to be covered by an IETF Standard?
As I've said many time before (to you and others):
for a terrestrial environment, the elements of the
TCP-Tranquility feature set are experimental and tailored
primarily for the space environment (but work well in any
lossy tetherless network):
Pure Rate Pacing is only useful for reserved paths
Selective Negative Acknowledgements are best for
environments far more lossy than should be on any
end-to-end path going over the Internet backbone.
The Vegas modifications seem to work well in general
but there still *may* be some nasty edge conditions
in networks that would not be typical to the space
environment.
Any bandwidth estimation techniques are
likely to be burdened by the same concerns.
Separating congestion signaling from loss:
We've never advocated running a default loss assumption
other than congestion for anything sharing an end-to-end
path with a public network (that may have different
assumptions and not the necessary machinery to explicitly
signal congestion)
Explicit signaling of loss (trends)
I seem to remember some traffic polling for interest
on this topic (this mailing list or end-to-end);
This is somewhat of a localized issue and maybe not
something that needs an IETF standard.
Link outages are a local problem and probably not something
that requires an IETF standard.
There is more, need I continue down the list or have I made
the point?
We've never been looking to push these concepts on a wired
infrastructure, but rather have always advocated using them
in networks which interface to a wired infrastructure.
The most valuable thing that the space community (and anyone else)
gets from protocol standards are standard *interfaces* - which
include important things like header formats;
Further, standardized state machines seem to track across diverse
environments, but the behaviors not covered by those state machines
may not.
It is not clear to many of us that the protocol behaviors which are
best for operating over a diverse terrestrial network are necessarily
the best behaviors for operation over a resource constrained, time
bounded delivery infrastructure that is prevalent in most space
environments (and more than a few tetherless environments)
You've probably been dealing in networking for long enough that you
probably remember the stupid/evil days of GOSIP - right?
Please don't depress me and claim that everything used in a space
environment needs to be blessed as an IETF Standard (or Standards
track) RFC?
Do you think the behavior of all the traffic that you are seeing on
your networks is strictly covered by (and conforming to) IETF Standards?
Faith in guiding principles *can* lead to many wonderful things,
Dogma *always* leads to disaster, grief and collateral damage...
Now - what was your question again?
Eric
This archive was generated by hypermail 2b29 : Tue Jun 18 2002 - 12:04:13 EDT