ARGH!
RjS
On Oct 21, 2006, at 12:41 PM, Robert Sparks wrote:
I've about got -04 ready to go - going through all the -03 comments to make sure they were covered - this (and Jeroen's quoted comment) need a reply.
Inline:
On Sep 14, 2006, at 1:08 PM, Pete Cordell wrote:
I don't think CSeq should be included either. We want information that is invariant throughout a session. By including CSeq there's a chance that one request doesn't have a hash collision when doing the loop detection, but a subsequent request does.
Pete.
We already have other things going into the input that will cause the output to vary between transactions. At a minimum an initial request might not have a Route hf, where a subsequent request may:
(from the draft):This second part MUST vary with any field used by the location service logic in
determining where to retarget or forward this request. This is necessary to distinguish
looped requests from spirals by allowing the proxy to recognize if none of the values
affecting the processing of the request have changed. Hence, The second part MUST depend
at least on the received Request-URI and any Route header field values used when processing
the received request. Implementers need to take care to include all fields used by the
location service logic in that particular implementation.
So, including the CSeq does no harm, and it could do good to avoid repeating the collision.
----- Original Message ----- From: "Jeroen Van Bemmel" <jbemmel at zonnet.nl>To: "Robert Sparks" <rjsparks at nostrum.com>
Yes, except that using "the via branch" here is tricky: which one do you take?
Pre-RFC3261 clients would not insert a branch parameter, so taking the top via branch wont always work. Using the branch parameter added by the proxy itself is possible, provided that only the "first part" is used. Implementors then need to make sure to disect the branch prior to calculating the loop hash.
Possible, but easy to get wrong
Jeroen
That is the same concern I have had all along with the basic way this "look through the Via stack" loop detection mechanism is constructed in the first place.
It's very likely that the first time implementer will do something wrong. The most frequent wrong thing I saw at SIPits back when this was mandatory the first time around
was that implementations were very fragile about parsing other people's Vias, particularly the Vias of other proxies that were using the via as a convenient place to hold
information about the transaction for when the response came back through (made for unusually formed, but quite legal field values).
To your specific comment, my text below was ambiguous. Here's the tightened up version that I'm putting in -04. Note that this isn't asking an implementation to do _any_ dissection
of a via branch parameter it didn't create (which is the confusion I think I caused you).
(from the draft):When forming the second part using a hash,
implementations SHOULD include at least one field in the input to the hash that
varies between different transactions attempting to reach the same destination to avoid
repeated failure should the hash collide. The Call-ID and CSeq fields, or the first part
of the via branch parameter value the proxy is currently constructing would be good inputs for this purpose.
RjS
-----Oorspronkelijk bericht -----
Van: "Robert Sparks" <rjsparks at nostrum.com>
Aan: "Jeroen Van Bemmel" <jbemmel at zonnet.nl>
CC: "Pete Cordell" <pete at tech-know-ware.com>; "Cullen Jennings" <fluffy at cisco.com>; "SIP" <sip at ietf.org>
Verzonden: 14-9-06 15:00
Onderwerp: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03
Hrmm. Let me poke at that for a minute.
You would never compare the hashes you created for two different calls. You only compare hashes for different instances of the _same request_ reaching the element multiple times. The only things in the Via stack when the request reaches you are values placed when _this request_ went through other element, and you're checking to see if one of them just happened to be this element.
The Call-ID is invariant for those comparisons. If you had a perfect hash, including it would have no effect on the correctness of the algorithm at all - it would be wasted effort, which is why we were removing it.
But for a hash that has collisions, including it, or any other set of bits that change between requests, shifts where you land in the hash's range, increasing the probability that you won't encounter the _same_ collision more than once.
That may be exactly why call-id and cseq were included in the hash in 3261. Assuming that's so, then all we need are bits that change between transactions. The first part of the via branch parameter would be enough.
So, I propose I add text explaining why you SHOULD (do we make this MUST?) add some set of bits that change between requests, and note that either the first part of the via branch or the combination of call-id and cseq would be good choices.
RjS
On Sep 14, 2006, at 5:20 AM, Jeroen Van Bemmel wrote:
I suppose one issue is that if you do happen to be the 20 billionth person trying to make such a call, then your call will fail every time, which may be a bad effect.
(jvb) And THAT'S the reason to include the call-id in the hash: to ensure that an unlucky caller does not suffer the same fate twice (or rather: to make it very unlikely)
Jeroen
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip