Re: Informed regulator about the shorter-than-64 necessity on 3G/4G/5G

Yucel Guven <yucel.guven@gmail.com> Thu, 21 January 2021 20:52 UTC

Return-Path: <yucel.guven@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6B13A0C7D for <ipv6@ietfa.amsl.com>; Thu, 21 Jan 2021 12:52:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 yk17Lzrx2LCC for <ipv6@ietfa.amsl.com>; Thu, 21 Jan 2021 12:52:49 -0800 (PST)
Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 CE3E03A0C7E for <ipv6@ietf.org>; Thu, 21 Jan 2021 12:52:49 -0800 (PST)
Received: by mail-ot1-x330.google.com with SMTP id f6so2985373ots.9 for <ipv6@ietf.org>; Thu, 21 Jan 2021 12:52:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hz2VlMJ5k3fSyelXgQ/RDjAEMO6FDteYBXIdzH78s7Q=; b=c7n64Tf1ptI+2eXbhwEy7sxQnZo9Nq5jxe35fmIvC7Vdy9MF2GE3HwssHuiyvx2UkW FGbzkhX9Fb72LjBrF7QxzJaq+WtKQcZYYEyhqo5VBshSTbN5ocUUHAqDnbSuC0CsAnUZ +2gqij8eUaCV8Ly2Af1gyllRBNjXuxmStbd33VxZiKgTIYct7U1BAP/ObyO+e32Ha3V0 NJqfstdw5gd5koMQqWSp7d8k5uhMP4RAVn0TVHbOv72YHjROJki22GAo4oFQvO8nLwCG 6XdPhDMbshnQ6QQz3fm7W/Pw5/HPL4kZIpJAdYZ1TqDUGltynIaNSomeCnlYaR0Lzdes MZAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hz2VlMJ5k3fSyelXgQ/RDjAEMO6FDteYBXIdzH78s7Q=; b=mffO0c6WbQavHV+an1ykXqzZ8XYdtyKGFGChRrX4kg4vlp/gcohkzcae99hp3kX5ZD U1XHfZBmI+1h3X/+ewEbhnY3sHvZxTfCINnmdH4uf02EoywLPPqrQ8B+Rood/K5FbVHh f0BvpWDzi5Y7hY/69TNw43NQedObbhieVd2R2yj9Yg90uoqSXeIVP0AaDsHrJoJ7xKfH EsPXhtBYu0NfodkdkH/oj5czQ0WRyxVcQXXTHHNYOig48SICrGQ8HeAQvfxC4aE9tbEu wYxYqEOcXpggTxb9ds1hD294qQIj0MJgzcyNF5G6fN/DotezSlcYg37sSy6tl/Yq21ds 1qqA==
X-Gm-Message-State: AOAM533U+nOeV6RGaJ+4F/z0dXnjALQVPIkrwIL7/YBE10HbKwix8GLe APDNFBHMWLU3BaYQH/7DBPEjNddXSad3ZwmYiMfhjowi
X-Google-Smtp-Source: ABdhPJzbKOqCLVGPXz/+5IMhMW4ZEjia6ZlhV8BH4x2gPJ45IpjpZMoCUC3A6sdMSBEnDsDtPtJFgDroadnjT8w9RW4=
X-Received: by 2002:a9d:6383:: with SMTP id w3mr756224otk.225.1611262368976; Thu, 21 Jan 2021 12:52:48 -0800 (PST)
MIME-Version: 1.0
References: <616b05ca-1a02-dfbd-d7f6-c79f56276fa1@gmail.com> <f300119e-0233-c711-207e-6962d67e87bd@si6networks.com> <D120371E-C9D7-4F62-ADDF-2C990AD0E6FC@isc.org> <CAKQ4NaXWK3ZQUZnR7aXbjs6NSCX5d6xc9gQOzdmLMoOrvghGtQ@mail.gmail.com> <B3844144-1586-43BE-8B82-B98805D5F5E1@thehobsons.co.uk> <CAKQ4NaUp-VK5VodZYojDTSdzmK+xf1zdgCy57jedEASCrGy_Dw@mail.gmail.com> <52A3B62B-B8D7-4561-AF20-B3B9C1550E83@thehobsons.co.uk>
In-Reply-To: <52A3B62B-B8D7-4561-AF20-B3B9C1550E83@thehobsons.co.uk>
From: Yucel Guven <yucel.guven@gmail.com>
Date: Thu, 21 Jan 2021 23:54:13 +0300
Message-ID: <CAKQ4NaWGqK3Z3ORaukR0EBLBJLk+_FLgu7LiXHdKaxHCYYwjhw@mail.gmail.com>
Subject: Re: Informed regulator about the shorter-than-64 necessity on 3G/4G/5G
To: Simon Hobson <linux@thehobsons.co.uk>
Cc: IPv6 <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/OmfT2d0b0mz-w8jmyF19EJKw6Yc>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jan 2021 20:52:52 -0000

