Subject: [pim] Curiosity question - protocols PIM can work over...

From: Jonathan Day <[email-masked]>
Date: Tue, 15 Nov 2005 13:15:53 -0800 (PST)

With the current arguments/debate over PIM-over-TCP,
has anyone looked at using PIMv2 over DCCP (a protocol
midway between TCP and UDP)?

I also noticed recently that multicasting (rather than
broadcasting) is becoming popular on non-IP networks,
such as Infiniband. Is PIM protocol independent all
the way down, and is there any way to use it with
Infiniband's multicast capabilities?

__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

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

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 15 Nov 2005 13:40:07 -0800

> midway between TCP and UDP)?

I think TCP is just a keyword for reliable p2p signaling. We did at
one point in time evaluate SCTP as well, and that would be usable
as well.

I don't know DCCP, but the question is really whether you need to
have more transport functions than what TCP can give you.

I primarily want to have reliable signaling below the tree building.
Would DCCP give that for let's say link-laye multicast packets ? If
not, what then would be the benefit over TCP ?

> Infiniband's multicast capabilities?

Not really. There's way too much in PIM bound to rfc1112, and
it's unclear to me whether the multicast service definition in Infiniband
would be the same as in IP. 

For something like infiniband it probably a good idea to look
into using mLDP, which is basically simplified the two tree building
mechaniss from PIM (receiver side explicit join P2MP/SSM and MP2MP/Bidir
trees).

Cheers
	Toerless

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 15 Nov 2005 14:09:21 -0800

>> mechaniss from PIM (receiver side explicit join P2MP/SSM and MP2MP/Bidir

    LDP will have the same scaling problem on a large multi-access LAN that
    we are trying to avoid with PIM.

Dino

---

From: Stig Venaas <[email-masked]>
Date: Sun, 27 Nov 2005 15:29:55 +0100

> not, what then would be the benefit over TCP ?

They don't necessarily have more transport functions, but I would
say less is more; TCP does congestion control which I'm not so sure
is needed (and maybe not wanted).

DCCP is not reliable (I think), and that is something we want. While
it has congestion control which I'm not so sure is needed.

SCTP however is reliable. Advantages with SCTP over TCP are that it
does framing (so one message can be one j/p), and it doesn't maintain
ordering, which also might be useful.

Stig

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 27 Nov 2005 06:36:30 -0800

Maybe the other way around:

-> Why no congestion control ? I outlined the burstyness problem in my
   last mail. How do you think this should be handled ?

-> Reliability: I think we made the conclusion that we can either have
   current PIM soft-state or hard-state, but that hard state requrires
   reliable messaging. Correct ?

-> Reliability2: Why would it be better to encumber the PIM state machinery
   with the added complexity of providing reliable transmission if this
   could be done in a modular fashion by a transport protocol ?

-> Out-of-order transmission: Assuming hard state and as such only
   triggered join/prunes but no periodic ones, please explain where and
   how out-of-order transmission would be necessary ?

Thanks
    Toerless

---

From: Stig Venaas <[email-masked]>
Date: Sun, 27 Nov 2005 15:46:33 +0100

>    last mail. How do you think this should be handled ?

So question I guess, is whether you want the whole burst to be sent
with no congestion control, so that delay is kept to the minimum, or
if it's necessary to protect the router and/or link from the burst.

>    reliable messaging. Correct ?

Yes, so I think reliability certainly should be a requirement.

>    could be done in a modular fashion by a transport protocol ?

Right, so what we need to discuss I think, is what properties we
ideally need from the transport. Reliability, congestion control,
framing, ordering etc.

>    how out-of-order transmission would be necessary ?

I would say that order is not important. Hence if packets happen to be
reordered, you can process packets/messages as they are received. With
say TCP you would have to wait until the "right" packet comes along.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Sun, 27 Nov 2005 16:07:42 +0100

On Sun, Nov 27, 2005 at 03:46:33PM +0100, Stig Venaas wrote:
[...]
> say TCP you would have to wait until the "right" packet comes along.

After writing this I've started to doubt how likely reordering is, and
also, order might be important in some cases. So I wish I didn't write
that...

Anyway, I think it's good to consider these things, and write down what
the requirements are.

Stig

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 27 Nov 2005 07:15:52 -0800

> if it's necessary to protect the router and/or link from the burst.

I will of course try to build my products such that i can sustain large
bursts as the upstream receiver, but especially when i have a large fan-out
this may not be good enough, so i definitely think there's a need for
congestion control here. And remembering all the tricks and details
that went into congestion control for TCP, i am not sure that the PIM-WG
should reinvent that wheel (again: Not saying it MUST be TCP, but even
more so saying it MUST not be reinvented by PIM-WG unless there's sufficient
proof that existing transport protocols couldn't do what's deemed to be
required).

Also: The congestion control requirements as well as retransmission
requirements are likely easier when we only consider communications
between L2 connected neighbors, but if i wanted to also use PIM 
between PEs as a further step of eg: MVPN, then it's not bad to have
a more advanced transport protocol - i think. Now obviously if one
conclusion is that the characteristics of L2 vs. L3-core neighbor
connectivity is so different that a single transport protocol would not
be the best choice for both - that's fine. But that reinforces the notion
that we could keep the transport protocol functions out of PIM so that
we can modularily combine PIM with an appropriate transport protocol for
whatever L2 or L3 or whatever link we use - after all, the choice
of transport is a purely (logical) ip-subnet one, and not a network wide one!

> ideally need from the transport. Reliability, congestion control,

In my priorities, reliability is highest, then congestion control.

Framing would be nice, so TCP isn't ideal, but i haven't seen enough
proof that we really need to have the optimization of matching PIM PDUs
with transport PDUs, which is what we would get with a framing capable
TP (transport protocol). Let's say: I rather want to have the ability
to do fragmentation and reassembly in the TP to avoid having to bother
about max packet-sizes in PIM than i am interested to expose the framing
to PIM. But that's not a strong opinion, somebody would just need to
re-educate me if the implications of this thought line aren't ideal..

Ordering.. I don't think we need to have out of order transmission,
eg: If there is ordering, fine, if not: fine (for current PIM. I can
easily imagine future functionality that might change preferences though).
But it would be least proirity for me.

> say TCP you would have to wait until the "right" packet comes along.

Sure. And for MVPN/L3 PIM peerings a protocol with better ACK/NAK than
just a single sliding window would be definitely better. I just think
that we primarily talk about actual L2 peerings, and there i think
packet loss is primarily due to receiver side overload, and when you have
that you have interactions between congestion control, retransmission
strategy and ultimately you can consider that the receiver side CPU
is split between PIM state building and running the transport protocol,
so you easily get these feedback loops by which being able to quicker
process more packets under congestion immediately (like with a non-ordered
TP), just causes more packets to be lost immediately thereafter, and
the ultimate result is tht you are slower than with a simple TCP because
you had to spend more CPU on restransmission control.

So, from PIMs point of view the TP is not required to provide ordering.
This does not exclude protocols with ordering, it just makes ordering
not something required by the TP user (PIM), but rather by something that
may be choosen as a piece of the TPs congestion control.

Cheers
	Toerless