[e2e] overlay over TCP

[Joe Touch]

Randall Stewart wrote:
> 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.

They opened another connection for other reasons too:
	- to be able to signal "EOF"
	- to be able to force things to a third-party port
	  (to PUT to a lpr, e.g.)

The way the PORT command is spec'd, it almost looks like you could 
initiate a transfer remotely from a separate machine (A tells B to send 
a file to C) too. (anyone know whether that's possible? ever implemented?)

---

You might map it over, or not. HTTP, in particular, uses DNS names and 
IP address inside the stream. NATs want to translate them - even if we 
don't approve.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050120/6d2bca9b/signature.bin