IETF Logo Mail Archive

RE: PADDING vs PING

"Lubashev, Igor" <ilubashe@akamai.com> Mon, 19 March 2018 15:03 UTC

Return-Path: <ilubashe@akamai.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21365126C0F for <quic@ietfa.amsl.com>; Mon, 19 Mar 2018 08:03:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 7TvrbXGCUWJP for <quic@ietfa.amsl.com>; Mon, 19 Mar 2018 08:02:54 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58C5128D2E for <quic@ietf.org>; Mon, 19 Mar 2018 08:02:51 -0700 (PDT)
Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2JEvndm022186; Mon, 19 Mar 2018 15:02:48 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=e+YKoXwV+/g8Jd3BLC2DOqt1wgNqhf3RnDjR9Af4DSM=; b=YnRJnNwsnY3zgWJROJFwt2gdGqiiB5B/fpMpyMnGG08b1uFYKiBSjuJIUiOnbWMYAF1O PAi8aT5Pu3xHhxQ1PrrLCvdrKK0QnftYl8qW8K7QiXI6pJAajwa9grtyiE/EoyVCiZbA mz4Nkx1eGwHq+eY98xaC5YidJWqF+MG61ng+JmzzEVSPYT0FS/nSzBjIQnBvmrhZCTLn vVBCQcF3u8WD5FqWGmkpwcheWwQxsSaHj2utU+0mdRlfY6CG4Hj57szQD0lJ6pWDgBG1 SmKlhF1x5hI8TqD+I/Ao9sszcG2yvilJ0PyGdL9U5Xxq7eQyAHmI/u4VIYn/K/QDxflw Kg==
Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0b-00190b01.pphosted.com with ESMTP id 2grrrxwbff-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Mar 2018 15:02:48 +0000
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w2JEvgPD012606; Mon, 19 Mar 2018 11:02:47 -0400
Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint4.akamai.com with ESMTP id 2grxbvmvsg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 19 Mar 2018 11:02:47 -0400
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 19 Mar 2018 10:02:46 -0500
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1263.000; Mon, 19 Mar 2018 10:02:46 -0500
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Martin Thomson <martin.thomson@gmail.com>
CC: IETF QUIC WG <quic@ietf.org>
Subject: RE: PADDING vs PING
Thread-Topic: PADDING vs PING
Thread-Index: AdO/iza41CbbyhT3RkmWzLk9izKQ0wALmNsAAAnGXMA=
Date: Mon, 19 Mar 2018 15:02:46 +0000
Message-ID: <cf7026c0cc0f4ec1b99c888067c774e9@ustx2ex-dag1mb5.msg.corp.akamai.com>
References: <0a5ec245895043f196c0e93026d8e7ea@ustx2ex-dag1mb5.msg.corp.akamai.com> <CABkgnnU5FDgfhkGybBAV4Ei=cB7E6KF-WbVDgOm=w9pV51=gLA@mail.gmail.com>
In-Reply-To: <CABkgnnU5FDgfhkGybBAV4Ei=cB7E6KF-WbVDgOm=w9pV51=gLA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.153.49]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-19_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=638 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803190171
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-19_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=577 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803190171
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/o5SAhmZI7OK2BR2T_GZTUFqlHCQ>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Mar 2018 15:03:04 -0000

Very well.  So it is Option 2.  One thing I did want to propose that we make the "ACK expectations" of PADDING and PING clear.  Bother require ACKs (except for ACK+PADDING packets), but PING requires an immediate ACK, while PADDING allows for a delay.

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Monday, March 19, 2018 2:37 PM
To: Lubashev, Igor <ilubashe@akamai.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: PADDING vs PING

The current text counts ACK towards bytes in flight when there are other frames present, so you just described Option 2.  Albeit more precisely.

The key is that packets that comprise only (ACK[, PADDING]) count toward bytes in flight.  That is, the packet counts or not, but the content determines the answer.

On Mon, Mar 19, 2018 at 2:23 PM, Lubashev, Igor <ilubashe=40akamai.com@dmarc.ietf.org> wrote:
> Since 4 proposals is not enough, let me propose the 5th one, which is 
> an extension of Subodh’s proposal.
>
>
>
> PADDING does NOT count for bytes-in-flight (and does not require ACKs) 
> when it is a part of ACK+PADDING packets.
> PADDING does count for bytes-in-flight and does require ACKs otherwise 
> (including in PADDING-only packets).
> The difference between PADDING and PING in non-(ACK+PADDING) packets 
> is that PING requires an ACK to be sent ASAP, while ACKing PADDING can 
> be delayed, if the receiver does some ACK coalescing.
>
>
>
> Igor

v2.23.0 | Report a Bug | By Email