May be a bit more complex - as the reverse lookups shown in the traceroute have subtle differences (including case). One would wonder if there is also some split DNS as well. Dw.

From the article:

.. feedback loop allows TCP [to run][ congestion avoidance: If acks return at a slower rate than the data was sent out, that indicates that there is little bandwidth available, and the source throttles...

which does seem to be a far cry from TCP. While common lore (and the modern buffer bloated internet) has it that high RTT means little available bandwidth (and it sure does play havoc with the bandwidth product - giving rise to that lore fairly) - the design calls for packet drop rather than delay to indicate a link being overloaded. And while the source slows down - it does not actually throttles; it just awaits the ack - it wont slow down the next packets. It is just that the window won't grow further. So makes one think of the observations in RFC-2488.

And there is also the expectation of "But the IETF document still plays a subordinate role to that source code.'' in the original article. However one interesting expectation or requirement of IETF standards is that one expects at least one, ideally two, independent implementations based on the written spec. This would alleviate the concerns that the VP8 case is too leading - as one has now an example of an independently derived code base - which has taken the written spec as its lead - and secondly it would also give the community a very fair idea as to any residual IPR issues, by Google or by others. Thanks, Dw.