Subject: [p2pi] ietf mandate ...

From: "Don Bowman" <[email-masked]>
Date: Sun, 8 Jun 2008 14:28:22 -0400

One of the questions we left unanswered was what, if anything, the ietf
should do to be involved.

Since the ietf is a technical standards body, rather than a political
or legal, that contrains the area 'somewhat' :)

personally I have a real problem with the idea of 'flow destination
selection signalled from the network for times of congestion
or locations of cost', I think that it will be very hard, these
things change dynamically (mobile ip, load, network failovers,
ospf changes, ...). Thus I am not a fan of trying to build the
'best cost path' approach (despite having designed and deployed
Product at large scale that did this)... although its pragmatic
For certain classes of network, its not a generic solution.

I really like the idea of a true scavenger class. It would
hugely incent ISP's and operate in the best interest of the
users of the network. People could have a 'quota' that they
purchased as part of their plan, and choose to spend their
credits on each packet according to its delivery guarantees.
Any packet they didn't wish to 'pay for' would go in scavenger.
The implementation of a true end-to-end scavenger class is
quite hard, when placed into network designs that have properties 
like:
 * L2 (ATM, MPLS, ...) that don't look @ DSCP mark
 * overlay networks that priortise the overlay rather than the
   Packets within
 * access equipment that doesn't look @ packet priority
 * dynamic bandwidth access networks such as WiMax, 3GPP

So this is an area a standard's body could invest additional
(I'm aware of the considerable efforts thus far) effort.

Another idea which might have merit is the use of 'anycast'
With ipv6 it would be economic to assign an ipv6 anycast
IP to each unique piece of content, and on a packet-by
Packet basis (e.g. SCTP? UDP?) obtain it from the 'closest'
location, even as you or the destination moved around a mobile ip
Network. I realise this is a proposed implementation, but
Maybe forget the method... I think TCP is just the incorrect
transport to get content from many locations that offer
the same thing, when the transfer might be long in duration
and high in cost.
For this to work, a fairly dynamic directory service
(think DDNS w/ huge update rates) would be pretty cool.
Its kind of similar to the problem of allocating a new
Multicast group address, world-wide.

The 'anycast' addressing scheme would lend itself well
to access ISP who had a higher cost of upstream than
downstream (e.g. WiMax, Cable, 3G), or ones which had
a higher cost of transit than access (e.g. island nations)
as they could more easily deploy caching.

So maybe a standard which allowed:
* allocation of 'l3 address' <-> content
* scavenger-aware connectionless, guaranteed transport to dynamic l3
endpoints

Would be pretty cool. It would align a lot of 'non-technical' interests
too.

The issue of user-to-user fairness w/in the scavenger class would
be left to the ISP to enforce in some fashion, either economically
or technically or not at all.

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

---

From: "Robb Topolski" <[email-masked]>
Date: Sun, 8 Jun 2008 16:10:20 -0500

> For certain classes of network, its not a generic solution.

Don,

Although your suggestion comes with so many asterisks and concerns that I
don't quite know what to make of it all, *I like the gist of it*.  (If
congestion control really needs to be fixed, that is, which I am trending
toward the doubful side as events unfold.)

However, thinking about your suggestion, I have this question:  Can you help
me understand it by contrasting it to (my understanding, at least, of) DSCP
/ DiffServ?

Instead of a scavenger class, why couldn't "best-effort" or undesignated
traffic *be *the scavenger class traffic, and allow consumers to designate
some relatively tiny amount (either by monthly allocation or daily
percentage or whatever) for Expedited Forwarding.  (The EF quota would be an
amount definitely enough to make VOIP and head-to-head games work -- since
that's the practical example that we have today -- but the choice of what to
prioritize is the users' and not the ISP's purview.)

This idea could be built upon further with a second larger quota with some
"average" amount for a better-than-default Assured Forwarding class.  We
could think of this as an "very interactive class" or perhaps a "live
streaming" class.   What's left is "best-effort."

Users (through their applications) could identify which packets are which.
To prevent abuse, the network should ignore the markings if the user is
above their quota for that DSCP.

An opt-in DPI device at the carrier could help consumers get on board
without further configuration.  It would feature a one-size-fits-most preset
that applies for most users. Otherwise, consumers could enable or upgrade
their applications and equipment to enable packet marking to fit their own
desires.

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

---

From: "Don Bowman" <[email-masked]>
Date: Sun, 8 Jun 2008 18:45:07 -0400

From: Robb Topolski [mailto:[email-masked]] 
Sent: 2008-06-08 17:10

