Here is roughly the focus of the discussion after the presentation.
Feasability of distributing SEDA across many systems will require catering the software to the system it will be running on. Still it should be noted that this will give you good performance but will often lead down a path that you don't want to go on and that is specifying your system to the hardware it will be running on. SEDA is designed to be more of a general purpose platform capable of getting the best performance out of whatever hardware is running it.
It should be noted that fairness rises from some of the general issues surrouding TCP/IP. The exponential back-off of TCP connect attempts is a major factor but congestion control also contributes to slower response times on a busy network. It's difficult to compensate for protocol issues in your application.
Issues surrounding fairness in general, is it right for a server to expect people to refresh to receive their pages? Should we expect them to? How to compensate for this? So far it seems there is not perfect solution to the problem. Perhaps some of the problem lies in the fact that it is difficult to tell what knowledge our users should have and how much we are able to predict their actions. This is a difficult problem so it's logical that the solution will be hard to identify.
YouTube rose as an example of some of these difficulties. YouTube is a service that has grown tremendously in the past couple of years and requires high throughput and low response times to make sure video is streamed efficiently to the clientts. This is one case where fairness may not necessarily be what you want because a 500ms delay in packets will make streaming impossible. On the other hand you don't want your clients to wait one minute just to start their streaming because the server is full. It is difficult to evaluate what's right for your clients so you must be cautious when making these key decisions.