IETF Logo Mail Archive

Re: [quicwg/base-drafts] ACKing ACK (#291)

hardie <notifications@github.com> Wed, 15 February 2017 21:58 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E494612987C for <quic-issues@ietfa.amsl.com>; Wed, 15 Feb 2017 13:58:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.595
X-Spam-Level:
X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2ABqGVnXK8O for <quic-issues@ietfa.amsl.com>; Wed, 15 Feb 2017 13:58:15 -0800 (PST)
Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext8.iad.github.net [192.30.252.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1A3312987B for <quic-issues@ietf.org>; Wed, 15 Feb 2017 13:58:15 -0800 (PST)
Date: Wed, 15 Feb 2017 13:58:14 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1487195894; bh=OuH9A57jP3mWIFJQKB37MFK6YWCqFJHf05mzgcOQ37E=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=mRRHifT8nZPCITZlr8t56imqJ8j+7u32z05YonXDYqUKusghKgDI0S6+YR8J3QE1Y pY6zkudxVKJV2vjTgVkQExTACqiscOLu+igFeMbKclTC6KLoN6CMWB6Uol90bmmfA4 v39H+aoAUYgIi8XSWqv/2TzMnAztSDjP0zfR0LIs=
From: hardie <notifications@github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/291/280153368@github.com>
In-Reply-To: <quicwg/base-drafts/issues/291@github.com>
References: <quicwg/base-drafts/issues/291@github.com>
Subject: Re: [quicwg/base-drafts] ACKing ACK (#291)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_58a4cef68b817_1f2a3f8b7b945138111817"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: hardie
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/TOjIZl0o6W--sbY98XG1HRHTpE4>
Cc: Subscribed <subscribed@noreply.github.com>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: quic@ietf.org
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Feb 2017 21:58:18 -0000

Forgive the stupidity on my part, but why do PING frames really need access to the fast path? If a peer sends a PING to detect liveness and reachability, any other packet arriving will serve as a demonstration of that, right?  So the ACK of PING could be serviced right after the PING arrives (if things are quiescent) or after other frames bound to the same peer, and still get the same demonstration at the peer.  Or am I missing something?
 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/291#issuecomment-280153368

v2.35.0 | Report a Bug | By Email | System Status