Subject: [MBONED] WGLC on draft-ietf-mboned-session-announcement-req

From: Leonard Giuliano <[email-masked]>
Date: Thu, 1 Apr 2010 14:53:20 -0700

We would like to start the Working Group Last Call on "Requirements for IP 
Multicast Session Announcement" to close on April 15, 2010 at Midnight, 
UTC. The latest version of the draft can be found at:

http://tools.ietf.org/html/draft-ietf-mboned-session-announcement-req-03

Please review the document carefully, and send your feedback to the list. 
Please also indicate whether or not you believe that this document is ready to 
go to the IESG.

Thanks,
Lenny and Greg

---

From: Leonard Giuliano <[email-masked]>
Date: Wed, 7 Apr 2010 12:30:16 -0700

Speaking solely as an individual contributor and not a chair, I do not 
support this draft going forward.

SAP is an obsolete remnant from a previous century used to provide content 
discovery.  There are many far more scalable and robust ways to discover 
content on the Internet today (eg. Google, RSS, etc).  No one would ever 
imagine doing network-based content discovery for unicast content, thus I 
see no reason to do it for mcast.  The fact that mcast content may be 
ephemeral is not convincing; there is plenty of ephemeral content in the 
unicast world, yet people somehow find it without a SAP-like mechanism in 
unicast.

I personally believe we should let SAP die with dignity.

-) 
-) We would like to start the Working Group Last Call on "Requirements for IP
-) Multicast Session Announcement" to close on April 15, 2010 at Midnight, UTC.
-) The latest version of the draft can be found at:
-) 
-) http://tools.ietf.org/html/draft-ietf-mboned-session-announcement-req-03
-) 
-) Please review the document carefully, and send your feedback to the list.
-) Please also indicate whether or not you believe that this document is ready
-) to go to the IESG.
-) 
-) 
-) Thanks,
-) Lenny and Greg
-) 
-) 
-)

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 7 Apr 2010 15:14:07 -0500

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Leonard Giuliano
 
> I personally believe we should let SAP die with dignity.

+1

And too, I believe that both e-mail and web server-based systems for session announcements can be made to scale to anything that would be needed in practice, even in the Internet. Not sure that this is a real limitation anymore.

Makes me tired to think I need to implement a whole new sesssion announcement scheme to be legit, when I know I have some ready-made tools already in place that can do the job. Glad I'm not alone in this.

Bert

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 09 Apr 2010 16:11:33 +0900 (JST)

Hi,

> I personally believe we should let SAP die with dignity.

Right, that is the aim of this draft.

This draft does not recommend to use or modify SAP.
This draft clarifies the "issues" SAP has and describes the
"requirements" of session announcement protocols or procedures.
It may be possible to design a new session announcement protocol or
system in the future. However, this draft does not propose the new
architecture; it aims to understand current situation and required
conditions for multicast session announcement.

In fact, this draft also explains that simply using google or other
web based search engines is not always perfect for multicast session
announcement or discovery, because (1) the search engines may not
fullfil the scoping requirement because of lack of network-based
coordination, and (2) the crawler may take time to gather all
available session information from the whole Internet, and this
condition does not fit the situations for many of real-time IP
multicast sessions that possibly launched and terminated highly
dynamically.

For multicast communication, scoping is important to preserve
available bandwidth and privacy. This is different from unicast
communication. For unicast in concept, data senders or network
administrators can configure to filter out access from non-approved
users or stop flooding data to unwanted networks.
On the contrary, for multicast, a content server cannot recognize end
nodes receiving the content. One may say the use of RTCP RR for
knowing the receivers' conditions, but it may not be feasible for a
large number of receivers and it is impossible to control data
forwarding even with RTCP. Scoping is the reasonable method to provide
access control that enables to stop forwarding contents to unwanted
network domains.

I agree that SAP should be limited in the use of session announcement
in the entire Internet. And this thought is one of the important
motivations to work on this draft.

What do you think?
I'd be happy to improve the draft quality, so please give us comments
if you find some concern or ambiguity in this draft.
And if you still have an opinion to not move forward this draft, I'd
try to address the concern.

Regards,
--
Hitoshi Asaeda

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 12 Apr 2010 14:55:34 -0700

On Fri, 9 Apr 2010, Hitoshi Asaeda wrote:

