From jshen_cad at yahoo.com.cn  Sun Oct  2 04:46:51 2005
From: jshen_cad at yahoo.com.cn (Jing Shen)
Date: Sun, 2 Oct 2005 19:46:51 +0800 (CST)
Subject: [e2e] Is RED dead?
In-Reply-To: <20050930164517.98303.qmail@web25408.mail.ukl.yahoo.com>
Message-ID: <20051002114651.82120.qmail@web15404.mail.cnb.yahoo.com>

 
> 
> how does it matter in case of congestion/queue if i
> drop at a central node or an edge node?
> 

IMHO it doesn't matter where packet is dropped  if
only congestion is considered; but from viewpoint of
resource management those packet should be dropped as
near to the end station as possible. On the other
hand, service providers are always tried to
differentiate service between their customers, so
packet drop should consider the situation that
priority traffic 'eat' too much of bandwidth. Someone
may say we could divide bandwidth to different groups
in which each member is only allowed to occupy a part
of BW, but that lead to a problem of bandwidth
estimation and complexity in network management, esp.
when MPLS TE is employed. So, (W)RED may be good to
best-effort network. And, I don't think it enough for
ISPs who are trying hard to find out a way out of the
jungle of uncontrolled P2P, virus, SPAM, malicious
packets from crackers ...


So, should e2e only focusing on TCP, XCP or to
consider a system which could not only make internet a
robust and self-sealing system but also make it a
predictable system?  

Jing


> is the queue size sufficient to hold a window?

If I do not misunderstand your question, queues size
is to implementation design. To my limited knowledge
interface queue size is to hold traffic of 10-12ms
full rate bursty traffic.

regards

Joe



> 
> -danke!
> 
> --- Jing Shen <jshen_cad at yahoo.com.cn> wrote:
> 
> > I've talked with some one before who said wred is
> > deployed in ISP network edge, but he is just from
> a
> > network equipment manufacturer. 
> > 
> > To me, (W)RED seems good to provide a method
> > avoiding
> > congestion. But, how could those traffic be
> dropped
> > according to traffic management requirement ? how
> to
> > avoid to focusing those "honest" TCP
> > implementations?
> > 
> > Jing  
> > 
> > 
> > --- Randy Bush <randy at psg.com>дµÀ:
> > 
> > > wred is used in real network deployments, though
> > not
> > > as widely
> > > as it likely should be.
> > > 
> > > randy
> > > 
> > > 
> > 
> > 
> > Jing Shen
> > 
> > Data Communication Center
> > HangZhou TeleCom 
> > HangZhou ZJ 310027
> > P.R.China
> > 
> > ' spamcontrol '
> > 
> > 
> > 		
> >
>
___________________________________________________________
> > 
> >
>
ÑÅ»¢ÓÊÏ䳬ǿÔöÖµ·þÎñ£­2G³¬´ó¿Õ¼ä¡¢pop3ÊÕÐÅ¡¢ÎÞÏÞÁ¿ÓʼþÌáÐÑ
> > 
> > http://cn.mail.yahoo.com
> > 
> 
> 
> 
> 		
>
___________________________________________________________
> 
> To help you stay safe and secure online, we've
> developed the all new Yahoo! Security Centre.
> http://uk.security.yahoo.com
> 



	

	
		
___________________________________________________________ 
ÑÅ»¢Ãâ·ÑGÓÊÏ䣭ÖйúµÚÒ»¾øÎÞÀ¬»øÓʼþɧÈų¬´óÓÊÏä 
http://cn.mail.yahoo.com


From fred at cisco.com  Fri Oct  7 07:52:50 2005
From: fred at cisco.com (Fred Baker)
Date: Fri, 7 Oct 2005 07:52:50 -0700
Subject: [e2e] IEEE Internet Award
Message-ID: <C22959F4-7CF5-4FB2-8CE6-0C7621464A9A@cisco.com>

A committee is accepting nominations for the IEEE Internet Award. It  
may be presented annually to an individual or team of up to three for  
exceptional contributions to the advancement of Internet technology  
for network architecture, mobility and/or end-use applications.
In the evaluation process, the following criteria are considered:  
Innovation, leadership in the field, contributions to open system,  
specification, honors or other achievements and the quality of the  
nomination.

The URL for the award and nomination form is http://www.ieee.org/ 
portal/site/mainsite/menuitem.818c0c39e85ef176fb2275875bac26c8/ 
index.jsp?&pName=corp_level1&path=about/awards/ 
sums&file=internet.xml&xsl=generic.xsl

Please submit nominations.

From jj at cs.brown.edu  Wed Oct 12 10:57:44 2005
From: jj at cs.brown.edu (John Jannotti)
Date: Wed, 12 Oct 2005 13:57:44 -0400
Subject: [e2e] Networking meets databases (NetDB 06)
Message-ID: <m3hdbmmxd3.fsf@shrub.cs.brown.edu>


Is the integration of networks and databases the greatest sin against,
or greatest triumph of the end-to-end argument?  Submit a paper and
contribute to the argument.

The second IEEE NetDB is a workshop intended to bring together
networking and database researchers.  I hope you'll consider submitting
your work if it lies along that intersection.  This year it will be
co-located with ICDE in Atlanta.

Submissions are due Nov 7.

The workshop: http://www.cs.brown.edu/research/db/netdb06/
The CFP: http://www.cs.brown.edu/research/db/netdb06/cfp.html

  jj


From weixl at caltech.edu  Thu Oct 13 00:38:16 2005
From: weixl at caltech.edu (Xiaoliang (David) Wei)
Date: Thu, 13 Oct 2005 00:38:16 -0700
Subject: [e2e] A patch that speeds up the NS-2 simulation
References: <m3hdbmmxd3.fsf@shrub.cs.brown.edu>
Message-ID: <02d601c5cfc9$13508f70$f5f2010a@seashadow>

     I guess this may help some colleagues in e2e, especially those who are 
using NS-2 to simulate high speed long distance network. If you find that 
your NS-2 simulation runs on a 200-second simulation for a day, the patch 
may probably help. You can download the patch and see detailed explanation 
from:

     http://www.cs.caltech.edu/~weixl/technical/ns2patch/ns2patch.htm

     In the patch, I only changed the event scheduler of NS2. So, the 
patched NS-2 will give the same results as the original one. Depending on 
different scenarios, the patched NS2 runs faster in most the cases I tested, 
sometimes 50 times faster. If you find any problem, please let me know.:)



A little bit more details (See the link above for more details):

     The original NS2 scheduler is implemented by Calendar Queue. Its 
performance is expected to be O(1) on average but the real results may be 
much longer, especially when the events are not evenly distributed and the 
bucket-width is not "correct" for the event distribution. This is 
unfortunately more common in simulations of high speed long distance 
network, where the events are clustered in bursts.

     I add three changes:

1. Use the gaps between dequeued events, instead the gaps between the events 
in the most crowded bucket, to estimate the bucket-width.

2. Apply a scheme similar to SNOOPy Calendar Queue that tunes the 
bucket-width dynamically

3. Inside a bucket, I changed the search of event insertion point from 
forward-search to backward-search.




-David

Xiaoliang (David) Wei             Graduate Student in CS at Caltech
http://www.davidwei.org
==================================================== 



From riley at ece.gatech.edu  Thu Oct 13 12:20:19 2005
From: riley at ece.gatech.edu (George Riley)
Date: Thu, 13 Oct 2005 15:20:19 -0400
Subject: [e2e] A patch that speeds up the NS-2 simulation (Xiaoliang
	(David) Wei)
Message-ID: <01ddfc6d9b62a9a51e77bbd59692c476@ece.gatech.edu>

David, very nice.  You should try to get this folded into the baseline  
ns2 release.

A few years ago I added a "Map" scheduler to ns2, that simply uses an  
STL
map container to maintain the sorted list of events.  I'm pretty sure  
it's still
in the baseline ns2 release, and can be enabled by saying:

$ns use-scheduler Map

I'd be curious how this compares to yours in terms of efficiency.

George

------------------------------------------------------------------------ 
--------------------
George F. Riley, Assistant Professor
The School of Electrical and Computer Engineering at Georgia Tech
Atlanta, GA  30332-0250
(404)-894-4767
E-Mail: riley at ece.gatech.edu

ECE3090 Web Page: http://users.ece.gatech.edu/~riley/ece3090/
ECE6110 Web Page: http://users.ece.gatech.edu/~riley/ece6110/


From jtk at northwestern.edu  Thu Oct 13 12:27:31 2005
From: jtk at northwestern.edu (John Kristoff)
Date: Thu, 13 Oct 2005 14:27:31 -0500
Subject: [e2e] Is RED dead?
Message-ID: <20051013192731.EC3C9136C83@aharp.ittns.northwestern.edu>

On Mon, 19 Sep 2005 11:58:50 -0500
John Kristoff <jtk at northwestern.edu> wrote:

> I've recently been told by a trusted and clueful colleague that RED
> is a "compromised concept" and a "dead horse".  That surprised me a
> bit and I've been trying to understand why.  I've been reading and
[...]

I told a couple folks I would follow up with what I heard and learned
off list.  I heard from one person that thought RED.  Off list I heard
that a couple of big providers may use it when links become congested,
and that they will enable it if you ask, but do not by default.

Someone pointed out this useful link containing an extensive evaluation
of AQM schemes:

  <http://www.cs.unc.edu/~le/>

In my own experience with some Cisco gear, I suspect a fair number of
people have WRED on a number of interfaces where they have turned on
the QoS knobs for the box, primarily it seems as part of a VoIP
roll-out.  The queueing mechanisms are hardware dependent, but on a
Cisco 6509 Catalyst for example, most modern hardware modules come
with WRED on by default when you turn on 'QoS'.  However, since this
deployment is probably often done within campus networks where
congestion is rare, AQM is probably rarely activated.

In addition, in at least one Cisco platform I'm familiar with (6509/720
running native IOS), you also get the QoS knobs and WRED queueing turned
on by default when you enable Cisco's Control Plane Policing services.
I know of at least one large provider who is using this feature and I
suspect they've got some WRED queues without even knowing it.

So... in a nutshell, I feel I had gotten a very weak response to this
question.  Most people just don't seem to care enough or have problems
that really require it to be interested enough in RED or related
mechanisms at this time, but I wasn't convinced it was a compromised
concept.  :-)

John

From jtk at northwestern.edu  Thu Oct 13 13:00:42 2005
From: jtk at northwestern.edu (John Kristoff)
Date: Thu, 13 Oct 2005 15:00:42 -0500
Subject: [e2e] Is RED dead?
In-Reply-To: <20051013192731.EC3C9136C83@aharp.ittns.northwestern.edu>
References: <20051013192731.EC3C9136C83@aharp.ittns.northwestern.edu>
Message-ID: <20051013200042.5B5DA136C83@aharp.ittns.northwestern.edu>

On Thu, 13 Oct 2005 14:27:31 -0500
John Kristoff <jtk at northwestern.edu> wrote:

> I told a couple folks I would follow up with what I heard and learned
> off list.  I heard from one person that thought RED.  Off list I heard

Hmm... not sure what happened there... that second sentence should have
read:

  "I heard from one person that thought RED was dead."

John

From acaro at bbn.com  Thu Oct 13 13:22:04 2005
From: acaro at bbn.com (Armando L. Caro, Jr.)
Date: Thu, 13 Oct 2005 16:22:04 -0400
Subject: [e2e] Is RED dead?
In-Reply-To: <20051013192731.EC3C9136C83@aharp.ittns.northwestern.edu>
References: <20051013192731.EC3C9136C83@aharp.ittns.northwestern.edu>
Message-ID: <434EC1EC.6050807@bbn.com>

John Kristoff wrote:

> I told a couple folks I would follow up with what I heard and learned
> off list.  I heard from one person that thought RED.  Off list I heard
> that a couple of big providers may use it when links become congested,
> and that they will enable it if you ask, but do not by default.
                               ^^^^^^^^^^
Who exactly is "you"? I imagine you'd have to be a fairly big customer
to get that kind of response from a big provider. I'm sure that if *I*
even tried to ask *my* provider to turn on RED, I wouldn't even be able
to reach someone who understood what I was asking for.

-- 
Armando
www.armandocaro.net

From jtk at northwestern.edu  Thu Oct 13 13:38:02 2005
From: jtk at northwestern.edu (John Kristoff)
Date: Thu, 13 Oct 2005 15:38:02 -0500
Subject: [e2e] Is RED dead?
In-Reply-To: <434EC1EC.6050807@bbn.com>
References: <20051013192731.EC3C9136C83@aharp.ittns.northwestern.edu>
	<434EC1EC.6050807@bbn.com>
Message-ID: <20051013203802.AE715136C83@aharp.ittns.northwestern.edu>

On Thu, 13 Oct 2005 16:22:04 -0400
"Armando L. Caro, Jr." <acaro at bbn.com> wrote:

> Who exactly is "you"? I imagine you'd have to be a fairly big customer
> to get that kind of response from a big provider. I'm sure that if *I*
> even tried to ask *my* provider to turn on RED, I wouldn't even be
> able to reach someone who understood what I was asking for.

I was just relaying what I was told so I don't have any details.

I do remember asking UUNET about their use of RED a few years back
when I had a fractional DS-3 with them.  As I recall, the folks I
talked to, who, for technical people, were probably sales engineers
at best, said they didn't support it to do overall route performance
issues when it is enabled.  This sounded similar to the reasons for
not doing any kind of filtering (e.g. anti-spoof filters), which was
plausible, but this was the first I had heard of hardware performance
issues when RED was enabled so I challenged them on it.  I seem to
recall them mentioning something about a confidential internal testing
report that they couldn't share... then quickly shoo'ed me away.  :-)

John

From meena_selvam at yahoo.com  Sun Oct 16 10:36:14 2005
From: meena_selvam at yahoo.com (MEENA SELVAM)
Date: Sun, 16 Oct 2005 10:36:14 -0700 (PDT)
Subject: [e2e] doub regarding handling socket write errors
Message-ID: <20051016173615.32606.qmail@web30409.mail.mud.yahoo.com>

In one of the socket tutorials, , it was mentioned
when socket write errors are involved, perror can be
called and the program can be exited.

I also read when a system call fails, the progra will
exit.

In my situation, I have a main program which creates
threads. If socket write error happens in the sub
threads, I do not want to exit the main program,
basically I need to reconnect to the server when
socket write/read error happens.

so what should I do?

is there a signal that is generated upon a socket
write error? Should I catch that signal and try to
reconnect instead of exiting. How can I handle socket
write errors in my own way?

meena

 


		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/

From touch at ISI.EDU  Sun Oct 16 11:21:07 2005
From: touch at ISI.EDU (Joe Touch)
Date: Sun, 16 Oct 2005 11:21:07 -0700
Subject: [e2e] doub regarding handling socket write errors
In-Reply-To: <20051016173615.32606.qmail@web30409.mail.mud.yahoo.com>
References: <20051016173615.32606.qmail@web30409.mail.mud.yahoo.com>
Message-ID: <43529A13.70903@isi.edu>


MEENA SELVAM wrote:
> In one of the socket tutorials, , it was mentioned
> when socket write errors are involved, perror can be
> called and the program can be exited.
> 
> I also read when a system call fails, the progra will
> exit.
> 
> In my situation, I have a main program which creates
> threads. If socket write error happens in the sub
> threads, I do not want to exit the main program,
> basically I need to reconnect to the server when
> socket write/read error happens.
> 
> so what should I do?

Forward this query to another list, because this is off-topic for this
list. Please see our website for the purpose and topics that are
appropriate for this list.

Joe (as list admin)

> 
> is there a signal that is generated upon a socket
> write error? Should I catch that signal and try to
> reconnect instead of exiting. How can I handle socket
> write errors in my own way?
> 
> meena
> 
>  
> 
> 
> 		
> __________________________________ 
> Yahoo! Music Unlimited 
> Access over 1 million songs. Try it free.
> http://music.yahoo.com/unlimited/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20051016/6d052768/signature.bin

From jshen_cad at yahoo.com.cn  Sun Oct 16 20:23:00 2005
From: jshen_cad at yahoo.com.cn (Jing Shen)
Date: Mon, 17 Oct 2005 11:23:00 +0800 (CST)
Subject: [e2e] Is RED dead?
In-Reply-To: <007901c5c78c$7b977700$6401a8c0@rs.riverstonenet.com>
Message-ID: <20051017032300.59440.qmail@web15408.mail.cnb.yahoo.com>

> 
> I would use google/MSN/yahoo/xyz if either one of
> them is faster than the
> other since each one provides the same service
> 
> So if the content provider can get SPs to honor
> DS-TE on his packets
> (ofcourse coupled with a CAP on his circuit where he
> feeds the content) and
> deliver content faster to me, it makes sense from my
> view point to use his

That's what make sense to ISPs. Free lunch of
internet, esp. robust p2p networks, beat ISPs heavily
because there is so little gainback that could make
them thought internet is a good thing. We could not
overlook the fact that Internet has been open to
commercial world. In that world no service
differentiation means it's not a good platform.

Maybe this is off topic, but should we focus on
technical affairs while intellegent P2P network
becomes tools for virus or terrorist tools?   


> content service.
> again there is no end to the abstraction, if all
> content providers ask for
> that facility we are back to where we started and i
> need more
> bandwidth......

This is not possible because a very large amount of
traffic is made up of p2p applications. We all know
that Bittorent and Edonkey are free tools and ICP/ISP
could not use them to provide high quality service
now. Could it be possible for those individuals who
share pirate CDs by eDonkey? If not, why could they
consume a lot of bandwidth as xinhua.com.cn which pay
a lot to provide better service? Could WRED help with
this situation?  On the other hand, if there is
diffserv enabled in ISP networks how could we manage
to control virus cost much of the bandwidth
provisioned to EF classes?  

> plus I may not have too many users of say AOL in
> india, but a lot more of
> them in America, so should indian ISPs worry about
> the TOS bits set by AOL
> as it effects only a small chunk of their
> customers?..but is perfect from
> AOL's view point if they want to increase their user
> base in India...

