[Cerowrt-devel] trivial 6in4 fix(?)

[Sebastian Moeller]

Hi Toke,

On Jun 17, 2013, at 11:44 , Toke Høiland-Jørgensen <toke at toke.dk> wrote:

> Sebastian Moeller <moeller0 at gmx.de> writes:
> 
>> Honestly, I think the best thing to do is not so much assume ATM or
>> lack of ATM, but simply measure it :)
> 
> Right, doing the ping test with payload sizes from 16 to 113 packets
> gives me an almost completely flat ping time distribution ranging from
> 20.3 to 21.3 ms (see attached graphic). So probably I'm on PTM…

	I fully believe you that it is flat (graph did not make it into my inbox…) So that looks like PTM. Good! But beware the expected step size depends on your down and uplink speeds, at VDSL I would only expect a very tiny increase (basically the time it takes to see an additional ATM cell back and forth, (RTT step per ATM cell in milliseconds = (53*8 / line.down.bit + 53*8 / line.up.bit ) * 1000); this means that potentially a large sample size per ping packet size is required to be reasonably sure that there is no step....

> 
>> Easy to figure out empirically by hand, by finding the largest ping
>> packet size that still passes without fragmentation (see
>> http://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_finding_optimal_mtu)
> 
> $ ping -c 1 -s $((1500-28)) -M do www.debian.org
> PING www.debian.org (128.31.0.51) 1472(1500) bytes of data.
> 1480 bytes from senfl.debian.org (128.31.0.51): icmp_seq=1 ttl=45 time=114 ms
> 
> --- www.debian.org ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 114.522/114.522/114.522/0.000 ms
> 
> $ ping -c 1 -s $((1500-27)) -M do www.debian.org
> PING www.debian.org (128.31.0.51) 1473(1501) bytes of data.
> From 10.42.3.5 icmp_seq=1 Frag needed and DF set (mtu = 1500)
> 
> --- www.debian.org ping statistics ---
> 0 packets transmitted, 0 received, +1 errors
> 
> So the MTU seems to be 1500 bytes.

	That is great!

> 
> Now, how do I figure out what the PTM overhead is and feed it to HTB? :)

	All I know so far is that PTM will not drag in the quite baroque ATM encapsulation options. Googling for vdsl2 makes me hope that maybe there is no additional user visible overhead; so if you have PPP that would still need handling. It would be quite interesting to determine the overhead empirically. ATM's quantization makes overhead detection in atm based del lines conceptually easy; but for VDSL I am not so sure. In principle we expect to see "buffer bloat" and its signature increase of latency on saturated links if we shape with too high rates. So too small an overhead should fill the modems buffers and might increase latency (depending on the modems configuration, but assuming pfifo the buffer should just fill up slowly until latencies should be noticeably affected, or?). Hence in theory using a saturating load and measuring the latencies for different overhead values should still work. I wonder whether rrul might just be the right probe? If you go that route I would be delighted to learn the outcome :). Sorry to be of no more help here. 

Best
	Sebastian


> 
> -Toke