Re: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-03.txt

["Muthu Arul Mozhi Perumal (mperumal)" <[e-mail]>]

|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?  

Yes, that's what I had in mind -- don't generate a new request when a response is pending. A couple more constraints that could be useful:
- Don't generate a new consent freshness check when no traffic was sent over the last x sec (could save battery).
- Don't generate a new liveness check if any traffic was received since the last liveness check.

I had a crude algorithm:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg05000.html

Need to refine further.

|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.

Not sure I understood. Do you mean tightening the backoff timer?

|I think that the document only needs to talk in terms of "checks" or
|Binding requests rather than transactions.

How would that help? They would degenerate into transactions, anyway.

Muthu

|-----Original Message-----
|From: Martin Thomson [mailto:[e-mail]]
|Sent: Thursday, February 28, 2013 1:14 AM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: [e-mail]
|Subject: Re: [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-03.txt
|
|> In its current form, the draft uses the STUN transaction as defined in RFC5389, which implies the
|requests are retransmitted until a response is received, or until a total of 7 requests have been sent
|(assuming no hard ICMP error is received). So, reporting a consent freshness failure is sufficiently
|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 take 39.5 sec for the
|transaction to timeout -- this was considered too long to 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 bunch 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.