Subject: RE: (NAT) RSIP over TCP stream

From: "Tang, Tom J" <[email-masked]>
Date: Mon, 1 Nov 1999 14:40:25 -0800

Mike :

    I do not think that the protocol should remain
  unchanged at this point.  There are still issues 
  that need to be addressed, like multicast traffic.
  In a home network, the RSIP server would need to 
  be multicast aware, unless I am totally mistaken.
  This was mentioned in the RSIP framework as an issue
  also (Page 22, To Do).  

Tom J. Tang                      Telephone : (503) 712-1791
Network Software Engineer        Office Fax : (503) 264-3843
Intel Architecture Labs          Email : [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 01, 1999 1:51 PM
To: Saint-Hilaire, Ylian
Cc: [email-masked]'
Subject: RE: (NAT) RSIP over TCP stream

This speaks to an even larger issue: should RSIP recommend TCP or UDP?
In different environments, their are advantages and disadvantages to each.
In the initial (smaller scale) deployments of RSIP, I suspect that TCP would
be
the most
useful, while later (larger scale) deployments may require the low overhead
of
UDP.

If we can pick one or the other and just go with it, that would simplify
things
greatly.
Discussion?  TCP, UDP, or both....

-Mike

"Saint-Hilaire, Ylian" <[email-masked]> on 11/01/99 03:34:54
PM

Sent by:  "Saint-Hilaire, Ylian" <[email-masked]>

To:   Mike Borella/MW/US/3Com, "Saint-Hilaire, Ylian"
      <[email-masked]>
cc:   "'nat @livingston.com'" <[email-masked]>
Subject:  RE: (NAT) RSIP over TCP stream

TCP is a stream based protocol, with or without fragmentation, we need a way
to break up the RSIP messages inside the stream. If you send small messages
(under path MTU) you never see the problem since a single "socket read" will
get the entire message, but if the message is larger it is not possible to
know where it ends. You should never make a single read off a TCP socket and
expect the same behavior as UDP.

I think we need a size field or a separator of some kind if we want to keep
using RSIP over TCP.

Ylian Saint-Hilaire
Intel - Communication Architecture Labs

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 01, 1999 12:22 PM
To: Saint-Hilaire, Ylian
Cc: [email-masked]'
Subject: Re: (NAT) RSIP over TCP stream

I really can't imagine RSIP packets getting fragmented and would
like to avoid any significant (or insiginificant) modifications to the RSIP
protocol at this point.  Is there any WG consensus on this issue?

-Mike

"Saint-Hilaire, Ylian" <[email-masked]> on 10/21/99 04:46:49
PM

Please respond to "Saint-Hilaire, Ylian" <[email-masked]>

Sent by:  "Saint-Hilaire, Ylian" <[email-masked]>

To:   "'nat @livingston.com'" <[email-masked]>
cc:    (Mike Borella/MW/US/3Com)
Subject:  (NAT) RSIP over TCP stream

Comment on the RSIP-PROTO-02 draft:

Since TCP is a streams based protocol, when using RSIP over TCP (control
channel) we need a way to delimit the start and end of each RSIP message.
The new draft supports an arbitrary number of options but there is not
indication on the number of options or the size of the message.
Consequently, an RSIP client could retrieve a message and not get one or
more optional parameters. A fix would be to place a message size field in
front of each RSIP message when using RSIP over TCP. Any feedback?

Ylian Saint-Hilaire
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 2 Nov 1999 22:00:54 -0800

>  be multicast aware, unless I am totally mistaken.
  
Actually, the -03 draft should work fine for a host sending to a
multicast destination; RSIP already provides for making sure that
RTP/RTCP packets will have the correct source address and ports. 

As for receiving multicast, the IGMP proxy specified in 
draft-fenner-igmp-proxy-01.txt should work fine for this;
no need to RSIP to duplicate that functionality. BTW,
SOCKS multicast functionality got a chilly reception when
reviewed in MBONED a while back (see RFC 2588 for details).
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.