It is programmed to detect when a modem isn’t using all the bandwidth available to it and automatically adjust the modem to deliver significant increases in speed and capacity.
Maybe think of it slightly differently - the system looks at what devices are currently talking on the network (and on what parts of the spectrum and what each device can do - eg use OFDM or bond 4 channels vs 32 channels), then shuffle/distribute them around in the available spectrum so as to maximize the performance potential of each one and the network as a whole.
Considering it's just a QoS setting on their edge router......
FWIW, as a minor aside, it is not really a QoS setting as this would typically imply use of DSCP at the IP packet level - more a DOCSIS layer thing. But your core observation holds - that this is done at the edge router (CMTS) and to the cable modem that the CMTS connects to in the network.
Tech that "speeds up" lesser-used connections then slows them down again during heavy use
It is not slowing someone down. This is not an IP-layer congestion management system but rather more of a DOCSIS link layer network efficiency / performance improvement system. In the same way moving to OFDM meant more efficient use of RF spectrum then similarly this system provides a way to wring even more performance out of the network.
I believe that the statement really meant to point to the connecting equipment at locations owned by Comcast, not at the connection point in someone's home.
It looks at the RF interface on your cable modem CPE. Whether owned or leased the network need to work with the modem to do things like assign the correct DOCSIS channels and so on. Connecting to and managing the RF interface is an integral part of network management - no essentially nothing new in terms of managing that interface - but more about efficiencies that have been gained.
> Some cable ISPs have features with names like "speed boost", where they'll make your modem faster than usual when you're not using it much, and then reduce it after a few seconds or minutes of heavy use.
Do any ISPs still offer this? Comcast phased it out many years ago. The release of DOCSIS 3.0 channel bonding make it a sort of outdated approach.
Comcast's network does not do that (in FD I work there...) NXDOMAIN redirection was done for a short period that ended in January 2012 when DNSSEC Validation was turned on (1st large ISP in the US to do so).
Comcast is definitely *not* doing that (I work there). Here is a demonstration using dig @ that server and a name that does not exist. 1st example results in NXDOMAIN. 2nd example gets a SERVFAIL, likely because the auth server does not respond to recursions from 4.2.2.2.
dig @4.2.2.2 nonamehere.example.com
; <<>> DiG 9.10.6 <<>> @4.2.2.2 nonamehere.example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19479
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 8192
;; QUESTION SECTION:
;nonamehere.example.com. IN A
;; AUTHORITY SECTION:
example.com. 1884 IN SOA ns.icann.org. noc.dns.icann.org. 2019101516 7200 3600 1209600 3600
;; Query time: 84 msec
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Fri Nov 08 18:06:57 EST 2019
;; MSG SIZE rcvd: 107
dig @4.2.2.2 flubboxzing.org
; <<>> DiG 9.10.6 <<>> @4.2.2.2 flubboxzing.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38884
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;flubboxzing.org. IN A
;; Query time: 24 msec
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Fri Nov 08 18:09:20 EST 2019
;; MSG SIZE rcvd: 33
Techdirt has not posted any stories submitted by jlivingood.
Re:
Maybe think of it slightly differently - the system looks at what devices are currently talking on the network (and on what parts of the spectrum and what each device can do - eg use OFDM or bond 4 channels vs 32 channels), then shuffle/distribute them around in the available spectrum so as to maximize the performance potential of each one and the network as a whole.
Re: Re: Re:
FWIW, as a minor aside, it is not really a QoS setting as this would typically imply use of DSCP at the IP packet level - more a DOCSIS layer thing. But your core observation holds - that this is done at the edge router (CMTS) and to the cable modem that the CMTS connects to in the network.
(untitled comment)
It is not slowing someone down. This is not an IP-layer congestion management system but rather more of a DOCSIS link layer network efficiency / performance improvement system. In the same way moving to OFDM meant more efficient use of RF spectrum then similarly this system provides a way to wring even more performance out of the network.
That's a pretty pathetic retort.
Re: Re:
It looks at the RF interface on your cable modem CPE. Whether owned or leased the network need to work with the modem to do things like assign the correct DOCSIS channels and so on. Connecting to and managing the RF interface is an integral part of network management - no essentially nothing new in terms of managing that interface - but more about efficiencies that have been gained.
Re: Re:
Re: Re: Re: Re: The Reason
Comcast's network does not do that (in FD I work there...) NXDOMAIN redirection was done for a short period that ended in January 2012 when DNSSEC Validation was turned on (1st large ISP in the US to do so).
Re: Re: Re: The Reason Telecoms don't Want Encrypted DNS Lookups
Wow - that is all mangled in plain text. Trying again in markdown:
dig @4.2.2.2 flubboxzing.org
; <<>> DiG 9.10.6 <<>> @4.2.2.2 flubboxzing.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38884
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
dig @4.2.2.2 nonamehere.example.com
; <<>> DiG 9.10.6 <<>> @4.2.2.2 nonamehere.example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19479
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 8192
;; QUESTION SECTION:
;nonamehere.example.com. IN A
;; AUTHORITY SECTION:
example.com. 1884 IN SOA ns.icann.org. noc.dns.icann.org. 2019101516 7200 3600 1209600 3600
;; Query time: 84 msec
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Fri Nov 08 18:06:57 EST 2019
;; MSG SIZE rcvd: 107
;; QUESTION SECTION:
;flubboxzing.org. IN A
;; Query time: 24 msec
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Fri Nov 08 18:09:20 EST 2019
;; MSG SIZE rcvd: 33
Re: Re: The Reason Telecoms don't Want Encrypted DNS Lookups
Techdirt has not posted any stories submitted by jlivingood.
Submit a story now.
Tools & Services
TwitterFacebook
RSS
Podcast
Research & Reports
Company
About UsAdvertising Policies
Privacy
Contact
Help & FeedbackMedia Kit
Sponsor/Advertise
Submit a Story
More
Copia InstituteInsider Shop
Support Techdirt