Subject: [MMUSIC] STUN Transactions, still needed in ICE?

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

Hi,

During the TRAM meeting it was briefly discussed if we could changing the STUN transaction ID when retransmitting a STUN request. Main reason is to get more accurate/easier RTT measurements.

Can we remove the STUN transaction concept from ICEbis without breaking anything? Would there be simplification there as well as we no longer would need two timers (One transaction timer and one retransmit timer). 

From a code (At least mine..) perspective it would simplify the STUN part (client/server) and put some more logic into the ICE part. 

.-.
Pål-Erik

---

From: Martin Thomson <[email-masked]>
Date: Fri, 14 Nov 2014 01:31:36 +0000

Let me get this straight. This would, in effect, remove the transaction id
re-use requirement (?). You would maintain the retransmission timing with
back-off, though, and basically everything else stays the same.

In the repeated id mode that you would have us drop, forgetting about
requests is covered by a single timer that might run after the
retransmission of requests ceases. In the proposed mode, you might use a
timer for every request. You don't have to, but it makes it feasible. And
it then makes the timing stuff possible in light of retransmission.

P.s. this is actually what I did when I built ICE. Just one of many things
that I willfully violated in 5245.

On Thu, Nov 13, 2014, 12:35 Pal Martinsen (palmarti) <[email-masked]>
wrote:

> Hi,
>
> During the TRAM meeting it was briefly discussed if we could changing the
> STUN transaction ID when retransmitting a STUN request. Main reason is to
> get more accurate/easier RTT measurements.
>
> Can we remove the STUN transaction concept from ICEbis without breaking
> anything? Would there be simplification there as well as we no longer would
> need two timers (One transaction timer and one retransmit timer).
>
> From a code (At least mine..) perspective it would simplify the STUN part
> (client/server) and put some more logic into the ICE part.
>
> .-.
> Pål-Erik
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Emil Ivov <[email-masked]>
Date: Fri, 14 Nov 2014 06:38:50 +0100

On 13.11.14, 23:34, Pal Martinsen (palmarti) wrote:
> Hi,
>
> During the TRAM meeting it was briefly discussed if we could changing
> the STUN transaction ID when retransmitting a STUN request. Main
> reason is to get more accurate/easier RTT measurements.
>
> Can we remove the STUN transaction concept from ICEbis without
> breaking anything? Would there be simplification there as well as we
> no longer would need two timers (One transaction timer and one
> retransmit timer).
>
> From a code (At least mine..) perspective it would simplify the STUN
> part (client/server) and put some more logic into the ICE part.

I guess that for anyone who did implement transactions as per the spec, 
this would be a considerable effort. For us it certainly would be. Much 
more so than the perceived gain of improving RTT measurements.

Wouldn't it be easier to just repurose three or four bits from the 
transaction ID and use them as a counter? This way the receiving side 
can also learn about loss and use it as a factor in constructing pair 
preferences.

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Fri, 14 Nov 2014 06:51:25 +0100

> can also learn about loss and use it as a factor in constructing pair

And obviously there's also the option of just doing that in an extra 
attribute.

And just to be clear, I do think improving the RTT measurement would be 
a good thing. I just don't believe that repurposing the entire 
transaction ID as a counter is the best way to do it.

Emil

-- 
https://jitsi.org