Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Sat, 20 Dec 2014 05:05:58 +0000

Yes, that is a good point. I wondered myself (at this day and age) which
long-lived content is actually represented by a single long lived flow.

- From what I understood from video streaming folks  multiple connections
are used and switched at different times.
- Download managers and torrents use 100s of connections to download a
single file. 

Regards,

Reinaldo

On 12/19/14, 8:01 PM, "Tirumaleswar Reddy (tireddy)" <[email-masked]>
wrote:

>Section 3 (Long-tail Content CDN Use Case)
>
>Comment> Content could also be split into chunks (span of 2-3 minutes)
>and each chunk can also be downloaded using a different HTTP(S)
>connection. Long-lived content does not mean long-lived flow.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 20 Dec 2014 00:26:25 -0500

There are many cases where there is not a long lived flow.  This use 
case does not apply to those.  Trying to infer correlation across flows, 
and guessing that new flows are safe based on old flows, is unlikely to 
be effective.

Having said that, observation shows that there are MANY circumstances 
where there are large, long-lived, flows.  Some of the other working 
groups have been working on tuning ECMP for those, because the "normal" 
behavior can sometimes produce very undesirable results.

Equally, there are some flows which can not be judged "safe".  There are 
some (many actually) which can.  The use case does not claim that all 
flows are safe, or even that all flows can be determined.  But some 
flows can be determined to be safe.

And while encryption makes the application of many of these services 
more complicated, and we expect a lot of traffic to be encrypted, I for 
one don't want to give up on doing what we can in terms of service steering.

Yours,
Joel

On 12/20/14 12:05 AM, Reinaldo Penno (repenno) wrote:
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>