[CAP] Presidential CAP questiion

[Rex Buddenberg]

Since we're headed in this direction (tech rather than policy) ...


On Mon, 2007-10-15 at 16:49 -0400, Nabil Seddigh wrote:
> I would agree with most of what Rex has written...except ... :)
> 
> ...to say that the issue of traffic prioritization or QoS
> (Quality of Service) mechanisms in packet or router networks
> remains a matter of debate. All the router vendors now have
> traffic prioritization capability. 

Most _routers_ do indeed support protocols like diff-serv and RSVP.  

> However, most of these
> features were not turned on for the longest time. 

For _very_ good reasons.  If just anybody can turn on, say, the
diff-serv bits (set the DSCP) then just anybody has a DOS flooding
vector.  So not only do most ISPs routers not recognize DSCPs, most
border gateways actually turn them off.  
     My previous caveat stands -- if there's no congestion, then this is
an angels-on-pinheads discussion.  

> Slowly but
> surely, as attention is focused on carrying voice/video over
> packet networks, these QoS or traffic prioritization features
> are being turned on in *some* networks.

Yes ... in order to keep the video from cluttering up the rest of the
world;-).  Actually, the application nature of the media is a very poor
determinant.  The admiral's e-mail to the President and his e-mail to
his wife look the same in the network so attempting to use port numbers
as a discriminator doesn't help ...even if things are honest.  And
implementations tend to discourage dishonesty -- how many things out
there (like Skype, to pick on just one) are using port 80?  
     
For any QoS Control features to make sense, they need to be
authentically implemented in the end system -- mark the datagrams before
they ever hit the network.  

But there's a meta issue here.  I've never seen a situation where high
availability issues didn't trump QoS ones.  You should never wrap around
axle on QoS until you've dealt with the high Ao ones.  Which is
essentially what all the core ISPs have done -- there are enough
altroutes around to drive the Ao numbers into acceptable territory --
which has the side effect of overprovisioning the system so the backbone
almost never has congestion ... stop worrying about QoS, it can't
help!!  

> 
> I would agree with Rex that as long as CAP messages are
> carried over reliable protocols (like TCP), this will likely be
> a non-issue for packet networks. However if CAP msgs are
> transmitted over UDP, QoS becomes a key requirement for
> delivering the msg reliably.

Mixed terms.  TCP is a reliable transport protocol.  It trades off a
number of qos factors in order to get bit-perfect, in-order traffic
between exactly two end systems.  But in emergency services, it's better
to look to the future and reliable multicast protocols (see NORM).  
     QoS deals properly with bandwidth efficiency, determinism, latency,
jitter, interactivity (in approx that order of importance).  But not
end-end reliability -- that's the transport protocol's job.  
     UDP is not a protocol at all, just an interface definition (you got
that part essentially right).  But diddling with the QoS control knobs
won't help it's fundamental non-reliability.  

You are, I hope, acquainted with the most important acronym in the QoS
buiness?  TANSTAFL





> 
> ---
> Best,
> 
> Nabil Seddigh
> nseddigh at solananetworks.com
> http://www.solananetworks.com
> 
> 
> > I think the question really has to do with the nature of packet
> > switching and the archaic circuit switched notion of pre-emption.  (With
> > Presidential as just one instantiation)????
> > 
> > In circuit-switched networks, a channel can carry only one application
> > at a time.  Which translates to user terms of 'gotta hang up on one
> > conversation to pick up another'.  Pre-emption is a means of forcing the
> > first conversation to close so one can barge in with the second.  In the
> > interior of the network, pre-emption is represented by a parallel 'grab
> > the circuit'.  In abstract terms, circuit switched networks are
> > connection-oriented.  
> >     
> > But in packet switched systems things change.  Packets arrive at routers
> > from multiple applications in no particular order or organization.
> > Layer 3 plumbing in the internet is expressly connectionless and
> > stateless.  Therefore, pre-empting' a connection makes no sense -- there
> > aren't any.  (*more below)
> > 
> > This doesn't translate quite as intuitively to end system applications.
> > It may make sense to interrupt one human conversation to get a
> > converser's attention.  But this has nothing to do with the underlying
> > plumbing any more. 
> > 
> > There was a working group in IETF a few years ago thrashing emergency
> > services issues.  Great amounts of flame and heat trying to get some of
> > the members to understand that 'pre-empt' belonged in places like SIP
> > servers, not routers.  
> > 
> > 
> > 
> > 
> > *in most of the internet infrastructure, there's enough overprovisioning
> > that fiddling with packet priorities within a router makes no sense
> > either -- there's nothing you can do to 'improve' service if there's no
> > congestion.  The place where this does become important is at the parts
> > of the internet where we reach to mobile platforms -- the radio-WANs.
> > But that's a different conversation, so I won't chase it here unless
> > somebody rings back (it's my research area).  Here the issue is not
> > pre-emption in the customary sense, but a packet prioritization sense
> > where 'the most important packets get handled first'.  The definition of
> > 'most important' is always disputed along with the means of marking
> > packets with appropriate labeling.  
> > 
> > 
> > 
> > On Mon, 2007-10-15 at 14:16 -0400, matt hoffman wrote:
> > 
> >>Art is certainly the authority on this, but I'll second that impresson. 
> >>I've worked on IPAWS-related prototypes implementing CAP interfaces, but 
> >>I have never heard mention of any system that disseminated Presidential 
> >>messages via anything other than the existing EAS framework.
> >>
> >>Matt
> >>
> >>
> >>Art Botterell wrote:
> >>
> >>>Jim -
> >>>
> >>>I can't speak for FEMA, but I would expect that presidential messages will go from WACA to FEMA for distribution through the IPAWS framework to EAS, cellular and other dissemination media.  Of course, presidential alerts have been, to date, vanishingly rare.
> >>>
> >>>- Art
> >>>
> >>>
> >>>Art Botterell, Manager
> >>>Community Warning System
> >>>Contra Costa County Office of the Sheriff
> >>>50 Glacier Drive
> >>>Martinez, California 94553
> >>>(925) 313-9603
> >>>fax (925) 646-1120
> >>>
> >>>  
> >>>
> >>>>>>"Jim Trawick" <JimTrawick at viaRadio.com> 10/15/2007 7:45 AM >>>
> >>>>>>        
> >>>
> >>>Although there's been a lot of talk about the Presidential messaging
> >>>possibilities in DEAS and at least three different versions of what that
> >>>might be (PBS, NOAA and DHS variations, that I'm aware of), is anyone aware
> >>>of a specific, currently available Presidential source (i.e., pre-empting
> >>>all others, even those in progress, per various Executive Orders), which is
> >>>available in CAP format (or any other digital, text-oriented format), and if
> >>>so, what that current source might be, and through whom it might be
> >>>currently available? Surely one must have been employed in the DMIS EAN test
> >>>back in June.
> >>>
> >>> 
> >>>Jim Trawick
> >>>Senior Software Engineer
> >>>viaRadio Logo Scaleable smaller no tag no background