Re: interoperability issue with TCP PEP

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" <[email protected]> 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: [email protected] [mailto:[email protected]] On
>>> Behalf Of Lakshmi Priya
>>> Sent: Wednesday, July 28, 2004 7:42 AM
>>> To: [email protected]
>>> 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
>>> [email protected]
>>> https://www1.ietf.org/mailman/listinfo/pilc
>>> http://www.ietf.org/html.charters/pilc-charter.html
>>> http://pilc.grc.nasa.gov/
>>> 
>>>    
>>> 
>> 
>> 
>> _______________________________________________
>> pilc mailing list
>> [email protected]
>> 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" <[email protected]> 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: [email protected] [mailto:[email protected]] On
>>>>Behalf Of Lakshmi Priya
>>>>Sent: Wednesday, July 28, 2004 7:42 AM
>>>>To: [email protected]
>>>>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
>>>>[email protected]
>>>>https://www1.ietf.org/mailman/listinfo/pilc
>>>>http://www.ietf.org/html.charters/pilc-charter.html
>>>>http://pilc.grc.nasa.gov/
>>>>
> 
> 
>>>_______________________________________________
>>>pilc mailing list
>>>[email protected]
>>>https://www1.ietf.org/mailman/listinfo/pilc
>>>http://www.ietf.org/html.charters/pilc-charter.html
>>>http://pilc.grc.nasa.gov/
>>> 
>>>
>>
> 
> 





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