Re: [mif] Five additional problem statements for mif----Different metric measurements
Lars Eggert <lars.eggert@nokia.com> Wed, 18 March 2009 04:19 UTC
Return-Path: <lars.eggert@nokia.com>
X-Original-To: mif@core3.amsl.com
Delivered-To: mif@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A20BD3A6802 for <mif@core3.amsl.com>; Tue, 17 Mar 2009 21:19:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.304
X-Spam-Level:
X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599]
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 9Ne6q35RgMjd for <mif@core3.amsl.com>; Tue, 17 Mar 2009 21:19:33 -0700 (PDT)
Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id B2B6B3A698B for <mif@ietf.org>; Tue, 17 Mar 2009 21:19:32 -0700 (PDT)
Received: from 12-187-233-228.att-inc.com (12-187-233-228.att-inc.com [12.187.233.228] (may be forged)) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n2I4K8Fq039348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Mar 2009 06:20:10 +0200 (EET) (envelope-from lars.eggert@nokia.com)
Message-Id: <8A156E63-2833-4BB0-8B8C-A79D07F7899D@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: Min Hui <huimin.cmcc@gmail.com>
In-Reply-To: <5dca10d30903172052h16ad160cv99df5f7e0254aedb@mail.gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail-90--802713305"; micalg="sha1"; protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Tue, 17 Mar 2009 21:20:07 -0700
References: <5dca10d30903172052h16ad160cv99df5f7e0254aedb@mail.gmail.com>
X-Mailer: Apple Mail (2.930.3)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [195.148.124.194]); Wed, 18 Mar 2009 06:20:11 +0200 (EET)
X-Virus-Scanned: ClamAV 0.94.2/9126/Wed Mar 18 01:07:14 2009 on fit.nokia.com
X-Virus-Status: Clean
Cc: mif <mif@ietf.org>
Subject: Re: [mif] Five additional problem statements for mif----Different metric measurements
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Mar 2009 04:19:34 -0000
Hi, On 2009-3-17, at 20:52, Min Hui wrote: > This is the third one: Different metric measurements > > Metrics are used to measure the performance of routings, the lower > metric it owns, the higher priority it has. For example, the default > gateway is chosen based on the metric rule as RFC1122 description, The > one have the lowest metric value becomes to the default gateway among > several connected gateways, and the interface correspond to this > gateway turns to be the default interface. RFC1122 Section 3.3.4.3 only talks very broefly about using "preference" as a tie breaker and doesn't talk about metrics. Did you mean to point to a different RFC? > Metric rules are different depending on the access technology and > routing protocol, if the multiple interfaces connect to multiple > access networks which have different measurements of metrics, the > comparing of metrics will be meaningless. However, the current > operating system really does this to choose routing among several > different networks in multiple interfaces situation. For example, > current metric rules define the 100M bps Ethernet network card to be > 20 and 10M bps to be 30, but the CDMA data card set its metric value > as 1, although its speed is lower than 100M bps Ethernet network card, > and the host will choose the CDMA data card as the default network > card. This problem confuses the selection of routing in multiple > interfaces situation. See above - I don't think what you describe is actually defined in RFC1122 (or at least, I can't find it there). Is this something that we have an RFC about, or is this something you have observed in some stack implementations? Thanks, Lars > > - Hui Min > > 2009/3/18 Min Hui <huimin.cmcc@gmail.com>: >> Hi, all mif fans >> >> I have viewed the agenda of mif bof, and I notice some problem >> statements for mif are not concluded in the current ps documents >> which >> will be discussed in the meeting. >> So I post these additional problems in the mail list for discussion, >> all of them come from the draft >> "draft-hui-ip-multiple-connections-ps-02" with some modifications >> according to the comments received recently. >> There are five problems in addition, which will be proposed in five >> separated mails in order to have sufficient discussion for each of >> them. >> Five mails will be sent out following this mail, the structure is: >> 1. Host routing >> 2. DNS selection >> 3. Different metric measurements >> 4. Source address selection for IPv4 >> 5. TOS consideration >> >> Any comment is welcomed, and thanks for your notice. >> >> BR, >> - Hui Min >> > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif