From touch at ISI.EDU  Fri Jun  2 15:28:40 2006
From: touch at ISI.EDU (Joe Touch)
Date: Fri, 02 Jun 2006 15:28:40 -0700
Subject: [e2e] new network architecture idea -
In-Reply-To: <20060527045214.GA4401@colorado.edu>
References: <E1FhTba-0000sE-00@mta1.cl.cam.ac.uk>
	<44712935.9010509@reed.com>	<4477C404.2090605@isi.edu>
	<20060527045214.GA4401@colorado.edu>
Message-ID: <4480BB98.6030306@isi.edu>

I'm not sure what 'circumscribed' means in a communication channel.

If it means inverting send/receive gives the designer a different 
perspective, fine, but that's not an architecture as much as a 
philosophy. Anything else amounts to redefining communication, IMO.

Joe


Eric W. Anderson wrote:
> I think what it may come down to is this:  In receiver-initiated
> communication, the (former) receiver becomes a sender, but maybe *what*
> they send can be sufficiently circumscribed that the problems become
> more manageable.  
> 
> -Eric
> 
> Thus spake Joe Touch (touch at ISI.EDU):
> 
>> Communication is initiated at the sender by definition; initiating at
>> the receiver just means the receiver becomes the sender ;-)
>>
>> The sender is the one that decides what to put out and labels it
>> according to what receiver it wants to reach (whether directly, via
>> unicast, or indirectly, by group ID, XML tag, etc.) The list of what
>> receivers are reachable must be known in advance.
>>
>> I.e., although it seems like receiver-driven might get us somewhere, how
>> much of it is just relabeling the endpoints?
>>
>> Joe
>>
>>

From weigengyu at hotmail.com  Sun Jun  4 20:55:45 2006
From: weigengyu at hotmail.com (weigengyu)
Date: Mon, 5 Jun 2006 11:55:45 +0800
Subject: [e2e] Fw:  signaling performance on TCP
Message-ID: <BAY110-DAV176646D8E03EA6C8C7C2F8B3940@phx.gbl>


----- Original Message ----- 
From: "weigy" <weigy at aceway.com.cn>
To: "Randall Stewart" <randall at lakerest.net>; "Fred Baker" <fred at cisco.com>
Cc: <end2end-interest at postel.org>
Sent: Friday, June 02, 2006 1:02 PM
Subject: Re: [e2e] signaling performance on TCP


> Thank you for your replys. 
> And I would like to explain why I put the query.
> 
> We make efforts on researching the performance of Signaling of IMS.
> From 3GPP and IETF, Sig of IMS would be transferred by SIP, 
> and SIP would be over TCP, UDP or SCTP.
> 
> But, when we say signaling, most of people would like to compare it with SS7.
> As everybody knows, SS7 is lack of end to end transmission control,
> which has been the basis of TCP as end-to-end arguments.
> Although SCCP contains both connection and connectionless transmission, 
> most of the messages transfer use connectionless.
> 
> For SS7,  we know that the traffic engineering in telecom based on Erlang formula even now. 
> The analysis model is M/M/n.
> The link capacity has been limited to 0.7 Erlang in engineering design and network operations. 
> From the preformance point of view, we know the limitation of each signaling link,
> we know the required delay limitation in each link and node (STP or SP), 
> So we have the signalling performance matrices. 
> 
> The problem is  how the IMS signaling performace will be 
> when it is transfered by SIP, and SIP may be over TCP, UDP or SCTP. 
> The problem may be how the setup delay will be in such situation? 
> How the signaling would be affected by the difference when IMS sig in SIP over TCP, UDP or SCTP,
> and how to make it complied with the requirements of telecom.
> Is it adqate to put Sig/SIP/UDP, or Sig/SIP/TCP, or Sig/SIP/SCTP into use 
> at wireless link or core networks.   
> 
> There are many differences between SS7 and Sig of IMS, 
> so, there are several problems that need to study.
> And we want to know if there are any related works, thoughts or publications.  
> 
> Wei, Gengyu 
> The School of Computer Science & Technology
> Beijing University of Posts & Telecommunications 
> 
> ----- Original Message ----- 
> From: "Randall Stewart" <randall at lakerest.net>
> To: "Fred Baker" <fred at cisco.com>
> Cc: "weigengyu" <weigengyu at hotmail.com>; <end2end-interest at postel.org>
> Sent: Thursday, June 01, 2006 11:31 PM
> Subject: Re: [e2e] signaling performance on TCP
> 
> 
>> Fred:
>> 
>> In principle I agree.. with on cavet..
>> 
>> Most TCP stacks today require a blocking connect()
>> 
>> so you get
>> 
>> -----SYN---->
>> <----SYN-ACK---
>> -----ACK---->
>> unblock
>> ----First-Data---->
>> <----ACK +....
>> 
>> This is true for SCTP if you use the socket api one-2-one model
>> but NOT true for SCTPif you use the socket api one-2-many model.. you
>> get
>> ----INIT---->
>> <---INIT-ACK---
>> ---COOKIE+DATA--->
>> <---COOKIE-ACK+SACK---
>>  <---DATA
>> 
>> That all being siad this is only a slight advantage and
>> probably just a small bit..
>> 
>> The only place that SCTP makes a lot more sense for SIP is
>> between SIP proxy's.. in that case we can have one
>> connection and route calls over different streams to
>> avoid HOL Blocking...  But I don't think that is what
>> the query was about :-D
>> 
>> R
>> 
>> Fred Baker wrote:
>>> I don't see why SCTP would fare one iota different than TCP. In context, 
>>> they have essentially equivalent message exchange. SIP on UDP would do 
>>> it in less RTTs, in that there would be no SYN/SYN-ACK or FIN/FIN-ACK. I 
>>> think the real difference there is debateable, though.
>>> 
>>> Allocating excess capacity to a signaling channel and putting SIP into 
>>> it basically allows SIP to bypass queues that form around file 
>>> transfers. Personally, I think this is a good thing, and RFC 4542 
>>> supports it.
>>> 
>>> 
>>> On May 15, 2006, at 11:13 PM, weigengyu wrote:
>>> 
>>>> Hi,
>>>>  
>>>> Can anyone give an answer to my question?
>>>>  
>>>> 1. SIP will be the signaling protocol for IMS in 3GPP,and SIP can be 
>>>> over TCP, UDP, or SCTP;
>>>> 2. For SIP over TCP as signaling transfer, are there any analysis 
>>>> model for the performance evaluation?
>>>> 3. Somebody told me that there is no problem if you allocate enough 
>>>> bandwidth to signaling channel.
>>>>    (the enough bandwidth in engineering design may be 10% of total 
>>>> transmission line capacity) 
>>>>    So, is there any measured data to support the above design.
>>>>  
>>>> 4. Could you get better performance by SIP over SCTP than SIP over TCP 
>>>> for signaling transfer?
>>>>  
>>>> Gengyu
>>>>
>>> 
>> 
>> 
>> -- 
>> Randall Stewart
>> 803-345-0369 <or> 815-342-5222(cell)
>>

From falk at ISI.EDU  Thu Jun  8 11:13:38 2006
From: falk at ISI.EDU (Aaron Falk)
Date: Thu, 8 Jun 2006 11:13:38 -0700
Subject: [e2e] Open mailing list for the discussion of Independent RFC
	Submissions Process
References: <E1Fo5dQ-0000Gx-AA@ietf.org>
Message-ID: <B5A1F0E6-750B-498E-BDE3-06EF3CC143E7@isi.edu>

Forwarded from Leslie Daigle, IAB Chair:


As part its role in supporting the RFC Editor function, the Internet
Architecture Board (IAB) has created a public mailing list for the  
discussion of
the RFC Independent Submissions process.

The purpose of this discussion is to achieve consensus, in the coming  
weeks, on
a process for fair and appropriate approval of independent  
submissions to the
RFC series.  These are separate from IETF, IAB or IRTF approved  
submissions.

Individuals familiar with the RFC series and working in the Internet  
research
and engineering community are invited to join this mailing list and  
participate.

   independent<at>ietf.org

   https://www1.ietf.org/mailman/listinfo/independent


There is an initial draft proposal, available at

   http://www.ietf.org/internet-drafts/draft-klensin-rfc- 
independent-02.txt


Leslie Daigle,
Chair, IAB.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20060608/d53e2d49/PGP.bin

From francis at cs.cornell.edu  Fri Jun  9 05:15:04 2006
From: francis at cs.cornell.edu (Paul Francis)
Date: Fri, 9 Jun 2006 08:15:04 -0400
Subject: [e2e] Offpath BoF at Montreal IETF
Message-ID: <E6F7A586E0A3F94D921755964F6BE006117C1F@EXCHANGE2.cs.cornell.edu>

 
Gang,

The offpath BoF, titled "Path-decoupled Signaling for Data", as been approved
for the next IETF.  The proposed topic for the BoF is copied below, and is
also available at http://www.cs.cornell.edu/people/francis/offpath/.

This message is being sent (separately) to the nsis, behave, p2psip,
e2e-interest, and ietf mailing lists.

The purpose of this message is to solicite feedback about the topics and
agenda for the BoF.  Note that the immediate goal of the BoF is to create an
IRTF research group.  

A BoF mailing list has been created (see below).

Thanks,

PF


---------------------------------------------------------------------

Path-decoupled Signaling for Data (offpath)
 

To be held at the 66th (Montreal) IETF, under the auspices of the Transport
Area (Lars Eggert), and coordinated with the IRTF (Aaron Falk).

 

BoF Chair:  TBD

  

BoF Initiators: 
Paul Francis and Saikat Guha (both of Cornell University) <francis,
saikat>@cs.cornell.edu

 

General Discussion: off-path-bof at ietf.org To Subscribe:
off-path-bof-request at ietf.org In Body: (un)subscribe
Archive: http://www.ietf.org/mail-archive/web/off-path-bof/index.html

This page at:  http://www.cs.cornell.edu/people/francis/offpath

 

Purpose of BoF:
Gauge interest in creating an IRTF research group on this topic.

  

Synopsis: 

Path-decoupled (or off-path) signaling, in the form of SIP, has proven to be
a very powerful mechanism for facilitating media connection establishment
between hosts.  It provides friendly naming, discovery, user mobility,
authentication, transport and application negotiation, and even NAT/FW
traversal for UDP and, more recently, TCP.  Furthermore, it is network
independent, working equally well for IPv4 and IPv6.  This set of features,
however, would be attractive to all types of data sessions, not just media.
The purpose of this BoF is to gauge interest in the design of off-path
signaling (probably but not necessarily using SIP) for establishing all kinds
of non-public-server data sessions.  A positive outcome of this BoF would be
the formation of an IRTF group, though other outcomes will of course be
considered.

We are particularly interested in models of off-path signaling that improve
security beyond today's address/port/deep-inspection model.  The use of
path-decoupled signaling gives both the middle and the ends the opportunity
to assert policy and negotiate an acceptable session.  We would like to
explore cases where the off-path signaling operates alone (i.e. NAT/FW
traversal with legacy NAT/FW's), as well as where it operates in conjunction
with subsequent path-coupled signaling (either in-band or out-of-band).
Considering that an application can always lie about what it is, we would
also like to explore how to couple the signaling primitives with emerging OS
security features (i.e. trusted computing platforms).  Beyond security, we
would like to explore the use of off-path signaling for such features as user
and host mobility, transport negotiation (i.e. TCP versus SCTP), anycast and
multicast, billing, and time-delayed communications messaging). 

The ultimate goal here is that some or all of these features become part of
the standard sockets API of typical OS's, and that infrastructure support for
the signaling becomes ubiquitous (in the same sense that DNS is ubiquitous).
This would allow application developers, security vendors (middlebox and
endhost), users, and network administrators to converge on a unified method
of naming and connection establishment over the Internet.  (By contrast,
naming and connection establishment through NATs and firewalls today is ad
hoc and usually application specific, variously involving email, IM services,
dynamic DNS services, manual configuration of ports, and so on.) 

Of the IETF working groups, this BoF is most closely aligned with the nsis WG
in the Transport Area, especially the NAT/FW NSLP.  The following gives an
example of how an off-path signaling protocol would work in conjunction with
the NAT/FW NSLP.   This is only an example...there are other approaches and
variants on this example. 

