[e2e] overlay over TCP

[Randall Stewart]

Joe:

A question and a comment..

Joe Touch wrote:
> 
> 
> Coene Lode wrote:
> 
>>> David P. Reed wrote:
>>>
>>>> The reason not to depend on SCTP is the same reason that UDP isn't 
>>>> adequate. 
>>>
>>>
>>> I said DCCP, not SCTP, FWIW, and for a number of reasons.
>>
>>
>> And what might be those reasons????
>> DCCP will have just about the same deployment difficulties that any other
>> new transport protocol has to jump through....
> 
> 
> 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.

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.
> 

Hmm.. last time I checked pound for pound DCCP specs weighed in
about the same length or possibly longer when you add in the
CCID's and you need at least one...aka TCP friendly

DDCP          - 126 pages
CCID-02 (TCP) - 22 pages

and if you add in what all of them will eventually aka
the critical CC update TFRC you add:

CCID-03 (TFRC) - 39 pages

Take out the 2 pages of boiler plate on each one and
you have 181 pages of text.

SCTP RFC2960 - 134 pages
PR-SCTP ext RFC3758 - 22 pages

take out the same boiler plate and you are at 152 pages of
text.

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...


> ...
> 
>> 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...

R

> 
> Joe


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