Subject: ICMP EaTEN message...

From: Jamshid Mahdavi <[email-masked]>
Date: 07 Apr 2000 13:23:41 -0700

[Now that it has a cute name, we'll just *have* to implement it :-)].

This is a summary of some discussion we had at the IETF on the concept
of an ICMP message for "Explicit Transmission Error Notification".  I
couldn't think of a good word that starts with "A" but "EaTEN" is
clearly the correct sentiment.

The basic problem, which has been discussed quite a bit in pilc, is
for wireless links.  It is impossible to completely avoid transmission
errors, and people in the WG have argued that in some cases providing
suitable amounts of FEC to reduce errors to a suitable low level is
too costly (for whatever reason).

As outlined in ERROR, losses due to transmission errors have a bad
impact on TCP.  TCP must assume that these losses are caused by
congestion (because there is no information to the contrary), and
therefore back off its congestion window.

The proposed solution, therefore, is to create a mechanism to
communication this information about corruption back to the sending
TCP.  I assume that the receiving wireless node computes a link-layer
checksum and determines that the packet has been corrupted.  Normally
at this point, it would simply drop the packet as it is no longer
forwardable.  In addition to dropping the packet, the proposal is to
send an ICMP EaTEN message back to the origin, in effect saying that
the packet was "eaten".  (The ICMP includes the original IP and TCP
headers).

The sending TCP would respond to this ICMP message in two ways.
First, it would immediately perform a fast retransmit of the corrupted
segment.  Second, because it knows that the loss was *not* due to
congestion, it would *not* reduce cwnd.  This would eliminate the
major detriment (to TCP) of having an error-prone link in the path.

(For security, the considerations discussed in TSVWG for Phil's ICMP
kick-tcp message would be need to be included.  I think this means
matching the ICMP messages to actual packet losses in order to
eliminate various forms of DoS attacks and probably also using some
type of detection for floods of these messages.  This also means that
you don't actually immediately retransmit the corrupted packet, but
still wait until you get 3 dupacks -- treating the ICMP message in an
advisory fashion.)

Note that with this solution, the error-prone hop can be anywhere in
the path; it is not restricted to being an endpoint.  And it works
fine whether there are 1 or 5 or 20 wireless hops in the path.

Cons to the EaTEN ICMP concept:

1. Phil posed the following question: if all this message is going to
   accomplish is to have TCP retransmit the packet, why not just have
   the link layer do this via an ARQ mechanism?  This would get the
   data there quicker, and be more efficient for the network.

2. The other problem is that if the part of the original segment which
   was corrupted included the packet headers, the ICMP might be sent
   to the wrong host or connection.

Since the IETF, I came up with a counter-argument for Phil's point.
If the link layer can accomplish the ARQ within 3 packets of the
original transmission, there is no problem.  However, if it takes
longer than this, it will be out of order by enough to trigger fast
retransmit anyway, which mean that the ARQ had no useful effect.

There are some things we can talk about doing to TCP to make this less
of a problem (basicly delaying fast retransmit under certain
well-defined circumstances), but for long delay links such as
satellites, this might not be possible to overcome.

I don't have a good answer for point 2.  I suppose the security checks
mentioned above would provide some insurance that a misrouted message
didn't do any harm, however.

I pose all of this to the list because I've heard suggestions from
various fronts that such a thing would be useful.  I've also heard a
lot of comments to the effect that if we just design the subnetworks
correctly in the first place, this doesn't need to be a problem.
Personally, I am entirely on the fence and am usually swayed by the
arguments of whoever I happen to have spoken with most recently.

--Jamshid

---

From: Bora Akyol <[email-masked]>
Date: Fri, 07 Apr 2000 17:38:51 -0700

One concern:

How does a wireless network router know who a corrupted packet belongs to
in a shared medium network so that it can send this message.

Very likely, what this will boil to is sending a message to all TCP
sessions that it has seen recently on this link.

This will work OK for wireless nodes that are transmitting to other nodes,
but for wireline nodes, the sheer number of them that are out there may
"eat" away at the benefits of such a message.

You are much better of giving some sort of piggy back feedback between
wireless nodes involved in the connection to their TCPs if they happen to
be at the same place.

For example:

if you have wireless router A, and wireless node B, then if B got some
sort of feedback on the link quality than it can give explicit feedback to
hosts that it has TCP connections to. If on the other hand two nodes
happen to be connecting through a wireless link, then we are out of luck.

In a nutshell, I think that this idea even though it sounds useful at
first, is really not that useful.

Regards

Bora Akyol

ps. You may want to check on some old research done in the late 70s, early
80s on wireless packet data networks if you have not done so already.

---

From: Jamshid Mahdavi <[email-masked]>
Date: 10 Apr 2000 07:34:15 -0700

> sessions that it has seen recently on this link.

This was not what I had in mind.  Rather, I thought that the router
could simply look at the IP header in the corrupted packet and hope
that the source IP address was not corrupted.  My assumption (not
knowing a lot about wireless) was that there is a reasonably good
chance that four bytes early in the packet would have made it through
OK.  However, perhaps this is not a good assumption...

> first, is really not that useful.

I'm not completely understanding your argument here, but it does sound
similar to other arguments against doing this sort of thing.  What I
hope to see on the mailing list is some consensus on whether this is
in fact a useful idea or not, and then change the text in section 4 of
the error draft to match.

So far, the score seems to be two votes against :-).

--J

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 10 Apr 2000 15:55:40 +0100 (BST)

> OK.  However, perhaps this is not a good assumption...

Depends on whether the IPv4 header checksum passed or not.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Bora Akyol <[email-masked]>
Date: Mon, 10 Apr 2000 11:05:04 -0700

Jamshid

There is no way for the receiver to know which particular pieces of the header
are corrupt when the checksum fails. Therefore you can assume that the source
address is OK.

Overall, this message will not be useful.

Regards

Bora

---

From: Reiner Ludwig <[email-masked]>
Date: Mon, 17 Apr 2000 10:22:28 +0200

>retransmit anyway, which mean that the ARQ had no useful effect.

Link layer ARQ is *commonly* implemented together with the in-order 
delivery property, i.e., no packet can "overtake" the other. Thus, the 
scenario you decribe is unlikely to happen in today's wireless systems 
implementing link layer ARQ.

///Reiner

---

From: Dr G Fairhurst <[email-masked]>
Date: Mon, 17 Apr 2000 12:55:10 +0100

I suggest we don't ***exclude*** the possibility of out-of-sequence
delivery
for future "wireless links" (i.e. RF environment).

Someone said, link layer ARQ is *commonly* implemented together with the
in-order
delivery property.... I agree.

Where the link delay is longer (an obvious example is packet satellite)
there
***may*** be advantage in allowing out of sequence delivery (by which I
mean the
receiver ARQ does not buffer correctly received out-of-sequence packets,
but forwards each good
packet on arrival, retransmitting any corrupted packets later
out-of-sequence). We have implemented
such schemes more than once in our lab based on a modified HDLC.,

N.B. Lack of sequencing may also arise from routing over alternate paths
/ links.

Gorry Fairhurst

P.S. I agree with nitin, we should talk about congestion losses (meaning
sender rate is too
high for the moment) with non-congestion losses (i.e. the loss is not a
function
of the sender rate, but is a function of RF environment, access
protocols, etc).