Subject: PGMCC and unicast

From: Jeremiah Scholl <[email-masked]>
Date: Mon, 11 Jun 2001 12:48:48 +0200

I have a question for the group regarding the Internet-Draft for PGMCC
that you has submitted for standardization.  In PGMCC "the acker"
(worst-case receiver) sends out an ack for each data packet received and
the sender uses this information to adjust its send rate.  The
internet-draft for PGMCC does not specify if acks are unicast to the
sender or if it is acceptable to multicast them to the entire group.

This question is in regards to a joint project between Luleå Techinical
University and Marratech AB.  Marratech is an emeetings software company
and the engineers here feel that due to the use of firewalls, it is not
realistic to assume that unicast connections will be available when
deploying their products on the Internet.  Some clarification on this
point would be helpfull.

Thanks,

Jeremiah

---

From: Lorenzo Vicisano <[email-masked]>
Date: Mon, 11 Jun 2001 14:46:50 -0700

Jeremiah,

In message <[email-masked]>,
> sender or if it is acceptable to multicast them to the entire group.

the assumption in the draft is that ACKs are sent unicast and
we should make it clear if it currently isn't.
Although there might be potential advantages in multicasting
them to the entire session, I don't think that these pay off
for the added overhead (i.e. significant amount of added traffic).
Furthermore, a criteria defined in RMT is that protocols should
work without multicast feedback, if possible. This requirement
comes from network infrastructure consideration (e.g. some
IP multicast protocol, like SSM, are asymmetric).

> deploying their products on the Internet.  Some clarification on this

Are you suggesting that potential PGM-receivers will be able to source
multicast but will not be able to send unicast, or are you talking about
the source-side ?

	thanks,
	Lorenzo

---

From: Lorenzo Vicisano <[email-masked]>
Date: Mon, 11 Jun 2001 15:17:35 -0700

[resending with correct address list]

In message <[email-masked]>,

---

From: Luigi Rizzo <[email-masked]>
Date: Tue, 12 Jun 2001 00:28:56 +0200 (CEST)

As Lorenzo said, ACKs are supposed to be unicast to the sender.
I cannot see any advantage in multicasting them to the session
(they cannot be used to elicit feedback from potential ackets,
because in PGMCC the receivers do not have an RTT estimate).

As for the firewall issue: I am unclear on what is your point when you say

> deploying their products on the Internet.

do you really mean unicast ?

If you are afraid that netadmins are blindly blocking traffic and you
have no input on what services to let through, then your
only option is probably to encapsulate everything into
UDP packets on port 53 (DNS) ... 

But if you want to use PGM, you need to tell the netadmin "listen,
i need protocol 113 to get through, and bidirectional connectivity
(for NAKs), at which point asking unicast is the least of your
worries.

	cheers
	luigi

> > > that you has submitted for standardization.  In PGMCC "the acker"

-----------------------------------+-------------------------------------
  Luigi RIZZO, [email-masked]  . Dip. di Ing. dell'Informazione
  http://www.iet.unipi.it/~luigi/  . Universita` di Pisa
  TEL/FAX: +39-050-568.533/522     . via Diotisalvi 2, 56126 PISA (Italy)
  Mobile   +39-347-0373137
-----------------------------------+-------------------------------------

---

From: Jeremiah Scholl <[email-masked]>
Date: Tue, 12 Jun 2001 10:14:07 +0200

I am asking these questions in regard to using PGMCC with SRM like protocols or
more specifically NORM once it is standardized, not for use in conjunction with
PGM.  Marratech would like to make sure that it will be able to use the
standardized NACK based protocol and standardized congestion control scheme that
will accompany it.

I proposed my question to the group because if PGMCC uses unicast we feel that
it will not be compatible with Marratech's products.  This is due to hosts often
being on different networks with firewalls inbetween them.  So, we will need an
additional congestion control scheme to be standardized for use with NORM.

I do have an idea for a solution to this problem and would really like some
feedback from the group regarding it.  PGMCC has the receiver unicast acks in
order to get a more complete set of which packets are lost by the worst-case
receiver.  This information is not available in SRM due to the use of
suppression timers.  However, this same information can be made available to the
sender in SRM by having the designated worst-case receiver stop using these
suppression timers.  All other receivers would still use suppression timers like
normal and would have their NACKs suppressed.

This solution has the benifit that it is low-weight and will also lead to faster
recovery times for packets that are lost by the worst-case receiver.  Since
there will only be one worst-case receiver at any given time it should not lead
to more redundant NACKs than SRM does.  I realize that the solution does require
us to wonder a bit away from the origional SRM framework so I would really like
some comments on it.

Can anyone give me a reason why this solution would not work?  Some thoughts
would be nice.

Jeremiah

---

From: Luigi Rizzo <[email-masked]>
Date: Tue, 12 Jun 2001 12:57:42 +0200 (CEST)

Jeremiah, 

i think you are addressing a few different issues in this msg.

First one is "what kind of connectivity should we assume between
source(s) and receiver(s) in NORM protocols."

The (hidden) assumption in PGMCC is to have multicast downstream, and
unicast upstream (plus optional multicast on the LAN, but only for nak
suppression purposes).

I think this is one of the least restrictive assumption you can
make on availability of service.  My feeling is that over time it
will be less likely to have multicast in both directions (e.g.
because of SSM, or asymmetric nets with satellite downlink and
phone uplink, etc.).