-) Hi,
-) 
-) > Speaking solely as an individual contributor and not a chair, I do not 
-) > support this draft going forward.
-) > 
-) > SAP is an obsolete remnant from a previous century used to provide content 
-) > discovery.  There are many far more scalable and robust ways to discover 
-) > content on the Internet today (eg. Google, RSS, etc).  No one would ever 
-) > imagine doing network-based content discovery for unicast content, thus I 
-) > see no reason to do it for mcast.  The fact that mcast content may be 
-) > ephemeral is not convincing; there is plenty of ephemeral content in the 
-) > unicast world, yet people somehow find it without a SAP-like mechanism in 
-) > unicast.
-) > 
-) > I personally believe we should let SAP die with dignity.
-) 
-) Right, that is the aim of this draft.
-) 
-) This draft does not recommend to use or modify SAP.
-) This draft clarifies the "issues" SAP has and describes the
-) "requirements" of session announcement protocols or procedures.
-) It may be possible to design a new session announcement protocol or
-) system in the future. However, this draft does not propose the new
-) architecture; it aims to understand current situation and required
-) conditions for multicast session announcement.
-) 

My comments on the obsolescence of SAP could be generally applied to all 
network-based content discovery schemes, wheter it's SAP, SAPv2 or some 
new protocol.  No one would plausibly propose a network-based content 
discovery of unicast, so why do it for mcast?

-) In fact, this draft also explains that simply using google or other
-) web based search engines is not always perfect for multicast session
-) announcement or discovery, because (1) the search engines may not
-) fullfil the scoping requirement because of lack of network-based
-) coordination, and (2) the crawler may take time to gather all
-) available session information from the whole Internet, and this
-) condition does not fit the situations for many of real-time IP
-) multicast sessions that possibly launched and terminated highly
-) dynamically.
-) 

I would disagree that mcast is somehow unique in this regard.  There's 
plenty of unicast content that fits the same description.  I would suggest 
that there's no fundamental difference between mcast and (some) unicast 
content; mcast simply offers a more efficient way to distribute this 
content to multiple destinations.

-) For multicast communication, scoping is important to preserve available 
-) bandwidth and privacy. This is different from unicast communication. 
-) For unicast in concept, data senders or network administrators can 
-) configure to filter out access from non-approved users or stop flooding 
-) data to unwanted networks. On the contrary, for multicast, a content 
-) server cannot recognize end nodes receiving the content. One may say 
-) the use of RTCP RR for knowing the receivers' conditions, but it may 
-) not be feasible for a large number of receivers and it is impossible to 
-) control data forwarding even with RTCP. Scoping is the reasonable 
-) method to provide access control that enables to stop forwarding 
-) contents to unwanted network domains.
-) 

If this is a requirement, there are far better ways to handle access 
control of mcast traffic than by limiting the way the content is 
advertised.  Removing a street sign will not guarantee that no one will be 
able to find or use that street.

One simple example of access control could be to just encrypt the mcast 
stream and use unicast to distribute the decryption keys.  Then the source 
could know and control all the recipients.

-) I agree that SAP should be limited in the use of session announcement
-) in the entire Internet. And this thought is one of the important
-) motivations to work on this draft.
-) 
-) What do you think?
-) I'd be happy to improve the draft quality, so please give us comments
-) if you find some concern or ambiguity in this draft.
-) And if you still have an opinion to not move forward this draft, I'd
-) try to address the concern.
-) 
-) Regards,
-) --
-) Hitoshi Asaeda
-) _______________________________________________
-) MBONED mailing list
-) [email-masked]
-) https://www.ietf.org/mailman/listinfo/mboned
-)

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 19 Apr 2010 18:39:48 +0900 (JST)

> discovery of unicast, so why do it for mcast?

This draft does not propose or recommend network-based content
discovery. Whether network-based or other approach, there are special
requirements for content information announcement or discovery in IP
multicast.

Multicast is highly useful for real-time applications, such as live
streaming. To live with real-time applications, getting the content
information is the first step for users. However, if we obtain
"obsolete" content information (e.g. information about content ended),
it is meaningless. How can we obtain the "active" or "available"
content information in a time-sensitive manner? Or how we can discard
"obsolete" content information when we obtain the session information?
We had used SAP to obtain active content information by supporting
this concept. However, SAP has many issues as this draft mentions. As
you said this condition implies network-based session announcement
gives difficulties in its scalability. However, just using a search
engine neither solves the problems, as described in the draft.

> content to multiple destinations.

There is a problem to announce unicast real-time contents to the
Internet users, too.
The requirements for session announcement would fit the demend of
real-time streaming. This means the problem exists also in unicast.
How can I announce my streaming content to you now? How can you
discover my streaming content now? What is the best way to convey or
discover real-time content information in general? SAP, email, web,
rss, or any other implementation does not fit the demand. (Our draft
details the point, so I omit to explain what is the demand here.) The
session announcement or discovery scheme doesn't depend on its
transmission, whether unicast or multicast. The point is that the
problems in session announcement give higher impact to multicast
communication, and it is necessary to take it into account for its
deployment. And also, the corresponding solution will solve both
unicast and multicast.

On the other hand, there is one important role in the announcement or
discovery for multicast contents. The keyword is "scope". This is
explained in the draft, and briefly in the latter part of this mail.

> could know and control all the recipients.

Data encryption contributes to content security but does not help
preserving bandwidth and privacy of content information.
Scoping is necessary to "preserve available bandwidth" and "keep
privacy". The aim of scoping is different from content encryption.

Also from user's perspective, getting unneeded content information
(e.g. site-local content the user doesn't belong) is meaningless, or
furthermore, annoys the user, especially when the amount of content
information becomes very huge. This consideration is also very
important in near future.

What do you think, folks?

Regards,
--
Hitoshi Asaeda

---

From: Leonard Giuliano <[email-masked]>
Date: Wed, 21 Apr 2010 14:31:03 -0700

On Mon, 19 Apr 2010, Hitoshi Asaeda wrote:

-) > My comments on the obsolescence of SAP could be generally applied to all 
-) > network-based content discovery schemes, wheter it's SAP, SAPv2 or some 
-) > new protocol.  No one would plausibly propose a network-based content 
-) > discovery of unicast, so why do it for mcast?
-) 
-) This draft does not propose or recommend network-based content
-) discovery. Whether network-based or other approach, there are special
-) requirements for content information announcement or discovery in IP
-) multicast.
-) 
-) Multicast is highly useful for real-time applications, such as live
-) streaming. To live with real-time applications, getting the content
-) information is the first step for users. However, if we obtain
-) "obsolete" content information (e.g. information about content ended),
-) it is meaningless. How can we obtain the "active" or "available"
-) content information in a time-sensitive manner? Or how we can discard
-) "obsolete" content information when we obtain the session information?

If you replace the word "Multicast" with "Unicast", this paragraph is 
equally true:

"Unicast is highly useful for real-time applications, such as live
streaming. To live with real-time applications, getting the content
information is the first step for users. However, if we obtain
"obsolete" content information (e.g. information about content ended),
it is meaningless. How can we obtain the "active" or "available"
content information in a time-sensitive manner? Or how we can discard
"obsolete" content information when we obtain the session information?"

-)
-)

[clip]

-) 
-) There is a problem to announce unicast real-time contents to the 
-) Internet users, too. The requirements for session announcement would 
-) fit the demend of real-time streaming. This means the problem exists 
-) also in unicast. How can I announce my streaming content to you now? 
-) How can you discover my streaming content now? What is the best way to 
-) convey or discover real-time content information in general? SAP, 
-) email, web, rss, or any other implementation does not fit the demand. 
-) (Our draft details the point, so I omit to explain what is the demand 
-) here.) The session announcement or discovery scheme doesn't depend on 
-) its transmission, whether unicast or multicast. The point is that the 
-) problems in session announcement give higher impact to multicast 
-) communication, and it is necessary to take it into account for its 
-) deployment. And also, the corresponding solution will solve both 
-) unicast and multicast.
-) 

I certainly agree with this paragraph (except the part about "higher 
impact to multicast"), and suggest if this is something needed for mcast, 
there is also something needed for unicast.  Perhaps a generic solution 
that addresses both unicast and mcast for this category of "real-time, 
dynamic content" might be appropriate.  If so, I am not sure this WG is 
the right place for such work.  Perhaps MMUSIC or one of the other RAI WGs 
might be the right place?

-) On the other hand, there is one important role in the announcement or
-) discovery for multicast contents. The keyword is "scope". This is
-) explained in the draft, and briefly in the latter part of this mail.
-) 

Not sure I agree that the desire for mcast scoping is any different than 
unicast access control.  But assuming there are some unique considerations 
for mcast, I think it would appropriate for MBONED to provide input on 
mcast considerations for a broader solution that encompasses both unicast 
and mcast.  Again, I think this generic solution would be more appropriate 
in one of the RAI WGs.