In message <14D6DC7C-FCD2-4EB9-AA56-ECF13A110C33@xxxxxxxxxxxxxxx>, 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@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf