Subject: RE: (NAT) RSIP over TCP stream

From: "Saint-Hilaire, Ylian" <[email-masked]>
Date: Mon, 1 Nov 1999 13:34:54 -0800

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.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Nov 1999 07:47:00 -0400

>>>>> "Saint-Hilaire" == Saint-Hilaire, Ylian <[email-masked]> writes:

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

  Even if you are sending small messages, buffering or window considerations
may cause the stream to be split. Put the length in for TCP.

] Train travel features AC outlets with no take-off restrictions|  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.