Subject: [SAM] draft-irtf-sam-muramoto-generic-require-00.txt

From: Eiichi Muramoto <[email-masked]>
Date: Tue, 20 Jun 2006 22:57:42 +0900

Hello all.

We just submitted a draft.

I posted it after the cut-off date. So I also put it below.
http://www.xcast.jp/~muramoto/draft-irtf-sam-muramoto-generic-require-00.txt
Although it is not polished enough, 
we hope it would help our discussion in the next IETF meeting.

Regards,
Eiichi Muramoto, Yuji Imai, Nobuo Kawaguchi / WIDE project

-----
[email-masked]

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

---

From: Jun Lei <[email-masked]>
Date: Wed, 21 Jun 2006 15:42:53 +0200

Hi, all:
     We are interested in this topic as well and glad to the draft on " 
requirements for SAM framework". The motivation behind this draft is 
great because the requirements and problems statements seem to the 
instructions of the research work.

     Nevertheless, I have some comments on it.

1. In this draft, "problems space" is mentioned, however, the exact 
problem statements are missing. It might be better to illustrate the 
existing problems at the beginning.

2. Generally, to my opinion, it is better to state the reason why the 
requirement is important to the SAM framework, at least the advantage of 
considering the requirement. However, it is hard to find above 
statements in this draft.

In the following contents, some suggestions:

3. In section 3.2, the contents might be not quite in accordance with 
the title since it mainly talks about the underlying infrastructure 
support. Or maybe I make a misunderstanding?

4. 3.3.4 might be better to say "dynamic management of group membership" 
instead of "dynamics of group membership" as a requirement.

5. Another requirement might also be important "efficiency of data 
distribution/transmission". As we known, application level multicast is 
much less efficient as the network layer multicast.

6. There are several grammatical errors and spelling mistakes.
for example,
3.3.1 at the beginning "*Mulitcast* distribution..." should be 
"Multicast ...";
3.3.2 "..forwarding *function* (...) are ..." should be "...functions 
(..) are...";
"in such situation, .." should be "in such a situation".

It might be better to revise the whole expression?

Best Regards

Jun

-- 
Jun Lei
PhD Student

Address:
Georg-August-Universitaet Goettingen
Institut fuer Informatik
Telematics Group
Lotzestrasse 16-18
37083 Goettingen

Fax: +49 (551) 39-1 44 03
Tel: +49 (551) 39-1 35 78

Email: [email-masked]

---

From: Eiichi Muramoto <[email-masked]>
Date: Fri, 23 Jun 2006 14:31:47 +0900

Hi, Lei

Thank you for reading the "rushing" draft.

I think your comments are right. 
 ( we should state problem space and importantance of requirement, if possible )

Forunately (or unfortunately) the draft returned back to me because of insufficient copyright statement.(I wrote "2005".)

>It might be better to revise the whole expression?
Yes. I think the document is only for our discussion not for formal one.
After 1st meeting in the next IETF, it should be revised.
So I did not add something nor fix the document itself. 
I just fixed typo and re-submited it.

Regards,
Eiichi Muramoto.

-----

---

From: Rick Boivie <[email-masked]>
Date: Fri, 23 Jun 2006 15:29:28 -0400

Hi Guys,

It seems that the title of section 3.3 in your draft should
be something like "Number of Groups"
since that's what seems to be discussed in that section.
Not group size.

Also, here are some words I put together for a requirements
discussion a little while back

-  should be scalable in that it should be able to support a very
   large number of multicast groups  (since the network will need
   to support very large numbers of groups for VoIP conference
   calls, for videoconferences, e-meetings and other applications).

-  should be able to rapidly adapt to changes in network topology --
   even if there is a large number of multicast groups, even if group
   membership is highly dynamic and even if lots of group members
   are moving.  To state this requirement in a more quantifiable way,
   multicast routing should converge for 95% of the affected groups
   within 1 second, say, after convergence of unicast routing (to
   minimize outages of VoIP conference, e-meetings etc.)

-  Multicast packets should follow "close to optimal" routes from a source
   to a destination.  To state this in a more quantifiable and measurable
   way, the end-to-end delay from a source, s, to a destination, d, in a
   multicast transmission should be no more than 50 msec (say) longer
   than the end-to-end delay of a unicast transmission from s to d.
   (Need to have good end-to-end delay to support full-duplex, real-time
   VoIP communications.)

-  Multicast should not artificially concentrate traffic on certain
   nodes or certain links (think rendez-vous points) since this can
   introduce unnecessary queueing delays and unnecessary packet loss
   in addition to unnecessarily long network paths and unnecessarily
   large end-to-end    latencies.

Rick

             Eiichi Muramoto                                               
             <muramoto.eiichi@                                             
             jp.panasonic.com>                                          To 
                                       [email-masked]                        
             06/20/2006 09:57                                           cc 
             AM                                                            
                                                                   Subject 
                                       [SAM]                               
                                       draft-irtf-sam-muramoto-generic-req 
                                       uire-00.txt                         

                                                                           

Hello all.

Regards,

-----