Re: [p2pi] TANA proposed charter -- packet marking question

It's actually not that easy to get a router and an access device (DSL  
modem or cable modem) to do the right thing when they are in separate  
boxes separated by an Ethernet: the router knows how to do smart  
queuing but there's no queue on the Ethernet; the access device isn't  
smart enough to do, say, Diffserv in its queue facing the uplink. (My  
home configuration works pretty well, but is so far from a typical  
home configuration that it's not worth talking about.)

As was noted in the BoF in Dublin, getting well designed routers and  
access devices out into the world and properly configured, and getting  
all the end systems to use Diffserv marking is a solution that we're  
not likely to see soon. That is why the charter says that goals of the  
algorithm are:

> * operate well in networks with FIFO queueing with drop-tail  
> discipline,
> * where available, use explicit congestion notification (ECN),  
> active queue management (AQM), and/or end-to-end differentiated  
> services (DiffServ).

The first bullet says "deal with the world as it is"; the second says  
"deal with the world as you wish it were"

I think that is a very sensible approach.

Bruce

On Oct 24, 2008, at 1:35 PM, Laird Popkin wrote:

> My understanding from talking with some vendors of home routers is  
> that if there were a standard for proper behavior in this area, they  
> would be happy to conform to it. But if there's not a standard, it's  
> hard for them to get engineers and sub-vendors to implement "be  
> smart".
>
> - Laird Popkin, CTO, Pando Networks
>  mobile: 646/465-0570
>
> ----- Original Message -----
> From: "Nicholas Weaver" <nweaver@ICSI.Berkeley.EDU>
> To: "John Leslie" <john@jlc.net>
> Cc: p2pi@ietf.org, tana@ietf.org, "Nicholas Weaver" <nweaver@ICSI.Berkeley.EDU 
> >
> Sent: Friday, October 24, 2008 1:24:49 PM (GMT-0500) America/New_York
> Subject: Re: [p2pi] TANA proposed charter -- packet marking question
>
>
> On Oct 24, 2008, at 9:12 AM, John Leslie wrote:
>>>
>>>
>>> I start a full rate, SINGLE TCP flow to this remote system.  The  
>>> ping
>>> time jumps up to 3 seconds!  Yes, the stupid NAT box or DSL modem
>>> (not
>>> sure which at this moment) has a 3 second packet buffer, and simple
>>> FIFO behavior.  Any full rate upload and I can kiss my connection
>>> goodbye.  Period.  End of story.  Have a nice day.
>>
>>  Fortunately, the Linksys _could_ be easily programmed to fix that --
>> and if the problem becomes obvious enough to enough buyers, the
>> competition will fix it...
>
> I disagree.
>
> I've had DSL or cable modem connectivity for damn-near a decade now.
> And fixing it is easy: the data rates are trivial, the devices are
> often programmable, and the solution straightforward: just have only
> 30ms of packet buffer, not 3s.  Yet these devices STILL have this
> problem.
>
> And the only reason that as a clued user it would be fixable if its
> the Linksys box is I DELIBERATELY purchased the version where I can
> replace the firmware to fix something the vendors refused to fix for
> themselves.  And I just unplugged the linksys: its the DSL modem,
> purchased within the past 2.5 years.
>
> (The reason its not a problem for me is I don't use P2P apps, and only
> rarely upload large quantities of photos)
>
> So I think the conclusion should be there has been a market failure in
> this area, and that absent a miracle, this problem will remain.
>
> _______________________________________________
> p2pi mailing list
> p2pi@ietf.org
> https://www.ietf.org/mailman/listinfo/p2pi
> _______________________________________________
> p2pi mailing list
> p2pi@ietf.org
> https://www.ietf.org/mailman/listinfo/p2pi

_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi