Joined: 16 May 2010 Posts: 130 Location: San Francisco Bay Area
Posted: Sat Jan 25, 2014 0:00 Post subject:
Lightsword wrote:
This wiki article Comcast download speed fix for Linksys eSeries is somewhat unclear, while the numerical DSCP value of 8 is higher than 0 it actually indicates a lower priority, its just that the Broadcom WL responds too aggressively to that marker and causes massive slowdowns.
DSCP 0 is Class Selector 0, default, Undifferentiated applications.
DSCP 8 is Class Selector 1, Any flow that has no BW assurance.
Per RFC 4594 Guidelines for DiffServ Service Classes, there is no inherent priority difference:
Quote:
Also, note that the service class naming or ordering does not imply any priority ordering. They are simply reference names that are used in this document with associated QoS behaviors that are optimized for the particular application types they support. [emphasis added]
RFC 3662 suggests (not mandates) Class Selector 1 as "Lower Effort", but "starvation is not strictly required"; i.e., that shouldn't result in delays or slowdowns when there is no other traffic.
... PHBs selected by a Class Selector Codepoint SHOULD give packets a probability of timely forwarding that is not lower than that given to packets marked with a Class Selector codepoint of lower relative order, under reasonable operating conditions and traffic loads.
In other words, the driver behavior is simply a bug. _________________ Hope that helps,
John
DD-WRT 21676 K26 Mini, Kong 22000++, Kong 25015-SP1, and 26138
Last edited by JNavas on Sat Jan 25, 2014 0:21; edited 1 time in total
This wiki article Comcast download speed fix for Linksys eSeries is somewhat unclear, while the numerical DSCP value of 8 is higher than 0 it actually indicates a lower priority, its just that the Broadcom WL responds too aggressively to that marker and causes massive slowdowns.
DSCP 0 is Class Selector 0, default, Undifferentiated applications.
DSCP 8 is Class Selector 1, Any flow that has no BW assurance.
Per RFC 4594 Guidelines for DiffServ Service Classes, there is no inherent priority difference:
Quote:
Also, note that the service class naming or ordering does not imply any priority ordering. They are simply reference names that are used in this document with associated QoS behaviors that are optimized for the particular application types they support. [emphasis added]
In other words, the driver behavior is simply a bug.
I see for CS1(DSCP 8) : Low-Priority Data
For CS0(DSCP 0) I see : Standard
My interpretation of that is DSCP 8 is a lower priority than the default(CS0). CS0 is unknown traffic unlike CS1 which is known but low priority traffic. CS0 would be a marking from an application that does not set DSCP even if that application may need priority, on the other hand CS1 is for traffic from applications that are explicitly marked as low priority. I think broadcom enabled aggressive power saving on CS1 traffic because they expected only applications that did not need priority to use it, specifically applications where you would not care about speed but Comcast's nonstandard use of the CS1 priority marker make it so they could no longer enable powersaving on CS1 traffic without dramatically impacting service.
Joined: 16 May 2010 Posts: 130 Location: San Francisco Bay Area
Posted: Sat Jan 25, 2014 0:26 Post subject:
Lightsword wrote:
I see for CS1(DSCP : Low-Priority Data
For CS0(DSCP 0) I see : Standard
My interpretation of that is DSCP 8 is a lower priority than the default(CS0). CS0 is unknown traffic unlike CS1 which is known but low priority traffic. CS0 would be a marking from an application that does not set DSCP even if that application may need priority, on the other hand CS1 is for traffic from applications that are explicitly marked as low priority. I think broadcom enabled aggressive power saving on CS1 traffic because they expected only applications that did not need priority to use it, specifically applications where you would not care about speed but Comcast's nonstandard use of the CS1 priority marker make it so they could no longer enable powersaving on CS1 traffic without dramatically impacting service.
See my updated post, which now includes more citations. There is no mandated priority difference, and there should be no performance difference when there is no other traffic. The purpose of classes is to give certain traffic priority over other traffic, not to delay traffic for any other purpose (including power management). In other words, the driver behavior is simply a bug. _________________ Hope that helps,
John
DD-WRT 21676 K26 Mini, Kong 22000++, Kong 25015-SP1, and 26138
Last edited by JNavas on Sat Jan 25, 2014 0:33; edited 1 time in total
I see for CS1(DSCP : Low-Priority Data
For CS0(DSCP 0) I see : Standard
My interpretation of that is DSCP 8 is a lower priority than the default(CS0). CS0 is unknown traffic unlike CS1 which is known but low priority traffic. CS0 would be a marking from an application that does not set DSCP even if that application may need priority, on the other hand CS1 is for traffic from applications that are explicitly marked as low priority. I think broadcom enabled aggressive power saving on CS1 traffic because they expected only applications that did not need priority to use it, specifically applications where you would not care about speed but Comcast's nonstandard use of the CS1 priority marker make it so they could no longer enable powersaving on CS1 traffic without dramatically impacting service.
See my updated post, which now includes more citations. There is no mandated priority difference, and there should be no performance difference when there is no other traffic. This has nothing to do with power management because traffic is present. The behavior is simply a bug.
That makes sense, so both broadcom and Comcast have problems in that case. Although its somewhat ambiguous, its not required to slow down, but per spec hard to say its necessarily wrong.
Joined: 16 May 2010 Posts: 130 Location: San Francisco Bay Area
Posted: Sat Jan 25, 2014 0:35 Post subject:
Lightsword wrote:
JNavas wrote:
Lightsword wrote:
I see for CS1(DSCP : Low-Priority Data
For CS0(DSCP 0) I see : Standard
My interpretation of that is DSCP 8 is a lower priority than the default(CS0). CS0 is unknown traffic unlike CS1 which is known but low priority traffic. CS0 would be a marking from an application that does not set DSCP even if that application may need priority, on the other hand CS1 is for traffic from applications that are explicitly marked as low priority. I think broadcom enabled aggressive power saving on CS1 traffic because they expected only applications that did not need priority to use it, specifically applications where you would not care about speed but Comcast's nonstandard use of the CS1 priority marker make it so they could no longer enable powersaving on CS1 traffic without dramatically impacting service.
See my updated post, which now includes more citations. There is no mandated priority difference, and there should be no performance difference when there is no other traffic. This has nothing to do with power management because traffic is present. The behavior is simply a bug.
That makes sense, so both broadcom and Comcast have problems in that case.
With respect, it's entirely a Broadcom (and DD-WRT) bug, not a Comcast bug.
Comcast may have a valid purpose for that DSCP value. _________________ Hope that helps,
John
DD-WRT 21676 K26 Mini, Kong 22000++, Kong 25015-SP1, and 26138
I see for CS1(DSCP : Low-Priority Data
For CS0(DSCP 0) I see : Standard
My interpretation of that is DSCP 8 is a lower priority than the default(CS0). CS0 is unknown traffic unlike CS1 which is known but low priority traffic. CS0 would be a marking from an application that does not set DSCP even if that application may need priority, on the other hand CS1 is for traffic from applications that are explicitly marked as low priority. I think broadcom enabled aggressive power saving on CS1 traffic because they expected only applications that did not need priority to use it, specifically applications where you would not care about speed but Comcast's nonstandard use of the CS1 priority marker make it so they could no longer enable powersaving on CS1 traffic without dramatically impacting service.
See my updated post, which now includes more citations. There is no mandated priority difference, and there should be no performance difference when there is no other traffic. This has nothing to do with power management because traffic is present. The behavior is simply a bug.
That makes sense, so both broadcom and Comcast have problems in that case.
With respect, it's entirely a Broadcom (and DD-WRT) bug, not a Comcast bug.
Comcast may have a valid purpose for that DSCP value.
I see no reason for Comcast to transmit that DSCP value to a customers router, they seem to be misusing DSCP for internal routing and neglecting to strip it at the network boundary. Comcast may have a purpose for it(internally) but it is not an expected priority marker for the customer and is thus miscatagorized traffic. VoIP traffic is certainly not CS1 traffic but Comcast is marking it as CS1.
Joined: 16 May 2010 Posts: 130 Location: San Francisco Bay Area
Posted: Sat Jan 25, 2014 1:05 Post subject:
Lightsword wrote:
JNavas wrote:
With respect, it's entirely a Broadcom (and DD-WRT) bug, not a Comcast bug.
Comcast may have a valid purpose for that DSCP value.
I see no reason for Comcast to transmit that DSCP value to a customers router, they seem to be misusing DSCP for internal routing and neglecting to strip it at the network boundary. Comcast may have a purpose for it(internally) but it is not an expected priority marker for the customer and is thus miscatagorized traffic. VoIP traffic is certainly not CS1 traffic but Comcast is marking it as CS1.
Comcast may be using that DSCP value for network management, with some users or traffic getting higher priority than others, a valid use of DSCP, and it has no reason or obligation to change DSCP on traffic passed to the customer, where it should have no adverse effect.
If you still disagree, please cite the relevant RFC (as I have). _________________ Hope that helps,
John
DD-WRT 21676 K26 Mini, Kong 22000++, Kong 25015-SP1, and 26138
With respect, it's entirely a Broadcom (and DD-WRT) bug, not a Comcast bug.
Comcast may have a valid purpose for that DSCP value.
I see no reason for Comcast to transmit that DSCP value to a customers router, they seem to be misusing DSCP for internal routing and neglecting to strip it at the network boundary. Comcast may have a purpose for it(internally) but it is not an expected priority marker for the customer and is thus miscatagorized traffic. VoIP traffic is certainly not CS1 traffic but Comcast is marking it as CS1.
Comcast may be using that DSCP value for network management, with some users or traffic getting higher priority than others, a valid use of DSCP, and it has no reason or obligation to change DSCP on traffic passed to the customer, where it should have no adverse effect.
If you still disagree, please cite the relevant RFC (as I have).
Comcast may have a use for it, but the customer does not, I'm simply stating that for the customer the DSCP value is incorrect and that the marker is not what was sent to the customer. If Comcast does not want to strip DSCP it must be changed by the customers router in order to be "correct" which is something that the customer should not have to do(correct would include CS0 because that is a default unclassified priority). Every other ISP has managed to do network management without passing potentially toxic DSCP markers to customer networks. If the traffic is not CS1 priority traffic and Comcast marks it as CS1 then the traffic is marked wrong.
Joined: 16 May 2010 Posts: 130 Location: San Francisco Bay Area
Posted: Sat Jan 25, 2014 1:26 Post subject:
[quote="Lightsword"]
JNavas wrote:
Comcast may have a use for it, but the customer does not, I'm simply stating that for the customer the DSCP value is incorrect and that the marker is not what was sent to the customer. If Comcast does not want to strip DSCP it must be changed by the customers router in order to be "correct" which is something that the customer should not have to do(correct would include CS0 because that is a default unclassified priority). Every other ISP has managed to do network management without passing potentially toxic DSCP markers to customer networks. If the traffic is not CS1 priority traffic and Comcast marks it as CS1 then the traffic is marked wrong.
It's not "incorrect" or "toxic" -- CS1 may be unique to Comcast, but it's nonetheless valid, causing no problems in properly functioning routers.
What the customer does with DSCP is entirely up to the customer, not Comcast, which has no responsibility to make up for deficiencies in third-party products.
You never "strip" DHCP -- you change it (to whatever you want in your network).
Again, if you're going to make claims, then you should back them up with authoritative RFC citations (as I have), which you've haven't done thus far. _________________ Hope that helps,
John
DD-WRT 21676 K26 Mini, Kong 22000++, Kong 25015-SP1, and 26138
Comcast may have a use for it, but the customer does not, I'm simply stating that for the customer the DSCP value is incorrect and that the marker is not what was sent to the customer. If Comcast does not want to strip DSCP it must be changed by the customers router in order to be "correct" which is something that the customer should not have to do(correct would include CS0 because that is a default unclassified priority). Every other ISP has managed to do network management without passing potentially toxic DSCP markers to customer networks. If the traffic is not CS1 priority traffic and Comcast marks it as CS1 then the traffic is marked wrong.
It's not "incorrect" or "toxic" -- CS1 may be unique to Comcast, but it's nonetheless valid, causing no problems in properly functioning routers.
What the customer does with DSCP is entirely up to the customer, not Comcast, which has no responsibility to make up for deficiencies in third-party products.
You never "strip" DHCP -- you change it (to whatever you want in your network).
Again, if you're going to make claims, then you should back them up with authoritative RFC citations (as I have), which you've haven't done thus far.
Is VoIP traffic "Low-Priority Data"? Customer routers are not typically designed to change DSCP. By "strip" I mean reset to CS0 which is the default. CS0 has no priority while CS1 has low priority these are very different. I'm going off of the RFC you linked.
Joined: 16 May 2010 Posts: 130 Location: San Francisco Bay Area
Posted: Sat Jan 25, 2014 20:17 Post subject:
Lightsword wrote:
JNavas wrote:
It's not "incorrect" or "toxic" -- CS1 may be unique to Comcast, but it's nonetheless valid, causing no problems in properly functioning routers.
What the customer does with DSCP is entirely up to the customer, not Comcast, which has no responsibility to make up for deficiencies in third-party products.
You never "strip" DHCP -- you change it (to whatever you want in your network).
Again, if you're going to make claims, then you should back them up with authoritative RFC citations (as I have), which you've haven't done thus far.
Is VoIP traffic "Low-Priority Data"? Customer routers are not typically designed to change DSCP. By "strip" I mean reset to CS0 which is the default. CS0 has no priority while CS1 has low priority these are very different. I'm going off of the RFC you linked.
As I proved previously, there's no inherent priority difference or performance issue.
Properly functioning routers have no issue with DSCP 8 no matter what the type of traffic (VoIP included).
As I proved previously, Comcast is free to use whatever DSCP values it wishes to manage its network and services, and has no reason much less any obligation to change DSCP to any other value. No ISP is responsible for prioritizing incoming customer Internet traffic.
Arbitrarily changing DSCP to 0 would not have any benefit to VoIP or any other traffic, since all traffic would still be in the same service class.
A vague RFC reference does not quality as a citation. You need to identify the specific RFC(s), specific section(s), and specific text you think supports your claims, as I have.
You should invest the time to learn QoS, as I have, before taking issue with me.
_________________ Hope that helps,
John
DD-WRT 21676 K26 Mini, Kong 22000++, Kong 25015-SP1, and 26138
As I proved previously, there's no inherent priority difference or performance issue.
Properly functioning routers have no issue with DSCP 8 no matter what the type of traffic (VoIP included).
As I proved previously, Comcast is free to use whatever DSCP values it wishes to manage its network and services, and has no reason much less any obligation to change DSCP to any other value. No ISP is responsible for prioritizing incoming customer Internet traffic.
Arbitrarily changing DSCP to 0 would not have any benefit to VoIP or any other traffic, since all traffic would still be in the same service class.
A vague RFC reference does not quality as a citation. You need to identify the specific RFC(s), specific section(s), and specific text you think supports your claims, as I have.
You should invest the time to learn QoS, as I have, before taking issue with me.
1. There is a priority difference between CS1 and CS0, CS0 is the null(default) and CS1 is a specified LOW priority(non-default). There is a difference between not having a priority marker at all and having a low priority marker.
2. This is not necessarily true, especially when there is other traffic not marked as CS1 on the network.
3. This is not the issue, Comcast can manage internally how they want but they should not be transmitting incorrect non-default DSCP to external(customer) networks that they do not control.
4. This is not true, LAN traffic(unless set manually or by an application) would not have DSCP 8 and would thus be incorrectly prioritized over VoIP even if it was not latency sensitive such as a file transfer. This would affect every single router that implements WMM or any other sort of QoS
5. The CS0 and CS1 descriptions are what I'm citing from that RFC. Ctrl-F
6. I've been researching this for a while, this is not something I'm new to.
Joined: 16 May 2010 Posts: 130 Location: San Francisco Bay Area
Posted: Sun Jan 26, 2014 17:19 Post subject:
Lightsword wrote:
JNavas wrote:
As I proved previously, there's no inherent priority difference or performance issue.
Properly functioning routers have no issue with DSCP 8 no matter what the type of traffic (VoIP included).
As I proved previously, Comcast is free to use whatever DSCP values it wishes to manage its network and services, and has no reason much less any obligation to change DSCP to any other value. No ISP is responsible for prioritizing incoming customer Internet traffic.
Arbitrarily changing DSCP to 0 would not have any benefit to VoIP or any other traffic, since all traffic would still be in the same service class.
A vague RFC reference does not quality as a citation. You need to identify the specific RFC(s), specific section(s), and specific text you think supports your claims, as I have.
You should invest the time to learn QoS, as I have, before taking issue with me.
1. There is a priority difference between CS1 and CS0, CS0 is the null(default) and CS1 is a specified LOW priority(non-default). There is a difference between not having a priority marker at all and having a low priority marker.
2. This is not necessarily true, especially when there is other traffic not marked as CS1 on the network.
3. This is not the issue, Comcast can manage internally how they want but they should not be transmitting incorrect non-default DSCP to external(customer) networks that they do not control.
4. This is not true, LAN traffic(unless set manually or by an application) would not have DSCP 8 and would thus be incorrectly prioritized over VoIP even if it was not latency sensitive such as a file transfer. This would affect every single router that implements WMM or any other sort of QoS
5. The CS0 and CS1 descriptions are what I'm citing from that RFC. Ctrl-F
6. I've been researching this for a while, this is not something I'm new to.
With respect, you don't seem to understand basic IP networking much less QoS, don't seem interested in learning more, and just keep repeating the same contentions without anything concrete to back them up, so I'm not going to waste any more time on this. _________________ Hope that helps,
John
DD-WRT 21676 K26 Mini, Kong 22000++, Kong 25015-SP1, and 26138
in the Command Shell window and clicked the "Save Firewall" button.
Better Way
To ensure the fix is applied to the correct VLAN, use this instead for Firewall:
Code:
iptables -t mangle -A PREROUTING -i `nvram get wan_ifname` -j DSCP --set-dscp 0
Note: I currently have no way of testing this, so would appreciate someone checking it.
Sorry for the very late reply. This did not work. With the fix I initially applied I was able to pull down about 57Mbps. It makes sense as VLAN2 is my WAN bridge. With this new fix, the problem returned and I was peaking at around 14Mbps.
Posted: Tue Feb 25, 2014 11:10 Post subject: We really need the device driver fixed
Just something to add on this issue. The iptables fix DOES NOT WORK if your just using the router as an access point. That is, you have another NAT or firewall and you have plugged it's output into one of the lan ports, to bridge the traffic over to the wireless port. I ran into this when trying to do that with a Linksys E1200 v1
: Low-Priority Data