Subject: [tcpm] RE: [e2e] Open the floodgate

From: Michael Welzl <[email-masked]>
Date: Fri, 23 Apr 2004 13:08:52 +0200

Hi, 
 
I like this approach, and I know lots of related papers; 
I believe I even saw a draft on something like this recently 
(perhaps in tcpm, or tsvwg?). I am very much in favor of 
these things. 
 
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. 
 
It's strange that we all know this problem and there are 
a billion related papers out there when my TCP/IP stack 
still doesn't do anything in this aspect. 
 
I'm cc'ing tcpm. 
 
Cheers, 
Michael 

Zitat von "Fu Cheng Peng, Franklin" <[email-masked]>: 
 
> One possible solution  to solve the loss type distinghishing between 
> congestion loss and random loss, seeing TCP Veno at JSAC Feb.. 2003, or 
> at http://www.ntu.edu.sg/home/ascpfu/veno.pdf 
>  
>  
> -Franklin 
>  
>  
> > -----Original Message----- 
> > From: [email-masked]  
> > [mailto:[email-masked]] On Behalf Of  
> > Michael Welzl 
> > Sent: Friday, April 23, 2004 1:41 PM 
> > To: Noel Chiappa 
> > Cc: [email-masked] 
> > Subject: Re: [e2e] Open the floodgate 
> >  
> >  
> > >     > a protocol that believes it needs to slow down  
> > whenever it sees a 
> > >     > packet loss. 
> > >  
> > > Look, we all have known for some time that i) TCP can't currently  
> > > distinguish between error loss and congestion loss, and ii) slowing  
> > > down for an error loss is a mistake.  (In fact, I'm losing horribly  
> > > these days because my mail is kept on a host which is on a network  
> > > which is losing packets, so I am personally aware of this issue.)  
> > > We're not cretins. You don't need to keep repeating it. 
> >  
> > So why don't we have separate header/payload checksums in TCP  
> > yet via a header option, as we now have in DCCP? 
> >  
> > (Potential problem: no coverage field for the regular  
> > checksum in TCP - so this option would have to redefine the  
> > semantics of the TCP header ... oh well - is that the reason?) 
> >  
> > Cheers, 
> > Michael 
> >  
> >  
>  

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: "David P. Reed" <[email-masked]>
Date: Fri, 23 Apr 2004 10:03:19 -0400

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

---

From: "Michael Welzl" <[email-masked]>
Date: Fri, 23 Apr 2004 18:34:52 +0200

> When you have erroneous packets (for whatever reaso other than
> congestion), who will inform about that? Maybe the addresses themselves
> are erroneous. Besides, some packets just get completely junked ...
> Special headers will not solve the problem.

This is a misunderstanding, and I guess it's because I didn't
give enough details - sorry!

So:

The idea is to have a second checksum that lets you distinguish
between an error that occured in the header and an error that
occured in the payload (e.g., a checksum that covers only the
header as opposed to the original TCP checksum that covers
header+payload). If the header is broken, I agree that there
is nothing you can do. However, if you know for sure that the
error was in the payload and all the header information is intact,
I don't quite see the point of doing standard TCP backoff as
if it was a congestion event.

Exactly this mechanism was introduced to DCCP by the name
of a Data Checksum option.

Cheers,
Michael

---

From: "Michael Welzl" <[email-masked]>
Date: Fri, 23 Apr 2004 19:52:04 +0200

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

>                  to get them from A.   Why doesn't A just retransmit them

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.

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

> 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

---

From: Saad Biaz <[email-masked]>
Date: Fri, 23 Apr 2004 08:09:47 -0500 (CDT)

----------------------------------------------------------------------
Saad Biaz, Ph.D., Assistant Prof.     Voice: (334) 844 6307
114 Dunstan Hall Auburn University    Fax  : (334) 844 6329
Auburn, AL 36849-5347, USA            http://www.eng.auburn.edu/~sbiaz
----------------------------------------------------------------------