Subject: [MEXT] early vs. late flow bindings

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 21 Jun 2009 11:58:55 +0200

Hi,

I would like to make a comment on the flow binding approaches.

First of all, i think it is important for this comment to clarify what 
is the minimum flow granularity we would like to support.
I personally believe that the _minimum_ unit of flow that we would like 
to specify that it needs to be forwarded through a given CoA can be 
expressed either as:
- src add, dst add, protocol, src port, dst port, or
- src add, dst add, SPI

So, do people think that we need to support higher granularity than 
this? I.e. that we need to send some packets of a TCP connection through 
one CoA and other packets of the same TCP connection through a different 
CoA?

So, for the rest of the argument, I will assume that with this 
granularity suffices
.
So, when we want to bind a flow to a give CoA, we can do an early 
binding or a late binging. Let me explain what i mean by that (in case 
it not obvious from the wonderfully intuitive terminology i selected)

A late binding would work as follows. The MN has a default CoA through 
which it receives all flows that have no binding. When the MN starts 
receiving a flow and the MN internal policy states that this particular 
flow should flow through an alternative CoA, it sends a flow binding 
message, saying that _this_ particular flow (identified either by the 
5-tuple (src add, dest add, src port, dest port, protocol) or by the 
3-tuple (src add, dst add, SPI)) is bound to an alternative CoA. When 
the HA receives this msg, it moves the flow to the right CoA.

An early binding is when the MN notifies the HA about what are the flow 
descriptors of flows that should be forwarded though each CoA. So, for 
instance the MN sends a flow binding saying that all packets addressed 
to port TCP 80 (irrespectively of the src and dst address) should be 
forwarded to a given CoA. So, whenever a packet arrives for port 80, it 
is directly forwarded to the selected CoA.

Now, the disadvantage of the late binding is that it requires sending a 
flow binding msg per new flow (so it is more overhead) and it is 
reactive, so the first packets of the flow would flow through the 
default CoA. the advantage of early bindings is that we don't really 
need to encode in the flow descriptors all kind of transport and 
application fields that describe a flow.

So, due to the aforementioned disadvantages of the early bindings, i 
don't think it is optimal to only use early bindings (even though it 
would be the cleaner approach imho). However, imho we can certainly use 
the late bindings for those flows that require more sophisticated flow 
descriptors. So, imho, we should support the IP packet fields and the 
protocol, src port and dst port as flow descriptors to be used in early 
bindings and let all the rest of the flows that cannot be properly 
described with these fields to be handled with late bindings.

comments?

Regards, marcelo

---

From: Yungui Wang <[email-masked]>
Date: Mon, 22 Jun 2009 11:16:09 +0800

Hello

Do we need to differentiate whether a binding is the early binding
or the late binding? It seems implementation-specific.

B.R.
Yungui

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of marcelo bagnulo braun
> Sent: Sunday, June 21, 2009 5:59 PM
> To: mext
> Subject: [MEXT] early vs. late flow bindings
> 
> Hi,
> 
> First of all, i think it is important for this comment to 
> clarify what is the minimum flow granularity we would like to
support.
> I personally believe that the _minimum_ unit of flow that we 
> would like to specify that it needs to be forwarded through a 
> given CoA can be expressed either as:
> So, do people think that we need to support higher 
> granularity than this? I.e. that we need to send some packets 
> of a TCP connection through one CoA and other packets of the 
> same TCP connection through a different CoA?
> 
> So, for the rest of the argument, I will assume that with 
> this granularity suffices .
> So, when we want to bind a flow to a give CoA, we can do an 
> early binding or a late binging. Let me explain what i mean 
> by that (in case it not obvious from the wonderfully 
> intuitive terminology i selected)
> 
> A late binding would work as follows. The MN has a default 
> CoA through which it receives all flows that have no binding. 
> When the MN starts receiving a flow and the MN internal 
> policy states that this particular flow should flow through 
> an alternative CoA, it sends a flow binding message, saying 
> that _this_ particular flow (identified either by the 5-tuple 
> (src add, dest add, src port, dest port, protocol) or by the 
> 3-tuple (src add, dst add, SPI)) is bound to an alternative 
> CoA. When the HA receives this msg, it moves the flow to the 
> right CoA.
> 
> An early binding is when the MN notifies the HA about what 
> are the flow descriptors of flows that should be forwarded 
> though each CoA. So, for instance the MN sends a flow binding 
> saying that all packets addressed to port TCP 80 
> (irrespectively of the src and dst address) should be 
> forwarded to a given CoA. So, whenever a packet arrives for 
> port 80, it is directly forwarded to the selected CoA.
> 
> Now, the disadvantage of the late binding is that it requires 
> sending a flow binding msg per new flow (so it is more 
> overhead) and it is reactive, so the first packets of the 
> flow would flow through the default CoA. the advantage of 
> early bindings is that we don't really need to encode in the 
> flow descriptors all kind of transport and application fields 
> that describe a flow.
> 
> So, due to the aforementioned disadvantages of the early 
> bindings, i don't think it is optimal to only use early 
> bindings (even though it would be the cleaner approach imho). 
> However, imho we can certainly use the late bindings for 
> those flows that require more sophisticated flow descriptors. 
> So, imho, we should support the IP packet fields and the 
> protocol, src port and dst port as flow descriptors to be 
> used in early bindings and let all the rest of the flows that 
> cannot be properly described with these fields to be handled 
> with late bindings.
> 
> comments?
> 
> Regards, marcelo
> 
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>

---

From: Jinwei Xia <[email-masked]>
Date: Mon, 22 Jun 2009 14:45:21 +0800

Hi Marcelo,

	Thank your clear clarification about flow bindings, some comments
are inline

