Re: [6lo] [Int-area] Short Hierarchial IPv6 addresses

Uma Chunduri <umac.ietf@gmail.com> Thu, 11 November 2021 17:08 UTC

Return-Path: <umac.ietf@gmail.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 4B9223A0CE9; Thu, 11 Nov 2021 09:08:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Ht9fztunQ9FY; Thu, 11 Nov 2021 09:08:18 -0800 (PST)
Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 7D4BD3A0CDF; Thu, 11 Nov 2021 09:08:13 -0800 (PST)
Received: by mail-yb1-xb2a.google.com with SMTP id a129so16681714yba.10; Thu, 11 Nov 2021 09:08:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F21El6MwHJTjjiKT3PIvdvs+jIE9jYJsxYh1iRcgY8I=; b=YMFChzZ+6oSIJvCOD43Ub22kImJVKYmH80SFQXxdoqp5mFAlu66JpnXMMVPoqPLnUG FJQCNnVHUwFWkCTMhGD/jXw+aSALO3fqjBFdIuKUrigylS8j3IA9qXdm+bv7pfdKHg7n f9Ks/CY4Dt1KT+W2sur/QMGbXeHgLAP2ZRa+FWdAh8b0bZH3D87EMN6yyq/JSZLS2ZYV WFkM+I+F37XHZjIG51YVo8Lb0QKcXDa12CDHJ1MUfKxgm8v8zbzxLUeq2AqmUVx1HvTH jH//cbfyIViqAqqE0WueaQygCcrnCZ+wxQ5/1DAHvb0Pv5VjQKSHCsZ2byZUprN6cuiN RPRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F21El6MwHJTjjiKT3PIvdvs+jIE9jYJsxYh1iRcgY8I=; b=IkuM/rQpZsx4MKQPw4sUR/+5sGDByo4gL6mQVn+FX/rd6yEEmzlM6yexTs5Ojp0Zd0 QGupVNx9VmRg4ooP+v8JiQSuZWlzcmRp3Dx3dWbRJd0xyZQivKrnyo3qbmQeRTqvneB4 P1pyOWXR8VzUT+oul+GAKv+tDD8dvTqt9VQzEmItItBFVKEi5moakuVMtALz8y1FUS/1 amciHeQHT1uMNCsDCgSBO8Be8pJe2ZCSk5janLu5AWueWmVzCvTxt5lRnNYllTUGk+nC aOy3RR70IW+MSpGlrI2p84S+LdE4THr7Ai+RWI7SDLNnZQj37A1FAZ3HD10vJC7rhdbP 9GUQ==
X-Gm-Message-State: AOAM530t1Tp2GaUO/owoj5oKV2zLadQhP5dZQ5M+6sn4XumF3vBockVD 5xFuUpC7q3CI28LotMe2c7nGEajSH9UqeDPrXLA=
X-Google-Smtp-Source: ABdhPJzcd8g1VxoxJWv6OCzzTFbpxYqn1x6rPeCKigWZ7mV4ZX/SCFbAP4zL/y9kMCeSGkh7Lx0jcgqmkAUorpXBs4Q=
X-Received: by 2002:a25:aea4:: with SMTP id b36mr9509663ybj.182.1636650491554; Thu, 11 Nov 2021 09:08:11 -0800 (PST)
MIME-Version: 1.0
References: <b9d172392013f578cdbd8e7120f6154e.squirrel@webmail.entel.upc.edu> <BY3PR13MB47870F8078E156139DE953769ABC9@BY3PR13MB4787.namprd13.prod.outlook.com> <16151.1634581572@localhost> <BY3PR13MB4787D81E9B56FBBEA62EA28A9ABC9@BY3PR13MB4787.namprd13.prod.outlook.com> <BY3PR13MB4787BBE8A65861E0927E615C9A919@BY3PR13MB4787.namprd13.prod.outlook.com> <5CB1DC41-6BB9-4251-A080-207120F0311E@cisco.com> <BY3PR13MB47875C6A873BBA1FDD9F9E9F9A929@BY3PR13MB4787.namprd13.prod.outlook.com> <CACQW0EovGkJFiiN29Y3yadVQiXLyjHu6jsFJWYvZv+Rwu7JSqg@mail.gmail.com> <BY3PR13MB4787C4DF1D74A7BD79995BD39A939@BY3PR13MB4787.namprd13.prod.outlook.com> <CABOxzu3nFw1AxCiYv1ao2Dui_JgPrQK6My4xFWjiUm+_fMGOKQ@mail.gmail.com> <BY3PR13MB478705606B1A60564D39435F9A939@BY3PR13MB4787.namprd13.prod.outlook.com>
In-Reply-To: <BY3PR13MB478705606B1A60564D39435F9A939@BY3PR13MB4787.namprd13.prod.outlook.com>
From: Uma Chunduri <umac.ietf@gmail.com>
Date: Thu, 11 Nov 2021 09:08:00 -0800
Message-ID: <CAF18ct6UZ4=gtOsCbT13mYWs0tSPtnfu=sDUixyFDKwbVMivHw@mail.gmail.com>
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Kerry Lynn <kerlyn@ieee.org>, "int-area@ietf.org" <int-area@ietf.org>, Alexander Pelov <a@ackl.io>, "6lo@ietf.org" <6lo@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002baf6405d08663ba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/MJkg3nXqZXPtjcoVDDTu4XmYKvo>
Subject: Re: [6lo] [Int-area] Short Hierarchial IPv6 addresses
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: Thu, 11 Nov 2021 17:08:24 -0000

