Subject: Re: new draft draft-tommasi-rsvp-enhan-scalab-01.txt

From: Lou Berger <[email-masked]>
Date: Mon, 01 Nov 1999 09:50:26 -0500

Franco, (Simone),

         There's a lot of overlap between your draft and ours
(draft-ietf-rsvp-refresh-reduct-01.txt).  I don't know about anyone else, 
but I'd find it (more) useful for you to send comments on the draft where 
overlap exists.  I think creating a derivative draft that has mostly 
equivalent functionality (with only some of the text) really just leads to 
confusion.  Certainly a new draft covering new functionality is reasonable.

I have some specific comments included in-line below.

Lou

At 10:38 PM 10/31/99 +0100, Franco Tommasi wrote:
>Sorry if this is the second time you receive this message (I didn`t 
>receive it from the list so I thought something went wrong).
>============================================================================
>
>Hi,
>
>A new version of our draft is available.
>
>You can download it from
>
>http://www.ietf.org/internet-drafts/draft-tommasi-rsvp-enhan-scalab-01.txt
>
>Its subject is RSVP scalability, and it updates the draft sent
>on the 1st of July (rejected; at the time we didn`t suspect of any 
>deadline, we apologize) and resent (successfully: 
>draft-tommasi-rsvp-enhan-scalab-00.txt) soon after the Oslo meeting.
>
>We will be in Washington, and we received a positive answer to our request 
>of a little time on the agenda to present the draft.
>
>Perhaps a few lines about its content can be of help.
>We would be happy to answer to comments and questions.
>
>Contents
>
>2.   MESSAGE_ID OBJECTS
>3.   BUNDLE MESSAGES
>Just pointers to Berger's work, with slight differences.

Comments on what you'd like to see changed in
draft-ietf-rsvp-refresh-reduct-01.txt would be most welcome.

>4.   HOW TO DELAY MESSAGES
>4.1. URGENT BIT
>The context is the interim meeting's decision, about using a
>100msec-delay-buffer for bundling's purposes.

The minutes of the meeting state "(e.g. 100 msec)".  This value *was not* 
the consensus of the attendees, just an illustration in the minutes of a 
possible value.  (I'm not even sure a value was mentioned.)  I personally 
think a more reasonable value would be 5ms.

Remember Bundling only makes sense when there is a high rate of RSVP 
messages.  (100ms = 10 mesg/sec != high)  Having the draft mention 
something about timing is a reasonable comment.  I think the urgent bit is 
overkill, but I'm sure we'll talk about it in DC.

>We think it is in general incorrect to force all application to suffer a 
>delay that could end up being greater than that caused by IP`s best-effort.
>So:
>1) The delay timer of the Bundle buffer is determined, when possible, as a
>percentage of the RTT between nodes.
>2) An Urgent bit is defined in trigger messages, so that these
>applications can escape the bundling delay.
>
>
>5.   LIST_DESCRIPTOR OBJECTS
>List of Message_IDs. Quite similar to Berger's MESSAGE_ID LIST objects: they
>where parallely developed.

Do you see the documented List mechanisms as being deficient in any way? 
(Note the mechanisms did not change between rev -00 and -01.)

>5.1. COMPRESSED_LIST_DESCRIPTOR OBJECTS
>Some simple compression mechanisms for LIST_DESCRIPTOR objects.
>(Their are used to simplify some operation like Strong Refresh)

My understanding is that WG has decided to pursue "compression" extensions 
independent of the other extensions.  (This was first discussed at the 
interim meeting in April.)  There are other proposals, see 
draft-wang-rsvp-state-compression-02.txt and 
draft-swallow-rsvp-hierarchical-refresh-00.txt.

>6.   ACK MESSAGES
>LIST_DESCRIPTOR objects for multple acks can be used.

Ack messages can already contain multiple acks.  Lists of Acks seems like 
overkill here.  My opinion is this unneeded optimization and I'm not 
convinced it's worth the incremental complexity.

>7.   WEAK REFRESH
>A simple refresh mechanism: just exchange messages with LIST_DESCRIPTOR
>objects.

Again, do you see any problems with draft-ietf-rsvp-refresh-reduct-01.txt?

>8.   STRONG REFRESH

Like other RSVP messages, Srefreshes can be Acked.  This provides reliable 
refresh.  The other functionality of this message is not clear, possibly it 
overlaps with draft-swallow-rsvp-hierarchical-refresh-00.txt?

>A reliable refresh mechanism. It is very useful on really congested links,
>to avoid state time-outs due to lost refresh messages.
>The full list of messages to be refreshed is exchanged, so that neighbor 
>routers
>can fully syncronize their state.
>COMPRESSED_LIST_DESCRIPTOR objects perhaps should be used.
>
>
>
>Best regards
>
>Franco Tommasi <[email-masked]>
>and
>Simone Molendini <[email-masked]>
>
>University of Lecce
>Lecce - Italy
>

I look forward to any comments you may have and meeting you in DC.

Lou