Subject: [Sip] Attention - comment on Loose Routing draft

From: Robert Sparks <[email-masked]>
Date: Mon, 14 Jan 2002 13:57:47 -0500

The draft below contains the resolution to a large
set of open issues around processing of the Route header,
preloaded routes, and the use of default outbound proxies.
The plan is to modify bis to reflect these proposals.

Please review it as soon as you can and comment if you
see real problems. Silence will be taken as consent.

RjS

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: Thursday, January 10, 2002 10:46 PM
> To: [email-masked]'
> Subject: [Sip] Loose Routing draft
> 
> 
> I just submitted a draft refining the post I sent
> out after IETF52 on the loose routing proposal.
> 
> Until it appears in the archive, you can find it at
> http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.txt
> or
> http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.html
> 
> 
> RjS
> 
> _______________________________________________
> Sip mailing list  http://www1.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
> 

_______________________________________________
Sip mailing list  https://www1.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: Robert Sparks <[email-masked]>
Date: Tue, 15 Jan 2002 14:25:21 -0500

The restriction against modifying or removing Route header
field values beyond the topmost one is needed to ensure that
the resources placed in the Route are eventually visited.
Without something like it, a policy of "remove and ignore
all Route headers" would be valid - something we don't want.
If a resource appears in a Route header the request must
eventually reach that resource. 

The problem with X reaching into the stack and touching
the B entry is that X doesn't necessarily know what Y
was going to do. The sender of the request may have
really intended for B to process the request based on
the output of Y. So, just like it would be bad for X 
to decide the request doesn't _really_ need to go to Y,
it would be bad for X to decide the request doesn't
really need to go to B.

So, the question I'm taking from this is does the recommendation
to put the intended destination at the end of the route set
effectivly prevent retargeting of the request before the owner
of that last element is reached? It looks like it does if the
request encounters a strict router on the path (such an encounter
is exactly what motivated the recommendation).

It would help in exploring this if you could provide details 
of a specific instance of the scenario you have in mind.

RjS

> Consider a situation, where a request is directed
> to (B) and two service elements (X) and (Y) have
> to be visited before.
> (X) performs a service, which replaces the intended
> destination URL, i.e. (B), whereas (Y) executes
> some feature, which depends on the output of (X). 
> 
> When the request arrives at (X), the R-URI / Route
> could look like:
> - R-URI: <X>
> - Route: <Y>,<B>
> (The intended destination has been appended earlier
> to Route as per section 5.2 in your I/D)
> 
> How can (X) now apply the destination URL relacing feature?
> My first guess was, that (X) would modify the last entry
> in the Route, i.e. (B).
> 
> Your first proposal in section 2 prohibits such behavior:
> "[...] an element [...] MUST NOT modify or remove
> subsequent Route header field values."
> 
> Is this restriction intended also for such cases or could
> we relax it to allow modifying of the last entry in Route?
> Would marking the last Route entry as the intended
> destination (and allow modifying of such only) solve
> this issue?
> 
> Greetings,
>  Bernie
>  
> 
> PS: Some Typos:
> 
> - section 5.5, F7-F12:
>   s/Contact: sip:[email-masked]/Contact: sip:[email-masked]/
> 
> - section 5.5. F3/F4:
>   - Shouldn't maddr in F4 contain a different IP-address
>     than in F3?
>   - Maybe add a FQDN <-> IP mapping table to ease
>     the understanding of the examples.
>    
> - section 5.8:
>   s/senting/sending/     
> 
> 
> 
> >From: ext Robert Sparks [mailto:[email-masked]]
> >Sent: 14. January 2002 20:58
> >To: [email-masked]'
> >Subject: [Sip] Attention - comment on Loose Routing draft
> >
> >

---

From: "Honeisen Bernhard (NET/Helsinki)" <[email-masked]>
Date: Wed, 16 Jan 2002 11:01:06 +0200

Hi Robert!

My comments inline.

>eventually reach that resource. 

No problem with this.

>is exactly what motivated the recommendation).

The recommendation to put the intended destination at the end
of the route set as such is rather sensible.
We need such functionality, if we are pre-loading Route headers
AND routing might be strict.
Thus, this is an issue even with the current (as so far
specified in RFC2543/bis) approach.