Say an application wishes to establish a TCP connection with a "peer", where
both peers are behind NAT/FW's.  The initiating peer off-path signals a
connection request.  The request contains the application name, user names,
authentication information (Certs or Diameter), and information about the
preferred transport (TCP, SSL, IPSec, etc.).  The off-path request is checked
by the initiating endhost's policy, and then flows through policy boxes
representing the initiator's and the recipient's networks.  This gives both
sides an opportunity to reject the request, or to request different transport
or security characteristics, or to accept and pass on the request as-is.
Note that the policy boxes could both be far from either ends' physical
network, thus not revealing the IP addresses of either end until the
connection is approved.  The policy boxes could also be widely replicated. 

Assuming the connection request is approved, the endhosts use the NAT/FW NSLP
to obtain address and port mappings from their respective NAT boxes.  These
are conveyed through the off-path signaling channel.  In addition, the policy
boxes create secure tokens that firewalls can use to allow the approved
connection.  These tokens are passed to the endhosts through off-path
signaling, which then convey them on-path, either in-band or out-of-band
(i.e. the NAT/FW NSLP), to traverse the firewall.

 

Supporting material:
http://nutss.gforge.cis.cornell.edu/

 

 

 

From fenner at research.att.com  Mon Jun 12 13:05:51 2006
From: fenner at research.att.com (Bill Fenner)
Date: Mon, 12 Jun 2006 13:05:51 -0700
Subject: [e2e] Legal fragment sizes
Message-ID: <200606122005.k5CK5psT012075@bright.research.att.com>


>I wonder how many stacks we can crash this way!?

The "Ping of Death" DoS attack was based on this - sending a packet with
total size 65538 - so while in 1996 the answer was "lots", I suspect
now the answer may be "few".

  Bill

From touch at ISI.EDU  Tue Jun 13 15:58:35 2006
From: touch at ISI.EDU (Joe Touch)
Date: Tue, 13 Jun 2006 15:58:35 -0700
Subject: [e2e] seeking help recalling a network term
Message-ID: <448F431B.8060809@isi.edu>

Hi, all,

I apologize if this is a simple question:

I'm trying to recall the name for a network where the number of
packets/tokens/empty-frames inside the net is a constant, i.e., where
real data can be put into these units when empty, and emptied at the
destination, but that the whole net is otherwise just shuffling around
these 'holes'.

I'm recalling a term akin to "idempotent" or "isomorphic" - though I
know both are wrong ;-) Does anyone recall the term for these nets?

(I recall their being vogue in the late 1980's, but not much after that).

Thanks,

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20060613/f051fd00/signature.bin

From bmanning at vacation.karoshi.com  Tue Jun 13 17:24:00 2006
From: bmanning at vacation.karoshi.com (bmanning@vacation.karoshi.com)
Date: Wed, 14 Jun 2006 00:24:00 +0000
Subject: [e2e] seeking help recalling a network term
In-Reply-To: <448F431B.8060809@isi.edu>
References: <448F431B.8060809@isi.edu>
Message-ID: <20060614002400.GA2554@vacation.karoshi.com.>

On Tue, Jun 13, 2006 at 03:58:35PM -0700, Joe Touch wrote:
> Hi, all,
> 
> I apologize if this is a simple question:
> 
> I'm trying to recall the name for a network where the number of
> packets/tokens/empty-frames inside the net is a constant, i.e., where
> real data can be put into these units when empty, and emptied at the
> destination, but that the whole net is otherwise just shuffling around
> these 'holes'.
> 
> I'm recalling a term akin to "idempotent" or "isomorphic" - though I
> know both are wrong ;-) Does anyone recall the term for these nets?
> 
> (I recall their being vogue in the late 1980's, but not much after that).
> 
> Thanks,
> 
> Joe
> 

	you mean like the 802.4 and 802.5 specs?

--bill


From touch at ISI.EDU  Tue Jun 13 17:27:52 2006
From: touch at ISI.EDU (Joe Touch)
Date: Tue, 13 Jun 2006 17:27:52 -0700
Subject: [e2e] seeking help recalling a network term
In-Reply-To: <448F431B.8060809@isi.edu>
References: <448F431B.8060809@isi.edu>
Message-ID: <448F5808.5080007@isi.edu>

PS - found it via some indirect means; it's isarithmic ;-)

Joe

Joe Touch wrote:
> Hi, all,
> 
> I apologize if this is a simple question:
> 
> I'm trying to recall the name for a network where the number of
> packets/tokens/empty-frames inside the net is a constant, i.e., where
> real data can be put into these units when empty, and emptied at the
> destination, but that the whole net is otherwise just shuffling around
> these 'holes'.
> 
> I'm recalling a term akin to "idempotent" or "isomorphic" - though I
> know both are wrong ;-) Does anyone recall the term for these nets?
> 
> (I recall their being vogue in the late 1980's, but not much after that).
> 
> Thanks,
> 
> Joe
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20060613/d7a51f7d/signature.bin

From chris at cs.utexas.edu  Tue Jun 13 19:54:18 2006
From: chris at cs.utexas.edu (Chris Edmondson-Yurkanan)
Date: Tue, 13 Jun 2006 21:54:18 -0500
Subject: [e2e] seeking help recalling a network term
In-Reply-To: <448F5808.5080007@isi.edu>
References: <448F431B.8060809@isi.edu> <448F5808.5080007@isi.edu>
Message-ID: <e715d03bb4a90c2eee0bd1707a6e4adf@cs.utexas.edu>

Joe,

I know how much you like history, so here's some fun:

That was Donald Davies concept (who independently invented packet 
switching in the UK in 1965); he used the term isarithmic, the Greek 
term for "equal").

John McQuillan's 1974 dissertation on routing describes it as follows:

"One major thrust of the research at NPL has been a study of so-called 
"isarithmic" networks in which the number of packets and packet 
"containers" is held constant.  This is essentially a flow control 
mechanism designed to prevent congestion.... but such a technique does 
have an impact on the appropriate routing doctrine..."

This concept was first published in 1971:
ACM second symposium on Problems in the optimizations of data 
communications systems.
(at SIGCOMM's 2nd sponsored conference ;-)

Davies wrote in the paper:
The Control of Congestion in Packet Switching Networks
(which has  a 72 version in IEEE Trans. on Communications)

"Since data-carrying packets must be created and destroyed, the balance 
is kept by using empty packets.  Thus when a normal, data-carrying 
packet arrives at its destination it is replaced by an 'empty' which, 
is put back into the system.  When data is ready to enter the network, 
an empty packet must be found and replaced by a data-carrying 
packet..."

Eventually, they switched to permits to avoid the unnecessary traffic 
of empties.  And as routing algorithms improved, isarithmic congestion 
control no longer helped.

Donald Davies Oral History 1986:

"As a means of controlling the number of packets, it occurred to me to 
give them a permit before they could get into the network.  The idea 
was, I think a good one, and in simulation it seemed to work, but it 
had the danger that permits could get lost and so the thing had a nasty 
collapsing process if some part of the network was doing the wrong 
thing... I don't think the idea was ever more than a theoretical one... 
quite interesting to statisticians who liked the idea of this...

that's it,
Chris

On Jun 13, 2006, at 7:27 PM, Joe Touch wrote:

> PS - found it via some indirect means; it's isarithmic ;-)
>
> Joe
>
> Joe Touch wrote:
>> Hi, all,
>>
>> I apologize if this is a simple question:
>>
>> I'm trying to recall the name for a network where the number of
>> packets/tokens/empty-frames inside the net is a constant, i.e., where
>> real data can be put into these units when empty, and emptied at the
>> destination, but that the whole net is otherwise just shuffling around
>> these 'holes'.
>>
>> I'm recalling a term akin to "idempotent" or "isomorphic" - though I
>> know both are wrong ;-) Does anyone recall the term for these nets?
>>
>> (I recall their being vogue in the late 1980's, but not much after 
>> that).
>>
>> Thanks,
>>
>> Joe
>>
>
>
Chris Edmondson-Yurkanan
(chris at cs.utexas.edu)
Contact info:  www.cs.utexas.edu/~chris/


From Jon.Crowcroft at cl.cam.ac.uk  Wed Jun 14 01:06:38 2006
From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft)
Date: Wed, 14 Jun 2006 09:06:38 +0100
Subject: [e2e] seeking help recalling a network term
In-Reply-To: Message from Chris Edmondson-Yurkanan <chris@cs.utexas.edu> 
	of "Tue, 13 Jun 2006 21:54:18 CDT."
	<e715d03bb4a90c2eee0bd1707a6e4adf@cs.utexas.edu> 
Message-ID: <E1FqQOc-0008L7-00@mta1.cl.cam.ac.uk>

In missive <e715d03bb4a90c2eee0bd1707a6e4adf at cs.utexas.edu>, Chris Edmondson-Yu
rkanan typed:

 >>I know how much you like history, so here's some fun:
 
 >>That was Donald Davies concept (who independently invented packet 
 >>switching in the UK in 1965); he used the term isarithmic, the Greek 
 >>term for "equal").

it was part of the french 1st packet switched net hop-bu-hop traffic
management (flow, congestion and crowd control) technology.... its way
cool and the idea has been re-invented lotsa times including in other
areas like road-trains

also bittorrent incentive matching technology is basically the same
concept

the closed loop e2e feedback that TCP uses isnt, but with ECN or
re-feedback, it starts to sound like a (weak) approxiamtion

davies was very very very clever
 >>John McQuillan's 1974 dissertation on routing describes it as follows:
 >>
 >>"One major thrust of the research at NPL has been a study of so-called 
 >>"isarithmic" networks in which the number of packets and packet 
 >>"containers" is held constant.  This is essentially a flow control 
 >>mechanism designed to prevent congestion.... but such a technique does 
 >>have an impact on the appropriate routing doctrine..."
 >>
 >>This concept was first published in 1971:
 >>ACM second symposium on Problems in the optimizations of data 
 >>communications systems.
 >>(at SIGCOMM's 2nd sponsored conference ;-)
 >>
 >>Davies wrote in the paper:
 >>The Control of Congestion in Packet Switching Networks
 >>(which has  a 72 version in IEEE Trans. on Communications)
 >>
 >>"Since data-carrying packets must be created and destroyed, the balance 
 >>is kept by using empty packets.  Thus when a normal, data-carrying 
 >>packet arrives at its destination it is replaced by an 'empty' which, 
 >>is put back into the system.  When data is ready to enter the network, 
 >>an empty packet must be found and replaced by a data-carrying 
 >>packet..."
 >>
 >>Eventually, they switched to permits to avoid the unnecessary traffic 
 >>of empties.  And as routing algorithms improved, isarithmic congestion 
 >>control no longer helped.
 >>
 >>Donald Davies Oral History 1986:
 >>
 >>"As a means of controlling the number of packets, it occurred to me to 
 >>give them a permit before they could get into the network.  The idea 
 >>was, I think a good one, and in simulation it seemed to work, but it 
 >>had the danger that permits could get lost and so the thing had a nasty 
 >>collapsing process if some part of the network was doing the wrong 
 >>thing... I don't think the idea was ever more than a theoretical one... 
 >>quite interesting to statisticians who liked the idea of this...
 >>
 >>that's it,
 >>Chris
 >>
 >>On Jun 13, 2006, at 7:27 PM, Joe Touch wrote:
 >>
 >>> PS - found it via some indirect means; it's isarithmic ;-)
 >>>
 >>> Joe
 >>>
 >>> Joe Touch wrote:
 >>>> Hi, all,
 >>>>
 >>>> I apologize if this is a simple question:
 >>>>
 >>>> I'm trying to recall the name for a network where the number of
 >>>> packets/tokens/empty-frames inside the net is a constant, i.e., where
 >>>> real data can be put into these units when empty, and emptied at the
 >>>> destination, but that the whole net is otherwise just shuffling around
 >>>> these 'holes'.
 >>>>
 >>>> I'm recalling a term akin to "idempotent" or "isomorphic" - though I
 >>>> know both are wrong ;-) Does anyone recall the term for these nets?
 >>>>
 >>>> (I recall their being vogue in the late 1980's, but not much after 
 >>>> that).
 >>>>
 >>>> Thanks,
 >>>>
 >>>> Joe
 >>>>
 >>>
 >>>
 >>Chris Edmondson-Yurkanan
 >>(chris at cs.utexas.edu)
 >>Contact info:  www.cs.utexas.edu/~chris/
 >>

 cheers

   jon