That's that COPS cares about. From viewpoint of e2e
qos provisioning, AQM cares little on DSCP bits but
dropping packets randomly. An example, someone points
out that edonkey makes use of UDP/8094. Could WRED
affact UDP application throughput?  


Jing


		
___________________________________________________________ 
ÑÅ»¢ÓÊÏ䳬ǿÔöÖµ·þÎñ£­2G³¬´ó¿Õ¼ä¡¢pop3ÊÕÐÅ¡¢ÎÞÏÞÁ¿ÓʼþÌáÐÑ 
http://cn.mail.yahoo.com

From jshen_cad at yahoo.com.cn  Sun Oct 16 20:33:32 2005
From: jshen_cad at yahoo.com.cn (Jing Shen)
Date: Mon, 17 Oct 2005 11:33:32 +0800 (CST)
Subject: [e2e] Is RED dead?
In-Reply-To: <20051013192731.EC3C9136C83@aharp.ittns.northwestern.edu>
Message-ID: <20051017033332.34073.qmail@web15407.mail.cnb.yahoo.com>

Hi,

> 
> I told a couple folks I would follow up with what I
> heard and learned
> off list.  I heard from one person that thought RED.
>  Off list I heard
> that a couple of big providers may use it when links
> become congested,
> and that they will enable it if you ask, but do not
> by default.
> 

> Someone pointed out this useful link containing an
> extensive evaluation
> of AQM schemes:
> 
>   <http://www.cs.unc.edu/~le/>
> 
> In my own experience with some Cisco gear, I suspect
> a fair number of
> people have WRED on a number of interfaces where
> they have turned on
> the QoS knobs for the box, primarily it seems as
> part of a VoIP
> roll-out.

That's may be the key reason for only EF class
implemented in some enterprise networks. But, would
WRED act with EF class traffic ?



  The queueing mechanisms are hardware
> dependent, but on a
> Cisco 6509 Catalyst for example, most modern
> hardware modules come
> with WRED on by default when you turn on 'QoS'. 
> However, since this
> deployment is probably often done within campus
> networks where
> congestion is rare, AQM is probably rarely
> activated.

I'm not sure but to my experience I have to config
packet dropping policy explicity with Cat6509. 

> 
> So... in a nutshell, I feel I had gotten a very weak
> response to this
> question.  Most people just don't seem to care
> enough or have problems
> that really require it to be interested enough in
> RED or related
> mechanisms at this time, but I wasn't convinced it
> was a compromised
> concept.  :-)
> 

IMHO, AQM may be a good tool for 'traditional'
internet environment because there is only 'honest'
TCP applications. In current situation, condition
changes. what I'm not sure is, could AQM be used in
network which need to differentiate e2e service
quality? Could it do much help with those complex
network administration/provisioning problem? 

Jing  



	

	
		
___________________________________________________________ 
ÑÅ»¢Ãâ·ÑGÓÊÏ䣭ÖйúµÚÒ»¾øÎÞÀ¬»øÓʼþɧÈų¬´óÓÊÏä 
http://cn.mail.yahoo.com


From jtk at northwestern.edu  Sun Oct 16 20:53:36 2005
From: jtk at northwestern.edu (John Kristoff)
Date: Sun, 16 Oct 2005 22:53:36 -0500
Subject: [e2e] Is RED dead?
In-Reply-To: <20051017033332.34073.qmail@web15407.mail.cnb.yahoo.com>
References: <20051013192731.EC3C9136C83@aharp.ittns.northwestern.edu>
	<20051017033332.34073.qmail@web15407.mail.cnb.yahoo.com>
Message-ID: <20051017035337.1741E136C82@aharp.ittns.northwestern.edu>

On Mon, 17 Oct 2005 11:33:32 +0800 (CST)
Jing Shen <jshen_cad at yahoo.com.cn> wrote:

> > In my own experience with some Cisco gear, I suspect
> > a fair number of
> > people have WRED on a number of interfaces where
> > they have turned on
> > the QoS knobs for the box, primarily it seems as
> > part of a VoIP
> > roll-out.
> 
> That's may be the key reason for only EF class
> implemented in some enterprise networks. But, would
> WRED act with EF class traffic ?

No.  By default EF traffic will be put in a strict priority queue.
At least on the gear I've seen.  Note, other DiffServ codepoints are
often supported and enabled by default for some applications, such
as video.  However, I bet many if not most organizations are ignoring
those other codepoints or resetting them to best effort (CS-0).

Regardless of whether this is the right approach or not (it wipes out
scavenger, which is may not what you might want to do).

More specifically it seems that EF is supported and set by using a
packet filter to match on what looks like voice traffic (e.g. ef set,
UDP,  ports set to fit [x1-x1,y1-y2], IP src/dst) and everthing else
is remarked best effort if it isn't already.

> I'm not sure but to my experience I have to config
> packet dropping policy explicity with Cat6509. 

In versions I've used, once you set 'mls qos' globally, you get the
default queueing parameters as they are hard wired to the physical
interface (modules).

John

From jshen_cad at yahoo.com.cn  Sun Oct 16 23:32:02 2005
From: jshen_cad at yahoo.com.cn (Jing Shen)
Date: Mon, 17 Oct 2005 14:32:02 +0800 (CST)
Subject: [e2e] Is RED dead?
In-Reply-To: <20051017035337.1741E136C82@aharp.ittns.northwestern.edu>
Message-ID: <20051017063202.4793.qmail@web15410.mail.cnb.yahoo.com>

> > 
> > That's may be the key reason for only EF class
> > implemented in some enterprise networks. But,
> would
> > WRED act with EF class traffic ?
> 
> No.  By default EF traffic will be put in a strict
> priority queue.
> At least on the gear I've seen.  Note, other
> DiffServ codepoints are
> often supported and enabled by default for some
> applications, such
> as video. 

What do you mean by "DSCP are often enabled by default
for some applications, such as  video"?  Would those
routers can recognize  video traffic and set
approprate DSCP to video packets?  Considering a
network carrying IPTV and normal traffic, could that
be possible for each node to allocate/divide bandwidth
to each class on each hop while balancing requirement
between IPTV traffic and normal internet traffic?  


> 
> More specifically it seems that EF is supported and
> set by using a
> packet filter to match on what looks like voice
> traffic (e.g. ef set,
> UDP,  ports set to fit [x1-x1,y1-y2], IP src/dst)
> and everthing else
> is remarked best effort if it isn't already.
> 
> > I'm not sure but to my experience I have to config
> > packet dropping policy explicity with Cat6509. 
> 
> In versions I've used, once you set 'mls qos'
> globally, you get the
> default queueing parameters as they are hard wired
> to the physical
> interface (modules).
> 

do you mean WRED is enabled in those default queueing
parameters? 


Jing




	

	
		
___________________________________________________________ 
ÑÅ»¢Ãâ·ÑGÓÊÏ䣭ÖйúµÚÒ»¾øÎÞÀ¬»øÓʼþɧÈų¬´óÓÊÏä 
http://cn.mail.yahoo.com


From label_label_label_label at yahoo.com  Sun Oct 16 23:56:06 2005
From: label_label_label_label at yahoo.com (Zaphod Beeblebrox)
Date: Sun, 16 Oct 2005 23:56:06 -0700 (PDT)
Subject: [e2e] Header length field in IP header
Message-ID: <20051017065606.6906.qmail@web53712.mail.yahoo.com>

>
> (I just wanted to keep the flow of the argument
going,
> no disrespect meant to anyone)
>
> as an humble observation by an observer from another
> galaxy,
>
> Why don't earthlings do this:
>
>
>              DNS-------DNS----DNS
>               |          |      |
> Endhost1----NAT1-------NAT2---NAT3-----endhost2
>
>
> Since all end hosts will always do a name
resolution,
> we can treat that as a way to setup the path :),
just
> like a TCP handshake :)

unless the source uses destinaiton's IP address
without going through the
name resolution. And if I trust arp caching, I am
always going to get the
same route. Further, this same route may have been
"tore off" by the
intermediate NAT gateways! 


---> 

so treat the nslookup more like "call the remote
end/drop the call"

you could always do something like
a. each host tells big box in the middle that he wants
to talk to some end
big box has a counter per destination call it
counter_using_dest
b. bigbox then checks if he already has a association
for that destination programmed in hardware
(counter_using_dest!=0)
c. if b is true then pop back that ip already given to
the end host and switch the rest in hardware
d. if not put a new entry in hardware
e. increment entry ref count by counter_using_dest++
f. one each host finishes its transaction, it has to
tear down the session.
on tear down counter_using_dest--
g. if counter_using_dest==0, delete entry, and tell
node further up towards destn that i dont need this
entry and so on...

sort of becomes a mixture of merged flows to same
destn, coupled with signalling

if remote end has to talk back, then the
identifier/name of the initiator has to be carried
inside the message of the association so formed, i.e
identify source within the message?

not same as flow switching as flow switching does not
rely on initiating hosts tearing down the
associations... waits for flow timeouts.. dont like
that too much :-(

mew mew?

-ZB

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

From jtk at northwestern.edu  Mon Oct 17 04:52:57 2005
From: jtk at northwestern.edu (John Kristoff)
Date: Mon, 17 Oct 2005 06:52:57 -0500
Subject: [e2e] Is RED dead?
In-Reply-To: <20051017063202.4793.qmail@web15410.mail.cnb.yahoo.com>
References: <20051017035337.1741E136C82@aharp.ittns.northwestern.edu>
	<20051017063202.4793.qmail@web15410.mail.cnb.yahoo.com>
Message-ID: <20051017115257.96C9A136C82@aharp.ittns.northwestern.edu>

On Mon, 17 Oct 2005 14:32:02 +0800 (CST)
Jing Shen <jshen_cad at yahoo.com.cn> wrote:

> What do you mean by "DSCP are often enabled by default
> for some applications, such as  video"?  Would those
> routers can recognize  video traffic and set
> approprate DSCP to video packets?  Considering a

Some applications, particularly ones that do streaming video, set the
DiffServ codepoint to some AFxy value by default.  ...and if you have
QoS knobs turned on in your network gear, like simply 'mls qos' as on
the Cisco platforms as I've seen, you also get some basic handling of
those marked packets also.  In addition to putting EF marked packets
in a priority queue, AFxy marked packets are probably going into a
specific WRED queue and associated with a specific drop threshold.

> network carrying IPTV and normal traffic, could that
> be possible for each node to allocate/divide bandwidth
> to each class on each hop while balancing requirement
> between IPTV traffic and normal internet traffic?  

I'm not exactly sure what you're asking here.  If the question is,
can the routers allocate capacity, queueing behavior or something
else to different classes of traffic based on DiffServ codepoints
found in IPTV traffic versus other best effort traffic, then the
answer is yes.  If that was not your question, then please restate
and I'll try again.

> > In versions I've used, once you set 'mls qos'
> > globally, you get the
> > default queueing parameters as they are hard wired
> > to the physical
> > interface (modules).
> > 
> 
> do you mean WRED is enabled in those default queueing
> parameters? 

Yes if 'mls qos' is set.  For recent native IOS on a 6509 for example,
type:

  'show queueing interface g5/1'

It will tell your current queuing configuration and what queues
marked packets will be put in if QoS is enabled.

John

From falk at ISI.EDU  Mon Oct 17 16:16:21 2005
From: falk at ISI.EDU (Aaron Falk)
Date: Mon, 17 Oct 2005 16:16:21 -0700
Subject: [e2e] Updated XCP version: xcp-nodiv
Message-ID: <C7227692FB13DC8154BFFD8C@nak.isi.edu>

All-

We have completed an update on the XCP end-system and router code resulting 
in a release of xcp-nodiv for FreeBSD-5.3.

The most significant change is that the per-packet router calculations no 
longer include division.  This change is important because performing 
line-rate divisions on production routers is undesirable.  To facilitate 
this change we changed the Throughput header field to carry RTT/Throughput. 
This value may be thought of as an idealized inter-packet time, although we 
just call it 'X'.

The tarball also includes a matching protocol specification, modified 
analysis tools, and scripts for exercising the algorithm.

We continue to develop the algorithm.  Current work addresses identifying 
and responding appropriately to non-XCP queues, sharing bottleneck capacity 
fairly with Reno-style flows, evaluating performance under a variety of 
environments (e.g., intermittent links) and traffic models (e.g., web 
mice), and a network processor implementation.

The tarball, specification (submitted for publication as 
draft-falk-xcp-spec-01.txt), and mailing list information can be found at 
<http://www.isi.edu/isi-xcp>.

--aaron


From jshen_cad at yahoo.com.cn  Mon Oct 17 23:47:09 2005
From: jshen_cad at yahoo.com.cn (Jing Shen)
Date: Tue, 18 Oct 2005 14:47:09 +0800 (CST)
Subject: [e2e] Is RED dead?
In-Reply-To: <20051017115257.96C9A136C82@aharp.ittns.northwestern.edu>
Message-ID: <20051018064709.42726.qmail@web15405.mail.cnb.yahoo.com>

> > network carrying IPTV and normal traffic, could
> that
> > be possible for each node to allocate/divide
> bandwidth
> > to each class on each hop while balancing
> requirement
> > between IPTV traffic and normal internet traffic? 
> 
> 
> I'm not exactly sure what you're asking here.  If
> the question is,
> can the routers allocate capacity, queueing behavior
> or something
> else to different classes of traffic based on
> DiffServ codepoints
> found in IPTV traffic versus other best effort
> traffic, then the
> answer is yes.  If that was not your question, then
> please restate
> and I'll try again.
> 

Because we are not sure how much bandwidth high
priority traffic needs ( number of subscriber may vary
with time), bandwidth allocation policy between
different QoS level has to be ajusted from time to
time. So, there comes a problem,  how to minimize the
cost of network management? 

My question is, could those default queueing policy
adjust bandwidth allocation policy according to real
traffic requirement automatically? if not, how to
control the network management complexity when QoS &
WRED are deployed ? 


thanks 

Jing
 






	

	
		
___________________________________________________________ 
ÑÅ»¢Ãâ·ÑGÓÊÏ䣭ÖйúµÚÒ»¾øÎÞÀ¬»øÓʼþɧÈų¬´óÓÊÏä 
http://cn.mail.yahoo.com


From sampad_m at rediffmail.com  Tue Oct 18 05:44:27 2005
From: sampad_m at rediffmail.com (sampad  mishra)
Date: 18 Oct 2005 12:44:27 -0000
Subject: [e2e] Is RED dead?
Message-ID: <20051018124427.31353.qmail@webmail53.rediffmail.com>

  

Hi all,
       I think RED is not dead, however some kind of inhibitions are restricting the use of it. 
       Currently I'm emulating(using Linux TC) a QOS architecture(based on my prof's paper) which can provide specified minimum throughput for TCP connections with very minimal delay(& delay jitters) for realtime applications. It has no signalling reuirements and employs RED control , WRR schedulers and priority. We can differentiate different levels of traffic from DSCP bits and accordingly set the parameters. With admission control we plan to provide QOS in dynamic traffic conditions. 

       I find RED to be pretty handy as it does a good job . However I have a doubt regarding RED paramter (minimum queue length). Min queue length(as specified) should be big enough to accomodate the bursts however can anyone tell me how does min Q length affect the throughput , if at all it does? Basically, I want to know, apart from accomodating bursts, what other factors should be taken into account while assigning min Q length. 

Kindly enlighten me....

Regards,
sampad mishra.
ECE,IISc.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/end2end-interest/attachments/20051018/4210040f/attachment.html

From sampad_m at rediffmail.com  Tue Oct 18 05:50:27 2005
From: sampad_m at rediffmail.com (sampad  mishra)
Date: 18 Oct 2005 12:50:27 -0000
Subject: [e2e] Is RED dead?
Message-ID: <20051018125027.20599.qmail@webmail31.rediffmail.com>

  

Hi all,
       I think RED is not dead, however some kind of inhibitions are restricting the use of it. 
       Currently I'm emulating(using Linux TC) a QOS architecture(based on my prof's paper) which can provide specified minimum throughput for TCP connections with very minimal delay(& delay jitters) for realtime applications. It has no signalling reuirements and employs RED control , WRR schedulers and priority. We can differentiate different levels of traffic from DSCP bits and accordingly set the parameters. With admission control we plan to provide QOS in dynamic traffic conditions. 

       I find RED to be pretty handy as it does a good job . However I have a doubt regarding RED paramter (minimum queue length). Min queue length(as specified) should be big enough to accomodate the bursts however can anyone tell me how does min Q length affect the throughput , if at all it does? Basically, I want to know, apart from accomodating bursts, what other factors should be taken into account while assigning min Q length. 

Kindly enlighten me....

Regards,
sampad mishra.
ECE,IISc.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/end2end-interest/attachments/20051018/9743c76a/attachment.html

From sampad_m at rediffmail.com  Tue Oct 18 05:51:19 2005
From: sampad_m at rediffmail.com (sampad  mishra)
Date: 18 Oct 2005 12:51:19 -0000
Subject: [e2e] Is RED dead?
Message-ID: <20051018125119.23584.qmail@webmail31.rediffmail.com>

  

Hi all,
       I think RED is not dead, however some kind of inhibitions are restricting the use of it. 
       Currently I'm emulating(using Linux TC) a QOS architecture(based on my prof's paper) which can provide specified minimum throughput for TCP connections with very minimal delay(& delay jitters) for realtime applications. It has no signalling reuirements and employs RED control , WRR schedulers and priority. We can differentiate different levels of traffic from DSCP bits and accordingly set the parameters. With admission control we plan to provide QOS in dynamic traffic conditions. 

       I find RED to be pretty handy as it does a good job . However I have a doubt regarding RED paramter (minimum queue length). Min queue length(as specified) should be big enough to accomodate the bursts however can anyone tell me how does min Q length affect the throughput , if at all it does? Basically, I want to know, apart from accomodating bursts, what other factors should be taken into account while assigning min Q length. 

Kindly enlighten me....