I see your point, that if proxies can wildly change the
Route set, we are ending up in a mess.
Therefore, I was thinking, whether we should somehow mark
the Route header entry, which points to a intended detination
and <only if it is marked> AND <only if it is the last
Route entry>, X can perform the retargeting service.

Example: 

  INVITE <X> 
  Route: <Y>,
         <B>; intended-destination 

  (if the intended-destination tag present, we can modify it)

The problem now is maybe, how the earlier element knows, when
to mark to last Route header. Or would it be enough to mandate
(or recommend) such marking, if we are adding the intended
destination at the end of the route set (5.2). 

>of a specific instance of the scenario you have in mind.

I tried to generalize the example as much as possible.
(X) could be a service: find best destination UAS depending
on the time of the day, etc.
(Y) could be a statistics service, which logs all outgoing
calls, right before they leave my network

The real example comes from 3GPP, where we have a set of
Application Servers (AS) to traverse and we don't know, what
they are doing. But retargeting a request is a likely service.

In 3GPP it could look like (some network elements are skipped for
the sake of brevity; A is UAC, B is UAS):

<A> - <S-CSCF> - <AS> - <S-CSCF> - <B>

At the first visit of <S-CSCF>, we get a set of AS to traverse
(in this example one). After the AS, the request has to be routed
back to the S-CSCF.
I had in mind, that the <S-CSCF> pre-loads the route as follows:

 INVITE <AS>
 Route: <S-CSCF>, <B>

And if <B> has to be retargeted, <AS> would do it in the last
Route header.

Another example could look like:
<A> - <S-CSCF> - <AS 1> - <S-CSCF> - <AS 2> - <S-CSCF> - <B>

 INVITE <AS 1>
 Route: <S-CSCF>, <AS 2>, <S-CSCF>, <B>

Note: The detailed routing mechanisms between <S-CSCF>
      and <AS> are currently beeing standardized in 3GPP
      and the preferred way is to do it in line with SIP.

Greetings,
 Bernie

---

From: Robert Sparks <[email-masked]>
Date: Wed, 16 Jan 2002 10:46:58 -0500

Current strict-routing renders the request-URI
of a request containing a Route header impotent.

On reflection, looseroute-00 suggests that you 
could use it anyhow and as long as everyone played
nice (i.e. you did not encounter any strict routers)
the request-URI of a request containing Route headers
could have meaning. However, it introduced a suggestion
for protection against an element that doesn't play nice
that defeats the whole point, at least with the suggested
routing mechanism.

So - we can attack either the protection mechanism or the
routing mechanism. 

The direction you are suggesting can be made to work.
It basically says that the Request-URI is meaningless 
in the presence of Route headers because 
legacy strict-routers might exist, so lets just replace
its functionality with some other peice of the message.
It would define a "real" request-URI. If we were to go
down this path, making it a new header rather than a
specially tagged last Route element would be better - it
really has a different meaning than Route and forcing
elements to find the last value of a header field to do
their normal job is something we are learning to avoid
(it generally becomes an O(n^2) requirement on the overall
system). Unfortunately, that removes the protection against
strict-routers that having the intended destination in the
last Route would provide. 

Several people have suggested the alternative of using
Proxy-Require and further restricting the loose route
policy to say the output Request-URI must always reflect
the intended destination (possibly after retargetting).
The problem with this kind of proposal (beyond its tendency
to become Proxy-Require:do-what-i-mean) is it doesn't
fail well when the ultimate destination is behind a
strict-router. It becomes impossible to reach that 
destination _and_ invoke services using the routing mechanism -
you have to pick one.

Now, we could remove the suggestion to add the intended
destination as the last route element, and accept the 
potential failure induced by running into a strict-router
in between the elements on the Route set (we don't get failure
if the strict-router is encountered after the Route set is
exhausted). Is that kind of failure really likely to occur.
Certainly not within domains of control - the only scenarios
to study are those where you have multiple domains of control
on the route set (visiting and home services for example) and
there might be a strict router between those domains.

At the moment, I'm leaning towards the last. The proposal would
be to remove the suggestion to add the intended destination to
the last route and point out where legacy strict routers will
introduce failure. This gets us back to carrying the targetting
information in the Request-URI, where it belongs.

RjS

---

From: [email-masked]
Date: Mon, 21 Jan 2002 09:43:18 -0700

> I'll give an example that describes the problem I think 
> you're seeing -- I'm
> probably understanding you wrong, so flame on . . .
> 
> Ok, let's say we have established a dialog routed UA1, P1, 
> P2, UA2. P2 has
> resources tied up.
> 
> After some time, P1 decides to "retarget" the dialog by altering the
> destination of a reINVITE issued by P1. P1 rewrites the 
> request-URI and/or
> routes such that the reinvite traverses P3 and arrives at UA3.
> 
> Yes, this is bad, as it leaves P2 holding resources. But it's 
> bogus more
> ways than that . . .
> 

I think we agree here.

> But what if P1 has knowledge that P2 has failed, and it 
> re-routes thru P3
> in order to get to UA2, the original target?

OK, if failure recovery is what you had in mind, this sounds reasonable.  I
would have no problem with language that makes this intent clear when
allowing changed routes.  As long as the language doesn't allow problems
touched on above to happen.

John Hearty
Level3

> 
> --
> Dean
> 
> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; 
> <[email-masked]>
> Sent: Friday, January 18, 2002 9:20 AM
> Subject: RE: [Sip] Attention - comment on Loose Routing draft
> 
> 
> >
> >  The UAC considers it a re-Invite even when a proxy later 
> re-writes the
> > r-uri (a common action).  I'm not clear where you are 
> headed with this
> line
> > of thought wrt Robert's draft.
> >
> > John Hearty
> > Level3
> >
> > From: Dean Willis [mailto:[email-masked]]
> > Sent: Friday, January 18, 2002 7:06 AM
> > To: Hearty, John
> > Cc: [email-masked]; [email-masked]; 
> [email-masked]
> > Subject: Re: [Sip] Attention - comment on Loose Routing draft
> >
> >
> > Changing the request-URI in a reinvite makes it not a 
> reinvite, right?
> >
> > --
> > Dean
> >
> > ----- Original Message -----
> > From: <[email-masked]>
> > To: <[email-masked]>
> > Cc: <[email-masked]>; <[email-masked]>;
> <[email-masked]>
> > Sent: Thursday, January 17, 2002 9:22 AM
> > Subject: RE: [Sip] Attention - comment on Loose Routing draft
> >
> >
> > >
> > >  I would have to disagree with you too.  This sounds like trouble
> brewing,
> > > especially in transactions subsequent to the first.  Take 
> for example a
> > > firewall control proxy downstream from X.  An initial 
> Invite sets up
> > > firewall resources.  If a re-Invite comes through and X 
> decides service
> > > route points downstream from X don't matter anymore, you 
> just stranded
> > > firewall resources.
> > >
> > > John Hearty
> > > Level3
> > >
> > > From: Dean Willis [mailto:[email-masked]]
> > > Sent: Thursday, January 17, 2002 3:55 AM
> > > To: Honeisen Bernhard (NET/Helsinki); [email-masked]
> > > Cc: 'ext Robert Sparks'
> > > Subject: Re: [Sip] Attention - comment on Loose Routing draft
> > >
> > >
> > > Hmm, RjS may disagree, but I think that the retargeting 
> of the message
> at
> > X
> > > might override the service routing in the original 
> request. Changing the
> > > request URI means to me "don't send it to where it was 
> being sent, send
> it
> > > to this other place instead". Given this logic, service 
> route points
> > > downstream from X probably don't matter anymore.
> > >
> > > --
> > > Dean
> > >
> > > ----- Original Message -----
> > > From: "Honeisen Bernhard (NET/Helsinki)" 
> <[email-masked]>
> > > To: <[email-masked]>
> > > Cc: "'ext Robert Sparks'" <[email-masked]>
> > > Sent: Tuesday, January 15, 2002 9:05 AM
> > > Subject: RE: [Sip] Attention - comment on Loose Routing draft
> > >
> > >
> > > > Hi RjS!
> > > >
> > > > Some question:
> > > >