IETF Logo Mail Archive

Re: [Roll] Eliding mechanism in 6550

Rahul Jadhav <nyrahul@outlook.com> Mon, 07 October 2019 06:19 UTC

Return-Path: <nyrahul@outlook.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4022512002F for <roll@ietfa.amsl.com>; Sun, 6 Oct 2019 23:19:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 Z80lXuxXghGl for <roll@ietfa.amsl.com>; Sun, 6 Oct 2019 23:19:25 -0700 (PDT)
Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255037.outbound.protection.outlook.com [40.92.255.37]) (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 0D4581200F8 for <roll@ietf.org>; Sun, 6 Oct 2019 23:19:24 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j6qMuJup/PJiWrjyhuNhijzZO3a9qRRqbYsX59BuJzqr6puCFFJmcNcXH3XRE6KqIlthK4SitbSGmHCjJLGL0o/BdWvfvOoiMZOk3UNaVoRUkbp/mLTd5rEl61CckP7MTsqhjcyr5MHb8+koTb5KJyvzB0Kijj5oOew4PQjwWs86Ylm9wuT5n/pSWpP+4RBxZnpuJN0yizm6M6GrUbCTxQOG1z/+UNJD2j4PtPr6+2hgDpnQDidObjj5iCZ/FbgyvnQ3nw3PlTmUBi18M1sciuG3CNUlV3BSKpVNRuhRacQUlLKYvR8+I6kBZBKaZ6COcs1UHQyyC4U7OlDKem3nYQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C8h0dWOCIHkHXMR2b8T8jl5Uz1+uEEYHR7tU5xmrpmo=; b=jpZGtTyFVV0kB5XpQJ6tAL4NU9ztQfgS+T2ljXdfhroT+akSoVehGmJdlsdcpIQzwp2NJaJISQv+kNoxvRXFg5n/Bmh9LbygHATQAfN/MQARV0cNxAvvViPuCAFbvfRijvCaG8KgfB7RNuUNG1w9daeID5K/t5D+EBactgyyVZpyOyCgoVYWNKFAOOoiO0l8GnSQM8NcRXF5UATdPrHFUmVCYyZz9EDde+RuZufii/aosHlIETsYOTdY8KRVGZ2KAWzVNDlwmCXH14sFqPZtjG44NRiyfDWzljYNtDbPo9yjTHi4qF3wT0r6upCY7qxv2eMuYE6xlqujplXnhhi1oQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C8h0dWOCIHkHXMR2b8T8jl5Uz1+uEEYHR7tU5xmrpmo=; b=aNsogEMnopog9XWRqCODf8as3pc2Mb0rErLUyClVrTQBMKfsioSu0sgRpYFm1fEas41+gkKAj7VyhtDVmQh5naAa8AKP9ywttIWkd6F7W6MXKj7WvAIuyj2l8jmxWDNgaOXwmlobQNW4QVUVPEL/8iQi7VLaKV1wJWb6JgXwvcP3xvpGD+8yct6/bJ82FEPtaUgganHX55PFyLRCSPiLnEsHJdZTT8nUY1zdO2MlSrjvX+UAIUm+bH7BnNb/Jwv+dG8Z/MQv6vu7VVB0X8tyBBedQnO6wYak9jLuS82BcPsg1xP0LYa3izopS6NPfWtozXov44fZiFmt3Q/pLwe0lw==
Received: from HK2APC01FT040.eop-APC01.prod.protection.outlook.com (10.152.248.56) by HK2APC01HT172.eop-APC01.prod.protection.outlook.com (10.152.249.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2327.20; Mon, 7 Oct 2019 06:19:22 +0000
Received: from BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM (10.152.248.51) by HK2APC01FT040.mail.protection.outlook.com (10.152.249.42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.20 via Frontend Transport; Mon, 7 Oct 2019 06:19:22 +0000
Received: from BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM ([fe80::8a1:677d:4fb6:b932]) by BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM ([fe80::8a1:677d:4fb6:b932%6]) with mapi id 15.20.2327.023; Mon, 7 Oct 2019 06:19:22 +0000
From: Rahul Jadhav <nyrahul@outlook.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] Eliding mechanism in 6550
Thread-Index: AQHVdUhliZ040nQflUyScFbwadE6vadDQIYAgABYVgCAAm1ugIAIvMZj
Date: Mon, 07 Oct 2019 06:19:22 +0000
Message-ID: <BM1PR01MB2612F28DFB810043C7316EB5A99B0@BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM>
References: <28599.1569796250@localhost> <5DBFE23C-9388-4FF3-949C-13846F68AF7C@cisco.com>, <MN2PR11MB35651A3D6FA6CC1B7CEDC41AD89D0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB35651A3D6FA6CC1B7CEDC41AD89D0@MN2PR11MB3565.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:E9343AD607DDF00BC62EE1F93128098DB727C9EE3EE0028BA460E259B10C2438; UpperCasedChecksum:3683407F485F15EA53491703D97F36571D51B3CCA9E17806ABAE15298416C4A0; SizeAsReceived:6887; Count:43
x-tmn: [ploj+NiL6eIRIdPDlZEMCj9lUNezNqcn]
x-ms-publictraffictype: Email
x-incomingheadercount: 43
x-eopattributedmessage: 0
x-ms-traffictypediagnostic: HK2APC01HT172:
x-ms-exchange-purlcount: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: mS16Ue6KDyNPj192BRcKMzvPg1nlZRZoMhbxJZmXP4KBDNP4s7i1BW8rygEidfMySiMD2nNzuB4RW+ywMvl6T3xP5WFDFv0QMgPyMRFabBbVJk6o+tGq3KL8gtVUuiviR9OQQkyEljT75SDVFLlzLJ9616xHpFGe3TNfiKK5fGL78MvEupxs8Kx03QzpDeLO5x8PKEIEGJCAcvG0x/0O43Ii6MumnhmmhGsXEmKqa2g=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BM1PR01MB2612F28DFB810043C7316EB5A99B0BM1PR01MB2612INDP_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: ae492ada-749f-4a25-1947-08d74aee4b5b
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2019 06:19:22.1998 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT172
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/1mv8ugXq83Ud3S7kvuiCS2kwRJc>
Subject: Re: [Roll] Eliding mechanism in 6550
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Oct 2019 06:19:27 -0000

Maybe DODAGID is not a good example but how about other static information such as Prefix Information Option carried in DIO. Can it be a candidate for eliding?
________________________________
From: Roll <roll-bounces@ietf.org> on behalf of Pascal Thubert (pthubert) <pthubert@cisco.com>
Sent: Tuesday, October 1, 2019 4:51 PM
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] Eliding mechanism in 6550

Typo by autocorrection: Before my phone knew better I meant  DIO... So:
I would not compress the identification of the message otherwise a DIO for another DODAG may be confused.
The DODAGID indicates which DODAG this DIO is about, it should not be elided...

Pascal

-----Original Message-----
From: Roll <roll-bounces@ietf.org> On Behalf Of Pascal Thubert (pthubert)
Sent: dimanche 29 septembre 2019 20:47
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] Eliding mechanism in 6550

I would not compress the identification of the message otherwise a FIO for another DODAG me be confused ...


Regards,

Pascal

> Le 30 sept. 2019 à 00:31, Michael Richardson <mcr+ietf@sandelman.ca> a écrit :
>
> 
> Rahul Jadhav <nyrahul@outlook.com> wrote:
>> During the interim Pascal/Michael suggested the use of counter to
>> track the freshness of the Config Option. This could further extend
>> to track MOPex and CAP options freshness.
>
>> The suggestion was to use the reserved bits in the base DIO message for such a counter.
>
> Yup.
>
>> I was wondering if the DODAGID in the DIO could also be elided under
>> the same guise? Basically the point is to elide all the "static"
>> information which rarely changes.
>
>> Clearly this has issues in multi-DODAG networks but it is possible to
>> handle such issues. Considering that this directly results in 16
>> bytes savings per DIO multicast message, do you think it is worth the
>> effort or if there are other issues?
>
> My question is what are the sizes of the DIOs, and how close are we to
> fragmentation already?
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

v2.23.0 | Report a Bug | By Email