Re: [mif] Follow up with BBF proposal

["Sri Gundavelli (sgundave)" <[e-mail]>]

> 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" <[e-mail]<mailto:[e-mail]>> 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" <[e-mail]<mailto:[e-mail]>> 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:[e-mail]]
Sent: Monday, November 10, 2014 4:23 PM
To: Ted Lemon
Cc: STARK, BARBARA H; Hui Deng; [e-mail]<mailto:[e-mail]>; Brian Haberman; Jouni
Korhonen; [e-mail]<mailto:[e-mail]>; 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mif



_______________________________________________
mif mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mif