Subject: Re: [MMUSIC] ICE-18 Nominating pairs on controlled agents

From: "Adam Fisk" <[email-masked]>
Date: Sat, 3 Nov 2007 22:49:29 -0400

Hi Jonathan-  Thanks for the clarifications.  Responses inline.

>
> I agree this is confusing, though it is correct. The case here is this.
> An agent is controlled. It gets a request with a USE-CANDIDATE. This
> causes the triggered check (7.2.1.4). That check produces a response.
> Once that response arrives, the pair from the *original request* now has
> its nominated flag set. So 7.1.2.2.4 is trying to say, "hey, this
> response might be for a triggered check that you sent as a result of the
> processing of 7.2.1.5, so you may need to follow its directions now".
> I'll make that more clear.

OK, I'm completely with you regarding this logic, and I agree your new
wording in ICE-19 is an improvement, but I still feel it could be
clearer.

I  don't understand why 7.1.2.2.4 wouldn't just say something like:

   If the agent is the controlled agent, the response may be the result
   of a triggered check which was sent in response to a request which
   itself had the USE-CANDIDATE attribute.  If so, The agent now sets
   the nominated flag in the the pair learned from the original request to
   true.  This may end ICE processing for this media stream; see Section 8.

as opposed to the current (first sentence is identical):

   If the agent is the controlled agent, the response may be the result
   of a triggered check which was sent in response to a request which
   itself had the USE-CANDIDATE attribute.  This case is described in
   Section 7.2.1.5, and may now result in setting the nominated flag for
   the pair learned from the original request.

What am I missing?  When is the nominated flag not set here?

If I'm understanding things correctly, the only time you nominate a
pair on a controlled agent *not as the result of a triggered check in
response to a Binding Request with USE-CANDIDATE* is when you happen
to have already done a successful check on that pair prior to
receiving the USE-CANDIDATE.  Is that right?  If so, then it seems
like 7.2.1.5 is basically an optimization to support that case.
That's fine, but it takes awhile to figure out as is.

I think the change above would make it a lot clearer.  I agree it
works as is, and I'm completely fine with keeping it if the above does
not seem better, but it made my brain hurt.

Finally, the second bullet of  7.2.1.5 is also a little confusing for
the following reasons:

1) 7.2.1.4 says to cancel IN-PROGRESS pairs, to add them to the
triggered check queue, and to set them to WAITING.  So when would the
pair ever be IN-PROGRESS?

2) It makes it seem as if the IN-PROGRESS state is a special case, but
I don't think it is.  If we always record the fact that we've received
USE-CANDIDATE in the pair (which we have to do for all the triggered
check cases anyway), we'll always just nominate it when the successful
response arrives.  That's sort of intertwined with 1) though, because
1 makes it a triggered check case anyway.

Any reason not to just kill that second bullet and have this whole
section only handle the special case where the pair already succeeded
prior to receiving USE-CANDIDATE?

Thanks very much for wading through all of this.

-Adam

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