[NNagain] Flash priority

[NNagain] Flash priority

[Douglas Goncz A.A.S. M.E.T. 1990]

[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]

One of the things that affects net neutrality and latency is packet
priority and also density of traffic

Most of you here probably know there's a flash bit that can be set in a
packet to indicated top priority

My question firstly is flash traffic legally restricted on the Internet or
can I upload any priority I wish to send?

My question secondly is since I already have firstnet which many of you may
not know about,

Let me describe that firstly

And I think it was 2012 after 9/11 of 2001 the legislature enacted what was
to become firstnet who now provided as AT&T sole source

Firstnet reserves band 14 of lte traffic for exclusive use of first
responders communicating with each other including dispatch

Certain work I do makes me eligible for firstnet plus I feel a lot of
paperwork to get that filled out a lot of paperwork to get that

Excuse me I can't keyboard it's the microphone doing that

So my second question is assuming you know what firstnet is already would I
as a firstnet connected person be able to send a flash priority packet if
needed?


Third question is

Is anyone doing CSD these days? For those of you who don't know CSD takes a
hell of a lot of man with to get a little bit of data through but it is
capable of sending a secure fax when needed substituting bandwidth for the
word man GM sorry.

So my hands shake and I can't use the keyboard and I have ADHD which leaves
errors in place for this I apologize