From weigengyu at hotmail.com  Wed Jun 14 20:47:33 2006
From: weigengyu at hotmail.com (weigengyu)
Date: Thu, 15 Jun 2006 11:47:33 +0800
Subject: [e2e] seeking help recalling a network term
References: <E1FqQOc-0008L7-00@mta1.cl.cam.ac.uk>
Message-ID: <BAY110-DAV20FADE5398141D622B002B3820@phx.gbl>


----- Original Message ----- 
From: "Jon Crowcroft" <Jon.Crowcroft at cl.cam.ac.uk>
Subject: Re: [e2e] seeking help recalling a network term


> In missive <e715d03bb4a90c2eee0bd1707a6e4adf at cs.utexas.edu>, Chris Edmondson-Yu
> rkanan typed:
> 
> >>I know how much you like history, so here's some fun:
> 
> >>That was Donald Davies concept (who independently invented packet 
> >>switching in the UK in 1965); he used the term isarithmic, the Greek 
> >>term for "equal").
> 
> it was part of the french 1st packet switched net hop-bu-hop traffic
> management (flow, congestion and crowd control) technology.... its way
> cool and the idea has been re-invented lotsa times including in other
> areas like road-trains
>
> also bittorrent incentive matching technology is basically the same
> concept
> 
>   jon
> 

There is a set of signal lamps every 2km to control railway train go/stop here.

In telecom, SS7 networks are packet switched networks,
The SS7 messages/packets are actually controlled link-by-link  in operations.
The mechanism to prevent congestion is to keep the traffic less than 0.7 Erlang for each link.

Telephone networks works well in general.

Gengyu

From Jon.Crowcroft at cl.cam.ac.uk  Thu Jun 15 04:55:36 2006
From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft)
Date: Thu, 15 Jun 2006 12:55:36 +0100
Subject: [e2e] fast restoration/protection
Message-ID: <E1FqqRl-0000uA-00@mta1.cl.cam.ac.uk>

there's loads and loads of fancy algorithms for computing alternate
routes and building k-resiliency etc etc, but does anyone know if
there's a paper on the obvious - if routers were to log routing
tables, and then one correlated this with faults, one could simply
_load_ the alternate forwarding table directly after a link or node
outage from the previous time there had been an outage at that point -
i.e. simply use the fact that the routing system is a distributed 
algoriithm for path finding, but give it some memory:)

j.

From Jon.Crowcroft at cl.cam.ac.uk  Thu Jun 15 06:28:04 2006
From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft)
Date: Thu, 15 Jun 2006 14:28:04 +0100
Subject: [e2e] fast restoration/protection
In-Reply-To: Message from Jon Crowcroft <Jon.Crowcroft@cl.cam.ac.uk> of "Thu,
	15 Jun 2006 12:55:36 BST." <E1FqqRl-0000uA-00@mta1.cl.cam.ac.uk> 
Message-ID: <E1FqrtE-0002b8-00@mta1.cl.cam.ac.uk>

to clarify - what happens in a link state protocol is that you
distribute states each epoch to all routers who construct a RIB
and do a dijkstra to compute a local FIB - what i am saying is
save the output of the dijkstra for all cases you see, and then 
when you get a link state delta that _matches_ the FIB for a previous
case, load the FIB immediately

for distance or path vector, this is harder as you need to add info
(BGP in practice already has loadsa add ons to achieve some of these
effects in an ad hoc way, but it might be nice to do it in some sort
of principled fashion:-)

In missive <E1FqqRl-0000uA-00 at mta1.cl.cam.ac.uk>, Jon Crowcroft typed:

 >>there's loads and loads of fancy algorithms for computing alternate
 >>routes and building k-resiliency etc etc, but does anyone know if
 >>there's a paper on the obvious - if routers were to log routing
 >>tables, and then one correlated this with faults, one could simply
 >>_load_ the alternate forwarding table directly after a link or node
 >>outage from the previous time there had been an outage at that point -
 >>i.e. simply use the fact that the routing system is a distributed 
 >>algoriithm for path finding, but give it some memory:)
 >>
 >>j.

 cheers

   jon


From amundk at simula.no  Thu Jun 15 07:19:16 2006
From: amundk at simula.no (Amund Kvalbein)
Date: Thu, 15 Jun 2006 16:19:16 +0200 (CEST)
Subject: [e2e] fast restoration/protection
In-Reply-To: <E1FqrtE-0002b8-00@mta1.cl.cam.ac.uk>
References: <E1FqrtE-0002b8-00@mta1.cl.cam.ac.uk>
Message-ID: <Pine.LNX.4.63.0606151604370.22620@kuusi.ifi.uio.no>

Jon,

If I understand your idea correctly, what you would gain with respect to 
restoration time is to eliminate the time it takes to compute a new FIB 
after a link state change. That is fine, but running dijkstra constitutes 
only a small part of the total convergence time (what dominates is the 
time it takes to load the new FIB to the line cards, see paper by Francois 
et al. in CCR July 2005).

Also, you would still have the problem of transient loops if the routers 
do not switch to the new FIB synchronously. Allowing the detecting router 
to locally switch to an alternate path while avoiding forwarding loops is 
an important goal for fast restoration schemes.

Regards,
Amund



On Thu, 15 Jun 2006, Jon Crowcroft wrote:

> to clarify - what happens in a link state protocol is that you
> distribute states each epoch to all routers who construct a RIB
> and do a dijkstra to compute a local FIB - what i am saying is
> save the output of the dijkstra for all cases you see, and then
> when you get a link state delta that _matches_ the FIB for a previous
> case, load the FIB immediately
>
> for distance or path vector, this is harder as you need to add info
> (BGP in practice already has loadsa add ons to achieve some of these
> effects in an ad hoc way, but it might be nice to do it in some sort
> of principled fashion:-)
>
> In missive <E1FqqRl-0000uA-00 at mta1.cl.cam.ac.uk>, Jon Crowcroft typed:
>
> >>there's loads and loads of fancy algorithms for computing alternate
> >>routes and building k-resiliency etc etc, but does anyone know if
> >>there's a paper on the obvious - if routers were to log routing
> >>tables, and then one correlated this with faults, one could simply
> >>_load_ the alternate forwarding table directly after a link or node
> >>outage from the previous time there had been an outage at that point -
> >>i.e. simply use the fact that the routing system is a distributed
> >>algoriithm for path finding, but give it some memory:)
> >>
> >>j.
>
> cheers
>
>   jon
>
>

From Jon.Crowcroft at cl.cam.ac.uk  Thu Jun 15 07:42:51 2006
From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft)
Date: Thu, 15 Jun 2006 15:42:51 +0100
Subject: [e2e] fast restoration/protection
In-Reply-To: Message from Amund Kvalbein <amundk@simula.no> of "Thu,
	15 Jun 2006 16:19:16 +0200."
	<Pine.LNX.4.63.0606151604370.22620@kuusi.ifi.uio.no> 
Message-ID: <E1Fqt3b-0003xj-00@mta1.cl.cam.ac.uk>

so while this is correct, i think, initially, i conjecture that once one
had a bit of experience with this, one could start 
i) to look at
triggering the selection of alternate FIBs on local detection of
outage only
and
ii) examining the cascade of convergence as the knowledge of the
chance percolated
iii) trigger LSAs only (no periodic update) so that the selection is
made in < 1 rtt remotely too...

In missive <Pine.LNX.4.63.0606151604370.22620 at kuusi.ifi.uio.no>, Amund Kvalbein
 typed:

 >>If I understand your idea correctly, what you would gain with respect to 
 >>restoration time is to eliminate the time it takes to compute a new FIB 
 >>after a link state change. That is fine, but running dijkstra constitutes 
 >>only a small part of the total convergence time (what dominates is the 
 >>time it takes to load the new FIB to the line cards, see paper by Francois 
 >>et al. in CCR July 2005).
 
 >>Also, you would still have the problem of transient loops if the routers 
 >>do not switch to the new FIB synchronously. Allowing the detecting router 
 >>to locally switch to an alternate path while avoiding forwarding loops is 
 >>an important goal for fast restoration schemes.
 >>
 >>Regards,
 >>Amund
 >>
 >>
 >>
 >>On Thu, 15 Jun 2006, Jon Crowcroft wrote:
 >>
 >>> to clarify - what happens in a link state protocol is that you
 >>> distribute states each epoch to all routers who construct a RIB
 >>> and do a dijkstra to compute a local FIB - what i am saying is
 >>> save the output of the dijkstra for all cases you see, and then
 >>> when you get a link state delta that _matches_ the FIB for a previous
 >>> case, load the FIB immediately
 >>>
 >>> for distance or path vector, this is harder as you need to add info
 >>> (BGP in practice already has loadsa add ons to achieve some of these
 >>> effects in an ad hoc way, but it might be nice to do it in some sort
 >>> of principled fashion:-)
 >>>
 >>> In missive <E1FqqRl-0000uA-00 at mta1.cl.cam.ac.uk>, Jon Crowcroft typed:
 >>>
 >>> >>there's loads and loads of fancy algorithms for computing alternate
 >>> >>routes and building k-resiliency etc etc, but does anyone know if
 >>> >>there's a paper on the obvious - if routers were to log routing
 >>> >>tables, and then one correlated this with faults, one could simply
 >>> >>_load_ the alternate forwarding table directly after a link or node
 >>> >>outage from the previous time there had been an outage at that point -
 >>> >>i.e. simply use the fact that the routing system is a distributed
 >>> >>algoriithm for path finding, but give it some memory:)
 >>> >>
 >>> >>j.
 >>>
 >>> cheers
 >>>
 >>>   jon
 >>>
 >>>

 cheers

   jon


From Jon.Crowcroft at cl.cam.ac.uk  Thu Jun 15 08:10:35 2006
From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft)
Date: Thu, 15 Jun 2006 16:10:35 +0100
Subject: [e2e] fast restoration/protection
In-Reply-To: Message from "Narasimha Reddy" <reddy@ece.tamu.edu> of "Thu,
	15 Jun 2006 09:32:36 CDT." <001a01c69088$8f7f1460$23d25ba5@tamu.edu> 
Message-ID: <E1FqtUS-0004X4-00@mta1.cl.cam.ac.uk>

In missive <001a01c69088$8f7f1460$23d25ba5 at tamu.edu>, "Narasimha Reddy" typed:

 >>Jon, the following paper addresses the problem of fast rerouting:

 >>Y. Liu and ALN Reddy, "A fast rerouting scheme for OSPF/IS-IS Networks".
 >>http://www.ece.tamu.edu/~reddy/papers/yong_icccn04.pdf

yes, i've read that

 >>It is not enough for the local router by itself to choose a FIB computed
 >>earlier on the same link failure. This will likely lead to routing loops
 >>since the other nodes are using FIBs that assume the availability of the
 >>failed link.
 
sure - but i wasn't proposing this - its a bit more subtle - the point
is that you haev a set of link/node failure probabilities, and you
have a set of routing configurations  and you 
i) pick configs which match failures but ALSO
ii) pick configs that don't lead to loops if picked differently

so the system of routers
moves through a phasespace/ensemble of configs that gradually converge on 
a consistent new view as they learn of the link state change, but
without doing new computations since all the computations were done
once and once only for all the likely combinations of cases
(and before people tell me that that is a huge search space, i know,
but it is the _actual_ cases that matter that one records, not all
possible cases)

