Re: [Plus] Supporting connection tracking and basic diagnostics: a minimal PLUS

[Ian Swett <[e-mail]>]

Good point, though they'd only know it afterwards.  At which point the
connection would be torn down.

I'm not sure it's critical the receiver is unaware they're being tested or
not.  And if the connection is suddenly torn down, presumably they'll
realize they were being tested anyway?

On Sun, Dec 11, 2016 at 11:47 AM, Christian Huitema <[e-mail]>
wrote:

> On Sunday, December 11, 2016 6:51 AM, Ian Swett wrote:
> > On Sun, Dec 11, 2016 at 1:33 AM, Christian Huitema <mailto:
> [e-mail]> wrote:
> >> ...OTOH, there is going to be a "feature interaction" between this
> sequence+echo scheme and
> >> the senders' strategy of skipping some sequence numbers in order to
> verify that the recipients
> >> are not making up ACKS. The intermediate boxes will have no way to
> distinguish between a
> >> packet number voluntarily skipped by the sender, and a packet loss
> between the sender and
> >> the middlebox. I hope this won't affect the "wireshark diagnostics" too
> much.
> >
> > We could specify that if a peer wants to skip packet numbers, it should
> be by more than 256,
> > assuming 256 packet gaps are rare(which they are, though they do
> happen).    Or some other
> > known approach that is relatively simple to identify.
>
> If you make it easier to identify, then you defeat the purpose of the
> packet skipping. Suppose a bad receiver, intent on setting a DOS attack.
> Its strategy is to ACK as quickly as possible, regardless of losses. The
> sender detects ACK of packets that were not sent, and aborts the
> connection. But if the skipping is easy to detect by middleboxes, it is
> also easy to detect by the bad receiver, which will suspend its ACK
> everything strategy if it detects a test...
>
> -- Christian Huitema
>
>
>
>
>