Hi Ted,
sorry for the delay, however, as you performed a couple of changes it took me a
while to re-review. I believe I’m unfortunately not fully ready to release my
discuss at this point, but close..
Regarding my first discuss point (delayed ACKs aso.) I think the text improved
and I would like to seem my minor wording question (comment 2) below addressed
before I finally release the discuss here. However, I still think the extensive
discussion as provided in section 9.5 now, does not necessarily belong in this
document. Therefore I would rather would have preferred to move this text in a
real appendix, or removed it completely and maybe document in an own
informational RFC (in tcpm).
Regarding my second discuss point (keep-alives), the text seems still not quite
right yet, or I’m really confused. Please also see also further below (comment
3).
Anyway here are my comments on the edited/new text in the order they appear in
the draft:
1) I think the following text in section 3 is not fully correct:
"Fast Open message: A TCP SYN packet that begins a DSO connection and
contains early data ([RFC8446] section 2.3). Fast Open is only
permitted when using TLS encapsulation: a TCP SYN message that does
not use TLS encapsulation but contains early data is not permitted.“
If TLS 0-RTT is used this data will not be carried in the TCP SYN, it will
„just“ be send at the same time as the TLS handshake is performed (but after
the TCP handshake). Only if TCP Fast Open (TFO) (see RFC7413) is used, data can
also be sent in the TCP SYN. I guess you mainly need to fix the reference here,
or maybe name both mechanisms separately.
2) In section 5.5.1:
"With a DSO request message, the TCP implementation waits for the
application-layer client software to generate the corresponding DSO
response message, which enables the TCP implementation to send a
single combined IP packet containing the TCP acknowledgement, the TCP
window update, and the application-generated DSO response message.
This is more efficient than sending three separate IP packets.“
The phrasing here is a bit confusing, to me at least. It sounds a bit like
there is a special TCP for DSO… maybe the following is a bit better:
"With a DSO request message, TCP delayed acknowledge timer will usually
make the implementation wait for the
application-layer client software to generate the corresponding DSO
response message before it sends out an TCP acknowledgment
This will generate a
single combined IP packet containing the TCP acknowledgement, the TCP
window update, and the application-generated DSO response message and
is more efficient than sending three separate IP packets.“
(Note that the deplayed ack timer can be configured to a very small value as
well, and as such it depends on the processing time and the value of the timer
if a TCP implementation will wait or not.)
3) Section 6.5.2
"For example, a (hypothetical and unrealistic)
keepalive interval value of 100 ms would result in a continuous
stream of ten messages per second or more, in both directions, to
keep the DSO Session alive. And, in this extreme example, a single
packet loss and retransmission over a long path could introduce a
momentary pause in the stream of messages of over 200 ms, long enough
to cause the server to overzealously abort the connection.“
I think this example is still not correct (and the changes might made have it
worse: how can there be more then 10 messages?)
So the point here is that there is a dependency on the RTT. Only if the RTT is
smaller than 200ms this can happen, otherwise the connection is closed anyway
after two keep-alives. However, if the RTT is much smaller than 100ms and e.g.
TLP is used, it would still work even if one packet is lost.
In any case, I don’t think this example is actually very helpful. The point is
that the keep-alives interval should always be much larger than the RTT to make
this work appropriately. However, the point about keeping the network load is,
is rather independent to the question of when the mechanism actually breaks. I
would recommend to simply remove this example and just say that the interval
MUST not be smaller than 10 sec to keep the network load reasonably low.
However, having read this and the previous section again, I think your
implementation of the keep-alives mechanism could also be improved. Usually,
there should be two intervals. One defines, how long the connection can be idle
before an keeps-live is sent and one that defines when a keeper-lives should be
retransmitted if it is deemed to be lost, where the first one just usually be
larger than the second one (and both timers should always be larger than the
RTT). That would enable faster failure if the connection is actually lost.
4) Section 6.6.2.2. (Reconnecting After an Unexplained Connection Drop)
"It is also possible for a server to forcibly terminate the
connection; in this case the client doesn't know whether the
termination was the result of a protocol error or a network outage.
The client could determine which of the two is occurring by noticing
if a connection is repeatedly dropped by the server; if so, the
client can mark the server as not supporting DSO.“
How often should the client try and in which interval?
5) Section 9.2:
"In principle, anycast servers could maintain sufficient state that
they can both handle packets in the same TCP connection.“
Really? I mean in theory yes but has this ever been done in practice? I would
think that sharing TCP state is even harder than sharing DSO state.
Thanks!
Mirja
> Am 27.09.2018 um 06:57 schrieb Ted Lemon <[email protected]>:
>
> Mirja, I notice that you are still holding a discuss on this document. I
> believe that we addressed the concerns you raised in your discuss. Could
> you please let us know if there is still work to do on this, and if not,
> clear the discuss?
>
> Thanks!
>
>
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