think of it like a distributed, incremental pattern matching scheme:)

 >>
 >>-----Original Message-----
 >>From: end2end-interest-bounces at postel.org
 >>[mailto:end2end-interest-bounces at postel.org] On Behalf Of Jon Crowcroft
 >>Sent: Thursday, June 15, 2006 7:28 AM
 >>Cc: Jon.Crowcroft at cl.cam.ac.uk; end2end-interest at postel.org
 >>Subject: Re: [e2e] fast restoration/protection
 >>
 >>to clarify - what happens in a link state protocol is that you
 >>distribute states each epoch to all routers who construct a RIB
 >>and do a dijkstra to compute a local FIB - what i am saying is
 >>save the output of the dijkstra for all cases you see, and then=20
 >>when you get a link state delta that _matches_ the FIB for a previous
 >>case, load the FIB immediately
 >>
 >>for distance or path vector, this is harder as you need to add info
 >>(BGP in practice already has loadsa add ons to achieve some of these
 >>effects in an ad hoc way, but it might be nice to do it in some sort
 >>of principled fashion:-)
 >>
 >>In missive <E1FqqRl-0000uA-00 at mta1.cl.cam.ac.uk>, Jon Crowcroft typed:
 >>
 >> >>there's loads and loads of fancy algorithms for computing alternate
 >> >>routes and building k-resiliency etc etc, but does anyone know if
 >> >>there's a paper on the obvious - if routers were to log routing
 >> >>tables, and then one correlated this with faults, one could simply
 >> >>_load_ the alternate forwarding table directly after a link or node
 >> >>outage from the previous time there had been an outage at that point
 >>-
 >> >>i.e. simply use the fact that the routing system is a distributed=20
 >> >>algoriithm for path finding, but give it some memory:)
 >> >>
 >> >>j.
 >>
 >> cheers
 >>
 >>   jon
 >>
 >>

 cheers

   jon


From Bonaventure at info.ucl.ac.be  Thu Jun 15 08:11:58 2006
From: Bonaventure at info.ucl.ac.be (Olivier Bonaventure)
Date: Thu, 15 Jun 2006 17:11:58 +0200
Subject: [e2e] fast restoration/protection
In-Reply-To: <E1FqrtE-0002b8-00@mta1.cl.cam.ac.uk>
References: <E1FqrtE-0002b8-00@mta1.cl.cam.ac.uk>
Message-ID: <449178BE.2020403@info.ucl.ac.be>

Jon,

> to clarify - what happens in a link state protocol is that you
> distribute states each epoch to all routers who construct a RIB
> and do a dijkstra to compute a local FIB - what i am saying is
> save the output of the dijkstra for all cases you see, and then 
> when you get a link state delta that _matches_ the FIB for a previous
> case, load the FIB immediately

Yes, but this approach of precomputing FIBs has a few drawbacks :
- you may need to compute a lot of different FIB to cover all possible
failures in the network
- updating a FIB is not necessary fast on current routers. For example,
on a Cisco 12k, updating a FIB requries about 110 microsecond per prefix
http://citeseer.ist.psu.edu/francois05achieving.html

If instead of updating completely the FIB you agree to use a tunnel to
reroute the packets around a local failure, then it is possible to
achieve fast  (i.e. sub 50 msec) restoration even for BGP peering links
but using a clever organisation of the FIB, see :

http://citeseer.ist.psu.edu/bonaventure05achieving.html

The IETF is also doing some (slow) work on those fast restoration issues
in the rtgwg working group.


Best regards,


Olivier

-- 
CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/



From faber at ISI.EDU  Thu Jun 15 08:30:35 2006
From: faber at ISI.EDU (Ted Faber)
Date: Thu, 15 Jun 2006 08:30:35 -0700
Subject: [e2e] seeking help recalling a network term
In-Reply-To: <BAY110-DAV20FADE5398141D622B002B3820@phx.gbl>
References: <E1FqQOc-0008L7-00@mta1.cl.cam.ac.uk>
	<BAY110-DAV20FADE5398141D622B002B3820@phx.gbl>
Message-ID: <20060615153035.GC80800@hut.isi.edu>

On Thu, Jun 15, 2006 at 11:47:33AM +0800, weigengyu wrote:
> There is a set of signal lamps every 2km to control railway train go/stop here.
> 
> In telecom, SS7 networks are packet switched networks,
> The SS7 messages/packets are actually controlled link-by-link  in operations.
> The mechanism to prevent congestion is to keep the traffic less than 0.7 Erlang for each link.
> 
> Telephone networks works well in general.

Yeah, for circuit-switched fixed-capacity voice calls. :-)

There's more than one way to do most things, congestion control
included, and the problem you want to solve should guide your approach.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20060615/399ca4fd/attachment.bin

From craig at aland.bbn.com  Thu Jun 15 09:21:10 2006
From: craig at aland.bbn.com (Craig Partridge)
Date: Thu, 15 Jun 2006 12:21:10 -0400
Subject: [e2e] fast restoration/protection
In-Reply-To: Your message of "Thu, 15 Jun 2006 17:11:58 +0200."
	<449178BE.2020403@info.ucl.ac.be> 
Message-ID: <20060615162110.8BC5E67@aland.bbn.com>


In message <449178BE.2020403 at info.ucl.ac.be>, Olivier Bonaventure writes:

>Yes, but this approach of precomputing FIBs has a few drawbacks :
>- you may need to compute a lot of different FIB to cover all possible
>failures in the network
>- updating a FIB is not necessary fast on current routers. For example,
>on a Cisco 12k, updating a FIB requries about 110 microsecond per prefix
>http://citeseer.ist.psu.edu/francois05achieving.html

Sounds like two good research problems.

In fact, one solution to the second problem is known -- have two FIB
memories -- one active, one backup -- and make it possible to switch.
We showed how to do that about ten years ago in the MultiGigabit Router
project (the major nuisance was invalidating the NP caches).

As for the first -- do we know or have we thought of ways to determine
which FIBs it would be useful to have?  I.e., don't solve all possible
failures -- pick the best subset of FIBS given a limit on the number of
FIBS (say 5) and current statistics on link outages.  There's also a clear
metric for goodness -- namely, take the list of outages, weighted by
their likelihood, and see what fraction of [weighted] outages are covered
by the set of alternate FIBS.  Obviously a metric of 1.0 is desired, but
I'll bet any metric over, say, 0.6 has an impact.

Craig

From craig at aland.bbn.com  Thu Jun 15 12:45:59 2006
From: craig at aland.bbn.com (Craig Partridge)
Date: Thu, 15 Jun 2006 15:45:59 -0400
Subject: [e2e] fast restoration/protection
In-Reply-To: Your message of "Thu, 15 Jun 2006 21:24:39 +0200."
	<4491B3F7.3070805@uclouvain.be> 
Message-ID: <20060615194559.61BB767@aland.bbn.com>


Hi Oliver:

I think you misunderstand the tenor of my note.

Regarding FIBS, my proposal was to compute multiple FIBs (not preserve
old ones) as routing updates came in, based on a history of the kinds
of outages that had occurred (e.g. which links seemed to fail most
often).  Then test (using outage information) how well the computed
backup FIBs would have done.  Pure research question of whether keeping
a limited set of FIBs around as backups (in the optimal case -- not
storing old ones but computing new ones) would work.

As for multiple FIBs in a line card.  Yes, it means more memory and,
in some cases it is perfectly feasible (been there, done that, as have
others).  But my broader point is that we should not treat the FIB
per-entry update time in a Cisco 12K as indicative of the kind of
solutions we should pick.  Rather, I'd argue, we should find our
solutions and then see what those solutions require of the hardware
(and whether that's feasible...).  Cisco FIBs exist the way they do
because of certain (well considered) expectations on the part of
Cisco engineers -- but we're playing here with changing expectations.

Thanks!

Craig

In message <4491B3F7.3070805 at uclouvain.be>, Olivier Bonaventure writes:

>Craig,
>> 
>>>Yes, but this approach of precomputing FIBs has a few drawbacks :
>>>- you may need to compute a lot of different FIB to cover all possible
>>>failures in the network
>>>- updating a FIB is not necessary fast on current routers. For example,
>>>on a Cisco 12k, updating a FIB requries about 110 microsecond per prefix
>>>http://citeseer.ist.psu.edu/francois05achieving.html
>> 
>> 
>> Sounds like two good research problems.
>> 
>> In fact, one solution to the second problem is known -- have two FIB
>> memories -- one active, one backup -- and make it possible to switch.
>> We showed how to do that about ten years ago in the MultiGigabit Router
>> project (the major nuisance was invalidating the NP caches).
>
>The cost is to have two FIBs instead of one one each linecard.
>
>> As for the first -- do we know or have we thought of ways to determine
>> which FIBs it would be useful to have?  I.e., don't solve all possible
>> failures -- pick the best subset of FIBS given a limit on the number of
>> FIBS (say 5) and current statistics on link outages.  There's also a clear
>> metric for goodness -- namely, take the list of outages, weighted by
>> their likelihood, and see what fraction of [weighted] outages are covered
>> by the set of alternate FIBS.  Obviously a metric of 1.0 is desired, but
>> I'll bet any metric over, say, 0.6 has an impact.
>
>It could be possible to maintain a cache of the last N FIBs that have
>been used, but this kind of approach may be difficult in practice for
>two reasons :
>- studies of ospf traces
>http://citeseer.ist.psu.edu/watson03experiences.html
>have shown that a router does not frequently reuse exactly the same
>shortest path tree many times
>- the link state database must be maintained together with the old FIB
>and when a new link state packet is received with a change, then you
>need to check whether the topology of the old FIB is exactly equal to
>the current one
>
>
>Olivier

From weigengyu at hotmail.com  Thu Jun 15 20:10:38 2006
From: weigengyu at hotmail.com (weigengyu)
Date: Fri, 16 Jun 2006 11:10:38 +0800
Subject: [e2e] seeking help recalling a network term
References: <E1FqQOc-0008L7-00@mta1.cl.cam.ac.uk><BAY110-DAV20FADE5398141D622B002B3820@phx.gbl>
	<20060615153035.GC80800@hut.isi.edu>
Message-ID: <BAY110-DAV91C29E71AFC3FC32A8011B3830@phx.gbl>


Hi, 
to make things clear:

1. The telephone networks including fixed or mobile ones are circuit-switching.
2. There is only SS7 used for control message transmission, SS7 networks is a packet switched networks.
3. Some future services like IMS need connection setup stage before communication. 
That will be on an IP based packet switching network.
4. The quality of services requires limited delay of setup connection.  There is no guarantte by TCP or SCTP. 
You have to wait long time when you start to establish a connection in current Internet. 

Gengyu

----- Original Message ----- 
From: "Ted Faber" <faber at ISI.EDU>
To: "weigengyu" <weigengyu at hotmail.com>
Cc: "Jon Crowcroft" <Jon.Crowcroft at cl.cam.ac.uk>; <end2end-interest at postel.org>
Sent: Thursday, June 15, 2006 11:30 PM
Subject: Re: [e2e] seeking help recalling a network term

On Thu, Jun 15, 2006 at 11:47:33AM +0800, weigengyu wrote:
> There is a set of signal lamps every 2km to control railway train go/stop here.
> 
> In telecom, SS7 networks are packet switched networks,
> The SS7 messages/packets are actually controlled link-by-link  in operations.
> The mechanism to prevent congestion is to keep the traffic less than 0.7 Erlang for each link.
> 
> Telephone networks works well in general.

Yeah, for circuit-switched fixed-capacity voice calls. :-)

There's more than one way to do most things, congestion control
included, and the problem you want to solve should guide your approach.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG

From amundk at simula.no  Fri Jun 16 00:09:28 2006
From: amundk at simula.no (Amund Kvalbein)
Date: Fri, 16 Jun 2006 09:09:28 +0200 (CEST)
Subject: [e2e] fast restoration/protection
In-Reply-To: <20060615162110.8BC5E67@aland.bbn.com>
References: <20060615162110.8BC5E67@aland.bbn.com>
Message-ID: <Pine.LNX.4.63.0606160859590.27623@seitseman.ifi.uio.no>

Craig,

>
> As for the first -- do we know or have we thought of ways to determine
> which FIBs it would be useful to have?  I.e., don't solve all possible
> failures -- pick the best subset of FIBS given a limit on the number of
> FIBS (say 5) and current statistics on link outages.  There's also a clear
> metric for goodness -- namely, take the list of outages, weighted by
> their likelihood, and see what fraction of [weighted] outages are covered
> by the set of alternate FIBS.  Obviously a metric of 1.0 is desired, but
> I'll bet any metric over, say, 0.6 has an impact.
>

