[ILUG] Free software for .pando files?

paul at clubi.ie paul at clubi.ie
Fri Sep 7 00:24:53 IST 2007


On Wed, 5 Sep 2007, Thomas Bridge wrote:

> The entire thrust of my comments have been aimed at the position 
> that as a cost of managing and routing P2P traffic, transit is not 
> particularly high on the list.  I've never suggested there were 
> problems with using transit (by which I include peering with other 
> ISPs).

Ok.

So there are no problems - at least, nothing mentioned by me or the 
other two posters so far is a problem.

How about going into detail as to what (if any) problems P2P is 
causing ISPs, with respect to load particularly. That'd be far more 
productive application of your operational experience than this 
naysaying..

>> Uh, ATM, MPLS, L2TP all:
>
>> - post-date IP!!!!
>> - are circuit-switched

> MPLS and L2TP are not circuit switched.

The packets forming an L2TP need not be circuit switched, no - but 
it's used to create circuits and hide stuff from IP still.

MPLS most definitely /is/ circuit-switched, rather than 
packet-switched.

No packets for a given circuit (how packets are classified is network 
specific) can flow until LDP sets up an end-end path (well, where 
egress controls setup of label - which is the common case). All 
packets of a given class follow the same circuit (an MPLS 
label-switched path, i.e. circuit, might be renegotiated to a new 
path though).

- path setup triggered by need
- network control messages converge on a path /before/ data flows
- path for some class of data is fixed
- does not rely on any fancy graph-theory, distributed algorithm for
   cycle-free convergence

   - Control messages and circuit setup precedes data and they probe
     the entire path, in both directions. So it's self-evident that
     any circuit that gets setup is both viable and loop-free.

   - Yes, MPLS still has TTLs, that's cause we've learned that
     forwarding without TTLs is NOT robust (see ethernet).

     - with distributed algorithms, the network /regularly/ will have
       loops as and when things change. With LDP/MPLS, it shouldn't
       happen normally, but it's still better to have TTLs to be
       safe..

It's pretty much classic circuit-switching (though, a lot more 
dynamic than older circuit-switching networks).

The last bullet point particularly is pretty indicative of 
circuit-switching, versus networks which independently route each 
packet, hop by hop.

Yes, some control information is now in-band (label header prependend 
to data), and acted on per-packet, per-node - rather than out-of-band 
(ie in the network, as with older circuit-switched networks), but 
even POTS calls have long been digitised and prepended with headers 
before being passed through a circuit switched network.

If you don't believe me, go read 3.21 of RFC3031, "MPLS 
Architecture":

    Route selection refers to the method used for selecting the LSP for a
    particular FEC.  The proposed MPLS protocol architecture supports two
    options for Route Selection: (1) hop by hop routing, and (2) explicit
    routing.

    Hop by hop routing allows each node to independently choose the next
    hop for each FEC.  This is the usual mode today in existing IP
    networks.  A "hop by hop routed LSP" is an LSP whose route is
    selected using hop by hop routing.

    In an explicitly routed LSP, each LSR does not independently choose
    the next hop; rather, a single LSR, generally the LSP ingress or the
    LSP egress, specifies several (or all) of the LSRs in the LSP.  If a
    single LSR specifies the entire LSP, the LSP is "strictly" explicitly
    routed.  If a single LSR specifies only some of the LSP, the LSP is
    "loosely" explicitly routed.


Note:

- "explicit routing" boils down to 'ordered distribution control'
   mode of LDP - which is what I'm talking about above.

- The other possibility, independent per-hop-packet routing, (so not
   circuit switching) is not, in my limited operational knowledge,
   used much (e.g. JunOS doesn't support it in their LDP apparently.
   And I'd imagine few people use OSPF or IS-IS to distribute labels).
   It seems slightly pointless from a management POV (it exists purely for
   speed, afaik).

> I'm thinking protocols like SDH, ISDN and ATM. And my point would 
> have better made had I said "predate wide deployments of IP".

All of those post-date the wide deployment of IP. ATM was a reaction 
by the telco world to the rise of packet switching - IP being the 
predominant packet-switched technology, along with ISO.

> No - I said the costs of getting traffic from the customer site to 
> the ISP's data centre were the biggest part of the cost involved in 
> supplying a DSL service.  For clarity, it's the cost of building 
> and maintaining the DSL "circuit/link" in the first place - not 
> just the cost of carrying traffic over the link.

Interesting.

The whole 'connect customers to ISPs' circuit-switching model also 
has a lot over administrative overhead.

Intriguingly, this does NOT seem to be borne by the IP guys. All the 
work of co-ordinating with Eircom to connect "DSL at line with number 
Y" -> ISP X seems to get done by non-technical administrative staff.

That's essentially a human form of LDP ;). But it's a cost you, in 
your network-ops capacity, don't fully see. (I imagine you're aware 
of it though).

