From Heinrich.Hummel@icn.siemens.de  Tue Aug  6 02:41:31 2002
Received: from someone claiming to be gorilla.mchh.siemens.de
	puck.NOSPAM (gorilla.mchh.siemens.de [194.138.158.18])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with ESMTP id g766fUs3006900
	for <irtf-rr@puck.nether.net>; Tue, 6 Aug 2002 02:41:30 -0400
	(envelope-from Heinrich.Hummel@icn.siemens.de)
Received-Date: Tue, 6 Aug 2002 02:41:30 -0400
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id IAA25457;
	Tue, 6 Aug 2002 08:39:27 +0200 (MET DST)
Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id IAA29038;
	Tue, 6 Aug 2002 08:39:28 +0200 (MET DST)
Received: by MCHH246E with Internet Mail Service (5.5.2656.59)
	id <PTSZDQ5N>; Tue, 6 Aug 2002 08:39:12 +0200
Message-ID: <EF8E39AA846CD411BB9C00508B951F510514B983@MCHH267E>
From: Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>
To: "'Ibrahim Matta'" <matta@cs.bu.edu>,
   "Naidu, Venkata"
	 <Venkata.Naidu@marconi.com>
Cc: "'Ayyasamy, Senthilkumar (UMKC-Student)'" <saq66@umkc.edu>,
   Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>, jnc@ginger.lcs.mit.edu,
   fred@cisco.com, irtf-rr@puck.nether.net, routing-discussion@ietf.org
Date: Tue, 6 Aug 2002 08:39:10 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="ISO-8859-1"
Subject: [Irtf-rr] AW: Differentiated Routing, not only plain rambo-SPF
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

 

"Naidu, Venkata" wrote:
>   Simply, SPs can map 2 different services [example,
>   2 different CoS-types] to these different metrics.
>   Effectively we *are* doing DiffRouting...previously
>   there is no name for it...(and we are getting panicked
>   that we are facing a new/unresovable/performace
>   implicated problem here).
> 
Ibrahim wrote:

How is "DiffRouting" different from
old Type-of-Service (ToS) routing?

My answer:
By constructing multiple road systems, which  eventually are even constructed in awareness of
road systems constructed before (e.g. overflow road system X-overflow w.r.t. road system X)
and to lock traffic into some road system so that it is kept out of the way from other traffic. It may mean not to
take the shortest path for the individual micro flow.

Heinrich



http://www.faqs.org/rfcs/rfc1349.html
http://www.cs.bu.edu/fac/matta/Papers/jsac95.ps

ibrahim


--
Ibrahim Matta       Dept of Comp Sci, 111 Cummington St, MCS-271
matta@cs.bu.edu     Assistant Prof, Boston Univ., Boston, MA 02215
Tel: (617)358-1062, Fax: (617)353-6457, URL: www.cs.bu.edu/fac/matta/

From Heinrich.Hummel@icn.siemens.de  Tue Aug  6 03:33:32 2002
Received: from someone claiming to be gorilla.mchh.siemens.de
	puck.NOSPAM (gorilla.mchh.siemens.de [194.138.158.18])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with ESMTP id g767XVs3011163
	for <irtf-rr@puck.nether.net>; Tue, 6 Aug 2002 03:33:31 -0400
	(envelope-from Heinrich.Hummel@icn.siemens.de)
Received-Date: Tue, 6 Aug 2002 03:33:31 -0400
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA29369;
	Tue, 6 Aug 2002 09:31:28 +0200 (MET DST)
Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id JAA21703;
	Tue, 6 Aug 2002 09:31:30 +0200 (MET DST)
Received: by MCHH274E with Internet Mail Service (5.5.2656.59)
	id <P83CGKP6>; Tue, 6 Aug 2002 09:31:14 +0200
Message-ID: <EF8E39AA846CD411BB9C00508B951F510514B984@MCHH267E>
From: Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>
To: "'Naidu, Venkata'" <Venkata.Naidu@Marconi.com>,
   "'Ayyasamy, Senthilkumar  (UMKC-Student)'" <saq66@umkc.edu>,
   Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>
Cc: jnc@ginger.lcs.mit.edu, fred@cisco.com, irtf-rr@puck.nether.net,
   routing-discussion@ietf.org
Date: Tue, 6 Aug 2002 09:31:11 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: [Irtf-rr] AW: Differentiated Routing, not only plain rambo-SPF
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

I am really surprised that the need for having several routing table is =
a big (scalability) issue:
(BTW:Logically it takes separate routing tables, one per DSCP. But you =
may as well maintain one routing table
 and search the next hop entry also based on the DSCP)

IMO stateless DiffRout-Forwarding is more scalable than MPLS or RSVP.

However,if the size of the routing table is an issue, then why wasn't =
it an issue so far:
Each ingress node needs to know the egress node before setting up the =
respective next hop entry in the routing table.
So why doesn't the IP header contain a field for the destination router =
address. It would allow to keep the routing tables
small: one single next hop entry w.r.t. each destination router would =
be sufficient.
Of course, it would be rediculous to expect any change in IPv4. But why =
wasn't this an issue for IPv6 ?
When IPv6 was born, I guess there have already been routing tables of =
respectful size.
Can anyone tell me?

Heinrich


-----Urspr=FCngliche Nachricht-----
Von: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com]
Gesendet: Montag, 5. August 2002 21:33
An: 'Ayyasamy, Senthilkumar (UMKC-Student)'; Hummel Heinrich
Cc: jnc@ginger.lcs.mit.edu; fred@cisco.com; irtf-rr@puck.nether.net;
routing-discussion@ietf.org
Betreff: RE: Differentiated Routing, not only plain rambo-SPF


Senthil,

-> > There is no difference between MPLS-TE and=20
-> DiffServ-aware-MPLS-> TE? In other=20
-> > words, are you saying that Differv-aware-MPLS-TE=20
-> > is notgoing solve ANY problem that MPLS-TE alone couldn't=20
-> > solve ?
-> I was just talking about diffserv aware MPLS TE which is=20
-> more related to=20
-> the context of discussion. The authors of diffserv MPLS TE=20
-> draft discusses scalability problems.

  Yes! I am also talking about DiffServ-aware-MPLS-TE.
  In the draft-ietf-tewg-diff-te-reqts-05.txt authors
  clearly mentioned about problem statement and how we
  can benefit from DiffServ-aware-MPLS-TE (even if there
  are some scalability issues). Effectively, authors
  are trying to solve SOME problem - then how can=20
  you can say that DiffServ-aware-MPLS-TE (aka DiffRouting)
  is not going to solve ANY problem.

  Scalability issues in TOS Routing are different
  from scalability issues in DiffRouting (if you consider
  TOS routing is applicable in traditional hop-by-hop
  routing case and DiffRouting is applicable in todays
  source routing cases).

  Finally, let me conclude what I agree and disagree
  with you.

  What I agree:
  - None of these approaches [traditional TOS-Routing or
    DiffRouting (DiffServ-aware-MPLS-TE)] really solve
    end-to-end QoS/Performance. I already expressed this
    concern to Fred Baker (which he concluded that as
    an open ended question) - which is fine!
http://www1.ietf.org/mail-archive/working-groups/routing-discussion/curr=
ent/
msg00060.html

  - None of the above approaches are complete. They have
    some common and some different issues - for example
    scalability etc etc

  What I don't agree (my view):
  - Just because a solution has scalability issues doesn't
    mean that that solution is not going to solve ANY=20
    problem.

  - Diffserv-aware-MPLS-TE is trying to solve different problems
    which we couldn't solve with traditional routing approaches
    *easily* in the past.

  - We are trying to solve (we will solve) those scalability
    issues in source routing (using hierarchical TE etc etc)
    in future.

  Do you agree? If not let me know - let us discuss :)

  If you still feel that DiffRouting is not going to solve=20
  ANY problem then I will ask authors of=20
  draft-ietf-tewg-diff-te-reqts-05.txt (for clarification).
 =20
  Finally, you didn't tell me in what other approaches
  we can solve the same issues that the DiffServ-TE is
  trying to solve (with out letting control plane know,
  with out CSPF, with out connection-oriented MPLS etc etc).
 =20
--
Venkata

From saq66@umkc.edu  Tue Aug  6 04:14:35 2002
Received: from someone claiming to be kc-msxproto2.kc.umkc.edu
	puck.NOSPAM (kc-msxproto2.kc.umkc.edu [134.193.143.159])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with ESMTP id g768EZs3012231
	for <irtf-rr@puck.nether.net>; Tue, 6 Aug 2002 04:14:35 -0400
	(envelope-from saq66@umkc.edu)
