Subject: [Rmt] AD Evaluation comments on draft-ietf-rmt-bb-tfmcc-06

From: Magnus Westerlund <[email-masked]>
Date: Wed, 05 Apr 2006 13:13:05 +0200

Hi,

I have done an AD evaluation of the draft and found a few things I like
to have clarified. Depending on the answer it might be necessary to
update the draft.

1. Section 1.3:
"TFMCC inherently works with all types of networks, including LANs, 
WANs, Intranets, the Internet, asymmetric networks, wireless networks, 
and satellite networks."

I reacted to the word "all" here. I think it needs a clarification that
it is for all networks that enables bi-directional traffic. Could this
be fixed in the text?

2. Section 1.3, last paragraph:

"TFMCC is designed for applications that use a fixed packet size, and
vary their sending rate in packets per second in response to congestion.
Some audio applications require a fixed interval of time between packets
and vary their packet size instead of their packet rate in response to
congestion.  The congestion control mechanism in this document cannot be
used by those applications."

Here my issue is with "Some audio applications require ...". I would
like to change this to "Some applications, e.g. those using audio, may
require ...". The problem is more encompassing than only audio, audio is 
however an good example.

3. Section 2.2.1, the ts_r in data packets. I think this section is
missing the addition of the delay between receiving the feedback packet
with the ts_r and the transmission of ts_r' in the sender to receiver path.

4. I also think the usage of ts_r and ts_i is make a bit unclear by not
separating the different instances of the timers. If I understand the
RTT measurements loops there are two one for the sender and one for each
receiver.

                   < ts_d >
ts_i             ts_now   ts_i2
                           ts_r'
    \             ^        \
     \           /          \
      \         /            \
      V        /             V
      t_now    ts_r          t_now2
               ts_i'
       < tr_d >

The sender loop as I understand it starts with the first message
containing ts_i. The receiver does a receiver timestamp on the arrival
t_now. Then when sending feedback it calculates ts_i'= ts_i + ts_r-t_now
This I think is understandable from the text. And following from that
the sender's measurement of RTT will be R_r = ts_now - ts_i'.

The receivers measurement loop is similar but uses ts_r which is the
local clock value of when the feedback messages is going to be sent.
According to issue 3 above there doesn't seem to be any indication that
ts_r' is ts_r + ts_d, where ts_d is ts_i2-ts_now. The receivers makes it
RTT calculation R_sample = t_now2 - ts_r'.

 From this I have the following questions:
A. Was it intentional to ignore ts_d? If not please clarify that the
sender should create a ts_r' when sending the value.

B. I think one should maybe clarify that there is a ts_now and tr_now as
they are different clocks. Now the same variable is used in both
chapters which is a bit confusing.

C. Clarify which value should be used in the calculations, the ts_r or
the ts_r'.

5. Section 3.2
" R_max = max(R_max, s/X + t_gran)"

Is it intentional to calculate s/X rather than 8s/X? I react to that the
value is bytes divided by bits/s and thus seem to contain a unit error.

6. Section 3.6: I am missing any definition on when slow start may be
used. What are the prerequisite for applying the slow start mechanism?

7. Section 4.3.3: In the D_r calculation it seems that the ts_r term
should be the ts_r' term instead. Secondly the R' calculation should not
contain the ts_i' value, rather ts_i value of the latest received data
packet. I think the used notation is creating confusion here.
Please clarify this.

8. Section 5.5: Could anyone please explain why the history discounting 
for I_tot1 does only include the DF_i and not also the DF value?

9. Split references to normative and informational.

 From my perspective the draft would benefit significantly from 
clarifying the RTT measurements variables and their usage. When doing 
that I think a the other more editorial things could also be fixed.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 11 Apr 2006 15:38:33 +0200

Hi,

I have removed all items where the proposed fixes are fine. I think the 
proposed changes for ts_r, ts_i' etc are good and will result

Joerg Widmer wrote:
> As written in 3.6, "Slowstart is terminated as soon as any one of the
> receivers experiences its first packet loss". We kept TFMCC congestion 
> control as similar to TFRC as possible, so all this is more or less as 
> in RFC 3448. For multicast, a false slowstart during severe congestion 
> can cause considerable harm and we therefore opted to only allow it at 
> the start of the session.

Okay, it is clear when you leave slow start. What isn't clear is the 
what the requirements are for entering slow start. In my opinion the 
draft need some text explaining when a sender is allowed to use slow start.

> 
>> 8. Section 5.5: Could anyone please explain why the history 
>> discounting for I_tot1 does only include the DF_i and not also the DF 
>> value?
> 
> The DF is used to give more weight to the first interval I_0 only if the 
> first interval is included. For calculating p, we compare the avg. 
> interval size with I_0 to that without it, and for the latter DF has to 
> be omitted. (In fact, we could also multiply I and W by DF which would 
> do nothing since p = W/I.)
> 

Thanks, I think I understand.

> I'll prepare and updated version as soon as possible in the coming 1-2
> weeks. Please let me know if you have any comments concerning the 
> proposed changes. What exactly are the next steps? Do I need to submit 
> the changes directly to you or is a draft submission necessary first?
> 

Please submit a new draft. I will check the actual changes before 
forwarding the draft to IETF last call.

cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 11 Apr 2006 17:15:35 +0200

Joerg Widmer wrote:
> Hi Magnus,
> Ok, I can include a sentence in section 3.6 that explicitly states that 
> slowstart is only used at the beginning before any of the receivers has 
> experienced any loss.
> 

So if I as a sender stop sending, can I after any time use slow start 
again? If I can what rules applies. When does my acquired state become 
useless?

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 12 Apr 2006 10:07:29 +0200

Hi,

I am fine with this resolution. If anyone in the WG has objections 
please speak up.

Joerg, please provide an updated draft. When I have received a 
satisfactory update I plan to go forward with IETF last call. That will 
also give the WG time to look at these changes before sending it to the 
IESG for approval. If anyone objects please send me a message.

cheers

Magnus Westerlund
Your AD

Joerg Widmer wrote:
>>> Ok, I can include a sentence in section 3.6 that explicitly states 
>>> that slowstart is only used at the beginning before any of the 
>>> receivers has experienced any loss.
>>>
> Ok, I see what you mean. This is indeed missing from the draft. I
> propose to do this similar to TFRC.
> 
> If the the sender stops sending data packets, it records the current
> sending rate X' = X. Every 10 RTTs the allowed sending rate will be
> halved due to lack of feedback as specified in 3.3. This halving may
> take place multiple times. When the sender resumes, it may perform a
> slowstart from the current allowed rate up to the recorded rate X'.
> 
> Receivers have to clear the have_loss flag after 10 RTTs without data
> packets. have_loss is only used during slowstart, so this has no effect
> if no packets arrived due to a network partition or packet loss.
> Otherwise, if the sender is trying to do a slowstart after being idle,
> everything will proceed as in the initial slowstart with it terminating
> after the first packet loss by any of the receivers or as soon as X' is
> reached.
> 
> If you agree, I'd include a paragraph about this in the section on
> slowstart and clarify that this only applies when the sender stops
> sending due to lack of application data.
> 
> Cheers,
>    Joerg
> 

-- 

Magnus Westerlund