We have done some work on this. It turns out that you can actually 
construct a very limited number of topologies/FIBs that cover all possible 
failures. We typically need five or less for existing networks.  This is 
done by carefully selecting a subset of routers that are not used to 
forward packets in each topology.

See http://www.simula.no/departments/networks/.artifacts/infocom06 for 
details.

Regards,
Amund

From Jon.Crowcroft at cl.cam.ac.uk  Fri Jun 16 01:29:30 2006
From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft)
Date: Fri, 16 Jun 2006 09:29:30 +0100
Subject: [e2e] fast restoration/protection
In-Reply-To: Message from Olivier Bonaventure
	<Olivier.Bonaventure@uclouvain.be> 
	of "Thu, 15 Jun 2006 21:24:39 +0200." <4491B3F7.3070805@uclouvain.be> 
Message-ID: <E1Fr9hq-0002jJ-00@mta1.cl.cam.ac.uk>

what is interesting about that study is that it shows that the net
_evolves_ almost more than it just changes - this means that a lot of
_pre-computed_ protection schemes aren't going to work too well...assuming the
study of the michnet is typical of other nets

In missive <4491B3F7.3070805 at uclouvain.be>, Olivier Bonaventure typed:

 >>Craig,
 >>> 
 >>>>Yes, but this approach of precomputing FIBs has a few drawbacks :
 >>>>- you may need to compute a lot of different FIB to cover all possible
 >>>>failures in the network
 >>>>- updating a FIB is not necessary fast on current routers. For example,
 >>>>on a Cisco 12k, updating a FIB requries about 110 microsecond per prefix
 >>>>http://citeseer.ist.psu.edu/francois05achieving.html
 >>> 
 >>> 
 >>> Sounds like two good research problems.
 >>> 
 >>> In fact, one solution to the second problem is known -- have two FIB
 >>> memories -- one active, one backup -- and make it possible to switch.
 >>> We showed how to do that about ten years ago in the MultiGigabit Router
 >>> project (the major nuisance was invalidating the NP caches).
 >>
 >>The cost is to have two FIBs instead of one one each linecard.
 >>
 >>> As for the first -- do we know or have we thought of ways to determine
 >>> which FIBs it would be useful to have?  I.e., don't solve all possible
 >>> failures -- pick the best subset of FIBS given a limit on the number of
 >>> FIBS (say 5) and current statistics on link outages.  There's also a clear
 >>> metric for goodness -- namely, take the list of outages, weighted by
 >>> their likelihood, and see what fraction of [weighted] outages are covered
 >>> by the set of alternate FIBS.  Obviously a metric of 1.0 is desired, but
 >>> I'll bet any metric over, say, 0.6 has an impact.
 >>
 >>It could be possible to maintain a cache of the last N FIBs that have
 >>been used, but this kind of approach may be difficult in practice for
 >>two reasons :
 >>- studies of ospf traces
 >>http://citeseer.ist.psu.edu/watson03experiences.html
 >>have shown that a router does not frequently reuse exactly the same
 >>shortest path tree many times
 >>- the link state database must be maintained together with the old FIB
 >>and when a new link state packet is received with a change, then you
 >>need to check whether the topology of the old FIB is exactly equal to
 >>the current one
 >>
 >>
 >>Olivier

 cheers

   jon


From akatlas at gmail.com  Thu Jun 15 13:25:49 2006
From: akatlas at gmail.com (Alia Atlas)
Date: Thu, 15 Jun 2006 13:25:49 -0700
Subject: [e2e] fast restoration/protection
In-Reply-To: <20060615194559.61BB767@aland.bbn.com>
References: <4491B3F7.3070805@uclouvain.be>
	<20060615194559.61BB767@aland.bbn.com>
Message-ID: <6280db520606151325n5a90d7d3v3bf11d624da5b1b5@mail.gmail.com>

On 6/15/06, Craig Partridge <craig at aland.bbn.com> wrote:
>
> Hi Oliver:
>
> I think you misunderstand the tenor of my note.
>
> Regarding FIBS, my proposal was to compute multiple FIBs (not preserve
> old ones) as routing updates came in, based on a history of the kinds
> of outages that had occurred (e.g. which links seemed to fail most
> often).  Then test (using outage information) how well the computed
> backup FIBs would have done.  Pure research question of whether keeping
> a limited set of FIBs around as backups (in the optimal case -- not
> storing old ones but computing new ones) would work.

There was a research paper out of Germany that discussed how many
different topologies needed to be computed & concluded that the number
was substantially smaller than one might expect.  Olivier may recall
the reference; I don't have it to hand.  One of the issues was
identifying which FIB to use for a particular packet.

Alia

From touch at ISI.EDU  Mon Jun 19 13:00:43 2006
From: touch at ISI.EDU (Joe Touch)
Date: Mon, 19 Jun 2006 13:00:43 -0700
Subject: [e2e] new "Journal of Internet Engineering"
Message-ID: <4497026B.1000509@isi.edu>

(posted on behalf of Vassilis)

--------------------------------------

Dear colleagues,

Please check
	www.jie-online.org
which announces the new "Journal of Internet Engineering". The journal
has started accepting submissions and the first issue is expected in
September 2006.

Regards,
Vassilis Tsaoussidis

From lynne at telemuse.net  Mon Jun 19 14:07:12 2006
From: lynne at telemuse.net (Lynne Jolitz)
Date: Mon, 19 Jun 2006 14:07:12 -0700
Subject: [e2e] new "Journal of Internet Engineering"
In-Reply-To: <4497026B.1000509@isi.edu>
Message-ID: <004201c693e4$557e3980$6e8944c6@telemuse.net>

Perhaps they should start by replacing "localhost" with the correct url designations on their website. :-)

"<p>Interested in submitting to this journal? We recommend that you review the <a href="http://localhost/ojs/index.php/jie/about">About the Journal</a> page for the journal's section policies, as well as the <a href="http://localhost/ojs/index.php/jie/about/submissions#authorGuidelines">Author Guidelines</a>. Authors need to <a href="http://localhost/ojs/index.php/jie/user/register">register</a> with the journal prior to submitting, or if already registered can simply <a href="http://localhost/ojs/index.php/index/login">log in</a> and begin the 5 step process.</p>"

Lynne.

----
We use SpamQuiz.
If your ISP didn't make the grade try http://lynne.telemuse.net


> -----Original Message-----
> From: end2end-interest-bounces at postel.org
> [mailto:end2end-interest-bounces at postel.org]On Behalf Of Joe Touch
> Sent: Monday, June 19, 2006 1:01 PM
> To: end2end-interest at postel.org
> Subject: [e2e] new "Journal of Internet Engineering"
> 
> 
> (posted on behalf of Vassilis)
> 
> --------------------------------------
> 
> Dear colleagues,
> 
> Please check
> 	www.jie-online.org
> which announces the new "Journal of Internet Engineering". The journal
> has started accepting submissions and the first issue is expected in
> September 2006.
> 
> Regards,
> Vassilis Tsaoussidis
> 

From day at std.com  Mon Jun 19 14:10:38 2006
From: day at std.com (John Day)
Date: Mon, 19 Jun 2006 17:10:38 -0400
Subject: [e2e] fast restoration/protection
In-Reply-To: <E1Fr9hq-0002jJ-00@mta1.cl.cam.ac.uk>
References: <E1Fr9hq-0002jJ-00@mta1.cl.cam.ac.uk>
Message-ID: <a06230922c0bcc1981fba@[10.0.1.3]>

Rather than try to compute all of the possible alternate FIBs that 
could occur (most won't happen) and  on the assumption, that networks 
tend to fail in the same places, ;-) as Jon first suggested why not 
just keep the a running history of the last several FIBs, assume 
after some amount of time or lack of use (a FIB replacement algorithm 
;-)) they are discarded, when a failure/change occurs if no existing 
FIB meets the evaluation criteria (not a close fit), then compute a 
new one, and add it to your cache, etc.

Of course the hard part is coming up with the evaluation criteria to 
determine whether the current situation matches previous ones. But as 
Jon suggests there are probably some pretty nice pattern matching 
schemes for this.

Take care,
John



At 9:29 +0100 2006/06/16, Jon Crowcroft wrote:
>what is interesting about that study is that it shows that the net
>_evolves_ almost more than it just changes - this means that a lot of
>_pre-computed_ protection schemes aren't going to work too well...assuming the
>study of the michnet is typical of other nets
>
>In missive <4491B3F7.3070805 at uclouvain.be>, Olivier Bonaventure typed:
>
>  >>Craig,
>  >>>
>  >>>>Yes, but this approach of precomputing FIBs has a few drawbacks :
>  >>>>- you may need to compute a lot of different FIB to cover all possible
>  >>>>failures in the network
>  >>>>- updating a FIB is not necessary fast on current routers. For example,
>  >>>>on a Cisco 12k, updating a FIB requries about 110 microsecond per prefix
>  >>>>http://citeseer.ist.psu.edu/francois05achieving.html
>  >>>
>  >>>
>  >>> Sounds like two good research problems.
>  >>>
>  >>> In fact, one solution to the second problem is known -- have two FIB
>  >>> memories -- one active, one backup -- and make it possible to switch.
>  >>> We showed how to do that about ten years ago in the MultiGigabit Router
>  >>> project (the major nuisance was invalidating the NP caches).
>  >>
>  >>The cost is to have two FIBs instead of one one each linecard.
>  >>
>  >>> As for the first -- do we know or have we thought of ways to determine
>  >>> which FIBs it would be useful to have?  I.e., don't solve all possible
>  >>> failures -- pick the best subset of FIBS given a limit on the number of
>  >>> FIBS (say 5) and current statistics on link outages.  There's 
>also a clear
>  >>> metric for goodness -- namely, take the list of outages, weighted by
>  >>> their likelihood, and see what fraction of [weighted] outages are covered
>  >>> by the set of alternate FIBS.  Obviously a metric of 1.0 is desired, but
>  >>> I'll bet any metric over, say, 0.6 has an impact.
>  >>
>  >>It could be possible to maintain a cache of the last N FIBs that have
>  >>been used, but this kind of approach may be difficult in practice for
>  >>two reasons :
>  >>- studies of ospf traces
>  >>http://citeseer.ist.psu.edu/watson03experiences.html
>  >>have shown that a router does not frequently reuse exactly the same
>  >>shortest path tree many times
>  >>- the link state database must be maintained together with the old FIB
>  >>and when a new link state packet is received with a change, then you
>  >>need to check whether the topology of the old FIB is exactly equal to
>  >>the current one
>  >>
>  >>
>  >>Olivier
>
>  cheers
>
>    jon


From touch at ISI.EDU  Mon Jun 19 14:46:58 2006
From: touch at ISI.EDU (Joe Touch)
Date: Mon, 19 Jun 2006 14:46:58 -0700
Subject: [e2e] new "Journal of Internet Engineering"
In-Reply-To: <004201c693e4$557e3980$6e8944c6@telemuse.net>
References: <004201c693e4$557e3980$6e8944c6@telemuse.net>
Message-ID: <44971B52.3060304@isi.edu>

It seems the offending pages are all linked on the page of the following
URLs, FWIW:

http://www.jie-online.org/ojs/index.php/jie/information/authors
http://www.jie-online.org/ojs/index.php/jie/information/readers

(links on the lower right of the main page); other links appear to work
(e.g., at the top of the page), and appear to be able to access the same
information.

Joe

Lynne Jolitz wrote:
> Perhaps they should start by replacing "localhost" with the correct url designations on their website. :-)
> 
> "<p>Interested in submitting to this journal? We recommend that you review the <a href="http://localhost/ojs/index.php/jie/about">About the Journal</a> page for the journal's section policies, as well as the <a href="http://localhost/ojs/index.php/jie/about/submissions#authorGuidelines">Author Guidelines</a>. Authors need to <a href="http://localhost/ojs/index.php/jie/user/register">register</a> with the journal prior to submitting, or if already registered can simply <a href="http://localhost/ojs/index.php/index/login">log in</a> and begin the 5 step process.</p>"
> 
> Lynne.
> 
> ----
> We use SpamQuiz.
> If your ISP didn't make the grade try http://lynne.telemuse.net
> 
> 
>> -----Original Message-----
>> From: end2end-interest-bounces at postel.org
>> [mailto:end2end-interest-bounces at postel.org]On Behalf Of Joe Touch
>> Sent: Monday, June 19, 2006 1:01 PM
>> To: end2end-interest at postel.org
>> Subject: [e2e] new "Journal of Internet Engineering"
>>
>>
>> (posted on behalf of Vassilis)
>>
>> --------------------------------------
>>
>> Dear colleagues,
>>
>> Please check
>> 	www.jie-online.org
>> which announces the new "Journal of Internet Engineering". The journal
>> has started accepting submissions and the first issue is expected in
>> September 2006.
>>
>> Regards,
>> Vassilis Tsaoussidis
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20060619/d57ca774/signature.bin

