Subject: RE: [NSIS] Re: qos-nslp-00

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 30 Oct 2003 16:07:01 -0000

hi paulo,

> I agree with you that the experience of RSVP and many-to-many 
> multicast was nor good. But, as you said, we have a different 
> scenario if we consider SSM or xcast like-schemes.

well, to be strict, what i was trying to say was that actually
RSVP including multicast is complicated, but because the problem
is fundamentally complicated it is probably not possible to do 
any better. anyway...

> With my questions, I wanted to understand what is opinion of the 
> NSIS community about the inclusion of some lighter form of 
> multicast, instead of the many-to-many considered in RSVP. I 
> completely agree that this is out of scope in the current 
> charter, but what is going to happen in the next charter? 
> A starting point could be to include in this NSLP (which I think 
> is quite good) some considerations, not only referring to what 
> will be analyzed in the next versions of the document, but also 
> referring future open issues. In this latter case, I could 
> include the study of the interaction with different QoS models 
> and the study of multicast usage (even if only with one-to-many 
> schemes).

this would be an approach.

> Another question that I got from your answer is the following. 
> The NSIS charter says "The intention is to re-use, where 
> appropriate,
> the protocol mechanisms of RSVP, while at the same time 
> simplifying it and applying a more general signaling model.". I 
> think that this general signaling model is in contrast with what 
> you said "there is no reason why a resource manager shouldn't be 
> able to handle unicast traffic with nsis and multicast with 
> rsvp". Is this right? It seems that in the end of this charter 
> we'll have a unicast signaling protocol, but not a general 
> signaling protocol for the Internet.

well, this is a good question about charter scope and engineering
feasibility. but my interpretation of the "general signalling
model" phrase in the charter is to do with handling multiple
signalling applications (rather than QoS with an IntServ focus
as RSVP does), and not to do with handling unicast + multicast
together.

my engineering prejudice is that building protocols which integrate
unicast and multicast (ASM) is not a good idea; we don't try to
do it with routing, transport or security protocols, and we 
shouldn't try to do it with signalling protocols, at least 
not the NTLP (which has interactions with routing, transport and
security functions), especially when you start to pin down error
conditions.

> This picture is more confuse when we read the definition of a flow 
> in the requirements draft:
>    "Flow: .... The flow can be unicast (uni- or bi-directional) or 
> multicast. For multicast, a flow can diverge into multiple flows as 
> it propagates toward the receiver.  For multi-sender multicast, a 
> flow can also diverge when viewed in the reverse direction (toward 
> the senders)."

> For me, it is clear that multicast is included in the set of issues 
> that are out of scope of the current NSIS charter. In this case, the 
> previous definion of a flow should be modified. What is not clear is 
> if someone has an idea about the road to follow after achieving the 
> current goals (next charter).

I agree it's confusing that the req draft includes multicast in the
flow defn but doesn't later include any statements about whether
it is actually a requirement. Your final question I cannot answer!

r.

> Cheers,
> Paulo

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