Fred,
Fred Baker wrote:
On Nov 14, 2006, at 8:36 AM, Brian E Carpenter wrote:
2. The notion that solutions such as precedence and preemption are
(a) requirements and (b) applicable to all applications just doesn't
compute for me.
They don't especially compute for me in the sense that the terms are
used in the PSTN service; the Internet isn't the PSTN, and many of its
applications operate in a very different sphere.
That's exactly why I disagree with Sam - I think that writing up
these functional requirements in a way that relates technically to
how the Internet works can be done best in the IETF. I do believe
the charter needs more work to make it clear to newcomers that this
is the job to be done. Probably, there are too many words in the
draft charter, not too few.
Brian
That said, I among
many others have worked with DoD to come up with something that
actually does work in their environment. Basically, a PSTN-like service
makes sense for applications that are PSTN-like, which would include
voice, video, and certain kinds of sensor traffic. For elastic traffic,
the point as elaborated by Col Tim Gibsen, then of DARPA, is that there
are times when a file transfer or other transaction are mission
critical in a certain sense and all other traffic is secondary, and
there are certain communications that either are emails or are
structurally similar to email (delay- tolerant store and forward
messaging service) that none-the-less have to be delivered within a
stated interval of time to a stated set of recipients. For these, the
current NCID specified a traffic class that guarantees some amount of
bandwidth to preferred traffic in a work-conserving manner (eg, the
bandwidth is available to other traffic classes when not in use by its
target traffic), and I think there are some application layer things to
do as I mentioned in an email earlier in this thread.
Voice and video are, IMHO, largely a done deal, between RFC 4542, RFC
4594, draft-baker-tsvwg-admitted-voice-dscp, and draft-ietf-tsvwg-
diffserv-class-aggr. Francois has been working on related documents for
the MPLS part of the network.
"Another traffic class" for elastic traffic requires no further
specification - this is well known and proven technology, diffserv.
Delay-sensitive email mail does IMHO require further analysis, and some
in this thread have suggested that it should be a different protocol.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf