Re: [icnrg] Next steps on the 4G/LTE Draft

Luca Muscariello <muscariello@ieee.org> Mon, 03 June 2019 11:30 UTC

Return-Path: <muscariello@ieee.org>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE6C12024D for <icnrg@ietfa.amsl.com>; Mon, 3 Jun 2019 04:30:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.008
X-Spam-Level:
X-Spam-Status: No, score=-2.008 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_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 (1024-bit key) header.d=ieee.org
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 rTKDVhXgD5hP for <icnrg@ietfa.amsl.com>; Mon, 3 Jun 2019 04:30:12 -0700 (PDT)
Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (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 208B4120276 for <icnrg@irtf.org>; Mon, 3 Jun 2019 04:30:12 -0700 (PDT)
Received: by mail-wr1-x444.google.com with SMTP id r18so2640259wrm.10 for <icnrg@irtf.org>; Mon, 03 Jun 2019 04:30:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=Q4Hke/vQcf/7yL8gL6uFcIEURw9HUglni3lMueFUSEs=; b=RRDSbvYNQdFI84EMkq8xuCMwNWfT1AVME3gCHEk7Xr+nVgTu4E4vFC+zoHwY7HFeFg Z3403kHs7Oiidr/hBcrkyFznQxZGM+6App0OTohnYjK4G4YMAKo3wtiME9t0QVxhFmOx ceuR8V/ks/q3IL/XWUZffw+rw2SnI4wvVZ7mw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Q4Hke/vQcf/7yL8gL6uFcIEURw9HUglni3lMueFUSEs=; b=biQ7ZwuGjq0oihtG1TvFFYyxbH4yc1wuc2E+lbvbes88zUx7Ydwl4lERBDNHp05h67 hbASs5YSvo/JOiAp8qAbaEXlNX0kpkl/CBj3vkxCJeOlSH2lMq8R7NZV920EmiX1Po88 j8+qFJPzkghzYTjKsfMja/xQCEtFQQ1Mf3286mxCBf3ZIFeO/AjTk9as9y6Ai+xZfR/z UM4VTACS+BqQ98FKp0oEUnv0ByI63Gz/aUBj9JNBmGC5i36k1Bj9RifZMaYHbviDayeF 9GPNzA7aR9RzU97XhRcEhAvPpuoq/XECqhsrfwPkJ//ZKJzvu/g8QpvpIbowz66GLRzT 2weA==
X-Gm-Message-State: APjAAAW6RfrLC6EIbjgaY8qhesr3PmlSr6jOA6NbcLdPlBLbxGnILPib BaEqJehEhLN99zkFPFUpV3dUojPfjaIsheuhdUrWAA==
X-Google-Smtp-Source: APXvYqxO/kNssTkzVWDtLGcgZMhjhozuC3UrEBJgO+ji0FYyLVHmrSOiZhcyZXnfMoeTdHLhUrBiUeAnPaa5bvs81l4=
X-Received: by 2002:a5d:444c:: with SMTP id x12mr338560wrr.234.1559561410487; Mon, 03 Jun 2019 04:30:10 -0700 (PDT)
MIME-Version: 1.0
From: Luca Muscariello <muscariello@ieee.org>
Date: Mon, 03 Jun 2019 13:29:59 +0200
Message-ID: <CAH8sseTC+6j4FjnMzrtJL=mR3qvLC47+fzJCNcgH39WD=tw-=A@mail.gmail.com>
To: "Anil Jangam (anjangam)" <anjangam@cisco.com>
Cc: Akbar Rahman <Akbar.Rahman@interdigital.com>, icnrg <icnrg@irtf.org>, "Prakash Suthar (psuthar)" <psuthar@cisco.com>, "Milan Stolic (mistolic)" <mistolic@cisco.com>, Dirk Trossen <Dirk.Trossen@interdigital.com>, Ravi Ravindran <ravi.ravindran@huawei.com>, "Oran, Dave" <daveoran@orandom.net>
Content-Type: multipart/alternative; boundary="000000000000e0d57f058a69aff9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/SF5Msz9BgQgAFUM5_CXc0DBl7AU>
Subject: Re: [icnrg] Next steps on the 4G/LTE Draft
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Jun 2019 11:30:21 -0000

Hi Anil,

Thanks for the update.
Few quick comments.
hope that helps.
Luca



1)
In the following text you say that using the GTP-U extension header, ICN
payload is encapsulated in the GTP tunnel.
Actually the GTP tunnel terminates at the SGW, while the extension header
can be processed at any node and potentially the ICN packet will never
reach the SGW.
This older paper does not consider hICN. Maybe the paper reference tag
should better be MBICN?


       An approach to implement ICN in mobile backhaul networks is
       described in [MBHICN
<https://tools.ietf.org/html/draft-irtf-icnrg-icn-lte-4g-03#ref-MBHICN>].
It implements a GTP-U extension header
       option to encapsulate ICN payload in GTP tunnel.  However, as
       this design runs ICN as an overlay over IP, it would complement
       only ICNoIP use case scenario described in this draft.



2) The following text is unclear to me. In CCN/NDN and also hICN it is
assumed a new transport is used.