From puddinghead_wilson007 at yahoo.co.uk  Tue Jun 20 01:23:14 2006
From: puddinghead_wilson007 at yahoo.co.uk (Puddinhead Wilson)
Date: Tue, 20 Jun 2006 09:23:14 +0100 (BST)
Subject: [e2e] fast restoration/protection
In-Reply-To: <a06230922c0bcc1981fba@[10.0.1.3]>
Message-ID: <20060620082314.97170.qmail@web25402.mail.ukl.yahoo.com>

why not simply install all possible equal cost paths
as suggested in an IETF draft in the IDR WG by Manav
Bhatia and remove only those which are not needed/have
failed.




--- John Day <day at std.com> wrote:

> Rather than try to compute all of the possible
> alternate FIBs that 
> could occur (most won't happen) and  on the
> assumption, that networks 
> tend to fail in the same places, ;-) as Jon first
> suggested why not 
> just keep the a running history of the last several
> FIBs, assume 
> after some amount of time or lack of use (a FIB
> replacement algorithm 
> ;-)) they are discarded, when a failure/change
> occurs if no existing 
> FIB meets the evaluation criteria (not a close fit),
> then compute a 
> new one, and add it to your cache, etc.
> 
> Of course the hard part is coming up with the
> evaluation criteria to 
> determine whether the current situation matches
> previous ones. But as 
> Jon suggests there are probably some pretty nice
> pattern matching 
> schemes for this.
> 
> Take care,
> John
> 
> 
> 
> At 9:29 +0100 2006/06/16, Jon Crowcroft wrote:
> >what is interesting about that study is that it
> shows that the net
> >_evolves_ almost more than it just changes - this
> means that a lot of
> >_pre-computed_ protection schemes aren't going to
> work too well...assuming the
> >study of the michnet is typical of other nets
> >
> >In missive <4491B3F7.3070805 at uclouvain.be>, Olivier
> Bonaventure typed:
> >
> >  >>Craig,
> >  >>>
> >  >>>>Yes, but this approach of precomputing FIBs
> has a few drawbacks :
> >  >>>>- you may need to compute a lot of different
> FIB to cover all possible
> >  >>>>failures in the network
> >  >>>>- updating a FIB is not necessary fast on
> current routers. For example,
> >  >>>>on a Cisco 12k, updating a FIB requries about
> 110 microsecond per prefix
> > 
>
>>>>http://citeseer.ist.psu.edu/francois05achieving.html
> >  >>>
> >  >>>
> >  >>> Sounds like two good research problems.
> >  >>>
> >  >>> In fact, one solution to the second problem
> is known -- have two FIB
> >  >>> memories -- one active, one backup -- and
> make it possible to switch.
> >  >>> We showed how to do that about ten years ago
> in the MultiGigabit Router
> >  >>> project (the major nuisance was invalidating
> the NP caches).
> >  >>
> >  >>The cost is to have two FIBs instead of one one
> each linecard.
> >  >>
> >  >>> As for the first -- do we know or have we
> thought of ways to determine
> >  >>> which FIBs it would be useful to have?  I.e.,
> don't solve all possible
> >  >>> failures -- pick the best subset of FIBS
> given a limit on the number of
> >  >>> FIBS (say 5) and current statistics on link
> outages.  There's 
> >also a clear
> >  >>> metric for goodness -- namely, take the list
> of outages, weighted by
> >  >>> their likelihood, and see what fraction of
> [weighted] outages are covered
> >  >>> by the set of alternate FIBS.  Obviously a
> metric of 1.0 is desired, but
> >  >>> I'll bet any metric over, say, 0.6 has an
> impact.
> >  >>
> >  >>It could be possible to maintain a cache of the
> last N FIBs that have
> >  >>been used, but this kind of approach may be
> difficult in practice for
> >  >>two reasons :
> >  >>- studies of ospf traces
> > 
>
>>http://citeseer.ist.psu.edu/watson03experiences.html
> >  >>have shown that a router does not frequently
> reuse exactly the same
> >  >>shortest path tree many times
> >  >>- the link state database must be maintained
> together with the old FIB
> >  >>and when a new link state packet is received
> with a change, then you
> >  >>need to check whether the topology of the old
> FIB is exactly equal to
> >  >>the current one
> >  >>
> >  >>
> >  >>Olivier
> >
> >  cheers
> >
> >    jon
> 
> 



	
	
		
___________________________________________________________ 
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine 
http://uk.docs.yahoo.com/nowyoucan.html

From Jon.Crowcroft at cl.cam.ac.uk  Tue Jun 20 01:33:40 2006
From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft)
Date: Tue, 20 Jun 2006 09:33:40 +0100
Subject: [e2e] fast restoration/protection
In-Reply-To: Message from Puddinhead Wilson
	<puddinghead_wilson007@yahoo.co.uk> of "Tue,
	20 Jun 2006 09:23:14 BST."
	<20060620082314.97170.qmail@web25402.mail.ukl.yahoo.com> 
Message-ID: <E1Fsbg5-0007hi-00@mta1.cl.cam.ac.uk>

In missive <20060620082314.97170.qmail at web25402.mail.ukl.yahoo.com>, Puddinhead
 Wilson typed:

 >>why not simply install all possible equal cost paths
 >>as suggested in an IETF draft in the IDR WG by Manav
 >>Bhatia and remove only those which are not needed/have
 >>failed.

 I think thats a good approach for some situations, but there are
scenarios where an unequal cost path is useful for protection (e.g.
you might be provisioned for voip and best effort with all paths
working ,but happily re-route best effort onto a worse cost path to
keep the voip traffic ok... - c.f. sprint labs research on this...)

 >>
 >>
 >>--- John Day <day at std.com> wrote:
 >>
 >>> Rather than try to compute all of the possible
 >>> alternate FIBs that 
 >>> could occur (most won't happen) and  on the
 >>> assumption, that networks 
 >>> tend to fail in the same places, ;-) as Jon first
 >>> suggested why not 
 >>> just keep the a running history of the last several
 >>> FIBs, assume 
 >>> after some amount of time or lack of use (a FIB
 >>> replacement algorithm 
 >>> ;-)) they are discarded, when a failure/change
 >>> occurs if no existing 
 >>> FIB meets the evaluation criteria (not a close fit),
 >>> then compute a 
 >>> new one, and add it to your cache, etc.
 >>> 
 >>> Of course the hard part is coming up with the
 >>> evaluation criteria to 
 >>> determine whether the current situation matches
 >>> previous ones. But as 
 >>> Jon suggests there are probably some pretty nice
 >>> pattern matching 
 >>> schemes for this.
 >>> 
 >>> Take care,
 >>> John
 >>> 
 >>> 
 >>> 
 >>> At 9:29 +0100 2006/06/16, Jon Crowcroft wrote:
 >>> >what is interesting about that study is that it
 >>> shows that the net
 >>> >_evolves_ almost more than it just changes - this
 >>> means that a lot of
 >>> >_pre-computed_ protection schemes aren't going to
 >>> work too well...assuming the
 >>> >study of the michnet is typical of other nets
 >>> >
 >>> >In missive <4491B3F7.3070805 at uclouvain.be>, Olivier
 >>> Bonaventure typed:
 >>> >
 >>> >  >>Craig,
 >>> >  >>>
 >>> >  >>>>Yes, but this approach of precomputing FIBs
 >>> has a few drawbacks :
 >>> >  >>>>- you may need to compute a lot of different
 >>> FIB to cover all possible
 >>> >  >>>>failures in the network
 >>> >  >>>>- updating a FIB is not necessary fast on
 >>> current routers. For example,
 >>> >  >>>>on a Cisco 12k, updating a FIB requries about
 >>> 110 microsecond per prefix
 >>> > 
 >>>
 >>>>>>http://citeseer.ist.psu.edu/francois05achieving.html
 >>> >  >>>
 >>> >  >>>
 >>> >  >>> Sounds like two good research problems.
 >>> >  >>>
 >>> >  >>> In fact, one solution to the second problem
 >>> is known -- have two FIB
 >>> >  >>> memories -- one active, one backup -- and
 >>> make it possible to switch.
 >>> >  >>> We showed how to do that about ten years ago
 >>> in the MultiGigabit Router
 >>> >  >>> project (the major nuisance was invalidating
 >>> the NP caches).
 >>> >  >>
 >>> >  >>The cost is to have two FIBs instead of one one
 >>> each linecard.
 >>> >  >>
 >>> >  >>> As for the first -- do we know or have we
 >>> thought of ways to determine
 >>> >  >>> which FIBs it would be useful to have?  I.e.,
 >>> don't solve all possible
 >>> >  >>> failures -- pick the best subset of FIBS
 >>> given a limit on the number of
 >>> >  >>> FIBS (say 5) and current statistics on link
 >>> outages.  There's 
 >>> >also a clear
 >>> >  >>> metric for goodness -- namely, take the list
 >>> of outages, weighted by
 >>> >  >>> their likelihood, and see what fraction of
 >>> [weighted] outages are covered
 >>> >  >>> by the set of alternate FIBS.  Obviously a
 >>> metric of 1.0 is desired, but
 >>> >  >>> I'll bet any metric over, say, 0.6 has an
 >>> impact.
 >>> >  >>
 >>> >  >>It could be possible to maintain a cache of the
 >>> last N FIBs that have
 >>> >  >>been used, but this kind of approach may be
 >>> difficult in practice for
 >>> >  >>two reasons :
 >>> >  >>- studies of ospf traces
 >>> > 
 >>>
 >>>>http://citeseer.ist.psu.edu/watson03experiences.html
 >>> >  >>have shown that a router does not frequently
 >>> reuse exactly the same
 >>> >  >>shortest path tree many times
 >>> >  >>- the link state database must be maintained
 >>> together with the old FIB
 >>> >  >>and when a new link state packet is received
 >>> with a change, then you
 >>> >  >>need to check whether the topology of the old
 >>> FIB is exactly equal to
 >>> >  >>the current one
 >>> >  >>
 >>> >  >>
 >>> >  >>Olivier
 >>> >
 >>> >  cheers
 >>> >
 >>> >    jon
 >>> 
 >>> 
 >>
 >>
 >>
 >>	
 >>	
 >>		
 >>___________________________________________________________ 
 >>All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine 
 >>http://uk.docs.yahoo.com/nowyoucan.html

 cheers

   jon


From touch at ISI.EDU  Tue Jun 20 09:18:55 2006
From: touch at ISI.EDU (Joe Touch)
Date: Tue, 20 Jun 2006 09:18:55 -0700
Subject: [e2e] PS - a hint to avoid getting posts held-for-approval
In-Reply-To: <E1Fsbg5-0007hi-00@mta1.cl.cam.ac.uk>
References: <E1Fsbg5-0007hi-00@mta1.cl.cam.ac.uk>
Message-ID: <44981FEF.4050801@isi.edu>

Hi, all,

In order to reduce bulk spam, this list has a limit on the number of
recipients allowed before filters kick-in and a post is held for approval.

There is no limit on how many recipients are allowed in a post, but such
posts may be delayed until reviewed and approved. To avoid your posts
being inadvertently delayed, please trim the recipient list of your posts.

FYI.

Joe (as list admin)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20060620/26e6f034/signature-0001.bin

From mbgreen at dsl.cis.upenn.edu  Wed Jun 21 13:29:58 2006
From: mbgreen at dsl.cis.upenn.edu (mbgreen@dsl.cis.upenn.edu)
Date: Wed, 21 Jun 2006 16:29:58 -0400 (EDT)
Subject: [e2e] queuing/dropping algorithms *actually* deployed
Message-ID: <200606212029.k5LKTwmF018130@codex.cis.upenn.edu>

