Re: Death of the Internet - details at 11

We're clearly looking at this issue from VERY different viewpoints. See 
comments inline.
At 07:11 AM 1/30/2004, Randall R. Stewart (home) wrote:
> Daniel Senie wrote:
>
> > 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.
> No.. it is not the stack that makes the policy.. it is what is in the
> routing tables...
Wrong origination of routing information. I see from comments below you're 
looking at the "I'm an end user and want to have multiple paths to the 
Internet to get more bandwidth or redundancy" aspect. I run a web hosting 
company. We want to be able to have multiple upstream providers and 
multihome to guard against outages at any one provider. We pay for 
bandwidth based on usage, and so may well have several connections, but 
designate one or more to be used only if other connectivity as a last resort.
As the content provider who's spending lots of money on which of MY 
circuits I want traffic to arrive on, I don't want you deciding on your two 
DSL lines to choose one of my sets of addresses or the other. If you stream 
video over a link I don't want used normally, my bills would skyrocket.
This is why I said the decisions in YOUR stack are deciding routing policy 
for MY circuits. In the IPv4/BGP world configuration of this stuff isn't 
clean or simple, but it is possible to encourage the use of some links over 
others. I don't see how I would be able to implement that type of control 
with your simplistic SCTP stack tests, other than to play games with 
discarding or delaying probe packets from your computer on some paths.

> Note that all SCTP (or TCP for that matter) does is ask for an alternate.
> If the administrator does not have an alternate available.. or deems it
> costs to much then it would not be at that level of the table. Also the
> admin controls which is priority by order.. .i.e. if I add
Wrong table. You can control which interfaces YOU use to reach the world. I 
don't see how I can control the weightings and preferences your computer 
will use to reach MY multihomed systems.

> route add default 10.1.1.1
> and then
> route add default 10.2.1.1
>
> Then you will get the 10.1.1.1 first... the signifigance of this is
> that you use the alternate route ONLY when you are having
> difficulty getting to through to the peer... i.e. T3-rtx's...
>
> So if you were really concerned about cost.. the admin would
> need to put the cheapest route in first... in reality my two
> routes in my multi-homed box do not cost any more.. they
> are equal cost.. I have them since I want to stay connected and
> I want it simple.. i.e. I add two default routes and SCTP just
> works...
I'm concerned about traffic inbound to my site, and the cost of the various 
pipes I use for that.





> > 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 think you need to look at how most of us purchase broadband..
This is where I got clued in to the fact that we're not talking about the 
same problem.
>  I buy
> two DSL's into my house... I don't really care which one is used.. they cost
> no more if I let one sit idle then if I send/recv ton's of data. This is the
> reality of the DSL for 49.95 a month... there is not cost difference.. only
> when I start running T1's and such to my house does cost become an
> issue... and I just don't see the masses doing this.. they will wait
> for the DSL and cable modem to be in the neighborhood...
I don't expect the masses to multihome at all. I do expect most content 
providers to be multihomed, and to want to manage that multihoming. Today, 
it's possible to multhome if you have PI space, or if you get a couple of 
cooperating network providers to punch sufficient holes in their aggregates 
and toss routes to one another (to deal with folks who filter the more 
specifics). A great deal of effort has been expended by many folk to 
provide ways to specify routing policy and path preferences.
If I can't make these types of policy decisions, there's no reason for me 
to implement the type of multihoming you're promoting.





> > > 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.
> I don't see why I would want two addresses to the same companies.. I buy
> two DSL's in my location because I know that any single ISP tends to 
> fail.. thus
> I get two seperate non-related IP addresses... like I have now.. go do
> a dig on
> stewart.chicago.il.us
If I've got a farm of 100 servers, I would need each of them to have an 
address on each provider. Will those providers allow me to obtain more 
address space? Under present rules, I have to justify the space I ask for 
from each upstream. Each of them wants to know how I'm utilizing space from 
the other.

> The two V4 addresses you see are NOT related... one is SBC/Ameritech the
> other is speakeasy..
>
> This requires no changes in any ARIN or RIRs rules...
It sure seems like it would if you're asking for a bigger chunk of space 
from each provider. Will I be able to get a /23 from each of 3 providers 
without running afoul of ARIN rules? I don't know for sure, but suspect it 
would be an issue.
Since you're talking about residential circuits, and I'm talking about fat 
pipes in data centers, it seems the examples each of us had in mind don't 
make sense for the others' arguments.
Dan