IETF Logo Mail Archive

RE: Cost of multicast [was Re: Brokenness of specs w.r.t. client behaviorwith M&O bits]

"Manfredi, Albert E" <albert.e.manfredi@boeing.com> Tue, 14 October 2008 00:15 UTC

Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ipngwg-archive@lists.ietf.org
Delivered-To: ietfarch-ipngwg-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75B933A6944; Mon, 13 Oct 2008 17:15:17 -0700 (PDT)
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95D503A681B; Mon, 13 Oct 2008 17:15:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlKLWrxreYN2; Mon, 13 Oct 2008 17:15:14 -0700 (PDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id CA9A43A635F; Mon, 13 Oct 2008 17:15:14 -0700 (PDT)
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m9E0FH3H000239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Oct 2008 17:15:18 -0700 (PDT)
Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m9E0FHhf012829; Mon, 13 Oct 2008 19:15:17 -0500 (CDT)
Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m9E0FH3h012824; Mon, 13 Oct 2008 19:15:17 -0500 (CDT)
Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.72]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Oct 2008 20:15:17 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Cost of multicast [was Re: Brokenness of specs w.r.t. client behaviorwith M&O bits]
Date: Mon, 13 Oct 2008 20:15:16 -0400
Message-ID: <CA7D9B4A761066448304A6AFC09ABDA90331C41B@XCH-NE-1V2.ne.nos.boeing.com>
In-Reply-To: <200810132059.m9DKxiEq018367@cichlid.raleigh.ibm.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Cost of multicast [was Re: Brokenness of specs w.r.t. client behaviorwith M&O bits]
Thread-Index: Acktf14pXVs6UJyxQR+rd36kn/9V9AAELnzQ
References: <0DAA0914-0F69-49A1-96AF-ADD56EFBDFD9@muada.com> <200810132059.m9DKxiEq018367@cichlid.raleigh.ibm.com>
From: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
To: Thomas Narten <narten@us.ibm.com>
X-OriginalArrivalTime: 14 Oct 2008 00:15:17.0208 (UTC) FILETIME=[EFB7D580:01C92D91]
Cc: DHC WG <dhcwg@ietf.org>, IPV6 List Mailing <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

> -----Original Message-----
> From: Thomas Narten [mailto:narten@us.ibm.com] 

> My understanding is that when clients invoke DHC, and there are no
> DHCP servers, they backoff and retransmit, eventually stablizing as is
> governed by the following (from RFC 3315):
> 
>    MRT specifies an upper bound on the value of RT (disregarding the
>    randomization added by the use of RAND).  If MRT has a value of 0,
>    there is no upper limit on the value of RT.  Otherwise:
> 
>       if (RT > MRT)
>          RT = MRT + RAND*MRT
> 
> 
> In the case of solicit messages, MRT is set to 120 seconds. RAND is
> set to +/- .1, so the RT is capped at between 118 and 122 seconds.
> 
> So, clients will retransmit about once every 2 minutes.

This creates a long wait for the user, if his workstation was
misconfigured to use DHCP when none is available. Seems like a good
reason to keep the M&O flags, just to avoid that long wait?

> Did you read my original note carefully? In it, I pointed out that one
> concern against trusting the M&O bits was misconfiguration. You may
> think this scenario is rare to non-existant, but please acknowledge
> that others in the community may view the concern differently than you
> -- and indeed, may weigh this concern as more significant than your
> concern about additional multicast traffic.

It seems more likely that random clients would be misconfigured, though.

If the M&O flags are misconfigured, then the situation is not much
different from having no flags to begin with. The client would wait some
time before giving up, and using autoconfiguration. But in most cases,
the client can avoid the agonizingly long waits.

Possibly too, a case can be made that the clients' behavior does not
need to be uniquely specified by the IETF. "Use stateful addresses when
they are available" seems like it could be a viable strategy, without
having to incur that long wait to implement it.

Bert
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

v2.46.0 | Report a Bug | By Email | System Status