Subject: RE: ICE pacing connectivity checks (wasRE:[MMUSIC] WGLC: draft-ietf-mmusic-ice-15.txt)

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 May 2007 13:33:20 -0700

Magnus wrote:
 
...
> >> My question is what do you win with that rather than moving the 
> >> triggered checks to the top of the paced list. That way 
> >> you keep the 
> >> rate and avoid hurting yourself more than what you would 
> >> by instantly 
> >> initiate the triggered checks.
> > 
> > Its not just new transactions; in most cases a triggered check is a 
> > retransmit of a transaction already in progress.
> 
> I had forgotten this. And the reason for doing that is that 
> it is quite likely that the previous transmission was dropped 
> in the NAT where now a binding exist?

Exactly.  Or (less likely) the packet was dropped by the network.

> > Pacing those along with 
> > periodic checks requires me to mix both of those things 
> > into a single 
> > mechanism, which I don't like. I prefer a cleaner 
> > separation of ICE and STUN.
> 
> I can, understand that. You still have an interface question for the
> triggered checks, where ICE needs to tell an ongoing STUN transaction
> that the check should be retransmitted. Not complicating that 
> case is fine.
> 
> However for all the other cases from the list in section 7.2.1.4 using
> pacing to start the triggered checks seems easy to implement. It also
> appears there is a good reason for pacing as it prevents multiple
> triggered checks to significantly increase the bit-rate 
> consumed.

I'll let Jonathan comment.  

> But I
> would appreciate more data how this actually play out in a case where
> there is multiple medias in a session. Because to me it appears that
> when a peer finds the combination of interfaces that works, it will
> start unfreezing a lot of candidates that will get through and
> triggered checks.

At the point where ICE decides to unfreeze the other m= lines and
do its checks, it'll only do one STUN transaction on each of those
other m= lines, unless that STUN transaction fails (which isn't
very likely).  If the STUN transaction fails it'll get 
retransmitted and other a=candidates in that m= line will get 
processed per our rules.

I guess, at that time, you're already sending RTP out the first
media line (audio, probably).  And we'd want to reduce those ICE 
checks to not consume the bandwidth of the audio session.

The easiest and most effective way to do that is constrain each 
of the ICE checks to the bandwidth of their respective m= lines, 
rather than the sum of RTP bandwidth available to all of the
m= lines.

> I would really appreciate some simulation data for
> cases that are a bit more extreme when it comes to the number of
> candidates and medias.

That excel spreadsheet currently handles 10 candidates; how many
more do you want simulated?

-d

> Cheers
> 
> 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]
> --------------------------------------------------------------
> --------

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 01 May 2007 23:20:58 +0200

> rather than the sum of RTP bandwidth available to all of the

Okay, I think there need to go into some thought into if the 
connectivity checks are happening from individual bit-rate budgets or if 
there are a common one. There are some issues with getting completion if 
some media streams are very low bit-rate compared to other large bandwidth.

> more do you want simulated?

What is needed is to understand how it behaves from small cases with a 
few candidates all the way up to the upper limit that ICE allows. Which 
means at least 100 candidates needs to be looked at.

Cheers

Magnus Westerlund

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 May 2007 15:54:08 -0700

> connectivity checks are happening from individual bit-rate 
> budgets or if there are a common one. There are some issues 
> with getting completion if some media streams are very low 
> bit-rate compared to other large bandwidth.

We have to make some guesses, then.  The most important 
guess is if the network polices our flows by the sum of
those media lines or (as with, for example, a PacketCable
network) the network would police the flows by each m= 
line.

If the network is bandwidth constrained (dialup, DSL, etc.),
the limit is overall bandwidth.  If there is a bandwidth
policer in place doing Smart Things (tm), it may well be
smart enough to help us (give us the sum of both media
lines' bandwidth) or smart enough to be difficult (give 
us the bandwidth indicated in each of the media lines).

> What is needed is to understand how it behaves from small 
> cases with a few candidates all the way up to the upper 
> limit that ICE allows.  Which means at least 100 candidates 
> needs to be looked at.

With my current estimate of 108 bytes of UDP payload for a STUN
packet, and 40 bytes of UDP payload every 20ms for RTP (which
is similar to G.726), it would take a bit over 3 seconds for
the initial STUN checks to be sent out.

If we need 100 candidates to work, we would need a more 
aggressive algorithm than what I had previously suggested, 
which would exceed the already-undesirable bandwidth
consumption of RTP.

A new excel spreadsheet that handles 0-100 candidates is
at http://www.employees.org/~dwing/ice-rtp-backoff.xls

-d

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 07 May 2007 16:14:27 +0200

> us the bandwidth indicated in each of the media lines).

In most cases there will be a common pool of resources. However there 
clearly are examples where the resources are allocated per media stream. 
Thus a paragraph on how to handle these cases should be included.

> at http://www.employees.org/~dwing/ice-rtp-backoff.xls

My point with making 100 candidates work, is not that it completes 
quickly but that it does work. If you have to go through a 100 
candidates to find something that works, then you have prioritized 
wrongly or are extremely unlucky. But nothing breaks because the checks 
take 3 seconds to pace out? I think that is the import fact.

What I see as reasonable here is:

1) ICE consumes a reasonable and bounded amount of network resources per 
second when it is running checks.
2) ICE has a reasonable good completion time for a reasonable number of 
candidates
3) ICE still work but may take longer time as the number of candidates 
increase.

Cheers

Magnus Westerlund