>Although your suggestion comes with so many asterisks and 
>concerns that I don't quite know what to make of it all, 
>I like the gist of it.  (If congestion control really needs 
>to be fixed, that is, which I am trending toward the doubful 
>side as events unfold.)

>However, thinking about your suggestion, I have this question: 
>Can you help me understand it by contrasting it to (my 
>understanding, at least, of) DSCP / DiffServ?

>Instead of a scavenger class, why couldn't "best-effort" or 
>undesignated traffic be the scavenger class traffic, and 
>allow consumers to designate some relatively tiny amount 
>(either by monthly allocation or daily percentage or 
>whatever) for Expedited Forwarding.  (The EF quota would be 
>an amount definitely enough to make VOIP and head-to-head 
>games work -- since that's the practical example that we 
>have today -- but the choice of what to prioritize is the users' 
>and not the ISP's purview.)  

BTW, I think I'm also proposing the same thing: a user-to-user
enforced 'fairness' in the network, and then you set the
priority on your packets within that 'envelope'.

My suggestion is not exclusive of DSCP. However, scavenger / 
Congestion is more than just drop.

Consider that I use UDP for all my traffic, and I transmit
@ a constant 10Mbps rate. I go through 3 successive choke
points in the network, 1 in my home @ 6Mbps, 1 in the 
access network @ 4Mbps, and 1 in the core network @ 2Mbps.

In the DSCP - only model, I will have 40% dropped in my
modem, another 20% dropped in the access, and another
20% dropped in the core, constantly.

The 20% dropped in the core still leaves 20% of access
BW consumed that helped no one: not me, not the destination.
DSCP would have simply tried to drop my packets with a higher
priority than some others, but I would still have fought
against others of the same priority (and others of higher
priority).

In a perfect world, this 2Mbps minimum rate would have been
instantly known by the sender, who would have xmit no more
than 2Mbps.

So clearly DSCP alone is not sufficient to create a 'scavenger
class'.

Now, consider the same as above w/ TCP. Various TCP implementations
balance the bandwidth-latency product differently, slow
start, nagle, delayed-ack, reno, vegas, window sizes, sack,
lots of algorithms that try to make it robust, good throughput, etc.

So one option is to simply set the DSCP on TCP and see what
happens, those end-to-end bandwidth factors get keyed in
somehow.

Some access technologies have control systems (e.g. WiMax)
which may fight with this, they dynamically increase your bandwidth.

Some network topologies carry those DSCP - encoded packets over
a type of link that ignores them. DSL does this (typically).

The link from your home to a DSLAM is yours alone. But the
link from your DSLAM to your BRAS is shared, and is typically
a L2 tunnel on ATM. This is where the oversubscription occurs,
and there is no use of DSCP.

In fact, its practically a guarantee that somewhere between
Your house and your destination you travel over at least one
tunnel. If the tunnel is but one hop, the right thing might
still happen as the label-edge-router will use the DSCP to
decide which packets to route into the tunnel, and which to
drop. But I suspect a single-hop tunnel is not so common.

Similarly in a wireless network, 3GPP(2) use a proportional-fair
algorithm to try and maximise the useful BW of the network.
They have the challenge that as you walk further into a building,
your data rate goes down. As the sky gets cloudy, buildings
go up, you get in a train, etc... a very dynamic environment.
And, the highest cost part of the network, the RF side, doesn't
use that DSCP mark at all. Once a packet is xmit from you onto
the RF, they want to keep it (no sense making you retransmit it).
The worst case is to drop an ACK packet upstream for an already
delivered downstream packet.

So I guess a 'scavenger class' is not that simple as just
a DSCP mark. In an enterprise network it is, but as an end-to-end
method through multiple providers, it doesn't really work.
* access technology rarely is able to use it on all pieces
  (DSL doesn't, docsis doesn't, wimax doesn't, 3gpp(2) doesn't)
* providers remark on the border to prevent 'theft of qos'
* tunnels through the core ignore

We also have the issue of the widely deployed nature of things
(e.g. home routers, NAT, MS Windows networking stacks, ...) which 
makes 'improvements' frustrating :) The so-called '80%' problem:
80% of the solution exists, so its not too motivating to work
on the 100% solution. E.g. why switch to ipv6, I can just go
buy another NAT.

Networks have switched to packet-switched for a reason, so
we can't really go back to 'this flow has this property'
 -> core routers just can't handle the routing table size or
updates needed.
 -> I'm arguing in mobile ip it would be non-constant anyway

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 9 Jun 2008 15:31:47 -0400

Replies inline below.  Took me an extra moment to type this, as I fell
out of my chair when I saw Robb suggest he supported using DPI below.
;-)
 
Jason

	Instead of a scavenger class, why couldn't "best-effort" or
undesignated traffic be the scavenger class traffic, and allow consumers
to designate some relatively tiny amount (either by monthly allocation
or daily percentage or whatever) for Expedited Forwarding.  (The EF
quota would be an amount definitely enough to make VOIP and head-to-head
games work -- since that's the practical example that we have today --
but the choice of what to prioritize is the users' and not the ISP's
purview.)   

	Users (through their applications) could identify which packets
are which.  To prevent abuse, the network should ignore the markings if
the user is above their quota for that DSCP.   
	 
	So, best effort is best effort today, and you have a priority
class (that you call EF).  In this imagined priority class, what quota
would you attach to it?  64Kbps, 96Kbps, etc.?  I am guessing in this
case that you would need user devices and/or software to designate the
use of such a class, therefore delegating priority selection to these
users and/or their software/devices.  
	
	An opt-in DPI device at the carrier could help consumers get on
board without further configuration.  It would feature a
one-size-fits-most preset that applies for most users. Otherwise,
consumers could enable or upgrade their applications and equipment to
enable packet marking to fit their own desires.  
	 
	So you are suggesting the ISP deploys DPI, so I have marked this
day in history.  ;-)  In all seriousness, though, can you explain what
you mean by 'help consumers get on board without further configuration?'
I am not sure I understand how the DPI function would work in your
suggestion.  Are you saying that it be used in some kind of policy
enforcement function, or to ensure that what is marked as say priority
really 'should' be or 'should not' be priority?  Appreciate any thoughts
you have to expand on what you mean to suggest.

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 9 Jun 2008 12:46:53 -0700

On Jun 9, 2008, at 12:31 PM, Livingood, Jason wrote:
> Replies inline below.  Took me an extra moment to type this, as I  
> fell out of my chair when I saw Robb suggest he supported using DPI  
> below.  ;-)
...

Actually, it makes sense, but DPI is largely overkill (traffic  
analysis will suffice).

If an ISP needs to make a shaping decision on a user to reduce their  
traffic under a threshhold T (or a subsection of their traffic.  This  
could include just the access link in the absence of a smarter end- 
user attachment device), random allocation doesn't actually make sense.

Absent explicit user guidance through QoS or related packet-marking,  
there are several IMPLICIT classes:

1: VoIP and other realtime
2: Interactive TCP (web surfing)
3: Streaming TCP [1]
4: Bulk-data P2P

Which can be easily distinguished by the ISP through traffic analysis  
heuristics, and there is a simple ranking of priority which will  
suffice for almost all users, because this ordering directly reflects  
the usual urgency of the packets.

I believe that such classification BETWEEN users is bad, but within a  
single user's flows, can greatly improve their perceived service, and  
whether opt-in, opt-out, or mandatory in the absence of packet  
marking, would result in a large benefit.

[1] This is about the only case where DPI rather than traffic analysis  
could be a win.  YouTube and others seem to operate in two modes:  
underbuffered and overbuffered.  Thus if there is insufficient  
bandwidth, you get pausing and stuttering.  But if there is  
oversufficient bandwidth, it can get way ahead of the actual point of  
viewing.

Unless the user does a seek to much later in the video, this traffic  
could have easily been throttled back without affecting the user's  
experience, and will significantly reduce the traffic the user  
received if the user stops watching midway through the RickRolling.

Ideally, the Flash-based players should just buffer the right amount,  
but unless they do, DPI could fix this "bug" when congestion is an  
issue for that user.

---

From: "Robb Topolski" <[email-masked]>
Date: Mon, 9 Jun 2008 16:41:50 -0700

Thanks for that explanation, Don!  That was awesome!
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: "Robb Topolski" <[email-masked]>
Date: Mon, 9 Jun 2008 16:55:42 -0700

On Mon, Jun 9, 2008 at 12:46 PM, Nicholas Weaver <[email-masked]>
wrote:

> Actually, it makes sense, but DPI is largely overkill (traffic analysis
> will suffice).
>
> traffic under a threshhold T (or a subsection of their traffic.  This could
> include just the access link in the absence of a smarter end-user attachment
> device), random allocation doesn't actually make sense.

Either way, I don't want to lose the fact that OPT-IN are operative words in
turning control of  TOS/DSCP/XYZ Service Flow classification to the ISP.
Otherwise, its just another violation of Standards and its an awfully lot of
power to put in the hands of a service provider who might be working in the
best interests of their users today but might be "monetizing" them for cheap
tomorrow..  .