Subject: [tcpm] Some comments on 2581bis

From: Fernando Gont <[email-masked]>
Date: Wed, 14 Feb 2007 04:35:19 -0300

Mark,

Some comments on the draft:

** RFC 2581 & SACK
Page 3 says:
         Alternatively, a TCP that utilizes selective acknowledgments
         [RFC2018,RFC2883] can determine an incoming ACK is a "duplicate"
         if the ACK contains previously unknown SACK information.

And page 7 says:
Note that a sender using SACK [RFC2018]
         MUST NOT send new data unless the incoming duplicate
         acknowledgment contains new SACK information.

IMHO, if you keep the "MUST NOT" in page 7, you'd probably 
s/can/MUST/ in page 3. Also, maybe it would be worth to clarify that 
the SACK information should be "in window"?

** Limits on dupacks
Would it make sense to limit the number of accepted dupacks to 
Max_dupacks = (Flight_size_fr - 1) / SMSS ?
where Flight_size_fr is the Flight_Size at the point fast retransmit 
is triggered.

Thanks,

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

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

---

From: Mark Allman <[email-masked]>
Date: Wed, 14 Feb 2007 10:05:38 -0500

> the SACK information should be "in window"?

Well, duplicate ACKs in 2581 are not always to send out new data.

That said, I am wondering if we should just nuke the sentence you quote
above.  This document does not deal with SACK-based loss recovery and if
you have SACK then you should be doing something smarter than this
document.  And, so maybe we don't need to really define things about
SACK-based loss recovery in here.  Certainly, I don't think we want to
get into whether SACK blocks that this document doesn't use at all are
in window or not.

> where Flight_size_fr is the Flight_Size at the point fast retransmit

I'd like to hear what people think on this notion.  The intent in
putting the new text in was not to tightly specify a mechanism, but to
note that there is good reason to put some sort of limit on things.  How
that is done does not seem important to me.  (*If* it is done only seems
marginally helpful to me.)  I.e., one could envision a cwnd limit or
trying (because we don't keep track in some stacks) to track the number
of packets vs. dupacks as above or ...

I guess I would rather leave it as sort-of fuzzy guidance and not
mechanism or just drop it as new functionality that is out of scope for
the revision.

What do folks think?

allman

---

From: John Heffner <[email-masked]>
Date: Wed, 14 Feb 2007 11:02:09 -0500

> get into whether SACK blocks that this document doesn't use at all are

The notion of the sender "using" SACK is a bit fuzzy anyway, since some 
stacks will send the options but not process them in any meaningful way 
(writing scoreboard code is hard).

   -John

---

From: Fernando Gont <[email-masked]>
Date: Wed, 14 Feb 2007 13:36:04 -0300

>Well, duplicate ACKs in 2581 are not always to send out new data.

My point is: if you disregard "dupacks" that don't have new sack 
information for sending new data, why would you let them trigger loss recovery?

>get into whether SACK blocks that this document doesn't use at all are

I fully agree with this view.

>mechanism or just drop it as new functionality that is out of scope for

I think it would be helpful to describe possible mechanisms (such as 
the one above). If not, chances are that people is not going to 
implement it, or they may get the limit wrong. The doc already some 
includes text about ack-division attacks, so IMHO I don't think 
describing a mechanism for enforcing limits on dupacks would be out of scope.

Thanks,

---

From: Mark Allman <[email-masked]>
Date: Wed, 14 Feb 2007 12:03:01 -0500

> describing a mechanism for enforcing limits on dupacks would be out of

The hesitation here is that we're making things up for inclusion in a
document that we are trying to progress to draft standard.  I am a
little uncomfortable with that.  The other things in the document have
some more long-term understanding and study behind them.

I don't mind the document saying "here is a case where you might want to
be more conservative than allowed".  But, if we translate that into one
or more mechanisms we could easily get bit.  I have done this "it is
such an easy tweak, how could it be wrong?" business enough times over
the years to know that the interactions are tricky and subtle and it
takes work to understand the implications of these things.  And,
sometimes the "easy, for sure gotta be right" changes are absolutely
wrong.  I am just feeling like we don't want to do that in this
document. 

Just my opinion ...

allman

---

From: Mark Allman <[email-masked]>
Date: Wed, 14 Feb 2007 13:07:23 -0500

> The notion of the sender "using" SACK is a bit fuzzy anyway, since
> some stacks will send the options but not process them in any
> meaningful way (writing scoreboard code is hard).

This is getting a little better.  Contrast the 2000 and 2004 results on
actual SACK usage (not just sending them) in the paper below.  Still not
stunning in 2004, but at least it was on the rise and hopefully it has
continued to be.

allman

Alberto Medina, Mark Allman, Sally Floyd.  Measuring the Evolution of
Transport Protocols in the Internet.  ACM Computer Communication Review,
35(2), April 2005. 
http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps