site Search:


 
    All Forums Hot Topics Gallery






how-to block ads


 
Search Topic:
Uniqs:
3938
Share Topic
Posting?
Post a:
Post a:
Links: ·Web page ·Network Status ·RR FORUM FAQ ·Cable Users FAQ ·Tweaks ·Broadband Modem
page: 1 · 2
AuthorAll Replies

isamu99

join:2004-03-10
Los Angeles, CA

Heads up guys....new trick to eliminate Youtube throttling!

I couldn't reply to the original thread because it's too old, but anyway since that time I have just discovered this new method that fixes the Youtube throttle buffering issue! I tried it and it WORKS!!!!!!

»www.reddit.com/r/technology/comm···youtube/

said by Connor Babel :
go here and read the top comment if you have windows 7 »www.reddit.com/r/technology/comm···youtube/
ps. the thread on reddit is named for time warner but it works with any ISP from my experience
quote:
His Windows guide has you use the Adv Firewall UI instead of netsh which is about 2000 steps too many.

netsh advfirewall firewall add rule name="YoutubeHTTP1" protocol=TCP localport=80 action=block dir=IN remoteip=173.194.55.0/24

netsh advfirewall firewall add rule name="YoutubeHTTP2" protocol=TCP localport=80 action=block dir=IN remoteip=206.111.0.0/16

Enjoy. The incredible thing is now I'm not even seeing any delay when switching to 1080p, I used to see a complete refresh and then a pause.

PS; if you're on XP you'll need to edit the command as they renamed firewall to advfirewall later on (Vista I believe).

Edit: People keep asking how to them remove in case something breaks.. Simple,

netsh advfirewall firewall delete rule name=YoutubeHTTP1

netsh advfirewall firewall delete rule name=YoutubeHTTP2

And an image to show you what you're actually doing- »i.imgur.com/wSoiAe2.png
Let me know if it works for you guys

SyphonBW

join:2004-02-24
Alliance, OH

What if i dont run windows firewall at all?
I have the sbg6580 modem/router from time warner,how do i input this into my router settings and where?



kontos
xyzzy

join:2001-10-04
West Henrietta, NY

reply to isamu99

said by isamu99:

I

Let me know if it works for you guys

I had problems with Youtube up to about a week after that workaround was publicized. I guess either the mass of users routing around that network decreased it's load to a better level, or it got the people who could really fix the problem to actually do something.

isamu99

join:2004-03-10
Los Angeles, CA

I doubt that was the case. I was having buffering problems until I applied the fix.

To the other poster....you don't put those settings in your router, you type them in windows cmd prompt. whether you're using windows firewall or not is irrelevant. try it.



kontos
xyzzy

join:2001-10-04
West Henrietta, NY

said by isamu99:

try it.

Why would I? I have not seen a buffering problem with Youtube in roughly the last two weeks.
Trust me, I've kept this information tucked away and as soon as I have trouble watching a HD video, I'll give it a shot. Otherwise; if it ain't broke...

isamu99

join:2004-03-10
Los Angeles, CA

I was addressing the second part of my post to SyphonBW.



BAF
Baffles
Premium
join:2004-02-22
Gansevoort, NY

reply to isamu99
Umm, I think you're wrong isamu99. If you're not using Windows Firewall, then this won't work.

You *CAN* put these settings in your router if you want. Just add firewall rules to block traffic to those IP blocks, and then the fix is applied to your entire network.



Nick21

join:2010-02-03
New York, NY

reply to isamu99
I don't even see where you could put these settings in SBG6580 admin cp?


SyphonBW

join:2004-02-24
Alliance, OH

Same Here



Nick21

join:2010-02-03
New York, NY

reply to isamu99
It seems more likely settings for your firewall than router. I still can't find out how in my firewall software.


SyphonBW

join:2004-02-24
Alliance, OH

reply to Nick21

said by Nick21:

I don't even see where you could put these settings in SBG6580 admin cp?

Noone knows how?


koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:18

reply to isamu99
Note: I am not a TWC customer.

What's being proposed in that Reddit thread, and in the reference materials that thread cites (some random blog, and that blog cites some random Youtube video), is dangerous on numerous levels. There's a very strong indication that the authors involved do not understand networking, and/or the implications of their ""solution"".

The proposed ""solution"", at the firewall level, does the following:

1. Drop any TCP packet destined to an IP within the 173.194.55.0/24 netblock, with a TCP destination port of 80
2. Drop any TCP packet destined to an IP within the 206.111.0.0/16 netblock, with a TCP destination port of 80

To date, not a single person has provided actual packet captures providing that TWC is doing some kind of HTTP redirection which causes your client to fetch content from alternate locations (e.g. content hosted within the 173.194.55.0/24 or 206.111.0.0/16 netblocks -- BTW, those are, respectively, Google and XO Communications -- and in the case of the former, Google advertises 173.194.0.0/16 via BGP on the Internet).

