Subject: local recovery and NORM

From: Jeremiah Scholl <[email-masked]>
Date: Thu, 29 Mar 2001 13:13:17 +0200 (MET DST)

Can anyone out there give me information regarding the NORM protocol and
local recovery mechanisms.  Is there a plan to add local recovery to NORM
before it is standardized?  If so, which type of local recovery scheme
(hop-scoped, group-scoped ect.) will most likley be a part of the
protocol.

Thanks!

Jeremiah Scholl

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Thu, 29 Mar 2001 13:44:14 +0200

Jeremiah,

one of the main points of NORM is to be simple, so NORM-PI should probably
not try to implement local recovery.
The NORM building block will certainly allow for local receovery, though.
Adding local recovery is probably most useful in cooperation with GRA, which
still is in the process of solidifying.

Gruesse, Carsten

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Jeremiah
> Scholl
> Sent: Thursday, March 29, 2001 13:13
> To: [email-masked]
> Cc: Peter Parnes
> Subject: local recovery and NORM
>
>

---

From: "Michael R. Eckhoff" <[email-masked]>
Date: Thu, 29 Mar 2001 07:47:37 -0600

Greetings!

I am new to this list, so please forgive me if I bring up topics that
have already been discussed in great detail.

Currently, I have over 150 multicast locations utilizing distance
education software (including white board, audio, application sharing,
etc.).  Most of these locations utilize 256Kbps frame relay.  Normally,
all packets are delivered successfully, unless an unexpected TCP file
transfer takes place.

The main issues that I am finding with the "reliable transport protocol"
that is being used with this application (lrmp) is that the recovery
process tends to cause more problems than it is worth.

Here is why:

1)  If a station loses multicast packets, chances are, the entire
location lost the packets.
2)  It does no good to attempt local recovery on the local segment since
everyone else probably lost it as well.
3)  If a location loses multicast packets, chances are, the router
dropped the packets due to bandwidth constraints.
4)  Recovery on a loaded line will just cause more packets to be
dropped.
5)  If packets are not reliably recovered for, applications that expect
to read a stream from their buffer will time out waiting for the
recovery.

I feel that any sort of multicast recovery should be done through TCP
and to a single upstream source.

How about this scenario:

- Assumption is some sort of RTP header is placed in the multicast
packet which includes a sequence number, a tag as to if this packet
could be lost or MUST be recovered, and a timer value as to how soon
this recovery should take place before a failure should be noted.

- Utilize IGMP, or a similar protocol, to signal to the router that
recovery of a sequence number is necessary.  The client would signal on
the group ID in which he lost the packet with a SEQUENCE_RECOVERY
payload type.  In the payload data, he would include the sequence number
in which he is requesting.

- Any clients in this group that may have also lost packets would set
back off timers if they hear someone request their sequence.  Much like
standard IGMP operation.

- The router would build an upstream TCP connection to it's RPF router
towards the source.  It would query the RPF router to see if it has the
sequence number in its cache.  If the RPF router does have the packet,
it would pass it down the TCP stream - to "guarantee" delivery of the
packet in the case that the line is still loaded - as to not cause the
recovery cycle to perform multiple recovery requests. 

*Note:  The router would only have one TCP stream to its upstream
neighbor no matter how many packets are being recovered.  Therefore, if
all packets were lost to 5 clients at a remote location, there would
still only be a max. of 1x retransmission on the line since the
recovered packets would be multicast on the wire and only one station
would attempt recovery for the entire group.  So if a line was fully
saturated, essentially, the multicast application would switch to a TCP
tunnel and maintain connectivity.  This TCP "tunnel" should stay
established for X amount of time to keep from having to go through a
setup/teardown procedure for every missed packet.  It may also be
convenient to create the tunnel if the bandwidth on the line crosses a
specified limit.

- If the RPF router does not have the sequence, it would perform the
same process until ultimately the source could be contacted.  This
should never happen since the DR for the source should always have a
stable cache if it is connected to the source through a reliable
connection. 

- Once the router gets the sequence, it would cache it and multicast it
out to its clients.  This caching should be optional if the router is
attached to a single ethernet interface to reduce memory requirements at
the endpoints.

- All clients requesting this sequence would clear it from their
recovery list upon arrival.  If they miss it, they would run through the
process again, only retrieve it from their local routers cache.

I think that a procedure such as this would allow for both reliable
packet delivery, as well as a reliable recovery from missed packets,
even under the constraints of a loaded line.

-me

Michael R. Eckhoff
Sr. WAN Comm Analyst
citigroup / The Associates

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Thu, 29 Mar 2001 18:37:36 +0200

> 4)  Recovery on a loaded line will just cause more packets to be

This is exactly the reason why RFC2357 ("IETF Criteria for Evaluating
Reliable Multicast Transport and Application Protocols") *requires*
congestion control.

Gruesse, Carsten

---

From: Brian Whetten <[email-masked]>
Date: Thu, 29 Mar 2001 11:53:52 -0800

The other alternative for local recovery is to use TRACK, which will be 
hierarchical in nature, but will use a minimum of hard state, so that it 
keep much of the flexibility and fault resilience of NORM.  TRACK primarily 
uses local multicast addresses for repairs.

Brian

---

From: Joe Macker <[email-masked]>
Date: Thu, 29 Mar 2001 17:50:25 -0500

Jeremiah,

I agree with Carsten's observations on the PI.
The NORM-PI to be well-suited for single-source multicast environments.
The building block should not preclude its use.
As mentioned, GRA and TRACK are both potential candidates for adding this.

-Joe