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

From: Phil Roberts <[email-masked]>
Date: Wed, 13 Feb 2002 14:47:30 -0500

> This last point is not a fair characterization: I can come up 
> with many 
> links that
> would be abused if piggybacking was NOT used, and the 
> receiver severely 
> bruised.
> Such a statement can be written for any functionality, replace 
> 'piggybacked BU' with
> your least favorite functionality. I hope this does not show 
> a bias of 
> the DT.
> 

Cedric,

No, it was an attempt to capture assertions made on the list.

Phil

---

From: "Glenn Morrow"<[email-masked]>
Date: Thu, 14 Feb 2002 13:51:32 -0600

I agree too.

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: Thursday, February 14, 2002 1:31 PM
> To: [email-masked]
> Cc: Erik Nordmark; James Kempf
> Subject: Re: [mobile-ip] Piggybacking - DT recommendation
> 
> 
> Hello folks,
> 
> James Kempf wrote:
> 
> > If we don't start now, it will take even longer to get the change. I
> > don't
> > understand why we couldn't simply allow piggybacking
> > with the caveat that you shouldn't use it with IPSec, then start
> > working with the IPSec group to come up with a solution 
> that will work.
> > The MN doesn't have to send the BU as part of an IPSec secured
> > TCP stream, it could send it separately.
> 
> I think this is a very realistic answer, which I fully support.
> Since it provides what everyone wants, I think it is the
> consensus-building approach, and should be endorsed by the
> design team.
> 
> > Sorry, since I wasn't part of the DT, I'm not up on the specifics of
> > this. What is the problem with simply specifying that the BU header
> > is within the authenticated or encrypted part of the packet covered
> > by the AH or ESP header?
> 
> If the payload requires a different security policy than the
> Binding Update authentication, then the BU can include the
> Binding Authentication Data suboption, and all is well.
> 
> 
> Regards,
> Charlie P.
>

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 15 Feb 2002 12:42:17 +0100

James,

  > > => I've tried to show several times that the best
  > > way to support MIPv6 signalling on a link with
  > > QoS support is to separate the signalling packets
  > > form the normal traffic. If anyone thinks
  > > this is unreasonable then please explain why. 
  > > 
  > 
  > Sure, radio links would all work *much* better if
  > we got to use a special channel for IP signaling.
  > Maybe someday this will happen, but the
  > fact of the matter is, today it doesn't.

=> It does. WCDMA already has separate
bearers for different types of traffic.
They can be reused or new ones can easily
be defined. But I think the existing ones
are fine. I don't know about the specifics
of cdma2000 but I find it very hard to
see why the same can't be done. Unless it 
doesn't provide QoS assurances, which seems
unlikely. It's a matter of mapping IP
packets on the right bearers. No magic
at all.

  > > => A BSA would only exist if an appropriate mechanism
  > > was used. I think that can be done with RR+CGA. 
  > > Just because you have an IPsec SA, doesn't mean you
  > > are authorised to send the BU. It's an address
  > > ownership problem and that's why we need RR. 
  > > 
  > 
  > How long do you think a handover
  > would take if the MN had to do RR in order to
  > update a binding at a MAP? 

=> Too long :) Which is why I keep saying
that we should get CGAs done pretty quickly. 
I think a lot of detailed work was done 
by several people from several 
organisations. I haven't seen any serious 
technical concerns raised against the CGA concept. 

Hesham

---

From: "Glenn Morrow"<[email-masked]>
Date: Tue, 19 Feb 2002 11:30:39 -0600

From a cellular perspective I only see a few tenable solutions:

One way would be to RF temporarily pump up the volume a bit in order to send
a little bit more information in a smaller amount of time; however, I
suspect many will say it is better to keep the volume at the same level for
a longer time. They may also say we don't want to change the MAC/LAC layer
to do this?

Another method would be to use ROHC or their LMM device to separate the PDUs
and send the BU over another variable bearer on the reverse path to the
receiving  mobile. The way the MIPv6 signaling and IPv6 (no checksum) are
defined it can be separated.

In both cases on the forward path a mobile would likely not piggyback when
connected to these cellular links.  

But again these are access specific solutions and issues. So the point is
that there are work-arounds for this that can be done in the access SDOs.

