Re: [multipathtcp] 6824bis -11 review

[Christoph Paasch <[e-mail]>]

On 28/07/18 - 18:19:16, Alan Ford wrote:
> Hi Rahul,
> 
> Thank you very much indeed for this review.
> 
> > On 28 Jul 2018, at 08:38, Rahul Arvind Jadhav <[e-mail]> wrote:
> > 
> > Hi,
> > 
> > As promised  in IETF102, here is my review for 6824bis-11. As Phil had suggested, I didn't take the trouble to check if my comments overlap with any of the previous discussions/comments. 
> > 
> > 1. Section 3.6: Subflow Reset
> > [RJ]: Is MP_TCPRST a SHOULD or MUST to be included along with the TCP_RST ? Can this be stated explicitly in section 3.6?
> 
> It’s a MAY :)  We say:
> 
> "These semantics are carried in the MP_TCPRST option that can be included on a TCP RST packet.”
> 
> We should change that to “MAY be included”.
> 
> > 2. Section 3.4.2. Remove Address
> >   "The sending and receipt (if no keepalive response was received) of
> >   this message SHOULD trigger the sending of RSTs by both hosts on the
> >   affected subflow(s) "
> > [RJ]: Since a MP_TCPRST should be associated with this RST, what should be the corresponding Reason Code that can be used in MP_TCPRST for this case? I checked existing reason codes in section 3.6 and none of those made sense (may be except for 0x0 ?).
> 
> That’s an interesting one. There may be some benefit (maybe for middleboxes, or maybe for security) to sharing this information in the RST with an explicit reason code. We could add one - but I would be interested in hearing other opinions.

We could add one that indicates that the RST is upon a response of an
incoming MPTCP-option (e.g., responding to a REMOVE_ADDR, a
MP_FASTCLOSE,...).


Christoph