A colleague who wanted to do some formal model checking and formal
performance analysis on an application-level protocol going through a
router, asked me what algorithms are used in currently deployed
routers in the Internet.  (Looking for an accurate model of packet
drops when this protocol was running alongside many flows of the same
protocol, as well as both congestion aware *and* inelastic
bad-behaving flows).

I realized that I had no idea what to tell him.  In what
fraction of routers is RED turned on and used these days?  Is some
sort of fairness or QoS preserved in a measurable fraction of routers?
Scheduling?  10 or 15 years ago I guess I could have safely said
queues are almost all FIFO and drop-tail controls when packets are
dropped and basically nothing else is relevant in a formal model.

Today I have no idea.  Is there some web site somewhere that can give 
me this information?  Is e2e the right place to ask this question ---
if not, then where? [and, in that case, my apologies for sending it
here]

Thanks in advance for any pointers.



From mbgreen at dsl.cis.upenn.edu  Wed Jun 21 14:18:07 2006
From: mbgreen at dsl.cis.upenn.edu (mbgreen@dsl.cis.upenn.edu)
Date: Wed, 21 Jun 2006 17:18:07 -0400 (EDT)
Subject: [e2e] queuing/dropping algorithms *actually* deployed
Message-ID: <200606212118.k5LLI7JX019125@codex.cis.upenn.edu>

A colleague who wanted to do some formal model checking and formal
performance analysis on an application-level protocol going through a
router, asked me what algorithms are used in currently deployed
routers in the Internet.  (Looking for an accurate model of packet
drops when this protocol was running alongside many flows of the same
protocol, as well as both congestion aware *and* inelastic
bad-behaving flows).

I realized that I had no idea what to tell him.  In what
fraction of routers is RED turned on and used these days?  Is some
sort of fairness or QoS preserved in a measurable fraction of routers?
Scheduling?  10 or 15 years ago I guess I could have safely said
queues are almost all FIFO and drop-tail controls when packets are
dropped and basically nothing else is relevant in a formal model.

Today I have no idea.  Is there some web site somewhere that can give 
me this information?  Is e2e the right place to ask this question ---
if not, then where? [and, in that case, my apologies for sending it
here]

Thanks in advance for any pointers.


From dpreed at reed.com  Thu Jun 22 01:09:58 2006
From: dpreed at reed.com (David P. Reed)
Date: Thu, 22 Jun 2006 04:09:58 -0400
Subject: [e2e] queuing/dropping algorithms *actually* deployed
In-Reply-To: <200606212029.k5LKTwmF018130@codex.cis.upenn.edu>
References: <200606212029.k5LKTwmF018130@codex.cis.upenn.edu>
Message-ID: <449A5056.3010604@reed.com>

What is the scope?   Are you interested in the queueing/dropping 
protocols deployed on gateways connected via carrier pigeons according 
to the RFC standard?

If so, I am prepared to send samples of the droppings, at least, from 
Trafalgar Sq.

mbgreen at dsl.cis.upenn.edu wrote:
> A colleague who wanted to do some formal model checking and formal
> performance analysis on an application-level protocol going through a
> router, asked me what algorithms are used in currently deployed
> routers in the Internet.  (Looking for an accurate model of packet
> drops when this protocol was running alongside many flows of the same
> protocol, as well as both congestion aware *and* inelastic
> bad-behaving flows).
>
> I realized that I had no idea what to tell him.  In what
> fraction of routers is RED turned on and used these days?  Is some
> sort of fairness or QoS preserved in a measurable fraction of routers?
> Scheduling?  10 or 15 years ago I guess I could have safely said
> queues are almost all FIFO and drop-tail controls when packets are
> dropped and basically nothing else is relevant in a formal model.
>
> Today I have no idea.  Is there some web site somewhere that can give 
> me this information?  Is e2e the right place to ask this question ---
> if not, then where? [and, in that case, my apologies for sending it
> here]
>
> Thanks in advance for any pointers.
>
>
>
>
>   


From mbgreen at dsl.cis.upenn.edu  Thu Jun 22 06:29:32 2006
From: mbgreen at dsl.cis.upenn.edu (mbgreen@dsl.cis.upenn.edu)
Date: Thu, 22 Jun 2006 09:29:32 EDT
Subject: [e2e] queuing/dropping algorithms *actually* deployed
Message-ID: <200606221329.k5MDTWUP008375@central.cis.upenn.edu>

[I guess I need to fix my "From:" address; the first time I sent
this it was rejected.]

   From: David P. Reed [mailto:dpreed at reed.com]
   Sent: Thursday, June 22, 2006 4:10 AM
   
   What is the scope?   Are you interested in the  
   queueing/dropping protocols deployed on gateways
   connected via carrier pigeons according to the RFC 
   standard?

I guess that's a good question and I should clarify.  By
algorithms "deployed in routers in the Internet" I meant
queuing/dropping algorithms deployed in a measurable
fraction of routers reachable through IP, by packets with
IPv4 or IPv6 Internet addresses from a source attached to
the "public" Internet (e.g. the "Internet" accessible from
an ISP such as Comcast or Verizon or by being connected
through most U.S. universities).  

As to your particular example: if a significant fraction
of such routers were connected by carrier pigeons, then
yes, I'd want to know about that.  If these were common
enough then I'd bet there would be models of the likely
order in which packets would arrive, and the odds of them
being dropped (Maybe not even so complicated a model if
pigeons in Trafalgar square use "tail"-drop, no? :-)
Similarly, if there happen to be a lot of gateways
connected by men with telescopes and flags or sending
morse code, then I'd want to know about.

But I thought that pigeons, and telescopes, and smoke and
mirrors were rare (relatively) these days --- at least
from routers reachable by standard IP addresses from the
"Internet".  But I don't *know* that, because I don't know
what is commonly deployed today, nor what algorithms are
commonly provided or actually turned on in the
routers/gateways that *are* deployed.

Thanks for any info.
   
   If so, I am prepared to send samples of the droppings,
   at least, from
   Trafalgar Sq.
   
   mbgreen at dsl.cis.upenn.edu wrote:
   > A colleague who wanted to do some formal model checking and
   > formal performance analysis on an application-level protocol
   > going through a router, asked me what algorithms are used in
   > currently deployed routers in the Internet.  (Looking for an
   > accurate model of packet drops when this protocol was
   > running alongside many flows of the same protocol, as well
   > as both congestion aware *and* inelastic bad-behaving
   > flows).
   >
   > I realized that I had no idea what to tell him.  In what
   > fraction of routers is RED turned on and used these days?
   > Is some sort of fairness or QoS preserved in a measurable
   > fraction of routers?  Scheduling?  10 or 15 years ago I
   > guess I could have safely said queues are almost all FIFO
   > and drop-tail controls when packets are dropped and
   > basically nothing else is relevant in a formal model.
   >
   > Today I have no idea.  Is there some web site somewhere that
   > can give me this information?  Is e2e the right place to ask
   > this question --- if not, then where? [and, in that case, my
   > apologies for sending it here]
   >
   > Thanks in advance for any pointers.

From chrisk at mysticlabs.com  Thu Jun 22 07:08:19 2006
From: chrisk at mysticlabs.com (Chris Kappler)
Date: Thu, 22 Jun 2006 10:08:19 -0400
Subject: [e2e]  queuing/dropping algorithms *actually* deployed
Message-ID: <005001c69605$5266f5c0$6601a8c0@mystic3>

 

One way to go about analyzing this is to look at the product placement
graphs of the major manufacturers and cross-reference that with the
supported configurations.  

 

http://www.juniper.net/products/301015.pdf

http://www.cisco.com/en/US/products/hw/routers/index.html  (click on Routers
for Service Providers)

 

 

I have first-hand knowledge of some of the mid- to hi-end Cisco platforms
which enable WRED and some degree of fairness automatically on every
classification type that is created.  The user is then capable of
configuring large scale traffic classification and associated QoS.  Many of
the large routers have so many interfaces that some degrees of QoS is needed
internally just to keep the links full.

 

Just about every platform, including my linksys router at home, supports
simple priorities.  I have this feature enabled to prevent my wife's photo
uploads from knocking my VoIP phone off-line.  The higher-end Cisco routers
support what is called the modular QoS CLI which is basically a set of
classification commands and the corresponding QoS treatment for each class.
The first link below makes me think that Juniper has a similar command set.

 

Configuration pointers:

http://www.juniper.net/techpubs/software/junos/junos76/swconfig76-cos/html/c
os-overview7.html#1024445

http://www.cisco.com/en/US/products/ps5763/products_configuration_guide_chap
ter09186a00803b7c7b.html#wp1035219

 

Most service providers take provisioning and QoS pretty seriously since
bandwidth and differentiated services are at the heart of their revenue
stream.  Big telephone companies seem to have well educated QoS staff that
asks hard questions of routing manufactures.  I don't have first-hand
knowledge on other zones of the net such as core or customer premises.
However, I have heard more than once that companies deploying VoIP services
internally usually require a re-vamp of their internal QoS before their
fancy new telephones start working as well as the old ones did :)

 

I hope this helps,

Chris Kappler

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20060622/4e7b149f/attachment.html

From puddinghead_wilson007 at yahoo.co.uk  Thu Jun 22 02:05:43 2006
From: puddinghead_wilson007 at yahoo.co.uk (Puddinhead Wilson)
Date: Thu, 22 Jun 2006 10:05:43 +0100 (BST)
Subject: [e2e] fast restoration/protection
In-Reply-To: <E1Fsbg5-0007hi-00@mta1.cl.cam.ac.uk>
Message-ID: <20060622090543.26011.qmail@web25408.mail.ukl.yahoo.com>

ok , so make "your contraint" a metric in BGP and send
out the best of all your constraints as BGP does even
now. 
So if a node A says "my best is X" for a given
constraint it is fair to assume that that particular
node has paths which satisfy that max, and lower.

Though if the LSP/path is setup only for FRR/backup
etc, running IGP on all intermediate nodes and BGP
towards customer facing networks is what makes more
sense.

more like 
customer--BGP(with some connection setup.teardown
mechanism)-----rest of the networks running ISIS/OSPF
on circuit swithing gear---BGP---customer facing
stuff.
--- Jon Crowcroft <Jon.Crowcroft at cl.cam.ac.uk> wrote:

