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

[Min Hui <[e-mail]>]

Hi, marcelo
Thanks for your comments, pls see my answers below.
- Hui Min

2009/3/16 marcelo bagnulo braun <[e-mail]>
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.

A: It is a routing problem, but it will affect the application to
choose a right interface, which is the key issue of mif. The reason is
the application will not appoint a source address in most situations
currently. The source address will be determined by host operating
system after querying the host routing table, if there is any
available routing item for the destination, the corresponding source
address of this routing item will be selected. In most cases, the
routing item of default gateway will be used, so that every
application will use the same interface. This problem can be solved in
IP layer, e.g. specify the source address of the application according
to the policy.


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

A: The problem is when the host gets multiple IP addresses for its
multiple interfaces, it will get multiple DNS addresses as well, so
that query  which DNS to obtain the IP address of a domain name is a
question needs to be solved. It is similar with the source address
selection problem. Could you give more explanation of dual faced DNS
you mentioned?



       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

A: I agree with you that comparing the metric of two different
networks is meaningless. However, the current operating system really
does this to choose routing among several different networks. 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. Internal policy is needed to adjust and modify
the metrics of different networks to work coherently, and it is what
the metrics consideration section wants to indicate.

     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...

A: As depicted in RFC1122, TOS is a necessary parameter to choose a
suitable routing. And different applications have different
requirements of access network, which can be reflected as TOS. So we
think TOS will be useful in multiple interface situations.


       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....

A: There is no problem that the source address would match the
outgoing network, the problem is how to select the right source
address for a specific application so as to deliver the data by the
right access network.

        3. Analysis of Related Work in IETF


I didn't find that section very useful actually.

A: Thanks for your doubt, we will think over it.

      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....

A: The meaning is the default gateway mechanism only support one
outgoing interface at once, we need to improve it to support multiple
interface simultaneously. The detail description of default gateway
problem can be seen in section 2.1.


 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

A: You are right, we will modify this bullet in the next version.

 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?

A: That is the policy in the network side. Corresponding to the policy
of sending data mentioned in the fourth bullet, the policy of
receiving data is also needed, which can be apply in the network side.
The network can determine forward a specific IP flow to which
interface of the destination host according to the policy.


Regards, marcelo




_______________________________________________
mif mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mif