Re: [p2pi] Follow-Up from Comcast Presentation

[Richard Bennett <[e-mail]>]

This is an interesting discussion. By way of introduction, I'm mainly an 
IEEE 802 guy, having contributed to 802.3, 802.11, and 802.15.3a, but I 
did have some input into RFC 1001 and 1002, and have worked on Bandwidth 
Brokers to support video conferencing and that sort of thing for a 
while. I think some combination of Re-ECN and Diffserv will solve the 
congestion problem that we see on primarily on Layer 2 networks thanks 
to increased use of P2P.

In the 802.11e/Wi-Fi Alliance WMM world, we created four priorities that 
are easily mappable to DSCP and 802.1d VLAN tags: Voice, Video, Best 
Effort, and Background. The worse-than-best-effort service is 
Background. WMM is implemented in all the wireless NAT boxes that have 
sold over the last three years or so, so it's basically the status quo 
model for residential networks. In the early days of the Internet, 
during the Great Switchover period, the default Layer 2 was DIX 
Ethernet, a single service system, but nowadays Wi-Fi is a major part of 
the Layer 2 scenario with its four service classes. We could do worse 
than see how to smoothly integrate this sort of Layer 2 service into the 
IETF stack.

David Clark made the observation at the FCC hearing in Cambridge that it 
would be nice for the network to communicate its congestion state to 
applications a priori, so that applications would make decisions about 
how to handle current conditions. This strikes me as a wise enhancement. 
It would no doubt be facilitated by a system that improved 
layer-to-layer communication within the stack.

IEEE 802 goes to great pains to describe Service Access Points at each 
layer and a variety of return codes for accessing functions. In 
principle a Layer 3 function desiring a specific priority from Layer 2 
can simply ask for it when presenting a packet, and be told if it got 
what it wanted. In practice, the DiffServ model of tagging packets with 
priority can be married with 802.11e/WMM through what we call a 
Convergence Function in 802 land. The 802.11e standard actually 
describes one, but I'm not sure it's right.

We probably won't make much progress here if we engage in too much 
hand-waving and opining about the old days of the Internet and what 
assumptions developers may or may not have, so it's probably wise to 
stick to specifics as Nick has below.

Richard Bennett

Nicholas Weaver wrote:
> There is always just "friendlier than TCP-Reno under reasonable ranges  
> of latency and bandwidth" as a definition, so conventional TCP flows  
> will outcompete the "scavenger" service.
>
> Of which there are plenty of examples, including TCP-vegas, of stable  
> congestion control algorithms which have this property.
>
> So the question is not "How do you do this?" but "Why is this not  
> done?".
>
> I believe that the Linux stack, for example, allows you to switch the  
> behavior of newly-created flows from Vegas to Reno with a /proc update.
>
> _______________________________________________
> p2pi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/p2pi
>   
_______________________________________________
p2pi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/p2pi