[e2e] overlay over TCP

[Joe Touch]

Randall Stewart wrote:
> Joe:
> 
> A question and a comment..
> 
...
>> Recall that David Reed's initial post asked for:
>>     1- TCP-friendliness
>>     2- no app penalty for reliability or in-order delivery
> 
> 
> I don't get why you answer the way you do on <2> for SCTP...
> 
> What app penalty are you talking about for reliability or
> in-order delivery... With SCTP you can have reliability, in-order
> delivery or no-reliability and out-of-order delivery and any
>  combination.

PR-SCTP is an extension to SCTP, which isn't as widely deployed as SCTP. 
  I re-read the PR-SCTP spec a few times, and _still_ cannot figure out 
how to provide true unreliable, any-order delivery. That alone is a fine 
reason not to use PR-SCTP for this example. See below for other reasons...

As to the app penalty, it's related to reliable, in-order delivery costs 
the application latency if there are losses or out-of-order events in 
the net (for retransmission and reordering).

> How does that not meet 2?
> 
>> SCTP does (1) but NOT (2).
>>
>> DCCP does both (1) and (2) as requested.
>>
>> There are other reasons, notably SCTP's complexity compared to DCCP, 
>> as well as features such as multihoming and multistream muxing that 
>> may result in an unstable foundation for overlays, e.g., that want to 
>> do their own dynamic routing.

(page count comparisons omitted for brevity)...

> Seems to me about the same complexity and also DCCP is not an
> RFC yet.. there may be more to it... I know they talked
> about a mobility draft and some new CCID for VOIP..
> 
> All in all I don't buy your argument that SCTP is more
> complex...
> 
> And I think DCCP had a form of multi-homing in it too.. its
> been a while since I have read through it so it may be removed or
> moved other places ....
> 
> Besides which, we are no longer in the 8088 days so complexity
> in either DCCP or SCTP is not something to be afraid of. An
> application wants services plain and simple...

Complexity affects a number of things:

	- reliability of implementation
	- ability to easily configure and use the protocol

In particular, _if_ you're referring to PR-SCTP, please indicate where 
in the PR-SCTP RFC its use for unreliable, out-of-order messages is 
simply and clearly described. ;-)

>> ...
>>
>>> Seriously: you can extend TCP or deploy an already existing transport
>>> protocol that gets close to what you want.
>>> If it has to do something similar to UDP then PR-SCTP and/or DCCP 
>>> might do
>>> the job....
>>> (PR-SCTP: Partial relialability extension for SCTP)
>>
>> Why bother with PR-SCTP when a much simpler DCCP will suffice, esp. 
>> when other SCTP properties may be (IMO, are) harmful to overlays?
> 
> If one does not want multi-homing one can basically turn if
> off for tunnels.. I can setup my tunnel endpoints so that
> the association is singly homed.. thats easy... so if you
> think M-homing is harmful, turn it off. And you will
> find, IMO, SCTP a bit further along on the way to deployment
> then DCCP.. this is not to say DCCP won't deploy eventually.. but
> it too has the same hurtles this thread as discussed with NATs
> and Firewalls.. and its just starting...

There are so many things in SCTP to turn off, it's impossible to 
consider a valid argument that SCTP is less complex than DCCP.

The length of the DCCP spec vs. SCTP may speak to the comparitive 
clarity or completeness; spec length isn't always a good metric of 
complexity. My metric is feature set. By that metric DCCP is a much 
simpler subset for the task requested.

As to NATs and Firewalls, as we all agreed, anything short of IP over 
HTTP is liable to be blocked somewhere.

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/20050119/cff279f4/signature.bin