Re: Re-charter? [solutions already?]

At 03:31 PM 7/1/2005 -0400, Janet P Gunn wrote:

>Closely related to the question "what is a session" is the question"what is
>pre-emption?"  In the circuit switched world, a connection is "nailed up"
>and there is little confusion on what constitutes a "session" or
>"pre-emption".

If RSVP is used (or NSIS when it becomes a protocol), the coupling of SIP 
(for example) to the reservation protocol reduces this confusion, do you 
not agree?


>But in the IP world, even if we restrict our discussion to SIP related
>sessions, it is not so clear.

For SIP, RFC3261 defines what a session is. IEPREP doesn't need to redefine it.

>Once a session has been established, how many
>packets need to be dropped, how bad does the "quality" need to get, before
>we declare that the  session has "failed" or been "pre-empted"?

Perhaps this is part of the first two deliverables:

Oct 05 Submit an initial I-D of Emergency Threats Analysis
of Government/Military Networks

Dec 05 Submit an initial I-D of Differences between GETS and
MLPP Networks

We should not be considering the definition of IP traffic in this WG.


>Looking at it from another perspective, If traffic engineering indicates
>that a given (IP) interface or route can accept 100 simultaneous calls with
>a given QoS, but there is a mechanism to allow "special" calls to be
>accepted (without actually tearing down existing calls) above that
>threshold, at what point do I declare that the "special" calls are
>pre-empting "regular calls"?

the above is asking for a solution - which is premature at this point IMO

>As soon as I exceed the engineered
>capacity(typically a utilization less than 100%)?  Once I exceed the raw
>capacity (even though all calls may continue to meet the specified QoS)?
>When a single call drops below its QoS specification? For how long?
>
>And so on.
>
>While the CONCEPT of "pre-emption based" vs. "non-pre-emption based"
>carries over from the circuit switched world, and is useful in the IP world
>(especially when IP networks are operating under rules and regulations
>developed for the circuit switched world), the specific definition do not
>carry over with any intrinsic clarity.
>
>If we are going to go down this path, I think the first step is to agree on
>a consistent set of definitions.

this will be part of an early doc IMO


>Janet
>
>
>----------------------------------------------------------------------------------------
>
>This is a PRIVATE message. If you are not the intended recipient, please
>delete without copying and kindly advise us by e-mail of the mistake in
>delivery. NOTE: Regardless of content, this e-mail shall not operate to
>bind CSC to any order or other contract unless pursuant to explicit written
>agreement or government initiative expressly permitting the use of e-mail
>for such purpose.
>----------------------------------------------------------------------------------------
>
>
>
>
> 
>
>                       Henning 
 >
>                       Schulzrinne <hgs         To:      "King, Kimberly 
> S." <[email protected]>
>                       @cs.columbia.edu         cc:      "Jon Peterson 
> \([email protected]\)"
>                       > 
> <[email protected]>, [email protected], "Ieprep \([email protected]\)"
>                       Sent 
> by:                 <[email protected]> 
 >
>                       ieprep-bounces           Subject: Re: [Ieprep] 
> Re-charter?
> 
>
> 
>
>                       06/30/2005 
> 10:48 
>
>                       AM 
 >
> 
>
>
>
>
>
>Brief remark: I'm not sure what "sessions" refers to in the snippet
>below. Is this addressed to the application layer session (say, SIP), a
>network layer session (RSVP, NSIS) or something else entirely?
>
>In general, given the tortuous history of IEPREP discussions, more
>specificity as to the types of mechanisms and protocols affected would
>be helpful, in my opinion. Are there existing drafts that will be used
>as baseline (or input) or this is a from-scratch effort?
>
>King, Kimberly S. wrote:
>
> > 3. Some countries require civil networks to preempt sessions
> > under state circumstances, and preemption is considered an
> > absolute requirement in governmental networks in most
> > countries. Unless implementation of these requirements can
> > be objectively shown to threaten network health (via
> > simulation or in operations), then the requirement needs to
> > be considered by IEPREP and specific solutions must be
> > developed.
> >
>
>_______________________________________________
>Ieprep mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/ieprep
>
>
>
>_______________________________________________
>Ieprep mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/ieprep


cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.