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

From: Franco Tommasi <[email-masked]>
Date: Wed, 3 Nov 1999 13:07:33 +0100

> 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
>

Lou, we`ll try to answer to your points:

> >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.

The Message_ID field in the MESSAGE_ID object has a size of 31 bits instead of
32. Here is why: when the first bit is fixed at the 0 value, the 31-bits field
is a Message_Id; when the first bit is fixed at the 1 value, the 31-bits field contains a compression-code.

In Bundle Messages nothing changes.

>
> >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.

Pasting from minutes of the interim meeting:
"  A cheap implementation of packing functionality is to insert a small
  latency in output buffer (e.g. 100 msec), to collect together
  messages bound to particular next/previous hop."

We agree that 100msec is perhaps too high, and that 5msec could be good or
perhaps too low....

We think:

1) An upper bound to the bundling delay MUST be given at the protocol level:
this is to avoid high delays caused by unaware implementors.

2) This value has a strong dependency on the link's characteristic:
it seems reasonable to us to bound the bundling delay to a fraction (e.g. 25%) of the extimated RTT beetwen nodes choosing an upper bound for the slowest links (TBD, 100ms was a first guess). This is a way to let the application exactly determine the worst case delay caused by bundling (25% of the extimated end-to-end RTT). 

3) If, for some reason, the application finds the 25% delay (or whatever it is) too long to suffer, it can still set the urgent bit. We don`t see this as overkill. Think, for example, of a distributed computing application facing bundling delays.
Also we don`t see the Urgent mechanism as having an heavy impact on the protocol: just
stop bundling and transmit, when an Urgent trigger message is created.

>
> >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.)
>

We have already explained extensively to the chair (and sintetically to the WG as we wasn`t sure it was interesting for everybody) the history of the development of this extension.
We just kept the original formulation as it resulted in our draft posted in
July (sent before the Oslo meeting and resent three days after the meeting).

We note no particular differences between MESSAGE_ID LIST and
LIST_DESCRIPTOR objects.

> >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.
>

Hold a second! We propose to express a number of Message_IDs in a compressed form (differential, bitmap etc.) and not to compress the message's content (Wang) or to do refresh of Srefresh messages (Swallow).
In a few words, a node can recalculate the original list of Message_ID without referring to a previous one: it just "uncompresses" the list.

An example:

given the list:

150 (ID), 157 (ID), 160 (ID), 165 (ID)

Differential compression gives :

150 (ID), 7 (Diff), 3 (Diff), 5 (Diff), 

Bitmap compression gives:

150 (ID), 00000010010000100000000000000000 (Binary Bitmap), 

These operations can be made 'on the fly' (as well as uncompression).

Some rough analysis shows us that length of lists (and number of refresh
messages) is reduced of up to 10 times.

Again, this seems to us a good trade off between refresh-reduction
needs and increase in complexity.

We have seen Swallow's draft just yesterday.

>
> >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.
>

We don't propose list of Ack messages, we propose Ack messages with List  ID
objects.
Let see:

In draft-ietf-rsvp-refresh-reduct-01.txt:

     <ACK Message> ::= <Common Header> [ <INTEGRITY> ]
                           <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>
                           [ <MESSAGE_ID_ACK> ... ]
                           [ <MESSAGE_ID_NACK> ... ]

A list of objects is used: that is, 3 words and object-parsing for each ID
to be acked

In draft-tommasi-rsvp-enhan-scalab-01.txt:

    < Ack Message > ::= < Common Header > [ < INTEGRITY > ]
               < LIST_DESCRIPTOR >

A List object is used: that is, 1 words for each ID to be acked, and a
single object-parsing. If needed,  COMPRESSED_LIST_DESCRIPTOR objects can be
used instead.

In other words, we give to our object LIST_DESCRIPTOR a more general usage:
rules to process List objects were already given for refreshing purposes:
why don't "freely" use them in more general a way leading to considerable compression/compactness?
Isn`t this purpose our work is all about?

BTW: this can be perhaps linked to Braden's note of a few days ago, about
the high number/confusing relationships between ID objects.

> >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?
>

No.
We used WeakRefresh messages as a light-weight refresh, in a
similar way to your Srefresh ones.

We have still some perplexities about the mechanism of refreshing multicast
sessions in your draft-ietf-rsvp-refresh-reduct-01.txt draft (we read
Braden's comments about this issue).

> >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?
>

No, we don`t think so.

The Strong Refresh mechanism offers a global view of all the states to be refreshed, easily allowing detection of absences and new presences (essentially due to route changes).
The Srefreshes mechanism (as well the Weak Referesh one) doesn`t allow easy detection of absences.

Let`s try an example.

With Srefreshes and Weak Referesh:

1) An ID is sent, and is identified by receiver. Result: related state is refreshed.
2) An ID is sent, and is not identified by receiver. Result: a clarification message is sent.
3) An ID is not sent, and the receiver cannot assess its validity . Result: related state persists until timeout (thus wasting resources that could be freed soon).

