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

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 15 Apr 2004 15:43:53 +0200

hi james, 

thanks for your detailed response. please see my comments inline:

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]]
> Sent: Tuesday, April 13, 2004 10:57 PM
> To: Tschofenig Hannes; [email-masked]
> Cc: [email-masked]
> Subject: Re: Questions regarding
> <draft-baker-tsvwg-mlpp-that-works-01.txt> 
> 
> 
> 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
> 
> At 08:13 PM 4/3/2004 +0200, Hannes Tschofenig wrote:
> >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?
> 
> 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.
> 

thanks. i guess i now understand the differences much better. 

> 
> >- 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??
> 
> 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).
> 
thanks for your explanations. 

> 
> >- type 1 encryption
> >
> >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

i was just curious - some fancy encryption stuff. 

> 
> >- 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.
> 
> I'll let Fred elaborate on this facet
> 
> 
> >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?
> 
> 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).

i agree with you but it might be more difficult to have intermediate routers
to decide by their own. if we speak about different levels of priorities in
rsvp then there must be a way to figure out whether one is entitled to
indicate a certain priority level. why wouldn't i always set a high
priority. i once heard that people belonging to some governmental agencies
can give their phone calls higher priority (which might be useful in
emergency cases) by dialing some special numbers (passcodes or something
similar). i don't know whether this is actually true but it sounds like
role-based access control to me and possibly useful. are you aware of
something like this?

> 
> 
> >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

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

i can also send you text, if you want. 

>ciao
>hannes

ciao
hannes

> cheers,
> James

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

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