Subject: RE: [mobile-ip] Piggybacking - DT recommendation

From: [email-masked]
Date: Wed, 20 Feb 2002 09:08:09 +0200

Hi Erik,

> It's my understanding that the NSIS WG is at least looking into
> signalling that isn't end-to-end i.e. the receiver might have done QoS
> signalling one or a few hops into the network but not all the 
> way through the network. Thus the sender wouldn't necessarily know this 
> as part of some QoS signalling mechanisms. 

As NSIS chair, I sense this QoS discussion, in my opinion, is best discussed
else where (like NSIS).  We are currently discussing requirements, and
I am sensing a requirement here.  

Personally, I think this issue with respect to piggybacking should be 
limited to:

1) MIP implementations should ensure that piggybacked data does not excede
   path MTU.
2) If a tight QoS channel is negotiated, piggybacking should be considered.

I think point 1 is something that should be located in the MIPv6 document,
while point 2 should be put into the NSIS requirements document.

Is this sensible?

Additionally, NSIS is trying to ensure that QoS is still end-to-end,
but some of the QoS reservations may not be.  For example, one might
like to explicitly reserve resources in an access network, while not
reserving anything in the backbone / transit network.  However,
to insure fairness, there should be a mechanism in place to be able
inform on an end-to-end basis about the signaled QoS.

best regards,
John

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Feb 2002 07:38:19 -0800 (PST)

> I am sensing a requirement here.  

   No. This entire subject has to do with whether
   piggybacking is useful for mac/phy's whose method
   for allocating bandwidth for elevated QoS is to
   give fixed sized slots. DOCSIS USG is a perfect
   example, and is illustrative of how bandwidth
   can be parceled out on a shared media. Wireless
   has *many* of the same considerations. For
   those kinds of media, piggybacking is a
   distinct disadvantage, especially if it affects
   downstream flows (which a sender would be
   clueless about).
   
   This has nothing to do with L3 QoS signaling.

	    Mike