httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: paper on "Promoting the Use of End-to-End Congestion Control" (fwd)
Date Tue, 03 Mar 1998 07:22:20 GMT
Mildly unrelated, but the data referenced here is very cool.  There are a
lot of cool numbers I am thinking of trying to get with it.  If I get the
time.  Just like everything else I want to do.  Sigh. 

---------- Forwarded message ----------
Date: Mon, 2 Mar 1998 01:14:55 -0800
From: k claffy <kc@caida.org>
To: Sally Floyd <floyd@ee.lbl.gov>
Cc: end2end-interest@ISI.EDU, Hans-Werner Braun <hwb@nlanr.net>,
    kevin <kthomp@mci.net>, joel <apisdorf@mci.net>
Subject: Re: paper on "Promoting the Use of End-to-End Congestion Control"



sally/kevin

    Kevin Fall and I have revised a subsection of our 1997 draft paper on
    "Router Mechanisms to Support End-to-End Congestion Control".  The
    revised paper is titled "Promoting the Use of End-to-End Congestion
    Control", http://www-nrg.ee.lbl.gov/floyd/end2end-paper.html


as usual, way cool paper. like poetry -- 

section 2.2 'danger of congestion collapse' you mention 

	We believe that this [undelivered packets, those
	that just get toasted on their way to destination]
	is the largest unresolved danger wrt congestion
	collapse in the Internet today.
	The danger of congestion collapse from undelivered packets
	is due primarily to the increasing deployment of open-loop
	applications not using end-to-end congsetion control.
	Even more destructive would be best-effort applications
	that *increased* their sending rate in response 
	to an increased packet dfrop rate (e.g., using an 
	increased level of FEC).

quite a strong belief system,
it's actually not obvious to me from looking at
what WAN stats we can can get our mitts on 
that UDP is playing such a strong role yet --
am not saying it's not, just would be good to verify  --

you also talk later about the other phenomenon of
increased control traffic,

	as a result of increasing load and therefore
	increasing congestion, and increasingly-large fraction
		{ do you get the sense everything on the internet
		  is Increasing? :) }
	of the bytes transmitted on the congested links belong 
	to control traffic (packet headers for small data packets, 
	routing updates, multicasts join and prune messages, 
	session messsages for reliable multicast sessions, 
	DNS messages, etc), and an increasinly-small 
	fraction of the bytes trasmitted correspond to data 
	actually delivered to network applications

are SYN's in there somewhere?  
(not to mention SYN attacks <s> ) 
i mean not even small data packets but Zero Data Packets...
(unless you count as seq/ackNum field as data
which i guess would be fair enough..)


anyway, if anyone has time/inclination to back up 
with analysis of WAN packet trace data --
we've been working for a few months (well, years, really) 
to get to a point where we can again offer 
'realistic' packet traces from a wide area exchange point, 
specifically one of the four OC3 links between the 
MAE/FIX at NASA Ames and MAE-west/SanJose -- 
(now if only we had the time/energy/resources 
to do all the analysis folks want)

anyway, mci/vbns(nsf) have done the oc3mon work to make this possible
(joel apisdorf, kevin thompson, greg miller, et al)

and hwb's done all collection stuff:

	http://moat.nlanr.net/Traces/
	(hwb's readme file under
	http://moat.nlanr.net/Traces/Traces)

so if anyone needs class projects, have at it...
(caveat ftper the uh, file Siiizes...
syquest's NASDAQ symbol is SYQT... :)  )


again, totally yummy paper
kudos
k


Mime
View raw message