[-- Attachment #2: Type: text/html, Size: 2068 bytes --]

Re: [NNagain] Flash priority

[David Lang]

[-- Attachment #1: Type: text/plain, Size: 2167 bytes --]

In practice, priority bits are ignored on the Internet. There are no legal 
limits on what bits can be generated, and no reason to trust priority bits that 
come from a different network.

As I understand the current state of the art, best practice is to zero out 
priorities at organizational boundries

David Lang

On Fri, 8 Mar 2024, Douglas Goncz A.A.S. M.E.T. 1990 via Nnagain wrote:

> Date: Fri, 8 Mar 2024 21:31:35 -0500
> From: Douglas Goncz A.A.S. M.E.T. 1990 via Nnagain
>     <nnagain@lists.bufferbloat.net>
> To: nnagain@lists.bufferbloat.net
> Cc: Douglas Goncz  A.A.S. M.E.T. 1990 <DGoncz@replikon.net>
> Subject: [NNagain] Flash priority
> 
> One of the things that affects net neutrality and latency is packet
> priority and also density of traffic
>
> Most of you here probably know there's a flash bit that can be set in a
> packet to indicated top priority
>
> My question firstly is flash traffic legally restricted on the Internet or
> can I upload any priority I wish to send?
>
> My question secondly is since I already have firstnet which many of you may
> not know about,
>
> Let me describe that firstly
>
> And I think it was 2012 after 9/11 of 2001 the legislature enacted what was
> to become firstnet who now provided as AT&T sole source
>
> Firstnet reserves band 14 of lte traffic for exclusive use of first
> responders communicating with each other including dispatch
>
> Certain work I do makes me eligible for firstnet plus I feel a lot of
> paperwork to get that filled out a lot of paperwork to get that
>
> Excuse me I can't keyboard it's the microphone doing that
>
> So my second question is assuming you know what firstnet is already would I
> as a firstnet connected person be able to send a flash priority packet if
> needed?
>
>
> Third question is
>
> Is anyone doing CSD these days? For those of you who don't know CSD takes a
> hell of a lot of man with to get a little bit of data through but it is
> capable of sending a secure fax when needed substituting bandwidth for the
> word man GM sorry.
>
> So my hands shake and I can't use the keyboard and I have ADHD which leaves
> errors in place for this I apologize
>

[-- Attachment #2: Type: text/plain, Size: 146 bytes --]

_______________________________________________
Nnagain mailing list
Nnagain@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] Flash priority

[Livingood, Jason]

On 3/8/24, 22:02, "Nnagain on behalf of David Lang via Nnagain" <nnagain-bounces@lists.bufferbloat.net <mailto:nnagain-bounces@lists.bufferbloat.net> on behalf of nnagain@lists.bufferbloat.net <mailto:nnagain@lists.bufferbloat.net>> wrote:

> In practice, priority bits are ignored on the Internet. There are no legal 
limits on what bits can be generated, and no reason to trust priority bits that 
come from a different network.
> As I understand the current state of the art, best practice is to zero out 
priorities at organizational boundries

[JL] Quite true: each network tends to use DSCP marks on a private/internal basis and so will bleach the DSCP marks on ingress from peers. This will, however, change with the upcoming IETF RFC on Non-Queue-Building (NQB) Per Hop Behavior - https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb. And I can report that we at Comcast now permit DSCP-45 inbound for NQB packets, in case developers would like to experiment with this (we just finished updating router configs last week for residential users on DOCSIS; FTTP and commercial are still in process). 

Re: [NNagain] Flash priority

[Sebastian Moeller]

Hi Jason,

> On 9. Mar 2024, at 15:38, Livingood, Jason via Nnagain <nnagain@lists.bufferbloat.net> wrote:
> 
> On 3/8/24, 22:02, "Nnagain on behalf of David Lang via Nnagain" <nnagain-bounces@lists.bufferbloat.net <mailto:nnagain-bounces@lists.bufferbloat.net> on behalf of nnagain@lists.bufferbloat.net <mailto:nnagain@lists.bufferbloat.net>> wrote:
> 
>> In practice, priority bits are ignored on the Internet. There are no legal
> limits on what bits can be generated, and no reason to trust priority bits that 
> come from a different network.
>> As I understand the current state of the art, best practice is to zero out
> priorities at organizational boundries
> 
> [JL] Quite true: each network tends to use DSCP marks on a private/internal basis and so will bleach the DSCP marks on ingress from peers. This will, however, change with the upcoming IETF RFC on Non-Queue-Building (NQB) Per Hop Behavior - h++ps://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb.

[SM] In all respect, that is wishful thinking. Just because an IETF RFC states/recommends something does not mean it actually is implemented that way in the existing internet... Current in-effect RFCs already recommend that ISPs should not change DSCPs that they do not need to use for their own PHB-needs but simply treat them to default forwarding, but that is not what ISPs actually do. Case in point, a big (probably the biggest) DOCSIS ISP in the USA had been remarking a noticeable fraction of packets to CS1 for years (which at a time was defined to mean background or lower priority and is treated as such by default WiFi APs) causing issues at end users' home networks. (Said ISP, to its credit, did fix the issue recently, but it tool a few years...).

Just becyause something is writen in an RFC does not make it reality. And given the hogwash that some RFCs contain, that is not even a bad thing per se. (Examples on request ;) )

> And I can report that we at Comcast now permit DSCP-45 inbound for NQB packets, in case developers would like to experiment with this (we just finished updating router configs last week for residential users on DOCSIS; FTTP and commercial are still in process).

[SM] Since I have your attention, if I try comcast's bespoke networkQuality server (from your L4S tests):
networkQuality -C https://rpm-nqtest-st.comcast.net/.well-known/nq -k -s -f h3,L4S
I saw ECT(1) marking on my egressing packets, but none on the ingressing packets... that does not seem to be in line with the L4S RFCs (giving another example why RFC text alone is not sufficient for much). (Sidenote: if all L4S testing is happening in isolated networks, why wait for L4S becoming RFCs before starting these tests?)

> 
> 
> 
> 
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> h++ps://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] [EXTERNAL] Re: Flash priority

[Livingood, Jason]

On 3/9/24, 10:04, "Sebastian Moeller" <moeller0@gmx.de <mailto:moeller0@gmx.de>> wrote:
> [SM] ...a big (probably the biggest) DOCSIS ISP in the USA had been remarking a noticeable fraction of packets to CS1 for years (which at a time was defined to mean background or lower priority and is treated as such by default WiFi APs) causing issues at end users' home networks. (Said ISP, to its credit, did fix the issue recently, but it tool a few years...).

[JL] Once the issue was escalated to me (thank you), it was fixed very quickly. ;-) 

