Re: [MEXT] weird idea about flow bindings

[Hesham Soliman <hesham at elevatemobile.com>]

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

> Hesham Soliman escribió:
>> 
>> 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 we don't need negotiation for this right?
> the only thing that we need is that the CN sets different flow label
> values for different flows. for isntnace if each socket uses a different
> flow label, then we are ok i think

=> Yes I understand, I was responding to the comment about RFC 3697. The
other point is, the CNs didn't set that field at all (last time I checked).
Until that happens, no one can use it for anything. It would be good to know
if that behaviour has changed.

>> 
>> => Makes sense to recommend that, but of course the spec needs to offer both
>> options for the reasons above.
>> 
>>   
> mmm, i am not sure i understand what you suggest we need to support in
> the spec.
> 
> I think that we could simply support flow descriptors  as follows:
> MUST support flow descriptors based on IP header
> MAY support flow descriptors based on transport header
> 
> I would be silent about other flow descriptors. In particular, i would
> not define in the spec means to use app data bits as flow descriptors.
> 
> would that make sense to you?

=> Yes that works for me but I suspect that people will treat the MAY above
in the same way as a MUST when it comes to implementation.

Hesham


> 
> Regards, marcelo
> 
>> 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
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>   
>>>>>>       
>>>>>>           
>>>> 
>>>>   
>>>>       
>> 
>> 
>> 
>>   
>