[e2e] overlay over TCP

[Randall Stewart]

Joe Touch wrote:
> 
> 
> 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...

Hmm. Now how I interpret the above is that you cannot
figure out how to write code for PR-SCTP that gives you
unreliability. If that is what you mean, I would not
look for a protocol spec to tell you how to interface
to an API.

The PR-SCTP spec provides a base "service" aka timed-reliability
and a protocol mechanism.

Its not meant to give you a how to use it. The 3rd edition
of UNP gives a much better view of how to use the socket
API and I belive (if I remember right) it discusses using
the lifetime field.

Basically to get unreliable service (equiviant to udp)
all one has to do is set a lifetime parameter less than
the 1 second aka RTO.min. If one does that then you will
have the same symantic as UDP. One can choose to
use a smaller time then RTO.min too I suppose but
if you are after a unreliable service that would
be how one would do it. Some implementations actually
have a "SEND_ONLY_ONCE" like flag, this can also
be used as well, but of course thats an implemenation
specific thing.

As to the unordered, thats a base SCTP thing and one
(as covered in UNP) just passes the MSG_UNORDERED flag
in with the message (or'd in with any other options).
Of course thats for the socket-api and other implementations
will vary on how they specify unordered :-D


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

So basically if you can do un-reliable, out-of-order delivery you
meet (2).. SCTP with the PR-SCTP extension can do that. So
I believe your statement below is incorrect.
> 
>> 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. ;-)

Check the API document and UNP. As to reliability of implementation
and ease to use.

a) Last interop we had about 15 stable and reliable implementations
    of SCTP present reperesenting and running on all O/S's.
b) Most all of the implementations supported PR-SCTP, very few
    did not.
c) a large number of implementations supported the sockets api
    which is quite simple and easy to use and as I said has
    quite detailed coverage in UNP 3rd edition (you should
    get a copy).

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

I don't get this response. You obviously have not
used the SCTP API with sockets. Its quite easy to
use only one address.. you use a bind call. Its
quite easy to send with various options (check
the UNP or the socket api draft if you prefer a
draft). Its not complicated or hard.

It took a two line code change to make mozilla
run over SCTP. Of course not all features were
used.. but not everyone needs to use all features
either.

It's easy to use and not complex.. and implementation
wise we seem to have a lot of them for such a
"complex problem". The 15 I mention were what was
at the last inter-op. Many implementations did not
come since they consider themselves so stable they
are not interested in attending... there are probably
closer to 30 implemenations total then 15... but I
would need to go back and check all of the multitude
of interops that have gone on before I could say
for sure the exact numbers...

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

And as yet I could not

a) tell you how to write a line of code to it
<and>
b) tell you how to negotiate and end up with a
    congestion control profile (one of the things
    its supposed to do for me) without open loop
    negotation.
<or>
c) Tell you for sure what O/S's support it, I believe
    there MAY be a KAME extension that includes DCCP
    but I have only tried once to get it to compile
    and that did not work.

It may have a smaller feature set, but it does have
its complexities as well and the more CCID's you
add the more complex it becomes and the more
you end up with features and options.. each
CCID is a feature IMO. Which to me, is not
a bad thing. As an APP writer I want features
from my lower layers. This gives me more optioins.

> 
> As to NATs and Firewalls, as we all agreed, anything short of IP over 
> HTTP is liable to be blocked somewhere.
> 
At least on this we agree... and this is after
something is supported in the NAT and F/W world.

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