From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id EEEE521F25D; Mon, 2 Mar 2015 15:26:04 -0800 (PST) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t22NPPrO015216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Mar 2015 15:25:26 -0800 (PST) Message-ID: <54F4F166.6040303@isi.edu> Date: Mon, 02 Mar 2015 15:25:26 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: David Lang References: <7B3E53F5-2112-4A50-A777-B76F928CE8F2@trammell.ch> <54F4DBC9.1010700@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Mon, 02 Mar 2015 16:20:43 -0800 Cc: Brian Trammell , bloat , "cerowrt-devel@lists.bufferbloat.net" , "aqm@ietf.org" Subject: Re: [Cerowrt-devel] [aqm] ping loss "considered harmful" X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 23:26:33 -0000 On 3/2/2015 3:14 PM, David Lang wrote: > On Mon, 2 Mar 2015, Joe Touch wrote: > >> On 3/2/2015 1:40 AM, Brian Trammell wrote: >> ... >>> The real solution is to create a utility called "ping" that uses >>> traffic that gets prioritized the same way as the traffic you care >>> about instead of ICMP echo request/reply. Users don't care about >>> the packets on the wire so much as they do that you're supposed to >>> ping things. >> >> There are three separate problems: >> >> 1. a ping that doesn't use ICMP >> there are dozens of these >> >> 2. needing a reflector >> ping gets around this only because the reflector is widely >> deployed (and integrated into most OSes) >> >> 3. using the same port as the traffic you care about >> transport protocol is only one problem (ICMP being a "transport >> protocol" by virtue of using the IP protocol number field) >> >> the other is differential prioritization based on port number >> >> there's no easy solution to that; >> every service would need an integrated >> ping reflector >> >> I suspect #3 is the ultimate killer of this idea. > > The service you are trying to contact acts as a reflector for TCP > traffic. If you send a syn you will get back a syn-ack from the TCP > stack of the receiving system. Sure, but SYNs and SYN-ACKs don't get prioritized the same as non-control TCP segments. And they could have been spoofed by a middlebox. Joe