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

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 24 Oct 2003 20:12:10 +0100

hi paulo,

i (for one) would be quite happy to see it clarified that 
no future version of this draft will ever consider multicast.

there are a number of reasons for this to do with missing 
parts of the multicast story in the Internet as a whole
and also the fact that we would have to revisit multicast
in the whole NSIS requirements and framework. 

however, the main point is that I'm pretty sure that if you
tried to invent a multicast NSIS you would end up with 
something nearly identical to RSVP (which of course we do
not need to invent again). there is no reason why a resource
manager shouldn't be able to handle unicast traffic with nsis
and multicast with rsvp; and, IMHO, the overlap between 
unicast and multicast functionality in the signalling 
protocol is rather limited.

(at least, this is true if you consider traditional IP 
multicast in its full glory. the situation for things like
SSM or xcast is probably different, since these are much
easier to handle. all we need is someone to want these 
supported strongly enough...)

cheers,

r.

> -----Original Message-----
> From: Paulo Mendes [mailto:[email-masked]]
> Sent: Friday, October 24, 2003 17:44
> To: Rute C. Sofia
> Cc: [email-masked]; [email-masked]
> Subject: Re: [NSIS] Re: qos-nslp-00
> 
> 
> Hi all,
> 
> >* would change "it is simplified by the elimination of support for
> >multicast" to something as "it does not address multicast 
> support" (which
> >you actually say a couple of paragraphs after)
> >  
> >
> I agree with this point, which leads me to a question: Will 
> some future 
> version of this draft address the issue of multicast? If not, 
> should be 
> referred somewhere in this draft that multicast support should be 
> analysed in a different document? A lack of any comment about 
> this issue 
> might be understood as an indication that the future NSIS 
> protocol will 
> not be able to handle QoS multicast services.
> 
> Cheers,
> Paulo
> 
> -- 
> Paulo Mendes
> DoCoMo Communications Laboratories Europe GmbH
> Landsberger Str. 312
> 80687 Munich, Germany
> Tel. +49-89-56824-226
> Fax. +49-89-56824-300
> E-mail: [email-masked]
> http://www.docomoeurolabs.de/
> 
> 
> 
> _______________________________________________
> 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: Paulo Mendes <[email-masked]>
Date: Tue, 28 Oct 2003 21:05:02 +0100

hi Robert,

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.

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

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.

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

Cheers,
Paulo

Hancock, Robert wrote:

>Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell,
>Berkshire. RG12 8FZ
>
>The information contained in this e-mail and any attachments is confidential to
>Roke Manor Research Ltd and must not be passed to any third party without
>permission. This communication is for information only and shall not create or
>change any contractual relationship.
>
>
>  
>