RE: Scheduling unpleasantness

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Iljitsch,

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

	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
	nature;
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
Ericsson  

> -----Original Message-----
> From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] 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@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
> 
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]