Re: stds-80220-requirements: 4.1.9 Latency- ARQ loop delay
Samir,
I agree with your comments below. Low ARQ loop times are necessary
to limit large latencies and jitter in challenging rf environments.
I think that maintaining latencies consistent with latencies
common in wired broadband systems is an important objective and
differentiator for 802.20. For example, DSL connections that I have
typically seen achieve round trip ping times in the 10ms range.
Many IP applications are highly transactional in nature and
so latencies can quickly add up to limit performance even if
data rates are quite high. For example, a simple web page download
can consist of 50 or more transactions (requests for objects).
Over the air latencies can quickly add up in such a scenario
and will be the key limitation in performance no matter how high the
link speed.
We should therefore scrutinize any reduction in system performance
affecting latency with the same scrutiny we would apply to a reduction
in target data rates.
Mike
On Thu, Oct 30, 2003 at 02:06:17PM -0500, Kapoor Samir wrote:
> Marianna,
> I think the "3rd frame" you're mentioning is a ack/nak control message, not a data frame and is counted within the round trip latency. It is common for many systems to support multiple frame sizes, including longer ones, so I believe the intent of the requirement in the PAR was to require at least one (realistic) configuration that meets these latencies. The issue with longer ARQ loop times is not just for voice, it impacts overall latency after retransmissions for every traffic type, particularly under harsh conditions. The fact the some types of traffic may "tolerate" it better than others does not necessarily mean that their performance is not impacted (e.g. TCP/IP). It also impacts the tolerable underlying error rates that the physical layer can operate at (and its corresponding impact on choice of coding and modulation options, utilised power and bandwidth etc).
> Regards,
> Samir
>
> -----Original Message-----
> From: Marianna Goldhammer [mailto:marianna.goldhammer@alvarion.com]
> Sent: Thursday, October 30, 2003 12:09 PM
> To: Li Junyi; Jin-Weon Chang; stds-80220-requirements@ieee.org
> Subject: RE: stds-80220-requirements: 4.1.9 Latency- ARQ loop delay
>
>
> Li,
>
> 1. Probably 3 frames will be needed for most of implementations
>
> 2. For systems targeting SDMA, the MAC frame will be longer than 3-4ms.
>
> 2. For VoIP, not necessarely one needs retransmissions, the codecs are tolerant to packet losses.
>
> Regards,
>
> Marianna
>
> -----Original Message-----
> From: Li Junyi [mailto:Junyi_Li@flarion.com]
> Sent: Thursday, October 30, 2003 5:56 PM
> To: Marianna Goldhammer; Jin-Weon Chang; stds-80220-requirements@ieee.org
> Subject: RE: stds-80220-requirements: 4.1.9 Latency- ARQ loop delay
>
>
>
> Jin,
>
>
>
> I am a little puzzled by your estimation. Note that when a physical frame is transmitted, it is also received at the same time. Unless the receiver has to take the entire time duration of a physical frame to finish the decoding after the frame has been received, the ARQ loop delay seems to be dominated by the two TX physical frames, not four.
>
>
>
> In addition, the use of small frame size is not uncommon in other technologies. For example, in HDR, the slot time is 1.66ms. Voice traffic often has delay constraint of 20 or 40 ms. Considering the scheduling jitter and retransmission requirement, 10 ms ARQ loop delay does not seem to be terribly small.
>
>
>
> Regards,
>
>
>
> Junyi
>
>
>
> -----Original Message-----
> From: Marianna Goldhammer [mailto:marianna.goldhammer@alvarion.com]
> Sent: Thursday, October 30, 2003 8:05 AM
> To: Jin-Weon Chang; stds-80220-requirements@ieee.org
> Subject: RE: stds-80220-requirements: 4.1.9 Latency- ARQ loop delay
>
>
>
> Jin,
>
>
>
> I agree with your comments.
>
>
>
> In my understanding, video teleconf needs the lowest delay, I guess
>
> that 40-50ms for ARQ loop delay should be enough.
>
>
>
> Regards,
>
>
>
> Marianna
>
> -----Original Message-----
> From: Jin-Weon Chang [mailto:jwchang1@samsung.com]
> Sent: Thursday, October 30, 2003 4:16 AM
> To: stds-80220-requirements@ieee.org
> Subject: stds-80220-requirements: 4.1.9 Latency- ARQ loop delay
>
> Dear colleagues,
>
>
>
> In the section 4.1.8 Latency "ARQ loop delay" is required to be less than 10ms.
>
> If I understand the ARQ loop delay correctly, it includes
>
> - TX time of a physical frame,
>
> - Propagation time over the air,
>
> - RX time of a physical frame,
>
> - Processing time for acknowledgement,
>
> - TX time of a ACK/NACK frame,
>
> - Propagation time over the air, and
>
> - RX time of an ACK/NACK frame.
>
> ARQ loop delay includes 4 times of physical frame
>
> if we assume ACK/NACK information is transffered in a physical frame.
>
> Limiting the delay within 10ms results in limiting the size of a physical frame
>
> less than 2.5ms.
>
> This requirement will highly restrict physical design of MBWA.
>
> I think the size of a physical frame should be determined
>
> considering not only delay factor but also many other factors.
>
>
>
> Thus I would like to propose that 10ms requirement in ARQ loop delay be removed.
>
>
>
> Best regards,
>
> Jin
>
>
>
>
>
> This mail passed through mail.alvarion.com
>
> ************************************************************************************
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
> ************************************************************************************
>
> This mail was sent via mail.alvarion.com
>
> ************************************************************************************
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
> ************************************************************************************
>
>
> This mail passed through mail.alvarion.com
>
> ************************************************************************************
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
> ************************************************************************************
>
>
> This mail was sent via mail.alvarion.com
>
> ************************************************************************************
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
> ************************************************************************************
>
>