Subject: Re: [rrg] Last call: Design goals

From: [email-masked]
Date: Thu, 21 Oct 2010 04:59:08 EDT

In einer eMail vom 20.10.2010 18:35:01 Westeuropäische Sommerzeit schreibt  
[email-masked]:

Hi  Heiner,

Thank you very much for commenting.

> 3.1. Improved  routing scalability
> It lacks naming the two aspects in the first  place: memory consumption 
and CPU-performance (update churn). Only thereafter  it makes sense to 
request independency from the internet user population. Why  is the control plane 
mentioned specifically? I don’t understand. It is neither  necessary nor 
correct.

The control plane subsumes the memory,  bandwidth and CPU required for 
routing, both within individual systems and  network-wide.  We distinguish from 
the data plane, which is the transit  traffic.  There are similar 
scalability issues in the data plane, but the  argument there is much more challenging 
to make and is not widely  accepted.

Ok.I thought RIB=Control-, FIB=Data-plane and that using the term  
control-plane wouldn’t get us any further. Nevertheless the issues should be  
mentioned and specified: The current enormous size of the Internet ( number of  
DFZ-routers =x, number of RIB-entries = y, number of FIB-entries=z). The  
continuing growth wrt size and tighter meshing(FIB-growth-factor=350,000 /  
310,000=1,13).The expiration of IPv4 addresses (number of unused addresses=  n)

>  3.2. Scalable support for traffic  engineering
> Bad English: The solutions should also be scalable also  wrt detouring 
routes. ( and not wrt to traffic engineering).

By  detour routes, I'm assuming that you're talking about FRR and similar  
technologies.  This would seem to be an independent issue and I don't  think 
we have any agreement that this is an inter-domain  issue.

But for multihoming there is agreement. And multihoming is  just a special 
case of alternate routing, i.e.FRR (if seen  logically; I know   according  
to IETF terminology these are completely different animals). My guess is: 
FRR is  enabled intra-domain, hence there is a demand for it, 
intra-domain-wide. FRR is  not enabled inter-domain, hence there is no demand for it, 
inter-domain  wide.
 
.

>  3.3. Scalable support for multi-homing
> It  wouldn’t be bad to mention that multi-homing is just a particular 
aspect of  multipath.

Sorry, I'm not seeing your point.  Does multi-path  support affect our 
design goals?  

See above

>  3.4. Scalable support for mobility
> We should also mention support of  PRIVACY (where is the roaming user at 
this moment). Privacy can always be  supported (i.e. by any solution) by 
employing a home agent who will or who  will not relay. We may need to deal 
with both options. The current text  fosters the belief that   some solution 
> may provide both  concurrently.

Agreed.  Added a comment:  

"Mechanisms that help to provide more
efficient  and scalable mobility support are desired, especially
when they can be coupled with security, _especially privacy_, and
support topological changes at a high-rate."

>  3.5. Simplified renumbering
> The best of all is not mentioned:  solutions which do not require any 
renumbering.

Fair enough.   Added.

> 3.6. Decoupling location and identification
> I  have strong doubts that this community has fully understood what 
loc/id-split  may mean.

This doesn't seem like a document where we should be  educating them.

Agreed:-)

> 3.7. First-class elements
> Half of this  paragraph is used to explain this weir headline.
> What is really  intended here, should be expressed simpler and without 
this  climbim.

Please propose text.  I realize that my background is  unique, but I know 
of no better way to accurately and concisely describe this  in polite and 
professional language.  Saying that "the architecture can't  be a kludge" or 
"no cheesy hacks" doesn't seem to be appropriate.   ;-)

I did read 3.7 a few more times. I assume it is much more general  i.e.not 
just about tunnels. Myself, I cannot even find another example for what  may 
be meant. Also, if I were asked to come up with a first example, I would  
never have pointed to tunnels

> 3.8. Routing quality
>  A lot of words in  order to get to the term “stretch”.
> I have my own suspicion why this  term had been invented (and why it has 
been adopted). I can imagine that  routing quality may also mean different 
aspects (QoS,…)

If you  would care to propose text, I would be happy to replace the current 
 definition.  This is taken from the academic literature, where they  
wanted a metric to evaluate routing quality.  Personally, I don't  consider it to 
be a very practical measure, as it ignores policy and the  granularity is 
poor.  A stretch of 2 is simply  disastrous.

 I cannot propose text immediately because it needs more discussion up 
front. Quality routing may
 I cannot propose text immediately because it needs more discussion up 
front. Quality routing may
address a) the applied algorithms, or b) the selection of first-class paths 
and links (QoS-paths/links).
Ad a)  (only) : It is up to the provisioned information and up to the 
algorithm itself how good or bad is 
the resulting routing technology.
1. Imho, it is NOT quality routing if the second best route is  –
eventually- completely out of scope.
2. My suspicion: “Stretch” was introduced by Dima while judging  his own 
hyperbolic concept in 
comparison with the status quo. Shortest path means shortest path, and any 
longer path should be 
as short as possible and as long as necessary. Going from A to B via C, 
rather than directly from A to B,
means stretch 2 (which wouldn’t be such disastrous:-).Thinking about 
concepts with some conceptually 
built-in stretch factor >1: 
(1)FEDERAL EXPRESS: All parcels are sent to Memphis,TE, then forwarded 
(2)PNNI with its logical group nodes’ topologies.
We may say: The concept itself should not enforce longer routes. Comments?  
3.We are far off from better routing which e.g. might enable state-less  
p2mp /mp2mp, or scoped broadcast.4.We are far off proper dealing with loops:  
crankback means loop. Eventually crankback provides the only available route 
!  Quality routing may mean “better routing”

>  3.9. Routing security
> No comment to this  place holder phrase.

Your sarcasm is not constructive.  If you  dislike the content, please 
propose alternate text.

The text is ok. I should have written “sentence” instead of “phrase”.

>  3.10. Deployability
> The first sentence can  be deleted (blabla only).
> Any solution which required a flag day is  out from the beginning.
> Yes, incremental deployability is definitely  required.
> However, I think that ALL solutions can provide this (all  the so far 
displayed as well as all not-yet born  solutions:-)

Clearly, this is not the case.  It is very clear  that one can propose a 
solution that there are non-deployable flag-day  solutions.  While they are 
not going to fall into anyone's definition of  common sense, it is incumbent 
on us to be clear about the requirements  anyway.  In fact, in the past, this 
was a significant point of  discussion.

Agreed.

>  Furthermore I miss 3.11: 
> The solution should also enable Moore's Law  as addressed in RFC4984

I'm sorry, I don't understand your  point.  As has been argued in 4984, 
Moore's Law is not the only  constraint that we must work with.  DRAM latency, 
for example, is NOT  subject to Moore's Law.  Care to propose text?
Will think about some text.

Regards,
Tony

Heiner

---

From: Tony Li <[email-masked]>
Date: Thu, 21 Oct 2010 09:38:28 -0700

Hi Heiner,

> Nevertheless the issues should be mentioned and specified: The current enormous size of the Internet ( number of DFZ-routers =x, number of RIB-entries = y, number of FIB-entries=z). The continuing growth wrt size and tighter meshing(FIB-growth-factor=350,000 / 310,000=1,13).The expiration of IPv4 addresses (number of unused addresses= n)

This really seems like material for the problem statement, more than the design goals.

> But for multihoming there is agreement. And multihoming is just a special case of alternate routing, i.e.FRR (if seen logically; I know   according to IETF terminology these are completely different animals). My guess is: FRR is enabled intra-domain, hence there is a demand for it, intra-domain-wide. FRR is not enabled inter-domain, hence there is no demand for it, inter-domain wide.

For multi-homing, there's already a separate section.  I'm not understanding what changes you're recommending.

> > It wouldn’t be bad to mention that multi-homing is just a particular aspect of multipath.
> 
> 
> Sorry, I'm not seeing your point.  Does multi-path support affect our design goals?  
> 
> See above

I'm still not seeing your point.

> > I have strong doubts that this community has fully understood what loc/id-split may mean.
> 
> 
> I did read 3.7 a few more times. I assume it is much more general i.e.not just about tunnels. Myself, I cannot even find another example for what may be meant. Also, if I were asked to come up with a first example, I would never have pointed to tunnels

Well, as I've commented to a few others, the text here clearly doesn't communicate my intent, but it's the best that I can do at expressing the intent while remaining professional.  I welcome alternate text.

> > 3.8. Routing quality
> I cannot propose text immediately because it needs more discussion up front. Quality routing may
> address a) the applied algorithms, or b) the selection of first-class paths and links (QoS-paths/links).
> Ad a)  (only) : It is up to the provisioned information and up to the algorithm itself how good or bad is 
> 1. Imho, it is NOT quality routing if the second best route is  –eventually- completely out of scope.
> 2. My suspicion: “Stretch” was introduced by Dima while judging  his own hyperbolic concept in 
> comparison with the status quo. Shortest path means shortest path, and any longer path should be 
> as short as possible and as long as necessary. Going from A to B via C, rather than directly from A to B,
> means stretch 2 (which wouldn’t be such disastrous:-).Thinking about concepts with some conceptually 
> 3.We are far off from better routing which e.g. might enable state-less p2mp /mp2mp, or scoped broadcast.4.We are far off proper dealing with loops: crankback means loop. Eventually crankback provides the only available route ! Quality routing may mean “better routing”

