Subject: Some comments about draft-polk-tsvwg-rfc4594-update-00

From: "Jose Saldana" <[email-masked]>
Date: Wed, 4 Apr 2012 08:18:58 +0200

James,

I have been reading the draft, and I have found some small errors, which may
be corrected in the next version.

Best regards,

Jose Saldana

--------

- Page 3, first paragraph of the introduction: There is something wrong in
this sentence:

>Local administrators are who configuration each router for which
Differentiated Services Code 

>Points (DSCP) are to be treated differently, ...

- Page 4: There is something missing in this sentence:

>[ID-DSCP] goes further to explain that may layer 2 technologies fewer bits
for marking and prioritization.

- Page 15: It is said that 

>Conversational service group consists of five service classes:

But only three classes appear

- Page 16, Real-time paragraph. Games do not use RTP, but only bare UDP an
TCP.

>Real-Time Interactive, which includes both 'admitted' and 'unadmitted'
Realtime-Interactive

>service class, is for bidirectional variable rate inelastic applications
that require low 

>jitter and loss and very low delay, such as interactive gaming applications
that use 

>RTP/UDP streams for game control commands,

- Page 20: You say that real-time interactive service has to work with very
low loss rate. This may be true or not. In a reference I sent yesterday, it
was shown that Microsoft's game "Halo" stops working with 4% packet loss,
whereas Quake III works well with 30%, and players do not notice

- Page 42, first paragraph: 

>Interactive gaming applications that do not have the ability to change
encoding rates 

>or to mark packets with different importance indications is one good
example of such an 

>application.

I think that talking about encoding rates for games is a bit confusing. The
games I have studied do not modify encoding rates, since they do not
transmit audio or video. They only transmit the game status or the actions
of the player. The game is rendered in the local machine. One exception:
games including a voice channel in order to coordinate the different
players.

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 04 Apr 2012 16:35:35 -0500

Jose

Thanks for catching these, I'll fix each of them in the upcoming revision.

James

At 01:18 AM 4/4/2012, Jose Saldana wrote:
>James,
>
>I have been reading the draft, and I have found some small errors, 
>which may be corrected in the next version.
>
>Best regards,
>
>Jose Saldana
>
>--------
>
>- Page 3, first paragraph of the introduction: There is something 
>wrong in this sentence:
> >[ID-DSCP] goes further to explain that may layer 2 technologies 
> fewer bits for marking and prioritization.
>
>
>- Page 16, Real-time paragraph. Games do not use RTP, but only bare 
>UDP an TCP.
> >Real-Time Interactive, which includes both 'admitted' and 
> 'unadmitted' Realtime-Interactive
> >service class, is for bidirectional variable rate inelastic 
> applications that require low
> >jitter and loss and very low delay, such as interactive gaming 
> applications that use
>- Page 20: You say that real-time interactive service has to work 
>with very low loss rate. This may be true or not. In a reference I 
>sent yesterday, it was shown that Microsoft's game "Halo" stops 
>working with 4% packet loss, whereas Quake III works well with 30%, 
>and players do not notice
>
>
> >Interactive gaming applications that do not have the ability to 
> change encoding rates
> >or to mark packets with different importance indications is one 
> good example of such an
> >application.
>
>I think that talking about encoding rates for games is a bit 
>confusing. The games I have studied do not modify encoding rates, 
>since they do not transmit audio or video. They only transmit the 
>game status or the actions of the player. The game is rendered in 
>the local machine. One exception: games including a voice channel in 
>order to coordinate the different players.
>

---

From: "Jose Saldana" <[email-masked]>
Date: Fri, 6 Apr 2012 13:07:08 +0200

One errata:

Page 16: "conversational signaling" service appears twice in the list of
services.

Regards,

Jose

-----Mensaje original-----
De: James M. Polk [mailto:[email-masked]] 
Enviado el: miércoles, 04 de abril de 2012 23:36
Para: Jose Saldana; [email-masked]
Asunto: Re: Some comments about draft-polk-tsvwg-rfc4594-update-00

Jose

James

At 01:18 AM 4/4/2012, Jose Saldana wrote:
>- Page 3, first paragraph of the introduction: There is something wrong 
>in this sentence:
>- Page 16, Real-time paragraph. Games do not use RTP, but only bare UDP 
>an TCP.
>- Page 20: You say that real-time interactive service has to work with 
>very low loss rate. This may be true or not. In a reference I sent 
>yesterday, it was shown that Microsoft's game "Halo" stops working with 
>4% packet loss, whereas Quake III works well with 30%, and players do 
>not notice
>
>
>I think that talking about encoding rates for games is a bit confusing. 
>The games I have studied do not modify encoding rates, since they do 
>not transmit audio or video. They only transmit the game status or the 
>actions of the player. The game is rendered in the local machine. One 
>exception: games including a voice channel in order to coordinate the 
>different players.
>

---

From: "Jose Saldana" <[email-masked]>
Date: Fri, 6 Apr 2012 13:27:36 +0200

James,

Another question: Clarifying the number of services and clases. I have
summarized the service classification you present in the draft, at the end
of this message. Some suggestions:

1) The fact of grouping "Audio", "Hi-Res Video" and "Video" into a group,
makes it a bit confusing. In the figures, you consider them as different
services, but in page 15 you put them at a different level. This results a
bit confusing for the reader: are them a class or three classes? Since you
use them separately in the next classifications, I think that the paragraph
" Conversational service group consists of five service classes" could be a
comment, and then you could put the three services using "o" instead of "-"

2) Perhaps "Broadcast video" in page 18 could be "Broadcast". There is also
audio broadcast.

3) Perhaps the order of the different services could be the same in section
2.1, section 2.2 and the figures 2, 3 and 4. Perhaps it is not possible, but
the draft would read better.

4) In figure 2, best effort service is called "standard", but in figure 3 it
is called "best effort".

Regards,

Jose

--------------------------------
Summary of the different classifications:

Classification of draft-polk-tsvwg-rfc4594-update-00, section 2.1:

* Network control

o "Network Control" for routing and network control function.
o "OAM" (Operations, Administration, and Management) for network
configuration and management functions.

* The user/subscriber traffic group is broken down into ten (eleven) service
classes to

o Audio		\
o Hi-Res Video	- Conversational service includes three service classes
o Video		/
o Conversational Signaling (it appears twice in page 16)
o Real-Time Interactive
o Multimedia Conferencing
o Multimedia Streaming
o Broadcast
o Low-Latency Data
o High-Throughput Data
o Standard service class, commonly called best effort (BE)
o Low-Priority Data

So we have 2 + 12 = 14 service classes

Figure 2, 3, 4 include 14 service classes.

Classification of draft-polk-tsvwg-rfc4594-update-00, section 2.2 (only
user/subscriber traffic group): 12 application classes, divided into 4
categories

* Application Control Category

o Conversational Signaling 

* Media-Oriented Category

o Audio
o Video
o Hi-Res Video
o Realtime-Interactive
o Multimedia Conferencing 
o Broadcast video 
o Multimedia Streaming

* Data Category

o Low-Latency Data
o High-Throughput Data
o Low-Priority Data

* Best-Effort Category
o Standard