Of course you can tunnel your ACKs using whatever transport you
have available, including multicast -- basically this is what you
propose in the second part of your msg. You might lose some efficiency
in the process, and put a lot more state in the net, but if you
have no better alternative, what else you can do.

Second issue is your proposal of using immediate feedback to trigger
retransmissions. I think in some cases it might be better to wait
a bit (which is a side effect of sending repairs in response to
delayed NAKs).

Examples:
 + in a context (such as PGM) where you have nodes doing selective
   forwarding, you want to retransmit only after receivers have had a
   chance to send out their NAKs (and install state in the filtering nodes).

 + if you use FEC-based repairs, you might want to count the amount of
   lost packets to select the most appropriate FEC parameters (block
   size, number of repair blocks, etc);

 + you still need to handle reordering in packet arrivals; using delayed
   NAKs frees you from counting N dup-acks for retransmission purposes.

Third one: you say
	
>                                      PGMCC has the receiver unicast acks in
> receiver.

not exactly. Those acks really carry throughput estimates, and
"tokens" to trigger the transmission of new traffic. They are not
(meant to be) used at all for data integrity purposes.

	cheers
	luigi

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 12 Jun 2001 12:19:22 +0100

>>have no better alternative, what else you can do.

of course, in a genuine shared media net, it might make a lot of sense
to multicast acks - it seems like it ought to be an option, but i
agree 100% it is likely to be the exception

jeremiah:
also, in the case of firewalls, NATs etc, the chances are that
multicast is MORE likely to be blocked first, and let through latest,
rather than unicast, so i dont see the marratech objection here really

finally, all the RMT work has moved away from SRM, temporarily, since
we couldn't figure out congestion control for multiple sources, and
several people of "importance" claimed that "there were'nt any
compelling multiple source applications anyhow" :-)

its not clear why having the PGMCC acker send data to all sources
means much for a multiple sender session- if each source independantly 
adjusts its rate in a TCP-friendly way, you get the right effect, and 
given most delivery trees for steady traffic are going to be source based, 
they wont necessarily share bottlenecks very often
(except perhaps at the receivers themselves)
if you want to devise some applicatio nlayer rule about how to
_couple_ the sending rates for a multi-sender applciation, then thats
fine, but i dont see that it should be wired into the transport layer
congestion control in anyway - it can easily be done as a higher layer
policy, distributed in a session management protocol,
 and weighted into the rate computaton of PGMCC at each source

 cheers

   jon

---

From: Brian Adamson <[email-masked]>
Date: Tue, 12 Jun 2001 11:10:57 -0400

With MDP, we have had networks where _only_ unicast feedback was 
possible _and_ we have had networks where _only_ multicast feedback 
has been possible so options exist to force all-unicast or 
all-multicast feedback from receivers ... By default, ACKS are 
unicast  and NACKs tend to be multicast ... Although  we _have_ now 
implemented NACK suppression for unicast feedback with suppression 
performance comparable to multicast NACK feedback suppression at the 
cost of an additional RTT delay (and for some topologies or multicast 
routing protocols (e.g. shared-tree) there may not be much difference 
at all)

In the TFRC-like congestion control we have implemented in MDP, we do 
something like what you describe below ... A small subset of 
candidate worst-case receivers provide feedback (to congestion 
control probes interlaced with the senders' data transmissions) with 
no suppression timing ... (The sender adjusts its rate according to 
_the_ worst case receiver - we're still investigation the value of 
keeping congestion control state for multiple representatives instead 
of one as per PGMCC) ... As Luigi note for PGMCC, this does work 
independently of the reliability process although we do also 
piggy-back congestion control feedback (RTT, loss estimation 
feedback) on NACK messages ...

I have considered NACK suppression schemes where the receivers' 
history of NACKing may weight their probability of NACKing to a 
shorter backoff time (or possibly none at all as you describe below) 
... There is some danger in this (though some may be mitigated by the 
sender advertising the current designated zero-delay "nackers) ... 
However, in our experience on the MBONE, the statistics of loss don't 
appear to be stationary ... i.e. there doesn't seem to be much 
correlation between being the worst-case NACKer from one time period 
to the next ... this is probably not well understood for networks 
with lots of dynamic congestion-controlled flows either ... in 
congestion-control simulations we have done over topologies with 
multiple possible bottleneck and ongoing background flows and 
dynamically starting/stopping TCP/MDP flows, we tend to see dynamics 
in where the worst-case loss is occurring at any moment in time ... 
but we've had luck with the congestion-control being relatively 
stable I think since the loss interval is averaged over multiple 
intervals, each being multiple RTT in general ...

-- 
Brian
__________________________________
Brian Adamson
<http://manimac.itd.nrl.navy.mil>
<mailto:[email-masked]>

---

From: Luigi Rizzo <[email-masked]>
Date: Wed, 13 Jun 2001 00:46:25 +0200 (CEST)

> to multicast acks

it really depends on the protocol. TFMCC "acks" (or whatever they are
called) might be useful to other receivers too (as they contain a
throughput estimate, so can be used for suppression etc.), but
pgmcc acks are almost meaningless for other receivers, they only
mean something (for CC purposes) for the one sender they are
addressed to.

	cheers
	luigi