IETF Logo Mail Archive

RE: Cost of parsing ACK frames in QUIC

"Lubashev, Igor" <ilubashe@akamai.com> Thu, 10 May 2018 14:48 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 BDF4812EAF7 for <quic@ietfa.amsl.com>; Thu, 10 May 2018 07:48:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Level:
X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 hG6zQJdy8MfZ for <quic@ietfa.amsl.com>; Thu, 10 May 2018 07:48:30 -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 ADB1B1241FC for <quic@ietf.org>; Thu, 10 May 2018 07:48:30 -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 w4AEl2R1004580; Thu, 10 May 2018 15:48:27 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=sLqYqbj6F/Txsu/tCQq+IkxxdURm1tGWAzUlcKpR6Dg=; b=f6moue2MR1gJhovcSE+LLTiAxaSPgwleACEvAGNmc1696uxpzq7ge0bGFP6aNiSw4vnu 4md/NmlwOrQXQnPbKPFO4ODysBOJkhYaLHCsHpz9arSfIAunb0DDM8RB3LB7JQAL6a6B HxCVS7sOQmLGR8SiP4UjZP0x27+1kUQNWoRQHGGGzOYd+kK0X+DpB8VDINL8bf2u3XNy nRsRzyRRbViAtWihGjhE92gK8cG9YCVQLW0UYXnD//uu9q35rtctZ76eZsR0Vzc+buz7 Sw7/9WQj/C7//FERWc3IV03eBhxVFiaTNgXyvMwGkc7sTBs3XLKHsnFiSN9nPEic+YsS 0Q==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2hue76nmqn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 May 2018 15:48:27 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w4AEkuo7012858; Thu, 10 May 2018 10:48:26 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2hs7xvmw6m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 10 May 2018 10:48:25 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb4.msg.corp.akamai.com (172.27.123.56) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 10 May 2018 07:48:25 -0700
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 10 May 2018 10:48:25 -0400
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1365.000; Thu, 10 May 2018 10:48:25 -0400
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, "Deval, Manasi" <manasi.deval@intel.com>, IETF QUIC WG <quic@ietf.org>
Subject: RE: Cost of parsing ACK frames in QUIC
Thread-Topic: Cost of parsing ACK frames in QUIC
Thread-Index: AdPoaJzXsjis3gTFQX6IIe0OpT4RMgAJkvOAAAhXJ8A=
Date: Thu, 10 May 2018 14:48:24 +0000
Message-ID: <514f80e45dbe4c588fc1f6be7884a0dd@usma1ex-dag1mb5.msg.corp.akamai.com>
References: <1F436ED13A22A246A59CA374CBC543998B64E65D@ORSMSX111.amr.corp.intel.com> <CAN1APdcfmAsM-CBGzFEicBWf6Ck2uRhOmoiooo7d3EPDTjwt7g@mail.gmail.com>
In-Reply-To: <CAN1APdcfmAsM-CBGzFEicBWf6Ck2uRhOmoiooo7d3EPDTjwt7g@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.34.240]
Content-Type: multipart/alternative; boundary="_000_514f80e45dbe4c588fc1f6be7884a0ddusma1exdag1mb5msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-10_06:, , 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=531 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805100141
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-10_06:, , 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=471 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805100140
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/45aUS1GXFaos-dxQJW6epsywDkI>
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: Thu, 10 May 2018 14:48:33 -0000

My understanding is that QUIC requires that the packet decrypts successfully before it can modify the state of the receiver.  However, once it decrypts (hopefully in H/W), you do not need two passes.  You can modify the state as you parse the packet.  If there is anything syntactically or semantically wrong with the packet, that’s a cause for an immediate connection abort, so your entire state is out of the window at that point anyway.


  *   Igor

From: Mikkel Fahnøe Jørgensen [mailto:mikkelfj@gmail.com]
Sent: Thursday, May 10, 2018 10:44 AM
To: Deval, Manasi <manasi.deval@intel.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: Cost of parsing ACK frames in QUIC

While this may be true, please note that QUIC also requires that the entire packet is valid before it does anything that modifies the state of the receiver.

This means that you generally have to do two passes of the packet to ensure that the packet is valid. In the first pass you can then store data for the optimistic case of a single ACK frame.

That said, arguments about fast(er) processing still apply, but it is no longer limited to only ACK frames.



On 10 May 2018 at 16.25.50, Deval, Manasi (manasi.deval@intel.com<mailto:manasi.deval@intel.com>) wrote:
Hi All,

The QUIC header definitions tend to use as few bits as possible by implementing the policy to use variable size fields. The result of this policy would be that each receiver needs to do a two part lookup to identify the field and this needs to be implemented serially in order to parse the whole frame time.

For example, in a case where no packets were dropped, a sender may receive an ACK for a single block. If a code path were trying to determine the size of an ACK, they would have to read 8 fields to determine the size of ACK.

A client only sees a few ACKs. Majority of the ACKs are seen on the server side. It would be good to simplify this scheme so ACK processing can be accelerated with SIMD instructions would be good.

Thanks,
Manasi

v2.23.0 | Report a Bug | By Email