[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pilc] 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" <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/
>>>
>>>
>>
>
>