Subject: [Sip] Comments for connect-reuse-06

From: Benny Prijono <[email-masked]>
Date: Wed, 23 Aug 2006 23:05:40 +0100

Hi Vijay,

I also want to share my comments after reading the connect-reuse-6 
draft. This is the first time I read the document and involved in the 
discussion, so please bear with me if what I'm saying doesn't make any 
sense.

My .02p below.

- Alias table
   I understand that servers need to maintain the aliased transports in 
the alias table; this is the basic operation for connect-reuse. But what 
I don't understand is, why clients MUST add (aliased) outgoing 
connection to the alias table. Isn't it sufficient to just put the 
transport into the "normal" transport table?

- Server handling multiple alias
   I think it's important to define actions to be taken by servers when 
receiving multiple incoming connections that resolve to the same alias 
entry. I can think of several options:
   1. delete old alias with new alias, and gracefully close old
      connection, or
   2. reject the new connection, or
   3. load balance the connections, or
   4. please contact administrator (my favorite)

- Page 7:  "When the server, P2, receives the request, it may add a
             "received" parameter to the topmost Via..."
   In the context of Via header being discussed, I think the server 
*will* (or MUST) add "received" parameter to the topmost Via, since the 
Via sent-by is not an IP address.

- Page 10:
   "Clients must be prepared for the case that the connection no longer
    exists when they are ready to send a subsequent request over it.
    This may happen if the peer ran out of operating system resources and
    had to close the connection."

   This sounds like servers only close connection on an exceptional 
conditions, and certainly is not the case. If the server doesn't honor 
the "alias" request, or if it doesn't support it, then the connection 
will be closed normally as per RFC 3261 procedure.

- Page 13: (nit)
   "Once the malware program decides that a legitimate user agent is not
    running, it sends sends.."
   (note the double sends)

My 0.2p.

-benny

_______________________________________________
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: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 24 Aug 2006 11:24:15 -0500

> discussion, so please bear with me if what I'm saying doesn't make any 

Benny: Thank you for your time and willingness to read the document.
More inline.

> transport into the "normal" transport table?

Sure; if you already have one.

>   4. please contact administrator (my favorite)

I'd actually like to hear some more views on this.  Some folks
have suggested (3), which is on the complex end of the spectrum
(how many connections is enough?  What is the load balancing
scheme? etc.)  (1) and (2) are possibly good candidates as well.
(4) is out of the question, I think.

What do folks think?

> Via sent-by is not an IP address.

Right ... that's a rfc3261 stipulation, and no need to hedge around
it.  I re-worded the paragraph to now read:

   <t>When the server, P2, receives the request, it examines the
   topmost Via to determine whether P1 supports aliased connections.
   The Via at P2 now looks like (the "received" parameter is added
   by P2):</t>

   <figure><artwork><![CDATA[
   Via: SIP/2.0/TLS p1.example.com;branch=z9hG4bKa7c8dze;alias;
   received=192.0.2.1
   ]]></artwork></figure>

> will be closed normally as per RFC 3261 procedure.

True ... but the text you quote is referring to the fact that the
client had previously established an aliased connection, but much
later it got reclaimed.  I think the paragraph right before the
one you quote contains the gist of your comment above.

>    running, it sends sends.."

Fixed.

Thanks a bunch for your time on this.

Ciao.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)

---

From: Benny Prijono <[email-masked]>
Date: Thu, 24 Aug 2006 19:40:35 +0100

Hi Vijay,

thanks for the reply. More below.

Vijay K. Gurbani wrote:
>> the alias table; this is the basic operation for connect-reuse. But 
>> what I don't understand is, why clients MUST add (aliased) outgoing 

Sorry I don't get you, which one? Transport table? Alias table? Or are 
they basically the same thing? So what is alias table?

I think my confusion was caused from reading page 6 (in the bottom) that 
says:

  "To aid in connection reuse, a new data structure, the connection
   alias table (or simply, alias table) is defined in this document
   and is used to store the resolved addresses."

As implementor, I'm quite familiar with the term transport table (or 
transport hash table, transport map, etc.), because this is a logical 
consequences of having transport layer in a SIP stack. So reading the 
paragraph, I thought the document suggests that a new table should be 
created. Since I suspect this isn't the case, perhaps we can change the 
wordings to something like:

  "To aid the discussion of connection reuse, this document defines
   a data structure called connection alias table (or simply, alias
   table) which is used to store aliased addresses. User agent can.."

> (4) is out of the question, I think.

I'll let others comment on this.

>> *will* (or MUST) add "received" parameter to the topmost Via, since 
>> the Via sent-by is not an IP address.
> 

Perfect.

> one you quote contains the gist of your comment above.

No, there's nothing there that says "much later", and even if there was, 
it wouldn't make any difference. I would suggest that we just delete the

  "This may happen if the peer ran out of operating system resources and 
had to close the connection"

bit, since the previous paragraph has made it clear that connection 
(aliased or not) may be closed by server anyway.

thanks,
-benny

---

From: Benny Prijono <[email-masked]>
Date: Thu, 24 Aug 2006 23:15:23 +0100

Vijay K. Gurbani wrote:
> How about this: I modify the paragraph in question as follows:
> 
> OLD:
>    Clients must be prepared for the case that the connection no longer
>    had to close the connection.
> 
> NEW:
>    Once an alias has been established, clients must be prepared
>    for the case that the connection no longer exists when they
>    are ready to send a subsequent request over it.  

I don't have any problem with this part, and in fact, the old sentence 
is okay too (if not better).

>    This could happen if the server ran out of operating system resources and
>    had to reclaim the connection.
> 

Now, this is the part of the paragraph that I'm protesting against. If 
you want to explain why connection is closed in the client side, then I 
believe the complete sentence should look like this:

      This could happen if server does not support connection reuse, or
      when the server decides that it doesn't want to honor connection
      reuse request (perhaps because there is already an alias that
      resolves to the same client), or when the server decides to drop
      the connection (perhaps because it receives another connection
      that resolves to the same client), or because it runs out of
      operating system resources.

So either we put the complete sentence like that, or we just delete the 
sentence altogether. I was proposing that we just delete it, since the 
behavior has been explained elsewhere.

Of course I might just be missing something here.

-benny

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 25 Aug 2006 09:37:30 -0500

> behavior has been explained elsewhere.

Benny:

OK, how about deleting it for the reason you list.  So the text
will look like:

OLD:
    Clients must be prepared for the case that the connection no longer
    exists when they are ready to send a subsequent request over it.
    This may happen if the peer ran out of operating system resources and
    had to close the connection.  In such a case, a new connection MUST
    be opened to the resolved address and the alias table updated
    accordingly.

NEW:
    Once an alias has been established, clients must be prepared
    for the case that the connection no longer exists when they
    are ready to send a subsequent request over it.  In such a case,
    a new connection MUST be opened to the resolved address and the
    alias table updated accordingly.

I actually like the "Once an alias has been established" phrase.
It provides some context that goes a bit beyond the paragraph
that preceeds it.

Thanks.

- vijay

---

From: Benny Prijono <[email-masked]>
Date: Fri, 25 Aug 2006 18:21:45 +0100

>    alias table updated accordingly.

Looks good.

> It provides some context that goes a bit beyond the paragraph

I think I don't quite like it. Unless I misunderstood something, I don't 
think client has any indication that "an alias has been established". So 
because of this, client can never say that; it can only say that a 
connection has been established.

-benny