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
> 
> > 
> >