Regards,
sampad mishra.
ECE,IISc.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/end2end-interest/attachments/20051018/8135bd05/attachment.html

From sampad_m at rediffmail.com  Tue Oct 18 06:04:50 2005
From: sampad_m at rediffmail.com (sampad  mishra)
Date: 18 Oct 2005 13:04:50 -0000
Subject: [e2e] Is RED dead?
Message-ID: <20051018130450.22567.qmail@webmail6.rediffmail.com>

Hi all,
       I think RED is not dead, however some kind of inhibitions are restricting the use of it. 
       Currently I'm emulating(using Linux TC) a QOS architecture(based on my prof's paper) which can provide specified minimum throughput for TCP connections with very minimal delay(& delay jitters) for realtime applications. It has no signalling reuirements and employs RED control , WRR schedulers and priority. We can differentiate different levels of traffic from DSCP bits and accordingly set the parameters. With admission control we plan to provide QOS in dynamic traffic conditions. 

       I find RED to be pretty handy as it does a good job . However I have a doubt regarding RED paramter (minimum queue length). Min queue length(as specified) should be big enough to accomodate the bursts however can anyone tell me how does min Q length affect the throughput , if at all it does? Basically, I want to know, apart from accomodating bursts, what other factors should be taken into account while assigning min Q length. 

Kindly enlighten me....

Regards,
sampad mishra.
ECE,IISc.
  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/end2end-interest/attachments/20051018/f5f48747/attachment.html

From jtk at northwestern.edu  Tue Oct 18 07:54:37 2005
From: jtk at northwestern.edu (John Kristoff)
Date: Tue, 18 Oct 2005 09:54:37 -0500
Subject: [e2e] Is RED dead?
In-Reply-To: <20051018064709.42726.qmail@web15405.mail.cnb.yahoo.com>
References: <20051017115257.96C9A136C82@aharp.ittns.northwestern.edu>
	<20051018064709.42726.qmail@web15405.mail.cnb.yahoo.com>
Message-ID: <20051018145437.D0AF8136C82@aharp.ittns.northwestern.edu>

On Tue, 18 Oct 2005 14:47:09 +0800 (CST)
Jing Shen <jshen_cad at yahoo.com.cn> wrote:

> Because we are not sure how much bandwidth high
> priority traffic needs ( number of subscriber may vary
> with time), bandwidth allocation policy between
> different QoS level has to be ajusted from time to
> time. So, there comes a problem,  how to minimize the
> cost of network management? 

This is a good question.  If you could trust all the endpoints to
mark correctly it wouldn't be a problem, but you can't.  Ultimately
they could mark a link full of DoS traffic as EF so you need some
type of ingress function to sanitize what the network gets.  The
simplest approach is to rate limit a traffic profile (based on a
simple packet filter), but this is problematic for at least two
reasons.  One, if the filter is too broad, the host can make all
traffic look like the profile and get it into the EF queues.  Two,
what is the rate at which you set the limit?

There is a whole class of work on dynamically setting the rate
based on available capacity and some type of authorization scheme,
but none of these have been practical in networks I've worked on
and no operators I know are very interested in deploying such
schemes.

Also note I didn't mention re-marking excess traffic that fits the
EF profile.  While at first thought this may seem like a good
approach, it can be harmful to real EF traffic.  If you need these
queueing mechanisms to be activated during congestion, a traffic
flow where some packets fall in a different queue may result in
re-ordering or unacceptable jitter for that application.

> My question is, could those default queueing policy
> adjust bandwidth allocation policy according to real
> traffic requirement automatically? if not, how to
> control the network management complexity when QoS &
> WRED are deployed ? 

You could do that and I'm sure there are plenty of papers describing
how to do so.  Your second question is more relevant to me though.
I don't think you can really deploy too much of this stuff today and
get much value out of it.  You can do some simple things like RED and
EF queues for a very strict traffic profile, but even there as we're
seeing, very few seem to have much motivation to bother doing so.
At the heart of it is, the problem these knobs solve is a problem most
people don't seem to be having, or at least one not painful enough to
justify deployment over some other, presumably simpler, solution.

John

From sampad_m at rediffmail.com  Tue Oct 18 10:30:33 2005
From: sampad_m at rediffmail.com (sampad  mishra)
Date: 18 Oct 2005 17:30:33 -0000
Subject: [e2e] Is RED dead?
Message-ID: <20051018173033.32109.qmail@webmail30.rediffmail.com>


Sorry for sending multiple copies. It was accidental.
Hope u guys won't mind.

Regards,
sampad mishra.
ECE,IISc.  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/end2end-interest/attachments/20051018/9cc42d8b/attachment-0001.html

From jshen_cad at yahoo.com.cn  Wed Oct 19 00:08:32 2005
From: jshen_cad at yahoo.com.cn (Jing Shen)
Date: Wed, 19 Oct 2005 15:08:32 +0800 (CST)
Subject: [e2e] Is RED dead?
In-Reply-To: <20051018145437.D0AF8136C82@aharp.ittns.northwestern.edu>
Message-ID: <20051019070832.7596.qmail@web15404.mail.cnb.yahoo.com>

> at least two
> reasons.  One, if the filter is too broad, the host
> can make all
> traffic look like the profile and get it into the EF
> queues.  Two,
> what is the rate at which you set the limit?
> 

This comes back to a very old question, Is those QoS
mechanism developed enough for internet? or Could we
implement  QoS control in Internet which is built up
with end-to-end traffic control, stateless
transmission ?  

Less and less research work on Qos  is published,
while ISPs are trying hard to differentiated their
service among their customers.        

> At the heart of it is, the problem these knobs solve
> is a problem most
> people don't seem to be having, or at least one not
> painful enough to
> justify deployment over some other, presumably
> simpler, solution.
> 

So, WRED has more value in 'research' area than
internet?  

Jing




	

	
		
___________________________________________________________ 
ÑÅ»¢Ãâ·ÑGÓÊÏ䣭ÖйúµÚÒ»¾øÎÞÀ¬»øÓʼþɧÈų¬´óÓÊÏä 
http://cn.mail.yahoo.com


From yschoi at gmail.com  Wed Oct 19 23:25:04 2005
From: yschoi at gmail.com (cys)
Date: Thu, 20 Oct 2005 15:25:04 +0900
Subject: [e2e] Question about managing window(rfc1122, 4.2.2.16)
Message-ID: <5a8ce9ca0510192325y690864cfj8b061673464bd9b3@mail.gmail.com>

Hi.

While I'm implementing ELFN in ns simulator, I got some questions.

I searched some RFC and "tcp/ip illustrated" but I do not have a clue yet.


***TCP/IP vol.2, pp.857***
cancel any rtx timer
snd_nxt<-snd_una
enter the persist state.
probing
when receiver opens its window, start retransmitting form the left of
the window.
******

>RFC1122
>However, a sending TCP MUST be robust against window shrinking, which
may >cause the "useable window" (see Section 4.2.3.4) to become
negative.


>If this happens, the sender SHOULD NOT send new data,
What is the "new data"?? data beyond SND.UNA+SND.WND?
When does sender start transmit new data?

>but SHOULD retransmit normally the old unacknowledged data
>between SND.UNA and SND.UNA+SND.WND.
>The sender MAY also retransmit old data beyond SND.UNA+SND.WND, but
>SHOULD NOT time out the connection if data beyond the right window
edge
>is not acknowledged. If the window shrinks to zero, the TCP
>MUST probe it in the standard way (see next Section).

Does above cluase mean that TCP can transmit data "before" probing or
going to persist mode??

If it is(transmit some pkts before probing), how it can be possible?
SND.WND is already 0, isn't it?

If it It isn't, what is the old unacknowledged data?
TCP already set SND.NXT to SND.UNA. And I think TCP can't distinguish it.

--
cys

From francesco at net.infocom.uniroma1.it  Thu Oct 20 04:25:12 2005
From: francesco at net.infocom.uniroma1.it (Francesco Vacirca)
Date: Thu, 20 Oct 2005 13:25:12 +0200
Subject: [e2e] Spurious Timeouts in mobile wireless networks,
 was: Re:  Retransmission Timouts revisited
In-Reply-To: <431C2B55.5050505@net.infocom.uniroma1.it>
References: <430E1862.23935C68@web.de>	<4316EE5F.7060203@web.de>	<431708EE.8070807@net.infocom.uniroma1.it>	<43185BD7.2090402@inescporto.pt>	<4318759F.7010906@net.infocom.uniroma1.it>	<431893EC.4080608@web.de>	<431898D2.4070707@inescporto.pt>
	<431C2B55.5050505@net.infocom.uniroma1.it>
Message-ID: <43577E98.6020303@net.infocom.uniroma1.it>

Maybe you are interested in this technical report:
TCP Spurious Timeout estimation in an operational GPRS/UMTS network

http://userver.ftw.at/~ziegler/FTW-TR-2005-008.pdf

We deployed an algorithm to estimate spurious timeout retransmissions by 
passive monitoring that it is based on similar assumptions of F-RTO and 
reported the results on several day traces. The report is based on 
measurements made in the UMTS and GPRS networks of Mobilkom Austria, EU.

regards,

Francesco


Francesco Vacirca wrote:
> 
> 
> Filipe Abrantes wrote:
> 
>>
>>
>> Detlef Bosau wrote:
>>
>>> Francesco Vacirca wrote:
>>>
>>>> I'm agree with that... what I'm trying to say is that L2 
>>>> retransmissions are due to transmission errors on the wireless 
>>>> channel... and with all kind of ARQ protocols (from Stop'n Wait to 
>>>> Selective Repeat) if you drop packet K (because one or more PDUs 
>>>> belonging to that TCP-SDU reached the max number of retransmissions 
>>>> N), that implies that if packet K+1 crosses the wireless channel it 
>>>> will arrive after the moment that K would arrived with some more 
>>>> retransmissions... and this implies that if 
>>>
>>>
>>>
>>>
>>>
>>>
>>> I admit: I cannot follow.
>>>
>>> Packet K is lost. Packet K+1 not. What?s the problem?
>>>
>>> And what do you mean with "K+1 .... will arrive after the moment K 
>>> would arrived with...."?
>>>
>>> K did not arrive.
>>>
>>> So K?s arrivale time in case of ... does not matter.
>>>
>>
>> Hmmmm, some misunderstanding here i beleive: packet K and K+1 arrive 
>> at destination, (K is the seqno of TCP), however packet K has to be 
>> retransmitted in some wireless hop in the path, due to transmission 
>> errors. What Francesco was saying (if i understood it correctly) is 
>> that this restransmission will lead to an increase of the rtt which 
>> will be noted by the sender both in packet K and packet K+1 because 
>> packet K+1 goes imediatly after packet K. So if packet K time's out, 
>> then packet K+1 will also timeout. Francesco claimed that this would 
>> have some effect on the spurious timeout detection which i didn't 
>> quite understood, but im also not that familiar with rto estimation 
>> procedures.
>>
> 
> My point is a little bit different... I know I'm not good in explain 
> that... I'll try again:
> 
> One important point:
> -usually there is just one timer for on-flight TCP packets
> 
> Two different situations:
> 1) finite number of retransmissions
> 2) infinite number of retransmissions (or very high)
> 
> in case 1) if packet K is dropped because it is reached the maximum 
> number of retransmission attempts, K+1 can arrive:
> 
> A) before RTO expiration... and K is probably retransmitted with fast 
> retransmit
> B) after RTO expiration... and K is retransmitted because of RTO expiration
> 
> in case 2) with the same channel condition of 1A, K will arrive before 
> RTO expiration... no retransmissions
> in case 2) with the same channel condition of 1B, K will arrive after 
> RTO expiration... and K is retransmitted because of RTO expiration 
> (Spurious retransmission)
> 
>  From a TCP point of view, I think that 2) is always better than 1)
> 
> 
> regards,
> 
> f.

From vern at ee.lbl.gov  Mon Oct 17 23:41:26 2005
From: vern at ee.lbl.gov (vern@ee.lbl.gov)
Date: Mon, 17 Oct 2005 23:41:26 -0700
Subject: [e2e] public release of anonymized enterprise traces
Message-ID: <200510180641.j9I6fQ7G047377@jaguar.icir.org>

[apologies for multiple copies]

We'd like to announce the public release of a set of anonymized packet
header traces recorded inside a medium-sized enterprise, the Lawrence
Berkeley National Laboratory.  Information about the traces, including
a link to downloading them, is available at

	http://www.icir.org/enterprise-tracing/

and two associated papers, one analyzing the traces and the other discussing
the anonymization process, are available at:

	http://www.icir.org/enterprise-tracing/papers.html

This work was supported in part by the DHS-sponsored PREDICT trace repository,

	https://www.predict.org/

- Vern, on behalf of

Mark Allman (ICSI)
Mike Bennett (LBNL)
Jason Lee (LBNL)
Ruoming Pang (Princeton)
Vern Paxson (ICSI/LBNL)
Brian Tierney (LBNL)

From Robin.Braun at uts.edu.au  Wed Oct 19 16:59:39 2005
From: Robin.Braun at uts.edu.au (Robin Braun)
Date: Thu, 20 Oct 2005 09:59:39 +1000
Subject: [e2e] IWAN 2005 - Call for Attendance - November 21-23 2005
Message-ID: <20051019235933.B027C6F61B@gimli.eng.uts.edu.au>


        --------------------------------------------------------
        --                I W A N    2 0 0 5                  --
        -- Seventh Annual International Working Conference on --
        --         Active and Programmable Networks           --
        --               November 21-23 2005                  --
        --          Sophia Antipolis, Nice, FRANCE            --
        --                                                    --
        --                  Co-organized by :                 --
        --         INRIA (RESO Team) and HITACHI Europe       --
        --                                                    --
        --              http://www.iwan2005.net               --
        --                                                    --
        --------------------------------------------------------

                           Call For Attendance

Please accept our invitation to attend IWAN 2005. This year we have a
very high quality program that can be viewed at our website. The 
workshop is to be held in the beautiful south of France. You can
find other information their on travel and accomodation. 

Active and programmable networking has, over the past several years,
laid the foundations of providing easy, but robust, introduction of
new network services to devices such as routers and switches by adding
dynamic programmability to network equipment. Network programmability
and service deployment architectures can bring the right services to the
customer at the right time and location. The methods and technologies
explored in active and programmable networking research have helped
to realise the trend towards ad-hoc networks, autonomic computing and
communications, sensor networks and content-aware distribution. Also,
active and programmable networks will continue to play an important role
in future network architectures where the Quality of Service aspects
of performance, security and resilience are crucial.

Organizing Committee:

  * General Chair: David Hutchison, Lancaster University, UK
  * Program Comittee Chairs: Spyros Denazis, Hitachi Europe, France /
    Univ. Patras, Greece - Laurent Lefevre, INRIA, France -
    Gary J. Minden, The University of Kansas, USA
  * Publication Chair: Alessandro Bassi, Hitachi, France
  * Publicity Chair: Jean-Patrick Gelas, INRIA, France -
    Robin Braun, University of Technology of Sydney, Australia
  * Tutorial Chair : Mikhail Smirnov, Fraunhofer FOKUS, Germany
  * Local Arrangements committee : Beatrice Dessus, Hitachi Europe,
    France -  Daniele Herzog, INRIA, France
  * Local Technical Support : Jean-Christophe Mignot, LIP,
    Ecole Normale Superieure de Lyon, France

IWAN 2005 is co-organized by : INRIA (RESO Team) and HITACHI Europe
 
 
Robin M. Braun, Professor of Telecommunications 
University of Technology, Sydney
Ultimo, NSW Australia
Robin.Braun at uts.edu.au or www.eng.uts.edu.au/~robinb  
Voice: +61 2 9514 2460. Fax: +61 2 9514 2435 Mobile/Txt: +61 400 220 251
 


-- 
UTS CRICOS Provider Code:  00099F
DISCLAIMER: This email message and any accompanying attachments may contain
confidential information.  If you are not the intended recipient, do not
read, use, disseminate, distribute or copy this message or attachments.  If
you have received this message in error, please notify the sender 
immediately and delete this message. Any views expressed in this message 
are those of the individual sender, except where the sender expressly, and 
with authority, states them to be the views the University of Technology, 
Sydney. Before opening any attachments, please check them for viruses and 
defects.

From falk at ISI.EDU  Fri Oct 21 14:02:35 2005
From: falk at ISI.EDU (Aaron Falk)
Date: Fri, 21 Oct 2005 14:02:35 -0700
Subject: [e2e] not quite the differentiated services I was thinking of
Message-ID: <C7B444A1134C1EE3CDAF5E57@nak.isi.edu>

Phone, Cable Firms Rein In Consumers' Internet Use
Big Operators See Threat To Service as Web Calls,
Videos Clog Up Networks

By PETER GRANT and JESSE DRUCKER
Staff Reporters of THE WALL STREET JOURNAL
October 21, 2005; Page A1

Several large telephone and cable companies are starting to make it harder 
for consumers to use the Internet for phone calls or swapping video files.

Some of the companies say the users are hogging bandwidth, taking up too 
much space on networks and slowing down service for all customers that tap 
the Internet for email, video, music, phone and other services.

Wireless phone companies like Verizon Wireless and Vodafone Group PLC 
stipulate in their subscription contracts that customers can't use the 
company's high-speed Web-access networks for Internet calling -- or may 
prohibit usage in the future. Several cable companies are using technology 
to cap the speed at which some of their customers can swap videos. A number 
of equipment companies are selling software and other products designed to 
block and monitor Internet applications such as phone calls, video and 
photo downloads.

Many telephone and cable companies have begun to closely monitor the uses 
of their network with an eye toward controlling activity by users who are 
swapping movies, TV programs, pornography and other video files. Operators 
say file sharing is growing so quickly, it threatens to sharply slow down 
other uses.
[Bandwidth Surge]

