Re: [6lo] draft-ietf-6lo-minimal-fragment-00: When to remove VRB entries?

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 06 February 2019 15:36 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C5F128766 for <6lo@ietfa.amsl.com>; Wed, 6 Feb 2019 07:36:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -19.195
X-Spam-Level:
X-Spam-Status: No, score=-19.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=hUfy9pxR; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=O2LdUib0
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 pPT9E1kq92XA for <6lo@ietfa.amsl.com>; Wed, 6 Feb 2019 07:36:06 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF56128CF3 for <6lo@ietf.org>; Wed, 6 Feb 2019 07:36:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11996; q=dns/txt; s=iport; t=1549467366; x=1550676966; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=jgJ153Vr+d93DAdyk6cTxvNrgz96ROEqNBaq+fur8Bo=; b=hUfy9pxRIKRZVgPtV3PDEHzi506n9DulGZ/mqTZb78bOwTlLmaJ/RoTT mn5QDBKbAjCiA+MTh9dr7uwyafa29XCvb4ytsXkJg21/u0HbuYW7O8Pvu hwh5HkO2Y1zy0OS69rAHnutU7o1DXy7+siWDPIglU2z6HCsMiM0+Eh942 w=;
IronPort-PHdr: 9a23:QNwqexWYeoZ24+f6iJ1FtwdC0xnV8LGuZFwc94YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTFdE7KdehAk8GIiAAEz/IuTtankiAMRfXlJ/41mwMFNeH4D1YFiB6nA=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AKAABk/Vpc/4kNJK1lGgEBAQEBAgEBAQEHAgEBAQGBUwMBAQEBCwGBDSNQA2d0BAsnCoN5g0cDj3GCV5IghW8UgRADVAsBASUHhEACF4MDIjYHDQEDAQECAQECbRwMhUoBAQEEIwoTAQE4DwIBCA4DBAEBFhUCAgIwHQgCBAESCIMbgR1MAxUBAgyhcwKKFHGBL4J4AQEFgURBgwwYggsDBYxDF4FAP4EQAUaCTIMeAgMBgRguGSQHEoJKMYImihCGCpJwCQKHNYslkk6KLIU0jBMCBAIEBQINAQEFgU0OIyiBLnAVgyeCHAkag0uFFIU/coEojDMBgR4BAQ
X-IronPort-AV: E=Sophos;i="5.58,340,1544486400"; d="scan'208,217";a="295399680"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Feb 2019 15:36:05 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x16Fa5Dm009846 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Feb 2019 15:36:05 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 6 Feb 2019 09:36:04 -0600
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 6 Feb 2019 10:36:03 -0500
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 6 Feb 2019 09:36:02 -0600
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jgJ153Vr+d93DAdyk6cTxvNrgz96ROEqNBaq+fur8Bo=; b=O2LdUib0GJO10t+s9MAhmbdpfhXPZYv6oQLGRWPtIQRbekuqgKYHNbr7WHuuJ7bhbV68cJz9LJlF1MQBLu8ooQL0+vsgs0bF+SvDh+71SA9I23ZKQ5x9DcOxRkqXqb3pz3UQdQo/ILmd0sAOARjwZw+IYvM/SSM3IAtPmJ1QgmY=
Received: from SN6PR11MB3471.namprd11.prod.outlook.com (52.135.112.221) by SN6PR11MB2607.namprd11.prod.outlook.com (52.135.91.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.22; Wed, 6 Feb 2019 15:36:01 +0000
Received: from SN6PR11MB3471.namprd11.prod.outlook.com ([fe80::1c9f:935:667b:8957]) by SN6PR11MB3471.namprd11.prod.outlook.com ([fe80::1c9f:935:667b:8957%3]) with mapi id 15.20.1580.019; Wed, 6 Feb 2019 15:36:01 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Martine Lenders <m.lenders@fu-berlin.de>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: [6lo] draft-ietf-6lo-minimal-fragment-00: When to remove VRB entries?
Thread-Index: AQHUvis8l/WCJnJQfkSfvBG+Jtz0TaXS4i3A
Date: Wed, 06 Feb 2019 15:35:32 +0000
Deferred-Delivery: Wed, 6 Feb 2019 15:35:18 +0000
Message-ID: <SN6PR11MB3471A33D03F27608E8EE59BAD86F0@SN6PR11MB3471.namprd11.prod.outlook.com>
References: <CALHmdRwqF972Y4DG8x9QW_fg+AkwnQtzUVSgyE77FBYYO0SLpQ@mail.gmail.com>
In-Reply-To: <CALHmdRwqF972Y4DG8x9QW_fg+AkwnQtzUVSgyE77FBYYO0SLpQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [173.38.220.34]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN6PR11MB2607; 6:ZMSA+CXE6T5S1CMRF6vcUD4O/NtDOBljXI2Fr0p81BIJvO81ogqBJcQnUBdn83EBolEmNbUMXBYQhCz2sR2PztE9mPPLkTJeNh0IbFTR3aKcZ9wsg9FEd9uJ+GFlF/qWGs3rfQztxv41cmxKywISiYg2vpaywlpEhHdH631R0uKSqFksB9lKf/kM+yANZVe6PlFZj+b6hulDyr8K47LAQpkySIADSKJVmAHurXGnMr0AljluKzYVurQi4G0Ti3siHA5OwWzItduB8UTUnsvKyJrMVvPdOuNLUccA8N+n5oPpmMdiqMeEQDVRq59qc1nJ1/vGE5wdbqyp+rSA/YG5lU1SoBB1vULRVjRKjnoFW0AYAcTHmjoPtoNt/Ugwi86MYR4fboIxRJfolQ4Vs312IIdobKyi4PIsn2gdYMdSlXBw5lx1UXuZm8wuY0pjZZmJssQ8BI1zm+86+R0AbUq1bQ==; 5:udxTDd4GApDdbOyKIPBbskHSQbpxhqcCB/DKgmfFmJ7dgWNYkNnw14Au9bvzoe2o14PqUkMtmRxFNpNlZ8Pwla6H9r6UM48IZ+6dolbgjQHoSM+J1ml2fSY0LgXDUPP6GiMq88sgVw9Y6VYAbytM17X+uqwkbCSQpZbzNDMsnNZH1AaO5tIt8phBZBTnK7T2j/Gqx7Hlr/zpLkz9EXM7sw==; 7:jBja9q6TplL5bMXZ40wDTyDfa1+6qqtj7M0g+hnAdj66Iu/0SmAHTLrg5XCGmJcs+L7sgemSBpbgWPubVUiSkt7s/vsr1qa3+ecCleoft5gqpxjJUZYa+1lFyb5nLS5j8Ax0L2naYB3M7x8QUJqisA==
x-ms-office365-filtering-correlation-id: d387c01b-2f95-4231-abf0-08d68c48cc86
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:SN6PR11MB2607;
x-ms-traffictypediagnostic: SN6PR11MB2607:
x-microsoft-antispam-prvs: <SN6PR11MB2607049E503975575B16C6E0D86F0@SN6PR11MB2607.namprd11.prod.outlook.com>
x-forefront-prvs: 0940A19703
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(136003)(39860400002)(396003)(189003)(199004)(53936002)(6246003)(561944003)(74316002)(2501003)(110136005)(76176011)(33656002)(7736002)(14454004)(478600001)(97736004)(316002)(8936002)(66066001)(966005)(8676002)(2906002)(606006)(81156014)(68736007)(81166006)(11346002)(476003)(446003)(486006)(9686003)(66574012)(53546011)(106356001)(186003)(71190400001)(14444005)(105586002)(6666004)(6506007)(256004)(6116002)(3846002)(86362001)(229853002)(25786009)(790700001)(236005)(54896002)(6306002)(99286004)(6436002)(7696005)(71200400001)(55016002)(102836004)(26005)(564094006); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR11MB2607; H:SN6PR11MB3471.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: iM6PuXqKGv6bEkJwVJymZ/bYwurF/rOtPC8f9aPN5CJhYwC0IH/SKrjrpd7VZtBYUlRbyCR7h4MEH6RS/H0jVCbkHuC4dtmiOvpHsukIdo1r8TH2fLjGPbXOYzlkQ3GveFeNxQgkYzW97fhCXCMA7HfzhiBIfbt+B5sLb3ouMdBErmZSE5Sb0pcvQvOEa04GXITGvdKNG3QU+kXJs6X/cCux5gB0k7EvK0ubxfVb5sTQuPzOL87yTqseBSJD/kF/rCX75uhiwM1TQBhdypk83PUIxcNcWFZb7PMnU2cLfKP9gBJPcvCxMNJ16eNXrCP+oA/ZFFwAhKMbb+UBkbjWYZ4iaVurThtNr4pf+yBVKw1T8NeW0kC8RQXGF8L747dBGznTtpWsr2CbVupENv2MmSSPFl8rdt2kG5fUTKLMoWI=
Content-Type: multipart/alternative; boundary="_000_SN6PR11MB3471A33D03F27608E8EE59BAD86F0SN6PR11MB3471namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d387c01b-2f95-4231-abf0-08d68c48cc86
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2019 15:36:01.5405 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2607
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/RTUQ9IB8xzs75vTCd9pAO6E-T5c>
Subject: Re: [6lo] draft-ietf-6lo-minimal-fragment-00: When to remove VRB entries?
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Feb 2019 15:36:08 -0000

Hello Martine

Fragments follow a same path, but this is not a guarantee that they will not be mis-ordered. So whatever you do, it should not be immediate but done upon a time out because once the VRB is gone, packets are dropped. Note that if the first packet is delayed, then minimal-fragment is in trouble.

For fragment-recovery-01 there is text in 7.3 about cleaning the VRB, basically an ACK that indicates a reset of a complete reception (all 0 or all 1) triggers a short timer to destroy the VRB. This is done in case the ack is lost on the rest of the way back and the last flow is retried. There is also text at the end of section 6 that indicates that a reset by the sender may not have an rfrag-ack request bit set. In that case, the same operation as if the RFRAG ack was received applies. I could add a word on that.

All the best,

Pascal

From: 6lo <6lo-bounces@ietf.org> On Behalf Of Martine Lenders
Sent: mercredi 6 février 2019 15:49
To: 6lo@ietf.org
Subject: [6lo] draft-ietf-6lo-minimal-fragment-00: When to remove VRB entries?

Hi,

I'm currently in the process of implementing first prototypes of both minimal fragment forwarding [1] and fragment recovery [2] for RIOT [3].

However, I'm unsure how I can determine when it is safe to remove a VRB entry at least for the minimal forwarding case (even for a successfully transmitted datagram). As far as I have seen not even the original VRB draft [4] mentions a strategy for that.

For the success case I could of course just count the bytes of the fragments and remove the VRB entry once I reach the datagram size, however this does not account for possibly received duplicates (unless I keep track of at least the intervals of all received fragments which of course costs more memory).

The failure case is easier, since I could just use the timeout used in the original 6Lo fragmentation, but using this for the success case as an alternative to my proposal above might lead to a congestion of the VRB.

Are there any other strategies I might have missed?

Kind regards,
Martine Lenders

[1] https://datatracker.ietf.org/doc/draft-ietf-6lo-minimal-fragment/
[2] https://datatracker.ietf.org/doc/draft-ietf-6lo-fragment-recovery/
[3] https://github.com/RIOT-OS/RIOT
[4] https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-networks/