> [SM] Since I have your attention, if I try comcast's bespoke networkQuality server (from your L4S tests)...I saw ECT(1) marking on my egressing packets, but none on the ingressing packets... that does not seem to be in line with the L4S RFCs (giving another example why RFC text alone is not sufficient for much). 

[JL] That is far from a production server and we've been making config changes to that box all last week as we prepare for more testing - I would not trust any recent results. But in any case, if you are not seeing ECN marks on packets coming back to you, and you are off-net, then something on the path back to you is bleaching. Feel free to send me a traceroute privately and we can continue to discuss it. 

Jason

Re: [NNagain] Flash priority

[rjmcmahon]

> [JL] Quite true: each network tends to use DSCP marks on a
> private/internal basis and so will bleach the DSCP marks on ingress
> from peers. This will, however, change with the upcoming IETF RFC on
> Non-Queue-Building (NQB) Per Hop Behavior -
> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb. And I can
> report that we at Comcast now permit DSCP-45 inbound for NQB packets,
> in case developers would like to experiment with this (we just
> finished updating router configs last week for residential users on
> DOCSIS; FTTP and commercial are still in process).

iperf 2 now supports a --dscp option as a convenience (vs setting the 
--tos byte.) I can confirm --dscp 45 is being passed over my xfinity hop 
to my linodes (now Akamai) servers in both directions at multiple colo 
locations.

The --dscp is in the master branch. 
https://sourceforge.net/p/iperf2/code/ci/master/tree/  Older versions 
require --tos and setting the byte, e.g. 180

Bob

Re: [NNagain] Flash priority

[rjmcmahon]

I should note that I haven't evaluated ECN marks, just that 45 gets 
passed to/fro

Bob
>> [JL] Quite true: each network tends to use DSCP marks on a
>> private/internal basis and so will bleach the DSCP marks on ingress
>> from peers. This will, however, change with the upcoming IETF RFC on
>> Non-Queue-Building (NQB) Per Hop Behavior -
>> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb. And I can
>> report that we at Comcast now permit DSCP-45 inbound for NQB packets,
>> in case developers would like to experiment with this (we just
>> finished updating router configs last week for residential users on
>> DOCSIS; FTTP and commercial are still in process).
> 
> iperf 2 now supports a --dscp option as a convenience (vs setting the
> --tos byte.) I can confirm --dscp 45 is being passed over my xfinity
> hop to my linodes (now Akamai) servers in both directions at multiple
> colo locations.
> 
> The --dscp is in the master branch.
> https://sourceforge.net/p/iperf2/code/ci/master/tree/  Older versions
> require --tos and setting the byte, e.g. 180
> 
> Bob
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] Flash priority

[Sebastian Moeller]

Hi Bob,

so having iperf2 actually check and report this information, obviously is the end game here (especially reporting, the DSCP and ECN pattern send, the patterns recswivec by the other side and what the receiver saw in the response packets would be really helpful).

But one can use tcpdump as a crude hack to get the desired information:

Here are my GOTO tcpdump invocations for that purpose...

# ECN IPv4/6
tcpdump -i pppoe-wan -v -n '(ip6 and (ip6[0:2] & 0x30) >> 4  != 0)' or '(ip and (ip[1] & 0x3) != 0)' # NOT Not-ECT
tcpdump -i pppoe-wan -v -n '(ip6 and (ip6[0:2] & 0x30) >> 4  == 1)' or '(ip and (ip[1] & 0x3) == 1)' # ECT(1)
tcpdump -i pppoe-wan -v -n '(ip6 and (ip6[0:2] & 0x30) >> 4  == 2)' or '(ip and (ip[1] & 0x3) == 2)' # ECT(0)
tcpdump -i pppoe-wan -v -n '(ip6 and (ip6[0:2] & 0x30) >> 4  == 3)' or '(ip and (ip[1] & 0x3) == 3)' # CE

