Subject: RE: RFC2961 BUNDLE message

From: Dimitrios Pendarakis <[email-masked]>
Date: Thu, 25 Oct 2001 17:31:13 -0400

One benefit of the Bundle message, which might be more
relevant in the optical domain, is that it potentially 
could be used to signal set-up of multiple LSPs (lightpaths) 
at the same time.

There was some discussion in the context of the OIF UNI
about signaling multiple lightpaths simultaneously; but
it was not included in the final UNI 1.0 spec.
The idea was that it would be beneficial to path computation, 
for example.

Dimitris

> -----Original Message-----
> From: Yousuf Hasan [mailto:[email-masked]]
> Sent: Thursday, October 25, 2001 3:27 PM
> To: Feng, Mark
> Cc: 'Arvind, K'; [email-masked]'
> Subject: RE: RFC2961 BUNDLE message
> 
> 
> At 12:07 PM 10/25/2001 -0700, Feng, Mark wrote:
> >One thing it saves is the IP header, since multiple RSVP 
> message will be
> >packed into one.
> 
> The Summary Refresh helps solve the scaling issue a little 
> more, but it can only be used for messages in steady state.  
> Thanks
> 
> -Yousuf 
> 
> 
> 
> >If the question is, by the Bundle message itself, helps the 
> scaling problem.
> >IMO, not a whole lot.
> >
> >- Mark
> >
> >> -----Original Message-----
> >> From: Arvind, K [mailto:[email-masked]]
> >> Sent: Thursday, October 25, 2001 11:47 AM
> >> To: [email-masked]'
> >> Cc: Arvind, K
> >> Subject: RFC2961 BUNDLE message
> >> 
> >> 
> >> Does the BUNDLE message offer any real benefit in terms of 
> >> reducing control
> >> overhead? There seems to be no significant change in the 
> >> overall amount of
> >> control traffic that is generated or processed as a result of 
> >> bundling (even
> >> though the traffic is bunched together resulting in fewer 
> (but larger)
> >> messages). Does this mechanism really help in scaling RSVP?  
> >> Could someone
> >> throw light on this? Thanks.
> >> 
> >> Regards,
> >> Arvind.
> >> 
> 
>

---

From: "Feng, Mark" <[email-masked]>
Date: Sat, 27 Oct 2001 11:31:58 -0700

I stand corrected. That makes sense.

Thanks.

- Mark

> From: Ping Pan [mailto:[email-masked]]
> Sent: Friday, October 26, 2001 3:11 PM
> To: Feng, Mark
> Subject: Re: RFC2961 BUNDLE message
> 
> 
> Mark,
> 
> I'm not sure that the packet size matters much here. A while 
> ago, I had
> measured processing time vs. packet size on 4.4 BSD. It was almost a
> flat line. Bundling was designed to improve I/O efficiency, 
> not to save
> packet size.
> 
> - Ping
> 
> 
> "Feng, Mark" wrote:
> >

---

From: Khuzema Pithewan <[email-masked]>
Date: Mon, 29 Oct 2001 10:34:24 +0530

Hi,

Irrespective of whether network is MPLS enabled or not, Srefresh messages
does reduces the number of Control Messages flowing on the wire drastically.
Too many control messages is one of dis-advantage of RSVP over LDP/CR-LDP in
MPLS network. Refresh reduction solves this problem through Srefresh
messages....

Khuzema. 

> ----------
> From: 	Ping Pan[SMTP:[email-masked]]
> Sent: 	Saturday, October 27, 2001 3:32 AM
> To: 	Arvind, K
> Cc: 	[email-masked]'
> Arvind,
> RSVP soft-state refresh has two significant scaling problems: 
> - there are too many control packets on the wire, and 
> - refresh and trigger messages look the same (so they have to be
> processed the same way). 
> 
> RFC2961 is to fix both problems. Bundling message can stuff multiple
> messages in one frame, so that a router can take care of multiple
> sessions in one shot. (This is very important in many operating systems,
> where I/O overhead is generally greater than memory copy.) So bundling
> reduces the total number of messages. With the help of Srefresh, you can
> process refresh messages differently.
> 
> In short, RFC2961 can improve the performance greatly. In MPLS networks,
> I don't see any scalability problem caused by RSVP.
> 
> - Ping
> 
> 
> "Arvind, K" wrote:
> > 
> > Does the BUNDLE message offer any real benefit in terms of reducing
> control
> > overhead? There seems to be no significant change in the overall amount
> of
> > control traffic that is generated or processed as a result of bundling
> (even
> > though the traffic is bunched together resulting in fewer (but larger)
> > messages). Does this mechanism really help in scaling RSVP?  Could
> someone