In August alone, one cable broadband subscriber consumed a total of 1.5 
terabytes, the equivalent of 1,500 standard-definition movies, according to 
CableLabs, the cable industry's research and development arm. Fewer than 
10% of the subscribers of Time Warner Inc.'s cable unit consume more than 
75% of its bandwidth, says Mike Lajoie, chief technology officer of Time 
Warner Cable. "It can be frustrating for people using email or sending 
pictures to their moms," he says. "It tends to slow down the rest of the 
network."

Critics say the big operators are using their concerns about heavy network 
traffic to fight competition from smaller rivals that are using the phone 
and cable companies' networks, like Internet calling companies Skype 
Technologies SA or Vonage Holdings Corp. Others say that telecom companies 
may use their control over the networks to charge users more money if they 
want higher quality.

"They claim it's a network-management issue when it's really a 
revenue-maximization issue," says Mark Cooper, research director for the 
Consumer Federation of America.

The battle features big companies with multibillion-dollar telephone, cable 
and cellular networks into homes and tiny competitors who don't own any 
network but whose low-cost or free services compete with those of the big 
operators. Consumers could get caught in the squeeze.

The crackdown is controversial: Consumers have come to expect unfettered 
use of the Internet. Any effort by phone or cable companies to curtail use 
so far has sparked an outcry.

Kevin Martin, chairman of the Federal Communications Commission, has said 
that market forces would prevent operators from curtailing applications 
that run on their networks, but he also says the FCC is looking into 
guidelines to protect consumers on this issue. Earlier this year, telecom 
provider Madison River Communications stopped blocking Vonage's service 
after the FCC intervened.

While there aren't yet specific laws to enforce so-called net neutrality, 
an FCC spokesman said the commission relied on its broad authority "to 
ensure an efficient communications network at reasonable charges" in its 
action on Madison River earlier this year. He declined to comment on 
Verizon Wireless's contract language prohibiting Internet calling. "It 
would involve looking at the facts of the situation." Verizon Wireless is a 
joint venture between Verizon Communications Inc. and Vodafone.

The big operators' efforts at Internet traffic control reflect, in part, 
the skyrocketing use of video files and other bandwidth-intensive 
applications by the tens of millions of households with high-speed Internet 
connections. Video file sharing can use up more than 20 times as many bits 
as other Internet applications, such as making a phone call.

One kind of video-file-sharing software alone, called BitTorrent, accounted 
for 18% of Internet traffic on U.S. cable operators' networks this year, 
according to a recent CableLabs survey. "These applications, run unchecked, 
could consume all of the bandwidth available in the network," says Ralph 
Brown, CableLabs' chief technology officer.

The increasing attention being placed on broadband traffic control promises 
to be a boon for network-gear businesses like Ellacoya Networks Inc., 
Sandvine Inc. and P-Cube, which was acquired by Cisco Systems Inc. last 
year for $200 million. Some of these companies have developed a technology 
called "deep packet inspection" that enables network operators to tell 
whether bits on their network are email, videos, music, photos or any other 
use.

The use of such policing technologies by big operators is also driven by 
the popularity of competing Internet-calling services like those of Skype 
and Vonage. Those companies offer customers the ability to make free or 
cheap calls using their high-speed Internet connection without paying a 
telephone company for traditional voice service. Last month, Skype, which 
has 55 million registered users world-wide, was acquired by eBay Inc. for 
$2.6 billion.

Verso Technologies Inc. last month launched its "Skype Filtering 
Technology," marketing it to carriers seeking to block the use of Skype and 
other such services. "I can guarantee you that if a service provider has 
the ability to prioritize their voice traffic over Skype traffic, they'll 
do theirs," a Verso executive said.

Verizon Wireless's BroadbandAccess enables customers to use its cellular 
network for high-speed Internet access. But the service explicitly 
prohibits subscribers from using it for Internet calling because "we don't 
want people clogging up the network," says spokesman Jim Gerace. The 
carrier launched the service in two markets in 2003, but has only recently 
begun heavily marketing the offering, cutting prices by 25%.

Mr. Gerace adds that Verizon Wireless has to bear the cost of any 
dissatisfaction with an Internet-calling provider. "We offer a wireless 
connection. When it doesn't work well, who do they call? They don't call 
Skype; they call us," he said.

A Vodafone spokesman said the company's contract language, which applies 
only to its customers in Germany, was included as "a legal reservation" for 
potential future action. He said the carrier isn't blocking Internet 
calling and accepts that such a service is a competitor.

Time Warner Cable is considering several ways of controlling the traffic on 
its network, Mr. Lajoie says. The operator might simply give video 
file-sharing traffic a lower priority than other traffic so that it slows 
down first during periods of peak usage. Or it might restrict the flow of 
bits to a particular user's computer if the usage is too heavy. Time Warner 
Cable may also charge heavy users more if they want preferred treatment. 
"Revenue opportunities...definitely exist," Mr. Lajoie says.

Phone companies also may take such steps for their land-line broadband 
networks. Verizon Communications, for example, has put tools in place for 
monitoring the network, and managing it if necessary, says spokesman Eric 
Rabe. "We don't feel at this point [video file sharing] has caused the kind 
of problem that would force us to take extraordinary measures," he says. 
"But we're prepared to deal with it if we need to."

Telecom companies overseas have been more aggressive than those in the U.S. 
in controlling their networks. Verso says that interest in its service so 
far has come primarily from overseas carriers, since deploying such a 
technology here in the U.S. would be highly controversial. The only carrier 
it would name is Britain's Cable & Wireless PLC, which it says is 
interested in deploying the technology in its Caribbean markets. Cable & 
Wireless didn't respond to requests for comment.

Shaw Communications Inc., a large Canadian cable operator, has been using 
technology purchased from Ellacoya to manage its broadband network for 
about one year, says Shaw's president, Peter Bissonnette.

During some periods of peak usage, video file-sharing traffic is slowed to 
provide more bandwidth for subscribers accessing email, Web pages and other 
uses. "We try to manage those people who are avariciously using up 
spectrum," he says.

Shaw also uses the network management technology to increase revenue. For 
example, customers who use Vonage or another Internet phone service can pay 
an additional $9.95 a month to make sure that their calls get higher 
priority on the network than some other uses.

Businesses that sell services that piggy-back on cable and phone networks 
have been watching efforts by operators to control traffic with alarm. "To 
use a broadband connection for any legal application is critical to 
ensuring the vitality of the Internet," says Brooke Schulz, a Vonage 
spokeswoman.

Ashwin Navin, chief operating officer of BitTorrent, said he is "very 
disappointed" that operators are taking steps to slow down video 
file-sharing traffic. He says that he's mostly hearing about it happening 
in markets served by only one operator, depriving disgruntled consumers of 
a choice.

Write to Peter Grant at peter.grant at wsj.com1 and Jesse Drucker at 
jesse.drucker at wsj.com2
  	URL for this article:
http://online.wsj.com/article/SB112985651806475197.html

From nichols at pollere.com  Fri Oct 21 13:13:57 2005
From: nichols at pollere.com (Kathleen Nichols)
Date: Fri, 21 Oct 2005 13:13:57 -0700
Subject: [e2e] not quite the differentiated services I was thinking of
In-Reply-To: <C7B444A1134C1EE3CDAF5E57@nak.isi.edu>
References: <C7B444A1134C1EE3CDAF5E57@nak.isi.edu>
Message-ID: <43594C05.6050906@pollere.com>


Though, as a user, this may not be what you want, no one
should be surprised that differentiated services as a
way of *controlling* network usage is important to operators.
I believe this was brought up as far back as the fdiffs BoF
Brian Carpenter organized and I know the cable data company
I worked for 10 years ago was interested in providing its customers,
the operators, with that kind of control over subscriber use
(though it was through the MAC layer).

There was a lot of discussion in the diffserv WG about differentiation
that limited users, Yoram Bernet brought it up as a needed service
for enterprises (for much the reasons in the article) as did Klaus
Wehrle and Roland Bless, who proposed a lower effort PHB. Brian
Carpenter and I felt this was a PDB function not a PHB function
and sketched this as a "Bulk Handling" PDB which got combined with Klaus
and Roland's work into RFC3662 for a "Lower Effort PDB".

So the notion of using differentiated services to control the
network has been around for a while. Seems pretty reasonable
to me that a network operator ought to be able to choose who
gets better service and who gets worse service based on whatever
is important (often $$$ commercially).

	Kathie

From davidopp at gmail.com  Sat Oct 22 09:31:05 2005
From: davidopp at gmail.com (David Oppenheimer)
Date: Sat, 22 Oct 2005 09:31:05 -0700
Subject: [e2e] not quite the differentiated services I was thinking of
In-Reply-To: <43594C05.6050906@pollere.com>
References: <C7B444A1134C1EE3CDAF5E57@nak.isi.edu>
	<43594C05.6050906@pollere.com>
Message-ID: <e041bec0510220931k74cecd8cvc1d2deff0ce79ba0@mail.gmail.com>

> Though, as a user, this may not be what you want, no one
> should be surprised that differentiated services as a
> way of *controlling* network usage is important to operators.
[...]
> Seems pretty reasonable
> to me that a network operator ought to be able to choose who
> gets better service and who gets worse service based on whatever
> is important (often $$$ commercially).

Rather than setting priorities on a per-application basis, I think the
more reasonable approach is to simply sell users SLAs and allow them
to use what they're buying however they wish. There are all kinds of
pricing schemes that can prevent users from "hogging the network,"
while remaining application-agnostic.

The network operators seem somehow surprised that when they sell users
(say) a 3 Mb/s network connection, some users actually use 3 Mb/s for
more than just bursts. It sounds like the companies need to align
their sales and marketing departments with the actual capacity of
their networks, rather than making value judgments about what
applications are more deserving of bandwidth than others.

David

From rishisin at usc.edu  Sun Oct 23 18:48:58 2005
From: rishisin at usc.edu (Rishi Sinha)
Date: Sun, 23 Oct 2005 18:48:58 -0700 (PDT)
Subject: [e2e] Internet packet size distribution
Message-ID: <Pine.GSO.4.33.0510231846350.22025-100000@aludra.usc.edu>

We were recently looking at packet size distributions in Internet traffic
and observed some shifts in packet sizes compared to common wisdom. We
want to ask end2end if other folks have seen similar things, and if anyone
has alternatives to the reasons we suggest for the causes of this shift.
Details are in the note below, and with graphs at the web page
<http://netweb.usc.edu/~rsinha/pkt-sizes>.

We observed two suprising things. First, current packet sizes seem mostly
bimodal at 40B and 1500B (at 40% and 20% of packets, respectively). This
observation represents a change from common wisdom such as the pre-2000
data that reports tri-modal packet sizes around 40, 576, and 1500B.

Second, in some cases we observe a strong mode around 1300B. This
represents a new phenomenon.

The first observation holds across all observations at five different
network points, including Los Nettos (our regional ISP, carrying a mix of
academic and commercial traffic), a USC Internet2 connection, and three
connections monitored by NLANR. The second observation does not hold
universally, but is very strong at Los Nettos and USC Internet2, and is
noticeable in all traces.

The shift away from 576B packets is not suprising, since it is consistent
with evolution of OSes and widespread use of Ethernet with a 1500B MTU.

The growth at 1300B packets (seen at Los Nettos and the USC Internet2
link) was suprising to us. We have tentatively identified 1300B packets as
stemming from widespread use of VPN software, and possibly from
recommendations from DSL providers.

We traced the recommendations for 1300B MTU to several sources. For
example VPN MTU recommendations, see our web page.

Our observations do not point to wide use of end-to-end VPN over WANs, but
to VPN use at the edge network, since the 1300B size noted is presumably
that of packets that have exited a VPN tunnel. This edge-network use is
certainly true at USC, where most wireless traffic traverses a VPN over
the wireless hop and then proceeds unencrypted over the rest of the
Internet. This behavior explains why Los Nettos and USC Internet2 traffic
shows the strongest 1300B modes of the sites we observe.

Regards,

Rishi Sinha
Christos Papadopoulos
John Heidemann


From anoop.ghanwani at hp.com  Mon Oct 24 11:05:25 2005
From: anoop.ghanwani at hp.com (Ghanwani, Anoop)
Date: Mon, 24 Oct 2005 11:05:25 -0700
Subject: [e2e] Internet packet size distribution
Message-ID: <83AB0942FD087D499DF2DD5CEE1B61330288340B@cacexc06.americas.cpqcorp.net>

 
> We traced the recommendations for 1300B MTU to several sources. For
> example VPN MTU recommendations, see our web page.

Could this be because of IPv6 traffic being tunneled in IPv4?
IPv6 requires that the link layer support an MTU of at least
1280 bytes.  Add 20 bytes for an IPv4 tunnel header and you
get 1300 bytes.

Anoop

From tatsuya at nttlabs.com  Wed Oct 26 03:14:40 2005
From: tatsuya at nttlabs.com (Tatsuya MORI)
Date: Wed, 26 Oct 2005 19:14:40 +0900 (JST)
Subject: [e2e] Internet packet size distribution
In-Reply-To: <83AB0942FD087D499DF2DD5CEE1B61330288340B@cacexc06.americas.cpqcorp.net>
References: <83AB0942FD087D499DF2DD5CEE1B61330288340B@cacexc06.americas.cpqcorp.net>
Message-ID: <20051026.191440.74751147.tatsuya@nttlabs.com>


> > We traced the recommendations for 1300B MTU to several sources. For
> > example VPN MTU recommendations, see our web page.
> 
> Could this be because of IPv6 traffic being tunneled in IPv4?
> IPv6 requires that the link layer support an MTU of at least
> 1280 bytes.  Add 20 bytes for an IPv4 tunnel header and you
> get 1300 bytes.

The statistics of several IPv6 links have been collected by the
researchers from MAWI WG, WIDE project.  
We can see the jump at 1300B. 

http://tracer.csl.sony.co.jp/mawi/
http://tracer.csl.sony.co.jp/mawi/samplepoint-C/2000/200010250900.html
http://tracer.csl.sony.co.jp/mawi/samplepoint-C/2001/200110250900.html
http://tracer.csl.sony.co.jp/mawi/samplepoint-C/2002/200210250900.html
http://tracer.csl.sony.co.jp/mawi/samplepoint-C/2003/200310250900.html
http://tracer.csl.sony.co.jp/mawi/samplepoint-C/2004/200410250900.html
http://tracer.csl.sony.co.jp/mawi/samplepoint-C/2005/200510250900.html

Best regards,

-- Tatsuya

From tatsuya at nttlabs.com  Wed Oct 26 05:10:56 2005
From: tatsuya at nttlabs.com (Tatsuya MORI)
Date: Wed, 26 Oct 2005 21:10:56 +0900 (JST)
Subject: [e2e] Internet packet size distribution
In-Reply-To: <20051026.191440.74751147.tatsuya@nttlabs.com>
References: <83AB0942FD087D499DF2DD5CEE1B61330288340B@cacexc06.americas.cpqcorp.net>
	<20051026.191440.74751147.tatsuya@nttlabs.com>
Message-ID: <20051026.211056.74750092.tatsuya@nttlabs.com>


> > > We traced the recommendations for 1300B MTU to several sources. For
> > > example VPN MTU recommendations, see our web page.
> > 
> > Could this be because of IPv6 traffic being tunneled in IPv4?
> > IPv6 requires that the link layer support an MTU of at least
> > 1280 bytes.  Add 20 bytes for an IPv4 tunnel header and you
> > get 1300 bytes.
> 
> The statistics of several IPv6 links have been collected by the
> researchers from MAWI WG, WIDE project.  
> We can see the jump at 1300B. 

It seems that the jumps measured on the v6 links are at 1280B of IP
packet length; although I don't know whether they are related to the
1300B measured on the v4 links (v6 over v4 tunneling?).

Here is an example obtained from the following v6 packet trace.
> http://tracer.csl.sony.co.jp/mawi/samplepoint-C/2005/200510250900.html

length  count
72      524317
60      410304
1500    236794
104     100459
64      72420
68      25436
94      23686
91      21196
81      20000
84      18906
80      17938
79      14239
108     14210
78      14140
141     13001
1280    12623 <--
89      12011
148     11987
...<snip>...

Best regards,
 
-- Tatsuya

From johnh at ISI.EDU  Wed Oct 26 11:10:53 2005
From: johnh at ISI.EDU (John Heidemann)
Date: Wed, 26 Oct 2005 11:10:53 -0700
Subject: [e2e] Internet packet size distribution
In-Reply-To: <83AB0942FD087D499DF2DD5CEE1B61330288340B@cacexc06.americas.cpqcorp.net>
Message-ID: <200510261810.j9QIArDR022101@dash.isi.edu>

On Mon, 24 Oct 2005 11:05:25 PDT, "Ghanwani, Anoop" wrote: 
> 
>> We traced the recommendations for 1300B MTU to several sources. For
>> example VPN MTU recommendations, see our web page.
>
>Could this be because of IPv6 traffic being tunneled in IPv4?
>IPv6 requires that the link layer support an MTU of at least
>1280 bytes.  Add 20 bytes for an IPv4 tunnel header and you
>get 1300 bytes.

Good point.

My assumption is that VPN'ed traffic is much, much more common than
tunneled IPv6 (particularly at USC where all wireless was VPNed until
recently), but it would be good to validate that assumption.

   -John

From rishisin at usc.edu  Wed Oct 26 12:55:46 2005
From: rishisin at usc.edu (Rishi Sinha)
Date: Wed, 26 Oct 2005 12:55:46 -0700 (PDT)
Subject: [e2e] Internet packet size distribution
In-Reply-To: <200510261810.j9QIArDR022101@dash.isi.edu>
Message-ID: <Pine.GSO.4.33.0510261234450.24084-100000@aludra.usc.edu>

On Wed, 26 Oct 2005, John Heidemann wrote:
> On Mon, 24 Oct 2005 11:05:25 PDT, "Ghanwani, Anoop" wrote:
> >Could this be because of IPv6 traffic being tunneled in IPv4?
> >IPv6 requires that the link layer support an MTU of at least
> >1280 bytes.  Add 20 bytes for an IPv4 tunnel header and you
> >get 1300 bytes.
>
> Good point.
>
> My assumption is that VPN'ed traffic is much, much more common than
> tunneled IPv6 (particularly at USC where all wireless was VPNed until
> recently), but it would be good to validate that assumption.