# TCP ECN IPv4/6: (for IPv6 see see https://ask.wireshark.org/question/27153/i-am-trying-to-capture-tcp-syn-on-ipv6-packets-but-i-only-get-ipv4/)
tcpdump -i pppoe-wan -v -n '(tcp[tcpflags] & (tcp-ece|tcp-cwr) != 0)' or '((ip6[6] = 6) and (ip6[53] & 0xC0 != 0))' # TCP ECN flags, ECN in action
tcpdump -i pppoe-wan -v -n '(tcp[tcpflags] & tcp-ece != 0)' or '((ip6[6] = 6) and (ip6[53] & 0x40 != 0))' # TCP ECN flags, ECE: ECN-Echo (reported as E)
tcpdump -i pppoe-wan -v -n '(tcp[tcpflags] & tcp-cwr != 0)' or '((ip6[6] = 6) and (ip6[53] & 0x80 != 0))' # TCP ECN flags, CWR: Congestion Window Reduced (reported as W)


# IPv4/6 everything decimal DSCP 45 0x2D
tcpdump -i pppoe-wan -v -n '(ip and (ip[1] & 0xfc) >> 2 == 0x2D)' or '(ip6 and (ip6[0:2] & 0xfc0) >> 4  == 0x2D)'


Sure this is not super convenient, but they can help a lot in quick and dirty debugging...

Note: pppoe-wan is my OpenWrt router's wan interface.



> On 9. Mar 2024, at 19:43, rjmcmahon via Nnagain <nnagain@lists.bufferbloat.net> wrote:
> 
> I should note that I haven't evaluated ECN marks, just that 45 gets passed to/fro
> 
> Bob
>>> [JL] Quite true: each network tends to use DSCP marks on a
>>> private/internal basis and so will bleach the DSCP marks on ingress
>>> from peers. This will, however, change with the upcoming IETF RFC on
>>> Non-Queue-Building (NQB) Per Hop Behavior -
>>> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb. And I can
>>> report that we at Comcast now permit DSCP-45 inbound for NQB packets,
>>> in case developers would like to experiment with this (we just
>>> finished updating router configs last week for residential users on
>>> DOCSIS; FTTP and commercial are still in process).
>> iperf 2 now supports a --dscp option as a convenience (vs setting the
>> --tos byte.) I can confirm --dscp 45 is being passed over my xfinity
>> hop to my linodes (now Akamai) servers in both directions at multiple
>> colo locations.
>> The --dscp is in the master branch.
>> https://sourceforge.net/p/iperf2/code/ci/master/tree/  Older versions
>> require --tos and setting the byte, e.g. 180
>> Bob
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] Flash priority

[rjmcmahon]

Adding ECN observations is on the todo list. Likely using EBPFs.

It would be great if there were a L4S CCA were released in a released 
kernel vs build your own.

Then being able to try different marking planes.

Finally, there is --tcp-tx-delay to support testing with different RTTs 
as the RTT should impact the ECN control loop's "order." This is better 
than netem delays because it's per socket. This is already supported but 
does require qdisc of fq (not fq_codel)

Note: I tried to support a dynamic tx delays but that didn't work to 
well.