Great discussion and inputs from many header compression experts.

>So maybe for the networks or applications where low latency is a critical
requirement in addition to the bandwidth efficiency, we could find such
context-less scheme more compelling.


I can with certainty give 2 such examples where I was involved multiple
times w.r.t IPv6 usage:

1. A subset of mIOT UEs (this is a huge swath of UEs we are talking about)
which needs low latency, high bandwidth and is sensitive to battery power.
For example, a V2X UE, cares for low latency and high bandwidth *but is not
*necessarily constrained by low battery power (though saving is always
good). However, an AR/VR UE (advanced handset or 5G enabled headset) cares
for all 3 (high BW, low latency and battery).

2. Another  one is with LEO satellite constellations and communication from
the end points. Here also only a subset of use cases/devices cares for all
3.

regards!
--
Uma C.


On Wed, Nov 10, 2021 at 2:26 PM Haoyu Song <haoyu.song@futurewei.com> wrote:

> Hi Kerry and Alexander,
>
>
>
> Thank you very much for the information. It seems the existing standards
> serve their purpose well. But Kerry did mention an interesting point: both
> these networks have low data rate and are insensitive to latency. So maybe
> for the networks or applications where low latency is a critical
> requirement in addition to the bandwidth efficiency, we could find such
> context-less scheme more compelling. This is very helpful discussion.
> Thanks a lot!
>
>
>
> Best regards,
>
> Haoyu
>
>
>
> *From:* Kerry Lynn <kerlyn@ieee.org>
> *Sent:* Wednesday, November 10, 2021 9:04 AM
> *To:* Haoyu Song <haoyu.song@futurewei.com>
> *Cc:* Alexander Pelov <a@ackl.io>; Pascal Thubert (pthubert) <
> pthubert@cisco.com>; int-area@ietf.org; 6lo@ietf.org
> *Subject:* Re: [6lo] Short Hierarchial IPv6 addresses
>
>
>
> On Tue, Nov 9, 2021 at 7:15 PM Haoyu Song <haoyu.song@futurewei.com>
> wrote:
>
> Hi Alexander,
>
>
>
> Thanks for the clarification! It seems you suggest that the bandwidth
> efficiency (i.e., the header overhead) is much more important than the cost
> of storage and processing in wireless. It would be great if we could find
> some quantitative research results. Is there any such info available?  It’s
> also good to know that SCHC already supports direct device communications.
> How about 6loWPAN? Same?
>
>
>
> It is important to note that there are several 6lo data links that employ
> RFC6282
>
> header compression including RFC8163, which is wired. (Indeed, I believe
> 6282
>
> is a common denominator of published 6lo RFCs.) So, from my perspective,
> I'd
>
> like your proposal to show why RFC6282 _won't_ work for your application.
>
>
>
> Re: quantitative research results for the comparative energy costs of
> different
>
> 6lo design tradeoffs, I believe these studies do exist and folks in t2trg
> might be
>
> able to point you to specific papers. Most (all?) 6lo data links are
> characterized
>
> by low data rates, so it's important to consider the latency win of IPv6
> header
>
> compression as an additional consideration.
>
>
>
> Regards, Kerry
>
>
>
> <snip>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>