Subject: FW: Notification: Inbound Mail Failure

From: TiscomPostmaster <[email-masked]>
Date: Thu, 22 Oct 1998 07:08:33 -0400

To who it may concern, please remove
[email-masked] from your mail list

> -----Original Message-----
> From:	TiscomPostmaster 
> Sent:	Wednesday, October 21, 1998 4:18 PM
> To:	TiscomPostmaster
> Subject:	Notification: Inbound Mail Failure 
> 
> The following recipients did not receive the attached mail.  A NDR was not
> sent to the originator for the following recipients for one of the
> following reasons:
> 
> 
> 	* The Delivery Status Notification options did not request failure
> notification, or requested no notification.
> 
>         * The message was of precedence bulk.
> 
> 
> 
> NDR reasons are listed with each recipient, along with the notification
> requested for that recipient,
> or the precedence.
> 
> <[email-masked]> [email-masked]
> 	MSEXCH:IMS:USCG:TISCOM:TISCOMEX 0 (000C05A6) Unknown Recipient
> 	Precedence: bulk
> 
> The message that caused this notification was:
> 
>  <<Re: TCP+RSVP>> 

Subject: Re: TCP+RSVP
From: William D Ivancic <[email-masked]>
To: Tang Oo <[email-masked]>, [email-masked]
Date: Wed, 21 Oct 1998 15:30:44 -0400

At 10:57 AM 10/21/98 +0800, you (Tang Oo) wrote:
>Is anyone working on TCP+RSVP? If a certain number of bandwidth is reserved
>along the connection, what modifications shall be made to TCP slow start
and
>congestion control?
>
>Tang Oo 	Research Engineer
>Network Technology Research Center
>Nanyang Technological University, Singapore
>Tel: 7905362	Fax: 7926894
>
No changes should be made to TCP because of RSVP.  RSVP does not guarantee
bandwidth or quality of service.  

It is my understanding that RSVP will probably not be seen in the wide area
network and that differentiated services (diffserv) and/or a combination of
diffserv and ATM will reside in the WAN with RSVP at the edges.
(clarification and/or corrections to this statement are welcome.)

I you know you have locked up bandwidth (a VERY unique situation), you do
not need to have congestion control. I this case, you may wish to consider
other protocols instead of TCP.   

*********************************************
William D. Ivancic
NASA Lewis Research Center
21000 Brookpark Rd.   MS 54-8
Cleveland, Ohio  44135
USA
Phone:   1 216 433 3494
FAX:     1 216 433 8705
Email:   [email-masked]
         [email-masked]		
*********************************************