I will try to elaborate on the problems below.
Joel
On 7/5/18 6:28 PM, Ted Lemon wrote:
The text also says that it's fine to blindly forward DSO messages if the
middlebox isn't modifying the stream, e.g. in a NAT. It really is
quite clear on that point. The case where it's bad to blindly forward
DSO messages is when there is no stream that's the same stream on both
sides of the middlebox. In this case, it really is a MUST NOT. What
reader's need are you trying to address here? Who is going to be
reading the document and is going to be confused about this?
The text in 5.3.1 says that middleboxes MUST NOT do blind forwarding.
Regarding the further text, given the wroding it is actually very hard
to understand whether that is supposed to be an exception to the MUST
NOT, or a description of some other case.
Even if the further text covers a lot of cases, the MUST NOT is
presumably describing a situation that existing middleboxes do find
themselves in. I do think it is fair to ask for an explanation of why
existing middleboxes that do fall into the relevant case will do the
right thing. Are there no such existing middleboxes (seems unlikely)?
Do such existing middleboxes already for some reason do things that will
prevent the blind forwarding (that would be great, just explain it)? Or
is it actually okay that existing middleboxes violate the MUST NOT (in
which case, why is it a MUST NOT)?
As far as I can tell, the text on Nagle is correct, and you haven't
pointed to an error. You appear to have said that you want it to place
a new requirement on the sender to respond within the 200ms DA window.
This is unnecessary. What am I missing?
What the text in 5.4 actually says is that magically the data will be
piggybacked. It treats it as if there are only two cases, DSO requests
that generate a response that automatically combine the two, and DSO
requests that do not generate responses. The reality is that there are
three cases.
1) DSO requests that get responses and are responded fast enough to get
nagle behavior and the resulting performance benefit,
2) DSO requests that get responses and for whatever reason are responded
to more slowly
3) DSO requests that do not generate responses.
The fix, it seems to me is to make two small changes:
A) In the first sentence of 5.4, change "for DSO requests that generate
a response" to "for DSO requests that generate a response and are
responded to in a sufficiently timely fashion"
B) At the start of the second paragraph, change "For DSO requests that
do not generate a response" to "For DSO requests that do not generate a
response or those that generate a response but are not responded to in a
sufficiently timely fashion"
This has the side benefit of making clear to implementors that ensuring
responsiveness of their implementation will improve the network utilization.