>From the definitions of late and early flow binding, IMO it can be concluded
as reactive and preactive mode flow binding respectively. And the essential
difference is MN registers flow binding either voluntarily or triggered by
outgoing flow traffic, right? 

It seems to be a inner implement work of MN. In such case, this topic should
belong to the scope of MIF WG :-)

If I am wrong, please correct me, thank you~!

BR
	Jinwei

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 22 Jun 2009 09:24:25 +0200

Yungui Wang escribió:
> or the late binding?

probably not, but it does influences how much do we need to express the 
different flows

regards, marcelo

>  It seems implementation-specific.
>
> B.R.
> Yungui
>  
>
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 22 Jun 2009 09:26:09 +0200

> outgoing flow traffic, right? 
right
> It seems to be a inner implement work of MN.
that may be true indeed

>  In such case, this topic should
i don't think so... afaict mobility specific issues are explicitly out 
of the scope of mif and this is certainly mip specific, since it deal 
with signalling to the HA

Regards, marcelo

---

From: Nicolas Montavont <[email-masked]>
Date: Mon, 22 Jun 2009 12:38:45 +0200

Marcelo,

On Jun 21, 2009, at 11:58 AM, marcelo bagnulo braun wrote:

> First of all, i think it is important for this comment to clarify  
> what is the minimum flow granularity we would like to support.
> I personally believe that the _minimum_ unit of flow that we would  
> like to specify that it needs to be forwarded through a given CoA  
> can be expressed either as:
> this? I.e. that we need to send some packets of a TCP connection  
> through one CoA and other packets of the same TCP connection through  
> a different CoA?
>

Let say that it is enough "in a first time". I mean, I am not sure we  
have enough experience with splitting a single connection into  
multiple paths, so maybe it is better to propose a specification just  
for the granularity of the flow.

> binding or a late binging. Let me explain what i mean by that (in  
> case it not obvious from the wonderfully intuitive terminology i  
> selected)
>
> A late binding would work as follows. The MN has a default CoA  
> through which it receives all flows that have no binding. When the  
> MN starts receiving a flow and the MN internal policy states that  
> this particular flow should flow through an alternative CoA, it  
> sends a flow binding message, saying that _this_ particular flow  
> (identified either by the 5-tuple (src add, dest add, src port, dest  
> port, protocol) or by the 3-tuple (src add, dst add, SPI)) is bound  
> to an alternative CoA. When the HA receives this msg, it moves the  
> flow to the right CoA.
>
> An early binding is when the MN notifies the HA about what are the  
> flow descriptors of flows that should be forwarded though each CoA.  
> So, for instance the MN sends a flow binding saying that all packets  
> addressed to port TCP 80 (irrespectively of the src and dst address)  
> should be forwarded to a given CoA. So, whenever a packet arrives  
> for port 80, it is directly forwarded to the selected CoA.
>
> sending a flow binding msg per new flow (so it is more overhead) and  
> it is reactive, so the first packets of the flow would flow through  
> the default CoA. the advantage of early bindings is that we don't  
> really need to encode in the flow descriptors all kind of transport  
> and application fields that describe a flow.

I don't really see why you want to differentiate these two types of  
bindings flow to CoAs.
I think we need both, because you'll probably want to install rules a  
priori, but you'll probably need to re-distribute flows in real time  
once a flow started. The two drafts we are proposing support these two  
behaviors (draft-ietf-mext-flow-binding and draft-tsirtsis-mext-binary- 
filters)

Nicolas

> would be the cleaner approach imho). However, imho we can certainly  
> use the late bindings for those flows that require more  
> sophisticated flow descriptors. So, imho, we should support the IP  
> packet fields and the protocol, src port and dst port as flow  
> descriptors to be used in early bindings and let all the rest of the  
> flows that cannot be properly described with these fields to be  
> handled with late bindings.
>
> comments?
>
> Regards, marcelo
>

---

From: Yungui Wang <[email-masked]>
Date: Tue, 23 Jun 2009 08:14:42 +0800

Hello

What's your intent? 
Do you want to reflect the influence in flow binding, such as
making some parameters mandatory/optional, etc.? Or, do you want
to give us a guide to implement flow binding? Thanks.

B.R.
Yungui

> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Monday, June 22, 2009 3:24 PM
> To: [email-masked]
> Cc: 'mext'
> Subject: Re: [MEXT] early vs. late flow bindings
> 
> Yungui Wang escribió:
> > Hello
> >
> > Do we need to differentiate whether a binding is the early 
> binding or 
> > the late binding?
> 
> probably not, but it does influences how much do we need to 
> express the different flows
> 
> regards, marcelo
> 
> 
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >> Of marcelo bagnulo braun
clarify 
> >> what is the minimum flow granularity we would like to
> >>     
> > support.
> >   
would 
> >> like to specify that it needs to be forwarded through a 
> given CoA can 
> >> be expressed either as:
> granularity than 
this 
> >> granularity suffices .
early 
> >> A late binding would work as follows. The MN has a default
CoA 
> >> through which it receives all flows that have no binding.
> policy states 
> >> that this particular flow should flow through an 
> alternative CoA, it 
are the 
> >> should be forwarded to a given CoA. So, whenever a packet 
> arrives for 
> >> Now, the disadvantage of the late binding is that it 
> requires sending 
> >> a flow binding msg per new flow (so it is more
> flow would 
> >> flow through the default CoA. the advantage of early 
> bindings is that 
> >> we don't really need to encode in the flow descriptors all
kind of 
> >> transport and application fields that describe a flow.
> >>
> bindings, i 
> >> would be the cleaner approach imho).
> those flows 
> >> that require more sophisticated flow descriptors.
protocol, 
> >> src port and dst port as flow descriptors to be used in early