Subject: [ledbat] Review of ledbat draft

From: Murari Sridharan <[email-masked]>
Date: Sun, 27 Mar 2011 12:46:50 +0000

My review as an individual contributor. 

I think the draft is almost there thanks to Jana and Mirja's efforts. There are a couple of issues that I'd like taken care of. I think (assuming I read it right) #3 and #8 are critical and must be fixed. 

1. " LEDBAT can be used, with appropriate extensions  where necessary, with TCP" - I'd like to add some serious caveats as this statement makes it look like it is easily doable. Getting Ledbat to work over TCP requires re-purposing timestamps in a way end nodes agree and understand. I am not questioning the ease of implementation but this would require a decent amount of work which the statement above doesn't quite reflect. 
2. Editorial: " LEDBAT decreases its sending rate quickly as a response to potential  congestion in the network" - I'd remove the word potential here. Potential makes it look like we either don't believe delay increase implies congestion or we don't trust our delay measurements. 
3. May be I am reading this wrong but I think the following is incorrect. 
queuing_delay = MIN(current_delays) - MIN(base_delays)
update_current_delay(delay)
     # Maintain a list of CURRENT_FILTER  last delays observed.
     delete first item in current_delays list
     append delay to current_delays list

The above seems wrong to me because all you need is a few packets to go through without queueing and infact ledbat relies on this to get the correct base delay. Some form of average is needed to protect from this otherwise MIN (current delays) has a pretty good chance of being same as MIN(base delay) and therefore we continue to ramp up when infact we shouldn't.
4. GAIN MUST be set to 1 or less. - Why not just say MUST be set to 1, per our goals that's the right value
5. In practice other delay based algorithms dump the base delay and history when it hits a timeout which is the safe thing to do, we should be recommending something along those lines in the discussion section. 
6. Editorial: " end-to-end  delay measurement" - It may avoid confusion if we keep using one-way delay throughout. For a second I misread E2E as RTT.
7.  " delay of 150 ms  to be acceptable for most user voice applications." - Hmm seems high, I always thought that this number was more like 50ms from SONET numbers. 
8. "LEDBAT does require that the receiver MUST transmit at least one ack in every RTT" 
I think this is a problem as it will make the Ledbat controller ineffective due to bursty release of packets from the send queues upon ACK. Large bursts means flows in the network often see uncharacteristic spikes which makes them go back only to find that further measurements are clean. I think we should recommend that the receiver ACK  once every 2 data packets similar to TCP to keep the ack clock going.
9. RFC 3390 doesn't sound normative to me and if we are making 5681 normative for loss based cc then Bra94 should also be made normative for delay based cc. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rolf Winter
Sent: Monday, March 21, 2011 9:04 AM
To: [email-masked]
Subject: [ledbat] congestion control draft

Hi,

since people clearly have started to read and digest the newest version of the draft, the chairs would appreciate if you could post your general feedback about the document. Something like "I think this is good now" or "it has addressed my previous concerns" etc. would be good feedback for us.

Thanks,

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

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

---

From: Murari Sridharan <[email-masked]>
Date: Sun, 27 Mar 2011 12:48:29 +0000

Rolf, I have some other typos fixed will fwd a commented version to Jana and Mirja offline. 

Thanks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Murari Sridharan
Sent: Sunday, March 27, 2011 5:47 AM
To: Rolf Winter; [email-masked]
Subject: [ledbat] Review of ledbat draft

4. GAIN MUST be set to 1 or less. - Why not just say MUST be set to 1, per our goals that's the right value 5. In practice other delay based algorithms dump the base delay and history when it hits a timeout which is the safe thing to do, we should be recommending something along those lines in the discussion section. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rolf Winter
Sent: Monday, March 21, 2011 9:04 AM
To: [email-masked]
Subject: [ledbat] congestion control draft

Hi,

Thanks,

Rolf

---

From: "Woundy, Richard" <[email-masked]>
Date: Mon, 28 Mar 2011 08:38:32 +0000

I wanted to make a quick comment on Murari's excellent review.

>7.  " delay of 150 ms  to be acceptable for most user voice applications." - Hmm seems high, I always thought that this number was more like 50ms from SONET numbers.

50ms is about SONET restoration time, not typical SONET delay.

A definitive reference for acceptable delay for voice applications is: ITU-T G.114 (5/2003) SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS, Figure 1, page 3, One way transmission time.

That ITU diagram shows that voice quality begins to drop when the end-to-end one-way delay exceeds 150ms, and crosses the threshold from "users very satisfied" to "users satisfied" around 200ms.

But note that the end-to-end delay includes factors beyond the network transmission delay, such as codec delay, packetization delay, jitter buffer delay, etc. This is why the target delay for network transmission tends to be lower.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rolf Winter
Sent: Monday, March 21, 2011 9:04 AM
To: [email-masked]
Subject: [ledbat] congestion control draft

Hi,

Thanks,

Rolf

---

From: Murari Sridharan <[email-masked]>
Date: Mon, 28 Mar 2011 09:15:37 +0000

Ok. I thought the sonet restoration time was motivated due to voice quality issues beyond 50ms. In any case below reference is authoritative enough.

Sent from my Windows Phone

-----Original Message-----
From: Woundy, Richard
Sent: Monday, March 28, 2011 1:38 AM
To: Murari Sridharan; Rolf Winter
Cc: [email-masked]
Subject: RE: Review of ledbat draft

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rolf Winter
Sent: Monday, March 21, 2011 9:04 AM
To: [email-masked]
Subject: [ledbat] congestion control draft

Hi,

Thanks,

Rolf