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

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 7 Nov 2010 08:04:15 -0800

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.

-acbegen

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 7 Nov 2010 16:15:35 +0000

> Interestingly, several other lists were copied to this email but not the main httpstreaming list. I would recommend dropping other lists. One comment inline.

Ah! I just replied to the original e-mail which appears not to have included the [email-masked] list, thanks for including it & snipping the other lists.

> 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…

Agreed. IMO this is purely a deployment/implementation issue and not something that needs any standardisation.

Ben

---

From: Colin Perkins <[email-masked]>
Date: Mon, 8 Nov 2010 00:36:15 +0800

> On 7 Nov 2010, at 16:04, Ali C. Begen (abegen) wrote:
...
> Agreed. IMO this is purely a deployment/implementation issue and not something that needs any standardisation.

It *might* make sense if the aim were to add an HTTP header to mark HTTP streaming requests, so that a web proxy treated them differently? (i.e., differentiation at the HTTP service layer, not at the network layer).

Colin

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 7 Nov 2010 08:43:42 -0800

> From: Colin Perkins [mailto:[email-masked]]
> Sent: Monday, November 08, 2010 12:36 AM
> To: Ben Niven-Jenkins
> Cc: Ali C. Begen (abegen); [email-masked]
> Subject: Re: [httpstreaming] [AVT] Fw: Agenda and Slides
> 
> >> 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.
> >
> It *might* make sense if the aim were to add an HTTP header to mark HTTP streaming requests, so that a web proxy treated
> them differently? (i.e., differentiation at the HTTP service layer, not at the network layer).

Sure, but that does require changes in the proxies. And if we start going down that path, there are many, probably better, things that we can do.

-acbegen

---

From: Mark Watson <[email-masked]>
Date: Sun, 7 Nov 2010 09:31:26 -0800

Sent from my iPad

> It *might* make sense if the aim were to add an HTTP header to mark HTTP streaming requests, so that a web proxy treated them differently? (i.e., differentiation at the HTTP service layer, not at t…

But why ? It's not clear to me at all that "HTTP Streaming" traffic (whatever that means) should have 'higher priority' (whatever that means) than other web traffic. HTTP streaming clients generally have at least tens of seconds of buffer, meaning they can absorb delays in delivery, whereas for a web page every delay translates into the user waiting, and the user really wants their whole page as fast as possible.

If there are additional HTTP features that would be good for HTTP Streaming (and I am sure there are) these should be designed as generic HTTP enhancements.

This discussion needs to be much clearer about the assumptions and what is actually meant by the various terms being used.

...Mark 

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

---

From: Wenbo Zhu <[email-masked]>
Date: Mon, 8 Nov 2010 17:17:34 +0800

On Mon, Nov 8, 2010 at 12:43 AM, Ali C. Begen (abegen) <[email-masked]>wrote:

> > >>> 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
> > >>> This is not correct, it is possible to apply different treatment to
> HTTP Streaming traffic Vs "regular" web page traffic, e.g.
> > by
> > >> 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
> > > Agreed. IMO this is purely a deployment/implementation issue and not
> something that needs any standardisation.
> >
> > It *might* make sense if the aim were to add an HTTP header to mark HTTP
> streaming requests, so that a web proxy treated
> Sure, but that does require changes in the proxies. And if we start going
> down that path, there are many, probably better, things that we can do.
>
Isn't this one of biggest advantages of using HTTP, i.e. services are
allowed to define/advise special semantics at the protocol-level without
breaking the transport-level compatibility.  I am glad that DPI was even
mentioned.

- Wenbo