[16NG] question about RFC4840

"Wei Gengyu" <weigengyu@vip.sina.com> Tue, 17 April 2007 06:28 UTC

Return-path: <16ng-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdhB9-0007jk-Oo; Tue, 17 Apr 2007 02:28:39 -0400
Received: from 16ng by megatron.ietf.org with local (Exim 4.43) id 1HdhB8-0007je-5M for 16ng-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 02:28:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdhB7-0007jW-Q5 for 16ng@ietf.org; Tue, 17 Apr 2007 02:28:37 -0400
Received: from smtp.vip.sina.com ([202.108.3.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdhB3-0001TM-O1 for 16ng@ietf.org; Tue, 17 Apr 2007 02:28:37 -0400
Received: from DELLWEI (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id 3670544A4CF for <16ng@ietf.org>; Tue, 17 Apr 2007 14:28:23 +0800 (CST)
Message-ID: <000c01c780b9$934e3630$d936fea9@DELLWEI>
From: "Wei Gengyu" <weigengyu@vip.sina.com>
To: <16ng@ietf.org>
Date: Tue, 17 Apr 2007 14:28:12 +0800
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Spam-Score: 0.4 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Subject: [16NG] question about RFC4840
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0715536783=="
Errors-To: 16ng-bounces@ietf.org

Hi! all,

I have a prolem of rfc4840.

In section 2.2 multicast/broadcast: 

   In wireless media where data rates to specific destinations are
   negotiated and may vary over a wide range, it may be more efficient
   to send multiple frames via link-layer unicast than to send a single
   multicast/broadcast frame.  For example, in [IEEE-802.11.2003]
   multicast/broadcast traffic from the client station (STA) to the
   Access Point (AP) is sent via link-layer unicast.

It is because it usually is physical "unicast" from the STA to the AP.
It is the point to point link. 

As there is no words about the link from AP to STA,
the following recommendation seems to be problematic.   

   Recommendation: Where support for link-layer multicast/broadcast is
   problematic, limit the propagation of link-scope multicast and
   broadcast traffic by assignment of separate prefixes to hosts.  In
   some circumstances, it may be more efficient to distribute
   multicast/broadcast traffic as multiple link-layer unicast frames.
 
In many circumstances, it is less efficient to distribute multicast/broadcast 
traffic from AP to STA in multiple unicast frames.

I want to know what are the circumstances that the author wrote. 

Regards,

Gengyu
 
_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng