> Also, transport area may be well aware that this kind of per-packet splitting across links happens on a routinely at intermediary routers: two successive traceroutes rarely show same sequence.
Sure. Applications can deal with it, or they may suffer. Traffic load balancing in internet has always been there. But, there is a fundamental difference between splitting a flow between two redundant paths connected over high-speed links in the internet core, to splitting the same flow across two access two access-links to which a mobile node is attached. Can we split a audio flow on satellite access and DSL link and say its an application problem ? Is it not a network design problem and should it not be avoided ? > Again, the MIP work with flows has nothing to do with what we try do here. Please state some technical reasons. What we did in the past is the following. [cid:98EFB856-22C0-4936-9BD6-7F7497C8397F] Application Preferred Access Type Second Preference Third Preference HTTP BLUE RED <DROP> IPSec RED BLUE <DROP> SSH <DROP> <DROP> - SIP / RTP BLUE <DROP> <DROP> 1.) Ability to allow a mobile router to perform connection management; - Single Access Attach – Attach to the "best" available access network - Multi Access Attach – Attach to all available access networks 2.) Ability for the mobile router to register multiple care-of address with the anchor (MCOA Work which we did for 3 years) 3.) Ability to request IPv4 and/or IPv6 mobile network prefixes for the ingress network from the anchor 4.) Ability to establish multiple tunnel paths to the anchor to realize multi-path overlay topology from the mobile network to the anchor; So, to realize a bigger data pipe for the traffic associated with the mobile network prefixes 5.) Ability to negotiate a traffic flow policy on application basis; Most preferred access to least preferred access on application basis and ability switch the flows based on the path availability 6.) Ability to perform heart-beats for path management and to re-evaluate the flow policy 7.) Ability to support IPv4/IPv6 transport network, or IPv4/IPv6 mobile networks 8.) Ability to perform NAT translation on the "transport" network 9.) The anchor that is here is the HA/LMA/BNG/PGW/ which is used in Wi-Fi, LTE and Cable MSO accounts is the subscriber management function. There is charging, policy, infrastructure that is supported and deployed in todays networks. Now, if I fix the MR and nail the MR to a wall, what aspects of the above do not work ? Can the MR cannot be a CPE in home with LTE and DOCSIS access ? What is missing here ? Is it the per-packet load balancing ? Is there any thing more ? --> If you can summarize your answer for the above 9 points and just state it below it will help. Regards Sri On 11/11/14 8:07 AM, "Alexandru Petrescu" <alexandru.petre...@gmail.com<mailto:alexandru.petre...@gmail.com>> wrote: Le 11/11/2014 10:18, Sri Gundavelli (sgundave) a écrit : (We have started the technical discussion, but I do want to respond to this) Hi Hui, Current MIF charter prevent MIF from working on flow switch which is mostly mobile ip/dmm based solution, but it doesn't disallow MIF to work on flow split and per packet delivery. You are saying the charter disallows splitting of flows across two access networks, but it allows splitting of a single flow ? What is the logic here ? So, this requirement does not match the prior work because the flow policy is different ? That's the only reason why we should look at this as a different problem from the work that was done in the past ? Per-packet load balancing is probably not explicitly stated as transport group was never in favor of splitting a single flow across two access links with different transmission properties (latency, packet loss and jitter) as that will result in peers requiring to deal with re-odering/buffering issues. General recommendation was not to split a single flow, and so the MIP WG always kept the flow definition at the granularity of a flow-level and not at a packet level. That was then. Again, the MIP work with flows has nothing to do with what we try do here. When the transport are tells problems may arise with reordering it's because the MIP WG did not reply that (1) applications may deal with reordering and (2) the HA may deal with reordering. Also, transport area may be well aware that this kind of per-packet splitting across links happens on a routinely at intermediary routers: two successive traceroutes rarely show same sequence. Alex But, in any case that's just a policy that is exchanged between two peers. Regards Sri On 11/10/14 6:34 PM, "Hui Deng" <deng...@chinamobile.com<mailto:deng...@chinamobile.com>> wrote: Hi Sri, Current MIF charter prevent MIF from working on flow switch which is mostly mobile ip/dmm based solution, but it doesn't disallow MIF to work on flow split and per packet delivery. This is the key point that PS should explain the clearly. -Hui -----Original Message----- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Monday, November 10, 2014 4:23 PM To: Ted Lemon Cc: STARK, BARBARA H; Hui Deng; mif@ietf.org<mailto:mif@ietf.org>; Brian Haberman; Jouni Korhonen; pierrick.se...@orange.com<mailto:pierrick.se...@orange.com>; Dapeng Liu Subject: Re: Follow up with BBF proposal Hi Ted, Having a discussion in MIF WG sounds reasonable to me. Regarding homenet relation, I'm not sure it belongs to that WG either. The focus of the homenet is on ingress networks and for realizing simplified configurations and that has no relation to access selection on egress paths. FWIW, this work is very much related to what the MIP working group have been doing for many years. Sure, the device in case of BBF is a fixed device, but the fundamental requirements are about access selection, flow mobility and policy exchange. The flow mobility / MCOA work in MIP working groups have done significant amount of work in this area and the expertise is in that group. If the reason for steering this work away from DMM is due the belief that we will apply only MIP-based solution, I'd say the group will certainly do that, but the WG may also agree to additional solution/protocol mechanisms. Also, IETF is in no position to pick one protocol/solution for this requirement. It is probably reasonable for IETF to identify a set of solutions and present analysis on each of the solutions and that can be the basis for the BBF to review and pick one or more solutions. But, either way I believe the expertise around this topic is in DMM WG and not in homenet or in MIF WG's. Regards Sri _______________________________________________ mif mailing list mif@ietf.org<mailto:mif@ietf.org> https://www.ietf.org/mailman/listinfo/mif _______________________________________________ mif mailing list mif@ietf.org<mailto:mif@ietf.org> https://www.ietf.org/mailman/listinfo/mif
_______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
