Subject: Re: [Sip] WGLC for draft-ietf-sip-connect-reuse-04.txt

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 04 Nov 2005 17:09:08 -0600

Dean Willis wrote:
> I'd like to go ahead and start WGLC for the connection reuse draft.  
> This is on the proposed SIP re-charter with a November deliverable,  so 
> we need to get moving on it.

Dean, Rohan:

Here are my WGLC comments for connect-reuse-04.

They are organized such that substantitive comments come first,
followed by nits.

1) The whole issue of "Directional Connectivity" in Section 2.2 is
best left to the outbound draft.  Currently it is discussed in
detail under the high order heading of "Problem Statement (Section
2)."  But connect-reuse does not solve this particular problem; so I
think it is best to take Section 2.2 out, and instead, put it in
the outbound I-D.  The outbound I-D does not have a "Problem
Statement" section and I think that it will benefit handsomely
from this swap.

Ditto for the last paragraph in "Clustering" Section 2.3.  This
paragraph is best put in the outbound I-D "Problem Statement"
section.

2) In Section 4, where the interaction of DNS and "alias" is described,
I believe that the use of "alias" leads to starvation of other
servers in a proxy farm since we have established an affinity with
a particular server.  Let me explain.

If within the Priority field of SRV RRs, the Weight fields are
the same (as is the example), then there will arise a situation
where the "alias" parameter will lead to the starvation of other
servers in a proxy farm.  Under normal circumstances, since the
Weight field of the SRV RRs is the same, traffic should be
distributed equally.  If instead, because of the "alias" parameter,
we do not use SRV, then only one host from the proxy farm gets
bombasted with *all* the traffic, effectively inhibiting load
distribution through SRV.

Do you see this as a problem?

3) In Section 3 "Requirements", Requirement 1 -- I am not sure why we
are worried about responses.  Responses tend to use the same
connection over which the request was sent (based on rfc3261).
It is subsequent requests in the opposite direction, and to a lesser
extent subsequent requests in the same direction that are a problem.

4) In Step 3 of Section 4.1.1, define "advertised name".  I think
you take this to mean what is in the sent-by production rule.
In other words:
   Via: SIP/2.0/TCP proxy-farm-a.example.com; ...
Here, "proxy-farm-a.example.com" is the "advertised name" ... yes?

5) I think a little bit more explanation around the example that
follows the 4 steps in Section 4.1.1 will help implementors in
gauging the intent.  Something as simple as replicating the
Via string mentioned before (i.e.,
Via: SIP/2.0/TLS proxy-farm-a.example.com;branch=z9hG4bK7c8ze;alias;
   received=10.54.32.2) will add some more understanding to the
example.

Nits:

1) Section 2
    s/connections instead using the/connections instead, using the

2) Section 2.1: I would suggest a vertical time-line diagram is
    appropriate for the call flow.  Something like:

                    Proxy A    Proxy B
                       |          |
   Create connection 1 +---INV--->|
                       |          |
                       |<---200---+ Response over connection 1
                       |          |
   Re-use connection 1 +---ACK--->|
                       |          |
                       =          =
                       |          |
                       |<---BYE---+ Create connection 2
                       |          |
        Response over  +---200--->|
        connection 2

3) Section 4.1.1: s/Finally, Verify/Finally, verify

4) Section 4.1.1: s/For example, take the example/Take the example

5) Label the figure in Section 4.  Change naming conventions in it
    to reflect "a1" and "a2" (which are used in the text) instead of
    "A1" and "A2" (used only in the figure).  Also, consider naming
    the boxes on the left hand side as "host-a1.example.com" and
    "host-a2.example.com".

6) Section 4 says that "The originator places their alias in the
Via header field value (in the sent-by production)."
Pedantically speaking the "alias" is not in the sent-by
production rule but rather in the via-parms, as Section 4.2
accurately reflects.

7) Is it okay to use 10.0.0.0 addresses as examples?  I
have learned that as per rfc3330, the 192.0.2.0/24 is what we
should be using in documentation and example code.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Ph.D.  vkg@{lucent.com,research.bell-labs.com,acm.org}
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216
_______________________________________________
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: "Brett Tate" <[email-masked]>
Date: Mon, 14 Nov 2005 13:45:56 -0500

