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

From: "Nguyen, An" <[email-masked]>
Date: Thu, 8 Apr 2004 09:10:13 -0400

Fred,

I would like to know how SIP P-R and RSVP work together to have priority
level and QoS information forwarded across a MLPP network domain.

Thanks,

An  

-----Original Message-----
From: Tschofenig Hannes [mailto:[email-masked]]
Sent: Wednesday, April 07, 2004 10:16 AM
To: [email-masked]; 'James M. Polk'
Cc: [email-masked]
Subject: RE: [NSIS] Questions regarding
<draft-baker-tsvwg-mlpp-that-works -01.txt>

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

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

<snip> 

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

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

---

From: Fred Baker <[email-masked]>
Date: Thu, 08 Apr 2004 12:57:23 -0700

>level and QoS information forwarded across a MLPP network domain.

I think that's discussed in the document you refer to on the subject 
line... I'm going to go over material here that was discussed on 24 March 
and 2 April with Peter Fonash and others of your organization. IIRC 
correctly, you were there on 24 March too, but we didn't get to talk directly.

In most real-time applications, and specifically in voice and video, the 
application-application discussion includes both session layer control 
transactions and data plane information exchange. In the session layer, one 
opens and closes sessions, finds peers to have sessions with, and so on. In 
the PSTN, this is the province of SS7, H.320/H.242/etc, and so on. The data 
plane in the PSTN is the circuit that carries voice-or-whatever. In the 
PSTN, once one gets a circuit to put one's voice-or-whatever on, a circuit 
is a circuit is a circuit.

In the IP context, the control plane is SIP/SDR, and the data plane is RTP. 
Both ride on IP. SIP and SS7 have serious differences that I don't want to 
gloss over (you will recall me discussing very carefully the difference 
between a PSTN switch, which controls capacity and routing, and a SIP 
proxy, which is ignorant of routing and capacity), but in this context can 
be compared pretty easily.

The question before the house in SS7 is "who gets a circuit", and the SS7 
exchange carries policy tidbits that assert "if there is an issue, I'm 
special, prefer me". The result of the SS7 exchange is one of two things: 
if there is capacity (a circuit) available in the network and if the called 
handset is not in use, or (military MLPP case and one could imagine the 
case on telephones that have a call-waiting feature with appropriate 
signals available to the user) if the called terminal can be convinced to 
make itself available, a circuit is assigned and the call goes through. 
Otherwise, it doesn't.

The question before the house in SIP is "who gets to have a chat with the 
remote terminal". Note that this is a policy question, and doesn't 
automatically have any knowledge of network loading or routing; hence, the 
addition of RFC 3312, which provides a way to go to a separate signaling 
protocol (RSVP) that is able to trace network routing and determine whether 
capacity exists to support the policy. The SIP Resource Priority Header 
contains information that allows someone to say "if there is an issue, I'm 
special, prefer me". There is also a capability in the RSVP policy blob to 
assert a verifiable identity, concerning which the network may conclude the 
same regarding capacity decisions.

The combination of the two protocols implements something analogous to what 
SS7 does in the PSTN. In the PSTN, IF there is capacity AND the remote 
handset can be made available THEN the call is placed; OTHERWISE it is 
refused. In SIP, IF the remote handset can be made available THEN the call 
is placed, but it may not have sufficient capacity on some trunk in the 
network to provide adequate call quality. In SIP+RSVP as described in RFC 
3312, IF there is capacity AND the remote handset can be made available 
THEN the call is placed; OTHERWISE it is refused, either by SIP refusing 
the call or by RSVP rejecting the capacity admission. There remains a 
difference; in the PSTN, once a circuit is routed, it is in place and 
capacity is assured until SS7 makes it go away. In the IP world, routing is 
completely separate from application behavior, and can change without the 
end system knowing that happened. Therefore, when routing changes, capacity 
calculations can change. In such a case, RSVP follows the routing, and can 
result in the call's status changing (in an MLPP world, in it being 
preempted) in mid-flight.

The data plane in the IP network is very different from anything in the 
world of circuits, however, in that packets compete statistically for 
capacity and biasing that in favor of one class of traffic over another 
requires marking them in some way and the network doing something specific 
to implement that behavior. DISA (Mike Pierce) and NCS (Janet Gunn) are 
arguing fairly strongly that it is insufficient to use the EF PHB and 
actually say "capacity is capacity is capacity" as is done in the circuit 
world. Rather, they would like to have varied DSCP values. I think I 
understand the reasons they are asking for this; I also think the case has 
not been proven. In the presence of capacity-aware CAC, as Mike's latest 
Assured Service Requirements draft calls for and as I have asserted is 
necessary, the varied DSCP values don't hurt, but I don't see how they 
really help.

BUT: if we do have multiple DSCP values, when Alice calls Bob with a 
certain resource priority, Alice plans to send her packets to Bob using the 
elevated DSCP value in the data plane, and Bob would be well advised to do 
the same. The Resource Priority blob in the SIP message communicates to Bob 
that he should do so and guides him as to which value to select.

The discussion in NSIS wants to replace RSVP in all of the above with NSIS, 
which I'm all for some day when NSIS decides to produce a deployable 
result. That result has to meet the requirements of the system being 
discussed: the ability to aggregate calls, manage policy, and so on and so 
forth.