It is though different to say that this transport is running in the
UE. It could run in a GW/proxy that

is not necessarily co-located with the UE. Also, I don't get why the
mobile core (SGW?) has to run the transport layer

unless in GW/proxy mode. In the case of hICN as long as the name
prefixes, which are routable IP prefixes, point towards

a mobile GW (PGW or local breakout, say CUPS) there is potentially
nothing to do in terms GW updates.


5.  Hybrid ICN (hICN)

       An alternative approach to implement ICN over IP is provided in
       Hybrid ICN [HICN
<https://tools.ietf.org/html/draft-irtf-icnrg-icn-lte-4g-03#ref-HICN>].
It describes a novel approach to integrate
       ICN into IPv6 without creating overlays with a new packet format
       as an encapsulation.  HICN address the content by encoding a
       location independent name in an IPv6 address.  It uses two name
       components, namely name prefix and name suffix, which identify
       the source of data and the data segment within the scope of name
       prefix respectively.

       From the perspective of this draft, HICN provides an alternative
       transport layer, to be used by the UE and mobile core network
       nodes, which can be selected by the TCL.




On Mon, Apr 29, 2019 at 8:10 PM Anil Jangam (anjangam) <anjangam@cisco.com>
wrote:

> Hello Luca, Rehman, and All,
>
>
>
> We released an update to this draft (see attached) incorporating some of
> the feedback we received. Please let us know if this update meets your
> concerns.
>
>
>
> We also call for your vote on moving this draft to RG last call. Please
> respond and let us know if you have any other feedback.
>
>
>
> Thank you,
>
> /anil.
>
>
>
>
>
> icnrg on behalf of Trossen, Dirk icnrg-bounces@irtf.org on behalf of
> Dirk.Trossen@InterDigital.com 11/15/18, 7:49 AM
>
>
>
> Hi Luca,
>
>
>
> The abstract provides a number of aspects for wanting to utilize ICN in
> 4G/LTE networks, such as “ICN has an inherent capability for multicast,
> anchorless mobility, security and it is optimized for data delivery using
> local caching at the edge.” – I agree that being brief, given that it’s
> in the abstract, but similar to what the paper discusses as opportunities.
> Furthermore, there’s a possible argument to be made that 4G/LTE will be
> around for some time to come, including being introduced in a number of
> markets as new deployments even – but should this be part of a technical
> draft?
>
>
>
> I’m a bit confused by the ‘HAS to compare with those solutions’ comment.
> Do you expect a functional comparison, a reference to the (brief)
> discussion in Section V on possible deployments, …?
>
>
>
> As for the HICN statement, I see your point on a possible misunderstanding
> (albeit it’s clear to me) – would you have a proposed improved formulation
> that avoids any such misunderstanding?
>
>
>
> What is not clear to me though if your comment is meant as an opposition
> to the validity of the solution described in the draft and its adoption
> specifically?
>
>
>
> Best,
>
>
>
> Dirk
>
>
>
> *From:* icnrg [mailto:icnrg-bounces@irtf.org] *On Behalf Of *Luca
> Muscariello
> *Sent:* 07 November 2018 09:09
> *To:* Oran, Dave <daveoran@orandom.net>
> *Cc:* icnrg <icnrg@irtf.org>
> *Subject:* Re: [icnrg] Next steps on the 4G/LTE Draft
>
>
>
> Hi,
>
>
>
> A few comments to the document:
>
>
>
>
>
> The motivation of this document seems weak. E.g. Why should I do all these
> changes? Worth the pain?
>
> Please find below a paper that may help to motivate that a little bit.
>
>
>
> The following paper is also a good citation and the author of this draft
> should compare
>
> at least with Sec V of it, where several deployment options where proposed
> including encapsulation in IP and GTP-U extension headers. This draft HAS
> to compare with those solutions. Beware that those solutions were
> Alcatel-Lucent IPR and should be Nokia IPR now.
>
> There might be Orange SA IPR as well. If necessary I could check myself.
>
>
>
> Until that comparison is not made, I feel this draft SHOULD NOT go through
> a final call.
>
>
>
> G. Carofiglio, M. Gallo, L. Muscariello and D. Perino, "Scalable mobile
> backhauling via information-centric networking," *The 21st IEEE
> International Workshop on Local and Metropolitan Area Networks*, Beijing,
> 2015, pp. 1-6.
>
>
>
>
>
> Minor:
>
> This text is either wrong or inaccurate. Or maybe, it is so short that is
> prone to misguided interpretation.
>
>        An alternative approach to implement ICN over IP is provided in
>
>        Hybrid ICN [HICN], which implements ICN over IP by mapping of ICN
>
>        names to the IPv4/IPv6 addresses.
>
>
>
> HTH
>
> Luca
>
>
>
> On Wed, Nov 7, 2018 at 7:51 AM David R. Oran <daveoran@orandom.net> wrote:
>
> At the ICNRG Interim meeting at IETF 103, we got an update status on
> https://datatracker.ietf..org/doc/draft-irtf-icnrg-icn-lte-4g/
> <https://datatracker.ietf.org/doc/draft-irtf-icnrg-icn-lte-4g/>
>
> This document is reaching a mature state and the chairs would like to get
> a sense from the RG participants on two questions:
>
> 1.      Do you think this is ready for an RG last call, and if not, what
> additions/changes you would like to see to move it forward.
>
> 2.      Do you think the appropriate target for this particular set of
> work is the “Informational” or “Experimental RFC track. It seems to fall
> somewhat in a grey area between the two.
>
> Please reply to the list. We would like to have feedback by the end of
> next week or so (November 17).
>
> Dave, Dirk, & Börje.
>
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg
>
>
>
>
> ---------- Forwarded message ----------
> From: "Anil Jangam (anjangam)" <anjangam@cisco.com>
> To: "icnrg@irtf.org" <icnrg@irtf.org>
> Cc:
> Bcc:
> Date: Mon, 11 Mar 2019 06:42:17 +0000
> Subject: [icnrg] FW: New Version Notification for
> draft-irtf-icnrg-icn-lte-4g-03.txt
> Hello All,
>
> We are providing a new revision incorporating the review feedback we
> received.
>
> Added a comparison w.r.t. ICN implementation in mobile backhaul networks
> and its relation to the ICNoIP use case. Provided an elaboration about hICN
> and how it is used in the deployment scenarios (in section 4.2). Provided
> more discussion about transport convergence layer. Also added some
> clarification related to the use of ICN in LTE control/signaling plane.
> Incorporated some of the editorial comments.
>
> Thank you everyone for the review comments and for your helpful feedback!
>
> Thank you,
> /anil.
>
>
>
>     A new version of I-D, draft-irtf-icnrg-icn-lte-4g-03.txt
>     has been successfully submitted by Anil Jangam and posted to the
>     IETF repository.
>
>     Name:               draft-irtf-icnrg-icn-lte-4g
>     Revision:   03
>     Title:              Native Deployment of ICN in LTE, 4G Mobile Networks
>     Document date:      2019-03-11
>     Group:              icnrg
>     Pages:              37
>     URL:
> https://www.ietf.org/internet-drafts/draft-irtf-icnrg-icn-lte-4g-03.txt
>     Status:
> https://datatracker.ietf.org/doc/draft-irtf-icnrg-icn-lte-4g/
>     Htmlized:
> https://tools.ietf.org/html/draft-irtf-icnrg-icn-lte-4g-03
>     Htmlized:
> https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-icn-lte-4g
>     Diff:
> https://www.ietf.org/rfcdiff?url2=draft-irtf-icnrg-icn-lte-4g-03
>
>     Abstract:
>        LTE, 4G mobile networks use IP based transport for control plane to
>        establish the data session and user plane for actual data delivery.
>        In existing architecture, IP transport used in user plane is not
>        optimized for data transport, which leads to an inefficient data
>        delivery.  IP unicast routing from server to clients is used for
>        delivery of multimedia content to User Equipment (UE), where each
>        user gets a separate stream.  From bandwidth and routing perspective
>        this approach is inefficient.  Multicast and broadcast technologies
>        have emerged recently for mobile networks, but their deployments are
>        very limited or at an experimental stage due to complex architecture
>        and radio spectrum issues.  ICN is a rapidly emerging technology
> with
>        built-in features for efficient multimedia data delivery, however
>        majority of the work is focused on fixed networks.  The main focus
> of
>        this draft is on native deployment of ICN in cellular mobile
> networks
>        by using ICN in 3GPP protocol stack.  ICN has an inherent capability
>        for multicast, anchorless mobility, security and it is optimized for
>        data delivery using local caching at the edge.  The proposed
>        approaches in this draft allow ICN to be enabled natively over the
>        current LTE stack comprising of PDCP/RLC/MAC/PHY or in a dual stack
>        mode (along with IP) help optimize the mobile networks by leveraging
>        the inherent benefits of ICN.
>
>
>
>
>     Please note that it may take a couple of minutes from the time of
> submission
>     until the htmlized version and diff are available at tools.ietf.org.
>
>     The IETF Secretariat
>
>
>
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg
>