Bob
> Hi Bob,
> 
> so having iperf2 actually check and report this information, obviously
> is the end game here (especially reporting, the DSCP and ECN pattern
> send, the patterns recswivec by the other side and what the receiver
> saw in the response packets would be really helpful).
> 
> But one can use tcpdump as a crude hack to get the desired information:
> 
> Here are my GOTO tcpdump invocations for that purpose...
> 
> # ECN IPv4/6
> tcpdump -i pppoe-wan -v -n '(ip6 and (ip6[0:2] & 0x30) >> 4  != 0)' or
> '(ip and (ip[1] & 0x3) != 0)' # NOT Not-ECT
> tcpdump -i pppoe-wan -v -n '(ip6 and (ip6[0:2] & 0x30) >> 4  == 1)' or
> '(ip and (ip[1] & 0x3) == 1)' # ECT(1)
> tcpdump -i pppoe-wan -v -n '(ip6 and (ip6[0:2] & 0x30) >> 4  == 2)' or
> '(ip and (ip[1] & 0x3) == 2)' # ECT(0)
> tcpdump -i pppoe-wan -v -n '(ip6 and (ip6[0:2] & 0x30) >> 4  == 3)' or
> '(ip and (ip[1] & 0x3) == 3)' # CE
> 
> # TCP ECN IPv4/6: (for IPv6 see see
> https://ask.wireshark.org/question/27153/i-am-trying-to-capture-tcp-syn-on-ipv6-packets-but-i-only-get-ipv4/)
> tcpdump -i pppoe-wan -v -n '(tcp[tcpflags] & (tcp-ece|tcp-cwr) != 0)'
> or '((ip6[6] = 6) and (ip6[53] & 0xC0 != 0))' # TCP ECN flags, ECN in
> action
> tcpdump -i pppoe-wan -v -n '(tcp[tcpflags] & tcp-ece != 0)' or
> '((ip6[6] = 6) and (ip6[53] & 0x40 != 0))' # TCP ECN flags, ECE:
> ECN-Echo (reported as E)
> tcpdump -i pppoe-wan -v -n '(tcp[tcpflags] & tcp-cwr != 0)' or
> '((ip6[6] = 6) and (ip6[53] & 0x80 != 0))' # TCP ECN flags, CWR:
> Congestion Window Reduced (reported as W)
> 
> 
> # IPv4/6 everything decimal DSCP 45 0x2D
> tcpdump -i pppoe-wan -v -n '(ip and (ip[1] & 0xfc) >> 2 == 0x2D)' or
> '(ip6 and (ip6[0:2] & 0xfc0) >> 4  == 0x2D)'
> 
> 
> Sure this is not super convenient, but they can help a lot in quick
> and dirty debugging...
> 
> Note: pppoe-wan is my OpenWrt router's wan interface.
> 
> 
> 
>> On 9. Mar 2024, at 19:43, rjmcmahon via Nnagain 
>> <nnagain@lists.bufferbloat.net> wrote:
>> 
>> I should note that I haven't evaluated ECN marks, just that 45 gets 
>> passed to/fro
>> 
>> Bob
>>>> [JL] Quite true: each network tends to use DSCP marks on a
>>>> private/internal basis and so will bleach the DSCP marks on ingress
>>>> from peers. This will, however, change with the upcoming IETF RFC on
>>>> Non-Queue-Building (NQB) Per Hop Behavior -
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-nqb. And I 
>>>> can
>>>> report that we at Comcast now permit DSCP-45 inbound for NQB 
>>>> packets,
>>>> in case developers would like to experiment with this (we just
>>>> finished updating router configs last week for residential users on
>>>> DOCSIS; FTTP and commercial are still in process).
>>> iperf 2 now supports a --dscp option as a convenience (vs setting the
>>> --tos byte.) I can confirm --dscp 45 is being passed over my xfinity
>>> hop to my linodes (now Akamai) servers in both directions at multiple
>>> colo locations.
>>> The --dscp is in the master branch.
>>> https://sourceforge.net/p/iperf2/code/ci/master/tree/  Older versions
>>> require --tos and setting the byte, e.g. 180
>>> Bob
>>> _______________________________________________
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] Flash priority

[Lee]

