Subject: [Sip] RE: Question about keep-alives in Outbound draft

From: "Francois Audet" <[email-masked]>
Date: Fri, 20 Jul 2007 12:32:35 -0500

Moving to proper mailing list (i.e., sip).

Rohan, I also think that the draft could be a little bit clearer
about where the CRLF is sent, and where it stops, but I think it's a
consequence of how section 3 is structured, and the terms we use.

If we made the concept of "Outbound proxy" a bit clearer in the
document, and
use it throughout, and specifically say that the CRLF is sent to the
outbound proxy, 
it would read much better. 

Section 3 and above don't even use the term "outbound proxy" and instead
uses
euphemisms such as "edge proxy", "proxy", "registrar", "host" and
"server".

Furthermore, it starts with a special case (co-located Registrar and
Proxy),
and finishes with the the general case (outbound proxy is separate
from the Registrar).

I would suggest the following editorial changes:

- Move section 3.4 to where 3.2 currently is.

  - Remove the word "Proxy" in the box that says "Registrar/Proxy"
(i.e., 
    it should just say "Registrar". There is no need for having a proxy
    necessarily co-located in the Registrar, and it's immaterial to this
    draft.

   - The box that say "Edge1" and "Edge2" should really be labelled 
     "Outbound Proxy  1" and "Oubound Proxy 2". The text should also
     use the term "outbound proxy" instead of "edge proxy", and it
     should just explain that often this configuration is called 
     and "edge proxy".

- In section 3.2 (which would now be 3.3), clarify that this is just a 
  special case of the outbound proxy and Registrar being co-located.
  Also use the term "outbound proxy" in the diagram and the text, as
  appropriate.

- In section 3.3 (which would now be 3.4), clarify that the Host1 and
  Host2 are really the outbound proxy 1 and 2, in the diagram.

- In section 3.5, use the term "outbound proxy" instead of server
  when talking about the entity receiving the ping and sending the pong.
  
- Section 5 should use the term "Outbound proxy" instead of "Edge
proxy".

- Section 5.4 is where we should say the "oubound proxy" does not 
  forward the keep alives.

- Section 9 should use the terms "Primary outbound proxy" and "Secondary

  outbound proxy".

Cheers

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]] 
> Sent: Friday, July 20, 2007 09:20
> To: Stucker, Brian (RICH1:AR00)
> Cc: Rohan Mahy; Cullen Jennings; [email-masked]; Audet, 
> Francois (SC100:3055)
> Subject: Re: Question about keep-alives in Outbound draft
> 
> 
> On Jul 19, 2007, at 9:50 PM, Brian Stucker wrote:
> 
> > Cullen/Rohan,
> >
> > I have a question about keep-alive behavior in the -10 
> version of the 
> > outbound draft.
> >
> > How far are keep-alives propagated along the flow created at 
> > registration?
> >
> > The text seems a bit hazy on how far it is expected for a 
> keep- alive 
> > to be propagated along the flow. Section 8 has text in the last 
> > paragraph on page 25 that seems to imply that STUN 
> keep-alives go no 
> > further than the edge proxy immediately adjacent to the 
> client device. 
> > Section
> > 4.4.3
> > seems to also limit generation of STUN keep-alives to the 
> User-Agent 
> > only.
> 
> one-hop.  one-hop only Mister Kamarov.
> 
> > Likewise, section 4.4.1 and 5.4 seem to limit the TCP CRLF 
> response to 
> > the first edge-proxy as well.
> 
> yes.
> 
> I don't think either of these statements is hazy.  Can you 
> propose a rewording?
> 
> > Inclusion of the keep-stun or keep-crlf parameters for a Path URI 
> > inserted by an edge proxy or registrar outside of the one in the 
> > outbound-proxy-set seems moot as earlier edge-proxies that don't 
> > support these mechanisms would ostensibly drop the keep-alives.
> 
> if these parameters find their way into a URI handled by 
> another proxy (instead of the UAC), they will be ignored (and 
> no keepalives will be generated by the proxy).
> 
> > Further, you only show a NAT/FW between the first 
> edge-proxy and the 
> > User-Agent in the figure for section 3.4.
> 
> yes.  that was part of our design assumptions.  we had a hum 
> on that about a year ago.  We assume that there is a full SIP 
> connectivity among any of the proxies and that anything 
> necessary to make that work is taken care of.
> 
> > However, the spec never really
> > says very clearly what should occur at the edge-proxy: 
> should it check 
> > for freshness of the next-hop towards the registrar or not, 
> based upon 
> > what it observed in the Path header coming back in the registration 
> > response?
> 
> It says very clearly what to actually do and I hope it 
> doesn't even hint that you should even begin to think about 
> such a heinous thing as sending keepalives to the registrar 
> from the EP.
> 
> > Is there a reason that edge-proxies are not expected to regenerate/ 
> > relay the appropriate keep-alive message to the next entry 
> on the Path 
> > vector?
> > Not doing so means that some other mechanism must be 
> employed to keep 
> > bindings/pinholes open between the various edge-proxies and the 
> > registrar proxy.
> 
> If that problem exists in your environment, it is completely 
> out of the scope of outbound.  The spec is about routing 
> traffic over outbound-initiated flows from the UA.
> 
> > For instance, in IMS you can have a P-CSCF in the visited network 
> > talking to an IBCF in the visited network that is connected 
> to an IBCF 
> > in the home network that finally terminates at the S-CSCF 
> in the home 
> > network of the user that is registering. A NAT/FW is likely 
> to exist 
> > between the UA and the visited P-CSCF as well as between 
> the IBCF in 
> > the visited network and the IBCF in the home network.
> 
> How do SIP messages make it today from a P-CSCF to an S-SCSF?
> 
> > Another possible example (I believe) would be in the case of p2psip 
> > where you may have multiple hops between the client and the node 
> > acting as a registrar for the DHT algorithm. Wouldn't you 
> want to keep 
> > the entire path to the node storing your contact information in the 
> > DHT alive or is there some other property of the DHT algorithm that 
> > ensures that this is always the case even though outbound 
> only keeps 
> > the last hop fresh?
> 
> p2psip has some unique requirements.  I don't think outbound 
> prevents p2psip from addressing their requirements, but they 
> are certainly not the concerns that outbound intended to address.
> 
> thanks,
> -rohan
> 
> 
> > Regards,
> > Brian
> 
> 

_______________________________________________
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: Rohan Mahy <[email-masked]>
Date: Fri, 20 Jul 2007 10:56:51 -0700

François,

We started off using the term outbound proxy in previous versions of  
the draft and many people complained that the term did not have a  
meaningful or useful definition.  It was one of those "its what I  
mean" definitions.  I think the definitions of edge proxy,  
authoritative proxy, registrar, and UAC are pretty tight.  There  
certainly might be some places where we say "host" or "client" or  
"proxy" where we should be saying something more well defined, but if  
so, I would like to change them to the correct terms, not to outbound  
proxy".

AFAIK, going back to outbound proxy will be a big step backwards for  
the document.  Also, the registrar and proxy together is the simplest  
case to explain and I think it is still the most common topology.

thanks,
-rohan

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 20 Jul 2007 13:22:26 -0500

The "Registrar" and "Authoritative proxy" definitions are prety tight, sure. That's
OK with me.

The problem is that you have no consistent term in the document for "the place where
the UAC sends both requests and keep alives".

In some places it's called "host", in others "server", in others "edge proxy",
in others "registrar", depending on topology. In other places, it's just 
avoided altogether, e.g.., the request is "sent" as oppose to the request is
"sent to edge proxy".

If we don't want to use the term "outbound proxy" that is used consistently in
RFC 3261 (presumably because it's both an "outbound" and an "inbound" proxy at the same 
time, and because it means "the outbound proxy that conforms to the this draft"), then let's 
use "Edge proxy" consistently. And we should state that "An Edge proxy is an Outbound
Proxy (as per RFC 3261) that conforms to the requirements of this specification" (if the
statement is true).

