From owner-p4-projects@FreeBSD.ORG Wed Jan 9 12:52:16 2008 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 3A7C816A421; Wed, 9 Jan 2008 12:52:16 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA3AC16A417 for ; Wed, 9 Jan 2008 12:52:15 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id C4D2D13C447 for ; Wed, 9 Jan 2008 12:52:15 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.1/8.14.1) with ESMTP id m09CqFJ1018430 for ; Wed, 9 Jan 2008 12:52:15 GMT (envelope-from rpaulo@FreeBSD.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.14.1/8.14.1/Submit) id m09CqFkf018427 for perforce@freebsd.org; Wed, 9 Jan 2008 12:52:15 GMT (envelope-from rpaulo@FreeBSD.org) Date: Wed, 9 Jan 2008 12:52:15 GMT Message-Id: <200801091252.m09CqFkf018427@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to rpaulo@FreeBSD.org using -f From: Rui Paulo To: Perforce Change Reviews Cc: Subject: PERFORCE change 132879 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2008 12:52:16 -0000 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. */