[Simple] RE: Comments on draft-ala-kurikka-simple-pidfconn-00

["Jussi Ala-Kurikka" <[e-mail]>]

Hello,
Comments inline.

> -----Original Message-----
> From: Zisimopoulos, Haris, VF-Group
> [mailto:[e-mail]]
> Sent: 15. marraskuuta 2005 10:38
> To: [e-mail]; [e-mail]
> Subject: Comments on draft-ala-kurikka-simple-pidfconn-00
> 
> Hello,
> 
> First I think that the concept of connectivity as part of the Presence 
> information should be further exploited and this proposal provides a 
> good start.
> 
> I have some comments though for this I-D:
> 
> - First of all I think it is unclear what is defined as connectivity. 
> For example it can be (wireless) network attachement, allocation if IP 
> adress, registration in the SIP domain with that contact? It needs to 
> be clarified.

The draft was not explicit on this, I agree. A connectivity is the physical
layer last-hop technology with which an end-user's device is connected to a
network (e.g. 802.3u, 802.11b, GPRS). In order for the presentity to convey
its connectivity features, it should naturally itself know them first.
Without measurements it is typically only possible to know the theoretical
features of a connectivity (if even those). However, as Henning Schulzrinne
pointed out in the SIMPLE meeting, the connectivity is not always the most
constraining part of the end-to-end connection. E.g. in airplanes it might
be the airplane<->Internet connection that is the most constraining one. Of
course, the more accurate the conveyed data, the better the watchers are
able to determine which service to use, if any.

> - Determining the QoS characteristics (eg throughput, delay
> etc) just from the type of the wireless technology is very naïve. Even 
> wireless networks that perform over-the-air resource reservation keep 
> these resources only if there is traffic flowing. Also the allocation 
> of resources largely depends on the overall congestion in the network 
> and can vary over time. Therefore here it would be wiser I think just 
> to indicate the network attachment to a particular network type (eg 
> UMTS,GPRS etc) which *generally* gives some static QoS characteristics 
> indication. For example indicating to the watcher that I am attached 
> in WLAN generally speaking gives the indication that I have better QoS 
> than GPRS (apart from when I am in IETF :-)). I am very sceptical that 
> you can go beyond that unless you do some real-time measurements in 
> the terminal which is something not advisable.

The reason why we wanted to model the features of a connectivity instead of
conveying the network type directly is that this way we do not need to
enumerate the values of the connectivity element for all the possible
connectivities. Simply saying "this element contains a name of the used
connectivity" will not probably do, as it would likely produce
interoperability issues (e.g. a presentity could state either WLAN or
802.11b). We would need to do the enumeration either in the draft or to
specify a reference. I could not find any such reference within the IETF. Of
course, the list of connectivities should also be kept up-to-date, adding
all future connectivities.

It would perhaps be easier for the presentity to convey just the network
type. He would not need to know the theoretical "best-case" features of the
used connectivity but just the type, which could maybe be extracted from the
device name provided by hardware. However, for expressing the network type
to be of any value, the watcher would need to be able to somehow map the
network type to its typical features. Therefore, the watcher would basically
need to know the mapping between names and features of the connectivities of
the presentities they are watching. 

In an implementation based on the current draft, this mapping would not be
needed. Users/software would just need to know for example the throughput
requirements of the sessions they would like to initiate. Presentities could
also convey measured data, e.g. maximum throughput, if they had that
information.

> - The idea of charging indication in an on/off manner is interesting 
> but I think it becomes very complicated if you attempt to go beyond 
> that. So the sentence under 2.3.2.1 that "... followed by any number 
> of elements from different namespaces for an extended specification of 
> the billing." is very difficult to be implemented in a real world.

That might be true. However, we did not want to rule that out either. In
fact, as commented during the discussion after the SIMPLE meeting, even
saying that charge is false or true could be difficult because sometimes
there are also flat fees with a limited amount of megabytes per month. The
megabytes exceeding that amount do in fact affect the presentity's billing.
In that case, the value of <basic> would need to be updated when crossing
that amount.

-Jussi


_______________________________________________
Simple mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/simple