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