iPad / iPhone may have PMTUD failure workaround behaviour?

[jm493]

Examine this packet capture at SERVER, network is filtering ICMP6 PTB's from SERVER.
CLIENT is an iPad. It works around ICMPv6 PTB being lost problem.

Samsung phones didn't work around the PTB lost problem and would sit in a loop re-sending the first data packet.

15:00:41.146239 IP6 CLIENT.61147 > SERVER.http: Flags [S], seq 216877467, win 65535, options [mss 1380,nop,wscale 5,nop,nop,TS val 643320162 ecr 0,sackOK,eol], length 0
15:00:41.146321 IP6 SERVER.http > CLIENT.61147: Flags [S.], seq 468246155, ack 216877468, win 14280, options [mss 1440,sackOK,TS val 388070460 ecr 643320162,nop,wscale 7], length 0
15:00:41.170597 IP6 CLIENT.61147 > SERVER.http: Flags [.], ack 1, win 4104, options [nop,nop,TS val 643320183 ecr 388070460], length 0
15:00:41.174822 IP6 CLIENT.61147 > SERVER.http: Flags [.], seq 1:1369, ack 1, win 4104, options [nop,nop,TS val 643320186 ecr 388070460], length 1368
15:00:41.174912 IP6 SERVER > CLIENT ICMP6, packet too big, mtu 1280, length 1240
15:00:41.175147 IP6 CLIENT.61147 > SERVER.http: Flags [P.], seq 1369:2036, ack 1, win 4104, options [nop,nop,TS val 643320186 ecr 388070460], length 667
15:00:41.175218 IP6 SERVER.http > CLIENT.61147: Flags [.], ack 1, win 112, options [nop,nop,TS val 388070489 ecr 643320183,nop,nop,sack 1 {1369:2036}], length 0
15:00:41.268809 IP6 CLIENT.61147 > SERVER.http: Flags [P.], seq 668:2036, ack 1, win 4104, options [nop,nop,TS val 643320280 ecr 388070489], length 1368
15:00:41.268924 IP6 SERVER > CLIENT ICMP6, packet too big, mtu 1280, length 1240
15:00:41.512267 IP6 CLIENT.61147 > SERVER.http: Flags [.], seq 1:1369, ack 1, win 4104, options [nop,nop,TS val 643320512 ecr 388070489], length 1368
15:00:41.512369 IP6 SERVER > CLIENT ICMP6, packet too big, mtu 1280, length 1240
15:00:41.846150 IP6 CLIENT.61147 > SERVER.http: Flags [P.], seq 1:2036, ack 1, win 4104, options [nop,nop,TS val 643320839 ecr 388070489], length 2035
15:00:41.846284 IP6 SERVER.http > CLIENT.61147: Flags [.], ack 1189, win 134, options [nop,nop,TS val 388071160 ecr 643320839,nop,nop,sack 1 {1369:2036}], length 0
15:00:41.846339 IP6 SERVER.http > CLIENT.61147: Flags [.], ack 2036, win 153, options [nop,nop,TS val 388071160 ecr 643320839,nop,nop,sack 1 {1369:2036}], length 0
15:00:41.847246 IP6 SERVER.http > CLIENT.61147: Flags [.], seq 1:1369, ack 2036, win 153, options [nop,nop,TS val 388071161 ecr 643320839], length 1368
15:00:41.847262 IP6 SERVER.http > CLIENT.61147: Flags [P.], seq 1369:1866, ack 2036, win 153, options [nop,nop,TS val 388071161 ecr 643320839], length 497
15:00:41.847358 IP6 SERVER.http > CLIENT.61147: Flags [F.], seq 1866, ack 2036, win 153, options [nop,nop,TS val 388071161 ecr 643320839], length 0
15:00:41.866088 IP6 CLIENT.61147 > SERVER.http: Flags [.], seq 1189:1369, ack 1, win 4104, options [nop,nop,TS val 643320858 ecr 388071160], length 180
15:00:41.866170 IP6 SERVER.http > CLIENT.61147: Flags [.], ack 2036, win 153, options [nop,nop,TS val 388071180 ecr 643320839,nop,nop,sack 1 {1189:1369}], length 0
15:00:41.868888 IP6 CLIENT.61147 > SERVER.http: Flags [.], ack 1866, win 4080, options [nop,nop,TS val 643320861 ecr 388071161], length 0
15:00:41.868902 IP6 CLIENT.61147 > SERVER.http: Flags [.], ack 1867, win 4080, options [nop,nop,TS val 643320861 ecr 388071161], length 0
15:00:41.869306 IP6 CLIENT.61147 > SERVER.http: Flags [F.], seq 2036, ack 1867, win 4096, options [nop,nop,TS val 643320862 ecr 388071161], length 0
15:00:41.869378 IP6 SERVER.http > CLIENT.61147: Flags [.], ack 2037, win 153, options [nop,nop,TS val 388071183 ecr 643320862], length 0

At 15:00:41.174822, CLIENT sends seq 1:1369 len 1368 => PTB
At 15:00:41.175147, CLIENT sends seq 1369:2036 len 667 => sack
At 15:00:41.268809, CLIENT sends seq 668:2036 len 1368 => PTB
At 15:00:41.512267, CLIENT sends seq 1:1369 len 1368 => PTB
At 15:00:41.846150, CLIENT sends seq 1:2036 len 2035
At 15:00:41.846284, SERVER sends ack 1189
At 15:00:41.846339, SERVER sends ack 2036
...
At 15:00:41.866088, CLIENT sends seq 1189:1369 len 180

The overlapping packet 668:2036 is strange.

The len 2035 is very strange. Perhaps the network card or network stack is re-assembling packets?

The ack 1189 is also strange (why 1189?).

[jfesler]

I'll have to look at this more when I can focus on it (vs sitting at IETF).

FWIW: Windows also works around. It quickly retransmits a few times then drops the MSS and fragments the first packet into 2. The delay is just 1-2 seconds before it clamps down automatically.

[jm493]

It's not urgent. Just recording today's evidence as a baseline for later investigation.

I wonder if IETF v6ops (or elsewhere) has done a survey of the PMTUD behaviour of various OS's?