![]() ![]() ![]() In the above example this connection takes some 1.2 seconds, where some 0.9 seconds is spent performing name resolution using the DNS and 0.3 seconds (or one round trip time) is spent performing the TCP connection setup. What I am interested here is time taken from the start of the connection operation, which is when the DNS queries are fired off to the time when, from the client’s perspective, TCP is able to complete the initial three-way handshake. All these packet traces are performed at the client side of the connection. My local application sends an ACK packet after a further millisecond and the connection has been established, with a total elapsed time of 1.168 seconds. ![]() After one Round Trip Time (RTT) interval of 280ms there is a SYN+ACK packet received in response. After a further 3ms the application has generates an initial TCP connection packet (a SYN packet) to the IPv6 address. This second query takes 299ms to obtain a response. What this shows is a 581ms delay between issuing the query to the DNS for the AAAA resource record for the domain name foo.rd.td.h., and a 4 millisecond delay after receiving the response before issuing a DNS query for the A resource record for the same domain name. The time is measured in milliseconds, and the above log shows the elapsed time between each packet event that was generated in attempting to complete the connection. ![]() If I use a simple custom TCP application (there are a number of good resources for coding up a TCP connection, including ) that performs a conventional connect using the operating system interface, then I see a normal Windows XP behaviour of protocol preference in a dual stack environment:Ĭonnection: tcpopen foo.rd.td.h.Ġ → DNS Query for AAAA record foo.rd.td.h.ĥ81 ↠AAAA response 2a01:4f8:140:50c5::69:72Ĥ → DNS Query for A record for foo.rd.td.h.Ģ80 ↠SYN + ACK response from 2a01:4f8:140:50c5::69:72 “Conventional” Dual Stack ConnectivityĪ conventional approach to the dual stack environment can be seen if I dust off the cobwebs of my old Windows XP implementation and turn on IPv6. There is an excellent article on this topic by Emile Aben on the RIPE LABs site (“ Hampered Eyeballs“), and I’d here like to build on his work by taking a slightly deeper investigation of the issue and look at how a number of popular web browsers and operating systems cope with accessing dual stack servers, and look in particular at what happens when things don’t go as smoothly as one would hope. In this article I’ll look at how browsers on dual stack client systems access dual stack servers, and examine the corner cases when one protocol or the other isn’t quite working properly, and how the browser attempts to recover from the error. It proposes taking the essentially sequential behavior of current implementations where they probe for connectivity in one protocol and then the other, and attempting to perform the initial connection (DNS name resolution and TCP connection handshake) in each protocol in parallel, and then proceeding with the fastest connection. There is a proposal doing the rounds in the IETF for standardising dual stack client connection management called “ Happy Eyeballs”. In this column I’d like to head upward in the protocol stack to the rarefied air way up there at the level of the application, and look at how applications are managing to cope with the issue of two IP stacks. The introduction of a second IP protocol into the Internet presents many technical issues, and in previous columns we’ve explored many of the issues related to network engineering and infrastructure. ![]()
0 Comments
Leave a Reply. |