В сторону RVSP можете посмотреть.

Ну вообще, "умная очередь", про которую вы говорите, это частично и есть средства реализации QoS.

Ну а если именно для курсовика и с моделированием, то конечно можно изобрести велосипед - сделать несколько очередей по типу траффика и запускать пакеты в сеть по какому-нибудь принципу к примеру, RoundRobin с весами или стохастической диспетчеризации.

Моделирование с очередями рассмотрел мой научный руководитель, он изложил все результаты в своей работе. Мне надо же изобрести не велосипед.. думаю что-то на много сложнее. Мне надо надо написать протокол, который бы позволял граничным узлам как-то договориться, чтобы не грузить сильно ядро... Я даже не могу найти пример алгоритма такого протокола.... У кого-нибудь есть какие-нибудь идеи?

Повторяю, почитайте про RVSP - не совсем оно, но идеи можно почерпнуть. Может попутно и найдёте ещё что-нибудь.

Хм, если уже про технологию в предыдущем посте (хотя, если речь именно о протоколе резервирования ресурсов, то он всё-таки RSVP называется), можете взглянуть ещё на следующие темы, тоже вполне полезно - HSRP, VRRP, GLBP. В основном, они сделаны для отказоустойчивости, но для иллюстрации балансировки нагрузки тоже сойдут.

Nookie, а вуз случаем не МИЭМ?



З.Ы. мелькнула мысль: а почему должны договариваться именно граничные узлы? Должно договариваться ядро между самим собой =)
Но если обязательным условием является, что именно граничные, причём от каждого граничного узла есть канал минимум до двух устройств, входящих в состав ядра, (как оно и бывает обычно), перечисленные выше 3 технологии очень даже в тему.. хотя разговаривают там всё равно элементы ядра, насколько я помню.. 

Это сообщение отредактировал(а) Nicos - 15.12.2007, 06:47

Да, точно RSVP. Прошу прощения за дезинформацию.

Нет, я не с этого вуза. Мне было сказано, что все эти протоколы не подходят....

Вопрос стоит о справедливо разделении ресурсов на входе в сеть, то есть на граничном узле. пусть у нас присутствуют 2 типа работающих приложений, "жадные" и "хорошие", к жадным относятся к примеру закачка файлов, а "хорошие"  - это например передача звука. на входе в сеть мы разделяем каким-нибудь образом все потоки и находим оченку сверху выделяймой для них полосы пропускания, эту оценку нужно найти так, чтобы "хоршие" приложения работали хорошо, а "жадные" нормально, все равно этот файл когда-нибудь закачается. Вот в этом состоит наша задача. Главная проблема состит в том, чтобы выделять как-то полосы и нахождение этой оценки сверху интенсивности потока. У кого-нибудь есть мысли по этому поводу??

Ну дык вот она и есть эта технология, о которой и говорилось выше, скажем, у Cisco, да и не только:

Traffic policing, Traffic shaping
Это, условно говоря, раздача необходимой полосы пропускания, а далее и параметров качества обслуживания (Quality of Service, QoS) определённым типам трафика и система очередей (WFQ, CBWFQ)

На типы трафика исходный трафик делится технологией NBAR (Network-Based Application Recognition). По заголовку пакета, путём анализа информации верхних уровней определяется тип приложения (список сигнатур часто обновляется) и соответственно применяется правило для этого типа приложений - а дальше, когда трафик уже определён и промаркирован, управлять им можно как угодно, средств для этого полно. 

Детали - в документе Cisco BCMSN Certification Guide - тут его нельзя выкладывать, но найти можно.