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

[Min Hui <[e-mail]>]

Hi, marcelo

pls see my reply in line.

thanks.

- Hui Min

2009/3/17 marcelo bagnulo braun <[e-mail]>:
> Min Hui escribió:
>>
>> 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.
>>
>
>
> First of all, if i understand this correctly, what you want is that certain
> applications use a given interface and other applications use a different
> one, right?

You're right, it's the aim.
>
> On one hand, i see your point with this being related to routing cause if we
> have normal routing tbale,s we will use only one default route
> irresepctively of the application. so, in order to deal with this we need
> change that. I agree so far
>
> On the other hand, you seem to want to use the source address as a mean for
> the application to select the interface. I mean, if the application makes a
> bind to a given source address, and we are in the strong host model, that it
> will need to use the associated interface. This could work, but i think this
> is solution space. I mean, you could think of a different mechanism to bind
> a given app to an interface and then simply select the source address as it
> is currently done
>
> So, i think for a problem statement to be in good shape, you need to
> distinguish which are the problems and what is the solution

ok, thanks.

>>
>> 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?
>>
>>
>
> becuase this is only a problem if the DNS reply is different depending on
> the DNS server you use, right? I mean, if all the DNS servers in the
> different interfaces provide the same reply, then it is irrelevant which one
> do you choose, right?
> So, DNS servers provide different replies in multiple situations. But i
> think the most critical one is dual faced dns, in which the reply may simply
> not be valid if a differnet interface is used or you may be able to resolve
> a given query if the wrong dns server is used.

I understand your meaning, It is indeed a problem when each DNS server
provides different replies.

>>
>>       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.
>>
>>
>
> right, see your point. Again, harmonizing the metrics is one possible
> solution. You probably want to describe the problem and leave open how this
> can be solved
>
>
>>     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.
>>
>>
>
> right, my question was how widely used is this. I mean how much of the
> internet traffic actually sets the TOS?

The 3G network use TOS as one of the QoS parameters, and we suppose to
use it in the multiple interfaces situation.

>
>>       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.
>>
>>
>
> right, as we disucssed above, this seems to be more a result of a particular
> solution rather than a problem in itself

>
>>        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.
>>
>>
>
> right, i see what you mean now and i agree this is a problem
>
>
>>  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.
>>
>>
>
> right, i see what you mean. I am not sure which element of the network would
> do that... i mean, are you assuming that all interfaces are being connected
> to the same ISP? If not, i am not sure how would you do this...

In technical perspective,  the element would be the gateway which in
charge of all the interfaces, e.g. PDN GW in 3GPP architecture, LMA in
PMIP domain; In deployment perspective, it's better when all
interfaces connect to the same ISP, the negotiation is needed when
multiple ISP are involved.

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