Thanks,

Glenn

> From: James Kempf [mailto:[email-masked]]
> Sent: Monday, February 18, 2002 5:53 PM
> Hi Dave,
> > It seems to me that you can have all the benefits, with none of the
> > tricky tradeoffs with security and processing semantics of 
> piggybacked
> > BUs if instead of doing intra-packet piggybacking, we 
> simply defined a
> > simple way to put two or more IP packets into one L2 frame, 
> and hence
> > one radio frame transmission.
> >
> 
> I think what you mean is two or more IP packets per scheduled packet
> transmission slot. Radio L2 frame sizes vary, of course, but on most
> cellular
> systems they are on the order of 40 bytes. This would be just 
> enough to
> carry one uncompressed IPv6 header with no header options.
> 
> > My reading of why piggybacking wins is because you avoid
> re-arbitrating
> > and re-scheduling the radio channel, not because one packet is all
> that
> > much smaller than two (with header compression and the two packets
> going
> > between the same pair of addresses, the two-packet header 
> scheme might
> > be even shorter)!
> >
> 
> Don't know about the last point, but I agree that being able 
> to schedule
> more than one packet per packet transmission slot could 
> potentially have
> the same effect as piggybacking.
> 
> The problem is that this falls into the same category as Hesham's
> suggestion that IP signaling be done over a separate 
> signaling channel.
> I don't believe it works that way today. One argument people have
> expressed for
> getting rid of piggybacking is: "It interferes with IPSec and Jeff
> Schiller
> has indicated that we should not expect IPSec to change to accommodate
> Mobile IP in the near future (or possibly ever?, that wasn't 
> clear)." If
> changing IPSec in the near future is hard, then I'd venture to guess
> that
> changing the 3GPP or 3GPP2 MAC layers is probably nigh on impossible.
> 
> But certainly 3GPP and 3GPP2 are not the last cellular radio protocols
> that will ever get designed and if we can ever get together a
> comprehensive
> set of recommendations to L2 designers about what makes a good radio
> L2 for IP, this would be high among the recommendations.
> 
>             jak
> 
> 
> 
>

---

From: "Glenn Morrow"<[email-masked]>
Date: Tue, 19 Feb 2002 12:13:56 -0600

I also need to mention that this is only an issue for these optimized voice
bearers. For instance non voice traffic doesn't really have this problem
because they use more flexible variable bearers.

-----Original Message-----
From: Morrow, Glenn [RICH2:C330:EXCH] 
Sent: Tuesday, February 19, 2002 11:31 AM
To: [email-masked]
Subject: RE: [mobile-ip] Piggybacking - DT recommendation

Thanks, 

Glenn 

> From: James Kempf [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: "Glenn Morrow"<[email-masked]>
Date: Wed, 20 Feb 2002 09:50:50 -0600

John,

The use of the MTU seems to be extremely reasonable and quite simple, too.

Thanks,

Glenn

> 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: "Glenn Morrow"<[email-masked]>
Date: Wed, 20 Feb 2002 13:21:06 -0600

Some more thoughts came up on this:

Perhaps we should use SDP to indicate something like MTU or piggybacking
preference and alter the socket API to allow per-flow/media policy. 

This would allow these non-transparent bearers to exist while not detracting
the benefits of piggybacking when it simply isn't a concern.

Of course this would be doing extra work in the upper layers and APIs just
for these special link layers and the jitter point would still be an area of
contention. 

regards,

Glenn

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, February 20, 2002 11:30 AM
> [email-masked] writes:
>  > Hi Michael,
>  > 
>  > >    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).
>  > 
>  > So, if a layer 2 API which had QoS info that a MIP implementation
>  > could leverage, there may not be complications.  Of course, this
>  > is an IF ... however, I think Erik did bring NSIS into the
>  > discussion, and I'd be happy to get some input on level 3
>  > MIP QoS needs in NSIS. 
> 
>    This isn't an issue of information and/or
>    signaling. It's an issue of how bits are placed
>    on the wire. Many shared media L2 QoS schemes
>    like fixed sized slots, and piggybacking is
>    harmful when they are used willy-nilly,
>    especially by senders who don't know that
>    altering the payload size of a flow is harmful.
> 
> 	   Mike
>