Subject: Re: [Sip] [Sipping] status of draft-ietf-sip-gruu-15

From: Dean Willis <[email-masked]>
Date: Thu, 2 Oct 2008 10:24:52 -0500

Juha brought this up on SIPPING, and I'm moving it to SIP.

On Oct 1, 2008, at 2:49 PM, Juha Heinanen wrote:

> DRAGE, Keith \(Keith\) writes:
>
>> draft-ietf-sip-gruu is dependent on draft-ietf-sip-outbound (for  
>> which
>> publication has been requested but the AD has not yet moved it off  
>> the
>> starting grid).
>
> outbound going to be published?  i suggest that it is fixed first.
>

I'm going to regret this. I know. But I have to ask.

  I thought was fixed as you wanted by requiring multiple  
registrations if there are multiple configured proxies.

So what do you think is broken now?

--
Dean

_______________________________________________
Sip mailing list  https://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: [email-masked] (Juha Heinanen)
Date: Thu, 2 Oct 2008 19:03:43 +0300

> So what do you think is broken now?

see my message a few days ago to the list.  i have read only a few
percent of outbound text and at least this paragraph is broken:

   If the UAC is sending a dialog-forming request, and wants all
   subsequent requests in the dialog to arrive over the same flow, the
   UAC adds an 'ob' parameter to its Contact header.  Typically this is
   desirable, but it is not necessary for example if the Contact is a
   GRUU [I-D.ietf-sip-gruu].  The flow used for the request is typically
   the same flow the UA registered over, but it could be a new flow, for
   example the initial subcription dialog for the configuration
   framework [I-D.ietf-sipping-config-framework] needs to exist before
   registration.

also, i'm questioning why outbound i-d does not provide a general
solution to "usage of the same flow for in-dialog requests" problem:

  outbound behavior is also needed in case of regular presence server.
  that is why i don't quite understand is why is this "usage of the same
  flow for in-dialog requests" feature tied to outbound proxy.  why is it
  not useful to have a generic capability for UAC to tell to the next hop
  (a proxy or UAS) in its dialog initiating request that "please use this
  flow for subsequent requests of this dialog"?

-- juha

---

From: Dean Willis <[email-masked]>
Date: Thu, 2 Oct 2008 18:00:45 -0500

>   framework [I-D.ietf-sipping-config-framework] needs to exist before

Ah. Thanks.

I'll follow that one up on the list on the thread in which it was  
raised.

>  flow for subsequent requests of this dialog"?

It probably is useful, just as having keepalive separate from outbound  
is probably useful. If we were designing outbound from scratch, we'd  
probably break those two functions out into separate drafts, and have  
outbound use them.

Given that we can, if we find it sufficiently useful, add a generic  
connect-reuse modifier apart from outbound, Is it worth derailing  
outbound in order to fix it at this stage?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 2 Oct 2008 18:58:52 -0500

>  framework [I-D.ietf-sipping-config-framework] needs to exist before

Proposed text:

Typically, a UAC using the procedures of this document and sending a
dialog-forming request will want all subsequent requests in the dialog
to arrive over the same flow. If the UAC is using a GRUU
[I-D.ietf-sip-gruu] that was instantiated using a Contact header field
value that included an "ob" parameter, the UAC sends teh request over
the flow used for registration and susequent requests will arrive over
that same flow. If the UAC is not using such a GRUU, then the UAC adds
an "ob" parameter to its Contact header field value.  This will cause
all subsequent requests in the dialog to arrive over the flow
instantiated by the dialog-forming request. This case is typical when
the request is sent prior to registration, such as in the the initial
subcription dialog for the configuration framework
[I-D.ietf-sipping-config-framework].

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 3 Oct 2008 08:42:24 +0300

> probably break those two functions out into separate drafts, and have  

my understanding is that there has never been a previous outbound
related rfc, i.e., we ARE designing outbound from scratch.

 > outbound in order to fix it at this stage?

it surely is.  real life fact is that many vendors have already
implemented keepalive as a standalone mechanism and (as my presence
example showed) there would be need to have a generic mechanism for
connection reuse too.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Fri, 3 Oct 2008 11:25:46 -0500

> related rfc, i.e., we ARE designing outbound from scratch.

Nope. We're designing outbound from where it is -- a document with  
years of effort in it, and quite a few implementations.

We always learn things while doing a document. Sometimes those things  
make their way into the document sometimes they don't.

My understanding of the WG's consensus position is that, while we  
could probably keep making Outbound better forever, the currently  
known weaknesses are not enough to force a fundamental redesign at  
this point.  We're still open to clarifications, and there's always  
the possibility that a real show-stopper could exist, but these two  
design limitations don't qualify as show-stoppers.

> example showed) there would be need to have a generic mechanism for

We're looking at a standalone keepalive, and Christer has been leading  
that work. We've also been stumbling over a connection-reuse mechanism  
for years; perhaps you have an insight that could lead that work  
towards some sort of meaningful conclusion.

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 3 Oct 2008 19:03:36 +0300

Dean Willis writes:

 > this point.

i haven't suggested "fundamental redesign".  outbound should refer to
generic connection reuse and keepalive rfcs rather that include limited
solutions of its own that are likely to cause later backwards
compatibility issues or second solutions to the same problems.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 3 Oct 2008 16:56:54 -0500

Thanks Dean.

This text seems perfect to me. I'll deal with it in WGLC. 

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: Thursday, October 02, 2008 16:59
> To: Audet, Francois (SC100:3055)
> Cc: Juha Heinanen; SIP IETF
> Subject: gruu in outbound-15 9.1
> 
> >
> 
> Original text:
> 
> 
> Typically, a UAC using the procedures of this document and 
> sending a dialog-forming request will want all subsequent 
> requests in the dialog to arrive over the same flow. If the 
> UAC is using a GRUU [I-D.ietf-sip-gruu] that was instantiated 
> using a Contact header field value that included an "ob" 
> parameter, the UAC sends teh request over the flow used for 
> registration and susequent requests will arrive over that 
> same flow. If the UAC is not using such a GRUU, then the UAC 
> adds an "ob" parameter to its Contact header field value.  
> This will cause all subsequent requests in the dialog to 
> arrive over the flow instantiated by the dialog-forming 
> request. This case is typical when the request is sent prior 
> to registration, such as in the the initial subcription 
> dialog for the configuration framework

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 6 Oct 2008 09:22:25 +0200

Hi,

I have to admit that I have missed the addition of the possibiliy to
establish non-registration outbound flows using dialog-forming requests.

However, I unfortunately think that is going to require some more
editorial work to the spec, because parts of the documents talk about
the registation case, and some procedures seem to assume that
registrations are used, so maybe clarifications are needed that some
procedures only apply to the registration case.

---------------------------

Subclause 1 says:

"The key idea of this specification is that when a UA sends a REGISTER
request or a dialog-forming request, the proxy can later use this
same network "flow"--whether this is a bidirectional stream of UDP
datagrams, a TCP connection, or an analogous concept in another
transport protocol--to forward any incoming requests that need to go
to this UA in the context of the registration or dialog.

The text is a little confusing. It starts by talking about when a UA
sends a REGISTER, and at the end it talks about the context of a dialog.
You probably need to e.g. split the text into two parts - one talking
about the registration case, and one talking about the dialog case.

---------------------------

Subclauses 2.1 says:

"ob Parameter:  The 'ob' parameter is a SIP URI parameter which has
      different meaning depending on context.  In a Path header field
      value it is used by the first edge proxy to indicate that a flow
      token was added to the URI.  In a Contact or Route header field
      value it indicates that the UA would like other requests in the
      same dialog routed over the same flow."

First, I assume it refers to a Contact or Route header inserted by the
UAC in the dialog, so maybe that needs to be clarified. 

Second, I assume the only time the UAC will insert the parameter in a
Route header is when it was sent beck in a Path header?

---------------------------

Subclause 3.1 says:

 "When sending a dialog-forming request, a UA can also ask its first
   edge proxy to route subsequent requests in that dialog over the same
   flow.  This is necessary whether the UA has registered or not."

Why is this necessary when the UA is registered? Won't requests then
automatically be delivered over the registered flow?

---------------------------

Also, are keep-alives sent on dialog-forming requests? The text in the
last paragraph of subclause 1 seems to indiate so.

But, the non-registration flow examples don't show any keep-alives.

Also, subclause 3.5 says:

"When the UA detects that a flow has failed or that the flow definition
has changed, the UA needs to re-register..."

Is that true if the flow was established using a dialog-forming request?
What if the UA isn't registerded in the first place...? I guess
subclause 4.5 clarifies that this only applies to registation flows, but
it would also need to be claified here.

Also, subclause 3.5.1 says:

"If the client does not receive a pong in response to its ping, it
declares the flow dead and opens a new flow in its place."

How will that be done if the flow was established using a dialog-forming
request? Will the new flow be esablished by transfering the existing
dialog?

---------------------------

Subclause 4.2.1 talks about the case when the UAC recieves a 439
resposne for the REGISTER request. But, can't it receive 439 also if it
tries to estblish the flow using a dialog-establisment request?

---------------------------

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Francois Audet
Sent: Saturday, October 04, 2008 12:57 AM
To: Dean Willis
Cc: SIP IETF
Subject: Re: [Sip] gruu in outbound-15 9.1

Thanks Dean.

> value that included an "ob"
> registration and susequent requests will arrive over that same flow. 
> If the UAC is not using such a GRUU, then the UAC adds an "ob" 
> parameter to its Contact header field value.
> This will cause all subsequent requests in the dialog to arrive over 
> the flow instantiated by the dialog-forming request. This case is 
> typical when the request is sent prior to registration, such as in the

> the initial subcription dialog for the configuration framework 
_______________________________________________
Sip mailing list  https://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
_______________________________________________
Sip mailing list  https://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: "Christer Holmberg" <[email-masked]>
Date: Mon, 6 Oct 2008 20:19:37 +0200

Some updates to my own previous comments. I have found answers to some
of the questions, so I have removed them.

Hi,

Subclause 1 says:

"The key idea of this specification is that when a UA sends a REGISTER
request or a dialog-forming request, the proxy can later use this same
network "flow"--whether this is a bidirectional stream of UDP datagrams,
a TCP connection, or an analogous concept in another transport
protocol--to forward any incoming requests that need to go to this UA in
the context of the registration or dialog.

Regards,

Christer

-----Original Message-----

Thanks Dean.