None of the 1300B packets seen in our Los Nettos and USC Internet2 traces
seem to be tunneled IPv6. The protocol field is almost always 6 (TCP)  or
17 (UDP). It's never 41 (IPv6).

Rishi.


From touch at ISI.EDU  Wed Oct 26 13:14:41 2005
From: touch at ISI.EDU (Joe Touch)
Date: Wed, 26 Oct 2005 13:14:41 -0700
Subject: [e2e] Internet packet size distribution
In-Reply-To: <200510261810.j9QIArDR022101@dash.isi.edu>
References: <200510261810.j9QIArDR022101@dash.isi.edu>
Message-ID: <435FE3B1.7030801@isi.edu>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



John Heidemann wrote:
> On Mon, 24 Oct 2005 11:05:25 PDT, "Ghanwani, Anoop" wrote: 
> 
>>>We traced the recommendations for 1300B MTU to several sources. For
>>>example VPN MTU recommendations, see our web page.
>>
>>Could this be because of IPv6 traffic being tunneled in IPv4?
>>IPv6 requires that the link layer support an MTU of at least
>>1280 bytes.  Add 20 bytes for an IPv4 tunnel header and you
>>get 1300 bytes.
> 
> Good point.
> 
> My assumption is that VPN'ed traffic is much, much more common than
> tunneled IPv6 (particularly at USC where all wireless was VPNed until
> recently), but it would be good to validate that assumption.
> 
>    -John

It can be difficult to find such traffic, since it isn't always on
protocol 50 (ESP) or 4 (IP-IP tunnel); the totals for those are under
1%, as per CAIDA's traces from around 2002.

The rest shows up hidden inside UDP or even TCP, esp. to traverse
firewalls or NA(P)Ts, and cannot as easily be measured.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDX+OxE5f5cImnZrsRAt0VAKDU4mSFQiUxXTkD//oDp3bFjxn0NQCeITWN
hFG5PxDbungO0EbdkcDAkHM=
=UDib
-----END PGP SIGNATURE-----

From ljorgenson at apparentnetworks.com  Wed Oct 26 22:07:39 2005
From: ljorgenson at apparentnetworks.com (Loki Jorgenson)
Date: Wed, 26 Oct 2005 22:07:39 -0700
Subject: [e2e] Internet packet size distribution - is Cisco VPN
Message-ID: <F09324DCDD2F5D488EAC603D6B299DC7012830C4@jsrvr8.jaalam.net>

FYI - in our experience, 1300 bytes is one of several default values
associated with Cisco VPNs.

Loki Jorgenson
e   ljorgenson at ApparentNetworks.com
t   604 433 2333 ext 105
f   604 433 2311
m   604 250-4642
w   www.ApparentNetworks.com

Message: 3
Date: Wed, 26 Oct 2005 11:10:53 -0700
From: John Heidemann <johnh at ISI.EDU>
Subject: Re: [e2e] Internet packet size distribution
To: "Ghanwani, Anoop" <anoop.ghanwani at hp.com>
Cc: Rishi Sinha <rishisin at usc.edu>, end2end-interest at postel.org
Message-ID: <200510261810.j9QIArDR022101 at dash.isi.edu>
Content-Type: text/plain; charset=US-ASCII

On Mon, 24 Oct 2005 11:05:25 PDT, "Ghanwani, Anoop" wrote: 
> 
>> We traced the recommendations for 1300B MTU to several sources. For
>> example VPN MTU recommendations, see our web page.
>
>Could this be because of IPv6 traffic being tunneled in IPv4?
>IPv6 requires that the link layer support an MTU of at least
>1280 bytes.  Add 20 bytes for an IPv4 tunnel header and you
>get 1300 bytes.

Good point.

My assumption is that VPN'ed traffic is much, much more common than
tunneled IPv6 (particularly at USC where all wireless was VPNed until
recently), but it would be good to validate that assumption.

   -John

From craig at aland.bbn.com  Thu Oct 27 13:23:48 2005
From: craig at aland.bbn.com (Craig Partridge)
Date: Thu, 27 Oct 2005 16:23:48 -0400
Subject: [e2e] number of flows per unit time in routers
Message-ID: <20051027202348.55CE81FF@aland.bbn.com>


Hi folks:

I've spent this afternoon reading through the literature on flows and
can't seem to find anything that tries to characterize how many flows
actually pass through a router per second or minute or hour.

I carefully say "a router" as I'd be interested in the statistics regardless
of where the router is located.

Thanks!

Craig

E-mail: craig at aland.bbn.com or craig at bbn.com

From dga+ at cs.cmu.edu  Thu Oct 27 15:15:04 2005
From: dga+ at cs.cmu.edu (David Andersen)
Date: Thu, 27 Oct 2005 18:15:04 -0400
Subject: [e2e] number of flows per unit time in routers
In-Reply-To: <20051027202348.55CE81FF@aland.bbn.com>
References: <20051027202348.55CE81FF@aland.bbn.com>
Message-ID: <F77FE010-A4E9-4686-B1D9-3E74BB6D6025@cs.cmu.edu>

Dina Katabi's Hotnets work last year that looked at "flowlets"  
included some graphs of the number of active flows (for some  
definition of active) at routers.  This may or may not have what you  
want -- I'm pretty certain it didn't have long-term flow stats, but  
perhaps it would be a useful starting point.  I'd dig more into it,  
but I'm email-only at the moment.

   -Dave

On Oct 27, 2005, at 4:23 PM, Craig Partridge wrote:

>
> Hi folks:
>
> I've spent this afternoon reading through the literature on flows and
> can't seem to find anything that tries to characterize how many flows
> actually pass through a router per second or minute or hour.
>
> I carefully say "a router" as I'd be interested in the statistics  
> regardless
> of where the router is located.
>
> Thanks!
>
> Craig
>
> E-mail: craig at aland.bbn.com or craig at bbn.com
>
>


From xie at ict.ac.cn  Thu Oct 27 18:46:16 2005
From: xie at ict.ac.cn (Xie)
Date: Fri, 28 Oct 2005 09:46:16 +0800
Subject: [e2e] number of flows per unit time in routers
References: <20051027202348.55CE81FF@aland.bbn.com>
	<F77FE010-A4E9-4686-B1D9-3E74BB6D6025@cs.cmu.edu>
Message-ID: <00cb01c5db61$62a88890$4d27e29f@ictxie>

Hi Craig,

We have got some flows metrics on an aggregative link of a carrier's MAN with NetTurbo which is a network monitoring system developed by ourselves.  If these data are useful for you, we will send more data to you including rate of flows new-adding, rate of flows close, workload of flows.  

Cheers,
Xie
----- Original Message ----- 
From: "David Andersen" <dga+ at cs.cmu.edu>
To: "Craig Partridge" <craig at aland.bbn.com>
Cc: <end2end-interest at postel.org>
Sent: Friday, October 28, 2005 6:15 AM
Subject: Re: [e2e] number of flows per unit time in routers


> Dina Katabi's Hotnets work last year that looked at "flowlets"  
> included some graphs of the number of active flows (for some  
> definition of active) at routers.  This may or may not have what you  
> want -- I'm pretty certain it didn't have long-term flow stats, but  
> perhaps it would be a useful starting point.  I'd dig more into it,  
> but I'm email-only at the moment.
> 
>    -Dave
> 
> On Oct 27, 2005, at 4:23 PM, Craig Partridge wrote:
> 
> >
> > Hi folks:
> >
> > I've spent this afternoon reading through the literature on flows and
> > can't seem to find anything that tries to characterize how many flows
> > actually pass through a router per second or minute or hour.
> >
> > I carefully say "a router" as I'd be interested in the statistics  
> > regardless
> > of where the router is located.
> >
> > Thanks!
> >
> > Craig
> >
> > E-mail: craig at aland.bbn.com or craig at bbn.com
> >
> >
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/end2end-interest/attachments/20051028/670a6199/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flow rate.jpg
Type: image/jpeg
Size: 120374 bytes
Desc: not available
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20051028/670a6199/flowrate-0001.jpg

From tvpoh at essex.ac.uk  Fri Oct 28 12:56:33 2005
From: tvpoh at essex.ac.uk (Tze-Ven Poh)
Date: Fri, 28 Oct 2005 12:56:33 -0700
Subject: [e2e] number of flows per unit time in routers
References: <20051027202348.55CE81FF@aland.bbn.com>
Message-ID: <00a901c5dbf9$b2755220$a273f59b@essex.ac.uk>

Hello Craig,

You may want to check out this site:
http://pma.nlanr.net/Traces/long/ipls1.html

See here for example:
http://pma.nlanr.net/Traces/long/ipls1/IPLS-CLEV-20020814-090000.html

Look for Active Connections graph.


----- Original Message -----
From: "Craig Partridge" <craig at aland.bbn.com>
To: <end2end-interest at postel.org>
Sent: Thursday, October 27, 2005 1:23 PM
Subject: [e2e] number of flows per unit time in routers


>
> Hi folks:
>
> I've spent this afternoon reading through the literature on flows and
> can't seem to find anything that tries to characterize how many flows
> actually pass through a router per second or minute or hour.
>
> I carefully say "a router" as I'd be interested in the statistics
regardless
> of where the router is located.
>
> Thanks!
>
> Craig
>
> E-mail: craig at aland.bbn.com or craig at bbn.com


From ijs at iitis.gliwice.pl  Thu Oct 27 21:25:27 2005
From: ijs at iitis.gliwice.pl (Irek Szczesniak)
Date: Thu, 27 Oct 2005 21:25:27 -0700
Subject: [e2e] number of flows per unit time in routers
In-Reply-To: <20051027202348.55CE81FF@aland.bbn.com>
References: <20051027202348.55CE81FF@aland.bbn.com>
Message-ID: <4361A837.1060904@iitis.gliwice.pl>

 > I've spent this afternoon reading through the literature on flows
 > and can't seem to find anything that tries to characterize how many
 > flows actually pass through a router per second or minute or hour.

I was looking for something similar: the number of TCP flows that pass
thought a single wavelength in a backbone network.

So far I only found that a 40Gb/s router can handle tens of millions
of flows.  Here is the article:

http://www.lightreading.com/document.asp?doc_id=63606


HTH & best,
Irek

From braden at ISI.EDU  Fri Oct 28 10:12:09 2005
From: braden at ISI.EDU (Bob Braden)
Date: Fri, 28 Oct 2005 10:12:09 -0700 (PDT)
Subject: [e2e] number of flows per unit time in routers
Message-ID: <200510281712.KAA11769@gra.isi.edu>


It seems to me that this question is ill-posed.  It seems to make
sense to talk about the number of flows per time T only when average
flow duration << T.  So, flows per hour might make since, assuming
few flows are longer than a few minutes, but flows per second makes
no sense.

Bob Braden

From yganjali at stanford.edu  Fri Oct 28 10:34:01 2005
From: yganjali at stanford.edu (Yashar Ganjali)
Date: Fri, 28 Oct 2005 10:34:01 -0700
Subject: [e2e] number of flows per unit time in routers
In-Reply-To: <200510281712.KAA11769@gra.isi.edu>
References: <200510281712.KAA11769@gra.isi.edu>
Message-ID: <43626109.2020006@stanford.edu>

Another way of looking at this is to count the number of flows which are 
active before and after a certain point in time. This way, we don't need 
to have a large time interval T. I consider this a better definition, 
since it does not depend on an arbitrarily chosen time T.

--Yashar

Bob Braden wrote:

>It seems to me that this question is ill-posed.  It seems to make
>sense to talk about the number of flows per time T only when average
>flow duration << T.  So, flows per hour might make since, assuming
>few flows are longer than a few minutes, but flows per second makes
>no sense.
>
>Bob Braden
>  
>

-- 
---------------------------------------------------
Yashar Ganjali        Email: yganjali at stanford.edu
PhD Candidate    http://www.stanford.edu/~yganjali
Computer Systems Lab.           Home: 510-526-4662
Stanford University             Work: 650-723-1414
---------------------------------------------------


From craig at aland.bbn.com  Fri Oct 28 10:41:12 2005
From: craig at aland.bbn.com (Craig Partridge)
Date: Fri, 28 Oct 2005 13:41:12 -0400
Subject: [e2e] number of flows per unit time in routers
In-Reply-To: Your message of "Fri, 28 Oct 2005 10:12:09 PDT."
	<200510281712.KAA11769@gra.isi.edu> 
Message-ID: <20051028174112.6CB8A1FF@aland.bbn.com>


Hi Bob:

Sounds as if I need to provide a bit of context.  If you are tracking
flows (imagine a router keeping track of flows, using, say something like
NetFlow), one question is how many flows do I need to keep track of.
Another question is how fast may I have to create new flows or expire
old flows.  Yet another question, and the one I was aiming at, is that
if I'm archiving flow records over time, at what rate do I have to
archive?

Note that for all but the first question, flows per second makes perfect
sense.

Thanks!

Craig

In message <200510281712.KAA11769 at gra.isi.edu>, Bob Braden writes:

>
>It seems to me that this question is ill-posed.  It seems to make
>sense to talk about the number of flows per time T only when average
>flow duration << T.  So, flows per hour might make since, assuming
>few flows are longer than a few minutes, but flows per second makes
>no sense.
>
>Bob Braden

From braden at ISI.EDU  Fri Oct 28 10:40:57 2005
From: braden at ISI.EDU (Bob Braden)
Date: Fri, 28 Oct 2005 10:40:57 -0700 (PDT)
Subject: [e2e] number of flows per unit time in routers
Message-ID: <200510281740.KAA11837@gra.isi.edu>


  *> 
  *> Another way of looking at this is to count the number of flows which are 
  *> active before and after a certain point in time.

Do you mean, the number N(T) of flows with duration > T?  Yes, that
distribution function makes sense.

Bob Braden


From braden at ISI.EDU  Fri Oct 28 10:53:47 2005
From: braden at ISI.EDU (Bob Braden)
Date: Fri, 28 Oct 2005 10:53:47 -0700 (PDT)
Subject: [e2e] number of flows per unit time in routers
Message-ID: <200510281753.KAA11864@gra.isi.edu>



Craig,

I agree with your more precise statements of the problem.  The original
statement was incomplete, I believe.

Bob

From ramana at cs.ucsd.edu  Fri Oct 28 11:42:12 2005
From: ramana at cs.ucsd.edu (Ramana Rao Kompella)
Date: Fri, 28 Oct 2005 11:42:12 -0700
Subject: [e2e] number of flows per unit time in routers
In-Reply-To: <20051028174112.6CB8A1FF@aland.bbn.com>
References: <20051028174112.6CB8A1FF@aland.bbn.com>
Message-ID: <43627104.5010603@cs.ucsd.edu>

Craig,

It is entirely dependent on the traffic mix. If you are faced with 
adversarial
traffic, the number of records is going to be too high. But most if it 
is going to
be junk (such as small one packet flows for DoS traffic).

You might want to take a look at our recent IMC 2005 paper titled
"Power of Slicing in Internet Flow Measurement" along with
Cristi Estan.

We propose an algorithm for reducing bottlenecks  including
storage/reporting bandwidth depending on the traffic mix. We also
propose mechanisms to preserve the accuracy  of various estimates by
choosing the right flow records to archive.

Of course, if the line rate is low ( < OC 12), NetFlow without sampling
might be alright, but you still run into adverarial traffic mixes that can
overwhelm the archival process.

Not sure if that answers your question directly, but just something that
you might require as a future step.

-Ramana

Craig Partridge wrote:

>Hi Bob:
>
>Sounds as if I need to provide a bit of context.  If you are tracking
>flows (imagine a router keeping track of flows, using, say something like
>NetFlow), one question is how many flows do I need to keep track of.
>Another question is how fast may I have to create new flows or expire
>old flows.  Yet another question, and the one I was aiming at, is that
>if I'm archiving flow records over time, at what rate do I have to
>archive?
>
>Note that for all but the first question, flows per second makes perfect
>sense.
>
>Thanks!
>
>Craig
>
>In message <200510281712.KAA11769 at gra.isi.edu>, Bob Braden writes:
>
>  
>
>>It seems to me that this question is ill-posed.  It seems to make
>>sense to talk about the number of flows per time T only when average
>>flow duration << T.  So, flows per hour might make since, assuming
>>few flows are longer than a few minutes, but flows per second makes
>>no sense.
>>
>>Bob Braden
>>    
>>


From detlef.bosau at web.de  Fri Oct 28 13:42:19 2005
From: detlef.bosau at web.de (Detlef Bosau)
Date: Fri, 28 Oct 2005 22:42:19 +0200
Subject: [e2e] number of flows per unit time in routers
References: <20051027202348.55CE81FF@aland.bbn.com>
Message-ID: <43628D2B.23550FBA@web.de>

Craig Partridge wrote:
> 
> Hi folks:
> 
> I've spent this afternoon reading through the literature on flows and
> can't seem to find anything that tries to characterize how many flows
> actually pass through a router per second or minute or hour.

It?s perhaps more or less covered by the other comments, but I?m
particularly curious about the duration of the individual flows.

Some folks are mainly interested in long termed flows, which IMHO hardly
reflect reality. There are quite a few papers around characterizing the
length of a flow. With respect to congestion control this means, that
each time a new flow enters a path the system is about to settle.
Sometimes, I read that
the vast majority of flows does not even contain twenty TCP datagrams.
When I think of this in terms of delack, rounds etc. these flows are
hardly
to see more than, say, three "rounds" where all settling must take
place.

So, for a path with mainly short termed flows I expect a different
behaviour compared to a path with mainly long termed flows.

I think, this question is even important for the LRD guys.

Of course, everyone wants long termed flows, preferable everlasting
ones, because these are so nice to deal with :-)

Detlef

BTW: Now you see one reason for my mostly terrible long mails :-) It?s a
contribution to a well behaved Internet consisting of mainly long termed
flows :-)

