There is perhaps no need for the link layer ARQ mechanism to tell TCP to
retransmit, since, as Phil has rightly pointed out, it can do the
retransmission itself. BUT, there is always a need for the link layer to
tell TCP NOT TO RETRANSMIT when it itself is doing retransmissions. One way
to achieve the same goal is to stop the link layer retransmissions and let
TCP recover. Question is when?
The link layer retransmissions should be continued to the maximum possible
amount of time in order to get the maximum benefit out of it, making sure
that TCP's RTT doesn't timeout. But since this RTO estimation can be a
highly variable quantity (thanks to some previous retransmissions over a
GSM/CDMA radio link with ~ 100 ms delay and Jacobsen's algorithm), there
seems to be a need of "link-layer awareness for TCP " or "TCP-layer
awareness for the link layer", particularly for high FER conditions.
-Sanjoy
-----Original Message-----
From: adfalk@mail.hac.com [SMTP:adfalk@mail.hac.com]
Sent: Wednesday, January 27, 1999 11:30 AM
To: padmanab@microsoft.com; karn@homer.ka9q.ampr.org
Cc: rludwig@cs.berkeley.edu; pilc@lerc.nasa.gov
Subject: LL ARQ on LD links [was: PILC: prioritization]
Does anyone have real-life experience running TCP over
link-level ARQ
with a long delay (i.e. GEO satellite) link? I'm curious about
the
impacts on RTO of ARQ-induced jitter that comes in half-second
multiples. What about effects of initial RTO settings?
--aaron
______________________________ Reply Separator
_________________________________
Subject: RE: PILC: prioritization
Author: karn@homer.ka9q.ampr.org at mime
Date: 1/26/99 8:21 PM
Even for radio links where this isn't true, I still feel pretty
strongly that TCP should not have to be "educated" about
noise-induced
errors on wireless links when there exists a much more focused,
effective and cleanly-layered solution to the problem: link-level
ARQ
and FEC. If the link layer is going to the effort to generate a
"link
level error" message to tell TCP to retransmit, why shouldn't it
just
retransmit the packet itself?
RFC-822-headers:
Received: from CONVERSION-DAEMON by mail.hac.com (PMDF V5.1-12
#26580)
id <0F6700201B2FXH@mail.hac.com>; Tue, 26 Jan 1999 20:27:53 -0800
(PST)
Received: from PROCESS-DAEMON by mail.hac.com (PMDF V5.1-12 #26580)
id <0F6700201B2EXE@mail.hac.com>; Tue, 26 Jan 1999 20:27:51 -0800
(PST)
Received: from fw-es05.hac.com by mail.hac.com (PMDF V5.1-12 #26580)
with ESMTP id <0F6700265B2E0R@mail.hac.com>; Tue,
26 Jan 1999 20:27:50 -0800 (PST)
Received: from assateague.lerc.nasa.gov ([139.88.112.23])
by fw-es05.hac.com (8.9.0/8.9.0) with ESMTP id UAA18586; Tue,
26 Jan 1999 20:30:29 -0800 (PST)
Received: (listserv@localhost) by assateague.lerc.nasa.gov
(NASA LeRC 8.7.4.1/2.01-main) id XAA12510; Tue,
26 Jan 1999 23:27:54 -0500 (EST)
Received: from homer.ka9q.ampr.org (fw01.lerc.nasa.gov
[139.88.145.14])
by assateague-fi.lerc.nasa.gov with ESMTP (NASA LeRC
8.7.4.1/2.01-main)
id XAA11601; Tue, 26 Jan 1999 23:21:42 -0500 (EST)
Received: (from karn@localhost) by homer.ka9q.ampr.org
(8.8.8/8.8.8/Debian/GNU)
id UAA30249; Tue, 26 Jan 1999 20:21:36 -0800
Date: Tue, 26 Jan 1999 20:21:36 -0800
From: Phil Karn <karn@homer.ka9q.ampr.org>
Subject: RE: PILC: prioritization
In-reply-to: <2FEED299C092D1118B3100805F6F41BD0CA58E70@RED-MSG-09>
(message from Venkat Padmanabhan on Thu, 21 Jan 1999 16:48:18
-0800)
Sender: owner-pilc@lerc.nasa.gov
Reply-to: karn@qualcomm.com
Message-id: <199901270421.UAA30249@homer.ka9q.ampr.org>
MIME-version: 1.0
Precedence: bulk
X-Authentication-warning: assateague-fi.lerc.nasa.gov: listserv set
sender to
owner-pilc@lerc.nasa.gov using -f
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:20 EST