[tcpm] RFC2883 DSACK - duplicate SYN

"Scheffenegger, Richard" <rs.ietf@gmx.at> Mon, 09 September 2019 10:47 UTC

Return-Path: <rs.ietf@gmx.at>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FA81200D6 for <tcpm@ietfa.amsl.com>; Mon, 9 Sep 2019 03:47:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 zjdHCrmuJ3hB for <tcpm@ietfa.amsl.com>; Mon, 9 Sep 2019 03:47:43 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73400120033 for <tcpm@ietf.org>; Mon, 9 Sep 2019 03:47:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1568026057; bh=n642pqp8LAxvjbu+aoRwEJJ2yyvZypiBXOfIwNXi3hE=; h=X-UI-Sender-Class:To:From:Subject:Date; b=U2vRGIeZ4M/6JBhMW54M7U+RTQoshO9I5CqzefaiJy7pK4KtXD8bqhHGVG+VO/Z0H XCNerxwFU0LH8T+wbwgiXPu37yJNJoHetN6tg47uCj30fqlVSAwWd2G9ea5imOw+nH 46hVAi+xCgBJ6GyfwOEbq6MgOWfP9/CZIyS3NojA=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.67.133.231] ([217.70.210.46]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MbAh0-1iinoX1v2m-00baJ6 for <tcpm@ietf.org>; Mon, 09 Sep 2019 12:47:37 +0200
To: "tcpm@ietf.org" <tcpm@ietf.org>
From: "Scheffenegger, Richard" <rs.ietf@gmx.at>
Message-ID: <1964a510-1356-e6ec-e7ff-df98f8f07a85@gmx.at>
Date: Mon, 9 Sep 2019 12:47:36 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:hA18O/0HAAgwzbUNgLg1xb5Up1bHbCErdKV+FHnAgUPHD3V69Hw elaYfBEJY2h+rPcY6iNWVw1w4AGFr08BEOlHvx1biu6h5F3HEqiJRk487g7wQbLORDsLynn FlxGPKV73TPno7EUVE1vWBmpeJDqtFD5d2w69gHuOnH+Au5lhWXE9TiRQm+SmfonN/wLEAW +kyEad6spu4zpuQ7uP6Mg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:dHwnJIbZIXw=:1/Ug/Bpi566iZ4RNHKORZ+ /lMvBQ7uvkebLp1ceM0NX19RJ/tfuOflmlxcZGyck8pwCC4J5zN9FiQdVTGVMdnNqtCZsquFH zPV8CU3OUApTuz9HVD3fs54mf494rtzI5j8W3NBcO2/52lsNfaniSezPcGu6hWkjH3fhNNL0f FuBn9yK9X8VzbWSnJngQSVGvveygnIcm1dkXRWTd7P/aPCx5B3901fLWkQDDziiQkoeb1fmOG kaAVykZrYf2MPmgekm3g9pUNcegB2ttGra1Ha5XAHJFSpgocRRCPYOC64GWLx4J2F2/eGm1c5 MMh8DrPmapWiY1lwfSqHateh2a69oUnuLGmhjPB2KiFeBMUdr7W5IY40CXGik4KhNttwvo/Al p5PAqwKy0O7WHKoPSExQZmpEI7yxJWp1Cp7yLJFDXZnEUsE09v36R/Vt4qJaSbcJPwiAN4wuV yCY8pBYNRcXo8vuN49AF3kS2QB4G0+OHDYUUu9++qKBLVUMBucqcmb6p6nG1cL8l/YrVv2ogq //th6o5RNgbo2u+AfeNO18txqEEU38ySgi386l88AaYDJ/2cQzjNQOJqPy0qaM/blnzaTYus/ ONqgeuqsyN2RG1owKVkMhS9952j/a/v/5bZDmRN+jfI2NxlajfzIV9eM/ib50WoYyVdxvdHDl qKcihkhL5X4FdbWjxzrJ7QbwoDFLyxH878t5MeegPWOfilWo5S2soNpi94yHMGF5o4B4rrWcT ZxR6iJczDb1ZPS1BdrmlrkPqYxILm2d2w5Ka4EGJNAsfBtsbdpQiMS+g/ep6phRvzAA4ZNebW sOnZ8HxE8HCcSbTN3xWlTDFp8pCugWqeIuvaFsQqn6wWZ4WKQ2oNCk5+TnsEHHSmJ+0bTFSdn oSSRcGSgmGPrE+T86nlDZqLiuX4DBKShFEtOd9YdMZOC7kpJlVrIvVXwBUi1VkzrNyg8XYckj sZxNeNM86Ufg+Cn3K/V5SokB2CnjE8RS3aPQHyK5etFdeP9FVEaULj1Azh143HHkvs9p2r2uA HCBzY3cPVllm4nBYobsTk8n+ragDRLERqf/TO28X7oakWt8mgZhSjrpVcXaCJpcyW6E6Jmsj/ 2v39OkhjPjvOeVJ9nLXQIzvscnB6khlvp+MOOcnzZq/H7j39eutupdRAk4UaBdvksPSbvaixL 4B+HkHJEYkbuLo0lRaRHEq9M63hZngFu78xq+SyciAq8f0ELbHuPYb83aGx+hxn/pXwUo=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/I7XuG9WXMN3WzxX1L7lARpfj1Oc>
Subject: [tcpm] RFC2883 DSACK - duplicate SYN
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Sep 2019 10:47:45 -0000

Hi,

Since RFC2883 is silent on the two special flags SYN and FIN, I wanted
to check with you if my understanding is correct:

If a FIN is received (pure or with data) after a gap in the sequence
space, as it consumes a sequence number, it becomes part of the SACK
block reported back to the sender.

So far, so good. But shouldn't the same also be happening for a
duplicate received SYN?

The sender announces that it supports SACK with the SYN, thus a receiver
could choose to send out a DSACK for a duplicate SYN.  At least neither
RFC2018 nor RFC2883 are ruling this out:

  SYN (SACK permitted) ->
   <-  SYN,ACK (SACK permitted)
  (dup) SYN (SACK permitted) ->
   <-  SYN,ACK (SACK permitted, D-SACK for SYN)
  ACK ->


Depending on the sequence of events, a sender could infer network
duplication, or very high RTT, unambigiously when doing a DSACK on a
SYN,ACK....

Best regards,
    Richard