Re: [SAFE] RE: [BEHAVE] BOF request under consideration: SAFE

Le Friday 12 October 2007 15:06:12 ext Philip Matthews, vous avez écrit :
> I would like to second Markus comments: I also support the goals of
> the BOF, but I share his two technical concerns. The second concern
> was raised at the "informal BOF" in Chicago, but the first concern I
> have not hear discussed before.
>
> Regarding the first concern, I think this might actually go beyond
> just STUN Control to be a general STUN/ICE issue. Even without STUN
> Control, it seems important for an endpoint to know if its keep-alive
> rate is sufficient to keep the bindings in intermediate NATs alive.
> The way I see this might be done is for the STUN server (or perhaps
> the remote endpoint) to send data at regular intervals while the
> client sends keep-alives at some rate. If the client continues to
> receive data after one or two keep-alive intervals have passed, the
> client knows its keep-alive rate is sufficient. A client may choose
> to test a lower keep-alive rate in this manner to see if that is also
> sufficient.

From RFC4380, see §5.2.7 "Optional Refresh Interval Determination Procedure", 
which is exactly that. I had the feeling that "old" STUN also had such a 
thing as part of the behavior analysis stuff, but that this was considered 
bad, though. Maybe I got it wrong... ?

In any case, how often one sends keep-alives is a matter of engineering 
tradeoff between increased battery consumption and increased failure rate. I 
guess if the battery footprint is really bad, the industry will try to use 
longer refresh intervals whatever IETF recommends.

Nevertheless, I agree with Markus and you that there may be value in 
investigating STUN NAT control (and perhaps ALD and as well?), e.g. to 
negociate longer refresh intervals whenever possible. Hence, I support this 
BoF proposal.

-- 
Rémi Denis-Courmont

_______________________________________________
SAFE mailing list
SAFE@ietf.org
https://www1.ietf.org/mailman/listinfo/safe