Re: [mif] Follow up with BBF proposal

[Alexandru Petrescu <[e-mail]>]

Le 11/11/2014 20:22, Sri Gundavelli (sgundave) a écrit :
>
>  > 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.*

Where should I start?  Which (P)MIP document should I talk about?
(for reminder, please see our discussion in MIP4 about this a few years 
back)

> *What we did in the past is the following.*

[bitmap diagram of MR and HA skipped]

That figure is good on paper, but it does not augment bandwidth by 
itself.  It's just a way to show that both MR's connections are up at 
the same time.  They are not used to augment bandwidth.  There's only 
one default route that is used and it points to only one tunnel 
interface which in turn is bound to one single physical interface. 
Incoming packets may arrive on both interfaces but outgoing packets only 
go one interface.

I guess transport area will not be happy either to know that for one 
single application the outgoing packets always take a different path 
that incoming packets - assymmetry.


> *1.) Ability to allow a mobile router to perform connection management;*
> *
> *
> *- Single Access Attach – Attach to the "best" available access network*

I agree this is a feature and is highly needed for mobiles.  But 'best' 
means 'best first L2 hop' actually.

Here we talk a different thing.

> *- Multi Access Attach – Attach to all available access networks*

'Attach' is one thing, 'use' is another thing.

A mobile may be attached by many interfaces at the same time (ppp up, 
eth0 up, iwconfig up - all up) but the default route points to only one 
tunnel interface which in turn is linked to only one physical interface. 
  That's where bandwidth augmentation is not present.

> *2.) Ability for the mobile router to register multiple care-of address
> with the anchor (MCOA Work which we did for 3 years) *

Yes, but that's just registering the addresses.  It doesnt tell how to 
augment bandwidth, how to use simultaneously several such interfaces.

> *3.)  Ability to request IPv4 and/or IPv6 mobile network prefixes for
> the ingress network from the anchor*

Yes.

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

No, that 'so' is your 'so'.  There is no implementation that exhibits 
that bigger data pipe.

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

No, MIP has no ability to exchange such flow policy.

> *6.) Ability to perform heart-beats for path management and to
> re-evaluate the flow policy*

Sorry - which heartbeats?  There are no heartbeats in MIP.

> *7.) Ability to support IPv4/IPv6 transport network, or IPv4/IPv6 mobile
> networks*

What do you mean by 'mobile network'?

> *8.) Ability to perform NAT translation on the "transport" network*

I dont know what NAT translation means.

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

Sri - I disagree.  Neither PMIP nor MIP are used in these networks.  I 
dont know why you claim so.

> *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 ?*

Yes.

> *--> If you can summarize your answer for the above 9 points and just
> state it below it will help. *

Sri - you posted a feature list which is vaguely related to a list of 
RFCs.  It is a commercial advertisement for one particular router platform.

We can talk commercial advertisements if you wish, I have another such 
feature list ready to post.

Alex

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