Coordinated scheduling is similar to your idea, but the packet itself
carries the delay/time information. u can find the work in
www.ece.rice.edu/~knightly
Best regards,
Huirong
----- Original Message -----
From: Ashutosh Tayshete <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, February 12, 2002 9:19 AM
Subject: a DOUBT regarding FECN type transmission for video traffic
> Dear Sir/Madam,
>
> I am a post-graduate in Elec.Engg. at IIT BOMBAY, doing my final
> yr thesis report on congestion and admission control especially regarding
> bursty traffic and how to avoid congestion in the forward path. I am
> interested mainly in the theoretical aspect of this study.
>
> I hope for pure academic help.
>
> I have a singular doubt which is expressed below. Please help me out
> 1) by pointing out any points I have WRONGLY ASSUMED.
> 2) any suggestions.
> 3) any related work in THIS area.
>
> We assume
> a)real-time traffic.
> b)every 'packet' consists of how much data a frame might contain.(thus our
> packet-size here is TIME_VARYING.. VBR traffic.) packet/sec is thus
> proportional to data/sec which probably makes MOST sense.
>
> MODEL:
> Suppose bursty traffic flows through nodes 1 through N, with its source as
> node 0, client as node N.
>
> What is the problem in the following method:
>
> 1)as soon as a burst is identified at node 1, send a message (an elaborate
> form of FECN) to node 2, which further carries this message forward. This
> message contains the packet_id no and the burst size of the 'bursty
packet'.
>
> 2)now as soon as 2 receives this small message along with the packet id_no
> of the burst, it transmits it with utmost prioirty to node 3..and so on.
>
> 3)due to traffic problems and the high priority assigned to this message,
> it will bound to travel much faster than the actual burst.
>
> 4) then we could find some scheme to try and avoid congestion in the
> future, since we have SOME idea of the BURSTINESS that is to ensue in the
> near future. (this part is feasible!)
>
>
>
>
>
