Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Thu, 11 Oct 2001 11:39:56 +1000

Hi Rajeev, 

> >  > I don't understand why this problem is specific to binding updates.
> >  > Are you saying that under such a reservation, the packet size can't
> >  > vary at all ? If I have been sending 1000 bytes, which is way less
> >  > than 1280, if I send 1020 bytes, will it be dropped ? Then when such
> >  > a tight channel is reserved there should be indication to IP to
> >  > change its MTU value so that path mtu discovery can kick in.
> >
> >    Yup, that's the problem. It really has nothing to do
> >    with MTU; it's about keeping within the constraint of
> >    a reservation. MTU is link based, not flow based afterall.
> >
> 
> It is not entirely accurate to say that you cannot piggyback when using a
> dedicated channel. For instance, it is well-known that header compression
> gain can vary from packet to packet, thus affecting the compressor states.
> In a dedicated channel, which is what this thread is focussing on
> I assume, in order to accommodate `header bursts', you need to reserve for
> the worst-case. 
> 
	=> Sure, that would solve it, but wouldn't that add additional
	costs for a user ? For instance if I reserve for the worste case
	which will only happen rarely compared to the BW required 
	for my application, it would seem like I'm paying more than
	I need for y application. 
	I don''t really think the problems are significantly different 
	for Header compression (ie. whether you piggyback or not)
	so I'm more concerned about the BW reservation consequences.

	Regards,
	Hesham

> >         Mike

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 11 Oct 2001 10:20:33 -0700

Hello Hesham,

>      so I'm more concerned about the BW reservation consequences.

Well, if you support Full IP header transmission at all, with or without
header compression, you already are reserving for the worst-case. If you
don't have header compression, you have to reserve taking into account
the header bytes for all packets. If you have header compression, only
few (init, refresh) packets would need more bytes.

Anyway, my point is that some "wiggle" room will likely exist in
channels supporting IP for piggybacking.

Regards,

-Rajeev

---

From: Michael Thomas <[email-masked]>
Date: Thu, 11 Oct 2001 11:09:58 -0700 (PDT)

> channels supporting IP for piggybacking.

   Again, I'd like to see a MAC which works well with
   real time traffic on a shared access media
   because I know that the DOCSIS MAC specifically
   made the tradeoff of using the less efficient
   payload header supression which works well with
   TDM-like slots, where CRTP (or ROHC) does not.
   I guarantee you that cable MSO's are paranoid 
   about upstream bandwidth too.

   Until then, I chalk this up to wishful thinking.

	       Mike

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 11 Oct 2001 11:42:15 -0700

>    Until then, I chalk this up to wishful thinking.

You might want to look into some ROHC implementations.

Regards,

-Rajeev

---

From: Michael Thomas <[email-masked]>
Date: Thu, 11 Oct 2001 12:05:54 -0700 (PDT)

> You might want to look into some ROHC implementations.

   This is getting pretty frustrating.

   This has nothing to do with ROHC implementations.

   I have asked about 4 times now for a pointer to
   an L2 on a shared media which has the VBR 
   characteristics you claim exist which do not 
   compromise latency or bandwidth.

   Until you can come up with _one_ example, I'm
   going to assume that it does not exist and that 
   ROHC and piggybacking will result in unacceptible
   bandwidth use for real time traffic on shared 
   media.

		Mike