Subject: Re: ICMP EaTEN message...

From: Nitin H Vaidya <[email-masked]>
Date: Sun, 16 Apr 2000 10:07:47 -0500 (CDT)

>> From [email-masked] Sat Apr 15 21:20:53 2000
  >> To: Bora Akyol <[email-masked]>
  >> cc: pilc <[email-masked]>
  >> From: Sally Floyd <[email-masked]>
  >> Subject: Re: ICMP EaTEN message... 
  >> 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

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?

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/).

  >> 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.

This sounds like a good idea - if I understand correctly, Reiner
Ludwig's Eiffel algorithm behaves similarly.

  >> (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.

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).

- nitin

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

---

From: Dr G Fairhurst <[email-masked]>
Date: Tue, 18 Apr 2000 11:23:54 +0100

> Is there a disadvantge to link level sender acting on its own?

What you say is entirely possible - but I guess it is wise to provide
this on a best effort basis - would the "request for the notification message"
take a similar bandwidth to a NAK?

As you say, it is probably only wise to send the notification itself using a
best effort service - or you end-up needing reliability mechanisms.
How valuable all this is will depend, I guess on the processes covering
the probability of loss.  In some cases this a shorter message may have
a better chance of transmission than a longer one. In a general wireless/RF
case, conditions could be very variable and this may not be necessarily so.

I wonder if the problem is that you really need complete information about
all losses being "link related" to inhibit CA. Whereas you only need one
unexplained loss to trigger CA?

> Ludwig's Eiffel algorithm behaves similarly.

Have you thought of what would happen if both congestion and link
loss were simultaneously present?  If you have one ICMP EaTEN
message per missing IP fragment (not MSS?) you may be convinced
that all losses are link related?

>   >> Yes?  No?  Did I forget something?

Are you suggesting a proxy/gateway?

> impact as a bursty error loss).

-Gorry Fairhurst.