Re: [tcpm] Comments on draft-blanton-tcpm-3517bis-01

[Matt Mathis <[e-mail]>]

(back on tcpm)
Well, ok, keep your words.  However please at least remove or change
the first sentence.

Reneging is not really about memory, we only used that as an excuse.
We allowed the receivers to renege to force implementers think about
and actually test their code with inconsistent SACK updates.

At the time there was a strong track record for the following oft
repeated ugly scenario: the first implementer has a bug that does not
effect self-interoperability, and goes on to capture a significant
market share.  The second and subsequent implementer do not have the
bug and get punished by having interoperability problems.  Everybody
switches to "implemented but off by default".  Several years go by
waiting for the deployed bugs to vanish (w/o any market pressure)
before the new feature gets turned on....

We wanted to guarantee that SACK could not cause interoperability
problems and that the worst case impact of SACK bugs would be reduced
performance.  The last resort was to use Tahoe style go-back-n timeout
behavior.   Considering how may truly weird traces that we all have
looked at, this worked: as far as I know SACK bugs have never caused
connection hangs or aborts.

At the time 2018 was in draft there was a lot of pressure to take
reneging out.  We knew that it implicitly forbid many useful
optimizations.   It stayed in only because of the robustness argument.

Note that if you ever free queued data because it has been SACKed,
SACK bugs become fatal.

</soapbox>
Now that SACK is well established, it might be a feature to have bugs
cause interoperability problems.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay




On Fri, Apr 15, 2011 at 11:57 AM, Mark Allman <[e-mail]> wrote:
>
> Hi Matt!
>
> Question: do erratas formally update a spec?  I have forgotten.
>
> In any case, I like our words a lot better than your words.  I (1) think
> we're more precise in laying out the current state, (2) don't think it
> is this document's place to get into reneging detection in any sort of
> detail and (3) the detail you do provide in your text is fuzzy and
> non-actionable anyway ("eh, you could use DSACKs, perhaps!").
>
> What we tried to do is to say 3517bis is not normative on this subject
> and so please go look at the current normative stuff and of course use
> all SACK information available at all times.  That seems enough to me.
> Its all a minor point in this document.
>
> (I hate working .bis documents.  Everyone wants something.  That said,
> you should update 2018.)
>
> allman
>
>
>
>