Re: [DMM] Mirja Kühlewind's Discuss on draft-ietf-dmm-ondemand-mobility-16: (with DISCUSS and COMMENT)

[Mirja Kuehlewind <[e-mail]>]

Hi Danny,

I cleared my discuss now. However, given these are quite large changes, I think Suresh and the chairs need to decide if they want/need to rerun the wg last call.

See further comments inline (given I know had some time to look at this again and would like to add some thoughts).

> On 31. Jul 2019, at 21:52, Moses, Danny <[e-mail]> wrote:
> 
> Hi Mirja (and all other reviewers),
> Thanks for your comments.
> 
> I read once more your comments about the removal of the Socket API definitions (from February 2019), and after more thought agree to remove it from the normative part of the document.
> I believe that the important aspect of this work is to define the ability of applications to indicate the type of service they require in terms of session continuity and IP address reachability. The part that enhances the Socket APIs is our idea of implementation and not necessarily the only one. Once the concepts are defined, Socket API enhancements may better be defined in other forums.

I have to said I wasn’t fully aware that RFC3493, RFC3542, and RFC5014 specify the Socket API in such detail. I personally still think that RFCs are not the best format to specify APIs in that detail (e.g. using full functional c code) as usually the communities implementing these APIs in the end may have additional considerations for what to optimise for. However, these RFC mostly specify new structs and did not change the actual socket functions. In this sense the change proposed in this new drafts seems to be a much bigger change. Note that documenting an existing implementation of an API in an informational RFC can be a different case. 

Anyway for this document I would still say that the best way to implement this new API isn’t fully clear, and therefore it might be better to not demand one specific way to implement. Initially when reading the draft I didn’t fully think thought the blocking case. However, I guess another option would be to do the request for a new address during bind() if needed, however, I’m sure there are more thinks to consider when to best initiate such a request. On the other hand, acquiring an address of a specific type seems actually independent of opening a socket and could be done any time before the socket is created and bound. So I think removing any specifics is a good way forward. Thanks!

Still, just double-checking we do the right thing here: it would be different if e.g. the API would be already implemented like this in the Linux kernel. Then documenting what’s there could be of value. However, my currently understanding is that this is not the case…?

> 
> So I am removing sections 3.5, 4 and 6 from the document (as you suggested in the email from February). 

Thanks okay. I would also be okay with having 4.2. still in the doc if people feel such an example would be helpful (with some minor tweaks to remove references to sockets or setsc()).

> 
> I think it could be helpful to add an appendix that provide an example of an implementation in high-level. I reworded the text that was removed (section 3.5) to become a description of an example (rather than a definition of a solution) and placed it as an appendix.

Yes, I think this information is good and valuable to have in the draft. I would also be okay with moving the section as now in the appendix back in to the main body of the doc.

Thanks!

Mirja


