Meeting minutes
minutes review
<kaz> Jan-11
review minutes from 01-11
Lagally: any objections to publish?
… hearing none, will publish
review minutes 01-25
Lagally: had guests, so reminded people of patent policy, looked at Carlo's contribution, and update from Christine (McCool and Christine took an offline 1:1)
… any objections to publish?
… hearing none, will publish
<kaz> (link for Carlo's slides to be added)
contributions and prs
PR 182
<mlagally> https://
Lagally: slides from presentation two weeks ago
… migration use case from University of Pisa
Lagally: prefer to have it under CONTRIBUTIONS
… PDF, can use for preview; seems to work now
Lagally: shall we merge?
… merged
PR #186
<kaz> PR 186 - Add Service Migration horizontal use case
Lagally: service migration use case
Cristiano: not complete yet, but we can look at it today
Cristiano: was not sure title is the right title
McCool: I think mobility is confusable with accessibility issues, migration is prob the correct term
Lagally: feel there could be a better title
McCool: I do think migration is a standard term for this, could add "between servers"
Cristiano: I think it is horizontal, tried to identify suitable stakeholder
Cristiano: also use thing directory as notifiers
… then have motivation, but not too much information on how to apply
… I added a reference to our study
… not sure that is appropriate
McCool: two points: related to edge service migration being discussed in WNIG; also, why not use ipv6
Lagally: maybe bring use cases to the table?
Lagally: maybe ipv6 is too low-level?
McCool: just saying it should be pointed out that dealing with segmented networks is a precondition for this problem to exist, since it's about updating ipv4 addresses
Cristiano: so do we add WNIG to stakeholders?
Lagally: yes, or references
Lagally: drive in the car, move from one access point to another, IP can change
McCool: another question, is why does DNS not solve this problem?
McCool: another point is avoiding gaps in data when a service migrates
… may want to keep it running in two places during transition to avoid gaps...
Lagally: let's make sure we look at the actual PR
Carlo: description says there are two main problems: management of state and transfer; and ip addressing
… servient is our microservice, managed in a container
… in description, focus separately on state and addressing
… for state, value of properties, state of behaviours, etc.
… this state can be transferred in different ways, discuss under variants
… cite two different works
… from Pisa and Bologna
… these are a little different
… whole container movement is one option; use existing container mechanisms
… benefit is transfer is a low level; but can transfer a larger amount of data
… but advantage is transparent to application
… cristiano's approach uses a mobile agent approach
… in this they transfer state collected by the application itself, and is not transparent to the application
… certain functions need to be implemented by the application
… and application needs to actively pull the state
… but the advantage is that less data needs to be translated
… and don't have to transfer the entire environment
… then the use case discusses addressing, and how to update address
… in this case there are also several possibilities
… one is to let web Thing handle it by adding additional affordances, e.g. onMigration event
… another approach, proposed by cristiano, leverages TD and Directories directly, and actively pushes notifications
… finally, with respect to addressing, raised a point in gaps
… what about TCP connections; when IP address changes, connection will be closed
… and needs to be reestablished
… one solution is to use UDP and a suitable protocol; we use CoAP
… another option is QUIC
… this is gaining momentum recently
… it defines a mechanism to allow a connection to migrate
… connections are not identified by IP address and port, but its own identifiers
… but QUIC only applies this when client changes address
… but we have extended to also support cases where the server migrates
… so in short, the gap can be filled by developing a suitable HTTP/3 (HTTP over QUIC) protocol extension
Lagally: when you have a migrated Thing, is it still the same Thing? Does it need a new TD
McCool: (or id value?)
Lagally: suppose we have location metadata... does it need to be updated in the TD?
… how should this be handled?
Cristiano: how we handle this now is use a TDD that can notify the client
… that the TD was migrated, which changes the IP in the TD
… so if there is other metadata in the TD, it can be updated at the same time
Lagally: second question, when you do this migration, shut down first thing, bring the new thing up
… may want to limit authority to do this
… who among these stakeholders would be permitted to do this?
Cristiano: good question; in our work, we had an orchestrator that was the only entity that could do this
… but then who controls the orchestration?
… there are also cases where the developer or other stakeholders may have requirements
… there are requirements; distributed among the actors
Carlo: the property that we introduce, "migratable", does allow this to be specified in the TD
Lagally: something to consider: tell the thing that it can be migratable; can migratable property change?
McCool: two points, changes in location already being discussed under geolocation
… second point, is probably want to define quality of service, and then cloud/edge provider can migrate as long as they don't violate the terms of service
Cristiano: the paper does discuss this
carlo: position may not be an affordance, maybe be metadata
McCool: agree, that is what we are looking at as well
carlo: metadata is supposed to be static, properties are dynamic
McCool: agree, there are cases though when data that was *supposed* to be static has to be updated anyway, e.g. reinstalling a sensor in a new location
carlo: regarding fact that service in clouds are migrating anyway and we are not noticing... this is why we propose container migration, which is transparent
Kaz: can understand need for state pres and restore, but feel that this use case is a bit too researchy for standardization
… would like to see a few more concrete use cases
… for example, within a smart city context
… for instance, working at home, need to move to office, need to restore settings, etc.
Cristiano: agree with that; in paper do talk about vertical use cases
… italian-wide project for monitoring bridges
Cristiano: but this is still research level
Lagally: still think this is valuable and we should include it, but more concrete use case
Lagally: how do we close on this topic? Another update on this use case?
Cristiano: will do another round of revisions
Lagally: including a title update
geolocation
<kaz> issue 180 - Geolocation Review
Christine: I also created individual issues for specific problems
… in particular, AR/VR; I don't think it's exactly a horizontal use case; the "virtual guide" should be moved to "Smart City".
McCool: I concur
Lagally: rationale makes sense
… we put it in horizontal because AR applies to many things
Christine: agree it could be modified a bit
Christine: core recommendation is that it is not a horizontal use case, it is an enabler, not a use case for WoT itself
Lagally: the issue is if we put it in smart cities, it sounds like we can't use it for health
Christine: right, it applies to all of them where visualization is a goal
… purpose of use cases is just to generate requirements; putting in one place is enough to satisfy goals of extracting requirements
McCool: problem is that this, as written, is a vertical use case
Christine: argue we don't even need a vertical description, is enabler for human, not WoT
McCool: analogy is browser...
Lagally: since we are running out of time, defer to next week
… maybe have to follow up some more with Christine
Kaz: as one of the original proposals, agree with ML's position
… question is whether we need to restructure document or not; do we even need two sections, one for vertical and horizontal?
… perhaps too simplistic
Lagally: maybe defer to next cycle
McCool: sure, but I think that is later this year, not next charter
Lagally: in next call will look again at geolocation
<kaz> [adjourned]