Received-Date: Tue, 6 Aug 2002 04:14:35 -0400
Received: from KC-MAIL2.kc.umkc.edu ([134.193.143.162] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 6 Aug 2002 03:12:38 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 6 Aug 2002 03:12:37 -0500
Message-ID: <A29143A40AEAE3459FF829D1DD4331613C252C@KC-MAIL2.kc.umkc.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Differentiated Routing, not only plain rambo-SPF
Thread-Index: AcI9G085wsGx+1RERr2x31U9RMfHBgAAiCMA
From: "Ayyasamy, Senthilkumar  (UMKC-Student)" <saq66@umkc.edu>
To: "Hummel Heinrich" <Heinrich.Hummel@icn.siemens.de>,
   "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
Cc: <jnc@ginger.lcs.mit.edu>, <fred@cisco.com>, <irtf-rr@puck.nether.net>,
   <routing-discussion@ietf.org>
X-OriginalArrivalTime: 06 Aug 2002 08:12:38.0303 (UTC) FILETIME=[07275AF0:01C23D21]
Subject: [Irtf-rr] RE: Differentiated Routing, not only plain rambo-SPF
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

> I am really surprised that the need for having several=20
> routing table is a big (scalability) issue:
> (BTW:Logically it takes separate routing tables, one per=20
> DSCP. But you may as well maintain one routing table
>  and search the next hop entry also based on the DSCP)
> IMO stateless DiffRout-Forwarding is more scalable than MPLS or RSVP.
  Yes diffserv forwarding is less stateful when compared to MPLS=20
or RSVP. But that has nothing to do with scalability problems in =
maintaining=20
multiple routing tables.=20
There are scalability issues wrt single routing table itself. People are =
still=20
working on scalable solutions for mimizing the overhead, wrt adding =
mechanisms=20
like accounting and other valued added measurement functions, which =
requires=20
processing of pkts at line rate. So i am guessing, scalablity associated =
with=20
multiple routing tables, will be a long shot.

See again you have started with diffrout, then it was changed to =
diffser-aware-TE=20
and now mechanisms for basic diffserv arch.=20

> However,if the size of the routing table is an issue, then=20
> why wasn't it an issue so far:
> Each ingress node needs to know the egress node before=20
> setting up the respective next hop entry in the routing table.
> So why doesn't the IP header contain a field for the=20
> destination router address. It would allow to keep the routing tables
> small: one single next hop entry w.r.t. each destination=20
> router would be sufficient.
> Of course, it would be rediculous to expect any change in=20
> IPv4. But why wasn't this an issue for IPv6 ?
> When IPv6 was born, I guess there have already been routing=20
> tables of respectful size.
> Can anyone tell me?

From routing-discussion-admin@ietf.org  Tue Aug  6 04:34:56 2002
Received: from someone claiming to be n2.nomadiclab.com
	puck.NOSPAM (n2.nomadiclab.com [131.160.193.2])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with ESMTP id g768Yms3014955
	for <irtf-rr@puck.nether.net>; Tue, 6 Aug 2002 04:34:49 -0400
	(envelope-from routing-discussion-admin@ietf.org)
Received-Date: Tue, 6 Aug 2002 04:34:49 -0400
Received: by n2.nomadiclab.com (Postfix, from userid 962)
	id E688D22E1B; Tue,  6 Aug 2002 11:33:55 +0300 (EEST)
Received: from d2.nomadiclab.com (bastion [131.160.194.2])
	by n2.nomadiclab.com (Postfix) with ESMTP id 4459F22E13
	for <pekka.nikander@nomadiclab.com>; Tue,  6 Aug 2002 11:33:49 +0300 (EEST)
Received: from optimus.ietf.org (ietf.org [132.151.1.19])
	by d2.nomadiclab.com (Postfix) with ESMTP id 824A16CCAD
	for <pekka.nikander@nomadiclab.com>; Tue,  6 Aug 2002 08:34:04 +0300 (EEST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12044;
	Tue, 6 Aug 2002 04:12:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12014
	for <routing-discussion@optimus.ietf.org>; Tue, 6 Aug 2002 04:12:39 -0400 (EDT)
Received: from kc-msxproto2.kc.umkc.edu (kc-msxproto2.kc.umkc.edu [134.193.143.159])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28965
	for <routing-discussion@ietf.org>; Tue, 6 Aug 2002 04:11:25 -0400 (EDT)
Received: from KC-MAIL2.kc.umkc.edu ([134.193.143.162] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 6 Aug 2002 03:12:38 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Tue, 6 Aug 2002 03:12:37 -0500
Message-ID: <A29143A40AEAE3459FF829D1DD4331613C252C@KC-MAIL2.kc.umkc.edu>
Thread-Topic: Differentiated Routing, not only plain rambo-SPF
Thread-Index: AcI9G085wsGx+1RERr2x31U9RMfHBgAAiCMA
From: "Ayyasamy, Senthilkumar  (UMKC-Student)" <saq66@umkc.edu>
To: "Hummel Heinrich" <Heinrich.Hummel@icn.siemens.de>,
   "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
Cc: <jnc@ginger.lcs.mit.edu>, <fred@cisco.com>, <irtf-rr@puck.nether.net>,
   <routing-discussion@ietf.org>
X-OriginalArrivalTime: 06 Aug 2002 08:12:38.0303 (UTC) FILETIME=[07275AF0:01C23D21]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA12015
X-Mailman-Version: 1.0
Precedence: bulk
X-BeenThere: routing-discussion@ietf.org
X-Spam-Status: No, hits=0.4 required=5.0
	tests=FROM_ENDS_IN_NUMS
	version=2.31
X-Spam-Level: 
Subject: [Irtf-rr] RE: Differentiated Routing, not only plain rambo-SPF
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

> I am really surprised that the need for having several 
> routing table is a big (scalability) issue:
> (BTW:Logically it takes separate routing tables, one per 
> DSCP. But you may as well maintain one routing table
>  and search the next hop entry also based on the DSCP)
> IMO stateless DiffRout-Forwarding is more scalable than MPLS or RSVP.
  Yes diffserv forwarding is less stateful when compared to MPLS 
or RSVP. But that has nothing to do with scalability problems in maintaining 
multiple routing tables. 
There are scalability issues wrt single routing table itself. People are still 
working on scalable solutions for mimizing the overhead, wrt adding mechanisms 
like accounting and other valued added measurement functions, which requires 
processing of pkts at line rate. So i am guessing, scalablity associated with 
multiple routing tables, will be a long shot.

See again you have started with diffrout, then it was changed to diffser-aware-TE 
and now mechanisms for basic diffserv arch. 

> However,if the size of the routing table is an issue, then 
> why wasn't it an issue so far:
> Each ingress node needs to know the egress node before 
> setting up the respective next hop entry in the routing table.
> So why doesn't the IP header contain a field for the 
> destination router address. It would allow to keep the routing tables
> small: one single next hop entry w.r.t. each destination 
> router would be sufficient.
> Of course, it would be rediculous to expect any change in 
> IPv4. But why wasn't this an issue for IPv6 ?
> When IPv6 was born, I guess there have already been routing 
> tables of respectful size.
> Can anyone tell me?

_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org
https://www1.ietf.org/mailman/listinfo/routing-discussion

From Heinrich.Hummel@icn.siemens.de  Tue Aug  6 06:05:27 2002
Received: from someone claiming to be gorilla.mchh.siemens.de
	puck.NOSPAM (gorilla.mchh.siemens.de [194.138.158.18])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with ESMTP id g76A5Qs3018755
	for <irtf-rr@puck.nether.net>; Tue, 6 Aug 2002 06:05:27 -0400
	(envelope-from Heinrich.Hummel@icn.siemens.de)
Received-Date: Tue, 6 Aug 2002 06:05:27 -0400
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA17417;
	Tue, 6 Aug 2002 12:03:18 +0200 (MET DST)
Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id MAA13479;
	Tue, 6 Aug 2002 12:03:19 +0200 (MET DST)
Received: by MCHH246E with Internet Mail Service (5.5.2656.59)
	id <PTSZDZJT>; Tue, 6 Aug 2002 12:03:03 +0200
Message-ID: <EF8E39AA846CD411BB9C00508B951F510514B985@MCHH267E>
From: Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>
To: "'Ayyasamy, Senthilkumar  (UMKC-Student)'" <saq66@umkc.edu>,
   "Naidu, Venkata" <Venkata.Naidu@Marconi.com>,
   Hummel Heinrich
	 <Heinrich.Hummel@icn.siemens.de>
Cc: jnc@ginger.lcs.mit.edu, fred@cisco.com, irtf-rr@puck.nether.net,
   routing-discussion@ietf.org
Date: Tue, 6 Aug 2002 12:03:02 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="ISO-8859-1"
Subject: [Irtf-rr] AW: Differentiated Routing, not only plain rambo-SPF
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

 

Hummel, was your original proposal same like Diffserv-aware-TE. I thought
it was different.

My answer:
DiffRout is definitively different.

My motivation and my key thoughts to open this discussions have been:
- combine the best of Intserv/MPLS and Diffserv and as a result do stateless IP forwarding but get
     what  Intserv/MPLS are providing: Qos/BW/Policy/Traffic balancing/rerouting.

- therefore construct road systems and do IP forwarding/routing also based on DSCP.

- the road systems may have assigned bandwidth. This is reasonable/feasable because some traffic can really
  be locked into some slim road system (smallest size tree, smallest ring) just like MPLS traffic can be locked into
  some LSP. Whereas with rambo-SPF bandwidth assignment makes no sense as the sum of all
  shortest path trees computed by all the nodes would span the entire network, i.e. spread traffic all over it.
  The price for staying within some road system should be acceptable: Eventually, make a few hops more.
  Based on my computations, the smallest size tree may be smaller than the avarage shortest path tree by 15-20 %. 
  So I think the detour for the packets will not be very big either.   

- be guided by what you can observe on daily road traffic: Especially in the U.S. there are so many ramp-based
  road junctions, which are more impressive than any traffic light controlled junction, so that motor-cyclists may
  jump the queue of waiting cars (=DiffServ) if the traffic light is red. 
  There are so many observations that can be made watching how the traffic is managed for cars, 
  trains, airplanes, pedestrians, etc. We all are used to it and don't discern extra smartness in it. However there is.
      
- and I realized what is the big obstacle: Yes it is this rambo-SPF routing paradigma. It does not represent the  
  surveillant view, only the egomanic view, combined with the hope that in total you get best results because 
  "the streets are emptiest when each car takes the shortest route":-). 



Heinrich
   
    




 

From jshen@cad.zju.edu.cn  Tue Aug  6 09:03:30 2002
Received: from someone claiming to be mail.cad.zju.edu.cn
	puck.NOSPAM (cad.zju.edu.cn [210.32.131.2])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with SMTP id g76D3Os3026405
	for <irtf-rr@puck.nether.net>; Tue, 6 Aug 2002 09:03:25 -0400
	(envelope-from jshen@cad.zju.edu.cn)
Received-Date: Tue, 6 Aug 2002 09:03:25 -0400
Received: (qmail 22737 invoked from network); 6 Aug 2002 13:08:54 -0000
Received: from unknown (HELO cad.zju.edu.cn) (210.32.131.97)
  by 210.32.131.2 with SMTP; 6 Aug 2002 13:08:54 -0000
Message-ID: <3D4FC927.2CF8E99E@cad.zju.edu.cn>
Date: Tue, 06 Aug 2002 21:03:36 +0800
From: shen jing <jshen@cad.zju.edu.cn>
Reply-To: jshen@cad.zju.edu.cn
Organization: State Key Lab of CAD&CG
X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>
CC: irtf-rr@puck.nether.net, routing-discussion@ietf.org
References: <EF8E39AA846CD411BB9C00508B951F510514B985@MCHH267E>
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit
Subject: [Irtf-rr] Re: Differentiated Routing, not only plain rambo-SPF
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

Hi Hummel,

As DSCP is used for packet queueing in routers,  there may be many types of  queueing mechanism for scheduling of
different classes.

As mentioned in previous message that when overflow/congestion happens along some path, the flow of the same  DSCP
could be overflowed onto other path (?) or it could be dispersed onto multiple paths computed.
This means, if we want to adapt to time-varying network status  LSA must be triggered by overflow of any queue on its
outgoing interface. Because internet traffic's self-similarity characteristics and "heavy-tailed" flow sized distribution,
  we
could not expect the network status maintains a stable status. That is,  routing behavior have to be adjusted frequently.
Right ?  CBQ or the like may adjust the resource allocated dynamically according to load on routers, how could that be
reflected ?   I think, all these factors will do harm to routing stability and extensibility, esp. when we consider
inter-AS routing.

Well, I think some time to read those paper suggested.


>
>
> Hummel, was your original proposal same like Diffserv-aware-TE. I thought
> it was different.
>
> My answer:
> DiffRout is definitively different.
>
> My motivation and my key thoughts to open this discussions have been:
> - combine the best of Intserv/MPLS and Diffserv and as a result do stateless IP forwarding but get
>      what  Intserv/MPLS are providing: Qos/BW/Policy/Traffic balancing/rerouting.
>
> - therefore construct road systems and do IP forwarding/routing also based on DSCP.
>
> - the road systems may have assigned bandwidth. This is reasonable/feasable because some traffic can really
>   be locked into some slim road system (smallest size tree, smallest ring) just like MPLS traffic can be locked into
>   some LSP. Whereas with rambo-SPF bandwidth assignment makes no sense as the sum of all
>   shortest path trees computed by all the nodes would span the entire network, i.e. spread traffic all over it.
>   The price for staying within some road system should be acceptable: Eventually, make a few hops more.
>   Based on my computations, the smallest size tree may be smaller than the avarage shortest path tree by 15-20 %.
>   So I think the detour for the packets will not be very big either.
>
> - be guided by what you can observe on daily road traffic: Especially in the U.S. there are so many ramp-based
>   road junctions, which are more impressive than any traffic light controlled junction, so that motor-cyclists may
>   jump the queue of waiting cars (=DiffServ) if the traffic light is red.
>   There are so many observations that can be made watching how the traffic is managed for cars,
>   trains, airplanes, pedestrians, etc. We all are used to it and don't discern extra smartness in it. However there is.
>
> - and I realized what is the big obstacle: Yes it is this rambo-SPF routing paradigma. It does not represent the
>   surveillant view, only the egomanic view, combined with the hope that in total you get best results because
>   "the streets are emptiest when each car takes the shortest route":-).
>
> Heinrich
>
>
>
>
>
> _______________________________________________
> routing-discussion mailing list
> routing-discussion@ietf.org
> https://www1.ietf.org/mailman/listinfo/routing-discussion

--
Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, Z.J. 310027
P.R.China

Tel: +86-571-87932423

Email: jshen@cad.zju.edu.cn

**********************************************************************
* The SunShine of life is made up of very little beams which is      *
*  bright all the time                                               *
**********************************************************************




From Heinrich.Hummel@icn.siemens.de  Mon Aug 12 05:30:34 2002
Received: from someone claiming to be beamer.mchh.siemens.de
	puck.NOSPAM (beamer.mchh.siemens.de [194.138.158.163])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with ESMTP id g7C9UXs3000560
	for <irtf-rr@puck.nether.net>; Mon, 12 Aug 2002 05:30:33 -0400
	(envelope-from Heinrich.Hummel@icn.siemens.de)
Received-Date: Mon, 12 Aug 2002 05:30:33 -0400
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA27131;
	Mon, 12 Aug 2002 11:30:55 +0200 (MET DST)
Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA20967;
	Mon, 12 Aug 2002 11:31:14 +0200 (MET DST)
Received: by MCHH273E with Internet Mail Service (5.5.2656.59)
	id <P71R1ZGR>; Mon, 12 Aug 2002 11:30:51 +0200
Message-ID: <EF8E39AA846CD411BB9C00508B951F510514B98F@MCHH267E>
From: Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>
To: "'Michael Menth'" <menth@informatik.uni-wuerzburg.de>,
   "'routing-discussion@ietf.org'" <routing-discussion@ietf.org>,
   irtf-rr@puck.nether.net
Date: Mon, 12 Aug 2002 11:30:36 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: [Irtf-rr] AW: Dijkstra died.
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

Michael,
I am sure you agree to spread this news
via the routing discussion and IRTF routing research mailing lists.
Heinrich

-----Urspr=FCngliche Nachricht-----
Von: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]
Gesendet: Donnerstag, 8. August 2002 12:41
An: undisclosed-recipients
Betreff: Dijkstra died.



Dear friends,

Professor Edsger Wybe Dijkstra (shortest path, semaphores, etc.) has=20
passed away. A moment of silence for the great man.

Kind regards, Michael

http://www.cs.utexas.edu/users/UTCS/notices/dijkstra/ewdobit.html
http://lwn.net/Articles/6993/
http://www.lwn.net/Articles/6954/

--=20
Dipl.-Inform. Michael Menth
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room A212
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:menth@informatik.uni-wuerzburg.de
http://www-info3.informatik.uni-wuerzburg.de/~menth

From Heinrich.Hummel@icn.siemens.de  Mon Aug 12 11:02:49 2002
Received: from someone claiming to be gorilla.mchh.siemens.de
	puck.NOSPAM (gorilla.mchh.siemens.de [194.138.158.18])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with ESMTP id g7CF2ls3013060
	for <irtf-rr@puck.nether.net>; Mon, 12 Aug 2002 11:02:48 -0400
	(envelope-from Heinrich.Hummel@icn.siemens.de)
Received-Date: Mon, 12 Aug 2002 11:02:48 -0400
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA10822;
	Mon, 12 Aug 2002 17:03:24 +0200 (MET DST)
Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA22672;
	Mon, 12 Aug 2002 17:03:23 +0200 (MET DST)
Received: by MCHH247E with Internet Mail Service (5.5.2656.59)
	id <P71TXVBD>; Mon, 12 Aug 2002 17:02:59 +0200
Message-ID: <EF8E39AA846CD411BB9C00508B951F510514B992@MCHH267E>
From: Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>
To: "'jshen@cad.zju.edu.cn'" <jshen@cad.zju.edu.cn>,
   Hummel Heinrich
	 <Heinrich.Hummel@icn.siemens.de>
