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

["Giyeong Son" <[e-mail]>]

My comment with "Giyeong>>"

Giyeong 

-----Original Message-----
From: Hui Deng [mailto:[e-mail]] 
Sent: April 21, 2009 6:34 AM
To: Giyeong Son
Cc: Ted Lemon; Ralph Droms; mif; [e-mail]; [e-mail]; dhc WG; [e-mail]; Bernie Volz
Subject: 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.
==> such network characteristic could become a generic routing element which do decide whether to use this routing or interface or not, but IETF not necessraily mention it is "Money" or else. and also if it is not "flat rate" based, I guess that host will be not so suffcient intelligent to lead the routing based on the price like pennys or dollars.

Giyeong>> I agree. It does not need to *explicitly* indicate or utilize "Money" in IETF. But, as you mentioned, it would be better to provide a recommendation to provide the way or mechanism to present that kind of network characteristics to be mapped to generic elements by MIF or other working group in order to decide routing. 

>
> 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.
==> Reply same as the above

>
> 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.
==> Current charter says best current practice, and problems tatement, those work will be done after the re-charter.

thanks

-Hui
>
>
> Giyeong
>
> -----Original Message-----
> From: Hui Deng [mailto:[e-mail]]
> Sent: April 19, 2009 11:40 AM
> To: Giyeong Son
> Cc: Ted Lemon; Ralph Droms; mif; [e-mail]; [e-mail]; dhc 
> WG; [e-mail]; 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 <[e-mail]>:
>> 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: [e-mail] [mailto:[e-mail]] On Behalf Of 
>> Ted Lemon
>> Sent: April 14, 2009 5:48 PM
>> To: Ralph Droms
>> Cc: mif; [e-mail]; [e-mail]; dhc WG; 
>> [e-mail]; 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
>> [e-mail]
>> 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
>> [e-mail]
>> 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.
>

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