[mif] about draft-hui-ip-multiple-connections-ps-02

marcelo bagnulo braun <marcelo@it.uc3m.es> Sun, 15 March 2009 19:18 UTC

Return-Path: <marcelo@it.uc3m.es>
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 A563028C0F1 for <mif@core3.amsl.com>; Sun, 15 Mar 2009 12:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.434
X-Spam-Level:
X-Spam-Status: No, score=-6.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, 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 Y1BOwket7kXe for <mif@core3.amsl.com>; Sun, 15 Mar 2009 12:18:32 -0700 (PDT)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 5688A28C0DD for <mif@ietf.org>; Sun, 15 Mar 2009 12:18:31 -0700 (PDT)
Received: from marcelo-bagnulos-macbook-pro.local (181.pool85-53-149.dynamic.orange.es [85.53.149.181]) by smtp02.uc3m.es (Postfix) with ESMTP id 46840656B03 for <mif@ietf.org>; Sun, 15 Mar 2009 20:19:10 +0100 (CET)
Message-ID: <49BD54AD.1080504@it.uc3m.es>
Date: Sun, 15 Mar 2009 20:19:09 +0100
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: mif <mif@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16522.001
Subject: [mif] about draft-hui-ip-multiple-connections-ps-02
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: Sun, 15 Mar 2009 19:18:33 -0000

Hi,

thanks for the draft, certainly is pointing to some relevant problems 
imho. I have some clarifying questions below...


2.1. Default Gateway

   The Windows operating system in the host follows the default gateway
   mechanism, which will choose the unify gateway among more than one
   default routes ('0.0.0.0'), the detail is described in RFC1122. The
   default gateway guarantees there always has a route to network when
   the host can not find a specific route for a datagram in the route
   table.

   But when it comes to multi-homing, the default gateway also causes
   all the flows go out through one interface, although there has more
   than one network connections.  Nowadays there are diverse networks
   can be chosen by the user, and the terminal have the capability and
   interfaces to connect to more than one networks at the same time. It
   is possible and necessary for the user to require connecting to
   different networks to ensure the best user experiences of different
   services, but the default gateway mechanism only allows one
   connection at once. Although you can connect your host to several
   networks physically, and each network has already assigned a IP
   address for your host interface, even you can see different default
   routes in the route table, all the flow goes to the default gateway
   chosen by the operation system other than different gateways actually.

I am not convinced the problem you want to point is well characterised 
in here. I mean, you seem to imply this is a routing problem, but then 
it seems (from your examples aboves) that what you really want is that a 
given application uses one interface and a different application use 
another one. This is not celar to me that it is a routing problem or 
that the IP layer is the right place to solve it.

 2.2.1. DNS consideration

   DNS will be configured to the interface manually or by DHCP procedure,
   and multiple interfaces will obtain multiple DNS. The host will
   reserve several DNS in this situation. Referring to different domain
   names the host should query proper DNS so that the domain names can
   be resolved. The problem is current DNS selection mechanism is lack
   to choose a right one for specific visited domain name, so that we
   need to merge multiple DNS to provide the host with the best
   connectivity.



This is only a problem in the case of dual faced dns, right?
Or are you considering other situations, like i dont know Web proxies 
and the like?
You may want to be more explicit abotu what is the problem you are 
aiming at, since it is easy to envision many situations where there is 
no aparent problem

         2.2.2. Metrics consideration

   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.

I would argue that if you are connecting to two different networks, 
comparing the metric does not make much sense, i guess. I mean, i 
understnad that comparing the metric make sense when the  routes belong 
the the same network. I woudl argue that in the case of a multihomed 
device, the most importnat aspect to choose a route over a different 
route over a different provider is internal policy

       2.2.3. TOS consideration

   TOS can be a parameter of routing item to indicate which kind of IP
   data is suitable to deliver by this routing. The multiple interfaces
   will connect to multiple access networks, so that the preference of
   TOS need to be merged to have a better performance of data delivery.
   For example, the WiFi access could indicate itself has broader
   bandwidth comparing with 2G access, and set the TOS as broad
   bandwidth. When another interface connects the Ethernet, the TOS is
   also set as broad bandwidth preferred. In this situation, it needs
   some mechanism to merge and reorder the TOS getting form multiple
   interfaces.

I am not sure how widely used is this...


         2.3. Source address selection for IPv4

   For the host has more than one IP addresses which are obtained by
   multiple interfaces, the source address selection is the key issue in
   order to use multiple interfaces reasonably. The application needs to
   select right source address so that the data will be delivered by the
   corresponding interface. This mechanism is lack currently which needs
   to be solved in multiple interfaces situation.

I understnad that the current practice is that the host will use the 
source address of the outgoing interface... would this practice have any 
issue? I mean, the source address would match the outgoing network. so 
it seems to do what it is expected....

          3. Analysis of Related Work in IETF


I didn't find that section very useful actually.


        4. Requirements for Simple IP Multi-homing

   Based on problem statements and related work analysis, the
   requirements for simple IP multi-homing is concluded and listed as
   follows:

   1) The host with multiple network interfaces should be capable to
   connect with different networks simultaneously.

i agree with this one

   2) The default gateway mechanism needs to be improved to support
   several gateways working at the same time.


not sure what you mean by this....

   3) New metric mechanism must be defined to adapt to various network
   cards nowadays.

this seems more a solution than a requirement. I mean, what is the 
expect behaviour that you want to support? maybe metrics is the right 
way to go or maybe some other approach would work

   4) The policies to assign different flows to the appropriate
   interface are required, and how to apply the policies to the host
   need to be considered as well.

right, this makes sense to me

   5 Network side should be capable of distributing the IP flow
   according to some parameters, such as IP address prefix, network type
   and so on.

i don't understnad what you mean by this one, could you expand?

Regards, marcelo