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

From: "Roy, Radhika R, ALABS" <[email-masked]>
Date: Fri, 9 Apr 2004 13:26:12 -0400

Hi, all:

Some quick clarifications ...

I wonder whether we also consider the following in terms of SIP:

1. SIP signaling messages may indicate priorities how calls need to be
handled. However, SDP may contain multiple media: Audio, Video, and/or
Data. Again, each media may need to be dealt with different priorities
(e.g., audio - highest, data - second highest, vide - least priority).
The media level differentiation in priority in SIP, I guess, is yet to
be standardized.

2. If the SDP contains only one media (e.g., audio) and the call level
priority can also be mapped directly to media. So, RSVP can also take
care of reservation of audio media in terms of priority.

3. If SDP contains multiple media, how does RSVP will take of media
level differentiation in priority  in reservation of resources, if
something else does not help in differentiating priority of each media?
Of course, media policies can be used to define this, however, it would
be better if there is a standard to define so.

4. If all media of SDP get the same priority, however, there may not be
any problems (may not always be realistic if high-bandwidth video is
there).

Best regards,

Radhika R. Roy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Fred
Baker
Sent: Thursday, April 08, 2004 3:57 PM
To: Nguyen, An
Cc: [email-masked]; 'James M. Polk'; 'Tschofenig Hannes'
Subject: RE: [NSIS] Questions regarding
<draft-baker-tsvwg-mlpp-that-works -01.txt>

At 09:10 AM 04/08/04 -0400, Nguyen, An wrote:
>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.

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. 

_______________________________________________
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: Fri, 09 Apr 2004 11:02:16 -0700

At 01:26 PM 04/09/04 -0400, Roy, Radhika R, ALABS wrote:
>3. If SDP contains multiple media, how does RSVP will take of media level 
>differentiation in priority in reservation of resources, if something else 
>does not help in differentiating priority of each media?

I'm not the list moderator, but I'll say something that I'll bet the list 
moderator is thinking: If this is an NSIS requirement, the point on *this* 
list should be to ensure that NSIS (GIMP/NSLP) meets the requirement. I 
understand the working group to not so much be thinking about RSVP as a 
protocol to replace it, hopefully in a manner that is interoperable at some 
level.

I'd suggest that discussion of the NCS/MLPP near-term operational 
requirements, which have wandered from SIP to SIPPING to IEPREP to TSVWG, 
not be particularly brought here except to ensure that those needs will be 
met by NSIS when NSIS is done.