Re: [PCN] RSVP and ECMP

[Hannes Tschofenig <[e-mail]>]

Hi Anna,

Anna Charny (acharny) wrote:
> Hi Hannes,
>
>   
>> The problems obviously show up if the load balancing device 
>> does not inspect the RSVP traffic.
>> Then, you cannot ensure that the signaling traffic follows 
>> the data traffic anymore.
>>
>>     
>
> Sorry, I did not quite understand your point.  Wouldn't a packet
> carrying RSVP message be processes just like any other packet in the
> node which is not RSVP-capable? 

Theoretically yes. It just depends on the behavior of the box. The RSVP 
packet is, however, not a data packet.
It looks different.

>  So all that matters for the discussion
> on using RSVP message as a probe is whether that packet goes the same
> way as the corresponding data packets of the same flow under ecpm
> decisions? 
Correct, and the question is: Is it possible that data traffic travels 
along a different path than the signaling traffic.
The answer is "yes" (unless you have control over the box making the 
decisions).

>  Am I missing the point you are making?
>
>   


Ciao
Hannes

> Anna
>
>   
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:[e-mail]] 
>> Sent: Thursday, October 25, 2007 6:14 AM
>> To: Georgios Karagiannis
>> Cc: [e-mail]
>> Subject: Re: [PCN] RSVP and ECMP
>>
>> The problems obviously show up if the load balancing device 
>> does not inspect the RSVP traffic.
>> Then, you cannot ensure that the signaling traffic follows 
>> the data traffic anymore.
>>
>> Also with tunnels you need to ensure that at least one of the 
>> tunnel endpoints is aware of the signaling protocol. This 
>> might seem to be a simple requirement but I assume in reality 
>> it is not that easy. This is the area where complexity says 
>> HELLO to path-coupled signaling.
>>
>> Ciao
>> Hannes
>>
>> PS: When you still think that it is totally trivial then you 
>> might want to look at the many tunneling schemes folks use or 
>> want to use.
>>
>> Georgios Karagiannis wrote:
>>     
>>> Hi Bruce, Hi all
>>>
>>> I agree with Bruce! If it is to use probing, then we have to ensure 
>>> that the probes should get the similar correct ECMP 
>>>       
>> treatment as the 
>>     
>>> correct ECMP treatment achieved by RSVP.
>>>
>>> This means that the probe messages have to have the same 
>>>       
>> addresses and 
>>     
>>> ports as the data.
>>> I think tat this is not difficult and not complex to be achieved.
>>>
>>> Best regards,
>>> Georgios
>>>
>>>
>>>
>>> On 10/23/2007, "Bruce Davie" <[e-mail]> wrote:
>>>
>>>   
>>>       
>>>> Michael,
>>>>  RSVP tries to forward the Path exactly the same way that it would 
>>>> forward the data. Since Path messages are processed outside of the 
>>>> fast path, it is possible for the router to look at 
>>>>         
>> anything that is 
>>     
>>>> in the path message, including source addr, dest addr, and port 
>>>> numbers, and figure out where a data packet that had those 
>>>>         
>> values in 
>>     
>>>> its IP header would get forwarded. It sends the Path 
>>>>         
>> message out that 
>>     
>>>> interface. In practice, this takes care of the vast 
>>>>         
>> majority of ECMP 
>>     
>>>> algorithms. This approach is implemented today.
>>>>
>>>>  If ECMP was using something from the IP or higher layer 
>>>>         
>> header that 
>>     
>>>> was not in the Path message, then a problem would arise.
>>>>
>>>>  So, practically speaking, if the probe messages have the same 
>>>> addresses and ports as the data, they should get correct ECMP 
>>>> treatment. Or at least, fare no worse than RSVP.
>>>>
>>>> Bruce
>>>>
>>>> On Oct 23, 2007, at 12:07 PM, Michael Menth wrote:
>>>>
>>>>     
>>>>         
>>>>> Hi,
>>>>>
>>>>> I've got a question regarding RSVP. PATH messages need to 
>>>>>           
>> be carried 
>>     
>>>>> over the same path as subsequent data packets. How is 
>>>>>           
>> this achieved 
>>     
>>>>> in the presence of ECMP routing? In theory, PATH messages 
>>>>>           
>> can take a 
>>     
>>>>> different route than data packets if the load balancer takes 
>>>>> arbitrary parts of the header(s) to calculate a suitable 
>>>>>           
>> hash value, 
>>     
>>>>> which decides which route the packet will take.
>>>>>
>>>>> This issue seems to be related to the problem of how to make sure 
>>>>> that PCN probe messages take the same path as subsequent PCN data 
>>>>> packets, provided that they have the same source and destination 
>>>>> ports and addresses.
>>>>>
>>>>> I am interested in how this problem is solved in practice 
>>>>>           
>> or whether 
>>     
>>>>> it is intentionally avoided.
>>>>>
>>>>> Regards,
>>>>>
>>>>>    Michael
>>>>>
>>>>> --
>>>>> Dr. Michael Menth, Assistant Professor University of Wuerzburg, 
>>>>> Institute of Computer Science Am Hubland, D-97074 Wuerzburg, 
>>>>> Germany, room B206
>>>>> phone: [phone], fax: [phone] 
>>>>> mailto:[e-mail]
>>>>> http://www3.informatik.uni-wuerzburg.de/research/ngn
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> PCN mailing list
>>>>> [e-mail]
>>>>> https://www1.ietf.org/mailman/listinfo/pcn
>>>>>       
>>>>>           
>>>> _______________________________________________
>>>> PCN mailing list
>>>> [e-mail]
>>>> https://www1.ietf.org/mailman/listinfo/pcn
>>>>     
>>>>         
>>> _______________________________________________
>>> PCN mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/pcn
>>>   
>>>       
>>
>> _______________________________________________
>> PCN mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/pcn
>>
>>     



_______________________________________________
PCN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pcn