-- 
Detlef Bosau
Galileistrasse 30
70565 Stuttgart
Mail: detlef.bosau at web.de
Web: http://www.detlef-bosau.de
Mobile: +49 172 681 9937

From pingpan at cs.columbia.edu  Fri Oct 28 14:40:12 2005
From: pingpan at cs.columbia.edu (Ping Pan)
Date: Fri, 28 Oct 2005 14:40:12 -0700
Subject: [e2e] number of flows per unit time in routers
In-Reply-To: <00a901c5dbf9$b2755220$a273f59b@essex.ac.uk>
References: <20051027202348.55CE81FF@aland.bbn.com>
	<00a901c5dbf9$b2755220$a273f59b@essex.ac.uk>
Message-ID: <43629ABC.3060106@cs.columbia.edu>

Hi,

This is very interesting. Other than backbone links, does anyone have 
data on campus and carrier edge links? Have some flow duration 
information would be nice too.

Counting flows in the backbone is interesting, but the flows are mainly 
processed at edge. So it would be nice to see something in that region.

Thanks!

- Ping


Tze-Ven Poh wrote:
> Hello Craig,
> 
> You may want to check out this site:
> http://pma.nlanr.net/Traces/long/ipls1.html
> 
> See here for example:
> http://pma.nlanr.net/Traces/long/ipls1/IPLS-CLEV-20020814-090000.html
> 
> Look for Active Connections graph.
> 
> 
> ----- Original Message -----
> From: "Craig Partridge" <craig at aland.bbn.com>
> To: <end2end-interest at postel.org>
> Sent: Thursday, October 27, 2005 1:23 PM
> Subject: [e2e] number of flows per unit time in routers
> 
> 
> 
>>Hi folks:
>>
>>I've spent this afternoon reading through the literature on flows and
>>can't seem to find anything that tries to characterize how many flows
>>actually pass through a router per second or minute or hour.
>>
>>I carefully say "a router" as I'd be interested in the statistics
> 
> regardless
> 
>>of where the router is located.
>>
>>Thanks!
>>
>>Craig
>>
>>E-mail: craig at aland.bbn.com or craig at bbn.com
> 
> 

From braden at ISI.EDU  Fri Oct 28 14:44:22 2005
From: braden at ISI.EDU (Bob Braden)
Date: Fri, 28 Oct 2005 14:44:22 -0700 (PDT)
Subject: [e2e] number of flows per unit time in routers
Message-ID: <200510282144.OAA12259@gra.isi.edu>


 

  *> 
  *> Of course, everyone wants long termed flows, preferable everlasting
  *> ones, because these are so nice to deal with :-)
  *> 

Au contraire, connectionless networks could not care less about the
length of a flow.  It's just packets.

Bob Braden


From garmitage at swin.edu.au  Fri Oct 28 17:16:56 2005
From: garmitage at swin.edu.au (grenville armitage)
Date: Sat, 29 Oct 2005 10:16:56 +1000
Subject: [e2e] number of flows per unit time in routers
In-Reply-To: <200510282144.OAA12259@gra.isi.edu>
References: <200510282144.OAA12259@gra.isi.edu>
Message-ID: <4362BF78.1070908@swin.edu.au>

Bob Braden wrote:
	[..] 
>   *> Of course, everyone wants long termed flows, preferable everlasting
>   *> ones, because these are so nice to deal with :-)
>   *> 
> 
> Au contraire, connectionless networks could not care less about the
> length of a flow.  It's just packets.

It seems there are increasing numbers of places in today's internet where devices
do not immediately deallocate state associated with forwarding a packet once the
packet's passed through. One could argue the internet's not really 'connectionless'
in the purest sense anymore. packets is flushed.

cheers,
gja


From garmitage at swin.edu.au  Fri Oct 28 17:19:14 2005
From: garmitage at swin.edu.au (grenville armitage)
Date: Sat, 29 Oct 2005 10:19:14 +1000
Subject: [e2e] number of flows per unit time in routers
In-Reply-To: <4362BF78.1070908@swin.edu.au>
References: <200510282144.OAA12259@gra.isi.edu> <4362BF78.1070908@swin.edu.au>
Message-ID: <4362C002.2020503@swin.edu.au>

grenville armitage wrote:
	[..]
> in the purest sense anymore. packets is flushed.

even my emails keep state. the words "packets is flushed" should be
ignored in my previous post :)

cheers,
gja

From anoop.ghanwani at hp.com  Fri Oct 28 17:44:01 2005
From: anoop.ghanwani at hp.com (Ghanwani, Anoop)
Date: Fri, 28 Oct 2005 17:44:01 -0700
Subject: [e2e] number of flows per unit time in routers
Message-ID: <83AB0942FD087D499DF2DD5CEE1B6133028DBD11@cacexc06.americas.cpqcorp.net>


I have a very basic question -

Is there industry consensus on what constitutes a flow?
Theoretically, it could be some arbitrary bit mask being
applied to every packet.  However, in practice people talk
about TCP flows, UDP flows, ICMP flows, etc.  Just wondering
if there is a comprehensive list of these anywhere.

Thanks,
Anoop 

> -----Original Message-----
> From: end2end-interest-bounces at postel.org 
> [mailto:end2end-interest-bounces at postel.org] On Behalf Of 
> Craig Partridge
> Sent: Friday, October 28, 2005 10:41 AM
> To: Bob Braden
> Cc: end2end-interest at postel.org
> Subject: Re: [e2e] number of flows per unit time in routers
> 
> 
> Hi Bob:
> 
> Sounds as if I need to provide a bit of context.  If you are tracking
> flows (imagine a router keeping track of flows, using, say 
> something like
> NetFlow), one question is how many flows do I need to keep track of.
> Another question is how fast may I have to create new flows or expire
> old flows.  Yet another question, and the one I was aiming at, is that
> if I'm archiving flow records over time, at what rate do I have to
> archive?
> 
> Note that for all but the first question, flows per second 
> makes perfect
> sense.
> 
> Thanks!
> 
> Craig
> 
> In message <200510281712.KAA11769 at gra.isi.edu>, Bob Braden writes:
> 
> >
> >It seems to me that this question is ill-posed.  It seems to make
> >sense to talk about the number of flows per time T only when average
> >flow duration << T.  So, flows per hour might make since, assuming
> >few flows are longer than a few minutes, but flows per second makes
> >no sense.
> >
> >Bob Braden
> 

From sommerfeld at sun.com  Fri Oct 28 20:06:34 2005
From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Fri, 28 Oct 2005 23:06:34 -0400
Subject: [e2e] number of flows per unit time in routers
In-Reply-To: <4362BF78.1070908@swin.edu.au>
References: <200510282144.OAA12259@gra.isi.edu> <4362BF78.1070908@swin.edu.au>
Message-ID: <1130555194.26214.89.camel@localhost>

On Fri, 2005-10-28 at 20:16, grenville armitage wrote: 
> It seems there are increasing numbers of places in today's internet where devices
> do not immediately deallocate state associated with forwarding a packet once the
> packet's passed through. One could argue the internet's not really 'connectionless'
> in the purest sense anymore. 

one could also use that line of argument to say that any device with an
arp cache isn't connectionless.

I think the key distinction here is between a true cache (arp, flow
cache, etc.) where any entry can be discarded at any time, and
unrecoverable state (such as what you find in the middle of a NAT, an
application-layer gateway, or a stateful firewall).

						- Bill



From fred at cisco.com  Sat Oct 29 02:13:46 2005
From: fred at cisco.com (Fred Baker)
Date: Sat, 29 Oct 2005 05:13:46 -0400
Subject: [e2e] number of flows per unit time in routers
In-Reply-To: <20051028174112.6CB8A1FF@aland.bbn.com>
References: <20051028174112.6CB8A1FF@aland.bbn.com>
Message-ID: <BA7F1F9B-C824-4CCE-8536-59A50333A917@cisco.com>

The problem is that a flow is not an event, and when we talk about "X  
per second", X is usually an event. So it sounds like it would make  
more sense to talk about flow creations (installations of a flow data  
record, whatever the implementation calls it, in the netflow  
database) per second, flow expirations per second, or some such, and  
btw, some statistic reporting typical flow duration. Of course, on  
average over a longish interval one hopes that flows created per  
second equals flow expirations per second, but on a shorter period  
the rates will be skewed, with the number of flow records  
simultaneously open alternately increasing for a while and then  
decreasing for a while.

In our experience, the flow creation rate is predicted by the number  
of packets per second crossing an interface and is modified by the  
characteristics of the current definition of a "flow". Under  
configuration control, the network manager can store data about IP  
prefix pairs, IP address pairs, IP address pairs using the TCP  
protocol, IP address pairs establishing individual TCP sessions  
between them, etc etc etc. If you think about the dynamics of a web  
page, opening a web page may mean that your machine starts accessing  
files on a number of machines, usually mostly at the target site but  
not necessarily the same machine. Clicking on a link can result in  
the creation of a single IP prefix pair netflow entry, a few IP  
address pair netflow entries, or a series of TCP-session-between-IP- 
address-pair netflow entries. Therefore, the changing definition of a  
flow can easily change the flow creation rate by an order of  
magnitude. But if you know the average number of packets in a flow  
(if you know, for example, that web tcp sessions are typically 10  
packets each way and that is what you're tracking in netflow), then  
the flow creation rate is proportional to the packet rate on the  
interface.

Flow duration, btw, is generally proportional to the number of RTTs  
necessary to support the flow. Speaking in round numbers, a mumble  
packet web tcp session has an RTT for SYN/SYN-ACK, a second RTT for  
the request packet burst, a third RTT for the first response packet  
burst, potentially several more RTTs for more data, and then finally  
an RTT for the closing exchange. So flow duration is not proportional  
to line speed, but rather is proportional to some function of  
exchange (file) size and RTT.




On Oct 28, 2005, at 1:41 PM, Craig Partridge wrote:

>
> Hi Bob:
>
> Sounds as if I need to provide a bit of context.  If you are tracking
> flows (imagine a router keeping track of flows, using, say  
> something like
> NetFlow), one question is how many flows do I need to keep track of.
> Another question is how fast may I have to create new flows or expire
> old flows.  Yet another question, and the one I was aiming at, is that
> if I'm archiving flow records over time, at what rate do I have to
> archive?
>
> Note that for all but the first question, flows per second makes  
> perfect
> sense.
>
> Thanks!
>
> Craig
>
> In message <200510281712.KAA11769 at gra.isi.edu>, Bob Braden writes:
>
>
>>
>> It seems to me that this question is ill-posed.  It seems to make
>> sense to talk about the number of flows per time T only when average
>> flow duration << T.  So, flows per hour might make since, assuming
>> few flows are longer than a few minutes, but flows per second makes
>> no sense.
>>
>> Bob Braden
>

--------------------------------------------------------------
"Don't worry about the world coming to an end today. It's already  
tomorrow in Australia." (Charles Schulz )


From detlef.bosau at web.de  Sat Oct 29 08:17:07 2005
From: detlef.bosau at web.de (Detlef Bosau)
Date: Sat, 29 Oct 2005 17:17:07 +0200
Subject: [e2e] number of flows per unit time in routers
References: <20051027202348.55CE81FF@aland.bbn.com>
	<00a901c5dbf9$b2755220$a273f59b@essex.ac.uk>
	<43629ABC.3060106@cs.columbia.edu>
Message-ID: <43639273.4ACF5FC6@web.de>

Ping Pan wrote:
> 
> Hi,
> 
> This is very interesting. Other than backbone links, does anyone have
> data on campus and carrier edge links? Have some flow duration
> information would be nice too.
> 
> Counting flows in the backbone is interesting, but the flows are mainly
> processed at edge. So it would be nice to see something in that region.
> 

I see the point. However, the problem is that in campus links
statistical methods are perhpas much more difficult to apply than in
backbone links.
In backbone links, I "tend to believe" (my apologies for the word, but
in fact TCP congestion control _has_ some aspects of a religion...) that
statistical abstraction is possible. I don?t believe this in campus
links.

However, from my own experience, on campus networks often routers are
equipped with "sufficient memory", i.e. congestion drop does hardly
occur, and than anything works fine. As long as the queues resulting
from that do not introduce inacceptable latencies, anything is fine.

So, although a study of network behaviour on campus networks may be
interesting, the question is: From what network size on this study
is really helpful and relevant? And in which cases networks are designed
by "feeling", "faith and religion", "well founded private opinions" - or
simply because the local BOFH-instance is big enough and old enough and
ugly enough to design a network and that?s it?

I think, this is an important question. I guess, that backbone traffic
is quite well understood today. Furthermore, I guess traffic
in small networks is not understood because there is nothing to
understand. You don?t need any networking expertise to provide
for a proper Linux installation party. The problem is the area in
between. When networks become that large that they _must_ be understood,
nevertheless
they are still that small that the statistical and asymptotic
abstraction from the Tier 1 Backbone do not hold.

This could be the case for networks with, just as a guess, say 5.000 to
100.000 participants. Just a guess. So, provider links and provider
networks
may be really interesting.

Detlef


-- 
Detlef Bosau
Galileistrasse 30
70565 Stuttgart
Mail: detlef.bosau at web.de
Web: http://www.detlef-bosau.de
Mobile: +49 172 681 9937

From detlef.bosau at web.de  Sat Oct 29 08:27:58 2005
From: detlef.bosau at web.de (Detlef Bosau)
Date: Sat, 29 Oct 2005 17:27:58 +0200
Subject: [e2e] number of flows per unit time in routers
References: <83AB0942FD087D499DF2DD5CEE1B6133028DBD11@cacexc06.americas.cpqcorp.net>
Message-ID: <436394FE.631C4555@web.de>

"Ghanwani, Anoop" wrote:
> 
> I have a very basic question -
> 
> Is there industry consensus on what constitutes a flow?
> Theoretically, it could be some arbitrary bit mask being
> applied to every packet.  However, in practice people talk
> about TCP flows, UDP flows, ICMP flows, etc.  Just wondering
> if there is a comprehensive list of these anywhere.


This may become quite difficult.

When I read Bob?s post, my spontaneous thought was: "what is
connectionless?"

Of course, TCP is connection oriented. What about proprietary UDP based
protocols without a label "I?m a connection!"?
What about secure IP stuff, where you only see a large number of
packets?
What about multicast protocols for Internet radio?

You see just packets. However it?s not always clear what?s _behind_
those packets.

Detlef
-- 
Detlef Bosau
Galileistrasse 30
70565 Stuttgart
Mail: detlef.bosau at web.de
Web: http://www.detlef-bosau.de
Mobile: +49 172 681 9937

From gaylord at dirtcheapemail.com  Sat Oct 29 09:05:56 2005
From: gaylord at dirtcheapemail.com (Clark Gaylord)
Date: Sat, 29 Oct 2005 12:05:56 -0400
Subject: [e2e] number of flows per unit time in routers
In-Reply-To: <BA7F1F9B-C824-4CCE-8536-59A50333A917@cisco.com>
References: <20051028174112.6CB8A1FF@aland.bbn.com>
	<BA7F1F9B-C824-4CCE-8536-59A50333A917@cisco.com>
Message-ID: <43639DE4.6080402@dirtcheapemail.com>

Fred Baker wrote in end2end-interest at postel.org:

> The problem is that a flow is not an event, and when we talk about "X  
> per second", X is usually an event. So it sounds like it would make  
> more sense to talk about flow creations (installations of a flow data  
> record, whatever the implementation calls it, in the netflow  
> database) per second, flow expirations


Yes, "flow instantiation rate" is one of the critical parameters in 
effective network operation and yet is almost entirely overlooked.  If 
we can make buckets that leak bits and packets, why not flows? (*) This 
would be a tremendous benefit -- I have no problem with one of my hosts 
sourcing 1Gbps if that is what is appropriate for the network (**) and 
application, but I certainly do not want 10^9 flows/second coming from 
one host!

In answer to the original question, this is more answerable on a 
per-host-basis than a router interface.  We see 5,000-10,000 
flows/second from our busiest servers on campus at their normal 
high-water mark (campus mail server is the winner for flow-instantiation 
and I've seen it in the 10,000 neighborhood during "normal" operation 
... bear in mind that "normal" includes millions of spam messages per 
day).  For most "servers", high-water is closer to 1,000 and for most 
"clients", you'll sometimes see them get into three digits.  Based on 
this, I'll leave router interface calculation as an exercise to the reader.

Another point: I suspect flows are closer to our classic teletraffic 
models than packets or bytes.  After all, doesn't a flow feel more like 
a phone call to you?  You'll still see longer tails than you'd expect 
from classic models, but I think you can get away with mixures and/or 
periodic regression of tractibles (e.g. Poisson and such).  If we could 
limit flow rate to something reasonable (say 10^6/host instead of the 
10^9-ish that we have now!), these models could suddenly become more 
tractible and we could all sleep better.  The problem I'm having is the 
tractibility of the data gathering and organization! :-)

Of course, we've had flow-limiting hardware before, but now let's try to 
do it a bit more gracefully. ;-)

--ckg

(*) this question is both rhetorical and actual

(**) defined by TCP-fairness is fine ... but in the next breath I'm 
going to want you to ensure that the host is playing by the rules!

From pingpan at cs.columbia.edu  Sat Oct 29 14:01:51 2005
From: pingpan at cs.columbia.edu (Ping Pan)
Date: Sat, 29 Oct 2005 14:01:51 -0700
Subject: [e2e] number of flows per unit time in routers
In-Reply-To: <43639273.4ACF5FC6@web.de>
References: <20051027202348.55CE81FF@aland.bbn.com>		<00a901c5dbf9$b2755220$a273f59b@essex.ac.uk>
	<43629ABC.3060106@cs.columbia.edu> <43639273.4ACF5FC6@web.de>
Message-ID: <4363E33F.1040803@cs.columbia.edu>

Hi,

Thank for the reply.

Here is what I think: in today's Internet, there is little value in 
counting network flows in backbone and local campus networks.

