[e2e] Open the floodgate

David P. Reed dpreed at reed.com
Fri Apr 23 07:03:19 PDT 2004


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.



More information about the end2end-interest mailing list