Re: [Ieprep] Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]