With Strong Refresh, nothing changes for 1) and 2).

3) An ID is not sent, and the receiver can immediately decide it is not valid. Result: a clarification message is sent.

> >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.
> >
> >

Thanks for your comments,

Franco Tommasi <[email-masked]>
and
Simone Molendini <[email-masked]>

University of Lecce
Lecce - Italy

---

From: Lou Berger <[email-masked]>
Date: Wed, 03 Nov 1999 08:37:09 -0500

>Lou, we`ll try to answer to your points:

Franco, Simone,

         Thanks for the response.  I have some of my own in-line.

>field contains a compression-code.

Okay, so the difference is just linked to your compression proposal.

>In Bundle Messages nothing changes.

Then why partially define it?

>   messages bound to particular next/previous hop."

e.g. = for example.  This was the example given by the minutes author not 
of the interim meeting.  It doesn't state that this was the "interim 
meeting's decision."

>We agree that 100msec is perhaps too high, and that 5msec could be good or

5msec = 200pps.  If you have a much lower total RSVP message rate, the 
overhead of sending each message separately is likely to be tolerable so 
why bundle?

Also, I think we should remember we're talking about additional latency in 
*setup* NOT for data.  The setup process usually takes some time.

>this is to avoid high delays caused by unaware implementors.

As I just said, setup always takes a fair bit of time and RSVP has NEVER 
provided any mechanism to bound this.  (No other signaling protocol I know 
of does either.)  If your objective is to provide an "expected setup 
latency" upper bound to the RSVP user, you need to first define how this 
even works.  I'm not sure who to do this without doing almost the 
equivalent of a setup since to bound setup time, you need to know the full 
path taken to reach a destination and the control processing latency of 
each node along the path.

While this is a nice objective, I don't think it's viable.

>it seems reasonable to us to bound the bundling delay to a fraction (e.g. 
>25%) of the extimated RTT beetwen nodes choosing an upper bound for the 
>slowest links (TBD, 100ms was a first guess). This is a way to let the 
>application exactly determine the worst case delay caused by bundling (25% 
>of the extimated end-to-end RTT).

A RTT estimate doesn't take into account some expensive internal latencies 
or the number of simultaneous setup requests being processed.  In my 
experience RTT is only interesting in unloaded demo nets and for a few rare 
requests.

>3) If, for some reason, the application finds the 25% delay (or whatever 
>it is) too long to suffer, it can still set the urgent bit. We don`t see 
>this as overkill. Think, for example, of a distributed computing 
>application facing bundling delays.

The 'u-bit' itself isn't the issue.  It's a question of whether any 
optimization and resulting mechanism is needed to cover this case.  I think 
you know my opinion.

>We have already explained extensively to the chair (and sintetically to 
>the WG as we wasn`t sure it was interesting for everybody) the history of 
>the development of this extension.

This is good news to me.

>Hold a second! We propose to express a number of Message_IDs in a 
>compressed form (differential, bitmap etc.) and not to compress the 
>message's content (Wang) or to do refresh of Srefresh messages (Swallow).
>In a few words, a node can recalculate the original list of Message_ID 
>without referring to a previous one: it just "uncompresses" the list.
>
>An example:
>
>given the list:
>

Sounds like a topic for the meeting.

>We don't propose list of Ack messages, we propose Ack messages with List  ID

I thought that's what I said...

>Isn`t this purpose our work is all about?

Using the terms of the WG draft, I think your comment translates into a 
proposal to have ACK Messages also should be able to carry MESSAGE_ID LIST 
Objects.  Is this a correct characterization?

If so, my earlier comment still applies.  An Ack message currently can ack 
~175 messages in a 1500 byte packet.  Allowing Ack messages carry 
MESSAGE_ID LIST Objects doubles this to ~350.  Given Srefresh, I just don't 
see the need to add any optimization to cover the case where there are so 
many simultaneous unacknowledged RSVP messages.  I think the current 
mechanism of just generating multiple Ack messages is sufficient.

>the high number/confusing relationships between ID objects.

His comments were the reason for the new -01 version of the draft.  I'm 
sure he'll let us know if he still has issues.

>Braden's comments about this issue).

Again, we tried to address this in the -01 rev of the draft.  We will be 
talking about this in the WG.

>The Strong Refresh mechanism offers a global view of all the states to be 
>refreshed, easily allowing detection of absences and new presences 
>(essentially due to route changes).
>3) An ID is not sent, and the receiver cannot assess its validity . 
>Result: related state persists until timeout (thus wasting resources that 
>could be freed soon).
>
>3) An ID is not sent, and the receiver can immediately decide it is not 
>valid. Result: a clarification message is sent.

Thanks for the clarification.  You're right it doesn't overlap with 
swallow.  I does sound like it functionally overlaps with 
draft-wang-rsvp-state-compression.

Also, you don't get in to which of two refresh approaches should be used or 
do you see using them both together?

>Simone Molendini <[email-masked]>

Thank you for yours,
Lou