Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 16 Mar 2011 13:13:42 -0000
Message-ID: <5FDC413D5FA246468C200652D63E627A0D5F2140@LDCMVEXC1-PRD.hq.netapp.com>
In-Reply-To: <1D773EAD-B091-4A25-85F9-292863790AFD@ifi.uio.no>
Thread-Topic: [tcpm] Using the ECN Nonce to detect spurious loss events
Thread-Index: Acvj1+8bW9aI5eQjRbaabU4VDwF54QAAETNQ
References: <F93BAD94-39D8-414A-8364-9129B459A2CD@ifi.uio.no><5FDC413D5FA246468C200652D63E627A0D5F20BE@LDCMVEXC1-PRD.hq.netapp.com>
 <1D773EAD-B091-4A25-85F9-292863790AFD@ifi.uio.no>
From: "Scheffenegger, Richard" <rs@netapp.com>
To: "michawe" <michawe@ifi.uio.no>
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Using the ECN Nonce to detect spurious loss events
Precedence: list

Hi Michael,

=20
> 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.


Yes, somehow I seem to have missed that rfc. Unless you have some unique
signal that is conveyed in each sent segment, the best reaction time
will be 1 RTT after the (spurious) retransmission. With a unique signal
(like ECN nonce or timestamps (or packet size?), 1RTT (+reorder delay)
of the original segment is the minimum reaction time.

>=20
> 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.

Fully agreed -  this is still a very sketchy draft at this time; the
hints on possible use cases are there to move them later into separate
sections. We didn't want to put in too much possible signaling for which
no current foreseeable use case exists (ie. moved the clock resolution
range negotiation to annex A, from the -00 version, and got rid of a
number of possible redundant/unnecessary flags - ie BIAs, MIRror).

Does the negotiable range of clock rates between ~16 sec and ~8ns (down
to 8ps with reduced precision) sound reasonable enough, and is the
precision of a binary16 float good enough? Except for the bias and the
removal of special numbers (NaN/infinity), the format is like a IEEE
binary16, so I hope conversion can be made easy (simple stacks may just
insert a fixed value and negotiate for the modified TS reflection
behavior, without using the information from the other host).

The mask is now defined with bit-precision, allowing up to 31 bits of
the timestamp to be masked (limiting the value of timestamps for PAWS
very much :); personally, I think only up to 12 bits make some sense for
integrity checking while maintaining the usefulness of timestamps to
existing algorithms, but nibble-precision was seen as being too coarse.

>=20
> 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?


Actually, I had a model like RFC2018 / RFC3517 in mind - disentangle the
signaling from the algorithms making use of it.=20
Putting all the already investigated algorithms making use of such an
enhancement into one draft (ie. TCP Chirp, TCP LEDBAT, [TCP CUBIC
interaction w/ timestamps], fast-LRD, (eifel-style) spurious
retransmission detection/response) would make this a very lengthy and
needlessly complex draft.
Besides, there may be other useful properties (ie, a low bitrate,
unreliable channel in the masked TS bits) which could be put to other
good use...

I would rather go with a section for use cases, referencing the
(existing) RFCs/papers, and only giving hints how the improved signaling
can help in those algorithms. However, this is currently completely
missing from the draft due to it's very early stage.

>=20
> Cheers,
> Michael
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm