Subject: Re: [tana] [p2pi] [tsv-area] TANA proposed charter

From: Laird Popkin <[email-masked]>
Date: Fri, 24 Oct 2008 17:45:33 -0400 (EDT)

I think that "less than best effort" should be applied even more narrowly than that. For example, Pando's customers can use the same software and the same protocol to download the same bits either for a video stream or for a PodCast download, and only the application knows whether the download is time-sensitive or not. My thinking is that we would use "best effort" when downloading video streams that the user is watching, and "less than best effort" when downloading background subscriptions, which gives our users good experiences when they care, and more flexibility to ISPs to manage traffic when users don't care. 

- Laird Popkin, CTO, Pando Networks 
  mobile: 646/465-0570 

----- Original Message ----- 
From: "Robb Topolski" <[email-masked]> 
To: [email-masked] 
Sent: Friday, October 24, 2008 4:35:35 PM (GMT-0500) America/New_York 
Subject: Re: [tana] [p2pi] [tsv-area] TANA proposed charter 

Re: "Scavenger Network Congestion Protocols" -- good, but the inclusion 
of "congestion" could cause various congestion-deniers to avoid the 
group.  ;-)  In such a case, perhaps "control" instead? 

I am also concerned at the use of "scavenger."  Despite the fact that we 
all know what it means, certain folks with various axes prepared for the 
grinding are already having fun demonizing the work scavenger, by saying 
anyone that does this kind of thing just wants to starve their users and 
let them scavenge for scraps of food, etc. (Layer 8 concern) 

Jason is speaking about me, here, and mistakenly so.  I'm not having fun with the word scavenger.  My "axe" isn't that Comcast "wants" to starve their heavy users, it is that it has picked an inappropriate method that makes such an outcome possible.  

Personally, I think ISPs should hand out special cable modems to 24/7/365 P2P users and ask them to install 'em on their non-critical machines (such as something used for P2P) -- anything going through such modem is tagged for that lower-priority service flow. That would keep the gaming/VOIP/surfing traffic out of that class appropriately and ISPs could probably drop both the caps and the throttling. 

I'm not against the Scavenger class. I'm against throwing all of a users' traffic into it. 

--Robb 

Anyway, I have observed these names, and am inserting some suggestions 
of my own: 

1 - Scavenger Network Control Protocols (SNCP or SCAV) 
2 - Scavenger Network Congestion Protocols (SNCP or SCAV) 
3 - Scavenger Network Control Mechanisms (SNCM or SCAV) 
 [...] 

21 - Latency Insensitive Control Specifications (LICS) 
22 - Time Insensitive Data Transfer Enhancements(TIDE or TID-E) 

I think the best "differentiators" word that I've heard in this discussion is the word "Background."  (I've heard the word "passive" used as well, and I generally think that's on target.)  I'm generally not of fan of names that identifies this treatment for P2P or for file transfers or for large transfers, because those can have any priority and can be streaming and it might turn out to be just as appropriate to transfer thousands of small files this way.  I think the word "Congestion" can be dropped because it's not like we're eliminating congestion here, we're just identifying what we don't care about during congestion.  If there is no congestion, it all ought to get through, right?  So with that in mind, and keeping in mind we're going to have to identify a few different network scenarios -- something like "Background Optimized Transfer Handling (BOTH)." 

Robb Topolski 

-- 
Robb Topolski ( [email-masked] ) 
Hillsboro, Oregon USA 
http://www.funchords.com/ 

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

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

---

From: "Robb Topolski" <[email-masked]>
Date: Fri, 24 Oct 2008 15:15:57 -0700

On Fri, Oct 24, 2008 at 2:45 PM, Laird Popkin <[email-masked]> wrote:

> I think that "less than best effort" should be applied even more narrowly
> than that. For example, Pando's customers can use the same software and the
> same protocol to download the same bits either for a video stream or for a
> PodCast download, and only the application knows whether the download is
> time-sensitive or not. My thinking is that we would use "best effort" when
> downloading video streams that the user is watching, and "less than best
> effort" when downloading background subscriptions, which gives our users
> good experiences when they care, and more flexibility to ISPs to manage
> traffic when users don't care.
>
>
This is what I intended to say as well.  I'm with you. If I said something
to the contrary, then thanks for the correction.

 --Robb

-- 
Robb Topolski ([email-masked])
Hillsboro, Oregon USA
http://www.funchords.com/
_______________________________________________
tana mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tana

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 24 Oct 2008 15:58:12 -0700

Laird Popkin wrote:
> I think that "less than best effort" should be applied even more 
> narrowly than that. For example, Pando's customers can use the same 
> software and the same protocol to download the same bits either for a 
> video stream or for a PodCast download, and only the application knows 
> whether the download is time-sensitive or not. My thinking is that we 
> would use "best effort" when downloading video streams that the user is 
> watching, and "less than best effort" when downloading background 
> subscriptions, which gives our users good experiences when they care, 
> and more flexibility to ISPs to manage traffic when users don't care.
> 

Assuming that *only* the application knows the difference between
a time-sensitive and time-insensitive flow is somewhat self-defeating.

The stated goal is to enable time-insensitive flows to "saturate the
network" but be able to yield to guaranteed or best-effort traffic.
At the very least the protocol should be able to provide hints to
Bridges and Routers along the way as to which traffic class a given
frame belongs.

It would certainly be desirable not to *rely* on CoS sensitive handling,
but it should be used when supported.

As your example points out, the upper layer protocol is insufficient
for Bridges and Routers to determine the optimal handling of a given
flow. That is why explicit marking for Bridges and/or Routers would
be beneficial to meeting these goals.

-- 
Caitlin Bestler
[email-masked] - http://www.asomi.com/CaitlinBestlerResume.html
_______________________________________________
tana mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tana