[e2e] overlay over TCP

[Randall Stewart]

Joe Touch wrote:
> 
> 
> Randall Stewart wrote:
> 
>> 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.
> 
> 
> I look to a protocol spec to tell me what a protocol can do, and 
> (hopefully) how to get it to do it - that might give me a clue as to how 
> to, e.g., implement 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. 
> 
> 
> That's perfectly clear! Wait - no, maybe not. So there's no "unreliable" 
> flag, ala the unordered flag?
> 
> And what does a 'lifetime less than 1 second' mean, exactly - to 
> send-side buffers, receive-side, etc? Will it stall other packets sent? 
> Others received? If so, it's not UDP semantics per se...

It does not mean anything.. since the first time they will
get re-examined is when the timeout goes off.. which is about 1 second
later. Yes, things are not going to get discarded as quickly with
PR-SCTP as with UDP.. but then if you funnel information to
UDP to fast you get drops that never hit the wire .. funny
thats hard to find in any spec too.

I have found, in all the app work I have done, far more
useful API documents such as UNP... and thats because
they give you the things the specs were not meant
to give IMO..
> 
>> 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.
> 
> 
> You 'suppose'? It's not that simple, is 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.
> 
> 
> So the protocol MIGHT support UDP semantics, IF the API provides access 
> to enough of SCTP's knobs that you can figure out how to set it? I'm not 
> surprised I didn't notice _that_ in the spec...
> 
> ...
> 
>> 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).
> 
> 
> How many pages?? ;-)


There are three full chapters in UNP on SCTP.. and 2 other
chapters that had considerable addition..

> ...
> 
>>> 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.
> 
> 
> But as you hinted above, it what you want to do isn't a 'phrase' in the 
> API, you have to figure out how to do it - and be _sure_ (no "suppose" 
> involved ;-)

And AFAIKT it was something like the UNP that got everyone
to the point where they could write network code.. not
RFC's or drafts... TCP is a fine spec.. but it was the
things Mr. Stevens put out that got people the know how
to write to the API..

You need a manual.. just like a dictionary... when you
start coding to TCP, UDP or any other network protocol..

If you want I will bring you one of my copies of the UNP 3rd
edition.. you might find it filling in the missing information..
just like it did for TCP when it was the 1st edition...

R



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