Subject: [core] Cullen Notes from CORE IETF84 meeting #2

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 3 Aug 2012 18:33:30 +0000

These are my random notes from the congestion portion of the meeting. They were mostly meant for me but thought I would send them to the list. 

minute takers for meeting are : Andrew McGregor & Dominique Barthel 

David black:
see RFC 5405 
don't compare to TCP because not doing enough packets to cover this

Sal: Key problem is lots of nodes sending little, not one node sending lots 

On the topic of collapse. For example earth quake and many sensory react at same time. 

David Black 
Need to think about a RTT estimator. Look hard and see what you can do with RTT. Problem is we are using fixed RTT. 

Lars - obviously there are situation we will have congestion collapse. The question is does it work in the operating region we want to be in. Drafts need to say something about what region they can work in - like bandwidth and number of  nodes. 

Lars - if you can't do RTT, should not do more than 1 outstanding transaction. 

David - packet size matter expect when it does not. We have resources that congest on per packet, not on number of bytes. 

Michael Scharf - need to separate out confirmable and non conferrable behavior. 

Lars - pushed back on no room for minimal congestion state

Ekr - for example, seem like we could have space for crude for RTT estimator 

Jari - we can add a simple RTO implementation relatively easy. Need to deal with what happen when sending to multiple locations. For example is one location is down, don't want to block sending to other locations. 

David Black - bought up flash mob effect where all 3 milling sensors talk at same time

Jari - not sure endpoint is right answer 

David - we should do the solution that has the best "do no harm" type solution. We might be able to serrate flash mob case vs normal reporting case. 

on topic of delaying non confinable at 7B/s

Michael - pushed on not having state to do this and argued 

Black - if you don't want to RTT estimator, then stuck with 1 outstanding packets. 

On the topic of multicast reposes dithering stuff 

Lars - is you use 2.5 seconds estimate to start, but you need a way to slow this down. So restarted in at 2.5 scones again after a transaction had failed would not be ok

Don't want to be in state pealing batteries out of device to get million sensors to stop the collapse. 

--------------------------

On to what can we do.

Lars - limited bandwidth, if few nodes can send lots, if lots of nodes very hard 
- can you overhear packets send by others? Can tell how busy the channel is ? Is there link layer information ? 

???
1)  unlike wired network, don't want to assume every loss is due to congestion. 
2) if we have 2 or more classes of devices, what mix of theses causes things to fail. If all the automation systems in a building, and if you had a massive power outage, could be bad. Congestion nightmare. 

David Black - possible the flash mob problem can be separated out and dealt with much like multicast dithering. If you can be on network that is all soap traffic, self fair more important in theses case that TFRC. 

Andrew - Go read Tim ? PHD Thesis. Very good on congestion on wireless mesh. 

Michael - important thing is congestion avoidance. And if we have congestion, we have to react. 

Lars - can view this as an energy management problem. Don't want to do 

Lars - What we do complete no state? very hard. But with very little state. If we are talking 10 of bytes of total state and times, we can come up with something reasonable. 

Richard Calsen? - if you are running DTLS, just do RTT. Convinced RTT is right thing to do. Our ram and flash get used up by "just a little bit". Sort of by the argument here but scared of  

David black - on the confirmable. We get and RTT. And we get an ack locking. We should think about expanding the dither. If we have way to extend differ, can help deal with accidental synchronization. Do something fairly simple and tightly constrained, and allow people to do more if they do more. 

??? - we are wireless nodes that fluctuate lots so saving state does not help much.

Lars - do your link layers deliver corrupted packets? 

David Black - a course RTT estimator can help a lot. The difference of dealing with 1/2 second vs 5 second RTT is huge. 

Andrew McGregor - any previous estimate tends to be better than just using a default.

Lars - for non confinable, very hard if they are bulk of the traffic 

Andrew - require that certain small faction of non confirmable are conferrable - between 1 and 12 % of time ? 

Zach - would be fine with requiring percentage of confirables. You are concerned that some of data is getting there. 

Folks working on congestion plan: Carsten,  Lars, David, Andrew, Bert, Michael

Do we have test beds or simulators ?

----------------------

Groupcom 

Jorg - brought up issues you often can't tell if received packet came on multicast or not. 

Lars - Multicast issues. Responses have to fall under the other congestion budget. 

Zach - need to deal with not getting 404 back from half the group 

------------

AD - don't want work gin groups presentation of 30 drafts. Priortize on mailing list then perhaps talk about top few