Subject: [Sip] Forking: a modest proposal.

From: [email-masked]
Date: Mon, 2 Jul 2001 11:44:51 -0500

I'm putting together the SUB/NOT draft (we should go into nits
on Monday), and am currently wrestling with the issue of forking.

I have what I think is an elegant solution, given the immediate
NOTIFY mechanism that we have agreed on. Certain camps have objections
to this mechanism, and thinks that all but the first SUBSCRIBE should
be made to fail (by sending a 400 class response). I don't see this
difference of opinion as intractable, but it is something that will
take a considerable amount of time (discussion, work, etc) to reach
consensus.

On reflection, I realize that this entire situation just highlights
a thorn we've had in our paw the entire time.

Given that all transactions complete (basically) immediately (with
the exception of INVITEs), forking *any* non-INVITE request is just
a race waiting to happen. It usually just leads to heartburn when
you attempt to analyze how it's going to work with non-INVITE methods
(as in the SUBSCRIBE example).

Since there seems to be a general feeling that all but the first
received request should "fail" in some general sense (usually by
the request initiator not finding out about the response), I'd
like to float a proposal:

Deprecate forking of non-INVITEs.

Despite my tongue-in-cheek subject line, I'm serious.

SIP is not going to Draft Standard this time around, so maintaining
absolute compatibility with RFC 2543 isn't strictly required. No one
has come up with a useful application of forking non-INVITEs (except,
arguably, my proposal that a forked SUBSCRIBE can install several
subscriptions, with the subsequent NOTIFY messages establishing the
legs, routes, and contacts as necessary). Forking non-INVITEs adds
complexity to the protocol, extra work to all extensions, and
headaches all around. And as long as people insist that nothing useful
can come from forking anything but an INVITE, there is no gain to be
had by leaving this "feature" in the protocol.

As long as it is understood at a general protocol level that forking
of non-INVITEs is disallowed, I have no problem rejecting the additional
NOTIFY legs we find out about. If we continue to pretend that forking
of non-INVITEs is a useful concept, I can't see the logic behind refusing
to allow successful forking of SUBSCRIBEs.

Comments, etc, encouraged -- even if just to voice assent.

/a

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 6 Jul 2001 20:30:25 -0500

Well, I've made the less modest proposal before that forking could be
removed entirely from the specification. It seems to be an unpopular
suggestion in some quarters, but I like to bring it up before IETF meetings
as a matter of tradition (and in hopes that someday certain critical parties
will agree).

Admittedly, most of you people are way brighter than me. But I find that the
branches and tags and special cases and stuff introduced to make forking
work regularly confuse my pointy little head, and seem to occasionally trip
up other folks as well. It really makes me sweat every time I have to think
about how a proposed extension will interact with forking, and in the Texas
summer, extra perspiration could be dangerous.

On the other hand I have to admit that I do USE forking all the time --
inbound calls to my phone hit a forking proxy and land on three SIP phones
and my cell phone roughly simultaneously.

But it also seems that what we desired from forking could be readily
implemented as application logic without as much complexity in the core
protocol, and I think such an application would meet my needs as a forking
user (I've always wanted to say that about users). This would also allow
forking-like behavior for new messages on an as-needed-by-application-logic
basis. And acceptance of such a proposal would settle once and for all
whether non-INVITE messages get forked.

Any takers?

--
Dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 06 Jul 2001 23:10:46 -0400

> whether non-INVITE messages get forked.

The problem is that once you implement "forking" at the B2B-UA level,
you also need loop detection and most of the other features and pretty
soon, you'll be back to where we started, one layer up, except that
every system will implement them differently. It may well be that
splitting them across two layers would've been the right thing, but I
doubt that the overall system would be less complex. (I agree that tags
could be avoided if the B2BUA uses, say, a new call-ID for each branch.)

Some of the complexities are due to the desire to keep proxies call
stateless. If you are willing to make them call stateful, things like
multiple 200 can probably be avoided. Again, a trade-off with some cost.

Thus, I think this is a far more complex trade-off. Without a complete
design of the alternatives, I'm afraid that we'd be deluding us in terms
of overall system complexity.

Even email has various forking problems, even though the "branches" are
completely independent, as the usual complaints about vacation emails
and confirmation receipts (think of them as multiple final responses..)
show.

I agree that for most messages (such as MESSAGE), forking-like behavior
is much more like an email reflector and should be treated as such,
invisible to the sender.

Henning

---

From: [email-masked]
Date: Mon, 9 Jul 2001 11:13:09 -0500

> From: Henning Schulzrinne [mailto:[email-masked]]
> 

I think it would be far less complex, since it doesn't impact every
silly little detail of every single extension. By making it an application
on top of the protocol, it becomes an issue for the application designer.
By and large, such a designer will be able to make reasonable decisions,
like: "I have no idea what method XYZZY means, so forking it would
be absurd."

Currently, since it is part of the spec, forking proxies will say
"XYZZY is just a method. I'm method agnostic. I'll fork it!"

I'm 100% behind Dean's proposal, and would be interested to see
how, say, a hum vote on the topic would turn out. Can we have a
short rant on this topic in London followed by a poll for rough
consensus?

/a

---

From: Jay Batson <[email-masked]>
Date: Mon, 09 Jul 2001 19:24:05 -0400

>could be avoided if the B2BUA uses, say, a new call-ID for each branch.)

Of course, *that* problem could be solved by deprecating B2BUAs, which are 
truly and deeply evil IMHO....  Watching the list from afar as I do, I 
observe that there is a significant and growing temptation to fall back on 
doing everything via B2BUAs now, less and less of a discipline to force 
things into the proxy/server model, with the resulting behavior / 
architecture starting to feel more and more like Megaco.  This is a bad thing.

On the Forking topic, since I'm so far removed from true engineering, I 
thought forking *was* an application behavior, and not a part of the 
protocol.  So despite the fact that my opinion shouldn't count for much 
'cause I'm not rigorously informed or thinking as rigorously about it as I 
should, I'd probably take Adam up on his notion to keep forking at the 
application level.

Comments from an anarchist who has more of a vested interest in the edge 
than the middle....
-jb

-------------
PingMe!
Jay Batson
CEO
Pingtel Corp.
mailto:[email-masked]
781-938-5306 (office)

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 10 Jul 2001 06:52:04 -0700

Any way to simplify some of the tougher scenarios we have would be fine 
with me. I think we should at least discuss your proposal in London, either 
in the meeting or in the pub.