That would mean that in your co-located scenario, it would be a "Registrar/Edge Proxy"
instead of "Registrar/Proxy", and in your multiple connection scenario, it would be
"Edge Proxy 1" and "Edge Proxy 2".

Would that work?

> Sent: Friday, July 20, 2007 10:57
> To: Audet, Francois (SC100:3055)
> Cc: Rohan Mahy; Stucker, Brian (RICH1:AR00); Cullen Jennings; 
> [email-masked]
> We started off using the term outbound proxy in previous 
> versions of the draft and many people complained that the 
> term did not have a meaningful or useful definition.  It was 
> one of those "its what I mean" definitions.  I think the 
> definitions of edge proxy, authoritative proxy, registrar, 
> and UAC are pretty tight.  There certainly might be some 
> places where we say "host" or "client" or "proxy" where we 
> should be saying something more well defined, but if so, I 
> would like to change them to the correct terms, not to 
> outbound proxy".
> 
> AFAIK, going back to outbound proxy will be a big step 
> backwards for the document.  Also, the registrar and proxy 
> together is the simplest case to explain and I think it is 
> still the most common topology.
> 
> thanks,
> -rohan
> 
> 
> > Rohan, I also think that the draft could be a little bit 
> clearer about 
> > where the CRLF is sent, and where it stops, but I think it's a 
> > document, and use it throughout, and specifically say that 
> the CRLF is 
> > sent to the outbound proxy, it would read much better.
> >
> > Section 3 and above don't even use the term "outbound proxy" and 
> > instead uses euphemisms such as "edge proxy", "proxy", "registrar", 
> > "host" and "server".
> >
> > Proxy), and finishes with the the general case (outbound proxy is 
> > separate from the Registrar).
> >
> >> Cc: Rohan Mahy; Cullen Jennings; [email-masked]; Audet, Francois 
> >> (SC100:3055)
> propose a 
> >> rewording?
> >> if these parameters find their way into a URI handled by another 
> >> proxy (instead of the UAC), they will be ignored (and no 
> keepalives 
> >> will be generated by the proxy).
> >>
> >> yes.  that was part of our design assumptions.  we had a 
> hum on that 
> >> about a year ago.  We assume that there is a full SIP connectivity 
> >> among any of the proxies and that anything necessary to make that 
> >> work is taken care of.
> >>
> doesn't even 
> >> hint that you should even begin to think about such a 
> heinous thing 
> >> as sending keepalives to the registrar from the EP.
> >>
> >> If that problem exists in your environment, it is 
> completely out of 
> >> the scope of outbound.  The spec is about routing traffic over 
> >> outbound-initiated flows from the UA.
> >>
> >> p2psip has some unique requirements.  I don't think 
> outbound prevents 
> >> p2psip from addressing their requirements, but they are 
> certainly not 
> >> the concerns that outbound intended to address.
> >>
> >> thanks,
> >> -rohan
> >>
> >>
> >>> Regards,
> >>> Brian
> >>
> >>
> 
>

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 20 Jul 2007 11:53:28 -0700

Hi Francois,

I think calling the composed registrar and proxy an Edge Proxy will  
be confusing for a lot of people, but if you have a few places in  
mind and want to send example text for one or two of these I think  
its worth considering the change.

thanks,
-rohan

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 20 Jul 2007 18:08:46 -0500

The last sentence of section 8 says "The SIP keepalive STUN usage
requires no backwards
compatibility.".

It's not clear "with what".

I'm assuming that you mean it works with rfc3489bis but not RFC 3489?

Please clarify (in the document and on the mailing list).

---

From: Rohan Mahy <[email-masked]>
Date: Sat, 21 Jul 2007 23:51:59 -0700

> I'm assuming that you mean it works with rfc3489bis but not RFC 3489?

correct.  this is one of the things listed that a usage of stun needs  
to handle. i'll put this in the document.

thanks,
-rohan