remove an outdated reference to T/TCP
Subsystems (3)
PATCH 1/1 remove an outdated reference to T/TCP
Remove a particularly out of date bit of comment referring to T/TCP.
---
net/ipv4/tcp_input.c +0 -8
@@ -5824,14 +5824,6 @@ int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb,* we just ignore it, that fits the spec precisely * and avoids incompatibilities. It would be nice in * future to drop through and process the data. -* -* Now that TTCP is starting to be used we ought to -* queue this data. -* But, this leaves one open to an easy denial of -* service attack, and SYN cookies can't defend -* against this problem. So, we drop the data -* in the interest of security over speed unless -* it's still in use. */ kfree_skb (skb);return 0 ;
David Miller
maintainerFrom: Rick Jones <[email protected]>
Date: Tue, 6 Dec 2011 12:00:05 -0800 (PST)
Quoted 4 lines
Remove a particularly out of date bit of comment referring to T/TCP.
Signed-off-by Rick Jones <[email protected]>
I think it should stay because it discusses the potential bad side effects of queueing any data that might be in the SYN.
Quoted 10 lines · David Miller
From: Rick Jones<[email protected]>
Date: Tue, 6 Dec 2011 12:00:05 -0800 (PST)Quoted 4 lines
Remove a particularly out of date bit of comment referring to T/TCP.
Signed-off-by Rick Jones<[email protected]>I think it should stay because it discusses the potential bad side effects of queueing any data that might be in the SYN.
How about just the sentence that mentioned T/TCP explicitly since T/TCP is most definitely no longer starting to be used?-) The rest of it can be discussed when/if TCP Fast Open arrives :)
rick
David Miller
maintainerFrom: Rick Jones <[email protected]>
Date: Tue, 06 Dec 2011 13:39:23 -0800
Quoted 7 lines · David Miller
Quoted 6 lines
From: Rick Jones<[email protected]>
Date: Tue, 6 Dec 2011 12:00:05 -0800 (PST)Quoted 3 lines
Remove a particularly out of date bit of comment referring to T/TCP.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Signed-off-by Rick Jones<[email protected]>I think it should stay because it discusses the potential bad side effects of queueing any data that might be in the SYN.
How about just the sentence that mentioned T/TCP explicitly since T/TCP is most definitely no longer starting to be used?-) The rest of it can be discussed when/if TCP Fast Open arrives :)
T/TCP gives the statement context, as in referencing something that might make us want to at least theoretically consider handling the data.
Quoted 16 lines · David Miller
From: Rick Jones <[email protected]>
Date: Tue, 06 Dec 2011 13:39:23 -0800Quoted 12 lines · David Miller
Quoted 10 lines
From: Rick Jones<[email protected]>
Date: Tue, 6 Dec 2011 12:00:05 -0800 (PST)Quoted 4 lines
Remove a particularly out of date bit of comment referring to T/TCP.
Signed-off-by Rick Jones<[email protected]>I think it should stay because it discusses the potential bad side effects of queueing any data that might be in the SYN.
Quoted 7 lines
Quoted 3 lines
How about just the sentence that mentioned T/TCP explicitly since T/TCP is most definitely no longer starting to be used?-) The rest of it can be discussed when/if TCP Fast Open arrives :)
T/TCP gives the statement context, as in referencing something that might make us want to at least theoretically consider handling the data.
I am fine keeping the comment as is. This does remind me to put more comments on this part of the code in our upcoming Fast Open patch :)
Quoted 2 lines · Yuchung Cheng
I am fine keeping the comment as is. This does remind me to put more comments on this part of the code in our upcoming Fast Open patch :)
This sounds great.
Is TFO patch using inetpeer cache to store cookies ?
(I ask this because TFO paper I read mentions linux-2.6.34, I presume you couldnt use inetpeer at that time since it was IPv4 only)
Quoted 11 lines · Eric Dumazet
Quoted 2 lines · Yuchung Cheng
I am fine keeping the comment as is. This does remind me to put more comments on this part of the code in our upcoming Fast Open patch :)
This sounds great.
Is TFO patch using inetpeer cache to store cookies ?
(I ask this because TFO paper I read mentions linux-2.6.34, I presume you couldnt use inetpeer at that time since it was IPv4 only)
Very interesting! I didn't know inetpeer cache earlier so we implement own. duh! I will certainly look into it. Thanks for this tip. From the surface, it does not seem too difficult to extend inetpeer for IPv6?
Yuchung