Re: [pilc] tcppep
John Border <border@hns.com> Wed, 03 March 2004 18:55 UTC
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17388 for <pilc-archive@lists.ietf.org>; Wed, 3 Mar 2004 13:55:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AybWJ-00077k-68; Wed, 03 Mar 2004 13:55:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AybW0-00076t-8y for pilc@optimus.ietf.org; Wed, 03 Mar 2004 13:54:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17297 for <pilc@ietf.org>; Wed, 3 Mar 2004 13:54:42 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AybVy-00030E-00 for pilc@ietf.org; Wed, 03 Mar 2004 13:54:42 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AybU1-0002di-00 for pilc@ietf.org; Wed, 03 Mar 2004 13:52:42 -0500
Received: from hnse2.hns.com ([208.236.67.201]) by ietf-mx with esmtp (Exim 4.12) id 1AybTI-0002NS-00 for pilc@ietf.org; Wed, 03 Mar 2004 13:51:56 -0500
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 i23IlvWR025403; Wed, 3 Mar 2004 13:47:58 -0500 (EST)
Received: from hns.com (altasun9.md.hnsnet [10.48.51.25]) by excore8.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id i23Ilwst008185; Wed, 3 Mar 2004 13:47:59 -0500 (EST)
Message-ID: <4046285E.585B6274@hns.com>
Date: Wed, 03 Mar 2004 13:47:58 -0500
From: John Border <border@hns.com>
X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: lakshmips@future.futsoft.com
CC: pilc@ietf.org
Subject: Re: [pilc] tcppep
References: <001001c400d8$5cb1ab20$4703080a@future.futsoft.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: pilc-admin@ietf.org
Errors-To: pilc-admin@ietf.org
X-BeenThere: pilc@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pilc>, <mailto:pilc-request@ietf.org?subject=unsubscribe>
List-Id: Performance Implications of Link Characteristics IETF Working Group <pilc.ietf.org>
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>
Content-Transfer-Encoding: 7bit
A purist would say that even encapsulating the original header alters the end to end semantics. Even most non-purists would agree that changing the original header alters the end to end semantics. I happen to agree with the purists. So,... I think the question should be does it alter any of the end to end semantics that matter? And, the answer to that question depends on context. In many environments, I think it doesn't matter. In our case, we are very up front with our customers re the fact that we "spoof" TCP connections when carrying them across the satellite link... I am unaware of any public documents other than RFC 3135 and marketing literature from various companies. But, that doesn't mean it doesn't exist... John Lakshmi Priya wrote: > > hi, > > RFC3135 for PEP states that "In a split connection we can encapsulate > the tcp packets over satlink. These tcp packets are decapsulated at > the other end of the satlink and transmitted to the end host." > > Will it be necessary to encapsulate the entire packet along with the TCP and > IP headers to maintain end to end semantics? > In such a case wouldnt it be an overhead to manupulate the send buffers on > the satellite tcp as segments(since we retain the headers) rather than > bytes. > Any documents suggesting techniques for pep encapsulation? > > thanks, > lp > > *************************************************************************** > 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] tcppep Lakshmi Priya
- Re: [pilc] tcppep John Border
- RE: [pilc] tcppep Lakshmi Priya
- Re: [pilc] tcppep Joe Touch
- [pilc] interoperability issue with TCP PEP Lakshmi Priya
- RE: [pilc] interoperability issue with TCP PEP Keith L. Scott
- Re: [pilc] interoperability issue with TCP PEP John Border
- RE: [pilc] interoperability issue with TCP PEP Lakshmi Priya
- Re: [pilc] interoperability issue with TCP PEP Gorry Fairhurst