Subject: draft-ietf-bfd-base-03.txt comments

From: Chezhian Renganathan <[email-masked]>
Date: Wed, 17 Aug 2005 10:44:47 -0700

Hello,

Section 6.7.4 -
Unless I am missing something, it seems to me that the statement in braces
"roughly speaking, due to jitter"
should be applicable in the context of Detection Time rather than 
DetectMult.
The DetectMult is just number of packets and there is no variance there with
jitter.

Also, was there any thinking along the lines of making the "Reg Min Echo RX
Interval" field optional, keeping with the spirit of this function, 
being optional
with either modes. This field could potentially be set to all zeros for 
the entire
length of a session unless changed if the end systems support this 
function.

thanks,
chez

---

From: Dave Katz <[email-masked]>
Date: Wed, 17 Aug 2005 11:41:08 -0700

> The DetectMult is just number of packets and there is no variance  

The text in the document is correct.  DetectMult is used to calculate  
time, not count packets, so given the application of jitter, the  
number of packets missed is approximate (if DetectMult were 10, for  
example, the actual number of packets missed before detection might  
be as high as 13 if 25% jitter is applied and the timing is right.)

> with either modes. This field could potentially be set to all zeros  
> for the entire

Not sure exactly what you're saying here.  To actually leave out the  
field and shorten the packet four bytes?  I'm not sure what would be  
gained by this.  The processing cost would be higher (Is the field  
there?  What is the value?) and the difference in packet size  
negligible.

As it stands now, the field can be set to zero if the sender does not  
wish or is not able to support the echo function.

Perhaps I don't understand the question.

--Dave

---

From: Chezhian Renganathan <[email-masked]>
Date: Wed, 17 Aug 2005 12:12:32 -0700

> be as high as 13 if 25% jitter is applied and the timing is right.)
Ok got it.

> there?  What is the value?) and the difference in packet size  
Would it help the processing cost if done similar to the auth field 
which is controlled 
by the "A" flag.?
Apart from reducing the overhead there is some bandwidth being saved 
too. For instance, when
asynchronous mode is active across end systems (and potentially multiple 
sessions),
with no echo support, with a 10 msecs tx interval, we could be sending 
these 4 bytes
unnecessarily over the period of the session(s) uptime which could run 
into several days
 between interruptions.

thanks,
chez

---

From: Dave Katz <[email-masked]>
Date: Wed, 17 Aug 2005 12:43:07 -0700

> which is controlled by the "A" flag.?
> Apart from reducing the overhead there is some bandwidth being  
> saved too. For instance, when
> asynchronous mode is active across end systems (and potentially  
> multiple sessions),
> with no echo support, with a 10 msecs tx interval, we could be  
> sending these 4 bytes
> unnecessarily over the period of the session(s) uptime which could  
> run into several days
> between interruptions.

The authentication stuff was made optional partly because of its size  
and complexity (there are environments in which it is unnecessary and  
would stand in the way of efficient implementation in silicon) and  
partly for backward compatibility (the authentication stuff was added  
later in the process.)

The bandwidth savings is essentially invisible (it's totally  
invisible on Ethernet given the minimum packet size requirements.)   
Even at 10 msec intervals at 10Mbps it consumes only an additional . 
03% of the bandwidth, if my math serves.  Just not worth the trouble.

--Dave