Actually, if you believe in those peerless backbones, the number of 
network flows is the number of MPLS LSP's. If it is DiffServ-aware MPLS, 
the number of flows is probably eight times the number of LSP's.

As you said, there is probably little value in counting flows in campus 
networks if network resource is not an issue.

As the carriers begin to expand toward access (DSL/PON, or over-hyped 
triple play), there is another layer of network emerging between 
backbone and access, aggregation network. This is the place where the 
network nodes need to gather user flows, process them for whatever the 
reason (SLA, accounting, conversion...) and then groom them toward the 
core. As this part of the network starts to evolve, it would be 
interesting to understand:

1. How many "flows" are we dealing here? A flow can be anything that 
worth of deep-packet-inspection from layer-1 to layer-7 (GFP, VLAN, IP 
address, ICMP, TCP, RTP, SIP..)

2. What would be the desirable topology? Meshed? Spoke? How would this 
effect the way we build the routers/switches today? Full line-rate 
routing and switching may not be important in spoke network. As such, 
the cost of the system may come down... big time.

3. To make matter more interesting, what are we going to do with 
multicast? If you believe in all the IPTV talks and trails, what would 
be the user "flow" dynamic with all those IGMP going on?

It sounds like I am trying to bring back the "bad" memory of 
RSVP/IntServ/QoS from the 90's, well... they are not needed in the 
over-provisioned core. ;-) A paper from Sprint research a while back 
had proved that with minor overprovisioning per link, there would be no 
need for QoS in the core. The newly built Comcast IP backbone is all 
over provisioned... What traffic engineering? ;-)

What about the aggregation region? How can people overprovision access 
links except universities with government's money? How can we 
overprovision RAN (radio area network) for wireless traffic? For people 
who want to offer VoIP and VoD from their servers, unless they 
understand the traffic "flows" (or load), how big the "pipe" are they 
going to buy?...

IMHO, unless we have the ability to "count" flows and apply some 
regulation to the traffic, the network will have a tough time to scale.

This is the reason why I was asking the previous question. ;-)

Thanks!

- Ping


Detlef Bosau wrote:
> Ping Pan wrote:
> 
>>Hi,
>>
>>This is very interesting. Other than backbone links, does anyone have
>>data on campus and carrier edge links? Have some flow duration
>>information would be nice too.
>>
>>Counting flows in the backbone is interesting, but the flows are mainly
>>processed at edge. So it would be nice to see something in that region.
>>
> 
> 
> I see the point. However, the problem is that in campus links
> statistical methods are perhpas much more difficult to apply than in
> backbone links.
> In backbone links, I "tend to believe" (my apologies for the word, but
> in fact TCP congestion control _has_ some aspects of a religion...) that
> statistical abstraction is possible. I don?t believe this in campus
> links.
> 
> However, from my own experience, on campus networks often routers are
> equipped with "sufficient memory", i.e. congestion drop does hardly
> occur, and than anything works fine. As long as the queues resulting
> from that do not introduce inacceptable latencies, anything is fine.
> 
> So, although a study of network behaviour on campus networks may be
> interesting, the question is: From what network size on this study
> is really helpful and relevant? And in which cases networks are designed
> by "feeling", "faith and religion", "well founded private opinions" - or
> simply because the local BOFH-instance is big enough and old enough and
> ugly enough to design a network and that?s it?
> 
> I think, this is an important question. I guess, that backbone traffic
> is quite well understood today. Furthermore, I guess traffic
> in small networks is not understood because there is nothing to
> understand. You don?t need any networking expertise to provide
> for a proper Linux installation party. The problem is the area in
> between. When networks become that large that they _must_ be understood,
> nevertheless
> they are still that small that the statistical and asymptotic
> abstraction from the Tier 1 Backbone do not hold.
> 
> This could be the case for networks with, just as a guess, say 5.000 to
> 100.000 participants. Just a guess. So, provider links and provider
> networks
> may be really interesting.
> 
> Detlef
> 
> 

From pingpan at cs.columbia.edu  Sat Oct 29 14:14:31 2005
From: pingpan at cs.columbia.edu (Ping Pan)
Date: Sat, 29 Oct 2005 14:14:31 -0700
Subject: [e2e] number of flows per unit time in routers
In-Reply-To: <83AB0942FD087D499DF2DD5CEE1B6133028DBD11@cacexc06.americas.cpqcorp.net>
References: <83AB0942FD087D499DF2DD5CEE1B6133028DBD11@cacexc06.americas.cpqcorp.net>
Message-ID: <4363E637.2090704@cs.columbia.edu>

IMHO, at network edge, it's more like a bunch of application flows in 
any arbitrary pattern and combination from the user side to aggregate 
into one of the two "flows" toward the core:

(1) IP destination route
(2) MPLS/PWE3 label

Both have gotten deployed already in the core.

- Ping


Ghanwani, Anoop wrote:
> I have a very basic question -
> 
> Is there industry consensus on what constitutes a flow?
> Theoretically, it could be some arbitrary bit mask being
> applied to every packet.  However, in practice people talk
> about TCP flows, UDP flows, ICMP flows, etc.  Just wondering
> if there is a comprehensive list of these anywhere.
> 
> Thanks,
> Anoop 
> 
> 
>>-----Original Message-----
>>From: end2end-interest-bounces at postel.org 
>>[mailto:end2end-interest-bounces at postel.org] On Behalf Of 
>>Craig Partridge
>>Sent: Friday, October 28, 2005 10:41 AM
>>To: Bob Braden
>>Cc: end2end-interest at postel.org
>>Subject: Re: [e2e] number of flows per unit time in routers
>>
>>
>>Hi Bob:
>>
>>Sounds as if I need to provide a bit of context.  If you are tracking
>>flows (imagine a router keeping track of flows, using, say 
>>something like
>>NetFlow), one question is how many flows do I need to keep track of.
>>Another question is how fast may I have to create new flows or expire
>>old flows.  Yet another question, and the one I was aiming at, is that
>>if I'm archiving flow records over time, at what rate do I have to
>>archive?
>>
>>Note that for all but the first question, flows per second 
>>makes perfect
>>sense.
>>
>>Thanks!
>>
>>Craig
>>
>>In message <200510281712.KAA11769 at gra.isi.edu>, Bob Braden writes:
>>
>>
>>>It seems to me that this question is ill-posed.  It seems to make
>>>sense to talk about the number of flows per time T only when average
>>>flow duration << T.  So, flows per hour might make since, assuming
>>>few flows are longer than a few minutes, but flows per second makes
>>>no sense.
>>>
>>>Bob Braden
>>

From jshen_cad at yahoo.com.cn  Sun Oct 30 01:39:39 2005
From: jshen_cad at yahoo.com.cn (Jing Shen)
Date: Sun, 30 Oct 2005 17:39:39 +0800 (CST)
Subject: [e2e] not quite the differentiated services I was thinking of
In-Reply-To: <e041bec0510220931k74cecd8cvc1d2deff0ce79ba0@mail.gmail.com>
Message-ID: <20051030093940.69159.qmail@web15405.mail.cnb.yahoo.com>


> 
> Rather than setting priorities on a per-application
> basis, I think the
> more reasonable approach is to simply sell users
> SLAs and allow them
> to use what they're buying however they wish. There
> are all kinds of
> pricing schemes that can prevent users from "hogging
> the network,"
> while remaining application-agnostic.

The problem is, DiffServ mechanisms ( queueing,
bandwidth allocation ) introduce too much of
difficulties into ISP networks. An simple example, if
we enable traffic classification and multiple queues
in  ISP networks, QoS differentiation shows up only
when congestion happens; DiffServ tries to solve
bandwidth competition under congestion situation, ISP
want to differentiate e2e QoS even when bandwidth is
overprovisioned! 

Somebody may say ISP should make their network
bandwidth utilization level just around the threshhold
of congestion, but that's not applicable no matter in
service planning or in network management.  

As it is stated in the article Folk forwarded, ISPs
tries to management traffic in their network; But, it
should be clear that the ultimate target is to gain
more profit; Skype or those IP telephone provider
escape from the cost of network construction and
management, but they got a large part of market from
Telephone companies who may pay a lot of effort in
broadband network establishment and mainteinance. So,
such traffic should be managed or blocked. To my
understanding , WRED or current DiffServ mechanism
does not fit to such requirement at all.

Jing 


	

	
		
___________________________________________________________ 
ÑÅ»¢Ãâ·ÑGÓÊÏ䣭ÖйúµÚÒ»¾øÎÞÀ¬»øÓʼþɧÈų¬´óÓÊÏä 
http://cn.mail.yahoo.com


From fred at cisco.com  Sun Oct 30 03:12:19 2005
From: fred at cisco.com (Fred Baker)
Date: Sun, 30 Oct 2005 06:12:19 -0500
Subject: [e2e] not quite the differentiated services I was thinking of
In-Reply-To: <20051030093940.69159.qmail@web15405.mail.cnb.yahoo.com>
References: <20051030093940.69159.qmail@web15405.mail.cnb.yahoo.com>
Message-ID: <62CFD4D3-96F2-4E1E-89C4-208B4D1240C9@cisco.com>

so when you go to the store and you're the only one in the store,  
five cashiers are standing around waiting and hoping for the  
opportunity to take your money and there are no delays whatsoever,  
you still want the store to do something special for you?

yes, diffserv only solves a problem when there is a problem to solve.  
When there is no problem to solve, it doesn't solve it.

teh problem is *what*, precisely?

On Oct 30, 2005, at 4:39 AM, Jing Shen wrote:

> An simple example, if
> we enable traffic classification and multiple queues
> in  ISP networks, QoS differentiation shows up only
> when congestion happens;

--------------------------------------------------------------
"Don't worry about the world coming to an end today. It's already  
tomorrow in Australia." (Charles Schulz )


From mfisk at lanl.gov  Fri Oct 28 15:19:08 2005
From: mfisk at lanl.gov (Mike Fisk)
Date: Fri, 28 Oct 2005 16:19:08 -0600
Subject: [e2e] number of flows per unit time in routers
In-Reply-To: <20051028174112.6CB8A1FF@aland.bbn.com>
References: <20051028174112.6CB8A1FF@aland.bbn.com>
Message-ID: <14937c5c388d896d911d90ff715c6f14@lanl.gov>


On Oct 28, 2005, at 11:41 AM, Craig Partridge wrote:

>
> Hi Bob:
>
> Sounds as if I need to provide a bit of context.  If you are tracking
> flows (imagine a router keeping track of flows, using, say something 
> like
> NetFlow), one question is how many flows do I need to keep track of.
> Another question is how fast may I have to create new flows or expire
> old flows.  Yet another question, and the one I was aiming at, is that
> if I'm archiving flow records over time, at what rate do I have to
> archive?

That adds another dimension, because frequently you are capturing flows 
from multiple routers at a single collection point.  For a "large 
campus environment" (including border routers), I capture and archive 
an average of 127 million flows per day with a max of 208 million per 
day.  A quick look (e.g. statistically unsound) during peak local 
activity (not during a DOS attack or anything special) shows as many as 
17,000 flows per second and 95,000 flows per minute.

Mike Fisk
Team Leader, Networked Systems Research, Los Alamos National Lab
See http://public.lanl.gov/mfisk/ for contact information


From jshen_cad at yahoo.com.cn  Sun Oct 30 18:18:14 2005
From: jshen_cad at yahoo.com.cn (Jing Shen)
Date: Mon, 31 Oct 2005 10:18:14 +0800 (CST)
Subject: [e2e] not quite the differentiated services I was thinking of
In-Reply-To: <2EA0C9D5AD898E4C8D3D1E893DB627070394655B@df-chewy-msg.exchange.corp.microsoft.com>
Message-ID: <20051031021814.92609.qmail@web15401.mail.cnb.yahoo.com>

Hi,

> 
> "The problem is, DiffServ mechanisms ( queueing,
> bandwidth allocation ) introduce too much of
> difficulties into ISP networks. An simple example,
> if
> we enable traffic classification and multiple queues
> in  ISP networks, QoS differentiation shows up only
> when congestion happens; DiffServ tries to solve
> bandwidth competition under congestion situation,
> ISP
> want to differentiate e2e QoS even when bandwidth is
> overprovisioned! "
> 
> I have yet to see any compelling evidence for claim
> 1 above once you
> have decided to actually serve the needs of users.  
> It is mantra for
> many, but where is the objective evidence for this
> claim? 

Problem exists with the following aspects:

1) Security 

If network traffic is classified to different QoS
level, CBWFQ is utilized to enable transmission
differentiation. If virus generating high volume of
traffic in priority queue, those low level traffic
will be squeezed to experience congestion. 


2) SLA verification 

How could we verify SLA of a special QoS level in
network ? When multiple end hosts try to verify QoS
service level with pressure test, could that be
considered a security problem?

3) Network planning 

When multiple queues are established to enable
differentiate packet forwarding, queueing mechanism
like WRR will blur the edge of SLAs between
gold/silver/bronze ( so why should someone pay for
high priority service? ), if hard limited queueing is
introduced how could network administrators plan and
adjust bandwidth allocation in an network with more
than 1000 routers, redunant links ? If the cost of
differentiated service is higher that the cost of
service establishment, why should we use it?is there
any ISP which implement DiffServ in its network?

At last, as those have been published some ISPs manage
traffic with special equipment, but to my limited
knowledge it's not with DiffServ(
classifying+tagging+transmiting ) but with traffic
management product like Packeteer's traffic shaper. 


>  Perhaps it
> has been repeated so often that it is now considered
> proved by emphatic
> assertion.  I have also yet to see any other
> mechanisms that when FULLY
> implemented doesn't haul in most of the Diffserv
> mechanisms (or their
> analogues, and thus their "complexity").

I take that a game between service differentiation
requirement and cost of implementation. ISPs want to
differentiate service between customers at individual
cutomer's application level,   diffserv tries to
tradeoff between scalablity and complexity , but it's
not the situation that simple assumption could
fullfill the requirement of commerical market. 
    



 
> In terms of the example: Diffserv, it can be more
> than happy to punt or
> delay packets in light of lightly congested
> networks.   
> 
> A shamein the whole Diffserv travelogue is that we
> have not adequately
> separated out the discussions of signaling, policies
> and operations so
> that the Internet might end up with a single
> signaling protocol with the
> ability to implement multiple policies (e.g.
> bandwidth, access - FW/NAT,
> security, etc.) to support different mechanism, not
> all of which have to
> do with BW/QoS/etc.

 That's another point current QoS mechanism is not
enough but ATM like QoS is too much and too complex.

So, is there any way to introduce more intellegence
into IP network?

Regards

Jing



	

	
		
___________________________________________________________ 
ÑÅ»¢Ãâ·ÑGÓÊÏ䣭ÖйúµÚÒ»¾øÎÞÀ¬»øÓʼþɧÈų¬´óÓÊÏä 
http://cn.mail.yahoo.com


From dpreed at reed.com  Sun Oct 30 19:26:18 2005
From: dpreed at reed.com (David P. Reed)
Date: Sun, 30 Oct 2005 22:26:18 -0500
Subject: [e2e] not quite the differentiated services I was thinking of
In-Reply-To: <20051031021814.92609.qmail@web15401.mail.cnb.yahoo.com>
References: <20051031021814.92609.qmail@web15401.mail.cnb.yahoo.com>
Message-ID: <43658EDA.9000408@reed.com>

Jing Shen wrote:

> So, is there any way to introduce more intellegence into IP network?

Let's examine the term intelligence, here.

It seems to me that there is a lot of intelligence in the various
networks that underlay IP. That's the virtue of the hourglass model -
you can put brilliant technology under IP, all focused on making the
network the best it can be at transporting IP packets. The intelligence
is of a sense-and-respond, adaptive type that actually configures the
network based on observed use, rather than requiring the users to ask
permission for new uses or to declare their pattern of use in advance,
which is what would be needed if the network were truly braindead like ATM.


Now there is another interpretation of "intelligence" which is
specializing the network for specific application layer functions.
That's the meaning of the term "Intelligent Network" in the old AIN
telephony model. Specialization isn't intelligence, though - it is
making the network less capable in fact. A network that can only carry
voice is not intelligent, it's stupid. A network that can only carry
voice and TV on-demand is only slightly less brain-dead.

Intelligence is needed in the network to be adaptive to a widely varying
and hard to predict set of future usage scenarios and load mixes - but
binding the network to a fixed set of uses, limiting it to the
imagination of those who cannot conceive that applications like the web
could exist (where one transaction involves dynamic selection of content
from a broad set of 30-40 sites not known in advance to the requestor,
as many web pages do), that's not intelligent, that's dumb.





From jshen_cad at yahoo.com.cn  Mon Oct 31 06:50:49 2005
From: jshen_cad at yahoo.com.cn (Jing Shen)
Date: Mon, 31 Oct 2005 22:50:49 +0800 (CST)
Subject: [e2e] not quite the differentiated services I was thinking of
In-Reply-To: <43658EDA.9000408@reed.com>
Message-ID: <20051031145049.3323.qmail@web15410.mail.cnb.yahoo.com>


> 
> > So, is there any way to introduce more
> intellegence into IP network?
[snip]
> packets. The intelligence
> is of a sense-and-respond, adaptive type that
> actually configures the
> network based on observed use, rather than requiring
> the users to ask
> permission for new uses or to declare their pattern
> of use in advance,
> which is what would be needed if the network were
> truly braindead like ATM.
> 

Agree, no matter under IP or with IP. 


> 
> Now there is another interpretation of
> "intelligence" which is
> specializing the network for specific application
> layer functions.
[snip] 
> Intelligence is needed in the network to be adaptive
> to a widely varying
> and hard to predict set of future usage scenarios
> and load mixes - but
> binding the network to a fixed set of uses, limiting
> it to the
> imagination of those who cannot conceive that
> applications like the web
> could exist (where one transaction involves dynamic
> selection of content
> from a broad set of 30-40 sites not known in advance
> to the requestor,
> as many web pages do), that's not intelligent,
> that's dumb.

