ietf
[Top] [All Lists]

Re: a DOUBT regarding FECN type transmission for video traffic

2002-02-12 13:40:03


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 <tosh(_at_)ee(_dot_)iitb(_dot_)ac(_dot_)in>
To: <ietf(_at_)ietf(_dot_)org>
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!)








<Prev in Thread] Current Thread [Next in Thread>