> Let's start by putting Brett's three questions "on the plate" 
> and noting that WGLC isn't over until they're resolved.
> 
> 
> See:
> 
> http://www1.ietf.org/mail-archive/web/sip/current/msg12069.html
> http://www1.ietf.org/mail-archive/web/sip/current/msg12077.html
> http://www1.ietf.org/mail-archive/web/sip/current/msg12106.html
> 

The IETF 64 SIP agenda mentioned that the reuse draft was to be discussed.
I wish that I could have attended.  And I am anxiously awaiting the
preliminary minutes and slides. :)

If the discussion included resolutions for the linked questions, would
someone please post (or send me) the answers to the questions.

Thanks in advance,
Brett

---

From: Dean Willis <[email-masked]>
Date: Mon, 14 Nov 2005 15:35:29 -0600

> someone please post (or send me) the answers to the questions.

Rough notes are already posted on the softarmor site.

Connection reuse got deprecated from the agenda due to a flair-up of  
the higher-priority GRUU.

Rohan recapped the status as follows:

===
 From Scott's rough notes,

Rohan Mahy - Connection Reuse

       Rohan has received a number of mutually conflicting suggestions
       on how to address problems.  Since a quorum of those making the
       suggestions are not available here now, it will be taken to the
       list.

       Cullen Jennings - what is the timetable to resolve them?

       RM - will do work with the goal of completing it before the next
       IETF.
===

I also had several people ask if we still really need this draft.

Do we?

--
Dean

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 14 Nov 2005 20:04:01 -0800

Hi Brett,

We didn't discuss connection reuse.  Looking over the comments I 
received, we would need you and Jeroen to have a reasonable discussion, 
so I yielded the time so we could discuss GRUU.  I'd like to schedule 
some time on the phone to talk about the connect reuse draft and how to 
fix it.

thanks,
-rohan

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 16 Nov 2005 12:49:37 +0100

Just to share the 2 comments I sent:

1 - about the fact that TLS is a MUST
>
>Dean announced IETF LC for your draft on connection reuse, which reminded 
>me of a comment I had to share:
>The draft states "SIP Proxy Servers which implement this mechanism MUST 
>implement TLS mutual authentication, and MUST follow the authorization 
>rules described in Section 4.1.1.". Basically this implies that a server 
>MUST ignore an alias parameter on a Via with a non-TLS transport. This 
>(intentionally I assume) limits the >applicability of the mechanism to 
>infrastructures with a PKI in place

>I imagine that people will also want to use this for plain TCP, for the 
>performance benefit. The draft effectively disallows this. Would it be an 
>idea to specify that - in addition to the TLS mutual authentication, which 
>is RECOMMENDED - it is also possible to use the mechanism with TCP, 
>provided that the TCP connection comes from a trusted host? e.g. the proxy 
>maintains a list of trusted IP addresses, within a private network which 
>has some defence against spoofing.

>In other words, I feel that "the connection sharing mechanism SHOULD work 
>for all connection-oriented transports" is also a requirement to consider.

with a possible extension:

1) What if you allow alias if the request contains a challenge response that
the server / proxy can verify to come from an authorised user?
2) Same with S/MIME bodies?

2 - about ephemereal ports in Via headers
>I have a short question on 
>http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-04.txt 
>section 4:
>The given example is:
>Assuming the Via header field value shown below from the most recent
>   request arrived over a connection from 10.54.32.1 port 8241:

>   Via: SIP/2.0/TLS 10.54.32.1:5061;branch=z9hG4bKa7c8dze ;alias>In this 
> scenario, my stack would have used '8241' as the port in the Via sent-by 
> value. >Is there something wrong with that?(Rohan's answer: Its actually 
> better to put the real port in sent-by, so you are doing nothing wrong. 
> Unfortunately a lot of SIP stacks don't/can't do this.)

Jeroen

