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

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 3 Apr 2004 20:13:35 +0200

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-properties-04.t
xt

ciao
hannes

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

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 13 Apr 2004 15:57:13 -0500

Hannes

Again, sorry for the late response - and I noticed several of your 
questions haven't been answered yet, so I'll make an attempt at answering 
each (I hope), though 1 is deferred and 1 is being researched as I send this

>different. have you compared them?

Fred answered this well. There is session set-up signaling that has 
preemption possible only at the endpoints. And there is session set-up 
signaling that requests (within the SDP as specified in RFC 3312) that an 
appropriate amount of BW be guaranteed between the two UAs prior to the 
final SIP signaling acceptance of the set-up (the final 200 OK). If the 
control plane signaling fails to establish the bandwidth, the domain can 
use local policy to determine whether it wishes to have the session set-up 
(as best effort) anyway. MLPP networks will generally *not* want this 
functionality in the new call set-up. I think those domain might consider 
(well down the road, meaning years from now) that the preempted call have 
the choice to "stay up" in a best effort mode (but this can only apply to 
the case where the call between Carol and Dave was interrupted to make way 
for the higher priority call between Alice and Bob).

I have my thoughts on how endpoint preemption will evolve too, but that is 
not an NSIS or RSVP discussion.

>this might be of interest for the qos nslp work in nsis or even for

It should be. This is a case we're arguing is vital. The scenario is this: 
3 G.711 calls exist over a 256kbps WAN link (the phones cannot support any 
other codec in this example) when a 4th caller signals for a call to be 
established across that same link. Obviously ~ 80kbps more capacity does 
not exist, but SIP wouldn't know that. SIP, if it is the only means of call 
establishment and control, will set up the call, thereby reducing the 
quality of all 4 calls traversing that circuit. The users won't know what 
happened, just that voice reception quality just tanked. Diffserv does not 
have a feedback mechanism for real-time communications (ECN isn't used for 
RTP, and RTCP isn't and shouldn't be relied upon for effective endpoint 
feedback here either).

We're arguing in the above quoted section of mlpp-that-works that the 
callers should be informed when "something happened to their call" (like a 
tone, a chime, or a warning signal). If RSVP were to be in place in the 
above example, the 4th call would only be set-up if it is at a higher 
priority that at least one of the existing calls (thus preempting one of 
that 3 calls - and providing positive user feedback to that event), 
otherwise that 4th caller would receive the equivalent of a busy signal 
(because although the application layer can set up the call in SIP, the 
RESV would error due to lack of BW available somewhere in the path).

>what do you consider 'type 1 encryption'?

This is a US DOD standard that is not public information, requires a high 
level of security clearance to discuss, requires a long process of 
manufacturer clearance to attempt to build and produce products that 
qualify, and do not use publicly available or publicly known encryption 
algorithms.

I believe DES, 3DES and AES are the "Type 3" algorithms

>could you elaborate? sounds a bit like qos routing.

I'll let Fred elaborate on this facet

>along the path. is this right?

generally yes, but if each router must send a query back to some central 
server (the PDP), this might get a little slow. Our plan is for this to 
occur in the LDP in the router. Obviously this cannot be too complicated a 
decision or a list of possibilities too long (else the LDP will become 
overburdened).

>http://www.ietf.org/internet-drafts/draft-ietf-nsis-rsvp-sec-properties-04.t

I'm reviewing this section with other now, and will respond soon to this 
section's text

>hannes

cheers,
James

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

---

From: Fred Baker <[email-masked]>
Date: Wed, 14 Apr 2004 05:49:58 +0800

>I'll let Fred elaborate on this facet

The entire paragraph is:

1.2 Definition of Call Admission

    Traditionally, in the PSTN, "Call Admission Control", or CAC, has had
    the responsibility of determining whether a caller has permission (an
    identified subscriber, with identify attested to by appropriate
    credentials, is authorized) to use an available circuit. MLPP, or any
    emergency telephone service, creates two feedback paths in the
    algorithm: if a caller is authorized to use a higher precedence and
    is asserting that the advanced precedence applies to a given call, he
    may also be authorized to use other networks, or the PSTN may be
    obligated to preempt a call if possible and necessary to create
    appropriate bandwidth, or it may be authorized to use a guard band of
    bandwidth that other callers are not. At the completion of CAC,
    however, the caller either has a circuit that he or she is authorized
    to use, or has no circuit. Since the act of preemption or
    consideration of alternative bandwidth sources is part and parcel of
    the problem of providing bandwidth, the authorization step in
    bandwidth provision also affects the choice of networks that may be
    authorized to be considered. The three cannot be separated. The CAC
    procedure finds available bandwidth that the caller is authorized to
    use and preemption may in some networks be part of making that
    happen.

In the PSTN, which is the context of this paragraph, there is in fact the 
potential for call routing. In the Internet, at least at this point, call 
routing is not one of the options.
>>a minor issue: there is a bug in section 2.3.3

Thanks for pointing that out. That's the reason we post documents for open 
discussion...