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

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
[email protected]
https://www1.ietf.org/mailman/listinfo/ietf