Subject: [pcp] #69: Dave Thaler comments on draft-ietf-pcp-port-set-04

From: "pcp issue tracker" <[email-masked]>
Date: Tue, 25 Feb 2014 02:42:11 -0000

#69: Dave Thaler comments on draft-ietf-pcp-port-set-04

 > Le 2013-10-30 18:33, Dave Thaler a écrit :
 > > 1) The claim that a port set makes code simpler needs an explanation
 > > to
 > justify it.
 > > E.g., if an app really needs 16 ports, and it fails to get 16 back
 > > in its first request, it still has to handle that and say make
 > > multiple separate
 > requests.
 >
 > Two observations:
 >
 > - Wouldn't that behaviour be a tiny bit evil? It reminds me of
 > applications that create multiple flows in an attempt to trick an
 > SFQ-based QoS into allocating them more bandwidth.
 >
 > - Often, apps that ask for N ports don't really need N ports. Ideally
 > they would like to get N ports, but they can live with <N ports. No
 > need for single- port fallback in that case.
 >
 > > So if it already has to have
 > > code to deal with multiple separate requests, why is it simpler to
 > > add port set functionality to and implement both?  This seems
 > > counter-intuitive
 > to a reader.
 >
 > That would only apply to apps that absolutely need N ports to
 > function, and don't need them to be contiguous. Those apps need to
 > fall back on single- port requests as you describe. But I would argue
 > that these apps are really quite rare.
 >
 > We can add text describing these concerns in the next revision.

 Sure, but the claim in section 2 is that the client side logic *is*
 simpler.
 Not "often" simpler, or "may be simpler".   You can’t assert this when
 sections 6.4 and 6.3 both leave some major questions up to the
 implementation.  So it might be more complicated not simpler.  Suggest
 just deleting the "Client-side simplicity" bullet.

 The text added in section 6.4 looks fine to me, except for one editorial
 suggestion on this text:
 > Suppose a PCP client asks for 16 ports and receives 8.  What should
 >   it do?  Should it consider this a final answer?  Should it try a
 >   second request, asking for 8 more ports?  Should it fall back to 8
 >   individual MAP requests?  This document does not try to answer those
 >   questions , but describes issues to be considered when doing so.

 Suggest changing last sentence to
 "This document leaves the answers to be implementation-specific, but
 describes issues to be considered when answering them."

 That is, it answers them by saying it's implementation-specific.

 [...]
 Section 6.3 now looks fine to me, except for a typo:
 > which port set mapping requests would be arbitrated,  Alternatively,

 Change first comma to period.

 > > 4) Section 4.1 says if the response does not include a PORT_SET, in
 > > a response it assumes the server doesn't support it, and sends
 > > individual
 > MAP requests for the rest of the ports it needs.
 > > But section 4.2 says if the server does support PORT_SET but can
 > > only return 1 in its first response, It must omit the PORT_SET
 > > option.  I think
 > that's wrong since it will confuse the client as noted above.
 > > If it's included with a Port Set Size of 1, the client knows it can
 > > keep trying using PORT_SET for subsequent blocks, which might get
 > > more
 > than 1 port in each response.
 >
 > Agreed. I'll modify the draft accordingly unless others disagree.

 I expected the draft to be modified accordingly as I didn't see any
 disagreement on the list or in the meeting notes (let me know if I missed
 something).
 However a different change was made to the draft which I think isn't as
 good.

 Specifically, per the "Agreed" above, I expected it to say the server will
 return a port set option with size of 1, and the client then knows the
 server supports port-sets and can choose to ask for another port-set if it
 wants.
 And if the response has no port-set option, then it knows the server
 doesn't support it and can send other requests accordingly.

 Instead, -04 changed to keep the statement:
 >   If the PCP server ends up mapping only a single port, for any reason,
 >   the PORT_SET option MUST NOT be present in the response.

 And instead added this text:
 > If no PORT_SET option is present in the response, the PCP client
 >   cannot conclude that the PCP server does not support the PORT_SET
 >   option.  It may just be that the PCP server does support PORT_SET but
 >   decided to allocate only a single port, for reasons that are its own.
 >   If the client wishes to obtain more ports, it MAY send additional MAP
 >   requests (see Section 6.4),

 I didn't see it explained why this is better than what I thought we agreed
 to on the list.

 Also related to the above is the following from IETF 88 meeting minutes:
 > Dan: Server can be upgraded/changed to support/not support PORT_SET.
 >     Is there any harm to always request PORT_SET?
 > Dave: If I get an indication that the server doesn't currently support
 >      PORT_SET, I'll send multiple requests in parallel.

 Just keep the above in mind when addressing the earlier issue.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-pcp-port-
  [email-masked]  |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:  milestone1
Component:  port-set     |    Version:  1.0
 Severity:  Active WG    |   Keywords:
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/69>
pcp <http://tools.ietf.org/pcp/>