• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Main Menu

youtube v6 streaming

Started by matth1187, May 03, 2012, 09:05:17 AM

Previous topic - Next topic

matth1187

Page loads fine but when its time to play video it doesnt play, just a black box with no sound or video where the video should be.

The rest of page seems to load ok.

If i go back to v4 (disable v6) then things work

Anyone else have this issue?

cholzhauer

Are you using Google over IPv6 via a whitelist?

broquea

Just watched the MorpHex III video and it streamed over IPv6. I thought at some point Erik or Lorenzo over at Google said the streaming part was left unwhitelisted on IPv6 after Wv6D. Otherwise whitelisting definitely worked for me.

matth1187

Quote from: cholzhauer on May 03, 2012, 09:09:09 AM
Are you using Google over IPv6 via a whitelist?

Not that i am aware of, so i doubt it. looks like i need to do some more research about this whitelist.

Thx!

matth1187

I do realize this is not in the appropriate forum section, can Admins move this topic to DNS section?

Are He.nets DNS servers whitelisted with google(youtube), Im almost certain i read somewhere they are?

My computer is using ornds.he.net (2001:470:20::2), therefore i should have no issue accessing google service v6?
(pinging google.com and youtube resolves to their ipv6 address).

Any suggestions or suggested reading material?
 
Thx!




broquea

#5
ordns.he.net is the whitelisted anycasted recursor. This has nothing to do with dns.he.net so shouldn't be moved to the DNS area. You could try tweaking mtu on HE's side of the tunnel (you get 3 options) and see if that makes a difference. If you use something like IPvFox you can see what IPv6 resources you are connected to. When streaming I see that I'm fed by:http://o-o.preferred.lga15s18.v22.lscache7.c.youtube.com     2001:4860:4003:5::a

matth1187

Broquea, i have not forgotten you! Im sure we all have busy lives, this is something i am still troubleshooting (little day by day). I wanted to post an update on the status so far:

I have tweaked the MTU to 1280 but doesnt seem to make much difference.

Im wondering if this a valid for testing the proper MTU?
ping xx.x.youtube.com -l 1500
no responce then i slowly lower the value until the pings come through, it works at 1435.

So naturlly i assume that packets larger then that wont come through, so i changed mtu something below that, 1280 only option.

Before the page would load ok but only black boxes where the video/thumbnail should be. Now the page loads and after a minute or two the black boxes slowly fill in and the main video eventually starts to buffer, but is endless buffer.

I notice pings to the youtube server are 300-500 ms. I have a feeling this is related.

Is there a way to perform a speed test between my computer and a random host on the internet? ONly ones i know of are  client/server type apps (iperf) however i cant install iperf on a youtube streaming server lol.

matth1187

Quote from: matth1187 on June 12, 2012, 06:48:12 AM
Broquea, i have not forgotten you! Im sure we all have busy lives, this is something i am still troubleshooting (little day by day). I wanted to post an update on the status so far:

I have tweaked the MTU to 1280 but doesnt seem to make much difference.

Im wondering if this a valid for testing the proper MTU?
ping xx.x.youtube.com -l 1500
no responce then i slowly lower the value until the pings come through, it works at 1435.

So i assume that packets larger then that wont come through, so i changed mtu something below that, 1280 only option.

Before the page would load ok but only black boxes where the video/thumbnail should be. Now the page loads and after a minute or two the black boxes slowly fill in and the main video eventually starts to buffer, but is endless buffer.

I notice pings to the youtube server are 300-500 ms. I have a feeling this is related.

Is there a way to perform a speed test between my computer and a random host on the internet? ONly ones i know of are  client/server type apps (iperf) however i cant install iperf on a youtube streaming server lol.


matth1187

I see the other post regarding youtube. I am using wireless (however v4 and you tube work great) I will try to test with cable JUST to rule it out.

kasperd

Quote from: matth1187 on June 12, 2012, 06:48:12 AMIm wondering if this a valid for testing the proper MTU?
ping xx.x.youtube.com -l 1500
no responce then i slowly lower the value until the pings come through, it works at 1435.
I have seen hosts that would not respond to pings above a certain size. Even if that was far below the MTU. By default ping will use 56 bytes of data, which combined with the ICMPv6 header produces a 64 bytes payload. In at least one case I have seen a host which would not respond to any ICMPv6 echo request larger than that default size.

When things work as they are intended to, then a ping command with a packet size large than the PMTU will return an error for the first packet (or maybe even the first few), and after that packets will start coming through as they are properly fragmented.

So the output of your command depends on more than just whether the size you chose is more or less than the PMTU.

