RE: tcppep

Thanks John,
  Yes, in either case end to end semantics would be lost. Because, though we
encapsulate the
headers, they would need to be modified at the TCP session on the other end
of satlink,to suit its tcp window, options etc.
May be we can do away with the overhead of constructing new headers in this
case.

But I think it is mandatory to pass at least the host IP address information
(source) for end to end semantics.
Or do some implemetations just pass the payload? Anything else mandatorily
required?


But again the following doubts do remain.

1. Wouldnt it be complicated to manupulate the send buffers on PEP nodes,
 as segments(since we retain the IP, TCP headers of end host for
encapsulating).
 Its no longer as simple as handling buffers as byte stream from
application.
Packets need to be sent as whole segments to other end of satlink.

2. The entire TCP stack has to be traversed at the PEP nodes, for flow and
congestion control, for both terrestial and satlink causing performance
overhead.Can this be avoided?

Any clarification would be helpful.

lp


-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of John
Border
Sent: Thursday, 4 March 2004 12:18 AM
To: [email protected]
Cc: [email protected]
Subject: Re: [pilc] tcppep



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
> [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/



***************************************************************************
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/