[e2e] Scheduling+ARQ
Craig Partridge
craig at aland.bbn.com
Mon Dec 19 06:07:11 PST 2005
I think the second solution is the only right one.
In the first case, when ARQ is retransmitting, it will use more bandwidth than
it was scheduled for.
Craig
In message <43A6A118.2070709 at gmail.com>, Khaled Elsayed writes:
>This is a multi-part message in MIME format.
>--------------020408050401050103030602
>Content-Type: text/plain; charset=us-ascii; format=flowed
>Content-Transfer-Encoding: 7bit
>
>Hi All,
>
>Given a link-level QoS-oriented scheduler on a system implementing
>link-level ARQ, I am trying to make a choice between the following
>architectural alternatives:
>
>1- Alternative 1: When a packet/frame arrives at the data link layer it
>is first handled by the scheduler. When the packet is scheduled for
>transmission and it belongs to an ARQ-enabled connection it is
>forwarded to the ARQ subsystem which updates its state machine and then
>the packet is forwarded over the PHY (transmission) queues. In this
>case, the problem is when a packet is lost, how to reschedule the
>retransmission of the packet in a way that keeps the order of the
>original packet stream?
>
>2- Alternative 2: When a packet/frame arrives at the data link layer,
>it is checked if it belongs to an ARQ-enabled connection, if so it is
>forwarded to the ARQ subsystem and after the state machine update it is
>forwarded to the scheduler., The scheduler schedules the packet among
>those in its queues and then the packet is forwarded to the PHY
>tranmission queues. In this case if a packet is lost, the ARQ system
>will simply send the packet to the scheduler keeping the original order.
>
>In other words, do we have:
>
>------ ------ ------
> | --> | --> |
>------ ------ ------
>SCH ARQ TX
>
>OR
>
>------ ------ ------
> | --> | --> |
>------ ------ ------
>ARQ SCH TX
>
>
>I am more inclined towards the second for better handling of
>lost/dropped packets, but for some reason (actually just a feeling :) I
>think there is some architectural mistake in doing that (I always
>thought that ARQ is tighthly coupled with the PHY TX queues). Any comments?
>
>Thanks,
>
>Khaled Elsayed
>
>
>
>--------------020408050401050103030602
>Content-Type: text/html; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
><html>
><head>
> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
> <title></title>
></head>
><body bgcolor="#ffffff" text="#000099">
><font color="#333399"><big>Hi All,<br>
><br>
>Given a link-level QoS-oriented scheduler on a system implementing
>link-level ARQ, I am trying to make a choice between the following
>architectural alternatives:<br>
><br>
>1- Alternative 1: When a packet/frame arrives at the data link layer it
>is first handled by the scheduler. When the packet is scheduled for
>transmission and it belongs to an ARQ-enabled connection it is
>forwarded to the ARQ subsystem which updates its state machine and then
>the packet is forwarded over the PHY (transmission) queues. In this
>case, the problem is when a packet is lost, how to reschedule the
>retransmission of the packet in a way that keeps the order of the
>original packet stream?<br>
><br>
>2- Alternative 2: When a packet/frame arrives at the data link layer,
>it is checked if it belongs to an ARQ-enabled connection, if so it is
>forwarded to the ARQ subsystem and after the state machine update it is
>forwarded to the scheduler., The scheduler schedules the packet among
>those in its queues and then the packet is forwarded to the PHY
>tranmission queues. In this case if a packet is lost, the ARQ system
>will simply send the packet to the scheduler keeping the original
>order. <br>
><br>
>In other words, do we have:<br>
><br>
>------ ------  
>; ------<br>
> | --> &nb
>sp; | -->  
>; |<br>
>------ ------  
>; ------<br>
>SCH ARQ  
>; TX<br>
><br>
>OR<br>
><br>
>------ ------  
>; ------<br>
> | --> &nb
>sp; | -->  
>; |<br>
>------ ------  
>; ------<br>
>ARQ SCH &nbs
>p; TX<br>
><br>
><br>
>I am more inclined towards the second for better handling of
>lost/dropped packets, but for some reason (actually just a feeling :) I
>think there is some architectural mistake in doing that (I always
>thought that ARQ is tighthly coupled with the PHY TX queues). Any
>comments?<br>
><br>
>Thanks,<br>
><br>
>Khaled Elsayed<br>
><br>
><br>
></big></font>
></body>
></html>
>
>--------------020408050401050103030602--
More information about the end2end-interest
mailing list