Re: [pilc] interoperability issue with TCP PEP

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 04 August 2004 23:11 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 TAA18060 for <pilc-archive@lists.ietf.org>; Wed, 4 Aug 2004 19:11:13 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsUrC-0005ln-Bu; Wed, 04 Aug 2004 19:07:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsUjS-0004bE-Tr for pilc@megatron.ietf.org; Wed, 04 Aug 2004 18:59:41 -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 SAA17500 for <pilc@ietf.org>; Wed, 4 Aug 2004 18:59:35 -0400 (EDT)
Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsUmp-00027r-QE for pilc@ietf.org; Wed, 04 Aug 2004 19:03:08 -0400
Received: from [130.129.129.23] (opene-130-129-129-23.ietf60.ietf.org [130.129.129.23]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.11/8.12.11) with ESMTP id i74Mgl1G019688 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Wed, 4 Aug 2004 23:42:52 +0100 (BST)
User-Agent: Microsoft-Entourage/11.0.0.040405
Date: Wed, 04 Aug 2004 15:42:43 -0700
Subject: Re: [pilc] interoperability issue with TCP PEP
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
To: ipdvb@erg.abdn.ac.uk, lakshmips@future.futsoft.com
Message-ID: <BD36B473.D47%gorry@erg.abdn.ac.uk>
In-Reply-To: <410DB583.9090004@hns.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-ERG-MailScanner: Found to be clean
X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk
X-ERG-MailScanner-To: ip-dvb@erg.abdn.ac.uk, ipdvb@erg.abdn.ac.uk, lakshmips@future.futsoft.com, pilc@ietf.org, sis-scps-interest@mailman.ccsds.org
X-Spam-Score: 0.2 (/)
X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57
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

My take on this was the general story is that there have been a series of
meetings organised to understand the issues in producing inter-operable
PEPs, and the related issues of where NAT, IPSEC, etc are used and their
relation to DVB-RCS network scenarios.
 
SatLabs are considering a phased approach, looking for a short-term solution
providing basic PEP functions appropriate to some scenarios for DVB-RCS
(focussed on web browsing). They may also consider a more complete and
powerful long-term solution. Initial effort will probably be focussed on the
short term, looking at:

 - TCP with a split to a modified TCP transport layer (SCPS?)
 - a very light session layer if required to configure the two end points
 - optional web pre-fetching mechanisms in the application layer
 
I believe the result of their last meeting was that this work is to progress
in the months ahead.

Perhaps a member of Satlabs can give a more authorative status report?

Gorry
(speaking on behalf of no-one in particular)

-----------
On 1/8/04 8:31 pm, "John Border" <border@hns.com> wrote:

> 
> 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/
>>  
>> 
> 
Looks good to me.  I would add an "optional"  before the "web
prefetching".  I am not sure how much to say on timing or
actual outcome.

Cheers,
Joerg

Gorry Fairhurst wrote:

> See if you like this - or not, and I'll post it.
> 
> Gorry
> 
> ------
> 
> My take on this was the general story is that there have been a series of
> meetings organised to understand the issues in producing inter-operable
> PEPs, and the related issues of where NAT, IPSEC, etc are used and their
> relation to DVB-RCS network scenarios.
> 
> SatLabs are considering a phased approach, looking for a short-term solution
> providing basic PEP functions appropriate to some scenarios for DVB-RCS
> (focussed on web browsing). They may also consider a more complete and
> powerful long-term solution. Initial effort will probably be focussed on the
> short term, looking at:
> 
> - TCP with a split to a modified TCP transport layer (SCPS?)
> - a very light session layer if required to configure the two end points
> - web pre-fetching mechanisms in the application layer
> 
> I believe the result of their last meeting was that this work is to progress
> in the months ahead.
> 
> Perhaps a member of Satlabs can give a more authorative status report?
> 
> Gorry
> (speaking on behalf of no-one in particular)
> 
> On 1/8/04 8:31 pm, "John Border" <border@hns.com> wrote:
> 
> 
>>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/