Subject: [Fwd: Re: [FORCES] I-D ACTION:draft-khosravi-forces-tcptml-01.txt]

From: Patrick Droz <[email-masked]>
Date: Thu, 3 Mar 2005 10:44:55 +0100

sorry I did not do a replay all.

Regards,
Patrick

-------- Original Message --------
Subject: Re: [FORCES] I-D ACTION:draft-khosravi-forces-tcptml-01.txt
Date: Thu, 03 Mar 2005 10:32:51 +0100
From: Patrick Droz <[email-masked]>
Organization: IBM Research
To: Khosravi, Hormuzd M <[email-masked]>
References: <468F3FDA28AA87429AD807992E22D07E046D56CA@orsmsx408>

Hi Hormuzd,

see comment inline.

Khosravi, Hormuzd M wrote:

> Robert,
> 
> Thanks for your feedback! Pls see my comments inline below... 
> 
> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:[email-masked]] On Behalf Of Robert Haas
> 
> I think we also have to provide a way to transport redirected packets 
> from the FE to the CE _without_ any encapsulation, i.e. _raw_
> redirection.
> 
> The bad-length case raised by Joel could be supported with 
> encapsulation, as it anyway remains a corner case. And I don't think it 
> is difficult to distinguish such raw redirected packets from PL 
> messages, nor to prevent DoS by setting shapers in the FE. My main 
> motivation is to free the FEs from an unnecessary encapsulation load.
> 
> [HK] The biggest issue that I see for not encapsulating the redirected
> packets in the PL header is interoperability. This is clearly a
> tradeoff, you might get slightly better performance if you avoid any
> encapsulation (although we haven't noticed any performance issues here)
> but at the cost of Interoperability, bad-length case that Joel pointed
> out, loss of protocol-inbuilt DoS prevention mechanisms, etc. IMHO,
> Interoperability alone clearly out weighs any performance benefits here
> (not considering the other issues, which are also significant).
> 

performance is an issue here. OSPF for example does not use TCP but
rather raw socket. Why do you want to have each OSPF message go
through ForCES. This need additional copies and parsing. How would
we support an RDMA capable interface? Most things that are intended
for the CE do not need to be encapsulated in ForCES. I also do not
understand why this raises interpretability problems. Today without
ForCES OSPF as an example works fine and we do not have interpretability
problems. Just send the packets for the CE which are not ForCES
related in the traditional why to the CE.

> BTW, if you have any performance nos here, pls do share them with us. I
> would be very interested to know since we didn't see any such issues in
> our implementation.
> 

look at the work that RDMA and OpenRDMA is doing. The goal is to have
a zero copy stack to reduce latency. By coping the packed again we
introduce additional overhead in kernel space and user space since we
have to copy and parse the packet again.

Regards,
Patrick

> 
>>BTW, Jamal, I agree very much with your design philosophy regarding
>>doing away with TML messages/ header and keeping it simple. Just need
> 
> to
> 
>>analyze further if this is viable.
> 
> 
> That has been my thinking as well. As Jamal described, some additions to
> 
> the FE LFB can replace special mcast control TML messages.
> 
> [HK] Good, we are all on the same page here...we will definitely strive
> to achieve this goal of minimal TML overhead...it should be achievable.
> 
> Regards
> Hormuzd
> 
> 

-- 
    Dr. Patrick Droz 			| [email-masked]
    IBM Zurich Research Laboratory 	| http://www.zurich.ibm.com/~dro
    Saumerstrasse 4 			| Tel. +41-1-724-85-25 CH-8803
    Rueschlikon/Switzerland 		| Fax. +41-1-724-85-78

-- 
   Dr. Patrick Droz 			| [email-masked]
   IBM Zurich Research Laboratory 	| http://www.zurich.ibm.com/~dro
   Saumerstrasse 4 			| Tel. +41-1-724-85-25 CH-8803
   Rueschlikon/Switzerland 		| Fax. +41-1-724-85-78