Subject: questions on draft-ietf-intserv-rsvp-use-00.txt

From: Roch Guerin <[email-masked]>
Date: Wed, 14 Aug 1996 18:37:08 -0400

John and Bob, 

I agree with Lou.  Also, currently John's doc states (bottom of p. 6
and top of p. 7):

   Upon arrival at a receiver, the complete absence of
   an ADSPEC fragment for a specific service indicates to receivers that
   the service should not be used.

Since all services now have ADSPECs, including CL, it seems to me
that this makes it mandatory for ADSPEC to be supported.

In addition to this, I had a couple of other questions.

- In the SENDER_TSPEC object, there is still a service number field,
  but it is my understanding that this WILL NOT be used by a sender to
  select a particular service, i.e., senders will ALWAYS use service
  number 1.  This is consistent with the note on p. 7 that states that
  in order to dictate which service receivers should use, it would
  only include the corresponding ADSPEC (instead of using a service
  number in its SENDER_TSPEC).  
  I just wanted to confirm that this was the case otherwise there are
  a bunch of error scenarios to consider.

- In the discussion on p. 9 wrt MTU negotiations, I'm not sure I
  understand exactly what the last paragraph appears to be requiring,
  i.e., 
 
   - When the completely merged RESV message arrives at each sender,
     the MTU value (M parameter) in the merged FLOWSPEC object will have
     been set to the smallest acceptable MTU of the data paths from that
     sender to any session receiver. This MTU should be used by the
     sending application to size its packets. Any packets larger than
     this MTU may be delivered as best-effort rather than covered by the
     session's resource reservation.

It seems to me that this requires the sender to adjust its MTU
whenever a new receiver joins that may have a smaller MTU than what
was previously OK, if it wants the reservation to reach that receiver.
I don't know of many applications where you could be doing that
dynamically.  The traditional option would seem to be to rely on
fragmentation when and where needed while also hoping that the sender
can set its MTU "correctly" from the information in the FLOWSPEC.
I guess my question is more in terms of what are the expectations both
for the senders and the intermediate network element in terms of
fragmentation support.

Thanks.   
Roch

---

From: John Wroclawski <[email-masked]>
Date: Wed, 14 Aug 1996 19:19:58 -0400

At 6:37 PM -0400 8/14/96, Roch Guerin wrote:
>     sending application to size its packets.
>

It does, yes. The service documents, and I believe RSVP as well,
specifically do not support fragmented packets. One problem is that the
RSVP filters can't identify fragments other than the first. Another problem
is that fragmentation totally screws up your ability to compute the
link-level overhead of a packet when doing admission control.

-john

---

From: John Wroclawski <[email-masked]>
Date: Wed, 14 Aug 1996 19:28:44 -0400

>  number in its SENDER_TSPEC).

Roch,
This is what I meant to say, yes.

---

From: Steven Berson <[email-masked]>
Date: Thu, 15 Aug 1996 10:48:12 -0700 (PDT)

> for the senders and the intermediate network element in terms of

Note that the MTU might also need to be adjusted in the case of a
route change.

Cheers,
Steve