In message <14d6dc7c-fcd2-4eb9-aa56-ecf13a110...@virtualized.org>, David Conrad writes: > Martin, > > On Jun 23, 2010, at 6:06 AM, Martin Rex wrote: > > What you described results in a negative incentive for servers to > > become accessible under IPv6 as an alternative to IPv4. That is a real pro > blem. > > I guess I'm not seeing how it is a significant negative incentive to servers. > > > If IPv6 connectivity is still bad, then the connection request will > > not reach the server and the server will not notice. > > Right. So, the only case where a parallel open would potentially have any im > pact on the server is when there is good v6 connectivity. Presumably, if a s > erver operator has configured v6, they are anticipating v6 load and will have > engineered for that load. Since for any given session, the application will > either communicate via v4 or via v6, not both, the additional load on the se > rver will be exactly one additional communication initiation event. I honest > ly have difficulty seeing a server operator building a system so close to the > edge that this would be a real concern, particularly given any server connec > ted to the Internet today is going to be subject to vastly more load due to r > andom scans from malware. > > In the serial case, there are two options: v4 first or v6 first. If v4 is ch > osen first, it is unlikely v6 will ever be used, thus the server operator set > ting up v6 would be a waste of time. If v6 is chosen first, then the client > will have to wait for the v6 initiation to time out in the case of bad v6 con > nectivity. My guess is that this would result in an increase in support call > s to the server operator ("why is your server so slow?") with the typical sup > port center response being "turn off v6 support". I believe this has been em > pirically demonstrated.
The third choice is to do a non-blocking connect to IPv6 then if that does not succeed in 1 or 2 seconds (most successful connects are within this peroid but connect failures are considerably longer) initiate a non blocking IPv4 connection and keep whichever completes first and abort the other. > I personally don't see how we'll get anywhere with v6 deployment using the se > rial approach nor do I see any other options than parallel vs. serial. Since > you believe parallel open to be a problem, what is your proposed alternative > ? > > Regards, > -drc > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf