Subject: Re: [mif] Five additional problem statements for mif ---- host routing

From: Min Hui <[email-masked]>
Date: Wed, 18 Mar 2009 11:45:39 +0800

Hi, everyone

This is the first one: Host routing

The host routing currently 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 multiple interfaces situation, the default
gateway mechanism in host routing will let all the IP flows go out
through one interface except some specific assignment (e.g. static
routing item). In this case, the applications can’t use different
interfaces which are the aim of multiple interfaces. 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.
In conclusion, the above host routing mechanism is one of problems in
the way to maintain multiple interfaces work simultaneously.

- Hui Min

2009/3/18 Min Hui <[email-masked]>:
> 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
>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 17 Mar 2009 21:15:12 -0700

Hi,

well, you could also argue that the current source address selection  
is actually fine, and it's in fact the applications' fault, because  
they don't bind to a specific address. Not binding to an address is  
telling the OS "you choose for me". As long as there is only one  
interface, being lazy has no consequences, but if there are multiple  
interfaces, it does.

I agree that fixing this in the stack has distinct advantages over  
waiting for apps to be fixed, but I disagree that the current stack  
mechanism is broken - it isn't. It's the apps that are mostly broken.

Lars

On 2009-3-17, at 20:45, Min Hui wrote:

> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: Min Hui <[email-masked]>
Date: Wed, 18 Mar 2009 17:43:32 +0800

Hi, Lars

Thanks for your clarify. I also agree that app can bind a source
address to solve this problem, but it will be better if the stack can
do this.
I think we reach a consensus that there exists the problem of host
routing regardless whether the stack or app should be responsible for
this.
So would you please let me know what's your suggestion about the
description of this problem?

Thanks.

-Hui Min

2009/3/18 Lars Eggert <[email-masked]>:
> Hi,
>
> well, you could also argue that the current source address selection is
> actually fine, and it's in fact the applications' fault, because they don't
> bind to a specific address. Not binding to an address is telling the OS "you
> choose for me". As long as there is only one interface, being lazy has no
> consequences, but if there are multiple interfaces, it does.
>
> I agree that fixing this in the stack has distinct advantages over waiting
> for apps to be fixed, but I disagree that the current stack mechanism is
> broken - it isn't. It's the apps that are mostly broken.
>
> Lars
>