Hi, Giyeong, At least those are not in the current charter scope. but Ted gave a one potential solution on one problem. Regarding to Money et al, I think IETF is not going to talk about it. which is more operational recommendation. Operation could recommend the benchmark to let the user to select what he favoriate by human language other than technical language. thanks -HUi 2009/4/15 Giyeong Son <gson@xxxxxxx>: > I think Ted pointed out very interesting but crucial problems if I > understood correctly. So, I'd like to confirm what Ted indicated and > emphasized: > > 1. How to dynamically/automatically/efficiently enable and manage > multiple active interfaces on a host? > 2. How to utilize multiple active interfaces on a host? > 2. What are the efficient (or cost-effective) routing decision policy? > Is it least cost routing policy? Or other? If it is least cost routing > policy, what are the costs? Are they "money" to use the connection (e.g. > WiFi vs. cellular), "time" to spend for the transmission, "reliability" > of the transmission, etc? > > If those are what Ted indicated, I am also interested in asking if the > above things are in scope of MIF. Based on my experience in terms of > simultaneous use of multiple interfaces, the aboves are the most > critical and interesting issues in practice in order to utilize the > network environment of simultaneous use of multiple interfaces reliably > and efficiently. > > > Giyeong > > -----Original Message----- > From: mif-bounces@xxxxxxxx [mailto:mif-bounces@xxxxxxxx] On Behalf Of > Ted Lemon > Sent: April 14, 2009 5:48 PM > To: Ralph Droms > Cc: mif; ietf@xxxxxxxx; Black_David@xxxxxxx; dhc WG; gen-art@xxxxxxxx; > Bernie Volz > Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00 > > On Apr 14, 2009, at 3:31 AM, Ralph Droms wrote: > >> Now, I admit I'm describing a hypothetical and abstract scenario. I >> don't have a specific example of a situation in which a host might >> make decisions - either in the stack or in an application or ??? - >> about outbound traffic based on knowledge of how that traffic would be > >> forwarded by the RG. > > That's right. But I think it's not an accident that this is a > hypothetical scenario. In reality, a scenario like this has been > likely ever since wireless and wired network interfaces became > standard on laptops. And yet we don't have any real-life examples of > problems that this has caused, which need solving. To me, that seems > like an indication that this is not a real operational problem. That > is, that the answer "if two DHCP servers send the same client > conflicting information on two different interfaces, that is a > misconfiguration, and should be solved by correcting the > misconfiguration" is, in practice, the correct answer. > > If it were not, we would be hearing about concrete, real-world scenarios > of the type you describe, not about hypothetical ones. > > I don't mean to minimize this issue - if in fact there is some future > real-world scenario where this would be a serious problem, it would be > good if we could anticipate it. It might be profitable to consider > analogies. > > For instance, right now I have IPv6 set up at home. Because IPv6 > isn't deployed at all in Tucson, the way I have this working is by > tunneling. Since there are two tunnel brokers offering service for > people like me, and I am a bit adventurous, I have two tunnels. > Right now, every IPv6 packet I ever transmit goes out one of those > tunnels, with the exception of packets destined for a specific net, for > which I have defined a static route. > > First of all, this scenario works just fine. Both tunnels are > configured as a default route - it just happens that Linux's route > selection process always chooses the first one. This algorithm would > work poorly if one interface were preferable to the other, but since > both are equivalent it's not a problem. > > Second, though, why do I have a default route configured? It's > because I'm talking to a node on that network that will only answer if I > use the source address of one of the tunnels; and will ignore any > packets I send it with the other source address. So in the case > where there was a problem, I manually configured a workaround. > > How could we automatically solve this problem? Simple: any time we > are initiating communication with a device on the network, and do not > know that the communication is going to work, we simultaneously start > the communication in every plausible way. So suppose that there are > two AAAA records corresponding to the machine I want to talk to, and I > have two global IP addresses. I'm going to send four syn packets. > The first syn-ack I get back is the one I'm actually going to use - I'll > send RST packets to the other three. > > This is analogous to the solution Stuart Cheshire described a couple of > IETFs ago to the problem of IPv6 causing connectivity problems instead > of expanding connectivity opportunities - you can't prefer one solution > over the other, because you have no basis for doing so, so you have to > try all possible solutions and choose the one that works > best. My only extension, if it is one, is that I've added the source > address to the matrix - I'm not sure Stuart mentioned that. > > Now, how does this extend when we go to DHCP? Suppose I have DNS > resolver configurations from two DHCP servers. I try both in > parallel. I can winnow it down a bit: since I received the DNS > server information from one DHCP server on one interface, and the DNS > server information from the other DHCP server on a different interface, > I only have to try to query the DNS server using the source addresses of > the interface on which that DNS server's configuration information was > received. > > But how do I do that if the device that has two interfaces is not the > device originating the query, as is the case with the container > option? I think the answer is that I can't. There is no heuristic > that I can define that will always make the right choice, because the > device receiving the container options has to make the choice for the > client. > > In DHCPv6, we could at least give the client a hint about what to do as > follows: > > Suppose that I am dual-homed. I ask for, and get, a container option > on both outward-facing interfaces. I also wind up configuring one or > more prefixes as a result of my communication with the DHCPv6 server > on these two interfaces. I wind up advertising prefixes to the > client based on the answers that I get on both outward-facing > interfaces, so for example if I get a single prefix delegation from > each DHCPv6 server, I will advertise two prefixes to the client. So > when the client asks for, and gets, IA_ADDR configurations for both > prefixes, I include the container option information from each DHCPv6 > server in the IA_ADDR option for the prefix provided by that DHCPv6 > server. Now the client has enough information to make a choice - it > can use the source address for the prefix from a DHCP server to > communicate with the DNS servers provided by that DHCP server. > > But this requires a great deal of complexity on the client, and on the > server. Is this complexity that we want? And we haven't even > talked about the case where either due to cost considerations, or due > to speed considerations, one interface is preferable to the other. > How would we communicate that? How would we configure that? > Supposing that one prefix is more expensive than another, does the > client then not try the expensive prefix until it's timed out on the > cheap prefix? What does that look like to the end-user? Does it > fail gracefully? > > So I think it's an interesting problem space. And actually I think > that you could come up with heuristics that would work most of the time, > potentially at the cost of increased load on name servers, and increased > network usage, and the occasional $1000 cellular data > bill. But to come up with heuristics that will work the right way > every time, I think that is very difficult. > > _______________________________________________ > mif mailing list > mif@xxxxxxxx > https://www.ietf.org/mailman/listinfo/mif > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > _______________________________________________ > mif mailing list > mif@xxxxxxxx > https://www.ietf.org/mailman/listinfo/mif > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf