Subject: Re: [Sipping] WGLC for draft-ietf-sipping-reason-header-for-preemption-00.txt

From: Dean Willis <[email-masked]>
Date: Mon, 01 Mar 2004 20:14:54 -0600

James M. Polk wrote:
> how exactly is informing the UA translate into telling the user why 
> something has happened always (which is the way I read your question)?

Basic spook information theory.

1) A is talking to B.
2) A gets pre-empted and knows it.
3) A reasons that B must have gotten a call from someone more important 
than A, as Mike assert that's the only reason to get pre-empted. A calls 
his Evil Master and reports "something's up, B got a pre-emption call".

Issue: There are other reasons why A-B might get pre-empted. For 
example, C might need to talk to D, requiring a circuit used by A-B, so 
BOTH A and B get preempted. This helps only slighly.

Information theory: If A-B gets preempted, both A and B can determine 
that somebody somewhere more important than them (which might include 
their peer) had a call to make AND that some path between A and B is 
critical to that call. Statistical analysis of such obervations, 
especially if many observers are scattered around the network, allows 
the observer to guesstimate where the "important parties" are and vector 
  in a strategic air strike.

Corrolary: Even if A and B don't know they've been pre-empted, if they 
know that calls are more likely to fail when pre-empted, then the same 
analysis is possible.

Recovery: Institute pseudo-random failures with the same signature as 
user-perception of pre-emption, distributing those failures such that 
statistical analysis from a large number of observers cannot deduce the 
"high priority" participants.

Ever wonder why your mobile calls drop randomly, even when you seem to 
have a good signal? Now you know! Gotta "mess with you" all the time so 
that you never know when the "messing with" is actually important.

For a recreational treatment of information theory in a reasonably good 
story, I suggest Neal Stephenson's "Cryptonomicon", which appears to 
include some ghost writing from our "old friend" Bruce S., who once 
published a rather negative article about the state of SIP security and 
declined my invention to provide more specific input. On the other hand, 
the last time we asked, he said it was "better" now.

--
Dean

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 02 Mar 2004 02:38:52 -0600

>his Evil Master and reports "something's up, B got a pre-emption call".

All above is accurate (though I question the Evil Master angle will apply 
in all cases), but to direct at Mike's comment: He wants the preempted user 
to hear a chime that they have indeed been preempted - he's 
fearing/believing that if the Reason header indicates the type of 
preemption - access or RSVP based - the user will know this difference too 
(from the BYE message) as some unique indication of the two possibilities. 
I contend that just because a UA receives a more specific message doesn't 
mean that translates directly into a UI indication of that level of detail.

Put simply, regardless of the Reason Header value, the user hears the same 
generic chime (thus doesn't know which type of preemption event occurred, 
which is his preferred UAS behavior).

>Issue: There are other reasons why A-B might get pre-empted. For example, 
>C might need to talk to D, requiring a circuit used by A-B, so BOTH A and 
>B get preempted. This helps only slighly.

this is a network (or RSVP) based preemption

cheers,
James

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