Mark Allman wrote:
>
> (catching up ...)
>
> > I would rather have Andre work with me to get any other
> > rinkles out of SCTP that he deems are there... and get the
> > KAME-SCTP stack ported directly in to FreeBSD.. this IMO ... would
> > make more sense... Get something that is pretty well bak
(catching up ...)
> I would rather have Andre work with me to get any other
> rinkles out of SCTP that he deems are there... and get the
> KAME-SCTP stack ported directly in to FreeBSD.. this IMO ... would
> make more sense... Get something that is pretty well baked (IMO at
> least) and work to g
Karim Fodil-Lemelin wrote:
>
> Ok here is an example, just to make sure I understand:
>
> CLI1 : SERVER1 (first connection, option negociated, tuple hash
> created)
> CLI1 : SERVER1 (second connection, sending payload in first packet,
> using previously negotiated cookie)
> ...
> CL
Ok here is an example, just to make sure I understand:
CLI1 : SERVER1 (first connection, option negociated, tuple hash
created)
CLI1 : SERVER1 (second connection, sending payload in first packet,
using previously negotiated cookie)
...
CLI1 : SERVER1 ( nth connection, sending pa
Karim Fodil-Lemelin wrote:
>
> In the case where all connections go through the SATLINK and are
> splitted by proxies, it make sense to use this knowledge and not
> renegotiate cookies for every connections since we know there is only
> one path to the internet and that all SATLINK connections
In the case where all connections go through the SATLINK and are
splitted by proxies, it make sense to use this knowledge and not
renegotiate cookies for every connections since we know there is only
one path to the internet and that all SATLINK connections will support
(T/TCP or whatever na
Karim Fodil-Lemelin wrote:
>
> Now,
>
> I have a question. In our application which can be described as:
>
> Client > (Client Gateway) ---> SATLINK --> (Server Gateway)
> -> Internet
>
> We act as the Internet servers (transparent proxies) and therefore T/TCP
> traffic is on
Now,
I have a question. In our application which can be described as:
Client > (Client Gateway) ---> SATLINK --> (Server Gateway)
-> Internet
We act as the Internet servers (transparent proxies) and therefore T/TCP
traffic is only sent over the SATLINK. In the current T/TCP
i
Our product is a TCP/IP accelerator for satellite communications please
see http://www.xiplink.com/technology/xiplink_technology-datasheet.html.
Also, please see http://www.scps.org/scps/ for an explanation of our
Transport layer implementation. BTW, The marketing dep has renamed T/TCP
to fast
---Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Julian Elischer
> Sent: 04 November 2004 20:53
> To: Karim Fodil-Lemelin
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Andre Oppermann;
> [EMAIL PROTECTED]
> Subject: Re: Removing T/TCP
Karim Fodil-Lemelin wrote:
Hi,
I am jumping in here, was too busy to read the list for the last 2
weeks, so please excuse my intrusion. We are using T/TCP in our
product line and are very happy with the performance gain. Could you
tell me what is the rational for removing T/TCP
(security/p
Karim Fodil-Lemelin wrote:
>
> Hi,
>
> I am jumping in here, was too busy to read the list for the last 2
> weeks, so please excuse my intrusion. We are using T/TCP in our product
> line and are very happy with the performance gain. Could you tell me
> what is the rational for removing T/TCP
Hi,
I am jumping in here, was too busy to read the list for the last 2
weeks, so please excuse my intrusion. We are using T/TCP in our product
line and are very happy with the performance gain. Could you tell me
what is the rational for removing T/TCP (security/performances/code
complexity,
Mark Allman wrote:
Sure. To make you sleep better it will be disabled by default (like
T/TCP) and possibly even not compliled in by default (#ifdef'd).
Part of your argument against T/TCP. :-)
A writeup will follow once I get there. I made this request before I
start working on it to prevent to
Russell L. Carter wrote:
Greetings,
It is not easy to get kame up and running, and I know this because
I have. It is beyond all ordinary production installations.
Wow.. I have never had a problem installing it.. but of
course I have worked in U**X for 20+ years... so maybe
I don't notice and am not
Marco Molteni wrote:
On Thu, 21 Oct 2004 Andre Oppermann <[EMAIL PROTECTED]> wrote:
Bruce M Simpson wrote:
On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote:
Thus after the removal of T/TCP for the reasons above I want to
provide a work-alike replacement for T/TCP's functionality:
I
Matt Emmerton wrote:
The SCTP home page (www.sctp.org) has a list of implementations. Note that
I had to use Google's cache of the site -- I believe there was a Slashdot
article on SCTP this morning which may have taken down the site.
Sigh... It is also over satellite... which is medium speed int
> A T/TCP alternative as you are describing sounds very
> similar to PR-SCTP (Partial Reliability SCTP). (Don't let the
> name fool you, please read the internet draft).
Can you sketch this in a bit more detail? I do not follow. PR-SCTP is
about being allowed to "abandon" data --- i.e., send it
Dag-Erling Smørgrav wrote:
>
> Andre Oppermann <[EMAIL PROTECTED]> writes:
> > o T/TCP only available on FreeBSD. No other Operating System or TCP/IP
> > stack implements it to my knowledge. Certainly no OS that is common.
>
> AFAIK, both Linux and Windows support it, at least on the serv
Marco Molteni wrote:
>
> On Thu, 21 Oct 2004 Andre Oppermann <[EMAIL PROTECTED]> wrote:
>
> > Bruce M Simpson wrote:
> > >
> > > On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote:
> > > > Thus after the removal of T/TCP for the reasons above I want to
> > > > provide a work-alike re
[EMAIL PROTECTED] (Dag-Erling Smørgrav) writes:
> [...]
I should add: I'm not against removing T/TCP support (especially if it
helps simplify our network stack), but I don't see the point in
replacing it with some homebrew protocol that noone else supports.
DES
--
Dag-Erling Smørgrav - [EMAIL PR
Andre Oppermann <[EMAIL PROTECTED]> writes:
> o T/TCP only available on FreeBSD. No other Operating System or TCP/IP
> stack implements it to my knowledge. Certainly no OS that is common.
AFAIK, both Linux and Windows support it, at least on the server side
(i.e. they can receive T/TCP con
> On Thu, 21 Oct 2004 21:32:48 +0200
> [EMAIL PROTECTED](Marco Molteni) said:
> SCTP in KAME is complete, stable and fully supported.
> It is mainly developed by the SCTP RFC author, Randall Stewart.
KAME Project haven't received SCTP-related bug report so much, and I
think it's due to a
Craig Rodrigues wrote:
On Thu, Oct 21, 2004 at 09:32:48PM +0200, Marco Molteni wrote:
A T/TCP alternative as you are describing sounds very
similar to PR-SCTP (Partial Reliability SCTP). (Don't let the
name fool you, please read the internet draft).
Interesting stuff:
http://www.portaroo.net/ietf
Greetings,
It is not easy to get kame up and running, and I know this because
I have. It is beyond all ordinary production installations.
And as Craig notes it's not possible[1] in the 5* line
yet. Maybe Randall would like to chip in on whether BSD SCTP
is ready for prime time in FreeBSD. But
On Thu, Oct 21, 2004 at 09:32:48PM +0200, Marco Molteni wrote:
> SCTP in KAME is complete, stable and fully supported.
> It is mainly developed by the SCTP RFC author, Randall Stewart.
Randall has been maintaining his SCTP stack on FreeBSD 4.x,
OpenBSD, and NetBSD. It has recently been ported to
On Thu, 21 Oct 2004 Andre Oppermann <[EMAIL PROTECTED]> wrote:
> Bruce M Simpson wrote:
> >
> > On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote:
> > > Thus after the removal of T/TCP for the reasons above I want to
> > > provide a work-alike replacement for T/TCP's functionality:
Julian Elischer wrote:
>
> Andre Oppermann wrote:
>
> >Mark Allman wrote:
> >
> >
> >>>Thus after the removal of T/TCP for the reasons above I want to provide
> >>>a work-alike replacement for T/TCP's functionality:
> >>>
> >>>
> >>I haven't fully digested this yet. But, I'll voice my distaste f
David O'Brien wrote:
>
> On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote:
> > Thus after the removal of T/TCP for the reasons above I want to provide
> > a work-alike replacement for T/TCP's functionality:
> ..
> > This different implementation will be disabled by default and clear
< said:
> I'm not so happy with a FreeBSD-only "proprietary" thing. Is there any
> proposed RFC work that provides the qualities you want? The advantage
> with T/TCP is that there was a published standard.
T/TCP was a published *non*standard, loudly blazoned "EXPERIMENTAL".
I don't see how Andr
Andre Oppermann wrote:
Mark Allman wrote:
Thus after the removal of T/TCP for the reasons above I want to provide
a work-alike replacement for T/TCP's functionality:
I haven't fully digested this yet. But, I'll voice my distaste for
implementing things that just seem to "Make Sense". T
On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote:
> I intend to remove T/TCP (transactional TCP) support from our TCP
> implementation for the following reasons:
..
Fine.
> Thus after the removal of T/TCP for the reasons above I want to provide
> a work-alike replacement for T/TCP
> Sure. To make you sleep better it will be disabled by default (like
> T/TCP) and possibly even not compliled in by default (#ifdef'd).
Part of your argument against T/TCP. :-)
> A writeup will follow once I get there. I made this request before I
> start working on it to prevent to waste my
> Bruce M Simpson wrote:
> >
> > On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote:
> > > Thus after the removal of T/TCP for the reasons above I want to
provide
> > > a work-alike replacement for T/TCP's functionality:
> >
> > I disagree. I think the time spent here would be better s
Mark Allman wrote:
> > Thus after the removal of T/TCP for the reasons above I want to provide
> > a work-alike replacement for T/TCP's functionality:
>
> I haven't fully digested this yet. But, I'll voice my distaste for
> implementing things that just seem to "Make Sense". That's a model that
> I intend to remove T/TCP (transactional TCP) support from our TCP
> implementation for the following reasons:
Yeah, I think that makes a bunch of sense.
> Thus after the removal of T/TCP for the reasons above I want to provide
> a work-alike replacement for T/TCP's functionality:
I haven't fu
< said:
> I think that it would have to be slightly more complex than that for it to
> be secure. Instead of using syncookie/RFC1948-like generation,
> [...]
HIP! HIP! HIP!!!
-GAWollman
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/m
Bruce M Simpson wrote:
>
> On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote:
> > Thus after the removal of T/TCP for the reasons above I want to provide
> > a work-alike replacement for T/TCP's functionality:
>
> I disagree. I think the time spent here would be better spent on work
On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote:
> I intend to remove T/TCP (transactional TCP) support from our TCP
> implementation for the following reasons:
Go ahead and kill the old thing, it's time. I agree.
> Thus after the removal of T/TCP for the reasons above I want to p
Mike Silbersack wrote:
>
> On Thu, 21 Oct 2004, Andre Oppermann wrote:
> > o The client has to enable the option in the TCP SYN request to the server.
> > If the server accepts it, then it returns a unique cookie generated from
> > the IP address of the client and some random seed. On subsequ
On Thu, 21 Oct 2004, Andre Oppermann wrote:
I want to bring this up for discussion prior to start working on it.
I intend to remove T/TCP (transactional TCP) support from our TCP
implementation for the following reasons:
That sounds good.
o The client has to enable the option in the TCP SYN request
> I intend to remove T/TCP (transactional TCP) support from our TCP
> implementation for the following reasons:
Good reasons & decision Andre.
Another reason is that T/TCP (RFC1644) is listed as "deprecated" in the
"Roadmap for TCP Specification Documents" I-D, almost certainly to become
a RFC so
Poul-Henning Kamp wrote:
>
> In message <[EMAIL PROTECTED]>, Andre Oppermann writes:
> >I want to bring this up for discussion prior to start working on it.
> >
> >I intend to remove T/TCP (transactional TCP) support from our TCP
> >implementation for the following reasons:
>
> Yeah, go for it!
>
In message <[EMAIL PROTECTED]>, Andre Oppermann writes:
>I want to bring this up for discussion prior to start working on it.
>
>I intend to remove T/TCP (transactional TCP) support from our TCP
>implementation for the following reasons:
Yeah, go for it!
>However something like T/TCP is certainly
I want to bring this up for discussion prior to start working on it.
I intend to remove T/TCP (transactional TCP) support from our TCP
implementation for the following reasons:
o T/TCP is very intrusive to the TCP code and has special cases and
dependencies in many places. This makes it a lot
45 matches
Mail list logo
