Re: [Ieprep] proposed charter

[Rex Buddenberg <[e-mail]>]

Curtis,

You have stepped on a very important point:

> ETS == voice  ?  That was the question.

The tacit assumptions of many is that this is true.  But it is not now,
and increasingly will not be.

The Marines in Iraq are today using the same network* for voice and for
tactical data.  In the case that was relayed to me recently, 'tactical
data' meant the position report of an IED (roadside bomb) that showed up
on the plot of a deployed patrol.  The data is 'elastic' in the sense
that you used it -- as long as it shows up in time for the patrol
commander to reach properly, that's good enough.  In this particular
case that's exactly what happened; the patrol reacted by changing its
route.  




*right now a good share is two parallel networks.  But the backbone is
increasingly VOIP sharing with other ports over a single backbone, ...
and that's progressing down the food chain.  The obvious payoff is
breaking the one-app == one-radio stovepiping.  


On Wed, 2006-09-27 at 14:44 -0400, Curtis Villamizar wrote:
> In message <[e-mail]>
> "James M. Polk" writes:
> >  
> > At 06:02 PM 9/26/2006 -0400, Curtis Villamizar wrote:
> >  
> > >In message <[e-mail]>
> > >Fred Baker writes:
> > > >
> > > > or whether drop priority even makes sense operationally, which it
> > > > doesn't.
> > > >
> > > > On Sep 26, 2006, at 4:22 AM, Curtis Villamizar wrote:
> > > >
> > > > > For example, it is important
> > > > > to know how many priority/preemption values there will be and whether
> > > > > each priority requires three drop preferences as required by an AF
> > > > > service.
> > >
> > >
> > >Fred,
> > >
> > >For PSTN voice it doesn't but for elastic real time or elastic bulk
> > >transfer it might.  What you are saying is that AF doesn't make sense.
> >  
> > For voice?
> 
> 
> ETS == voice  ?  That was the question.
> 
> We already know that in general: voice != AF
> 
> Just confirming that Fred considers ETS to be voice only - at least
> for now.  btw - I think that is a valid assumption - at least for now.
> 
> 
> > >Maybe it doesn't but if so the diffserv WG wasted a lot of time.
> >  
> > Have you looked at who wrote 2597?
> 
> 
> If (ETS == voice) then restricting ETS to EF is not an issue.  See
> next sentence quoted below.
> 
> If ETS can also be elastic traffic of the type that was intended for
> AF but we have declared AF to be not useful for ETS, then it implies
> that AF is not useful.  That's all I was try to imply, nothing more.
> 
> Personally I think AF is useful that is why I wanted confirmation that
> Fred is assuming that ETS is voice only.
> 
> > >Either that or maybe ETS will never be anything but voice traffic.
> 
> 
> We should be clear about assumptions.  You and Fred seem to be
> assuming that ETS == voice, but also seem to be reluctant to say that.
> 
> Here are some of my assumptions.  We need to walk first, then run.
> The IETF should not assign DSCP codepoints for everyones pet idea.
> For now ETS is assumed to be voice.  EF is fine for voice.  A new
> codepoint allows traffic to be universally identified as being ETS
> related.  That might be good or bad.  ETS may later carry more than
> just voice.  If needed the decision to use one codepoint can be
> revisited.  There has never been anything stopping a deployment in
> which an experimental set of DSCP code points are used, EF-like,
> AF-like, or something else.  There is nothing to prevent a ETS
> deployment from using the existing AF codepoints.  If the use of
> experimental codepoints proves useful, additional ETS codepoints can
> be added later.
> 
> Curtis
> 
> _______________________________________________
> Ieprep mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ieprep


_______________________________________________
Ieprep mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ieprep