Subject: [tram] STUN retransmit count attribute

From: Justin Uberti <[email-masked]>
Date: Wed, 12 Nov 2014 17:57:19 -0800

Following up on the STUN retransmit discussion today:
I went back and looked through the rationale for why we considered adding a
retransmit count, and it was basically to allow the remote side to know
when ICE responses were getting lost, perhaps due to some internal error in
a NAT.

FWIW, in our impl we do update the transaction ID on each retransmit, since
we do want to calculate an accurate RTT.

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 13 Nov 2014 05:31:05 +0000

> On 12 Nov 2014, at 15:57, Justin Uberti <[email-masked]> wrote:
> 
> I went back and looked through the rationale for why we considered adding a retransmit count, and it was basically to allow the remote side to know when ICE responses were getting lost, perhaps due to some internal error in a NAT.
> 
> FWIW, in our impl we do update the transaction ID on each retransmit, since we do want to calculate an accurate RTT.

For webRTC and the rate limiting of the connectivity checks that makes sense.

For old school vanilla ICE transactions and retransmissions are decoupled. The connectivity check fails when the transaction fails. 

Maybe the question is to ask in MMUSIC is if the STUN transaction term is still valid in todays use cases? Could also have the added benefit of reducing the numbers of timers needed in ICE (Transaction timer and retransmit timer)

A counter of lost STUN packets on the wire would also be nice as a crude indication to severe packet loss.

.-.
Pål-Erik 

> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram