[e2e] overlay over TCP

[Joe Touch]

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

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

I'll concede that there are more SCTP implementations than DCCP, even 
that DCCP doesn't have a standard API (though one would expect it would 
have open/close like TCP with defaults to TCP cong control and a 
read/write like TCP that preserves boundaries only - i.e., as simple as 
some of the defaults in SCTP's API you mention).

But if the implementations of SCTP are anything like the specs, it's 
destined to be limited to the small communities that speak it's 
particular dialect of obscura.

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/9299cd2b/signature.bin