----- Original Message ----- 
From: "Rohan Mahy" <[email-masked]>
To: "Brett Tate" <[email-masked]>
Cc: <[email-masked]>; "Rohan Mahy" <[email-masked]>
Sent: Tuesday, November 15, 2005 5:04 AM
Subject: Re: [Sip] WGLC for draft-ietf-sip-connect-reuse-04.txt

> Hi Brett,
>
> We didn't discuss connection reuse.  Looking over the comments I received, 
> we would need you and Jeroen to have a reasonable discussion, so I yielded 
> the time so we could discuss GRUU.  I'd like to schedule some time on the 
> phone to talk about the connect reuse draft and how to fix it.
>
> thanks,
> -rohan
>
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 16 Nov 2005 08:52:23 -0600

> some time on the phone to talk about the connect reuse draft and how to 

Rohan:

Conference me in on the phone call as well.

I had posted some comments on connect-reuse (see
http://www1.ietf.org/mail-archive/web/sip/current/msg12373.html).
I am more interested in your thoughts on the interaction of
"alias" and DNS discussed in that email.

Thanks,

- vijay

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 16 Nov 2005 15:46:53 -0500

> 2) In Section 4, where the interaction of DNS and "alias" 
> is described, I believe that the use of "alias" leads to 
> starvation of other servers in a proxy farm since we have 
> established an affinity with a particular server.  
> Let me explain.
> 
> If within the Priority field of SRV RRs, the Weight fields 
> are the same (as is the example), then there will arise a 
> situation where the "alias" parameter will lead to the 
> starvation of other servers in a proxy farm.  Under normal 
> circumstances, since the Weight field of the SRV RRs is the 
> same, traffic should be distributed equally.  If instead, 
> because of the "alias" parameter, we do not use SRV, then 
> only one host from the proxy farm gets bombasted with *all* 
> the traffic, effectively inhibiting load distribution 
> through SRV.
> 

My current understanding/assumption is that the sender would loadbalance
across the opened connections for the alias.  Thus each cluster member could
establish a connection and keep it open to remain one of the choices for the
alias.  However it is definitely a problem when SRV would have indicated
different priority levels (or weights).

I think that this problem (and many of the questions I posted in prior
emails) arise from section 3 requirement 2.  Is requirement 2 really a
mandatory requirement for the reuse draft?

If not, requirement 2 potentially could be removed and placed into a
separate draft.  The draft could provide a more complete solution concerning
how to overlay the benefits of SRV priority and weights with the desired
number of connections between 2 devices, between a device and cluster, and
between 2 clusters.  It potentially could also define a mechanism to know
when to skip even trying to open a new connection towards a particular
device or cluster.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 16 Nov 2005 15:06:03 -0600

Brett Tate wrote:
> My current understanding/assumption is that the sender would 
> loadbalance across the opened connections for the alias.  Thus each 
> cluster member could establish a connection and keep it open to 
> remain one of the choices for the alias.

Over time, this will cause an aliased connection to be established
across all servers in a cluster.  The disadvantage is that this
forces the sender talking to the cluster to keep multiple
connections open, thereby defeating the purpose having a single
connection.

However, this is one way to solve it.  If we agree, then we
ought to mention this in the draft.

> However it is definitely a problem when SRV would have indicated

Yes, different priority levels are a problem anyway ... but I
think that the problem even occurs across the same priority
level as I indicated.  The solution for different priority/
weights would essentially be the same, namely open multiple
connections.

> I think that this problem (and many of the questions I posted in 
> prior emails) arise from section 3 requirement 2.  Is requirement 2 
> really a mandatory requirement for the reuse draft?

Hmmm ... interesting.  Maybe something to discuss during the
phone call.

Rohan, Brett, Jeroene: I can get a bridge if that will help.
We can have a private email exchange to work out the time and
other logistics.

> separate draft.  The draft could provide a more complete solution 
> concerning how to overlay the benefits of SRV priority and weights 
> with the desired number of connections between 2 devices, between a 
> device and cluster, and between 2 clusters.  It potentially could 
> also define a mechanism to know when to skip even trying to open a 
> new connection towards a particular device or cluster.

Thanks,

- vijay