[e2e] overlay over TCP

[Randall Stewart]

Joe Touch wrote:
> 
> 
> Randall Stewart wrote:
> ....
> 
>>>> As to "doing SCTP" NAT's don't do TCP.. they know about
>>>> it.. where the ports are, what the c-sum is etc.
>>>
>>>
>>> And where the data is, which for TCP and DCCP isn't as tricky ;-)
>>
>>
>> There was no trick to it... one does not have to
>> know where the data is since the header is
>> just like TCP, just like UDP, just like DCCP.
>>
>> And all data (data and control) start after the
>> header.. no different than TCP.. except for one
>> minor rinkle.. I don't have to do the bit with
>> psuedo headers...
> 
> 
> Yeah, but you do have to deal with the SCTP muxing headers. Don't 
> forget, you have to scan certain protocols to translate IP addresses and 
> port numbers in the data too. That means parsing the data inside the 
> muxing chunks. (see below)
> 
>>>> Same for UDP and of course the same thing is needed
>>>> for SCTP. You have to understand a "SYN" or an "INIT"
>>>> but it is not as complex as you make out.. no more
>>>> complex than having a NAT do TCP...
>>>
>>>
>>> NATs translate data _inside_ the packets too; that's where 'knowing 
>>> SCTP' is substantially more complex.
>>
>>
>> FTP, last I checked, does not run over SCTP.. and even
>> if it did it would not be that tough to find the addresses
>> etc... no different than knowing the data format of
>> any other protocol... including TCP..
> 
> 
> Does HTTP? Will either FTP or HTTP? Any other protocols?

If HTTP or FTP ever do move to SCTP the logical thing
to do will be to get rid of the silly IP addresses and ports
inside the data stream. Instead they can use stream's to
accomplish the same thing .. and get better performance as
well.

The reason they do the "open another connection" thing is to
get around some of the very things that SCTP provides pathway's
around aka head-of-line blocking.

I would hope, anyone so wise as to move to SCTP would not
make the same mistakes.. and instead use the protocol
mechanisms that benefit things..

Take a look at:

http://pel.cis.udel.edu/

They have a real interesting paper that compared using
the muilt-streaming feature for FTP. They gained a
LOT of performance by doing this instead of starting
parrallel connections.. exactly what you don't want
to do..

R
> 
> Doing "NAT" _means_ translating inner addresses used in the data. If 
> you're ignoring that, sure, it's certainly easy. But that's not what 
> makes NATs hard or complex.
> 
> Joe


-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)