Re: [MEXT] weird idea about flow bindings

[Hesham Soliman <hesham at elevatemobile.com>]

On 18/05/09 12:15 AM, "marcelo bagnulo braun" <marcelo at it.uc3m.es> wrote:

> Hesham Soliman escribió:
>> Thanks fpr the long version! Yes it works of course. That's why I agree that
>> it should be in every filter descriptor. However, since it's not currently
>> used at all,
> i woudl actually like to get data about this assertion. Are you certain
> that current OSes don't implement RFC3697?

=> RFC3697 mainly states requirements. Last time I checked there was no one
using the flow label in the API and there were no flow label negotiations
except, say SIP. But it would be interesting to see if anyone is actually
using it. The point is, even if 80% of implementations are using it, we
can't make it the only was of defining flows.

> 
>>  I don't think we can remove upper layer information. We need to
>> allow both to exist until the flow label is actually used. So, to summarise:
>> yes by all means we have to make sure it's in every spec defining filters
>> (which this draft is not btw), but not the only way of defining filters.
>> We should also make sure the SPI is one of those parameters for instance.
>>   
> Ok, this is where i come from.
> I don't have any problem whatsoever with using any IP layer information
> as a flow descriptor. So, SPIs are perfectly ok to me.
> I have a little problem with using transport layer information.
> Especially cause if the traffic is encrypted, we need to fall back to
> something else. 

=> Sure. Like SPI for example :)

 In any case, there are a few transports, that are pretty
> stable and we can rely on hardcoding where to look inside the packet to
> determine what is a flow (modulo the encrypted packets)
> I do have a big problem with using application layer information as a
> flow descriptor. I mean, there are millions of different apps and new
> apps are defined everyday and a not so limited number become widely
> used. I think using app bits in MIP signalling is simply a very bad
> idea. For example, let's take for instance an app protocol that it is
> propietary and it is widely used (skype for instance). You have no
> certainty which bits to look.

=> I don't advocate the use of app information either.

> 
> So, my preference here would be to:
> - use IP header info in any way you want (recommended approach,
> especially since the flow label approach can discriminate every flow)
> - maybe use transport info
> - don not use application layer information in any case.
> 
> Makes sense?

=> Makes sense to recommend that, but of course the spec needs to offer both
options for the reasons above.

Hesham

> 
> Regards, marcelo
> 
>> Hesham
>> 
>> 
>> On 17/05/09 10:58 PM, "marcelo bagnulo braun" <marcelo at it.uc3m.es> wrote:
>> 
>>   
>>> ok, let me try again because it seems i am failing miserably to
>>> communicate what i want to say (or it simply so broken that people
>>> cannot believe what they are reading :-)
>>> 
>>> Let's try with an example.
>>> 
>>> We have the MN who has two CoAs, CoA1 and CoA2.
>>> 
>>> The MN has a policy that says that it wants flows from app1 to be
>>> exchanged through CoA1 (well, the policy would say that they should be
>>> received by the interfece in which CoA1 is configured) and that flows
>>> from app2 to be exchanged through CoA2 (same comment about the interface
>>> applies here)
>>> 
>>> In addition, MN has defined CoA1 to be the primary CoA i.e. the CoA with
>>> highest priority.
>>> 
>>> So, we have two different situations. Either the MN starts the
>>> communication or the CN starts the communication. Actually, this is
>>> pretty irrelevant, cause the two directions of a connections are handled
>>> independently. the MN will send packets from app1 through CoA1 and
>>> packets from app2 through CoA2 and it doesn't need any additional
>>> actions from the HA for outgoing packets.
>>> 
>>> Now, the difficulty is with incoming packets. the MN needs to inform the
>>> HA about which CoA it wants to use to receive any flow.
>>> 
>>> Suppose that the HA has no flow bindings for the MN so far.
>>> 
>>> So, suppose that the app1 in CN starts a flow to the MN. The HA will
>>> receive the packet and will send it though the CoA1 cause it is the one
>>> with higher priority. the MN is happy and there is no need to do
>>> anything else.
>>> 
>>> Suppose now that the app2 in the CN starts a flow to the MN. According
>>> to RFC3697, the CN SHOULD assign a different flow label to the packets
>>> belonging to this flow e.g. to this TCP connection. Let's assume it is
>>> actually a TCP connection to make the example more concrete.
>>> So, app2 opens a TCP connection to MN. CN then sends the TCP SYN to the MN.
>>> The HA receives the TCP SYN and since there is no flow binding state for
>>> this flow it forwards it through the CoA1 (the one with highest priority)
>>> The MN receives the TCP SYN through CoA1 and it realizes that this is
>>> not compliant with its flow policy. So, it extracts the flow label
>>> value, the src address and the dest address and it sends a BU to the HA
>>> stating that the flow identified by the flow label, src add and dest add
>>> needs to be bound to the CoA2.
>>> Simultaneously, it also sends the TCP SYN+ACK back to the CN.
>>> The CN receives the TCP SYN+ACK and sends the Ack back. the HA receives
>>> the ACk and will forward it based on the flow binding, i.e. through the CoA.
>>> 
>>> the result is a method that never looks into higher layer information
>>> for setting the flows.
>>> 
>>> makes sense?
>>> 
>>> Regards, marcelo
>>> 
>>> 
>>> Hesham Soliman escribió:
>>>     
>>>> On 17/05/09 3:04 PM, "marcelo bagnulo braun" <marcelo at it.uc3m.es> wrote:
>>>> 
>>>>   
>>>>       
>>>>> Hesham Soliman escribió:
>>>>>     
>>>>>         
>>>>>> The flow label should be part of any filter descriptor anyway. So at
>>>>>> anytime
>>>>>> A MN can send a BU specifying that packets with flow label X should be
>>>>>> directed to CoA1. I'm not sure how your proposal changes/adds to this.
>>>>>>   
>>>>>>       
>>>>>>           
>>>>> what i am saying is that you don't need anything else other than this
>>>>>     
>>>>>         
>>>> => see below
>>>> 
>>>>   
>>>>       
>>>>>> As a general issue, the flow label is unlikely to be used for this
>>>>>> purpose
>>>>>> until we resolve it's mutability issues
>>>>>>       
>>>>>>           
>>>>> what mutability issues are you referring to?
>>>>> AFAIU, the flow label is set randomly b the source and remains unchanged
>>>>> e2e and for the duration of the flow.
>>>>>     
>>>>>         
>>>> => I thought RFC 3697 talked about it being changed en route then changed
>>>> back before it hits the destination. But I just scanned it and I can't find
>>>> this text. Maybe it was never included.
>>>> 
>>>>   
>>>>       
>>>>>>  and until it is actually _used_ in
>>>>>> the API. At least until recently no one was using it.
>>>>>>   
>>>>>>       
>>>>>>           
>>>>> why do we need to have it in the API? It is only imporntat the the
>>>>> source sets it to a random value and keep it unchenged e2e and for the
>>>>> duration of the flow. I understand that these conditions are met today,
>>>>> right?
>>>>>     
>>>>>         
>>>> => But are you saying the src MIP6 module overwrites the potential flow
>>>> label set in the API? Because it is possible that an app sets the flow
>>>> label. RFC 3697 assumes the presence of an e2e mechanism to negotiate the
>>>> flow label. If not then how do you make sure it's always unique? And how do
>>>> you make sure that the CN echoes back the same value in the flow label?
>>>> And what if the CN initiated the connection?
>>>> 
>>>> Hesham
>>>> 
>>>> 
>>>> 
>>>> 
>>>>   
>>>>       
>> 
>> 
>> 
>>   
>