On Sat, Mar 9, 2024 at 1:39 PM rjmcmahon via Nnagain
<nnagain@lists.bufferbloat.net> wrote:
>
> > [JL] Quite true: each network tends to use DSCP marks on a
> > private/internal basis and so will bleach the DSCP marks on ingress
> > from peers.

Anyone else seeing traffic from gmail coming in with a DSCP of CS4?

> iperf 2 now supports a --dscp option as a convenience (vs setting the
> --tos byte.) I can confirm --dscp 45 is being passed over my xfinity hop
> to my linodes (now Akamai) servers in both directions at multiple colo
> locations.
>
> The --dscp is in the master branch.
> https://sourceforge.net/p/iperf2/code/ci/master/tree/  Older versions
> require --tos and setting the byte, e.g. 180

https://sourceforge.net/projects/iperf2/files/README/download
2.1.9 (as of March 14th, 2023)

It's been a year, maybe it's time for a 2.1.10?

Lee

Re: [NNagain] Flash priority

[rjmcmahon]

e byte, e.g. 180
> 
> https://sourceforge.net/projects/iperf2/files/README/download
> 2.1.9 (as of March 14th, 2023)
> 
> It's been a year, maybe it's time for a 2.1.10?
> 
> Lee

Yes, I've got one last bug in the pipeline that's being actively worked 
on. Then we create a release candidate that goes into all our rigs to 
make sure, at a minimum, the throughput measurements give statistically 
the same values as previous releases when testing various WiFi chips and 
various operating systems. That typically takes two weeks or so. My goal 
is to have it all done and released by end of March.

Bob

Re: [NNagain] Flash priority

[Dick Roy]

