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

[<[e-mail]>]

Inline: 

-----Original Message-----
From: ext Zuniga, Juan Carlos
[mailto:[e-mail]] 
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
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. 

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

> 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