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