Subject: Re: ICMP EaTEN message...

From: Nitin H Vaidya <[email-masked]>
Date: Mon, 10 Apr 2000 10:36:02 -0500 (CDT)

>> From: Jamshid Mahdavi <[email-masked]>
  ...
  >> So far, the score seems to be two votes against :-).

Here is a vote partially in favor and partially against -:)

There are two related possibilities for sending
ICMP EaTEN type message, of which only the first one
below seems to be considered in this thread:

* Unnecessary fast retransmits: As you note, the receiver
  may determine that a packet is corrupted, and inform its
  sender (provided that the header info is intact).

  This approach may be beneficial when the channel encounters
  a "random" loss (as opposed to an extended period of bad state).

  However, in such situations, as someone else also pointed out,
  it may be possible to implement link level retransmissions to
  deal with the transmission errors (for large delay*bw links,
  need to ensure that link layer delivers packets "almost" in-order).

* Unnecessary timeouts:
  An alternative situation that is not handled well by link level
  retransmissions is that of extended bad periods (for instance,
  driving through a tunnel with link broken, or losing connectivity
  during hand-off between non-overlapping cells, or a long error
  burst for whatever reason).

  I believe that explicit notifications are of greater value
  in such situations, than when you have occassional packet
  being corrupted by errors.
  In such cases, the ICMP can be generated at the base
  station rather than the wireless receiver, for packets
  destined to the wireless host (fortunately,
  the base station has packet header information available).

  If the lower layers would deliver some packets despite 
  the above events - such as the TCP kickstart proposal - then
  there is less need for a new ICMP even with bursty losses.

The second situation above is also why I do not much like
the name ICMP EaTEN (I agree it is cute, but could misrepresent
the cause of packet loss).

Regards.

- nitin

---

From: Vern Paxson <[email-masked]>
Date: Wed, 12 Apr 2000 22:56:10 PDT

> point taken. actually they made both comments (DOS and multipath).
> there may have been others (are there any minutes for tsvwg meetings?).

Here's the relevant portion of the draft minutes (which I'll send out
to the tsvwg list shortly).

		Vern

Link Outage ICMP Notification -- Gabriel Montenegro, Sun

Both link-outage and link-outage-over are useful. Link outage was a valid
message at one time, worth revisiting. Easy to send, no state, simple
synchronous response using ICMP which stacks and apps already know about:
use 'host unreachable' message. RFC1122 says IP must pass these messages
to transport. But can't overload existing 'unreachable' codes. Recommend
using code #8: 'host isolated.' Introduced for routers (IMPs, actually).
Contains enough message to identify originating host. Actions could include
local disk caching, activate browser use of caches, freeze timers, etc.
Possible issues include whether errors are hard or soft. Could decide
based on whether message comes from local host or router.

Steve Deering: some links will send 'destination unreachable' messages
    when link goes down. What is an example of a hard error?
Gabe: one in which the upper layers won't retransmit forever. Like unhooking
    ethernet during an NFS transaction.
Steve: would need an AI to guess what the right response is. Give me an
    example when you'd know what to do?

Geoff Houston: what about the denial of service implications? This would
    be a great way to take down a network.
(Steve: minumum ICMP format include IP header plus 8 bytes.)

Jamshid: ICMP net down + ICMP kick won't work to manage TCP because you
    can't be sure you'll get the kick.

Van Jacobson: because one router can't reach a destination doesn't mean
    the packets won't reach the destination. Most vendors tend to misinterpret
    this information. Many firewalls filter out these ICMP messages.
    Suggest you don't do this because you can't know enough about your
    topology except for very simple networks.

Steve: one use for ICMP message is to print out a diagnostic when application
    finally quits.

---

From: Sally Floyd <[email-masked]>
Date: Sat, 15 Apr 2000 19:09:07 -0700

>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.
 
One possibility for ETEN might be the following:  

Assume that the link-level protocol uses FEC and/or link-level
retransmission, as a good link-level protocol for a lossy link
should, but that, at some point, the link-level protocol decides
to give up on trying to retransmit the corrupted packet.  At this
point, the link-level *receiver* does not necessarily know the
correct packet header for the corrupted packet, but the link-level
*sender* does know the correct header.  So it would seem that the
link-level receiver could tell the link-level sender to send a
short notification message, to the correct destination, that the
link-level has given up trying to correctly transmit the data packet
with this packet header.  (Yes, this short message could get
corrupted also;  in this case, the loss will be interpreted by the
end node as a congestion-related loss.)

One possible scenario for ETEN is for a TCP that has had a single
packet loss, has detected this loss with Fast Retransmit, and has
successfully retransmitted this packet and reduced its congestion
window in half.  If the TCP sender learns, perhaps some time later,
that this loss was in fact due to corruption and not congestion,
then the TCP sender can, after the fact, "undo" its reduction of
the congestion window, by slow-starting back up to its previous
value.

(I don't know the correct response of a TCP sender to the routine
loss of packets due to corruption, but reducing the congestion
window in half in response to a single packet lost due to corruption
seems like overkill to me...)

A second possible scenario for ETEN would be for an unreliable,
unicast transport protocol that uses equation-based congestion
control (e.g., "http://www.aciri.org/tfrc/").  Instead of reducing
the sending rate in half in response to each specific packet loss,
with equation-based congestion control the sender adjusts the
sending rate to the TCP-compatible sending rate that fits the packet
loss rate observed over a longer time interval.  Again, if the
sender learns after the fact that a loss was due to corruption
rather than to congestion, then the sender could adjust its sending
rate appropriately (whatever is the appropriate adjustment of the
sending rate to occasional packet corruption).

Yes?  No?  Did I forget something?  

The ideas are that in cooperation, the link-level sender and the
link-level receiver should know the correct packet header for the
corrupted packet; and that it could be useful for the sender to find
that a loss was due to corruption rather than congestion even if
the sender receives this information some time after it has made
a congestion-control response to the packet loss.

- Sally
--------------------------------
http://www.aciri.org/floyd/
--------------------------------

---

From: Sally Floyd <[email-masked]>
Date: Tue, 18 Apr 2000 10:23:22 -0700

Nitin -

>The link level sender could do this without having to be told
>by the link level receiver.
>Is there a disadvantge to link level sender acting on its own?

No.  It is just that the link level sender has to know that the
link level receiver did not correctly receive the earlier transmission
of that packet.

>We have previously suggested a couple of related approaches
>(named Partial Ack, and Explicit Bad State Notification), which
>differ in the amount of information provided in the feedback
>to TCP sender (www.cs.tamu.edu/faculty/vaidya/mobile/).

Thanks, I will look at them.

>This may sounds like nitpicking, but I would suggest we
>also consider congestion versus non-congstion losses, rather than
>just congestion versus corruption (for instance, packet loss
>during hand-off is not a corruption loss, but has similar
>impact as a bursty error loss).

Yes, I agree.

- Sally

---

From: Sally Floyd <[email-masked]>
Date: Tue, 18 Apr 2000 10:30:21 -0700

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

I agree.  One of the purposes of the proposed D-SACK (duplicate-SACK)
extension to SACK, now finishing up its last call before going to
Proposed Standard
("http://search.ietf.org/internet-drafts/draft-floyd-sack-00.txt"),
is to allow the development of mechanisms that make TCP more robust
in the presence of out-of-order delivery of packets.  And TCP is not
likely to be the only transport protocol operating over future "wireless
links"...

- Sally