From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bosmailout09.eigbox.net (bosmailout09.eigbox.net [66.96.189.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8A96F3B29D for ; Sat, 9 Mar 2024 15:42:21 -0500 (EST) Received: from bosmailscan09.eigbox.net ([10.20.15.9]) by bosmailout09.eigbox.net with esmtp (Exim) id 1rj3WM-0000GN-UN for nnagain@lists.bufferbloat.net; Sat, 09 Mar 2024 15:42:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alum.mit.edu; s=dkim; h=Sender:Content-Type:MIME-Version:Message-ID:Date: Subject:In-Reply-To:References:Cc:To:From:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ks/YhOLwdXnjBkR1U6oYFmo2aBurPhQt7HzSV6w9N7U=; b=PuViSBnozKplBrt3saVwcBGn6n JB+/kiDWJbUXFWi61hsKA1u0bCTCJIZP7ti2EkVcZBWECrvT1FWRv4bLieMwRte0K+NP89n9o9+9s lIix7ZdfQqzFBei2rS+meVRM0kfPv7mOsxbPnNEOQyhxKyYQsIIvnlmAKFnGGHDeuOgE5giqC3qjD 1cNGqdxvC4HFNCavMKySchVGeCLLU7JBFgTeNaz0f3r/kIpHB0k7CHw7sHMHW7yzh+UZm13KPKI+d pEBwP54fFjN9WipHxs5OCg4Ujo0E4hWr1vmh2552MhQHqWCLDZy98JxjB53AtuRlU4yowH3o3NN66 vhwOqZug==; Received: from [10.115.3.32] (helo=bosimpout12) by bosmailscan09.eigbox.net with esmtp (Exim) id 1rj3WK-0006U3-Mr for nnagain@lists.bufferbloat.net; Sat, 09 Mar 2024 15:42:16 -0500 Received: from bosauthsmtp12.yourhostingaccount.com ([10.20.18.12]) by bosimpout12 with id wkiD2B0020FdZ9W01kiGQB; Sat, 09 Mar 2024 15:42:16 -0500 X-Authority-Analysis: v=2.3 cv=dOg9ZNRb c=1 sm=1 tr=0 a=wx0GOVZTcu8EuaXTIXj3VQ==:117 a=tKttg/DTfI8zZz0UFxdR5w==:17 a=K6JAEmCyrfEA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=0c0kBfmvspWedDz_x38A:9 a=wPNLvfGTeEIA:10 a=SSmOFEACAAAA:8 a=Yu2YY0zi3yuW6yjWyoQA:9 a=ydAZn9RP77EfbPUl:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 Received: from c-73-158-253-41.hsd1.ca.comcast.net ([73.158.253.41]:53842 helo=SRA6) by bosauthsmtp12.eigbox.net with esmtpa (Exim) id 1rj3WH-0001uj-7w; Sat, 09 Mar 2024 15:42:13 -0500 Reply-To: From: "Dick Roy" To: =?iso-8859-1?Q?'Network_Neutrality_is_back!_Let=B4s_make_the_technical_as?= =?iso-8859-1?Q?pects_heard_this_time!'?= References: In-Reply-To: Date: Sat, 9 Mar 2024 12:42:10 -0800 Organization: SRA Message-ID: <6BE25389766648E5AA898A86F4937D34@SRA6> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0167_01DA721F.35FC49D0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AdpyAoNZavCjqjAoRkGsXB3RnJ0DoAAXqjqA X-MimeOLE: Produced By Microsoft MimeOLE X-EN-UserInfo: f809475445fb8041985048e338e1a001:931c98230c6409dcc37fa7e93b490c27 X-EN-AuthUser: dickroy@intellicommunications.com Sender: "Dick Roy" X-EN-OrigIP: 73.158.253.41 X-EN-OrigHost: c-73-158-253-41.hsd1.ca.comcast.net Subject: Re: [NNagain] Verizon, T-Mobile, Nokia get noisy on network slicing and net neutrality (LightReading) X-BeenThere: nnagain@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: =?utf-8?q?Network_Neutrality_is_back!_Let=C2=B4s_make_the_technical_aspects_heard_this_time!?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2024 20:42:21 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0167_01DA721F.35FC49D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 =85 =20 As expected this technique is designed to allow exactly what NN was = designed to prohibit (treating packets differentially in the internet based on economic considerations*)... this is IMHO why instead of calling a spade = a spade mobile carriers avoid describing this in a useful way, as it is exactly about prioritisation... IMHO that will back fire, and a better avenue would be to be open about what it enables and propose a method to restrict the potential issues. E.g. (I am making this up on the fly, so = it will likely not hold up to any degree of scrutiny) by self limiting to = never commit more than X% of a cell's capacity to slicing, IFF the cell is = used for normal end user service at all. So admit that there is some = trade-off here, limit the fall-out, and then describe why we as a society should embrace that trade-off. I am a bit sceptical about the whole car 2 car communication thing (that is cars talk to cars, not people n cars talk = to people on cars ;) ), but if a Carrier believes there is value in that = for e.g. accident avoidance, then tell how this requires the stricter = network guarantees that (only?) slicing can deliver. [RR] V2X communications for saving lives will NEVER go through ANY = carrier=92s network in spite of what you hear. There is simply no way anyone is = going to pay to have BSMs broadcast 10 times a second to prevent accidents, = and NO CARRIER is going to give that capacity away for free, even if they had enough to carry the traffic, which they do not by many orders of magnitude!!! More importantly, the information being exchanged does NOT require a network to get where it needs to go! The 5G hype you hear = from various carriers and equipment suppliers related to V2X communications = is all powerpoint BS (to make shareholders happy). And there is a ton of it = out there! :-):-) =20 RR ------=_NextPart_000_0167_01DA721F.35FC49D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

 

…

 

As expected this technique is designed to allow exactly what NN = was designed to prohibit (treating packets differentially in the internet = based on economic considerations*)... this is IMHO why instead of calling a spade = a spade mobile carriers avoid describing this in a useful way, as it is = exactly about prioritisation... IMHO that will back fire, and a better avenue = would be to be open about what it enables and propose a method to restrict the = potential issues. E.g. (I am making this up on the fly, so it will likely not hold = up to any degree of scrutiny) by self limiting to never commit more than X% of = a cell's capacity to slicing, IFF the cell is used for normal end user = service at all. So admit that there is some trade-off here, limit the fall-out, and = then describe why we as a society should embrace that trade-off. I am a bit sceptical about the whole car 2 = car communication thing (that is cars talk to cars, not people n cars talk = to people on cars ;) ), but if a Carrier believes there is value in that = for e.g. accident avoidance, then tell how this requires the stricter network = guarantees that (only?) slicing can deliver.

[RR] V2X communications for saving lives will NEVER go through ANY = carrier’s network in spite of what you hear. =A0There is simply no way anyone is = going to pay to have BSMs broadcast 10 times a second to prevent accidents, and = NO CARRIER is going to give that capacity away for free, even if they had = enough to carry the traffic, which they do not by many orders of magnitude!!! = =A0More importantly, the information being exchanged does NOT require a network = to get where it needs to go! =A0The 5G hype you hear from various carriers and = equipment suppliers related to V2X communications is all powerpoint BS (to make shareholders happy). And there is a ton of it out there! = JJ

 

RR

------=_NextPart_000_0167_01DA721F.35FC49D0--