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

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 12 Apr 2004 23:03:48 +0100

A very brief comment on the RSVP/NSIS relationship/interchangeability:

So far as I can tell, everything we have done so far in NSIS is
compatible with the concept of using it as a side-by-side 
alternative to RSVP, at least so far as relationship with other
higher-layer protocols (like SIP) is concerned. The differences
from RSVP are to do with wanting different performance/complexity
tradeoffs and different types of flexibility within the protocol.

In particular, I've read mlpp-that-works and believe that we
could do "s/RSVP/NSIS", except that we don't have all the RFC
numbers yet ;-).

The main point is that NSIS signalling is tied to the data plane
in exactly the same way as RSVP (which also makes interoperability
easy to consider, except when route changes start moving the 
interoperation point around ...)

However, while I've tried to understand whether the MLPP 
discussions help us to work out where within the NSIS protocol
suite to put priority and pre-emption (which is where this conversation
started), so far I've failed to find any guidance on that subject.
(One interesting question would be "Is there any experience about 
whether the priority/pre-emption model of RFC3181 is a good match 
for operational requirements or not?")

robert h.

> -----Original Message-----
> From: Roy, Radhika R, ALABS [mailto:[email-masked]]
> Sent: Friday, April 09, 2004 20:20
> To: Fred Baker
> Cc: Nguyen, An; Tschofenig Hannes; James M. Polk; [email-masked]
> Subject: RE: [NSIS] Questions regarding
> <draft-baker-tsvwg-mlpp-that-works -01.txt>
> 
> 
> Hi, Fred:
> 
> We are in agreement.
> 
> The main points are as follows:
> 
> 1. Applications level signaling schemes (e.g., NSIS protocols) need to
> understand the implications between the call level priority 
> (e.g., SIP)
> vs. media (e.g., SDP) level priority.
> 
> 2. The complexities for comparisons of different priority 
> levels between
> the circuit-switched PSTN network vs. Packet-switched IP network along
> with the application level call signaling protocols (e.g., ISUP, SIP)
> that are used.
> 
> In this way, we would help us to rationalize how we should address
> different aspects of NSIS protocols.
> 
> br,
> Radhika
> 
> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]]
> Sent: Friday, April 09, 2004 2:02 PM
> To: Roy, Radhika R, ALABS
> Cc: Nguyen, An; Tschofenig Hannes; James M. Polk; [email-masked]
> Subject: RE: [NSIS] Questions regarding
> <draft-baker-tsvwg-mlpp-that-works -01.txt>
> 
> 
> 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. 
> 
> 
> _______________________________________________
> 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: "Hancock, Robert" <[email-masked]>
Date: Wed, 14 Apr 2004 13:00:57 +0100

hi,

> > Yes, you are right.
> >
> > What NSIS protocols need to do is as follows:
> >
> > 1. Differentiation in call level priority
> >
> uh, don't think so. NSIS doesn't know a "call" from a hole in 
> the ground

NSIS fundamentally knows about flows (unicast, unidirectional,
defined by an ntuple), and signalling applications can map these
to things called "NSIS sessions" how they like. 

How these get mapped to 'calls' is something I would assume
is an upper-layer issue in the call endpoints (especially e.g.
if a 'call' is a duplex thing).

> 
> > 2. Differentiation in priority level for each media of a 
> given call level
> > priority
> >
> modulo needing both preemption and holding precedence, and possibly a 
> restoration precedence too, yes.
> 
> note that the identifier space can't be private to the protocol layer 
> either. It needs to be a "first class object" that is both read/write 
> through the application interface to NSIS protocols in hosts.

This is an important point. I assume the expectation is that this 
identifier would need to be communicated in non-NSIS protocols e.g. between
the user application peers. Are there any established requirements for
such identifiers (e.g. which node is expected to allocate them, at what 
stage during a call does each end need to know about them)? This could
have interesting impacts on the NSIS protocol design details.

[There has been some discussion of what identifier space to use in the
NATFW signalling application drafts, specifically whether to use the
NSIS session id or the flow identification N-tuple. But I don't think 
there are any firm conclusions on that yet.]

r.

> Dave.
> > Best regards,