TWC can't be doing reverse-proxying because otherwise said ""solution"" wouldn't work; they would have to be, for example, looking for very specific HTTP headers and GET requests and injecting an HTTP Location: header into the response, to force the browser to fetch content from an alternate location. If it was done via reverse-proxying (e.g. transparently), the above ""solution"" would not work, since it's being done on the workstation itself.

I suppose an alternate model/method they could be using is wildcard DNS matching (e.g. return IPs within the above netblocks when folks look up very specific FQDNs for c.youtube.com content -- normally they're very strange FQDNs such as r9---sn-nwj7knel.c.youtube.com), in which case using an alternate DNS provider (e.g. OpenDNS) should, unless they're doing transparent DNS response injection, accomplish the same thing. However, in the below referenced video, the author claims "changing DNS providers did nothing".

I can talk at extreme length about this whole ordeal and what it actually amounts to at a networking level, but it's all speculative because nobody has provided actual evidence of what's going on; the Youtube video that mitchribar.com mentions as "proof" is not a proper analysis of any sort.

Packet captures of all HTTP and DNS traffic when visiting Youtube and watching a video need to be provided -- and preferably with ipconfig /flushdns being done beforehand.

--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.



swintec
Premium,VIP
join:2003-12-19
Alfred, ME
kudos:4
Reviews:
·RapidVPS
·Sprint Mobile Br..
·VoicePulse
·RoadRunner Cable

reply to isamu99
I had to Telnet into my router to test the blocks. I tried "reject" and "drop" but it made no difference. Videos would fail to start, take way to long to start or get hung up on the ads that play before the videos.
--
Usenet Block Accounts | Unlimited Accounts


dude34221

join:2002-06-13
Columbus, OH
Reviews:
·Time Warner Cable

Click for full size
i used the windows firewall as stated above, due to having no router and no options in modem. i found with windows firewall on (which i dont normally use) youtube was slower, by look and via the stats. Tried 1080hd and sd videos. turned it off and i was back to normal. 30/5 package, no congestion

test this yourself! On any video right click the video and choose "show video info" It will display current speeds and some other stats. I will attach my graph here. You can see a noticeable dip in performance with firewall on, and back to normal with it off. That info page is at »www.youtube.com/my_speed

Edit: forgot graph!

steve5728

join:2001-03-06
Howard Beach, NY

1 edit

It Works!!!

Also. I don't have any issues with buffering while using ZoneAlarm firewall. Only with Windows firewall.


ke4pym
Premium
join:2004-07-24
Charlotte, NC
Reviews:
·VOIPo
·Verizon Broadban..
·RoadRunner Cable
·Northland Cable ..

reply to koitsu

said by koitsu:

Note: I am not a TWC customer.

What's being proposed in that Reddit thread, and in the reference materials that thread cites (some random blog, and that blog cites some random Youtube video), is dangerous on numerous levels. There's a very strong indication that the authors involved do not understand networking, and/or the implications of their ""solution"".

The proposed ""solution"", at the firewall level, does the following:

1. Drop any TCP packet destined to an IP within the 173.194.55.0/24 netblock, with a TCP destination port of 80
2. Drop any TCP packet destined to an IP within the 206.111.0.0/16 netblock, with a TCP destination port of 80

To date, not a single person has provided actual packet captures providing that TWC is doing some kind of HTTP redirection which causes your client to fetch content from alternate locations (e.g. content hosted within the 173.194.55.0/24 or 206.111.0.0/16 netblocks -- BTW, those are, respectively, Google and XO Communications -- and in the case of the former, Google advertises 173.194.0.0/16 via BGP on the Internet).

TWC can't be doing reverse-proxying because otherwise said ""solution"" wouldn't work; they would have to be, for example, looking for very specific HTTP headers and GET requests and injecting an HTTP Location: header into the response, to force the browser to fetch content from an alternate location. If it was done via reverse-proxying (e.g. transparently), the above ""solution"" would not work, since it's being done on the workstation itself.

I suppose an alternate model/method they could be using is wildcard DNS matching (e.g. return IPs within the above netblocks when folks look up very specific FQDNs for c.youtube.com content -- normally they're very strange FQDNs such as r9---sn-nwj7knel.c.youtube.com), in which case using an alternate DNS provider (e.g. OpenDNS) should, unless they're doing transparent DNS response injection, accomplish the same thing. However, in the below referenced video, the author claims "changing DNS providers did nothing".

I can talk at extreme length about this whole ordeal and what it actually amounts to at a networking level, but it's all speculative because nobody has provided actual evidence of what's going on; the that mitchribar.com mentions as "proof" is not a proper analysis of any sort.

Packet captures of all HTTP and DNS traffic when visiting Youtube and watching a video need to be provided -- and preferably with ipconfig /flushdns being done beforehand.

I'd be happy to pull this off. But I have issues with Youtube and Maps from all over the place.

I have access to the following ISPs:

Verizon Wireless (3G & 4G)
AT&T via metro ethernet
Time Warner Cable via cable modem and metro ethernet
Time Warner Telecom via metro ethernet
Charter cable via cable modem

On all of those connections, with various hardware, Youtube and Maps S U C K 99.8% of the time.

If you want me to send you a packet capture from TWC via cable modem let me know. I'll be happy to send you something.


koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:18

I don't want "something" -- I want a proper packet capture of all traffic from someone on TWC who can confirm that the aforementioned ""solution"" works for them (and I want the capture to be when such ""solutions"" are not in place). I want an actual raw capture, not "logging lines", because every packet and its headers (particularly the payload portion) need to be examined.

The pcap filter rule I'd recommend using is (tcp and port 80) or (udp and port 53). This will capture HTTP and DNS traffic only. I would suggest closing down all other applications (including anything running in the systray) before doing this.

I would also appreciate this be done by someone who is not behind a router (unless their router is running a Linux equivalent and they can use tcpdump to capture traffic out the WAN interface), i.e. directly connected.

Please keep a clock running on your computer doing the captures, and make note of what times/etc. you do certain things -- it might be easier to just click an existing Youtube video URL that starts with http://.

Finally remember that visiting http://www.youtube.com/ will redirect you to https://www.youtube.com/ (Google does that), and subsequent videos shown via that would be streamed via HTTPS (SSL) and not HTTP (the above pcap filter will not match HTTPS traffic); I don't see how TWC could be doing any kind of redirection or injection if HTTPS is used, as that would indicate a MITM attack and certificate verifications would fail.

--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.



swintec
Premium,VIP
join:2003-12-19
Alfred, ME
kudos:4
Reviews:
·RapidVPS
·Sprint Mobile Br..
·VoicePulse
·RoadRunner Cable

said by koitsu:

Finally remember that visiting http://www.youtube.com/ will redirect you to https://www.youtube.com/ (Google does that), and subsequent videos shown via that would be streamed via HTTPS (SSL) and not HTTP

Are you sure? »[OOL] is punishing encrypted YouTube straems at prime time?

Poster on the 4th page:
"YouTube streams are not encrypted. If you go to https://www.youtube.com/watch?v=YIBx0PoSqSg you are only viewing the webpage using SSL. The actual video stream still comes via a non SSL connection from the CDN. This can be verified using WireShark or a similar packet capture software."

--
Usenet Block Accounts | Unlimited Accounts


koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:18

said by swintec:

said by koitsu:

Finally remember that visiting http://www.youtube.com/ will redirect you to https://www.youtube.com/ (Google does that), and subsequent videos shown via that would be streamed via HTTPS (SSL) and not HTTP

Are you sure? »[OOL] is punishing encrypted YouTube straems at prime time?

Poster on the 4th page:
"YouTube streams are not encrypted. If you go to https://www.youtube.com/watch?v=YIBx0PoSqSg you are only viewing the webpage using SSL. The actual video stream still comes via a non SSL connection from the CDN. This can be verified using WireShark or a similar packet capture software."

Wow, interesting -- you're right. I just did a packet capture and verified this claim.

I guess this is one thing that, somehow, streaming video models let you get away with: mix-matched URI schemes. Normally with HTTPS you can't have mix-matched content (i.e. everything has to use HTTPS else risk the browser throwing nastygrams at you). It isn't a "Flash thing" because I enabled HTML5 and found a Youtube video that was available via HTML5 and despite the URL using an HTTPS URI scheme, the video was still transmitted via HTTP.
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.

ke4pym
Premium
join:2004-07-24
Charlotte, NC
Reviews:
·VOIPo
·Verizon Broadban..
·RoadRunner Cable
·Northland Cable ..

reply to koitsu

said by koitsu:

I don't want "something" -- I want a proper packet capture of all traffic from someone on TWC who can confirm that the aforementioned ""solution"" works for them (and I want the capture to be when such ""solutions"" are not in place). I want an actual raw capture, not "logging lines", because every packet and its headers (particularly the payload portion) need to be examined.

The pcap filter rule I'd recommend using is (tcp and port 80) or (udp and port 53). This will capture HTTP and DNS traffic only. I would suggest closing down all other applications (including anything running in the systray) before doing this.

I would also appreciate this be done by someone who is not behind a router (unless their router is running a Linux equivalent and they can use tcpdump to capture traffic out the WAN interface), i.e. directly connected.

I'm down with doing this. However, as far best as I can tell, m0n0wall won't do a packet capture. And there's noooo way I'm hooking up directly to the cable modem.

I'm very familiar with taking packet captures with WireShark. I can do that, or if you'll help with command line syntax, I can use tcpdump on my Mac.

--edit to correct pcap for tcpdump.

Monday, 08-Apr 09:32:27 Terms of Use & Privacy | feedback | contact | Hosting by nac.net - DSL,Hosting & Co-lo
over 13.5 years online © 1999-2013 dslreports.com.
Most commented news this week
Hot Topics