Cc: irtf-rr@puck.nether.net, routing-discussion@ietf.org
Date: Mon, 12 Aug 2002 17:02:57 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable
Subject: [Irtf-rr] AW: Differentiated Routing, not only plain rambo-SPF
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

Jing,
Let me recapture and use the following DSCPs:=20
DSCP-Gold-1st, DSCP-Gold-2nd, =
DSCP-Silver-1st,DSCP-Silver-2nd,DSCP-Bronze-1st,DSCP-Bronze-2nd.=20

DSCP-Gold-1st and DSCP-Gold-2nd shall trigger DiffServ Gold-SLA =
handling.
DSCP-Silver-1st and DSCP-Silver-2nd shall trigger DiffServ Silver-SLA =
handling.
DSCP-Bronze-1st and DSCP-Bronze-2nd shall trigger DiffServ Bronze-SLA =
handling.=20

They shall as well identify road systems:=20
DSCP-Gold-1st, DSCP-Gold-2nd, =
DSCP-Silver-1st,DSCP-Silver-2nd,DSCP-Bronze-1st,DSCP-Bronze-2nd - built =
in this
sequence. Hereby each road system is based on what has been left over =
by the previously built road systems (in terms of
bandwidth).

Gold:  A smallest size tree of toll roads, highways, state roads, =
country roads.
Silver:A smallest size tree of highways, state roads, country roads.
Bronze:A smallest size tree of state roads, country roads, and highways =
only if no path otherwise.
=20
QoS parameters (speed, packet loss rate, MTU size,..) may define the =
type of road.

1st and 2nd road system may be different at least  w.r.t. their kernel =
parts. (The kernel part be that=20
center of the smallest size tree, which is used by at least m =
ingress/egress combinations).
Either traffic starts out with a) proper DSCP-Y-1st, resp. DSCP-Y-2nd, =
or b) is  changed from DSCP-Y-1st to
DSCP-Y-2nd at the rim of the kernel if some current traffic load =
information advises so. I prefer a) and if possible such
that any microflow will entirely take one single route.

Jing, you are mentioning two aspects, namely stability and =
extensibility.
Stability:=20
We may toss a dice at the ingress,i.e. determine a random number Y =
between 0.0 and 1.0. If =20
0.0<=3D Y < a, then we use DSCP-Y-1st, if a<=3D Y < 1, then we use =
DSCP-Y-2nd. The real number a should be such
that we avoid/dissolve some congestion and do not relocate it. At =
low-traffic times a is equal 1. But for the busy hour
determining value a  will be a very interesting topic.=20
If any  University folks were interested in doing simulations as to =
determine value a for all ingress/egress combinations
and for all three SLAs, I would be happy to exchange more thoughts and =
details on it (so far I have always deferred it).
Especially, it would be interesting to get comparable results between =
what I called "Orchestrally Conducted Traffic" and
OMP.
However we would be leaving  the DiffRout-track of thoughts. Therefore =
we should say: this is out of scope of this thread.=20
It may only be addressed by some other thread.

Extensibility:
So far I have no solution, on how to determine a smallest size tree =
made out of OSPF-links and EBGP/IBGP-hops.
BTW:
It seems to be appropriate to focus on  smallest size tree road =
systems, at least for some time, although ring and
somehow meshy road systems might also be considered.=20

Can anybody contribute some  solution ? I think, it must be an =
identical tree of BGP-hops. Only all edge routers of the
same OSPF network must aquire the completely identical tree. Somehow:-)


Heinrich=20

-----Urspr=A8=B9ngliche Nachricht-----
Von: shen jing [mailto:jshen@cad.zju.edu.cn]
Gesendet: Dienstag, 6. August 2002 15:04
An: Hummel Heinrich
Cc: irtf-rr@puck.nether.net; routing-discussion@ietf.org
Betreff: Re: Differentiated Routing, not only plain rambo-SPF


Hi Hummel,

As DSCP is used for packet queueing in routers,  there may be many =
types of  queueing mechanism for scheduling of
different classes.

As mentioned in previous message that when overflow/congestion happens =
along some path, the flow of the same  DSCP
could be overflowed onto other path (?) or it could be dispersed onto =
multiple paths computed.
This means, if we want to adapt to time-varying network status  LSA =
must be triggered by overflow of any queue on its
outgoing interface. Because internet traffic's self-similarity =
characteristics and "heavy-tailed" flow sized distribution,
  we
could not expect the network status maintains a stable status. That is, =
 routing behavior have to be adjusted frequently.
Right ?  CBQ or the like may adjust the resource allocated dynamically =
according to load on routers, how could that be
reflected ?   I think, all these factors will do harm to routing =
stability and extensibility, esp. when we consider
inter-AS routing.

Well, I think some time to read those paper suggested.


>
>
> Hummel, was your original proposal same like Diffserv-aware-TE. I =
thought
> it was different.
>
> My answer:
> DiffRout is definitively different.
>
> My motivation and my key thoughts to open this discussions have been:
> - combine the best of Intserv/MPLS and Diffserv and as a result do =
stateless IP forwarding but get
>      what  Intserv/MPLS are providing: Qos/BW/Policy/Traffic =
balancing/rerouting.
>
> - therefore construct road systems and do IP forwarding/routing also =
based on DSCP.
>
> - the road systems may have assigned bandwidth. This is =
reasonable/feasable because some traffic can really
>   be locked into some slim road system (smallest size tree, smallest =
ring) just like MPLS traffic can be locked into
>   some LSP. Whereas with rambo-SPF bandwidth assignment makes no =
sense as the sum of all
>   shortest path trees computed by all the nodes would span the entire =
network, i.e. spread traffic all over it.
>   The price for staying within some road system should be acceptable: =
Eventually, make a few hops more.
>   Based on my computations, the smallest size tree may be smaller =
than the avarage shortest path tree by 15-20 %.
>   So I think the detour for the packets will not be very big either.
>
> - be guided by what you can observe on daily road traffic: Especially =
in the U.S. there are so many ramp-based
>   road junctions, which are more impressive than any traffic light =
controlled junction, so that motor-cyclists may
>   jump the queue of waiting cars (=3DDiffServ) if the traffic light =
is red.
>   There are so many observations that can be made watching how the =
traffic is managed for cars,
>   trains, airplanes, pedestrians, etc. We all are used to it and =
don't discern extra smartness in it. However there is.
>
> - and I realized what is the big obstacle: Yes it is this rambo-SPF =
routing paradigma. It does not represent the
>   surveillant view, only the egomanic view, combined with the hope =
that in total you get best results because
>   "the streets are emptiest when each car takes the shortest =
route":-).
>
> Heinrich
>
>
>
>
>
> _______________________________________________
> routing-discussion mailing list
> routing-discussion@ietf.org
> https://www1.ietf.org/mailman/listinfo/routing-discussion

--
Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, Z.J. 310027
P.R.China

Tel: +86-571-87932423

Email: jshen@cad.zju.edu.cn

**********************************************************************
* The SunShine of life is made up of very little beams which is      *
*  bright all the time                                               *
**********************************************************************





_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org
https://www1.ietf.org/mailman/listinfo/routing-discussion

From jshen@cad.zju.edu.cn  Tue Aug 13 08:19:24 2002
Received: from someone claiming to be mail.cad.zju.edu.cn
	puck.NOSPAM (cad.zju.edu.cn [210.32.131.2])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with SMTP id g7DCJLs3009396
	for <irtf-rr@puck.nether.net>; Tue, 13 Aug 2002 08:19:23 -0400
	(envelope-from jshen@cad.zju.edu.cn)
Received-Date: Tue, 13 Aug 2002 08:19:23 -0400
Received: (qmail 26435 invoked from network); 13 Aug 2002 12:25:37 -0000
Received: from unknown (HELO cad.zju.edu.cn) (210.32.131.97)
  by 210.32.131.2 with SMTP; 13 Aug 2002 12:25:37 -0000
Message-ID: <3D58F982.8ED0E4D0@cad.zju.edu.cn>
Date: Tue, 13 Aug 2002 20:20:18 +0800
From: shen jing <jshen@cad.zju.edu.cn>
Reply-To: jshen@cad.zju.edu.cn
Organization: State Key Lab of CAD&CG
X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>
CC: irtf-rr@puck.nether.net, routing-discussion@ietf.org
References: <EF8E39AA846CD411BB9C00508B951F510514B992@MCHH267E>
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit
Subject: [Irtf-rr] Re: AW: Differentiated Routing, not only plain rambo-SPF
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

Hummel,

> 
> Gold:  A smallest size tree of toll roads, highways, state roads, country roads.
> Silver:A smallest size tree of highways, state roads, country roads.
> Bronze:A smallest size tree of state roads, country roads, and highways only if no path otherwise.
> 
> QoS parameters (speed, packet loss rate, MTU size,..) may define the type of road.

Do you means to restrict DSCP to be 3bits? 


> 
> 1st and 2nd road system may be different at least  w.r.t. their kernel parts. (The kernel part be that
> center of the smallest size tree, which is used by at least m ingress/egress combinations).
> Either traffic starts out with a) proper DSCP-Y-1st, resp. DSCP-Y-2nd, or b) is  changed from DSCP-Y-1st to
> DSCP-Y-2nd at the rim of the kernel if some current traffic load information advises so. I prefer a) and if possible such
> that any microflow will entirely take one single route.

So, that means to use alternative path for overflowed traffic?  In fact,
someone has proposed similar

method. Perhaps you are interested in the following paper:

http://www.cs.virginia.edu/~rv3s/pubs/compnet_paper.pdf 

> 
>
> Stability:
> We may toss a dice at the ingress,i.e. determine a random number Y between 0.0 and 1.0. 

I think this determines when a second path is adopted for traffic
routing, in fact we do not
need to use a random number if MPLS is used. At this situation, I think
what we need is to 
monitor load on a LSP, if the load is more than 70% of the effective
bandwidth another LSP is
adpoted. If distributed routing is used ( as that of current IP
network), traffic dispersion 
have to be triggerred by heuristic method mentioned by you.

> 
> Extensibility:
> So far I have no solution, on how to determine a smallest size tree made out of OSPF-links and EBGP/IBGP-hops.

As I think, a routing system built on time-varying network status will
do harm to both
stability and extensibility, because it could not be expected to all
routers converge to the same 
point within a short time period. 

Some others have been working on resource management in DiffServ
networks, the page located 
at:

http://standards.ericsson.net/rmd/

In deed, I'm very interested in this idea but I think it need more
clarification.

Hope to hear from others.





-- 
Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, Z.J. 310027
P.R.China

Tel: +86-571-87932423

Email: jshen@cad.zju.edu.cn

**********************************************************************
* The SunShine of life is made up of very little beams which is      *
*  bright all the time                                               *
**********************************************************************

From Heinrich.Hummel@icn.siemens.de  Tue Aug 13 09:07:32 2002
Received: from someone claiming to be gorilla.mchh.siemens.de
	puck.NOSPAM (gorilla.mchh.siemens.de [194.138.158.18])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with ESMTP id g7DD7Vs3011337
	for <irtf-rr@puck.nether.net>; Tue, 13 Aug 2002 09:07:31 -0400
	(envelope-from Heinrich.Hummel@icn.siemens.de)
Received-Date: Tue, 13 Aug 2002 09:07:31 -0400
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA04103;
	Tue, 13 Aug 2002 15:08:14 +0200 (MET DST)
Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA08189;
	Tue, 13 Aug 2002 15:08:14 +0200 (MET DST)
Received: by MCHH246E with Internet Mail Service (5.5.2656.59)
	id <PTSZJZ5P>; Tue, 13 Aug 2002 15:07:51 +0200
Message-ID: <EF8E39AA846CD411BB9C00508B951F510514B996@MCHH267E>
From: Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>
To: "'jshen@cad.zju.edu.cn'" <jshen@cad.zju.edu.cn>,
   Hummel Heinrich
	 <Heinrich.Hummel@icn.siemens.de>
Cc: irtf-rr@puck.nether.net, routing-discussion@ietf.org
Date: Tue, 13 Aug 2002 15:07:40 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="gb2312"
Subject: [Irtf-rr] AW: AW: Differentiated Routing, not only plain rambo-SPF
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

Jing
see my inserted comments.
Heinrich 


Hummel,

> 
> Gold:  A smallest size tree of toll roads, highways, state roads, country roads.
> Silver:A smallest size tree of highways, state roads, country roads.
> Bronze:A smallest size tree of state roads, country roads, and highways only if no path otherwise.
> 
> QoS parameters (speed, packet loss rate, MTU size,..) may define the type of road.

Do you means to restrict DSCP to be 3bits? 
HH=> No. In general we may  correlate several, e.g. m,  "gold-like" DSCPs 
          a) to their currently defined "gold-like" DiffServ functionality
          and b) to one Gold-1st road system,
    
     Furthermore, we may identify m additional and  suitable  DSCPs which shall trigger the same
     "gold-like" DiffServ functionality like above, but which are correlated to Gold-2nd road system.

   

> 
> 1st and 2nd road system may be different at least  w.r.t. their kernel parts. (The kernel part be that
> center of the smallest size tree, which is used by at least m ingress/egress combinations).
> Either traffic starts out with a) proper DSCP-Y-1st, resp. DSCP-Y-2nd, or b) is  changed from DSCP-Y-1st to
> DSCP-Y-2nd at the rim of the kernel if some current traffic load information advises so. I prefer a) and if possible such
> that any microflow will entirely take one single route.

So, that means to use alternative path for overflowed traffic?  In fact,
someone has proposed similar

method. Perhaps you are interested in the following paper:

http://www.cs.virginia.edu/~rv3s/pubs/compnet_paper.pdf 

HH=> I will go and read this paper.
     I am not surprised and I really welcome that there are others who write such papers.
     I only believe, that sqeezing/locking some traffic into e.g. some smallest size tree-road system
     enables much more effectiveness, both for the better and the worse:
     for the worse: Best-Effort-Traffic may even be handled worse, if locked into an overcrowded road system of
                    bad condition.
     for the better: Gold-traffic will be handled better, if best roads are available and if Best-Effort-Traffic is
                     kept out of the way.  

> 
>
> Stability:
> We may toss a dice at the ingress,i.e. determine a random number Y between 0.0 and 1.0. 

I think this determines when a second path is adopted for traffic
routing, in fact we do not
need to use a random number if MPLS is used. At this situation, I think
what we need is to 
monitor load on a LSP, if the load is more than 70% of the effective
bandwidth another LSP is
adpoted. If distributed routing is used ( as that of current IP
network), traffic dispersion 
have to be triggerred by heuristic method mentioned by you.

HH=> Fine.

> 
> Extensibility:
> So far I have no solution, on how to determine a smallest size tree made out of OSPF-links and EBGP/IBGP-hops.

As I think, a routing system built on time-varying network status will
do harm to both
stability and extensibility, because it could not be expected to all
routers converge to the same 
point within a short time period.

HH=> We should really ask students to program simulations and to investigate whether it will harm or improve stability. 

Some others have been working on resource management in DiffServ
networks, the page located 
at:

http://standards.ericsson.net/rmd/

In deed, I'm very interested in this idea but I think it need more
clarification.

HH=> I will read this paper, too. But again: If you have (at least)  N shortest path trees rooted at  N ingress edge router,
they will disperse traffic all over the network and it is fairly vague what bandwidth on which link shall be reserved.
Whereas if you lock all this traffic into one single  smallest size tree, you may allocate bigger BWs to fewer links.

Hope to hear from others.
HH=> Hope so, too.





-- 
Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, Z.J. 310027
P.R.China

Tel: +86-571-87932423

Email: jshen@cad.zju.edu.cn

**********************************************************************
* The SunShine of life is made up of very little beams which is      *
*  bright all the time                                               *
**********************************************************************

From Heinrich.Hummel@icn.siemens.de  Tue Aug 13 09:24:23 2002
Received: from someone claiming to be beamer.mchh.siemens.de
	puck.NOSPAM (beamer.mchh.siemens.de [194.138.158.163])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with ESMTP id g7DDOMs3012878
	for <irtf-rr@puck.nether.net>; Tue, 13 Aug 2002 09:24:23 -0400
	(envelope-from Heinrich.Hummel@icn.siemens.de)
Received-Date: Tue, 13 Aug 2002 09:24:23 -0400
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA08895;
	Tue, 13 Aug 2002 15:24:43 +0200 (MET DST)
Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA17621;
	Tue, 13 Aug 2002 15:25:03 +0200 (MET DST)
Received: by MCHH273E with Internet Mail Service (5.5.2656.59)
	id <P71RGBAB>; Tue, 13 Aug 2002 15:24:38 +0200
Message-ID: <EF8E39AA846CD411BB9C00508B951F510514B997@MCHH267E>
From: Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>
To: "'jshen@cad.zju.edu.cn'" <jshen@cad.zju.edu.cn>
Cc: "'irtf-rr@puck.nether.net'" <irtf-rr@puck.nether.net>,
   "'routing-discussion@ietf.org'" <routing-discussion@ietf.org>
Date: Tue, 13 Aug 2002 15:24:14 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="gb2312"
Subject: [Irtf-rr] AW: AW: Differentiated Routing, not only plain rambo-SPF
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

Jing,
Right this moment I looked at new email-thread on MPLS list "fast re-route merging".
What popped up in my mind:
The smallest size tree road system is, in practice, BI-DIRECTIONAL. It should be feasable to
crank back:  Either   IP-in-IP or some new TYPE information may be applied.The packet's source and destination 
address fields may be exchanged at the point of congestion. The packet may be returned to where the associated overflow road system can be entered. There, source and destination address fields have to be exchanged once again and the packet may be
forwarded with the alternate DSCP along the associated alternate road system.

Wouldn't this be a nice add-on ?

Heinrich
 

From Venkata.Naidu@Marconi.com  Tue Aug 13 11:00:56 2002
Received: from someone claiming to be mailgate.pit.comms.marconi.com
	puck.NOSPAM (mailgate.pit.comms.marconi.com [169.144.68.6])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with ESMTP id g7DF0us3017304
	for <irtf-rr@puck.nether.net>; Tue, 13 Aug 2002 11:00:56 -0400
	(envelope-from Venkata.Naidu@Marconi.com)
Received-Date: Tue, 13 Aug 2002 11:00:56 -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA20146;
	Tue, 13 Aug 2002 11:01:41 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA11474;
	Tue, 13 Aug 2002 11:01:42 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <3W99VFN7>; Tue, 13 Aug 2002 11:01:41 -0400
Message-ID: <39469E08BD83D411A3D900204840EC557632E3@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Hummel Heinrich'" <Heinrich.Hummel@icn.siemens.de>,
   "'Ayyasamy, Senthilkumar  (UMKC-Student)'" <saq66@umkc.edu>,
   "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
Cc: routing-discussion@ietf.org,
   "'irtf-rr@puck.nether.net'"
	 <irtf-rr@puck.nether.net>
Date: Tue, 13 Aug 2002 11:01:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Irtf-rr] RE: AW: Differentiated Routing, not only plain rambo-SPF
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

Heinrich,
 
-> I think the more we debate, the more usefull things we will 
-> discover:-)

  Yes! you are right :) But we can't keep on discussing or
  learning things... :-)

  Average age of a person who can make significant 
  novel contribution to any field will increase in 
  future years. Next generations will definitely 
  suffer & struggle for existence in the changing 
  facets of science & technology (unless intellectual 
  power of humans increase by birth). 

  To make it crystal clear, now (in 2002) it is 
  enough to invent something new/beneficial technology,
  if we follow past work done by few Yakov Rekhters.
  But in future, an average inventor must know
  thousands of such Yakov Rekhters works. Is that 
  possible in a life span ? :)

  It is highly unlikely that a person can invent 
  something new with out complete understanding of 
  relevant past work done on any subject.

  I am really worried...

--
Venkata.

From Heinrich.Hummel@icn.siemens.de  Tue Aug 13 11:05:36 2002
Received: from someone claiming to be gorilla.mchh.siemens.de
	puck.NOSPAM (gorilla.mchh.siemens.de [194.138.158.18])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with ESMTP id g7DF5Zs3017459
	for <irtf-rr@puck.nether.net>; Tue, 13 Aug 2002 11:05:36 -0400
	(envelope-from Heinrich.Hummel@icn.siemens.de)
Received-Date: Tue, 13 Aug 2002 11:05:36 -0400
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA14105;
	Tue, 13 Aug 2002 17:06:25 +0200 (MET DST)
Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA18322;
	Tue, 13 Aug 2002 17:06:25 +0200 (MET DST)
Received: by MCHH273E with Internet Mail Service (5.5.2656.59)
	id <P71RGF08>; Tue, 13 Aug 2002 17:06:00 +0200
Message-ID: <EF8E39AA846CD411BB9C00508B951F510514B99E@MCHH267E>
From: Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>
To: "'Ayyasamy, Senthilkumar  (UMKC-Student)'" <saq66@umkc.edu>,
   "Naidu, Venkata" <Venkata.Naidu@Marconi.com>,
   "Manfredi, Albert E"
	 <albert.e.manfredi@boeing.com>
Cc: routing-discussion@ietf.org, irtf-rr@puck.nether.net
Date: Tue, 13 Aug 2002 17:05:54 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: [Irtf-rr] AW: AW: Differentiated Routing, not only plain rambo-SPF
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

I am sorry, but there is no signalling (like RSVP, RSVP-TE, CR-LDP) for =
doing DiffRout.

Based on the information exchanged by the routing protocol (like OSPF) =
all nodes should be able to
compute the same smallest size tree which interconnects the edge =
routers (those with attached users or attached external interfaces), =
and which complies to some specific constraints =
(QoS/BW/Policy,eventually avoiding overlaps with other=20
road systems),and which are associated to the same DSCP(s).  // plural: =
see my  previous email from today

But there is no signalling as to "establish the DSCP-associated road =
system" !!!

However,it would be a fancy but completely new task to determine and =
establish an MPLS-road system,
which may lock MPLS-traffic into such slim Smallest Size Tree graphs. =
See all my work on establishing
the "road systems for VPNs" based on elementary+ hierarchical LSPs.

Heinrich



-----Urspr=FCngliche Nachricht-----
Von: Ayyasamy, Senthilkumar (UMKC-Student) [mailto:saq66@umkc.edu]
Gesendet: Dienstag, 13. August 2002 16:40
An: Naidu, Venkata; Hummel Heinrich; Manfredi, Albert E
Cc: routing-discussion@ietf.org; irtf-rr@puck.nether.net
Betreff: RE: AW: Differentiated Routing, not only plain rambo-SPF



> -> yes,it is similar;
> -> but here it is about state-less IP forwarding, i.e. about=20
> -> forwarding the individual IP packets, without any
> -> RSVP path and without any MPLS path.
>=20
>   Oh! Ok...you would like to do Crankback in
>   connection less IP environments?!?
>=20
>   In such a case, you might find below paper interesting:
> http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers/te-
> latest.pdf
 I have studied this paper. Your are mis-interpreting here. The RPI
paper is an increment to OSPF or BGP for some traffic engineering
functionalties. It doesnt require signaling whereas, diffrout=20
requires signaling. Also, we are taking more from a diffserv=20
point of view.
 As i told, routing in peer to peer networks and some overlay=20
systems can use diffrout concept. We can explore certain non-
cooperative algorithms for an alternative to SPF. But as mentioned
before, this will not work out if we see from an engineering=20
perspective.=20

>=20
>   There was some discussion in E2E list regarding
>   pros & cons of this approach. I couldn't find the URL
>   but I vaguely remember that the subject of the discussion
>   is "EC++N" or something like that...

From saq66@umkc.edu  Tue Aug 13 11:13:01 2002
Received: from someone claiming to be kc-msxproto4.kc.umkc.edu
	puck.NOSPAM (kc-msxproto4.kc.umkc.edu [134.193.143.48])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with ESMTP id g7DFD1s3017716
	for <irtf-rr@puck.nether.net>; Tue, 13 Aug 2002 11:13:01 -0400
	(envelope-from saq66@umkc.edu)
Received-Date: Tue, 13 Aug 2002 11:13:01 -0400
Received: from KC-MAIL2.kc.umkc.edu ([134.193.143.162] RDNS failed) by kc-msxproto4.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 13 Aug 2002 10:13:53 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 13 Aug 2002 10:13:27 -0500
Message-ID: <A29143A40AEAE3459FF829D1DD4331613C2540@KC-MAIL2.kc.umkc.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: Differentiated Routing, not only plain rambo-SPF
Thread-Index: AcJC2wVbvBpSCzdhSq22rnYtxklySwAADolA
From: "Ayyasamy, Senthilkumar  (UMKC-Student)" <saq66@umkc.edu>
To: "Hummel Heinrich" <Heinrich.Hummel@icn.siemens.de>,
   "Naidu, Venkata" <Venkata.Naidu@Marconi.com>,
   "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
Cc: <routing-discussion@ietf.org>, <irtf-rr@puck.nether.net>
X-OriginalArrivalTime: 13 Aug 2002 15:13:53.0543 (UTC) FILETIME=[09432970:01C242DC]
Subject: [Irtf-rr] RE: AW: Differentiated Routing, not only plain rambo-SPF
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

> I am sorry, but there is no signalling (like RSVP, RSVP-TE,=20
> CR-LDP) for doing DiffRout.

 My mistake here.. But diffrout has few goals in common with
the RPIs *BANANAS* traffic engineering framework but sometimes
complimentary too. The best suggestion might be ..why cant=20
you come up with some very rough draft version.So that, we=20
can be clear that we are discussing the same scheme. I have=20
one picture of diffrout, some others think that as diffser-TE=20
and so , it is better if we have some notes before discussion.

>=20
> Based on the information exchanged by the routing protocol=20
> (like OSPF) all nodes should be able to
> compute the same smallest size tree which interconnects the=20
> edge routers (those with attached users or attached external=20
> interfaces), and which complies to some specific constraints=20
> (QoS/BW/Policy,eventually avoiding overlaps with other=20
> road systems),and which are associated to the same DSCP(s). =20
> // plural: see my  previous email from today
>=20
> But there is no signalling as to "establish the=20
> DSCP-associated road system" !!!
>=20
> However,it would be a fancy but completely new task to=20
> determine and establish an MPLS-road system,
> which may lock MPLS-traffic into such slim Smallest Size Tree=20
> graphs. See all my work on establishing
> the "road systems for VPNs" based on elementary+ hierarchical LSPs.
>=20
> Heinrich
>=20
>=20
>=20
> -----Urspr=FCngliche Nachricht-----
> Von: Ayyasamy, Senthilkumar (UMKC-Student) [mailto:saq66@umkc.edu]
> Gesendet: Dienstag, 13. August 2002 16:40
> An: Naidu, Venkata; Hummel Heinrich; Manfredi, Albert E
> Cc: routing-discussion@ietf.org; irtf-rr@puck.nether.net
> Betreff: RE: AW: Differentiated Routing, not only plain rambo-SPF
>=20
>=20
>=20
> > -> yes,it is similar;
> > -> but here it is about state-less IP forwarding, i.e. about=20
> > -> forwarding the individual IP packets, without any
> > -> RSVP path and without any MPLS path.
> >=20
> >   Oh! Ok...you would like to do Crankback in
> >   connection less IP environments?!?
> >=20
> >   In such a case, you might find below paper interesting:
> > http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers/te-
> > latest.pdf
>  I have studied this paper. Your are mis-interpreting here. The RPI
> paper is an increment to OSPF or BGP for some traffic engineering
> functionalties. It doesnt require signaling whereas, diffrout=20
> requires signaling. Also, we are taking more from a diffserv=20
> point of view.
>  As i told, routing in peer to peer networks and some overlay=20
> systems can use diffrout concept. We can explore certain non-
> cooperative algorithms for an alternative to SPF. But as mentioned
> before, this will not work out if we see from an engineering=20
> perspective.=20
>=20
> >=20
> >   There was some discussion in E2E list regarding
> >   pros & cons of this approach. I couldn't find the URL
> >   but I vaguely remember that the subject of the discussion
> >   is "EC++N" or something like that...
>=20

From Venkata.Naidu@Marconi.com  Tue Aug 13 11:15:27 2002
Received: from someone claiming to be mailgate.pit.comms.marconi.com
	puck.NOSPAM (mailgate.pit.comms.marconi.com [169.144.68.6])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with ESMTP id g7DFFRs3017992
	for <irtf-rr@puck.nether.net>; Tue, 13 Aug 2002 11:15:27 -0400
	(envelope-from Venkata.Naidu@Marconi.com)
Received-Date: Tue, 13 Aug 2002 11:15:27 -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA21252;
	Tue, 13 Aug 2002 11:16:13 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA15774;
	Tue, 13 Aug 2002 11:16:14 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <3W99VGL7>; Tue, 13 Aug 2002 11:16:13 -0400
Message-ID: <39469E08BD83D411A3D900204840EC557632E4@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Ayyasamy, Senthilkumar  (UMKC-Student)'" <saq66@umkc.edu>,
   Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>
Cc: routing-discussion@ietf.org, irtf-rr@puck.nether.net
Date: Tue, 13 Aug 2002 11:16:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Irtf-rr] RE: AW: Differentiated Routing, not only plain rambo-SPF
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

Senthil,

-> > -> yes,it is similar;
-> > -> but here it is about state-less IP forwarding, i.e. about 
-> > -> forwarding the individual IP packets, without any
-> > -> RSVP path and without any MPLS path.
-> > 
-> >   Oh! Ok...you would like to do Crankback in
-> >   connection less IP environments?!?
-> > 
-> >   In such a case, you might find below paper interesting:
-> > http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers/te-
-> > latest.pdf
->  I have studied this paper. Your are mis-interpreting here. The RPI
-> paper is an increment to OSPF or BGP for some traffic engineering
-> functionalties. It doesnt require signaling whereas, diffrout 
-> requires signaling. 

  Heinrich is talking about connection-less, no RSVP, no MPLS
  signaling. I just pointed a *relavent* paper. 
  
  You can find solution to any problem in multiple ways. 
 
  The problem in hand is:
  - Bypass congestion area *effectively* 
    using best of today's technologies
  - Effecient utilization of resources 
  - Fast forwarding
  - QoS (end-to-end perspective)
    etc etc

  IMO, after working for many years in MPLS & relavent technologies,
  I am convinced that MPLS will solve most of the problem we couldn't
  solve in the past *effectively*. Ofcourse, there are some issues
  with MPLS, still, I think, we can solve most of the above issues 
  very efficiently using MPLS than traditional IP routing.

  That is why I am arguing that, what ever problem in hand, can be
  solved by recent advancements in MPLS. Let us not go back to the
  past where we tried to achieve things in connection-less IP 
  environments.

  The work done by RPI guys is something similar to what Heinrich
  is discussing. Especially, section 3.1. Interested people can
  compare/contrast similar work done in the past (like above paper).

--
Venkata

From Venkata.Naidu@Marconi.com  Tue Aug 13 11:18:49 2002
Received: from someone claiming to be mailgate.pit.comms.marconi.com
	puck.NOSPAM (mailgate.pit.comms.marconi.com [169.144.68.6])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with ESMTP id g7DFIms3018959
	for <irtf-rr@puck.nether.net>; Tue, 13 Aug 2002 11:18:48 -0400
	(envelope-from Venkata.Naidu@Marconi.com)
Received-Date: Tue, 13 Aug 2002 11:18:48 -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA21511;
	Tue, 13 Aug 2002 11:19:28 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA16746;
	Tue, 13 Aug 2002 11:19:28 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <3W99VG4V>; Tue, 13 Aug 2002 11:19:27 -0400
Message-ID: <39469E08BD83D411A3D900204840EC557632E5@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'Ayyasamy, Senthilkumar  (UMKC-Student)'" <saq66@umkc.edu>,
   Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>
Cc: routing-discussion@ietf.org, irtf-rr@puck.nether.net
Date: Tue, 13 Aug 2002 11:19:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Irtf-rr] RE: AW: Differentiated Routing, not only plain rambo-SPF
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

-> The best suggestion might be ..why cant 
-> you come up with some very rough draft version.So that, we 
-> can be clear that we are discussing the same scheme. I have 
-> one picture of diffrout, some others think that as diffser-TE 
-> and so , it is better if we have some notes before discussion.

  I completely agree.

--
Venkata

From Heinrich.Hummel@icn.siemens.de  Tue Aug 13 11:24:33 2002
Received: from someone claiming to be gorilla.mchh.siemens.de
	puck.NOSPAM (gorilla.mchh.siemens.de [194.138.158.18])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with ESMTP id g7DFOWs3019397
	for <irtf-rr@puck.nether.net>; Tue, 13 Aug 2002 11:24:32 -0400
	(envelope-from Heinrich.Hummel@icn.siemens.de)
Received-Date: Tue, 13 Aug 2002 11:24:32 -0400
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA15260;
	Tue, 13 Aug 2002 17:25:22 +0200 (MET DST)
Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA28214;
	Tue, 13 Aug 2002 17:25:23 +0200 (MET DST)
Received: by MCHH247E with Internet Mail Service (5.5.2656.59)
	id <P71TYWS1>; Tue, 13 Aug 2002 17:24:59 +0200
Message-ID: <EF8E39AA846CD411BB9C00508B951F510514B9A0@MCHH267E>
From: Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>
To: "'Naidu, Venkata'" <Venkata.Naidu@Marconi.com>,
   "'Ayyasamy, Senthilkumar  (UMKC-Student)'" <saq66@umkc.edu>,
   "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
Cc: routing-discussion@ietf.org,
   "'irtf-rr@puck.nether.net'"
	 <irtf-rr@puck.nether.net>
Date: Tue, 13 Aug 2002 17:24:59 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: [Irtf-rr] AW: AW: Differentiated Routing, not only plain rambo-SPF
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

Venkata,
We have only discussed for three weeks and have just scratched a little =
bit on the
disadvantages of SPF. Most of it in the light that real road traffic =
won't be managed
based on such egocentric view. We are about to look at the existing =
IETF concepts and will
certainly discover a lot of things which can be improved, simplified, =
enabled.

Heinrich


-----Urspr=FCngliche Nachricht-----
Von: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com]
Gesendet: Dienstag, 13. August 2002 17:02
An: 'Hummel Heinrich'; 'Ayyasamy, Senthilkumar (UMKC-Student)';
Manfredi, Albert E
Cc: routing-discussion@ietf.org; 'irtf-rr@puck.nether.net'
Betreff: RE: AW: Differentiated Routing, not only plain rambo-SPF


Heinrich,
=20
-> I think the more we debate, the more usefull things we will=20
-> discover:-)

  Yes! you are right :) But we can't keep on discussing or
  learning things... :-)

  Average age of a person who can make significant=20
  novel contribution to any field will increase in=20
  future years. Next generations will definitely=20
  suffer & struggle for existence in the changing=20
  facets of science & technology (unless intellectual=20
  power of humans increase by birth).=20

  To make it crystal clear, now (in 2002) it is=20
  enough to invent something new/beneficial technology,
  if we follow past work done by few Yakov Rekhters.
  But in future, an average inventor must know
  thousands of such Yakov Rekhters works. Is that=20
  possible in a life span ? :)

  It is highly unlikely that a person can invent=20
  something new with out complete understanding of=20
  relevant past work done on any subject.

  I am really worried...

--
Venkata.

From Heinrich.Hummel@icn.siemens.de  Tue Aug 13 11:38:07 2002
Received: from someone claiming to be beamer.mchh.siemens.de
	puck.NOSPAM (beamer.mchh.siemens.de [194.138.158.163])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with ESMTP id g7DFc6s3019860
	for <irtf-rr@puck.nether.net>; Tue, 13 Aug 2002 11:38:06 -0400
	(envelope-from Heinrich.Hummel@icn.siemens.de)
Received-Date: Tue, 13 Aug 2002 11:38:06 -0400
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA17652;
	Tue, 13 Aug 2002 17:38:37 +0200 (MET DST)
Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA04447;
	Tue, 13 Aug 2002 17:38:57 +0200 (MET DST)
Received: by MCHH273E with Internet Mail Service (5.5.2656.59)
	id <P71RGHGN>; Tue, 13 Aug 2002 17:38:32 +0200
Message-ID: <EF8E39AA846CD411BB9C00508B951F510514B9A1@MCHH267E>
From: Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>
To: "'Ayyasamy, Senthilkumar  (UMKC-Student)'" <saq66@umkc.edu>,
   "Naidu, Venkata" <Venkata.Naidu@Marconi.com>,
   "Manfredi, Albert E"
	 <albert.e.manfredi@boeing.com>
Cc: routing-discussion@ietf.org, irtf-rr@puck.nether.net
Date: Tue, 13 Aug 2002 17:38:19 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="ISO-8859-1"
Subject: [Irtf-rr] AW: AW: Differentiated Routing, not only plain rambo-SPF
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

The best suggestion might be ..why cant 
you come up with some very rough draft version.So that, we 
can be clear that we are discussing the same scheme. I have 
one picture of diffrout, some others think that as diffser-TE 
and so , it is better if we have some notes before discussion.


Certainly. It will be my pleasure to write a draft on this topic.
The day after tomorrow I will go on vacation. So it may take a little while :-)
Heinrich     

 

From jshen@cad.zju.edu.cn  Wed Aug 14 08:19:33 2002
Received: from someone claiming to be mail.cad.zju.edu.cn
	puck.NOSPAM (cad.zju.edu.cn [210.32.131.2])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with SMTP id g7ECJUs3007329
	for <irtf-rr@puck.nether.net>; Wed, 14 Aug 2002 08:19:31 -0400
	(envelope-from jshen@cad.zju.edu.cn)
Received-Date: Wed, 14 Aug 2002 08:19:31 -0400
Received: (qmail 10409 invoked from network); 14 Aug 2002 12:25:54 -0000
Received: from unknown (HELO cad.zju.edu.cn) (210.32.131.97)
  by 210.32.131.2 with SMTP; 14 Aug 2002 12:25:54 -0000
Message-ID: <3D5A4B13.4385ABBE@cad.zju.edu.cn>
Date: Wed, 14 Aug 2002 20:20:35 +0800
From: shen jing <jshen@cad.zju.edu.cn>
Reply-To: jshen@cad.zju.edu.cn
Organization: State Key Lab of CAD&CG
X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: irtf-rr@puck.nether.net
CC: "'Hummel Heinrich'" <Heinrich.Hummel@icn.siemens.de>,
   "'routing-discussion@ietf.org'" <routing-discussion@ietf.org>
References: <39469E08BD83D411A3D900204840EC557632E2@vie-msgusr-01.dc.fore.com>
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit
Subject: [Irtf-rr] Re: AW: Differentiated Routing, not only plain rambo-SPF
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

The discussion you mentioned is that of congestion removement by e2e
mechanism  or by routing. Professor Crowcroft proposed a method
named ECN++ which trigger a new path that acts when ECN bit is set 
in packet header.



> 
> Heinrich,
> 
> -> yes,it is similar;
> -> but here it is about state-less IP forwarding, i.e. about
> -> forwarding the individual IP packets, without any
> -> RSVP path and without any MPLS path.
> 
>   Oh! Ok...you would like to do Crankback in
>   connection less IP environments?!?
> 
>   In such a case, you might find below paper interesting:
> http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers/te-latest.pdf
> 
>   There was some discussion in E2E list regarding
>   pros & cons of this approach. I couldn't find the URL
>   but I vaguely remember that the subject of the discussion
>   is "EC++N" or something like that...
> 
> --
> Venkata
> 
> _______________________________________________
> routing-discussion mailing list
> routing-discussion@ietf.org
> https://www1.ietf.org/mailman/listinfo/routing-discussion

-- 
Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, Z.J. 310027
P.R.China

Tel: +86-571-87932423
Mobile: (0)13516813753
Email: jshen@cad.zju.edu.cn

**********************************************************************
* The SunShine of life is made up of very little beams which is      *
*  bright all the time                                               *
**********************************************************************

From Heinrich.Hummel@icn.siemens.de  Wed Aug 14 08:46:58 2002
Received: from someone claiming to be gorilla.mchh.siemens.de
	puck.NOSPAM (gorilla.mchh.siemens.de [194.138.158.18])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with ESMTP id g7ECkvs3008432
	for <irtf-rr@puck.nether.net>; Wed, 14 Aug 2002 08:46:58 -0400
	(envelope-from Heinrich.Hummel@icn.siemens.de)
Received-Date: Wed, 14 Aug 2002 08:46:58 -0400
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA10309;
	Wed, 14 Aug 2002 14:47:50 +0200 (MET DST)
Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA12849;
	Wed, 14 Aug 2002 14:47:53 +0200 (MET DST)
Received: by MCHH246E with Internet Mail Service (5.5.2656.59)
	id <PTSZK8W2>; Wed, 14 Aug 2002 14:47:28 +0200
Message-ID: <EF8E39AA846CD411BB9C00508B951F510514B9A2@MCHH267E>
From: Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>
To: "'jshen@cad.zju.edu.cn'" <jshen@cad.zju.edu.cn>, irtf-rr@puck.nether.net
Cc: Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>,
   "'routing-discussion@ietf.org'" <routing-discussion@ietf.org>
Date: Wed, 14 Aug 2002 14:47:24 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable
Subject: [Irtf-rr] AW: AW: Differentiated Routing, not only plain rambo-SPF
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

Let's assume there are two Smallest Size Tree road systems X1 and X2. =
X2 detours/avoids the kernel links of X1.
For some source/destination node pair the total pathes may be =
different. Or only the section in the middle is different.
Or only a section close to the source (or close to the dest.) is =
different. Whatever applies:
From the point of congestion on road system X1 the packet my crankback =
(hereby source and dest. address are swapped)
to that first node which is also part of X2.
There  source and dest. address are swapped again,  DSCP-X1 is replaced =
by DSCP-X2 and the packet is  moved forward=20
via X2.

Heinrich

-----Urspr=A8=B9ngliche Nachricht-----
Von: shen jing [mailto:jshen@cad.zju.edu.cn]
Gesendet: Mittwoch, 14. August 2002 14:21
An: irtf-rr@puck.nether.net
Cc: 'Hummel Heinrich'; 'routing-discussion@ietf.org'
Betreff: Re: AW: Differentiated Routing, not only plain rambo-SPF



The discussion you mentioned is that of congestion removement by e2e
mechanism  or by routing. Professor Crowcroft proposed a method
named ECN++ which trigger a new path that acts when ECN bit is set=20
in packet header.



>=20
> Heinrich,
>=20
> -> yes,it is similar;
> -> but here it is about state-less IP forwarding, i.e. about
> -> forwarding the individual IP packets, without any
> -> RSVP path and without any MPLS path.
>=20
>   Oh! Ok...you would like to do Crankback in
>   connection less IP environments?!?
>=20
>   In such a case, you might find below paper interesting:
> =
http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers/te-latest.pdf=

>=20
>   There was some discussion in E2E list regarding
>   pros & cons of this approach. I couldn't find the URL
>   but I vaguely remember that the subject of the discussion
>   is "EC++N" or something like that...
>=20
> --
> Venkata
>=20
> _______________________________________________
> routing-discussion mailing list
> routing-discussion@ietf.org
> https://www1.ietf.org/mailman/listinfo/routing-discussion

--=20
Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, Z.J. 310027
P.R.China

Tel: +86-571-87932423
Mobile: (0)13516813753
Email: jshen@cad.zju.edu.cn

**********************************************************************
* The SunShine of life is made up of very little beams which is      *
*  bright all the time                                               *
**********************************************************************

From Venkata.Naidu@Marconi.com  Wed Aug 14 09:56:15 2002
Received: from someone claiming to be mailgate.pit.comms.marconi.com
	puck.NOSPAM (mailgate.pit.comms.marconi.com [169.144.68.6])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with ESMTP id g7EDuEs3011098
	for <irtf-rr@puck.nether.net>; Wed, 14 Aug 2002 09:56:15 -0400
	(envelope-from Venkata.Naidu@Marconi.com)
Received-Date: Wed, 14 Aug 2002 09:56:15 -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA15829;
	Wed, 14 Aug 2002 09:56:35 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA10152;
	Wed, 14 Aug 2002 09:56:36 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <3W99WLVD>; Wed, 14 Aug 2002 09:56:36 -0400
Message-ID: <39469E08BD83D411A3D900204840EC557632E9@vie-msgusr-01.dc.fore.com>
From: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>
To: "'jshen@cad.zju.edu.cn'" <jshen@cad.zju.edu.cn>, irtf-rr@puck.nether.net
Cc: "'Hummel Heinrich'" <Heinrich.Hummel@icn.siemens.de>,
   "'routing-discussion@ietf.org'" <routing-discussion@ietf.org>
Subject: RE: [Irtf-rr] Re: AW: Differentiated Routing, not only plain ramb
	o-SPF
Date: Wed, 14 Aug 2002 09:56:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="gb2312"
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

Shen,

Please follow the thread:
http://www.postel.org/pipermail/end2end-interest/2002-April/002006.html

--
Venkata.

-> -----Original Message-----
-> From: shen jing [mailto:jshen@cad.zju.edu.cn]
-> Sent: Wednesday, August 14, 2002 8:21 AM
-> To: irtf-rr@puck.nether.net
-> Cc: 'Hummel Heinrich'; 'routing-discussion@ietf.org'
-> Subject: [Irtf-rr] Re: AW: Differentiated Routing, not only 
-> plain rambo-SPF
-> 
-> 
-> 
-> The discussion you mentioned is that of congestion removement by e2e
-> mechanism  or by routing. Professor Crowcroft proposed a method
-> named ECN++ which trigger a new path that acts when ECN bit is set 
-> in packet header.
-> 
-> 
-> 
-> > 
-> > Heinrich,
-> > 
-> > -> yes,it is similar;
-> > -> but here it is about state-less IP forwarding, i.e. about
-> > -> forwarding the individual IP packets, without any
-> > -> RSVP path and without any MPLS path.
-> > 
-> >   Oh! Ok...you would like to do Crankback in
-> >   connection less IP environments?!?
-> > 
-> >   In such a case, you might find below paper interesting:
-> > 
-> http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers/te
-> -latest.pdf
-> > 
-> >   There was some discussion in E2E list regarding
-> >   pros & cons of this approach. I couldn't find the URL
-> >   but I vaguely remember that the subject of the discussion
-> >   is "EC++N" or something like that...
-> > 
-> > --
-> > Venkata
-> > 
-> > _______________________________________________
-> > routing-discussion mailing list
-> > routing-discussion@ietf.org
-> > https://www1.ietf.org/mailman/listinfo/routing-discussion
-> 
-> -- 
-> Jing Shen
-> 
-> State Key Lab of CAD&CG
-> ZheJiang University(YuQuan)
-> HangZhou, Z.J. 310027
-> P.R.China
-> 
-> Tel: +86-571-87932423
-> Mobile: (0)13516813753
-> Email: jshen@cad.zju.edu.cn
-> 
-> *************************************************************
-> *********
-> * The SunShine of life is made up of very little beams which 
-> is      *
-> *  bright all the time                                       
->         *
-> *************************************************************
-> *********
-> _______________________________________________
-> Irtf-rr mailing list
-> Irtf-rr@puck.nether.net
-> http://puck.nether.net/mailman/listinfo/irtf-rr
-> 

From jshen@cad.zju.edu.cn  Wed Aug 14 10:02:05 2002
Received: from someone claiming to be mail.cad.zju.edu.cn
	puck.NOSPAM (cad.zju.edu.cn [210.32.131.2])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with SMTP id g7EE21s3011269
	for <irtf-rr@puck.nether.net>; Wed, 14 Aug 2002 10:02:02 -0400
	(envelope-from jshen@cad.zju.edu.cn)
Received-Date: Wed, 14 Aug 2002 10:02:02 -0400
Received: (qmail 12116 invoked from network); 14 Aug 2002 14:08:36 -0000
Received: from unknown (HELO cad.zju.edu.cn) (210.32.131.97)
  by 210.32.131.2 with SMTP; 14 Aug 2002 14:08:36 -0000
Message-ID: <3D5A6325.3C9DB86C@cad.zju.edu.cn>
Date: Wed, 14 Aug 2002 22:03:17 +0800
From: shen jing <jshen@cad.zju.edu.cn>
Reply-To: jshen@cad.zju.edu.cn
Organization: State Key Lab of CAD&CG
X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Hummel Heinrich <Heinrich.Hummel@icn.siemens.de>
CC: irtf-rr@puck.nether.net,
   "'routing-discussion@ietf.org'" <routing-discussion@ietf.org>
References: <EF8E39AA846CD411BB9C00508B951F510514B9A2@MCHH267E>
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 8bit
Subject: [Irtf-rr] Re: AW: AW: Differentiated Routing, not only plain rambo-SPF
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

Hummel,

the crankback could be assumed, but the difficulty exists with when it
is triggered.

No matter how the two trees are estabilished, the network traffic is
shown to be 
self-similar, and with the increase of bandwidth*delay burst traffic
occurs frequently.

If a router react to transient overload, there may be a huge burden on
dealing with such 
operations. So, I think this mechanism may be adpoted for broken links
but not for congestion.




> 
> Let's assume there are two Smallest Size Tree road systems X1 and X2. X2 detours/avoids the kernel links of X1.
> For some source/destination node pair the total pathes may be different. Or only the section in the middle is different.
> Or only a section close to the source (or close to the dest.) is different. Whatever applies:
> >From the point of congestion on road system X1 the packet my crankback (hereby source and dest. address are swapped)
> to that first node which is also part of X2.
> There  source and dest. address are swapped again,  DSCP-X1 is replaced by DSCP-X2 and the packet is  moved forward
> via X2.
> 
> Heinrich
> 
> -----Ursprščngliche Nachricht-----
> Von: shen jing [mailto:jshen@cad.zju.edu.cn]
> Gesendet: Mittwoch, 14. August 2002 14:21
> An: irtf-rr@puck.nether.net
> Cc: 'Hummel Heinrich'; 'routing-discussion@ietf.org'
> Betreff: Re: AW: Differentiated Routing, not only plain rambo-SPF
> 
> The discussion you mentioned is that of congestion removement by e2e
> mechanism  or by routing. Professor Crowcroft proposed a method
> named ECN++ which trigger a new path that acts when ECN bit is set
> in packet header.
> 
> >
> > Heinrich,
> >
> > -> yes,it is similar;
> > -> but here it is about state-less IP forwarding, i.e. about
> > -> forwarding the individual IP packets, without any
> > -> RSVP path and without any MPLS path.
> >
> >   Oh! Ok...you would like to do Crankback in
> >   connection less IP environments?!?
> >
> >   In such a case, you might find below paper interesting:
> > http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers/te-latest.pdf
> >
> >   There was some discussion in E2E list regarding
> >   pros & cons of this approach. I couldn't find the URL
> >   but I vaguely remember that the subject of the discussion
> >   is "EC++N" or something like that...
> >
> > --

-- 
Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, Z.J. 310027
P.R.China

Tel: +86-571-87932423
Mobile: (0)13516813753
Email: jshen@cad.zju.edu.cn

**********************************************************************
* The SunShine of life is made up of very little beams which is      *
*  bright all the time                                               *
**********************************************************************

From saq66@umkc.edu  Tue Aug 13 10:40:00 2002
Received: from someone claiming to be kc-msxproto2.kc.umkc.edu
	puck.NOSPAM (kc-msxproto2.kc.umkc.edu [134.193.143.159])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with ESMTP id g7DEe0s3016395
	for <irtf-rr@puck.nether.net>; Tue, 13 Aug 2002 10:40:00 -0400
	(envelope-from saq66@umkc.edu)
Received-Date: Tue, 13 Aug 2002 10:40:00 -0400
Received: from KC-MAIL2.kc.umkc.edu ([134.193.143.162] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 13 Aug 2002 09:40:52 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 13 Aug 2002 09:40:17 -0500
Message-ID: <A29143A40AEAE3459FF829D1DD433161010A297A@KC-MAIL2.kc.umkc.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RE: AW: Differentiated Routing, not only plain rambo-SPF
Thread-Index: AcJC11fNv4OkNLEeRN64Eok2XBVR/g==
From: "Ayyasamy, Senthilkumar  (UMKC-Student)" <saq66@umkc.edu>
To: "Naidu, Venkata" <Venkata.Naidu@Marconi.com>,
   "Hummel Heinrich" <Heinrich.Hummel@icn.siemens.de>,
   "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
Cc: <routing-discussion@ietf.org>,
   "irtf-rr@puck.nether.net" <'irtf-rr@puck.nether.net'>
X-OriginalArrivalTime: 13 Aug 2002 14:40:52.0351 (UTC) FILETIME=[6C6140F0:01C242D7]
Subject: [Irtf-rr] RE: AW: Differentiated Routing, not only plain rambo-SPF
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

> -> yes,it is similar;
> -> but here it is about state-less IP forwarding, i.e. about=20
> -> forwarding the individual IP packets, without any
> -> RSVP path and without any MPLS path.
>=20
>   Oh! Ok...you would like to do Crankback in
>   connection less IP environments?!?
>=20
>   In such a case, you might find below paper interesting:
> http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers/te-
> latest.pdf
 I have studied this paper. Your are mis-interpreting here. The RPI
paper is an increment to OSPF or BGP for some traffic engineering
functionalties. It doesnt require signaling whereas, diffrout=20
requires signaling. Also, we are taking more from a diffserv=20
point of view.
 As i told, routing in peer to peer networks and some overlay=20
systems can use diffrout concept. We can explore certain non-
cooperative algorithms for an alternative to SPF. But as mentioned
before, this will not work out if we see from an engineering=20
perspective.=20

>=20
>   There was some discussion in E2E list regarding
>   pros & cons of this approach. I couldn't find the URL
>   but I vaguely remember that the subject of the discussion
>   is "EC++N" or something like that...

From rxtian@ns.6test.edu.cn  Sun Aug 18 05:58:41 2002
Received: from someone claiming to be ns.6test.edu.cn
	puck.NOSPAM (ns.6test.edu.cn [202.112.54.2])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with ESMTP id g7I9wdnB031967
	for <irtf-rr@puck.nether.net>; Sun, 18 Aug 2002 05:58:40 -0400
	(envelope-from rxtian@ns.6test.edu.cn)
Received-Date: Sun, 18 Aug 2002 05:58:40 -0400
Received: (from rxtian@localhost)
	by ns.6test.edu.cn (8.11.6/8.11.6) id g7IA6IU12826
	for irtf-rr@puck.nether.net; Sun, 18 Aug 2002 18:06:18 +0800 (CST)
	(envelope-from rxtian)
Date: Sun, 18 Aug 2002 18:06:18 +0800 (CST)
From: TIAN Rui-xiong <rxtian@ns.6test.edu.cn>
Message-Id: <200208181006.g7IA6IU12826@ns.6test.edu.cn>
To: irtf-rr@puck.nether.net
Subject: [Irtf-rr] interdomain routing inefficiency
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Id: <irtf-rr.puck.nether.net>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

Some papers have surveyed the impact of interdomain routing policy on end-to-end performance,such as inflating path,selection of inefficiency path. Does ssurvey how and which degree each policy set influence the end-to-end performance and how to improve it?

From jshen@cad.zju.edu.cn  Wed Aug 28 06:54:49 2002
Received: from someone claiming to be mail.cad.zju.edu.cn
	puck.NOSPAM (cad.zju.edu.cn [210.32.131.2])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with SMTP id g7SAsgnB003980
	for <irtf-rr@puck.nether.net>; Wed, 28 Aug 2002 06:54:44 -0400
	(envelope-from jshen@cad.zju.edu.cn)
Received-Date: Wed, 28 Aug 2002 06:54:44 -0400
Received: (qmail 8146 invoked from network); 28 Aug 2002 11:01:29 -0000
Received: from unknown (HELO cad.zju.edu.cn) (210.32.131.97)
  by 210.32.131.2 with SMTP; 28 Aug 2002 11:01:29 -0000
Message-ID: <3D6CAC43.2A500A3F@cad.zju.edu.cn>
Date: Wed, 28 Aug 2002 18:56:03 +0800
From: Jing Shen <jshen@cad.zju.edu.cn>
Reply-To: jshen@cad.zju.edu.cn
Organization: State Key Lab of CAD&CG
X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: MAHRAMIAN MEHRAN <M_MAHRAMIAN@ISC.IRANET.NET>, irtf-rr@puck.nether.net
References: <80EBCF44DEB4D611AD9700500436140E10C2D2@mail.faradis.com>
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit
Subject: [Irtf-rr] Re: question about multipath routing applicability and internet traffic
 pattern
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Id: IRTF RR WG List <irtf-rr.puck.nether.net>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

Dear Mr. MAHRAMIAN MEHRAN,

Thank you very much for comment.

The work has been finished and we resort to a method named 
"proactive multipath routing" to route according to traffic 
characteristics. With that method we try to route according to
traffic characteristics. And, simulation shows it could improve 
network performance significantly. The paper related is accepted
by QofIS'02 which will be held in Oct.16.

I have read the paper by Jin Cao and Cleverland, in which they state
traffic shows traffic in high speed network tend to be Possion
arrival. In contrast, steve claimed it do follow the way of Self-similar 
when he analyze his observation( You can find his message on ippm list).

The result seems contradictable but with our observation on ZJU-Net,
the bandwidth consumed do shows self-similar.( The ZJU-Net is 
a network consist by 10Mbps--100Mbps--1Gbps Ethernet and all of 
those in ZJU use it to transmit text, audio, video, software etc.)

So, what I conclude is : it still "self-similar" but there do exist
something behind our eyes. 

Regards



> 
> Dear Mr. Jing Shen
> 
> Although I am new in this field, but I think that we need a uniform network
> to guarantee QoS and make sure about loop free paths during multipath
> routing.
> Your results may differ from previous papers, because of self-similar
> traffic that you may have applied to your network. I have already received a
> message from one of my friends that claims that high bandwidth traffics are
> not necessarily self similar. You may work more on the statistical model of
> your traffic.
> 
> Mehran Mahramian Moallem
> Amirkabir University of Technology
> Tehran, Iran
> 
> This is a reply to the message below :
> 
> > Hi,
> 
> I want to make clear some problems while doing with multipath routing.
> 
> At current time routing is done with unipath ( including ECMP on it), while
> in some ISP network
> network optimization is done according to the traffic pattern derived from
> observation.
> it is found such methodology works fine in current network environment ( Am
> i right with current situation? )
> 
> But TE asks us to make full use of network resource and improve the
> network's adapting ability
> to bursty traffic. Although overprovision is adopted to deal with such
> requirements, it is not the
> least cost solution ( I think). But as we simulate some of the multipath
> routing method for
> intradomain routing, under uniform traffic pattern multipath always shows
> bad congestion
> delivery capacity. :-(
> 
> My questions raise with such experience is :
> 
> 1. How is the network traffic distributed when considering edge-to-edge
> connections ? What about aggregation?
>    what I want to make clear is : how non_uniformility is ? what is the flow
> level properties ?
> 
> 2. Is it reasonable to simulate a network with only a subset of node
> exchange traffic? How could
>    load sensitive routing affect the traffic distibution over the network?
> is there any paper on it?
> 
> I found i lost in the jungle as our experiments shows different result
> showed by some papers I read.
> Would you please give some help?
> 
> great thanks to each word you give.
> 
> Regards
> 
> Jing Shen

-- 
Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, Z.J. 310027
P.R.China

Tel: +86-571-87932423

Email: jshen@cad.zju.edu.cn

**********************************************************************
* The SunShine of life is made up of very little beams which is      *
*  bright all the time                                               *
**********************************************************************

From M_MAHRAMIAN@ISC.IRANET.NET  Tue Aug 27 09:20:34 2002
Received: from someone claiming to be isc.iranet.net
	puck.NOSPAM (host-64-110-148-5.interpacket.net [64.110.148.5])
	by puck.nether.net (8.12.3/8.9.3.2001112601.msa) with ESMTP id g7RDKFnB017141
	for <irtf-rr@puck.nether.net>; Tue, 27 Aug 2002 09:20:31 -0400
	(envelope-from M_MAHRAMIAN@ISC.IRANET.NET)
Received-Date: Tue, 27 Aug 2002 09:20:31 -0400
Received: by mail.faradis.com with Internet Mail Service (5.5.2653.19)
	id <RQ977SZT>; Tue, 27 Aug 2002 17:51:07 +0430
Message-ID: <80EBCF44DEB4D611AD9700500436140E10C2D2@mail.faradis.com>
From: MAHRAMIAN MEHRAN <M_MAHRAMIAN@ISC.IRANET.NET>
To: "'irtf-rr@puck.nether.net'" <irtf-rr@puck.nether.net>
Cc: "'jshen@cad.zju.edu.cn'" <jshen@cad.zju.edu.cn>
Date: Tue, 27 Aug 2002 17:51:03 +0430
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: [Irtf-rr] Re: question about multipath routing applicability and internet t
 raffic pattern&In-Reply-To=<000801c1ef89$b08b4600$a68320d2@topgun>
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Id: IRTF RR WG List <irtf-rr.puck.nether.net>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

Dear Mr. Jing Shen

Although I am new in this field, but I think that we need a uniform network
to guarantee QoS and make sure about loop free paths during multipath
routing.
Your results may differ from previous papers, because of self-similar
traffic that you may have applied to your network. I have already received a
message from one of my friends that claims that high bandwidth traffics are
not necessarily self similar. You may work more on the statistical model of
your traffic.

Mehran Mahramian Moallem
Amirkabir University of Technology
Tehran, Iran

This is a reply to the message below :


> Hi, 

I want to make clear some problems while doing with multipath routing. 

At current time routing is done with unipath ( including ECMP on it), while
in some ISP network 
network optimization is done according to the traffic pattern derived from
observation. 
it is found such methodology works fine in current network environment ( Am
i right with current situation? ) 

But TE asks us to make full use of network resource and improve the
network's adapting ability 
to bursty traffic. Although overprovision is adopted to deal with such
requirements, it is not the 
least cost solution ( I think). But as we simulate some of the multipath
routing method for 
intradomain routing, under uniform traffic pattern multipath always shows
bad congestion 
delivery capacity. :-( 

My questions raise with such experience is : 

1. How is the network traffic distributed when considering edge-to-edge
connections ? What about aggregation? 
   what I want to make clear is : how non_uniformility is ? what is the flow
level properties ? 
    
2. Is it reasonable to simulate a network with only a subset of node
exchange traffic? How could 
   load sensitive routing affect the traffic distibution over the network?
is there any paper on it? 
    
I found i lost in the jungle as our experiments shows different result
showed by some papers I read. 
Would you please give some help? 

great thanks to each word you give. 

Regards 

Jing Shen 



From craig@more.net  Wed Oct 23 17:02:53 2002
Received: from someone claiming to be um-msxproto2.um.umsystem.edu
	puck.NOSPAM (um-msxproto2.um.umsystem.edu [207.160.156.152])
	by puck.nether.net (8.12.6/8.9.3.2001112601.msa) with ESMTP id g9NL2TZR011251
	for <irtf-rr@puck.nether.net>; Wed, 23 Oct 2002 17:02:49 -0400
	(envelope-from craig@more.net)
Received-Date: Wed, 23 Oct 2002 17:02:49 -0400
Received: from um-mailnode1.um.umsystem.edu ([207.160.156.154]) by um-msxproto2.um.umsystem.edu with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 23 Oct 2002 16:03:57 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 23 Oct 2002 16:03:57 -0500
Message-ID: <DED9C2BCA57FC544ABF93CD5EE01F28C1FEEDE@um-mailnode1.um.umsystem.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Just an idea for a self organiziong IPv6 address space network
Thread-Index: AcJ617OyY4VZcFXJRpq04vipEjhUjw==
From: "Pepmiller, Craig E." <craig@more.net>
To: <irtf-rr@puck.nether.net>, <dmf@unl.edu>
X-OriginalArrivalTime: 23 Oct 2002 21:03:57.0585 (UTC) FILETIME=[B3F9E010:01C27AD7]
Subject: [Irtf-rr] Just an idea for a self organiziong IPv6 address space network
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Id: IRTF RR WG List <irtf-rr.puck.nether.net>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

I have been considering making a proposal for part of the reserved IPv6 =
address space.  The goal would be experimentation into a self-organizing =
network.  Please help me brainstorm what is needed for a self-organizing =
IP network.

Proposed protocol:  Address space allocation protocol (yes I know ASAP =
is taken)

Goal:  Automatically assign IPv6 address space to routers and clients.

Definitions:
	1) Seed point:  An Internic controlled, fixed start of network- the =
seed point is where all other networks directly or indirectly get their =
addressing from the reserved pool and their authority to delegate =
addressing.  This router/server has the only fixed address.
	2) Seed router:  The router/server that acts as the seed point.
	3) Delegate router:  Any router that understands the protocol and can =
act on the part of the seed for downstream connections.

How the protocol works:
	1) non-seed routers connect to the seed point (or a delegate) by using =
either pre-assigned addresses (as currently assigned by the Internic) or =
through the IPv6 local-link addressing
	2) non-seed routers make a request for address space and forward their =
current routing table (as generated by BGP and any of their IGPs)
	3) seed router (or it's delegate) executes tests to determine bandwidth =
and minimum latency of the local link to the requesting router
	4) seed router (or it's delegate) evaluates the routing table to =
determine expected address requirements; larger chunks of address space =
are allocated for routers with large, complex routing tables reflecting =
lots of aggregated routes; high speed connection to the seed (or =
delegate) and high latency (This is an attempt to cast the address net =
as wide as possible first.  High latency indicates that the requesting =
router is a larger physical distance from the seed point.) any routing =
table entries that use addressing from the reserved block for this =
protocol are discounted.  The goal is to make the address block =
assignment enough to cover the address requirements assuming that all =
downstream networks will accept addresses from the requesting router. =20
	5) the seed router or delegate assigns an address block to the =
requesting router and sets a secondary address on the connection to the =
starting address of that range
	6) the seed router (or delegate) communicates the address block to the =
requesting router.  If the address block allocation is more than enough =
to cover the downstream networks as indicated in the routing table then =
the seed router (or delegate) also communicates that the requesting =
router is able to act as a delegate
	7) the requesting router sets a secondary address to the starting =
address of the address block plus one and acknowledges the block =
assignment and agreement to be a delegate (if offered) from the new =
address
	8) the delegate router that made the assignment communicates the =
assignment to the seed point. =20
	9) the seed point makes a log entry of the assignment.

Potential modifications:
	1) multiple seed points
	2) upstream communication of unused address space for possible =
reassignment
	3) modification of the address block calculation to handle waste in =
other IPv6 address assignments.  The initial protocol relies on routing =
tables that are mostly IPv4 address blocks, which can easily be covered =
by a small segment of the IPv6 block reserved for the protocol.
	4) ability to make secondary assignments to routers that come back =
asking for more address space
	5) potential for the seed or a delegate to call for readdressing to =
compact the assigned address space and free up blocks for reassignment

Open questions:
	1) is bandwidth, latency and a routing table enough to make decisions =
on address block assignments?
	2) any suggestions?

Thanks-
-Craig Pepmiller=09

From Pekka.Nikander@nomadiclab.com  Sat Oct 26 10:12:51 2002
Received: from someone claiming to be n97.nomadiclab.com
	puck.NOSPAM (teldanex.hiit.fi [212.68.5.99])
	by puck.nether.net (8.12.6/8.9.3.2001112601.msa) with ESMTP id g9QECoZR025232
	for <irtf-rr@puck.nether.net>; Sat, 26 Oct 2002 10:12:51 -0400
	(envelope-from Pekka.Nikander@nomadiclab.com)
Received-Date: Sat, 26 Oct 2002 10:12:51 -0400
Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33])
	by n97.nomadiclab.com (Postfix) with ESMTP
	id 0E0711C; Sat, 26 Oct 2002 17:19:29 +0300 (EEST)
Message-ID: <3DBAA2E3.20004@nomadiclab.com>
Date: Sat, 26 Oct 2002 17:12:51 +0300
From: Pekka Nikander <Pekka.Nikander@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021021
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Pepmiller, Craig E." <craig@more.net>
Cc: irtf-rr@puck.nether.net, dmf@unl.edu
Subject: Re: [Irtf-rr] Just an idea for a self organiziong IPv6 address space
 network
References: <DED9C2BCA57FC544ABF93CD5EE01F28C1FEEDE@um-mailnode1.um.umsystem.edu>
In-Reply-To: <DED9C2BCA57FC544ABF93CD5EE01F28C1FEEDE@um-mailnode1.um.umsystem.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Id: IRTF RR WG List <irtf-rr.puck.nether.net>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

Pepmiller, Craig E. wrote:

> Open questions:
> 	2) any suggestions?

Multi-homing?  Non-hierarchical routing topologies?

--Pekka Nikander


From curtis@workhorse.fictitious.org  Tue Oct 29 12:25:32 2002
Received: from someone claiming to be workhorse.fictitious.org
	puck.NOSPAM (workhorse.fictitious.org [209.150.1.230])
	by puck.nether.net (8.12.6/8.9.3.2001112601.msa) with ESMTP id g9THPVZR032635
	for <irtf-rr@puck.nether.net>; Tue, 29 Oct 2002 12:25:31 -0500
	(envelope-from curtis@workhorse.fictitious.org)
Received-Date: Tue, 29 Oct 2002 12:25:31 -0500
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA43026;
	Tue, 29 Oct 2002 12:25:08 -0500 (EST)
	(envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200210291725.MAA43026@workhorse.fictitious.org>
To: "Pepmiller, Craig E." <craig@more.net>
cc: irtf-rr@puck.nether.net, dmf@unl.edu
Reply-To: curtis@fictitious.org
Subject: Re: [Irtf-rr] Just an idea for a self organiziong IPv6 address space network 
In-reply-to: Your message of "Wed, 23 Oct 2002 16:03:57 CDT."
             <DED9C2BCA57FC544ABF93CD5EE01F28C1FEEDE@um-mailnode1.um.umsystem.edu> 
Date: Tue, 29 Oct 2002 12:25:08 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Id: IRTF RR WG List <irtf-rr.puck.nether.net>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

In message <DED9C2BCA57FC544ABF93CD5EE01F28C1FEEDE@um-mailnode1.um.umsystem.edu
>, "Pepmiller, Craig E." writes:
> I have been considering making a proposal for part of the reserved IPv6 addre
> ss space.  The goal would be experimentation into a self-organizing network. 
>  Please help me brainstorm what is needed for a self-organizing IP network.


I suggest that you stop wasting your time.  The Internet is a mesh at
many oranizational and topological levels, not a hierarchy.  The
business interests at play here barely trust each other and accepting
addresses in such a fashion just isn't going to fly.

Curtis

From randy@psg.com  Tue Oct 29 14:20:40 2002
Received: from someone claiming to be roam.psg.com
	puck.NOSPAM (exim@dhcp3253.nanog26.merit.net [192.35.167.253] (may be forged))
	by puck.nether.net (8.12.6/8.9.3.2001112601.msa) with ESMTP id g9TJKdZR005643
	for <irtf-rr@puck.nether.net>; Tue, 29 Oct 2002 14:20:39 -0500
	(envelope-from randy@psg.com)
Received-Date: Tue, 29 Oct 2002 14:20:39 -0500
Received: from localhost
	([127.0.0.1] helo=roam.psg.com.psg.com ident=randy)
	by roam.psg.com with esmtp (Exim 4.05)
	id 186buy-000042-00; Tue, 29 Oct 2002 11:20:48 -0800
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Pepmiller, Craig E." <craig@more.net>
Cc: <irtf-rr@puck.nether.net>, <dmf@unl.edu>
Subject: Re: [Irtf-rr] Just an idea for a self organiziong IPv6 address space network
References: <DED9C2BCA57FC544ABF93CD5EE01F28C1FEEDE@um-mailnode1.um.umsystem.edu>
Message-Id: <E186buy-000042-00@roam.psg.com>
Date: Tue, 29 Oct 2002 11:20:48 -0800
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Id: IRTF RR WG List <irtf-rr.puck.nether.net>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

> I have been considering making a proposal for part of the reserved IPv6
> address space.  The goal would be experimentation into a self-organizing
> network.

this is interesting research.  there are mechanisms in the address
allocation work to allow experimental space.  therefore i suggest
concentrating on the research goals and tactics, and only then get
down to how to get address space.

randy


From dima@krioukov.net  Tue Oct 29 16:24:23 2002
Received: from someone claiming to be mail.krioukov.net
	puck.NOSPAM (pcp744791pcs.reston01.va.comcast.net [68.49.138.160])
	by puck.nether.net (8.12.6/8.9.3.2001112601.msa) with ESMTP id g9TLOMZR009070
	for <irtf-rr@puck.nether.net>; Tue, 29 Oct 2002 16:24:22 -0500
	(envelope-from dima@krioukov.net)
Received-Date: Tue, 29 Oct 2002 16:24:22 -0500
Received: from DIMA1 (5-62.dialup.lanck.net [62.152.65.62])
	by mail.krioukov.net (8.9.3/8.9.3) with SMTP id QAA08712;
	Tue, 29 Oct 2002 16:24:26 -0500
From: "Dmitri Krioukov" <dima@krioukov.net>
To: "Pepmiller, Craig E." <craig@more.net>
Cc: <irtf-rr@puck.nether.net>
Subject: RE: [Irtf-rr] Just an idea for a self organiziong IPv6 address space network
Date: Wed, 30 Oct 2002 00:24:22 +0300
Message-ID: <NCBBIKACLKNMKDHKKKNFKEFNHGAA.dima@krioukov.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-reply-to: <DED9C2BCA57FC544ABF93CD5EE01F28C1FEEDE@um-mailnode1.um.umsystem.edu>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Id: IRTF RR WG List <irtf-rr.puck.nether.net>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

I perfectly understand Curtis's reply.
It would be quite surprising to know
how anything like this could work on
meshy networks. Some preliminary
calculations based on fundamental
Kleinrock's results on hierarchical
routing are included in:
http://www.krioukov.net/~dima/pro/lulea/lulea-msrw.ppt
--
dima.


From yxw@cordelia.lcs.mit.edu  Tue Oct 29 16:50:40 2002
Received: from someone claiming to be cordelia.lcs.mit.edu
	puck.NOSPAM (cordelia.lcs.mit.edu [18.26.0.55])
	by puck.nether.net (8.12.6/8.9.3.2001112601.msa) with ESMTP id g9TLodZR009981
	for <irtf-rr@puck.nether.net>; Tue, 29 Oct 2002 16:50:40 -0500
	(envelope-from yxw@cordelia.lcs.mit.edu)
Received-Date: Tue, 29 Oct 2002 16:50:40 -0500
Received: from cordelia.lcs.mit.edu (localhost [127.0.0.1])
	by cordelia.lcs.mit.edu (8.12.3/8.12.3) with ESMTP id g9TLol1O015971;
	Tue, 29 Oct 2002 16:50:47 -0500 (EST)
	(envelope-from yxw@cordelia.lcs.mit.edu)
Date: Tue, 29 Oct 2002 16:50:46 -0500
Message-ID: <pzvbs5c3oeh.wl@cordelia.lcs.mit.edu>
From: Xiaowei Yang <yxw@cordelia.lcs.mit.edu>
To: "Dmitri Krioukov" <dima@krioukov.net>
Cc: "Pepmiller, Craig E." <craig@more.net>, <irtf-rr@puck.nether.net>
Subject: Re: [Irtf-rr] Just an idea for a self organiziong IPv6 address space network
In-Reply-To: <NCBBIKACLKNMKDHKKKNFKEFNHGAA.dima@krioukov.net>
References: <DED9C2BCA57FC544ABF93CD5EE01F28C1FEEDE@um-mailnode1.um.umsystem.edu>
	<NCBBIKACLKNMKDHKKKNFKEFNHGAA.dima@krioukov.net>
User-Agent: Wanderlust/2.8.1 (Something) Emacs/21.2 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Id: IRTF RR WG List <irtf-rr.puck.nether.net>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

just out of curiosity, can someone explain what "meshy networks" are?
I understand Internet is no telephone network, and does not have a
strict hierarchy. but the customer-provider relationship defines a
hierarchical relationship, and two provider trees may be connected by
horizontal peering links. so, why is the idea of self organizing
address space so surprising?


At Wed, 30 Oct 2002 00:24:22 +0300,
Dmitri Krioukov wrote:
> 
> I perfectly understand Curtis's reply.
> It would be quite surprising to know
> how anything like this could work on
> meshy networks. Some preliminary
> calculations based on fundamental
> Kleinrock's results on hierarchical
> routing are included in:
> http://www.krioukov.net/~dima/pro/lulea/lulea-msrw.ppt
> --
> dima.
> 
> _______________________________________________
> irtf-rr mailing list
> irtf-rr@puck.nether.net
> http://puck.nether.net/mailman/listinfo/irtf-rr


From dima@krioukov.net  Wed Oct 30 14:50:29 2002
Received: from someone claiming to be mail.krioukov.net
	puck.NOSPAM (pcp744791pcs.reston01.va.comcast.net [68.49.138.160])
	by puck.nether.net (8.12.6/8.9.3.2001112601.msa) with ESMTP id g9UJoSZR024515
	for <irtf-rr@puck.nether.net>; Wed, 30 Oct 2002 14:50:28 -0500
	(envelope-from dima@krioukov.net)
Received-Date: Wed, 30 Oct 2002 14:50:28 -0500
Received: from DIMA1 (5-19.dialup.lanck.net [62.152.65.19])
	by mail.krioukov.net (8.9.3/8.9.3) with SMTP id OAA13902;
	Wed, 30 Oct 2002 14:50:09 -0500
From: "Dmitri Krioukov" <dima@krioukov.net>
To: "Xiaowei Yang" <yxw@cordelia.lcs.mit.edu>
Cc: <irtf-rr@puck.nether.net>, <curtis@workhorse.fictitious.org>
Subject: RE: [Irtf-rr] Just an idea for a self organiziong IPv6 address space network 
Date: Wed, 30 Oct 2002 22:50:09 +0300
Message-ID: <NCBBIKACLKNMKDHKKKNFMEGEHGAA.dima@krioukov.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-reply-to: <200210301723.MAA56113@workhorse.fictitious.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: irtf-rr-admin@puck.nether.net
Errors-To: irtf-rr-admin@puck.nether.net
X-BeenThere: irtf-rr@puck.nether.net
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=unsubscribe>
List-Id: IRTF RR WG List <irtf-rr.puck.nether.net>
List-Post: <mailto:irtf-rr@puck.nether.net>
List-Help: <mailto:irtf-rr-request@puck.nether.net?subject=help>
List-Subscribe: <http://puck.nether.net/mailman/listinfo/irtf-rr>,
	<mailto:irtf-rr-request@puck.nether.net?subject=subscribe>
List-Archive: <http://puck.nether.net/pipermail/irtf-rr/>

For one of the best attempts to uncover the
current Internet hierarchy incorporating customer-
provider relationship please see this:
http://www.cs.berkeley.edu/~sagarwal/research/BGP-hierarchy/

However, it doesn't change a bit in calculations
derived from the fundamental Kleinrock's results.
And this is essentially reinforced by Curtis's
considerations below.
--
dima.

> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]
> Sent: Wednesday, October 30, 2002 8:24 PM
> To: Xiaowei Yang
> Cc: Dmitri Krioukov; Pepmiller, Craig E.; irtf-rr@puck.nether.net
> Subject: Re: [Irtf-rr] Just an idea for a self organiziong IPv6 address
> space network 
> 
> 
> 
> In message <pzvbs5c3oeh.wl@cordelia.lcs.mit.edu>, Xiaowei Yang writes:
> > 
> > just out of curiosity, can someone explain what "meshy networks" are?
> > I understand Internet is no telephone network, and