Re: [6gip] continueing the discussion on B5G
Rex Buddenberg <buddenbergr@gmail.com> Fri, 08 January 2021 20:42 UTC
Return-Path: <buddenbergr@gmail.com>
X-Original-To: 6gip@ietfa.amsl.com
Delivered-To: 6gip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 9E5A23A12A9
for <6gip@ietfa.amsl.com>; Fri, 8 Jan 2021 12:42:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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,
SPF_HELO_NONE=0.001, SPF_PASS=-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 MzFGMkYoPnea for <6gip@ietfa.amsl.com>;
Fri, 8 Jan 2021 12:42:21 -0800 (PST)
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com
[IPv6:2607:f8b0:4864:20::102d])
(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 1A4693A12A8
for <6gip@ietf.org>; Fri, 8 Jan 2021 12:42:21 -0800 (PST)
Received: by mail-pj1-x102d.google.com with SMTP id p12so4273045pju.5
for <6gip@ietf.org>; Fri, 08 Jan 2021 12:42:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=message-id:subject:from:to:date:in-reply-to:references:mime-version
:content-transfer-encoding;
bh=upy0yEQDZNKBL9liOtZDMquGQaCLNza5vbblN4dKuRQ=;
b=tnsD57jt1JeKwRlwt9Hs7SpbdP7Cib0cOAWXhJoArgC/ioJqHx4GzT5OCEhYWc/9Be
8wvCdo+yxgfW7qyesQN62eJ8tU9cTXWkOTSj5DfZ2rLCMPLAh9XUMx5v2OKplLYW1zqT
UywCM2eQP0tCHhFTvuuoi4e3unyuwXBMPIuvSePudQBOOUbsVgfdUOIOvAVhuUwEV6NA
+rut0cDPhgnfEnxPPZz34mbwPJWjDMSL9iHgkJ3gwWNU1GXBVIbCFz8NpBxGxMzt8Pv5
VCnw2z9oiUfseY+rjAA30ZyLkHw+2x7o4JVX5afp5p94j+Nfd0v4/GZ1oLGHdR5GbuCX
IVzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to
:references:mime-version:content-transfer-encoding;
bh=upy0yEQDZNKBL9liOtZDMquGQaCLNza5vbblN4dKuRQ=;
b=EjOvljt7wRI9iiweSNwZZFSR6soMXNlK/PucysHJgP7B0SEtwAvtfQEJyjLNyIpJyp
kS+TMchKfUwO9Da1BqocFA0cK45Qq2/R9NsmNeyKl2v4ghM3zye9/UCxRK5wT+Yk/cyT
jA7cJkkgUGiVZ5kYAF5+1RqZ3sBjCwo/x7vv9aH+iyF2x6Yvw+qC5BbPNZgs2E47QOTV
xxCHvi/LZhMR3B+GjG8g17z9UdV0mRUOqYlLV/PQyeCRSlNMMxUb+Tzz8O904cYK7iWI
jlBpSmvQOFtNPVZv4V0USuI1Sq7RnsETE6JpmvcoIJq0S/VP1Kuzc/zxMpYqYijK+QsP
JnRg==
X-Gm-Message-State: AOAM531RPZrXKJgEkQq8s2d0qg+15leUQd6Zjlm80/iHL+lGFwHD/rbR
6x/XKO7mb9vEXL7UKxnG9Qc=
X-Google-Smtp-Source: ABdhPJwwHq1CaijFCEuJ0GCFH5Mdhi96B3vmKWXzkU8aNZsC8vdnpQAK1VyUSHM460+N/bevjg4RIA==
X-Received: by 2002:a17:902:cb95:b029:dc:3a38:c7df with SMTP id
d21-20020a170902cb95b02900dc3a38c7dfmr5518041ply.49.1610138540380;
Fri, 08 Jan 2021 12:42:20 -0800 (PST)
Received: from localhost.localdomain (c-73-241-197-249.hsd1.ca.comcast.net.
[73.241.197.249])
by smtp.gmail.com with ESMTPSA id v125sm10587540pgv.6.2021.01.08.12.42.19
(version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256);
Fri, 08 Jan 2021 12:42:19 -0800 (PST)
Message-ID: <1610138538.14219.152.camel@gmail.com>
From: Rex Buddenberg <buddenbergr@gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>, 6gip@ietf.org
Date: Fri, 08 Jan 2021 12:42:18 -0800
In-Reply-To: <57fcbe91-8f94-f5ba-794a-e47b1385fb78@gmail.com>
References: <CAC8QAcehdY7ZMM528EurJ-H5WCbPM_YodBi3uE=MwZBnSUT2Yg@mail.gmail.com>
<FRAPR01MB1252B940C4B52CDE23AD42D6D1FC0@FRAPR01MB1252.DEUPRD01.PROD.OUTLOOK.DE>
<DB7PR06MB47926584901A75CEFB5973E7B5FC0@DB7PR06MB4792.eurprd06.prod.outlook.com>
<b301c27d-db9b-9ff8-3771-fc86c5f58dee@ninetiles.com>
<FRAPR01MB1252A810545FF74ADF7C4716D1F40@FRAPR01MB1252.DEUPRD01.PROD.OUTLOOK.DE>
<5c891c8d-62b6-c0af-5388-984d301fe408@gmail.com>
<099804f7-3704-c015-71bc-2b094ee3ea53@gmail.com>
<18919675-ea7c-ae93-1e53-7625340a081d@tu-dresden.de>
<03859cfc-2635-09ac-b66b-2556afcc7a91@gmail.com>
<e8a8be95-1651-9fbd-6242-7c8bda8b29bb@tu-dresden.de>
<2ed901d6-8d97-0c5a-bcb2-834289f7f282@gmail.com>
<ccdd1c70-5d20-3614-4202-ff3c31b9d479@ninetiles.com>
<57fcbe91-8f94-f5ba-794a-e47b1385fb78@gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23)
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/6gip/kDZblFZKOpJqMmleaEpeYoocYmw>
Subject: Re: [6gip] continueing the discussion on B5G
X-BeenThere: 6gip@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IP Issues in 6th Generation Mobile Network System \(6gip\)"
<6gip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6gip>,
<mailto:6gip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6gip/>
List-Post: <mailto:6gip@ietf.org>
List-Help: <mailto:6gip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6gip>,
<mailto:6gip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jan 2021 20:42:23 -0000
alex, qos and QoS tends to be a murky subject. First, in system design, QoS should be discussed _after_ - availability and survivability issues. - security issues. The Ao considerations often result in infrastructure density that renders QoS discussions moot. This happens regularly in terrestrial (wired) parts of the internet. In radio segments, things get more complex. But remember: radio is hard and it will always be hard. So good strategy means shrinking the radio space before tackling it directly. That has the side effect of making the qos issues more amenable. Second, there are parts of qos that are in tension -- trading off to optimize one component will cost you something elsewhere. The comment: > Are we talking latency or throughput here? Starts to get to the issue. This is the list I used in the classroom: - bandwidth efficiency - throughput (closely related to b/w efficiency) - latency (one way) subdivided into macro and micro - latency (round trip) - synchronicity The tradeoffs are significantly affected by MAC design. Contention access (CSMA) which is present in all forms of ethernet (including WiFi) yields low latency in lightly loaded network segments due low numbers of collisions. Ethernet MACs simply listen for vacancy and squirt packets out -- no setup foreplay. But a lightly loaded segment is not using the bandwidth available very much. Heavily load the network segment and you stall it from congestion. With no good way out from an operational point of view - add more cells but that's an infrastructure issue, not an operational one of making what you have work. By contrast, scheduling MACs may cost you something in original access (a couple of setup handshakes) but you then can get controlled throughput, or near-synchronous behavior because the base station can guarantee you a certain amount of capacity each frame. Something WiFi cannot do but LTE does. I can't comment of 5G or 6G specifically because they have MAC behavior that I don't (yet) understand. One of the practical lessons in the whole QoS discussion is that the cure is often (hell, almost always) worse than the qos disease. The internet is littered with the debris of failed QoS regimes most of which require a trade of stateless behavior of routers for reserved capacity (RSVP is an example). Diff-serve doesn't compromise the statelessness of routers but we quickly found that the CPU processing cost outweighed the qos effects (there are several shaggy stories herein, some bordering on farce. Helps if you have worked with US DoD). Help? On Fri, 2021-01-08 at 19:18 +0100, Alexandre Petrescu wrote: > > Le 08/01/2021 à 16:52, John Grant a écrit : > > > > On 07/01/2021 22:22, Alexandre Petrescu wrote: > > > > > > > > > I would expect, by feeling, that latencies in the core network > > > based on Ethernet are hugely lower than latencies in the air. In > > > that sense, the difference NSA vs SA might not impact the feeling > > > of the end user comparing 5G to 4G or 4G+. > > > > > > Basically, it is sufficient to download some large file from > > > youtube and highest definition (4K?) and try it first with a 4G > > > text above the 5 bars showing signal quality and then with the 5G > > > text instead. In theory one should be impressed by the download > > > speed on 5G. > > Are we talking latency or throughput here? And if latency is it > > round > > trip latency, where milliseconds can be important in some > > applications, or just the delay between requesting something and > > the > > content appearing? > It is a good question. Smaller round or single trip latency and > larger > throughput parameters have distinct influence on different apps. A > youtube watch might not be influenced by the latter but a skype call > might be influenced by the former. > > What do you think could be another smartphone easy test to > demonstrate > the superiority of 5G over 4G? > > Because I think at this time what can be evaluated is a feeling. > > The feeling of whether 5G feels faster than 4G to the end user. > > It is very easy for some users who have access to 5G smartphones and > 5G > deployments to tell whether 5G feels faster than 4G. In France, > these > users are located in a few cities such as Marsilia or Nice and with > operator SFR, but need a 'business' kind of subscription. In other > countries it might be other operators. > > These deployments started in December. > > So I wonder how do the 5G users feel about it being faster than > 4G? Is > it _much_ faster than 4G? Can one download a 4Gb DVD in a few > minutes > time? What does 'google speed test' reply? > > What do you think could be another smartphone easy test to > demonstrate > the superiority of 5G over 4G? > > Alex > > > > >
- [6gip] Slides from IETF 109 Side Meeting Behcet Sarikaya
- Re: [6gip] Slides from IETF 109 Side Meeting Dirk.von-Hugo
- Re: [6gip] Slides from IETF 109 Side Meeting David Lake
- Re: [6gip] Slides from IETF 109 Side Meeting John Grant
- [6gip] continueing the discussion on B5G Dirk.von-Hugo
- Re: [6gip] continueing the discussion on B5G Alexandre Petrescu
- Re: [6gip] continueing the discussion on B5G Behcet Sarikaya
- Re: [6gip] continueing the discussion on B5G Alexandre Petrescu
- Re: [6gip] continueing the discussion on B5G Frank Fitzek
- Re: [6gip] continueing the discussion on B5G Alexandre Petrescu
- Re: [6gip] continueing the discussion on B5G Frank Fitzek
- Re: [6gip] continueing the discussion on B5G David Lake
- Re: [6gip] continueing the discussion on B5G Alexandre Petrescu
- Re: [6gip] continueing the discussion on B5G John Grant
- Re: [6gip] continueing the discussion on B5G Alexandre Petrescu
- Re: [6gip] continueing the discussion on B5G Rex Buddenberg