[e2e] Open the floodgate

[Cannara]

David, long, complex DLC links, which IP never sees, do a very great deal of
management regarding error and flow issues.  If a packet is lost on a link,
nothing need happen for TCPcannara, because it hasn't been told there's
congestion -- it just continues sending at the same rate and resends the lost
packet when the receiver does Repeated Ack, etc.  No ay problemos.  The
problem is not communication of errored events, but the blind lumping of them
with congestion, because we never bothered to inform ends of congestion until
ECN.

Alex

"David P. Reed" wrote:
> 
> 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).
> 
>                  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?
> 
> 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.
> 
> 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.

.