To my understanding that's the cover of end-to-end
policy behind TCP/IP architecture, but the back is
those 'rubish traffic' (SPAM , virus , cracking ... )
could run easily around the world. Internet succeed
because intellegence is put at the edge, but what if
virus/terrist make use of robust p2p technology to
overcome those reactive 'firewall'.  

 I don't think intellegience in network is to break
the basic policy in TCP/IP architecture.
Theoretically, intelligence in core network should
focus on adapt to traffic chacteristics and e2e QoS
requirements; at the edge, intellegence should make
internet a managable system while keeping it a low
cost and extensible platform. What confuse me a lot
is, is that possible to make those BRAS (access
router) intelligent enough to  manage traffic at
application level? if backbone is always
overprovisioned, why diffserv? 

Jing 


Jing




		
___________________________________________________________ 
ÑÅ»¢Ãâ·ÑGÓÊÏ䣭No.1µÄ·À¶¾·ÀÀ¬»ø³¬´óÓÊÏä 
http://cn.mail.yahoo.com

From demir at kou.edu.tr  Mon Oct 31 06:26:18 2005
From: demir at kou.edu.tr (Alper Kamil Demir)
Date: Mon, 31 Oct 2005 16:26:18 +0200
Subject: [e2e] [SPAM] - Re: number of flows per unit time in routers -
 Email has different SMTP TO: and MIME TO: fields in the email addresses
In-Reply-To: <4363E33F.1040803@cs.columbia.edu>
References: <20051027202348.55CE81FF@aland.bbn.com>
	<00a901c5dbf9$b2755220$a273f59b@essex.ac.uk><43629ABC.3060106@cs.columbia.edu>
	<43639273.4ACF5FC6@web.de>, <4363E33F.1040803@cs.columbia.edu>
Message-ID: <BAD56A70-2153-462E-8FED-1647EAAD9033@mimectl>

Ping,
>It sounds like I am trying to bring back the "bad" memory of 
>RSVP/IntServ/QoS from the 90's, well... they are not needed in the 
>over-provisioned core. ;-) A paper from Sprint research a while back 
>had proved that with minor overprovisioning per link, there would be no 
>need for QoS in the core. The newly built Comcast IP backbone is all 
>over provisioned... What traffic engineering? ;-)
I appreciate if you could point out the reference of Sprint paper. I wonder what had been proved. Overprovisioning is an easy way to have the Internet work with some application domain; is not a way to provide QoS; is a type of QoS. 

Alper K. Demir

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/end2end-interest/attachments/20051031/bdd435f2/attachment.html

From demir at kou.edu.tr  Mon Oct 31 07:00:38 2005
From: demir at kou.edu.tr (Alper Kamil Demir)
Date: Mon, 31 Oct 2005 17:00:38 +0200
Subject: [e2e] [SPAM] - Re: not quite the differentiated services I was
 thinking of - Email has different SMTP TO: and MIME TO: fields in the email
 addresses
In-Reply-To: <20051030093940.69159.qmail@web15405.mail.cnb.yahoo.com>
References: <e041bec0510220931k74cecd8cvc1d2deff0ce79ba0@mail.gmail.com>,
	<20051030093940.69159.qmail@web15405.mail.cnb.yahoo.com>
Message-ID: <58BE53D4-5DA4-45ED-B41F-9D10D41ED03A@mimectl>

Jing,
>in  ISP networks, QoS differentiation shows up only
>when congestion happens; DiffServ tries to solve
>bandwidth competition under congestion situation, ISP
>want to differentiate e2e QoS even when bandwidth is
>overprovisioned! 
This is not true. There are non-work-conserving and work-conserving QoS schemes that does not depend on congestion. DiffServ does not only try to solve BW competition under congestion situations i.e. EF PHB-related services. Bandwidth is not the only limited resource in the network and is not the only means of service related parameter. 

Current applications on the Internet are congestion-sensitive. I guess that's why overprovisioning seems enough for now. 

Alper K. Demir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/end2end-interest/attachments/20051031/e86e7bd4/attachment.html

From pingpan at cs.columbia.edu  Mon Oct 31 08:41:46 2005
From: pingpan at cs.columbia.edu (Ping Pan)
Date: Mon, 31 Oct 2005 08:41:46 -0800
Subject: [e2e] [SPAM] - Re: number of flows per unit time in routers -
 Email has different SMTP TO: and MIME TO: fields in the email addresses
In-Reply-To: <BAD56A70-2153-462E-8FED-1647EAAD9033@mimectl>
References: <20051027202348.55CE81FF@aland.bbn.com>		<00a901c5dbf9$b2755220$a273f59b@essex.ac.uk><43629ABC.3060106@cs.columbia.edu>
	<43639273.4ACF5FC6@web.de>, <4363E33F.1040803@cs.columbia.edu>
	<BAD56A70-2153-462E-8FED-1647EAAD9033@mimectl>
Message-ID: <4366494A.4090604@cs.columbia.edu>

Appeared in Infocom a couple of years ago, and ToN a couple of months ago:

"Provisioning IP backbone networks to support latency sensitive traffic" 
by C. Fraleigh, F. Tobagi and C. Diot.

Based on a bunch of traffic traces from Sprint backbone at the time.

(Of course, if you really want to hear about overprovisioning, google 
Andrew Odlyzko's old papers. ;-))

- Ping

Alper Kamil Demir wrote:
> Ping,
>  >It sounds like I am trying to bring back the "bad" memory of
>  >RSVP/IntServ/QoS from the 90's, well... they are not needed in the
>  >over-provisioned core. ;-) A paper from Sprint research a while back
>  >had proved that with minor overprovisioning per link, there would be no
>  >need for QoS in the core. The newly built Comcast IP backbone is all
>  >over provisioned... What traffic engineering? ;-)
> I appreciate if you could point out the reference of Sprint paper. I 
> wonder what had been proved. Overprovisioning is an easy way to have the 
> Internet work with some application domain; is not a way to provide QoS; 
> is a type of QoS. 
>  
> Alper K. Demir
> 
>  

From gaylord at dirtcheapemail.com  Mon Oct 31 08:46:33 2005
From: gaylord at dirtcheapemail.com (Clark Gaylord)
Date: Mon, 31 Oct 2005 11:46:33 -0500
Subject: [e2e] not quite the differentiated services I was thinking of
In-Reply-To: <20051031145049.3323.qmail@web15410.mail.cnb.yahoo.com>
References: <20051031145049.3323.qmail@web15410.mail.cnb.yahoo.com>
Message-ID: <43664A69.2050101@dirtcheapemail.com>

Jing Shen wrote:

>could run easily around the world. Internet succeed
>because intellegence is put at the edge, but what if
>virus/terrist make use of robust p2p technology to
>overcome those reactive 'firewall'.  
>  
>

That's why we have a protocol that is designed to withstand nuclear war.

--ckg

From gaylord at dirtcheapemail.com  Mon Oct 31 08:52:57 2005
From: gaylord at dirtcheapemail.com (Clark Gaylord)
Date: Mon, 31 Oct 2005 11:52:57 -0500
Subject: [e2e] number of flows per unit time in routers
In-Reply-To: <83AB0942FD087D499DF2DD5CEE1B6133028DBD11@cacexc06.americas.cpqcorp.net>
References: <83AB0942FD087D499DF2DD5CEE1B6133028DBD11@cacexc06.americas.cpqcorp.net>
Message-ID: <43664BE9.40800@dirtcheapemail.com>

Ghanwani, Anoop wrote:

>I have a very basic question -
>
>Is there industry consensus on what constitutes a flow?
>Theoretically, it could be some arbitrary bit mask being
>applied to every packet.  However, in practice people talk
>about TCP flows, UDP flows, ICMP flows, etc.  Just wondering
>if there is a comprehensive list of these anywhere.
>  
>

You could read more from the ipfix group, but basically cisco got the 
definition right with netflow.  This gets messy with non-TCP traffic, 
but what are you gonna do?  "The five-tuple" is the usual shorthand 
(dst/src address/port + protocol).  Non-port protocols either have 
something similar (a la icmp message) or ignore the port field.  Note 
that a flow is uni-directional, so some have tried to define the 
bi-directional pair, but that gets dicey since there are plenty of 
applications (e.g. multicast streaming) that are inherently 
uni-directional.  Of course, multicast is a bit of a special case anyway.

--ckg

From yb at bashibuzuk.net  Mon Oct 31 10:54:39 2005
From: yb at bashibuzuk.net (Yann Berthier)
Date: Mon, 31 Oct 2005 19:54:39 +0100
Subject: [e2e] number of flows per unit time in routers
In-Reply-To: <43664BE9.40800@dirtcheapemail.com>
References: <83AB0942FD087D499DF2DD5CEE1B6133028DBD11@cacexc06.americas.cpqcorp.net>
	<43664BE9.40800@dirtcheapemail.com>
Message-ID: <20051031185439.GN55099@bashibuzuk.net>

On Mon, 31 Oct 2005, Clark Gaylord wrote:

> Ghanwani, Anoop wrote:
> 
> >I have a very basic question -
> >
> >Is there industry consensus on what constitutes a flow?
> >Theoretically, it could be some arbitrary bit mask being
> >applied to every packet.  However, in practice people talk
> >about TCP flows, UDP flows, ICMP flows, etc.  Just wondering
> >if there is a comprehensive list of these anywhere.
> > 
> >
> 
> You could read more from the ipfix group, but basically cisco got the 
> definition right with netflow.  This gets messy with non-TCP traffic, 
> but what are you gonna do?  "The five-tuple" is the usual shorthand 
> (dst/src address/port + protocol).  Non-port protocols either have 
> something similar (a la icmp message) or ignore the port field.  Note 
> that a flow is uni-directional, so some have tried to define the 
> bi-directional pair, but that gets dicey since there are plenty of 
> applications (e.g. multicast streaming) that are inherently 
> uni-directional.  Of course, multicast is a bit of a special case anyway.

   I would be tempted to say that uni-directional applications (which
   are quite the minority for many networks) are just a special case of
   bi-directional flows, with 'back' fields (number of bytes, packets
   and so on) filled with zeros. Now that doesn't change the fact that
   what is exported by routers is uni-directional ;), and that some
   post-processing work is needed to match the in and out part of a
   bi-directional flow. And i know no collector doing this job, so it
   would have to be done after the flows have been stored on disk, which
   seems to me rather sub optimal.
   
   Btw, there is now a draft for a bi-directional support in IPFIX:
   http://www.rfc-editor.org/internet-drafts/draft-boschi-ipfix-biflow-01.txt

   Regards,

      - yann

--
Flowop - collecting NetFlow related discussions
          flowop at lists.csrrt.org

From gaylord at dirtcheapemail.com  Mon Oct 31 13:17:46 2005
From: gaylord at dirtcheapemail.com (Clark Gaylord)
Date: Mon, 31 Oct 2005 16:17:46 -0500
Subject: [e2e] number of flows per unit time in routers
In-Reply-To: <20051031185439.GN55099@bashibuzuk.net>
References: <83AB0942FD087D499DF2DD5CEE1B6133028DBD11@cacexc06.americas.cpqcorp.net>	<43664BE9.40800@dirtcheapemail.com>
	<20051031185439.GN55099@bashibuzuk.net>
Message-ID: <436689FA.7020205@dirtcheapemail.com>

Yann Berthier wrote:

>   I would be tempted to say that uni-directional applications (which
>   are quite the minority for many networks) are just a special case of
>   bi-directional flows, with 'back' fields (number of bytes, packets
>   and so on) filled with zeros. Now that doesn't change the fact that
>   what is exported by routers is uni-directional ;), and that some
>   post-processing work is needed to match the in and out part of a
>   bi-directional flow. And i know no collector doing this job, so it
>   would have to be done after the flows have been stored on disk, which
>   seems to me rather sub optimal.
>   
>   Btw, there is now a draft for a bi-directional support in IPFIX:
>   http://www.rfc-editor.org/internet-drafts/draft-boschi-ipfix-biflow-01.txt
>  
>

For most useful analysis, both sides of a bi-directional flow are 
useful, but routing, traffic patterns, etc, are not necessarily 
symmetric either.   So flows are fundamentally unidirectional with 
bi-dir a function of synthesis.

Pedantry happens.

--ckg

From gaylord at dirtcheapemail.com  Mon Oct 31 13:20:09 2005
From: gaylord at dirtcheapemail.com (Clark Gaylord)
Date: Mon, 31 Oct 2005 16:20:09 -0500
Subject: [e2e] [SPAM] - Re: number of flows per unit time in routers -
 Email has different SMTP TO: and MIME TO: fields in the email addresses
In-Reply-To: <BAD56A70-2153-462E-8FED-1647EAAD9033@mimectl>
References: <20051027202348.55CE81FF@aland.bbn.com>	<00a901c5dbf9$b2755220$a273f59b@essex.ac.uk><43629ABC.3060106@cs.columbia.edu>	<43639273.4ACF5FC6@web.de>,
	<4363E33F.1040803@cs.columbia.edu>
	<BAD56A70-2153-462E-8FED-1647EAAD9033@mimectl>
Message-ID: <43668A89.1090208@dirtcheapemail.com>

Alper Kamil Demir wrote:

> Ping,
> >It sounds like I am trying to bring back the "bad" memory of
> >RSVP/IntServ/QoS from the 90's, well... they are not needed in the
> >over-provisioned core. ;-) A paper from Sprint research a while back
> >had proved that with minor overprovisioning per link, there would be no
> >need for QoS in the core. The newly built Comcast IP backbone is all
> >over provisioned... What traffic engineering? ;-)
> I appreciate if you could point out the reference of Sprint paper. I 
> wonder what had been proved. Overprovisioning is an easy way to have 
> the Internet work with some application domain; is not a way to 
> provide QoS; is a type of QoS. 


The other thing you need for that to work is that core link speeds are 
faster than access speeds, but with that assumption it doesn't take long 
to get to this conclusion.

--ckg

From jshen_cad at yahoo.com.cn  Mon Oct 31 16:38:39 2005
From: jshen_cad at yahoo.com.cn (Jing Shen)
Date: Tue, 1 Nov 2005 08:38:39 +0800 (CST)
Subject: [e2e] not quite the differentiated services I was thinking of
In-Reply-To: <43664A69.2050101@dirtcheapemail.com>
Message-ID: <20051101003840.37072.qmail@web15406.mail.cnb.yahoo.com>


--- Clark Gaylord <gaylord at dirtcheapemail.com>:
> 
> That's why we have a protocol that is designed to
> withstand nuclear war.
> 

So, no QoS needed in backbone network; SPAM could be
transferred everywhere ....  ???

I found this in Andrew's paper list,interesting


http://www.rnejournal.com/abstract_odlyzko_sept04.html

Jing





	

	
		
___________________________________________________________ 
ÑÅ»¢Ãâ·ÑGÓÊÏ䣭ÖйúµÚÒ»¾øÎÞÀ¬»øÓʼþɧÈų¬´óÓÊÏä 
http://cn.mail.yahoo.com


From pingpan at cs.columbia.edu  Mon Oct 31 17:13:13 2005
From: pingpan at cs.columbia.edu (Ping Pan)
Date: Mon, 31 Oct 2005 17:13:13 -0800
Subject: [e2e] [SPAM] - Re: number of flows per unit time in routers -
 Email has different SMTP TO: and MIME TO: fields in the email addresses
In-Reply-To: <43668A89.1090208@dirtcheapemail.com>
References: <20051027202348.55CE81FF@aland.bbn.com>	<00a901c5dbf9$b2755220$a273f59b@essex.ac.uk><43629ABC.3060106@cs.columbia.edu>	<43639273.4ACF5FC6@web.de>,
	<4363E33F.1040803@cs.columbia.edu>
	<BAD56A70-2153-462E-8FED-1647EAAD9033@mimectl>
	<43668A89.1090208@dirtcheapemail.com>
Message-ID: <4366C129.70003@cs.columbia.edu>

Actually, not really. GE and 10GE are getting real popular for access, 
in particular, PON-based access networks. There could be tons of GE/10GE 
at aggregation points, but only a single OC3/OC12 toward the core.

The assumption has been that video traffic can be handled locally within 
aggregation networks, (R/F overlay through optical links directly, or 
satellite video download etc...)

What may happened is that large user traffic bursts jam into the narrow 
OC-n links toward the core. This is where proper traffic policing 
becomes useful.

- Ping

Clark Gaylord wrote:
>
> The other thing you need for that to work is that core link speeds are 
> faster than access speeds, but with that assumption it doesn't take long 
> to get to this conclusion.
> 
> --ckg

From pingpan at cs.columbia.edu  Mon Oct 31 17:16:51 2005
From: pingpan at cs.columbia.edu (Ping Pan)
Date: Mon, 31 Oct 2005 17:16:51 -0800
Subject: [e2e] not quite the differentiated services I was thinking of
In-Reply-To: <20051101003840.37072.qmail@web15406.mail.cnb.yahoo.com>
References: <20051101003840.37072.qmail@web15406.mail.cnb.yahoo.com>
Message-ID: <4366C203.9040908@cs.columbia.edu>

Since when backbone QoS is designed for SPAM prevention? :-) If you have
that much SPAM to contribute, the service providers need to disconnect
you first. ;-)

- Ping

Jing Shen wrote:
> --- Clark Gaylord <gaylord at dirtcheapemail.com>:
> 
>>That's why we have a protocol that is designed to
>>withstand nuclear war.
>>
> 
> 
> So, no QoS needed in backbone network; SPAM could be
> transferred everywhere ....  ???
> 
> I found this in Andrew's paper list,interesting
> 
> 
> http://www.rnejournal.com/abstract_odlyzko_sept04.html
> 
> Jing
> 
> 
> 
> 
> 
> 	
> 
> 	
> 		
> ___________________________________________________________ 
> ÑÅ»¢Ãâ·ÑGÓÊÏ䣭ÖйúµÚÒ»¾øÎÞÀ¬»øÓʼþɧÈų¬´óÓÊÏä 
> http://cn.mail.yahoo.com