Subject: [MIPSHOP-MIH-DT] Still [Transport] issues

From: <[email-masked]>
Date: Tue, 4 Sep 2007 04:45:28 -0500

Hi,

I am still wondering, if the transport we have chosen are the right
ones. I understand that ES and CS are rather small messages, and having
UDP carrying them would be good enough. The problem is, that these two
types of messages fall under a "push" model, where the network would
unsolicitedly send these messages over udp. If there are to be
middlebozes in between, those will cause problems. Current NATs do not
have a well specified timeout period but it seems that 30 sec is quite
ofter used.

IS on the other had is more like a pull model, so no major problems for
the middleboxes. If MIH would have applic layer fragmentation, then I'd
say udp would certainly fit better here than tcp.

We could say that any choice is as good (or as bad) as the other one, it
mainly depends on the deployment scenario which we still do no know. I
was just trying to point out that avoiding udp fragmentation must not be
the only consideration to be taken into account.

Hopefully we can spend a few minutes on these issues on the conf call.

- gabor

-----Original Message-----
From: ext Telemaco Melia [mailto:[email-masked]] 
Sent: Thursday, August 30, 2007 8:46 AM
To: [email-masked]
Subject: [MIPSHOP-MIH-DT] Current status

Dear all,

I have been reading the input Gabor provided with the IDs
draft-bajko-mos-dhcp-options-00 and draft-bajko-mos-dns-discovery-00.
Thanks Gabor for the work. Here my comments:

o draft-bajko-mos-dhcp-options-00
-1 terminology section should be aligned with the PS doc
-2 introduction section: I do not think it is required, I would prefer
to refer to the solution doc and move the text there if you want.
-3 discussion on co-located MoS: move it to the solution document when
we talk about the transport

o draft-bajko-mos-dns-discovery-00
- same as before for 1 and 2
- refer to the solution document when you discuss on the selection of
the transport

During the nect AC we should then discuss the open points noted in the
draft.
I also would like to receive from Nada an update of the current status
and see what text we can included in the first version of the document.

As for the time of the AC I would propose to have it at 14:00 CET on
Tuesday September 4th.
Would  be fine with everybody?

Please le me know

Telemac

_______________________________________________
MIPSHOP-MIH-DT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

---

From: Sam Xia <[email-masked]>
Date: Tue, 04 Sep 2007 17:48:00 +0800

hi all,
Today's meeting is too late for me in Beijing.  I am glad that we have made
progress now than before.  For this initial verison, i have some comments.

1: General comments:
Except the discovery parts that seems like a solution, the other part look
more like architecture/suggestion, not like a detailed solution. I am sure
that there should be a distance to pushing this draft to become a working
group draft. we have to make more progress.

2: Technical  omments on the detailed text:

2.1: about the scenarios:
we have introduced four kinds of scenarios.  Is is possible that there
exists scenario mixture-output  from listed four scenarios?

2.2 about "section 4: solution overview"

we have good input from Gabor about discovery. But we have nothing about
transport protocol, rough description about architecture. we have to get
more valuable input.

2.3 about discovery mechnism using DHCP
since we support 4 kinds of different scenarios using DHCP discovery
mechnism, it is very possible that it is mobile node who designates which
MoSx will be used.  I suggest that we could add a DHCP option to express its
preference of MoSx in DHCP discovery/request messages.

2.4 about "draft-bajko-DHCP-discovery"
I have checked DHCP code space. It seems that we have no enough code value
to support 3 kinds MIH Service(IS, ES, CS).  My suggestion is that we could
converge 3 kinds of different codes (codes for is, es,cs) into one code that
is just mih code. and then we could design sub option to describe
information for IS, ES, CS.

2.5 about "section 6: MIH transport"
First, thanks Carlos for his input. 

>From the text,  I draw a conclusion that only one tranasport protocol can be
used for MIH message transport at the same time. Right?
As a good and flexible solution, we should provide means to let user select
and swith transport procol.
Could you tell me what the interface between MSTP and its user(MIHF) should
look like as well as corresponging interface attribute?  As a solution, I
think that we should prescribe the Server Access Point(primitive).

2.6 about  "section 8: Security Considerations"
Sorry, subir. It is not a good input.

Firstly, we should take into considerations security issues between MN and
MIH service provider.  not just security issue between MN and DNS server or
DHCP server. These issues are not introduced by MIH trasnport protocol. We
should focus on issue we have introduced when we are designing a new
protocol. right?

Secondly, this section does not discuss the security requirements, just
mentions making reference to PS document.  It is not good.

Thirdly,  this section does not discuss the security solution. 

Fourth, this section dees not discuss how to authenticate, replay
protect....

3: Question

If the WG adopts the solution draft, what about Gabor's two new drafts?

 Best Regards, Sam Xia 

