Subject: Re: Some more questions

From: [email-masked]
Date: Sat, 6 Nov 1999 11:36:10 -0800

*> From [email-masked] Fri Nov  5 17:37:09 1999
  *> X-Sender: [email-masked] (Unverified)
  *> X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 
  *> Date: Fri, 05 Nov 1999 20:37:06 -0500
  *> To: [email-masked]
  *> From: Lou Berger <[email-masked]>
  *> Subject: Re: Some more questions
  *> Cc: [email-masked], [email-masked], [email-masked]
  *> In-Reply-To: <[email-masked]>
  *> Mime-Version: 1.0
  *> Content-Type  *> :   *> text/plain  *> ;   *> charset="us-ascii"  *> ;   *> format=flowed  *> 
  *> Content-Length: 3363
  *> X-Lines: 94
  *> 
  *> Bob,
  *>          Thanks for the additional comments.
  *> 
  *> At 03:17 PM 11/5/99 -0800, [email-masked] wrote:
  *> 
  *> >Lou,
  *> >
  *> >I am still struggling to understand your refresh-reduct I-D.
  *> >(Since I see no other issues raised on the list, I must conclude
  *> >that I am the only one who doesn't get it.)  In any case, since
  *> >I have not a shred of pride, let me ask you the following:
  *> >
  *> >1. Section 2.3: "RSVP Bundle messages MUST not be used if ...
  *> >         changes in next hops cannot be identified via routing"
  *> >
  *> >         Precisely why? (There seems to be some logic omitted here...)
  *> 
  *> 
  *> Because if you can't detect a route change you could send path and path 
  *> tear messages to the wrong (pre change) next hop.  Remember Bundle messages
  *> are sent hop-by-hop.

I understand hop-by-hop, but "changes via routing" does not compute for me,
for several different reasons.

  *> 
  *> >2. Section 3.4: "Message_ID objects can be used in both a Bundle
  *> >         message and its sub-messages".
  *> >
  *> >         What is a Message_ID object in a Bundle message used for?
  *> 
  *> Reliable transmission of the whole bundle.

Reliable transmission of bundles seems to me to be conceptually
a big leap, and not a clear win.  We can talk about this in DC.

  *> 
  *> >3. Section 3.5: "Implementations SHOULD include MESSAGE_ID_ACK
  *> >         and MESSAGE_ID_NACK objects in standard RSVP
  *> >         messages when possible."
  *> >
  *> >         There is no alternative for NACK objects, is there?
  *> 
  *> Both NACKs and ACKs may be sent piggy-backed (see section 3 intro or 3.5) 
  *> or in an ACK message (see section 3.3).

OK.

  *> 
  *> (Are you perhaps reading draft -00?  draft -01's text is cleanup a bit and 

The draft I am reading, and from which the above was quoted, *says* -01.

  *> is more consistent - mostly resulting from your earlier comments.  Let me 
  *> know if you want a version with change-bars.)
  *> 
  *> I think the current text is fairly explicit on this.
  *> 
  *> >         Is it always preferable to send an ACK object piggy-backed
  *> >         rather than in an ACK object?
  *> 
  *> In my opinion, yes. Hence the "should".  Note that it is intentionally NOT 
  *> a requirement.

It seems to me that if you have a lot of ACK objects to send, it may be
simpler to send them in ACK messages.  In the end, the best choice is a
trade-off between the total # number of messages and the delay before
the ACK object can be sent.  Thus, you don't want to delay a long time
waiting for a message to piggy-back on, if you have enough ACK objects
accumulated to send them earlier in an ACK msg. The best thing to do
seems complicated, but a SHOULD here seems simplistic.

  *> 
  *> 
  *> >5. The [only] reason you have MESSAGE_ID MCAST_LIST and SRC_LIST
  *> >         objects is to allow RPF checks when Srefresh messages for
  *> >         multicast sessions are sent to the all-hosts multicast
  *> >         address?
  *> 
  *> The first part of the sentence is correct.  Both are required solely to 
  *> perform RPF checks.
  *> 
  *> SRC_LIST objects contain {message_identifier, S}.  They are sent in 
  *> messages destined for a session's multicast destination {G}.  Since the 
  *> multicast group is carried in the IP header it doesn't need to be present 
  *> in the object.
  *> 
  *> MCAST_LIST objects contain {message_identifier, S, G}.  They are carried in 
  *> messages destined for an RSVP next hop when that next hop is directly 
  *> connected over a point to point link.  This allows the aggregation of all 
  *> multicast (and unicast) path associated message_identifiers to be 
  *> aggregated into a single message.   Since the multicast destination {G} 
  *> isn't in the header it must be carried in the object.
  *> 
  *> If we sent the Srefreshes for all multicast Path state to the all- RSVP 
  *> hosts multicast address (this is George's preference) then all we wouldn't 
  *> need the SRC_LIST object, but RSVP hosts that were not listening to a group 
  *> would need to filter (at the RSVP level) Srefreshes for each group it 
  *> wasn't listening to.

I understood everything up to this last ("George's preference") paragraph. 
How would the node (not host) be able to filter Srefreshes if it does
not have (S,G)?

Bob

  *> 
  *> Thanks,
  *> Lou
  *> 
  *> >Thanks,
  *> >
  *> >Bob Braden
  *> 
  *>

---

From: Lou Berger <[email-masked]>
Date: Sat, 06 Nov 1999 15:10:43 -0500

>for several different reasons.

Including path messages in bundle messages disables RSVP's natural to adapt 
to route changes.   I'm not sure what you're objecting to. Is it a) that 
there are ways other than routing to detect a change in next hop? b) that 
you think a total restriction is too extreme in the case, i.e. limit 
bundling to hop-by-hop messages? or c) something completely different?

>a big leap, and not a clear win.  We can talk about this in DC.

How is it different than reliable transmission of each sub message?

>seems complicated, but a SHOULD here seems simplistic.

Would you prefer this to be a "MAY" or for the draft to not provide 
guidance?  Either are fine with me.

>How would the node (not host) be able to filter Srefreshes if it does

Sorry.  The word "all" should not have been included, i.e. the paragraph 
should have read:

   *> If we sent the Srefreshes for all multicast Path state to the all- RSVP
   *> hosts multicast address (this is George's preference) then we wouldn't
   *> need the SRC_LIST object, but RSVP hosts that were not listening to a 
group
   *> would need to filter (at the RSVP level) Srefreshes for each group it
   *> wasn't listening to.

In this case Srefreshes for multicast path messages would be sent to the 
all-RSVP hosts multicast address.  Each message would carry MCAST_LIST 
objects which contain {message_identifier, S, G}.  So the {S,G} information 
would be present.  The issue is the receiver's RSVP agent would not 
normally see ANY Path messages for any groups that the node was not a 
listener.  So this approach adds overhead to non-participating nodes.  I 
feel this is a bad thing.  George disagrees.  I believe he prefers the 
simplicity and better aggregation properties.  If you have an opinion we 
would be most interested in hearing it.

Thanks,
Lou