there are many packet level tools ad server based packages that can
help forecast and pipe v6 loads seamless to your user stack.
Sent from my iPhone (SDK). Please excuse my brevity.
On Jun 24, 2010, at 1:23 PM, David Conrad <drc@xxxxxxxxxxxxxxx> wrote:
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 problem.
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 impact on the server is when there is good v6
connectivity. Presumably, if a server 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
server will be exactly one additional communication initiation
event. I honestly 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 connected to the Internet today is
going to be subject to vastly more load due to random scans from
malware.
In the serial case, there are two options: v4 first or v6 first. If
v4 is chosen first, it is unlikely v6 will ever be used, thus the
server operator setting 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 connectivity. My guess
is that this would result in an increase in support calls to the
server operator ("why is your server so slow?") with the typical
support center response being "turn off v6 support". I believe this
has been empirically demonstrated.
I personally don't see how we'll get anywhere with v6 deployment
using the serial 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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf