RE: Re: WG Review: Recharter of Internet EmergencyPreparedness (ieprep)

We do not need a different PHB,   but a separate EF code point

-----Original Message-----
From: Fred Baker [mailto:[email protected]]=20
Sent: Tuesday, November 14, 2006 3:02 PM
To: Brian E Carpenter
Cc: Robert G. Cole; Pekka Savola; [email protected]; Kimberly King; Scott
Bradner; Sam Hartman; [email protected]
Subject: Re: [Ieprep] Re: WG Review: Recharter of Internet
EmergencyPreparedness (ieprep)

On Nov 14, 2006, at 8:36 AM, Brian E Carpenter wrote:
> 2. The notion that solutions such as precedence and preemption are =20
> (a) requirements and (b) applicable to all applications just =20
> doesn't compute for me.

They don't especially compute for me in the sense that the terms are =20
used in the PSTN service; the Internet isn't the PSTN, and many of =20
its applications operate in a very different sphere. That said, I =20
among many others have worked with DoD to come up with something that =20
actually does work in their environment. Basically, a PSTN-like =20
service makes sense for applications that are PSTN-like, which would =20
include voice, video, and certain kinds of sensor traffic. For =20
elastic traffic, the point as elaborated by Col Tim Gibsen, then of =20
DARPA, is that there are times when a file transfer or other =20
transaction are mission critical in a certain sense and all other =20
traffic is secondary, and there are certain communications that =20
either are emails or are structurally similar to email (delay-=20
tolerant store and forward messaging service) that none-the-less have =20
to be delivered within a stated interval of time to a stated set of =20
recipients. For these, the current NCID specified a traffic class =20
that guarantees some amount of bandwidth to preferred traffic in a =20
work-conserving manner (eg, the bandwidth is available to other =20
traffic classes when not in use by its target traffic), and I think =20
there are some application layer things to do as I mentioned in an =20
email earlier in this thread.

Voice and video are, IMHO, largely a done deal, between RFC 4542, RFC =20
4594, draft-baker-tsvwg-admitted-voice-dscp, and draft-ietf-tsvwg-=20
diffserv-class-aggr. Francois has been working on related documents =20
for the MPLS part of the network.

"Another traffic class" for elastic traffic requires no further =20
specification - this is well known and proven technology, diffserv. =20
Delay-sensitive email mail does IMHO require further analysis, and =20
some in this thread have suggested that it should be a different =20
protocol.

_______________________________________________
Ieprep mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ieprep