MIME-Version: 1.0
In-Reply-To: <E721D8C6A2E1544DB2DEBC313AF54DE22402509E@xmb-rcd-x02.cisco.com>
References: <20130225182705.666.1653.idtracker@ietfa.amsl.com>
 <E721D8C6A2E1544DB2DEBC313AF54DE224023E19@xmb-rcd-x02.cisco.com>
 <CABkgnnXkBSTNPDw-e=RMOU9UsucPeQyFya6w0R83CZvUqww_-A@mail.gmail.com>
 <E721D8C6A2E1544DB2DEBC313AF54DE22402509E@xmb-rcd-x02.cisco.com>
Date: Wed, 27 Feb 2013 11:43:49 -0800
Message-ID: <CABkgnnV3Oo2B8xyeb1=-3pu0b81Xhk5D_-TYmu3Swmsi-JY8Lw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] FW: I-D Action:
 draft-muthu-behave-consent-freshness-03.txt
Precedence: list

> In its current form, the draft uses the STUN transaction as defined in RF=
C5389, which implies the requests are retransmitted until a response is rec=
eived, or until a total of 7 requests have been sent (assuming no hard ICMP=
 error is received). So, reporting a consent freshness failure is sufficien=
tly guarded against transitory network failures.

That's far too much.  And the backoff is designed for completely
different situations.

Imagine that you are running Tr at 1 second, with a complete
transaction required before you do anything.  Do you run 39 in
parallel with hundreds of checks, or do you not create a new
transaction when another is outstanding?  Keep in mind that the latter
choice means that you aren't really sending a check every second any
more, despite agreeing to do so.

> However, with the default 500 ms RTO recommended in RFC5389, it would tak=
e 39.5 sec for the transaction to timeout -- this was considered too long t=
o declare a consent freshness failure.

We've discussed tightening the timers once the session is live.  We've
also discussed tightening timers when the session is starting.  Both
of which I would have expected to see in the document as proposed
solutions.

> One option could be to define a new STUN transaction that doesn't do the =
exponential backoff for retransmission, but instead retransmits at periodic=
 intervals and declare failure if there is no response after sending a bunc=
h of them, as you are suggesting. But, I am not sure at this point how that=
 would be both superior compared to the transaction defined in RFC5389 and =
sufficiently guard against transitory network failures.

I think that the document only needs to talk in terms of "checks" or
Binding requests rather than transactions.