[-- Attachment #1: Type: text/plain, Size: 3206 bytes --]

 

 

  _____  

From: Nnagain [mailto:nnagain-bounces@lists.bufferbloat.net] On Behalf Of
Douglas Goncz A.A.S. M.E.T. 1990 via Nnagain
Sent: Friday, March 8, 2024 6:32 PM
To: nnagain@lists.bufferbloat.net
Cc: Douglas Goncz A.A.S. M.E.T. 1990
Subject: [NNagain] Flash priority

 

One of the things that affects net neutrality and latency is packet priority
and also density of traffic

 

Most of you here probably know there's a flash bit that can be set in a
packet to indicated top priority

[RR] One man’s “top priority” packet is another man’s
“congesting/nuisance”packet.  Assigning priorities to an application’s ADUs
on the web is simply not going to happen in any logical, rational, or
meaningful way for obvious reasons.   There is not nor will there be, a
global internet police force, and we don’t really want one again for obvious
reasons.  As long as people think that gaming packets have any priority
whatsoever, this problem will continue to exist until such time as the
information carrying capacity of the internet exceeds that of the gamer’s
demands by an order of magnitude.  And, of course, that will never happen
because when you build a faster highway, “they” will build more cars to fill
it up!  IMO, the ONLY “way forward” is to train human beings to think for
themselves and realize that frivolous use of the precious resource called
the web is simply NOT in their best interest.  That is, bring up our
children to “get a life”! For the time being, I guess we all have to put up
with “stupid cat videos”and “minecrafters” (OK … I am dating myself:-))
doing what they do best … increasing latency for everyone! Thinking that the
web should be a resource for the betterment of mankind is a dream that will
only become a reality when “WE BELIEVE IT WILL”! Unfortunately, we are not
there yet :-(:-(:-(

 

RR

 

My question firstly is flash traffic legally restricted on the Internet or
can I upload any priority I wish to send?

 

My question secondly is since I already have firstnet which many of you may
not know about,

 

Let me describe that firstly

 

And I think it was 2012 after 9/11 of 2001 the legislature enacted what was
to become firstnet who now provided as AT&T sole source

 

Firstnet reserves band 14 of lte traffic for exclusive use of first
responders communicating with each other including dispatch

 

Certain work I do makes me eligible for firstnet plus I feel a lot of
paperwork to get that filled out a lot of paperwork to get that

 

Excuse me I can't keyboard it's the microphone doing that

 

So my second question is assuming you know what firstnet is already would I
as a firstnet connected person be able to send a flash priority packet if
needed?

 

 

Third question is

 

Is anyone doing CSD these days? For those of you who don't know CSD takes a
hell of a lot of man with to get a little bit of data through but it is
capable of sending a secure fax when needed substituting bandwidth for the
word man GM sorry.

 

So my hands shake and I can't use the keyboard and I have ADHD which leaves
errors in place for this I apologize


[-- Attachment #2: Type: text/html, Size: 10778 bytes --]

Re: [NNagain] Flash priority

[Vint Cerf]

[-- Attachment #1.1: Type: text/plain, Size: 2234 bytes --]

Flash priority is a long dead leftover from US DoD attempt to map its
AUTODIN messaging system priorities to Internet packets.
Never implemented and, as has been mentioned, ignored for all practical
purposes.

v


On Fri, Mar 8, 2024 at 9:31 PM Douglas Goncz A.A.S. M.E.T. 1990 via Nnagain
<nnagain@lists.bufferbloat.net> wrote:

> One of the things that affects net neutrality and latency is packet
> priority and also density of traffic
>
> Most of you here probably know there's a flash bit that can be set in a
> packet to indicated top priority
>
> My question firstly is flash traffic legally restricted on the Internet or
> can I upload any priority I wish to send?
>
> My question secondly is since I already have firstnet which many of you
> may not know about,
>
> Let me describe that firstly
>
> And I think it was 2012 after 9/11 of 2001 the legislature enacted what
> was to become firstnet who now provided as AT&T sole source
>
> Firstnet reserves band 14 of lte traffic for exclusive use of first
> responders communicating with each other including dispatch
>
> Certain work I do makes me eligible for firstnet plus I feel a lot of
> paperwork to get that filled out a lot of paperwork to get that
>
> Excuse me I can't keyboard it's the microphone doing that
>
> So my second question is assuming you know what firstnet is already would
> I as a firstnet connected person be able to send a flash priority packet if
> needed?
>
>
> Third question is
>
> Is anyone doing CSD these days? For those of you who don't know CSD takes
> a hell of a lot of man with to get a little bit of data through but it is
> capable of sending a secure fax when needed substituting bandwidth for the
> word man GM sorry.
>
> So my hands shake and I can't use the keyboard and I have ADHD which
> leaves errors in place for this I apologize
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice

[-- Attachment #1.2: Type: text/html, Size: 3564 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4006 bytes --]

Re: [NNagain] Flash priority

[Joe Hamelin]

[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]

Even then, one could just set the Flash Override bit.  -Joe

On Sat, Mar 9, 2024 at 1:41 AM Vint Cerf via Nnagain <
nnagain@lists.bufferbloat.net> wrote:

> Flash priority is a long dead leftover from US DoD attempt to map its
> AUTODIN messaging system priorities to Internet packets.
> Never implemented and, as has been mentioned, ignored for all practical
> purposes.
>
> v
>
>
> On Fri, Mar 8, 2024 at 9:31 PM Douglas Goncz A.A.S. M.E.T. 1990 via
> Nnagain <nnagain@lists.bufferbloat.net> wrote:
>
>> One of the things that affects net neutrality and latency is packet
>> priority and also density of traffic
>>
>> Most of you here probably know there's a flash bit that can be set in a
>> packet to indicated top priority
>>
>> My question firstly is flash traffic legally restricted on the Internet
>> or can I upload any priority I wish to send?
>>
>> My question secondly is since I already have firstnet which many of you
>> may not know about,
>>
>> Let me describe that firstly
>>
>> And I think it was 2012 after 9/11 of 2001 the legislature enacted what
>> was to become firstnet who now provided as AT&T sole source
>>
>> Firstnet reserves band 14 of lte traffic for exclusive use of first
>> responders communicating with each other including dispatch
>>
>> Certain work I do makes me eligible for firstnet plus I feel a lot of
>> paperwork to get that filled out a lot of paperwork to get that
>>
>> Excuse me I can't keyboard it's the microphone doing that
>>
>> So my second question is assuming you know what firstnet is already would
>> I as a firstnet connected person be able to send a flash priority packet if
>> needed?
>>
>>
>> Third question is
>>
>> Is anyone doing CSD these days? For those of you who don't know CSD takes
>> a hell of a lot of man with to get a little bit of data through but it is
>> capable of sending a secure fax when needed substituting bandwidth for the
>> word man GM sorry.
>>
>> So my hands shake and I can't use the keyboard and I have ADHD which
>> leaves errors in place for this I apologize
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>>
>
>
> --
> Please send any postal/overnight deliveries to:
> Vint Cerf
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346
>
>
> until further notice
>
>
>
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
>


-- 
Joe Hamelin, W7COM, Tulalip, WA  Portland, OR, 360-474-7474

[-- Attachment #2: Type: text/html, Size: 4742 bytes --]

Re: [NNagain] Flash Priority

[Douglas Goncz A.A.S. M.E.T. 1990]

[-- Attachment #1: Type: text/plain, Size: 545 bytes --]

I think some of the cogent points made were

Just because something is in an RFC and recognized or accepted RFC does not
mean it's been established

Ancient rfcs can age out into abandoned protocols

I got the distinct impression now and I think it's reasonable flash
priority is an abandoned protocol

I will stay with firstnet and the engineers there to make sure I have
reliable communication in the event of an Internet emergency so that I can
do what I do best which is help other people and I thank you all for
helping me with this issue.

[-- Attachment #2: Type: text/html, Size: 812 bytes --]

Re: [NNagain] Flash Priority

[Dave Cohen]

[-- Attachment #1: Type: text/plain, Size: 2235 bytes --]

Bear in mind that FirstNet is its own thing, to an extent. Internet
providers will (almost?) always discard priority bits for *general public
Internet service*. FirstNet doesn't qualify as a service for general use,
so it is possible that some markings may be reacted to, or at least not
discarded outright. That is a question for someone more knowledgeable on
the FirstNet service directly.

What I can add is that in a previous life at a Tier 1, any traffic on a
port that touched the public Internet in some manner had priority markings
squashed, and that traffic was placed into the same priority queue on our
backbone links (I recognize that the latter part of this statement opens up
some other neutrality-adjacent worms) - this includes traffic accepted via
peering, not just transit. Customers with private L2/3 services would
either have their markings preserved or acted upon, depending on whether or
not that service was "QoS enabled". The conclusions to reach here are, IMO:

1) Even if FirstNet itself responds to or accepts prioritization markings,
destination networks beyond, where applicable, may not, so the relevance
may be limited regardless.
2) This is deliberate choice at the provider level, even if that choice is
effectively a consensus

On Sat, Mar 9, 2024 at 12:56 PM Douglas Goncz A.A.S. M.E.T. 1990 via
Nnagain <nnagain@lists.bufferbloat.net> wrote:

> I think some of the cogent points made were
>
> Just because something is in an RFC and recognized or accepted RFC does
> not mean it's been established
>
> Ancient rfcs can age out into abandoned protocols
>
> I got the distinct impression now and I think it's reasonable flash
> priority is an abandoned protocol
>
> I will stay with firstnet and the engineers there to make sure I have
> reliable communication in the event of an Internet emergency so that I can
> do what I do best which is help other people and I thank you all for
> helping me with this issue.
>
>
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
>


-- 
- Dave Cohen
craetdave@gmail.com
@dCoSays
www.venicesunlight.com

[-- Attachment #2: Type: text/html, Size: 3239 bytes --]