Re: [tcpm] draft-anumita-tcpm-stronger-checksum

["Scheffenegger, Richard" <[e-mail]>]

My understanding was, that it has more to do with the reliability of
your back channel (ACK/SACK dropped on their way to the receiver).

But SACK is not required to have "perfect" state shared between receiver
and sender; if multiple consecutive SACKs are dropped, and due to the
lower number of SACK fields some of that info never comes to the sender,
it might unnecessarily retransmit segments, which the receiver did in
fact already receive properly.

Just an edge issue, really, causing behaviour more like Reno (non-SACK)
retransmissions. But even having just one SACK field should already
serve to conserve much bandwidth (and responsiveness, as fewer RTTs are
necessary to re-send all missing data) over NewReno.

Richard Scheffenegger

 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: Donnerstag, 10. Juni 2010 08:45
> To: Scheffenegger, Richard
> Cc: [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum
> 
> 
> On 10 Jun 2010, at 00:53, Scheffenegger, Richard wrote:
> > 
> > Further, I have spent some time looking for research on the 
> > effectiveness of SACK - as this option would reduce the 
> typical number 
> > of SACK fields from a maximum of 3 down to 2. But from what 
> I learned, 
> > it seems that the number of SACK fields in an ACK have the 
> property of 
> > diminishing returns. You gain a lot from the 1st field; 
> somewhat from 
> > the 2nd, a bit from the 3rd, and having a 4th is surplus :).
> 
> That's probably because TCP's dupack threshold is three, 
> after which fast recovery is invoked.
> 
> Lloyd Wood
> [e-mail]
> http://sat-net.com/L.Wood
> 
> 
> 
>