Re: Death of the Internet - details at 11

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 28-jan-04, at 23:47, Randall R. Stewart (home) wrote:

- increased overhead compared to TCP

Ok lets see. SCTP takes on average 4 more bytes per data packet then
TCP. However, if the TCP implementation enables timestamps then
that is not true and TCP takes more overhead by about 4 bytes...

Hm... timestamp option takes 12 bytes, what gives?


Unless you are discussing another type of overhead...

Apart from the extra bytes (which isn't the main issue) there are the CRC32 checksum, which is considerably more expensive to compute than the TCP/UDP/IP checksum and the fact that SCTP has much more complexity. I would be surprised if the "fast path" for SCTP wouldn't turn out to be more expensive than that of TCP, especially without disabling all the features that make SCTP more interesting than TCP in the first place. And of course those heartbeats I love to hate. (Which don't provide any benefits when there are only two paths anyway.)


- requires significant changes from applications

Ok let see.. for Mozilla we converted two lines of code

Ok, we can discuss whether the changes are significant but the fact that changes are required at all is the main problem.


sd = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP);
became --------------> sd = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP);

and

setsockopt(sd, IPPROTO_TCP, TCP_NODELAY, &on_off, sizeof(on_off));
became ---------------> setsockopt(sd, IPPROTO_SCTP, SCTP_NODELAY, &on_off, sizeof(on_off));

So is this enough to gain all multihoming benefits? Even if all other magic is hidden inside the protocol, the application must at least try all possible destination addresses. (But this is true for several other multi6 proposals as well.)


Now to take advantage of the stream feature you would need to do
more.. but for pure multi-homing one or two lines of change does
not seem that big of deal to me ...

Doing WWW-style HTTP (lots of concurrent sessions) with SCTP would be nonsense, this is where the feature where multiple streams are multiplexed over a single session would be extremely useful.


- no backward compatibility of any kind

I am not sure what you mean by backward compatable? You definetly
can't have TCP and SCTP talk.. they are after all different protocols...
But if an application needs the redundancy move to it.. its there today
with about 2 lines of coding change...

But then you'll have to run services on both TCP and SCTP pretty much forever. Not a good thing.


- source address selection problem isn't addressed fully, if at all

I don't think I understand this issue either..

Host has addresses a and b from ISPs A and B. Host sends a packet to address x which is routed over ISP A. However, the host selects source address b which is filtered by A, so no connectivity. For extra credit: solve same when this happens in the middle of a session, and in cases where connectivity consists of two one way paths. (a -> x and y -> b work, but not x -> a or b -> y)


We have fully
addressed source address selection in the KAME implementation.

In what way?




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]