Subject: FW: Notification: Inbound Mail Failure

From: TiscomPostmaster <[email-masked]>
Date: Mon, 22 Feb 1999 08:41:00 -0500

To the listhoulder. Please remove MErnesto from you mail list.
He has been gone for the last 6 months.

> -----Original Message-----
> From:	TiscomPostmaster 
> Sent:	Saturday, February 20, 1999 4:38 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: HTTP performance issues>> 

Subject: RE: HTTP performance issues
From: Barry Raveendran Greene <[email-masked]>
To: [email-masked], Lloyd Wood <[email-masked]>
Cc: Joe Touch <[email-masked]>, [email-masked], [email-masked]
Date: Sat, 20 Feb 1999 16:08:02 -0500

Hello Guy,

> The plan is to us proxies on each remote and one on the VSAT HUB.
>  We are now
> testing Satbooster and Venturi, do you know similar products like this ?

Several people have worked this with Squid. Other WWW Cache products are
doing this as part of a TCP Stack modification or integrated into the
product. For example, we've got the following going into the latest version
of the Cache Engine (2.0):

+ TCP slow start
+ Congestion avoidance
+ Fast retransmit / fast recovery algorithms
+ No delayed-ACK in the TCP establish phase
+ Reduced the initial smooth threshold value to avoid the slow start process
ramp up too quickly to cause network congestion (based on Janey C. Hoe's
work)
+ No re-start the slow start when the connection has been idle
+ Better TCP timers mechanism to cut the TCP timers process times
+ Window scale option (RFC 1323). It can go as high as 1,073,725,440 bytes
(64k x 2 power of 14)
+ SACK/PMTU and Path MTU Discovery will be in version  2.1.

All of this is common sense for a WWW Cache manufacturer - we keep up with
the research, IDs, and RFCs to work the features into make friendlier to
satellite links. Just working through RFC1223 and RFC2488/BCP28 provides a
lot of information.

The parallel step would be to work more of the http 1.1 compliance into the
WWW Cache Software. It's not just http 1.1 persistent connection. For
example, IMS (If-Modified-Sense) also has a role to play in the performance
optimization over a satellite link.

Barry