Subject: Re: [httpstreaming] [AVT] Fw: Agenda and Slides

From: Ning Zong <[email-masked]>
Date: Mon, 08 Nov 2010 00:23:26 +0800

Hi, Ali,

Thanks for droping other lists, let's keep one (httpstreaming) list as major. See inline.
  
======= At 2010-11-08, 00:04:15 you wrote: =======

>Interestingly, several other lists were copied to this email but not the main httpstreaming list. I would recommend dropping other lists. One comment inline.
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
>> Sent: Sunday, November 07, 2010 11:54 PM
>> To: Qin Wu
>> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
>> Subject: Re: [AVT] Fw: [httpstreaming] Agenda and Slides
>> 
>> Colleagues,
>> 
>> Reading the slides I'd like to make some comments in advance of the bar-bof, we can discuss them more via the mailing list
>> or in the bar-BoF itself.
>> 
>> HTTP_Stream_1.ppt Slide 14:
>> 
>> "
>>  No distinction regular HTTP traffic from HTTP Streaming traffic
>>   Disadvantage:
>>    Transport streaming media in the same way as web page
>>    transport Streaming media has no priority to be delivered/processed first
>> "
>> 
>> This is not correct, it is possible to apply different treatment to HTTP Streaming traffic Vs "regular" web page traffic, e.g. by
>> the server setting different TOS/DSCP for streaming Vs "web" traffic.
>
>If the network will not respect to these code points (which is the case in the open Internet), this won’t help but the servers themselves can prioritize anything they want to in their scheduling or processing. But, I am having difficulty in understanding why this is relevant to a standardization work. It looks to me as a product feature differentiation.

[Ning Zong]: I agree with you that if the streaming application wants to achieve such kind of differenetiation in E2E way, it is an implementation issue that usually doesn't require interoperability & standardization. But if we want to put this treatment in the network (e.g. intermediary nodes), the standard way (e.g. marking the packets from whatever application servers they were sent) could a better choice... Again, we are quite open to discuss other possible way for such treatment.

>
>-acbegen
>_______________________________________________
>httpstreaming mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/httpstreaming

= = = = = = = = = = = = = = = = = = = =
			
Ning Zong
[email-masked]
2010-11-08

---

From: Qin Wu <[email-masked]>
Date: Mon, 08 Nov 2010 09:50:21 +0800

Sorry, I forgot to drop other lists.
> ----- Original Message ----- 
> From: "Ben Niven-Jenkins" <[email-masked]>
> To: "Qin Wu" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
> Reading the slides I'd like to make some comments in advance of the bar-bof, we can discuss them more via the mailing list or in the bar-BoF itself.
> 
> This is not correct, it is possible to apply different treatment to HTTP Streaming traffic Vs "regular" web page traffic, e.g. by the server setting different TOS/DSCP for streaming Vs "web" traffic.

[Qin]: There are two different levels for service differential
 1evel 1: How to separate HTTP streaming service from High Speed Internet Service(HSI) Since HTTP streaming service and HSI share the same channel and HTTP Streaming service may require more bandwidth or other resource to support high quality content delivery. If the serve can do some mark in the HTTP header and there is some smart cache with intelligence to understand this mark situated between the server and client, the smart cache can treat HTTP streaming traffic in the different way as web traffic.
 
 level2:   How to treat different HTTP streaming traffic with different priorities.
 This is more precise granularity of service differential. If there is way to do this, HD HTTP streaming can be treated in the different way as SD HTTP Streaming. 
 Smart cache is one way to do this.
 
 As for these two levels of service differential, I agree there is other ways to deal with it, I just think it is quite interesting issue to me, when I dig this problem out 
> 
> On 7 Nov 2010, at 07:11, Qin Wu wrote:
> 
>> FYI.
>> ----- Original Message ----- 
>> From: "David A. Bryan" <[email-masked]>
>> To: "httpstreaming" <[email-masked]>
>> Sent: Sunday, November 07, 2010 2:37 PM
>> Subject: [httpstreaming] Agenda and Slides
>> 
>> 
>>> I just uploaded an agenda and the current slides from the
>>> participants. The slides are available as links from the agenda, which
>>> I have uploaded here:
>>> 
>>> http://www.p2psip.org/httpstream/79/Agenda.html
>>> 
>>> I still don't know which room is the IESG room, but I will find out
>>> and post here shortly.
>>> 
>>> Thanks, and see you all on Wed.
>>> 
>>> David
>> Audio/Video Transport Working Group
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/avt
> 
>