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 protected]> wrote: > 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 > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
