Re: [pilc] interoperability issue with TCP PEP

John Border <border@hns.com> Mon, 02 August 2004 03:43 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26047 for <pilc-archive@lists.ietf.org>; Sun, 1 Aug 2004 23:43:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrTda-0006Fw-1y; Sun, 01 Aug 2004 23:37:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BrTYu-0003ou-3j for pilc@megatron.ietf.org; Sun, 01 Aug 2004 23:32:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25511 for <pilc@ietf.org>; Sun, 1 Aug 2004 23:32:29 -0400 (EDT)
Received: from hnse2.hns.com ([208.236.67.201]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BrTbd-00066O-Ap for pilc@ietf.org; Sun, 01 Aug 2004 23:35:24 -0400
Received: from excore8.hns.com (excore8.hns.com [139.85.52.126]) by hnse2.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id i723VV3C028436 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 1 Aug 2004 23:31:31 -0400 (EDT)
Received: from hns.com (rasnvpn53.hns.com [139.85.221.136]) by excore8.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id i723VGQg004345; Sun, 1 Aug 2004 23:31:19 -0400 (EDT)
Message-ID: <410DB583.9090004@hns.com>
Date: Sun, 01 Aug 2004 23:31:15 -0400
From: John Border <border@hns.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: lakshmips@future.futsoft.com
Subject: Re: [pilc] interoperability issue with TCP PEP
References: <0I1K00FKJJPZTK@mailsrv2a.mitre.org>
In-Reply-To: <0I1K00FKJJPZTK@mailsrv2a.mitre.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Filtered: Sendmail Attachment Filter v2.6.0 hnse2.hns.com i723VV3C028436
X-AntiVirus: Sendmail Anti-Virus Filter hnse2.hns.com 4.3.20 4382 i723VV3C028436
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8
Content-Transfer-Encoding: 7bit
Cc: sis-scps-interest@mailman.ccsds.org, ip-dvb@erg.abdn.ac.uk, pilc@ietf.org
X-BeenThere: pilc@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Performance Implications of Link Characteristics IETF Working Group <pilc.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pilc>, <mailto:pilc-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pilc@ietf.org>
List-Help: <mailto:pilc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pilc>, <mailto:pilc-request@ietf.org?subject=subscribe>
Sender: pilc-bounces@ietf.org
Errors-To: pilc-bounces@ietf.org
Content-Transfer-Encoding: 7bit

DVB-RCS, via SatLabs, is currently looking into standardizing a minimum 
interoperable PEP.  Not sure of the current status of the effort...

Keith L. Scott wrote:

>Lakshmi,
>
>It is entirely possible for PEPs made by different vendors to interoperate,
>provided the vendors implement a common standard; and yes, there _is_ a
>standard for how the information is carried across the satellite link.
>
>The Space Communications Protocol Standards: Transport Protocol (SCPS-TP,
>also sometimes referred to as TCP tranquility) defines a set of TCP options
>that can improve TCP performance in stressed environments, including
>satellite communications.  PEP products that implement these options are
>available from a number of vendors, and should interoperate if they all
>conform to the specification.  There is also a freely available reference
>implementation of the SCPS protocols that includes a PEP application that is
>available by sending mail to the point of contact listed at
>http://www.scps.org.
>
>Tranquility is completely backward-compatible with other TCP
>implementations; all of the Tranquility-specific functionality is negotiated
>during the SYN exchange.  By using different settings for the terrestrial
>and satcom sides of the PEPs, they can dramatically improve performance over
>the satcom link.  There is currently no implementation that I know of that
>does private, out-of-band signaling between the PEPs, though I can envision
>uses for such signaling.
>
>I'd be happy to answer any other questions you have or to point you at some
>vendors.
>
>The SCPS-TP protocol spec is available from
>http://www.ccsds.org/CCSDS/documents/714x0b1.pdf
>
>Best regards,
>
>		--keith
>
>
>
>
>  
>
>>-----Original Message-----
>>From: pilc-bounces@ietf.org [mailto:pilc-bounces@ietf.org] On 
>>Behalf Of Lakshmi Priya
>>Sent: Wednesday, July 28, 2004 7:42 AM
>>To: pilc@ietf.org
>>Subject: [pilc] interoperability issue with TCP PEP
>>
>>
>>hi,
>>
>>    Would it be possible to implement PEP such that it is 
>>interoperable
>>with other PEP implementations?
>>That is, in a split connection, is it possible to have 2 
>>different vendor
>>implementations running on either end of satellite link PEP 
>>nodes? Are there
>>any such implementations?
>>
>>    Since there are no standards to the way in which the end host
>>information is carried over the satlink after spoofing, I 
>>guess this would
>>not be possible. There could also exist many other proprietary control
>>packets. Any inputs in this regard is welcome.
>>
>>thanks and regards,
>>Lakshmi Priya
>>
>>
>>
>>***************************************************************
>>************
>>This message is proprietary to Future Software Limited (FSL)
>>and is intended solely for the use of the individual to whom it
>>is addressed. It may contain  privileged or confidential information
>>and should not be circulated or used for any purpose other than for
>>what it is intended.
>>
>>If you have received this message in error, please notify the
>>originator immediately. If you are not the intended recipient,
>>you are notified that you are strictly prohibited from using,
>>copying, altering, or disclosing the contents of this message.
>>FSL accepts no responsibility for loss or damage arising from
>>the use of the information transmitted by this email including
>>damage from virus.
>>***************************************************************
>>************
>>
>>
>>_______________________________________________
>>pilc mailing list
>>pilc@ietf.org
>>https://www1.ietf.org/mailman/listinfo/pilc
>>http://www.ietf.org/html.charters/pilc-charter.html
>>http://pilc.grc.nasa.gov/
>>
>>    
>>
>
>
>_______________________________________________
>pilc mailing list
>pilc@ietf.org
>https://www1.ietf.org/mailman/listinfo/pilc
>http://www.ietf.org/html.charters/pilc-charter.html
>http://pilc.grc.nasa.gov/
>  
>


_______________________________________________
pilc mailing list
pilc@ietf.org
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/