For mobile connections, we pay for the "amount" of data (in units of
bytes) that we consume either in 3 seconds or in 30 days.
It's not our problem to think about provider's network infrastructure
in the past or in the future.
Subscribers pay for the service in this free market economy as mentioned,
and subscribers should be able to decide what to do with paid mobile connection,
either with one interface or with multiple interfaces (usb, wifi,
etc...), either with one /64 or with /xy prefix.
(Better not to diverge from the title of thread.)

Regards,
Yucel

On Thu, Jan 21, 2021 at 9:06 PM Simon Hobson <linux@thehobsons.co.uk> wrote:
>
> Yucel Guven <yucel.guven@gmail.com> wrote:
>
> > It can not be the provider's business to put connection restrictions
> > AFTER subscribers paid for X GB connection. Subscribers share it or
> > not, it's their choice.
>
> You'd think so, but it seems that the cellular industry (at least in some parts) still disagrees.
>
> > This situation also sheds some light on why cellular providers do not
> > like/want 'tethering'.
>
> Historically I could see a valid argument for that. When you consider how phones used to be limited in function, and inherently limited in how much data they could consume, being able to tether a "real" computer to it could dramatically alter the data usage proposition. And that change has the scope to dramatically alter the costs to the operator (both in terms of upstream bandwidth, and in terms of network infrastructure) without changing the price the customer pays.
> But these days, most phones can stream media as well as (or even better than !) a computer that might be tethered to it - so the argument collapses.
>
>
> An anecdote for you ...
>
> Going back to the 90s and 00s, and even into the 10s, at least here in the UK it was fairly common to hook up PSTN-mobile gateways of some sort (generically called Primicells as a common device from Nokia was the Premicell) to the company PBX. This has been the case at my previous 2 jobs. At my last job, we had one of these, used only for low volumes of traffic between the office and our 3-4 engineers. We had to disconnect it one time as we got a call from our mobile provider that basically said "using one of those is not allowed, disconnect it or we terminate all your phones". Given our usage patterns, I don't think it did as many call minutes as lots of people would do with their real phones !
>
> But at the time, the mobile industry was used to extracting high termination charges for incoming calls from the PSTN. So allowing PBX-mobile calls to shift from being PSTN-mobile to mobile-mobile (using "free" inclusive minutes) meant that they lost a slice of revenue from each call. And "because they can", it was common to find such usage prohibited in the contract small print.
>
> Going back to my previous job to that, we ended up stopping using the gateways - at one point we had two on different networks. It just got too much trouble playing whack-a-mole with the routing. Routing whole prefixes for a network through a device on that network was not a problem - but back then, if someone ported their number* then the network charged inter-network rates which were as high as, or even higher, than PSTN calls to the target network. The networks were working on the group of friends problem - if all your friends are on carrier A, and it costs a fortune to call them unless you are on carrier A, then you will also go with carrier A. As a result, all the carriers (we had 4 in the UK at the time) made sure that it was expensive not to be on the same one as your friends. Every time we got the bill, I'd have to put exception routing in for a bunch of new numbers that had been ported and it got unmanageable.
>
> * I don't know whether you ever sorted this out in the USA, but here in the UK the carriers eventually gave in to pressure and porting was allowed. You could move to network B but keep your number on network A. The call would initially be routed to network A, who would then re-present it to network B - which means another set of charges behind the scenes.
> AFAIK that's still the case here in the UK - though there has long been talk of having a network where any network would be able to determine (down to single number level) which network any call needed to be presented to, and I haven't kept up with how that went on.
>
>
> > If in the future, cellular providers restricts tethering/sharing/etc.,
> > then I think 'portion' of responsibility will also be on shoulders of
> > RFC writers
> > since many parts of the operating software is written with respect to RFCs,
> > and this is NOT a BUSINESS but rather it's a technical communication
> > protocol subject.
>
> I'm not sure there much that can be done about it by the IETF.
> If the IETF writes a standard (e.g. thou shalt provide a /56 to the mobile device) that 100% of the cellular industry disagrees with - then the response from the industry will be to ignore it. Since, as previously mentioned, customers are unable to vote with their feet/wallets (even if they realised that it would be a good thing to do), then it would change nothing.
>
> Simon
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------