List Info

Thread: connect-reuse-08: Terminology for "Connection Sharing" and "Connection Reuse"




connect-reuse-08: Terminology for "Connection Sharing" and "Connection Reuse"
country flaguser name
United States
2007-12-13 16:51:01
Hi: During the WGLC review of connect-reuse-08, I received
a
private email requesting that the document contain
explanation
of terms being used.  To quote the email:

   > A connection is established, and two things can
happen....
   >
   > 1. One end sends multiple messages over the same
connection
   > for multiple sessions, where these sessions are
sequential.
   > Example: A sends INVITE to B, and all dialog
messages for the
   > call sessions traverse the same TCP connection until
the BYE
   > and 200 OK BYE is completed, at which time the
connection
   > is not torn down but remains up and a subsequent
INVITE session
   > is then initiated over the same connection. We had
been
   > calling this TCP Connection Reuse.
   >
   > 2. One end sends multiple messages over the same
connection
   > for multiple simultaneous sessions. Example: A sends
INVITE to
   > B for one call session and then sends another INVITE
to B for
   > another call session and so on. Each session is
maintained in
   > parallel with the others, and all dialog messages
for all
   > sessions traverse the same TCP connection until the
BYE and
   > 200 OK BYE is completed for each session. We had
been calling
   > this TCP Connection Sharing.
   >
   > These are not just our usages of the terms, but are
also being
   > used by our customers as well.

Note that there are existing techniques in SIP to
disambiguate
multiple dialogs/sessions arriving on the same TCP stream. 
So the
difference between connection reuse and connection sharing
is not
tied to whether the sessions are sequential or not.  Rather,
the
difference is whether or not the connection can be used to
send
requests in the backwards direction.  More specifically,

Connection Reuse: The process of using the same connection
to send
  new requests in the backwards direction (i.e., A opens a
connection
  to B to send requests, and B uses the same connection to
send
  new requests to A.)

Connection sharing: The process of using the same connection
to send
  multiple requests on the same connection (and of course,
receive
  multiple responses over the connection.)  A shared
connection will
  not be reused for requests in the backwards direction.

Comments?  Thoughts?  Suggestions?  Other terms to
document?

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.al
catel-lucent.com/bell-labs


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Re: connect-reuse-08: Terminology for "Connection Sharing" and "Connection Reuse"
user name
2007-12-14 14:04:37
   From: "Vijay K. Gurbani" <vkgalcatel-lucent.com>

   Connection Reuse: The process of using the same
connection to send
     new requests in the backwards direction (i.e., A opens
a connection
     to B to send requests, and B uses the same connection
to send
     new requests to A.)

   Connection sharing: The process of using the same
connection to send
     multiple requests on the same connection (and of
course, receive
     multiple responses over the connection.)  A shared
connection will
     not be reused for requests in the backwards direction.

   Comments?  Thoughts?  Suggestions?  Other terms to
document?

This is good, but I'd replace the sentence "A shared
connection will
not..." with "Connection sharing does not imply
connection reuse."
Once you get that straightened out, you can say "TCP
connections are
shared by default, but should not be reused except when the
recipient
has some way to authenticate the source."  If
"shared" *excludes*
"reused", that straightforward statment requires
awkward
circumlocutions.


Dale


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Re: connect-reuse-08: Terminology for "Connection Sharing" and "Connection Reuse"
country flaguser name
United States
2007-12-14 14:39:46
Dale.Worleycomcast.net wrote:
>    From: "Vijay K. Gurbani" <vkgalcatel-lucent.com>
> 
>    Connection Reuse: The process of using the same
connection to send
>      new requests in the backwards direction (i.e., A
opens a connection
>      to B to send requests, and B uses the same
connection to send
>      new requests to A.)
> 
>    Connection sharing: The process of using the same
connection to send
>      multiple requests on the same connection (and of
course, receive
>      multiple responses over the connection.)  A shared
connection will
>      not be reused for requests in the backwards
direction.
> 
>    Comments?  Thoughts?  Suggestions?  Other terms to
document?
> 
> This is good, but I'd replace the sentence "A
shared connection will
> not..." with "Connection sharing does not
imply connection reuse."

Perfect; I'll make the change.  Thanks, Dale.

> Once you get that straightened out, you can say
"TCP connections are
> shared by default, but should not be reused except when
the recipient
> has some way to authenticate the source."  

I will say something to the following effect:

   ... Connection sharing does not imply connection reuse
except
   when the recipient has some assurance of the authenticity
of
   the source.

Since this text that defines these terms will go in the
beginning
of the draft (probably in the terminology section), I will
leave
out the details of which connections can be shared by
default (like
TLS) and which ones (like TCP) should only be shared under
certain
circumstances.  The reader will, in time, read the relevant
sections
and arrive at the requisite conclusion.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.al
catel-lucent.com/bell-labs


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

[1-3]

about | contact  Other archives ( Real Estate discussion Medical topics )