Re: Question about RSVP based preemption

At 09:19 AM 10/18/04 -0400, Eagan, Christopher wrote:
>Regarding the example in Appendix A of 
>draft-baker-tsvwg-mlpp-that-works-02.txt, it seems that RSVP based 
>preemption may unnecessarily drop low priority calls in cases were the 
>preempting call is not completed to the original callee

That would surprise me except in very narrow cases; as I understand it, 
those cases also hold in the military PSTN MLPP implementation.

in the general case:

RFC 3312 (which is reflected in the appendix) describes how RSVP and the 
application protocol (in this case SIP) interact. The end systems have a 
fair exchange of application signaling before their IP addresses and port 
numbers are even known to each other to initiate the RSVP exchange. Part of 
what has to be determined at the application layer is whether the end 
system has been turned on (is the plug in the wall?), whether it is 
currently engaged with another call (which may be preempted in SIP), and so on.

In addition, as opposed to the Caspian proposal currently being discussed 
in TIA, RSVP initiates the reservation in the RESV message originated by 
the receiver towards the sender, which is a response to the PATH message 
the sender sent to the receiver.

By definition, if there is an RESV message in the system (if someone is 
trying to install a reservation), a fair SIP exchange has already occurred, 
the two handsets have decided to engage in a call if possible, and the PATH 
message has already made it from the sender to the receiver.

Now, yes, one does ensure bandwidth before ringing the phone. So if no 
human actually answers the phone (your specific case), an unnecessary 
preemption event may have occurred.

Now let's take a look at the PSTN case. Any given call proceeds through 
some number of switches. In the final switch, there is no real question of 
bandwidth: if the switch can get to the phone, the bandwidth exists, and in 
any event if the phone having been rung is answered the switch is in a 
position to handle any issues that might arise. In the N-1 preceding, 
however, there may or may not be bandwidth to the next switch, and 
preemption may be used to create that bandwidth. In such a case, the 
preemption likewise occurs prior to ringing the phone, and therefore before 
a human has the opportunity to answer or fail to answer.

To be frank, while I think it would be good if we could solve both problems 
simultaneously, I think the premise in this system is that a routine call 
being dropped here or there is not a big problem. And by the way, James and 
I are not arguing that routine calls are sacrosanct. We are arguing that 
*if* a call at any preference level is preempted, one or two should be 
dropped entirely rather than an entire class of calls being made marginal.

>- in cases where the callee's UAS is alive and well but the call for some 
>reason goes unanswered and is forwarded to an alternate party or a global 
>attendant somewhere else on the network.
>
>If you have a network snippet like......
>
>             Alt Party      R Talker
>                |               |
>              |               |
>F Caller-----N---------------N------F Callee
>                              |
>                              |
>                            R Talker
>
>Where the 2 "R Talkers" are on an existing Routine Call, N are routers 
>where RSVP preemptions may occur, and F Caller / F Callee are participants 
>in a Flash call being set up (and assuming that the current b/w 
>requirements are such that the F's cannot make their call w/o preempting 
>the R's).
>
> From the example in the draft, it looks like the R's will receive the 
> RSVP preemption messages before F Callee's phone rings to prevent dead 
> rings.  Is this correct?  Is yes, and F Callee doesn't answer the phone 
> for any reason, F Caller will be redirected to F Callee's Alternate 
> Party.  In this case the Routine call is unnecessarily preempted.
>
>Is my understanding of how this works correct?
>
>Is it possible for the RSVP preempting routers to delay the tear down of 
>low priority calls until the high priority stream actually starts?  I.e. 
>Mark the low priority stream for preemption, but don't actually tear it 
>down until the b/w is at capacity.
>
>Thanks,
>
>Chris
>
>Christopher Eagan
>Software Engineer
>Lockheed Martin, IS&S
>(301) 240 - 6328