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 2EBF121F2E7; Mon, 2 Mar 2015 13:53:31 -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 t22LrD0k020720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Mar 2015 13:53:14 -0800 (PST) Message-ID: <54F4DBC9.1010700@isi.edu> Date: Mon, 02 Mar 2015 13:53:13 -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: Brian Trammell , Dave Taht References: <7B3E53F5-2112-4A50-A777-B76F928CE8F2@trammell.ch> In-Reply-To: <7B3E53F5-2112-4A50-A777-B76F928CE8F2@trammell.ch> 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: "aqm@ietf.org" , "cerowrt-devel@lists.bufferbloat.net" , bloat 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 21:54:00 -0000 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. Joe