RE: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

You are right "money" is more operation related not technical side. However, I 
believe that this is also one of the most important factors and popularly has 
been used for determining an interface with an (access) network among multiple 
active interfaces automatically and dynamically. And, the mechanism to adopt or 
apply like this network characteristic into the routing policy on the network 
environment of simultaneous use of multiple interfaces may be deeply related 
with technical side regarding simultaneous use of multiple interfaces though.  

For instance, for a dual-mode device at home with WiFi and IP over cellular 
available (e.g. CDMA, GPRS/EDGE, etc), combination of various network 
characteristics in it would be the major factors to determine either WiFi or 
cellular for packet transmission. My point here is how to present those factors 
into the routing policy in order to determine a suitable interface with the 
type of *DATA or PACKET* for the transmission would be one of  the important 
technical side to be discussed in terms of simultaneous use of multiple 
interfaces.

However, according to Hui, it seems to be out of MIF scope described in the 
charter. BTW, again regarding MIF scope, I am wondering if we have already gone 
through a scenario for simultaneous use of multiple active interfaces based on 
a network environment with necessary associated network entities (from enabling 
attachment of multiple access networks to processing a packet transmission over 
the access networks from the link layer up to the transport layer) in order to 
identify the MIF scope (presented in the charter). If it has been already done 
or everyone understands clearly in terms of the MIF scope, it is OK. Otherwise, 
it would be good to practice it in order to clarify the MIF scope in the 
charter. 


Giyeong

-----Original Message-----
From: Hui Deng [mailto:denghui02(_at_)gmail(_dot_)com] 
Sent: April 19, 2009 11:40 AM
To: Giyeong Son
Cc: Ted Lemon; Ralph Droms; mif; ietf(_at_)ietf(_dot_)org; 
gen-art(_at_)ietf(_dot_)org; dhc WG; Black_David(_at_)emc(_dot_)com; Bernie Volz
Subject: Re: [mif] [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

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(_at_)rim(_dot_)com>:
> 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(_at_)ietf(_dot_)org 
> [mailto:mif-bounces(_at_)ietf(_dot_)org] On Behalf Of 
> Ted Lemon
> Sent: April 14, 2009 5:48 PM
> To: Ralph Droms
> Cc: mif; ietf(_at_)ietf(_dot_)org; Black_David(_at_)emc(_dot_)com; dhc WG; 
> gen-art(_at_)ietf(_dot_)org; 
> 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(_at_)ietf(_dot_)org
> 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(_at_)ietf(_dot_)org
> 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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf