Re: [e2e] Question about fast path / slow path and IPv6

Alex Cannara wrote:

>respectable network-software vendors, like Level7, etc.

Well, since Alex mentions L7 in nearly every post, I feel compelled to say
that my current employer had to abandon L7 stack due to intractable
stability problems even with trivial configurations, resulting in 
a year of wasted efforts by the routing software group.  Caveat emptor.

--vadim

PS  I'm speaking for myself, and the above statement is my personal
    opinion.

Re: [e2e] Question about fast path / slow path and IPv6

Vadim, that's too bad, I just mentioned L7, because I've known folks who had
good results with them, and have heard some bad things about some other stack
vendors, whom I didn't mention.  Caveat emptor indeed!  

My point is, by the way, that there's no good reason to think any vendor's
stacks work exactly as any other's, with respect to many things, including the
current topic of allocating pkts to fast ot slow path.  These differing code
stes can not just appear across different box vendors, but within them as
well, as for example when Cisco bought a successful switch vendor and
subsequent boxes with Cisco labels worked differently, even incompatibly
together.

Alex

Vadim Antonov wrote:
> 
> Alex Cannara wrote:
> 
> >respectable network-software vendors, like Level7, etc.
> 
> Well, since Alex mentions L7 in nearly every post, I feel compelled to say
> that my current employer had to abandon L7 stack due to intractable
> stability problems even with trivial configurations, resulting in
> a year of wasted efforts by the routing software group.  Caveat emptor.
> 
> --vadim
> 
> PS  I'm speaking for myself, and the above statement is my personal
>     opinion.

[e2e] Call for Papers: SIGMETRICS 2004/ Performance 2004

                           Call for Papers

             ******SIGMETRICS 2004/ Performance 2004 ******

                 Joint International Conference on
            Measurement and Modeling of Computer Systems
        Sponsored by ACM SIGMETRICS and  IFIP Working Group 7.3
                  June 12-16th, 2004, New York, NY
                http://www.cs.columbia.edu/~sigm2004/

The joint SIGMETRICS/Performance conference solicits papers on the
development and application of state-of-the-art, broadly applicable
analytic, simulation, and measurement-based performance evaluation
techniques.  Of particular interest is work that furthers the
state-of-the-art in performance evaluation methods, or combines
analytic and experimental methods to evaluate design trade-offs in real
systems.

Topics of interest include but are not limited to:

- Performance-oriented design and evaluation studies of communication
  networks, Internet servers, computer architectures, database
  systems, operating systems, distributed systems, multimedia systems,
  mobile and handheld systems, file and I/O systems, memory systems,
  real-time systems, and dependable systems, including case studies
  and performance-evaluation tools.

- Performance methodology techniques, algorithms, and tools for
  analytic modeling, system measurement and monitoring, model

RE: [e2e] Question about fast path / slow path and IPv6

Michael,

