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

["Zuniga, Juan Carlos" <[e-mail]>]

Hello,

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

Jc

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



> 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.

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). 

> 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.
> 
> Hopefully we can spend a few minutes on these issues on the conf call.
> 
> - gabor
> 
> -----Original Message-----
> From: ext Telemaco Melia [mailto:[e-mail]]
> Sent: Thursday, August 30, 2007 8:46 AM
> To: [e-mail]
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt
> 



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

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