Subject: [pcp] -06 review: retransmission

From: Paul Selkirk <[email-masked]>
Date: Mon, 07 Mar 2011 22:56:28 +0000

Let me see if I have this straight.

6.1.  General PCP Client: Generating a Request
   The PCP client sends a PCP message to each server in
   sequence, waiting for a response until its timer expires.  Once a PCP
   client has successfully communicated with a PCP server, it continues
   communicating with that PCP server until that PCP server has not
   responded to 5 retransmissions, which causes the PCP client to
   attempt to re-iterate the procedure starting with the first PCP
   server on its list.

Are these 5 retransmissions all with the fixed 4-second retransmit
timer?  I think so, since no other timers are mentioned.

   If no response is received from any of those servers, it
   doubles its retransmission timer and tries each server again.  This
   is repeated 4 times (for a total of 5 transmissions to each server).

So after 5 retransmissions (6 unacknowledged transmissions) to the
primary PCP server, it starts polling backup servers with an
exponential backoff.  In the usual case of 1 server, this is a further
5 retransmissions:
. 4 4 4 4 4 8 16 32 64 128 = 268 sec = 4:28

I strongly suspect that, long before the final expiry of four and half
minutes, the app will have given up.

Renewal retransmission (8.3, 9.5) follows Zeno's progression (1/2, 3/4,
7/8, etc), with a limit of 4 seconds.  Do these retransmits count
against the 5 permitted for a new request (section 6.1), or only when
it gets down to the 4-second timer?  i.e. When does the client give up
trying - when the lifetime expires, at the end of the 5-count, or
something else?

				paul

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Mar 2011 19:09:26 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Selkirk
> Sent: Monday, March 07, 2011 2:56 PM
> To: [email-masked]
> Subject: [pcp] -06 review: retransmission
> 

Correct.  I stole the design from DNS.

> minutes, the app will have given up.

If the application (or the user) will give up, how long is that going
to be?  That is, what is our design constraint?  Most DNS resolvers
on hosts will re-transmit after 2 seconds.  Most TCP clients re-transmit
thir SYN after 3 seconds, and again at 6 seconds.

How many PCP servers can we reasonably expect?  I bet 1-2, because that
is how many DNS servers are configured on a host.

If there is one PCP server, how about:

  4 seconds (total: 4 seconds)
  8 seconds (total: 12 seconds)
 16 seconds (total: 28 seconds)

which causes this behavior with two servers:

  4 seconds to server 1 (total: 4 seconds)
  8 seconds to server 1 (total: 12 seconds)
 16 seconds to server 1 (total: 28 seconds)
  4 seconds to server 2 (total: 32 seconds)
  8 seconds to server 2 (total: 40 seconds)
 16 seconds to server 2 (total: 56 seconds)

If there are other PCP servers, we could alternate them, too, like this:

  4 seconds to server 1 (total: 4 seconds)
  4 seconds to server 2 (total: 8 seconds)
  8 seconds to server 1 (total: 16 seconds)
  8 seconds to server 2 (total: 24 seconds)
  ... etc. ...

could also send the requests in parallel.

Separately is how to deal with a PCP server that was responding just fine,
but has since become non-responsive.  For that, I believe we want to use
exponential backoff.  Perhaps maximize it to 16 second intervals:

  4 seconds (total: 4 seconds)
  8 seconds (total: 12 seconds)
 16 seconds (total: 28 seconds)
 16 seconds (total: 44 seconds)
 16 seconds (total: 60 seconds)

> trying - when the lifetime expires, at the end of the 5-count, or

Myself, I would prefer they do a normal transmissions, instead of being
more aggressive as the lifetime nears 0 which is what it is doing now.  
If the PCP server is non-responsive, beating it with more frequent
refresh messages isn't going to liven it up.  :-)

-d