Re: Satellites running IP

[Daniel Shell <[e-mail]>]

Eric

So the answer is no.

Sorry for the short reply but I am on vacation will get you a more detailed
answer later




At 11:58 AM 6/18/2002, Eric Travis wrote:
>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

Dan Shell
Network Architect
CISCO Systems
Gobal Defense and Space Group
Wireless/Mobile Networking/ Satellite
216 643 2422