Quote from: matth1187 on June 12, 2012, 06:48:12 AMSo naturlly i assume that packets larger then that wont come through, so i changed mtu something below that, 1280 only option.
If you have a way to change the MSS rather than the MTU, then you might be better off.

matth1187

#10
I dont think i had a very good understanding of PMTU, which now i believe is the problem. Im still a little fuzzy on it so please bear with me.
http://www.netheaven.com/pmtu.html
http://www.tunnelbroker.net/forums/index.php?topic=1722.0

i know icmp is NOT blocked on my router tunnel.

However here is where i get confused. Since youtube is streaming, and the "stream" is coming towards me, hypothetically if there is a mtu issue, based on PMTU, the router should send the streaming server a icmp message saying hey, packet to big! send the stream in smaller packets. perhaps the streaming server is blocking icmp? i find that hard to believe.

From my understanding that, PMTU relies on icmp messages, where as changing the MSS is only telling them remote server "hey, only send me this size packet" without relying on icmp BUT my computer will still send out using whatever the MTU is set at, in my case the default 1500.

Therefore changing my windows MTU or even HE MTU will have no effect on the what MTU the streaming server uses, so that is were MSS comes in play..?

I assume when PMTU is working, my computer would cache the info somewhere for that partiular host, is this correct? and if so how can i see this w/o sniffing packets?  

time to fireup wireshark anyway.

thanks kasperd ill post the results hopefully tonight.

kasperd

Quote from: matth1187 on June 13, 2012, 09:40:58 AMTherefore changing my windows MTU or even HE MTU will have no effect on the what MTU the streaming server uses, so that is were MSS comes in play..?
The MSS option is only sent on TCP SYN packets. Each end of the connection knows the MTU of the link it is directly attached to. The default MSS is computed by subtracting the size of IP and TCP headers from that MTU, so in the case of IPv6 the default MSS is computed by subtracting 60 from the MTU,

Each end of the connection will consider both the MTU of the directly attached interface and the MSS reported by the other end of the connection to decide how large packets to send. It will use the one which results in the smaller packets. Except from cases where some asymmetric routing is going on, both ends of the connection will start with the same size of packets.

ICMP packets are only needed if a hop somewhere in between has a smaller MTU. The first and last hop of the route are automatically covered by the MSS. However though the default MSS is computed from the MTU, there is nothing preventing you from using a smaller MSS. If you have a 1500 byte MTU there is no major performance penalty from reducing the MSS to 1220. An MSS value of 1220 should eliminate MTU problems from all TCP connections.

Reducing the MTU is one way to drive the MSS down, but then that applies to other packets as well, and you may be better off reducing the MSS instead. This is particular important if the link where you would reduce the MTU carries packets where neither sender nor receiver of that packet is directly attached to the link with the lowered MTU. Also remember that the MTU setting for a link is not necessarily the same at both ends, one end doesn't know what the other end has set as MTU for that link.

A reasonable behaviour is to use the configured MTU as limit for outgoing packets on that link but still accept incoming packets on that link, which exceed the configured MTU. Another not completely unreasonable reaction is to send a packet too big ICMP message if a packet is received exceeding the MTU of the link on which it is received. Silently dropping a packet because it exceeds the configured MTU of the link on which it is received is not reasonable, but I wouldn't trust that no system would do so.

Reducing the MSS does not have the same potential to introduce new problems, so I consider that a better solution. If you have that option reduce the MSS first and keep the MTU.

I would only reduce the MTU if reducing MSS is not an option.

Quote from: matth1187 on June 13, 2012, 09:40:58 AMI assume when PMTU is working, my computer would cache the info somewhere for that partiular host, is this correct? and if so how can i see this w/o sniffing packets?
Yeah, there need to be a cache for this. It is somehow tied to routing information, but I don't know how to see it without looking at the network packets. And it differs between operating systems anyway.

matth1187

Now I understand how MSS, MTU, and pMTU work.
Very thorough, excellent job kasperd, I do appreciate your time on that.

Unfortunately I did not get a chance to even think about this yesterday after work, however today is a different story so I will post my results this evening.
:D

     

matth1187

Well i cant figure out how to change the MSS value on windows 7, seems that windows automatically handles that based on your link speed so all im left with us changing MTU via registry.

Before i changed anything I thought i would load up you tube and capture the traffic to see if i can spot any issues and so i can compare before and after
Of course the streaming worked flawlessly.  ???

i notice the max size of packets was 1294, previously i changed the tunnel MTU to 1280, youtube still was not working with this but i swore i changed it back. I checked that this morning and it was set to 1280. Im going to set it back to 1480 and go from there. I feel like im getting closer to resolution! many thx