> From: Telemaco Melia [mailto:[email-masked]] 
> Sent: Thursday, August 30, 2007 11:46 PM
> -2 introduction section: I do not think it is required, I 
> would prefer to refer to the solution doc and move the text 
> there if you want.
> -3 discussion on co-located MoS: move it to the solution 
> document when we talk about the transport
> 
> - refer to the solution document when you discuss on the 
> selection of the transport
> 
> During the nect AC we should then discuss the open points 
> noted in the draft.
> I also would like to receive from Nada an update of the 
> current status and see what text we can included in the first 
> version of the document.
> 
> As for the time of the AC I would propose to have it at 14:00 
> CET on Tuesday September 4th.
> Telemaco

---

From: Sam Xia <[email-masked]>
Date: Tue, 04 Sep 2007 17:59:09 +0800

> Hi,
> 
> I am still wondering, if the transport we have chosen are the 
> right ones. I understand that ES and CS are rather small 
> messages, and having UDP carrying them would be good enough. 
> The problem is, that these two types of messages fall under a 
> "push" model, where the network would unsolicitedly send 
> these messages over udp. If there are to be middlebozes in 
> between, those will cause problems. Current NATs do not have 
> a well specified timeout period but it seems that 30 sec is 
> quite ofter used.

Sam>
Could you expand more?  sorry that i don't know why  ES and CS fall in
"push" model and what is your meaning of "network would unsolicitedly send 
 these messages over udp". and why NATs do not work well for "push" model.

> IS on the other had is more like a pull model, so no major 
> problems for the middleboxes. If MIH would have applic layer 
> fragmentation, then I'd say udp would certainly fit better 
> here than tcp.

Sam>
I have the same question.

> 
> We could say that any choice is as good (or as bad) as the 
> other one, it mainly depends on the deployment scenario which 
> we still do no know. I was just trying to point out that 
> avoiding udp fragmentation must not be the only consideration 
> to be taken into account.
>

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Tue, 4 Sep 2007 09:21:10 -0400

Hello,

Some more comments about the middlebox traversal (see below).

Jc

-----Original Message-----
From: Sam Xia [mailto:[email-masked]] 
Sent: September 4, 2007 5:59 AM
To: [email-masked]; [email-masked];
[email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Still [Transport] issues

Sam>
Could you expand more?  sorry that i don't know why  ES and CS fall in
"push" model and what is your meaning of "network would unsolicitedly
send 
 these messages over udp". and why NATs do not work well for "push"
model.

JCZ>
The real issue for middlebox traversal is not whether the model is push
or pull, but rather which side starts the transaction. The push or pull
would happen above the transport and for us sending an MIH Request, an
Indication or a Response does not look too different. The issue is for
instance in the NAT traversal whether the transaction is initiated on
the private or on the public side. Assuming that the MN discovers and
registers with the MIHF at the Network side, middlebox traversal would
not be an issue. After that, we can only give recommendations (like
draft-ietf-tsvwg-udp-guidelines), to refresh the middlebox state (e.g.
keep binding). 

Sam>

---

From: <[email-masked]>
Date: Tue, 4 Sep 2007 08:52:25 -0500

Inline: 

-----Original Message-----
From: ext Zuniga, Juan Carlos
[mailto:[email-masked]] 
JCZ>
The real issue for middlebox traversal is not whether the model is push
or pull, but rather which side starts the transaction. 

<gabor> that is what I meant, I thought the equivalence is obvious. In
pull model, you as a client start the communication and you are in
control on when the data flows. In push, the other side may send you
information at any time, thus you as a client need to make sure that you
keep open your udp connection through the NAT.

The push or pull
not be an issue. 

<gabor> two things: middlebox is not just NAT, it can be a firewall or
any ALG.
In case of firewalls dropping udp the situation is much worse, while
with tcp aware firewalls, there are no issues.

NATs ARE AN ISSUE!! This is what the whole ietf is talking for the last
2 years! If not else, it requires the clients to send periodic
keepalives to keep the udp binding alive in the box, and that drains out
the battery of a mobile terminal. The situation is so bad, that
currently some applications are not present on the phones because of
this issue. 

So let's not trivialize an important issue. At least it has to be
considered, analysed, mentioned. The good thing is, that there is
nothing MIH specific in it, so we could refer to already existing
problem statements and solutions.

- gabor

After that, we can only give recommendations (like
draft-ietf-tsvwg-udp-guidelines), to refresh the middlebox state (e.g.
keep binding). 

Sam>

---

From: Telemaco Melia <[email-masked]>
Date: Tue, 04 Sep 2007 16:09:01 +0200

Hi all,

Let's go through these issues during the AC and assign action points to 
update the document accordingly.

tele

-- 
Dr. Telemaco Melia			[email-masked]
Senior Research Staff Member		Tel: +49 (0) 6221 4342- 142
NEC Europe Ltd.
NEC Laboratories Europe
Network Division			
Kurfürsten-Anlage 36		
69115 Heidelberg
GERMANY	  

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014