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

Min Hui escribió:
> Hi, marcelo
> Thanks for your comments, pls see my answers below.
> - Hui Min
>
> 2009/3/16 marcelo bagnulo braun <marcelo@it.uc3m.es>
> 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?

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

>        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...
> Regards, marcelo
>
>
>
>
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
>
>   