Subject: Re: [MEXT] About flow binding directionality

From: Conny Larsson <[email-masked]>
Date: Wed, 26 Aug 2009 07:59:35 +0200

Hi Marcelo,

I believe the two alternatives that you describe below makes sense. I 
read the mail thread between you and Hesham and as Hesham I also believe 
that the MN is the natural point to take decisions on where to send 
specific data flows. However, there may be cases when the network has 
information and would like to influence which access a data flow should use.

Regards
Conny

marcelo bagnulo braun wrote:
> Hi,
>
> I have read the long discussion about this.
> It seems that in order for the HA to be able to send
> meaningful/useful information to the MN about a flow binding,
> either:
>
> 1- the HA knows something relevant that is not available to the
> MN about the path conditions between the HA and the different CoAs,
> or,
>
> 2- The HA has enough information to make a clue-full decision and
> we want to support a model where the network side influences the MN
> choices.
>
> Let me try to take a stab on those, and i am confident you will let
> me know what i am missing.
>
> Let's start by the first case i.e.
> 1- the HA knows something relevant that is not available to the
> MN about the path conditions between the HA and the different CoAs,
>
> Suppose the following scenario.
>
>     +-----+
>     | CN  |
>     +-----+
>        |
> +------------------+
> |      ISP3        |
> |                  |
> +------------------+
>        |
> +----------------------------------------+
> | Home Network                           |
> |                +----+                  |
> |                | HA |                  |
> |                +----+                  |
> |                 |  |                   |
> |        +--------+  +---------+         |
> |        |                     |         |
> +--------|---------------------|---------+
>         |                     |
>         |                     |
>   +------------+    +---------------+
>   | ISP1       |    | ISP2          |
>   |            |    |               |
>   +------------+    +---------------+
>       |                  |
>       |        +----+    |
>       +--------| MN |----+
>           CoA1 +----+ CoA2
>
>
> So, in case it is not obvious, i describe it a bit
> more in detail.
> Assume that the home network has 3 providers.
> ISP1 that is the same that it is providing one access to the MN ISP1 
> that is the same that it is providing the other access to the MN
> And ISP3, that is connected to the CN
>
> (i know this is a somehow forced example, but it is easily generalizable
> to more complex scenarios, where the HA could play a useful role in
> traffic engineering for the home network)
>
> So, for obvious reasons, the traffic flowing from the MN to the HA 
> through
> CoA1 will flow through ISP1 and the traffic flowing from the MN to the
> HA through CoA2 will flow through ISP2.
>
> Now, suppose that the link between the ISP1 and the home network is 
> becoming
> congested, or is about to reach the expected quota or whatever traffic
> management issue that is perfectly known to the home network.
>
> Since the HA, as it is located in the home network, it would make sense
> that the HA can have easy access to that circumstance and it would
> make sense that the HA asks the MN to move the traffic from the CoA1 
> to the
> CoA2.
>
> Of course, this is not all the information that is needed to actually 
> decide
> what is the best CoA, but i think that the point is that this is relevant
> information for the MN to have. Of course, the problem is that what if 
> the MN
> actually believes that the other CoA is the right one to use?
> I believe that this is up to the MN  policy and internal heuristics, 
> about
> how to make a reasonable decision considering all the input it has.
> At this point, the point that i am trying to make is that the HA may have
> access to information that the MN has not and if anything, if the MN
> has no preference, it can follow the HA suggestions.
>
> Does this makes sense to you?
>
> Let me try the second case i.e.
>
> The HA has enough information to make a clue-full decision and
> we want to support a model where the network side influences the MN
> choices.
>
> Now, in order for this work, we need to assume a bunch of things,
> which will certainly not be true in the general case, but may be
> true in some specific cases.
>
> First of all, we need to agree whether there is some value in allowing
> the HA (i.e. the network side) to micro manage the MN.
> If not, then, this case has no value.
> If yes, then i guess that under a set of assumptions, this can be done.
> I understand that the assumptions basically comes down to the things
> that are needed for the HA to have the information.
>
> So these assumptions include:
> - The HA knows what access is associated to each CoA
> - The HA knows the situation of the visited network, including
> the radio access link with the MN. This essentially
> implies that the HA and the visited network are the same admin domain.
> - The HA also knows the situation of the rest of the network, in order
> to have a full picture of the different paths.
> - The HA knows something about the flows. This can be achieved cause
> the apps running in the MN are managed by the network, or cause they
> usually use the well known ports in a reasonable way or because they
> the late binding approach (i.e. the HA moves the existent flows once
> it is aware of their characteristics e.g. the rate fo the flow)
>
> So, maybe the assumptions can be relaxed, but i think that the point is
> that under a set of assumptions that may match to a viable scenario,
> it is possible for the HA to manage the MN.
>
> So, does people agree that this is a viable scenario?
> And does people see any value in having the network side managing the MN?
>
> Fire up.
>
> We should try to wrap this up for ietf75....
>
> Regards, marcelo
>
>        _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext