PERFORCE change 132879 for review

[Rui Paulo]

http://perforce.freebsd.org/chv.cgi?CH=132879

Change 132879 by rpaulo at rpaulo_alpha on 2008/01/09 12:51:55

	draft-ietf-tcpm-ecnsyn-04 is out and it discusses a drawback
	of setting ECT in the SYN/ACK packet.
	It's not problematic, but let's be like everyone else (except
	for NetBSD) by not setting ECT in the SYN/ACK packet.
	
	We may revert back to the old behaviour in the future.

Affected files ...

.. //depot/projects/tcpecn/netinet/tcp_syncache.c#5 edit

Differences ...

==== //depot/projects/tcpecn/netinet/tcp_syncache.c#5 (text+ko) ====

@@ -1357,36 +1357,6 @@
 	if (sc->sc_flags & SCF_ECN) {
 		th->th_flags |= TH_ECE;
 		tcpstat.tcps_ecn_shs++;
-		
-		/*
-		 * draft-ietf-tcpm-ecnsyn-00.txt
-		 *
-		 * "[...] a TCP node MAY respond to an ECN-setup
-		 * SYN packet by setting ECT in the responding
-		 * ECN-setup SYN/ACK packet, indicating to routers 
-		 * that the SYN/ACK packet is ECN-Capable.
-		 * This allows a congested router along the path
-		 * to mark the packet instead of dropping the
-		 * packet as an indication of congestion."
-		 *
-		 * "[...] There can be a great benefit in setting
-		 * an ECN-capable codepoint in SYN/ACK packets [...]
-		 * Congestion is  most likely to occur in
-		 * the server-to-client direction.  As a result,
-		 * setting an ECN-capable codepoint in SYN/ACK
-		 * packets can reduce the occurence of three-second
-		 * retransmit timeouts resulting from the drop
-		 * of SYN/ACK packets."
-		 *
-		 * Page 4 and 6, January 2006.
-		 */
-#ifdef INET6
-		if (sc->sc_inc.inc_isipv6)
-			ip6->ip6_flow |= htonl(IPTOS_ECN_ECT0 << 20);
-		else
-#endif
-			ip->ip_tos |= IPTOS_ECN_ECT0;
-		tcpstat.tcps_ecn_ect0++;
 	}
 	
 	/* Tack on the TCP options. */