[ggm]

Google employ a small number of people to write TCP/IP core stack functionality. This is not a 'twenty hundred fiddy' people problem, its a six rising ten people problem.

The core issue is: how do we get the team in question to acknowledge and respond, with a timely code change?

[dragonwriter]

It doesn't sound like it's a core TCP/IP stack problem, it sounds like it's a Google Cast support in Play Services problem.

[ggm]

The packet explosion in multicast had me thinking some upper layer call is being made, which the stack interprets to mean "keep going" in ways which then bomb the link layer out of existence. Its not TCP/IP I agree. I mis-characterized that. But I think the essential quality is the same: this heads to a single, or small number of people. Google chooses modes of operation which isolates those people from the feedback channels. I have had experience of this: go into a room, present on observed behaviour of a google service, zero outcome. Go into another room, repeat, the guy who can fix it walks to the microphone and says "thanks, I fixed that"

There is no strong git, or feedback-driven path which determines success or failure notifying google about code problems. Some work, some which used to work don't work now, some which didn't work then work now. Its unstable. Its unpredictable.

(for example, feedback inside bug reporting channels for Android, where the most common response from google staff is "this is the wrong channel to provide that feedback" including things which are bugs)

[ggm]

Other write ups say that on wake(), the device detects a true time difference between when it said "queue up sends" and now, and rather than just sending 5, it sends the sum of all missed sends in the interval.

Sleep for 5min, get 5,000. sleep for 10min, get 10,000

And, it is apparently a known side effect of a given java library, which has hit other people.

(and its not a TCP/IP stack problem, its an upper layer problem so you are right)