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
This archive was generated by hypermail 2b29 : Wed Jun 19 2002 - 08:53:10 EDT