If everything ran in a single network, with the /ability/ to 
short-circuit ISP traffic at exchanges and/or BAS (if the ISPs 
involved deemed that to be 'shortest'), you might save some of those 
human overheads. Hence the 'build' cost might be slightly lower..

> As an ISP would typically deliver several thousand customers over 
> the same STM-1 circuit, there is an additional cost for carrying 
> the traffic, as the value of "several" depends on the average 
> amount of traffic that each customer is carrying.

The average amount is going to tend towards "the link capacity". The 
masses *will* one day be watching corry via IP.. And P2P is the new 
multicast..

Cable ISPs will be able to take advantage (some already do TVoIP from 
headends to STBs), simply by letting customers see each other. ISPs 
tied to the state-telco-wholesaler model are going to have to bear 
the extra costs of shipping a *lot* of quite redundant bits.

That surely will hurt those ISPs..

> I would say that the proportion of traffic travelling from house to 
> house within the same street is typically less than 0.1% of the 
> average DSL users traffic.

>From your view of a DSL network operatio. Agreed. Because it's 
impossible at present for people to do so.

The P2P applications at present have no incentive to look locally 
first (as discussed) + the masses aren't yet watching Corrie online 
(but ITV do now have it online..).

There are IPTV apps which try to be topology aware.. It is the 
future.

I bet the picture is different with cable networks where customers 
can see each other..

> In other words, you're fussing about a very small amount of data 
> that is taking a sub optimal route.

Perhaps.

> No my problem with "native" IP networks is that it's impossible for
> more than one ISP to run a service into the exchange.

> The fact you can't have multiple providers using the same exchange 
> equipment.

But all the Irish ISPs seem to be doing their best to have the 'share 
the equipment' scenario be their /last resort/. So the few remaining 
Irish ISPs are doing their best to try avoid it.

Layers of crap and scenic routing are quite a price to pay to allow 
multiple ISPs to share access to the copper.

We could have invented ways to distribute IP configuration 
information from ISPs to wholesaler, rather than have invented ways 
to fake-up L2 links between customer and ISP (e.g. PPPoE, L2TP - 
energy mispent).

> MT routing?

Multi-Topology. E.g. doing one kind of routing (e.g. IP topology) 
then another (e.g. an MPLS-like one) over another, etc...

So you can have a single, unobscured link topology, but apply an 
ordered set of routing mechanisms to it.

> It's worth noting at this point that at the time Tinet was launched 
> - there were already several ISPs offering dial up IP services - 
> IEunet, Ireland On Line, Indigo, Connect and Club Internet all come 
> to mind.
>
> If we'd left it to incumbent telco to run the country's ISP
> infrastructure, we'd all still be using 33.6K modems at an average
> cost of about €40 a month.

Sure, agreed.

>> It is. Though not in the sense you mean here - BGP links are 
>> between ASes. For eBGP sessions, links often do correspond to IP 
>> links (some crazy people run multihop eBGP, to a central router, 
>> for various reasons to do with lack of resources ;) ).

> Thats not what a link aware protocol is.   BGP significantly abstracts
> the topology - and when calculating the forwarding table from it's
> database, isn't remotely interested in the status of a given link.

Again, you're using "link" solely in the sense of "layer-2 link". You 
need to reread what I wrote. ;)

> With the state of IP as it stands, you can't have more than one 
> ISP. The entire network would have to be under a single 
> administrative domain for it to work.

Yes you could: Distribute control information, not L2 data..

I.e. instead of having invented PPPoE, L2TP, MPLS, etc.. If we'd 
dealt with the fundamental management problems instead (that retail 
ISPs didn't have a way to exchange IP configuration information with 
wholesale ISPs, and have wholesale ISPs apply that information) then 
we'd today have much more efficient broadband networking.

Inventing one wouldn't have taken any extra thought over the other, 
except that telco people seem wedded to thinking of networking as 
circuits - so to solve problems they create things to make circuits..

You can continue to think these networks of circuits of networks of 
circuits of neto.... are a good thing, the reality is they're a 
kludge. It's provably inefficient, and it needn't have been so.

We might not be able to change it today, but we should try learn from 
it.

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
Age and treachery will always overcome youth and skill.


More information about the ILUG mailing list