Subject: [Iptel] CPL - Recurse in proxy node

From: Bogdan-Andrei IANCU <[email-masked]>
Date: Mon, 08 Sep 2003 21:38:28 +0200

Hi *,

I have some questions about processing a proxy node when recurse in 
active. I went through the draft, but there were no  mentions about what 
I was interested in, so, here are my questions. First of all , as is 
written in CPL draft, recurse applies for all proxying modes - 
sequential, parallel and first-only. Now, how exactly this should work!?

1) for sequential - you have a set of locations and do a serial forking 
on it; if a 3xx is received, put the locations from contact hdr into the 
set. The question is, you insert the new location into the set according 
to their q value (location set is a list of location sorted by the q 
value), or consume first all the location form the original set and if 
all fails start proxying to the locations received by 3xx replies? Ex: 
if I have the following location set  A;q=0.0, B;q=1.0 and after 
proxying to A I get a 3xx with a Contact carrying C;q=0.8 and D;q=1.0, 
what will be next proxying order: C,B,D or B,C,D?

2) for parallel - I have the original location set (A) and as a final 
reply of the parallel  forking I get a 3xx having in its Contact some 
new location ( that will form location set B). If I follow the idea of 
recursing, I will end having a serial number of parallel proxying: 
parallel proxying of A that will generate B -> parallel proxying of B 
that will maybe generate C, etc (some sequential-parallel proxy 
combination)- is this the way it suppose to work?

3) for first-only - after doing a proxy only to the first location form 
the set, if I get back a 3xx response, do I proxy based only on the new 
received locations or I just add them to the location set (in this case 
the same question as for serial proxying->adding to location set means 
to insert or to append - if we respect the order imposed by q or not)?

Best regards,
Bogdan

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

---

From: [email-masked]
Date: Tue, 9 Sep 2003 10:26:17 +0530

Hi,

my comments inline....

regards,
Siddharth.
-------------------
Siddharth Toshniwal @ Hughes Software Systems
http://www.hssworld.com

[email-masked] wrote on 09/09/2003 01:08:28 AM:

> on it; if a 3xx is received, put the locations from contact hdrinto the

Its your choice, I think. From the Section 8.1.3 of
the RFC 3261 (Processing 3xx responses) :

"As the target set grows, the client MAY generate new
 requests to the URIs in any order. A common mechanism
 is to order the set by the “q” parameter value from the
 Contact header field value. Requests to the URIs MAY be
 generated serially or in parallel. One approach is to
 process groups of decreasing q-values serially and process
 the URIs in each q-value group in parallel. Another is
 to perform only serial processing in decreasing q-value
 order, arbitrarily choosing between contacts of equal
 q-value."

I would recommend decreasing q value as the order. Once
you get a 3xx, populate your current location set with
the new found contacts (in a sorted manner on q-value)
and try the locations after the location set is ready.
So, my answer is B, D, C.

> combination)- is this the way it suppose to work?

I think so. Others can clarify in case this is incorrect.

> to insert or to append - if we respect the order imposed by q or not)?

If you are doing CPL, you should insert the new
locations into your location set.

> Best regards,
> Bogdan�ץ����x%��H�ץ��_��!��l��0�'�~���f��f��X��)ߣ����

---

From: Bogdan-Andrei IANCU <[email-masked]>
Date: Tue, 09 Sep 2003 15:39:17 +0200

Thanks for your response. Just to be sure if I get it correct: when 
ordering is first-only, recurse actually has no sense - if a 3xx is 
received, disregarding recurse, the new locations will be added to the 
location set and the proxying process will stop by  exiting by 
redirection branch.

Thanks again for clarification,
Bogdan

---

From: [email-masked]
Date: Tue, 9 Sep 2003 23:29:26 +0530

Yes, that is correct. If a first-only location is tried,
the recursion should not happen till the CPL script
has processed those locations.

regards,
Siddharth.
-------------------

Bogdan-Andrei IANCU <[email-masked]> wrote on 09/09/2003
07:09:17 PM:

> >>active. I went through the draft, but there were no  mentionsabout what
> >>received locations or I just add them to the location set (inthis case

---

From: Pekka Pessi <[email-masked]>
Date: Fri, 12 Sep 2003 10:44:42 +0300

Bogdan-Andrei IANCU <[email-masked]> writes:
>Thanks for your response. Just to be sure if I get it correct: when ordering
>is first-only, recurse actually has no sense - if a 3xx is received,
>disregarding recurse, the new locations will be added to the location set
>and the proxying process will stop by  exiting by redirection branch.

	I'm afraid I have to disagree with you. The Q values in the
	user's locations should not be mixed with Q values from 302
	Contact header. So, if you execute recursive
	first-only/sequential proxy node, the contact(s) in 302 are
	processed immediately, not mixed with the rest of the location
	set.

					Pekka

>> is to order the set by the "q" parameter value from the

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Sep 2003 03:13:27 -0400

a thought inline.

> what will be next proxying order: C,B,D or B,C,D?

Interesting question.

rfc3261, as written, advises to re-sort the result in q-value order, 
so you would get B, D, C.

However, I have raised an issue recently about the problem with doing 
this. It only works on the assumption that the various elements which 
have provided these q-values agree on a semantic for the values such 
that they can be chosen in a way which allows meaningful ordering. 
That is not the semantic of q-values, in fact, as they are really 
meant to be ordinal, not cardinal. As such, you cannot usefully mix 
q-values from different sources and get a meaningful order.

As such, the only approach which makes sense is to treat the redirect 
as a replacement for the contact which caused the redirect. In that 
case, you would substitute A in {A,B} with {D,C} and thus get 
{{D,C},B}. That is the approach I would advise.

> combination)- is this the way it suppose to work?

Yes.

> to insert or to append - if we respect the order imposed by q or not)?

Good question. I think the text is contradictory in that regard. The 
behavior described for recurse and first-only cannot be mutually 
satisfied. I believe this is a bug which needs to be clarified in the 
document. I would tend to think that "first-only" should win, and so 
the recurse output would be taken even if recurse was also set.

-Jonathan R.

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