Re: Death of the Internet - details at 11

At 07:43 AM 1/29/2004, Randall R. Stewart (home) wrote:
> Iljitsch van Beijnum wrote:
>
> > 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?
>
> Ahh.. I never did the direct comparison at the RFCs... just what
> I saw in ethereal..
>
> My hosts are BSD based and always send MSS of 1448 bytes. SCTP
> uses 1452.
>
> Looking at the RFC's SCTP is 8 bytes more...
>
> Don't think 8 bytes is really a killer.. especially when 4 of those
> bytes can be used for the application (PPId)....
>
> And especially since:
>
> 1) SCTP is not as subject to the wrap issue so Timestamps are not needed
> 2) SCTP is not as subject to data and control injection by blind attackers
>
> and these come for free as well..
>
> > > 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.)
> As to CRC32c .. yes it is more expensive.. but it affords a lot more
> protection then the TCP checksum.  And just like the TCP checksum
> there are already chipsets out there that do this in hardware... I
> know intel has such a chipset and I am sure you will see it evolve
> to other hardware makers as well.
>
> As to the other features... if the application is going to
> have to perform them then you have not removed the
> cost.. you have just pushed it to a higher layer...
>
> > > > - 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.
>
> You don't get new features without change of some sort...
>
> > > 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.)
>
> Yes you get a retransmissions to alternate addresses with this small 
> change. And
> you don't have to try all the addresses.. just an alternate until you
> find one that works...
I really don't see how this fits with routing policy. You appear to make 
the assumption that a multi-homed site wants to use the multiple paths as 
equals.



> > > 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.
>
> Yes.. if you wanted to do HTTP over SCTP and use features such
> as streams you WOULD WANT to extend HTML so that you could
> have the client "get pages" on particular streams... Then you could
> have parrallel transfers over one association and not have to require
> multiple TCP connections... this is optimal...
>
> Jana was doing some investagtion into this at the University of Deleware's 
> Protocol
> Engineering Lab.. don't know if he will be writting a paper on it.. I 
> imagine so...
> > > > - 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.
> Just like we are stuck with IPv4 "forever" as well...  Its pretty much
> a given.. once a new technology comes along it is a slow gradual 
> transition not
> a mass move. IPv6 as been out since 1993 and we are not only 11 years into
> the migration.. it will all happen eventually.. but I see many years left for
> IPv4... and only a slow migration to V6...
>
> The same, I think, can be said for SCTP.. and it is very early in this 
> process if
> you use IPv6 as a gage :-D
>
> > > > - 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 solved this in kame with our alternate routing code. Each time
> an address fails more than a threshold (default of 2 rtx's if I remember 
> right) we
> ask the routing system for an alternate route... This makes it so that after
> any two failed transmissions to x routed through B we would then ask for
> a new route and get one over A... And yes it works in the the middle
> of a session when the ISP makes a change during the conversation.. the
> thresholds are not picky about when it happens ...
Ah, so you have indeed made routing policy decisions and placed them into 
the end systems of the originator of the session. This is most interesting. 
A site which has multiple connections with varying cost has to either live 
with the routing policy you've encoded into the stack or force dropped 
packets in some fashion to try to fool your stack.
I'm afraid the multihoming solution you are promoting does not match up 
entirely with the full scope of the multihoming problem. Though I'm sure 
some folks will be relieved to not need to formulate routing policies, it 
does seem a lot of folks really want to be able to control their routing. 
Today, there can be cost differences among circuits (think about circuits 
that are priced based on usage), preferred circuits, and so forth.

> I might add that TCP could also take advantage of this code and gain
> some reliability as well.
>
> Oh, and note, in your scenario above.. if it happens in the middle of
> a TCP connection the connection will fail.. or just plain not start
> up if it is being filtered and that is the way the routes point.
>
> For our KAME stack with the patch it will NOT fail in the middle...
>
> > > We have fully
> > > addressed source address selection in the KAME implementation.
> >
> > In what way?
>
> See above, you would be best to get the KAME stack, and the patch from
> www.sctp.org
> (further details are in the alternate routing discussion on the sctp.org 
> web site)
> and then play with it..
The other failing of the dual-address problem is the need for dual 
addresses. I guess we'll have to ask ARIN and the other RIRs to adjust 
their rules to allow justification of parallel allocations from multiple 
upstreams to a single company, where they'd only have needed a single block 
of a given size before. There's no free lunch, at least if there's any 
interest in using SCTP as a multihoming solution atop IPv4.