From rbriscoe at jungle.bt.co.uk Sat Sep 1 02:02:37 2007
From: rbriscoe at jungle.bt.co.uk (Bob Briscoe)
Date: Sat, 01 Sep 2007 10:02:37 +0100
Subject: [e2e] opening multiple TCP connections getting popular
In-Reply-To: <46D7BC78.6030106@isi.edu>
References: <5.2.1.1.2.20070830171615.04159680@pop3.jungle.bt.co.uk>
<aa7d2c6d0708300848y29d6d7cegb6ac4c6ecc28c440@mail.gmail.com>
<5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk>
<46D65074.9060403@isi.edu>
<aa7d2c6d0708300814w20175c31n3861d029d5d39d85@mail.gmail.com>
<46D6E139.1050202@isi.edu>
<aa7d2c6d0708300848y29d6d7cegb6ac4c6ecc28c440@mail.gmail.com>
<5.2.1.1.2.20070830171615.04159680@pop3.jungle.bt.co.uk>
Message-ID: <5.2.1.1.2.20070901084903.04240dc0@pop3.jungle.bt.co.uk>
Joe,
I composed responses yesterday to each of your points, but I've realised
there's no purpose in sending them until the underlying terms of reference
are mended...
At 08:00 31/08/2007, Joe Touch wrote:
>Bob (et al),
---snip---
> >> (and, as others have noted, it's not
> >> clear we _need_ to do anything).
> >
> > Tell that to the CEO of any network operator. I think you're saying
> > there's not an engineering problem. But that's because resource
> > allocation problems are economic problems not engineering problems...
>
>No - I'm saying it isn't a problem. Whether it's economic or otherwise,
>as others have noted, not being 'fair' depends on an agreed concept of
>fairness. We have one now - per-TCP connection, relative to RTT. That's
>not perfect, but it is a definition, and it does work.
Well, most people who have entered this debate (mosly on tsvwg) have tried
to distance themselves from ever having been definite about per-TCP
connection/RTT as the agreed measure.
Of course there's not a problem... if you're measuring it the way you
are... but that's because the measure you're using isn't a relevant measure
- fairness is a social science issue so you need a social or economic
measure. Otherwise your judgement of whether 'it works' is circular...
Imagine a country had a tax system based on the number of transactions
entering and leaving a person's bank accounts.
* I'm saying such a metric doesn't produce a fair taxation system (e.g.
high earners stuff more money through less transactions).
* By analogy, by sticking with transaction count as a measure, you're led
to argue that there's not a problem. You can cite surveys of the
transaction count into people's bank accounts that show people are being
taxed in fair proportion to this count, and further, you're led to say that
there can't be a problem because the spread of the count of transactions
between most and least is pretty small.
If you look instead at the different volumes of congestion that users cause
against how much each is contributing to the system, you should be able to
see there is a huge problem. There's also a far greater spread of
congestion volume caused by different users than is warranted by any value
they get from causing it - many orders of magnitude between the lowest
quartile and the highest, but the spread of contributions is probably
within an order of magnitude.
It's not just flow rate. Flow rate must be weighted by the prevailing
congestion at each instant and the result accumulated over /time/. Then
attributed to each /economic entity/. That's congestion volume per 'user'.
And, if we go straight to congestion volume without passing through flow
rate, the resulting accountability system is really simple.
Ditch flows.
Bob
____________________________________________________________________________
Bob Briscoe, <bob.briscoe at bt.com> Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196
From touch at ISI.EDU Sat Sep 1 03:05:03 2007
From: touch at ISI.EDU (Joe Touch)
Date: Sat, 01 Sep 2007 03:05:03 -0700
Subject: [e2e] opening multiple TCP connections getting popular
In-Reply-To: <5.2.1.1.2.20070901084903.04240dc0@pop3.jungle.bt.co.uk>
References: <5.2.1.1.2.20070830171615.04159680@pop3.jungle.bt.co.uk> <aa7d2c6d0708300848y29d6d7cegb6ac4c6ecc28c440@mail.gmail.com> <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> <46D65074.9060403@isi.edu> <aa7d2c6d0708300814w20175c31n3861d029d5d39d85@mail.gmail.com> <46D6E139.1050202@isi.edu> <aa7d2c6d0708300848y29d6d7cegb6ac4c6ecc28c440@mail.gmail.com> <5.2.1.1.2.20070830171615.04159680@pop3.jungle.bt.co.uk>
<5.2.1.1.2.20070901084903.04240dc0@pop3.jungle.bt.co.uk>
Message-ID: <46D9394F.1040304@isi.edu>
Bob Briscoe wrote:
> Joe,
>
> I composed responses yesterday to each of your points, but I've realised
> there's no purpose in sending them until the underlying terms of
> reference are mended...
The underlying issues are, as far as this thread is concerned, IMO:
1) any mechanism that TCP needs to be per-user fair - to defeat multiple
TCP connections as a cheat - is needed both for TCP and flow-rate fairness.
2) that mechanism doesn't exist, so flow-rate fairness alone isn't
sufficient
3) if that mechanism did exist, THEN we're back to arguing the
definition of fairness at two levels (at least):
a) from the user down to the flow/connection within that
nonexistent mechanism
b) among flows/connections
Near as I can tell, FRF addresses ONLY 3b.
IMO, this thread is more about 3a; FRF has absolutely nothing to do with
that.
IMO, 3a drives more about what people consider 'fair' than anything else.
You raised an excellent point that there's nothing about this mechanism
that we cannot implement, however, 3a requires knowing the policy we
want to enforce, and we don't know (or at least don't agree upon) that.
Further, we agree that FRF is better than TCP-friendly 'fairness'.
We probably ought to agree to disagree about whether TCP-friendly
fairness is so utterly broken that it needs to be replaced, and whether
the impact required to deploy FRF is worth the benefit gained. That's
the devil in our past arguments, and in most of the negative FRF
feedback I've seen from the IETF in public.
However, those last two points have nothing to do with this thread,
again, AFAICT.
Joe
--
----------------------------------------------------------------------
Joe Touch Sr. Network Engineer, USAF TSAT Space Segment
Postel Center Director & Research Assoc. Prof., USC/ISI
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070901/e5a74aaa/signature.bin
From rbriscoe at jungle.bt.co.uk Mon Sep 3 05:07:53 2007
From: rbriscoe at jungle.bt.co.uk (Bob Briscoe)
Date: Mon, 03 Sep 2007 13:07:53 +0100
Subject: [e2e] opening multiple TCP connections getting popular
In-Reply-To: <46D9394F.1040304@isi.edu>
References: <5.2.1.1.2.20070901084903.04240dc0@pop3.jungle.bt.co.uk>
<5.2.1.1.2.20070830171615.04159680@pop3.jungle.bt.co.uk>
<aa7d2c6d0708300848y29d6d7cegb6ac4c6ecc28c440@mail.gmail.com>
<5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk>
<46D65074.9060403@isi.edu>
<aa7d2c6d0708300814w20175c31n3861d029d5d39d85@mail.gmail.com>
<46D6E139.1050202@isi.edu>
<aa7d2c6d0708300848y29d6d7cegb6ac4c6ecc28c440@mail.gmail.com>
<5.2.1.1.2.20070830171615.04159680@pop3.jungle.bt.co.uk>
<5.2.1.1.2.20070901084903.04240dc0@pop3.jungle.bt.co.uk>
Message-ID: <5.2.1.1.2.20070901110955.04232c18@pop3.jungle.bt.co.uk>
Joe,
To take the last point first about relevance to this thread.
You may have missed my second posting (in response to JonC),
<http://www.postel.org/pipermail/end2end-interest/2007-August/006933.html>
clarifying that any assumption that multiple TCP connections are
bad/unfair/cheating was in the reader's head, not in my posting (and hey, I
started this thread!). This thread is about how it would be OK to open
multiple connections (or window scaling) if there were accountability for
the congestion caused.
Or as I put it at the start, "Why shouldn't app-layer people expect the
transport layer to correctly handle fairness?" [fairness would actually be
done below the transport layer].
Nonetheless, I believe Hitler was bad/unfair/cheating (that may help Ted
place me on his political spectrum :)
more inline...
At 11:05 01/09/2007, Joe Touch wrote:
>Bob Briscoe wrote:
> > Joe,
> >
> > I composed responses yesterday to each of your points, but I've realised
> > there's no purpose in sending them until the underlying terms of
> > reference are mended...
>
>The underlying issues are, as far as this thread is concerned, IMO:
>
>1) any mechanism that TCP needs to be per-user fair - to defeat multiple
>TCP connections as a cheat - is needed both for TCP and flow-rate fairness.
Yes. Indeed, it's needed irrespective of how a user's bits are carved up
into flows.
Nit: If you really meant "TCP and flow rate fairness", this might indicate
we're taking different meanings for FRF. The term "FRF" is surely a general
term for TCP fairness, generalised to include other attempts to define
fairness; as approximate equality of the rates of individual competing flows.
From a couple of other instances later in this thread, I think you've
mistakenly used the term "flow rate fairness" where you possibly meant
"cost fairness". But in one case, I think you might have really meant flow
rate fairness. I need to check whether I need to decode an intermittent
substitution cipher!
>2) that mechanism doesn't exist, so flow-rate fairness alone isn't
>sufficient
I'm lost. We must be talking at complete cross-purposes here.
But whatever, that mechanism does exist, at least as a proposal (mine).
My proposal (re-ECN) can do both:
- any form of flow-rate fairness (by confining its scope to each flow
myopically) including TCP-fairness
- and wider fairness across flows (cost fairness).
>3) if that mechanism did exist, THEN we're back to arguing the
>definition of fairness at two levels (at least):
>
> a) from the user down to the flow/connection within that
> nonexistent mechanism
>
> b) among flows/connections
>
>Near as I can tell, FRF addresses ONLY 3b.
>
>IMO, this thread is more about 3a; FRF has absolutely nothing to do with
>that.
Now, I do agree with both these statements.
>IMO, 3a drives more about what people consider 'fair' than anything else.
I think you're saying "what people believe" is what you believe they should
believe? If that's a correct reading, yes I agree. And that's one of the
main motivations of my proposal.
>You raised an excellent point that there's nothing about this mechanism
>that we cannot implement, however, 3a requires knowing the policy we
>want to enforce, and we don't know (or at least don't agree upon) that.
re-ECN doesn't take a position on what the policy should be - it allows
policy to be applied to it. We need a policy control system precisely when
we don't know what the policy should be.
>Further, we agree that FRF is better than TCP-friendly 'fairness'.
Again, eh? FRF is a superset of TCP-friendly. But I'm glad to see you've
put 'fairness' in quotes, so we must be agreeing at some level, but there's
a misunderstanding or a substitution cipher here somewhere too.
>We probably ought to agree to disagree about whether TCP-friendly
>fairness is so utterly broken that it needs to be replaced, and whether
>the impact required to deploy FRF is worth the benefit gained. That's
>the devil in our past arguments, and in most of the negative FRF
>feedback I've seen from the IETF in public.
I think you might be meaning cost fairness, when you say FRF? Otherwise,
there's a deep level of misunderstanding here.
Cheers
Bob
>However, those last two points have nothing to do with this thread,
>again, AFAICT.
>
>Joe
>
>--
>----------------------------------------------------------------------
>Joe Touch Sr. Network Engineer, USAF TSAT Space Segment
> Postel Center Director & Research Assoc. Prof., USC/ISI
____________________________________________________________________________
Bob Briscoe, <bob.briscoe at bt.com> Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196
From touch at ISI.EDU Mon Sep 3 19:03:49 2007
From: touch at ISI.EDU (Joe Touch)
Date: Mon, 03 Sep 2007 19:03:49 -0700
Subject: [e2e] opening multiple TCP connections getting popular
In-Reply-To: <5.2.1.1.2.20070901110955.04232c18@pop3.jungle.bt.co.uk>
References: <5.2.1.1.2.20070901084903.04240dc0@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070830171615.04159680@pop3.jungle.bt.co.uk> <aa7d2c6d0708300848y29d6d7cegb6ac4c6ecc28c440@mail.gmail.com> <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk> <46D65074.9060403@isi.edu> <aa7d2c6d0708300814w20175c31n3861d029d5d39d85@mail.gmail.com> <46D6E139.1050202@isi.edu> <aa7d2c6d0708300848y29d6d7cegb6ac4c6ecc28c440@mail.gmail.com> <5.2.1.1.2.20070830171615.04159680@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070901084903.04240dc0@pop3.jungle.bt.co.uk>
<5.2.1.1.2.20070901110955.04232c18@pop3.jungle.bt.co.uk>
Message-ID: <46DCBD05.7030006@isi.edu>
Bob,
Bob Briscoe wrote:
> Joe,
>
> To take the last point first about relevance to this thread.
>
> You may have missed my second posting (in response to JonC),
> <http://www.postel.org/pipermail/end2end-interest/2007-August/006933.html>
> clarifying that any assumption that multiple TCP connections are
> bad/unfair/cheating was in the reader's head, not in my posting (and
> hey, I started this thread!). This thread is about how it would be OK to
> open multiple connections (or window scaling) if there were
> accountability for the congestion caused.
I didn't miss it; it doesn't address the issue that this sort of
fairness is defined by a policy that we don't currently have.
> Or as I put it at the start, "Why shouldn't app-layer people expect the
> transport layer to correctly handle fairness?" [fairness would actually
> be done below the transport layer].
IMO, the missing piece is above the transport layer, not below.
> Nonetheless, I believe Hitler was bad/unfair/cheating (that may help Ted
> place me on his political spectrum :)
>
> more inline...
>
>
> At 11:05 01/09/2007, Joe Touch wrote:
>
>> Bob Briscoe wrote:
>> > Joe,
>> >
>> > I composed responses yesterday to each of your points, but I've
>> realised
>> > there's no purpose in sending them until the underlying terms of
>> > reference are mended...
>>
>> The underlying issues are, as far as this thread is concerned, IMO:
>>
>> 1) any mechanism that TCP needs to be per-user fair - to defeat multiple
>> TCP connections as a cheat - is needed both for TCP and flow-rate
>> fairness.
>
> Yes. Indeed, it's needed irrespective of how a user's bits are carved up
> into flows.
>
> Nit: If you really meant "TCP and flow rate fairness", this might
> indicate we're taking different meanings for FRF. The term "FRF" is
> surely a general term for TCP fairness, generalised to include other
> attempts to define fairness; as approximate equality of the rates of
> individual competing flows.
>
> From a couple of other instances later in this thread, I think you've
> mistakenly used the term "flow rate fairness" where you possibly meant
> "cost fairness". But in one case, I think you might have really meant
> flow rate fairness. I need to check whether I need to decode an
> intermittent substitution cipher!
Pick an acronym suitable for the mechanism you propose. ;-)
>> 2) that mechanism doesn't exist, so flow-rate fairness alone isn't
>> sufficient
>
> I'm lost. We must be talking at complete cross-purposes here.
>
> But whatever, that mechanism does exist, at least as a proposal (mine).
>
> My proposal (re-ECN) can do both:
> - any form of flow-rate fairness (by confining its scope to each flow
> myopically) including TCP-fairness
> - and wider fairness across flows (cost fairness).
So can RFC2140. The missing piece is "what is fair":
one 'chunk' (flow, cost, unit - again, the term isn't
as relevant as the concept) per:
- user (what's a user?)
- process
- transport connection
- endpoint IP address
- HIP ID
- IPsec SA
Until we decide how aggregate accounting happens, the rest is moot. The
fundamental problem with opening multiple TCP flows to 'cheat' is that
there are different groups with different views on that aggregation.
Given whatever aggregation you find comfortable, there are different
versions of fair:
- yours
- TCP-friendly
Now, admittedly, TCP-friendly doesn't jib with what some would call
fair, especially because, other things being equal:
- smaller RTT gets a bigger slice
- lower loss gets a bigger slice
- obeying TCP's rules for friendliness
The useful point about TCP-friendly is that it's currently sufficient
largely (IMO) because users can't do anything to make the first two of
those parameters smaller; they can only increase them, and that is
self-penalizing.
The last parameter is the devil, but it's somewhat a defining
characteristic of any mechanism that lacks enforcement, somewhat of a
Nash-ism: everyone plays by the rules, and the rules work for everyone.
>> 3) if that mechanism did exist, THEN we're back to arguing the
>> definition of fairness at two levels (at least):
>>
>> a) from the user down to the flow/connection within that
>> nonexistent mechanism
>>
>> b) among flows/connections
>>
>> Near as I can tell, FRF addresses ONLY 3b.
>>
>> IMO, this thread is more about 3a; FRF has absolutely nothing to do with
>> that.
>
> Now, I do agree with both these statements.
>
>> IMO, 3a drives more about what people consider 'fair' than anything else.
>
> I think you're saying "what people believe" is what you believe they
> should believe? If that's a correct reading, yes I agree. And that's one
> of the main motivations of my proposal.
I agree! You want to define a more 'fair' concept of 'fair' among
parties, but the problem in this thread is more with defining a 'party'
(IP flow, endpoint, HIP ID, etc.) than with what's fair once you do that.
>> You raised an excellent point that there's nothing about this mechanism
>> that we cannot implement, however, 3a requires knowing the policy we
>> want to enforce, and we don't know (or at least don't agree upon) that.
>
> re-ECN doesn't take a position on what the policy should be - it allows
> policy to be applied to it. We need a policy control system precisely
> when we don't know what the policy should be.
Right! And it's the lack of that policy that is the key to *this* thread.
>> Further, we agree that FRF is better than TCP-friendly 'fairness'.
>
> Again, eh? FRF is a superset of TCP-friendly. But I'm glad to see you've
> put 'fairness' in quotes, so we must be agreeing at some level, but
> there's a misunderstanding or a substitution cipher here somewhere too.
s/FRF/Bob's mechanism/ -- I think we agree here.
>> We probably ought to agree to disagree about whether TCP-friendly
>> fairness is so utterly broken that it needs to be replaced, and whether
>> the impact required to deploy FRF is worth the benefit gained. That's
>> the devil in our past arguments, and in most of the negative FRF
>> feedback I've seen from the IETF in public.
>
> I think you might be meaning cost fairness, when you say FRF? Otherwise,
> there's a deep level of misunderstanding here.
Probably.
>> However, those last two points have nothing to do with this thread,
>> again, AFAICT.
Let's not please lose this last point, however.
--
----------------------------------------------------------------------
Joe Touch Sr. Network Engineer, USAF TSAT Space Segment
Postel Center Director & Research Assoc. Prof., USC/ISI
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070903/e976b624/signature.bin
From garmitage at swin.edu.au Thu Sep 6 23:34:16 2007
From: garmitage at swin.edu.au (grenville armitage)
Date: Fri, 07 Sep 2007 16:34:16 +1000
Subject: [e2e] Logging active TCP details in FreeBSD 5, 6 and 7
Message-ID: <46E0F0E8.8040000@swin.edu.au>
All,
On the off chance this is of general interest, I'd like to let
people know of a FreeBSD kernel module we've developed for
logging various TCP state variables in a running kernel
while sessions are active.
Called SIFTR ("sifter"), we built this for our own research into
precisely how a FreeBSD TCP stack behaves when faced with real
and artificial (e.g. dummynet) paths. Figured it might also be
of interest to others.
See http://caia.swin.edu.au/urp/newtcp/tools.html (under SIFTR)
for a readme, changelog and tarball. The authors would love to get
feedback from anyone trying it out. (SIFTR has been developed and
tested mostly under FreeBSD 6.2, but we believe it'll be stable
under 5.x and 7.x too.)
cheers,
gja
From nataraja at cis.udel.edu Sun Sep 9 06:12:07 2007
From: nataraja at cis.udel.edu (Preethi Natarajan)
Date: Sun, 09 Sep 2007 09:12:07 -0400
Subject: [e2e] VSAT/3G
Message-ID: <46E3F127.4080109@cis.udel.edu>
Hello,
Can someone point me to references/information on characteristics
(bandwidth, typical loss rates observed, e2e delay) of
(i) current VSAT deployments for Internet connectivity in countries such
as Africa, India
(ii) 3G networks
Thanks a ton!
Preethi
From nina.taft at intel.com Sat Sep 15 01:05:26 2007
From: nina.taft at intel.com (Taft, Nina)
Date: Sat, 15 Sep 2007 01:05:26 -0700
Subject: [e2e] IMC 2007 Call For Participation
Message-ID: <4D97B70CF7F72144881F66DFF4BD7A1202A7C6C3@fmsmsx413.amr.corp.intel.com>
Dear Colleagues,
It is now time to register and book your hotel for IMC 2007.
Internet Measurement Conference
Sponsored by ACM SIGCOMM in cooperation with Usenix
October 24-26, 2007
San Diego, CA USA
DEADLINES: Book hotel before Sept. 30th to receive discounted rates
Please register by Oct.12, 2007
The seventh Internet Measurement Conference (IMC 2007) is a two and
one-half day event focusing on networking measurement and analysis.
Join
us for the latest research on Internet data analysis and its
applications. The conference this year will cover a range of topics
including security, social networks, wireless networking, routing,
topology,
applications, and more. This year IMC has expanded its wireless
measurement
scope, as we adapt to meet the evolving interests of the community.
TECHNICAL PROGRAM
To view the full technical program, please see:
http://www.imconf.net/imc-2007/program.html
SPECIAL EVENT - NEW THIS YEAR
In addition to the usual technical program, this year there will
be a couple of talks on the ethics and legality of network measurement
practices among our community. This will be followed by a BoF,
in which we will discuss these issues as a community. Invited
participants
from the law profession as well as privacy experts will join us.
We are excited to host this event as these issues are timely.
ACCOMODATIONS:
The conference will be held in the Paradise Point Resort Hotel on
Mission Bay.
To receive the discount rate of $205/night for the conference you MUST
book
your room before September 30th. Please tell them you are with the
Internet
Measurement Conference to receive our bulk discount rate. After Sept.
30th rooms are not guaranteed and the rate will increase! So please book
your reservation promptly.
For information on the hotel and how to make a reservation, please see:
http://www.imconf.net/imc-2007/venue.html
REGISTRATION
To register on-line, please go to:
http://www.imconf.net/imc-2007/
Please register for IMC no later than Oct. 12th, 2007
we look forward to seeing you soon,
from the IMC Steering Committee:
Nina Taft,
Bruce Maggs
Paul Barford
Kevin Jeffay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070915/488531f3/attachment.html
From rajeevshorey at gmail.com Tue Sep 18 09:20:55 2007
From: rajeevshorey at gmail.com (Rajeev Shorey)
Date: Tue, 18 Sep 2007 21:50:55 +0530
Subject: [e2e] ACM SenSys 2007 -- Call for Participation
In-Reply-To: <942a90780709180920o59677b36m5c1c86a20ab35db7@mail.gmail.com>
References: <942a90780709180913g1f604063yd0a3da7df6a06da0@mail.gmail.com>
<942a90780709180915s6a56d26ct437b3d12c2fb942b@mail.gmail.com>
<942a90780709180920o59677b36m5c1c86a20ab35db7@mail.gmail.com>
Message-ID: <942a90780709180920o1f25df1av503dbc59835ccfda@mail.gmail.com>
May we request you to widely circulate the CF Participation of ACM SenSys
2007.
ACM SenSys 2007: Call for Participation
The 5th ACM Conference on Embedded Networked Sensor Systems
November 6-9, 2007
Sydney, Australia
http://sensys.acm.org/2007/
============================================================
Sponsored by ACM SIGCOMM, SIGMOBILE, SIGARCH, SIGOPS, SIGMETRICS and SIGBED.
The 5th ACM Conference on Embedded Networked Sensor Systems (SenSys) is a
highly selective, single-track forum for the presentation of research
results on systems issues in the area of embedded, networked sensors.
Distributed systems based on networked sensors and actuators with embedded
computation capabilities enable an instrumentation of the physical world at
an unprecedented scale and density, thus enabling a new generation of
monitoring and control applications. This conference will provide an ideal
venue to address the research challenges facing the design, deployment, use,
and fundamental limits of these systems. Sensor networks require
contributions from many fields, from wireless communication and networking,
embedded systems and hardware, distributed systems, data management, and
applications, the papers will cover cross-disciplinary work.
*Keynote Speaker*: Wednesday, 7 November 2007
Seth Goldstein (CMU), "On the Path Towards Programmable Matter"
*Workshops*: Tuesday, 6 November 2007
This year two workshops on current emerging topics in sensor networks will
be held in conjunction with SenSys. In addition, there is a Doctoral
colloquium.
SenseID: Convergence of RFID and Wireless Sensor Networks and their
Applications
Sensing on Everyday Mobile Phones in Support of Participatory Research
SenSys Doctoral Colloquium
*"Soap Box" Talks*:
A series of 5 minute talks providing strong, controversial, and/or
outrageous opinions on a topic within the scope of SenSys, e.g., direction
the field should/should not take, future predictions, etc.
*SenSys 2007 Organizing Committee:*
General Chair: Sanjay Jha (U. New South Wales)
Program Co-Chairs: Phillip B. Gibbons (Intel Research), Akos Ledeczi
(Vanderbilt)
Poster Co-Chairs: Nirupama Bulusu (Portland State), Rachel Cardell-Oliver
(U. Western Australia)
Demo Co-Chairs: Suman Nath (Microsoft Research), Max Ott (NICTA, Australia)
Workshop Chair: Andreas Savvides (Yale)
Student Award Chair: Alberto Cerpa (UC Merced)
Local Arrangements Chairs: Subhash Challa (U. Technology, Sydney), Salil
Kanhere, (U. New South Wales)
Publicity Co-Chairs: Rajeev Shorey (GM Research, India), Guoqiang Mao (U.
Sydney)
Web Chair: Wen Hu (CSIRO, Australia)
Registration Chair: Ren Liu (CSIRO, Australia)
Publications Chair: Adam Dunkels (SICS)
Finance Chair: Chun Tung Chou (U. New South Wales)
Steering Committee Chair: John Heidemann (USC)
*Program Committee*:
Tarek Abdelzaher (UIUC), Gaetano Borriello (U. Washington), Andrew Campbell
(Dartmouth), Peter Corke (CSIRO, Australia), Richard Han (U. Colorado), Tian
He (U. Minnesota), John Heidemann (USC), Ted Herman (Iowa), Polly Huang
(National Taiwan U.), Brad Karp (U. College London), Phil Levis (Stanford),
Jie Liu (Microsoft Research), Chenyang Lu (Washington U. in St. Louis), Sam
Madden (MIT), Miklos Maroti (U. Szeged, Hungary), Margaret Martonosi
(Princeton), Lama Nachman (Intel Research), Kay R?mer (ETH Zurich), Mani
Srivastava (UCLA), John Stankovic (U. Virginia), Subhash Suri (UCSB), Thiemo
Voigt (SICS, Sweden)
*Sponsors*:
Academic sponsors: SIGCOMM, SIGMOBILE, SIGARCH, SIGOPS, SIGMETRICS, SIGBED
*Corporate sponsors: *
Silver: Intel, UNSW, ACORN, CSIRO
Bronze: AARNet, NICTA, Archrock, Google, Crossbow
All details regarding ACM SenSys 2007, including Preliminary Program,
Workshops and Registration can be seen at the following URL: *
http://sensys.acm.org/2007/*
**
**
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20070918/48ef05f1/attachment.html
From gdt at gdt.id.au Fri Sep 21 00:18:06 2007
From: gdt at gdt.id.au (Glen Turner)
Date: Fri, 21 Sep 2007 16:48:06 +0930
Subject: [e2e] opening multiple TCP connections getting popular
In-Reply-To: <7e12cc153d26c4072bc1bf0d5d91a939@mac.com>
References: <5.2.1.1.2.20070829162659.039f4b18@pop3.jungle.bt.co.uk>
<46D5B665.6090800@reed.com> <E1IQSg1-00068s-00@mta2.cl.cam.ac.uk>
<aa7d2c6d0708291422o4f554fefta367f9209a4e32f8@mail.gmail.com>
<E1IQVLI-0000jO-00@mta2.cl.cam.ac.uk>
<1188454695.3723.23.camel@pc105-c703.uibk.ac.at>
<0202239B-D3C8-4AC6-8CEE-B97F79475B2F@nokia.com>
<1188550774.3711.97.camel@pc105-c703.uibk.ac.at>
<46D80A85.6080707@reed.com> <7e12cc153d26c4072bc1bf0d5d91a939@mac.com>
Message-ID: <1190359086.1586.44.camel@roma.44ansell.gdt.id.au>
On Fri, 2007-08-31 at 08:07 -0700, rick jones wrote:
> On Aug 31, 2007, at 5:33 AM, David P. Reed wrote:
>
> > It's fascinating to me that Window Scaling (an end-to-end option)
> > would be screwed by bugs in *routers*.
>
> If my experience interacting with end users in netnews is
> representative, these "routers" are likely as not the
> NAT/firewall/switch boxes like the one sitting between me and my DSL
> line at the moment. They get branded with the term "router" all the
> time.
The problem is well described at
http://lwn.net/Articles/92727/
and in the threads at
http://oss.sgi.com/archives/netdev/2004-07/msg00146.html
http://kerneltrap.org/node/6723
The known faulty equipment is:
Cisco PIX NAT feature corrupting in presence of SACK and window
scaling. I don't have a Cisco bug ID for that -- the Cisco bug
navigator requires the specific version of software to be
known to hunt for a bug, which makes finding historical bugs
hard. You would presume that people kept their firewall software
up-to-date, but the PIX had a bug where it filtered packets with
IP.ECN != 00 and that took years to disappear.
Linux routers running the Netfilter firewalling package with
the tcp-window-tracking module from the Netfilter Patch-o-matic.
This bug was fixed in May 2003
http://oss.sgi.com/archives/netdev/2004-07/msg00261.html
but made it into a lot of domestic appliance firewall/routers
in 2002-4. Workaround is to disable firewall, fix is to
upgrade software (which may not be possible since many
manufacturers don't support older models and the source
code for self-support is often not available, despite the
GPL).
It is suspected that other faults exist, simply because of the
number of bandwidth-shaping middleboxes which munge with the TCP
window.
Best wishes, Glen