> 
> I believe this was the last open issue and that now the draft can be published.
> Please consider the new version that I have posted: https://tools.ietf.org/pdf/draft-ietf-dmm-ondemand-mobility-18.pdf
> 
> Best regards, 
> 
> Danny
> 
> -----Original Message-----
> From: Mirja Kuehlewind [mailto:[e-mail]] 
> Sent: Monday, July 29, 2019 19:57
> To: Moses, Danny <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; Dapeng Liu <[e-mail]>
> Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-dmm-ondemand-mobility-16: (with DISCUSS and COMMENT)
> 
> Hi Danny,
> 
> Sorry for my super late reply! Somehow your mail got sorted in the wrong folder and I therefore overlooked it.
> 
> Did you have a chance to talk more about this with other reviewers or other people in the working group?
> 
> I still think that it is not appropriate nor very useful to have the Socket API specified in the body of the draft (as the Linux community will not necessarily follow this). Therefore I still recommend to remove it or more it to the appendix and clearly indicated that this is an example implementation for illustrative purposes only. 
> 
> Further I think it would still be good to discuss pros and cons or different approaches to realise this interface rather than trying to impose one specific implementation (which may potentially not be adopted in practice).
> 
> Please see further inline below.
> 
> Thanks!
> Mirja
> 
> 
>> On 22. Feb 2019, at 11:49, Moses, Danny <[e-mail]> wrote:
>> 
>> Hi Mirja,
>> Thanks for your comments.
>> 
>> I would like to start with responding to your last proposal to remove all socket API specifications from the document.
>> 
>> Yes, we could do that. However, this is a significant modification and I would like some sort of ruff consensus from the rest of the reviewers for such a significant change.
>> 
>> I must admit that this idea was brought up to me after the WGLC and I was not sure whether this could be done without a broader discussion. During the work on this document (which has been discussed in many dmm session over several years), people felt that the Socket API info was important. Furthermore, there were several discussions about whether to use additional flags in setsockopt() or add a new function (which was added eventually). There were also discussions about whether or not to add a pseudo code example to the document and after it was added, a discussion about the example. 
>> 
>> My personal view is that the concept of introducing mobility service types and enabling applications to request them on a per-socket basis, is the most important aspect of this work. The socket extensions part is there to provide guidance from IETF as to how this extension should be designed. The multiple discussion we had about the socket extensions prove to me that some people think they are valuable as well.
>> 
>> If the reviewers think that leaving the socket extensions specification in the document is a show stopper, I will remove the text as you propose, but I would like the opinions of more reviewers on that. 
>> 
>> 
>> Response to the comment about the API approach:
>> The comment indicates that according to section 3.2 Fixed IP address cannot be configured on a per socket basis since the application needs the same IP address for multiple socket connections. This, according to the comment, contradicts the text in section 3.3 indicating that IP address type selection is made on a per-socket granularity.
>> 
>> I would like to clarify this point.
>> 
>> IP address type selection should indeed be done on a per-socket basis. If an application requires a socket with a Fixed address type, it will require the same address whenever it re-opens this specific socket. But this does not mean that the application requires the same Fixed source IP address for other sockets it uses (if any). It can use whatever source IP address type it needs according to the address reachability and/or session continuity requirements for the other sockets. 
> 
> This is still not clear to me because usually there is no way to “re-open” a socket. When the socket is closed you can only open a new socket and there seems no way right now to indicate that the same fixed IP address is needed with this new socket than was used for an old closed socket.
>> 
>> Furthermore, when a mobile host deploys several applications with one of them requiring a Fixed source IP address, others may require different address types and this is supported when the address type is selected on a per-socket basis.
> 
> This is understood. I was talking more about the other case where the same address is required for multiple sockets.
>> 
>> 
>> Response to the comment about adding flags to setsockopt() versus the new function setsc():
>> The original design was to use new flags for setsockopt(). However, during discussions in the dmm group, some people were concern with the fact that the new functionality may cause a ‘blocking’ behavior to setsockopt(). The reason for this ‘blocking’ behavior, as described in section 3.5, is due to the fact that in some cases, requesting a specific address type may trigger an interaction between the mobile host and the network requesting a prefix for this address. This interaction which involves exchange of packets may take some time, and the function can return only after the exchange of packets is completed.
>> 
>> The concern was that this changes the behavior of setsockopt() from a function that returns immediately, to a function that may block the invoking thread for a while, may confuse socket users.
>> 
>> Several options were presented to resolve this concern and the alternative that was selected by dmm was to leave setsockopt() in its non-‘blocking’ nature, and introduce a new function – ‘setsc()’ that has no legacy usage and may block the thread if the invocation triggers an exchange of packets between the TCP/IP stack in the mobile host and the network (as described in section 6.1).
>> 
>> I hope I managed to clarify this point.
> 
> I think this should further be explained in the draft. However, that is a decision to make for OS community that will implement this.
> 
>> 
>> 
>> Response to the comment about mobility being a transport question rather than an application layer question:
>> I am not sure I agree with this comment .I think that it does not take in account the extra cost and non-optimized routes used when networks provide session-lasting source IP addresses. But nevertheless, having a discussion about this point only strengthens the notion that the flexibility of being able to select service types on a per-socket basis is valuable.
> 
> This comment was also related to TAPS, as Magnus mentioned. Some of the functionality requested here could be provided through the TAPS API e.g. by indicating a preference. This is another reason to not specify a concrete Socket API in this document because in future these APIs could look very differently and you still want to make sure that the needed functionality is supporter. Probably it would also be good to point the TAPS group at this document and make sure its considered in their architecture.
> 
> 
>> 
>> /Danny
>> 
>> 
>> 
>> 
>> -----Original Message-----
>> From: Mirja Kühlewind [mailto:[e-mail]]
>> Sent: Wednesday, February 20, 2019 15:48
>> To: The IESG <[e-mail]>
>> Cc: [e-mail]; Dapeng Liu 
>> <[e-mail]>; Sri Gundavelli <[e-mail]>; 
>> [e-mail]; [e-mail]; [e-mail]
>> Subject: Mirja Kühlewind's Discuss on 
>> draft-ietf-dmm-ondemand-mobility-16: (with DISCUSS and COMMENT)
>> 
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-dmm-ondemand-mobility-16: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all 
>> email addresses included in the To and CC lines. (Feel free to cut 
>> this introductory paragraph, however.)
>> 
>> 
>> Please refer to 
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> As mentioned by the TSV-ART review (Thanks Magnus!) and confirmed by Danny Moses in his response to the TSV-ART review ("There were several discussions as to whether this draft should specify Socket extensions or provide guidelines for an API provided by the network stack to applications. The decision, eventually, was that since IETF does not specify the Socket API, we should not specify Socket extensions, but rather, provide guidelines for such functionality. "), I don't think this document should specify an socket API.
>> 
>> Further I don't necessarily think the API approach taken is correct. First section 3.3. says:
>> 
>> "IP address type selection is made on a per-socket granularity.
>>  Different parts of the same application may have different needs.
>>  For example, the control-plane of an application may require a Fixed
>>  IP Address in order to stay reachable, whereas the data-plane of the
>>  same application may be satisfied with a Session-lasting IP Address."
>> 
>> However, Fixed IP Address (as defined in section 3.2) cannot be configured on a per socket-basis as the application needs the same IP address for multiple socket connections.
>> 
>> Further, section 3.5. says.
>> 
>> "Extending this further by adding more flags does not work when a
>>  request for an address of a certain type results in requiring the IP
>>  stack to wait for the network to provide the desired source IP prefix
>>  and hence causing the setsockopt() call to block until the prefix is
>>  allocated (or an error indication from the network is received)."
>> 
>> However, later on section 6.1. it says:
>> 
>> "setsc() MAY block the invoking thread if it triggers the TCP/IP stack
>>  to request a new IP prefix from the network to construct the desired
>>  source IP address."
>> 
>> Therefore, I really don't understand why a new flag in setsockopt() can not be used.
>> 
>> I propose to remove all socket API specifications from this document and only discuss requirements  (as indicated by Danny). That would basically mean to remove sections 3.5, 4.1, and 6.
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> Please also note that address mobility is actually more a transport question that an application layer question. For TCP session-lasting addresses will always be more efficient if available while an application using TCP will always need to cover the case where an TCP connection fails or is interrupted and therefore the application needs to reconnect. However, in contrast QUIC supports IP address mobility and will survive changing IP addresses. I think that should be also clarified in the draft and it should be double-check if the use of the word application is always correct or if it should be replaced sometimes with e.g. transport system or a more general term.
>> 
>> 
>> ---------------------------------------------------------------------
>> A member of the Intel Corporation group of companies
>> 
>> This e-mail and any attachments may contain confidential material for 
>> the sole use of the intended recipient(s). Any review or distribution 
>> by others is strictly prohibited. If you are not the intended 
>> recipient, please contact the sender and delete all copies.
> 
> ---------------------------------------------------------------------
> A member of the Intel Corporation group of companies
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.