Subject: [MMUSIC] ICE retransmitted Binding Request processing

From: "Adam Fisk" <[email-masked]>
Date: Tue, 2 Oct 2007 18:36:42 -0400

I've noticed in my ICE tests that it's quite common for a peer to receive
multiple Binding Requests for the same STUN transaction as a result of STUN
retransmissions.

While this is to be expected, the processing of the request specified in ICE
18 section 7.2.1.4 "Triggered Checks" results in adding precisely the same
candidate pair to the triggered check queue multiple times, resulting in
multiple subsequent identical triggered checks and subsequent work.  Is this
the expected behavior, or am I missing something?  While it doesn't seem the
above will break anything, it doesn't appear optimal either.

Should the triggered check queue filter duplicates?  Should the STUN server
side in ICE ignore Binding Requests with transaction IDs it has already
processed (clearly still sending Binding Responses, just not forwarding the
request to the ICE procedures)?  I'd assume the latter, but it seems I must
be missing something in one of the specs if this is the case.

This is assuming the ICE STUN server side just reprocesses each Binding
Request and recomputes the Binding Response each time since the Binding
method is idempotent, as specified in draft-ietf-behave-rfc3489bis-10
section 7.3.1 "Processing a Request."

Thanks very much.

-Adam Fisk
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 03 Oct 2007 09:42:43 +0200

Hi Adam,

In my opinion you should do the following.
- Always respond to binding requests, as the first response may not have
reached the requestor.

- Not perform the Triggered check for anything more than the first
request. No restart nor multiple queuing of the connectivity check for
that candidate pair.

I think there might be need for clarification on this in the ICE spec.

Cheers

Magnus

Adam Fisk skrev:
> I've noticed in my ICE tests that it's quite common for a peer to
> receive multiple Binding Requests for the same STUN transaction as a
> result of STUN retransmissions. 
> 
> While this is to be expected, the processing of the request specified in
> ICE 18 section 7.2.1.4 <http://7.2.1.4> "Triggered Checks" results in
> adding precisely the same candidate pair to the triggered check queue
> multiple times, resulting in multiple subsequent identical triggered
> checks and subsequent work.  Is this the expected behavior, or am I
> missing something?  While it doesn't seem the above will break anything,
> it doesn't appear optimal either. 
> 
> Should the triggered check queue filter duplicates?  Should the STUN
> server side in ICE ignore Binding Requests with transaction IDs it has
> already processed (clearly still sending Binding Responses, just not
> forwarding the request to the ICE procedures)?  I'd assume the latter,
> but it seems I must be missing something in one of the specs if this is
> the case.
> 
> ------------------------------------------------------------------------
> 

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 28 Oct 2007 18:43:09 -0400

Yes, this is a bug. I had in mind an implementation which implemented 
transaction state, and thus silently absorbed retransmits. For such an 
implementation you would not see this. However Adam is correct that such 
an implementation is certainly allowed. I changed the text from:

o  If the pair is already on the check list:

       *  If the state of that pair is Waiting or Frozen, a check for
          that pair is enqueued into the triggered check queue.

to:

o  If the pair is already on the check list:

       *  If the state of that pair is Waiting or Frozen, a check for
          that pair is enqueued into the triggered check queue if not 
already present.

I believe that fixes the problem.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com