[Top] [All Lists]

RE: Scheduling unpleasantness

2008-03-24 09:11:49

        I'm not sure that I would say that Philadelphia was
worse than most meetings, but it may have been from your

        This sort of scheduling problem is very well known
to be NP hard and trying to meet the scheduling conflict 
matrix for 1500 to 2500 people would make the "N" large.

        I've heard that it is already very difficult to find 
a scheduling solution that satisfies the conflict matrix of 
just the ADs and WG chairs for the meetings they have to 
attend (not taking into account the meetings they want to 
attend as well - where, in some cases, "want to attend" 
means they may miss something important fo their own WG or 
Area if they can't go).

        Given that the conflicts of ADs and WG chairs are -
for the most part - the result of fairly focused interests,
it is likely that there is still some degree of freedom in
the range of acceptable scheduling solutions.  This means
that it might be possible to further refine final results
to accomodate other people - except that there is not a
(well defined) mechanism for gathering input from others.

        And there are probably problems with defining a means
to collect input from others. A few that I can think of off
the top of my head are:

o       people might see this as some form of guarantee;
o       you can't reliably expect people to differentiate
        what they "want" from what they "need" when asking
        for this kind of input;
o       there are always going to be those people who are
        their companies only IETF "representative" and who
        have (as a result) an agenda lacking in focus;
o       the longer you wait in collecting input, the larger
        "N" gets, and the harder the problem is to solve in
        any reasonable amount of time;
o       I'm not sure how much super-computer time the IETF
        can afford to consume to solve a problem of this
o       etc.

        One approach to address at least these issues is to
consider (perhaps as an experiment) adding a check-list of
meetings people would like to attend to the registration
form, taking the first "P" people to register (or however
many have registered by some date in advance) and applying
their input to attempt to refine the solution for only the
areas where there are degrees of freedom in the range of
solutions already determined from AD and WG chair input (we 
can't bump a WG chair out of being able to attend a WG 
meeting).  We would also have to make it clear that this 
would only be used for the very limited scope implied, for
those people who elect to give input.

        This could be an optional portion of the registration
- reached perhaps by clicking on a button for those people
who want to try taking advantage of it.

        Of course, a simpler alternative would be to try to 
stick to a fixed schedule.  That way, it is more difficult
to find yourself in an unresolved scheduling conflict at
one meeting when you have not had the problem previously.
If you're trying to stick to a fixed schedule, you only 
have to solve the scheduling problem for the meetings that
need to be inserted or moved for some reason.

Eric Gray
Principal Engineer

-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On 
Behalf Of Iljitsch van Beijnum
Sent: Monday, March 24, 2008 10:41 AM
To: IETF Discussion
Subject: Scheduling unpleasantness

Finally back at the office today...

While it is a fact of life that sessions clash at IETF meetings, I  
must say that Philadelphia has been especially bad in this regard.  
Does anyone else have the same experience?

If it wasn't just me, I think it's time to look at the scheduling  
algorithm in some detail, because from where I'm sitting, 
it's broken.  
My interests are mainly in the internet area + some routing and  
congestion related issues. The int area pretty much had two sessions  
the whole week except on friday, so I guess that avoiding overlap  
there is unavoidable. But there were instances where there were five  
of int, tsv, rtg and irtf routing/congestion at the same time.

IETF mailing list

IETF mailing list