Subject: RE: [NSIS] Questions regarding <draft-baker-tsvwg-mlpp-that-works -01.txt>

From: Tschofenig Hannes <[email-masked]>
Date: Wed, 7 Apr 2004 16:16:22 +0200

hi all, 

i would like to add something to my question with regard to the difference
between the sip based preemption approach
(draft-ietf-sip-resource-priority-03.txt) and the rsvp preemption approach
(rfc2751):

draft-ietf-sip-resource-priority-03.txt defines a scheme based on : 
- enumerations of <'namespace' '.' 'priority value'> pairs.

rfc2751 defines a scheme based on: 
- a preemption priority 
- a defending priority 
- and a merging strategy

how do they match to each other? 
which approach would you suggest for the qos nlsp (or for nsis in general)?

ciao
hannes

> -----Original Message-----
> From: Tschofenig Hannes 
> Sent: Saturday, April 03, 2004 8:14 PM
> To: [email-masked]; 'James M. Polk'
> Cc: [email-masked]
> Subject: [NSIS] Questions regarding
> <draft-baker-tsvwg-mlpp-that-works-01.txt>
> 
> 
> hi fred, hi james, 
> 
> your draft has recently been mentioned in the nsis wg. i have 
> read the draft
> and came across a few issues: 
> 
> - the details between the preemption defined in
> <draft-ietf-sip-resource-priority-03.txt > and <rfc2751> seem 
> to be a bit
> different. have you compared them? 
> 
> - in section 2.1 you talk about notifying the end hosts about 
> preemption
> (somewhere in the network). also section 1.5 says something similar: 
> "All callers on the preempted call must be informed that
>       the call has been preempted, and the call must make way for the
>       higher precedence call."
> 
> this might be of interest for the qos nslp work in nsis or even for
> nat/firewall work??
> 
> - type 1 encryption
> 
> what do you consider 'type 1 encryption'? 
> 
> - authorization
> 
> in section 1.2 you say: 
> "Since the act of preemption or
>    consideration of alternative bandwidth sources is part and 
> parcel of
>    the problem of providing bandwidth, and the authorization step in
>    bandwidth provision also affects the choice of networks that may be
>    authorized to be considered." 
> 
> i am not quite sure what you mean with ... also affects the choice of
> networks....". 
> could you elaborate? sounds a bit like qos routing. 
> 
> regarding section 2.3.5.2 i suspect that the typical procedure is as
> follows: 
> 
> a user adds a priority level in his qos request. the 
> authenticated request
> is processed at the first router and forwarded to the "policy decision
> point" together with the qos parameters and the indicated 
> priority level. as
> part of the authorization procedure the request is granted or 
> rejected. if
> it is granted then the request (including the priority level) 
> is forwarded
> along the path. is this right?
> 
> a minor issue: there is a bug in section 2.3.3 - the 
> relationship between
> ipsec encrypted traffic and rsvp signaling. you might want to 
> take a look at
> section 5.4 of
> http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-p
roperties-04.t
xt

ciao
hannes

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

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

---

From: Fred Baker <[email-masked]>
Date: Wed, 07 Apr 2004 09:27:36 -0700

Tschofenig Hannes wrote:
> (rfc2751)

I think you're comparing apples and orangutans.

The preemption question in SIP is between two calls to the same device. 
If Alice is calling Bob when Bob is talking with Carol, in some 
circumstances you would like Bob and Carol to hang up and have Bob's 
phone immediately ring with Alice's call. This is not a bandwidth 
question, it is a question of the urgency of Alice's call vs the one 
currently in progress.

In addition, if Alice is calling Bob and is using an unusual DSCP (DISA 
wants to use multiple DSCP values instead of a single EF code point), 
Bob should be using the same DSCP value Alice does. The Resource 
Priority header, by corelated configuration, tells Bob what DSCP value 
to use.

The question being looked at in capacity admission concerns choices in 
how a finite amount of bandwidth migh be used. If Alice calls Bob at a 
time that some bottleneck link is using all of the bandwidth it is 
configured to use for that aggregate of applications (might be voice or 
video, or potentially other real-time applications), it might be 
preferable for Carol and Dick's call to be dropped entirely rather than 
simply lose the equivalent of a call's bandwidth distributed across all 
of the ambient calls.

Capacity admission is a network layer question. The other, whatever you 
choose to call it, is an application layer question.