Subject: [P2PSIP] Overlap of RTO and ORT

From: "Michael Chen" <[email-masked]>
Date: Wed, 02 Nov 2011 07:25:00 -0700

Hi,

Say the newly coined "overlay-reliability-timer" (ORT) in base-19 has a
3 second default.

Base-19 section 5.6.3.1 paragraph 6 describes an example of a 500ms RTO
and re)transmission at 0ms, 500ms, 1500ms, 3500ms, 7500ms.  One problem
with this paragraph is that it is mixing receiving ACK with receiving a
response of a request, which are two distinct steps.  The second problem
is obvious, the 4th transmission at 3.5 second overlaps the first ORT.

The second paragraph of this section also says, "A node MUST NOT have
more than one unacknowledged message on the DTLS connection at a time." 
This means RTO trumps ORT such that if a request originator has not
received an ACK from its first hop peer, ORT must not fire or must start
after ACK from the first hop is received.  This does not apply to
intermediate peers.

If this is by design, then it is too important not to spell it out in
the draft. I will come up with some text if everybody agrees on "RTO
trumps ORT" or "ORT starts after ACK" for request originator.

Thanks

--Michael

---

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 7 Nov 2011 00:25:42 -0500

Michael,

These timers exist at different layers and aren't really related.

First, the overlay-reliability-timer was something that was added in
response to some of the reviewers comments.  (I know we had discussed
the idea of making it configurable, and don't honestly recall what the
reason was it wasn't made configurable earlier.)  It was made an
overlay parameter because it is also used to determine when
intermediate peers can free state, which obviously shouldn't be before
the requesting node times the transaction out.

Regarding the retransmissions in 5.6.3.1, they are used both to
provide semi-reliability and also to probe whether the link is
functioning.  As the goal of the Simple Reliabiity/Stop-and-wait
protocol is to be as simple as possible, having a single
retransmission timer that is also used to indicate link failure seems
like the simplest solution.

5.6.3.1 also includes: If no ACKs have been received by the time the third
   retransmission occurs, it is RECOMMENDED that the link be removed
   from the routing table.

This is only a recommendation to simplify the mandatory
implementation, but the concept is the link can be removed more in a
timeframe related to the ORT than to wait for a hard link failure.

So in your particular scenario, what I think a good implementation
should do is for the retransmission from the o-r-t to be sent over a
different link in the routing table because the first link has been
removed from the routing table even though retransmissions are still
going on.

Bruce

On Wed, Nov 2, 2011 at 10:25 AM, Michael Chen <[email-masked]> wrote:
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>