A couple of comments:

- AFAIK, the reference is the first usage of the term 'stretch' in the literature (2006), and unless someone has an earlier reference, I'm inclined to attribute this to the authors.

- Some people make their living on minimizing the bit*miles that their employers have to pay for.  For them stretch 2 is fatal.

Tony

---

From: "Stephen D. Strowes" <[email-masked]>
Date: Thu, 21 Oct 2010 17:59:43 +0100

Hi,

On Thu, 2010-10-21 at 17:38 +0100, Tony Li wrote:
> Heiner wrote:
> - AFAIK, the reference is the first usage of the term 'stretch' in the
> literature (2006), and unless someone has an earlier reference, I'm
> inclined to attribute this to the authors.

I'm not sure where the term was coined, but stretch is a well-known term
in compact routing literature. Certainly Peleg and Upfal used the term
in 1989 (c.f. "A Trade-Off between Space and Efficiency
for Routing Tables", http://portal.acm.org/citation.cfm?id=65953 ).
Without digging further back, I wouldn't be surprised if it was used
earlier, but the abstract for this paper seems to feature an
equally-good definition for the term.

Cheers,
-S.

---

From: Tony Li <[email-masked]>
Date: Thu, 21 Oct 2010 10:54:26 -0700

> equally-good definition for the term.

Thanks, we'll update to use that reference.

Tony

---

From: Paul Jakma <[email-masked]>
Date: Mon, 25 Oct 2010 14:01:18 +0100 (BST)

On Thu, 21 Oct 2010, Stephen D. Strowes wrote:

> I'm not sure where the term was coined, but stretch is a well-known 
> term in compact routing literature. Certainly Peleg and Upfal used 
> the term in 1989 (c.f. "A Trade-Off between Space and Efficiency 
> Without digging further back, I wouldn't be surprised if it was 
> used earlier, but the abstract for this paper seems to feature an 

I had a look back too this morn, and Kleinrock's '77 paper also talks 
about stretch ("increase in path length", eq. 24 - didn't coin 
stretch though ;) ).

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
Newton's Little-Known Seventh Law:
 	A bird in the hand is safer than one overhead.

---

From: [email-masked]
Date: Mon, 25 Oct 2010 17:43:18 -0400

> I'm not sure where the term was coined, but stretch is a well-known > term in compact routing literature.
Right.Compact routing discriminated hierarchical routing by asserting it would induce routes of stretch 17,e.g.. What kind of hierarchical routing was that? Obviously a bad concept.
Those  statements hurted my feeling, because I also conceived TARA routing (using  several hierarchies of zooms) to be some sort of hierarchical routing. For TARA shortest path still means shortest path. Period. And of course, TARA would also enable detours. 
For comparison: Current DV-based BGP would, eventually, disregard even  the second best route ! How would you call such a lousy concept ?!!!

As long as we are  devoted to shortest path, and as long as we try to use paths which are as short as possible and as long as necessary as to comply with the applied constraints we don't need any stretch metric. Stretch is appropriate if you have different concepts whereby these concepts themselves induce stretch>1  !!!

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Paul Jakma <[email-masked]>
An: Stephen D. Strowes <[email-masked]>
Cc: Tony Li <[email-masked]>; Paul Jakma <[email-masked]>; [email-masked] <[email-masked]>
Verschickt: Mo., 25. Okt. 2010, 15:01
Thema: Re: [rrg] Last call: Design goals

On Thu, 21 Oct 2010, Stephen D. Strowes wrote: 
 
> I'm not sure where the term was coined, but stretch is a well-known > term in compact routing literature. Certainly Peleg and Upfal used > the term in 1989 (c.f. "A Trade-Off between Space and Efficiency > for Routing Tables", http://portal.acm.org/citation.cfm?id=65953 ). > Without digging further back, I wouldn't be surprised if it was > used earlier, but the abstract for this paper seems to feature an > equally-good definition for the term. 
 
I had a look back too this morn, and Kleinrock's '77 paper also talks about stretch ("increase in path length", eq. 24 - didn't coin stretch though ;) ). 
 
regards, 
-- Paul Jakma  [email-masked]  Key ID: 64A2FF6A 
Fortune: 
Newton's Little-Known Seventh Law: 
   A bird in the hand is safer than one overhead. 
_______________________________________________ 
rrg mailing list 
[email-masked] 
http://www.irtf.org/mailman/listinfo/rrg

---

From: Patrick Frejborg <[email-masked]>
Date: Tue, 26 Oct 2010 21:40:06 +0300

On Tue, Oct 26, 2010 at 12:43 AM,  <[email-masked]> wrote:
> Right.Compact routing discriminated hierarchical routing by asserting it
> would induce routes of stretch 17,e.g.. What kind of hierarchical routing
> was that? Obviously a bad concept.
> Those  statements hurted my feeling, because I also conceived TARA routing
> (using  several hierarchies of zooms) to be some sort of hierarchical
> routing. For TARA shortest path still means shortest path. Period. And of
> course, TARA would also enable detours.

Hi Heiner,

I was also a little bit shocked - since I have proposed hIPv4  -when I
noticed that hierarchical routing is a bad choice...
But after studying a bunch of Compact Routing papers I discovered that
 when CR researchers are discussing hierarchical routing they are
actually discussing CIDR, i.e. routing tables are kept under control
by aggregating and summarizing prefixes - and a global flat address
space is used. With this concept there will be stretch issues, the
more compact RT the the more likely it is to have a high stretch value
for a session. If I got it all wrong I ask kindly the CR researchers
to correct me, thanks.

Think this is not the hierarchical routing TARA  is proposing, think
TARA falls into Landmark Routing category -there are papers available
on-line and I also found one draft
http://tools.ietf.org/html/draft-ietf-manet-lanmar-05:

   The concept of landmark routing was first introduced in wired area
   networks [6].  The original scheme required predefined multi-level
   hierarchical addressing.  The hierarchical address of each node
   reflects its position within the hierarchy and helps to find a route
   to it.  Each node knows the routes to all the nodes within its
   hierarchical partition.  Moreover, each node knows the routes to
   various landmarks at different hierarchical levels.  Packet
   forwarding is consistent with the landmark hierarchy and the path
   is gradually refined from the top level hierarchy to lower levels
   as a packet approaches its destination.

You might find the paper of Paul Francis Tsuchiya. "The Landmark
hierarchy: a new hierarchy for routing in very large networks"
interesting

There is also a very nice explanation of the stretch issue in the
paper, see section 2.1 Area Hierarchy

I also think CR researchers are assuming that the session leverages a
single path between the two endpoints - this is a fair assumption
since the majority of the sessions are either TCP or UDP based. What
if in the future (if it ever happens), most of the sessions are
multipath enabled sessions and the endpoints can have several exit and
entry points between the private network and Internet (multi-homing).
E.g. the initiator have two attachment points to Internet, also the
receiver has two attachment points to Internet. Then the endpoints can
setup four subflows and the transport protocol will most likely found
out which of the subflows have the best throughput, i.e. the lowest
stretch (assuming no congestion occurs) . Thus the question is, to
which degree should the stretch issued be/can be solved by the routing
architecture, how much will/can be solved by a multipath enabled
transport protocol?

Patrick

---

From: [email-masked]
Date: Tue, 26 Oct 2010 18:25:57 -0400

Indeed, TARA is different by employing in principle 64800 hierarchies such that a router can see precisely that  excerpt of  the internet topology from that geopatch it belongs to by itself, plus the well-skimmed network of the surrounding geopatch cluster (= lesser zoom), plus..., plus the most intensively skimmed topology from the entire globe.

I am not an expert in compact routing. The good thing: The CR experts realized themselves how bad it is, hence came up with the term stretch as to measure its weakness.
Imho "stretch" is to measure the degree of weakness of the architecture under test.
Stretch 17 disqualifies any architecture for sure that causes such poor routing. Stretch 2 can be very reasonable wrt time-of-day routing, i.e.by taking either the west-bound or the east-bound route such that the   sleeping part of the globe is preferrably passed. But try that with today's routing architecture, or with LISP, or with ILNP !  No chance.

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Patrick Frejborg <[email-masked]>
An: [email-masked]
Cc: [email-masked]
Verschickt: Di., 26. Okt. 2010, 20:40
Thema: Re: [rrg] Last call: Design goals

Hi Heiner,

Patrick

---

From: "Stephen D. Strowes" <[email-masked]>
Date: Tue, 26 Oct 2010 23:53:47 +0100

On Tue, 2010-10-26 at 23:25 +0100, [email-masked] wrote:
> I am not an expert in compact routing. The good thing: The CR experts
> realized themselves how bad it is, hence came up with the term stretch
> as to measure its weakness.

Amusing, but wrong. Stretch is a quantifiable measure of how _well_ a
routing algorithm performs, and is used in the compact routing work as
the primary trade-off against routing state. In particular, the
algorithms presented in the literature define provable bounds on
achievable state with respect to the state requirements.

Cheers,
-S.

---

From: "Stephen D. Strowes" <[email-masked]>
Date: Tue, 26 Oct 2010 23:55:53 +0100

> achievable state with respect to the state requirements.

s/state/stretch/

-S.