Subject: RE: [Ieprep] identification of packets

From: "King, Kimberly S." <[email-masked]>
Date: Tue, 3 Dec 2002 12:50:55 -0500

I said:
> While it is true that "entities that
> are addressing congestion on the access link" may use different 
> methods,
> this doesn't stop the hope that in many cases a common configuration
of
> *user software* is possible.  It doesn't have to imply interprovider 
> QoS
> either.

Ran said:
>Hmm.

>What do you mean by "common configuration of user software" ?

I'm an intuitionist, I was thinking in that way at the time.

Anyway, I was thinking about old conversations about the differences between
the PSTN and the Internet and how it is endsystems (lack of common
configuration) that stalls working systems on the Internet.  I was also
thinking about a conversation I had with Rohan Mahy at the last IETF about
an idea that he has.  Here the common configuration would be some user
software, configured in a particular way to work with a select number of
ISPs.  

(Sorry Rohan if I'm about to misrepresent your idea...)

Scenario:  Emergency Services Organization contracts with several major ISPs
to provide the following service.  Critical emergency workers are given some
type of identification/authorization single use token.  When a disaster
occurs, then the emergency worker finds an Internet connection such as an
Internet café.  

Suppose the service quality isn't as good as desired (due to dreaded
congestion).  The emergency worker then sends the authentication information
out to the network (e.g., a modification of RSVP that is intercepted by the
first hop access router).  

If the access router is part of an ISP providing this service, this
authentication token triggers a special configuration on the access router.
Namely, this triggers a configuration method existing on this access router
that then provides additional resources for the connection from the given
location (e.g., increases the token bucket size or some other form of rough
additional resource).  This behavior isn't necessarily based upon flows from
the particular user but rather for the entire connection, say for some fixed
time period (e.g., 5 days).  

The WG can investigate if more complicated behavior is reasonable such as
the emergency workers flows be marked by particular DiffServ codepoints
however the WG is strongly suggested follow the KISS principal.  Remember
that even the roughest of preferential treatment can potentially increase
the probably of successful communications.  Also keep in mind the tradeoff
between complexity and security, and complexity and cost (i.e., complicated
deployments are often expensive deployments).  Possibly, additional
resources could be provided at both directions at the access router (i.e.,
extra resources in accepting packets from that connection and also resources
for packets destine back to the emergency worker).  If the application also
involves another users such as with VoIP, is also possible that the egress
router, should it also be in one of the contracted ISPs would also provide
some extra measure of QoS.  Note that there will be security concerns
including replay attacks.  
	
So, I think we should toss around this idea with the IP experts and see if
they can figure out if such a scheme is viable, and what protocols might
need some modification to support such a feature.  (For example, RSVP may be
an ideal choice.)  

If this all seems positive, I'll try to round up a design team to work on
the problem.  Members of the design team are responsible for choices made
along the way however their progress and background on why they make the
choices they make will be presented to the working group.  This isn't a case
where rough consensus is abandoned.  Any requirements or BCPs produced by
the WG are still subject to WG rough consensus.

Thoughts?

Kimberly

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

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 3 Dec 2002 14:27:30 -0500

On Tuesday, Dec 3, 2002, at 12:50 America/Montreal, King, Kimberly S. 
wrote:
> the probably of successful communications.

	Deploying any form of QoS can also *reduce* the probability of
successful communications, by increasing the complexity of the network.

> Also keep in mind the tradeoff
> deployments are often expensive deployments).

And the tradeoffs between:
	complexity and network availability
	complexity and mean-time-to-repair
	complexity and mean-time-between-failure

Ran
[email-masked]