[e2e] overlay over TCP

[Coene Lode]

Joe, 

I was pleasently surprised to learn that I can read and (probably) write
Greek, in addition to Dutch, French, German and English. 
Then I remebered that I could also read DCCP and TCP specs and understand
them. 
And they were in a very similar language to the SCTP Specs.....  
Maybe after all, you can also read and speak greek.... :-)

> Note that item F2 in sec 3.5  of RFC 3758 also allows 
> delaying outgoing 
> chunks for aggregation; DCCP does not appear to do that (any DCCP 
> experts like to chime in?)DCCP appers to correlate packets on 
> the wire 
> with application writes and reads; the same is not 
> necessarily true with 
> SCTP. There are substantial advantages to such correlation when 
> tunneling network layer packets over transport protocols. I 
> think that's 
> what David Reed was referring to...

And that is what I am using with SCTP.
Bundling messages is an Option in SCTP. 
I turn this option off, so all my messages get on the wire the moment I
write them to the socket... 
Most present day SCTP aplication do this. They do not bundle/aggregate
messages.
And you are right, there are substantial advantage to such a correlation(to
start with debugging, the logical flow of the program and so forth...) That
why most SCTP applications want and do this...

However some applications may like them aggregate, so no problem for me,
just switch it on...

It seems that I been doing overlay networks for most of my life, that why we
required SCTP to at least have the option to turn aggregation off. And some
other options that are included in SCTP which make overlaying a bit easier. 
Does this add complexity, sure, but then just compare UDP with DCCP...
Mathematical speaking , if you go from a protocol which can be described in
10 pages to a protocol(UDP) that must be described on around 100
pages(DCCP), that is a pretty big jump in complexity, 
Then any application that want to use it, should at least expect to see some
advantages from it....
If a transport protocol does not the stuff that I deem necessary for my
particular kind of overlay, then I am sorry, then it is very likely that I
will not choose that protocol....
DCCP was not around when we were working on our overlay...
But now that DCCP is around, it still comes up short in some aspects....
And NO , do not change DCCP to adapt to our needs, because you will then end
up with a clone of SCTP..(and the same complexity)
(And yes, along those lines , I admit that SCTP is a clone of TCP with some
extra thrown in...There is nothing wrong with that.)
SCTP does it job . And some of the additional stuff will make it doing it's
job even better...

My company sells stuff with SCTP in to operators. They use it, so the NAT
belonging to those operators have to let SCTP through.. Otherwise the
consequence is that they make no money from it and believe if that happens,
they gone tell that NAT/firewall/router vendor to adapt or take the
NAT/firewall/router gear back... 
> 
> Joe
> 

Yours sincerly,
Lode Coene