> In missive
>
<20060620082314.97170.qmail at web25402.mail.ukl.yahoo.com>,
> Puddinhead
>  Wilson typed:
> 
>  >>why not simply install all possible equal cost
> paths
>  >>as suggested in an IETF draft in the IDR WG by
> Manav
>  >>Bhatia and remove only those which are not
> needed/have
>  >>failed.
> 
>  I think thats a good approach for some situations,
> but there are
> scenarios where an unequal cost path is useful for
> protection (e.g.
> you might be provisioned for voip and best effort
> with all paths
> working ,but happily re-route best effort onto a
> worse cost path to
> keep the voip traffic ok... - c.f. sprint labs
> research on this...)
> 
>  >>
>  >>
>  >>--- John Day <day at std.com> wrote:
>  >>
>  >>> Rather than try to compute all of the possible
>  >>> alternate FIBs that 
>  >>> could occur (most won't happen) and  on the
>  >>> assumption, that networks 
>  >>> tend to fail in the same places, ;-) as Jon
> first
>  >>> suggested why not 
>  >>> just keep the a running history of the last
> several
>  >>> FIBs, assume 
>  >>> after some amount of time or lack of use (a FIB
>  >>> replacement algorithm 
>  >>> ;-)) they are discarded, when a failure/change
>  >>> occurs if no existing 
>  >>> FIB meets the evaluation criteria (not a close
> fit),
>  >>> then compute a 
>  >>> new one, and add it to your cache, etc.
>  >>> 
>  >>> Of course the hard part is coming up with the
>  >>> evaluation criteria to 
>  >>> determine whether the current situation matches
>  >>> previous ones. But as 
>  >>> Jon suggests there are probably some pretty
> nice
>  >>> pattern matching 
>  >>> schemes for this.
>  >>> 
>  >>> Take care,
>  >>> John
>  >>> 
>  >>> 
>  >>> 
>  >>> At 9:29 +0100 2006/06/16, Jon Crowcroft wrote:
>  >>> >what is interesting about that study is that
> it
>  >>> shows that the net
>  >>> >_evolves_ almost more than it just changes -
> this
>  >>> means that a lot of
>  >>> >_pre-computed_ protection schemes aren't going
> to
>  >>> work too well...assuming the
>  >>> >study of the michnet is typical of other nets
>  >>> >
>  >>> >In missive <4491B3F7.3070805 at uclouvain.be>,
> Olivier
>  >>> Bonaventure typed:
>  >>> >
>  >>> >  >>Craig,
>  >>> >  >>>
>  >>> >  >>>>Yes, but this approach of precomputing
> FIBs
>  >>> has a few drawbacks :
>  >>> >  >>>>- you may need to compute a lot of
> different
>  >>> FIB to cover all possible
>  >>> >  >>>>failures in the network
>  >>> >  >>>>- updating a FIB is not necessary fast
> on
>  >>> current routers. For example,
>  >>> >  >>>>on a Cisco 12k, updating a FIB requries
> about
>  >>> 110 microsecond per prefix
>  >>> > 
>  >>>
> 
>
>>>>>>http://citeseer.ist.psu.edu/francois05achieving.html
>  >>> >  >>>
>  >>> >  >>>
>  >>> >  >>> Sounds like two good research problems.
>  >>> >  >>>
>  >>> >  >>> In fact, one solution to the second
> problem
>  >>> is known -- have two FIB
>  >>> >  >>> memories -- one active, one backup --
> and
>  >>> make it possible to switch.
>  >>> >  >>> We showed how to do that about ten years
> ago
>  >>> in the MultiGigabit Router
>  >>> >  >>> project (the major nuisance was
> invalidating
>  >>> the NP caches).
>  >>> >  >>
>  >>> >  >>The cost is to have two FIBs instead of
> one one
>  >>> each linecard.
>  >>> >  >>
>  >>> >  >>> As for the first -- do we know or have
> we
>  >>> thought of ways to determine
>  >>> >  >>> which FIBs it would be useful to have? 
> I.e.,
>  >>> don't solve all possible
>  >>> >  >>> failures -- pick the best subset of FIBS
>  >>> given a limit on the number of
>  >>> >  >>> FIBS (say 5) and current statistics on
> link
>  >>> outages.  There's 
>  >>> >also a clear
>  >>> >  >>> metric for goodness -- namely, take the
> list
>  >>> of outages, weighted by
>  >>> >  >>> their likelihood, and see what fraction
> of
>  >>> [weighted] outages are covered
>  >>> >  >>> by the set of alternate FIBS.  Obviously
> a
>  >>> metric of 1.0 is desired, but
>  >>> >  >>> I'll bet any metric over, say, 0.6 has
> an
>  >>> impact.
>  >>> >  >>
>  >>> >  >>It could be possible to maintain a cache
> of the
>  >>> last N FIBs that have
>  >>> >  >>been used, but this kind of approach may
> be
>  >>> difficult in practice for
>  >>> >  >>two reasons :
>  >>> >  >>- studies of ospf traces
>  >>> > 
>  >>>
> 
>
>>>>http://citeseer.ist.psu.edu/watson03experiences.html
>  >>> >  >>have shown that a router does not
> frequently
>  >>> reuse exactly the same
>  >>> >  >>shortest path tree many times
>  >>> >  >>- the link state database must be
> maintained
>  >>> together with the old FIB
>  >>> >  >>and when a new link state packet is
> received
>  >>> with a change, then you
>  >>> >  >>need to check whether the topology of the
> old
>  >>> FIB is exactly equal to
>  >>> >  >>the current one
>  >>> >  >>
>  >>> >  >>
>  >>> >  >>Olivier
>  >>> >
>  >>> >  cheers
>  >>> >
>  >>> >    jon
>  >>> 
>  >>> 
>  >>
>  >>
>  >>
>  >>	
>  >>	
>  >>		
> 
>
>>___________________________________________________________
> 
>  >>All new Yahoo! Mail "The new Interface is
> stunning in its simplicity and ease of use." - PC
> Magazine 
>  >>http://uk.docs.yahoo.com/nowyoucan.html
> 
>  cheers
> 
>    jon
> 
> 



		
___________________________________________________________ 
Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html

From braden at ISI.EDU  Thu Jun 22 09:50:20 2006
From: braden at ISI.EDU (Bob Braden)
Date: Thu, 22 Jun 2006 09:50:20 -0700 (PDT)
Subject: [e2e] queuing/dropping algorithms *actually* deployed
Message-ID: <200606221650.JAA22729@gra.isi.edu>


 
Dave Reed wrote:

  *> 
  *> What is the scope?   Are you interested in the queueing/dropping 
  *> protocols deployed on gateways connected via carrier pigeons according 
  *> to the RFC standard?
  *> 
  *> If so, I am prepared to send samples of the droppings, at least, from 
  *> Trafalgar Sq.

Uh, Dave, I think your sample should be limited to packet-carrying carrier
pigeons in Trafalgar Square.

(sorry)

Bob Braden

From dpreed at reed.com  Thu Jun 22 13:30:35 2006
From: dpreed at reed.com (David P. Reed)
Date: Thu, 22 Jun 2006 16:30:35 -0400
Subject: [e2e] queuing/dropping algorithms *actually* deployed
In-Reply-To: <200606221650.JAA22729@gra.isi.edu>
References: <200606221650.JAA22729@gra.isi.edu>
Message-ID: <449AFDEB.5060905@reed.com>

Bob Braden wrote:
> Uh, Dave, I think your sample should be limited to packet-carrying carrier
> pigeons in Trafalgar Square.
>   
I was wondering exactly how to get valid data, thinking I could engage 
the clever heads of a few doctoral students at UCL to determine whether 
drops are valid IP packets or merely those fed by non-IP telco walled 
gardens in London.

Since Jon Crowcroft's pate is now gone from the area, perhaps Mark 
Handley would lead the team.   (Mayor Livingstone may moot the question 
soon, since he apparently is focused on blocking pigeon traffic in the 
square entirely.   Net Neutrality in London is apparently not on..., at 
least on the avian AS).

From jtk at northwestern.edu  Thu Jun 22 14:38:00 2006
From: jtk at northwestern.edu (John Kristoff)
Date: Thu, 22 Jun 2006 16:38:00 -0500
Subject: [e2e] queuing/dropping algorithms *actually* deployed
In-Reply-To: <200606212118.k5LLI7JX019125@codex.cis.upenn.edu>
References: <200606212118.k5LLI7JX019125@codex.cis.upenn.edu>
Message-ID: <20060622213802.97851136C82@aharp.ittns.northwestern.edu>

On Wed, 21 Jun 2006 17:18:07 -0400 (EDT)
mbgreen at dsl.cis.upenn.edu wrote:

> I realized that I had no idea what to tell him.  In what
> fraction of routers is RED turned on and used these days?  Is some

This came up in a a thread entitled "Is Red Dead?" on this last year
in September and October.  Perusing those posts will give you some
insight.

> sort of fairness or QoS preserved in a measurable fraction of routers?
> Scheduling?  10 or 15 years ago I guess I could have safely said
> queues are almost all FIFO and drop-tail controls when packets are
> dropped and basically nothing else is relevant in a formal model.

This is probably still true, but I know there has been some use of
QoS/AQM within organizations turning that stuff on as they deploy
VoIP.  Though in my experience, except for those limited WAN links
most of preferential treatment of packets and dropping is not
actively happening.  Furthermore, in my experience, monitoring to
see if those knobs are doing something useful is rarely being done.

Recently I have heard of one very large content provider who is
deploying "QoS".  As it was described to me, it was mainly as a means
to help decide "who/what" gets to live if a significant portion of
the network goes away rather than as a way to prioritize packets in
normal operation.  I'm not sure if this is public knowledge, but I
am hoping they'll at least do some kind of talk based on their
experience soon.

All the political talk of net neutrality I suppose may spur some
additional management pressure to do "QoS" as well.

John

From fergdawg at netzero.net  Thu Jun 22 15:02:02 2006
From: fergdawg at netzero.net (Fergie)
Date: Thu, 22 Jun 2006 22:02:02 GMT
Subject: [e2e] queuing/dropping algorithms *actually* deployed
Message-ID: <20060622.150228.15905.256641@webmail22.lax.untd.com>

An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://mailman.postel.org/pipermail/end2end-interest/attachments/20060622/758e1436/attachment.ksh

From garmitage at swin.edu.au  Thu Jun 22 15:49:51 2006
From: garmitage at swin.edu.au (grenville armitage)
Date: Fri, 23 Jun 2006 08:49:51 +1000
Subject: [e2e] Online FPS LAN traces available
Message-ID: <449B1E8F.5010308@swin.edu.au>

All,

Hopefully this is of interest to end2end readers...

In the last few years we've all seen papers on modelling and simulating the
traffic patterns of online multiplayer games. To support this interest
CAIA is releasing a collection of tcpdump files containing traffic fragments
of First Person Shooter games with different numbers of players and maps.

The online database is preliminary, and we hope to expand it in the future.
For the moment it contains LAN traces from Enemy Territory (10),
Half Life 2 Counter-Strike (12), Half Life 2 Deathmatch (10),
Half Life Counter-Strike (10), Half Life Deathmatch (10), Quake3 (10)
and XBox Halo (8). Documentation is provided with each tracefile to
identify the LAN and host PC conditions underwhich each trace was
collected.

http://caia.swin.edu.au/sitcrc/staticpages/index.php?page=song

(The repository is called SONG - "Simulating Online Networked Games",
and will eventually also contain traffic generator examples.)

cheers,
gja 

http://caia.swin.edu.au


From randy at psg.com  Thu Jun 22 16:58:40 2006
From: randy at psg.com (Randy Bush)
Date: Thu, 22 Jun 2006 16:58:40 -0700
Subject: [e2e] queuing/dropping algorithms *actually* deployed
References: <200606212118.k5LLI7JX019125@codex.cis.upenn.edu>
	<20060622213802.97851136C82@aharp.ittns.northwestern.edu>
Message-ID: <17563.11952.364718.402628@roam.psg.com>

> All the political talk of net neutrality I suppose may spur some
> additional management pressure to do "QoS" as well.

hard to drop someone's packets well when my job is to deliver
packets

randy


From jshen_cad at yahoo.com.cn  Sun Jun 25 10:00:56 2006
From: jshen_cad at yahoo.com.cn (Jing Shen)
Date: Mon, 26 Jun 2006 01:00:56 +0800 (CST)
Subject: [e2e] queuing/dropping algorithms *actually* deployed
In-Reply-To: <20060622213802.97851136C82@aharp.ittns.northwestern.edu>
Message-ID: <20060625170056.948.qmail@web15409.mail.cnb.yahoo.com>

> 
> Recently I have heard of one very large content
> provider who is
> deploying "QoS".  As it was described to me, it was
> mainly as a means
> to help decide "who/what" gets to live if a
> significant portion of
> the network goes away rather than as a way to
> prioritize packets in
> normal operation.  I'm not sure if this is public
> knowledge, but I
> am hoping they'll at least do some kind of talk
> based on their
> experience soon.
> 

that should be interesting. IMHO, the word "QoS" is
used and misunderstanded in many area. In technical
area, the word usually means turple of bandwidth,
delay, jitter, packet loss , while in some technical
training book ( like those for CCNP) it just means
there is configure command for queueing. In commercial
world, QoS means difference between e2e communicatin
quality and customer service ( including distard
recovery, technical service, value-added service
etc.). 

what I'm interested in is, whether their is
architectural solution for e2e communication quality
difference? Could current IP queueing mechanism do
what TDM channel could provide? or, is there a way to
make internet more controllable than before?

Joe

Jing Shen

Data Communication Center
HangZhou TeleCom 
HangZhou ZJ 310027
P.R.China

' spamcontrol '


		
___________________________________________________________ 
ÇÀ×¢ÑÅ»¢Ãâ·ÑÓÊÏä-3.5GÈÝÁ¿£¬20M¸½¼þ£¡ 
http://cn.mail.yahoo.com