-> This goes to the router people out there:
-> 
-> Is IP fast path / slow path processing (for packets carrying
-> IP options) similar for IPv4 and IPv6 in most current routers?

  I am trying to expand and explain your words "processing" and 
  "similar" clearly in technical terms:

  1. There is clearly a big difference between slow path vs fast 
     path. But the question is not that I hope. That question is 
     about IPv4 vs IPv6.

  2. Major changes between IPv4 and IPv6 are:

     * Fragmentation - IPv6 completely avoid fragmentation in
       transit routers. So the fragmentation "processing" 
       overhead is eliminated for IPv6.

     * Header Checksum - IPv6 assumes that lower layer checksums 
       are enough for hop-by-hop bit/packet integrity and
       higher-layer checksums are enough for end-end to 
       integrity. So checksum processing is eliminated in IPv6.
       (don

       Note that in IPv4 fragmentation and/or checksum in 
       transit routers is a rare event. 

     * Address/Tag lookup: Here comes some complex processing 

[e2e] TE using IGP metrics

Hi all,

What are the most common methods for doing non-MPLS traffic engineering? 
How is the performance of such methods characterized or evaluated? Any 
tools that may be used in such process where we can qantify the 
performance of such methods? (NS2 maybe???). Any pointers to the 
literature and websites would be great.

Thanks,
Zartash

Re: [e2e] TE using IGP metrics

am not too sure how one can do "TE" using IGP metric...

i mean you would need acls

but IGP metric would play no role at all as the IGP would tend to send the
packet along the best IGP path....
hence you could probably multipath, but "TE"....i dont think one can
without acls.....

> Hi all,
>
> What are the most common methods for doing non-MPLS traffic
> engineering?  How is the performance of such methods characterized or
> evaluated? Any  tools that may be used in such process where we can
> qantify the
> performance of such methods? (NS2 maybe???). Any pointers to the
> literature and websites would be great.
>
> Thanks,
> Zartash

Re: [e2e] TE using IGP metrics

See:

Bernard Fortz, Jennifer Rexford, and Mikkel Thorup, "Traffic
engineering with traditional IP routing protocols," IEEE
Communication Magazine, October 2002.
http://www.research.att.com/~jrex/papers/ieeecomm02.long.pdf

-Nick

On Thu, Sep 04, 2003 at 02:26:05AM +0500, Zartash Afzal Uzmi wrote:
> Hi all,
> 
> What are the most common methods for doing non-MPLS traffic engineering? 
> How is the performance of such methods characterized or evaluated? Any 
> tools that may be used in such process where we can qantify the 
> performance of such methods? (NS2 maybe???). Any pointers to the 
> literature and websites would be great.
> 
> Thanks,
> Zartash

[e2e] (no subject)

RE: [e2e] TE using IGP metrics

I guessed someone will point out to this paper but it seems that not much
literature is available. I couldn't find any work that is built upon this
paper that you have referenced. Somewhat theoretical treatment of
closely-related issues is given by V. Ramachandaran and R. Chowdhury at UT,
Austin but they look at it from theoretical perspective. Thanks.

Zartash

-----Original Message-----
From: Nick Feamster [mailto:feamster <at> lcs.mit.edu]
Sent: Friday, September 05, 2003 12:02 AM
To: Zartash Afzal Uzmi
Cc: end2end-interest <at> postel.org
Subject: Re: [e2e] TE using IGP metrics

See:

Bernard Fortz, Jennifer Rexford, and Mikkel Thorup, "Traffic
engineering with traditional IP routing protocols," IEEE
Communication Magazine, October 2002.
http://www.research.att.com/~jrex/papers/ieeecomm02.long.pdf

-Nick

On Thu, Sep 04, 2003 at 02:26:05AM +0500, Zartash Afzal Uzmi wrote:
> Hi all,
>
> What are the most common methods for doing non-MPLS traffic engineering?
> How is the performance of such methods characterized or evaluated? Any
> tools that may be used in such process where we can qantify the

RE: [e2e] TE using IGP metrics

Hi,

TE with non-MPLS methods is possible - it is modelled as an optimization 
problem.   One could use any technique (MIP, ILP, etc.) to solve this 
problem.  In my personal experience  genetic algorithms  (GA) outperform 
classical methods when it comes to efficiency.  One could argue about 
the quality of results as GAs are prone to getting stuck in local 
optimas and produce sub-optimal results, however, there are ways to 
tackle the problem.  Take a  look at the following paper which perhaps 
is one of the best i have seen on the subject.

*"A Genetic Algorithm For The Weight Setting Problem In OSPF Routing" * 
<http://citeseer.nj.nec.com/context/2068192/526656> M. Ericsson, M. G. 
C. Resende, P. M. Pardalos

http://citeseer.nj.nec.com/526656.html

regards,

SM

Zartash Afzal Uzmi wrote:

 >I guessed someone will point out to this paper but it seems that not much
 >literature is available. I couldn't find any work that is built upon this
 >paper that you have referenced. Somewhat theoretical treatment of
 >closely-related issues is given by V. Ramachandaran and R. Chowdhury 
at UT,
 >Austin but they look at it from theoretical perspective. Thanks.
 >