[dhcwg] WLAN (was Re: IPv6 Host Configuration of Recursive DNS Server)

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Tue, 08 June 2004 08:43 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11063; Tue, 8 Jun 2004 04:43:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXc8n-0000Wg-E0; Tue, 08 Jun 2004 04:39:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXc1x-0007d6-MS for dhcwg@megatron.ietf.org; Tue, 08 Jun 2004 04:32:26 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10288 for <dhcwg@ietf.org>; Tue, 8 Jun 2004 04:32:23 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXc1u-0004Mm-Pq for dhcwg@ietf.org; Tue, 08 Jun 2004 04:32:22 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXc0w-0003gp-00 for dhcwg@ietf.org; Tue, 08 Jun 2004 04:31:23 -0400
Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by ietf-mx with smtp (Exim 4.12) id 1BXc0B-00030q-00 for dhcwg@ietf.org; Tue, 08 Jun 2004 04:30:35 -0400
Received: (qmail 10129 invoked from network); 8 Jun 2004 08:24:50 -0000
Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 8 Jun 2004 08:24:50 -0000
Message-ID: <40C57A46.2030805@necom830.hpcl.titech.ac.jp>
Date: Tue, 08 Jun 2004 17:35:18 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: ja, en-us, en
MIME-Version: 1.0
To: dnsop-v6conf@nominum.com
References: <DAC3FCB50E31C54987CD10797DA511BA096341CF@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA096341CF@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Cc: V6OPS WG <v6ops@ops.ietf.org>, dnsop@lists.uoregon.edu, Jaehoon Paul Jeong <paul@etri.re.kr>, IPv6 WG <ipv6@ietf.org>, DHC WG <dhcwg@ietf.org>
Subject: [dhcwg] WLAN (was Re: IPv6 Host Configuration of Recursive DNS Server)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: 7bit

Dear all;

The problem is rather generic than DNS configuration. But...

I know ND is wrong. That is, I know it is wrong to have generic
link protocols ignoring link specific properties and has been
pondering on how such protocols suffer.

I just recently noticed that WLAN (802.11*) is not very good at
supporting ND (nor DHCP nor any broadcast/multicast protocol).

Because WLAN use CSMA/CA, it needs ACK for reliable transmission
by confirming that each packet reaches its destination without
collision.

However, with broadcast/multicast packets, there is no ACK for
an obvious reason.

If WLAN is lightly loaded, it is not a serious problem.

However, if WLAN is heavily loaded, ND (and DHCP and any broadcast/
multicast protocol) works poorly. Note that MIPv6 works poorly
too. 

Still, management beacon frames are transmitted frequently
and expected to carry information in a long run.

So, it is possible to piggyback broadcast/multicast part
of address resolution and autoconfiguration (maybe and
routing) in reserved fields of beacon frames.

Though  it is possible to use some data frame frequently
transmitted like beacon frams, it make the already congested
WLAN worse.

Anyway, the fundamental mistake is to try not to have link
specific ways to perform address resolution and autoconfiguration.

DHCP simply needs link specific ways of DHCP discover.

ND needs, IMHO, a lot more.

Note that modifying WLAN protocol to use PIFS is not enough
unless combined with frequent transmission.

						Masataka Ohta


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg