Subject: DVMRP:Prune retransmissions

From: [email-masked]
Date: Wed, 3 May 2000 11:26:17 +0530

Hi all,
 I have a question regarding prune retransmission as stated in section 3.5.5. of dvmrp v3 draft 
(draft-ietf-idmr-dvmrp-v3-09.txt) dated September 1999.

As stated in the above document(section 3.5.5 para 3), on multiaccess networks, even if a 
prune is received by the upstream router, data may still be received due to other receivers on 
the network. Due to this there will be unnecessary retransmissions of the prune message. 
Can't this be avoided by having an ackowledgment for the prune(just like for the graft) on 
multiaccess network interfaces alone. If after the prune ack is received the downstream still 
receives multicast dgrams it can ignore them instead of retransmitting the prune.

This will also eliminate the need for maintaing the list of neighbors addresses on the 
downstream interfaces of the forwarding cache on the upstream router. Currently the above 
information might be needed to validate if the prune is from a downstream dependent DVMRP 
router. If prune is not retransmitted this validation can be simplified to just checking if the 
prune is from a downstream interface of the forwarding cache.

Regards,
Vijay

Enter your default signature here
Sent by Indya Messaging Service

---

From: "Shekhar, Ravi" <[email-masked]>
Date: Wed, 3 May 2000 11:49:10 -0400

Vijay,

> downstream interfaces of the forwarding cache on the upstream 

  Its not required to maintain the list of downstream dependent nbrs
  on each forwarding cache entry even now. It can be obtained from the 
  the corresponding DVMRP unicast routing table entry (i.e. the route entry
  which matches the source of data).

> prune is from a downstream interface of the forwarding cache.

  I doubt that. You would still need to maintain the list of downstream
  nbrs who have pruned just to know if all the downstream nbrs on an
  interface have pruned or not before you can remove that downstream
  intf from the forwarding cache.

  - Ravi Shekhar.

---

From: Bill Fenner <[email-masked]>
Date: Wed, 3 May 2000 08:56:29 -0700

>As stated in the above document(section 3.5.5 para 3), on multiaccess
>networks, even if a prune is received by the upstream router, data
>may still be received due to other receivers on the network. Due to
>this there will be unnecessary retransmissions of the prune message.
>Can't this be avoided by having an ackowledgment for the prune(just
>like for the graft) on multiaccess network interfaces alone. If after
>the prune ack is received the downstream still receives multicast dgrams
>it can ignore them instead of retransmitting the prune.

However, due to the exponential backoff, there will be 11 retransmissions
of the prune.  Implementations that retransmit prunes can get benefit
from retransmitting prunes by themselves; implementations that require
prune-acks would need both routers to be upgraded before seeing any use.
The advantage of incremental deployment far outweighs the cost of 11
packets over 2 hours.

>This will also eliminate the need for maintaing the list of neighbors
>addresses on the downstream interfaces of the forwarding cache on the
>upstream router.  Currently the above information might be needed to
>validate if the prune is from a downstream dependent DVMRP router. If
>prune is not retransmitted this validation can be simplified to just
>checking if the prune is from a downstream interface of the forwarding
>cache.

How would the router know when to stop forwarding?  You can't stop
forwarding on the first prune that you ACK; if there are e.g. 5
downstream dependent neighbors you need to get prunes from each one.
However, you're advocating not tracking from whom prunes have been
received, so can you ever tell when you've gotten prunes from all 5?
(What about getting 5 prunes from one misbehaving neighbor?)

  Bill

---

From: [email-masked]
Date: Thu, 4 May 2000 11:02:05 +0530

Iam not considering  misbehaving routers, for that matter a misbehaving upstream router may 
jeoparadise downstream multicast traffic. I am just asking if it would be possible to simplify 
the information maintained by the protocol data structures and thus speed up the operation. 

Regards,
Vijay

---

From: Bill Fenner <[email-masked]>
Date: Thu, 4 May 2000 08:11:04 -0700

>Iam not considering  misbehaving routers, for that matter a misbehaving
>upstream router may jeoparadise downstream multicast traffic.

However, if you can protect against certain types of misbehaving routers,
so much the better.

>I am just
>asking if it would be possible to simplify the information maintained
>by the protocol data structures and thus speed up the operation.

I still think that the upstream doesn't know when to stop forwarding
if it doesn't keep track, even if all downstreams are well-behaved.

  Bill

---

From: "Shekhar, Ravi" <[email-masked]>
Date: Thu, 4 May 2000 11:43:06 -0400

> totally jeoparadise multicast traffic. I am just asking if it 
> would be possible to simplify the 
> information maintained by the protocol data structures and 
> thus speed up the operation. 

  Actually it appears to me that downstream dependent routers do not
necessarily
  have to be mis-behaving for this to not work. A prune-ACK could get lost
or received 
  after some delay at the downstream nbr and as a result it might have to
retransmit its 
  prune. If the upstream router is merely counting number of prunes (without
keeping 
  any state to identify from which nbr it has arrived), it will count both
these prunes 
  from the same nbr and as a result will have wrong information. 

  - Ravi Shekhar.