[e2e] Open the floodgate

[Michael Welzl]

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" <ASCPFu at ntu.edu.sg>: 
 
> 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: end2end-interest-bounces at postel.org  
> > [mailto:end2end-interest-bounces at postel.org] On Behalf Of  
> > Michael Welzl 
> > Sent: Friday, April 23, 2004 1:41 PM 
> > To: Noel Chiappa 
> > Cc: end2end-interest at postel.org 
> > 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 
> >  
> >  
>