On Thu, 17 Oct 2013, Yoav Nir wrote:
On Oct 17, 2013, at 5:13 PM, Paul Wouters <p...@cypherpunks.ca> wrote:
While updating the retransmit timers in libreswan, I found no useful
information in 5996. Is that something we could add? I know it is
local policy but perhaps it would be good to add some guidance for
implementors. Do people use sub-second retries? exponential backoff?
How do people deal with slow wakeup stacks (eg 3G) and preventing of
firsts of duplicate first packets?
I agree with Yaron. The only guidance is "at least 12 retransmission over at least
two minutes"
I guess I was hoping for more operation experiences. I was not asking
for specific values, but for some more guidance.
To be sure, I'm using a laptop connected to a smartphone hotspot, connected to
a 3G cellular network from a moving train half-way around the world. But still,
sub-second retries would have you send unnecessary retransmissions, and packet
loss is pretty low.
Yet some implementations do sub-second retries. Packet loss is high
within the first second when you are waking up your 3G chipset for
example. If the first packet hits the wakeup, and you wait one second,
that's plenty of opportunity for packet leaks. But sending more packets
will likely result in a burst of initial packets being sent out.
The world is now much more depending on sub-second times than it was
before.
My own policy is 1 second between first and second transmissions, and the wait
time is multiplied by sqrt(2) for each additional transmission, so the 12th
transmission is 107 seconds after the first. Close enough, sort of.
While it's possible to add a paragraph giving such a policy as an example, I
don't see why we should even imply that this is a requirement.
I see widely different times from sub-zero to 20 seconds. It suggests
implementors have pretty different ideas on what it should be.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
