Subject: Re: [NSIS] LIH (was: ntlp drafts differences)

From: Bob Braden <[email-masked]>
Date: Tue, 29 Jul 2003 16:35:44 -0700 (PDT)

*> From [email-masked]  Tue Jul 29 16:21:09 2003
  *> Date: Tue, 29 Jul 2003 19:19:40 -0400
  *> From: Henning Schulzrinne <[email-masked]>
  *> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
  *> X-Accept-Language: en-us, en
  *> MIME-Version: 1.0
  *> To: Bob Braden <[email-masked]>
  *> CC: [email-masked], [email-masked], [email-masked]
  *> Subject: Re: [NSIS] LIH  (was: ntlp drafts differences)
  *> Content-Transfer-Encoding: 7bit
  *> Content-Transfer-Encoding: 7bit
  *> X-BeenThere: [email-masked]
  *> X-Mailman-Version: 2.0.12
  *> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>,
  *> 	<mailto:[email-masked]?subject=unsubscribe>
  *> List-Id: Next Steps in Signaling <nsis.ietf.org>
  *> List-Post: <mailto:[email-masked]>
  *> List-Help: <mailto:[email-masked]?subject=help>
  *> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>,
  *> 	<mailto:[email-masked]?subject=subscribe>
  *> X-AntiVirus: scanned by AMaViS 0.2.1
  *> X-Spam-Status: No, hits=-5.9 required=5.0
  *> 	tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
  *> 	      RCVD_IN_NJABL,REFERENCES,REPLY_WITH_QUOTES,
  *> 	      USER_AGENT_MOZILLA_UA
  *> 	version=2.55
  *> X-Spam-Level: 
  *> X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
  *> 
  *> One question for clarification:
  *> 
  *> How would do you find out the LIH in the first place, without consulting 
  *> the routing table?

Presumably you have to do that whenever you send a path message; it saves
you doing it again when you receive a Resv message. Right?

Bob

  *> 
  *> Bob Braden wrote:
  *> 
  *> > I think your analysis is not quite right, but your conclusion seems to
  *> > be correct.
  *> > 
  *> > Assume pure unicast.
  *> > 
  *> > When the NSIS equivalent to an upstream RESV message arrives, how does
  *> > the NSIS program figure out which outgoing interface should have the
  *> > reservation?  Matching the path state does not help, because path state
  *> > is bound to incoming interfaces, not outgoing interfaces.  But the NSIS
  *> > program can make the proper assignment by consulting routing -- what
  *> > interface will data packets for this session be sent out?  Bind the
  *> > reservation to that interface.  So, the LIH is not logically necessary.
  *> > 
  *> > (OTOH, the LIH is an awfully cheap way to avoid this routing lookup in
  *> > the NSIS daemon!).
  *> > 
  *> > That's the way it seems to me.
  *> > 
  *> > Bob Braden
  *> > 
  *> > _______________________________________________
  *> > nsis mailing list
  *> > [email-masked]
  *> > https://www1.ietf.org/mailman/listinfo/nsis
  *> 
  *> 
  *> _______________________________________________
  *> nsis mailing list
  *> [email-masked]
  *> https://www1.ietf.org/mailman/listinfo/nsis
  *> 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 29 Jul 2003 19:47:22 -0400

> you doing it again when you receive a Resv message. Right?

 From a practical perspective, if you send a UDP-based PATH message, you 
wouldn't know which interface it left on. I think even for raw IP 
packets, the kernel does the routing, without informing the sender of 
the details of the interface selection decision. (Many of us would like 
to implement NSIS outside the kernel...)