Subject: Re: [tsvwg] draft-tuexen-tsvwg-sctp-sack-immediately-07.txt

From: "Scheffenegger, Richard" <[email-masked]>
Date: Sat, 10 Nov 2012 01:14:57 +0000

Again one stupid question:

The security considerations only mention RFC4960, but a malicious receiver/sender is not mentioned there... Could there be any adverse effect when the I-bit is constantly set? For latency-sensitive applications that appears like something an application programmer wants to do on a permanent basis, to never have to wait for any delayed SACK chunk...

But forgive me if this is a too TCP-ish view...

Regards,

Richard Scheffenegger

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 10 Nov 2012 09:33:51 +0100

On Nov 10, 2012, at 2:14 AM, Scheffenegger, Richard wrote:

> The security considerations only mention RFC4960, but a malicious receiver/sender is not mentioned there… Could there be any adverse effect when the I-bit is constantly set? For latency-sensitive applications that appears like something an application programmer wants to do on a permanent basis, to never have to wait for any delayed SACK chunk…
The receiver can already now use the socket API
http://tools.ietf.org/html/rfc6458#section-8.1.19
to set the SACK frequency to 1.

The only point is that it can be controlled by the sender... So I don't think there
is an issue here.

Best regards
Michael
>  
> But forgive me if this is a too TCP-ish view…
>  
> Regards,
>  
> Richard Scheffenegger
>

---

From: Randy Stewart <[email-masked]>
Date: Mon, 12 Nov 2012 10:09:47 -0500

Actually, if you want to be real TCPish the original TCP RFC (793) allows
you to sack every packet… not that folks do that but I do think its legal..

R

> But forgive me if this is a too TCP-ish view…

-----
Randall Stewart
[email-masked]