[e2e] Open the floodgate

[Michael Welzl]

> At 07:08 AM 4/23/2004, Michael Welzl wrote:
> >Still, my question remains: why don't we have these separate
> >checksums as a TCP option? It strikes me as a rather simple
> >method for links where erroneous data are actually handed
> >over, and I believe that it's about time we transferred these
> >things from the world of research into the IETF.
>
> Let's say we implement what Cannara is calling for. A very simple thought
> experiment:  if a packet is lost on a link, and it is possible to signal
to
> one end or the other that data was lost due to an error, how would this
happen?
>
> Call the sender A and the receiver B .   A wraps packet.   Sends bits to
> B.   B receives something or nothing.  B gets:
>          Something, and is OK.   We forward it.
>          Something, and is garble, but we think we know its source and
dest
> address: IP header checks out..
>
>                  Does B discard it?   Not unless it has a separate link
> level checksum.
>                  If not, The dest endpoint would know that a packet
>                  was garbled, and be less likely to respond as if
> congestion (though if the link is
>                  wireless, congestion is a major cause of garble - packet
> loss rates are load driven).

This is why I wouldn't necessarily recommend to the TCP sender
to act as if _NOTHING_ had happened - but it might make sense
to implement a less severe reaction to this type of congestion because
TCP CC. was designed to react upon overloaded queues - link
layer MAC is already designed to deal with this type of overload.

Let's say TCP CC. wouldn't react to erroneous bits in the payload
at all - the link layer could try to cope with it via its MAC mechanism.
If it keeps getting flooded by the sender and just can't deal with it,
it can still drop an erroneous packet every once in a while; what we
now have is implicit communication between the wireless link
somewhere along the path and TCP, somewhat similar to the
way RED communicates with TCP.


>                  If so, B would have discarded it, and perhaps asked A to
> retransmit.
>                  but if B did forward it, what would happen?  it would not
> be confused with congestion.
>                  Is it an improvement to have A retransmit or to have the
> end-point retransmit?
>
>          Something, and is garble, and we need to resync the link to make
> sense of the stream.
>                  We cannot do much, but if we need to know what packets
> were lost, we have
>                  to get them from A.   Why doesn't A just retransmit them
> to B, then?

I'm not against having A retransmit - the A-B connection may be much
shorter than the end-to-end TCP connection, after all. This is however
not always practical; if A-B had perfect persistence (i.e. would just
retry endlessly), A would require an endless buffer. So, in reality, most
link layers seem to give up after a while. In such a case, B shouldn't
just drop the data in my opinion but rather forward it to inform B of
the problem.


> The point here is that implementing a signal that differentiates ACTUAL
> congestion (not "ECN") requires the same work that link-level error
> correction requires - it requires A to keep a list of unacked packets that
> can then be transformed into such notifications.

Hm, but the point is to avoid TCP's multiplicative decrease in response
to a packet that was not dropped in a queue but just garbled along the
way. This, of course, doesn't solve the retransmission problem - but,
as I said above, link layer retransmission has its limits. If B just decides
to give up after a while, dropping the data doesn't help much.

I'm not trying to make a statement against link layer ARQ here; all I
say is that link layer designers should be motivated to have their
link layers occasionally forward erroneous data (in situations when
link layer ARQ fails). This option is available in some link layers already
(see the URL in my previous mail).


> The one possible improvement is the deliberate forwarding of garbled
> packets that still have a reliable IP header, which is in fact what is
done
> when there is no separate link level error correction.

Hm? This is exactly what I'm proposing - only forward packets that still
have a reliable IP header, at least SOMETIMES, or in special situations
(e.g., when link layer ARQ fails). Without a working header, everything
is useless ... but if TCP has some means to detect that bit errors occured
only in the payload and the headers are still intact, a more reasonable
congestion avoidance decision could be made.

Cheers,
Michael