Date: Wed, 9 Jan 2008 12:52:15 GMT From: Rui Paulo <rpaulo@FreeBSD.org> To: Perforce Change Reviews <perforce@FreeBSD.org> Subject: PERFORCE change 132879 for review Message-ID: <200801091252.m09CqFkf018427@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=132879 Change 132879 by rpaulo@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. */
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801091252.m09CqFkf018427>