A suggestion for draft-polk-tsvwg-rfc4594-update

Although I am mainly interested on online games, in my university there are
more serious people working on Telemedicine services. I was wondering if it
could be interesting to include in the draft a class for these kind of
services. I have been talking with Jose Garcia, a Professor whose research
interests are in Telemedicine, and he has told me that there are two kinds
of telemedicine services:

-          Non real-time: e.g. I send a radiography, and the doctor will
have it this afternoon.

-          Real-time: examples:

o    A doctor is in a hospital in a big town. A nurse is in a small village
with a patient. There is a service including video, voice and an
electrocardiogram signal established from the village to the hospital, that
allows a single doctor to attend a number of villages.

o   Another example: An ambulance carrying an injured man going to the
hospital, and connected to the Internet using the mobile cellular network to
send the electrocardiogram, voice, etc. to a doctor who is waiting in the
hospital.

So we could think in the working group the possibility of including some
service class for this. If we are trying to reduce latency for VoIP or
online games, why not thinking about this?

This would be similar to what we do in real-life: letting the ambulance
pass. Logically, we would have to be careful: some “smarty-pants” person
would try to follow the ambulance and take advantage of it. In our case, a
“smarty-pants” gamer could change his traffic in order to have a bigger
priority.

What do you think?,

Jose Saldana

At 04:47 AM 4/13/2012, Jose Saldana wrote:
>  ...
>
>This would be similar to what we do in real-life: letting the 
>ambulance pass. Logically, we would have to be careful: some 
>"smarty-pants" person would try to follow the ambulance and take 
>advantage of it. In our case, a "smarty-pants" gamer could change 
>his traffic in order to have a bigger priority.
>
>What do you think?Hi Jose,

You are discussing two mechanisms in series:

  - classifying telemedicine traffic by itself
  - arranging that (some) telemedicine traffic has priority treatment

I don't think it is in scope to establish relative class priorities.

There *should* be other classes whose characteristics can satisfy
the needs of the telemedicine applications you describe
(there are many classes!), and priority can be established in many ways.
It is a common tendency to identify a new application and decide
it needs special treatment in a class by itself, that's partly how
we arrived were we are, IMO.

regards,
Al

At 06:17 AM 4/13/2012, Al Morton wrote:
>At 04:47 AM 4/13/2012, Jose Saldana wrote:
>>  ...
>>
>>This would be similar to what we do in real-life: letting the 
>>ambulance pass. Logically, we would have to be careful: some 
>>"smarty-pants" person would try to follow the ambulance and take 
>>advantage of it. In our case, a "smarty-pants" gamer could change 
>>his traffic in order to have a bigger priority.
>>
>>What do you think?
>
>Hi Jose,
>
>You are discussing two mechanisms in series:
>
>  - classifying telemedicine traffic by itself
>  - arranging that (some) telemedicine traffic has priority treatment
>
>I don't think it is in scope to establish relative class priorities.
>
>There *should* be other classes whose characteristics can satisfy
>the needs of the telemedicine applications you describe
>(there are many classes!), and priority can be established in many ways.
>It is a common tendency to identify a new application and decide
>it needs special treatment in a class by itself, that's partly how
>we arrived were we are, IMO.I agree with Al. We're trying to avoid application specific service 
classes, but rather determine the necessary traffic characteristics 
for applications, then slotting those applications into service 
classes - if, and only if - they are widely used. There are 
exceptions to this rule in both directions. But we want to keep them 
to a minimum.

James>regards,
>Al
>
>

I think I get the point: if we have two VoIP conversations, one from an
ambulance carrying an injured man, and other one from a VoIP client, then
the two conversations have the same delay requirements, so they should be in
the same service class. The problem of prioritizing the first one does not
have to be solved by rfc4594-update. Perhaps the access provider may have a
special channel for ambulances, or something like that.

The different types of telemedicine can be found here:
http://en.wikipedia.org/wiki/Telemedicine#Typ.... Perhaps it
is correct that none of them can be seen as a new service. Perhaps
telesurgery (http://en.wikipedia.org/wiki/Telemedicine#Tel...), but I
don't think it is a good idea to use the Internet to do telesurgery (at
least if I am the patient). A dedicated link should be necessary in this
case.

Best regards,

Jose

-----Mensaje original-----
De: James M. Polk  
Enviado el: viernes, 13 de abril de 2012 21:05
Para: Al Morton; ; 
CC: José García Moros
Asunto: Re: A suggestion for draft-polk-tsvwg-rfc4594-updateAt 06:17 AM 4/13/2012, Al Morton wrote:
>At 04:47 AM 4/13/2012, Jose Saldana wrote:
>>  ...
>>
>>This would be similar to what we do in real-life: letting the 
>>ambulance pass. Logically, we would have to be careful: some 
>>"smarty-pants" person would try to follow the ambulance and take 
>>advantage of it. In our case, a "smarty-pants" gamer could change his 
>>traffic in order to have a bigger priority.
>>
>>What do you think?
>
>Hi Jose,
>
>You are discussing two mechanisms in series:
>
>  - classifying telemedicine traffic by itself
>  - arranging that (some) telemedicine traffic has priority treatment
>
>I don't think it is in scope to establish relative class priorities.
>
>There *should* be other classes whose characteristics can satisfy the 
>needs of the telemedicine applications you describe (there are many 
>classes!), and priority can be established in many ways.
>It is a common tendency to identify a new application and decide it 
>needs special treatment in a class by itself, that's partly how we 
>arrived were we are, IMO.I agree with Al. We're trying to avoid application specific service classes,
but rather determine the necessary traffic characteristics for applications,
then slotting those applications into service classes - if, and only if -
they are widely used. There are exceptions to this rule in both directions.
But we want to keep them to a minimum.

James>regards,
>Al
>
>