Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: michawe <michawe@ifi.uio.no>
In-Reply-To: <5FDC413D5FA246468C200652D63E627A0D5F20BE@LDCMVEXC1-PRD.hq.netapp.com>
Date: Wed, 16 Mar 2011 13:44:40 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D773EAD-B091-4A25-85F9-292863790AFD@ifi.uio.no>
References: <F93BAD94-39D8-414A-8364-9129B459A2CD@ifi.uio.no>
 <5FDC413D5FA246468C200652D63E627A0D5F20BE@LDCMVEXC1-PRD.hq.netapp.com>
To: "Scheffenegger, Richard" <rs@netapp.com>
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Using the ECN Nonce to detect spurious loss events
Precedence: list

On Mar 16, 2011, at 1:05 PM, Scheffenegger, Richard wrote:

> Hi Michael,
>=20
> I believe that your goal is very worthwhile - detecting spurious =
retransmissions and fixing the CC reaction.
>=20
> But neither ECN nor ECN-nounce are very widely deployed (in comparison =
with Timestamp - Eifel; SACK - DSACK). Hopefully, the state of ECN will =
improve with IPv6 (and now, that a number of major OS allow enabling =
ECN, even though it's not enabled by default).

... but if conex grabs the ecn nonce, they grab it for both ipv4 and =
ipv6 I suppose.

>=20
> However, as the number of SACK (DSACK) enabled sessions is already =
quite high, and there is less (no) state required in the server to =
discriminate spurious retransmissions with very high probability. I =
think documenting the proper response to DSACK (only the signaling is =
currently documented, IIRC) may be more valuable to drive adoption with =
commercial stacks - often stacks actively signal DSACK, but don't =
process that feedback themselves...

rfc 3708 seems to take care of what you describe here. while i think =
that this is a good thing to implement, it has the disadvantage of =
having to wait for a duplicate to arrive at the receiver, which can =
delay the reaction.


> Overall, I'm afraid I don't see that efforts to improve your scheme =
would see much deployment because of all these reasons.
>=20
>=20
> On a related topic, I would like to hear your and the groups feedback =
on the (sketchy) draft around TCP timestamp negotiation - when in use =
with SACK, it asks for immediate, unconditional reflection of the last =
received timestamp on the receiver side. This allows the unwind of =
misdirected CC reaction to be done faster than the RTT of the =
retransmission (current timestamp / DSACK can only signal back the =
spurious retransmission 1 RTT after the spurious retransmission, but not =
1 RTT (+reorder delay) after the original segment).
>=20
> (The other main features this signaling would allow are one-way-delay =
variance measurements, and also faster lost retransmission detection =
(than Linux; not a IETF RFC yet) without violating packet conservation =
principles, plus provide a means of transparently allowing integrity =
checks of timestamps without breaking timestamp-based algorithms).
>=20
> =
http://www.ietf.org/id/draft-scheffenegger-tcpm-timestamp-negotiation-01.t=
xt

I read this now. Style wise, I think that it's tough to read, a lot of =
things could just be expressed in simpler ways, probably by reducing the =
number of hints regarding possible usage.

I like the general idea. I think it's probably useful to extend TCP's =
timestamp handling in this manner, but I also think that the right point =
in time to extend it is when you can also propose a specific usage for =
this extension.
Like LEDBAT: if a part of the idea is to use this for incorporating =
LEDBAT congestion control in TCP, why not write this in the draft, as =
one concrete example application (with full detail, so that it can =
actually be implemented) of your extended signaling?

Cheers,
Michael