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

From: [email-masked]
Date: Thu, 4 Nov 1999 12:09:59 -0800

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

Lou,

I believe their point was that it is a bad idea to deliberately inject
significant additional delay (non-work-conservation) into the process.
This seems an obviously valid concern.  The only question seems to be
whether it is necessary to put an explicit bound on it in the spec, or
whether a note of the danger plus some guidelines (like the famous 30
second refresh timeout) would be suffcient.

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

Again, the RTT is one measure of what "signficant additional delay"
would mean.  The question before us is whether an RSVP needs to
dynamically measure the RTT to each neighbor in order to set a
reasonable bundle delay, or whether we should leave this to reasonable
defaults that may be overridden by network managers.

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

....

  *> >
  *> >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?
  *> 
  *> 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 neighbor relation will almost always be symmetric (except when
there is a non-RSVP cloud), so there should be a constant flow of ACKs
in the reverse direction to the Srefresh messages.  The question is why
the same argument that led to MESSAGE_ID_LIST objects does not hold
equally for ACK objects.

Your reply depends upon using ACK messages; but suppose ACK objects
are piggy-backed on Srefresh messages instead.

(There *may* be an argument on your side here, but it ultimately depends
upon the thrash rate).

  *> 
  *> >BTW: this can be perhaps linked to Braden's note of a few days ago, about
  *> >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.

If he can find the time...
:-(

Braden Himself

---

From: Lou Berger <[email-masked]>
Date: Thu, 04 Nov 1999 16:45:21 -0500

>second refresh timeout) would be suffcient.

Bob,
         I understood that point and agree that there should be some text 
on this topic added to the document.  (I even said this in an earlier 
message.)  I think including a default value in this text is reasonable.  I 
think adding the Urgent-bit provides such minimal value it's not worth 
adding.

(BTW the semantics of the bit are broken since it has an end-to-end 
construct being carried in a hop-by-hop object.  This can be fixed by 
moving the flag into the RSVP message header.)

What I was referring to in the above message is that they are introducing a 
new concept into rsvp, i.e., bounded setup time.  Also, given the 
asynchronous nature of generic RSVP I don't see how to support this.  I'm 
specifically referring to the way Path and Resvs messages are independently 
sent by applications at the source and destination.  How can a source be 
told by the network how long it'll take for the application to send a 
Resv?  From the destination's side and for unicast sessions with single 
sources, I can see how a destination can be told a somewhat representative 
upper bound on how long the Resv will take to reach a single source.  With 
multiple sources, there needs to be a per source value.  Finally, given the 
way multicast merging works I also don't see how RSVP can even support 
providing such an estimate without blowing some of RSVP's multicast scaling 
properties.

If you're willing to limit the scenario where bounded setup time is 
provided to a single source and a unicast destination AND require the 
application at the destination to have requested a reservation before a 
path message is received, then I can see how to provide an estimated upper 
bound on setup time.

Given that this proposal is really extending RSVP in a totally new 
direction, I definitely feel that no matter what, the refresh-reduct draft 
is not the right place for it and it should be pursued independently.

>defaults that may be overridden by network managers.

Your recasting their original question.  They said use to use RTT to "let 
the application exactly determine the worst case delay caused by bundling 
(25% of the estimated end-to-end RTT)."  My response was that RTT doesn't 
provide enough information to the application to be practically useful.  I 
didn't even mention the more serious issue of gauging application response 
time.

>the same argument that led to MESSAGE_ID_LIST objects does not hold

Because a single Ack can be used for a whole Srefresh message.

In the case of when Srefreshes are used Acks will only be used on trigger 
messages and Srefreshes.  In this case the Ack load will really just be 
proportional to the number of state changes (reflected in trigger messages) 
that will be occurring simultaneously.

>are piggy-backed on Srefresh messages instead.

Using list objects will always ~double the number of acks that can be sent 
in a message.

>(There *may* be an argument on your side here, but it ultimately depends

Right.  If we didn't have Srefresh messages I might feel differently.

>If he can find the time...

Thanks for commenting.  I look forward to your comments on the update.  I 
think it benefited from the last round of comments.

Lou

>Braden Himself

;-)

---

From: Masanobu Yuhara <[email-masked]>
Date: Mon, 08 Nov 1999 21:46:39 +0900

all,

braden> I believe their point was that it is a bad idea to deliberately inject
braden> significant additional delay (non-work-conservation) into the process.
braden> This seems an obviously valid concern.  The only question seems to be
braden> whether it is necessary to put an explicit bound on it in the spec, or
braden> whether a note of the danger plus some guidelines (like the famous 30
braden> second refresh timeout) would be suffcient.

I think it would be clearner if we don't explicitly specify the delay.
The bundling delay can be implementation dependent, but the 
semantics of Refresh Period (R) should stand as RFC2205.

If an implementation first timeouts for refresh and then delays some
time for bundling, then the timeout must always occur earlier than
1.5*R (Note: RSVP refresh period is random [0.5R, 1.5R]).

All we need to say is similar to the following sentences on Srefresh:

>   Specifically, the use of
>   Srefresh messages MUST NOT result in state being timed-out at the
>   RSVP next hop.  The period at which state is refreshed when using
>   Srefresh messages MAY be shorter than the period that would be used
>   when using Path or Resv message based refreshes, but it MUST NOT be
>   longer.

If we wan to go beyond this, we're talking about the original spec.,
and not the topic for the refresh-reduct draft.

For delayed-ACKs, howeber, we need to say something more because
there's no ACKs in RFC2205.  In order to make "rapid retransmission"
work, ACKs should not be delayed long. Frankly, I don't know how to
integrate "rapid retransmission" and delayed-ACKs.

(I will not be at the meeting, but my colleague will.)

------
Masanobu Yuhara		[email-masked]
Fujitsu Laboratories Ltd.