RE: Speeding up tail loss detection (Re: Congestion control algorithm questions)
"Lubashev, Igor" <ilubashe@akamai.com> Sat, 30 June 2018 03:43 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 14CC6130E40 for <quic@ietfa.amsl.com>; Fri, 29 Jun 2018 20:43:20 -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 HAD5mbX_6Yqf for <quic@ietfa.amsl.com>; Fri, 29 Jun 2018 20:43:17 -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 9FC52130DF3 for <quic@ietf.org>; Fri, 29 Jun 2018 20:43:17 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w5U3gJDV014863; Sat, 30 Jun 2018 04:43:09 +0100
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 : mime-version; s=jan2016.eng; bh=e33g+S/RSnTNVl/Og4kk3xxqvWTdiN1+HXj835A5qsc=; b=Nx+2w23mD9AuSUXRwnqAnStdsaBoTWoqEkPy1XFY3exmYi6gOzsHJpzHJl65tCI9Dmjc gMtofaTm0J9cTon1nxn6tbEeMi/ruBvA7t8MMGz1D6njXvweTtAPW7mqGzQOSskEVDm8 5Ok8mzIHLp27s/ZRYzcgZiZloyaD7mN+vrz2R9SGUTgkonTvBP9HTkpgrE+dkO+2+0I2 SCx/TbqLL6U9wwhkVCaRl0SOcaEUgqLUIDVmwmeHHujLQ8lnSrsckC3tccslhHWEJY78 fbBOrIKjSYceLAxbRtLWwFDm6YQUyhBeGJZt85uhI5to0mAcnOtH3jdIL9W+hqVRq9sC gg==
Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2jx1cmr3rv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 30 Jun 2018 04:43:09 +0100
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 w5U3ewkW023607; Fri, 29 Jun 2018 23:43:08 -0400
Received: from email.msg.corp.akamai.com ([172.27.25.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ju9bw02ty-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 29 Jun 2018 23:43:08 -0400
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 29 Jun 2018 22:43:07 -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.1365.000; Fri, 29 Jun 2018 22:43:07 -0500
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: "huitema@huitema.net" <huitema@huitema.net>, "kazuhooku@gmail.com" <kazuhooku@gmail.com>
CC: "quic@ietf.org" <quic@ietf.org>
Subject: RE: Speeding up tail loss detection (Re: Congestion control algorithm questions)
Thread-Topic: Speeding up tail loss detection (Re: Congestion control algorithm questions)
Thread-Index: AQHUECBvSG4+mMUizUuLpLeaaCeqgKR4KKij
Date: Sat, 30 Jun 2018 03:43:06 +0000
Message-ID: <037175748de14b49a815a91a883ee0e1@ustx2ex-dag1mb5.msg.corp.akamai.com>
References: <CANatvzwoHL1_MtkHM53+PKhR8Rs52Y2y=mVt+f5kFwpDGTNn2Q@mail.gmail.com>
In-Reply-To: <CANatvzwoHL1_MtkHM53+PKhR8Rs52Y2y=mVt+f5kFwpDGTNn2Q@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
Content-Type: multipart/alternative; boundary="_000_037175748de14b49a815a91a883ee0e1ustx2exdag1mb5msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-30_02:, , 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=400 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806300039
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-30_02:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=315 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806300039
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/8TVjZOUIs7kyBZZ5pUnkzbn78NI>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
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: Sat, 30 Jun 2018 03:43:21 -0000
It would make sense to define PING to require an ACK as soon as possible. The need for an immediate ACK is not just in tail loss probes. It is also PMTU probes. Come to think of this, PATH_CHALLENGE should require an expedited ACK as well. - Igor -----Original Message----- From: Kazuho Oku [kazuhooku@gmail.com] Received: Friday, 29 Jun 2018, 11:14PM To: Christian Huitema [huitema@huitema.net] CC: IETF QUIC WG [quic@ietf.org] Subject: Speeding up tail loss detection (Re: Congestion control algorithm questions) I know that the recovery draft defines TLP, but it does not provide a way for a sender to request client to send an ACK immediately. I think that there should be a way to request that, because it would help the sender detect the loss at the earliest moment. One way is to specify a TLP frame, which is identical to a PING frame with only one difference: it suggests the peer to send ACK immediately. A sender sending a TLP will include the frame in the packet to evoke the peer to send ACK without waiting for the delay. Searching the mailing list archive told me that Christian raised the issue about a year ago (in the mail cited below), but it seems to me that the issue has not been resolved yet. 2017-08-25 14:52 GMT+09:00 Christian Huitema <huitema@huitema.net>: > 3) Can the senders do something to speed up retransmission? > In the absence of continuous traffic flow, the previous decision tree > degenerates to timer based retransmission. To speed things up, > implementations can generate extra traffic. For example, if no > acknowledgement is received after a short timer, they can send a > gratuitous packet that may trigger a further acknowledgement. That's the > essence of the "tail loss probe" algorithm of TCP, but things are really > simpler with monotonously increasing packet sequence numbers. There are > various plausible ways to send a gratuitous packet -- a Ping, a Max Data > Update, or repeating the oldest packet will all work. > > Of course, implementations should avoid sending too many gratuitous > packets, because it can cause congestion. The typical implementation > will wait one min-RTT before sending the first tail loss probe, then > just wait for the regular timer based retransmission. But we may start > being creative. For example, if packets are waiting and the > implementation is sending a naked ACK for whatever reason, it does not > cost much to add a Ping to that. > > This simple text encompasses SACK, RACK, and Tail-Loss Probe. And it is > very easy to implement. > > -- > Christian Huitema > > -- Kazuho Oku
- Re: Speeding up tail loss detection (Re: Congesti… Ian Swett
- Re: Speeding up tail loss detection (Re: Congesti… Ian Swett
- Re: Speeding up tail loss detection (Re: Congesti… Yoshifumi Nishida
- RE: Speeding up tail loss detection (Re: Congesti… Praveen Balasubramanian
- RE: Speeding up tail loss detection (Re: Congesti… Lubashev, Igor
- Speeding up tail loss detection (Re: Congestion c… Kazuho Oku
- Re: Speeding up tail loss detection (Re: Congesti… Christian Huitema
- Re: Speeding up tail loss detection (Re: Congesti… Christian Huitema
- RE: Speeding up tail loss detection (Re: Congesti… Mikkel Fahnøe Jørgensen
- RE: Speeding up tail loss detection (Re: Congesti… Praveen Balasubramanian
- Re: Speeding up tail loss detection (Re: Congesti… Kazuho Oku
- RE: Speeding up tail loss detection (Re: Congesti… Praveen Balasubramanian
- Re: Speeding up tail loss detection (Re: Congesti… Yoshifumi Nishida