Re: [DNSOP] Genart telechat review of draft-ietf-dnsop-session-signal-11

["Joel M. Halpern" <[e-mail]>]

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.